Here is the second of a three part series of thoughts on implementing an AppSec program at an organization. For Part 1 click here: Implementing Application Security Part 1.
Step Three: Process
Build security requirements alongside functional requirements in the business requirements.
“Needs to be viewable in three languages”
“Must allow users to set their own color theme”
Include security requirements like:
“Passwords must be changed every 90 days”
“Only authorized personnel may view data X,Y,Z.”
By including these types of security requirements from the very beginning of the process, the developers know what’s expected of them and can be game-planning how to deal with them all along.
Embed security checkpoints into the development cycle. After creating security requirements, you don’t want to just assume they’ll be successfully implemented and wait for QA to tell you at the end that the application is not meeting the security requirements. By including security checkpoints in the development cycle, developers will keep these requirements in mind and increase the likelihood that your security is integrated and successful.
Determine metrics for success in secure development. Whether it is bugs per 1000 lines of code, percentage of security requirements met, or another metric that makes more sense in your environment, find a measurable way to report on the effectiveness of secure coding guidelines at your organization.
Implement performance objectives around secure coding. These objectives should be explicitly outlined in the employee’s goals. Give ongoing feedback on the developer’s success during the year. Don’t surprise him with either success or failure. Seeing these metrics and goals on a regular basis will keep application security top of mind.
Provide rewards. Research shows that in order for negative consequences to impact behavior they have to be applied at a much higher rate than positive consequences. So, rather than punishing those who do not follow security guidelines, give perks to those who are successful. A few free iPads will both get a whole development team on-board with security, and it will make the InfoSec guys look more like the good guy instead of the bully with a big stick.
Step Four: Testing
Get security involved at the very first architecture meetings. Talk about how the types of architecture you are using for the project will interact with one another. Figure out what unique vulnerabilities your product is going to have.
Work on threat modeling with not only the application architects and developers, but get the business owners involved as well. They know better than anyone else what the system is supposed to do and what constitutes an abuse case. While your developers might be able to prevent code flaws like XSS and SQL injections, they cannot help with all the potential logic flaws in a program. If the business doesn’t help think of the threats, even the best developers can’t make secure code.
Encourage developers to make unit testing for their code. Unit tests are not the end-all be-all, but in some cases they can help identify exactly when and where code is broken. By continuously running unit tests on their code, developers will be more aware of the impact and breadth of their changes.
Train up your QA team. They need just as much security training as your developers. They must know how to recognize potential security issues and know how to exploit them if they exist. Find automated tools for QA (you can start with something as simple as Nessus), and teach them how to use the tools. From there you can start offering them training on manual and more complex tools for testing. A well trained QA team should be the first (and only!) people to find any security issues that make it through development. A combination of scanning tools, penetration testing tools, and manual testing can help point the development team in the right direction before a vulnerability is exploited and splashed all over the internet.
For Part Three click here: Part 3
Connect with Robb on Google+