SIEMs used to leverage signature-based detection, which relies on known bad patterns or malware — but that approach comes with limitations. Today’s modern SIEMs rely on a mixture of signature-based and behavior-based detection for a more nuanced view of suspicious behavior in an environment that could lead to an attack.
How Blumira Creates Detection Rules
As incident detection engineers (IDEs), we’re hard at work keeping up with the latest exploits and attacker tactics, techniques and procedures (TTPs).
Here’s our process for developing detection rules as Incident Detection Engineers (IDEs) at Blumira.
We perform research for detection rules based on a few approaches, and balance all of those approaches to give customers the biggest bang for their buck across the board:
- Threat-based. We replicate observed threat actor attack paths and craft detections based on threat actor behavior — for example, using MimiKatz to steal credentials. We pull data from various threat intel reports to determine how threat actors operate.
- Post-compromise. In the rare instance that one of our customers gets compromised, we will perform post-compromise reviews on the data to learn any behavior that we may have missed, and create detections to fill in those gaps. We then make those detections available to all customers, enabling our IDEs to gather insight and identify patterns from a wide range of environments.
- Integrations. As we develop new integrations, we perform attacks against those specific integrations in the lab and combine that with research that’s been performed in the field.
- Emerging threats. When a new APT or vulnerability exploit gets released, we look for indicators of compromise (IOCs) that are related to that attack. Whenever attackers are actively exploiting a vulnerability or flaw in the wild, we immediately prioritize creating a detection for it.
2. Build Detections
Once the team emulates attacks in a lab environment, we identify and build detections based on the threat actors’ behavior. These detections are paired with contextual information around why you should be concerned that the finding has occurred.
Sometimes it could be a normal administrative activity, or it could be an attacker mimicking that activity to blend in. We also include links to defensive security configuration in the analysis. Along with the detection, we add custom in-depth incident response workflows, which provide step-by-step walkthroughs of what to investigate or which actions to take.
3. Test Again
The detection is tested again across customer datasets to remove common false positives, reducing noisy alerts to help customers focus on priority findings. Any time a tool or method of compromise changes or is discovered, we perform additional testing and the maturity of the detection grows.
4. Provide Stacked & Related Evidence
Blumira’s platform stacks similar alert data and includes the information in the already-triggered findings until the case is closed, helping to prevent alert fatigue. In addition to stacking evidence, if there are any related findings within the same time period on the same host or user, they are linked to provide additional context into the investigation.
5. Provide Ongoing Maintenance
Our belief is that SIEMs should help make our customers’ lives easier and not introduce unnecessary friction in their day.
Putting that belief in action, we actively maintain Blumira’s platform behind the scenes and add more detections on a rolling basis, as we believe it’s the responsibility of the product to support the user.
How Traditional SIEM Detections Work
Logs are generated on an endpoint, shipped over the network to some kind of collector and stored. A certain period of time elapses so that the data can be normalized and searched over.
This legacy detection system inspects for specific events over a designated window of time by design. The design flaw around this is that many detections do not need to be normalized, and should send a notification as soon as possible without delay. When 20, 30, 100 minutes go by, there is a critical gap between a malicious event occurring and customer notification.
This type of detection is brilliant for threat detections involving repeated events representing a single malicious behavior like password spraying. Password spraying isn’t a single point-in-time log event, it happens over a period of time, and so should the detection. It is less ideal for single moment-in-time threat detections such as Kerberoasting. Why wait a time period when you shouldn’t have to?
What Makes Blumira Different?
Blumira introduced a powerful detection system called Real-Time Detections. We built this technology in-house to provide you with real-time notifications for many of the product’s native threat detections.
Blumira’s platform was based on a scheduled detection system that could have variable time windows between 5-30 minutes. It was important to accelerate our time to detection so that organizations would get notified faster of threats to stop attacks sooner.
Real-Time detections with Blumira trigger an alert before the event logs are even stored to disk. In the parsing process we’ve created the ability to have point-in-time detections alert on known bad activity, giving you a head start and reducing your time to detection and time to remediation.
Our Real-Time Detection system will give you an added advantage in defending your organization’s network by dramatically accelerating the speed of the product’s detection notifications and, subsequently, your time to respond. This new system will execute logic to notify organizations in as little as 800 milliseconds.
Get Your Free Account
Blumira takes a different approach to SIEM detection rules and maintenance. We enable smaller teams to take the focus off of tasks like parsing and configuration, so they can focus on what matters most.
Experience Blumira for yourself with our free edition, which easily connects to your Microsoft 365 account. No credit card or sales conversation required to get started.