- It's All About the Software
- Hackers, Crackers, and Attackers
- Dealing with Widespread Security Failures
- Technical Trends Affecting Software Security
- The 'ilities
- Penetrate and Patch Is Bad
- On Art and Engineering
- Security Goals
- Know Your Enemy: Common Software Security Pitfalls
- Software Project Goals
- Conclusion
This chapter is from the book
This chapter is from the book
This chapter is from the book
Penetrate and Patch Is Bad
Many well-known software vendors don't yet understand that security is not an add-on feature. They continue to design and create products at alarming rates, with little attention paid to security. They start to worry about security only after their product has been publicly (and often spectacularly) broken by someone. Then they rush out a patch instead of coming to the realization that designing security in from the start may be a better idea. This sort of approach won't do in e-commerce or other business-critical applications.
Our goal is to minimize the unfortunately pervasive "penetrate-and-patch" approach to security, and to avoid the problem of desperately trying to come up with a fix to a problem that is being actively exploited by attackers. In simple economic terms, finding and removing bugs in a software system before its release is orders of magnitude cheaper and more effective than trying to fix systems after release [Brooks, 1995].
There are many problems to the penetrate-and-patch approach to security. Among them are the following:
Developers can only patch problems which they know about. Attackers may find problems that they never report to developers.
Patches are rushed out as a result of market pressures on vendors, and often introduce new problems of their own to a system.
Patches often only fix the symptom of a problem, and do nothing to address the underlying cause.
Patches often go unapplied, because system administrators tend to be overworked and often do not wish to make changes to a system that "works." As we discussed earlier, system administrators are generally not security professionals.
Designing a system for security, carefully implementing the system, and testing the system extensively before release, presents a much better alternative. We discuss design for security extensively in Chapter 2.
The fact that the existing penetrate-and-patch system is so poorly implemented is yet another reason why the approach needs to be changed. In an IEEE Computer article from December 2000 entitled "Windows of Vulnerability: A Case Study Analysis," Bill Arbaugh, Bill Fithen, and John McHugh discuss a life cycle model for system vulnerabilities that emphasizes how big the problem is [Arbaugh, 2000]. Data from their study show that intrusions increase once a vulnerability is discovered, the rate continues to increase until the vendor releases a patch, but exploits continue to occur even after the patch is issued (sometimes years after). Figure 1–4 is based on their data. It takes a long time before most people upgrade to patched versions, because most people upgrade for newer functionality, the hope of more robust software, or better performance; not because they know of a real vulnerability.
){kind=link}
Figure 1–4 Average number of intrusions for a security bug over time.