Where a known vulnerability cannot be patched or no security patch exists, agencies should put in place: (1) controls that resolve the vulnerability, for example turning off the affected functionality through product configuration, asking the vendor for another way to manage it, installing a product version free of the vulnerability, moving to a different product whose vendor is more responsive, or engaging a software developer to fix the software; (2) controls that stop exploitation, including sanitising external input (where an input triggers the exploit), filtering or verifying software output (where the exploit concerns information disclosure), adding access controls that block access to the vulnerability, or configuring firewall rules to restrict access to the vulnerable software; (3) controls that contain an exploit, including firewall rules restricting the outbound traffic likely during exploitation, mandatory access control that blocks exploit code from executing, file system permissions that stop exploit code being written to disk, and allow and deny listing to block code execution; (4) controls that detect attacks, including deploying an IDS, monitoring logging alerts, or other suitable mechanisms for detecting exploits of the known vulnerability; and (5) controls that prevent attacks, including deploying an IPS or HIPS, or other suitable mechanisms that divert exploit attempts against that vulnerability (for example Null routers and honey pots).
This control maps to 1 controls across 1 other frameworks. If you already hold one of them, the evidence you collected for it is the starting point here rather than new work.
Every mapping shown was judged rather than inferred from wording similarity, and the ones that failed review are published too. See the coverage reports and what was rejected.
The graph holds this control, the 1 it maps to, and the evidence behind each claim, over MCP and REST.