Get the reportMore
Complete visibility for DevSecOps
Reduce downtime and move from reactive to proactive monitoring.
Nowadays, it’s mostly a foregone conclusion that companies need a security program and centralized log aggregation and correlation platform. Unfortunately, the conversation all too often turns toward tactics for data collection and detection of specific threat actors or common vulnerabilities and exposures (CVEs). While those discussions are important and the security community is at its most effective when we share information and detection logic, every business and network is unique and has a unique threat model. With that in mind, let’s explore what goes into formulating a threat detection strategy.
Broadly speaking, defenders should develop a detection strategy that seeks to identify the procedural operations of your organization and understand how anomalies manifest. That means understanding the business inside and out with the goal of cataloging what is "normal" for the network. To keep that from being a nebulous task, it helps to break things down into approachable steps.
Everybody’s favorite pastime. Hear me out, though: you can collect this info methodically over time, and every last bit is useful. This also serves as a helpful way to challenge your assumptions about what is supposed to be happening in day-to-day operations.
When it comes to mapping out what your company's operational footprint looks like, consider the following areas:
Should be easy, right? Don’t be afraid to prioritize that list, add items, or remove items. The goal is forward progress at whatever pace you and your organization can manage.
The first thing to recognize is that you aren’t going to boil this ocean in a day (if any of you groaned at “boil the ocean,” just know that I could have mentioned Rome). Fortunately, every piece of information you collect is going to help shape your understanding of what “normal” should look like and how to explain deviations.
Let’s walk through an approach that focuses on broad “should” statements relying on the intended function of environment components. Suppose your organization maintains a DMZ for hosting internet-facing web applications, mail or file transfer servers. In that case, you might focus on understanding what an attack would look like if one of these servers was compromised and operating beyond standard tasks for that type of server.
A “what if” flow chart for a DMZ web server
You can probably see how this process would apply to everything from access management to endpoint monitoring. Developing an iterative approach allows you to steadily progress toward monitoring the most likely and most impactful threats against your organization. The more information you have about your environment, the more informed your decisions will be around what makes a viable detection rule.
While each of the above points—and many others depending on your specific circumstances—could be a blog post all on their own, the primary objective here is understanding the "machine behind the machine" regarding how your organization operates.
Once you have a strong understanding of that system, your detection strategy can evolve from the standard "this is universally bad" correlation rules to start looking for indicators that deviate from the standard procedural operations of your unique network.
This is where threat detection becomes nuanced: this network is yours to defend, and external actors are unwanted guests that don't know what normal looks like. Having a strong relationship with your administration teams goes a long way. Those relationships will help you understand procedures and request changes to use and abuse against attackers.
So what if you don't currently have the means to track down that information, or you want to implement the basics and cover the "universally bad" before diving into highly customized threat detection? Fortunately, virtually every SIEM product on the market comes with a suite of default content that ranges across myriad data types, from authentication to endpoint to networking and beyond. For those who are working with a custom-built ELK stack or similar setup that is not developed by a third-party vendor, many vendors publish freely available detection logic.
The most important thing to remember when leveraging this default content is that your vendor is creating detection logic to work with as many wildly different environments as possible, but that logic may not immediately work well in yours. There could be false positives or data sources that don't work with the default configuration. That’s by design, and it doesn’t mean you shouldn’t discount the core logic of those rules.
Here are some ways to fine-tune default content to work for you:
As you start collecting and applying this information, you should find that your SIEM alerting is more refined and that a clearer picture of what “normal” looks like begins to form.
Measuring detection capability against an established framework is a common way to begin tracking progress over time for a security program. Perhaps the most prolific framework in today’s landscape is MITRE ATT&CK. For those not familiar, this framework breaks down potential attack surfaces into tactics, the immediate goal of the observed activity, and techniques, the mechanism by which the tactic is achieved. The talented folks at MITRE have gone as far as to build the ATT&CK Navigator tool to help practitioners quickly assess their overall coverage within the framework. If you haven’t caught on by now, here at Sumo Logic, we integrate heavily with the ATT&CK framework and strive to map each of our out-of-the-box detection rules to applicable tactics and techniques.
All that said, there are a few caveats to leveraging any given framework. The first is that while you may have coverage for a given tactic or technique, you may not have coverage for all the possible ways to abuse a given technique. You can reduce the likelihood that your detection program is simply providing a false sense of security by applying the principles of defense-in-depth to a sort of detection-in-depth approach with regular testing, where no one sensor, tactic, technique, etc. is preferred to the exclusion of others.
The second, more salient caveat is that no global framework will ever sufficiently cover the distinct needs of a complex enterprise environment. That doesn’t mean you should eschew MITRE ATT&CK or any other standard framework entirely. Rather, once the basics are covered, you should be looking to identify the nuances of your network that require special attention and modifying an existing framework or creating your own to accommodate.
You may have noticed that many of the points in this post are also ways to help mature your security program toward achieving the central goal of identifying and leveraging your company's processes and procedures to build comprehensive threat detection. That's no accident—threat detection, much like security in general, is an iterative process with no defined endpoint. The best strategy identifies the logistics of your organization, defines reasonable parameters for what is normal, and focuses on consistent, gradual improvement over time.
How Sumo Logic can help
Sumo Logic helps you modernize your security operations and mitigate the overload of tools by allowing you to use a single platform that analyzes and correlates threats across your on-premises, cloud and multi-cloud environments. Serving your many security requirements, the platform provides comprehensive capabilities to meet your needs for log management, metrics, SIEM, alert triage, detection and incident response using data sources such as endpoint detection and response (EDR), network detection and response (NDR), web gateways, firewalls and threat intelligence.
To see how we can help you reach your security goals, contact us today.
Reduce downtime and move from reactive to proactive monitoring.
Build, run, and secure modern applications and cloud infrastructures.Start free trial