Continuous Security in Continuous Delivery – LondonCD meetup June 2017

This is part 1 of a 4-part series of articles based on discussions at the LondonCD meetup group on 12 June 2017. The other posts are linked at the end of this article.

How do we continuously address security concerns with modern software development? That was one of the questions we discussed and tried to answer at LondonCD meetup group on 12 June 2017. “The yearly PEN test is dead!”, said one person, meaning that reliance on an infrequent, specialist test to address all security problems is simply not good enough any more.

Office Lens 20170612-201113

Key points from the discussion:

Many IT security professionals are (or were) traditionally hostile to approaches like Continuous Delivery, so progress with continuous security has been slow. This hostility has sometimes been justified (sloppy development practices), but we now have a nice toolkit of security approaches that can be used to demonstrate a more mature, holistic attitude.
We now have many workarounds but few really good solutions for continuous security.
There seems to be a lack of Continuous Delivery awareness within the IT Security community. Do we need to do more to explain and evangelise CD more?
One person spoke about infrastructure that needed to be “certified” by a third party organisation before it could be used. This was a major blocker to moving more quickly. Sometimes, organisations needlessly constrain themselves by tortuous or unnecessarily stringent interpretations of security rules, regulations, or guidance.
Instead of a blanket “one size fits all” approach to security, we should push for risk-based approaches to security testing. This allows us to target our testing where it is most needed and incorporate awareness from people on technical teams who have recently worked on part of a system.
The idea of “security assurance” – offered by some companies – is based on outdated ideas about threats and risks. In 2015 the US FDA essentially said “the cloud is okay” for most organisations, but some companies are still peddling the idea that on-premises or co-lo hosted systems are somehow inherently “more secure”.
We can (and should) use tools like OWASP ZAP (Zed Attack Proxy). gauntlt, and Chef Inspec to write security tests in code as part of our deployment pipelines.
Many package management and artifact management tools can now scan or recognise packages and container images and warn or fail a deployment pipeline if suspicious packages or container images are found. Some tools include: Node Security Project (NSP), Fortify, Nexus, Artifactory. [I mentioned this in my recent post on Artifactory as a tool for global software development.]
Some organisations have a weird “cognitive dissonance” around security by having strict security requirements during build & deployment but then allow developers or IT operations people to ssh/WinRM (remote) into Live/Production servers.
Emerging good practice for continuous security is to adopt the use of Zero Trust Networks, where we assume that networks and applications inside the organisation network perimeter are hostile. Applications and services should therefore act as if other collaborating endpoints are potentially compromised. Conveniently, O’Reilly have just (June 2017) released a new book on Zero Trust Networks.

Other useful approaches include:

Ensure observability of system behavior and execution via logging and metrics.
Use read-only / low-privilege service accounts combined with operations dashboards to avoid the need to anyone to remote onto Production machines via ssh or WinRM.

Other posts in this LondonCD series

On 12 June 2017 we had a London Continuous Delivery meetup at Endava in London. We used a modified form of the Open Spaces format for the meetup with less initial open discussion and more guidance/suggestions on discussion topics (based on past experience with events like PIPELINE Conference, this “accelerated” approach is easier for people new to Open Spaces).

Some good discussions came out of the evening: