96-S Exhibit P - Security Assessment Report

Exhibit P

UNCLASSIFIED // FOR OFFICIAL USE ONLY

UNCLASSIFIED // FOR OFFICIAL USE ONLY

TEMPLATE VERSION (V1.3 FY17) - REMOVE BEFORE PUBLISHING

Security Assessment Report

Social Security Administration

(SSA)

<System Name> (<Acronym>) Security Categorization: <Enter Categorization>

<DRAFT/FINAL> Version <x.x> <Month DD, YYYY>

Prepared by

8229 Boone Blvd., Suite 750

Vienna, VA 22182

<System Name>

Security Assessment Report (SAR) Version <X.X>

TMP V1.3 FY17 UNCLASSIFIED // FOR OFFICIAL USE ONLY ii

<INSTRUCTIONS: Orange, bracketed text indicates instructions on how a section should be completed or sample text, which should be replaced with project specific information or removed. Ensure sample text is turned from orange to black where necessary (e.g., headings shall be changed to the standard heading color), and all instructions are removed (including this paragraph). Remove the template ID (e.g., TMP V1.3 FY17) from the footer before publishing. All black text shall remain unchanged.>

TMP V1.3 FY17 UNCLASSIFIED // FOR OFFICIAL USE ONLY iii

Assessment Summary This document describes the Federal Information Security Modernization Act (FISMA) Security Assessment Report (SAR) for Social Security Administration (SSA). The primary purpose of this document is to deliver the independent security assessment findings for <System Name> (hereafter known as <System Acronym>). These findings will lead to the initiation of corrective actions or for making risk-based decisions. This independent security assessment supports the U.S. Government’s mandate that all U.S. Federal information systems comply with FISMA of 2014.

The assessment took place between <MM DD, YYYY> and <MM DD, YYYY>. The independent security assessment followed the approved the Security Assessment Plan (SAP). All deviations from the approved SAP are located in Table 7.

The table below represents the aggregate risk identified from the independent security assessment.

Table 1: Executive Summary of Risks

NOTE: Total is the sum of high, moderate, and low risks with operationally required risks being represented as a subset of this total.

Risk Category Total % of Total Risks

High <# high risks> <% of total risks>

Moderate <# moderate risks> <% of total risks>

Low <# low risks> <% of total risks>

Total Risks <Sum of all H, M, L risks>

100%

TMP V1.3 FY17 UNCLASSIFIED // FOR OFFICIAL USE ONLY iv

Document Revision History Version Date Description Author

1.0 <10/02/2015> Initial release Coalfire

<1.1> <10/26/2015> <Final template updates FY17> Coalfire

<1.2> <10/24/2017> <Template updates for FY17> Coalfire

TMP V1.3 FY17 UNCLASSIFIED // FOR OFFICIAL USE ONLY v

Table of Contents

1 INTRODUCTION

1.1 Applicable Laws and Regulations

1.2 Applicable Standards and Guidance

1.3 Purpose

2 SCOPE

2.1 Applicable Security Controls

2.2 System Name/Title

2.3 Assessment Documentation

2.4 Location of Components Tested

2.5 Subsystems, Users and Interfaces

2.6 Assessment Inventory

3 SYSTEM OVERVIEW

3.1 Security Categorization

3.2 System Description and Purpose

4 ASSESSMENT METHODOLOGY

4.1 Perform Tests

4.1.1 Assessment Deviations

4.2 Identification of Vulnerabilities

4.3 Consideration of Threats

4.4 Perform Risk Analysis

5 SECURITY ASSESSMENT RESULTS

5.1 Security Assessment Summary

6 NON-CONFORMING CONTROLS

6.1 Risks Corrected During Testing

6.2 Risks with Mitigating Factors

6.3 Risks Remaining Due to Operational Requirements

7 RISKS KNOWN FOR INTERCONNECTED SYSTEMS

8 RECOMMENDATIONS

APPENDIX A. ACRONYMS AND TERMS

APPENDIX B. SECURITY RISK TRACEABILITY MATRIX (SRTM)

APPENDIX C. INFRASTRUCTURE SCAN RESULTS

Infrastructure Scans: Inventory of Items Scanned Infrastructure Scans: Raw Scan Results Infrastructure Scans: False Positive Reports

APPENDIX D. DATABASE SCAN RESULTS

Database Scans: Inventory of Databases Scanned Database Scans: False Positive Reports

APPENDIX E. WEB APPLICATION SCAN RESULTS

Web Application Scans: Inventory of Web Applications Scanned Web Application Scans: False Positive Reports

APPENDIX F. ASSESSMENT RESULTS

TMP V1.3 FY17 UNCLASSIFIED // FOR OFFICIAL USE ONLY vi

APPENDIX G. PENETRATION TEST REPORT

APPENDIX H. SECURITY ASSESSMENT REPORT SIGNATURE

List of Tables Table 1: Executive Summary of Risks .......................................................................................................... iii Table 2: Identified Security Controls Assessed Table 3: Information System Name and Title Table 4: Location of Components Table 5: Users and Interfaces Table 6: Hardware and Software Inventory Table 7: List of Assessment Deviations Table 8: Threat Categories and Type Identifiers Table 9: Potential Threats Table 10: Likelihood Definitions from NIST 800-30 Rev. 1 Publication Table 11: Impact Definitions from NIST 800-30 Rev. 1 Publication Table 12: Risk Exposure Ratings from NIST 800-30 Rev. 1 Publication Table 13: Risk Exposure Table 14: Summary of Risks Corrected During Testing Table 15: Summary of Risks with Mitigating Factors Table 16: Summary of Risks Remaining Due to Operational Factors Table 17: Risks from Interconnected Systems Table 18: Acronyms and Terms Table 19: Security Test Procedure Workbook Table 20: Inventory of Items Scanned Table 21: Raw Scan Results Table 22: Infrastructure Scans: False Positive Reports Table 23: Inventory of Databases Scanned Table 24: Database Scans: False Positive Reports Table 25: Inventory of Web Applications Scanned Table 26: Web Application Scans: False Positive Reports Table 27: Summary of System Security Risks from FISMA Testing Table 28: SAR Signatures

TMP V1.3 FY17 UNCLASSIFIED // FOR OFFICIAL USE ONLY 1

1 Introduction This SAR document for <System Acronym> is required by the National Institute of Standards and Technology (NIST) 800-53 Revision 4 (Rev 4) document. This SAR contains unbiased and factual security findings by an independent security assessment team. This SAR contains the <System Acronym> system specific security controls tested as per the Security Assessment Plan (SAP) approved by SSA Office of Information Security (OIS), the <System Acronym> Security Authorization Manager (SAM), and the Coalfire (formally Veris Group) Project Manager (PM). The implementation status of these controls identify the residual risk (risk remaining after controls have been implemented). These controls are required per NIST 800-53 Rev. 4 to address known information system vulnerabilities. The results are in support of SSA Security Authorization program goals, efforts, and activities necessary to achieve compliance with FISMA security requirements.

1.1 Applicable Laws and Regulations

• Computer Fraud and Abuse Act [Public Law (PL) 99-474, 18 U.S. Code (USC) 1030]

• E-Authentication Guidance for Federal Agencies [Office of Management and Budget (OMB) M-04- 04]

• FISMA of 2014 [PL 113-283]

• Freedom of Information Act (FOIA) As Amended in 2002 [PL 104-232, 5 USC 552]

• Guidance on Inter-Agency Sharing of Personal Data – Protecting Personal Privacy [OMB M-01-05]

• Homeland Security Presidential Directive(HSPD)-7, Critical Infrastructure Identification, Prioritization and Protection [HSPD-7]

• Internal Control Systems [OMB Circular A-123]

• Management of Federal Information Resources [OMB Circular A-130]

• Management’s Responsibility for Internal Control [OMB Circular A-123, Revised 12/21/2004]

• Privacy Act of 1974 as amended [5 USC 552a]

• Protection of Sensitive Agency Information [OMB M-06-16]

• Records Management by Federal Agencies [44 USC 31]

• Responsibilities for the Maintenance of Records About Individuals by Federal Agencies [OMB Circular A-108, as amended]

• Security of Federal Automated Information Systems [OMB Circular A-130, Appendix III]

1.2 Applicable Standards and Guidance

• A NIST Definition of Cloud Computing [NIST SP 800-145]

• Computer Security Incident Handling Guide [NIST SP 800-61, Revision 2]

• Contingency Planning Guide for Federal Information Systems [NIST SP 800-34, Revision 1]

• Engineering Principles for Information Technology Security (A Baseline for Achieving Security) [NIST SP 800-27, Revision A]

• Assessing Security and Privacy Controls in Federal Information Systems and Organizations [NIST SP 800-53A, Revision 4]

TMP V1.3 FY17 UNCLASSIFIED // FOR OFFICIAL USE ONLY 2

• Security and Privacy Controls for Federal Information Systems and Organizations [NIST SP 800- 53, Revision 4]

• Guide for Developing Security Plans for Federal Information Systems [NIST SP 800-18, Revision 1]

• Guide for Applying the Risk Management Framework to Federal Information Systems: A Security Life Cycle Approach [NIST SP 800-37, Revision 1]

• Guide for Mapping Types of Information and Information Systems to Security Categories [NIST SP 800-60, Revision 1]

• Guide for Security-Focused Configuration Management of Information Systems [NIST SP 800-128]

• Information Security Continuous Monitoring for Federal Information Systems and Organizations

[NIST SP 800-137]

• Managing Information Security Risk: Organization, Mission, and Information System View [NIST

SP 800-39]

• Minimum Security Requirements for Federal Information and Information Systems [FIPS Publication 200]

• Personal Identity Verification (PIV) of Federal Employees and Contractors [FIPS Publication 201- 2]

• Recommended Security Controls for Federal Information Systems [NIST SP 800-53, Revision 4]

• Guide for Conducting Risk Assessments [NIST SP 800-30, Revision 1]

• Security Considerations in the System Development Life Cycle [NIST SP 800-64, Revision 2]

• Security Requirements for Cryptographic Modules [Federal Information Processing Standard (FIPS) Publication 140-2]

• Standards for Security Categorization of Federal Information and Information Systems [FIPS Publication 199]

• Technical Guide to Information Security Testing and Assessment [NIST SP 800-115]

1.3 Purpose

The purpose of this document is to provide the System Owner (SO) and the SSA Authorization Official (AO) with a detailed level of the residual risk for <System Acronym>. An independent security assessment team conducted a test for each system specific security control implemented by SSA stakeholders. These tests include a combination of interviews, document examinations, and actual technical testing of controls when applicable. These controls each had implementation statements listed in the <System Acronym> System Security Plan (SSP). These statements identified how the controls are in place and the assessment team tested the controls based on that criteria. Additionally, the testing ensures the controls are in are in compliance with the FISMA baseline security control requirements as defined in NIST 800-53 Rev 4. FISMA mandates that all Federal Agencies will comply with the NIST 800-53 Rev. 4 standards.

Assessors from the independent security assessment team are members of contracted Coalfire Federal Services (formally Veris Group).

The system specific security controls for this assessment are in section 2.1

TMP V1.3 FY17 UNCLASSIFIED // FOR OFFICIAL USE ONLY 3

2 Scope

2.1 Applicable Security Controls

The applicable security controls as listed in the <System Acronym> SAP are in Table 2 of this <System Acronym> SAR. The security control assessment authorized by OIS and the <System Acronym> SAM gives authority to the Coalfire Independent Security Assessment team to assess the listed controls.

Table 2: Identified Security Controls Assessed

Security Control Family Security Control

Access Control AC-2, AC-2(2), AC-2(3), AC-2(4)

Awareness and Training

Audit and Accountability AU-7(1)

Security Assessment and Authorization CA-5, CA-6

Configuration Management CM-9

Contingency Planning

Identification and Authentication IA-2, IA-(3), IA-5, IA-5(1)

Planning PL-2, PL-2(3), PL-8

Personnel Security PS-4, PS-5

Risk Assessment RA-2, RA-3

System and Services Acquisition SA-3, SA-4(9), SA-5, SA-8, SA-9, SA-9(2), SA-11

System and Communications Protection SC-4, SC-39

System and Information Integrity SI-10, SI-11, SI-16

2.2 System Name/Title

The <System Acronym> system unique identifier and system acronyms are in Table 3. Due to the number of applications located within <System Acronym>, <only two of the subsystems> fall within the scope of this assessment. The authority to use a representative sample is located within NIST 800-53 Rev 4 Guide for Assessing the Security Controls in Federal Information Systems and Organizations.

Table 3: Information System Name and Title

Information System Name: <System Name> Information System Acronym: <System Acronym> Information System Identifier <System Identifier> Security Categorization: (High, Moderate, Low) <Categorization> PII data: (Yes/No) <Yes/No> e-Authentication Application: (Yes/No) <Yes/No> Production Data Used In Development/Test Environment (Yes/No)

<Yes/No>

TMP V1.3 FY17 UNCLASSIFIED // FOR OFFICIAL USE ONLY 4

Federal Tax Information (Yes/No) <Yes/No>

2.3 Assessment Documentation

Documentation used by the independent assessment team to perform the assessment of the <System Acronym> subsystems include the following:

• <System Acronym> System Security Plan (SSP)

• <System Acronym> Security Assessment Plan (SAP)

• Security Operation Division (SOC) Nessus scanner with McAfee, McAfee ePolicy Orchestrator (EPO) instance scan statistic reports

• SSA Information Security Policy (ISP)

• The <System Acronym> Boundary Scope Memo (BSM)

• The <System Acronym> Information System Contingency Plan (ISCP)

• The <System Acronym> Federal Information Processing Standards Publication (FIPS) 199

2.4 Location of Components Tested

The physical locations of all the different functional components supporting the testing of the <System Acronym> information system is in Table 4.

Table 4: Location of Components

System Physical Location and Addresses

Production Environment Site Name

Address Description of Components

<EXAMPLE: National Computer Center (NCC)>

6401 Security Blvd Baltimore, MD 21235

Production Environment (i.e., hardware ) (Primary Support)

Development/Test Environment Site Name

Address Description of Components

<EXAMPLE: National Support Center (NSC)>

3500 Campus Drive, Suite 106 Urbana, MD 21704

Development and Testing Environment (Integration Testing)

Disaster Recovery Environment Site Name

Address Description of Components

<EXAMPLE: Secondary Support Center (SSC)>

3004 Tower Blvd Durham, NC 27707

Production Environment (i.e., hardware) (Secondary/Failover Support)

Contractor Owned Environment Site Name

Address Description of Components

2.5 Subsystems, Users and Interfaces

TMP V1.3 FY17 UNCLASSIFIED // FOR OFFICIAL USE ONLY 5

The <System Acronym> system contains the following subsystems, users and interfaces that were tested as part of this assessment. They are contained within the embedded Table 6.

<Complete the embedded spreadsheet with system specific information.>

Table 5: Users and Interfaces

T2 Internet - Users and Interfaces.doc

<Embed the applicable system’s Users and Interface, EXAMPLE attached.>

2.6 Assessment Inventory

The <System Acronym> hardware and software inventories provided by the SO’s are in Table 6.

<Complete the embedded spreadsheet with system specific information.>

Table 6: Hardware and Software Inventory

T2 Internet - HW-SW Inventory.xl

<Embed the applicable system’s Hardware and Software Inventory, EXAMPLE attached.>

NOTE: Any changes to the scope of the Authorization Boundary after the Boundary Scope Meeting and finalization of the Boundary Scope Memo (BSM) may impact the overall Independent Verification and Validation (IV&V) schedule.

TMP V1.3 FY17 UNCLASSIFIED // FOR OFFICIAL USE ONLY 6

3 System Overview

3.1 Security Categorization

The FIPS 199 Security Categorization of a Federal Information and Information System publication determines the risk impact level of data vulnerability exploitation. The identified impact level sets the security control baseline that needs to be tested. The categorization for <System Acronym> determined by the FIPS 199 publication is a Moderate baseline. The NIST 800-53 Rev 4. <Moderate> baseline of controls are assessed during the security assessment.

3.2 System Description and Purpose

<In the sections below, insert a general description of the information system. Use a description that is consistent with the description found in the SSP. The description must only differ from the description in the SSP if additional information is going to be included that is not available in the SSP or if the description in the SSP is not accurate.>

TMP V1.3 FY17 UNCLASSIFIED // FOR OFFICIAL USE ONLY 7

4 Assessment Methodology A summary of the assessment methodologies used to conduct the security assessment for the <System Acronym> subsystems are in the following steps:

• Perform tests on the listed controls in the <System Acronym> SAP and record the results

• Identify vulnerabilities related to <System Acronym>

• Identify known threats and determine which threats are associated with the cited vulnerabilities

• Analyze risks based on vulnerabilities and associated threats after mitigating controls are implemented

• Recommend corrective actions for controls that are not satisfied (other than satisfied)

• Document all security assessment results, which include identified unmitigated risks, mitigated risks, and recommend corrective actions.

4.1 Perform Tests

Coalfire Federal Services performed security tests on the <Sys tem Acronym> subsystems, which concluded on < M M D D , Y Y Y Y >. The results of the tests are documented within the Security Risk Traceability Matrix (SRTM) in Appendix B. The SRTM serves as input to this SAR.

4.1.1 Assessment Deviations

Table 7 contains any deviations from the SAP if applicable. Coalfire Federal Services did not deviate from the testing plan.

Table 7: List of Assessment Deviations

Deviation ID Deviation Description Justification

4.2 Identification of Vulnerabilities

Coalfire Federal Services conducts an assessment to identify vulnerabilities for <S ys tem Ac ro n ym > subsystems. These vulnerabilities should have controls in place to mitigate the risk of exploitation.

A vulnerability is an inherent weakness in an information system that can be exploited by a threat or threat agent, resulting in an undesirable impact on the protection of the confidentiality, integrity, or availability of the system (application and associated data). A vulnerability may be due to a design flaw or error in a configuration that makes the network or a host on the network, susceptible to malicious attacks from local or remote users. Vulnerabilities can exist in multiple areas of the system or facilities, such as in firewalls, application servers, Web servers, operating systems, or fire suppression systems.

Whether or not a vulnerability has the potential to be exploited by a threat depends on a number of variables including (but not limited to):

• The strength of the security controls in place

• The ease at which a human actor could purposefully launch an attack

• The probability of an environmental event or disruption in a given local area

TMP V1.3 FY17 UNCLASSIFIED // FOR OFFICIAL USE ONLY 8

An environmental disruption is usually unique to a geographic location. Depending on the level of the risk exposure, the successful exploitation of a vulnerability can vary from disclosure of information about the host to a complete compromise of the host. Risk exposure to organizational operations can affect the business mission, functions, and/or reputation of the organization.

4.3 Consideration of Threats

A threat is an adversarial force or phenomenon that could affect the availability, integrity, or confidentiality of an information system, its networks, and the facility that houses the hardware and software. A threat agent is an element that provides the delivery mechanism for a threat. An entity that initiates the launch of a threat agent is referred to as a threat actor.

A threat actor might purposefully launch a threat agent (e.g., a terrorist igniting a bomb). A threat actor could also be a trusted employee that acts as an agent by making an unintentional human error (e.g., a trusted employee clicks on a phishing email that downloads malware). Threat agents may also be environmental in nature with no purposeful intent (e.g., a hurricane). Threat agents working alone, or in concert, exploit vulnerabilities to create incidents. FISMA categorizes threats using a threat origination taxonomy of purposeful (P), unintentional (U), or environmental (E) type threats as described in Table 8.

Table 8: Threat Categories and Type Identifiers

Threat Origination Category Type Identifier

Threats launched purposefully P

Threats created by unintentional human or machine error U

Threats caused by environmental agents or disruptions E

Threat actors for a variety of reasons launch purposeful threats and the reasons may never be fully known.

Curiosity, monetary gain, political gain, social activism, revenge or many other driving forces could motivate threat actors. It is possible that some threats could have more than one threat origination category.

Some threat types are more likely to occur than others are. FISMA considers threat types to help determine the likelihood that a vulnerability could be exploited. The threat table shown in

Table 9 describes typical threats to information systems; these threats have been considered for <System Acronym>.

TMP V1.3 FY17 UNCLASSIFIED // FOR OFFICIAL USE ONLY 9

Table 9: Potential Threats

ID Threat Name Type Identifier Description

Typical Impact to Data or System

Confidentiality Integrity Availability T-1. Alteration U, P, E Alteration of data, files, or records. Modification

T-2. Audit Compromise P

An unauthorized user gains access to the audit trail and could cause audit records to be deleted or modified, or prevents future audit records from being recorded, thus masking a security relevant event.

Modification or destruction

Unavailable accurate records

T-3. Bomb P An intentional explosion.

Modification or destruction

Denial of service

T-4. Communications Failure U, E Cut fiber optic lines, trees falling on telephone lines. Denial of service

T-5. Compromising Emanations P

Eavesdropping can occur via electronic media directed against large scale electronic facilities that do not process classified National Security Information.

Disclosure

T-6. Cyber Brute Force P

Unauthorized user could gain access to the information systems by random or systematic guessing of passwords, possibly supported by password cracking utilities.

Disclosure Modification or destruction

Denial of service

T-7. Data Disclosure Attack P

An attacker uses techniques that could result in the disclosure of sensitive information by exploiting weaknesses in system design or configuration.

Disclosure

T-8. Data Entry Error U

Human inattention, lack of knowledge, and failure to cross-check system activities could contribute to errors becoming integrated and ingrained in automated systems.

Modification

T-9. Denial of Service Attack P

An adversary uses techniques to attack a single target rendering it unable to respond; could cause denial of service for users of the targeted information systems.

Denial of service

TMP V1.3 FY17 UNCLASSIFIED // FOR OFFICIAL USE ONLY 10

Identifier Description

Typical Impact to Data or System

Confidentiality Integrity Availability

T-10. Distributed Denial of Service Attack P

An adversary uses multiple compromised information systems to attack a single target; could cause denial of service for users of the targeted information systems.

Denial of service

T-11. Earthquake E

Seismic activity can damage the information system or its facility. Refer to the following document for earthquake probability maps http://pubs.usgs.gov/of/2008/1128/pdf/OF08- 1128_v1.1.pdf .

Destruction Denial of service

T-12. Electromagnetic Interference E, P

Disruption of electronic and wire transmissions could be caused by high frequency (HF), very high frequency (VHF), and ultra-high frequency (UHF) communications devices (jamming) or sun spots.

Denial of service

T-13. Espionage P The illegal, covert act of copying, reproducing, recording, photographing or intercepting sensitive information.

Disclosure Modification

T-14. Fire E, P Fire can be caused by arson, electrical problems, lightning, chemical agents, or other unrelated proximity fires.

Destruction Denial of service

T-15. Floods E Water damage caused by flood hazards can be caused by proximity to local flood plains. Flood maps and base flood elevation must be considered.

Destruction Denial of service

T-16. Fraud P

Intentional deception regarding data or information about an information system could compromise the confidentiality, integrity, or availability of an information system.

Disclosure Modification or destruction

Denial of service

T-17.

Hardware or Equipment Failure

E Hardware or equipment may fail due to a variety of reasons. Denial of service

T-18. Hardware Tampering P An unauthorized modification to hardware that alters the proper functioning of equipment in a manner that Modification Denial of service http://pubs.usgs.gov/of/2008/1128/pdf/OF08-1128_v1.1.pdf http://pubs.usgs.gov/of/2008/1128/pdf/OF08-1128_v1.1.pdf

TMP V1.3 FY17 UNCLASSIFIED // FOR OFFICIAL USE ONLY 11

Typical Impact to Data or System

Confidentiality Integrity Availability degrades the security functionality provided by the asset.

T-19. Hurricane E A category 1, 2, 3, 4, or 5 land falling hurricane could impact the facilities that house the information systems. Destruction Denial of service

T-20. Malicious Software P Software that damages a system such a virus, Trojan, or worm.

Modification or destruction

Denial of service

T-21. Phishing Attack P

Adversary attempts to acquire sensitive information such as usernames, passwords, or SSNs, by pretending to be communications from a legitimate/trustworthy source.

Typical attacks occur via email, instant messaging, or comparable means; commonly directing users to Web sites that appear to be legitimate sites, while actually stealing the entered information.

Disclosure Modification or destruction

Denial of service

T-22. Power Interruptions E

Power interruptions may be due to any number of reasons such as electrical grid failures, generator failures, uninterruptable power supply (UPS) failures (e.g. spike, surge, brownout, or blackout).

Denial of service

T-23. Procedural Error U An error in procedures could result in unintended consequences. Disclosure

Modification or destruction

Denial of service

T-24. Procedural Violations P Violations of standard procedures. Disclosure

Modification or destruction

Denial of service

T-25. Resource Exhaustion U

An errant (buggy) process may create a situation that exhausts critical resources preventing access to services.

Denial of

TMP V1.3 FY17 UNCLASSIFIED // FOR OFFICIAL USE ONLY 12

Typical Impact to Data or System

Confidentiality Integrity Availability

T-26. Sabotage P Underhanded interference with work.

Modification or destruction

Denial of service

T-27. Scavenging P Searching through disposal containers (e.g., dumpsters) to acquire unauthorized data. Disclosure

T-28. Severe Weather E

Naturally occurring forces of nature could disrupt the operation of an information system by freezing, sleet, hail, heat, lightning, thunderstorms, tornados, or snowfall.

Destruction Denial of service

T-29. Social Engineering P

An attacker manipulates people into performing actions, divulging confidential information, or providing access to computer systems or facilities.

Disclosure

T-30. Software Tampering P

Unauthorized modification of software (e.g., files, programs, database records) that alters the proper operational functions.

destruction

T-31. Terrorist P An individual performing a deliberate violent act could use a variety of agents to damage the information system, its facility, and/or its operations.

destruction

Denial of service

T-32. Theft P An adversary could steal elements of the hardware. Denial of service

T-33. Time and State P

An attacker exploits weaknesses in timing or state of functions to perform actions that would otherwise be prevented (e.g., race conditions, manipulation of user state).

Disclosure Modification Denial of service

T-34. Transportation Accidents E

Transportation accidents include train derailments, river barge accidents, trucking accidents, and airline accidents. Local transportation accidents typically occur when airports, sea ports, railroad tracks, and major trucking routes occur in close proximity to systems facilities. Likelihood of HAZMAT cargo must

Destruction Denial of

TMP V1.3 FY17 UNCLASSIFIED // FOR OFFICIAL USE ONLY 13

Typical Impact to Data or System

Confidentiality Integrity Availability be determined when considering the probability of local transportation accidents.

T-35. Unauthorized Facility Access P

An unauthorized individual accesses a facility which may result in comprises of confidentiality, integrity, or availability.

Disclosure Modification or destruction

Denial of service

T-36. Unauthorized Systems Access P An unauthorized user accesses a system or data. Disclosure

Modification destruction

T-37. Volcanic Activity E

A crack, perforation, or vent in the earth’s crust followed by molten lava, steam, gases, and ash forcefully ejected into the atmosphere. For a list of volcanoes in the U.S. see:

http://volcanoes.usgs.gov/about/volcanoes/volcanolist.

php .

Destruction Denial of service http://volcanoes.usgs.gov/about/volcanoes/volcanolist.php http://volcanoes.usgs.gov/about/volcanoes/volcanolist.php

TMP V1.3 FY17 UNCLASSIFIED // FOR OFFICIAL USE ONLY 14

4.4 Perform Risk Analysis

NIST identifies risk assessment as the first process in the risk management methodology. Organizations use the risk assessment to determine the extent of the potential threat and the risk associated with an information system. NIST defines Risk as “a function of the likelihood of a given threat-source’s exercising a particular vulnerability and the resulting impact of the adverse event on the organization”. The outcome of performing risk analysis yields risk exposure metrics that can be used to make risk-based decisions.

The FISMA risk analysis process is a qualitative risk analysis. In qualitative risk analysis, the risk level of exploiting a threat may be subjective and the justification for each risk is explained in terms of probability.

The following tables have probabilities associated with the likelihood and the impact level of the risk. For example, when a system is easy to exploit, it has a “Very High” likelihood that a threat could exploit the vulnerability. Likelihood definitions and probabilities are in Table 10.

Note: The likelihood levels should not be confused or used interchangeably with the security categorization of the system even though they use the some of the same terminology. The security categorization is determined by the sensitivity of the data residing on the information system and is in the FIPS 199 publication.

Table 10: Likelihood Definitions from NIST 800-30 Rev. 1 Publication

Likelihood Probability Level

Description

Very Low If the threat event is initiated or occurs, it is almost certain to have adverse impacts.

Low If the threat event is initiated or occurs, it is unlikely to have adverse impacts.

Moderate If the threat event is initiated or occurs, it is somewhat likely to have adverse impacts.

High If the threat event is initiated or occurs, it is highly likely to have adverse impacts.

Very High If the threat event is initiated or occurs, it is almost certain to have adverse impacts.

Impact refers to the magnitude of potential harm to the information system (or its data) by successful vulnerability exploitation. Definitions for the impact are in Table 11. Since exploitation has not yet occurred, these values are perception values based on available information system information if the exploitation of a vulnerability can cause significant loss to a system (or its data) then the impact is “Very High”.

Table 11: Impact Definitions from NIST 800-30 Rev. 1 Publication

Impact Probability

Description

Very Low The threat event could be expected to have a negligible adverse effect on organizational operations, organizational assets, individuals other organizations, or the Nation.

Low The threat event could be expected to have a limited adverse effect on organizational operations, organizational assets, individuals other organizations, or the Nation. A limited adverse effect means that, for example, the threat event might:

(i) cause a degradation in mission capability to an extent and duration that the organization is able to perform its primary functions, but the effectiveness of the functions is noticeably reduced; (ii) result in minor damage to organizational assets;

(iii) result in minor financial loss; or (iv) result in minor harm to individuals

TMP V1.3 FY17 UNCLASSIFIED // FOR OFFICIAL USE ONLY 15

Moderate The threat event could be expected to have a serious adverse effect on organizational operations, organizational assets, individuals other organizations, or the Nation. A serious adverse effect means that, for example, the threat event might:

(i) cause a significant degradation in mission capability to an extent and duration that the organization is able to perform its primary functions, but the effectiveness of the functions is significantly reduced; (ii) result in significant damage to organizational assets; (iii) result in significant financial loss; or (iv) result in significant harm to individuals that does not involve loss of life or serious life-threatening injuries.

High The threat event could be expected to have a severe or catastrophic adverse effect on organizational operations, organizational assets, individuals, other organizations, or the Nation. A severe or catastrophic adverse effect means that, for example, the threat event might: (i) cause a severe degradation in or loss of mission capability to an extent and duration that the organization is not able to perform one or more of its primary functions; (ii) result in major damage to organizational assets; (iii) result in major financial loss; or (iv) result in severe or catastrophic harm to individuals involving loss of life or serious life-threatening injuries.

Very High The threat event could be expected to have multiple severe or catastrophic adverse effects on organizational operations, organizational assets, individuals, other organizations, or the Nation.

The combination of the Likelihood Probability and the Impact Probability creates the risk exposure. The risk exposure matrix shown in Table 12 presents the same likelihood and impact severity ratings as those found in NIST SP 800-30 Rev. 1 Risk Management Guide for Information Technology Systems.

Table 12: Risk Exposure Ratings from NIST 800-30 Rev. 1 Publication

Likelihood Impact

Very Low Low Moderate High Very High

Very High Very Low Low Moderate High Very High

High Very Low Low Moderate High Very High

Moderate Very Low Low Moderate Moderate High

Low Very Low Low Low Low Moderate

Very Low Very Low Very Low Very Low Very Low Very Low

Using Table 12 as a reference, Coalfire Federal Services reviewed all identified vulnerabilities and assigned a risk exposure located in the <System Acronym> SRTM in Appendix B.

Documenting the results of security control testing creates a record of the security posture for the system at a given moment in time. The record can be used by the AO to make risk-based decision and to create plans of action to mitigate unacceptable residual risks.

FISMA requires that a Plan of Action and Milestones (POA&M) be developed. The POA&M is a mitigation plan designed to address specific residual security risks and includes information on costing, resources, and target dates for remediation efforts resolving the identified security weaknesses. The plan is utilized as the primary mechanism for tracking all the residual risks and other issues. SSA will leverage the SAR to create a POA&M for <System Acronym>.

TMP V1.3 FY17 UNCLASSIFIED // FOR OFFICIAL USE ONLY 16

5 Security Assessment Results This section describes all security risks found during assessment. The following elements for each security risk are reported.

• Identifier

• Name

• Source of Discovery

• Description

• Affected internet protocol (IP) Address/Hostname/Database

• Applicable Threats

• Likelihood (before mitigating controls/factors)

• Impact (before mitigating controls/factors)

• Risk Exposure (before mitigating controls/factors)

• Risk Statement

• Mitigating Controls/Factors

• Likelihood (after mitigating controls/factors)

• Impact (after mitigating controls/factors)

• Risk Exposure (after mitigating controls/factors)

• Recommendation

Below is a description of the SAR security risk elements.

• Identifier: All weaknesses are assigned a vulnerability identifier (ID) in the form of V#-Security Control ID. For example, the first vulnerability listed would be reported as V1-AC-2(2) if the vulnerability is for control ID AC-2(2). If there are multiple vulnerabilities for the same security control ID, the first part of the vulnerability ID must be incremented, for example V1-AC-2(2), V2-

AC-2(2).

• Name: A short, unique name for each vulnerability.

• Source of Discovery: The source of discovery refers to the method that was used to discover the vulnerability (e.g., web application scanner, manual testing, security test procedure workbook, interview, document review). References must be made to scan reports, security test case procedure IDs, staff that were interviewed, manual test results, and document names. All scans reports are attached in Appendix C, Appendix D, Appendix E, and Appendix F. Results of manual tests can be found in Appendix G. If the source of discovery is from one of the security test procedure workbooks, a reference must point to the workbook name, the sheet number, and the cell number. Workbook tests results are found in Appendix B. If the source of discovery is from an interview, the date of the interview and the people who were present at the interview are named.

If the source of discovery is from a document, the document must be named.

TMP V1.3 FY17 UNCLASSIFIED // FOR OFFICIAL USE ONLY 17

• Description: All security weaknesses must be described in enough detail to be reproduced by the stakeholder, the Information System Security Officer (ISSO), or the AO. If a test was performed manually, the exact manual procedure and any relevant screenshots must be included. If a test was performed using a tool or scanner, a description of the reported scan results for that vulnerability must be included along with the vulnerability identifier (e.g., Common Vulnerabilities and Exposures (CVE), Common Vulnerability Scoring System (CVSS), Nessus Plugin ID) and screenshots of the particular vulnerability being described. If the tool or scanner reports a severity level, that level must be reported in this section. Any relevant login information and role information must be included for vulnerabilities discovered with scanners or automated tools. If any security weaknesses affect a database transaction, a discussion of atomicity violations must be included.

• Affected IP Address/Hostname(s)/Database: For each reported vulnerability, all affected IP addresses/hostnames/databases must be included. If multiple hosts/databases have the same vulnerability, list all affected hosts/databases.

• Applicable Threats: The applicable threats describe the unique threats that have the ability to exploit the security vulnerability. (Use threat numbers from Table 10.)

• Likelihood (before mitigating controls/factors): Very High, High, Moderate, Low, or Very Low (see Table 11).

• Impact (before mitigating controls/factors): Very High, High, Moderate, Low, or Very Low (see Table 12).

• Risk Exposure (before mitigating controls/factors): Very High, High, Moderate, Low, or Very Low (see Table 13).

• Risk Statement: Provide a risk statement that describes the risk to the business. (See examples in Table 8). Also indicate whether the affected machine(s) is/are internally or externally facing.

• Mitigating Controls/Factors: Describe any applicable mitigating controls/factors that could downgrade the likelihood or risk exposure. Also indicate whether the affected machine(s) is/are internally or externally facing. Include a full description of any mitigating factors and/or compensating controls if the risk is an operational requirement.

• Likelihood (after mitigating controls/factors): Moderate or Low (see Table 11) after mitigating control/factors have been identified and considered.

• Impact (after mitigating controls/factors): Moderate or Low (see Table 12) after mitigating control/factors have been identified and considered.

• Risk Exposure (after mitigating controls/factors): Moderate or Low (see Table 13) after mitigating controls/factors have been identified and considered.

• Recommendation: The recommendation describes how the vulnerability should be resolved.

Indicate if there are multiple ways that the vulnerability could be resolved or recommendation for acceptance of operational requirement.

5.1 Security Assessment Summary

<Two (2) vulnerabilities, (0 high, zero moderate, 2 low)> have been discovered as part of the manual security assessment testing. Vulnerability scans provided did not provide enough information to provide analysis of scan vulnerability to assessment result.

The vulnerabilities summary is contained in the following embedded file:

TMP V1.3 FY17 UNCLASSIFIED // FOR OFFICIAL USE ONLY 18

Table 13: Risk Exposure

T2 Risk Exposure Table.xlsx

<Embed applicable system’s Risk Exposure table, EXAMPLE attached.>

6 Non-conforming Controls In some cases, the initial risk exposure to the system has been adjusted due to either corrections that occurred during testing or to other mitigating factors. Additional detail is provided in the following sections.

6.1 Risks Corrected During Testing

Any risks that were discovered during the testing of the <System Acronym> subsystems and subsequently mitigated prior to authorization are listed in Table 14. Coalfire Federal Services verified risks corrected during testing. The verification method used to determine correction is noted in the right-hand column of Table 14.

Table 14: Summary of Risks Corrected During Testing

Identifier Description Source of Discovery

Initial Risk Exposure

Remediation Description

Date of Remediation

Verification Statement/Testing

Procedures

6.2 Risks with Mitigating Factors

Risks that have had their severity levels changed due to mitigating factors are summarized in Table 15.

The factors used to justify changing the initial risk exposure rating are noted in the right-hand column of the table. See Table 13 for more information on these risks.

Table 15: Summary of Risks with Mitigating Factors

Identifier Description Source of Discovery

Initial Risk Exposure

Current Risk Exposure

Description of Mitigating Factors

6.3 Risks Remaining Due to Operational Requirements

Risks that reside in the <system acronym> that cannot be corrected due to operational constraints are summarized in Table 17. An explanation of the operational constraints and risks are included in Table 17 as well as in the appropriate security assessment test cases and SSP. Because these risks will not be corrected, they are not tracked in the POA&M. See Table 14for more information on these risks.

TMP V1.3 FY17 UNCLASSIFIED // FOR OFFICIAL USE ONLY 19

Table 16: Summary of Risks Remaining Due to Operational Factors

Identifier Description Source of Discovery Current Risk Exposure Operational Requirements

Rationale

TMP V1.3 FY17 UNCLASSIFIED // FOR OFFICIAL USE ONLY 20

7 Risks Known for Interconnected Systems Inherent relationships between the system and other interconnected systems may affect the overall system security posture. A summary of the risks known for systems that connect to <System Acronym> is provided in Table 17.

Table 17: Risks from Interconnected Systems

System Authorization Date/Status

Date of POA&M Control Family Identifier

8 Recommendations <System Acronym> subsystem risks that were discovered during the assessment have an impact on the security posture of the SSA Federal Agency as a whole. These risks must be mitigated and Coalfire Federal Services has made recommendations in the Risk Exposure section, Table 14. These recommendations should be addressed by the SAM, system owners, OIS, and other stakeholders that have a responsibility for the controlling the overall risk of <System Acronym>.

TMP V1.3 FY17 UNCLASSIFIED // FOR OFFICIAL USE ONLY 21

Appendix A. Acronyms and Terms Acronyms and terms used throughout this SAR are defined in Table 18.

Table 18: Acronyms and Terms

Acronym/Term SAR Acronym Definitions

AC Associate Commissioner

AC Access Control

AO Authorizing Official

ARB Architecture Review Board

ART Analysis and Reporting Tool

AU Audit and Accountability

BRI Benefit Rate Increase

BSM Boundary Scope Memo

CA Security Assessment and Authorization

CCB Configuration Control Board

CIC Customer Information Control System

CM Configuration Management

CMP Contingency Management Plan

COTR Contract Officer’s Technical Representative

CSAM Cyber Security Assessment & Management

CSO Component Security Officer

CVE Common Vulnerabilities and Exposures

CVSS Common Vulnerability Scoring System

DCS Deputy Commissioner for Systems

DSPP Division of Security Policy & PII

EPECS Electronic Personal Enrollment Credential System

EPO ePolicy Orchestrator

FIPS Federal Information Processing Standard

FISMA Federal Information Security Modernization Act

FOIA Freedom of Information Act

HRMIS Human Resources Management Information System

HRODS Human Resources Operational Data Store

HSPD Homeland Security Presidential Directive

IA Identification and Authentication

ID Identification

TMP V1.3 FY17 UNCLASSIFIED // FOR OFFICIAL USE ONLY 22

IP Internet Protocol

ISCP Information System Contingency Plan

ISO Information Security Officers

ISP Information Security Policy

ISSO Information System Security Officer

LIS Low Income Subsidy

NIST National Institute of Standards and Technology

NSC National Support Center

OIS Office of Information Security

OMB Office of Management and Budget

OSOHE Office of Systems Operations and Hardware Engineering

OTSO Office of Telecommunications and Systems Operations

PAM Payment Application Modernization

PCCB Project Configuration Control Board

PIN Personal Identification Number

PIV Personal Identification Verification

PL Public Law

PL (Control) Planning

PM Program Manager

POA&M Plan of Action and Milestones

PRIDE Project Resource Guide

PS (Control) Personnel Security

P, U, E Purposeful, Unintentional, Environmental

SA System and Services Acquisition

SAM Security Authorization Manager

SAP Security Assessment Plan

SARA Security Administration Report Application (User Guide)

SAR Security Assessment Report

SC Systems and Communications Protection

SDLC System Development Life Cycle

SI System and Information Integrity

SMACS Security Management Access Control Systems

SO System Owner

SOC Security Operation Division

TMP V1.3 FY17 UNCLASSIFIED // FOR OFFICIAL USE ONLY 23

SP Special Publication

SRC System Release Certificate

SRTM Security Requirements Traceability Matrix

SSA Social Security Administration

SSC Secondary Support Center

SSP System Security Plan

SVR Security Violations Report

Threat An adversarial force or phenomenon that could affect the availability, integrity, or confidentiality of an information system, its networks, and the facility that houses the hardware and software.

Threat Actor An entity that initiates the launch of a threat agent is referred to as a threat actor.

Threat Agent An element that provides the delivery mechanism for a threat.

UPS uninterruptable power supply

USC United States Code

Vulnerability An inherent weakness in an information system that can be exploited by a threat or threat agent, resulting in an undesirable impact in the protection of the confidentiality, integrity, or availability of the system (application and associated data).

TMP V1.3 FY17 UNCLASSIFIED // FOR OFFICIAL USE ONLY 24

Appendix B. Security Risk Traceability Matrix (SRTM) The Security Risk Traceability Matrix (SRTM) with test results and test procedures are within the following embedded document in Table 19.

Table 19: Security Test Procedure Workbook

T2 SRTM

Worksheet.xlsx

<Embed the applicable system’s Security Risk Traceability Matrix (SRTM), EXAMPLE attached.>

TMP V1.3 FY17 UNCLASSIFIED // FOR OFFICIAL USE ONLY 25

Appendix C. Infrastructure Scan Results The Nessus scanner along with the McAfee ePolicy Orchestrator (EPO) deployed by the SOC was used to scan SSA servers. Associated Windows Database servers that have the EPO agent deployed within the < S y s t e m A c r o n y m > boundary were scanned. The other <System Acronym> servers did not have any vulnerability scanning tools available, which allowed for scanning of mainframe or storage hardware, and therefore were not scanned.

Infrastructure Scans: Inventory of Items Scanned Table 20 provides an inventory of infrastructure items scanned during this assessment.

Table 20: Inventory of Items Scanned

T2 Scanned Inventory Items.xlsx

<Embed the applicable system’s Inventory of Items Scanned, EXAMPLE attached.>

Infrastructure Scans: Raw Scan Results Table 21 has the <System Acronym> raw scan results:

Table 21: Raw Scan Results

T2 Raw Scan Results.xlsx

<Embed the applicable system’s Raw Scan Results, EXAMPLE attached.>

Infrastructure Scans: False Positive Reports Table 22 provides a list of false positive reports collected during infrastructure scans if applicable.

Table 22: Infrastructure Scans: False Positive Reports

ID# IP Address Scanner Severity Level Finding False Positive Explanation

TMP V1.3 FY17 UNCLASSIFIED // FOR OFFICIAL USE ONLY 26

Appendix D. Database Scan Results Database scan results are included in this appendix.

Database Scans: Inventory of Databases Scanned Table 23 provides an inventory of any databases scanned during this assessment if applicable.

Table 23: Inventory of Databases Scanned

IP Address Hostname Software and Version Function Comment

Database Scans: False Positive Reports Table 24 provides a list of false positive reports collected during database scans if applicable.

Table 24: Database Scans: False Positive Reports

TMP V1.3 FY17 UNCLASSIFIED // FOR OFFICIAL USE ONLY 27

Appendix E. Web Application Scan Results Web application scan results are included in this appendix.

Web Application Scans: Inventory of Web Applications Scanned Table 25 provides an inventory of all web…