Dr. Dobb's Journal April 2004
In the last year, your development team has coded hundreds of thousands of lines of new code. You've modified hundreds of thousands of lines of existing code. You passed the milestones of code complete and several release candidates. You've held reviews, performed testing, and computed every metric that you've found in the literature and a few more that you made up yourself (just because they seem to make sense in your environment). And, unlike many companies who are less wise, you've performed a security audit and, perhaps, even hired outside experts to give security a last minute tweak before release.
Less than a week after release, you are looking at your first security bulletin. Some lone hacker sent a bug report against your application to the press. Now, your customers know, your competitors know and your upper management knows. Likely, it is not going to be the only such bulletin you have to deal with over the coming months.
You failed. And now you must figure out what you are going to do about it.
Before we talk about what to do about it, let's reflect for a moment on why your company and thousands just like it find themselves awash in security bulletins despite spending substantial time and effort trying to prevent security holes in the first place.
The problem: You don't understand your adversary.
The intruders of the world have a key advantage over professional developers—they have substantial time on their hands. They are not burdened with the chores of day-to-day development in order to ship a product. We are. We must spend our time and effort getting a product out the door. It's simple, we either produce products that people find interesting, useful, and worth the cost, or our business makes no money and we lose our livelihood. The time it takes to do the research, writing and verify the code, paying attention to standards, usability, reliability, interoperability, compatibility, and all the other "ilities" leaves little time for other pursuits.
In contrast, intruders are rarely burdened with such concerns. They spend their substantial free time learning your application's ins-and-outs and applying attack techniques to break your application. Most of the time, they are successful because they are relying on the arcane nature of their craft: They know attacks that you don't. The very closed nature of the hacking community plays into their hands and foils our uninformed attempts at defense.
When we published How to Break Software Security, we went on the inevitable book tour and were shocked at the response to our book in which we detailed attacks and explained them in terms digestible by the masses of software developers and testers who are untrained in security. We were proud of what we considered the first software engineering book on security testing.
Among the positive responses to the book were also responses we did not expect: "How can you get by with publishing this?" we were asked. And "You're setting yourself up to be visited by the NSA!"
Please, we were quick to note, the only people without access to this information are the software developers of the world. The hackers have known this stuff for a long time.
And herein lays the fundamental issue. Security is seen as an arcane discipline and its underlying theory and practice remains an unstudied part of computer science. University classes on computer security are rare. When they are taught, it isn't by experts but instead by professors who are trying to stay a few chapters ahead of their students. It is taught as a network issue; secure the perimeter and your network is safe. Preaching such drivel is worse than preaching nothing at all. Of course, there are exceptions, but we hear from the industry constantly that hiring security-aware graduates is harder than solving the halting problem.
This must stop.
Lesson number one needs to be that security is a software problem, and that as software developers, we can prevent most security breaches by better architecture and more robust design. Lesson number two is that there is a large body of knowledge on the topic of security, only some of which is found in books from legitimate publishers.
To prove or disprove this point, take a poll of your software developers by asking them the following questions and tally the responses. The first three have to do with knowledge of the field:
1. Can you name at least three web sites where security bulletins are published?
2. Can you name three security tools for network penetration?
3. Can you name three tools that help you secure your application?
The next three concern knowledge of a specific type of security vulnerability:
4. Name three places in memory that an exploitable buffer overrun can occur.
5. Name three functions prone to the buffer overflow condition.
6. List three remote entry points to an application to test for the presence of a buffer overrun.
And the final three questions have to do with knowledge of your own application's security pedigree:
7. List the security bulletins that have been posted against your application in the past year.
8. Name the most egregious security bug that your team has shipped. Can you describe its causal fault? Its symptoms?
9. Describe the steps your organization is taking to react to the above.
The first three questions should give you the idea that you have to be immersed in the security literature and constantly thinking about how you can learn from the mistakes of others. This is exactly what hackers do and it's precisely the reason that they beat software developers at security testing. Intruders live to read security bulletins. What better way to understand how to break security than to read about what software development organizations are doing wrong? Not only do the bulletins immediately tell them that there are holes out there, but they likely give hints about how those holes can be exploited and which victims may not close the holes fast enough.
For our own purposes, though, the bulletins give us insight into avoiding the mistakes of others and in developing strategies for the deployment of fixes. In this manner, learning the arts of the adversary can help us defend against the adversary.
The next three questions should give you a wake up call that the body of knowledge on computer security is deep and broad. Many intruders possess this knowledge. Even more alarming is that they have constructed tools that embody the knowledge. This allows the infamous "script kiddies" to do damage without even understanding the issues.
The arts of the adversary include understanding security concepts and building tools that put these concepts into practice. We must do the same by forming study groups in our organization and budgeting time for building or acquiring scanners, analyzers, and test tools. Until our own knowledge and tool arsenal is better than that of our adversary, we will continue to lose this important battle.
The final three questions send the message that the best resource for understanding what we are doing wrong is right under our nose. As hired consultants, we have been shocked to find that we are often more familiar with a company's security (or lack thereof) history than the developers and testers responsible for the product. This simply is not acceptable.
Hackers are watching your security bulletins and actively thinking of how to use that knowledge against your code. Is the bug described in the bulletin applicable to other products in your suite of applications? Have the developers made the same mistakes in other parts of the application? Since the bug obviously avoided detection and was released in the final product, perhaps other bugs also avoided detection and are ripe for exploitation. Intruders understand that developers tend to make the same mistake and that where there is one bug, there are often several.
The cure for this is to increase the visibility of every bug you release to the field. Every manager, developer, tester, and technician should understand the bug, its cause, its symptoms, and its cure. The more we open up and talk about our mistakes, the more we learn about how not to repeat those same mistakes.
The advice we give our clients and colleagues is simple, but effective:
Form a security bug study group. Meet weekly and discuss your own bulletins and the bulletins against your competition. Organize the meeting around questions about the bulletins. Can you figure out the mistake made by the developer of the compromised application? Can you hypothesize what the buggy code looked like? Can you reason through how to fix it? Are any of your company's apps susceptible to such an attack? Would your test team have found such a bug in your own apps? What would the test case have looked like?
Form a security development task force. Allow certain developers to specialize in security. Budget for their training and give them time to read, study and go to conferences. Have these experts available for code reviews and have them give internal training sessions. Make them responsible for disseminating new security information, techniques, and tools to all developers. Repeat this until everyone on the team is an expert in software security.
Form a security testing task force. Testing is different than development and requires unique individuals with a unique focus. Choose your most hacker-prone developers to specialize in testing. Give them time for training and such as above. Build a lab and populate it with hacker tools, testing tools, and networking gadgets. Their charter is to do unto your apps before the hacker does unto you!
Now, back to those questions. What are the answers? We can't answer the last three. Those are for you to ponder inside the walls of your office. We'll answer the first six in next month's installment.
DDJ