Elastic and build.security: Shifting left together to secure the cloud

Since its inception, Elastic Security has had a clear mission: to protect the world's data and systems from attack.

We started with SIEM, built on top of the Elastic Stack, applying its fast and scalable search capabilities to detect security vulnerabilities across all threat vectors. Next, we joined forces with Endgame to integrate endpoint security into Elastic Security, and allow customers to prevent, detect, and respond to attacks from a single, unified platform. With the recent release of Elastic Security Limitless XDR and the general availability of Elastic Agent, we furthered our mission.

Today, we are excited to announce the next step in the Elastic Security journey: to extend security enforcement from every endpoint to every cloud workload.

Millions of users trust Elastic for observability of their critical business applications. Elastic is deployed across hundreds of thousands of cloud-native workloads for logging, metrics, and application performance monitoring. In addition, Elastic Security includes powerful detections against cloud-native threats, like our machine learning models to detect attacks against the AWS metadata service.

We are now taking this one step further. We are excited to join forces with build.security, based out of Tel Aviv, Israel, to move toward cloud security enforcement — the ability to enforce security actions for cloud native environments — on hosts, virtual machines, and containers orchestrated by Kubernetes.

The small but mighty team at build.security has created a policy definition and enforcement platform leveraging the open source standard Open Policy Agent (OPA) to allow organizations to hook into cloud-native infrastructure components like Kubernetes and enforce policies in real time. Leveraging simple user experience on top of OPA, build.security delivers policy management and enforcement across cloud-native environments and platforms like Kubernetes and Istio.

By integrating build.security's technology into Elastic Security over the coming months, our customers will be able to continuously monitor and ensure that their cloud environment is secure to the policies they have put in place, as well as validate their security posture against well established standards like CIS benchmarks. They will be able to ensure that their Kubernetes configurations are secure, that they are using approved container images, and much more.

Cloud security defined

At Elastic, we think of cloud security as including both detection of cloud-native threats, and enforcement of security actions on cloud-native infrastructure. Cloud security enables customers to answer two key questions:

• Is my cloud environment secure in accordance with the policies I've put in place? This is continuous cloud-native security.
• Is someone attempting to violate my security policies, and how do I prevent it? This is workload runtime security.

Continuous cloud-native security

Core to cloud-native security is ensuring all environments are built and maintained to the policies you define. This configuration and change management is critical in cloud computing, since new environments are created constantly and by numerous different teams in an organization. Whether it is a bespoke policy the organization has created, or a defined set of policies such as from CIS benchmarks, or a combination of the two, a capable cloud security offering needs to provide a simple way to enforce compliance to these policies. This is the area that build.security specializes in, and the focus of the work that we will do together.

Open Policy Agent (OPA)

We believe that data, policy, and policy management is at the heart of ensuring continuous cloud-native security. By joining forces with build.security, we are reinforcing our fundamental belief in policy as a cornerstone of security, and our shared conviction in the power of the de-facto standard for policy authoring and enforcement: CNCF's Open Policy Agent (OPA).

From the GitHub readme:

The Open Policy Agent (OPA) is an open source, general-purpose policy engine that enables unified, context-aware policy enforcement across the entire stack.

OPA is hosted by the Cloud Native Computing Foundation (CNCF) as a graduated project.

Using Rego, which is the policy language used to define OPA policies, companies can more easily articulate, and more importantly, collaborate, on common build time, deployment time, and runtime cloud native practices. Furthermore, being able to share them with a community can go a long way toward making all of us better. We've seen this first hand with the open detection repository for Elastic Security, with the community contributing dozens of new rules with our latest update. In time, we anticipate being able to invest in and contribute to the future of OPA as this standard continues to gain even more momentum amongst users.

The road ahead

We believe in the force multiplier effect that comes from joining forces with focused, innovative teams like build.security. Our intent is to start by working together with Amit Kanfer, the co-founder and CEO of build.security, and his team, to integrate OPA into Elastic Agent, as well as to build the ability to manage OPA policies directly in Kibana, and store the results of OPA policy executions within Elasticsearch using the Elastic Common Schema (ECS).

Starting with Kubernetes admission controller, Elastic will continue to add policy capabilities on all stages of the development pipeline, from code to cloud to runtime, ensuring compliance, mitigating risk and reducing human error — all on top of our existing observability stack.

But this is just the beginning. We asked Amit to co-author this blog and discuss his views on the future of policy and OPA for security. In his own words:

"Think of a platform that hooks into your git repository and enforces compliance and security checks at build time, blocking PRs from getting merged if they violate policy. That same platform attesting all security checks within the CI/CD pipeline (e.g., image scanning and verification), connecting to Jenkins and CircleCI, and through Kubernetes admission controllers in the cloud, preventing supply chain attacks. Potentially, being able to augment runtime workload protection when integrated with eBPF. All of these can be achieved by leveraging Open Policy Agent.

Now imagine all of that in Kibana, seamlessly integrated into Elastic Security and interoperable with Elastic Observability. How cool would that be?

Most software companies spend a ton of time justifying why they need a seat at the table. Elastic already has a seat at the table. We're excited to join forces with Elastic and accelerate our ability to deliver the promise of a free and open policy management platform for cloud native environments, starting with Kubernetes admission controller security and then expanding from design to deployment to production, from code to cloud to runtime."

Building a center of excellence in Israel

An additional benefit of joining forces with build.security is to cement a presence in the tech center of Tel Aviv. The entrepreneurial spirit is strong in Israel, with constant security innovations that have the potential to significantly improve the security experience. While Elastic remains a distributed company by design, with around a dozen employees already in Israel, the build.security team will be the foundation of our future growth in the region, and Amit will assume the role of site lead for our efforts there. We are excited about what we will be able to achieve together — we are just getting started!

Build.security was seeded by YL Ventures, a leading cybersecurity-focused venture capital firm headquartered in Silicon Valley.

To learn more about recent developments in Elastic Security, check out our latest 7.14 security release, and join us for our upcoming user Conference, ElasticON Global, Oct 5-7, 2021.

###

Forward-Looking Statements

This blog post contains forward-looking statements which include but are not limited to statements about future features and functionality. The release and timing of any features or functionality described in this document remain at Elastic's sole discretion. Any features or functionality not currently available may not be delivered on time or at all.