The 5 places that security testing should happen, but doesn't

The seemingly never-ending spate of hacking attacks is now the unfortunate norm across the web landscape. Among the casualties lay everything from personal data to entire companies who have been mercilessly eradicated in the Darwinian world of web vulnerabilities.

In a previous blog we discussed 5 steps to building a successful application security program, and in an ideal world developers would always write the correct (and secure) code the first time, but, as I think goes for every field, this just isn't realistic. However, let's focus on one important security element -- security testing.

To begin, there are five critical places that security testing should happen, but doesn't:

1. During Development:

The developers are the front line in terms of defending applications against attacks. By instituting secure coding guidelines, common security controls, and internal team code reviews developers can catch as many vulnerabilities as possible before they progress. Developers should peer review “security critical” code, such as authentication, access control, input validation, output encoding, encryption algorithms, hashing, password storage and so forth. Making use of security unit tests serve as a nice reminder for developers to properly implement these security controls, and give developers a heads-up when something breaks.

2. Static Code Analysis:

No matter how much peer review occurs, it's hard to match the speed and completeness of automation. Pretty much everyone agrees these days that automation is a necessary step towards properly securing custom code. By using static code analysis frequently throughout the development process, developers can get a greater assurance that absolutely every possible path has been traced and accounted for.

3. QA Testing:

So now developers have done checks on security critical areas, and static testing was used throughout the development process to catch missing security controls. By the time the application is nearing completion, the QA teams are going to be checking for missing or incorrectly implemented functionality. This is also a good time however to test for common vulnerabilities that are traditionally hard for automated scanners to reliably detect. Direct Object Reference, Cross Site Request Forgery and others are easy for human testers to check, and provide nice low hanging fruit to get out of the way.

4. Manual Code Review:

So although we've now had developers, automated analysis and QA testers banging on our application, high value applications normally warrant security professionals to dig in and test the non-automatable, application specific vulnerabilities. Problems in the business logic are pervasive and can cost organizations big time. Unfortunately, these types of vulnerabilities are unlikely to get caught in all our previous steps.

5.Ongoing Dynamic Analysis:

Ongoing testing is vital. Especially since most organizations are continually deploying new code, and therefore testing must be an ongoing process as well. Framework vulnerabilities, like Ruby on Rails, which has been suffering lately, could only be detected in an enterprise by continuous testing or at least through very careful inventory of all deployed frameworks and libraries.

By ensuring that security testing is actually happening at each phase of development, an organization stands a much greater chance at defending itself against attacks.

From CIO: 8 Free Online Courses to Grow Your Tech Skills
Join the discussion
Be the first to comment on this article. Our Commenting Policies