NIST CSF 2.0 DE.CM-09: Monitor Hardware, Software and Runtime

DE.CM-09 says computing hardware and software, runtime environments, and their data are monitored to find potentially adverse events. This is the endpoint and workload layer: laptops, servers, containers, applications and the data they touch. If something runs on your estate that should not, or a configuration drifts, you want to know quickly. CSF is voluntary and there is no certification for it.

What good looks like

Every laptop and server reports its health: patch level, malware status, disk encryption and installed software. Production workloads emit logs and alerts. Configurations are compared against a baseline and drift is flagged. Email, web and file sharing, the common attack paths, are watched for malware, phishing and data leaving the company. Authentication attempts are watched for credential attacks.

How to implement it

• Deploy an endpoint agent or the management tool you already own to all laptops and servers.
• Define a baseline per system type, such as hardened images for servers and a standard laptop profile.
• Alert on drift: new admin users, disabled security tools, changed firewall rules.
• Watch authentication logs for password spraying and reuse of leaked credentials.
• Inspect email and file sharing for malware and unusual bulk sharing.
• Monitor software, not only machines. New vulnerabilities appear in code you already shipped, so rescan dependencies on a schedule. The free in browser scan at https://gold.safeguard.sh/scan is a quick first look, and reachability analysis helps you focus on flaws your code actually calls.
• Quarantine noncompliant endpoints until they are patched, where your tooling allows it.

A worked example

Picture a 40 person software company. It has 45 laptops, a Kubernetes cluster and a handful of SaaS tools. The security lead starts with coverage, not detection. A device inventory shows 45 laptops but the endpoint agent reports from 38. Seven are unmanaged. Closing that gap is worth more than any new alert rule.

Next she writes a baseline for the production nodes: approved base image, no interactive logins, outbound traffic only to a short list of destinations. A weekly drift report compares nodes to that baseline. In week two it flags a node with a new local user. The cause is a contractor debugging session that was never cleaned up. The user is removed, the contractor access path is fixed, and the ticket becomes evidence.

On the software side, the team rescans its dependencies every night. A new advisory lands for a library already in production. Because the scan history shows exactly which services use it, and reachability analysis shows which of them call the vulnerable function, the fix goes to the right team the same day.

Metrics that keep you honest

• Percentage of laptops and servers reporting to the agent.
• Median days from patch release to patch installed.
• Number of drift alerts opened and closed each month.
• Hours from a new advisory to a triage decision.

Review these monthly. A flat line with no alerts is not proof of safety. It can mean the sensors are off.

Evidence to collect

• Device inventory with agent coverage percentage.
• Baseline documents and a drift report.
• Alert samples with the resulting tickets.
• Patch compliance reports.
• A dependency scan history.

Try it yourself

Click through it at your own pace, or open it full screen.

Common gaps

Agents on laptops but not on servers or containers. Baselines never written, so drift has no reference. Alerts go to a shared mailbox nobody reads. Software monitoring stops at deploy time.

Quick check

Sources

• NIST Cybersecurity Framework (CSF) 2.0, NIST CSWP 29: https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf
• NIST CSF 2.0 Reference Tool and implementation examples: https://csrc.nist.gov/Projects/Cybersecurity-Framework/Filters#/csf/filters