NIST Cybersecurity Framework 2.0: Detect
authors: mark keppler, steve foretCybersecurity Frameworks Series, part 7
Today, we will take a deep dive into the DETECT function. We've all heard cybersecurity experts warn that it’s not a matter of if, but when you get breached. We may hate that defeatist attitude, but it’s hard to argue with.
Conventional wisdom then suggests that organizations must have a solid Incident Response Plan (and they should) to address the inevitable (but the RESPOND function is for anther blog). To state the obvious, your organization’s response plans won’t work if you don’t know you’re being attacked, and they will work better the earlier you know something is going on.
The goal of the DETECT function is effective and timely discovery and analysis of anomalies, indicators of compromise, and other potentially adverse events that may indicate that unauthorized activities are occurring such as cybersecurity attacks.
Sub-functions of DETECT include:
Continuous Monitoring (DE.CM):
Assets are monitored to identify anomalies, indicators of compromise, and other potentially adverse events.
The Continuous Monitoring category includes the monitoring of network and network services, personnel activity, external service providers, system (physical and virtual) hardware and software runtime events and even the physical environment for potentially adverse events.
DE.CM-01: Networks and network services are monitored to find potentially adverse events
DE.CM-02: The physical environment is monitored to find potentially adverse events.
DE.CM-03: Personnel activity and technology usage are monitored to find potentially adverse events.
DE.CM-06: External service provider activities and services are monitored to find potentially adverse events.
DE.CM-09: Computing hardware and software, runtime environments, and their data are monitored to find potentially adverse events.
Many organizations have some of the basics mentioned above covered when it comes to detection. Nearly all could do be doing more. So, why don’t they? There’s a cost and complexity associated with doing everything listed above. Organizations often implement tools that provide broad (if not all encompassing) coverage. That broad coverage often is provided by an EndPoint Detection and Response (EDR), Cloud Access Security Broker (CASB), and/or Network Detection and Response (NDR) solution. EDR on endpoints is something we recommend, but there definitely are times when organizations place too much reliance on EDRs. CASB can create choke points for network analysis and DLP events as part of improved security visibility.
Adverse Event Analysis (DE.AE):
Anomalies, indicators of compromise, and other potentially adverse events are analyzed to characterize the events and detect cybersecurity incidents.
The Adverse Event Analysis category goes beyond simple security log review to facilitate more efficient and effective interpretation of events considering contextual information and multiple event sources.
DE.AE-02: Potentially adverse events are analyzed to better understand associated activities.
DE.AE-03: Information is correlated from multiple sources.
DE.AE-04: The estimated impact and scope of adverse events are understood.
DE.AE-06: Information on adverse events is provided to authorized staff and tools.
DE.AE-07: Cyber threat intelligence and other contextual information are integrated into the analysis.
DE.AE-08: Incidents are declared when adverse events meet the defined incident criteria.
We have seen an increase recently of companies improving detection by establishing a security operations center (SOC) using a managed security service provider (MSSP). Establishing an internal SOC isn’t practical for many, if not most, organizations.
Gaps we typically see are at the application (web, API, HMC, etc) and network level. Though most organizations have intrusion detection from network firewalls, firewall, router, and IDS logs are not always correlated with other events sources in a SIEM. In addition, detection capabilities are not “set it and forget it”. They require periodic health checks and tuning. From the application side, most organizations are not organized and prepared to create the practical and ideal set of application et al event logs.
That concludes our deep dive into the DETECT function. We will take a deep dive into the RESPOND function next. In the meantime, if you are not sure or would like to discuss, please feel free to reach out to SEVN-X. Our goal is to help you Achieve Better Cybersecurity and we’re happy to help!
Previous Blog:
Cybersecurity Frameworks Series part 6, NIST Cybersecurity Framework 2.0: Protect
Next Blog:
Cybersecurity Framework Series part 8, NIST Cybersecurity Framework 2.0: Respond