Application Security Street Fighting

Hi, this is Johannes Ullrich from SANS.

As CTO of the SANS Internet Storm Center , I lead the development of complex and exposed applications. Recently, SANS became a member of the SDL Pro Network. I am happy that I will be able to teach the SDL curriculum in San Diego September 15th

As a developer, you are faced with an almost impossible task. Even small projects process hundreds of pieces of input data, provide access control to multiple users and interact with multiple systems like databases and browsers. If you make one mistake, one single SQL injection flaw, one function with insufficient access control, you lose. On the other hand, an attacker only has to find one single flaw in order to breach the application.

How do you “win” given these unfavorable odds? One mistake made by developers is to worry too much about individual lines of code forgetting about the big picture. As part of teaching developers about secure coding and defending web applications, I have started to adopt a philosophy I describe as “application security street fighting”. This philosophy focuses on easy and repeatable coding techniques. These techniques do not require developers to become security experts. Instead the approach focuses on using the right tools and principles to guide developers to create secure applications that can be efficiently implemented and maintained.

1 – Simple repeatable coding techniques

One aspect of street fighting, as compared to martial arts practiced in dojos and exhibited in competition is the fact that complex techniques don’t work. A quick kick to the groin usually beats the complicated judo throw. For a developer, this means that standard problems have to be solved in simple, repeatable ways. For example, the ever-present issue of SQL injection is easily addressed. By writing a simple library to enforce the use of prepared statements, the need to implement and secure SQL statements one at a time will diminish.

Another example is user input validation. We typically teach developers to write two lines of code. One line is to retrieve the data from the user, and another line to validate that the data is in the expected format. In my opinion, this is one line of code too much. Instead, write a library once that will retrieve the data and validate it. Going forward, the developer will now only call one function, which will retrieve and validate the data. To illustrate, a little bit of pseudo code:

First the traditional way:


If ( ! is_email(Userdata) {



Next the better version:


2 – Threat Focused Coding

Once we get past simple issues like SQL injection and input validation, our developer is able to focus on more challenging security problems such as: How am I going to accurately describe the business logic?; or Which techniques could an attacker use to bypass access control restrictions? The developer’s focus will shift from individual lines of code to the larger threat. Threat modeling, an important part of the SDL, will now become much more meaningful to the developer. To apply a street fighting metaphor: Don’t look at your gun, look at your target. You need to know what is happening on a macro level and not get lost focusing on details.

3 – Training

Even simple techniques will not work if they haven’t been taught and practiced properly. There is a point for “dojo” style training in which you are presented with a set scenario and a safe environment in which to practice. This training needs to be applicable and based on real life situations in order to be effective. One thing I liked about the SDL curriculum developed by Microsoft is that it comes from a company that is able to apply these techniques in its own products. Software security training should not just come from security people, but be strongly influenced by developers. Aside from classroom training, there are plenty of other opportunities to learn and practice in your day-to-day job. It is also important to distinguish between training and practice. Training focuses on learning new skills, usually from an outsider. Practice on the other hand is all about applying what you learned and repeating it. Practice can benefit from outside feedback, but it can also be done on your own. Classroom training should illustrate how you are able to practice what you learned once you get back home. At SANS, one of our long-standing promises has been that what you learn in class, you will be able to apply the day you come home. If it would be any other way, we would only teach skills which you will never use and eventually forget.

4 – Conclusion

The SDL starts with training. Training your developers to reuse code and, to use simple and repeatable techniques to code securely will pay off later during implementation. Code reviews will be easier and faster if developers adhere to these guidelines. Even your response plan can harness the same principles by automating the detection and response to common attacks.

As I’ve discussed here, Application Security requires a combination of knowledge, basic skills and practice so that defending applications through secure coding is done instinctively. The MS SDL process is a great toolkit and leverages the hard lessons learned over the years in security. If you’d like to learn the basics in a one day class, I’ll be teaching the MS SDL in San Diego on September 15th. Check it out and register at