SI-2 on AWS

What this finds

An asset still reports an active finding for a CVE in CISA's Known Exploited Vulnerabilities catalogue, after the remediation date CISA published for that entry.

The requirement

The organization must identify, report, and correct information system flaws, and install security-relevant updates within an organization-defined time period of their release.

NIST SP 800-53 Rev. 5 — SI-2 (Flaw Remediation).

NIST requires flaws to be corrected within a period the organization defines. This pack does not attempt to judge every CVE. It narrows to CISA's Known Exploited Vulnerabilities catalogue — the subset with confirmed exploitation in the wild — and reports the ones still present after the remediation date CISA published. Which asset population is in scope, and whether a compensating control justifies an exception, remain organization-defined.

How this maps to the CISA performance goals

The Cross-Sector Cybersecurity Performance Goals are a voluntary baseline published by CISA — the U.S. federal agency for critical-infrastructure cybersecurity — written for organizations too small to employ security staff. This control speaks to:

• 2.B — Mitigate known vulnerabilities
  The goal is mitigating known vulnerabilities; the pack finds entries from CISA's own Known Exploited Vulnerabilities catalogue still active past the remediation date CISA published for them.
• 2.A — Manage organizational assets (partial — see note)
  Reaches the asset inventory only through whatever the vulnerability scanner already covers. An asset the scanner never sees produces no row here, so CM-8 rather than this pack is what evidences inventory completeness.

See the full coverage map, including the goals no query can answer →

Evidence this query needs

The query

Published as si-2-kev-overdue.aws.sql. Reads inspector_findings (Inspector export), kev_catalog (supplied). Requires: athena:StartQueryExecution; glue:GetTable; s3:GetObject.

Before this returns anything, inspector_findings (Inspector export) has to be reaching Amazon Athena over Amazon Inspector findings, and kev_catalog (supplied) has to be landed there. If not, the query reports nothing found — which looks exactly like nothing wrong. What has to be switched on first →

-- SI-2 -- known-exploited vulnerabilities still open past CISA's due date
-- Requires the kev_catalog contract registered as an Athena table.
SELECT
    f.resource_id,
    f.resource_type,
    upper(f.vulnerability_id) AS kev_cve,
    k.product                 AS kev_product,
    f.severity,
    f.first_observed_at,
    k.due_date,
    date_diff('day', k.due_date, current_date) AS days_overdue
FROM inspector_findings f
JOIN kev_catalog k
  ON upper(f.vulnerability_id) = upper(k.cve_id)
WHERE f.status = 'ACTIVE'
  -- overdue is the finding; an entry inside its window is not
  AND k.due_date < current_date
ORDER BY days_overdue DESC, f.resource_id ASC;

Open this pack on AWS to adjust the settings and download it →

The interactive version opens on AWS — the platform on this page — even if your environment profile does not list it.

Settings you decide

NIST states the objective and leaves these to your organization. The interactive version of this pack applies them to the query for you.

Grace period after the due date (days) (default 0)

Findings are only reported once this many days have passed beyond CISA's published remediation date.

Limit to specific assets (optional)

Paste resource identifiers, one per line.

Running it continuously

EventBridge Scheduler → Lambda → Security Hub

Schedule:         EventBridge Scheduler, rate(12 hours)
Compute:          Lambda (Python 3.12), 60s timeout
Step 1:           Start Athena query, poll for completion
Step 2:           Build an ASFF finding per returned row
Step 3:           BatchImportFindings -> AWS Security Hub
Severity label:   CRITICAL
Workflow status:  NEW
RelatedRequirements: NIST.800-53.r5 SI-2
Idempotency:      Id = sha256(resource_id + kev_cve)

The finding Id combines resource and CVE so the same overdue vulnerability on the same host stays one finding across runs, and closing it on one host does not close it everywhere.

Before you act on a result

• Is the KEV catalogue copy current? CISA adds entries continuously, and a stale file narrows this query silently.
• Has the vulnerability been mitigated in a way the scanner cannot see, such as removing the affected component from the network path?
• Is the asset in scope for patching at all, or is it a decommissioned system still reporting?
• Does a documented compensating control with an expiry cover this, and has that expiry passed?
• Is the scanner's coverage complete for this asset population, or would an unscanned host show nothing here regardless?

Common questions

How do I check for known-exploited vulnerability past its remediation date in AWS?

Run the published SQL (Athena) + Lambda query on this page against Amazon Athena over Amazon Inspector findings. It reads inspector_findings (Inspector export), kev_catalog (supplied) and reports: An asset still reports an active finding for a CVE in CISA's Known Exploited Vulnerabilities catalogue, after the remediation date CISA published for that entry.

What permissions are needed to run this AWS query?

athena:StartQueryExecution; glue:GetTable; s3:GetObject.

What evidence does SI-2 need that AWS cannot produce?

Known Exploited Vulnerabilities catalog (kev_catalog.csv). CISA's catalogue of vulnerabilities with confirmed exploitation in the wild, joined to your own vulnerability findings so SI-2 reports the ones that are actually being used against organizations rather than everything with a CVE. Download it from CISA rather than typing it: the authoritative CSV is published at https://www.cisa.gov/known-exploited-vulnerabilities-catalog and is a US federal work in the public domain. At minimum it must carry: cve_id, due_date.

Does a result from this query mean the control has failed?

A KEV entry past its due date does not establish that the vulnerability was exploited in your environment, or that exploitation is possible given your configuration. It establishes that a vulnerability confirmed to be exploited elsewhere is still reported as present after the date the federal catalogue set for fixing it. Scanner coverage gaps mean the absence of rows is not evidence of the absence of the condition.

The same control on other platforms

• SI-2 on Microsoft Sentinel — KQL
• SI-2 on Splunk — SPL
• All platforms for SI-2