DocuSign Envelope ID: 80DC0BDD-11E0-4E02-920B-1B4AF7F8B6CC

IT Security Procedural Guide:

Vulnerability Management Process
CIO-IT Security-17-80

Revision 2
December 30, 2021

Office of the Chief Information Security Officer

DocuSign Envelope ID: 80DC0BDD-11E0-4E02-920B-1B4AF7F8B6CC

CIO-IT Security-17-80, Revision 2 Vulnerability Management Process

VERSION HISTORY/CHANGE RECORD

Page
Change Person Posting
Change Reason for Change Number of
Number Change
Change
Initial Version – February 6, 2017
1 Nussdorfer / Created vulnerability management Updated to reflect and All
Wilson / procedural guide to document implement most current NIST
Klemens how GSA identifies vulnerabilities SP 800-53 Rev 4 and GSA
and reports on them for resolution requirements.
Revision 1 – August 21, 2019
1 Nussdorfer Replaced references to HP To reflect the shift to a new Various
WebInspect with Netsparker and web application scanning tool
added references to Nessus and the usage of Nessus Agents
Agents in vulnerability identification
2 Heffron Added references to Twistlock To reflect the usage of Various
Twistlock in Cloud vulnerability
identification
3 Feliksa / Dean / Changes made throughout the Updated to align with the Throughout
Klemens document to align with current current version of GSA CIO
OMB, NIST, and GSA policies 2100.1 format to latest guide
structure and style, revise
guidance to current GSA
policies and processes
4 Thomsen Expanded information regarding CDM tools being used for Section 9
Compliance checks using CDM compliance checks. and
tools. Appendices
Revision 2 - December 30, 2021
1 Quintananieves Updates include: Updated to align with BOD 22- Throughout
/ Peters/  Revised remediation timelines 01, GSA CIO 2100.1, and
Klemens per BOD 22-01 and GSA current GSA tools and
guidance. processes.
 Updated to ensure all GSA
systems are in scope.
 Updated tools used and
descriptions of their use.

U.S. General Services Administration

DocuSign Envelope ID: 80DC0BDD-11E0-4E02-920B-1B4AF7F8B6CC

CIO-IT Security-17-80, Revision 2 Vulnerability Management Process

Approval

IT Security Procedural Guide: Vulnerability Management Process, CIO-IT Security-17-80,

Revision 2 is hereby approved for distribution.

Bo Berlas
GSA Chief Information Security Officer

Contact: GSA Office of the Chief Information Security Officer (OCISO), Policy and Compliance
Division (ISP) at [email protected].

U.S. General Services Administration

DocuSign Envelope ID: 80DC0BDD-11E0-4E02-920B-1B4AF7F8B6CC

CIO-IT Security-17-80, Revision 2 Vulnerability Management Process

Table of Contents
1 Introduction ............................................................................................................................... 1
1.1 Purpose .......................................................................................................................................... 1
1.2 Scope.............................................................................................................................................. 1
1.3 Policy .............................................................................................................................................. 1
1.4 References ..................................................................................................................................... 3
2 Roles and Responsibilities ........................................................................................................... 3
2.1 Authorizing Officials (AOs) ............................................................................................................. 3
2.2 Information Systems Security Managers (ISSMs) .......................................................................... 4
2.3 Information Systems Security Officers (ISSOs) .............................................................................. 4
2.4 System Owners (SOs) ..................................................................................................................... 4
2.5 Custodians...................................................................................................................................... 5
2.6 System/Network Administrators ................................................................................................... 5
2.7 GSA SecOps Scanning Team Members .......................................................................................... 5
3 GSA General Vulnerability Management Procedures.................................................................... 5
3.1 Implementation of NIST Controls .................................................................................................. 5
3.2 Adherence to Federal Laws, Regulations, Directives, and Guidance ............................................ 6
3.2.1 DHS CISA Cybersecurity Directives ..................................................................................... 7
3.2.2 BOD 18-01 – Enhance Email and Web Security .................................................................. 7
3.2.3 BOD 19-02 - DHS Cyber Hygiene Scanning Program........................................................... 7
3.2.4 BOD 20-01 - Develop and Publish a Vulnerability Disclosure Policy................................... 8
3.2.5 BOD 22-01 - Reducing the Significant Risk of Known Exploited Vulnerabilities ................. 8
4 Vulnerability Management.......................................................................................................... 8
4.1 GSA Scanning Capabilities .............................................................................................................. 8
4.2 Vulnerability Scanning Process ...................................................................................................... 9
4.2.1 Inventory Updates by ISSOs ................................................................................................ 9
4.2.2 Scanning Tool Updates ....................................................................................................... 9
4.2.3 Performing Vulnerability Scans ......................................................................................... 10
4.2.4 Scan Issue Mitigation ........................................................................................................ 12
4.3 Vulnerability Scan Reports ........................................................................................................... 12
4.3.1 General Reports ................................................................................................................ 12
4.3.2 Executive Reports ............................................................................................................. 12
4.3.3 Ad Hoc Reports ................................................................................................................. 13
4.3.4 Documenting Report Reviews .......................................................................................... 13
4.4 Remediation Verification ............................................................................................................. 13
4.5 Re-Classification/Recasting of Known Vulnerabilities ................................................................. 14
4.6 False-Positive Handling ................................................................................................................ 14
5 Configuration Settings Management (CSM) ............................................................................... 15
5.1 CSM Scanning............................................................................................................................... 15
5.2 CSM Reporting ............................................................................................................................. 15
5.2.1 BigFix Compliance Portal .................................................................................................. 15
5.3 CSM Deviations ............................................................................................................................ 16
5.4 CSM Accounting, Compliance and Reporting .............................................................................. 16
5.4.1 CSM Accounting ................................................................................................................ 16
5.4.2 CSM Compliance Reporting .............................................................................................. 17

U.S. General Services Administration i

DocuSign Envelope ID: 80DC0BDD-11E0-4E02-920B-1B4AF7F8B6CC

CIO-IT Security-17-80, Revision 2 Vulnerability Management Process

Appendix A – Risk Level Identification ............................................................................................. 18

Appendix B – GSA Deadlines to Remediate Vulnerabilities ............................................................... 19
Appendix C – ISSO Vulnerability Management Tasks ........................................................................ 21
Appendix D – BigFix Report Recommendations ................................................................................ 22
Appendix E – Example of CSM Performance Management ............................................................... 23

List of Tables
Table 4-1: GSA Vulnerability Scanning Capabilities ..............................................................................8
Table 4-2: Scanning Schedule ........................................................................................................... 10
Table 5-1: Scanning Tool Applicability ............................................................................................... 15
Table 5-2: BigFix Reports .................................................................................................................. 16
Table 5-3: Configuration Setting Compliance Timeline....................................................................... 17
Table A-1: Risk Level Identification Table .......................................................................................... 18
Table B-1: Corrective Action Timelines .............................................................................................. 19
Table C-1: ISSO Vulnerability Management Tasks Table..................................................................... 21
Table D-1: Custom CSM Reporting Fields .......................................................................................... 22
Table E-1: Non-Compliant System ..................................................................................................... 23
Table E-2: Compliant System ............................................................................................................ 23

Notes:
 Hyperlinks in running text will be provided if they link to a location within this document
(i.e., a different section or an appendix). Hyperlinks will be provided for external sources
unless the hyperlink is to a web page or document listed in Section 1.4. For example,
Google Forms, Google Docs, and websites will have links.
 It may be necessary to copy and paste hyperlinks in this document (Right-Click, Select
Copy Hyperlink) directly into a web browser rather than using Ctrl-Click to access them
within the document.

U.S. General Services Administration ii

DocuSign Envelope ID: 80DC0BDD-11E0-4E02-920B-1B4AF7F8B6CC

CIO-IT Security-17-80, Revision 2 Vulnerability Management Process

1 Introduction
The General Services Administration (GSA) Chief Information Security Officer (CISO) is
responsible for implementing and administering an information security program to protect the
agency’s information resources, support business processes and the GSA mission. One part of
that program is the establishment of a vulnerability management process, this guide describes
that process. It addresses remediating vulnerabilities that are published as part of the
Department of Homeland Security (DHS) Cybersecurity Infrastructure Security Agency’s (CISA)
Cybersecurity Directives and establishes a process by which vulnerabilities affecting GSA
systems are identified using various security tools and communicated to appropriate personnel
for remediation.

1.1 Purpose

The purpose of this guide is to describe the procedures the GSA CISO has established to identify
and address vulnerabilities affecting GSA’s systems.

1.2 Scope

This guide must be followed by all GSA Federal employees and contractors managing (i.e.,
finding, reporting, tracking) vulnerabilities on GSA information systems and data. All GSA
systems, Contractor or Federal as defined below, must adhere to the timelines described in
Section 3 this guide.

 Contractor System. An information system in GSA’s inventory processing or containing

GSA or Federal data where the infrastructure and applications are wholly operated,
administered, managed, and maintained by a contractor in non-GSA facilities.
 Federal System (i.e., Agency System). An information system in GSA’s inventory
processing or containing GSA or Federal information where the infrastructure and/or
applications are NOT wholly operated, administered, managed, and maintained by a
Contractor.

1.3 Policy

GSA Order CIO 2100.1, “GSA Information Technology (IT) Security Policy” contains the following
policy statements regarding requirements related to vulnerability management.

11. Contractor Operations.

a. GSA System Program Managers and Contracting Officers shall ensure that the
appropriate security requirements of this Order are included in task orders and contracts
for all IT systems designed, developed, implemented, and operated by a contractor on
behalf of GSA, including but not limited to systems operating in a Cloud Computing
environment. In addition, GSA shall ensure that the contract allows GSA or its designated
representative (i.e., third-party contractor) to review, monitor, test, and evaluate the

U.S. General Services Administration 1

DocuSign Envelope ID: 80DC0BDD-11E0-4E02-920B-1B4AF7F8B6CC

CIO-IT Security-17-80, Revision 2 Vulnerability Management Process

proper implementation, operation, and maintenance of the security controls. This

requirement includes, but is not limited to: documentation review, server configuration
review, vulnerability scanning, code review, physical data center reviews, and
operational process reviews and monitoring of Service Organization Control 2 and
Statements on Standards for Attestation Engagements (SSAE) 18 reports.

b. The security controls implemented as part of contracts and task orders must include
specific language that requires solutions to align with existing information security
architecture. Security deliverables must be provided in a timely manner for review and
acceptance by GSA. Additional information may be found in GSA CIO-IT Security-09-48,
Security and Privacy Requirements for IT Acquisition Efforts and, for external information
systems, in GSA CIO-IT Security-19-101, External Information System Monitoring. Note:
As indicated in Chapter 1, Section 5, GSA has a deviation request process by which a
deviation from approved security architecture/standards may be requested.

Chapter 3, Policy for Identify Function, states:

4. Risk Assessment.

a. Independent vulnerability testing including penetration testing and system or port

scanning conducted by a third-party such as the GAO and other external organizations
must be specifically authorized by the AO and supervised by the ISSM

Chapter 5, Policy for Detect Function, states:

2. Security continuous monitoring.
t. Systems will be scanned for vulnerabilities of operating systems and web applications
periodically IAW GSA CIO-IT Security-17-80. Vulnerabilities identified must be remediated
IAW GSA CIO-IT Security-06-30.

Chapter 6, Policy for Respond Function, states:

4. Analysis.
f. The OCISO will establish a vulnerability management process for identifying
vulnerabilities via internal testing/scanning.
g. The OCISO will notify personnel with security responsibilities of vulnerabilities
disclosed via SAAs or other external sources.
4. Mitigation.

c. IAW GSA CIO-IT Security-06-30, system vulnerabilities must be:

(1) Remediated or mitigated IAW specified timeframes;

(2) Included in a Plan of Action and Milestones; or
(3) Included in an Acceptance of Risk Letter.

U.S. General Services Administration 2

DocuSign Envelope ID: 80DC0BDD-11E0-4E02-920B-1B4AF7F8B6CC

CIO-IT Security-17-80, Revision 2 Vulnerability Management Process

1.4 References

Note: GSA updates its IT security policies and procedural guides on independent cycles which
may introduce conflicting guidance until revised guides are developed. In addition, many of the
references listed are updated by external organizations which can lead to inconsistencies with
GSA policies and guides. When conflicts or inconsistencies are noticed, please contact
[email protected] for guidance.

Federal Laws, Regulations, and Guidance:

 CISA Cybersecurity Directives - Listing of Emergency and Binding Operational Directives
 Public Law 113-283, “Federal Information Security Modernization Act (FISMA) of 2014”
 NIST SP 800-115, “Technical Guide to Information Security Testing and Assessment”
 NIST SP 800-137, “Information Security Continuous Monitoring (ISCM) for Federal
Information Systems and Organizations”
 National Vulnerability Database Vulnerability Metrics, Webpage on Vulnerability Metrics
 44 U.S. Code § 3555, Authority and functions of the Director and the Secretary

GSA Guidance:
 GSA Order CIO 2100.1, “GSA Information Technology (IT) Security Policy”
The guidance documents below are available on the GSA IT Security Procedural Guides
InSite page.
 CIO-IT Security-06-30, “Managing Enterprise Cybersecurity Risk”
 CIO-IT Security-09-44, “Plan of Action and Milestones (POA&M)”
 CIO-IT Security-09-48, “Security and Privacy Requirements for IT Acquisition Efforts”
 CIO-IT Security-19-101, “External Information System Monitoring”

2 Roles and Responsibilities

The roles and vulnerability management responsibilities provided in this section have been
extracted and summarized from CIO 2100.1, Federal guidance, or GSA Security Operations
(SecOps) Scanning Team standard operating procedures/processes.

2.1 Authorizing Officials (AOs)

Responsibilities include the following:

 Ensuring vulnerability scans are able to be performed on systems and applications under
their purview;
 Coordinating with the CISO and experts within the OCISO regarding the consistent
management of cybersecurity risks across GSA.

U.S. General Services Administration 3

DocuSign Envelope ID: 80DC0BDD-11E0-4E02-920B-1B4AF7F8B6CC

CIO-IT Security-17-80, Revision 2 Vulnerability Management Process

2.2 Information Systems Security Managers (ISSMs)

Responsibilities include the following:

 Coordinating the performance of vulnerability scans with ISSOs and the SecOps Scanning
Team;
 Reviewing ISSO checklists submitted in Archer GRC to ensure vulnerability management
adheres to GSA policies and requirements and coordinating with ISSOs, as necessary, for
systems under their purview.

2.3 Information Systems Security Officers (ISSOs)

Responsibilities include the following:

 Coordinating the performance of vulnerability scans (scheduled and ad hoc) with System
Owners, ISSMs, and the SecOps Scanning Team;
 Working with the System Owner and ISSM to develop, implement, and manage
POA&Ms regarding identified vulnerabilities for their respective systems IAW GSA CIO-IT
Security-09-44;
 Evaluating known vulnerabilities (e.g., vulnerability summaries provided by ISE and scan
reports provided by the SecOps Scanning Team) with system personnel to ascertain if
additional safeguards are needed;
 Verifying all assets (hardware and software) in the A&A boundary (and only those
assets) for systems they are the assigned ISSO are scanned in accordance with GSA
policies and procedures (i.e., maintain an accurate inventory);
 Working with the SecOps Scan Team to resolve scanning issues (e.g., authentication
issues, unreachable hosts).
Note: Appendix C specifies at a more granular level ISSO tasks and associated deadlines
applicable to the vulnerability management process.

2.4 System Owners (SOs)

Responsibilities include the following:

 Coordinating the performance of vulnerability scans with ISSMs, ISSOs, and the SecOps
Scanning Team;
 Working with the ISSO and ISSM to develop, implement, and manage POA&Ms
regarding scanning results for their respective systems in accordance with CIO-IT
Security-09-44;
 Coordinating with the ISSO to ensure all assets (hardware and software) in the A&A
boundary (and only those assets) for systems under their purview are scanned in
accordance with GSA policies and procedures;
 Identifying, scheduling, and ensuring the completion of actions to remediate
vulnerability and configuration/compliance scan findings (e.g., security hardening,
configuration changes, software patches).

U.S. General Services Administration 4

DocuSign Envelope ID: 80DC0BDD-11E0-4E02-920B-1B4AF7F8B6CC

CIO-IT Security-17-80, Revision 2 Vulnerability Management Process

2.5 Custodians

Responsibilities include the following:

 Coordinating the running of vulnerability scans (e.g., identifying false positives) with
System Owners and the SecOps Scanning Team;
 Coordinating with System Owners, ISSMs, and ISSOs to ensure vulnerability and
configuration/compliance scans can be accomplished, cover all assets, and actions are
taken to address findings.

2.6 System/Network Administrators

Responsibilities include the following:

 Implementing the appropriate security requirements consistent with GSA IT security
policies and hardening guidelines;
 Coordinating the performance of vulnerability scans with System Owners, ISSOs, and the
SecOps Scanning Team;
 Applying patches/updates, configuration changes, and other remediation efforts to
address vulnerabilities, as appropriate, within required timeframes.

2.7 GSA SecOps Scanning Team Members

Responsibilities include the following:

 Updating vulnerability scanning tools and configuring them in accordance with GSA
requirements.
 Scheduling and conducting vulnerability scans and troubleshooting any issues.
 Producing, reviewing, and distributing vulnerability scanning reports.

3 GSA General Vulnerability Management Procedures

All GSA systems must adhere to the following general requirements regarding vulnerability
management. Appendix B, Table B-1, Corrective Action Timelines, provides information
on remediation timelines for BODs and GSA’s standard vulnerability management process.

3.1 Implementation of NIST Controls

All GSA systems must implement NIST controls RA-5, Vulnerability Scanning and SI-2(3), Flaw
Remediation | Time to Remediate Flaws/Benchmarks for Corrective Actions in accordance with
the frequencies and timelines established in the control statements and parameters as
indicated below.

RA-5:
a. Monitor and scan for vulnerabilities in the system and hosted applications [weekly
authenticated scans for operating systems (OS)-including databases, monthly

U.S. General Services Administration 5

DocuSign Envelope ID: 80DC0BDD-11E0-4E02-920B-1B4AF7F8B6CC

CIO-IT Security-17-80, Revision 2 Vulnerability Management Process

unauthenticated scans for web application, annual authenticated scans for web
applications] and when new vulnerabilities potentially affecting the system are
identified and reported;
d. Remediate legitimate vulnerabilities [
(1) BOD Timelines
(a) Within 14 days for vulnerabilities added to CISA’s KEV Catalog with a CVE date
post FY21.
(b) Per the CISA KEV catalog date or GSA Standard timelines below, whichever is
earlier, for vulnerabilities in the CISA KEV catalog with a CVE date in FY21 or
earlier.
(c) Within 15 days for Critical (Very High) vulnerabilities for Internet-accessible
systems or services.
(2) GSA Standard Timelines
(a) Within 30 days for Critical (Very High) and High vulnerabilities.
(b) Within 90 days for Moderate vulnerabilities.
(c) Within 120 days for Low vulnerabilities for Internet-accessible
systems/services.] in accordance with an organizational assessment of risk;
SI-2(3):
(b) Establish the following benchmarks for taking corrective actions: [
(1) BOD Timelines
(a) Within 14 days for vulnerabilities added to CISA’s KEV Catalog with a CVE date
post FY21.
(b) Per the CISA KEV catalog date or GSA Standard timelines below, whichever is
earlier for vulnerabilities in the CISA KEV catalog with a CVE date in FY21 or
earlier.
(c) Within 15 days for Critical (Very High) vulnerabilities for Internet-accessible
systems or services].
(2) GSA Standard Timelines
(a) Within 30 days for Critical (Very High) and High vulnerabilities.
(b) Within 90 days for Moderate vulnerabilities.
(c) Within 120 days for Low vulnerabilities for Internet-accessible systems or
services.] in accordance with an organizational assessment of risk;

As indicated in the Section 2 every role listed has some responsibility to ensure the required
scanning activities can and are performed for all GSA systems, applications, and assets; and that
remediation actions are taken.

3.2 Adherence to Federal Laws, Regulations, Directives, and Guidance

CIO 2100.1 establishes the controls/requirements for compliance to Federal Laws and
regulations, including DHS CISA Cybersecurity Directives and NIST publications. CIO-IT-Security-
06-30 reinforces these requirements and specifies requirements for vulnerability scanning and
flaw remediation. CIO-IT Security-09-48 reinforces the requirements to adhere to GSA policies
and requirements for all IT acquisitions (i.e., contracted systems), and CIO-IT Security-19-101

U.S. General Services Administration 6

DocuSign Envelope ID: 80DC0BDD-11E0-4E02-920B-1B4AF7F8B6CC

CIO-IT Security-17-80, Revision 2 Vulnerability Management Process

establishes the means by which GSA monitors external contractor systems for compliance with
GSA’s requirements.

In addition to the NIST requirements specified in the previous section, the processes defined in
GSA’s IT Security Policy and the procedural guides identified above, the primary adherence
requirements are generated by CISA’s Cybersecurity Directives which are explained in the
following sections.

3.2.1 DHS CISA Cybersecurity Directives

DHS CISA develops and oversees the implementation of BODs and EDs which require action on
the part of civilian Executive Branch agencies that fall under CISA’s authorities. GSA is an agency
that falls under CISA’s authorities. Descriptions of BODs and EDs are provided below.

Binding Operational Directive. A binding operational directive is a compulsory direction to

federal, executive branch, departments and agencies for purposes of safeguarding federal
information and information systems.

Emergency Directive. Section 3553(h) of title 44 U.S. Code, authorizes the Secretary of
Homeland Security, in response to a known or reasonably suspected information security
threat, vulnerability, or incident that represents a substantial threat to the information
security of an agency, to “issue an emergency directive to the head of an agency to take any
lawful action with respect to the operation of the information system, including such
systems used or operated by another entity on behalf of an agency, that collects, processes,
stores, transmits, disseminates, or otherwise maintains agency information, for the purpose
of protecting the information system from, or mitigating, an information security threat.”

Although all CISA Cybersecurity Directives, both EDs and BODs, are applicable to GSA’s systems,
the following sections highlight specific directives that are focused on vulnerability
management, identification, and remediation.

3.2.2 BOD 18-01 – Enhance Email and Web Security

This BOD focuses on Federal cyber hygiene and sets forth the requirement that all GSA web
applications be compliant with the following items.

 All publicly accessible Federal websites and web services provide service through a
secure connection (HTTPS-only, with HSTS),
 SSLv2 and SSLv3 are disabled on web servers, and
 3DES and RC4 ciphers are disabled on web servers

3.2.3 BOD 19-02 - DHS Cyber Hygiene Scanning Program

This BOD applies to all current and future critical vulnerabilities identified in the weekly "Cyber
Hygiene report" issued by DHS CISA. SecOps receives this report from CISA, notifies appropriate
personnel and coordinates remediation or mitigation. SecOps will perform all reporting to CISA,
including population of a partially completed remediation plan sent by CISA if GSA has any

U.S. General Services Administration 7

DocuSign Envelope ID: 80DC0BDD-11E0-4E02-920B-1B4AF7F8B6CC

CIO-IT Security-17-80, Revision 2 Vulnerability Management Process

overdue, in-scope vulnerabilities. If a remediation plan is received, SecOps will complete the
following fields in the remediation plan in cooperation with system personnel:

1. Vulnerability remediation constraints;

2. Interim mitigation actions to overcome constraints;
3. Estimated completion date to remediate the vulnerability.
3.2.4 BOD 20-01 - Develop and Publish a Vulnerability Disclosure Policy
This BOD requires each agency to develop and publish a vulnerability disclosure policy (VDP)
and maintain supporting handling procedures. It specifies a VDP as an essential element of an
effective enterprise vulnerability management program and critical to the security of internet-
accessible federal information systems.

All internet-accessible systems within GSA are required to be onboarded to the GSA
vulnerability disclosure program and abide by the published policy.

3.2.5 BOD 22-01 - Reducing the Significant Risk of Known Exploited Vulnerabilities
This BOD creates the CISA KEV catalog and creates remediation timelines associated with all
CVEs included within the catalog. SecOps will provide alerts to ISSOs related to flagged CISA
KEVs within their environments. SecOps will additionally be responsible for reporting BOD 22-
01 vulnerability metrics to CISA until such time as it is automated within the CDM dashboard.

4 Vulnerability Management
The following sections provide details on GSA SecOps’ scanning capabilities, processes, reports,
verification, and exception handling.

4.1 GSA Scanning Capabilities

Table 4-1 identifies the vulnerability scanning tools/capabilities used by GSA.

Table 4-1: GSA Vulnerability Scanning Capabilities

Tool Capability Description
Tenable.sc Vulnerability Scanning Tenable.sc (TSC) is used to identify vulnerabilities at
Configuration Scanning the operating system level. Furthermore, TSC will be
used for compliance checks against GSA’s
configuration benchmarks for assets that cannot
have a BigFix agent installed. TSC scans assets on-
premise and in the cloud and conducts scans over-
the-network or using an agent pre-installed on the
endpoint.
BigFix Configuration Scanning BigFix determines how compliant a workstation or
Compliance server is with their applicable security benchmark.
BigFix is the primary tool for this capability.

U.S. General Services Administration 8

DocuSign Envelope ID: 80DC0BDD-11E0-4E02-920B-1B4AF7F8B6CC

CIO-IT Security-17-80, Revision 2 Vulnerability Management Process

Tool Capability Description

Prisma Cloud Vulnerability Scanning Prisma Cloud Compute is the primary tool for finding
Compute vulnerabilities in Docker images and containers. It is
able to find vulnerabilities in the base docker image,
as well as code libraries running within that
container.
Anchore Vulnerability Scanning Anchore is an image vulnerability scanner used in
support of containerized environment build
processes.
Prisma Cloud Configuration Scanning Prisma Cloud Enterprise is a Software-as-a-Service
Enterprise (SaaS) capability managed by SecOps. The primary
purpose of the tool is the detection and alerting of
common misconfigurations within cloud
environments.
StackRox Vulnerability Scanning Stackrox is a Kubernetes native vulnerability
scanning and management tool. It is the primary tool
in use within GSA for securing Kubernetes clusters.
Netsparker Web Application Netsparker Cloud is a scalable multi-user online web
Cloud Vulnerability Scanning application security scanning solution with built-in
workflow tools that are used to configure, organize,
and report on GSA wide Netsparker scans.
Netsparker Cloud utilizes deployed Netsparker
agents as sensors to perform web application scans.

4.2 Vulnerability Scanning Process

This section describes key components of the vulnerability scanning process. See Appendix A
for how risk levels are assigned based on the vulnerability identification tools used at GSA.

4.2.1 Inventory Updates by ISSOs

System ISSOs are required to review and update their system inventory by the 15th of each
month. This includes updating all Internet Protocol (IP) addresses associated with each of their
assets. ISSOs responsible for Web applications must review and update the associated Uniform
Resource Locators (URLs) as needed. Updates to all inventories will be conducted via the
applicable SecOps supplied Google inventory sheets. Any changes to inventories should be
reflected in the system’s System Security and Privacy Plan.

Note: Failure to update system inventory data will result in inaccurate vulnerability scan reports
which, in turn, will lead to inaccurate System POA&M data and report.

4.2.2 Scanning Tool Updates

Vulnerability tools are configured to have their plugins auto updated, where possible updates
will occur during non-work hours. Leveraging the Google inventory sheets, the Scanning Team
will update the target lists within the vulnerability management tools, as needed. As necessary,

U.S. General Services Administration 9

DocuSign Envelope ID: 80DC0BDD-11E0-4E02-920B-1B4AF7F8B6CC

CIO-IT Security-17-80, Revision 2 Vulnerability Management Process

the Scanning Team will update the scan tool configuration (i.e., add plugins to a scan profile,
etc.) to maximize the vulnerabilities tested by the tool.

4.2.3 Performing Vulnerability Scans

The Scanning Team performs various types of Ad Hoc and scheduled vulnerability scanning. The
following sections describe each scan type.

4.2.3.1 Scheduled Scans

Table 4-1 provides a high-level view of scanning frequency. Additional details are available within
the 06-30 Scanning Parameter Spreadsheet.

Table 4-2: Scanning Schedule

Scanning Type* Frequency
Configuration Baseline Scans Biweekly
Agent Scans Every 72 hours
Container Image Vulnerability Scans Real-time
Operating System Vulnerability Scans (includes
Weekly
Databases where applicable)
Web Application – Unauthenticated Scans Monthly
Web Application – Authenticated Scans Annually
DHS Cyber Hygiene Scanning – Unauthenticated Scans Weekly
*Scans are authenticated unless otherwise noted, DHS uses a less intrusive scan over the Internet

4.2.3.2 Agent Scans

To support Department of Homeland Security (DHS) Continuous Diagnostics and Mitigation

(CDM) requirements, GSA has deployed Tenable Nessus Agents to servers and workstations.
The Nessus Agents are controlled and managed by an associated Nessus Manager. Agent
deployments eliminate issues with failed authentication on agent-deployed hosts by
continuously running and polling the Nessus Manager for new scans, rather than requiring a
Nessus scanner to use enterprise credentials to login. To support the 72-hour DHS scan
requirement, SecOps uses an automated script that identifies the age of the last scan for each
agent within GSA and schedules a new scan as needed. Associated “agent synchronization jobs”
are run withinTenable.sc to import the agent scan results, which are then included in SecOps
regular vulnerability reporting.4.2.3.3 Supplemental Active Scans

Due to the “in host” nature of the agent scans not all plugins run. To ensure that all applicable
vulnerability plugins within Tenable.sc are applied to GSA hosts during vulnerability scanning
additional scans are necessary. These supplemental active scans run against all GSA hosts that
contain a Nessus Agent and are conducted weekly on Thursdays.

U.S. General Services Administration 10

DocuSign Envelope ID: 80DC0BDD-11E0-4E02-920B-1B4AF7F8B6CC

CIO-IT Security-17-80, Revision 2 Vulnerability Management Process

4.2.3.3 Container Image Vulnerability Scans

To support security of Docker images and containers, GSA has deployed a Prisma Cloud
Compute Console to manage security and reporting requirements of vulnerability scanning. This
software gathers information from deployed agents called ‘Prisma Defenders’ which are
containers running on each server running the Docker engine. Prisma Defenders provide real-
time monitoring for all resources used by each running container on the system. This
information is sent to the Prisma Cloud Compute Defender Console where reporting and
enforcement takes place.

To support vulnerability scanning of Kubernetes environments GSA SecOps has deployed the
StackRox security suite that monitors Kubernetes environments on a daily basis.

4.2.3.4 Web Application Scanning

Web application scans are conducted using the Netsparker web application testing suite.
SecOps maintains this tool and is responsible for scanning and reporting out of the tool. In
general Web application scans fall into two categories:

 Unauthenticated Scans
 Authenticated Scans

These scans are conducted on a timeframe set forth in Table 4-1.

4.2.3.5 Performing Ad Hoc Scans

Out of cycle, or ad hoc, vulnerability scans will be performed on an as-requested basis, at the
discretion of the SecOps Scanning Team. Ad hoc scans are typically requested by ISSOs or
Application Developers in order to verify the remediation of a previously identified
vulnerability, support firewall change requests, or determine the security impact of any major
system changes. However, they may be requested by anyone with a vested interest in the
security posture of a system. Requests must be approved by the ISSM. Ad hoc vulnerability
scans may be requested via a ServiceNow Request using the following steps.
1. Open Service Now
2. Select “Submit Catalog Request”
3. Select “Data Enterprise Services”
4. Select “Security Scan Requests”
Note: Ad hoc scans may be performed with or without authentication depending upon the
configuration and the requirements of the request.
Note: All requested firewall changes will be supported by a vulnerability scan of the associated
host IPs and web applications.

U.S. General Services Administration 11

DocuSign Envelope ID: 80DC0BDD-11E0-4E02-920B-1B4AF7F8B6CC

CIO-IT Security-17-80, Revision 2 Vulnerability Management Process

4.2.4 Scan Issue Mitigation

Following vulnerability scans, the SecOps Scanning Team will coordinate with applicable ISSOs
regarding any scan related issues encountered during the scan cycle. Issues may include but are
not limited to:
 Failures regarding system authentication
 Failures regarding the ability to reach systems
 Failures of scans to complete
Coordination on scan failures will be accomplished via email. As necessary, the SecOps
Scanning Team will work with ISSOs to determine causes and resolve identified issues;
however, it is the ISSOs responsibility to ensure that all hosts within their system are being
scanned and to work with the underlying system administrators to resolve any authentication
issues.

4.3 Vulnerability Scan Reports

The SecOps Scanning Team will produce and distribute vulnerability scan reports used to track
vulnerabilities on assets. These reports can support an ISSO’s workflow for tracking
vulnerabilities thru closure (i.e., remediation). They can contain all the required fields for
understanding the vulnerabilities found on an asset, and their severity. These vulnerability
reports are classified as Controlled Unclassified Information and distributed on a need-to-know
basis.

4.3.1 General Reports

Tenable.sc will be configured to auto-generate and distribute to applicable ISSOs/Points of
Contact (POCs) vulnerability reports listing all of the vulnerabilities identified during the weekly
scans. Vulnerability reports depicting vulnerabilities identified during the monthly
unauthenticated Netsparker scans will be created and distributed by the SecOps Scanning
Team. ISSOs will be able to review the scan results associated with their systems via access to
the scanning tools. Vulnerability reports listing vulnerabilities identified during the ‘realtime’
Prisma Cloud Compute Defender monitoring will be automatically created and distributed
biweekly by the SecOps Scanning Team. A Prisma Cloud Compute Distribution’ list is maintained
by SecOps for distribution.

StackRox automated reporting is conducted on a daily basis. The distribution list for these
reports is maintained by the SecOps team.

4.3.2 Executive Reports

On a biweekly basis, the SecOps Scanning Team will produce and distribute Executive Reports
summarizing the vulnerabilities that affect GSA system components and applicable cloud
hosted environments. The systems outlined within the reports will be broken out by GSA
Service/Staff Office/organization responsibility and then by individual FISMA systems. The
following data breakouts will be contained within the Executive Reports:

U.S. General Services Administration 12

DocuSign Envelope ID: 80DC0BDD-11E0-4E02-920B-1B4AF7F8B6CC

CIO-IT Security-17-80, Revision 2 Vulnerability Management Process

 Number of outstanding high and critical risk vulnerabilities

 Summary of active vulnerabilities broken out by FISMA system
 Summary of vulnerabilities mitigated in the past 30 days broken out by FISMA system
 Top 10 Critical Vulnerabilities Summary
 Top 10 Critical and High Risk Vulnerability Summary
 Top 10 High and Critical Vulnerabilities Over 30 Days Old
 Top 10 Hosts with High and Critical Vulnerabilities Over 30 Days Old
 Hosts that are exposed to the Internet and have Critical Risk Vulnerabilities
These reports are distributed to applicable personnel such as AO, ISSM, ISSO, and System
Owners.
Note: Authorized individuals requiring additional data breakouts may contact the SecOps
Scanning Team and request a different system/vulnerability categorization scheme.
Note: Only Tenable.sc vulnerability data is included in Executive Reports.
4.3.3 Ad Hoc Reports
The SecOps Scanning Team will produce a vulnerability report of an ad hoc vulnerability
scanning event, upon request. These reports will be distributed to applicable personnel such as,
but not limited to ISSOs, ISSMs, AOs, and System Owners.

4.3.4 Documenting Report Reviews

Currently, ISSOs and/or ISSMs will document their review of scan results per the Review of
Security Vulnerability Scan Reports Google Document. In the near future, GSA’s implementation
of GRC Archer will be used to document the review of scan results using an ISSO Checklist.
Further guidance and training on using the ISSO Checklist will be provided as its implementation
into production is completed.

4.4 Remediation Verification

In Tenable.sc, data related to the aging of vulnerabilities will be collected and tracked by the
SecOps Scanning Team and provided to Executives, ISSMs, and ISSOs during the normal
reporting cycles. Vulnerabilities will mature based on the date originally identified in scan
results/reports. Vulnerabilities over 30 days old will be depicted within each report. The
provided associated files will contain columns depicting when vulnerabilities were ‘first
discovered’ and ‘last observed.’ ISSMs and ISSOs should leverage the reports and associated
files to assist with prioritizing mitigation activities.

Prisma Cloud Compute does not track ‘first discovered’ or ‘last observed’ information on
vulnerabilities on a per image basis. Its reports contain links to each specific vulnerability which
can be followed to find the date on which the vulnerability was announced to the open
community. This date should be used to calculate the 30-day and 90-day countdown for
prioritizing mitigation and resolution.

U.S. General Services Administration 13

DocuSign Envelope ID: 80DC0BDD-11E0-4E02-920B-1B4AF7F8B6CC

CIO-IT Security-17-80, Revision 2 Vulnerability Management Process

Web Application scanning conducted within Netsparker has the ability to do targeted
remediation tests which can be used to mark a finding as remediated. Additionally,
vulnerabilities can be marked as closed manually when manual testing is completed to show
remediation.

See Appendix B for additional details regarding remediation deadlines.

4.5 Re-Classification/Recasting of Known Vulnerabilities

Special considerations may be made for the reporting of vulnerabilities associated with
Acceptance of Risk (AoR) letters that have been approved per CIO-IT Security-06-30, “Managing
Enterprise Cybersecurity Risk.” ISSOs may request re-categorization of vulnerabilities included in
AoRs as follows:
 Web Application vulnerabilities may be considered false positives, therefore excluding
them from vulnerability reports.
 Operating system vulnerabilities will be ‘accepted’ within Tenable.sc when SecOps is
provided with a valid AOR
 Operating system vulnerabilities may be recast to ‘informational’ with supporting
justification.
 Prisma Cloud Compute related vulnerabilities may be handled as ‘ignored’ within the
PCC Console, allowing them to be untracked in future reports.
It is the responsibility of the individual ISSOs to track their associated AoRs and present the
SecOps Scanning Team with supporting documentation, as requested.
Note: Vulnerabilities with recast risk levels will appear in vulnerability scan reports with the
assigned Common Vulnerability Scoring System (CVSS) score, however the Severity level will be
shown as “Informational.”

4.6 False-Positive Handling

A vulnerability identified as a “false positive” applies to a vulnerability reported where in fact

none exists. Through the course of system personnel implementing remediation strategies to
mitigate identified vulnerabilities, it may be determined that a reported vulnerability is actually
a false positive. Following the verification of a false positive by technical/subject matter
experts, an ISSO, in coordination with the system owner/personnel, may request the associated
identified ‘vulnerability’ be reclassified in the same manner as described in Section 7. As with all
vulnerability scanning exceptions, this request must be routed through and approved by the
ISSM and SecOps Scanning Team.

Note: False Positives will be designated on an individual host-by-host basis. System wide
exceptions will only be made with explicit approval from the CISO/SecOps.

U.S. General Services Administration 14

DocuSign Envelope ID: 80DC0BDD-11E0-4E02-920B-1B4AF7F8B6CC

CIO-IT Security-17-80, Revision 2 Vulnerability Management Process

5 Configuration Settings Management (CSM)

Configuration Settings Management (CSM) is the practice of managing our security baselines
and configuring assets to comply with settings found in these baselines. This term was coined
under the Continuous Diagnostics and Mitigation (CDM) program.
Two tools are used to monitor and report compliance with our baselines: BigFix Compliance and
Tenable.sc. Each tool is considered authoritative for the results they provide and each tool
covers different sets of assets.

5.1 CSM Scanning

Several factors determine what tool will be used for CSM scanning: location, type of asset, level
of access to that asset. BigFix will be used whenever possible for CSM scanning. If a BigFix agent
cannot/should not be installed on the asset, Tenable Nessus will be used. Both solutions require
a configuration change on the asset and within the solution itself.
Table 5-1: Scanning Tool Applicability
Component Type Location CSM Tool Used
Workstation (GFE) Anywhere BigFix
Server On-premise BigFix
Server Cloud Tenable/BigFix
Network Devices On-premise Tenable

5.2 CSM Reporting

ISSOs, ISSMs, and other personnel responsible for the security of a system can use a variety of
different reports and dashboards within BigFix Compliance and Tenable Security Center to
monitor their compliance scores. See Appendices D and E for additional information regarding
CDM data for reporting and configuration settings.

5.2.1 BigFix Compliance Portal

Personnel can access the BigFix Compliance portal directly if they have been granted access. If
access is needed, a generic request in ServiceNow can be submitted with a justification for
access. Once granted, a user is automatically signed into the compliance portal using their Long
Name Account (LNA).
This portal offers dashboards and the ability to create and email custom reports. Compliance
reports can be customized then scheduled for delivery to a user’s email inbox. ISSOs will be
expected to access BigFix compliance for their reporting needs; SecOps will not publish or
distribute reports for assets within BigFix.

U.S. General Services Administration 15

DocuSign Envelope ID: 80DC0BDD-11E0-4E02-920B-1B4AF7F8B6CC

CIO-IT Security-17-80, Revision 2 Vulnerability Management Process

Table 5-2: BigFix Reports

Report Type When To Use Important Tips
Computer States an assets’ compliance percentage  Filter the list of assets using
against assigned baselines. Can be exported the “GSA FISMA System” field.
into Excel or viewed within BigFix  Filter on Configuration
Compliance. If viewed online in the portal, baseline to ensure
you can drill-down into the compliant and calculations don’t include two
non-compliant settings for a particular host. checklists.
Checklist Used to determine compliance with a  Filter the list of assets using
checklist. the “GSA FISMA System” field.
 Select a FISMA System.
 Select Checklists.

5.3 CSM Deviations

Some configuration settings cannot be applied to an asset(s) for valid reasons. In these cases,
the ISSO should request a deviation for these settings; otherwise, compliance scores will be
calculated and reported incorrectly. Any deviations, exceptions, or other conditions not
following GSA policies and standards must be submitted using the Security Deviation Request
Google Form. Once the deviation is documented and approved, those settings can be excluded
from compliance score calculations.

5.4 CSM Accounting, Compliance and Reporting

5.4.1 CSM Accounting

A FISMA system must monitor compliance to all of the configuration settings required by GSA
hardening guides. Each configuration setting must be covered by one of the following clauses:

 The configuration setting is compliant - The asset’s setting is either:

1. Equal to the setting required, or
2. More restrictive than the setting required.
 The configuration setting is not compliant - The asset is configured with a more liberal
setting than what is required. In this case, the non-compliant configuration setting
needs to be accounted for in one of the following ways:
1. Deviation - The non-compliant setting is covered by an approved deviation.
2. Plan of Action and Milestone (POA&M) - If the composite compliance percentage
of all assets with a single operating system is below 85% for over 90 days, a
POA&M must be created for the non-compliant operating system.

U.S. General Services Administration 16

DocuSign Envelope ID: 80DC0BDD-11E0-4E02-920B-1B4AF7F8B6CC

CIO-IT Security-17-80, Revision 2 Vulnerability Management Process

Table 5-3: Configuration Setting Compliance Timeline

Timeline Expectation
Harden asset to 85% compliance or seek
Day 1 – Day 90
approval for required deviations.
Create/maintain POA&M (per operating
system) if non-compliant setting
Day 91+ percentage is below 85% (approved
deviations not included in percentage
calculation).
5.4.2 CSM Compliance Reporting
A FISMA systems’ compliance with CSM requirements is regularly reported to executives. A
FISMA system will be reported as non-compliant with CSM requirements if any GSA Operating
System benchmark within the FISMA System is reporting under 85% compliance.

U.S. General Services Administration 17

DocuSign Envelope ID: 80DC0BDD-11E0-4E02-920B-1B4AF7F8B6CC

CIO-IT Security-17-80, Revision 2 Vulnerability Management Process

Appendix A – Risk Level Identification

Table A-1: Risk Level Identification Table
Source of Risk Rating Risk Assessment Process
Tenable.sc Use the National Vulnerability Database
(https://nvd.nist.gov/cvss.cfm) qualitative ratings, when available.
 (OS, including Database Tenable Security Center uses CVSS v2.0 ratings, vulnerabilities
scans) with assigned scores will be rated as listed below.
 Configuration/Compliance  CVSS score of 0.0-3.9 will be labeled "Low" severity.
scans  CVSS score of 4.0-6.9 will be labeled “Moderate” severity.
 CVSS score of 7.0-9.9 will be labeled “High” severity.
 CVSS score of 10.0 will be labeled “Critical” severity.
If the vulnerability has no CVSS score the Tenable Security Center
rating will be used.
Prisma Cloud Compute (OS Use the National Vulnerability Database
and code library results): (https://nvd.nist.gov/cvss.cfm) qualitative ratings. Prisma Cloud
Compute uses CVSS v3.0 ratings, vulnerabilities with assigned
scores will be rated as listed below.
 CVSS score of 0.1-3.9 will be labeled "Low" severity.
 CVSS score of 4.0-6.9 will be labeled “Moderate” severity.
 CVSS score of 7.0-8.9 will be labeled “High” severity.
 CVSS score of 9.0-10.0 will be labeled “Critical” severity.
If the vulnerability has no CVSS score the Prisma Cloud Compute
assigned rating will be used.
Netsparker (Web Use the Netsparker vulnerability severity rating, unless otherwise
application scans) reclassified/adjusted by the GSA OCISO. Netsparker uses the
following severities:
 Informational
 Low
 Medium
 High
 Critical

U.S. General Services Administration 18

DocuSign Envelope ID: 80DC0BDD-11E0-4E02-920B-1B4AF7F8B6CC

CIO-IT Security-17-80, Revision 2 Vulnerability Management Process

Appendix B – GSA Deadlines to Remediate Vulnerabilities

The following timeframes for remediating vulnerabilities have been established by DHS CISA
BODs and by the OCISO as GSA’s standard remediation timelines.

Table B-1: Corrective Action Timelines

Corrective Action Required Actions Target Primary

Deadline Reference

BOD Timelines

Within 14 days Remediate vulnerabilities Any GSA system with the BOD 22-01
added to CISA’s Known newly identified
Exploited Vulnerabilities vulnerabilities.
(KEV) Catalog with a CVE date
post FY21.

CISA KEV catalog Remediate vulnerabilities in Any GSA system with the BOD 22-01
date or GSA the CISA KEV catalog with a vulnerabilities listed in the
Standard timelines CVE date in FY21 or earlier. CISA KEV catalog.
below, whichever is
earliest.

Within 15 days of Remediate Critical (Very High) Any GSA system identified in BOD 19-02/
initial detection vulnerabilities for systems or a DHS Cyber Hygiene Report BOD 20-01
services with Internet-accessible with critical vulnerabilities.
IP addresses.

Within 30 days of Remediate High vulnerabilities Any GSA system identified in BOD 19-02/
initial detection for systems or services with a DHS Cyber Hygiene Report BOD 20-01
Internet-accessible IP addresses. with high vulnerabilities.

Standard GSA
Timelines

Within 30 days of Remediate Critical (Very High) Any GSA system identified RA-5 control
initial detection and High vulnerabilities. with critical (very high) parameter
vulnerabilities.

Within 90 days of Remediate Moderate Any GSA system identified RA-5 control
initial detection vulnerabilities. with moderate parameter
vulnerabilities.

Within 120 days of Remediate Low vulnerabilities Any GSA Internet-accessible RA-5 control
initial detection for Internet-accessible systems Web application identified parameter
or services. with low vulnerabilities.

U.S. General Services Administration 19

DocuSign Envelope ID: 80DC0BDD-11E0-4E02-920B-1B4AF7F8B6CC

CIO-IT Security-17-80, Revision 2 Vulnerability Management Process

Corrective Action Required Actions Target Primary

Deadline Reference

No specific deadline Remediate Low/Very Low Any GSA system identified 06-30,
unless defined by the vulnerabilities on a case-by-case with low/very low Section 5.7.3
GSA OCISO basis. vulnerabilities.

U.S. General Services Administration 20

DocuSign Envelope ID: 80DC0BDD-11E0-4E02-920B-1B4AF7F8B6CC

CIO-IT Security-17-80, Revision 2 Vulnerability Management Process

Appendix C – ISSO Vulnerability Management Tasks

The following table identifies ISSO tasks and deadlines associated with the vulnerability
management process.
Table C-1: ISSO Vulnerability Management Tasks Table
Task Deadline
Coordinate with the SecOps Scanning Team As needed.
pertaining to upcoming vulnerability scans.
Evaluate known vulnerabilities with system Upon release of new vulnerabilities (e.g.,
personnel to ascertain if additional safeguards are Vulnerability Summaries and Advisories
needed. provided by ISE).
Review and update system inventories. No later than the 15th of each month.
Request out of cycle, or ad hoc, vulnerability As required to verify the mitigation of a
scans, as required. previously identified vulnerability, support
firewall change requests, or determine the
security impact of any major system
changes.
Work with the SecOps Scanning Team to As required to overcome scan related
determine causes and resolve issues such as issues confronted by SecOps.
unreachable systems, or authentication issues
encountered during scan cycles.
Review all vulnerability reports and associated At a minimum, monthly.
files and document their review.
Track known vulnerabilities and their remediation Upon identification of new vulnerabilities.
statuses.
Track AoRs associated with their system(s). Upon acceptance of new AoRs, and request
Present the SecOps Scanning Team with for reclassification/recasting of
supporting documentation as requested, when vulnerabilities.
requesting reclassification/recasting of
vulnerabilities.
Respond to Emergency and Binding Operational Deadline as dictated by the ED or BOD as
Directives as they apply to the system. necessary.

U.S. General Services Administration 21

DocuSign Envelope ID: 80DC0BDD-11E0-4E02-920B-1B4AF7F8B6CC

CIO-IT Security-17-80, Revision 2 Vulnerability Management Process

Appendix D – BigFix Report Recommendations

Useful fields to include in custom CSM reports from BigFix.

Table D-1: Custom CSM Reporting Fields

Field Name Example of Data Field
Computer E04TCM-BFROOT
Last Seen 7 Days Ago
IP Address 127.30.32.3
GSA FISMA System EIO
Check Count 1
Total Compliant 258
Total Excepted 4
Compliance Percentage 98%

U.S. General Services Administration 22

DocuSign Envelope ID: 80DC0BDD-11E0-4E02-920B-1B4AF7F8B6CC

CIO-IT Security-17-80, Revision 2 Vulnerability Management Process

Appendix E – Example of CSM Performance Management

Example 1 - FISMA System is reported as Non-Compliant in leadership reports
A FISMA system has 3 different operating systems within it: Windows 2016, Red Hat Enterprise
Linux 6, and Windows 2012. The compliance scores are reported below. This FISMA system is
considered non-compliant because the Red Hat Enterprise Linux 7 benchmark is below 85%.
Table E-1: Non-Compliant System
Operating System Overall Compliance Number of Assets
Windows 2016 90% 5
Windows 2012 R2 85% 13
Red Hat Enterprise Linux 7 83% 4

Example 2 - FISMA System is reported as Compliant in leadership reports

This FISMA system has two operating systems. This system is considered compliant because all
applicable OS-level baselines are 85% or above.
Table E-2: Compliant System
Operating System Overall Compliance Number of Assets
Windows 2016 90% 15
Windows 2012 R2 87% 10

U.S. General Services Administration 23