Glossary

Agile Security

Ideal application development involves fast builds and effective testing cycles. This is easily facilitated through the employment of agile development methods. However, if you use this development approach there is a potential pitfall – cycles/sprints are extremely short in duration (often 2-4 weeks) and this makes it very hard for developers to commit to security assurance. There are of course other methodologies that can be used to write software that offer a higher level of focus on security assurance, but the problem is that they are slow. This is where agile security comes in – it offers a straightforward platform to support agile development without compromising release cycles.

In agile development, the requirements of a business are stated in the form of stories and occasionally as “epics” which are a group of such stories. These define the user’s expectations in the affirmative; e.g. I want to be able to log on and access my data. They tend not to address the negative cases; e.g. I don’t want my data to be accessible to others.  It is all too easy for security to slip through the cracks in these cases. It is therefore necessary to develop a series of “security stories” or possibly abuse cases (rather than use cases) to support agile security. The process begins with product managers developing an initial security review of the product. They examine functionality, policies, legal, regulatory and contractual requirements, etc.  From this review they develop security stories. These may then be better defined with the development team and prioritized for handling. Then when the development cycle/sprint begins, it is simple for the development team to pick up the security stories as well as the functional stories and begin the process of agile security development.

Prioritization is based around the concept of “security debt”. That means that each security story is assigned a value and the tasks left undone are considered as accumulated debt. The value is normally assigned around the potential return on investment; e.g. which tasks can be handled at the lowest cost during the development cycle compared to their cost to fix following that cycle. This prioritization may also contain a full examination of the system’s nature and the possible lines of attack that have been deemed most likely. These are clearly of a higher priority to fix than threats that only exist in potential previously. Once prioritization of security risks for agile security development has taken place, it’s a simple process to assign the related tasks to the individual team members. This allows each role (for example; testers, developers and architects) to cover areas of their strengths and contribute to the agile security process.

But Agile security goes beyond instilling awareness within the organization. This is where Static Code Analysis Testing (SAST) enters the picture. Source Code Analysis (SCA), a leading SAST methodology, allows for rapid testing of the delta (the changes made since the last test) without re-testing all previous code iterations. Thus it offers an agile approach to security in agile development cycles, where there is minimal disturbance in the development process with almost real-time results for quick mitigation. Security bugs are treated just as QA bugs, something that helps optimize Agile security by automating it.