In his talk during the first day of DevOps Days Amsterdam Frank Breedijk, security officer at Schuberg Philis, talked about the friction points between security and DevOps and how to collaborate to avoid them. Examples include automating security tests and environments, reducing scope of security audits to relevant system components only or allowing security fixes to jump the queue of changes to production.
Frank highlighted the friction between security and the lack of investment in security by development (incentivized to deliver functionality) and also the lack of support from operations who think of security as unnecessary burden on top of their regular work. Finally security people often see DevOps as a risk due to the seemingly lack of separation of responsibilities and increased rate of changes to production. Frank suggested a real DevOps culture should promote collaboration not only between dev and ops but also between both of them and security (thus the S in DevOpS he joked, alluring to other acronyms like Http/HttpS, Imap/ImapS).
Collaboration between all parties can be increased by demystifying security requirements on one hand and increasing visibility on changes to the system on the other, thus reducing fears of security threats. For example, a common misunderstanding regarding PCI DSS and SOX audits is to think the entire system needs to be audited when in fact only some components require approval. On the other hand, the delivery rate of changes to production typically increases significantly with the adoption of DevOps. Rolling back is not an option anymore but fixing forward is enabled by the increase in the ability to deliver high priority security fixes (jumping the queue of changes to production).
High delivery rates are not necessarily a problem for security according to Frank. When visible to everyone, smaller changes are easier to analyse and test for security. Plus the increased number of delivery windows allow for faster fixes to security issues in production. Finally, the focus on infrastructure configuration management to manage such dynamic production environments also helps in infrastructure security testing. For example, automatically checking that OS images used for provisioning new machines include all the required security patches. Overall the automation of security environments and tests becomes easier and can then be easily integrated into the delivery pipeline.
Frank also pointed out the difficulties to include security requirements in the mindset of functionality-oriented agile development teams and product owners. Work to meet such requirements needs to be planned in the development iterations and reducing technical debt by fixing security defects for example should be rewarded as much as delivering functionality.
Overall Frank suggests that a true DevOps culture should embrace security teams and align incentives so that everyone works towards delivering functional changes that meet security and operations requirements as well. Security teams should not be seen as bottlenecks for delivering changes but as a sort of immune system, detecting threats and providing the required insights and tools for fixing them.
This talk was live streamed [starting at 2:40:00 on day 1] as well as the rest of the conference. The slides are available as well.
