Published on
This article was born from an interview on the Application Security Podcast, season 5, episode 19 between Brook Schoenfeld and Chris Romeo / Robert Hurlbut. We began the conversation talking about tips for building an application security program. Here is the list of six items I wrote down, with a bit of color commentary thrown in.
You cannot mandate a program with Executive direction or just buy a tool.
When building a new program, many start here, thinking we’ll just create a policy and then everyone will follow along and do the right thing for security. Unfortunately, an Executive’s direction is not enough to change the security culture. It does not hurt along the way to have executive buy-in, but it won’t kick start the program.
Tools are helpful when people understand how to actually use them. The struggle when building a new program is to start by buying expensive tools, only to find that no one knows how to operate them and derive value from the > USD 100K investment.
Humans + automation = a strong program.
Automation is required to grow to receive the label as a “strong” program. Human beings are at the center of any effort, but we need tools to magnify their efforts. Software development is moving towards more and more automation (build pipeline), and a robust program embraces automation.
Tools are noisy and hard to configure and require tuning.
Tools should never deploy in an out of the box configuration. The key to encouraging developers with tools and automation is to not inundate them with technology that disrupts their normal development flow. Ask the tool vendors what situations allow their solution to excel, and then deploy in such a way so that it’s positive attributes shine.
Sometimes you’ll have to use multiple tools to do one job. That is the current state of where we live now in the application/software security space.
Prepare dev’s to use the tools to scan the code.
Get the tools as close to the developers as possible. For most dev’s, invade their IDE with the front end to your tooling. This engages the developers as they work, and allows them to fix security issues detected by the tools as they develop (in the flow). The classic approach was fixing security issues days or weeks after completing a block of code. Inter IDE based solutions are the best.
Use a team of security testers to take their knowledge and abilities to the next level.
Security test is an important function, and it’s essential to raise the knowledge level of everyone regarding security testing in a DevOps world. There is value, after reaching a certain program maturity, in building a dedicated application security red team to focus on finding the hard issues within your applications.
Culture hacking: integrate with what developers do, instead of asking them to come to us.
Culture hacking — small adjustments to the culture in an attempt to cause positive change. In the security program, meet the developers where they already are, and practice empathy. Think about the natural way to integrate whatever you hope to accomplish within the developer’s world. Just because we’re from security, does not mean we have all the answers.
