96-S Exhibit Q Risk Assessment Report

UNCLASSIFIED // FOR OFFICIAL USE ONLY

UNCLASSIFIED // FOR OFFICIAL USE ONLY

Exhibit Q

Social Security Administration (SSA)

Security Categorization: <Enter Categorization>

Risk Assessment Report (RAR)

FOR

<System Name> (<Acronym>)

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

Prepared by

Office of Information Security

Social Security Administration <System Name>

Version <x.x>

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).

All black text shall remain unchanged.>

FY17 UNCLASSIFIED // FOR OFFICIAL USE ONLY iii

Document Revision History Revision History Date Summary of Changes Author

1.0 <Month DD, YYYY> Initial release <name>

<x.x> <Month DD, YYYY> <description> <name>

<x.x> <Month DD, YYYY> <description> <name>

FY17 UNCLASSIFIED // FOR OFFICIAL USE ONLY iv

Table of Contents

1 RISK ASSESSMENT REPORT (RAR) BACKGROUND

2 RAR EXECUTIVE SUMMARY FOR <SYSTEM NAME>

3 <SYSTEM NAME> SYSTEM PURPOSE

3.1 System Name/Title/Unique Identifier

3.2 Responsible Organization

3.3 Security Categorization

4 RISK ASSESSMENT APPROACH

4.1 Risk Assessment Purpose

4.2 Risk Assessment Objective

4.3 Risk Assessment Scope

4.4 Limitations

4.5 Risk Assessors

4.6 Results

4.7 Recommendation

5 SUMMARY OF FINDINGS

APPENDIX A. REFERENCE DOCUMENTS

FY17 UNCLASSIFIED // FOR OFFICIAL USE ONLY v

List of Tables Table 1: <SYSTEM ACRONYM> Points of Contact Table 2: <System Name> Security Categorization Table 3: Assessment Team Points of Contact Table 4: Overall Risk Level Table 5: <SYSTEM ACRONYM> Results Summary Table 6: Acronym List

UNCLASSIFIED // FOR OFFICIAL USE ONLY 6

1 Risk Assessment Report (RAR) Background The Office of Management and Budget (OMB) directive requires the Social Security Administration (SSA) to assess and re-authorize its major information technology (IT) systems at least once every three years and in the event of a major change, when that change occurs. This information must be reported in the annual Federal Information Security Modernization Act (FISMA) report to OMB and Congress during the fourth quarter (Q4) of each year. OMB has directed Chief Information Officers (CIO) of Federal agencies to follow the guidance found in the National Institute of Standards and Technology (NIST) Special Publication (SP) 800-37 Revision 1, Guide for Applying the Risk Management Framework to Federal Information Systems, to assess and re-authorize their information systems. This security authorization process contains subordinate efforts including performing risk-based reviews of the systems, developing/updating system security plans (SSP), and assessing and testing the security controls implemented for SSA’s information systems.

2 RAR Executive Summary for <System Name> The Office of Information Security (OIS) contracted with Coalfire Federal Services, a third party assessment organization (3PAO), to conduct a system specific risk assessment on <system name> (<ACRONYM>).

The acting Director of the Division of Compliance and Assessments, and the Security Authorization Manager (SAM) of <SYSTEM ACRONYM> approved the controls selected for this risk assessment. Thirty-two (32) controls were tested over eleven (11) different NIST 800-53 Rev 4 control families. These controls were selected out of the <system categorization> baseline due to <SYSTEM ACRONYM> being categorized as a <system categorization> system as per the FIPS 199. During the assessment, there were <55 manual tests conducted, 62 interviews, and 84 document examinations>. Each of these is a requirement of a specific control. At the conclusion of the assessment, two controls were identified as “not implemented”. It should be noted that these controls have since been identified as common and should be added to the common control list. The controls that were not implemented, identified as PS4 (personnel termination), and PS 5 (personnel transfer), requires the SSA Information Security Policy (ISP) to document specific exit interview security debrief policies and procedures and the defined time period in which these must be carried out. Please refer to Table 5 for specific details. The likelihood of these vulnerabilities being exploited combined with the potential system impact is considered an overall LOW risk to the system. It is recommended that the <system name> assigned representative from the Security Assessment and Authorization Branch (SAAB) work with the System Authorization Manager (SAM) to mitigate these risks.

Due to the overall identified risk being LOW, it is recommended that this be considered an acceptable risk and the system be given an authority to operate (ATO) for the next three years.

3 <system name> System Purpose The <system name> (<ACRONYM>) system, has a <system categorization> Security Categorization. The boundaries are designed to aid SSA in the accomplishment of its mission to provide cost-effective and reliable services to other Federal agencies, and the public at large.

<Insert detailed information>

Coalfire Federal Services’ objective is to provide IT Independent Verification and Validation (IV&V) Support Services for <SYSTEM ACRONYM>.

3.1 System Name/Title/Unique Identifier

System/Application Name: <system name> (<SYSTEM ACRONYM>)

Unique Identifier : <016-00-SSA/DCS-M-001>

UNCLASSIFIED // FOR OFFICIAL USE ONLY 7

3.2 Responsible Organization

Table 1: <SYSTEM ACRONYM> Points of Contact

Title II Batch POCs.xlsx

Title II Internet Applications POCs.xlsx

<Embed the applicable system’s POCs, EXAMPLE attached.>

UNCLASSIFIED // FOR OFFICIAL USE ONLY 8

3.3 Security Categorization

This authorization boundary has been categorized as <system categorization> risk according to FIPS

199. Refer to Table 5 below for supporting documentation regarding the determination of the application’s security categorization.

Table 2: <System Name> Security Categorization

Information Type Confidentiality Integrity Availability

Accounting Mission Area: Financial Management Explanation: Selected risk values derived from NIST SP-800- 60, and FIPS 199, considering SSA business case.

L M L

Payments Mission Area: Financial Management Explanation: Selected risk values derived from NIST SP-800- 60, and FIPS 199, considering SSA business case.

L M L

Reporting & Information Mission Area: Financial Management Explanation: Based on the protection requirements for confidentiality, integrity and availability, the overall system sensitivity is <SYSTEM CATEGORIZATION>. The loss, misuse or unauthorized access to Agency data can be expected to have a serious adverse effect on SSA operations and assets.

L M L

Entitlement Event Information Mission Area: General Government Explanation: Selected risk values derived from NIST SP-800- 60, and FIPS 199, considering SSA business case.

M M M

Personal Identity and Authentication Mission Area: General Government

M M M

Information Sharing Mission Area: Information and Technology Management Explanation: Selected risk values derived from NIST SP-800- 60, and FIPS 199, considering SSA business case.

N/A N/A N/A

Overall M M M

4 Risk Assessment Approach

4.1 Risk Assessment Purpose

The purpose of this Risk Assessment Report (RAR) is to summarize the residual risk identified during the security assessment of <SYSTEM ACRONYM>. Risk is a factor derived from a vulnerability that can be exploited and the likelihood that it will be exploited. Please see Appendix A for the NIST 800-60 Volume II publication for the definition of risk.

4.2 Risk Assessment Objective

The objective of the risk assessment is to identify any controls that are not fully implemented as required by FISMA. Controls that are not implemented pose a measureable risk to SSA and that risk must be mitigated in a timely manner based on the level or risk the non-implemented control creates. For example, a low risk may only require an update to a policy or a POA&M that the system’s SAM must execute. Another example is a High risk that must have immediate action taken by the SAM and other stakeholders in order to prevent a threat actor(s) from exploiting the discovered risk.

UNCLASSIFIED // FOR OFFICIAL USE ONLY 9

4.3 Risk Assessment Scope

The previous system specific risk assessment was conducted on <SYSTEM ACRONYM> in <date>. The residual risk was identified and submitted to the SSA’s CIO. This submission was in accordance with OMB and FISMA guidelines to present the risk level of <SYSTEM ACRONYM> and ask for the ATO <SYSTEM ACRONYM> for the next three years. The CIO granted the ATO on <Month DD, YYYY> and allowed <SYSTEM ACRONYM> to operate from <Month DD, YYYY> to <Month DD, YYYY>.

A new risk assessment is required by OMB and FISMA in order to identify the current residual risk and any risks associated with controls that are not fully implemented. The assessed controls were selected based on the <SYSTEM ACRONYM> Security Assessment Plan (SAP) approved by the OIS Director and the

<SYSTEM ACRONYM> SAM.

In addition to the controls selected, SSA uses the Nessus scanner along with the McAfee ePolicy Orchestrator (EPO) deployed by the SOC to look for signature based vulnerabilities in accordance with the SSA ISP. Associated Windows Database servers that have the EPO agent deployed within the <SYSTEM ACRONYM> boundary were scanned. The other <SYSTEM ACRONYM> servers did not have any vulnerability scanning tools available that could scan mainframe or storage hardware, and therefore were not scanned.

The risk assessment was performed in accordance with all applicable laws, regulations, rules and orders of all governmental agencies and authorities. A complete list of referenced publications and regulations can be found in Appendix A. All risks associated with <SYSTEM ACRONYM> that were identified during the assessment and the potential impact of those risks are documented in this RAR.

The RAR complies with the following SSA guidance:

• SSA ISP

4.4 Limitations

The <SYSTEM ACRONYM> subsystems, which reside within the National Support Center (NSC), rely on the Office of Systems Operations and Hardware Engineering (OSOHE) for hardware, software, and maintenance support. Additionally, user access and user profile provisioning for <SYSTEM ACRONYM> subsystems residing on the mainframe, are provided by CA Top Secret, and managed by the Office of Systems Operations and Hardware Engineering (OSOHE), not by <SYSTEM ACRONYM>. Therefore, some access controls specific to <SYSTEM ACRONYM> are tested during an enterprise level common control assessment, and not during the <SYSTEM ACRONYM> system specific assessment reported within this RAR.

This assessment was limited to the 32 system specific controls as listed in the approved SAP.

4.5 Risk Assessors

The participants in this risk assessment included the following Coalfire Federal Services personnel:

Table 3: Assessment Team Points of Contact

Name Role Contact Information

<TJ Crews> Program Manager <Tj.crews@ssa.gov>

<Kenneth Free> Lead Assessor (Senior Analyst) <kenneth.free@ssa.gov>

<Gregory Bonham> Junior Assessor <gregory.bonham@ssa.gov>

<Thomas G. Volpe, Sr.> Lead Assessor (Surge Support) <Thomas.G.Volpe@ssa.gov> http://isp.ssahost.ba.ssa.gov/Policy/section_3.htm#3.4 mailto:Tj.crews@ssa.gov mailto:kenneth.free@ssa.gov mailto:gregory.bonham@ssa.gov mailto:Thomas.G.Volpe@ssa.gov

UNCLASSIFIED // FOR OFFICIAL USE ONLY 10

The following techniques and NIST/FIPS publications were used to gather information relevant to the

<SYSTEM ACRONYM>:

• NIST SP 800-60 Volume II Revision 1/ and FIPS 199. The Risk Assessment (RA) Team utilized the <SYSTEM ACRONYM> Security Categorization, dated February 16, 2017 to determine associated system security categorization for the <SYSTEM ACRONYM>. System security categorization determines which recommended set of minimum (baseline) security controls from NIST SP 800-53 Revision 4 must be implemented.

• NIST SP 800-53 Revision 4. The RA Team utilized NIST SP 800-53 Revision 4 to determine the recommended set of minimum-security controls. The security controls (management, operational, and technical safeguards or countermeasures) were reviewed to ensure they adequately protect the confidentiality, integrity, and availability of the <SYSTEM ACRONYM>, and that the selected security controls have been implemented, or there is a plan for future implementation.

• Interviews. Interviews were conducted on-site with the SAM, System Administrator, and Database Administrator by the RA Team to collect useful information about the <SYSTEM ACRONYM>.

Follow-up communications were conducted via email and by telephone to collect additional information about the <SYSTEM ACRONYM>.

• Examination/Document Reviews. The RA Team reviewed documentation from the SSA for <SYSTEM ACRONYM>, such as policy and implementation guidance. POA&M, and the prior Security Assessment and Authorization (SA&A) Package, including the previous SSP, Risk Assessment, and the Security Control Assessment (SCA) Plan were reviewed.

• Testing of Systems. Testing and Evaluation of security controls for <SYSTEM ACRONYM> was based on System Specific and Hybrid security controls defined by the OIS Rev4 SSA Control Inheritance Structure Worksheet with a <SYSTEM CATEGORIZATION> Baseline. Using the NIST Guidance from NIST SP 800-53A Revision 4, the RA Team tested and evaluated these controls for specified conditions that compare actual with expected behavior, the results of which are used to support the determination of security control existence, functionality, correctness, completeness, and potential for improvement over time.

4.6 Results

The overall risk level of the <SYSTEM ACRONYM> was determined to be Low, which is the combination of the likelihood of identified threats being able to exploit known system vulnerabilities and the potential the impact to <SYSTEM ACRONYM>.

Low risk indicates that corrective actions are needed and a plan must be developed to incorporate these actions within a reasonable period of time. The preliminary review of security measures for the protection of the <SYSTEM ACRONYM> identified two low threat-vulnerability pairs (risks) in the overall risk assessment as summarized below in Table 2.

Table 4: Overall Risk Level

Risk Rating Control Category

Management Operational Technical Total

Very High 0 0 0 0

High 0 0 0 0

Moderate 0 0 0 0

Low 2 0 0 2

Very Low 0 0 0 0

Total 2 0 0 2

UNCLASSIFIED // FOR OFFICIAL USE ONLY 11

4.7 Recommendation

It is the recommendation from the Office of Information Security that an issuance of an Authority to Operate (ATO) for <system name> (<ACRONYM>) be given. This recommendation comes from the assessment findings from the 3PAO that conducted a system specific security assessment. The overall security categorization of <SYSTEM ACRONYM> is <system categorization> and the findings have an overall risk of LOW.

UNCLASSIFIED // FOR OFFICIAL USE ONLY 12

5 Summary of Findings

Table 5: <SYSTEM ACRONYM> Results Summary

Item No.

Finding

(In Order by Control Family)

Threat Source Likelihood Level

Impact Level

Risk Level

Recommended Corrective Action(s)

V-1

PS-4.c.1 PS-4.c.2

Personnel Termination SSA ISP does not define the security debrief topics or policy to discuss with separating employees.

In addition, the SSA ISP has no policy, guidelines for including the security debrief actions, or SSA specific information security topics during the exit interview as defined in PS-4.c.1 and PS-4.c.2.

Insider Threat with Intent (e.g., Poorly Trained, Disgruntled, Malicious, Negligent, Dishonest, or Terminated Employees)

Insider Threat without Intent or Knowledge

Computer Crime/Hackers

Espionage (e.g., Companies, Foreign Governments, or Other Government Interests)

Low Low Low This is an agency requirement that must be reflected in the SSA ISP and is the responsibility of Division of Security Customer Service (DSCS). The Security Authorization Manager (SAM) is not responsible for updating policy. The SSA ISP should be updated to include a requirement that employees sign a Non-Disclosure Agreement (NDA), and have a security debrief to discuss the importance of not disclosing knowledge of specifics pertaining to the SSA information system environment. The ISP section 2.1.1.3 should be updated to reflect this. In addition, section

2.1.1.3 should be updated to reflect that a security debrief must be included as part of the exit interview.

Exit interview guidance is currently located here:

http://personnel.ba.s sa.gov/OPE/cpps/exi tprocedures.html

UNCLASSIFIED // FOR OFFICIAL USE ONLY 13

Item No.

Finding

(In Order by Control Family)

Threat Source Likelihood Level

Impact Level

Risk Level

Recommended Corrective Action(s)

V-2 PS-5.b.1 PS-5.b.2

Personnel Transfer SSA ISP does not define what security actions are to be taken when an employee is transferred or reassigned. The SSA ISP also does not specify the time period in which security actions that are defined in must occur.

Insider Threat with Intent (e.g., Poorly Trained, Disgruntled, Malicious, Negligent, Dishonest, or Terminated Employees)

Insider Threat without Intent or Knowledge

Low Low Low This is an agency requirement that must be reflected in the SSA ISP and is the responsibility of DSCS. The ISP section 2.4 should be updated to define what security actions need to occur, in what period of time and what personnel or role is to be identified to be notified when an employee is transferred or reassigned.

Authority To Operate (ATO)

Recommendation

Acceptance and Signature

As the Security Authorization Manager (SAM) for <system name>, I hereby certify that this Risk Assessment Report provides an accurate representation of the system and its subsystems that were assessed. I also certify that it is my recommendation based on the findings that the SSA Chief Information Officer (CIO) grant an Authority to Operate (ATO) for <system name> for the next three (3) years.

Security Authorization Manager:

<name>

As the Acting Director of the Division of Compliance and Authorization (DCA) in the Office of Information Security (OIS), I hereby certify that this Risk Assessment Report provides an accurate representation of the system and its subsystems that were assessed. I also certify that it is my recommendation based on the findings that the SSA Chief Information Officer (CIO) grant an Authority to Operate (ATO) for <system name> for the next three (3) years.

Division of Compliance and Assessments Director Steven Harkness (Acting)

UNCLASSIFIED // FOR OFFICIAL USE ONLY 14

Table 6: Acronym List

Acronym Definition AO Authorizing Official

BSM Boundary Scope Memorandum

CET Customer Engagement Tool

CICS Customer Information Control System

CIO Chief Information Officer

CSO Component Security Officer

DCA Division of Compliance and Authorization

DCS Deputy Commissioner for Systems

EPO McAfee ePolicy Orchestrator

FIPS Federal Information Processing Standard

FISMA Federal Information Security Modernization Act

FOUO For Official Use Only

ISA Interconnection Security Agreement

ISP Information Security Policy

IT Information Technology

IV&V Independent Verification and Validation

L2TP Layer 2 Tunneling Protocol

LAN Local Area Network

LIS Low Income Subsidy

MKS Mortise Kern Systems

MOA Memorandum of Agreement

MOU Memorandum of Understanding

NDA Non-disclosure Agreement

NSC National Support Center

NIST National Institute of Standards and Technology

OIS Office of Information Security

OMB Office of Management and Budget

OSOHE Office of Systems Operations and Hardware Engineering

OTSO Office of Telecommunications and System Operations

PII Personally Identifiable Information

POA&M Plan of Action and Milestones

PSC Program Service Centers

RA Risk Assessment or Risk Assessor

UNCLASSIFIED // FOR OFFICIAL USE ONLY 15

Acronym Definition RAR Risk Assessment Report

RSDI Retirement, Survivor, or Disability Insurance

SA&A Security Assessment and Authorization

SAM Security Authorization Manager

SAP System Assessment Plan

SBU Sensitive But Unclassified

SCA Security Control Assessment

SO System Owner

SP Special Publication

SSA Social Security Administration

SSP System Security Plan

VPN Virtual Private Network

3PAO Third Party assessment Organization

APPENDIX A. REFERENCE DOCUMENTS

The following documents were reviewed during the risk assessment process of the SSA’s security controls:

• Federal Information Processing Standard (FIPS) 199

• NIST Special Publication 800-30 Rev. 1, “Guide for Conducting Risk Assessments”

• Office of Management and Budget (OMB) Circular A-130.

• NIST Special Publication 800-39

• NIST Special Publication 800-60 Revision 1, Volumes 1&2

• NIST Special Publication 800-53 Revision 4

• SSA Information Security Policy (ISP)