Weaponizing paranoia: developing a threat detection strategy

Hey, am I safe from <insert today’s threat>?

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.

Where do I start?

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.

Learn policies and procedures

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:

• Use of SaaS, PaaS, IaaS, or other hosted services
  • This includes understanding vendor support policies
• DevOps processes and procedures
• New account provisioning process
• Third-party contractor access provisioning process
• SSO integration with on-prem authentication infrastructure, or lack thereof
  • Additionally, services that are not integrated with the company's SSO platform and how they are accessed
• Helpdesk policies and procedures
• Existence of shared account names and IP space across different domains
• VPN topology, including which services require being connected to the corporate VPN to access and which don't
• Network segmentation, or lack thereof, as it relates to user role
• Which devices on the network are integral to the company’s cash flow

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.

What am I going to do with all that information?

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.

That’s a lot to handle

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.

Sounds great on paper, but we’re not that mature

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:

• Maintain inventories of users with roles that would change their normal behavior, such as helpdesk administrator accounts that will frequently reset MFA devices or passwords for other users
• Audit data sources for adherence to the vendor's data normalization schemas
• Disable rules that don't make sense for your environment to limit noise
• Add logic to default rules and searches to account for environmental nuance
• Develop a testing framework to ensure that malicious activity on the network is detected and adjust rules accordingly

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.

How do I track progress?

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.

Tie it all together for me

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.