SI-4 System monitoring
What the standard requires
a. Monitor the system to detect: 1. Attacks and indicators of potential attacks in accordance with the following monitoring objectives: [monitoring objectives] ; and 2. Unauthorized local, network, and remote connections; b. Identify unauthorized use of the system through the following techniques and methods: [techniques and methods]; c. Invoke internal monitoring capabilities or deploy monitoring devices: 1. Strategically within the system to collect organization-determined essential information; and 2. At ad hoc locations within the system to track specific types of transactions of interest to the organization; d. Analyze detected events and anomalies; e. Adjust the level of system monitoring activity when there is a change in risk to organizational operations and assets, individuals, other organizations, or the Nation; f. Obtain legal opinion regarding system monitoring activities; and g. Provide [system monitoring information] to [personnel or roles] [as needed | [frequency] ].
Quoted verbatim from NIST SP 800-53 Rev 5 (OSCAL catalog), which is in the public domain.
Maps to 1 control in 1 other framework
| Framework | Control |
|---|---|
| NIST Cybersecurity Framework (1.1, legacy) | DE.CM-1 Network monitored for cybersecurity events |
Mappings are CMDash’s own, seeded with the product and shown on both frameworks they connect. In the product they mean evidence you attach here also counts against the controls listed above.
Integrations that carry evidence for this family
These connectors produce data relevant to FedRAMP Moderate’s System & Information Integrity family, which is the granularity CMDash publishes — there is no pre-built per-control mapping, and claiming one would be inventing it. You decide which evidence answers which control.
In CMDash this control is a row with an owner, a status, uploaded evidence kept with its full history, and an export an assessor can read.