The Elastic InfoSec team's internal use of Elastic Security has increased visibility and exponentially expanded its response capabilities to threats.

This blog post is one in an occasional series about how we at Elastic embrace our own technology.
The Elastic InfoSec team is responsible for securing Elastic and responding to threats. We use our products everywhere we can&nbsp;— and for more than just logs. By harnessing the power and breadth of capabilities of the Elastic Stack, we are working on tracking risk and performance metrics, threat intelligence, our control framework, and control conformance information within Elastic.&nbsp;
Security has been and continues to be a top priority internally as well as in the products we develop and deliver. We’ve doubled down on these efforts when we joined forces with <a href="https://www.elastic.co/blog/endgame-joins-forces-with-elastic">Endgame</a> to craft Elastic Endpoint Security, and with <a href="https://www.elastic.co/blog/welcome-perched-security-training-for-siem-threat-hunting-and-more">Perched</a> to help create Elastic SIEM. Teaming up with these companies brought a whole new set of security professionals to the Elastic organization. Each professional brings a diverse set of skills and experiences that we can lean on to help protect our organization using our own security products — <a href="https://www.elastic.co/endpoint-security">Elastic Endpoint Security</a> and <a href="https://www.elastic.co/siem">Elastic SIEM</a>.
Our internal use of the Elastic Security solution has increased the Elastic InfoSec team’s level of visibility and has exponentially expanded its response capabilities to more fully empower the broader organization to protect the Elastic enterprise from the threats of today and tomorrow. For our Elastic community of users and customers, this also translates to us delivering a better, leading security solution.&nbsp;
We are excited to share our story….
<h2>“Customer Zero”</h2>We have the expressed goal of being Customer Zero for all of our solutions, and this applies especially to Elastic Security. To ensure that what we deploy to our customers has been tested in a real production environment before it gets distributed more broadly, we’re an early adopter of build candidate (pre-release) versions of the Elastic Stack and each of our solution deployments.
We’re excited about having an industry-leading Endpoint Detection and Response (EDR) tool available to use within our environment. You can read all about the effectiveness of Elastic Endpoint Security in third-party reports from NSS Labs, Gartner, and AV Comparatives in <a href="https://www.elastic.co/blog/introducing-elastic-endpoint-security">this post</a>.
Having leading detection and response capabilities on the endpoint is great on its own, but we’re really thrilled by the possibilities that come with its native integration with the Elastic Stack and Elastic SIEM.&nbsp;
It’s remarkable to have the ability to create automated responses and advanced analytics in addition to having the data and visuals we as analysts need — all in a single platform.
<h2>Piloting Elastic Endpoint Security</h2>Replacing an endpoint security agent is not a task that is frequently undertaken, and it often comes with unexpected challenges. So when we announced our intent to bring Endgame into the Elastic fold, we immediately began planning our migration from CrowdStrike to Elastic Endpoint Security (formerly Endgame).&nbsp;
After officially joining forces with Endgame, we began to deploy the Sensor Management Platform (SMP) for our end user pilot. We were easily able to import our whitelist and trusted applications that we had previously configured in CrowdStrike. Then, we created a single detection policy within the SMP and enabled all threat and adversary behavior detections. We also enabled all event collection features and set up event streaming to Elasticsearch.&nbsp;
We ran the pilot on a small percentage of endpoints in a detect-only mode for a little more than a week. With our pilot users streaming endpoint data back to the SMP and to our endpoint monitoring Elasticsearch cluster, we began migrating our existing Auditbeat and Winlogbeat dashboards, queries, and Watcher alerts to use the endpoint index. The data received via the endpoint agent is similar to the data collected by Auditbeat and Winlogbeat without having to manage yaml configurations.

<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltec0e916e79b25bd3/5e470e8a7c62095ce7b37118/Securingendpoints-blog-canvas-dashboard-overview-Elastic-Endpoint-Alerts-1.jpg" data-sys-asset-uid="bltec0e916e79b25bd3" alt="Securingendpoints-blog-canvas-dashboard-overview-Elastic-Endpoint-Alerts-1.jpg">

<figcaption>A Canvas dashboard giving an overview of Elastic Endpoint Alerts</figcaption><h2>Investigating with Elastic SIEM </h2>We were then ready to perform investigations in the Elastic SIEM app by simply adding the “endgame-*” index pattern to the default index for SIEM in Kibana. Investigating Elastic Endpoint Security alerts or other anomalous behavior in the SIEM app is easy with Timeline. Timeline allows us to stitch together processes by process ancestry similar to the ResolverTM view within the management console. It also allows us to see a population of events and data (process names, process arguments, etc.) across our entire endpoint fleet with the speed of Elasticsearch.

<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt85eaeb609b10986e/5e470e9894aef92989eeff6a/Securingendpoints-blog-configuring-indices-Elastic-SIEM.png" data-sys-asset-uid="blt85eaeb609b10986e" alt="Securingendpoints-blog-configuring-indices-Elastic-SIEM.png">

<figcaption>Configuring indices for the Elastic SIEM</figcaption>During the pilot, we had a single malware detection on one of our Mac workstations that had been present on the system with CrowdStrike installed. We were able to use the response capability in Elastic Endpoint Security to remotely remediate the malware with minimal impact and downtime to the impacted user. The user was actually able to continue working; the only interruption experienced was us telling them we were remotely working on their laptop.&nbsp; 
We were very happy with how easy it was to remove a fairly complex piece of malware that had several persistence mechanisms.&nbsp;
We’re a distributed organization with currently 1,900+ Elasticians located across 40+ countries, and a lot of our employees rarely, if ever, find themselves in an Elastic office. With this in mind, we were impressed with the Elastic Security solution’s ability to enable an Elastic analyst sitting in their house in Germany to successfully remediate malware on the device of a Tennessee-based employee. This was not a capability we had on Macs before installing Elastic Endpoint Security.
<h2>Deploying Elastic Endpoint Security</h2>After the pilot period, we deployed the Endpoint agent to the remainder of the endpoint fleet in detect mode over a period of five days while removing CrowdStrike at the same time. During this period, we deployed to 1800+ endpoints — our fleet of user devices at that point in time — with no reported issues from any of our fellow Elastician users. If you’ve ever deployed an agent to user endpoints (especially security agents), you know it never goes this smoothly. But for us, it did.
Once we rolled out to the fleet at large, we had 23 systems report malicious files that needed to be remediated. The surprising part for us was the extremely low false positive rate on threat detections.&nbsp;
The Adversary Behavior detections, however, were noisier and filled with false positives because of the diverse skill sets, and subsequent behavioral trends, of our Elasticians. We saw things like Elastic security professionals conducting research and exploit proof of concepts, developers creating software, and sales architects running containers and other interesting tools. Our initial pilot users, along with the 23 systems that had true positive threat detections, were moved into prevent mode in less than a month with no reported impact.&nbsp;
Shortly after moving the pilot users to prevent mode, we migrated the entire fleet of user devices to prevent mode with zero reported issues.&nbsp;
The difference in visibility we now have into our endpoints is amazing. We can be using remote response on an endpoint across the globe and see the signals from the endpoint in both the endpoint console and in Kibana — in close to real time. The level of detail in the signals is better than we have typically seen with other endpoint security tools we’ve used in the past.

<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltc00422b5bf702433/5e470eacca06ad274a65b76f/Securingendpoints-blog-elastic-SIEM-signal-and-resolver-view-console-1.jpg" data-sys-asset-uid="bltc00422b5bf702433" alt="Securingendpoints-blog-elastic-SIEM-signal-and-resolver-view-console-1.jpg">

<figcaption>(Top) A Signal in the Elastic SIEM app for an Elastic Endpoint Alert with logs for the same host inline with the Signal. (Bottom) The Resolver view, in the Elastic Endpoint Security console, showing the process lineage associated with the same alert.</figcaption><h2>From Elastic workstation to server fleet protection and beyond </h2>Now that our Elastic workstations are fully protected by Elastic Endpoint Security, we have begun our pilot of placing the Elastic Endpoint Security agent on our server fleet. We’ll be targeting all our server resources that bring you Elastic Cloud and enable us to deliver the Elastic Stack.&nbsp;
This rollout will probably take a bit more time than our endpoint rollout. We have a broader set of operating systems and cloud providers to test on than we did for workstations, but we’ll get there soon enough.
We’re excited to continue using the Elastic Security solution and all the integrations it has with the Elastic Stack. We’ll keep providing feedback directly to the Elastic teams working on the product, workflows, and integrations. We see this as a really great internal partnership.&nbsp;
Best of all, we’ll continue being Customer Zero so that our customers can benefit from well-tested and thoroughly deployed Elastic solutions and products.
Mandy Andress is CISO at Elastic; Darren LaCasse is Principal Analytics and Detection Lead I at Elastic; and Brian Milbier is Principal Security Assurance Analyst I at Elastic.

blog-banner-elastic-on-elastic.png

blog-thumb-elastic-on-elastic.png

Elastic on Elastic: Securing our endpoints with Elastic Security

Alerting with context baked in helps analysts be more efficient. Storing alerts let you see trends in your environment that you may have otherwise missed.

Within Elastic, the information security team is tasked with security detection and analytics, among many other activities of a typical information security team. To find abnormal and malicious behavior within our environment we leverage <a href="https://www.elastic.co/products/siem">Elastic SIEM</a> for investigations and threat hunting. When we find a pattern of behavior we want to be alerted on during an investigation or hunt we take the request JSON behind our investigation and put in to <a href="https://www.elastic.co/guide/en/elasticsearch/reference/7.5/xpack-alerting.html">Watcher</a> for alerting. Recently, we decided to start capturing the payload of our alerts in a separate index with the following goals: 
<ol>
	<li>Better reporting on the alerts that fire and observables (hosts, users, IPs, etc…) that are part of an alert payload.</li>
	<li>Enrichment of alert payloads with MITRE ATT&CK information and response playbooks. This will further speed up analysts and provide additional reporting on observed behaviors and coverage of the MITRE ATT&CK framework.</li>
</ol>Watcher has an <a href="https://www.elastic.co/guide/en/elasticsearch/reference/7.5/actions-index.html">index</a> action that allows you to index data into Elasticsearch but I wanted to do more than just send the alert data in to another index, I wanted to enrich it with additional data so I got creative to make this happen.&nbsp;
 <h2>Alert indexing and enrichment</h2>I won’t dive in to the body of the Watcher; I’m going to&nbsp; assume if you’re reading this you’ve already got Watcher setup for alerting. To get the enrichments in to the alert payload, I used a <a href="https://www.elastic.co/guide/en/elasticsearch/reference/7.5/transform.html">Watcher payload transform</a> to list each object in ctx.payload.hits.hits, and then added in the enriched, MITRE ATT&CK framework fields. You’ll notice we used parameters to inject the values for the newly created fields. This makes it easier to update the injected values without getting lost in the JSON:
<pre class="prettyprint">"transform": {
 "script": {
 "source": "List x = ctx.payload.hits.hits.stream().map(d -&gt; {d._source['threat.framework'] = params.framework; d._source['watcher.name'] = params.watcher; d._source['threat.tactic.name'] = params.tactic; d._source['threat.technique.id'] = params.techniqueid; d._source['threat.technique.name'] = params.techniquename; return d._source}).collect(Collectors.toList()); return x;",
 "lang": "painless",
 "params": {
 "watcher": "logFileChanges.json",
 "framework": "MITRE ATT&CK",
 "tactic": "Execution",
 "techniqueid": "T1059",
 "techniquename": "Command-Line Interface"
 }
 }
 }
</pre>Now the enriched alert payload is ready to be sent into the new index. This is where the index_payload action comes in. Another transform is used to return the documents in the ctx.payload._value that we created with the transform above and then we specify the index we want to put the alerts in, in our case it’s newIndex.
<pre class="prettyprint">"actions": {
 "index_payload": {
 "transform": {
 "script": {
 "source": "return ['_doc':ctx.payload._value];",
 "lang": "painless"
 }
 },
 "index": {
 "index": "newIndex"
 }
 }
 },
</pre><h2>Cool, Now What?</h2>Now that you’re storing and enriching alert data you’ll probably want to do something with it. This is where all the hard work of getting your alerts stored and enriched pays off. Now you have another index with data that you can report and alert on. Let’s dive in to some ways I’m using this alert data.
 <h3>Reporting</h3>Now that we have all of our alerts populating a new index with injected fields for our monitoring environment, we can start reporting on our observations. I set up a Canvas dashboard that lets us gain insights into what we’ve observed in our environment. Here is the Canvas dashboard with some sample data so you can see it in action.
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt3f3226ec24d94348/5de56dda546f955ab898caf4/alerts-blog-dashboard.jpg" data-sys-asset-uid="blt3f3226ec24d94348" alt="Canvas dashboard showing security alerts overview" style="display: block; margin: auto;">
With this Canvas dashboard we are showing an overview of the alerts enriched with MITRE ATT&CK information. You can see the total number of alerts triggered and that is further broken down by MITRE ATT&CK Technique, host, and operating system. This can start to give us insight into if an attack is targeted at a single or small number of hosts or if there is just a lot of activity happening in general. We can also see if the alerts are all for a particular operating system or not. This may result in reviewing the configuration and security posture of that OS since we can see more alerts being generated from them.&nbsp;
The Canvas dashboard also shows us a breakdown of the MITRE ATT&CK Techniques by technique so we can see which techniques are being utilized and alerted on. We can also see with the Timelion element when these alerts are happening. This can show us if the attacks are spread out evenly, ramping up over time, or spiking.
Easier reporting, check. More meaningful reporting, check. Now lets make these alerts more useful for the analyst.
 <h3>Alert Enrichment</h3>We already know the Elastic Stack is really fast at providing search results but we’re always looking for ways to make analysis even faster and more efficient. To speed up the analysts’ ability to investigate faster I made two of the injected fields link back to relevant information. Here is how I did that for threat.technique.id in the index pattern for this index.
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt71af6fb2ffbbac6a/5de56e7394bf745993ed3e7b/alerts-blog-field-format.png" data-sys-asset-uid="blt71af6fb2ffbbac6a" alt="" style="display: block; margin: auto; width:60%;">
I also did this for the field watcher.name. This is how those fields show up in the Discover view now
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltb62056c537f389f1/5de56eac92ebd8575d520078/alerts-blog-field-links.png" data-sys-asset-uid="bltb62056c537f389f1" alt="" style="display: block; margin: auto; width:75%;">
Where do these links take you? The link for threat.technique.id links back to the relevant MITRE ATT&CK Technique page so the analyst can read through the details of the technique if they aren’t familiar with it. The link to watcher.name links back to our triage playbook for this watcher so analysts don’t have to remember where to find the relevant playbook.&nbsp;
 <h2>Wrapping up</h2>And just like that, we’ve stored and enriched alert payloads to make reporting and we’ve met our&nbsp; goal of improving security detection capabilities. These same techniques can be used no matter your use case and I’m hopeful that you found this useful and can begin to do similar things within your environment. I encourage you to try it out yourself. And if you’re not currently using Elastic SIEM or Watcher, you can give them a whirl in a <a href="https://www.elastic.co/products/elasticsearch/service">free trial of the Elasticsearch Service</a>. And as always, if you run into any problems, reach out on our <a href="https://discuss.elastic.co">Discuss</a> forums. Enjoy!

AUTHOR

Articles By Darren LaCasse

Elastic on Elastic: Securing our endpoints with Elastic Security

Storing and enriching alerts for information security with Elasticsearch

注册 Elastic Cloud 免费试用版

产品和解决方案

公司

资源

解决方案

Elastic (ELK) Stack

新增功能

AUTHOR

Articles By Darren LaCasse

Elastic on Elastic: Securing our endpoints with Elastic Security

Storing and enriching alerts for information security with Elasticsearch

注册 Elastic Cloud 免费试用版