Last month, I had the opportunity to discuss the expanding threat of mobile IT security with CAST’s audience. The feedback we got was so overwhelming, I wanted to answer the questions we might have missed here on the blog. Lev already answered some of your questions in a previous post, so for my follow-up post, I’ll focus on the risks that often go ignored throughout the software development process.
Gone are the days where "ignorance is bliss" within the application development process -- all individuals and business units up and down the organization's structure are now accountable for security measures and protections. It's top-down enforcement with bottom-up execution and management.
Ignoring a risk corresponds to accepting the risk. This means that if all risk mitigation strategies are not performed, it’s the same as ignoring them. Therefore, the organization is accepting ALL risks -- whether known or unknown.
Unfortunately, ignoring risks continues to be a real and serious issue in software development processes. And the introduction of faster-to-market methodologies is only making this a challenge to address and manage. Think of it another way: ROI is no longer viewed as Return on Investment but as Risk of Incarceration because ignoring risks is no longer an option.
So, the question of how to build security controls into the Agile process is not only an excellent question, but it is the right way of thinking and approaching the ROI Challenge.
Below are processes that can be included in an Agile methodology that will provide executive management the assurance that the application’s risks are known, addressed, and documented -- easing their concerns of ROI:
Items to include in Agile Sprints (Level 1 Maturity)
1. Enforce organizational policies -- policies that are written for both the organization and can be enforced and implemented at the Application Layer (e.g. session management, password, data classification, authentication and authorization, etc.).
2. Secure coding guidelines -- these guidelines establish the required syntax, APIs, and frameworks/libraries to use to meet the requirements in accordance with organizational policies. A security framework is highly recommended to meet this objective.
3. Configure bug tracking to track security issues as defects with a sub-classification as security -- it’s important to treat security issues as software defects instead of placing them in a special category. A sub-classification can be used for metrics purposes, but is not necessary.
4. Verify security evangelists and plan for fixes -- schedule the defects, which include the security issues, in accordance with specific Sprint cycles (i.e. Sprint 3, 7, 10, etc.)
5. Determine more critical security defects and add to plan for fixes -- the defects are determined based on policies and factoring in the most critical assets. The use of the Return on Security Investment (ROSI) formula and others can help drive this decision.
6. Keep an inventory of third party dependencies, checking for patches/updates related to security issues -- not only is this important from a pure inventory perspective, but also from a monitoring perspective to periodically, throughout the Sprint cycles, check for patches/updates to the third party components that address security and critical issues.
7. Create a threat model during Sprints 1, 2, and 3, with a final review two cycles before the final Sprint -- a threat model is an important document and flow that will identify early in the Sprints what the attack vectors and threats are. Since the concept of Agile is to have 70 percent or more of the functionality completed early in the Sprint cycles, this document will prove invaluable to identifying and quickly remediating any potential threats.
8. Add automated security testing in QA -- types of automated testing with a security focus are web application vulnerability assessment (if a web application), fuzzing, and targeted misuse cases based on the threat model (attempting to add malicious or out-of-bounds input to determine how the application reacts to potentially malicious content).
9. Make sure all staff are properly trained -- e.g. secure coding for managers; secure coding for architects; secure coding for developers; and secure coding for testers .
Remember, in today’s “new normal” of IT security, organizations are accountable for both known and unknown risks alike. Moreover, CIOs can’t toss the blame to their teams anymore -- all individuals and business units are accountable for application security. So now you just have to ask yourself one question: Are you measuring your Risk of Incarceration?