Track known exploited vulnerabilities and notifications update supporting BOD 22-01

[chelsgr]

Summary

BOD 22-01 requires agencies to remediate known-exploitable vulnerabilities according to the timelines set forth in the CISA-managed vulnerability catalog (https://www.cisa.gov/known-exploited-vulnerabilities-catalog). CISA intends to send notifications to Federal stakeholders, as well as non-Federal with tailored messaging within 24 hours of detection.

Notification Modifications

Notification language changes:

Title change:

• from "New Critical/High Vulnerabilities Detected"
• to "Urgent Vulnerabilities Detected"

For Feds:

• "Cyber Hygiene scans of your host(s) conducted in the past day have detected new vulnerabilities requiring immediate attention. These vulnerabilities may be critical or high in severity and/or known to be exploitable and present an unacceptable risk to the federal enterprise."
• "As part of BOD 22-01, certain “known exploited” findings need to be remediated within two weeks."
• "As part of BOD 19-02, critical-severity findings need to be remediated within 15 days and high-severity findings remediated within 30 days."

For Non-Feds:

• "Cyber Hygiene scans of your host(s) conducted in the past day have detected new vulnerabilities requiring urgent attention. These vulnerabilities may be critical or high in severity and/or known to be exploitable."

• "CISA recommends remediating known exploited vulnerabilities within two weeks, and otherwise remediating critical findings within 15 days and high findings within 30 days."

Vulnerabilities table updates:

Add a new column to the findings.csv attached within the ad-hoc alert to denote “known exploited” vulnerabilities based on the key found in the tickets collection. Mock ups (“NonFed-KEV-in-Alert.pdf” and “Fed-KEV-in-Alert.pdf”) are available on LGX-421 ticket.

Acceptance criteria

Required reporting updates:

• Dependency: modify CyHy database for "known exploited" vulnerabilities.
• Add a new column to the findings.csv to denote “known exploited”.
• Make the requested modifications to the existing notifications language and known vulnerabilities table.
• Send out ad-hoc alerts within 24 hours of the initial detection of these vulnerabilities

[felddy]

I have a few points that need clarification:

1. How should the system handle the JSON file being inaccessible? e.g., network down, expired certs, page moved, permission errors, dns failures, etc...
2. Should the system validate the JSON file against the published schema?
3. Should the schema be loaded on each run, or does the system assume it will not change?
4. If the schema changes or is inaccessible how is this handled?
5. Who is notified of these failures cases? How?
6. Are the any specific recovery steps needed if there is a failure?
7. How does this catalog relate to the temporal CVSS scores (which include an "exploitability" scale) that are already present in CyHy? See: https://www.first.org/cvss/specification-document#Temporal-Metrics
8. Should the catalog data age out over time or is this an infinitely growing dataset?
9. Will entries be removed from the catalog over time? Does this system need to take any actions when an entry is removed?
10. Upon downloading the catalog should it wholesale replace any stored version in the system or should it be used to generate a differential?

[climber-girl]

@felddy

Unfortunately, I'm not sure we have great answers for you for most of these, and I am not sure which group would be the responsible team for getting you answers you are looking for that aren't addressed below.

In terms of functionality/ease of use, I envision that the best way to capture this in the CyHy database (at least in my mind... you all may have better ideas though) would be to create a "known exploitable" key in the database's cve collection, and I'd use the csv version of the catalog (not sure if that really makes much difference one format or the other).

• If a CVE is found in the catalog, then "known exploitable" in the DB should be set to "true."
• I don't know that the schema necessarily matters since we don't need to look up other info in that catalog associated with the CVE at this time.

I do not believe any of the CVEs in the catalog will be removed from the catalog (e.g. you can't undo the exploitability of a particular CVE, but I suppose there is the possibility of a human-made mistake like a typo and they remove/correct it). The list will really only grow.

• I envision the daily check could simply validate whether the CVE is on list, and if so, ensure the DB says "true".
• It would probably be good to also ensure that any CVEs in the DB currently reading "known exploitable" are still on the catalog list for the rare case a typo may have been made in the catalog and was subsequently corrected.. replacement of the value rather than a differential is totally fine.
• If the catalog is not accessible, skip the check for that day and just use what is already in the DB.

I don't know how the catalog relates to the temporal scores that get brought in from raw Nessus data captured in the vuln_scan collection. There could be overlap, and there may be some differences. Temporal scores from Nessus are not reported to stakeholders.

• The "known exploitable" flag/alerts should only be based off of the CISA known exploitable vulnerabilities catalog at this time.

Hopefully this helps!

[chelsgr]

Note: there is a request for a change to the report language as well: cisagov/cyhy-reports#68

[climber-girl]

Thanks for finding that and connecting the dots @chelsgr! That report language change can definitely be worked as part of this effort, but that is lowest priority for the BOD 22-01 stuff in my mind.

• Only concern with the language is to change "customers" to "stakeholders."
• If we do want to put that in as part of this effort, I think that message would fit in the VS weekly reports between Section 2 (Report Card) and Section 3 (Emergency Directive 19-01 for Feds; Executive Summary for non-Feds).

[chelsgr]

Created a separate epic issue to track the multiple pieces of the BOD 22-01 adjustments.

[chelsgr]

The summary and requirements for this ticket have been modified to reflect the latest information.

[felddy]

Logic when determining if a duplicate notification would be sent:

• If the vuln was already in a notification for popping as a new critical/high, and then later is added to the KEV catalog, re-alert once.
• If a vuln was already in a notification for having been listed on the KEV catalog but was a medium/low and then has its CVSS base score change in a way that makes it a high/critical, do not re-alert.

Currently notifications are only generated for new tickets. The system does not keep state of previously sent notifications. Therefore the "re-alert" logic cannot be implemented without a substantial rewrite of the notification generation subsystem.

https://github.com/cisagov/cyhy-core/blob/16d6b050a14e017b332f9e428db9df1e72eb65fa/cyhy/db/ticket_manager.py#L247-L249

        # Create notifications for Highs (3) or Criticals (4)
        if new_ticket["details"]["severity"] > 2:
            self.__create_notification(new_ticket)

[dav3r]

@chelsgr and @climber-girl - is this acceptance criteria correct?

Add a new column to the recently-detected.csv to denote “known exploited”.

The "recently-detected.csv" is part of the weekly reports, not the daily notifications, and should therefore be removed from this issue.

[chelsgr]

@dav3r, that was a mix up during requirements gathering/updates. It's noted in the comments for CyHy's report changes ticket and I've removed it from the acceptance criteria here.

[felddy]

Stop saying known exploitable:

There is a big (and probably legal) difference between known exploitable and known exploited. If we say known exploitable == false this is read as, "This is not exploitable." Please confirm this distinction is correct and that the term exploitable should not exist in any of our report templates.

[chelsgr]

I've provided this feedback on the business requirements ticket. I will provide updates once we receive confirmation from CyHy.

[chelsgr]

Great catch! We've received confirmation from CyHy the language should be "known exploited" in all instances.

[chelsgr]

Referencing @felddy's comment on notification generation for new tickets, CyHy provided this feedback: "It is extremely important to notify stakeholders of changes in vuln status that are 'urgent' --- whether that is low/med to high/critical or any non-KEV status to KEV" and requested we "Figure out the re-alerting code as part of the end of this effort".

[chelsgr]

Given the discussion above around complications in changing the notification generation functionality, the Leadership and CyHy team are now requesting that change be implemented at the end of this effort. I've created a ticket to track that request separately given the difference in prioritization: #36