How can big services still have security breaches?

How can this happen? Because security is hard.

In fact, it’s way harder than you or I can even imagine. And to be clear, I’m not trying to make excuses for AOL or any other service. I just want you to understand that security is really, really hard.

Let me review some of what I’ll call the fundamental principles that are at play in a situation like this.

#1 All software has bugs.

I think this is something that non-programmers have the hardest time with. The thinking is that if we just did it right in the first place, we wouldn’t have all these problems.

Here’s the fact: Even the the very best software you’ve ever used; the most stable; the fastest; the best and most loved software you can think of – still has bugs.

There is simply no such thing as bug-free software – period. Anyone who tells you differently is either lying to themselves or to you. At best, software manufacturers try to insure that the bugs that do remain are of insignificant impact, but there’s simply no way to anticipate and eliminate all bugs. Most – sure. All? Absolutely not.

And that’s primarily due to Principle #2.

#2 Today’s systems are unimaginably complex.

Seriously. Even the people who are supposed to understand them from top to bottom, don’t completely understand them.

Many of the bugs that I referred to in the first principle are not results of explicit programming errors, but rather side effects of errors in the way that these enormously complex systems are built. (Of course, explicit programming errors happen too.)

Remember, systems have to be built in such a way that individuals can build them. That means they’re built in parts; parts that can be understood. And those parts are then put together to form the larger whole. Very often, the problems that result are from simple misunderstandings or erroneous assumptions as these parts are put together.

And remember, we expect these systems never to crash, never to lose any data, and never deny access to those who are authorized; while never allowing access to those who should be denied. All of that while being both lightning fast and easy for just about anyone to use.

Incredible complexity is the result.

#3: You can’t retrofit security.

Systems often try to, but it’s a path fraught with potholes and pitfalls. True, comprehensive security needs to be baked in from day one.

That’s one of the major reasons that Windows 9x software was abandoned in favor of the Windows NT-based systems we use today. Windows 9x was based on MS-DOS, which had zero consideration for security. It just wasn’t part of the concept of that operating system. There were no such things as accounts or permissions. Windows 9x tried to bolt stuff on, but it could not overcome the fundamental assumptions made in its MS-DOS foundations.

Windows NT was a complete rewrite with multi-user account and security control built in from the very beginning. Windows 2000, XP, Vista, 7 and 8 all derive what they are from Windows NT. Yes, Windows has its issues, but what it is and does today simply could not have been built using the old DOS-based roots.

#4: Complexity and evolution are at odds with security.

Systems evolve. Whether or not you want more, the world, the market, the public in general, does. We want more features; we want more power, we want more games, we want more options.

As a result, systems evolve.

Evolution increases complexity. Evolution of an already complex system is even worse.

Evolution means that the security that you had built in may need to handle issues and situations that it was never designed to handle, things that were never even dreamed of, say, a decade ago. So the security measures get tweaked and adjusted, they get modified and evolve themselves with the hope that nothing breaks.

And of course, in addition to all the new things, we want all the things we did a decade ago to keep on working.

#5 You need security experts to do security right.

Security as a concept is hard enough. Security as an implementation is insanely hard because the margin for error is so small. For example, encryption is trivially easy to do wrong, or maybe not wrong so much as not right enough.

Account management is the same way. To this day, there are some services that are making bad decisions like perhaps actually storing passwords (which AOL did not do, by the way), because the coders don’t know any better or are in a hurry, or for some other reason.

This is perhaps one of the larger risks of today’s incubator or entrepreneurial startup models. A small number of people get together and create something because they have expertise in that something. That’s awesome; and they produce an awesome product or service around that thing. But none of them are security experts. They may have some notion of best practices like not storing plain text passwords. So they get the big things right, but it’s the small things that will bite them.

#6: People remain the weakest link.

All of the technology in the world won’t save you from the mistakes of human beings.

If a tech in your data center falls for a really good phishing attempt – and they do exist – then you’ve just bypassed even the best security. Maybe your security expert – an honestly, good, true expert -overlooks a case that can happen only in one in a billion times; and then your company grows to the point where you’re doing a billion transactions a day. Maybe adding a feature to your decades-old system uses an interface in a way that was never envisioned when it was created several years ago and never tested against since.

Maybe you just piss off the system administrator and before he quits, he leaves all of the security information on an anonymous hacker’s website.

Like I said, I’m not saying that any of these are justifications for security breaches but given the enormity, the age and the evolution of so many of these systems over time, it’s really no surprise. Throw in some human frailty along the way, and in a way it’s a surprise that it doesn’t happen more often.

The best systems, in my opinion, don’t make the assumption that we can stop this from happening or that this will never happen. That’s naïve. The best systems have an answer for the question, “What do we do when this happens and how do we reduce the damage if and when it does?” It’s kind of like backing up that way. You can’t say my disk will never fail – or if you did, you’d be wrong and also naïve. What you can say is, “How do I prepare for the day it happens, and how do I reduce the impact if and when it does?”