How to Help Your Security Team Help You
KubeCon + CloudNativeCon and Prisma from Palo Alto Networks sponsored this post, in anticipation of the virtual KubeCon + CloudNativeCon EU, Aug. 17-20.
In some organizations I talk to, the productivity and workflow benefits of bringing operations and development into a trusting partnership have failed to be replicated with the security team.
This, I contend, is bad for everyone involved.
Security Gaps Are Costly on Many Levels
It’s bad for developers because security is inherently part of software quality. Vulnerabilities that could have been caught at the early stages of development can mean significant re-work when they inevitably come to light, affecting developers’ focus, flow and joy.
It’s bad for security teams because they know that they are not successfully fulfilling their mandate to reduce risk for the organization. They understand that attempting to detect and remediate problems at the wrong end of a pipeline positions them as a bottleneck in the value stream.
It’s bad for the business and its customers, as features are delayed, data is lost, and headlines are written. It’s also not ideal for humble security vendors, who just want to make the world a better place (feeding our families is just a happy by-product).
One thing we know for sure: there are plenty of insecure configurations slipping through the net as a result of these missed opportunities.
A Three-Part Solution
Finding a solution to this issue in an organization requires changes in mindset, process and technology.
Mindset
When I talk to a security operations team that is struggling to work effectively with a development team, I encourage both to establish some shared understanding.
In the past, a lot of the security focus on tooling has been on the edge — both in terms of topologies (with firewalls, for instance) and from a workflow sense, where the security team comes in at the end of the pipeline and does an assessment on what’s been built, or advises changes to running systems.
For a development team, this is the tip of the iceberg, and not where their focus lies. Plus, for teams using Kubernetes — and especially one of the managed cloud Kubernetes services — traditional security tools can seem irrelevant (although I’d argue that’s not true at all).
So I’ve encouraged security teams to build empathy with their Dev/DevOps colleagues through building a Kubernetes cluster (following the excellent “Kubernetes the Hard Way”), in addition to reading some books and watching “10 Deploys a day at Flickr.”
Process
But how does a development team get a better handle on what a security team cares about? One of the things I think is important is the joint development of a threat surface area model and a reference architecture of controls and mitigations.
Where are the weaknesses in the workflow, spanning initial software development to running a pod on a Kubernetes cluster? What controls can be put in place, without breaking the existing workflow to help eliminate them?
Your security team are experts at looking at all the ways you could get compromised; from malicious modules typosquatting and scheming to snare the unwary, to the more mundane over-privileged and misconfiguration mistakes. You are the experts at finding ways to detect and remediate them in ways that integrate with your automated build and test pipelines.
There are, for sure, negotiations to be held — what level of risk should break a build? How much restriction should be placed on libraries that can be used? If a cloud database is unencrypted, what should the remediation look like? How can someone determine if their infrastructure-as-code (IaC) template passes checks before they commit it and (possibly) break the build?
This is where the fun can start if you manage to bring the right mentality to the workshop. Teaching the security team some of the cultural traits that have made DevOps such an effective operational model will pay dividends here.
Can you translate blame-free post-mortem thinking into conflict-free security planning? Although security is a serious business, the problem solving needed to identify and remediate threats within a modern software development process can be an entertaining challenge that everyone could enjoy.
Technology
Once you have a handle on the threats and remediations, then comes the choice of tools.
We’ve found that successful tools allow a security team to manage policy, but provide feedback directly to developers — for example with a Slack message saying your existing container image, which sat securely in a trusted registry, has a newly discovered vulnerability in a Node.js package.
It’s also important to consider “cognitive load.” Unless you want security to shift so far left that it all becomes your responsibility, it’s worth keeping the tool count low, and looking for platforms that can be driven in multiple modes for different users. Security teams have to provide reporting and audits, and solutions that roll that kind of functionality into the platform will make their lives considerably easier — which, hopefully by the end of the process, you will be inclined to do.
For more ways you can connect security with cloud native development, consider coming to KubeCon + CloudNativeCon Europe, Aug. 17–20, being held virtually (and therefore being held wherever is safe and convenient for you).
Feature image via Pixabay.
At this time, The New Stack does not allow comments directly on this website. We invite all readers who wish to discuss a story to visit us on Twitter or Facebook. We also welcome your news tips and feedback via email: feedback@thenewstack.io.