Matching information security and agile

While agile development is going mainstream, information security is having difficulties to keep up. The result of this struggle is that new systems are insecure, or that they are loaded with point solutions for security.

What is so hard about security in agile environments? In this article we examine what makes infosec fail with agile, in future articles we will propose solutions for that and present a model to integrate information security into an agile development process.

So, what is wrong with classical infosec in relation to agile?

This has to do with the common way of working within security management. Popular information security frameworks (such as ISO27001) use a top down approach: They emphasize that policies, processes and generic technical controls need to be in place to make sure an organization is in control of its information security. Once all of that is in place, projects can start building on this security foundation and use security management services. This works well in top down projects that follow the waterfall model, with clearly defined transition moments and deliverables. Information security is often addressed at the start and end of a project.

Agile however follows a different model, it is uses a risk based approach for developing in an incremental way, using short development cycles called sprints. A sprint is small enough to be manageable and it forces the product owner to set priorities. All new feature requests are collected in the backlog. For each sprint, a selection of requests is made, based on business value, urgency, ease of implementation, customer requirements, etcetera. If a feature or requirement is too complex or will take too long to implement, it may be broken down into smaller bits and implemented in a series of sprints. Test results from previous sprints are fed back into the next sprints to facilitate continuous improvement while performing sprints

So where do things go wrong?

Traditional security assumes that:

  1. the project team translates generic security requirements to appropriate security controls;
  2. The team has time, skills and tools to implement the controls properly;
  3. During the development project, there is sufficient time and money to conduct a security test or tests and process the findings;
  4. Sufficient time is available to address the security risks found during the project and test.

These assumptions do not hold up in an agile environment.

  1. The product owner has other priorities than to translate security requirements to controls. Time is of the essence in an agile approach and most, if not all, resources are dedicated to building the next iteration of building blocks required and creating business value.
  2. The development team may lack the state of mind, expertise and experience to implement security controls. Developers may not be aware of some of the vulnerabilities that could be present in the building blocks and may lack the proper training for developing secure code.
  3. There is no traditional test phase, where the product is frozen, in the project where all functional and non-functional requirements can be tested and issues can be fixed. The system is developed and released in a flow of small, incremental cycles. Each cycle determines what is developed and delivered in the next cycle, and the ‘predictability’ of the project is perhaps two or three cycles down the road. More often than not, different iterations run in parallel and they meet somewhere further down the road. Security testing is limited to the products that are available in the sprint and security management is often not able to adapt to that dynamic.
  4. There is a cultural issue as well. Not all, but most developers do not get warm fuzzy feelings when you mention the term ‘information security’. They know that it creates a lot of overhead when they are required to incorporate security controls. There is no direct benefit (i.e. functionality) in implementing security controls but it can take up considerable development time and it prevents them from implementing other features and functions.

This issue has been discussed previously in our PECB webinars. The full article is available at our site on agile security. In our next article we are going to present solutions and a model for agile security.

 

Bron: Pulse Arthur Donkers