How to make Agile and Security Work together

If you ask any random chosen person from the security industry, you will very likely hear, “Agile and security don’t work together”. 

But we think that Agile and Security can work together. Let us discuss how we can make it work together.

Constant pressure from executives to deliver results faster at lower costs has made Agile very popular in recent years. Even the Australian Prime Minister recommended adopting Agile methodologies for government projects. But is Agile really so good? Or maybe there's a hidden catch?

The answer depends on who is asking those questions. 

Here is why:

• Lack of Design 

• Lack of Security Architecture

• Constant and Frequent Changes

• Security is Considered & Implemented as the Last Thing

• No Security Owners within Agile Squads

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 broad, ranging from a security breach to revoking the company's certification (e.g., PCI-DSS) 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 willing to take on 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 sessions, 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 work, addressed as product backlog items (PBIs). 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 to 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 of having a design is higher accuracy and better penetration testing results. After 2 or 3 months, you should see the first results. Penetration testing should identify fewer vulnerabilities and fewer compliance failures to national or industry standards, and the security posture should improve 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 costs by, for example, adding additional features, such as a checkbox for penetration testing in JIRA. This will enable the team to coordinate the release plan with the penetration testing schedule, resulting in fewer 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 the propositions above, one crucial thing is still 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 project requirements and the desired state change frequently in agile.

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

If you want to know more about how we have done this with our customers and saved them effort, book a free consultation here.