How to make Agile and Security Work together

 Since every Agile project is different, you could face one or all of these issues at once. Taking the above points into consideration, they may (and very often simply do) lead to a security cataclysm. The definition of the security cataclysm is very wide – from a security breach, through revoking the certification for the whole company (i.e., PCI-DSS), up to compromising a government agency. The belief that Agile and security cannot work together is so strong that it’s hard to find security experts who are willing to take the challenge and make it happen. Fortunately, there are a few things that we can do and may change that perception.

1. The first measure is to assign a security consultant to all agile squads. Let him/her attend all the stand ups, planning & grooming session, retrospection meetings, and be responsible for security. This should allow him or her to address any security or compliance issues before they are implemented, in other words this is a preventive activity. The maximum successful ratio is one consultant per four agile squads.

2. But that is not enough. Security also has to work closely with the scrum master and together enforce design works – addressed as product backlog item (PBI’s). This second measure will allow the project to perform security reviews based on the designs. These early reviews will lower the cost of any required penetration testing activities later prior the “go live” event. You will need to assign a security assessment subtask to each PBI to perform a security review. By doing this, you should minimize the mitigation costs, and address immediately security & compliance requirements. Another benefit from having a design is higher accuracy and better results from penetration testing. After 2 or 3 months, you should see the first results. Penetration testing should identify less vulnerabilities, less compliance failures to national or industry standards and the security posture should grow within your environment.

Let's say that with the above measures security can be agile. But you will say - it is expensive. Is it? Maybe. There is always a cost attached to improving security. But you can lower the costs by for example creating additional features i.e. a checkbox for penetration testing in JIRA. This will enable the team to coordinate release plan with penetration testing schedule, resulting in decreased number of engagements with a security company. You may encourage squad members to learn practices from the security consultant and introduce cross-quad security assessments. The cross-squad security assessment will also ensure the segregation of duties principle.

However, despite all propositions above, there is still one crucial thing missing. In this approach the security consultant doesn’t have a holistic view of the products and/or environment. This is key for security to be able to assess and provide valuable input to the project. Since that is not available in agile projects, the security consultant starts her/his engagement with a gap analysis against the desired security standard. The desired state and input from some architects is all (s)he needs. Reassessing the gap from time to time (i.e., every 6 months) is recommended here as projects requirements and the desired state change frequently in agile.

The proposed solutions above are not based on the laws of physics, but should bring security and the agile dogma closer to each other. If you have succeeded in bringing those two enemies together by other means please share with us and the world your revelations.