PL-11_HHS Information Security Controls.pdf

HHS Information Security

Information Security Controls (IS-Controls)

Version (v) 1.2.1

November 2, 2021

PUBLIC

Table of Contents

1.1. Purpose

1.2. Background

1.3. Scope

1.4. Target Audience

1.5. Alignment

1.6. Definitions and Document Composition

2.1. Information System Security Categorization

2.1.1. Determine Information System HHS Data Classification:

2.1.2. Determine Applicable Overlays

2.1.2. Determine Initial Security Baseline

2.1.4. Finalize Security Baseline

2.2. Security Control Selection and Tailoring

2.3.1. Security Control Implementation

2.3.2. Documenting Information System Security

2.4. Information System Risk and Security Assessments

2.4.1. Risk Assessments

2.4.3 Remediation

2.5. Information System Authority to Operate

2.5.1. CA-06, Security Authorization

2.5.2. Security Authorization Package

2.5.3. Risk Determination and Acceptance

2.6. Monitoring Security Controls

2.6.1. Changes to the Information System and Environment of

Operations

2.6.2. Ongoing Risk Assessments

2.6.3. Ongoing Remediation Actions

HHS Cloud Requirements

3.2. Federal Cloud Requirements

3.2.2. IRS Federal Tax Information (FTI)

3.2.3. FBI Criminal Justice Information (CJI)

3.2.4. SSA Requirements and Procedures

3.2.5. CMS MARS-E

4.1. Control Structure

HHS IS-Controls (v1.2.1), November 2, 2021

Publication Information

Authorized By: HHS Chief Information Security Officer (CISO) Thuy Cao

Publication Version History Numbering convention: Version. Revision as n.xx. Pre-publication drafts are 0.xx; first published version is 1.00; for minor revisions to a published document, increment the decimal number (ex. 1.01); for major content upgrades to a published document, increment the leading whole number (ex.2.00).

Revision Date Change Description

1.0

February 9, First published version of HHS Information Security Controls.

This document fully replaces the Enterprise Information Security Standards and Guidelines (EISSG) and Information Security Standards and Guidelines (ISSG). All previous versions of those publications are rescinded and no longer valid.

1.1

September 21, Changes made were part of the agency’s corrective actions in response to IRS audit finding. Corrections include: a) updating the AT and AU controls to correct errors and remove incorrect information; b) specifically adding a log to document and track the agency’s required annual reviews of select controls (AU, AT, MA, PL, RA, SC); c) addressing organizational changes combining ISO and CISO role and documented changes in Circular -21; and d) removal of the CMS-ARS requirements, as CMS-ARS is not applicable to HHS information systems.

1.2 Sept 20, 2021 Change made to framework and inconsistency in documents.

The addition of new agency publications released by the agency.

(IS-Policy, Training Policy, Incident Response.) The RMF image was updated to the most current version, revision 2.2. The overlay section was updated to removed inconsistency between baseline, All CMS-ARS language removed from document (appendix B&C). Final editing October 11, 2021.

1.2.1 Nov 1, 2021 A request was made to update Appendix B&C for CM-04(01) and redirect the reader to the recently documented Architecture Advisory Board Environment Standards. The change clearly identifies how and when confidential data can be used in a non-production environment. Also, to acclimate the reader to the terms “upper environment” and “lower environment” since neither of these are included in standard NIST documentation.

Appendix B&C, and non-appendix (Framework) will reflect version 1.2.1 and a publication date of 11/2/2021

Publication Review History To satisfy the requirements of the Information Systems Security Program, a formal review of this document was conducted in accordance with HHS requirements on the following dates:

Control Revisions (September 21,2020) Revision Name Revision Effects Comments AU Family Controls Updated language, removed

CMS-ARS

Language updated part of agency POAM.

AT Family Controls Updated language, removed

CMS-ARS

Language updated part of agency POAM.

Revision Date Reviewer Review Comments

1.0 February 9, Shirley Erp, Chief Information Security Officer

Authorized publication of v1

1.1 September

28, 2020

Thuy Cao, Chief Information Security Officer

Authorized publication of v1.1

1.2 October 7, Thuy Cao, Chief Information Security Officer

Authorized publication of v1.2

1.2.1 November 1, Thuy Cao, Chief Information Security Officer

Authorized publication of v1.2.1

Annual Review Logs

Control Reviewed Review Results Reviewer Review Date AU-01 Audit and Accountability

Updated language to reflect new AU policy and standards.

Stan Hogan, Cybersecurity Assurance Manager

9/28/2021

AT-01 Awareness and Training

Updated language to reflect new AT policy.

Stan Hogan, Cybersecurity Assurance Manager

9/28/2021

MA-01 System Maintenance Policy and Procedures

No changes identified Stan Hogan, Cybersecurity Assurance Manager

9/28/2021

PL-01 Security Planning Policy and Procedures

IS-Policy link updated, CMS-ARS language removed

Stan Hogan, Cybersecurity Assurance Manager

9/28/2021

RA-01 Risk Assessment Policy and Procedures

IS-Policy link updated, CMS-ARS language removed

Stan Hogan, Cybersecurity Assurance Manager

9/28/2021

SC-01 System and Communications Protection Policy and Procedures

IS-Policy link updated, CMS-ARS language removed

Stan Hogan, Cybersecurity Assurance Manager

9/28/2021

1. Introduction Title 1, Part 10, Texas Administrative Code (TAC), Chapter 202, Rule §202.24 Agency Information Security Program requires that all state agencies have an information security program consistent with the rules defined in TAC 202.

The Texas Health and Human Services (HHS) Circular C-021 establishes the Information Security Program for the HHS system which is aligned with the HHS Strategic Plan for supporting the mission and functions of the HHS agencies. The HHS Information Security program is comprised of security policies, standards, controls, and guidelines. This document, IS-Controls, is an expansion of the HHS Information Security Policy (IS-Policy) requirements.

The HHS Chief Information Security Officer (CISO) office under HHS IT provides the Information Security program, as required by TAC 202. The IS- Controls document will refer to Information Security program unless the “CISO office” designation is more applicable.

1.1. Purpose

The security and privacy controls contained in this document are the safeguards or countermeasures that, when implemented and enforced, will satisfy the information security compliance requirements defined in the HHS IS-Policy and applicable federal laws, executive orders, directives, policies, HHS regulations and standards.

1.2. Background

The HHS IS Program is based on the following three security objectives of confidentiality, integrity and availability:

Confidentiality “Preserving authorized restrictions on information access and disclosure, including means for protecting personal privacy and proprietary information…” [44 U.S.C., Sec. 3542] A loss of confidentiality is the unauthorized disclosure of information.

Integrity “Guarding against improper information modification or destruction, and includes ensuring information nonrepudiation and authenticity…” [44 U.S.C., Sec. 3542]

A loss of integrity is the unauthorized modification or destruction of information.

Availability “Ensuring timely and reliable access to and use of information…” [44 U.S.C., SEC. 3542]

A loss of availability is the disruption of access to or use of information or an information system.

Security and privacy controls are designed to protect and meet the security objectives of confidentiality, integrity, and availability of information and the information system, reducing risk to a manageable level.

The IS-Controls supports the risk management process by specifying the minimum information security and control requirements that agencies shall use based on information system security categorization levels with the objective of reducing risk to an acceptable level.

The comprehensive set of security and privacy controls contained in the IS- Controls protects not only information and systems, but also individual employees and HHS as a whole. As such, these security and privacy controls represent the HHS organization’s strong commitment to information systems security.

Prior to IS-Controls v1.0, there was no single, integrated, comprehensive approach to security and privacy that addressed all applicable federal requirements. These laws differ in areas of system categorization, selection of operational security controls, and the use of program management controls. Given the diversity of federal and state laws and regulations governing security and privacy that may apply, Texas HHS has amended IS- Controls to identify key standards and processes to support compliance with the current body of laws and regulations.

Certain federal programs, such as Internal Revenue Service Federal Tax Information (IRS FTI), Social Security Administration (SSA), Federal Bureau of Investigation (FBI) Criminal Justice Information (CJI), and Centers for Medicare / Medicaid Services (CMS) have specific control implementation standards that are required. (See 2.1.2 for a list of federal standards that might be applicable). Each Federal agency has unique data protection regulations and requirements. HHS systems and their contractors must adhere to the safeguard requirements of the Federal agencies when mandated by a contractor and interconnection agreement.

IMPORTANT: Nothing in this document should be construed to eliminate the obligation for an HHS system or contractor to comply with the requirements of other applicable bodies of laws/regulations that apply. Depending on the information processed, an HHS information system or contractor system may be required to meet additional security control requirements as mandated by specific sources. It is the responsibility of information owner and or their information custodian to ensure their information systems meet compliance with state and federal laws and regulations.

1.3. Scope

All HHS employees, contractors, third party users, external entities and all HHS physical, software, and information assets (whether standalone or attached to the HHS local and wide area networks), that access, create, disclose, receive, transmit, maintain, or store HHS information, as well as all services that support or otherwise handle those physical, software, and information assets, are required to comply with the security and privacy controls contained within this document.

The security controls outlined in this document are required upon release of this document, and compliance should be documented in the information systems next annual risk assessment.

1.4. Target Audience

The IS-Controls is intended to serve a diverse audience of information systems, Information Owners, Information Custodians and Information Security staff. While all users of HHS information systems assets should be aware of security controls as adopted by HHS Information Security, primary users of this document are the information custodians of IT operations, system and database administrators, application developers, support, maintenance personnel, and information security.

1.5. Alignment

The HHS Information Security Program makes extensive use of the information security guidance found in the Department of Information Resources (DIR) Security Control Standards Catalog, and the National Institute of Standards and Technology (NIST) Special Publications (SP) 800- 53, Revision 4 (rev 4) suite of controls. This document is not intended to address NIST 800-53 rev 5, that was published on 09/23/20. The incorporation of NIST 800-53 rev 5 will be addressed in the next major release (version 2.0) of the IS-Controls document.

1.6 Definitions and Document Composition

Technical terms used in the IS-Controls were minimized to the greatest extent possible. However, definition should align with NIST, and if unclear the HHS IT Business Operations division offers a Glossary for employees and contractors of HHS. If outside HHS or an external entity, the NIST Glossary is available.

https://txhhs.sharepoint.com/sites/hhsc/IT/busserv/plpp/ppp/Site%20Pages/Home.aspx https://csrc.nist.gov/glossary

For convenience of the reader the document is separated into a non-appendix section that contains background and front matter necessary for the reader to understand the document. This includes the security life cycle, risk management framework, cloud security and the control structure.

2. Security Life Cycle The IS-Controls specifies the minimum information security requirements that are necessary to provide the appropriate levels of information security according to risk levels. The HHS Security Life Cycle is based on the National Institute of Standards and Technology (NIST) Risk Management Framework (RMF). The RMF incorporates security in seven steps of the security life cycle. The diagram below identifies the steps of the security life cycle along with a RACI model description of areas accountable, responsible, and consulted. Also, Information Security has identified the deliverables that are required for each step of the lifecycle.

2.1. Information System Security Categorization

The identification and selection of the applicable baseline and overlay(s) of security controls is essential to ensure the proper controls are selected, implemented and assessed.

Security control baselines, listed in Appendix A, are the starting point for the security control selection process and are the minimum required HHS security controls a system must implement. They are chosen based on the security category and impact of the types of data the information system processes. There are four control baselines, listed in Table 2.1 below that align with the applicable security categorization and impact levels of the data the information system processes.

Table 2.1. Security Categorization and Control Baselines Control Baselines

Regulation Drivers Data Classification Security Categorization & Impact

Low State Public Low Low Plus State Agency

Sensitive Low

Moderate State and Federal Confidential Moderate High State and Federal Confidential High

Identifying and selecting the correct baseline and overlay(s) of security controls begins with determining the security categorization level and baseline of the information system.

To determine the appropriate baseline and overlay(s) follow these three steps.

2.1.1. Step 1: Determine Information System HHS Data Classification:

The security baseline is dependent upon the classification of data. To do this, evaluate all HHS data that is stored, processed, or maintained by the information system using the HHS Data Classification Standard. Select the highest (most confidential) data classification level and use that as the data classification for the information system.

The potential data classifications are:

• Public

• Agency Sensitive

• Confidential

2.1.2. Step 2: Determine Applicable Overlays

Overlays are deemed additional requirements to the security control baseline for an Information System. More than one overlay can be selected concurrently, and overlays exist for Texas HHS, State, and Federal requirements with specific control implementation standards. Overlays cannot reduce baseline requirements, and if there is a difference, the most restrictive security requirement must be selected.

Review and select all applicable overlays that apply to the information system.

Table 2.2. Texas HHS Overlays Overlay Required For:

SPI Information systems that are owned or managed by a contractor that creates, receives, maintains, uses, discloses, or has access to HHS Confidential Information and is required to sign a security and privacy inquiry (SPI).

Reference:

Information Security and Privacy Inquiry

Web & Mobile Information systems that can be accessed through a web browser or a mobile application.

Cloud Information systems that will reside in a non-HHS managed data center.

Table 2.3. State and Federal Overlays

HIPAA Information systems that create, receive, maintain, use, disclose, or have access to Protected Health Information (PHI).

Reference:

Texas Health and Safety Code, Chapter 181; 45 C.F.R § 160.103

CMS-MARS-E 1. Information Systems that are an ACA Administering Entity1 or contractor, subcontractor, their respective facilities supporting such IT system that access, create, disclose, receive, transmit, maintain, or store CMS data received from the CMS Federal Service Hub;

2. Or systems that interconnect (See CA-03) with the ACA Administering Entity (either directly to the Administering Entity or indirectly through an interconnection to a system that directly connects to the Administering Entity) to access, create, disclose, receive, transmit, maintain, or store CMS data.2

Note 1: For Texas, the Texas Integrated Eligibility Redesign System (TIERS) is the primary ACA Administering Entity. “Administering Entity” means Exchanges or Marketplaces, whether federal or state, state Medicaid agencies, Children’s Health Insurance Program (CHIP) agencies, or state agencies administering the Basic Health Program.

Note 2: CMS Data is any data provided by CMS through their Federal Service Hub.

Reference:

Catalog of Minimum Acceptable Risk Security and Privacy Controls for Exchanges v2.0 (Volumes 1 - 4).

http://www.statutes.legis.state.tx.us/Docs/HS/htm/HS.181.htm

IRS Information Systems that store, process, maintain or return information legally receive Federal Tax Information (FTI) directly from the IRS or obtained through an authorized secondary source, such as Social Security Administration (SSA), Federal Office of Child Support Enforcement (OCSE), Bureau of the Fiscal Service (BFS), or Centers for Medicare and Medicaid Services (CMS), or another entity acting on behalf of the IRS pursuant to an IRC 6103(p) (2) (B) Agreement. Note: FTI may not be masked to change the character of information to circumvent IRC 6103 confidentiality requirements.

Reference:

IRS Publication1075, Tax Information Security Guidelines For Federal, State, and Local Agencies

CJIS Applicable to every individual contractor, private entity non- criminal justice agency representative or member of a criminal justice entity with access to, or who operates in support of criminal justice services and information.

The Federal Bureau for Investigation (FBI) Criminal Justice Information System (CJIS) provides data necessary for law enforcement and civil agencies to perform their missions including, but not limited to biometric, identity history, biographic, property, and case/incident history data. The following categories of CJI describe the various data sets housed by the FBI CJIS architecture:

1. Biometric Data—data derived from one or more intrinsic physical or behavioral traits of humans typically for the purpose of uniquely identifying individuals from within a population. Used to identify individuals, to include: fingerprints, palm prints, iris scans, and facial recognition data.

2. Identity History Data—textual data that corresponds with an individual’s biometric data, providing a history of criminal and/or civil events for the identified individual.

3. Biographic Data—information about individuals associated with a unique case, and not necessarily connected to identity data. Biographic data does not provide a history of an individual, only information related to a unique case.

4. Property Data—information about vehicles and property associated with crime when accompanied by any personally identifiable information

(PII).

5. Case/Incident History—information about the history of criminal incidents.

https://www.fbi.gov/services/cjis/cjis-security-policy- resource-center https://www.irs.gov/pub/irs-pdf/p1075.pdf https://www.irs.gov/pub/irs-pdf/p1075.pdf https://www.irs.gov/pub/irs-pdf/p1075.pdf https://www.fbi.gov/services/cjis/cjis-security-policy-resource-center https://www.fbi.gov/services/cjis/cjis-security-policy-resource-center

VA Applies to all VA Information Systems, contractor operated services and information resources located and operated at contract facilities or any other third party utilizing VA information or VA information systems in order to perform a VA authorized activity.

Veteran’s Affairs Handbook 6500, Risk Management Framework for VA Information Systems

SSA Information under the control of SSA that is provided to an external entity under the terms of an information exchange agreement with SSA. However, “SSA data/information” also includes information provided to the Electronic Information Exchange Partners (EIEP) by a source other than SSA, but which the EIEP attests to that SSA verified it, or the EIEP couples the information with data from SSA as to certify the accuracy of the information.

Contact HHS Information Security if access is needed to the SSA overlay.

FERPA Applies to an educational agency or institution that receives funds under one or more of the programs covered by the Family Educational Rights and Privacy Act (FERPA) (20 U.S.C. § 1232g; 34 CFR Part 99). FERPA is a Federal law that protects the privacy of student education records.

Educational agency or institution is any public or private agency or institution. Education program means any program that is principally engaged in the provision of education, including, but not limited to, early childhood education, elementary and secondary education, postsecondary education, special education, job training, career and technical education, adult education, and any program that is administered by an educational agency or institution.

Reference:

https://www2.ed.gov/policy/gen/guid/fpco/ferpa/index.html

Select Agent Information Systems subject to select agent regulations in 42 C.F.R that is managed jointly by the Center for Disease Control (CDC) and United States Department of Agriculture (USDA). The Select Agent Program oversees the possession, use, and transfer of biological select agents and toxins which have the potential to pose a severe threat to public, animal or plant health, or animal or plant products.

Select Agency Information System Security Controls Guidance https://www.va.gov/vapubs/Search_action.cfm?FormNo=6500 https://www.va.gov/vapubs/Search_action.cfm?FormNo=6500 https://www.va.gov/vapubs/Search_action.cfm?FormNo=6500 https://www2.ed.gov/policy/gen/guid/fpco/ferpa/index.html https://www.cdc.gov/selectagent/isg-intro.html https://www.cdc.gov/selectagent/isg-intro.html

NCHHSTP Information systems subject to the CDC Data Security and

Confidentiality guidelines for HIV, Viral Hepatitis, Sexually Transmitted Diseases, and Tuberculosis Programs (NCHHSTP). This applies to all systems funded by NCHHSTP or for systems that receive data from a system funded by NCHHSTP.

NCHHSTP

2.1.3. Step 3: Determine Initial Security Baseline

Once the information system data classification and overlays have been determined, the initial security baseline can be calculated. Use the following table to determine the correct security control baseline:

Table 2.4. Data Classification to Security Baseline

Data Classification Has an Applicable Federal Overlay

Security Control Baseline Is:

Public Low Agency Sensitive Low Plus Confidential No Moderate Confidential Yes ** If the row above is not High Moderate

**If the information system has a confidential data classification and an applicable State or Federal overlay, refer to NIST FIPS 199 to determine if baseline is High or Moderate. For additional guidance on CMS, refer to CMS Risk Management Handbook Chapter 12 Security and Privacy Planning Sections 3.1.5-3.1.7. If you need assistance making this determination please contact the HHS CISO Office for help or reach out to your IS Portfolio Manager.

2.1.4. Step 4: Finalize Security Baseline

The security control baseline (Step 3), when combined with the applicable overlays (Step 2), determine the minimum required security controls for the Information System. Controls in Appendix A, marked with an (x) in the applicable baseline or overlays should be reviewed for inclusion in the Information Systems baseline. The final security baseline and applicable overlays should be documented in the System Security Plan (SSP).

Increasing the Security Control Baseline Requirements The Information Owner determines that the security control baseline is not sufficient to protect the information system, may either:

1. Increase the security control baseline to a higher level (e.g., moderate to high)

2. Select individual controls from a higher baseline to add to the security control https://www.cdc.gov/nchhstp/programintegration/data-security.htm https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.199.pdf https://www.cms.gov/files/document/rmh-chapter-12-security-and-privacy-planning.pdf https://www.cms.gov/files/document/rmh-chapter-12-security-and-privacy-planning.pdf requirements. Section 2.2 Security Control Selection and Tailoring gives further information on adding additional controls to mitigate the risk.

All decisions to modify the security control baseline must be documented, along with justification concerning the reason why, in the SSP.

2.2. Security Control Selection and Tailoring

Control selection is the process of tailoring the initial list of required security controls (based on the security baseline and overlay(s)). The Information Owner, working with the systems Information Custodian(s), uses the tailoring process to modify and appropriately align the controls more closely with the specific conditions with the organization. All control selection and tailoring decisions must be documented in the SSP.

The tailoring process includes:

a. Identifying Inheritable (Common) Controls: Identifying and designating controls as “inherited” common controls are the controls that the information system inherits from organizational common control providers. HHS Information Security maintains the list of inheritable common controls for HHS information systems.

Contractors that access, create, disclose, receive, transmit, maintain, or store HHS information must coordinate with HHS to determine the common controls that they may inherit, if any, from HHS.

b. Identifying Partially Inheritable (Hybrid) Controls: Identifying security controls that are partially inherited from organizational common control providers and are also partially provided by the information system. These controls are known as “hybrid” controls and HHS Information Security maintain the list of security controls inheritable as hybrid for HHS Information systems. Contractors that access, create, disclose, receive, transmit, maintain, or store HHS information must coordinate with HHS to determine hybrid controls they inherit from HHS.

c. Identifying Not Applicable Controls: Identifying security controls that are “Not Applicable” to the information system. This does not include removing security controls for operational convenience. A decision to mark a control as “Not Applicable” must be defensible based on the specific rationale and the decision must be documented in the SSP. Common reasons for marking a security control as “Not Applicable” include:

1. Technology related considerations: Security controls that refer to specific technologies (e.g., wireless, cryptography, public key infrastructure) are applicable only if those technologies are employed or are required to be employed.

2. Single User Systems: For information systems that are designed to operate as single-user systems (e.g., smart phones), several of the security controls that address sharing among users may not be needed.

Security controls such as AC-10, Concurrent Session Control, SC-4, Information in Shared Resources, and AC-3, Access Enforcement may not be required in single-user systems/operations.

3. Mobility: If those information systems operate primarily in mobile environments (e.g., mobile phones), the security control baseline should be tailored appropriately to account for the differences in mobility and accessibility of the specific locations where the systems reside. For example, many of the security controls in the Physical and Environmental Protection (PE) family that are selected in all three baselines reflect the assumption that the information systems reside in physical facilities/complexes that require appropriate physical protections.

4. Data Connectivity and Bandwidth: While many information systems are interconnected, there are some systems which for security or operational reasons, lack networking capabilities—that is, the systems are air gapped from the network. For non-networked systems, security controls such as AC-17, Remote Access, SC-8, Transmission Confidentiality and Integrity, and SC-7, Boundary Protection, are not applicable and may be tailored out of the security control baselines.

d. System-Specific Controls: All controls that are not identified as “common” or “hybrid” are considered system specific and must be fully implemented solely by the information system.

e. Identifying Mitigating Controls: If the initial baseline of controls is not sufficient to mitigate the risk to the system, the Information Owner may identify and add other security controls not included in the initial list of required security controls in order to mitigate for unresolved risk. The reasoning and justification for adding security controls to the initial list must be clearly documented in the SSP.

2.3. Security Control Implementation and Documentation

Once the information system’s required security controls have been finalized, the controls should be implemented by the information system and how they are implemented documented in the applicable SSP.

2.3.1. Security Control Implementation

Early integration of information security requirements into the system development life cycle is the most cost-effective method for implementing the organizational risk management strategy.

All portions of applicable security control requirements and implementation standards are required to be implemented by the information system or a common control provider unless a security exception is approved using the methodology document in Section 2.4.2 or the control has been determined to be “Not Applicable.”

2.3.2. Documenting Information System Security

Security control documentation describes how system-specific, hybrid, and common controls are implemented. The system security plan (SSP) serves as the primary method to document how security controls are implemented (including planned inputs, expected behavior, and expected outputs).

The current version of the SSP must be documented in the agency enterprise governance risk and compliance (eGRC) system. A template to use for offline purposes can be provided by HHS Chief Information Security Officer office.

The SSP documents must include the following information (at a minimum) about the information system:

a. Description: The description is an overview of the information system that includes identifying the purpose of the information system, information owner, custodians, categorization, security baselines, location, and data flows.

b. Environment and Boundaries: The system environment and boundaries include describing the architecture, topology, and system boundary; all system hardware and software assets; the used ports, protocols, and services; and all of the user community authorized to use the system.

c. Security Control Implementation: The implementation section is used to document how each applicable security control is implemented and its current implementation status.

2.4. Information System Risk and Security Assessments

2.4.1. Risk Assessments

The information owner is required by TAC 202.21 to conduct a risk assessment of their information system prior to receiving its first Authorization to Operate (ATO) (Section 2.5) and on an annual basis.

As defined in RA-03, this risk assessment will include:

a. A review of the compliance status of all security and privacy controls required per the system categorization.

b. Documenting the current implementation status of required security controls in the system security plan (SSP), to include creating plan of action and milestones (POA&M) for any security controls identified as not being fully in place.

c. A review of all security documents including the system categorization, SSP, contingency plans, and any open POA&M or findings.

d. A vulnerability assessment of the information system to detect if the system is vulnerable to unauthorized access or harm, including the extent to which the systems electronically stored information is vulnerable to alteration, damage, erasure, or inappropriate use.

The results of the risk assessment should be sent to the Information Security Officer for review. This report is due prior to requesting the system undergoing a security assessment, and subsequently no-later-than the Information Systems ATO anniversary date each year.

2.4.2. Security Assessments

Security assessments are conducted, if required, by the CISO Office or an authorized independent assessor after a risk assessment has been completed.

Security assessments are used to determine the extent to which the information system’s security and privacy controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for the system. Security Assessments are conducted on information systems when determined as required by the Authorizing Official (see Section 2.5). The output of a security assessment is a Security Assessment Report (SAR).

Due to the fact security assessments can require a significant amount of organizational resources to conduct, the Chief Information Security Officer, working with the Authorizing Official, must determine the level of effort required for each security assessment using a risk-based approach. Security assessment level-of-effort can be classified by defining the assessment methods, depth, and coverage that will be used.

a. Security Assessment Methods: The Information Security Office can leverage a wide variety of methods when conducting security assessments. The methods selected are dependent upon the criticality of the system and the level of effort required to conduct the assessment, and not all assessment methods are required to be used in every security assessment.

Assessment methods include:

1. Examine: This is the process of reviewing, inspecting, observing, studying, or analyzing assessment objects (e.g., system security plans, product specifications, security controls, etc.). The purpose of this method is to facilitate the security assessor’s understanding of the information system, clarification of an aspect of the system, or obtaining evidence.

2. Interview: This method is the process of holding discussions with individuals or groups of individuals to facilitate the security assessor’s understanding, achieve clarification, or obtain evidence.

3. Test: This method is the process of exercising one or more assessment objects (e.g., vulnerability scans, configuration scans, penetration tests).

b. Assessment Depth and Coverage: Prior to starting each security assessment, the expected depth and coverage of the assessment must be identified and documented by Information Security. The two attributes, depth and coverage, are critical to define the level of effort and timeframe for the assessment.

1. Depth: This attribute addresses the rigor and level of detail in the security assessment methods that will be used in the assessment process.

2. Coverage: This attribute addresses the scope or breadth of the assessment, including number and types of items to examine or test and number of people to interview.

Both attributes are broken into three categories: basic, focused, and comprehensive. For each attribute and method, a decision must be made and documented using Table 2.5 and Table 2.6 below as to the level of effort that will be spent by security assessors. See NIST 800-53A Appendix D for further information.

c. Scenarios The following scenarios are examples, and not official standards. Contact the Information Security Office for the current methodology used to determine the assessment depth and coverage for security assessment of HHS Information Systems.

Scenario 1 - Public system, internal only:

This system is deemed to pose a very low risk to the organization. Due to this, the Information Security Office selects the following level of effort:

• Depth: Examine (Basic)

• Coverage: Examine (Basic)

Scenario 2 - Internet facing system that transmits HHS confidential data:

This system is required to have a full security assessment and penetration test conducted due to Texas Government Code 2054.516. Due to that, the Information Security Office selects the following levels:

• Depth: Examine (Focused),

• Interview (Focused),

• Test (Comprehensive)

Table 2.5: Depth Assessment Attribute Categories by Method

Basic Focused Comprehensive Examine High level reviews, checks, observations, or inspections

A more in-depth study/analysis of the system. Requires a substantial body of evidence or documentation.

An in-depth, detailed, and thorough study/analysis of the controls. Requires an extensive body of evidence or documentation.

Interview Broad-based high level discussion with individuals and groups

More in-depth discussion in specific areas with individuals or groups

Probing discussions in specific areas with individuals or groups of individuals

Test Black box testing:

Assumes no knowledge of the internal structure and implementation details

Gray box testing:

Assumes some knowledge of the internal structure and implementation details

White box testing:

Assumes explicit and substantial knowledge of the internal structure and implementation details

Table 2.6: Coverage Assessment Attribute Categories by Method

Basic Focused Comprehensive Examine A representative sample of security controls and other assessment objects

A larger sample of security controls deemed particularly important to achieving the objective

A sufficiently large sample, or all, required security controls

Interview Representative sample of individuals in key organizational roles

Representative sample of individuals in key organizational roles and specific individuals deemed particularly important to achieving assessment objectives

Large sample of individuals in key organizational roles and specific individuals deemed particularly important to achieving assessment objectives

Test Representative sample of assessment objects

Representative sample of assessment objects and other assessment objects deemed particularly important

Sufficiently large sample of assessment objects

2.4.3 Remediation

Remediation begins after a weakness has been documented as a finding by Information Security and is the process of identify how to resolve the weaknesses and deficiencies identified in the information system. This process begins with the Information Owner and Custodian analyzing the identified weakness or deficiency and determining the methodology to resolve the finding. This decision, called the initial risk decision, should be made within the below time frames of receiving notification of a validated finding.

2.7. Remediation Timelines

Finding Criticality Days to Make Risk Decision Low Risk Findings 30 Days Moderate Risk Findings 20 Days High Risk Findings 10 Days

IMPORTANT: At the CISO discretion, depending on the severity of the risk associated with a high impact finding, the days to make a remediation decision may be decreased.

There are two generally accepted methods for resolving findings: remediate (e.g., correct) the weakness; or receive authorization to accept the risk (e.g., do not correct) from a senior agency official with the authority to accept the risk (Section 2.4.3.c).

a. Risk Levels: Weaknesses are assigned a Risk Level based on the severity using the following information.

• High Risk (High Impact): Risk that could 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; result in major damage to organizational assets; result in major financial loss; or result in severe or catastrophic harm to individuals involving loss of life or serious life threatening injuries.

• High Risk: Risk to an information resource’s confidentiality, integrity, or availability that could be expected to have a severe adverse effect on organizational operations, organizational assets, or individuals but not meet the requirement for high impact risk.

• Moderate Risk: Risk to an information resource’s confidentiality, integrity, or availability that could be expected to have a serious adverse effect on organizational operations, organizational assets, or individuals.

• Low Risk: Risk to an information resource’s confidentiality, integrity, or availability that could be expected to have a limited adverse effect on organizational operations, organizational assets, or individuals.

b. Risk Remediation: After weaknesses have been identified and a finding issued, a remediation strategy must be developed. This should be a collaborative effort with stakeholders including the Information Owner, Information Custodian, System Developers and Maintainers, CISO, and others as needed.

IMPORTANT: Depending on the risk level of the weakness, reasonable timeframes are granted for remediation. If a risk is determined to be high impact, the CISO, at their discretion can decrease the number of days granted for risk remediation

• High Risk: 30 days from the date the risk decision is due

• Moderate Risk: 60 days from the date the risk decision is due

• Low Risk: 90 days from the date the risk decision is due

Plan of Action and Milestone (POA&M): A POA&M is a formal documented plan for how the weakness will be remediated. A POA&M should clearly explain how the identified weakness will be corrected, including required steps, estimated timelines, who will complete the work, and costs.

When writing a POA&M to remediate a weakness, the organization should consider several factors:

• Required Work: Remediation plans often require multiple steps in order to be completed. These are documented as milestones, which include estimated delivery dates, resource requirements, and a description of what the milestone will accomplish.

• Mitigating Controls: Identify any controls already in place or that could be put in place that would adequately reduce the risk posed or the weakness to an acceptable level.

• Funding Requirements: The remediation process requires resources;

the type and amount of which will vary. Estimation of resources required should be done carefully, with consideration to:

o The complexity of the corrective action plan o Parties required to execute the corrective action plan o Purchasing requirements

Prioritization: Resource limitations often prevent stakeholders from obtaining the necessary resources to mitigate every identified weakness within the same time period. The careful prioritization of weakness helps ensure that critical important weaknesses are appropriately rank-ordered and allocated resources required to resolve the associated risk. Prioritization efforts should consider:

• Risk Level/Severity: Sensitivity and criticality of information on the system; the estimated likelihood of the weakness occurring and/or being exploited; the cost of a potential occurrence/exploitation in terms of dollars, man-hours, and/or reputation.

• Analysis: The weakness must be analyzed to determine if there are any other processes or system relationships that it may affect.

• Resources: Some weaknesses can be quickly and easily resolved without a large expenditure of time or money. In those cases, weaknesses may be addressed ahead of those weaknesses for which resourcing must be planned and budgeted.

• Management Input: Senior management and/or authorizing officials should have input into prioritizing remediation.

• Other Weaknesses: A combination of minor, overlapping weaknesses may highlight a more serious problem.

• Breadth: Whether the weakness is a systemic issue or an isolated event.

• Source: Whether the weakness identified through a method, such as an audit, which demands greater attention.

• Visibility: In some cases, a lower level weakness is a higher priority due to it garnering external visibility.

c. Risk Acceptance: In rare cases, the Information Owner can present a case for accepting, transferring, or mitigating risk instead of remediating the risk. In these instances, the risk exception process should be initiated by the Information Owner. Risk exceptions are not permanent and must be reviewed and reauthorized (normally once a year). Table 2.8 below provides the Authorized Approvers of a Risk Exception, however Circular C-021 Health and Human Services Information Security/Cybersecurity Policy aligned with TAC 202 should be considered the authoritative risk acceptance documentation, to include those designated officials who can accept each level of risk.

Table 2.8. Risk Rating for Exceptions / Authorized Approvers

Security/Impact Risk Rating

Information

Owner

CISO

CIO

Agency Head

Low Security Risk Initiate Approve

Moderate Security Risk Initiate Coordinate Approve High Security Risk * Initiate Coordinate Coordinate Approve

High Impact Risk ** Initiate Coordinate Coordinate Approve

*High Security Risk per the HHS Security Control Risk Score Formula in Appendix E or the CISO has been determined to be high risk. High residual risk requires Agency Head approval. The HHS CISO is responsible for deciding whether the High Security Risk meets the criteria for “High Impact Risk.”

**High Impact Risk, Per TAC 202, could 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; result in major damage to organizational assets; result in major financial loss; or result in severe or catastrophic harm to individuals involving loss of life or serious life threatening injuries. High Impact Risk requires Agency Head approval.

2.5. Information System Authority to Operate

An Authorization to Operate (ATO) is a formal declaration by a senior organizational official that authorizes operation of an Information System and explicitly accepts the risk to agency operations. The ATO is signed after the system has undergone a risk assessment that validates that the system has met and passed all requirements to become operational. Reference the ATO process as this explains how the HHS CISO Office evaluates the security of information systems, to grant an authority to operate.

2.5.1. CA-06, Security Authorization

Per the DIR Security Control Standards Catalog, mandated by Texas Administrative Code 202.26, requires that a senior organizational official accepts any residual risk and authorizes information systems for processing before the system begins operations or anytime it undergoes a significant change. This official is referred to as the Authorizing Official. The Authorizing Official, by granting an information system an ATO, formally accepts responsibility for the residual risk the information system poses to the organization. The Authorizing Official cannot delegate their responsibilities to other officials within the organization.

2.5.2. Security Authorization Package

The Authorizing Official, in order to make a well-informed risk-based authorization decision requires an authorization package that is comprised of several key documents. These documents, when combined, provide the minimum necessary documentation required for the Authorizing Official to determine whether the risk posed by the system is acceptable.

The authorization package, prepared by the Information Owner and/or Custodian, at a minimum, includes:

a. System Security Plan (SSP): This document, outlined in Section 2.3 and PL-

02, provides a comprehensive overview of the information system and its current security posture.

b. Security Assessment Report (SAR): This document, described in Section

2.4.2 and CA-02, is a formal report that documents the results of a risk assessment, and if requested, security assessment, and any weaknesses or deficiencies identified during the assessment(s).

c. Finding Plans of Action and Milestones (POA&M): These documents, described in section 2.4.3 and CA-05, document the organization’s planned remedial actions to correct weaknesses or deficiencies noted during the assessment of the Information System’s security controls and to reduce or eliminate known vulnerabilities in the system.

2.5.3. Risk Determination and Acceptance

The explicit acceptance of risk is the responsibility of the Authorizing Official and cannot be delegated to other officials within the organization. The Authorizing Official, in collaboration with the Chief Information Security Officer, considers many factors when deciding if the risk to organization operations (including mission, function, image, or reputation), organizational assets, individuals, other organization, and the State, is acceptable.

Security authorization decisions are based on the content of the security authorization package (section 2.5.2) and, where appropriate, any input from key organization officials.

The Authorizing Official formally documents their decision in an authorization decision document. This document must contain the following information:

a. Authorization decision: Indicates whether the Information System is (a) Authorized to Operate or (b) Not Authorized to Operate

b. Terms and Conditions for the Authorization: Provides a description of any specific limitations or restrictions placed on the operation of the information system.

c. Authorization Termination Date: Indicates when the authorization termination date expires. This is normally set at three years, as documented in CA-06, but can be set to a more restrictive timeframe.

The authorization decision document, once complete, is delivered to the Information Owner and Chief Information Security Officer and becomes a formal component of the information system’s security documentation.

2.6. Monitoring Security Controls

After the information system is authorized to operate, the security…