Agile and Security
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 recommends to use Agile methodology in government projects. But is Agile really so good? Or is there maybe a hidden catch?
- Lack of design
- Lack of security architecture
- Constant and frequent changes
- Security is considered and implemented as a last thing
- No security owners within agile squads
Since every Agile project is different you could face one or all issues at once. Taking into considerations the above points, 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.
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.
But that is not enough. Security has also to work closely with the scrum master and together enforce design works – addressed as 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.
Lets say that with the above measures security can be agile. But 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 at JIRA. This will enable to coordinate release plan with penetration testing schedule, in result decrease number of engagement with a security company. You may encourage squad members to learn practices from the security consultant and introduce cross squad security assessments. The cross- squad security assessment should 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 his with a gap analysis against desired security standard. The desired state and input from some architects is all he needs. Reassessing the gap from time to time (i.e. every 6 months) is recommended here as in agile projects requirements and the desired state are changing frequently.
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..