Twistlock: Cloud Native Implications For Security
Twistlock sponsored this podcast.
Cloud Native Implications For Security And Twistlock 18.11
Cloud native architectures require a new approach to security. The cloud native stack doesn’t communicate in the predictable and tightly coupled way that stratified frontend, middleware, and backend layers provide. Applications composed of microservices and serverless functions are loosely coupled pieces of code talking to each other in unique, asynchronous ways — and there are exponentially more of them.
“It’s an explosion of complexity,” said Sonya Koptyev, director of evangelism at Twistlock, in this podcast interview at KubeCon + CloudNativeCon last month in Seattle.
When managing such complex environments, it can be difficult for operations and security teams to even know which services developers have running on various cloud providers, let alone to identify and remediate a critical vulnerability such as the recent, major privilege escalation vulnerability in Kubernetes that, if left unpatched, would allow attackers to take over entire compute nodes.
“Once [companies] get past that couple of hundred employee mark they have all sorts of services they’re running that the security team doesn’t know about, and with that, you introduce all sorts of vulnerabilities and threats into the environment,” Koptyev said. “The security team can’t secure them because they don’t know about them.”
Twistlock advocates a three-part approach to remediation that brings developers, operations and security specialists together on the same page. This “defense in depth” strategy begins with visibility: knowing which cloud services are being used and from which providers, what normal interactions between those services look like and also tracking where critical vulnerabilities exist in the infrastructure. Second is awareness of anomalies in that regular pattern of behavior so that, say, anonymous access is detected. And finally, runtime defense which allows for rules and checkpoints that trigger automated shutdown of any containers displaying anomalous behavior as a means to prevent exploitation.
Such checks happen once code is in production, but also — and crucially — before it even leaves the build phase of the software development life cycle. Developers are able to address potential security and compliance issues as they are writing the code. And code must pass a threshold of security checks before it can be shipped. It’s an approach that allows developers to move quickly and ship code to production, while maintaining compliance and security standards.
“It’s a whole-team approach to security. We help to make it everyone’s responsibility,” Koptyev said.
With its latest 18.11 release, Twistlock’s cloud native security tool adds a number of new features, including Cloud Platform Compliance, which allows teams to find all the services in use across cloud providers and visualize them on a dashboard. The new release also integrates the Istio service mesh, allowing for vulnerability and compliance checks across Istio components along with the checks it provides for other cloud services.
In this Edition:
2:45: Can you tell us what your developer team focused on with the Twistlock 18.11 release?
5:52: Discussing the resurgence of multi-cloud.
9:58: Let’s talk about the service mesh component. Where are your customers in the service mesh cycle?
14:27: How much of that can be automated?
17:17: With this critical vulnerability, using the 18.11 Twistlock Tools, is that something you could detect?
20:41: Being proactive in an automated way.
KubeCon + CloudNativeCon is a sponsor of The New Stack.
