Applications are the Crash Test Dummies of Security

Once upon a time driving a car was substantially more dangerous than it is now. Manufacturers were not held liable for accidents caused by their processes. Then everything changed.

Now car manufacturers build safety into their car design right from the start. Software developers have also begun to try and build more secure applications. The problem is, the industry today is stuck at crash testing. Static analysis and runtime testing seems to be where the industry has settled in terms of application security innovation. We use time-boxed assessments that are generally inefficient at finding domain specific vulnerabilities, and we fix the vulnerabilities as soon as possible. Sometimes, those vulnerabilities get fixed before we deploy to production — sometimes they don’t and we cross our fingers in desperation that they won’t get found until the next release.

This is not good enough. Our applications should not be crash test dummies.

Most experienced application security practitioners will tell you that the vast majority of application vulnerabilities are actually preventable using readily available information such as the OWASP guide. Moreover, many of these vulnerabilities are domain-specific and may never be found by purely automated means. We can do better.

Developer education is a great start, but even five days of training may not cover the depth and breadth that developers need to know. Moreover, that security knowledge will fade over time unless developers are reminded on a regular basis.

There’s a gap today in requirements. We can quite easily build security into in-house and off-shore developed applications by integrating commonly known requirements. For example, we can require that developers not maintain integral state data on the client to defend against parameter manipulation. We can require that session ids are always sent over SSL. We can both require and check for these things before an app is deployed, so that the only thing left for crash testing are mistakes that slipped through the cracks, complex domain specific security flaws, and novel / unique security issues that haven’t been defined yet.

We as an industry have spoken at great lengths about security in the SDLC but we’ve only paid marginal attention to secure requirements. It’s time to move on from crash testing.

Previous Article
JSF Security Presentation
JSF Security Presentation

Recently, my colleague Rohit Sethi and I presented JSF Security at Source Conference in Seattle. Among othe...

Next Article
Viruses and Malware
Viruses and Malware

Our video series continues with the second video in our Safe Online Banking series about Viruses and Malwar...

×

Schedule a live demo

First Name
Last Name
Company Name
!
Thank you!
Error - something went wrong!