This blog takes inspiration from the US Cybersecurity and Infrastructure Security Agency’s (CISA’s) guidance on implementing US government memorandum M-21-31. Our aim is to help private-sector companies secure their environments by improving visibility and optimizing the logs they’re collecting. We also explain the importance of building a defense in depth (DiD) detection strategy. Let’s dive in.

Behind the Memo: Logging Prioritized

Following the SolarWinds supply chain attacks in late 2020, US President Joe Biden created Executive Order 14028, aptly titled “Improving the Nation’s Cybersecurity.” One key point was “modernizing federal government cybersecurity” by increasing visibility into threats existing within US organizations’ environments. It became the Office of Management and Budget’s task to identify requirements that will improve agencies’ investigative and remediation capabilities, when it comes to cybersecurity incidents.

Then M-21-31 appeared. The memorandum provided agencies thorough guidance to mature their event-log management. It offered a model centralized on the ingestion of different log sources based on criticality levels.

After the memorandum came out, CISA engaged with the relevant agencies and ultimately released operational guidance on what to prioritize as they worked toward the Event Logging tier 1—which we’ll go into later. This topic was also discussed on our ShadowTalk podcast, in the episode titled “HTML Smuggling, CISA Guidance on Logging.”

Better Log Collection Equals Better Visibility

As the adage goes, you can’t detect what you can’t see. Having proper visibility into activities taking place within your environment is not only key to building valuable detection rules, it’s pivotal in investigating those detections.

When responding to an alert, an analyst’s initial goal is to determine the root cause of the detection. If the activity was deemed malicious, the analyst needs the right logs to investigate further and determine the full scope and impact of the activity. This often means looking at logs from many different parts of the network.

Improved visibility doesn’t just shrink the time needed to resolve an incident; it also saves future time by allowing the analyst to “tune” with confidence. Let’s say the root cause was determined to be benign but seems to be continuing: The analyst should tune that activity out of their detection rules resulting in less time spent investigating the same activity already deemed non-malicious.

How do analysts confidently judge whether something is a true positive detection? One way is by using their understanding of technology, combined with security research, to look for activity an attacker would perform before and after a detection occurs. This varies by detection, and it depends on where that detection falls in the cyber kill chain. (Read more about that in our blog, “Top 3 Reasons to Alert Based on the Cyber Kill Chain Model.”)

Understandably, not every company has the budget to ingest every individual log from every log source within their environment, which can be quite expensive. Companies with limitations should focus on the log sources that will provide the most value to their detection and response capabilities.

CISA’s operational guidance focuses on the following log sources first.

  • Identity, credential, and access management (ICAM)
  • Operating systems (Windows/Linux/Mac)
  • Network device infrastructure
  • Cloud environments

A few additional log sources that are valuable from a detection standpoint are:

  • Antivirus
  • Endpoint detection and response (EDR) tools
  • Email security

As CISA’s operational guidance points out, it’s important to ensure you’re collecting logs from many different parts of the network. We’ve seen a detection built that would have caught malicious activity but missed it because logs from a networking device or high-impact system weren’t ingested into the security information and event management (SIEM) solution, causing a visibility gap. As additional systems are onboarded, enable them to be logged into the SIEM for auditing and alert correlation.

The Extra Mile: Optimizing Log Sources

In addition to focusing on log sources that offer the highest value from a detection-and-response perspective, you can go a step further to optimize those log sources. Ensure logs are being parsed correctly, not providing duplicate coverage, and enabled to their fullest extent.

Parsing enables you to extract more detailed information from the logs already being ingested. This enables you to search, analyze, and deploy content more effectively because there are more fields to work off. If your logs aren’t being parsed correctly, you can’t develop high-fidelity detections because your detections can’t use the full scope of the log. And low-fidelity detections can bring on an acute case of alert fatigue, affecting the productivity of your security teams.

For example, let’s say your email security solution provides a confidence score for potential phishing emails being sent to your users. But that confidence score isn’t being parsed into a field. If your security solution is set to block emails with high-confidence phishing scores, you may want to develop your detections to also incorporate that confidence score, allowing you to dial down the noise of already-mitigated threats.

Another way to optimize your logging and help reduce costs is to ensure you’re not ingesting log sources that provide the same coverage, which ultimately wastes resources and leads to slower search times. One example of duplicate coverage is ingesting process creation events through Windows Security logs, Event ID 4688 while also ingesting Sysmon logs, Event ID 1. In that case, Sysmon would be preferred because it captures more points of data during the process creation event.

Logs are more valuable when optional fields are enabled. For example, if command line auditing is enabled for process creation events, analysts see not just the parent that created the child process, but the exact command that was run when the parent created the child process. This piece of context strengthens the confidence behind a decision that something’s being done—or not done—in an unusual manner.

Covering the Whole Kill Chain

A DiD strategy is an approach that involves layering multiple security controls for greater protection against cyber threats. Threat actors will have to traverse through systems and parts of the network as they progress through the cyber kill chain. As they make that journey, their actions will be recorded by various log sources within your environment. That’s why developing detection rules for many different log sources across the kill chain ups the probability of detecting and responding to attacks.

To help highlight the importance of DiD, let’s talk through a scenario. Maria’s browsing the internet at work and visits a recently compromised website that hasn’t yet been identified as malicious; it’s not yet blocked by her proxy. She’s quickly coerced into downloading and executing malware: an information stealer (infostealer).

Her company’s environment does have detection rules in place for any attempts to download a file from one of several suspicious proxy categories. But in this case, they’ve not triggered—because the website’s reputation has yet to be deemed malicious.

Maria innocently executes the infostealer, triggering an alert as her browser’s credentials are dumped. During the investigation into the alert, the analyst identifies and removes the process that enabled the credential dumping. Because they have visibility into Maria’s network traffic, they can also identify the domain the file was downloaded from and put a block in place.

Using ReliaQuest GreyMatter for Defense in Depth

Had this environment not built detection rules for multiple use cases across multiple log sources, Maria’s folly may have been missed, her credentials unknowingly compromised, and the website left free to beckon more users toward compromise. Maria could be any one of your employees, and she makes an excellent case for building a strong DiD strategy to aid in the defense of your network.

Let ReliaQuest GreyMatter help you build a DiD detection strategy. Our security operations platform is technology agnostic and designed to help security teams increase visibility, reduce complexity, and manage risk across all of their security tools. With an expansive content library of alerts mapped to the cyber kill chain, it can help security teams defend against and respond to a wide range of threats, making it a versatile solution for businesses of all types and sizes.

Request a Demo >