Four reasons why Traditional Information Security fails in Agile Environments

While agile development is going mainstream, information security is having difficulties to keep pace with such short-term planning perspectives and instant changes in strategies. 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 information security fail with agile, while in future articles we will propose solutions for it and present a model to integrate information security into an agile development process.

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

This has to do with the common way of working within security management. Popular information security frameworks (such as ISO 27001) 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 the top-down projects that follow the waterfall model, with clearly defined transition moments and deliverables. Essentially, information security is often addressed at the start and end of a project.

Agile, however, follows a different model; it 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, and 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, and 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:

Information Security in Agile environments

These assumptions do not hold up in an agile environment:

1. First, 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. Second, 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. Third, 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. Fourth, there is a cultural issue as well. Not all of them, 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. However, it can take up considerable development time and prevent developers from implementing other features and functions.

This article is the first in a series written by the authors to explore the options for embedding information security into an agile development strategy. In the next article, they are going to present solutions and a model for agile security.

PECB

Information security is becoming increasingly important for nowadays organizations in one hand. On the other hand, certifying against it is oriented towards being a mandatory requirement for both the organization and individuals practicing security. Competently, PECB ensures valuable training and certification against ISO 27001 while expanding individuals’ abilities in responding towards various threats and vulnerabilities.

Co-Authored By:

Pascal de Koning, a highly skilled professional on Information Security, Security Architecture, Software Development, PCI DSS, Identity Management, TOGAF, Network Security, Integration, Business Continuity, and IAM. As a Chairman of Security Services Catalogue project supported by OSA and a Chairman of the TOGAF-SABSA integration project at KPN Telecommunications, his expertise becomes of great value to provide.