Part 3: Patch and Pray
(see “Mom’s Warning” and “The Defender’s Dilemma” for parts 1 and 2)
By now we know that though in the broadest definition security issues can be defined as “quality issues”, many issues that would be recognized as a quality problem simply cannot be leveraged by an attacker for gain and many security vulnerabilities would never show up on a defect list were the attacker not present to manifest the undesireable result. We also know that security and quality are both emergent properties of a system, but that quality is usually much more self evident, particularly if you are not an expert adversary (in our case a hacker). We also recognize that there are dedicated “security features” that can complicate the assessment of security by minimizing the more subtle emergent property. Finally, we also realize that a system can be mostly “high quality” and still rank high for quality, but we can never say a system is “secure” if we can show any major vulnerability that is not adequately defended for the risk it exposes. I would call this pretty far from the exact same thing.
So what do these differences mean to those of us building software? It means that while we continue to strive to improve quality incrementally, we have to learn how to get it 100% right from a security perspective and this is a radical departure from the current stand the community takes on quality.
This may provide a new perspective on the whole patch and pray phenomenon present today. Software companies with an engrained culture and processes to get it “mostly right” ship code with security vulnerabilities (often unwittingly because they did not adequately inspect the emergent property or were lulled into a false sense of security due to some high profile security feature).
Then an adversary finds and exploits the vulnerability. For commercial software companies, these are often researchers who do not care if the software is mostly correct, all they need to find is one hole and they publish a high profile report. That gets reported in the news, the software company rushes to fix that problem and rapidly ships out another patch, and so on, and so on. In the end the customers are frustrated about constantly being rolled between the rock and hard place of either patching their production systems or leaving them vulnerable to what is by then a widely known security bug.
What is even worse is the fact that the overwhelming amount of all hacking activity is not performed by researchers seeking fame, but rather by malicious individuals that want to harm systems and steal data for ego, profit, or malice and most of their work goes un-reported and all too often undetected. If your personal information was stolen from a company with which you do business, how would you even know if it were based on a flaw in a piece of code that was not reported by the hacker after they lifted the data from that company’s systems. Not afraid of your credit card being stolen? How about your competitor knowing precisely how many units you will be ordering from a supplier next quarter or knowing the names and addresses of all your customers. (The hacker doesn’t even have to breach your company’s system, compromising a shipping provider gets to your company’s secrets, too...)
(to be continued)
Comments (1)
I think there is a fatal flaw in this essay, which is otherwise fine: Security is not an absolute, and systems can't be described as being "secure."
A sort of proof of this is: if you call a system secure from some threats called "outside threats" then we only need to create an inside threat, and the security is breached. See Pareto-secure for more musings on that.
We don't need to get it right every time. Security is practiced proportional to risk, and your examples show that. E.g., open 2nd floor windows is security proportional to risk. If you call that "not secure" are you saying that the open windows on the 100th floor is also "not secure" ?
The flaw lies in the word "secure" which is a trap; security is not absolute, yet the word is too often used in an absolute sense.
Posted by Iang (Pareto-secure) | October 31, 2006 6:49 AM
Posted on October 31, 2006 06:49