SentinelOne Automates DevSecOps in Kubernetes Environments
SentinelOne this week announced it has added an Automated Application Control Engine that employs machine learning algorithms that only allows approved secure workloads to execute on a Kubernetes cluster.
Guy Gertner, vice president of product management for SentinelOne, says the goal is to automate DevSecOp processes using an allow list, formerly known as a white list, that machine learning algorithms enforce rather than requiring cybersecurity teams to manually set up and maintain a list on their own. Instead, the Automated Application Control Engine creates a default deny mode for containers based on scans for threats discovered by SentinelOne to prevent unauthorized changes to production workloads, he says.
In the absence of a dedicated allow list, cybersecurity teams alternatively need to spend time establishing a baseline to monitor application security each time a workload is deployed. At a time when DevOps teams are updating and deploying application workloads with greater frequency, that approach is no longer feasible, notes Gertner.
Initially available for Kubernetes runtime environments, Gertner says SentinelOne also plans to extend the reach of Automated Application Control Engine to additional runtime environments.
Gertner says one of the primary reasons organizations are finding it difficult to implement best DevSecOps practices is because there are too many manual steps involved. Security teams typically have many different workflow processes that make it challenging for them to manually keep pace with the current rate of application development, notes Gertner.
Rather than trying to force IT teams to meld those processes, it’s both more practical and effective to rely on automation in the form of machine learning algorithms to make sure unauthorized workloads are not allowed to execute in a runtime environment, says Gertner. Automated Application Control Engine identifies the execution of a foreign binary as a threat, isolates it in quarantine for inspection and then kills the process in the runtime environment.
While automating DevSecOps processes for runtime environments, there will still be a need to embed vulnerability scanning tools in application development tools. Eliminating the introduction of vulnerabilities in code is still the primary goal. However, as long as humans write code it’s probable mistakes will be made. As such, it’s critical to implement an additional layer of security in the runtime environment.
While there’s a lot more awareness of the need for DevSecOps processes, most organizations are a long way from realizing that goal. DevOps teams are clearly being held more accountable for application security as part of the overall shift left toward making developers responsible for applications on an end-to-end basis. The issue is that most DevOps teams don’t have the tools in place around which to construct those workflows. The most important thing now is to provide DevOps teams with access to the security tools required to begin crafting those DevSecOps processes, says Gertner.
As is the case with all things DevOps, the biggest issue is always the IT culture. Cybersecurity teams need to learn to trust application development teams to do the right security thing. The more DevSecOps processes become automated, the easier it becomes for those development teams to do the right thing every time a workload runs.
