Continued leadership in open and transparent security

Elastic Security has long been open — with open source roots, open development, and the release of our SIEM in 2019. In 2020, we further embraced the openness of Elastic and released our open detection-rules repo to collaborate with our users and be transparent about how we protect customers. That repo is focused on our SIEM and Security Analytics use cases and did not yet include Elastic Endpoint Security artifacts. We continue to build on that foundation today by opening a new public repo, protections-artifacts.

In the protections-artifacts repo, you’ll find protection logic utilized by Elastic Endpoint Security to stop threats on windows, macOS, and Linux operating systems. This includes malware behavior protection rules written in EQL as well as YARA signatures applied to both files and memory. This isn’t a subset or sampling, it’s the entire set of rules and signatures actively blocking threats. As we update these features in our product, you’ll see the changes, providing transparency into exactly how those features identify threats and behaviors to block.

A transparent approach

While sharing detection logic is becoming the status quo for SIEM vendors, that's not true for endpoint products. We believe that should change. Endpoint Detection and Response (EDR) and Endpoint Protection Platforms (EPP) are typically a black box, with many vendors expecting users to put up with a lack of information and insight. This way of doing business does little to educate and empower users. 

We look at our relationships with users as partnerships. In these relationships, transparency is a prerequisite to mutual success. The need to behave this way should be obvious and the practice universal. After all, security solutions are built to mitigate risk, and the only way a user can ensure a vendor is helping mitigate risk is for the vendor to be transparent about how they are protecting an environment. With transparency, our users can understand strengths in our product and can maximize their own efforts to close any remaining gaps that are of greatest risk to them.

[Related article: Forrester names Elastic a Strong Performer in the Endpoint Detection and Response Wave]

Addressing concerns

We believe that being open and transparent is best for users and will improve security for everyone in the long run. We considered our decision carefully. In the spirit of transparency, we’ll share our perspective on a few perceived negatives we expect some may raise:

We might get more public criticism and scrutiny because of our transparency. This is no reason to mask how a product works, if what we really care about is empowering and protecting our users. Elastic is already openly available with thousands of people downloading and trying us out every day — including some fantastic researchers probing our product. We welcome it. We hope that most researchers collaboratively engage with us as detection gaps are discovered. 

We don't expect everyone to embrace this approach, and some may try to score some Internet points by highlighting a gap and trying to dunk on us. We invite criticism and feedback with open arms. We will keep getting better and we’ll show you how we do it. 

Some may think it could be easier for attackers to bypass our product. Some may believe that if a product is closed, motivated attackers will struggle to understand how it detects and blocks threats. This is not true. Attackers are going to get the detection logic anyway, whether through dumping it from disk or memory on the endpoint or through trial and error testing against the product. Security through obscurity isn’t security! We believe in building protections that are fundamentally resilient to attacker knowledge of the logic behind any particular protection or rule. We target techniques that attackers have a hard time not utilizing, and we provide many layers of protection — so if one piece is bypassed, more protections lie behind it.

Competitors might steal our detection logic. Our goal with the open approach is to empower our users and make a meaningful improvement in security through greater transparency. This means raising all boats even if it may benefit other security vendors, some of whom might take whatever they can regardless of licensing and other restrictions while giving nothing back. We’re confident that our competitive advantage only gets stronger as we do things to help our users. It’s also not just about the detection rules. Elastic Security provides users with the best architecture to run the detection logic and block threats.

Open conversation

True to our open nature, we’d love your feedback: Talk to us via GitHub issues, chat with us in our community Slack, ask questions in our Discuss forums. Tell us what you need. Ask us why we made a certain choice. Even better, share detection logic with the world and help us raise the bar. 

Our invitation to share detection logic goes further than just our global user base. The status quo among EPP/EDR vendors should evolve toward transparency. We know we’re first movers on this and hope others follow. 

In summary, we think adding transparency to endpoint protection is the right thing for our users, so we’ve done it. We hope other vendors will follow and bring greater transparency to endpoint security. Expect to see updated YARA signatures and behavioral rules as we update Elastic Endpoint Security.

Stay tuned for more future transparency in endpoint security from Elastic Security by keeping an eye on protections-artifacts. We plan to release artifacts for additional endpoint protection features in the future. Also don’t forget to watch Elastic Security Labs for more insight into the security research we’re doing here at Elastic.  

Read this next: Get more data into your SIEM while increasing operational efficiency.