If You Could Go Back in Time...

time machine
Credit: Shutterstock
Turning back the clock

Every week brings news of breaches, cybercrime and state-sponsored hacks, each more shocking than the last.

Unfortunately, it's not practical to rip up the whole Internet and start over again with a more secure foundation.

But wouldn't it be nice if we could go back in time to when it was first being built, and shake some sense into the early developers?

We asked some security experts about what they would change if they could go back...

jordan becker
Credit: Shutterstock
Jordan Becker, BAE Systems, Inc.

"The early developers were universities, government labs and industrial research organizations," he said. "None of these were particularly security conscious. Back in those days, security was thought of as IP protection. They didn't think about threats and denial of service.

"If I could do that over again is source routing. The internet is based on destination routing -- you're worried about what the destination is, and you don't care what the source address is. And that turns out to be a big problem with voice and streaming video. The internet today remains a destination-based routing environment.

"In the early days, nobody cared if anyone could intercept traffic, because nobody is going to go out and try to intercept packets. Encryption came much later to the Internet world, and it is still an end-to-end problem, where the devices on the end points do encryption, not the Internet itself.

"There were a lot of accommodations made later on for how to do billing and payment that weren't designed up front. The early designers reserved a bit in the Internet header for type of service... But it's only one bit, so you don't have a lot of discretion.

"There wasn't a lot of thought put into those things. Later on, as we discovered the real requirements, we wound up building application protocols that were much more robust and sophisticated to deal with these issues. That's become big business for network equipment vendors, but it could have been designed up front and much cheaper had they thought about it in the early days."

dan cornell
Credit: Shutterstock
Dan Cornell, The Denim Group

"If the C language had been designed with safe string and array handling constructs, then entire classes of vulnerabilities such as buffer overflows would never have surfaced. This is probably the one inflection point where one different decision could have saved everyone a whole lot of trouble later on because buffer overflows have been and continue to be responsible for the nastiest security bugs in software.

"The measure that would have helped the Web in particular the most would be to have designed the underlying frameworks and protocols to separate code from data. If done properly this would eliminate entire classes of vulnerabilities that have plagued the web like SQL injection and cross-site scripting.

"If languages and frameworks would have been designed with some anticipation of potential security issues, it would be a lot harder for programmers to make mistakes that resulted in security vulnerabilities. These measures, alone, wouldn't ensure 'secure' systems, but they would go a long way toward addressing the 'low hanging fruit' that attackers have taken the most advantage of.

"It also wouldn't hurt if every computer book ever published – and, later, every programming blog article ever posted – went through a security review process so the 'sample code' displayed in these texts as illustrations was free of vulnerabilities.

"Every programmer since the dawn of time has started out building systems by copying examples from books – and now from the Web – and if these cut-and-paste operations didn't propagate junk code the world would be a way better place."

joshua cannel
Credit: Shutterstock
Joshua Cannell, Malwarebytes Labs

"If I had the opportunity to go back and time and speak with those involved with creating the computer networks that eventually made the Internet, the main thing I would want to emphasize is how big this undertaking was going to become.

"I don't think anybody could have expected the Internet, which started as a research project backed by the U.S. government, would later be sold as a service that today has been used by much of the world's population.

"I'd tell developers how much personal information would eventually be stored digitally and available in online servers, and how they need to work to protect it. I'd also emphasize the need for strong forms of authentication between clients and servers -- something that is better than the password to safeguard information against prying eyes.

"I would bring attention to the need for secure, quality-controlled protocols that are heavily tested to avoid security nightmares like Heartbleed. I'd also tell them about how the Internet would play a key role in the spread of computer viruses and malware, allowing a hacker in Moscow to infect a grandma's computer in Philadelphia."

lance cotrell
Credit: Shutterstock
Lance Cottrell, Ntrepid Corp.

"Ironically, one of the biggest problems for the design of the Internet was the almost universally trusting and trustworthy users. Most of the users were academics, and there was little value at stake. Cryptography, authentication, and anonymity should have been built into the low level protocols of the Internet.

"Early on, people tried to secure systems by putting up firewalls at the edge of networks and fixing software bugs. Unfortunately the total software codebase grows introducing new bugs much faster than vulnerabilities are fixed. What they needed was an approach of defense in depth and of quickly detecting and mitigating attacks. We are only now finally seeing concepts of robust isolation of vulnerable components being put into practice.

"There should have been robust systems for authenticated real name communications, reliable pseudonymous identities, and fully and overtly anonymous communications. Instead we have both weak identity and weak privacy."

gary mcgraw
Credit: Shutterstock
Gary McGraw, Cigital, Inc.

"The challenge is, whenever you're building a new platform that you think is going to be pervasive, is to get involved with security early. We have some issues with mobile technology right now, and it's not like we haven't seen this before.

"We've seen this before, and we don't seem to learn the number one lesson with security engineering, which is start at the very beginning with thinking about security.

"Open source has built a lot of really cool stuff -- but it's also built a lot of stuff that's not really secure at all. The notion that open source is secure because a lot of people are looking at it and surely they would spot all the bugs has turned out to be incorrect over the years. There's a basic economic problem in play there -- security is a discipline that is in very high demand.

"The people who do security are compensated very well for their expertise. And when you're doing hardcore security engineering for major multinational banks, it's hard to go home and want to do the same thing again for free for an open source project. We don't have enough software security people today to do all the work we need to do in the commercial worlds."

pam dingle
Credit: Shutterstock
Pam Dingle, Ping Identity

"My advice would be simple -- I would beg those early developers to be more discerning in their trust. Our history is that of 'implicit' rather than 'explicit' security. In the early days, machines accepted punch cards with the implicit assumption that only authorized users would be granted physical access to them.

:Later, on a PC, the implicit assumption was that if you were sitting in front of the keyboard, you must be the owner and therefore earned access to everything within. Even today, we implement authentication and authorization systems as standalone systems first, rather than as the connected systems we know they will be.

"I would also go back with some stern words for the US government, who stalled an applied use of cryptography. NSA prevented strong encryption from being used globally, at the very time when many of the services and protocols that ended up becoming critical internet infrastructure could have been architected to more secure standards.

"They made a terrible assumption that accountability for use of encryption should be enforced at the political level rather than built into the technological fabric, and that legacy -- and attitude -- still haunts us."

greg martin
Credit: Shutterstock
Greg Martin, ThreatStream

"If I could re-architect the internet from the ground up, I would introduce built-in identity and authentication controls that work seamlessly. Passwords have shown over time they are little more than a nuisance and do little to protect you from a determined hacker.

"A fully-baked Internet with built-in access control can not only prevent receiving malware-laden emails from random or spoofed senders, but it can go a long way towards resolving the weaknesses around password-based systems, which tend to be the weakest link in computer network security."

rich campagna
Credit: Shutterstock
Rich Campagna, Bitglass, Inc.

“The ability to secure data has, throughout time, been predicated on the ability to control infrastructure - networks, devices, and applications. In today's world of cloud and mobile, the custodian of the data no longer has control over the infrastructure, requiring a complete re-thinking of security.

"Had the Internet been designed to secure the data itself versus the underlying infrastructure on which it resides, security would be on much stronger footing today.”

rob kraus
Credit: Shutterstock
Rob Kraus, Solutionary, Inc.

"I believe one of the key focus points should have been identification of the requirement to ensure security testing is ingrained in the development of protocols. Many of the vulnerabilities today are the result of protocol specific flaws and could have been prevented altogether if proper focus was given during development of some of the foundational components of the internet that we still use today.

"A simple example, if enough thought was put into the vulnerabilities associated with things like the use of clear text protocols, we probably could have avoided using them all together and reducing the likelihood of compromise of many systems and networks.

"Possibly looking at a host reputation index that evaluated the credibility of systems as they interact with each other via various protocols and services. Creating and maintaining a web of trust that can not be spoofed or manipulated can prevent many of the security issues we experience today.

"Accounting for the possibility that use of the Internet could be used for cyberwar, additional controls should have been developed to ensure mechanisms are in place to reduce or prevent impact from related activities.

"However, despite all the things we could have changed, today's malicious actors will always find a new flaw to leverage, and ultimately have security professionals on the run looking to address a new breed of flaws. This is why we must always be vigilant in our application of security and be ready for the next great flaw. Nothing is perfect."