Part 1: Mom's Warning
I spend most of my time these days helping software developers understand the security implications of the software they write - and it is frustrating.
Security does not come naturally to software development and most of the people involved. You can simply scan the news headlines for the latest piece of software compromised to figure that out. But I have a great deal of empathy for those developers that I work with today, because the concepts of security applied to software took me a while to understand too - and I have the advantage of including some of world's top security experts in my co-workers and close friends.
Having friends that are experts explain the subtleties to you is a help. But one other thing that helped me understand the depth and complexity of this problem was by first understanding and contrasting it with software quality assurance. Because to many that are just learning about software security, or even to some security experts that don't understand the art of software, it can sure seem like they are "the exact same thing".
When comparing and contrasting software quality and software security, it is first useful to define what each is. A software quality problem can most broadly be defined as the failure of a piece of code to perform to the expectations of its specification which can be implicit (user thinks it should be different) or explicit (code did not answer network connect on a well defined protocol.) With that broad of a definition a "security issue", which we refer to as a "vulnerability". is a subset. A vulnerability is a feature of the code that allows its specified operation to be compromised by an attacker. To the naïve, it would first seem that an attacker would be limited to quality problems and therefore they should be exactly the same things. The truth is that most vulnerabilities are in perfectly fine code from a quality perspective - the code in question would have performed precisely to its specification had there been no adversary present to compromise it.
Security and quality, like safety, are what we call emergent properties. For any complex thing, we usually can't point to one piece and say "look at the quality". A big heavy dead-bolt on the front door may give us a clue that a home is secure, but upon finding all the windows open on the second floor we begin to see why we call it emergent. One area where security and quality begin to diverge considerably is the self evidence that these are emergent properties. This is due to the fact that in all realms we do have security features above and beyond the general property of being secure - remember that deadbolt? For example, if I showed you a word processor and the first menu item, supplacing the usual "file" menu, was a great big blinking "quality", would you assume that the word processor indeed was high quality? Would you be ready to migrate all of your MS Word documents over upon seeing that menu? Chances are you would not.
However, when you log into a "super secure" system over a "secure connection SSL" using three factor authentication the chances are pretty good that you assume (often errantly) that the system is secure. What if the system was an e-commerce site and right after that fancy authentication and over the secure channel it allowed you to make your purchase with someone else's account by simply changing some values in the session cookie hidden in your browser? Would that be secure? In fact, this specific problem has been uncovered in literally thousands of e-commerce sites over the years and still persists in high profile sites today.
So security and quality are both emergent properties of a system, that is, we can't really tell if something is high quality or secure just by looking for the feature that proves it, instead we look everywhere and make an assessment. But we have uncovered two critical differences - security is invisible to most of us (unless we are hackers) and quality - or lack thereof - is most often painfully visible. And security does have features present (login, crypto, etc) that makes the emergent nature less obvious and quite dangerously gives us a false sense of confidence. These are at the heart of why the software development community has a very difficult time recognizing the security problem. There is one more critical difference and it is at the heart of why the software development community will have an even harder time addressing the problem once it is recognized. In quality "a best effort" is good enough, whereas security is absolute.
To be continued...
