SI-2 Flaw Remediation (L) (M) (H)

NIST 800-53 (r4) Control:

The organization:

a. Identifies, reports, and corrects information system flaws;

b. Tests software and firmware updates related to flaw remediation for effectiveness and potential side effects before installation;

c. Installs security-relevant software and firmware updates within [FedRAMP Assignment: (L)(M)(H) thirty (30) days of release of updates] of the release of the updates; and

d. Incorporates flaw remediation into the organizational configuration management process.

NIST 800-53 (r4) Supplemental Guidance:

Organizations identify information systems affected by announced software flaws including potential vulnerabilities resulting from those flaws, and report this information to designated organizational personnel with information security responsibilities. Security-relevant software updates include, for example, patches, service packs, hot fixes, and anti-virus signatures. Organizations also address flaws discovered during security assessments, continuous monitoring, incident response activities, and system error handling. Organizations take advantage of available resources such as the Common Weakness Enumeration (CWE) or Common Vulnerabilities and Exposures (CVE) databases in remediating flaws discovered in organizational information systems. By incorporating flaw remediation into ongoing configuration management processes, required/anticipated remediation actions can be tracked and verified. Flaw remediation actions that can be tracked and verified include, for example, determining whether organizations follow US-CERT guidance and Information Assurance Vulnerability Alerts. Organization-defined time periods for updating security-relevant software and firmware may vary based on a variety of factors including, for example, the security category of the information system or the criticality of the update (i.e., severity of the vulnerability related to the discovered flaw). Some types of flaw remediation may require more testing than other types. Organizations determine the degree and type of testing needed for the specific type of flaw remediation activity under consideration and also the types of changes that are to be configuration-managed. In some situations, organizations may determine that the testing of software and/or firmware updates is not necessary or practical, for example, when implementing simple anti-virus signature updates. Organizations may also consider in testing decisions, whether security-relevant software or firmware updates are obtained from authorized sources with appropriate digital signatures. Related controls: CA-2, CA-7, CM-3, CM-5, CM-8, MA-2, IR-4, RA-5, SA-10, SA-11, SI-11.

NIST 800-53 (r5) Discussion:

The need to remediate system flaws applies to all types of software and firmware. Organizations identify systems affected by software flaws, including potential vulnerabilities resulting from those flaws, and report this information to designated organizational personnel with information security and privacy responsibilities. Security-relevant updates include patches, service packs, and malicious code signatures. Organizations also address flaws discovered during assessments, continuous monitoring, incident response activities, and system error handling. By incorporating flaw remediation into configuration management processes, required remediation actions can be tracked and verified.

Organization-defined time periods for updating security-relevant software and firmware may vary based on a variety of risk factors, including the security category of the system, the criticality of the update (i.e., severity of the vulnerability related to the discovered flaw), the organizational risk tolerance, the mission supported by the system, or the threat environment. Some types of flaw remediation may require more testing than other types. Organizations determine the type of testing needed for the specific type of flaw remediation activity under consideration and the types of changes that are to be configuration-managed. In some situations, organizations may determine that the testing of software or firmware updates is not necessary or practical, such as when implementing simple malicious code signature updates. In testing decisions, organizations consider whether security-relevant software or firmware updates are obtained from authorized sources with appropriate digital signatures.

38North Guidance:

Meets Minimum Requirement:

• Part a.

• Identify system flaws from various sources to include but not limited to:

  • 1. Automated vulnerability scans in accordance with RA-5;

    2. Security alerts, advisories, and directives in accordance with SI-5. May include security updates from vendors whose products are utilized within the information system.

• All vulnerability scans are performed in accordance with RA-5 (a) timeframes. CSP reviews vulnerability scan results and reports to identify newly identified vulnerabilities, action items, and remediated vulnerabilities that were identified on prior scans.

• Vulnerability findings are remediated in accordance with RA-5 (d) timeframes. If vulnerabilities are not corrected within RA-5 (d) timeframes, they must be imported into the POA&M to facilitate correlation of vulnerabilities to assess true impact and ensure prompt remediation. Refer to CA-5 for more information.

• Subscribe to all relevant vendor releases and identify, report, and correct legitimate system flaws accordingly.

• Part b. Test software and firmware updates related to flaw remediation for effectiveness and potential side effects before installation. All updates must be tested in accordance with the change management process described in CM-3. All changes must be tested in a separate environment prior to implementation in the production system in accordance with CM-3 (2). All testing performed is done to ensure security safeguards are unaffected and functionality of the system is not broken. The testing is meant to ensure the system continues to operate in a secure, optimal, and resilient manner.

• Part c. Install software and firmware updates to remediate discovered exploits as soon as possible, but within RA-5 (d) timeframes from the detection of the updates. Any vendor dependencies are tracked in accordance with CA-5 [Plan of Action and Milestones (POA&M)]. Security updates that have been released directly from the vendor must be tested and installed within thirty (30) days of release of the update. Example: Microsoft Patch Tuesday security updates must be tested and installed within thirty (30) days of release.

  • If a system has a mobile application component to it, which is downloadable through various app stores, it is required to display a message to the app user when the app is launched and force them to download the latest version of the app from the app store within 30 days of it being available for download. They should not be allowed to continue to use the old app (in essence ignoring the update).

• Part d. Incorporate flaw remediation into its configuration management process. Track updates to its platform and applications in accordance with the change management process described in CM-3.

Best Practice:

• If exemptions to flaw remediation are desired, document them clearly. Examples could be application of server or dependency patches, which may be excluded from test requirements if the organization accepts the risk of immediate application of vendor patches.

• If CSP can't patch all SI-2 patches within 30 days, would it be ok for them to prioritize based on severity (H, M, L)? Can CSP start remediation timeline based on "detection" through RA-5 vulnerability scans vs. "release of patch" from OEM?

  • Patch everything monthly, if not, mark alternative implementation (minimum is RA-5 timelines 30/90/180), 3PAO and JAB to determine if it meets intent (this could be a finding, moderate to high depending on breadth/depth)

  • Most CSPs establish a monthly cycle and pull patches the same week (usually after patch Tuesday) and target applying the new patches toward the end of the month. RA-5 kicks in once a published vulnerability is detected via scanners, but doesn't change the requirement to pull the new patches on a monthly basis.

  • RA-5 Risk management and vulnerability remediation requires analysis and a risk based approach depending on the finding or gap identified; SI-2 requires that the CSP responds to updates in a timely manner of release and are not dependent on the use or analysis of scanning tools.

  • Across our 38N team, we've seen a lot of SaaS clients lean on a strong monthly patching and remediation cycle to satisfy SI-2 whereas PaaS made sure their SDLC addressed prompt pushes of new code once they made it available to satisfy the thirty day requirement. In the end, it's not best practice to have inconsistent or lengthy patching cycles for OS, scanners, and other security-relevant software and firmware.

  • On the flip side, we have also seen some large IaaS providers handle vendor security updates using a risk based approach, installing security-relevant patches in accordance with the severity of the finding’s NIST CVSS score and RA-5 timelines (30/90/180). However, unfortunately the FedRAMP JAB today is more risk-averse and wants to see pretty clean vulnerability scans and a monthly patch cycle.

  • SI-2 is about installing the updates. It's related to vulnerability scans, but not one in the same. Tying it to RA-5 doesn't cover everything. CSP needs a formal patch management strategy to ensure the latest patches are tested and applied monthly (SI-2) on top of fixing their scan findings in the 30/90/180 day cycle (RA-5).

  • CSP's should implement something similar and call out what the process is for patching/maintenance (regardless of severity level). If it can't be 30 days for all updates, mark it as an alternative implementation and cite what the CSP is able to do (should not exceed RA-5 timelines 30/90/180). 3PAO/JAB/Agency can then determine if the alternative implementation meets the intent of the control.

Unofficial FedRAMP Guidance: None

Assessment Evidence:

• Part a.

• Tickets (or similar documentation) for low, moderate, and high/critical findings showing identified vulnerability scan issues are tracked, reported, and corrected. Evidence that issues were resolved within RA-5 (d) remediation timeframes. POA&Ms for findings that were not remediated within RA-5 (d) timeframes, and evidence of tracking to closure.

• Tickets (or similar documentation) showing identification, reporting, and remediation activities for relevant vendor releases, security alerts, advisories, directives, etc.

• Vulnerability scan reports (e.g., Nessus) for infrastructure, platform and application workloads.

• Part b. Tickets (or similar documentation) identifying that updates related to flaw remediation were tested prior to implementation. This can be included in evidence required for CM-3.

• Part c. Tickets (or similar documentation) showing software/firmware updates are installed within 30 days of release.

• Part d. System generated list of production configuration changes including software and firmware updates/patches. Associated change request documentation (e.g., tickets, etc.) showing flaw remediation flows through the change management process described in CM-3.

CSP Implementation Tips:

• FedRAMP Vulnerability Scanning Requirements

• FedRAMP Vulnerability Scanning Requirements for Containers