Creating security program requirements can be a challenging task, especially with application security. In this tip, Kevin Beaver shares several ways to create an effective program.
Security is often about requirements. What is it you're required to do based on business needs, risks and regulations? That's at the heart of it all.
Requirements are about setting expectations. This rings particularly true in terms of application security. Given all the variables involved in application security, there must be a core set of requirements that are met and governed over time.
Specific application security program requirements should establish standards in the following areas:
software development and integrating security controls, such as the OWASP Top 10 and the CWE/SANS TOP 25 Most Dangerous Software Errors, into the development and testing stages of your various applications;
platform specifications and standards that outline what specific application development languages should -- or must -- be used, specific operating systems that the software will run on, and minimum necessary configurations for both internal and cloud-based environments;
visibility and control, namely how various aspects of each application environment can be monitored, how alerts are generated and received, and how the system integrates with incident response efforts; and
security testing, specifically vulnerability scanning and penetration testing using the proper tools and techniques to help uncover software security flaws in web applications, mobile apps and traditional client/server applications.
These application security program requirements must apply across the board, including your internal development, quality assurance and security testing teams; external developers; related vendors; and even business partners and customers that your applications interface with.
Just because standards and requirements have been put in place, that doesn't mean they are fully implementable, especially as it relates to third parties outside of your control.
All of this would exist in an ideal world, but we must contend with reality. Just because standards and requirements have been put in place, that doesn't mean they are fully implementable, especially as it relates to third parties outside of your control. Still, if you are to establish and maintain a resilient application environment, you have to have goals and aim for specific metrics.
Not only will these application security program requirements help you in terms of application security, they will be of value on the reactive side if an impactful security incident or breach occurs. The last thing that you need is for someone else, such as the opposing legal counsel, to demonstrate that you failed to provide due care in terms of application security -- many people have yet to address this. There never seems to be enough time, and usability features tend to take precedence.
Still, you must take the lead and communicate that this aspect of application security needs to be addressed sooner rather than to later. Acknowledging the ailments in your application security program in the short term is half the battle, while reasonably addressing them over the long term is the cure.
Share your thoughts and suggestions with your peers and executive management -- practice what I call relentless incrementalism. This is where you address the important things a little bit at a time, over and over again. Stay proactive in this area of security and you'll soon see positive results. Remain apathetic or reactive and it's simply a matter of time before someone else demonstrates to you and, quite possibly, to the whole world just how many gaps your application security program has. It's all in the requirements.
