ATO Documents opener.
This record shall be maintained throughout the life of the document. Each published update shall be recorded.
|Date||Description of Change||Made by|
|7-MAR-2018||Initial draft||Shawn Wells | firstname.lastname@example.org|
The vulnerability management process begins with vulnerabilities being identified or reported to Red Hat’s Product Security team.
Red Hat Product Security rates the impact of security issues found in Red Hat products using a four-point scale (Low, Moderate, Important, Critical), as well as Common Vulnerability Scoring System (CVSS) base scores. These provide a prioritized risk assessment to help you understand and schedule upgrades to your systems, enabling informed decisions on the risk each issue places on your unique environment.
The four-point scale tells you how serious Red Hat considers an issue to be, helping system operators judge the severity and determine what the most important updates are. The scale takes into account the potential risk based on a technical analysis of the exact flaw and its type, but not the current threat level; a given rating will not change if an exploit or worm is later released for a flaw, or if one is available before the release of a fix.
|Critical Impact||This rating is given to flaws that could be easily exploited by a remote unauthenticated attacker and lead to system compromise (arbitrary code execution) without requiring user interation. These are the types of vulnerabilities that can be exploited by worms. Flaws that require an authenticated remote user, a local user, or an unlikely configuration are not classed as Critical impact.|
|Important Impact||This rating is given to flaws that can easily compromise the confidentiality, integrity, or availability of resources. These are the typos of vulnerabilities that allow local users to gain privileges, allow unauthenticated remote users to view resources that should otherwise be protected by authentication, allow authenticated remote users to execute arbitrary code, or allow remote users to cause a denial of service.|
|Moderate Impact||This rating is given to flaws that may be more difficult to exploit but could still lead to some compromose of the confidentiality, integrity, or availability of resources, under certain circumstances. These are the typoes of vulneravilities that could have had a Critical or Important impact but are less easily exploited based on a technical evaluation of the flaw, or affect unlikely configurations.|
|Low Impact||This rating is given to all other issues that have a security impact. These are the types of vulnerabilities that are believed to require unlikely circumstances to be able to be exploited, or where successful exploit would give minimal consequences.|
Additional information on Red Hat’s Severity Ratings can be found at Understanding Red Hat security ratings.
Differences Between NVD and Red Hat Scores
For open source software shipped by multiple vendors, the CVSS base scores may vary for each vendor’s version, depending on the version they ship, how they ship it, the platform, and even how the software is compiled. This makes scoring of vulnerabilities difficult for third-party vulnerability databases, such as the NIST National Vulnerability Database (NIST NVD), who can only give a single CVSS base score to each vulnerability.
These differences can cause the scores to vary widely. For example, NVD rates Firefox flaws as having High impact metrics because the Firefox application is also available for Microsoft Windows, where it is common that the user is running Firefix with administrator privileges. For Red Hat Enterprise Linux, Low impact metrics are used, as Firefox is most likely to run as an unprivileged user.
For these reasons, it is recommended that, whenever possible, CVSS base scores provided by Red Hat are given preference over third party scoring.
Differences Between DISA IAVA and Red Hat Scores
tbd tbd tbd
The system owner, upon receipt of an official notification of a vulnerability notice, will take the following actions:
- Access the DoD-CERT web page and retrieve the entire vulnerability notice message.
- Notify SA, ISSO, and all appropriate staff of the vulnerability notice and inform the staff to access the DoD-CERT web page and retrieve the vulnerability notice message.
- Acknowledge receipt of the vulnerability notification to the SMDC IAM. Acknowledgement must be completed within 5 days unless otherwise specified in the vulnerability notification.
- Assess the impact of the vulnerability, apply the fix or obtain an extension if corrective actions cannot be implemented within the specified timeframe. Report the status for each vulnerability notice as it applies to every applicable asset within the information system.
- Conduct random compliance checks on information system assets to validate the information being reported through the command channels.
Information system owners can opt to make a vulnerability notice requirement more stringent than those required by DoD CERT.
Patch Extension Request
Should timely patching not be feasible, extensions are granted by the organization’s Designated Approving Authority (DAA). The following considerations must be documented for each extension request:
- The assessment of risk (e.g.; how vulnerable the system is to exploit)
- How the system(s) will be monitored for exploitation (e.g.; use of mitigating tools)
- A Fix Action Plan with a completion date
Every asset potentially affected by a vulnerability notice will be labeled with one of the following “Compliance Status” identifies:
Open: “Open” means the asset is impacted by a specific alert; however, no protective actions have been put in place. As a result, the vulnerability still exists. Most alerts are issued with a period of 30 days for compliance. An “open” status is acceptable during this 30-60 day period. However, if an asset becomes operational 30 days after the initial release of the alert, an “open” status is not acceptable.
Not Applicable: “Not applicable” means the System Administrator (SA), Information System Security Officer (ISSO), Information System Security Manager (ISSM) or Program Manager (PM) has determined a recently released alert does not apply to the operational configuration of an asset. The responsible user who made this decision is required to maintain all documentation to justify the “Not Applicable” status. The management hierarchy or the DAA may request the documentation. Also, the documentation may be reviewed during the compliance validation process.
Fixed/In Compliance: This status means the SA or ISSO has determined an asset is applicable to a recently released alert and is in compliance with the official patch or fix.
Extension Requested: “Extension Requested” indicates that an extension request has been submitted for the asset and is in the process of being reviewed. There are two types of extension requests. First, the extension can be used in the traditional sense where the DAA accepts the mitigated risk associated with nonstandard official corrective action. Second, the extension can be employed by the user to request additional time to allow for corrective action to occur. This would be used for situations where corrective action cannot be implemented within the specified timeframe due to other factors (e.g.; equipment delivery, financial limitations, resource shortage, PMO actions, and other prerequisite tasks).
Extension Approved: This status indicates that an extension request has been approved for a specified timeframe. Management is responsible for continuing to address the problem and ensure that mitigating controls are in place. An extension may be granted for extended periods with management involvement. See list below.
|Period||Number of Days||Management||Fix Action Plan Requirement|
|Original Compliance Period||30 < original time period||IAM||* EMail tickler sent 15 days prior to compliance date polling activity fix status
* If asset will be in compliance - No action required.
* If asset will not be in compliance - IAM must submit a consolidated activity Plan of Action and Milestones (POA*M) to CIO 7 days prior to compliance date
|1st Extension||Not to exceed 30 days||IAM, DAA||* EMail tickler sent 15 days prior to compliance date polling activity fix status.
* If asset will be in compliance - No action required.
* If asset will not be in compliance - IAM must submit a consolidated activity Plan of Action and Milestones (POA&M) to CIO 7 days prior to extension expiration.
|2nd Extension||Not to exceed 60 days||IAM, DAA||* EMail tickler sent at 15-day intervals for compliance status check.|
|Additional Extensions (if required)||Based on circumstances||DAA||TBD|
Extension Denied: This status indicates that the Designated Approval Authority evaluated and denied an extension request. The SA/ISSO is responsible for immediately implementing corrective actions.
Extension Expired: This status indicates that an approved extension has expired for the asset and that corrective actions must be implemented or that another extension request must be submitted.
Information pertaining directly to vulnerabilities is posted on the ASSIST web site at http://www.jtfgno.mil/.