Built in or bolted on? When have you ever seen “bolted on” as the first choice of anyone in just about any imaginable scenario? Yet for software security, “bolted on” is certainly the norm.
Every day, applications are created or revised with inherent vulnerabilities that leave the software open to attack. These are not exotic, complex, ingeniously crafted vulnerabilities – they are well-known, garden variety bugs. The first four security risks cited in the Open Web Application Security Project (OWASP) Top 10 List were unchanged between 2010 and 2013, and would likely be unchanged if it were released today.
Reasons for this abound, but they boil down to one driver: developers are not trained to write secure code, nor are they incentivized to write secure code. Security of the code is the responsibility of the IT security team, which tests the applications and sends findings back to the developers. Of course, while the IT security team is running the tests, the developers are onto the next thing, whether it be the next release or an entirely new task. That is because developers are incentivized to create code to meet production deadlines without obvious flaws.
But the problem cannot be laid at the feet of the developers. Building security in takes a commitment by the entire organization that starts well before the developers are involved. It involves an investment in people through training and equipping them with the proper tools. It involves a commitment of resources to build and promote a Software Security Group. It involves a working relationship between developers and IT Security. You will hear vendors in the market talking about “moving left” to describe the concept of pushing software security closer to the developer. While this has a trendy ring, the term is unfortunate on several levels. First, this puts a very linear context to what is quickly evolving as a non-linear process with agile development and continuous integration. Second, it demonstrates a poor understanding of what “left” really is.
In Dr. Gary McGraw’s watershed book, Software Security, he notes that 50 percent of security problems can be found in flaws in the design and architecture. There are organizations that have eliminated cross-site scripting, a vulnerability always at the top of the OWASP list, completely from their software through secure design, architecture risk analysis and threat modeling. Threat modeling analyzes your architecture and design to expose risk before the coding begins.
Think about that last statement in the context of “moving left” vendor speak. As stated, this term is used to describe moving closer to the development environment, often weakly defined as moving the button that starts an application security test (AST) from IT Security to the developer’s environment. But if 50 percent of the problem is found before coding, they need to move further left.A lot further left.
To build security in, you have to embrace the 50 percent reality and really start in the beginning.
Now to the developers. I have a degree in computer science and started my career as a developer. While it has been some time since my developer days, I can clearly remember that I never stopped for one moment to consider security. I was not trained to, was not expected to, and had no accountability to consider security. Not much has changed. So moving the test button from the desk of the IT Security team and putting it on the desk of the developer does nothing material to address the challenge.
‘Building Security In’ means that security must be built into the developer culture. Developers should understand that security is now part of their job. This is accomplished by building security into their incentives, providing them the training they require, and showing them that security is a valued skill to the organization. There should be a well-defined software security group with equally well-defined policies and tools to measure efficacy.
A common pushback from developers is that security can decrease productivity. There are tools that will in fact do the exact opposite, demonstrating an increase in productivity by as much as 15 percent. These tools live in the developer’s environment and scan code as it is being created. When a potential vulnerability is identified, the developer receives information about the vulnerability along with guidance on how to fix the vulnerability on the spot. Many of these tools allow for organization-specific rules and the ability to link to educational material.
The result is highly beneficial to all concerned. Vulnerabilities are eliminated at the source rather than through the longer “find and fix” cycles of the scans run by IT security. The developer gets immediate, contextual help that educates them such that they will begin to code mindful of not creating vulnerabilities. As I like to say, thanks to the repeated correction of Spell Check in Word, even I now spell “separate” properly. All of this translates to code with less risk, created at higher rates of productivity.
So what about application security testing, which has become the focus for many in regard to software security? If you build security in, application security testing becomes less the focus and more a tool at the end of the development cycle before software is implemented. Mature organizations stay out of the Static versus Dynamic debate, realizing that these tests find different vulnerabilities and are therefore both highly useful. They also know that business logic testing or manual ethical hacking are important tools. If we build security in, IT security should have the resources to run these tests to reduce risk as much as possible.
The debate about whether to secure your software is over. How you plan on getting it done is now the question, and building security in has clear, substantial benefits over bolting security on. Organizations now have access to any number of tools, such as maturity models and software security initiatives to provide an assessment of current state and a starting point from which to advance. The most important component is not tools, tests, or templates. It is the commitment of the organization to change the culture and ‘Build Security In’.
