Why it's time for a new approach to Agile security [Q&A]

Security is often something that gets left until late in the development cycle and as Agile development takes off, security can be an inhibiting factor.

Since many security breaches now target the endpoint, there's more emphasis on building secure software which means it's something that needs to be integrated into the development process. Fixing security flaws late in the day can prove costly and time consuming.

Software security firm Cigital has recently released its latest Agile Security Manifesto offering principles for building security into the development process. We spoke to Meera Subbarao, director of secure development practice and a principal consultant from the company to find out more.

BN: Why is there tension between development and security?

MS: I worked as a software developer for decades before switching sides towards application security. Having done software development and now being on the other side of the spectrum, I am in a better position to understand both sides. Software developers and Application Security (AS) teams are always at loggerheads with each other. One of the main reasons for this is both teams have different priorities, different goals, and different incentive plans. Developers are incentivized based on how much code or functionality they implement, and AS teams are incentivized based on how many security vulnerabilities they are able to find.

An organization can bridge the gap by training developers in security and AS teams in application development, this way developers know about the security issues being identified by AS teams, and the AS team knows how to help/coach developers fix these identified vulnerabilities.

BN: How early in the development cycle should security issues be identified?

MS: Software security, just like quality, is not some 'fairy dust' that we can sprinkle on the application after it is ready. We need to design an application with security in mind, just as you design an application thinking about its performance characteristics and usability from the first lines of code. To create an attack-resistant application, you should start thinking about security even before you start writing code.

The touchpoints shown in the diagram above are artifact-centric, meaning they are designed to operate on documents, diagrams, code, etc. instead of relying on process elements. This makes security analysis a fairly process-agnostic approach that can be used regardless of the development process you follow.

Touchpoints are a mix of destructive and constructive activities. Destructive activities are about attacks, exploits, and breaking software. Constructive activities are about design, defence, and functionality. Both these activities are necessary.

The diagram shows how software practitioners can apply these activities to the various software artifacts produced during software development. This means understanding how to work security engineering into requirements, architecture, design, coding, testing, validation, measurement, and maintenance. These touchpoints identify specific activities companies can execute to improve the security and quality of the applications they deploy, regardless of the SDLC type employed by the organisation.

Activities can start with early-lifecycle elements such as requirements followed by identifying security requirements and abuse cases to define what 'secure' means for your system and to specifically consider how the software will be attacked.

Risk Analysis can be used to examine the architecture and design of your system to determine potential avenues of attack, which might present security risks.

Test Plans can be augmented with a risk-based approach to specifically address any of the identified risks. Everyone eventually ends up with executable code, and the touch points apply specific focus to examining that code to make sure it behaves in a secure manner. During testing, the touchpoints help to focus testing results to help develop risk-mediation plans for important defects in the software that present security risk.

Code Review is a necessary practice, but not sufficient for achieving secure software. All software projects produce at least one artifact: source code. At the code level, the focus is on implementation bugs, especially those that static analysis tools that scan source code for common vulnerabilities can discover.

Penetration Testing helps evaluate the final software product to ensure that the operational configuration holds up to standard network attacks that have historically caused problems.

Finally, the security operations touchpoint encourages the use of operational personnel with significant expertise in network security to help evaluate and constantly improve the fielded system.

BN: Are developers failing to take advantage of existing security features?

MS: Definitely. A couple of years ago, most security features needed to be turned on. From the past few years, the trend has changed, and security features are turned on by default. It is important for developers to understand the new features added to latest releases of frameworks and libraries, and use them appropriately.

BN: How does the Agile Manifesto help to address this?

MS: Agile Manifesto helps address the inefficiencies plaguing application security. These four principles are meant to guide and inspire Developers and AS teams alike to build secure software in an agile way:

• Rely on developers and testers more than security specialists
• Secure while we work more than after we’re done
• Implement features securely more than adding on security features
• Mitigate risks more than fix bugs

BN: What is the Building Security In Maturity Model (BSIMM) and how does it help?

MS: BSIMM (pronounced 'bee simm') is a study of real-world software security initiatives organised so that you can determine where you stand with your software security initiative and how to evolve your efforts over time.

BSIMM results provide a way to assess the current state of your software security initiative, prioritize change, and determine how and where to apply resources for immediate improvement.

The Building Security In Maturity Model (BSIMM) allows you to:

• Start a software security initiative using real data
• Measure your software security initiative relative to other firms in your space
• Set a benchmark and track initiative growth over time
• Interact with professionals facing common issues
• Evolve your initiative using lessons learned from mature initiatives.

Photo Credit:  kentoh/Shutterstock