A picture says more than a 1000 words:

If you are interested in our model and want to learn more, register for our workshop at Security Academy.

Here: Agile Security Introduction-20170531 you will find the sheets of the presentation Pascal and Arthur did on the Experts Gathering at i-to-i.

We did a short version of our Agile Security workshop and had a lot of positive feedback. You can find more information on our workshop at Security Academy.

Here is the slidedeck for continuous testing in an agile environment, PECB webinar, Oct. 19, 2016

Here is the link to the slidedeck on Agile Security for PECB on Oct 27, 2016.

Agile Security

Matching information security and agile

Four reasons why traditional information security fails in agile environments

While agile development is going mainstream, information security is having difficulties to keep pace. 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. 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, 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.

 

Arthur Donkers, 1Secure (arthur@1secure.nl), Pascal de Koning, i-to-i (p.de.koning@i-to-i.nl).