S000000251 Attachment 11 SSA Technical Systems Security Requirements TSSR.pdf

Social Security Administration (SSA)

Electronic Information Exchange Security Requirements and Procedures for State and Local Agencies Exchanging Electronic Information with the Social Security Administration Technical System Security Requirements (TSSR)

Security Categorization: Moderate

Version 10.5

April 11, 2022 Prepared by

Office of Information Security

Social Security Administration ii

Document Revision History Date Description Version Author

12/05/2019 Converted TSSR requirements to NIST SP 800-53 rev 4 controls 10.0 OIS

02/12/2020 Added Controlled Unclassified Information (CUI) language in section 1.3

10.1 OIS

01/08/2021 Added: CA-3, CA-8, SA-11 Removed: AU-3(1), PE-5, PS-5, SC-17, SI-12 Updated: DM-2 to include SSA retention specific language, MP-2 to accurately reflect NIST language

10.2 OIS

2/19/2021 Added: VAN and Data Transmission Requirements Updated assessment language throughout document Updated assessment timeframe Updated SEQ submission requirements

10.3 OIS

11/22/2021 Added Third Party Assessment guidance (section 1.6.4) Added SRTM reference with SEQ (section 1.6)

10.4 OIS

04/07/2022 Added Cloud Services requirements (section 2, Data Transmission)

10.5 OIS

iii

Table of Contents

1 INTRODUCTION

1.1 Applicable Laws and Regulations

1.2 Applicable Standards and Guidance

1.3 Controlled Unclassified Information (CUI)

1.4 Electronic Information Exchange (EIE) Definition

1.5 Roles and Responsibilities

1.5.1 SSA Office of Information Security (OIS)

1.5.2 SSA Regional Data Exchange Coordinator (DEC)

1.5.3 Electronic Information Exchange Partner (EIEP)

1.5.4 State Transmission/Transfer Component (STC)

1.6 SSA Security Assessments

1.6.1 Documenting Security Controls in the SEQ

1.6.2 EIEP Security Assessment Participation

1.6.3 Scheduling of Onsite Assessment

2 SYSTEMS SECURITY STANDARDS AND REQUIREMENTS

2.1 Access Control

2.2 Accountability, Audit, and Risk Management

2.3 Audit and Accountability

2.4 Awareness and Training

2.5 Contingency Planning

2.6 Data Minimization and Retention

2.7 Identification and Authentication

2.8 Incident Response

2.9 Media Protection

2.10 Personnel Security

2.11 Physical and Environmental Protection

2.12 Planning

2.13 Risk Assessment

2.14 Security Assessment and Authorization

2.15 System and Communications Protection

2.16 System and Information Integrity

2.17 System and Services Acquisition

APPENDIX A. ACRONYMS

APPENDIX B. ADDITIONAL DEFINITIONS

iv

List of Tables

Table 1: Acronyms and Terms Table 2: Additional Definitions

SSA Administratively Controlled Document 5

1 Introduction Federal standards require the Social Security Administration (SSA) to maintain oversight of the information it provides to its Electronic Information Exchange Partners (EIEPs). EIEPs must protect the information with efficient and effective security controls.

This document consistently references the concept of EIEPs; however, the SSA Security Evaluation Questionnaire (SEQ) document will use the terms “State Agency” or “State Agency, contractor(s), and agent(s)” or “organization” for clarity. Most state officials and agreement signatories are not familiar with the acronym EIEP; therefore, SSA will continue to use the terms “State Agency”, “Tribal Entity”, “Territory”, similar but different synonyms, or “State Agency, contractor(s), and agent(s)” or “organization” in the same manner as the Computer Matching and Privacy Protection Act (CMPPA) and Information Exchange Agreements (IEA). This allows for easier alignment and mapping back to the information exchange agreements between state agencies and SSA. It will also provide a more “user-friendly” experience for the officials who complete these forms on behalf of their agencies.

The objective of this document is to ensure that SSA can properly determine EIEPs as compliant with SSA security standards, requirements, and procedures.

This document helps EIEPs understand the criteria that SSA uses when assessing and certifying the system design and security features used for electronic or physical access to SSA data. Finally, this document provides the framework and general procedures for SSA’s Security Assessment Program.

The primary statutory authority that supports the information contained in this document is the Federal Information Security Management Act , as amended by the Federal Information Security Modernization Act (FISMA) of 2014 (Pub. L. 113-283). FISMA became law as part of the Electronic Government Act of 2002. FISMA is the United States legislation that defines a comprehensive framework to protect government information, operations, and assets against natural or manufactured threats. FISMA assigned the National Institute of Standards and Technology (NIST), a branch of the U.S. Department of Commerce, the responsibility to outline and define compliance with FISMA. Unless otherwise stated, all of SSA’s requirements mirror the NIST- defined management, operational, and technical controls listed in the various NIST Special Publications (SP) libraries of technical guidance documents.

Following Federal Information Processing Standards (FIPS) documents: FIPS-199, FIPS-200, and NIST 800-60 volume II, SSA has determined that its data is considered Personally Identifiable Information (PII). NIST, in solidarity with OMB, defines PII as “any information about an individual maintained by an agency, including (1) any information that can be used to distinguish or trace an individual’s identity, such as name, social security number, date and place of birth, mother‘s maiden name, or biometric records; and (2) any other information that is linked or linkable to an individual, such as medical, educational, financial, and employment information”. As a result of this classification of data, SSA has determined that there is a consistently moderate level of risk associated with the storing, processing, and transmitting of its data. NIST 800-53 Revision 4 defines the minimum security controls to be applied to Low, Moderate, and High risk data and the information systems associated with the data. SSA has determined that a selection of these controls are applicable to any organization storing, processing, or transmitting SSA data outside of a federal facility.

To gain electronic access to SSA data, under the auspices of a data exchange agreement, EIEP’s must comply with SSA’s current Electronic Information Exchange Security Requirements and Procedures for State and Local Agencies Exchanging Electronic Information with the Social Security Administration. This document is synonymous with the term Technical System Security Requirements (TSSR). The TSSR specifies minimally acceptable levels of security safeguards to protect SSA data. SSA maintains the TSSR as a living document (subject to change) that addresses emerging threats, new vulnerabilities, and the development of new technology that potentially places SSA data at risk. SSA will work with EIEPs to resolve deficiencies, which result from updates to the TSSRs. EIEPs may proactively ensure their ongoing compliance with the TSSRs by periodically requesting the most current TSSR package from their SSA Point of Contact (POC) from the data exchange agreement. Additions, deletions, or modification of security controls directly affect the level of security and due diligence SSA requires EIEPs use to mitigate risks. The emergence of new threats, attack methods, and the development of new technology warrants frequent reviews and

SSA Administratively Controlled Document 6 revisions to our TSSR. Consequently, EIEPs should expect SSA’s TSSR to evolve in harmony with the industry standards.

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]

• Federal Information Security Modernization Act (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]

• 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]

• Preparing for and Responding to a Breach of Personally Identifiable Information [OMB M-17-12]

• Privacy Act and Trade Secrets Act [18 USC 1905]

• 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]

• Unauthorized Access Act [18 USC 2701 and 2710]

1.2 Applicable Standards and Guidance

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

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

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

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

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

• Guide for Developing the Risk Management Framework to Federal Information Systems [NIST SP 800-37 Revision 2]

• Guide for Mapping Types of Information and Information Systems to Security Categories [NIST SP 800-60 volumes 1 & 2, 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 [NIST SP 800-39]

SSA Administratively Controlled Document 7

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

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

• Risk Management Guide for Information Technology Systems [NIST SP 800-30]

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

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

• Security Requirements for Cryptographic Modules [FIPS Publication 140-2]

• Social Security Administration, Office of Information Security, Information Security Policy (ISP)

• 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 Controlled Unclassified Information (CUI)

Controlled Unclassified Information (CUI) is information that requires safeguarding or dissemination controls pursuant to and consistent with applicable law, regulations, and government-wide policies but is not classified under Executive Order 13526 or the Atomic Energy Act, as amended.

Pursuant to 32 C.F.R. § 2002.16(a) (6), the State Agency must handle any CUI in accordance with Executive Order 13556, 32 C.F.R. Part 2002, and the CUI Registry. The State Agency acknowledges that misuse of CUI is subject to penalties established in applicable law, regulations, or Government-wide policies. The State Agency will report any non-compliance with handling requirements to SSA using methods approved by SSA.

1.4 Electronic Information Exchange (EIE) Definition

EIE is any electronic process in which SSA discloses information under its control to any third party for program or non-program purposes, without the specific consent of the subject individual or any agent acting on his or her behalf. EIE involves individual data transactions and data files processed within the programmatic systems of parties to electronic information sharing agreements with SSA. This includes access to SSA systems, batch processing, and variations thereof (e.g., online query) regardless of the systematic method used to accomplish the activity or to interconnect SSA with the EIEP.

1.5 Roles and Responsibilities

1.5.1 SSA Office of Information Security (OIS)

OIS has agency-wide responsibility for interpreting, developing, and implementing security policy; providing security and integrity review requirements for all major SSA systems; managing SSA's program integrity monitoring and reporting activities, developing and disseminating security training and awareness materials, and providing consultation and support for a variety of agency initiatives. OIS conducts SSA’s security assessments to ensure that external systems receiving information from SSA are secure and operate in a manner consistent with SSA’s Information Technology (IT) security policies and in compliance with the terms of electronic data exchange agreements executed by SSA with external partners. Within the context of SSA’s security policies and the terms of the electronic data exchange agreements with SSA’s EIEPs, SSA exclusively conducts and brings to closure security assessments. This includes (but not limited to) any EIEP that processes, maintains, transmits, stores, or destroys SSA data in accordance with pertinent Federal requirements.

SSA Administratively Controlled Document 8

1.5.2 SSA Regional Data Exchange Coordinator (DEC)

Regional DECs serve as a bridge between SSA and EIEPs. DECs assist in coordinating data exchange security assessment activities with EIEPs; (e.g., providing points of contact with state agencies, drafting and updating information exchange agreements, etc.) DECs are also the first points of contact for states if an employee of a State Agency or an employee of a State Agency’s contractor or agent becomes aware of suspected or actual loss of SSA data.

1.5.3 Electronic Information Exchange Partner (EIEP)

Electronic Information Exchange Partner is an organization that has an IEA with SSA and receives SSA data. SSA requires EIEPs to adhere to the standards, requirements, and procedures, published in this TSSR document.

Both SSA and EIEPs must exercise due diligence in the responsibility for establishing appropriate management, operational, and technical safeguards to ensure the confidentiality, integrity, and availability of its records and to protect against any anticipated threats or hazards to their security.

1.5.4 State Transmission/Transfer Component (STC)

A STC is an organization that performs as a transmission and/or collection point for one or more other entities.

An STC must also adhere to the same management, operational, and technical controls as the EIEP.

1.6 SSA Security Assessments

Security assessments involve the examination, interview, and testing of information system personnel, network, software, and hardware. All organizational units and personnel responsible for the answers given in the Security Evaluation Questionnaire (SEQ) and Security Requirements Traceability Matrix (SRTM), will be expected to attend the security assessment in its entirety. A significant part of the review process, and the validation of many safeguards, involves the demonstration, by the organization, of their information system(s). It is expected that organizations are capable and prepared to support a full demonstration of the system(s) as well as an ad hoc analysis from SSA assessment personnel.

The security assessment is performed every 3-5 years after an initial assessment and authorization has been completed. Deviations from the triennial review cycle are managed on a case by case basis.

The security assessment process applies to organizations that seek electronic and physical access to SSA data and consists of five phases:

Phase 1. Pre-Assessment:

a. In the pre-assessment phase, SSA assessment personnel will:

i. Contact Data Exchange Coordinators for an updated list of points of contact,

ii. Verify points of contact with the subject organization(s),

iii. Send engagement letters and copies of the most recently updated TSSR and SEQ

iv. Work with organizations to answer questions regarding the assessment process.

b. Organizations that have established a new agreement with SSA will not receive engagement letters, instead they will be contacted by the SSA OIS External Compliance Branch to onboard them into the security assessment program. This will effectively begin the pre-assessment phase.

Phase 2. SEQ and SRTM Review:

a. All organizations must complete the SEQ. The SEQ is an assessment document that allows organizations to clearly articulate how they have implemented SSA security controls and met the security objectives.

b. The assigned SSA security assessor must receive the completed SEQ no less than 60 days prior to a security assessment.

SSA Administratively Controlled Document 9

c. Organizations entering into an initial interconnection, or implementing a significant change, will need to notify SSA 8-12 months prior to the production deployment date and will need to provide the completed SEQ, SRTM, and supporting documentation no less than 120 days prior to the assessment.

Phase 3. Assessment:

a. The SSA security assessment is conducted by SSA, or on its behalf, to examine the full suite of management, operational, and technical security controls implemented by the organization to safeguard data obtained from SSA.

b. As stated above, a significant part of the review process, and the validation of many safeguards, involves the demonstration, by the organization, of their information system(s). It is expected that organizations are capable and prepared to support a full demonstration of the system(s) and applicable supporting components as well as an ad hoc analysis from SSA assessment personnel.

Phase 4. Post-Assessment:

a. Notify organization of findings

b. Remediation period

i. SSA will allow for a fixed period of time for some findings, depending on severity, to be remediated. This time cannot be extended and any finding still open after the remediation period will be elevated to a Plan of Action and Milestone (POA&M).

c. Final Report

i. The final report will detail the findings that will need to be remediated by the EIEP, and findings closed during the remediation period.

d. POA&M Creation

i. Any findings that remain open after the remediation period will result in the need for the organization to create a POA&M to address the finding.

Phase 5. POA&M Monitoring:

a. POA&Ms are monitored quarterly.

i. Severity of the finding and age of the POA&Ms will constitute additional activities from

SSA.

b. The organization is required to track POA&Ms and report the progress quarterly or as milestones are achieved.

NOTE: SSA will never request documentation for security assessments unless necessary to assess the EIEP’s security posture. The information is only accessible to authorized individuals who have a need for the information as it relates to the EIEP’s compliance with its information exchange agreement.

1.6.1 Documenting Security Controls in the SEQ

EIEPs must submit an SEQ when one or more of the following circumstances apply:

To obtain approval for requested access to SSA data for an initial connection, To obtain approval to reestablish previously suspended or terminated access to SSA data, To obtain approval for significant changes to the EIEP’s organizational structure, technical processes, operational environment, or security implementations planned or made since approval of their most recent security assessment, To document descriptions and explanations of measures implemented as the result of a data breach or security incident and to confirm compliance when one or more security breaches or incidents involving SSA data occurred since their most recent successfully completed security assessment, SSA may require a new SEQ if changes occurred (other than those listed above) that may affect the terms of the EIEP’s information exchange agreement with SSA.

SSA Administratively Controlled Document 10

SSA will not approve the initiation of transactions and/or access to SSA data before the EIEP fully complies with the TSSR.

NOTE: Organizations that function only as an STC, transferring SSA data to other EIEPs must, per the terms of their agreements with SSA, adhere to SSA’s TSSR and exercise their responsibilities regarding protection of SSA data.

1.6.2 EIEP Security Assessment Participation

SSA requires that any individual responsible for, or consulted in, completing the SEQ attend the security assessments for their respective organization in its entirety.

SSA may request to meet with the following stakeholders during the security assessment:

Sample of managers, supervisors, information security officers, system administrators, etc. responsible for enforcing and monitoring ongoing compliance to security requirements and procedures to assess their level of training to monitor their employee’s use of SSA data, and for reviewing reports and taking necessary action, Individuals responsible for performing security awareness and employee sanction functions to learn how EIEPs fulfill this requirement, Sample of the EIEP’s employees to assess their level of training and understanding of the requirements and potential sanctions applicable to the use and misuse of SSA data

Individual(s) responsible for management oversight and quality assurance functions to confirm how the EIEP accomplishes this requirement, and/or

Any additional individuals as deemed appropriate by SSA (i.e. Analysts, Project/Program Manager, Claims Representatives, etc.)

1.6.3 Scheduling of Onsite Assessment

SSA will schedule the assessment based on the SSA requirements. For newly established agreements, SSA will not schedule the onsite assessment until SSA has administratively approved the EIEP’s SEQ.

SSA is required to conduct an onsite security assessment no later than 60 days prior to production date for any significant changes or initial access involving SSA data.

The scheduling of the onsite review may depend on additional factors including:

SSA’s workload and resource considerations, The reason for submission of the SEQ, The severity of security issues, if any, Circumstances of the previous review.

1.6.4 Third Party Assessments

Based on guidance in NIST SP 800-37, SSA’s Authorizing Official may leverage the official assessment results produced by a third party provided to the information system’s authorizing official to authorize the use of an information system, service, or application to meet SSA assessment objectives. SSA requires the third-party assessment to be at a minimum equivalent to the scope, depth, and breadth of an SSA assessment, and organizations must and make available sufficient evidence regarding the security state of an information system so that SSA’s authorizing official can use that evidence to make credible, risk-based decisions regarding

SSA Administratively Controlled Document 11 the operation and use of that system or the information it processes, stores, or transmits. SSA will leverage an active federally authorized information system (IRS, CMS, CJIS, etc.…), industry recognized independent assessments (SOC 1, SOC 2), and independent third- party assessments using the individually agency's requirements.

What are the requirements?

• A completed ATO by the organization for the cloud system, service, or application (FedRAMP

Authorization or Agency Authorization to Operate).

• OIS review of the authorization package and documentation (SSP, SAP, SAR, POAMs, additional documentation as necessary)

• Assessment of SSA tailored controls will be required. Security controls assessments may be required for other controls in scope

• Leveraged ATO from the other organization must remain in good standing and following the continuous monitoring requirements

• Immediate notification by CIO, CISO, or System Owner if the leveraged ATO is revoked Since the required assessment and authorization documentation is owned by the organization, it is the sole responsibility of the organization to provide the required documentation to SSA for review. SSA’s goal is to provide an efficient security assessment process with organizational partners that aligns with other Federal standards and alleviates redundancy for our partners.

2 Systems Security Standards and Requirements SSA’s TSSR represents the current industry standard for security controls, safeguards, and countermeasures required for federal information systems by federal regulations, statutes, standards, and guidelines. Additionally, SSA’s TSSR includes organizationally defined interpretations, policies, and procedures mandated by the authority of the Commissioner of Social Security in areas when or where other cited authorities may be silent or non-specific.

SSA must assess and certify that the EIEP has implemented security controls that meet the requirements and work as intended, before the authorization to initiate transactions to and from SSA.

The TSSR addresses management, operational, and technical aspects of safeguards to ensure only authorized disclosure and usage of SSA data stored, processed, or transmitted by SSA’s EIEPs.

SSA requires EIEPs to document and seek formal approval from SSA’s Office of Privacy and Disclosure (OPD) if they plan to share SSA data with another organization or to allow them direct access to their system. This includes, but is not limited to, law enforcement, other state agencies, tribal entities, and state or federal organizations that perform audit, quality, or integrity functions.

EIEPs that store, process, or transmit SSA data must comply with the following systems security controls.

The following subsections define the security requirements for 17 control families derived from NIST 800- 53 Revision 4. This subset of security controls will help SSA establish a sense of risk associated with the storing, processing, and transmitting of SSA data by the subject organization. SSA does not make any recommendations as to how security controls are implemented.

1. Intent: EIEPs must ensure that means, methods, and technology used to process, maintain, transmit, or store SSA data neither prevents nor impedes the EIEP’s ability to:

Safeguard the information to comply with SSA and NIST requirements.

Effectively and efficiently investigate fraud, data breaches, or security events that involve SSA data.

Detect instances of misuse or abuse of SSA data.

SSA Administratively Controlled Document 12

For example, utilization of cloud computing may have the potential to jeopardize an EIEP’s compliance with the terms of their agreement or associated systems security requirements and procedures.

NOTE: EIEPs may not create separate files or records comprised solely of the information provided by SSA to administer programs governed by the presiding CMPPA and/or service level agreement, i.e. IEA.

2. Oversight: The EIEP must process SSA data under the immediate supervision and control of authorized personnel.

Any changes to the processing of SSA data must be approved through a documented change management process, any significant changes must be approved by SSA prior to implementation.

3. Schedule: A preliminary schedule for all activities involved in planning, establishing, and maintaining the interconnection will be developed and coordinated through the Office of Data Exchange (ODX). In addition, both parties agree to the schedule and conditions for terminating or reauthorizing the interconnection.

4. Data Transmission:

a. The EIEP must use the electronic connection established between the EIEP and SSA and any software and/or devices provided to the EIEPs only in support of the current agreement(s) between the EIEPs and SSA.

b. SSA prohibits the EIEP from modifying any software or devices provided to the EIEPs by SSA.

c. EIEPs must ensure that SSA data is not accessed, processed, maintained, transmitted, or stored in or by means of data communications channels, electronic devices, computers, or computer networks located in geographic or virtual areas not subject to U.S. law.

d. SSA data must traverse an appliance with State administrative authority prior to being sent to a third-party provider (cloud service provider or managed service provider).

e. SSA requires that EIEPs maintain a verification account number (VAN) for SSA data exchanges.

5. Data Protection:

a. Access: EIEPs must restrict access to the information to authorized users who need it to perform their official duties.

NOTE: Contractors and agents (hereafter referred to as contractors) of the EIEP who process, maintain, transmit, or store SSA data are held to the same security requirements as employees of the EIEP.

b. Storage: EIEPs must store information received from SSA in a manner that, at all times, is physically and electronically secure using FIPS 140-2 approved methods from access by unauthorized persons.

c. Safeguards: EIEPs must employ both physical and technological barriers to prevent unauthorized retrieval of SSA data via computer, remote terminal, or other means.

d. Confidentiality: EIEPs must advise employees with access to SSA data of the confidential nature of the information, the safeguards required to protecting the information, and the civil and criminal sanctions for non-compliance contained in the applicable Federal and state laws.

e. Cloud Services: When cloud services are utilized to transmit, process, or store SSA data, EIEPs must clarify and document what services are consumed and are/are not FedRAMP authorized in the Security Evaluation Questionnaire (SEQ). The Organization must provide a customer responsibility matrix (CRM) or similar document as an artifact for the examination portion of the security assessment.

6. Live Data Testing: The use of live SSA data in test environments should generally be avoided and is not authorized unless specifically approved by the Office of Information Security through the submission of a formal request. At least 60 days in advance, agencies must formally request SSA approval to use live SSA data in a testing environment.

SSA defines live data as primarily unmodified, non-sanitized data extracted from SSA files that identifies a specific individual SSA provided information. The use of live data in testing environments is limited to the terms of the Information Exchange Agreement or other authorized SSA purposes and may be disclosed only to those individuals with a need-to-know.

SSA Administratively Controlled Document 13

Any systems within pre-production testing environments ideally will be configured according to requirements in this publication. However, the Office of Information Security understands most agencies may not be able to fully implement all TSSR requirements in a test environment.

Agencies wishing to use live SSA data in pre-production must submit a formal request to SSA’s Office of Information Security for authority to use live data for testing, providing a detailed explanation of the safeguards in place to protect the data and the necessity for using live data during testing.

Need and Use Justification statements should be revised to cover this use of SSA data, if not already addressed.

State agencies should check their Information Exchange Agreements to verify if “testing purposes” is covered.

Testing efforts that use live SSA data primarily fall into two categories: one-time testing and ongoing testing.

An example of a one-time testing use of live SSA data would be for system testing that is done prior to a new system implementation and, once testing has validated that the data will work properly, the live SSA data is not required to continue to remain in the test environment. For one-time testing efforts, the Office of Safeguards requires the SSA data to be deleted from systems and databases upon completion of testing efforts, and that the hard drive of the test systems be sanitized electronically prior to repurposing the system for other state agency testing efforts.

Duration for ongoing test activities will be agreed upon as part of the live data request process. Some examples of ongoing testing efforts include:

a. Testing of extract, transform, and load (ETL) process to validate federal data loading into a database.

b. Application testing of eligibility modeling that requires data match between the entire population of state and federal information, where building a set of dummy data is not feasible.

7. Incident Response: EIEPs must have formal PII incident response procedures. When faced with a security incident, caused by malware, unauthorized access, software issues, or acts of nature, the EIEP must be able to respond in a manner that protects SSA data affected by the incident.

8. Security Awareness: EIEPs must have an active and robust security awareness program.

9. Contingency Planning:

a. In accordance with the NIST Special Publication (SP) on Contingency Planning requirements and recommendations, SSA requires EIEPs to document a senior management approved Contingency Plan (CP) that includes a Disaster Recovery Plan (DRP) that addresses both natural disaster and cyber-attack situations.

b. SSA additionally requires the Contingency Plan to include details regarding the organizational Business Continuity Plan (BCP) and a Business Impact Analyses (BIA) that address the security of SSA data if a disaster occurs.

c. Organizations should coordinate contingency planning training, testing, and exercises to minimize the impact of disasters and other contingencies that could damage the connected systems or jeopardize the confidentiality and integrity of shared data. Considerations include emergency alerts and notification; damage assessment;

response and recovery, and data retrieval. The organizations are to notify each other about changes to emergency POC information (primary and alternate), including changes in staffing, addresses, telephone and fax numbers, and e-mail addresses.

10. Interconnection Security Agreement (ISA): The ISA describes the process of data communication and the impact of the data interchange. An interconnection is defined, as the direct connection between two or more Information Technology Systems for the purpose of sharing/exchanging the information. The interconnection must be in compliance with NIST Special publication 800-47 titled “Interconnecting Information Technology Systems”, and to satisfy CA-3 control of the NIST Special publication 800-53 titled “Security & Privacy Controls for Federal Information Systems and Organizations”. Current agreements between SSA and EIEPs satisfy the requirements of 800-47.

11. Planned Disconnect: Any planned disconnect should be coordinated with the SSA internal business liaison who will notify the appropriate SSA components and the EIEP point of contact concerning the planned disconnection at least 90 business days before the disconnection takes place. Before terminating the interconnection, the initiating

SSA Administratively Controlled Document 14 party should notify the other party in writing, and it should receive an acknowledgment in return. The notification should describe the reason(s) for the disconnection, provide the proposed timeline for the disconnection, and identify technical and management staff who will conduct the disconnection.

12. Emergency Disconnect: If one or both organizations detect an attack, intrusion attempt, or other contingency that exploits or jeopardizes the connected systems or their data, it might be necessary to abruptly terminate the interconnection without providing written notice to the other party. This extraordinary measure should be taken only in extreme circumstances and only after consultation with appropriate technical staff and senior management.

The system owner or designee should immediately notify the other party’s emergency contact by telephone or other verbal method, and receive confirmation of the notification. Both parties should work together to isolate and investigate the incident, including conducting a damage assessment and reviewing audit logs and security controls, in accordance with incident response procedures. If the incident was an attack or an intrusion attempt, law enforcement authorities should be notified, and all attempts should be made to preserve evidence.

The initiating party should provide a written notification to the other party in a timely manner (e.g., within five days).

The notification should describe the nature of the incident, explain why the interconnection was terminated, describe how the interconnection was terminated, and identify actions taken to isolate and investigate the incident.

In addition, the notification may specify when and under what conditions the interconnection may be restored, if appropriate.

13. Change Management: In the event that EIEP or SSA make changes which trigger the need for re-authorization it would require the ISA to be updated and reauthorized by both parties. Please refer to “Documenting Security Controls in the SEQ” for further details.

14. System Configuration: If a party intends to make technical changes to the system architecture that party will report those changes to the other party’s designated technical staff counterparts before the changes are implemented. The initiating party agrees to conduct a risk assessment based on the new system architecture and to modify and re-sign a new Interconnection Security Agreement within one (1) month of implementation.

15. Topological Drawing: The EIEP should include a topological drawing illustrating the interconnectivity from SSA to the EIEP. The drawing should include all communications paths, circuits, and other components used for the interconnection, from “Organization A’s” system to “Organization B’s” system. The drawing should depict the logical location of all components (e.g., firewalls, routers, switches, hubs, servers, encryption devices, and computer workstations) and the physical location of the connection point.

16. Security Assessment: At its discretion, SSA or a third party (i.e. contractor) must have the option to conduct onsite security assessments or make other provisions, to ensure that EIEPs maintain adequate security controls to safeguard the information we provide.

SSA Administratively Controlled Document 15

2.1 Access Control

Control Number AC-1

Title Access Control Policy and Procedures

SSA Requirement The organization must:

a. Develop, document, and disseminate to designated organization officials:

1. An access control policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance;

2. Procedures to facilitate the implementation of the access control policy and associated access control controls;

b. Review and update the current access control procedures with the organization-defined frequency.

Supplemental Guidance (from

NIST 800-53)

This control addresses the establishment of policy and procedures for the effective implementation of selected security controls and control enhancements in the AC family. Policy and procedures reflect applicable federal laws, Executive Orders, directives, regulations, policies, standards, and guidance. Security program policies and procedures at the organization level may make the need for system-specific policies and procedures unnecessary. The policy can be included as part of the general information security policy for organizations or conversely, can be represented by multiple policies reflecting the complex nature of certain organizations. The procedures can be established for the security program in general and for particular information systems, if needed. The organizational risk management strategy is a key factor in establishing policy and procedures.

Related control: PM-9.

Control Number AC-2

Title Account Management

SSA Requirement The organization must:

a. Identify and select the accounts with access to SSA data to support organizational missions/business functions.

b. Assign account managers for information system accounts;

c. Establish conditions for group and role membership;

d. Specify authorized users of the information system, group and role membership, and access authorizations (i.e., privileges) and other attributes (as required) for each account;

e. Require approvals by designated access authority for requests to create information system accounts;

f. Create, enable, modify, disable, and remove information system accounts in accordance with organization account management procedures;

g. Monitors the use of information system accounts;

h. Notifies account managers when accounts are no longer required, when users are terminated or transferred; and when individual information system usage or need-to-know changes.

i. Authorizes access to the information systems that receive, process, store or transmit SSA data based on valid access authorization, need-to-know permission or under the authority to re-disclose SSA data.

j. Review accounts for compliance with account management requirements according to organization-based frequency; and

k. Establishes a process for reissuing shared/group account credentials (if deployed) when individuals are removed from the group.

SSA Administratively Controlled Document 16

NIST 800-53)

Information system account types include, for example, individual, shared, group, system, guest/anonymous, emergency, developer/manufacturer/vendor, temporary, and service. Some of the account management requirements listed above can be implemented by organizational information systems. The identification of authorized users of the information system and the specification of access privileges reflects the requirements in other security controls in the security plan. Users requiring administrative privileges on information system accounts receive additional scrutiny by appropriate organizational personnel (e.g., system owner, mission/business owner, or chief information security officer) responsible for approving such accounts and privileged access.

Organizations may choose to define access privileges or other attributes by account, by type of account, or a combination of both. Other attributes required for authorizing access include, for example, restrictions on time-of-day, day-of-week, and point-of-origin. In defining other account attributes, organizations consider system-related requirements (e.g., scheduled maintenance, system upgrades) and mission/business requirements, (e.g., time zone differences, customer requirements, remote access to support travel requirements). Failure to consider these factors could affect information system availability. Temporary and emergency accounts are accounts intended for short-term use. Organizations establish temporary accounts as a part of normal account activation procedures when there is a need for short-term accounts without the demand for immediacy in account activation. Organizations establish emergency accounts in response to crisis situations and with the need for rapid account activation. Therefore, emergency account activation may bypass normal account authorization processes. Emergency and temporary accounts are not to be confused with infrequently used accounts (e.g., local logon accounts used for special tasks defined by organizations or when network resources are unavailable). Such accounts remain available and are not subject to automatic disabling or removal dates. Conditions for disabling or deactivating accounts include, for example: (i) when shared/group, emergency, or temporary accounts are no longer required; or (ii) when individuals are transferred or terminated. Some types of information system accounts may require specialized training. Related controls: AC-3, AC-4, AC-5, AC-6, AC-10, AC-17, AC-19, AC-20, AU-9, IA-2, IA-4, IA-5, IA-8, CM-5, CM-6, CM-11, MA-3, MA-4, MA-5, PL-4, SC-13.

Control Number AC-3

Title Access Enforcement

SSA Requirement The organization must:

Enforces approved authorizations for logical access to information and system resources in accordance with applicable access control policies.

Supplemental Guidance

Access control policies (e.g., identity-based policies, role-based policies, control matrices, cryptography) control access between active entities or subjects (i.e., users or processes acting on behalf of users) and passive entities or objects (e.g., devices, files, records, domains) in information systems. In addition to enforcing authorized access at the information system level and recognizing that information systems can host many applications and services in support of organizational missions and business operations, access enforcement mechanisms can also be employed at the application and service level to provide increased information security. Related controls: AC-2, AC-4, AC-5, AC-6, AC-16, AC-17, AC-

Control Number AC-3(7)

Title Access Enforcement | Role-Based Access Control

SSA Requirement The organization information system must:

enforce a role-based access control policy over defined subjects and objects and controls access based upon the need to utilize SSA data.

Supplemental Guidance (from

NIST 800-53)

Role-based access control (RBAC) is an access control policy that restricts information system access to authorized users. Organizations can create specific roles based on job functions and the authorizations (i.e., privileges) to perform needed operations on organizational information systems associated with the organization-defined roles. When users are assigned to the organizational roles, they inherit the authorizations or privileges defined for those roles. RBAC simplifies privilege administration for organizations because privileges are not assigned directly to every user (which can be a significant number of individuals for mid- to large-size organizations) but are instead acquired through role assignments. RBAC can be implemented either as a mandatory or discretionary form of

SSA Administratively Controlled Document 17 access control. For organizations implementing RBAC with mandatory access controls, the requirements in AC-3 (3) define the scope of the subjects and objects covered by the policy.

Control Number AC-3(8)

Title Access Enforcement | Revocation Of Access Authorization

SSA Requirement The organization must:

Enforce a role-based access control over users and information resources that have access to SSA data, and control access based upon organization defined roles and users authorized to assume such roles.

Supplemental Guidance (from

NIST 800-53)

Revocation of access rules may differ based on the types of access revoked. For example, if a subject (i.e., user or process) is removed from a group, access may not be revoked until the next time the object (e.g., file) is opened or until the next time the subject attempts a new access to the object.

Revocation based on changes to security labels may take effect immediately. Organizations can provide alternative approaches on how to make revocations immediate if information systems cannot provide such capability and immediate revocation is necessary.

Control Number AC-4

Title Information Flow Enforcement

SSA Requirement The organization information system must: enforce approved authorizations for controlling the flow of information within the system and between interconnected systems based on the need for interconnected systems to share SSA data to conduct business.

Supplemental Guidance (from

NIST 800-53)

Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to that information. Flow control restrictions include, for example, keeping export-controlled information from being transmitted in the clear to the Internet, blocking outside traffic that claims to be from within the organization, restricting web requests to the Internet that are not from the internal web proxy server, and limiting information transfers between organizations based on data structures and content. Transferring information between information systems representing different security domains with different security policies introduces risk that such transfers violate one or more domain security policies. In such situations, information owners/stewards provide guidance at designated policy enforcement points between interconnected systems. Organizations consider mandating specific architectural solutions when required to enforce specific security policies. Enforcement includes, for example: (i) prohibiting information transfers between interconnected systems (i.e., allowing access only); (ii) employing hardware mechanisms to enforce one-way information flows; and (iii) implementing trustworthy regrading mechanisms to reassign security attributes and security labels.

Organizations commonly employ information flow control policies and enforcement mechanisms to control the flow of information between designated sources and destinations (e.g., networks, individuals, and devices) within information systems and between interconnected systems. Flow control is based on the characteristics of the information and/or the information path. Enforcement occurs, for example, in boundary protection devices (e.g., gateways, routers, guards, encrypted tunnels, firewalls) that employ rule sets or establish configuration settings that restrict information system services, provide a packet-filtering capability based on header information, or message-filtering capability based on message content (e.g., implementing key word searches or using document characteristics). Organizations also consider the trustworthiness of filtering/inspection mechanisms (i.e., hardware, firmware, and software components) that are critical to information flow enforcement. Control enhancements 3 through 22 primarily address cross-domain solution needs which focus on more advanced filtering techniques, in-depth analysis, and stronger flow enforcement mechanisms implemented in cross-domain products, for example, high-assurance guards. Such capabilities are generally not available in commercial off-the-shelf information technology products. Related controls: AC-3, AC-17, AC-19, AC-21, CM-6, CM-7, SA-8, SC-2, SC-5, SC-

7, SC-18.

Control Number AC-5

Title Separation of Duties