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 to very popular the last years. Even the Australian Prime Minister recommended to use Agile methodology in government projects. But is Agile really so good? Or maybe there's a hidden catch?
- 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
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.