In my first entry on Application Security ROI, I promised to delve into three areas of Application Security ROI a little more deeply. In this entry, which will now have to be the second of a trilogy given the title and my propensity to eat six times a day and grow hair on my feet, I will talk about the first, and least intuitive of these – how Application Security can make development projects more predictable and efficient. This predictability, and especially efficiency, is where the return on investment comes from. Without a Secure SDLC, Security becomes a gate throwing up roadblocks that seem incomprehensible and random to project teams, usually at the worst possible time. This seems like a trip through Moria, and often results in a process of recriminations followed by negotiations, with the outcome to nobody’s liking. Since the teams are not in synch on the goals and approach to application security, unpredictability and inefficiency ensues as resources are wasted going back and forth.
On the other hand, if the Two Towers of the application development team and the Security group can work together in a Secure SDLC rather than fighting a war between good and evil (each side believing it’s good), this can be avoided. Working together in a Secure SDLC means taking actions all throughout a project's lifecycle to create and meet common goals. Security can participate in setting Security Requirements and Threat Modeling at the early stages of the process, work with the team on refining them as the project continues, and then act as a consultant or even perform some security validation during the testing phase. Finally, in deployment, Security will have set requirements of the infrastructure for secure deployment of the application without interfering with its functionality. How does this result in ROI? Several ways:
- When each part of the team works from common Security Requirements (and explicit non-requirements), only those elements which are necessary need be built, tested and deployed, saving time and money vs. a broad generalized set of requirements.
- A Threat Model provides detail on the dangers to the application which informs the design, development and testing efforts, resulting in specific, effective mitigations.
- These items not only inform the development, but they clarify requirements for design as well as provide clear guidelines for what must be tested, and what need not be, saving time and money during both these efforts
- Secure code is good code. Many of the requirements for securing code such as not trusting input, and careful memory, pointer, error and integer handling, result in avoiding both security vulnerabilities and functional bugs saving expensive fixing and retesting time during the QA cycle.
You don’t have to take my word for it. This was also found by Forrester in the study I referred to in the first entry in this series. See especially Figure 9, Table 5, and the discussion around them. By the way, this may look like waterfall, but the same can work in Agile processes as well.
Now that you know that applying Application Security processes can save time and money, how do you go about creating your own fellowship between Security and Development? Training will be required so everybody understands the process and principals. Security Innovation can also help with a gap analysis of your process and a detailed roadmap on the steps to take to get to where you need to go, throwing your old inefficiencies into Mount Doom, destroying them forever.
