I was lucky enough to get to attend the recent DevOps Enterprise Summit 2017 in London last week, which, sadly, occurred right after recent tragic events there. Fortunately, the whole city felt safe, and everyone I met just wanted to get on with life, so I allowed myself to get immersed in technology themes of the day, and in this post, I’ll dig deeper into a few key themes
Most of the themes from conversations I had at #DOES featured the idea of Containers as a Security Enabler, a subject our CTO has spoken about multiple times at conferences. Specifically, there were three macro themes that bubbled up:
- How containers improve security: Containers offer a number of characteristics that create opportunities for building and deploying more secure applications and environments.
- How security can and should shift left. If you haven’t read it yet, Chris Riley did a great post on this for us recently too.
- How security is everyone’s responsibility and should be a first class citizen in the DevOps process. Michael Churchman has a good read on this here.
There were also quite a few related smaller bits that figured prominently into these macro themes, including:
- APIs are necessary: Please don’t give us yet another user interface as the only way of working with your tooling.
- Barriers to entry need to drop: If we want to have others take part, we need to make collaboration as easy, open and approachable as possible.
- Operational and Security barriers need to be re-evaluated for this high cadence of delivery.
- Tools must be able to run on a user’s platform of choice and either in a cloud provider or on-premise.
Let me unpack two of the larger themes here…
Containers as a Security Enabler
As we’ve written about many times, old world security has to evolve to a more proactive model. DevOps Enterprise Summit showed how multi-national, heavily regulated, security-conscious businesses are seeing real ROI by giving operational control of the application to the developer, often via containers.
To me, operational management of a service includes the security of that service. Just as DevOps teams leverage the specialist skillsets coming from traditional operations teams, so too can they leverage security skillsets. If security folks provide the rules and the tools to their DevOps teams in an easily consumable manner, DevOps will use them. In fact, they want to operationally manage that application or service. They also want to see a service in production helping your customers. Imagine if traditional security teams further leveraged this shared objective, and provided a Security as a Service toolset, then simply attended to bigger picture security? They could use the extra time on their hands to search out and fix other security risks in the company. Heck, they might even find a better solution than passwords!
“To the left, to the left,
everything you own in the box to the left”
Beyonce – Irreplaceable
When people at #DOES spoke of shift left left, they mentioned what worked and what didn’t work within their own teams. Here are the top three recommendations:
- Make your security policy clear and consumable: Having a policy on SharePoint which is covered in the electronic dust of ages is not the answer, but providing a means to scan an image for malware is required. This doesn’t mean that you have to show everyone what you are going to check for– just those things that your DevOps teams can and should be able to remediate.
- Ensure that your security tooling is approachable and consumable: APIs are key! Either that or having a Jenkins or TeamCity plugin is immensely helpful. Our own CI/CD capabilities are outlined here.
- Provide a means to take on additional checks that your teams may want: As other team members get engaged and empowered, you might be surprised at how they will then want to make things even better. Take in custom CVE feeds or XCCDF documents for compliance. Collaboration and inclusion is a driving force.
Once you can engage your DevOps teams in a meaningful dialogue, they can begin to take on vulnerability and compliance scanning at build time. Also, with the reports available to them, they’ll be more clearly accountable for the state of the service in production.
By shifting things left you then allow specialized security personnel to operate at scale so they can concentrate on developing and enhancing the security state of your company overall.
Follow us on Twitter
Follow us on Twitter for real time updates on the cloud native ecosystem, Twistlock product, and cloud native security threats.
Announcing Our Series C FundingRead the Blog
Real Time View of Your Cloud Native Applications: Radar v3Read the Blog
AWS Fargate Security: Runtime Defense with Twistlock 2.5Read the Blog
Cloud Native Forensics: Security Incident Response in Twistlock 2.5Read the Blog
Announcing Twistlock 2.5: GA Release NotesRead the Blog