Tips · 6 MIN READ · DAN WHALEN AND PETER SILBERMAN · FEB 26, 2019 · TAGS: Get technical / How to / Selecting tech / SOC / Tools
Editor’s note: This is the first in a series of posts that’ll tell you all about technologies we use in conjunction with Expel Workbench.
At Expel, our SOC analysts get to work with lots of cool security technologies every day. Some are integrated directly into Expel Workbench — like Carbon Black, Darktrace and Duo, to name a few — because these are the products our customers already use, and we ingest activity events and alerts to monitor a customer’s environment. (By the way, if you want to see a longer list of our integration partners, go check out this page.)
But we also use other technologies behind the scenes to make our analysts more efficient. Ultimately, we’re trying to apply technology to the alerts we pull from our integration partners so we can: 1) generate higher fidelity alerts and 2) give our analysts additional context when they’re triaging an alert.
When we evaluate technologies that we’ll potentially integrate into Expel Workbench, we typically ask ourselves four questions:
- Does this product or service allow us to improve a customer’s security posture?
- Does this technology offer new detection capabilities, improved response capabilities or provide our customers greater visibility into the work we’re doing?
- Will this product/service provide additional context that our SOC analysts would find useful?
- Will it allow us to shrink the time to evaluate a class of alerts?
If a technology meets any of the criteria above, then we’ll take it for a test drive to see if it can provide value to Expel Workbench, our analysts and our customers.
GreyNoise has sensors all around the world that tell you what IPs are scanning the internet on a daily basis. When GreyNoise sensors detect scanning activity from an IP address, the service records the behaviors it observes from the IP along with related context about what it knows about that source. Why is this useful? This context gives you a global view of what an IP address has been up to historically (a perspective that’s hard to come by otherwise). For example, threat researchers can use this data to look for spikes in scanning to identify possible new outbreaks of worms or other potential threats. Security practitioners can also use this data to filter out the noise in their network logs so they can focus their time on investigating legitimate threats actors and avoid wasting time chasing noise.
Before we evaluated GreyNoise, we thought their data could help us in a couple of ways. First, we thought GreyNoise’s data might help us enrich the alerts and investigative leads we generate with additional context so our SOC analysts could shrink the time it takes to triage alerts. Second, we were interested in experimenting with how we could use GreyNoise data to detect threats. Although detection isn’t our primary use case for GreyNoise, we wanted to explore some ideas that could help us identify noteworthy activity at our customers.
How we evaluated GreyNoise (and what we learned)
In order to evaluate GreyNoise and determine whether the tool would deliver the value we thought it might, we decided to run several different experiments using the service.
Greynoise offers an API free of charge to so you can test various use cases and get a better understanding of how the technology can help your security operations. This is pretty awesome — how many other vendors are offering things for free to prove their value?
We used this API, to test four use cases. For each use case below, we’ll describe why we explored it, how we evaluated it and what we learned. As you’re reading, think about how you might create different detection cases and then how you’d evaluate them for your organization.
Use case #1: Improving investigative context and triage time
Why we tested this use case: As a managed security provider, we’re always exploring ways to make our analysts more efficient. One common pain point for security analysts everywhere is that Internet-wide scanning generates a lot of noise. Most don’t require any actions. But reviewing them sucks up hours of time. We wanted to explore whether GreyNoise could help us quickly identify and filter out the noise so our analysts can focus their valuable time and energy on the alerts that matter.
How we evaluated it: We took a sample of ~11,000 public IPs observed generating alerts across our customer base and requested GreyNoise context. This helped us determine how often the service would be able to tell us something valuable about an IP address.
What we found: Our tests showed that GreyNoise was able to provide valuable context for 21 percent of the IP addresses we tested. This was a promising result for us! Speeding up the investigative process for a fifth of all alerts we review is a significant step in the right direction. As the GreyNoise service grows and collects more data we expect this percentage to increase.
Use case #2: Detect when a customer IP address is flagged by GreyNoise
Why we tested this detection: If GreyNoise identifies a customer’s IP as noise, it could be a security concern. For example, a noisy customer IP might mean there’s a worm infection on a customer asset, a compromised IoT device or a vulnerability on a customer asset (think reflective DoS).
How we evaluated it: We collected known IP space for a few of our customers by looking up their ASNs. We downloaded the daily noise from GreyNoise and compared the results against this IP space (~74,000 IPs).
What we found: We found 14 customer IP addresses that were classified as noisy by GreyNoise. When we investigated, we found evidence of anomalous outbound SMB traffic that led to a customer notification.
Use case #3: Detect customer hosts communicating with suspicious IP addresses
Why we tested this detection: If a customer asset is communicating with an IP flagged by GreyNoise, it could represent an actionable security concern or else give us valuable context that will speed up our investigation.
How we evaluated it: We took a sample of 29,652 destination IPs observed in customer environments and ran them against the GreyNoise API to retrieve context.
What we found: We found that a significant portion of security alerts observed across our customer base (~ 25 percent) were going to a ‘noisy’ IP address. When we reviewed these alerts, it was clear that the context GreyNoise provided would have accelerated our investigative process by, for example, differentiating targeted attacks from generic internet-wide scanning.
Detection #4: Detect successful logins or data access sourced from internet scanners
Why we tested this detection: If we saw successful logins from an IP address scanning the internet, it could indicate a user’s credentials were compromised or that some services were misconfigured. For example, we’ve seen organizations sometimes misconfigure cloud storage services like AWS S3 buckets or Microsoft Azure blobs. If we saw successful access to this storage from a scanner, it could indicate a misconfiguration that puts the customer’s data at risk.
How we evaluated it: We took a sample of 6,310 alert source IPs observed in customer environments and ran them against the GreyNoise API to retrieve context.
What we found: We didn’t find many instances of successful logins or data access from noisy IPs (good news!). GreyNoise provided context for ~0.5 percent of the alerts we tested. This is also encouraging from a detection perspective. Following our testing, we’ve implemented rules to generate alerts when we observe a successful login or data access from a noisy IP address to highlight potentially compromised accounts or a misconfigured cloud storage service.
Why we like GreyNoise
When we see alerts sourced from IPs that GreyNoise classifies as “noise,” it helps us accurately prioritize them as non-targeted threats. Of course, this depends on the type of activity we observe and how the IPs are tagged. GreyNoise has helped us to create new rules that eliminate noise for specific low-value events that don’t represent an actionable security concern. Additionally, the context it gives our analysts during alert triage can significantly reduce analysis time.
Since integrating GreyNoise in Expel Workbench last summer, Expel has used the data to more efficiently triage alerts, detect interesting activity and weed out internet noise to focus on the alerts that really matter. Moving forward, we hope to continue research into creative new use cases and leverage some new GreyNoise features (hello GreyNoise query language!) for detection and research. Big shout out to two of our interns, Chris Vantine and Brandon Dossantos for their work in helping us evaluate GreyNoise.
Interested in taking GreyNoise for a test drive? There are two easy ways to get started.
First, head over to the GreyNoise Visualizer and try searching for a few IP addresses as you investigate alerts throughout the day. You might find (as our analysts did) that this context reduces the time it takes to review alerts.
Second, if you are looking to integrate GreyNoise context into your analysis workflow, take a look at the GreyNoise API. This is a great way to automate lookups and eliminate extra steps in your analysis process.
Give these ideas a try and see how GreyNoise stacks up. We’d love to hear about what you learned during your evaluation process. Drop us a note and share your thoughts.