Home/Compliance
nist-800-53

NIST 800-53. Security Controls

10 controls · cross-mapped to ATT&CK techniques
Translate between regulatory language and what attackers actually do. Each control maps to MITRE ATT&CK techniques; open a control to see those techniques and whether we hold detection coverage for them.
1246
Total controls
0%
Detection coverage
0
Covered controls
1246
Coverage gaps
▤ Export audit (CSV) Coverage report Self-assessment Show gaps only
▶ Check your own detection coverage

Paste the ATT&CK technique IDs you have Sigma/YARA rules for (one per line, e.g. T1059, T1190). The controls below will update to show YOUR coverage instead of ours.

Red team insight A nist-800-53 compliant org should have detection for the green-tagged techniques below. Controls showing no technique coverage are likely blind spots. Use gaps view to enumerate unmonitored attack paths.

Controls

10 shown of 10
Require the developer of the system, system component, or system service to produce a design specification and security and privacy architecture that: Is consistent with the organization’s security and privacy architecture that is an integral part the organization’s enterprise architecture; Accurately and completely describes the required security and privacy functionality, and the allocation of controls among physical and logical components; and Expresses how individual security and privacy functions, mechanisms, and services work together to provide required security and privacy capabilities and a unified approach to protection.
family SA framework nist-800-53
Require the developer of the system, system component, or system service to: Produce, as an integral part of the development process, a formal policy model describing the {{ insert: param, sa-17.1_prm_1 }} to be enforced; and Prove that the formal policy model is internally consistent and sufficient to enforce the defined elements of the organizational security and privacy policy when implemented.
family SA framework nist-800-53
Require the developer of the system, system component, or system service to: Define security-relevant hardware, software, and firmware; and Provide a rationale that the definition for security-relevant hardware, software, and firmware is complete.
family SA framework nist-800-53
Require the developer of the system, system component, or system service to: Produce, as an integral part of the development process, a formal top-level specification that specifies the interfaces to security-relevant hardware, software, and firmware in terms of exceptions, error messages, and effects; Show via proof to the extent feasible with additional informal demonstration as necessary, that the formal top-level specification is consistent with the formal policy model; Show via informal demonstration, that the formal top-level specification completely covers the interfaces to security-relevant hardware, software, and firmware; Show that the formal top-level specification is an accurate description of the implemented security-relevant hardware, software, and firmware; and Describe the security-relevant hardware, software, and firmware mechanisms not addressed in the formal top-level specification but strictly internal to the security-relevant hardware, software, and firmware.
family SA framework nist-800-53
Require the developer of the system, system component, or system service to: Produce, as an integral part of the development process, an informal descriptive top-level specification that specifies the interfaces to security-relevant hardware, software, and firmware in terms of exceptions, error messages, and effects; Show via {{ insert: param, sa-17.04_odp }} that the descriptive top-level specification is consistent with the formal policy model; Show via informal demonstration, that the descriptive top-level specification completely covers the interfaces to security-relevant hardware, software, and firmware; Show that the descriptive top-level specification is an accurate description of the interfaces to security-relevant hardware, software, and firmware; and Describe the security-relevant hardware, software, and firmware mechanisms not addressed in the descriptive top-level specification but strictly internal to the security-relevant hardware, software, and firmware.
family SA framework nist-800-53
Require the developer of the system, system component, or system service to: Design and structure the security-relevant hardware, software, and firmware to use a complete, conceptually simple protection mechanism with precisely defined semantics; and Internally structure the security-relevant hardware, software, and firmware with specific regard for this mechanism.
family SA framework nist-800-53
Require the developer of the system, system component, or system service to structure security-relevant hardware, software, and firmware to facilitate testing.
family SA framework nist-800-53
Require the developer of the system, system component, or system service to structure security-relevant hardware, software, and firmware to facilitate controlling access with least privilege.
family SA framework nist-800-53
Design {{ insert: param, sa-17.08_odp.01 }} with coordinated behavior to implement the following capabilities: {{ insert: param, sa-17.08_odp.02 }}.
family SA framework nist-800-53
Use different designs for {{ insert: param, sa-17.09_odp }} to satisfy a common set of requirements or to provide equivalent functionality.
family SA framework nist-800-53
Showing 1-10 of 10
Vulnerabilities
CISA KEV catalog
CWE weaknesses
CAPEC attack patterns
Package vulnerabilities
Threat intelligence
Threat actors
Tools & malware
ATT&CK techniques
IOCs
Detection & defense
Sigma rules
YARA rules
Atomic Red Team tests
D3FEND countermeasures
Compliance
NIST 800-53
ISO 27001:2022
SOC 2 TSC
PCI-DSS v4.0
CIS Controls v8.1
About
All capabilities
Live statistics
Data sources
Privacy policy
Terms of service
threatengine.sh  ·  Open-source threat intelligence platform  ·  100+ authoritative sources  ·  Every fact traces to its origin