Attachment 1 - 209-Vulnerability Management Plan-2019.04_Final.pdf

Peace Corps

Vulnerability Management Plan

Version 2019.04

Prepared by:

Office of the Chief Information Officer (OCIO)

The Peace Corps

1111 – 20th Street NW

Washington, DC 20526

Peace Corps Vulnerability Management Plan v4.0

This page is intentionally blank.

Table of Contents

1 INTRODUCTION

2 WHAT IS VULNERABILITY MANAGEMENT?

2.1 PURPOSE AND OBJECTIVE

2.2 SCOPE

2.3 CANCELLATION OR EXPIRATION

2.4 TECHNICAL TESTING METHODOLOGY

2.5 VULNERABILITY MANAGEMENT PROCESS

2.6 ROLES AND RESPONSIBILITIES

2.7 SCANNING TOOLS

3 SCAN REQUEST PROCESS

3.1 FREQUENCY OF SCANNING AND SCANNING SCHEDULES ............................................................................................. 8 3.2 NEW SERVER BUILD SCANNING PROCESS ................................................................................................... 9 3.3

VULNERABILITY DETECTION PROCESS

3.4 TIME LINES AND THRESHOLDS FOR REMEDIATION

4 SCAN REPORTING

5 OFFICIAL REPORTS

6 VULNERABILITY MANAGEMENT/REPORTING

7 VULNERABILITY MANAGEMENT/REPORTING RISK MANAGEMENT

8 REMEDIATION VALIDATION

APPENDIX A: VULNERABILITY REMEDIATION TIME LINES AND THRESHOLDS

APPENDIX B: SOC RESPONSE SERVICE LEVEL

APPENDIX C: SCAN REQUEST CHECKLIST

Figures and Tables

Table 1 – SOC Tools

Table 2 – Scan Frequency

Table 3 - Reports

Figure 1 - SOP i

Document Revision History

Version Date Description

1.0 November 5th

2015 VM Plan – Updating November 5. V 0.1

1.1 April 2016

Reviewed for accuracy and made updates to the process and procedures.

2.0 April, 2017

Service Level Agreement (SLA), the scanning schedule and frequency as well as formatting.

3.0 December, 2017

Editing, Added signature page, added roles and responsibilities

4.0 April, 2019

General Editing, updated signature page, added new server scanning SOP, added scan request process, updated roles and responsibility, updated vulnerability remediation scanning section, added

SOC Service Levels ii

Michael Terry Date

Deputy Chief Information Officer (DCIO)

Christopher Bursenos

Director, Information Security, Policy and Date

Governance

1 Introduction

Peace Corps uses a comprehensive Vulnerability Management Program to detect and remediate vulnerabilities within networked devices to ensure that maximum security afforded by the network design is maintained.

Vulnerability management is an essential component of any information security program and the process of vulnerability assessment is vital to effective vulnerability management. Vulnerability assessment provides visibility into the vulnerability of assets deployed in the network. Vulnerability assessment consists of scanning to identify networked assets and determining potential vulnerabilities and assessment of potential vulnerabilities. Remediation of the vulnerabilities is another facet of vulnerability management.

2 What is Vulnerability Management?

Vulnerability management can be defined as “the cyclical practice of identifying, classifying, remediating, and mitigating vulnerabilities." Peace Corps use vulnerability management to preemptively defend against the exploitation of vulnerabilities in business applications, software and networks.

2.1 Purpose and Objective

The purpose of this program is to define the management process, procedure and controls used to maintain the security for systems and applications using network resources.

2.2 Scope

All Government Furnished Equipment (GFE) to include servers, workstations, printers, mobile devices, routers and switches or any device capable of connecting to the Peace

Corps network fall within scope. The scope also encompasses any internal private IP addresses (e.g., 172.0.0.0/8, 10.0.0.0/8, 192.168.0.0/16) as well as external IP address ranges both domestic and international.

2.3 Cancellation or Expiration

This policy does not have an expiry date. However, this document is reviewed and updated as required annually.

2.4 Technical Testing Methodology

The proposed testing methodology includes the following phases:

Service Discovery and Enumeration – This phase consists of conducting packet captures and network scans using various techniques to perform service discovery and enumeration.

The discovery techniques include, but are not limited to, the following:

• Packet sniffing and protocol decoding

• Discovery scanning

• Protocol Scanning

• ICMP Scanning

• TCP/UDP Port Scanning

• OS Fingerprinting

• Service Fingerprinting

Review of Configuration Files and System Settings – This phase involves reviewing the configuration files and/or system settings for servers. This review will provide information regarding local security policies and configuration settings on each host. The results will be analyzed to identify vulnerabilities and/or misconfiguration and to determine compliance with all applicable security policies.

Vulnerability Identification – This phase involves using tools such as Nessus to identify vulnerabilities and misconfigurations in the operating system running on each host. It is important to note that administrative credentials will be necessary for Nessus to run an audit policy on the systems being tested. The test team will work with the UNIX administrator for the appropriate credentials to be typed into the Nessus interface by the administrator.

Vulnerability Verification and Exploitation – This phase consists of verifying the results of the vulnerability identification phase in order to identify false positives.

Those vulnerabilities determined to have a high probability of legitimacy will be brought to the attention of Peace Corps personnel for verification and remediation.

2.5 Vulnerability Management Process

The Peace Corps vulnerability management process consists of the following five phases:

• Outline the vulnerability management policy

• Discover new and existing vulnerabilities

• Analyze current level of security and rank vulnerabilities by threat level/remediation actions required

• Mitigate the causes of vulnerabilities

• Maintain security through ongoing testing and discovery.

2.6 Roles and responsibilities

The following roles have been identified within the vulnerability management process:

• SOC Manager: The SOC engineer is the owner of the vulnerability management process. This person designs the process and ensures it is implemented as designed

• Vulnerability Engineer/Analyst (VE/VA): The VE is responsible for configuring the vulnerability scanner, scheduling the various vulnerability scans, creating reports and updating the system inventory provided by the ISSO team. The

VE/VA is responsible analyzing vulnerability and compliance reports/trends, providing summary of the reports, as well as removing false positives and accepted risk from the scanning tools

• ISSO: The ISSO role is to review the scan reports (vulnerability and compliance), review vulnerability trends for each of their identified systems. The ISSO will work with the system owner on remediation efforts, risk acceptance, and creating

POA&M’s to track vulnerability remediation. ISSO’s are also responsible for providing and maintaining the system inventory for each of their systems.

Inventory changes with the tools will be requested via track-IT ticket

• System Owner: The system owner is responsible for their system assets that is scanned by the vulnerability management process. This role should decide whether identified vulnerabilities are mitigated or their associated risks are accepted

• System Engineer/SCCM Engineer: The System engineer role is typically responsible for implementing remediating actions defined as a result of detected vulnerabilities

2.7 Scanning Tools

The primary vulnerability assessment solution is Tenable Security Center Continuous

View from Tenable. Security Center scans the Peace Corps network infrastructure, systems and devices on a scheduled periodic basis and generates a report on the vulnerabilities identified across all assets.

Other tools utilized for the technical vulnerability scanning and testing are a combination of licensed commercial tools, proprietary tools and freeware. The following sample tools may be used during the technical testing; however, additional tools will be used based on the findings, services discovered or vulnerabilities identified:

Tool Description Commercial/Open

Source

Platform

Nessus Network vulnerability scanner Freeware with

Commercial Feed

License

Unix/Win32/Mac

Nmap Network port and protocol scanner

Open Source Unix/Win32/Mac

OpenVAS Network vulnerability scanner Open Source, bundled with

Commercial Alien

Vault

Unix

Backtrack Vulnerability exploitation/validation

Suite

Open Source Unix / Windows

Nexpose Network vulnerability scanner

Commercial Unix / Windows

Metasploit Vulnerability exploitation/validation

Suite

Commercial Unix / Windows

Web Inspect Web application

Scanner

Commercial Windows

Burp Suite Web application

Scanner

Commercial Windows

Table 1 – SOC Tools

3 Scan request process

To request a specific vulnerability, compliance or Web application scan, a Track-It ticket will need to be opened and assigned to the SOC. The scan request checklist found in

Appendix C should also be filled out and attached to the ticket.

3.1 Frequency of scanning and scanning schedules

Full automated vulnerability scanning is conducted on a weekly basis during the nights and weekends. Additional scanning may also be required outside this window and will be performed as needed. The vulnerability and compliance scan schedule is highlighted below. The defined scan cycle makes provision for a scan frequency of at least once a week for servers, desktops, laptops, and networking devices.

Scanning this frequently allows the owners of the assets to track the progress of remediation efforts, identify new risks as well as reprioritize the remediation of vulnerabilities based on new intelligence gathered.

When a vulnerability is first released, it may have a lower vulnerability score because there is no known exploit. Once a vulnerability has been around for some time, an automated exploit kit may become available which would increase the risk of that vulnerability. A system that was once thought to not be vulnerable, may become vulnerable to a vulnerability or set of vulnerabilities due to new software installed or a patch roll back.

There are many factors that could contribute to the risk posture of an asset changing.

Frequent scanning ensures that the owner of the asset is kept up-to-date with the latest information.

The following table summarizes the scanning schedules:

Name of Scan Group Scan Frequency

Mobile Devices Nightly (after hours)

Malware Scanning with Nessus Nightly (after hours)

Servers, Desktops, Laptops

International

– Domestic and Weekly

Name of Scan Group Scan Frequency

Macintosh (Publications) Weekly

VMware Infrastructure Weekly

Edge Routers, Firewalls, VOIP Quarterly/ Adhoc

Compliance scanning (servers, Laptop, desktops, and tablets)

Quarterly/Adhoc

Table 2 – Scan Frequency

3.2 New server build scanning process

Members of the server team have been granted access to the Tenable SC\Nessus to perform vulnerability and compliance scanning for new server builds. Shown below is the scanning process for new server builds.

Figure 1 - SOP

3.3 Vulnerability Detection Process

Vulnerabilities can be identified through unauthenticated and authenticated methods.

Typically, an attacker would view a system with an unauthenticated view. Therefore, scanning without credentials would provide a similar view to a primitive attacker.

This method is good for identifying some extremely high-risk vulnerabilities that an attacker could detect remotely and exploit to gain deeper access to the system. There is, however, a higher likelihood for false positives, as it is very difficult to validate the presence of a vulnerability without exploiting it.

A much more comprehensive and recommended method for vulnerability scanning is to scan with credentials. This allows for increased accuracy in the determination of the vulnerability risk of the organization. Vulnerability signatures specific to the operating system and installed applications that were detected in the discovery and inventory stage are run to identify which vulnerabilities are present.

The SOC utilizes credentials for routine or periodic vulnerability testing. Other security vulnerability testing however may be performed without credentials. The credentials used by the SOC have administrator level privileges. The SOC presently has administrative credentials for the Windows Active Directory (AD), some

Cisco/Unix/Linux or Mac systems. Administrator level credential will also be requested in order to scan other Peace Corps approved devices.

3.4 Time lines and Thresholds for Remediation

The establishment of timelines and threshold between the SOC and the various IT support teams is vital to the enterprise and ensures proactive measures are implemented. Appendix A of this document holds vulnerabilities timelines for remediation according to their threshold. ISSO will open POA&Ms for vulnerabilities that cannot be remediated within 30 days for tracking and timely remediation.

4 Scan Reporting

At the successful completion of each weekly scan, two reports will be generated and distributed via email or available to our SharePoint site. Vulnerability Engineer/Analyst will review these scanned reports to make sure scans are accurate, there are no false/positives, and all approved exceptions are not in the reports. The ISSO of the applicable systems are responsible for reviewing the scanned reports to make sure all the findings are communicated to System Owner. All the findings that require more than

30 days to remediate will be tracked through POA&M process.

A Detailed Scan Report

The Detailed scan report will provide system level specifics on missing patches (both

Microsoft and third party), existing vulnerabilities and remediation guidance. This report can be accessed through our Security SharePoint repository.

Monthly Executive Scan Report

The Executive scan report will provide high level information, statistical numbers and trending data on all systems.

The following reports are generated in sequence with an allowance for a one month window between system administrator/ISSO/AO and CIO reports. However, actionable device reports are readily available upon completion of a successful scan.

https://in.peacecorps.gov/HQ/OCIO/security/Scan%20Reports/Forms/AllItems.aspx

5 Official Reports

Report Title Frequency Recipient Purpose Distrusted

Via

Executive

Report Monthly CISO and ISSO

The CISO view current and tracks changes in the vulnerability posture of Peace Corps

SharePoint

Email

Detailed Scan

Report Weekly ISSO

ISSO/System owners review these reports to understand the vulnerabilities that their systems may be exposed to and to work with the system administrators to perform corrective actions.

SharePoint

Actionable Reports

Ad-Hoc scan

Reports As needed for new or changed systems

ISSO

These reports are generally focused toward an individual asset and are usually requested for new assets or when changes are being made.

SharePoint

Email

Remediation

Reports As needed to confirm corrections.

ISSO

These reports are generated to refresh the vulnerability view to see that identified vulnerabilities have been properly addressed.

SharePoint

Table 3 - Reports

6 Vulnerability Management/Reporting

Reporting of vulnerabilities is done to provide ISSO and system owners and the opportunity to both understand the potential risk that their systems may be exposed to and to take proactive steps address the identified vulnerabilities. Between each official reporting period, vulnerabilities may be identified by the Security Team, system administrators, vendors, or other sources. The initiation of this process begins with the dissemination of actionable system reports as generated by the weekly scan cycle or by custom reporting. Any vulnerability designated as “Critical” or “High” will immediately be brought to the attention of the ISSO or his/her technical representative for immediate generation of a solution or mitigation options.

7 Vulnerability Management/Reporting Risk Management

Vulnerabilities may exist in the operating system, applications or in the way different components work together. Effort should be made to correct issues, but some vulnerabilities cannot be fixed. Vendors may have appliances that are not patched in a timely manner, services may be exposed to more hosts then required, and software may be abandoned and no longer supported. In these cases, additional protections may exist to negate the vulnerability. In these cases, risk-based decision may be made so that the vulnerabilities are not identified as items of risk to the system. System Owner needs to work with ISSO team to identify such vulnerabilities and work on exception document to document risk-based decisions. Vulnerability Engineer will tune their scans to incorporate all signed exceptions so these vulnerabilities will not show-up on the scans.

8 Remediation Validation

Secondary and tertiary scans are required to validate that remediation actions have been applied in the cases of zero day patches and non-patch related fixes. Validation for scheduled patching will be conducted on the next scheduled scan cycle. The SCCM team has been granted access to Tenable SC to perform validation scanning on an

Adhoc basis.

Appendix A: Vulnerability remediation time lines and thresholds

Vulnerability remediation is to be completed according to the following guidelines. Any findings that needs to be mitigated later than the service levels must be reviewed by the ISSO and be documented as exceptions. These exceptions are to be reviewed and approved by the Director of

Operations and the Director of IT Security.

Severity Description Service Level

Urgent Denotes a vulnerability through which an intruder can easily gain control at the administrator level of any affected host. This class of vulnerabilities poses the highest risk for a system-wide compromise of the Peace Corps network:

• Vendor 0 day vulnerabilities actively being exploited

• Critical vulnerabilities actively being exploited

• Binding Operational directive (BOD) 19-02

24-48 hours

• Vendor recommend configuration

• Vendor recommend patch

15 days

Critical and Highs per BOD 19-02

Critical Denotes a vulnerability through which an intruder could gain access to the host at the administrator level or could possibly access Sensitive Information stored on the host. While this class of vulnerabilities is extremely serious, the risk of a breach or compromise is not as imminent as with an Urgent severity rating.

• Vulnerabilities with a CVSS score of 9.5 or higher

• Critical patches with exploits kits available

• Critical patches with publicly available malware

30 days

Patches are tested prior to deployment

High Denotes a vulnerability that may allow an intruder to gain access to specific information stored on the host, including security settings. While not immediately associated with a compromise of an affected host, these vulnerabilities allow intruders to gain access to information that may be used to compromise the host in the future.

Vulnerabilities with a CVSS score of 8.0 to

9.5

30 days

Medium/Moderate Intruders may be able to collect sensitive information from the host, such as the precise version of software installed. With this information, intruders can easily exploit known vulnerabilities specific to software versions.

Vulnerabilities with a CVSS score of 6.0 to

8.0 and can be mitigated within an extended time frame

90 days

Appendix B: SOC Response Service Level

Service Request Type

Description Service Level

Scan Request

(Vulnerability\Compliance)

Requests for vulnerability or compliance scanning on all Peace Corps approved devices

2-3 days

Risk Acceptance creation Modifying Tenable SC scanner to match new baselines, risk acceptance and deviations

5-7 days

Web Application Scanning Performing web application scanning 5-7 days

Mobile application and device vetting Assist with the vetting of new mobile application and hardware devices

5-7 days

Printer Baseline review Manually reviewing new printer configuration

5-7 days

Investigations/forensics

Request for internal investigations for example (OIG Request, incident forensics, malicious code review, PII breach)

3-7 days for domestic

2-30 days for international

Appendix C: Scan Request Checklist

Checklist_for_Scan_ Requestv3_Sample.d