ESBD_File_328573_Addendum 2_Attachment 3_Exhibit M - HHSC INFORMATION SECURITY CONTROLS.pdf

RFQ No. HHS0013244

Exhibit M Information

Security Controls

Critical Incident Management System (CIMS) Health and Human Services Commission (HHSC)

PUBLIC

HHS Information Security

Information Security Controls (IS-Controls)

Version (v) 1.0

February 9, 2018

PUBLIC

Formerly known as Enterprise Information Security Standards and Guidelines

(EISSG and ISSG)

HHS IS-Controls (v1.0), February 9, 2018 i

Table of Contents Table of Contents .............................................................................. i

1. Introduction

1.1. Purpose

1.2. Background

1.3. Scope

1.4. Target Audience

1.5. Alignment

1.6. Definitions

2. Security Life Cycle

2.1. Information System Security Categorization

2.2. Security Control Selection and Tailoring

2.3. Security Control Implementation and Documentation

2.4. Information System Risk and Security Assessments

2.5. Information System Authority to Operate

2.6. Monitoring Security Controls

3. Information Security in the Cloud

3.1. HHS Cloud Requirements

3.2. Federal Cloud Requirements

4. How to Use this Document

4.1. Control Structure

Appendix A: Security Baselines and Overlays

Appendix B: HHS Information Security Controls

(AC) ACCESS CONTROLS

(AT) AWARENESS AND TRAINING

(AU) AUDIT AND ACCOUNTABILITY

(CA) SECURITY ASSESSMENT AND AUTHORIZATION

(CM) CONFIGURATION MANAGEMENT

(CP) CONTINGENCY PLANNING

(IA) IDENTIFICATION AND AUTHENTICATION

(IR) INCIDENT RESPONSE

(MA) MAINTENANCE

HHS IS-Controls (v1.0), February 9, 2018 ii

(MP) MEDIA PROTECTION

(PE) PHYSICAL AND ENVIRONMENTAL PROTECTION CONTROLS

(PL) PLANNING

(PM) PROGRAM MANAGEMENT

(PS) PERSONNEL SECURITY

(RA) RISK ASSESSMENT

(SA) SYSTEM AND SERVICES ACQUISITION

(SC) SYSTEM AND COMMUNICATIONS PROTECTION

(SI) SYSTEM AND INFORMATION INTEGRITY

Appendix C: HHS Information Security and Privacy Controls

(AP) AUTHORITY AND PURPOSE

(AR) ACCOUNTABILITY, AUDIT, AND RISK MANAGEMENT

(DI) DATA QUALITY AND INTEGRITY

(DM) DATA MINIMIZATION AND RETENTION

(IP) INDIVIDUAL PARTICIPATION AND REDRESS

(SE) SECURITY

(TR) TRANSPARENCY

(UL) USE LIMITATION

Appendix D: HIPAA Security Rules to IS-Controls Mapping

Appendix E: Security Control Risk Score Formula

Appendix F: References and Resources

HHS IS-Controls: February 9, 2018 iii

Publication Information Authorized By: HHS Chief Information Security Officer (CISO)

Shirley Erp Supersedes: Information Security Standards and Guidelines (EISSG/ISSG)

Controls Catalog v6

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.

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:

Revision Date Reviewer Review Comments

1.0 February 9, Shirley Erp, Chief Information Security Officer

Authorized publication of v1

HHS IS-Controls (v1.0): February 9, 2018 1

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

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.

HHS IS-Controls (v1.0): February 9, 2018 2

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.

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 full list of applicable federal standards.) 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.

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. Nothing in this document should be construed to eliminate the obligation for a HHS system or contractor to comply with the requirements of other applicable bodies of laws/regulations that apply. Depending on the information processed, a HHS information system or contractor system may be required to meet additional security control requirements as mandated by specific sources.

HHS IS-Controls (v1.0): February 9, 2018 3

1.3. Scope

All HHS employees, contractors, third party users, external service providers 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 Officers.

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) and is based on the NIST SP 800-53 rev 4 suite of controls.

1.6. Definitions

The terms used in the IS-Controls, and other HHS Information Security documents are defined in the HHS Information Security (IS)-Definitions document.

HHS IS-Controls (v1.0): February 9, 2018 4

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 six steps of the security life cycle:

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

HHS IS-Controls (v1.0): February 9, 2018 5 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 are aligned 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.

The following steps should be followed to determine the appropriate baselines and overlay(s) that apply.

2.1.1. Step 1: Determine Information System HHS Data

Classification:

One of the core components of determining 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 additional requirements that add to or replace portions of the security control baseline. More than one overlay can be selected concurrently, and overlays exists for Texas HHS, State, and Federal requirements.

HHS IS-Controls (v1.0): February 9, 2018 6

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 Overlay Required For:

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.

http://www.statutes.legis.state.tx.us/Docs/HS/htm/HS.181.htm https://www.ecfr.gov/cgi-bin/text-idx?tpl=/ecfrbrowse/Title45/45cfr160_main_02.tpl

HHS IS-Controls (v1.0): February 9, 2018 7

Overlay Required For:

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)

CMS-ARS Information systems that support a Center for Medicaid and Medicare Services (CMS) business mission and perform work on behalf of CMS, has a contract with CMS or one of their contractors that mandates CMS-ARS, and is not required to follow CMS-MARS-E.

Reference:

CMS Acceptable Risk Safeguards v3.0

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:

https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/InformationSecurity/Information-Security-Library.html?DLSort=0&DLEntries=10&DLPage=2&DLSortDir=ascending https://www.irs.gov/pub/irs-pdf/p1075.pdf https://www.irs.gov/pub/irs-pdf/p1075.pdf

HHS IS-Controls (v1.0): February 9, 2018 8

Overlay Required For:

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.

References:

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.

References:

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.

Reference:

https://www.fbi.gov/services/cjis/cjis-security-policy-resource-center https://www.fbi.gov/services/cjis/cjis-security-policy-resource-center https://www.va.gov/vapubs/Search_action.cfm?FormNo=6500 https://www.va.gov/vapubs/Search_action.cfm?FormNo=6500

HHS IS-Controls (v1.0): February 9, 2018 9

Overlay Required For:

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.

References:

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.

References:

Select Agency Information System Security Controls Guidance

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.

References:

NCHHSTP

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 https://www.cdc.gov/nchhstp/programintegration/data-security.htm

HHS IS-Controls (v1.0): February 9, 2018 10

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 Proceed to Table 2.5

If the information system has a confidential data classification and any applicable State or Federal overlays, the following additional questions must be answered to determine if the High or Moderate security control baseline is applicable.

Table 2.5. Confidential Federal Systems Security Control Baseline

Categorization Questions:

Security Control

Baseline Is:

Information system is directly involved in making payments for Medicare Fee-for-Service (FFS) or Medicaid and State Children’s Health Insurance Program AND the CMS-ARS overlay is applicable.

High

If the above is not applicable: Moderate

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. Any control, in Appendix A, with an (x) in the applicable baseline or overlays is required and should be included 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, if they determine 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), or

HHS IS-Controls (v1.0): February 9, 2018 11

2. Select individual controls from a higher baseline to add to the security control requirements. See 2.2, Security Control Selection and Tailoring for further information on adding additional controls to compensate for 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

HHS IS-Controls (v1.0): February 9, 2018 12 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 Compensating 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 compensate 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

HHS IS-Controls (v1.0): February 9, 2018 13

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

Contact HHS Information Security for the current version of the SSP.

The SSP documents 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 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:

HHS IS-Controls (v1.0): February 9, 2018 14

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 findings 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 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 Information Security Office or an authorized third party provider after a risk assessment has been completed, and 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).

Security assessments can require a significant amount of organizational resources to conduct. Due to that, 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:

HHS IS-Controls (v1.0): February 9, 2018 15

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

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.6 and Table 2.7 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)

HHS IS-Controls (v1.0): February 9, 2018 16

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

• Coverage: Examine (Comprehensive), Interview (Focused), Test (Focused)

Table 2.6: 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.7: 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

HHS IS-Controls (v1.0): February 9, 2018 17

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.

Finding Criticality Days to Make Risk Decision Low Risk Findings 90 Days Moderate Risk Findings 60 Days High Risk Findings 30 Days

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 (see 2.4.3.c).

a. Risk Levels: Weaknesses are assigned a Risk Level by Information Security based on the severity.

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

HHS IS-Controls (v1.0): February 9, 2018 18

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, Information Security Officers, CISO, and others as needed.

Depending on the risk level of the weakness, reasonable timeframes are granted for remediation:

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

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

• Low Risk: 365 business 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.

• Compensating Controls: Identify any controls already in place or that could be put in place that would adequately reduce the risk posed 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 the 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:

HHS IS-Controls (v1.0): February 9, 2018 19

• 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 weakness 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. Risk Exceptions Authorized Approvers

Security/Impact Risk Rating

Information Owner ISO CISO CIO

Agency Head

Low Security Risk Approve Approve Moderate Security Risk

Approve Approve

High Security Risk 1 Approve Coordinate Approve High Impact Risk 2 Approve Coordinate Coordinate Coordinate Approve

1 High Security Risk is risk that, per the HHS Security Control Risk Score Formula or the ISO, has been determined to be high risk and requires CISO approval. The HHS CISO is responsible for deciding whether the High Security Risk meets the criteria for “High Impact Risk.”

2 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

HHS IS-Controls (v1.0): February 9, 2018 20 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.

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.

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

HHS IS-Controls (v1.0): February 9, 2018 21

2.5.2. 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.1) 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 controls in the information system must be monitored on an ongoing basis. This includes documenting changes to the system or its environment of operation and conducting security impact analyses of the associated changes, conducting annual risk assessments, and reporting the security state of the system to designated organizational officials.

2.6.1. Changes to the Information System and its Environment of Operations Information systems are in a constant state of change with upgrades to hardware, software, or firmware and modifications to the surrounding environments where the system resides and operates. Anytime the information system is modified or changed, a security impact analysis (SIA) (CM-04) should be conducted by the Information Owner and/or Custodian to

HHS IS-Controls (v1.0): February 9, 2018 22 determine the extent to which the proposed or actual changes to the information system or its environment of operation may affect the security controls currently in place. The results of the SIA determines if the change is a:

a. Routine Change: This change is handled through the organizations continuous monitoring strategies documented in section 2.6.2 and section

2.6.3. This does not impact the system’s current ATO.

b. Minor Change: This change requires a reassessment of affected information security controls, normally referred to as a security evaluation. This does not impact the system’s current ATO, however the results of the security evaluation must be considered before the change is approved for operation by the Change Control Board (CCB). Additionally, any weaknesses identified in the security evaluation must be tracked as findings against the information system if the change is approved.

c. Significant Change: This change is of a significant enough nature that the system will require a full security assessment and a new ATO before the updated system may be moved to an operational environment.

2.6.2. Ongoing Risk Assessments

Subsequent to the initial authorization, the information owner is required by TAC 202 to conduct a risk assessment of their information system on a bi-annual basis. See section 2.4.1 for further information.

2.6.3. Ongoing Remediation Actions

Receiving an Authority to Operate does not relieve the Information Owner of the responsibility to remediate risks identified in the Security Assessment Report or through other means after the ATO is granted. Findings, unless granted an exception, must be remediated within the timeframes established by the organization.

HHS IS-Controls (v1.0): February 9, 2018 23

3. Information Security in the Cloud

As defined by NIST, “Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction.1

This cloud model promotes availability and is composed of five essential characteristics, three service model, and four deployment models.”

While cloud computing offers many potential benefits, it is…