HHS Enterprise
Information Security Standards and
Guidelines
EISSG v5.1
March, 2013
Table of Contents
Table of Contents .......................................................................................................... 2 Document History .......................................................................................................... 5 Revision History: .................................................................................................................. 5 Reviews ............................................................................................................................... 6 Purpose .......................................................................................................................... 7 Information Security Policies Scope ........................................................................... 7 Information Security Policies Compliance .................................................................. 7 Information Security Policies Ownership .................................................................... 7 HHS Information Security Roles and Responsibilities ............................................... 8 HHS Data Classification .............................................................................................. 10 Acceptable Use ............................................................................................................ 11 HHS Information Security Program Policies ............................................................. 16 Management Policies .................................................................................................. 16 1. Security Assessment and Authorization (CA) .................................................. 16 1.1. 1.2. 1.3. 1.4. 2. Security Assessments ............................................................................................... 16 Plan of Action and Milestones ................................................................................... 16 Security Authorization ............................................................................................... 16 Continuous Monitoring .............................................................................................. 17 Planning (PL) ....................................................................................................... 17 2.1. Exceptions ................................................................................................................. 17 3. Program Management (PM) ................................................................................ 17 3.1. Enterprise Architecture .............................................................................................. 17 3.2. Information Security Resources ................................................................................ 17 4. Risk Assessment (RA) ........................................................................................ 18 4.1. Vulnerability and Risk Assessment ........................................................................... 18 5. System Services and Acquisition (SA) .............................................................. 18 5.1. Systems Development .............................................................................................. 18 Operational Policies .................................................................................................... 21 6. Awareness and Training (AT) ............................................................................. 21 6.1. Security Training ....................................................................................................... 21 7. Configuration Management (CM) ....................................................................... 21 7.1. Change Management ................................................................................................ 21 8. Contingency Planning (CP) ................................................................................ 22 8.1. Back-up and Disaster Recovery ................................................................................ 22 9. Incident Response (IR) ........................................................................................ 22 HHS EISSG v.5.1
Page 2 of 75
9.1. Incident Management ................................................................................................ 22 10. Maintenance (MA) ................................................................................................ 23 10.1. Controlled Maintenance ............................................................................................ 23 11. Media Protection (MP) ......................................................................................... 23 11.1. Media Access and storage ........................................................................................ 24 11.2. Removable Media ..................................................................................................... 24 12. Physical and Environmental Protection (PE) .................................................... 24 12.1. Physical Access ........................................................................................................ 24 13. Personnel Security (PS) ...................................................................................... 25 13.1. Third-Party Personnel Security ................................................................................. 25 14. System and Information Integrity (SI) ................................................................ 25 14.1. Anti-Spam ................................................................................................................. 26 14.2. System Configuration Hardening / Patch Management ............................................ 26 14.3. Malicious Code .......................................................................................................... 26 14.4. Operating Systems .................................................................................................... 27 Technical Policies ....................................................................................................... 28 15. Access Control (AC) ............................................................................................ 28 15.1. Account Management ............................................................................................... 28 15.2. Administrative and Special Access ........................................................................... 29 15.3. Imaging Devices ........................................................................................................ 30 15.4. Network Access ........................................................................................................ 30 15.5. Network Configuration ............................................................................................... 31 15.6. Portable/Remote Computing ..................................................................................... 31 15.7. Vendor Access .......................................................................................................... 32 15.8. Virtual Private Network (VPN) ................................................................................... 33 15.9. Wireless Computing .................................................................................................. 33 16. Audit and Accountability (AU) ............................................................................ 35 16.1. Audit Logging ............................................................................................................ 35 16.2. Security Monitoring ................................................................................................... 35 17. Identification and Authentication (IA) ................................................................ 36 17.1. Passwords ................................................................................................................. 36 18. System and Communications Protection (SC) ................................................. 37 18.1. Electronic File Transfers ........................................................................................... 37 18.2. Intrusion Detection / Prevention ................................................................................ 38 18.3. Mobile Code .............................................................................................................. 39 19. Privacy Policies ................................................................................................... 39 19.6.1 Privacy Standards ......................................................................................... 40 20. Supporting Security Controls and Procedures ................................................... 41 21. Security Policies Exceptions ................................................................................ 41 22. Laws, Regulations, and Guidance........................................................................ 41 HHS EISSG v.5.1
Page 3 of 75
Federal ............................................................................................................................... 41 State…. .............................................................................................................................. 41 Industry .............................................................................................................................. 41 Organization ....................................................................................................................... 41 Appendices .................................................................................................................. 42 Appendix A – HHS Information Systems Security Controls Catalog.................................. 42 Appendix B - HHS Data Classification ............................................................................... 43 Appendix C - Recommended Events for Logging .............................................................. 59 Appendix D - Exception Request Form (Template) ........................................................... 60 Appendix E - Acronyms and Glossary ............................................................................... 66 Appendix F - Security References ..................................................................................... 74 HHS EISSG v.5.1
Page 4 of 75
Document History
Revision 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
Description
0.01
05-2007
Initial document distributed by Enterprise Security Management (ESM)
0.02
05-2007
Updates based on review by: Information Security Officer (ISO)s and
Information Resource Manager (IRMs)
0.03
05-2007
Updates based on management review by: Chief Information Officer (CIO)
1.00
05-2007
First Published Draft of Security Standards and Guidelines
1.01
11-2007
Updates to incorporate Federal Security Requirements sent for review to
ISOs and IRMs
1.02
12-2007
Updates to incorporate Federal Security Requirements sent for review by:
CIO
2.00
12-2007
Second Published Draft of Security Standards and Guidelines
2.50
06-2008
Updates to incorporate changes to physical security and address secure
file transfer requirements sent for review to IM&O, ISO’s and IRM’s
2.60
07-2008
Updates to incorporate changes to physical security, secure file transfer,
remote access, and security plan requirements sent for review to ISO’s,
IRMs and other agency management.
2.70
08-2008
Updates to incorporate changes to Wireless Computing, and Privacy
sections. Included section for data classification.
2.80
08-2008
Updates for addition of Electronic Transfer Section and final review by ISO,
IRM, CIO, TARB and EOB.
3.00
08-2008
Third Published Draft of Security Standards and Guidelines. (Revisions to
the numerous sections)
3.10
10-2008
Minor revision to incorporate changes to Portable/Remote Computing
Section 1.23, Removable Media Section 1.25 and Wireless Computing
Section 1.33
4.00
11-2010
Fourth published draft of the Security Standards and Guidelines.
(Revisions to the numerous sections based on the Audit of Confidential
Data Transfers)
4.01
05-2011
Minor revision to incorporate changes to Acceptable Use Section 1.1,
Incidental Use/Limited Use Section 1.14
4.02
11-2011
Revision to incorporate changes to Incident Management Section 1.13
5.0
06-2012
Major Revision to EISSG by HHSC Office of the Chief Information Security
Officer (CISO) – Identified an agency security program framework that
aligns with State, Federal, Local and agency compliance requirements.
5.1
02-2013
Major Revision to EISSG by HHSC Office of the Chief Information Security
Officer (CISO) – to include the HHS Security Controls Catalog (Appendix
A.),HHS Data Classification Guidelines (Appendix B) etc.
HHS EISSG v.5.1
Page 5 of 75
Reviews
To satisfy the requirements of the Information Systems Security Program, a formal review of this document is
mandatory annually.
Date
Reviewer
Department
Job Title
06/28/12
Brian Engle
Information Security Office
Chief Information Security Officer
09/25/12
Brian Engle
Information Security Office
Chief Information Security Officer
03/11/13
Brian Engle
Information Security Office
Chief Information Security Officer
HHS EISSG v.5.1
Page 6 of 75
Purpose
The Title 1, Texas Administrative Code (TAC), Chapter 202, RULE §202.20 Security Standards Policy, Item (2),
requires that all state agencies have an information security program consistent with the standards defined in the
TAC 202. The Texas Health and Human Services (HHS) HHS Circular C-021 HHS Enterprise Information
Security Policy establishes an information security program for the health and human services (HHS) enterprise
that is consistent with the TAC Chapter 202, Information Security Standards.
The HHS CISO is committed to the protection of information and computing assets within the HHS environment
and the fulfillment of the TAC 202 RULE §202.20 Security Standards Policy requirement, and the HHS Circular C021 HHS Enterprise Information Security Policy.
This EISSG document incorporates the requirements of public laws, federal, state, and HHSC regulations
documents, as listed in Appendix F. It is also designed to be consistent with, and an enabler of Privacy Protection
Principles as found in the Texas Business and Commerce Code section 521, Health and Safety Code and other
state data stewardship guidance’s.
The EISSG establishes a set of comprehensive rules and practices that regulate access to information systems
within the HHS environment and the information processed, stored, and transmitted by them. Comprehensive
security policies protect not only information and systems, but also the HHS organization as a whole. As such, the
EISSG represents the HHS commitment to information systems security.
Information Security Policies Scope
All HHS employees, contractors, and third party users, and all HHS physical, software, and information assets
(whether standalone or attached to the HHS local and wide area networks) that store, process, or transmit HHS
digital data, as well as all services that support or otherwise handle those physical, software, and information
assets, are required to comply with the security policies contained within this document.
Information Security Policies Compliance
Compliance with the security policies contained within this security policies document is mandatory. Reviews to
ensure compliance are undertaken at established intervals using authorized methods.
Information Security Policies Ownership
The HHS CISO is the sponsor and issuing authority for this HHS information security document.
HHS EISSG v.5.1
Page 7 of 75
HHS Information Security Roles and Responsibilities
Regardless of position or job classification, every employee and contractor that works in the HHS environment
plays an important role in safeguarding the confidentiality, integrity, and availability of the systems and the data
maintained by HHS. It is important that each individual fully understands his or her role and its associated
responsibilities as designated by the HHS information security program and abides by the security policies,
security controls, and procedures set forth by HHS CISO.
Role
Responsibility
HHS Chief Information Security
Officer (CISO)
The HHS CISO has the overall responsibility for the implementation of an IS
Security Program for the HHS environment.
 Provides Enterprise information security protections commensurate with this
policy, the HHS information security program and federal regulations;
 Develop Enterprise policies, procedures, and guidelines to ensure the
protection of information resources;
 Recommend information security strategies for the HHS Agencies
 Communicates information regarding the overall state of the HHS Information
Security Program and risks to information resources within the HHS
Enterprise, and overall ;
 Ensures that there are appropriate technologies and processes available and
implemented to provide the security level required; and
 Ensures that HHS has trained personnel sufficient to assist HHS in complying
with the requirements of this policy and related security controls and
procedures.
Agency Information Security Officer
(ISO)
















HHS EISSG v.5.1
Administer the agency Information Security Program.
Develop and recommend agency specific polices, standards and guidelines
where required to ensure the security of information resources within their
organization.
Establish and recommend procedures and practices to ensure the security of
information resources.
Ensure that security policies, procedures, standards, and guidelines are
implemented to protect agency’s information resources.
Establish procedures for assessing and ensuring compliance with information
security policies through inspections, reviews, and evaluations.
Develop and implement a comprehensive information security training and
awareness program.
Monitor the effectiveness of defined controls for mission-critical information.
Report on the status and effectiveness of information resources security
controls.
Serve as agency’s internal and external point of contact for all information
security matters.
Assists the HHSC Chief Information Systems Officer (CISO) in ensuring the
information systems in the HHS environment adheres to federal, state laws,
executive orders, directives, regulations, policies, standards, and HHSC
information system security program requirements;
Serves as the primary point of contact in the HHS for information systems
security issues;
Develops, evaluates, and provides information about the HHS Information
Security Program implementation within the associated agency, and
communicates HHS Information Security Program requirements and concerns
to HHSC management and personnel;
Ensures that the System Security Plan (SSP) is developed, reviewed,
implemented, and revised;
Maintains documentation that establishes systems security level designations
for all SSPs within HHS ;
Ensures that information system risk assessments (RA) are developed,
reviewed, and implemented for the SSP process;
Provides leadership and participates in information system incident response
and reporting in accordance with reporting procedures developed and
implemented by the agency.
Page 8 of 75
Role
System Owner
Responsibility




Application, Server, Database,
Network Administrators



System Developers


Assesses the risk to the information and information systems for which they
have responsibility;
Ensures through security assessments/audits that the HHS information system
for which they have responsibility are developed, implemented, operated, and
documented according to the requirements of this policy;
Verifies that the HHS information system fully complies with HHS security
requirements; and
Ensures appropriate security measures and supporting documentation are
maintained.
Verifies that server, database, and network security requirements are being
met;
Establishes and communicates the security safeguards required for protecting
server, database, and network security based on the sensitivity levels of the
information; and
Periodically reviews and verifies that all users of their servers, databases, and
network resources are authorized and are using the required systems security
safeguards, in compliance with the policies contained within this document
and all related security controls and procedures requirements.
Develops and implements the HHS information security requirements
throughout the System Development Life Cycle (SDLC); and
Plans and implements for the on-going maintenance of the information
system, including updates, upgrades, and patches in accordance with the
SDLC and security policies within this document.
Service Providers, Vendors, and
Contractor Employees
HHS service providers, vendors, and contract employees have the responsibility to
ensure the protection of HHS information (data) and information systems by:
 Complying with the information security requirements maintained in this policy.
 Complying with the HHSC information security policy requirements
Users
Users have the responsibility to ensure the protection of HHS information (data)
and the information system by:
 Complying with the HHSC information security policy requirements
HHS EISSG v.5.1
Page 9 of 75
HHS Data Classification
Data Classification provides a framework for managing data assets based on value and associated risks and for
applying the appropriate levels of protection as required by state and federal law as well as proprietary, ethical,
operational, and privacy considerations. All HHS data, whether electronic or printed, must be classified. The
data owner should consult with legal counsel on the classification of data as Confidential, Agency-Sensitive, or
Public. Consistent use of data classification reinforces with users the expected level of protection of HHS data
assets in accordance with HHS security policies.
The HHS Data Classification Standard applies equally to all individuals who use or handle any HHS Information
Resource.
HHS data created, sent, printed, received, or stored on systems owned, leased, administered, or authorized by
the HHS agency are the property of the HHS agency and its protection is the responsibility of the HHS owners,
designated custodians, and users.
Data shall be classified as follows from highest level sensitivity to the lowest:
1. Restricted – which includes ‘IRS FTI’ and ‘Verified SSA’ – Data that is subject to specific federal or state
regulatory requirements and must a) remain encrypted at all times while at rest, in use or during transmission,
b) be comprehensively monitored for access/distribution and c) provide for comprehensive access,
distribution and audit controls. For more information on what constitutes ‘Restricted’, see Appendix B – HHS
Data Classification.
2. Confidential – which includes ‘SPI’, ‘PI’, ‘PII’, ‘PHI’ or ‘LEA’ – Data that is subject to specific federal or state
regulatory requirements and must a) be encrypted during transmission to an outside agent or when stored on
a mobile device, b) be monitored and c) provide strong access, distribution and audit controls. For more
information on what constitutes ‘Confidential’, see Appendix B - HHS Data Classification.
3. Agency Internal – Data that is not is subject to specific regulatory or other external requirements but is
considered HHS sensitive. For more information on what constitutes ‘Agency Internal”, see Appendix B - HHS
Data Classification.
4. Public – Information intended or required for public release as described in the Texas Public Information Act
Information owned or under the control of the United States Government must comply with the federal
classification authority and federal protection requirements.
Violation of this policy may result in disciplinary action which may include termination for employees and
temporaries; a termination of employment relations in the case of contractors or consultants; dismissal for interns
and volunteers; or suspension or expulsion in the case of a student. Additionally, individuals are subject to loss of
HHS Information Resources access privileges, and to civil and criminal prosecution.
More detailed information on data classification is located in Appendix B - HHS Data Classification.
HHS EISSG v.5.1
Page 10 of 75
Acceptable Use
All electronic data, hardware, and software residing on HHS networks are considered state property (assets). All
information passing through the HHS networks, which has not been specifically identified as the property of other
parties, will be treated as an HHS asset. Unauthorized access, disclosure, duplication, modification, diversion,
destruction, loss, misuse, or theft of these resources is prohibited. All User activity on HHS IR is subject to
logging and review.
Every information system privilege that has not been explicitly authorized is prohibited. Such privileges will not be
authorized for any HHS business purpose until approved by the information Owner, or designee, in writing or by
electronic acknowledgement. Information entrusted to HHS will be protected in a manner consistent with data
classification and in accordance with all applicable standards, agreements, and laws.
Any person or entity granted access to HHS IR, including HHS employees, volunteers, interns, private providers
of services, contractors, vendors, and representatives of other agencies of state government must comply with
the standards set forth in this document. For purposes of this document, the term “User” refers specifically to an
HHS IR User.
1. Users may not attempt to access any data, program, or system for which they do not have authorization
or explicit consent.
2. Users must not disclose confidential or sensitive data or confidential or sensitive agency system or
network information.
3. Any User who becomes aware of or suspects an actual or possible incident of unauthorized access of
confidential information must report such to the agency Information Security Officer (ISO) and agency
Privacy Officer or designees upon discovery, immediately and no later than 24 hours. Additional
documentation may also be required. For example: the agency Privacy Office will have a worksheet for
potentially reporting loss of Protected Health Information (PHI) to the Centers for Medicare & Medicaid
Services.
4. Upon discovery of a possible unauthorized inspection or disclosure of Internal Revenue Service (IRS)
Federal Tax Information (FTI) including breaches and security incidents, the individual making the
observation or receiving the information should contact HHSC IRS Coordinator, at (512.206.5474). If you
are unable to reach the HHSC IRS Coordinator by phone, send a secure e-mail to HHSC IRS FTI at
IRS_FTI_Safeguards@hhsc.state.tx.us
The HHSC IRS Coordinator will report the incident by contacting the office of the appropriate Special
Agent-in-Charge, Treasury Inspector General for Tax Administration (TIGTA) and the IRS Office of
Safeguards as directed in Section 10.2 of Publication 1075.
5. Users must not share their account identifiers, passwords, Personal Identification Numbers (PINS),
Security/Access Tokens (e.g., Smartcards), or any other information or device used for identification,
authentication, authorization, or access purposes.
6. Any User who becomes aware of or suspects an actual or possible computer security incident, weakness,
misuse or violation of any policy related to the security and protection of those resources must report
such to the agency Information Security Officer (ISO) or designee upon discovery immediately, no later
than 24 hours.
7. Software installed or run within the HHS systems and/or networks must be approved by the Custodian
responsible for that area.
8. Users must not download/operate a peer-to-peer (P2P) file sharing system such as LimeWire, KaZaA,
BitTorrent, Morpheus or Gnutella etc., available to the general public to transfer files (including music or
video files).
Risks associated with P2P use include the following:
a. By running a peer-to-peer (P2P) application, you may be sharing confidential HHS information,
consuming excessive network bandwidth, inadvertently sharing personal information and/or making
HHS EISSG v.5.1
Page 11 of 75
your computer vulnerable.
b. Viruses and Trojans are easily spread using P2P applications. Many P2P applications include
“Malware” in the download, so you may be unintentionally infecting your HHS computer.
c.
If you copy and distribute copyrighted material without the permission required by law, you may be
violating civil or criminal copyright infringement laws. Civil penalties for Federal Copyright
infringement range from $750 per song to $150,000 in damages for each willful act. Criminal
penalties can run up to five years in prison and $250,000 in fines.
9. Before leaving their computers unattended, Users must either lock access to their workstations or logoff.
10. Users of HHS information resources must not engage in any act that would violate the purposes and
goals of HHS as specified in its governing documents, rules, regulations, and procedures.
11. Users must not intentionally access, create, store, or transmit any material that may be offensive,
indecent, or obscene. Materials required for research projects and explicitly approved by HHS are
excluded from this prohibition
12. A user may not engage in any activity that is harassing, threatening or abusive, degrades the
performance of IR, deprives or reduces an authorized User’s access to resources, or otherwise
circumvents any security measure or policy.
13. A User shall not use any HHS IR to gain personal benefit.
14. Users must use appropriate safeguards to protect IR from damage, loss, or theft.
15. Any User of HHS owned or leased equipment who takes the resource off-site to an environment out of
the authority of HHS must follow the same information security policies, standards, and guidelines to
protect the resource as required when in use at an HHS location.
16. Any User of HHS owned or leased equipment used in an environment out of the authority of HHS must
protect that equipment from theft, use or abuse by non-HHS approved Users.
17. Violation of the data classification policy (located above) may result in disciplinary action which may
include termination for employees and temporaries; a termination of employment relations in the case of
contractors or consultants; dismissal for interns and volunteers; or suspension or expulsion in the case of
a student. Additionally, individuals are subject to loss of HHS Information Resources access privileges,
and to civil and criminal prosecution.
18. All users must sign or electronically acknowledge the HHS Enterprise Computer Use Agreement
(http://hhscx.hhsc.state.tx.us/eit/security/is_forms/HR0314.pdf CUA, Form HR0314) indicating they have
read, understand and agree to comply with the rules of behavior and this must be on file before any
access is granted. (See Account Management Section 15.1)
E-mail Use
The growth of use and the increase in vulnerabilities related to electronic communications has seen a
corresponding increase in the need for policies governing the use of, and protections directed to, those
communications. This E-mail Standard applies to all Users of HHS e-mail systems.
19. The following activities are prohibited:
a.
b.
c.
d.
e.
f.
Sending e-mail that is intimidating or harassing,
Using e-mail to gain personal benefit,
Using e-mail for purposes of political lobbying or campaigning,
Violating copyright laws by inappropriately distributing protected works,
Posing as anyone other than oneself when sending e-mail, except when authorized to send
messages for another when serving in an administrative support role,
The use of unauthorized e-mail software,
HHS EISSG v.5.1
Page 12 of 75
g.
h.
i.
j.
Sending or forwarding chain letters,
Sending unsolicited messages to large groups except as required to conduct department business,
Sending or forwarding e-mail that is likely to contain malicious code, and
Using stationery in e-mail. These are backgrounds that are available through most commercial e-mail
software products. These take up excessive disk space, and therefore their use is prohibited on HHS
networks.
20. Any data that is classified as Restricted or Confidential must be encrypted or otherwise protected as
required by rule, regulation or law. Section (18.1 Electronic File Transfers).
21. All User activity on HHS IR assets is subject to logging and review. HHS e-mail Users shall have no
expectation of privacy.
22. E-mail Users must not give the impression that they are representing, giving opinions, or otherwise
making statements on behalf of any HHS agency or any unit of an HHS agency unless appropriately
authorized (explicitly or implicitly) to do so.
23. Individuals must not send, forward, or receive confidential HHS information through non-HHS e-mail
accounts, such as Yahoo, Hotmail, or Gmail accounts.
24. Individuals must not send, forward, or store confidential HHS electronic information utilizing non-state
owned or leased mobile devices without the prior written permission of the data Owner. These devices
include, but are not limited to, laptop/notebook computers, personal data assistants or other hand-held
devices, two-way pagers or digital/cellular telephones.
25. Refer to Chapter 4 of the HHS Human Resources Manual for more information about E-mail use.
Incidental Use/Limited Use
Incidental and Limited personal use of HHS IR by Users is permitted.
26. Limited personal use of e-mail and Internet access is allowed for employees and other approved Users only.
This use does not extend to visiting friends or relatives of the approved User.
27. Limited use must not result in any additional direct costs to HHS.
28. Limited use must not interfere with the normal performance of the Users' duties.
29. Storage of personal e-mail, voice-mail, files, and/or any other document by the approved User must be kept to
a minimum.
30. All messages, files, and/or documents located on any HHS IR are owned by HHS and may be accessed by
appropriate HHS staff without notice to the User. Such documents may be subject to open records requests.
This includes any personal messages, files, and/or documents.
31. Incidental personal use of Internet access is permitted, but must not inhibit or interfere with the use and/or
functionality of network resources for business purposes.
32. Incidental use of Instant Messaging (IM), social networking sites such as Facebook, Orkut, MySpace, and
Twitter, and video-hosting/sharing sites such as YouTube are prohibited. Exceptions for use of IM or social
networking sites for approved HHS business purposes must be approved by the agency IRM, or the HHS
Chief Information Officer (CIO) if there is no designated agency IRM, using the exception process in Section,
2.1 Exceptions of the EISSG. Prior to approval, a business justification is required. The “Social Networking
Justification and Approval Process” document can be found here:
http://hhscx.hhsc.state.tx.us/tech/policy/Social_Media_Process.doc
Internet/Intranet/Extranet Use
For the purpose of this standard, the term Internet shall include Intranet and/or Extranet.
33. Software for browsing the Internet is provided to Users for business and research purposes, and is allowed for
incidental/limited personal use only.
HHS EISSG v.5.1
Page 13 of 75
34. Incidental use must not interfere with the normal performance of an employee’s work duties.
35. Incidental use must not result in any direct costs to HHS.
36. All software used to access the Internet must be part of the HHS standard software suite, or approved for use
by the appropriate HHS authority.
37. All software used to access the Internet must incorporate vendor provided security patches.
38. All files downloaded from the Internet must be scanned for viruses using the approved current HHS virus
detection software.
39. All files downloaded from the Internet must fall within the defined download parameters allowed by the HHS
Enterprise Information Security Policy.
40. All software used to access the Internet shall be configured to provide the highest level of protection
appropriate to the risk to HHS systems and networks.
41. All content on HHS Internet sites must comply with the HHS Enterprise Acceptable Use Standard and other
sets of guidelines and standards developed in the management of Internet content, such as accessibility
standards.
42. No offensive or harassing materials may be linked through or posted to any HHS Internet site.
43. Internet access provided by HHS may not be used for personal solicitation or gain.
(a) Confidential HHS data or sensitive personal information; to include but not limited to PII, PHI, FTI,
transmitted over external network connections must be appropriately encrypted. To see more
information on HHS Data Classification, reference Appendix B.
Cloud Computing
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.
There are three service models:
Software as a Service (SaaS). The capability provided to the consumer is to use the provider’s applications
running on a cloud infrastructure2. The consumer does not manage or control the underlying cloud infrastructure
including network, servers, operating systems, storage, or even individual application capabilities, with the
possible exception of limited user-specific application configuration settings.
Platform as a Service (PaaS). The capability provided to the consumer is to deploy onto the cloud infrastructure
consumer-created or acquired applications created using programming languages, libraries, services, and tools
supported by the provider.
Infrastructure as a Service (IaaS). The capability provided to the consumer is to provision processing, storage,
networks, and other fundamental computing resources where the consumer is able to deploy and run arbitrary
software, which can include operating systems and applications.
Requirements:
To utilize a cloud computing model that receives, processes, stores, or transmits HHS data, the agency must
meet the following requirements:
1. A service level agreement (SLA) is required that has established security policies and procedures that
demonstrate how HHS data is stored, handled, and accessed inside the cloud though a legally binding
contract or service level agreement with their third party provider.
2. Data isolation must be in place within the cloud environment so that tenants sharing physical space
cannot access their neighbor’s physically co-located data and applications.
HHS EISSG v.5.1
Page 14 of 75
3. HHS data must be encrypted when in transit and\or at rest within the cloud environment. All mechanisms
used to encrypt HHS data must be FIPS 140-2 compliant, and operate utilizing the FIPS 140-2 compliant
module. This requirement must be included in the SLA.
4. Any security control implementation claims made by the cloud providers must be validated through a
security plan and security control assessments.
HHS EISSG v.5.1
Page 15 of 75
HHS Information Security Program Policies
Management Policies
The Management program class of controls (safeguards or countermeasures) for an information system is
focused on the management of risk and management of information system security.
1.
Security Assessment and Authorization (CA)
The HHS requires that (i) an initial assessment of the security controls for key information systems is performed to
determine if the controls are effective in their application; (ii) controls are monitored on an ongoing basis to ensure
their continued effectiveness; (iii) information systems containing potential vulnerabilities due to deficiencies in
their controls are documented and acknowledged by the HHS CISO and/or the appointed designee and (iv) plans
of action designed to correct deficiencies and reduce or eliminate vulnerabilities are developed and implemented.
1.1.
Security Assessments
HHS utilizes the Information System Security Plan template to assesses the security controls in an information
system as part of: (i) security assessments; (ii) meeting Federal, State, Local and agency requirements for
periodic assessments; (iii) continuous monitoring; and (iv) testing/evaluation of the information system as part of
the system development life cycle process.
Develops a security assessment plan that describes the scope of the assessment including:

Security controls and control enhancements under assessment;

Assessment procedures to be used to determine security control effectiveness; and

Assessment environment, assessment team, and assessment roles and responsibilities;

Assesses the security controls in the information system to determine the extent to which the controls are
implemented correctly, operating as intended, and producing the desired outcome with respect to meeting
the security requirements for the system;
 Produces a security assessment report that documents the results of the assessment; and
 Provides the results of the security control assessment, in writing, to the authorizing official or authorizing
official designated representative.
1.2.
Plan of Action and Milestones
The plan of action and milestones (POA&M) is a key document in the security authorization package; HHS will
ensure that a POA&M is developed for those key mission critical information systems requiring one.
1.2.1.
1.2.2.
1.3.
Develops a plan of action and milestones for the information system to document HHS planned
remedial actions to correct weaknesses or deficiencies noted during the assessment of the security
controls and to reduce or eliminate known vulnerabilities in the system.
Updates existing plan of action and milestones based on findings from security control assessments
and continuous monitoring activities.
Security Authorization
Security authorization is the official management decision given by a senior organizational official or executive
(i.e., authorizing official) to authorize operation of an information system and to explicitly accept the risk to
organizational operations and assets, individuals, other organizations, based on the implementation of an agreedupon set of security controls.
1.3.1.
1.3.2.
Assigns a senior-level executive or manager to the role of authorizing official for the information
system;
Ensures that the authorizing official authorizes the information system for processing before
commencing operations;
HHS EISSG v.5.1
Page 16 of 75
1.3.3.
1.4.
Through the employment of a comprehensive continuous monitoring process, the critical information
contained in the authorization package shall provide the authorizing official an up-to-date status of the
security state of the information system.
Continuous Monitoring
HHS must establish a continuous monitoring program, which allows HHS to maintain the security authorization of
key mission critical information system over time in a highly dynamic environment of operation with changing
threats, vulnerabilities, technologies, and missions/business processes.
1.4.1.
1.4.2.
2.
Ongoing security control assessments in accordance with the organizational continuous monitoring
strategy;
The continuous monitoring program is to provide updates to the security plan, the security
assessment report and the plan of action and milestones report.
Planning (PL)
The HHS requires the development, documentation, periodic update, and implementation of security plans for
information systems within the HHS environment. HHS CISO ensures that those security plans describe the
security controls in place or planned for the information systems and the rules of behavior for individuals
accessing the information systems.
2.1.
Exceptions
It is the intent of HHS Enterprise that all Owners, Custodians, and Users of HHS IR comply with all HHS
information security standards. However, there will be situations where the strict application of an information
security standard would significantly impair the functionality of a service. The exception standard provides a
method for documenting an exception to compliance with a published HHS standard.
2.1.1.
2.1.2.
2.1.3.
3.
Only temporary exceptions, where immediate compliance would disrupt critical operations, may be
granted. The security exception template, reference Appendix D is to be utilized to request an
exception.
If the Owner believes the exception should be granted, the Owner must then submit the exception
request to the agency IRM or the HHS Chief Information Officer (CIO) if there is no designated
agency IRM.
The HHS CISO may, at his/her discretion, modify the agency IRM’s decision in order to align with
current HHS information security initiatives.
Program Management (PM)
The HHS CISO employs information security requirements that are independent of any particular information
system and considered essential for managing the HHS information security program.
3.1.
Enterprise Architecture
HHS develops an enterprise information security architecture that is aligned with Federal, State, Local and
agency data security and privacy requirements. The integration of information security requirements and
associated security controls into the HHS enterprise information security architecture helps to ensure that security
considerations are addressed by HHS early in the system development life cycle and are directly and explicitly
related to HHS mission/business processes.
3.1.1. HHS develops enterprise security architecture with consideration for information security and the
resulting risk to HHS operations, assets, individuals, and other agencies.
3.2.
Information Security Resources
HHS must provide oversight for the information security-related aspects of the capital planning and investment
control process
3.2.1. HHS ensures that all capital planning and investment requests include the resources needed to
implement the information security program and documents all exceptions to this requirement;
HHS EISSG v.5.1
Page 17 of 75
4.
Risk Assessment (RA)
The HHS CISO requires that risks to HHS operations (including its mission, functions, image, or reputation), HHS
assets, and individuals, resulting from the operation of HHS information systems and the associated processing,
storage, or transmission of HHS information, are assessed.
4.1.
Vulnerability and Risk Assessment
The HHS Vulnerability Assessment Standard establishes the rules necessary to identify and inventory various
exposures to the HHS network(s) while validating compliance with or deviations from the HHS Enterprise
Information Security Policy.
4.1.1. The Agency IRM, or the CIO if no agency IRM exists, shall ensure that internal vulnerability
assessments of IR shall be performed and documented annually.
4.1.2. Risk assessment should be conducted for the information system based on the agency defined
methodology and documented that includes the likelihood and magnitude of harm, from the
unauthorized access, use, disclosure, modification, or destruction of the information system and the
information it processes, stores, or transmits.
4.1.3. Documents risk assessment results in accordance in a risk assessment report
4.1.4. Reviews risk assessment results annually; and
4.1.5. Updates the risk assessment annually or whenever there are significant changes to HHS information
systems or environment of operation (including the identification of new threats and vulnerabilities), or
other conditions that may impact the security or authorization state of the system.
4.1.6. Vulnerability reports and similar information shall be documented and presented to the agency head,
or designated representative, at least once annually.
4.1.7. Vulnerability assessments that focus on specific areas shall be based on the results of a security risk
assessment.
4.1.8. The inherent risk and frequency of the security risk analysis will be ranked, at a minimum, as either
‘High,’ ‘Medium,’ or ‘Low’.
4.1.9. Risk assessments shall identify business owners and custodians and defined respective roles and
responsibilities.
4.1.10. Risk assessments must be updated to account for significant changes in the agency information
systems, assets, operations, personnel, and supporting facilities.
4.1.11. The scope of the inventory of various exposures shall include asset identification and location
identification.
4.1.12. Risk assessment shall include an analysis or evaluation of security controls, corrective actions for
each weakness or finding, and a response for each finding or a mitigation strategy for the acceptance
of risk.
5.
System Services and Acquisition (SA)
The HHS (i) requires sufficient allocation of resources to adequately protect HHS information systems; (ii)
employs system development life cycle processes that incorporate information security considerations; (iii)
employs software usage and installation restrictions; and (iv) ensures that third-party providers employ adequate
security measures to protect information, applications, and/or services outsourced from HHS.
5.1.
Systems Development
The purpose of the Systems Development Standard is to ensure the development and implementation of new
software meets the requirements necessary to assure the security of HHS network(s) and systems.
5.1.1. Systems development projects shall adhere to the Systems Development Life Cycle in force at the
beginning of the development process.
5.1.2. Production systems must have a designated Owner and Custodian.
5.1.3. Production systems must have an access control system to restrict access to the system as well as
restrict the privileges available to Users.
5.1.4. Confidential data must be protected during SDLC phases.
HHS EISSG v.5.1
Page 18 of 75
5.1.5.
A risk assessment must be performed to identify inherent and control risk. It must be signed by the
designated Owner to document that management accepts the level of risk identified.
5.1.6. Application program-based access paths other than the formal User access paths, such as hardcoded backdoors, must be deleted or disabled prior to the software being moved into production.
5.1.7. Procedures must be established to restrict access to systems and software for purposes of testing
and revision to only authorized personnel.
5.1.8. Development and implementation of new software or systems must include adequate documentation
of the information system and its key security components. Information system documentation must
be readily available adequately protected and only distributed to authorized personnel.
5.1.9. All high risk systems must undergo an annual Security Risk Assessment using the DIR ISAAC Risk
Assessment template. (See Section 4.2 Vulnerability and Risk Assessment)
5.1.10. Any IR project that includes a modification, enhancement, new development, or any other changes to
systems, interfaces, or batch processes developed as a requirement for the following programs must
complete a security plan. (Use either the optional Security Plan template available from HHSC Office
of the CISO or an equivalent.)
a. Temporary Assistance for Needy Families
b. Medicaid
c. Supplemental Nutrition Assistance Program
d. Any State program administered under a plan approved under title I, X, or XIV, or title XVI of the
Social Security Act.
e. Any IR Project that meets the definition of a Major Information Resource Project under the
guidance of the Quality Assurance Team (QAT).
5.1.11. Data files, system interfaces and batch processes with Confidential HHS material or individuals’
names in conjunction with their sensitive PII and PHI must be encrypted or otherwise protected as
required by rule, regulation or law during all data transmissions outside of the HHS Local Area
Network (LAN). Examples of confidential or sensitive PII or PHI information includes: social security
numbers, federal tax return information or other medical records.
5.1.12. When cryptography is employed in the information system, agencies must ensure the information
system executes all cryptographic operations using FIPS 140-2 validated cryptographic modules with
approved modes of operation.
5.1.13. All environments that contain copies of Confidential production data must meet all security control
requirements defined in the HHS Enterprise Information Security Standards and Guidelines. Controls
must be re-evaluated at least annually as part of the defined risk assessment and risk management
processes. As part of the annual risk assessment process, both of the following must be
documented:

Responsible HHS custodian assertion that the test environment continues to meet all security
control requirements in the HHS Enterprise Information Security Standards and Guidelines for the
use of the confidential data.

Data owner assertion that (a) the use of confidential data in the test environment is still required
and (b) all personnel including, but not limited to, state and independent contractor employees
provided access to the test environment are still authorized to access the confidential data.
If risk assessment results determine that all control requirements are not met or the identified risks
cannot otherwise be mitigated, the confidential data must be declassified or removed from the test
environment.
5.1.14. Non production functions shall be kept either physically or logically separate from production
functions. Non production environments containing Confidential data (See Appendix B :HHS Data
Classification) require that all personnel including, but not limited to, state and independent contractor
employees provided access to those environments are authorized to access the confidential data.
Access will be provided and managed through individually assigned accounts. Data owners must
provide explicit authorization for access to confidential data contained within test environments and
manage the access in accordance with the HHS Enterprise Information Security Standards and
Guidelines.
HHS EISSG v.5.1
Page 19 of 75
5.1.15. If confidential production data is needed for testing purposes in an environment that cannot meet all
security control requirements defined in the HHS Enterprise Information Security Standards and
Guidelines AND the information cannot be de-classified/de-identified, the use and protection of the
confidential production data will be documented, justified, and approved by the HHS data owner and
the data custodian. Confidential production data will be removed from the non-production
environment immediately upon completion of the required testing.
HHS EISSG v.5.1
Page 20 of 75
Operational Policies
The Operational program class of controls (safeguards or countermeasures) for an information system is primarily
controls that are implemented and executed by people, as opposed to systems.
6.
Awareness and Training (AT)
The HHS (i) requires that users of HHS information systems are made aware of the security risks associated with
their activities and of the applicable laws, executive orders, directives, policies, standards, instructions,
regulations, or procedures related to the security of HHS information systems; and (ii) ensures that HHS
personnel are complying with HHSC information security awareness training requirements.
6.1.
Security Training
The purpose of the Security Training Standard is to ensure Users are aware of and adhere to security
requirements.
6.1.1. New Users must complete the HHS security awareness training program prior to, or within thirty (30)
days of, being granted access to any HHS IR.
6.1.2. Users must sign or electronically acknowledge the Computer Usage Agreement CUA, Form HR0314.
http://hhscx.hhsc.state.tx.us/eit/security/is_forms/HR0314.pdf) stating they have read and agree to
follow HHS requirements regarding computer security policies and procedures.
6.1.3. The Agency ISO must provide Users with sufficient training and supporting reference materials to
enable them to properly protect HHS IR.
6.1.4. The Agency ISO must develop and maintain a process enabling the communication of new computer
security program information, security bulletin information and security items of interest.
6.1.5. Users must reaffirm their commitment to the protection of HHS information resources by completing
the HHS security awareness training program on an annual basis.
6.1.6. All Users must be advised of the criminal and civil sanctions for unauthorized inspection or disclosure
of IRS Federal Tax Information (IRS FTI) and the reporting responsibilities for the loss or
unauthorized access to electronic Protected Health Information (ePHI) and other confidential data.
(See also: Section 15.1 Account Management)
7.
Configuration Management (CM)
The HHS (i) requires that baseline configurations and inventories of HHS information systems (including
hardware, software, firmware, and documentation) are established and maintained throughout the respective
system development life cycles; and (ii) establishes and enforces security configuration settings for information
technology products employed in HHS information systems. The configuration settings are to provide only
essential capabilities and specifically prohibit or restricts the use of ports, protocols and/or services.
7.1.
Change Management
The Change Management Standard establishes a set of rules and administrative guidelines to manage changes
in a rational and predictable manner. In addition, it provides for the necessary documentation of any changes
made so as to reduce any possible negative impact to the Users of HHS IR systems. Changes include, but are
not limited to implementation of new functionality, interruption of service, repair of existing functionality, and the
removal of existing functionality.
7.1.1. Change management will be required based on Agency risk assessment. The risk assessment shall
include operating systems, computing hardware, networks, and applications.
7.1.2. Any change affecting the IR computing environment (HVAC, water, plumbing, alarms, etc.) must be
coordinated with the appropriate IT staff to ensure compliance with the change management process.
7.1.3. Changes to IR must be documented and maintained according to Agency record retention
schedule(s) filed with Texas State Library and Archives.
7.1.4. The appropriate staff and data Owner(s) must review scheduled changes prior to the change. These
review staff may deny or delay the change if it is determined that the change has not been adequately
planned for, suffers from inadequate backup planning, will negatively impact a key business process,
or adequate resources cannot be made available to support the change.
HHS EISSG v.5.1
Page 21 of 75
7.1.5.
7.1.6.
7.1.7.
7.1.8.
8.
User notification, as appropriate to the specifics of the change, must be performed for each
scheduled change.
A change review process must follow all scheduled, unscheduled or emergency changes.
A change management log must be maintained for all changes and must be stored as a part of
Systems Development Life Cycle (SDLC) documentation.
Changes to HHS IR systems should follow the approved CM policy and process to allow for risk
mitigation to prevent unplanned outages and minimize data risk.
Contingency Planning (CP)
The HHS requires that plans for emergency response, backup operations, and post-disaster recovery for HHS
information systems are established, maintained and effectively implemented to ensure the availability of critical
information resources and continuity of operations in emergency situations.
8.1.
Back-up and Disaster Recovery
Backing up data and applications is an HHS business requirement. It enables the recovery of data and
applications in the event of loss or damage (natural disasters, system disk and other systems failures, intentional
or unintentional human acts, data entry errors, or systems operator errors). This standard applies to HHS IR and
vendors who operate information systems on behalf of an HHS agency.
8.1.1. The HHS business continuity and disaster recovery plans provide the required frequency and extent
of the backups. Frequency and extent may vary, depending on data classification and /or Owner
requirements. The Information Resources Manager (IRM) or designee, Chief Information Officer
(CIO) or designee must approve all backup and recovery plans and procedures.
8.1.2. Backup and recovery processes for all HHS information systems and resources must be documented
and periodically reviewed by the agency IRM or designee, the CIO or designee.
8.1.3. Offsite storage providers of HHS IR must be able to provide protection for the highest risk level of
information being stored. Physical access controls in use at any offsite storage location must meet or
exceed the physical access controls defined for the source system.
8.1.4. Offsite storage facilities must be geographically located away from the primary physical location of the
HHS information resource so that a single disaster shall not destroy the data at both sites. A
minimum of 10 miles is recommended.
8.1.5. Identification data used in granting access to the offsite storage facility must be reviewed on a regular
basis and changed or updated to reflect changes brought about by changes in authorized access
personnel.
8.1.6. Media used in the provision of backup storage must be protected in accordance with the highest level
of sensitivity of the information being stored.
8.1.7. All backups must be verified that they were successful.
8.1.8. Electronic information backups must be periodically tested to ensure recoverability.
8.1.9. Stored data must have, at a minimum, the following data clearly identifiable by labels and/or other
coding systems:
a. System Name,
b. Creation Date,
c. Sensitivity Classification (based on applicable record retention regulations),
d. HHS Contact Information.
9.
Incident Response (IR)
The HHS (i) establishes an operational incident handling capability for HHS information systems that includes
adequate preparation, detection, analysis, containment, recovery, and user response activities; and (ii) tracks,
documents, and reports incidents to appropriate HHS and HHSC officials and/or authorities.
9.1.
Incident Management
The Incident Management Standard establishes requirements for dealing with computer security incidents. These
security incidents include, but are not limited to: virus, worm and Trojan detection, unauthorized use of computer
HHS EISSG v.5.1
Page 22 of 75
accounts and systems, and improper use of resources as outlined in these standards related to E-mail, Internet
and Acceptable Use. Security incidents also include theft of hardware and/or data.
HHS Enterprise Information Security Policy and associated requirements, specifically Incident Response, is to
protect HHS Enterprise information resources against unauthorized access, disclosure, modification or
destruction of information. The purpose of the Incident Management Standard is to have a set of structured
actions in place to identify and respond to an assessed occurrence having actual or potentially adverse effects on
HHS information resources. The scope of the standard is to have in place procedures to make an initial
assessment of the incident, communicate the incident, contain the damage and minimize the risk, identify the type
and severity of the incident, notify external agencies if appropriate, recover systems, compile and organize
incident documentation, and review the response and update policies.
9.1.1. A Computer Security Incident Response Team (CSIRT) is established with membership having predefined roles and responsibilities. These CSIRT responsibilities may, during a security incident, take
priority over the members’ normal job functions.
9.1.2. The Incident Management procedures must be followed whenever a security incident is suspected or
confirmed. All security incidents must be tracked and documented. For information systems with IRS
FTI a test and/or exercise shall be conducted at least annually to determine incident response
effectiveness.
9.1.3. The ISO, or designee, is responsible for notifying the IRM, or the CIO, the Office of Inspector General
(OIG), the CSIRT, and any Owner(s) involved in or affected by the security incident, and shall initiate
the appropriate incident management action(s).
9.1.4. The ISO, or designee, is responsible for initiating, completing, and documenting the incident
investigation with the assistance from the CSIRT and shall report the incident to the appropriate
management at the DIR, as outlined in the requirements of Title 1 Texas Administrative Code (TAC)
Chapter 202, and the OIG as appropriate.
9.1.5. The appropriate technical personnel from the CSIRT are responsible for monitoring any damage
resulting from the security incident. In addition, they are responsible for ensuring its repair or
mitigation, and eliminating or minimizing, as appropriate, the area of vulnerability.
9.1.6. The ISO, working with the IRM or CIO, shall determine if a widespread communication related to the
incident is required. If communication is required, they are also responsible for its content and
distribution.
9.1.7. The appropriate technical personnel from the CSIRT are responsible for communicating any relevant
issues or vulnerabilities to any vendor involved in or affected by the security incident and for working
with the vendor to eliminate or mitigate these vulnerabilities.
10.
Maintenance (MA)
The HHS requires that (i) periodic and timely maintenance on HHS information systems occur; and (ii) effective
controls on the tools, techniques, mechanisms, and personnel used to conduct information system maintenance
are in place.
10.1. Controlled Maintenance
HHS must ensure that information security aspects of the organization’s information system maintenance
program are addressed.
10.1.1. HHS schedules, performs, documents, and reviews records of maintenance and repairs on
information system components in accordance with manufacturer or vendor specifications and/or
HHS requirements;
11.
Media Protection (MP)
The HHS requires (i) the protection of digital and non-digital information system media (ii) access to information
on information system media is limited to authorized users; and (iii) information system media is sanitized or
destroyed before disposal or release for reuse.
HHS EISSG v.5.1
Page 23 of 75
11.1. Media Access and storage
HHS must have safeguards in place to restrict access to Information system media which includes both digital
media (e.g., diskettes, magnetic tapes, external/removable hard drives, flash/thumb drives, compact disks, and
digital video disks) and non-digital media (e.g., paper, microfilm). This standard applies to mobile computing and
communications devices with information storage capability (e.g., notebook/laptop computers, smart phones,
digital cameras, and audio recording devices). The above devices require encryption.
11.1.1. Restrict access to media storage areas and to audit access attempts and access granted
11.1.2. Employ cryptographic mechanisms to protect information in storage.
11.1.3. Ensures the protection of information system media until the media is destroyed or sanitized using
approved equipment, techniques, and procedures.
11.2. Removable Media
The HHS Removable Media Security Standard establishes those rules necessary to protect HHS data and
networks and satisfies compliance requirements of state and federal law with regard to disposal and reuse of
media that contain electronic Protected Health Information (ePHI) and other confidential data. These include, but
are not limited to:
 Diskettes, tapes, DVD and/or compact disks (CD’s);
 Memory cards/sticks used in various portable digital devices;
 FireWire / USB “Flash/ Key/ Pen/ Thumb” drive memory devices.
 Portable mass storage devices
11.2.1. All HHS portable mass storage or removable media must at a minimum be password protected or
encrypted where technically feasible.
11.2.2. Agency Internal, confidential, and restricted personal information data, including ePHI that is stored
on removable media or in paper form, that is being transported to another location, must be labeled
as confidential according to agency requirements. There must be a return address, and the media
must be physically handed off and signed for, and tracked until it reaches its final destination, based
on agency management risk decision. This includes facsimiles and printed materials sent by postal
service or courier such as the United States Postal Service, FedEx, United Parcel Service of America
(UPS), Mailmax, and agency or personal vehicles
11.2.3. In the event of loss or theft of the removable media containing Agency Internal, confidential, or
restricted personal information, a description of the data and index or table of contents must be
provided with the report of loss or theft to the agency ISO within 24 hours.
11.2.4. All removable media must be scanned for malicious code content prior to use in HHS systems and/or
networks.
11.2.5. Re-use or disposal of removable media will follow the DIR Guideline for Removal of Data from Data
Processing Equipment to ensure removal of any Agency Internal, confidential and restricted personal
information, including ePHI.
12.
Physical and Environmental Protection (PE)
The HHS coordinates with Texas Facilities Commission (TFC) and/or other owning facility management
organizations to (i) limit physical access to information systems, equipment, and the respective operating
environments to authorized individuals; (ii) protect the physical plant and support infrastructure for information
systems; (iii) provide supporting utilities for information systems; (iv) protect information systems against
environmental hazards; and (v) provide appropriate environmental controls in facilities containing information
systems.
12.1. Physical Access
The Physical Access Standard establishes rules for granting, controlling, monitoring and removing physical
access to HHS IR facilities.
12.1.1. Physical security policy and procedures for all Data Centers must adhere to those established in the
Information Security Controls for State of Texas Data Center Services (DCS) Master System Security
Plan (MSSP) technical specification document and associated contractual documents.
HHS EISSG v.5.1
Page 24 of 75
12.1.2. Physical security systems must comply with applicable regulations such as building codes and fire
regulations.
12.1.3. Physical access to all restricted IR facilities or areas must be documented and managed.
12.1.4. HHS IR must be physically protected in proportion to the importance of their function within HHS and the
confidentiality required by rule, regulation or law.
12.1.5. Access to IR facilities must be granted only to authorized users whose job responsibilities require
access.
12.1.6. The process for granting access, via key-card or otherwise, to information resource facilities must
include the approval of the IRM, the CIO if no agency IRM exists or designated office or staff person
responsible for the facility.
12.1.7. All access requests to data centers must be justified (not just 24 hour access); if requesting personnel do
not perform direct support for the servers or other data center equipment access will be denied.
12.1.8. Each User granted access to IR secured facilities must sign the appropriate access and non-disclosure
agreements. Access and non-disclosure agreements must be maintained in accordance with records
retention requirements.
12.1.9. The applicable data or system Owner must initiate requests for access to secured facilities.
12.1.10. Access to secured facilities and/or key-cards must not be shared or loaned.
12.1.11. Access materials and/or key-cards that are no longer required must be returned to the appropriate HHS
IT representative. Under no circumstances is a “retired” card to be passed directly to another User.
12.1.12. Functional capabilities for an access key-card must be deactivated upon termination of need.
12.1.13. Lost or stolen access key-cards must be reported to the appropriate facility manager immediately upon
the User becoming aware of the loss.
12.1.14. Any HHS IR secured facility that allows access to visitors will track visitors’ access with a sign in/out log.
12.1.15. Visitors to controlled facilities must wear a visitor's badge, sign in and out at a reception area, and be
escorted when in restricted areas.
12.1.16. Access records, entry and exit logs, and visitor logs must be kept based on records retention or other
state or federal requirements.
12.1.17. Visitor logs and access records must be reviewed at least quarterly by HHS management.
12.1.18. Signs posted to inform of the restricted access to certain rooms or buildings must be posted in a manner
that serves their purpose without drawing attention to the secured nature of the site.
13.
Personnel Security (PS)
The HHS works with HHSC human resources to (i) ensure that individuals occupying positions of responsibility
within HHS (including third-party service providers) are trustworthy and meet established security criteria for those
positions; (ii) ensure that HHS information and information systems are protected during and after personnel
actions such as terminations and transfers; and (iii) employ formal sanctions for personnel failing to comply with
HHS security policies and procedures.
13.1. Third-Party Personnel Security
HHS requires all third party providers to comply with all HHS security policies and standards. Third-party
providers include, for example, service bureaus, contractors, and other organizations providing information
system development, information technology services, outsourced applications, and network and security
management.
13.1.1. Establishes personnel security requirements including security roles and responsibilities for thirdparty providers;
13.1.2. Documents personnel security requirements; and
13.1.3. Monitors providers for compliance.
14.
System and Information Integrity (SI)
The HHS CISO provides oversight to ensure (i) the identification, reporting, and the correction of information
system flaws in a timely manner; (ii) protection from malicious code at appropriate locations within HHS
HHS EISSG v.5.1
Page 25 of 75
information systems; and (iii) the monitoring of information system security alerts and advisories, and execution of
appropriate actions.
14.1. Anti-Spam
As digital messaging (e-mail, cellular messaging, etc.) has become an integral part of the business process, its
abuse has also grown. This abuse often is manifested as “spam” or “junk” messaging which has the potential to,
beyond its annoying nature, slow-down and/or clog the infrastructure required to process electronic messages. In
addition, “spam” is often used as a transmission vehicle in the migration of malicious code infections.
14.1.1. HHS Management retains the right to examine any message item for subject and/or content to
determine abuse.
14.1.2. HHS Information Technology (IT) management, in consultation with other HHS management,
reserves the right to filter and/or block any message item, inbound or outbound, which is determined
to place HHS, its systems, and/or networks at an unacceptable level of risk.
14.1.3. HHS IT shall, in consultation and aligned with industry best practices, filter and/or block any
attachment or enclosure to any message that places the HHS systems and/or networks at an
unacceptable level of risk.
14.1.4. HHS IT shall identify a listing of key words and phrases that are common to “spam” and shall filter
those words and phrases on all inbound message items in order to prevent those items from entering
the HHS systems and/or networks.
14.1.5. All Users of HHS messaging systems shall refrain from forwarding multiple copies of received
message items that are not directly connected to the HHS business process without the explicit
consent of the recipient.
14.2. System Configuration Hardening / Patch Management
The System Configuration Hardening / Patch Management Standard is created to ensure that HHS systems are
installed and maintained in a manner that prevents unauthorized access, unauthorized use, and disruptions in
services provided.
14.2.1. A system may not be connected to the HHS network until it is in a secure state and the network
connection is reviewed and approved by the appropriate agency IRM or the CIO if no agency IRM
exists.
14.2.2. The HHS configuration hardening standards shall include, but are not limited to:
a. Operating Systems may only be installed from IR approved sources.
b. Vendor-supplied patches shall be applied.
c. Unnecessary software, system port / protocol services and drivers shall be removed.
d. Appropriate security parameters, field protections and audit-logging capabilities shall be set and
periodically reviewed.
e. Default account passwords shall be changed on first use according to password standards.
f. Security configurations must be set to the most restrictive mode consistent with information
system operational requirements, and according to the level of risk formally accepted by owners
of the information systems.
g. The information system must be configured to provide only essential capabilities and specifically
prohibits and/or restricts the use of unnecessary functions, ports, protocols, or services.
14.2.3. Agency IT will monitor security issues and will manage the release of security patches.
14.2.4. Agency IT will test security patches against core resources prior to their release where practical.
14.2.5. Security patches must be implemented within the specified timeframe after notification by the Agency
ISO.
14.2.6. Agency IT will review services running and open ports at least once annually.
14.2.7. System initialization (Bios/CMOS) settings shall be password-protected for all systems that provide
access to confidential data.
14.3. Malicious Code
HHS EISSG v.5.1
Page 26 of 75
The purpose of the HHS Malicious Code Standard is to describe requirements for dealing with digital infections
referred to as “Malware” (including virus, worm, Trojan, Spyware and other similar infections), and their
prevention, detection and cleanup.
14.3.1. All workstations (desktop, notebook, laptop, wireless or any device capable of digital interaction with
HHS networks, systems and/or applications) whether connected to the HHS network, or used
remotely or stand-alone, must use malware protection software and have configurations equivalent to
that of HHS computing devices.
14.3.2. Each file server attached to the HHS network(s) must utilize HHS approved malware protection
software and setup to detect and clean malware.
14.3.3. Each e-mail gateway must use HHS approved e-mail malware protection software and must adhere
to the agency architecture for its setup and use.
14.3.4. Malware protection software must not be disabled or bypassed without the approval and involvement
of appropriate HHS IT staff.
14.3.5. Settings for malware protection software must not be altered in any manner that will reduce the
effectiveness of the software.
14.3.6. All virus protection mechanisms (including the latest virus definitions) must be updated when new
versions or releases are available and appropriate testing is completed.
14.3.7. Any automatic update frequency of the malware protection software designed into the software or
established as a batch process within the HHS network must not be altered to reduce the frequency
of updates.
14.3.8. Any malware that is not automatically cleaned by the software constitutes a security incident and
must be reported to the appropriate Help Desk within HHS.
14.4. Operating Systems
The HHS Operating Systems Standard establishes the rules necessary for the installation and maintenance of
HHS operating system software.
14.4.1. Installation of operating system software shall be documented and reviewed.
14.4.2. All operating system software must have appropriate patches. Security-related operating system or
software application patches must be reviewed and installed in a timely manner, consistent with the
criticality and vulnerability of the resource.
14.4.3. Operating system software changes shall be authorized, tested and approved in accordance with
HHS IR change management processes before being implemented.
14.4.4. Operating system software will be installed with the minimum number of services required to fulfill the
designated function.
14.4.5. Operating systems software will provide application software environments for all non-operating
system activities, which are separated from the operating system environment.
14.4.6. Use of operating system functions and functionality by application software will be through specifically
defined interfaces for those purposes.
14.4.7. Application software, as distinguished from operating systems software, will be unable to assume
access privileges normally reserved to the operating system.
14.4.8. Any use of host operating systems and application environments that do not conform to this standard
will be phased out as soon as possible.
HHS EISSG v.5.1
Page 27 of 75
Technical Policies
The Technical program class of controls for an information system is primarily controls that are implemented and
executed through mechanisms contained in the hardware, software, or firmware components of the information
system.
15.
Access Control (AC)
The HHS requires that access to applications, servers, databases, and network devices in the HHS environment
is limited to authorized personnel. Access is limited to authorized users, processes acting on behalf of authorized
users, or devices. Authorized users are further limited to the types of transactions and functions that they are
permitted to exercise.
15.1. Account Management
Account Management establishes the standards for the creation, monitoring, control, and removal of accounts.
The Account Management standard shall apply equally to all User accounts without regard to their status or
category.
User accounts are the means by which access is granted to HHS IR. They are granted to employees, volunteers,
vendors, contractors, students and others determined to have need. These accounts assist in establishing
accountability for systems use and are a key component in the protection of data confidentiality and integrity.
15.1.1. All Users must sign or electronically acknowledge the HHS Enterprise Computer Use Agreement
(http://hhscx.hhsc.state.tx.us/eit/security/is_forms/HR0314.pdf CUA, Form HR0314) before access is
given to any IR. Additional documentation may also be required. For example, all Users with access
to Federal Tax Information must sign a Form IRS-CSA (Computer Security Agreement) and affirm the
agreement annually
15.1.2. The appropriate access request processes must be completed and approved before a User account
is created and the User is granted access rights to any HHS IR.
15.1.3. The manager/supervisor of any HHS user must ensure that access to any HHS information resource
has been properly authorized and that such access is sufficient to complete job functions or is based
on a valid “need to know” and intended system usage. In other words, users should only be granted
access to the extent that the user must have access to confidential information or resources sufficient
to accomplish official duties.
15.1.4. Access to protected health information must be restricted to appropriate individuals and entitled
program areas only. Procedures must be in place to protect this health information from unauthorized
access by the organization at large.
15.1.5. Each User shall be assigned a unique identifier except for situations where risk analysis
demonstrates no need for individual accountability of Users.
15.1.6. Application owners are responsible for ensuring that a review of the creation, modification, disabling,
and termination actions of each authorized user and account access levels is conducted. Account
access levels will be reviewed, at a minimum, every twelve (12) months for appropriateness.
Application owners will notify IR Custodians or other appropriate security administrators of changes to
user accounts or access levels upon completion of an annual review or when changes occur.
15.1.7. Unsuccessful account access attempts must be monitored and accounts locked after failed attempts
as determined by a documented risk assessment.
15.1.8. HHS components disable inactive privileged accounts after sixty (60) days and non-privileged
accounts after ninety (90) days.
15.1.9. All User accounts that have not been accessed within ninety (90) days of creation will be disabled.
Exceptions to this include:
a. Certain accounts held in suspense for the purpose of application maintenance.
b. Accounts established for the purpose of quarterly, semiannual or annual usage.
15.1.10.
The manager/supervisor of any HHS IR user that shall be absent from the work place for a period in
excess of ninety (90) days must notify the Custodian or a designee responsible for that area. The
User’s account will be disabled during their absence and reactivated upon notification of their return.
HHS EISSG v.5.1
Page 28 of 75
15.1.11.
15.1.12.
15.1.13.
15.1.14.
15.1.15.
All accounts established for employees, contractors, consultants, interns, vendors and/or
maintenance accounts must be disabled immediately upon termination or completion of the contract
period.
Accounts that have been disabled due to a user termination will be deleted when technically feasible
within 90 days of disabling the account unless documented exceptions exist. Supervisors or internal
HHS management of the terminated employee, contractor, consultant, intern, or vendors must ensure
that all files, data or other electronic documents pertaining to State of Texas business are maintained
in accordance with records retention requirements.
All HHS partner organizations (private providers, Community Centers, etc.) must sign an agreement
that requires them to notify HHS when their User accounts change due to termination or transfer.
Upon notification, these accounts must be disabled or reassigned in compliance with application
specific requirements.
In the event of involuntary terminations of employees, contractors, consultants, interns or vendors
contact the agency designated Information Security Officer (ISO) or Enterprise Security Management
if immediate deactivation of security access is warranted.
Custodians or other designated staff:
(a) Must have a documented process (es) to manage accounts in the event of User’s termination of
employment or change in job status necessitating the termination or modification of a User’s
access.
(b) Must have a documented process (es) to modify a User account to accommodate situations such
as name changes, accounting changes, and permission changes.
(c) Are responsible for modifying or disabling the accounts of individuals who change roles within
HHS or are separated from their relationship with HHS.
(d) Must have a documented process (es) for periodically reviewing existing accounts for approved
access.
(e) Must maintain a current list of accounts for the systems they administer.
(f) Must provide a list of accounts for the systems they administer when requested by authorized
HHS management.
(g) Must cooperate with authorized HHS management investigating computer security incidents.
(h) Must restrict access to privileged functions (deployed in hardware, software, and firmware) and
security-relevant information to explicitly authorized personnel. Explicitly authorized personnel
includes; system and security administrators, network administrators and systems programmers,
database administrators or other personnel performing maintenance or system control and
monitoring.
15.2. Administrative and Special Access
On occasion, certain staff and/or consulting personnel may be granted levels of access to HHS systems that
exceed the account privileges granted the regular User. Typically, these are positions providing technical support
and/or administrative functions. The nature of these accounts requires a higher level of control and monitoring on
the part of security administrators throughout the HHS System.
The Administrative and Special Access standards establish those parameters to which the User granted this
access must adhere in order to adequately protect the information resources of HHS.
15.2.1. Prior to receiving access privileges to HHS systems, Users must sign the HHS Enterprise Computer
Usage Agreement (HR0314) and other security and privacy agreements appropriate to their status.
15.2.2. Each User of HHS Administrative/Special Access accounts shall be assigned a unique identifier,
except for situations where risk analysis demonstrates no need for individual accountability of Users.
15.2.3. Users with Administrative/Special Access must use the account privileges most appropriate to the
work they are performing. For example, they will not make use of their administrator account to
perform work more appropriately performed while using their standard User account.
15.2.4. Users with Administrative/Special Access will maintain a password for that account in compliance
with the HHS Password Standards. (See also: Section 17.1 Passwords)
15.2.5. Any password used in relation with a primary Administrator/Special Access account must be changed
when any individual with knowledge of that password changes duties such that they no longer require
access, including change of job duties, termination, etc. Any User of a primary Administrator account
HHS EISSG v.5.1
Page 29 of 75
(root, enterprise, etc.) must participate in password escrow so that another approved User, other than
the original administrator may access that account in the event of an emergency.
15.2.6. Any default administrative account must be renamed upon first use.
15.2.7. Any Special Access account created on behalf of specialized research projects, internal or external
audit needs and requirements, software installation, testing or development projects, or any other
defined need must:
a. Be authorized by the appropriate HHS staff position or administrator,
b. Be established with a specific and defined date of expiration, and
c. Be removed when the work is completed or the expiration date is reached, whichever is first.
d. The process (es) for changing and amending Special Access accounts must be documented.
15.2.8. Remote administration accounts must be approved by the Chief Information Officer, agency IRM, or
designee. Where remote administration is justified, transmittal of the administrator credentials and
other administration activities must be encrypted. (See also: Section 15.6 Portable/Remote
Computing).
15.3. Imaging Devices
The HHS Imaging Devices Security Standard mitigates risks associated with the increased use of devices that
have the capability to capture images for storage and/or transmission. Such devices with camera capabilities,
whether built in or attached, may include, but are not limited to, cellular telephones, Personal Digital Assistants
(PDAs), laptop/notebook computers, digital cameras, and/or digital video recording devices of any sort.
15.3.1. The use of such devices is allowed to the extent that there is an HHS business reason. In any case,
the Owner is responsible for the protection of all sensitive, confidential or information to which
employees, contractors, vendors, visitors or others may have access either as a granted right or by
accidental exposure.
15.3.2. Any device that has the capability to capture, store and/or transmit an image of any document,
person, or environment (still or in motion) under the authority of this policy shall have the image
capturing function disabled while in restricted HHS environments. Restricted HHS environments are
defined by Agency risk management decision.
15.3.3. Exemptions to this policy include dedicated document scanning devices and other equipment
designed specifically to capture document images for archival storage.
15.3.4. Requests for any other exemptions to this policy must be approved in writing prior to use of the
device. The exemption approval authority shall be one or more of the following:
a. Chief Information Officer (CIO), Chief Operations Officer (COO), or Chief Executive Officer
(CEO),
b. IRM or Agency Designee,
c. ISO, and/or
d. Enterprise Security Manager.
15.4. Network Access
The HHS Network Access Standard establishes security rules for the access and use of the network
infrastructure.
15.4.1. Network equipment, such as servers, firewalls, routers, switches, wireless access points, etc., shall
be installed in a manner and location to prevent unauthorized access and tampering.
15.4.2. Users are permitted to use only those network addresses and access points issued to them by HHS
IT.
15.4.3. Remote Users may connect to HHS IR using only those protocols approved by HHS IT. (See also:
Section 15.6 Portable/Remote Computing)
15.4.4. Users must not extend or re-transmit network services without agency IRM, or the CIO if no agency
IRM exists, or designee approval.
15.4.5. Users must not install hardware or software that provides network services without the approval of the
agency IRM, or the CIO if no agency IRM exists or a designee.
15.4.6. Non-HHS systems that require network connectivity must conform to HHS information security
policies, standards, procedures, and guidelines.
HHS EISSG v.5.1
Page 30 of 75
15.4.7. Users must not download, install or run application programs or utilities that reveal or exploit
weaknesses in the security of a system except as part of the official systems security management
process.
15.4.8. The use of unapproved tools such as password cracking programs, packet sniffers, network-mapping
tools, or port scanners are prohibited except as part of the official systems security management
process.
15.4.9. Users must not alter network hardware without authorization from the appropriate agency IRM, the
CIO if no agency IRM exists or a designee.
15.5. Network Configuration
The HHS Network Configuration Standard establishes the rules necessary for the maintenance, expansion, and
use of the HHS network infrastructure.
15.5.1. HHS IT is responsible for the oversight of the network infrastructure. The Wide Area Network is
maintained by the Department of Information Resources.
15.5.2. Networking development (including cabling) must be installed by appropriate HHS personnel or an
approved contractor.
15.5.3. Equipment connected to the HHS network must be configured to specifications approved by HHS IT.
15.5.4. Any hardware connected to the HHS network infrastructure is subject to HHS IT management
process and standards.
15.5.5. Changes to the configurations of any active network management device must not be made without
authorization from the CIO, agency IRM or designee.
15.5.6. The CIO, agency IRM or designee must approve any use of non-sanctioned protocols.
15.5.7. Any connection to the HHS network infrastructure by third party networks, including
telecommunications, must be approved by the CIO, agency IRM or designee.
15.5.8. The use of independently deployed firewalls or other non-standard tools is not permitted without the
written authorization of agency IRM, the CIO if no agency IRM exists or a designee.
15.5.9. Users must not install hardware or software that provides network services without the approval of the
CIO, agency IRM or designee.
15.5.10. Users must not alter network hardware without authorization from the CIO, agency IRM or designee.
15.6. Portable/Remote Computing
The HHS Portable Computing/Remote Security Standard establishes rules necessary to mitigate risks associated
with the use of HHS mobile computing devices and their connection to the HHS network(s). This includes any
easily portable device that is capable of receiving and/or transmitting data to and from an Information Resource.
These devices include, but are not limited to, laptop and notebook computers, handheld computers, Personal
Digital Assistants (PDA’s), pagers and digital/cellular telephones. (See also: Section 11.2 Removable Media and
Section 15.9 Wireless Computing)
15.6.1. Portable computing devices may be used to access HHS IR based on prior approval by the agency
IRM, the CIO if no agency IRM exists or a designee.
15.6.2. HHS owned/leased portable computing devices must be password protected.
15.6.3. All HHS portable/remote computing devices must be encrypted.
15.6.4. Remote access to HHS IR by means of non-HHS owned/leased computing devices must provide
User authentication including, at a minimum, a unique User identifier and a password.
15.6.5. All remote access sessions must employ cryptography to protect the confidentiality and integrity of
remote sessions.
15.6.6. All remote access sessions are subject to the Security Monitoring Standard of Section 16.2.
15.6.7. Remote access to HHS must be either through an approved modem pool or via a recognized Internet
Service Provider.
15.6.8. In the case of remote access from approved home-based computing devices, firewall, antiadware/spyware, antivirus protection and appropriate security patch levels must be installed and
maintained by the remote User.
HHS EISSG v.5.1
Page 31 of 75
15.6.9. Remote access for privileged functions must only be granted for compelling operational needs and
the rational for such access must be documented in the system security plan.
15.6.10. Non-HHS systems that require network connectivity must conform to HHS agency standards/policies
and must be approved by HHS agency IRM, the CIO if no agency IRM exists or a designee.
15.6.11. Unattended portable computing devices must be physically secured by locking devices and/or locked
storage.
15.6.12. Portable computing devices must maintain active firewall, anti-adware/spyware, antivirus protection
and appropriate security patch levels equivalent to those applied to any other HHS computing device.
15.6.13. When remote access is allowed as a part of an Eligibility Determination process in the Temporary
Assistance for Needy Families, Supplemental Nutrition Assistance Program, Medicaid, or any State
or Federal program administered under a plan approved under Title I, X, or XIV, or Title XVI of the
Social Security Act, then the following remote access requirements also apply: (See also: OMB-M-0616 Memorandum for Heads of Departments and Agencies)
a. Remote access to PII or confidential data must only be allowed when the access includes twofactor authentication where one of the factors is provided by a device separate from the computer
gaining access. For example, this access can be accomplished via a virtual private network
(VPN) connection established using agency-issued authentication certificate(s) or hardware
token.
b. When remote access is allowed users must also adhere to HHS agency standards/policies for
protecting downloaded or remote storage of PII or confidential information. The information
system being accessed remotely must employ automated controls to ensure that PII or
confidential information cannot be downloaded, physically removed, or remotely stored unless
authorized, or granted on a need to know basis.
c. When remote access is allowed the information must also employ automated methods for logging
all computer-readable data extracts from databases holding PII or confidential information.
Users must verify each extract including PII data has been erased within 90 days or its use is still
required.
d. When remote access to PII or confidential information is allowed the information system must
prevent further access to the system by initiating a session lock after 30 minutes of inactivity, and
the session lock remains in effect until the user re-establishes access using appropriate
identification and authentication procedures.
15.7. Vendor Access
The HHS Vendor Access Standard is intended to assure the security of HHS IR assets when vendor interaction is
involved.
15.7.1. Vendors must comply with all applicable HHS policies, practices, standards and agreements.
15.7.2. Vendor agreements must specify the HHS information resources to which the vendor should have
access.
15.7.3. Vendor agreements must specify how HHS information resources are to be protected by the vendor.
These protections must meet or exceed existing protections within the HHS networks.
15.7.4. Vendor agreements must specify that upon the departure of a vendor employee that
a. All HHS materials will be collected and returned to HHS or destroyed, as appropriate, and
b. The vendor will return or destroy all HHS information and provide written assurance of that
destruction upon termination of the agreement or at the request of HHS.
15.7.5. Vendor agreements must specify that HHS information resources will be used only for the purpose of
the terms of the business agreement. Contract Managers must retain vendor agreement
documentation in accordance with records retention requirements.
15.7.6. Vendor agreements must specify that any additional HHS information encountered during the
fulfillment of the agreement cannot be used for the vendor’s own purposes or disclosed to others.
15.7.7. HHS will provide an IT contact for the vendor. This individual shall work with the vendor to ensure
compliance with applicable HHS requirements.
15.7.8. Vendors must provide HHS IT with a list of all vendor employees who will be performing work on the
contract/agreement. This list must be updated or amended within 24 hours of any change. Contract
HHS EISSG v.5.1
Page 32 of 75
Managers must retain vendor employee documentation in accordance with records retention
requirements.
15.7.9. Vendor employees must report all computer security incidents or potential incidents directly to the
agency ISO or designee upon discovery immediately, no later than 24 hours.
15.7.10. Vendors must follow all applicable HHS change control processes and procedures.
15.7.11. Any vendor owned information resource equipment connected to the HHS network with the intent of
additional connection outside the HHS network via the network, telephone lines, leased lines or any
other method will remain disabled except when in use for the purpose of authorized maintenance
functions or other functions clearly defined in the terms of the vendor agreement.
15.7.12. Vendors must comply with all State and HHS auditing requirements, including the auditing of the
vendor’s work.
15.7.13. All software used by the vendor in the provision of services to HHS must be properly licensed and
inventoried.
15.8. Virtual Private Network (VPN)
The HHS VPN Security Policy establishes those rules necessary to mitigate risks associated with remote
connections to the HHS network(s) made by means of an approved VPN connection.
15.8.1. All Virtual Private Networks connected to HHS networks must be approved by the CIO, agency IRM,
or designee.
15.8.2. Approved Users may utilize the benefits of VPN. VPN access, granted by request to HHS, is a “User
managed” service. In all events, the User is responsible for the selection of an Internet Service
Provider (ISP), coordinating installation, installing any required software, and paying any required
fees.
15.8.3. VPN connected equipment is subject to the same rules, policies and regulations that apply to HHS
owned equipment.
15.8.4. It is the User’s responsibility, when connected to HHS networks via VPN, to assure that unauthorized
Users are not allowed access to the HHS networks through the VPN connection.
15.8.5. The use of VPN access to HHS networks must be controlled by using password authentication, token
devices or public/private key systems incorporating a strong password and/or pass-phrase.
15.8.6. VPN connections to HHS networks must force all traffic over the VPN tunnel. All other traffic will be
dropped.
15.8.7. Any computing device connected to HHS networks or any other HHS technology must be protected
by the use of a firewall that meets the standards of HHS.
15.8.8. Any computing device connected to HHS networks or any other HHS technology must use anti-virus
software and configurations approved by HHS IT. Anti-virus configurations will include real time as
well as passive scanning and maintain current virus definitions.
15.8.9. VPN connections will be automatically disconnected after a period of non-use or inactivity. In this
event, the User must log in again. The use of any technology to maintain an inactive connection
(ping, stay-connect, etc.) is prohibited and can result in termination of the VPN account.
15.8.10. Users of any computing device not owned by HHS must configure that device to comply with all HHS
standards and security policies while connected to the HHS networks.
15.8.11. The use of any VPN client other that the one provided by HHS or its service provider is prohibited.
15.8.12. The VPN User must monitor and report intrusion or security incidents to HHS as set forth in the HHS
Enterprise Information Security Policy.
15.8.13. The VPN User is subject to audit to insure compliance with this VPN Standard and HHS Enterprise
Information Security Policy
15.9. Wireless Computing
The HHS Wireless Computing Standard establishes those rules necessary to mitigate risks associated with the
use of devices that have the capability to connect computing devices to networks without the use of wires or
cables, such as:
 Wireless base and/or access points (built-in or attached),
HHS EISSG v.5.1
Page 33 of 75

15.9.1.
15.9.2.
15.9.3.
15.9.4.
15.9.5.
Personal Digital Assistants (PDA), text messaging devices or cellular/digital PDA-based
telecommunication devices (smart phones) with wireless connectivity capabilities (built-in or
attached),
 Laptop/Notebook Computers with wireless connectivity capabilities (built-in or attached), and
 Wireless transmitting and/or receiving devices used to transfer audio, video or data of any sort.
 Wireless Local Area Networks – Based on the IEEE 802.11 family of standards.
 Wireless Personal Area Networks – Based on Bluetooth, wireless USB, Infrared, or other limited
range technologies.
The User is responsible for the protection of all sensitive or confidential information to which they may
have access, either as a granted right or by accidental exposure.
All HHS devices with wireless capability must be encrypted. In addition, any HHS removable media
devices must at a minimum be password protected or encrypted where technically feasible. (See
also: Section 15.6 Portable/Remote Computing and Section 11.2 Removable Media)
Any wireless data transmissions that may contain sensitive, confidential and restricted personal
information, including electronic Protected Health Information, must be encrypted.
The use of wireless access points must include authentication and encryption to protect HHS IR. The
minimum encryption level is Advanced Encryption Standard (AES) with 128-bit encryption or FIPS
140-2 validated cryptographic modules, whichever is stronger.
All employees, providers, and vendors are prohibited from using or installing any device which
functions in wireless mode in order to access data, transfer data or connect in any manner to HHS
networks or systems without the approval of the Agency IRM, the CIO if no agency IRM exists, or a
designee, and assistance of the Agency IT staff.

The only exemptions shall be for equipment specifically tested, installed and maintained with
configurations that protect all HHS data and resources in accordance with this standards
document, and requirements of state and federal law.
 Exemption approval authority shall be the Agency IRM, the CIO if no agency IRM exists or a
designee.
15.9.6. When deploying wireless access points the following minimum standards shall apply:
a. File sharing on wireless clients shall be disabled.
b. Client NIC and Access Point firmware shall be upgradeable so that security patches may be
deployed as they become available.
c. Access Points shall be turned off when they are not in use (e.g., after hours and on weekends).
d. The Access Point’s Service Set Identifier, SSID, shall be changed from the default setting to an
ID that does not reflect the identity of the agency, department, and the nature of the work of the
physical location where it is installed, and the SSID Broadcast shall be disabled.
e. All non-secure and nonessential management protocols on Access Points shall be disabled.
f. All security features of the WLAN product, including the cryptographic authentication feature,
shall be enabled.
g. Wi-Fi Protected Access, WPA, security standard or greater shall be implemented.
h. Access Points shall have strong passwords and shall be changed regularly.
i. User authentication shall use an RFC compliant method, such as RADIUS, TACACS, etc.
j. Authentication mechanisms for the management interfaces of the Access Point shall be enabled
and management traffic destined for Access Points shall be on a dedicated wired subnet.
k. SNMP settings on Access Points shall be disabled or set for least privilege (i.e., read only), with
SNMPv3 or equivalent cryptographically protected protocol in use.
l. Installers shall ensure that new WLAN installations do not interfere with other existing equipment.
m. Physical and remote access to the Access Point Reset Function shall be restricted to authorized
administrators only.
n. The default cryptographic key shall be changed from the factory default and shall be changed on
a regular basis.
15.9.7. Bluetooth is an open standard for short-range radio frequency (RF) communication. When deploying
Bluetooth for HHS business devices, including cellular phones, personal digital assistants (PDA),
laptops, automobiles, printers, and headsets, agencies must use the strongest Bluetooth security
mode available for their devices.
HHS EISSG v.5.1
Page 34 of 75
15.9.8. Bluetooth devices’ default settings must be reviewed and changed as needed so that they comply
with agency security policy requirements. All unneeded Bluetooth profiles and services must be
disabled to reduce the number of vulnerabilities that attackers could attempt to exploit.
15.9.9. All users must be provided with a list of precautionary measures or additional security awareness
training so that they are fully informed of the security risks related to Bluetooth or other wireless
devices, and protecting handheld or wireless devices from theft.
16.
Audit and Accountability (AU)
The HHS CISO (i) ensures the creation, protection, and retention of information system audit records to the extent
needed to enable the monitoring, analysis, investigation, and reporting of unlawful, unauthorized, or inappropriate
information system activity; and (ii) ensures that the actions of individual information system users can be
uniquely traced to those users so they can be held accountable for their actions.
16.1. Audit Logging
Audit logs must enable the tracking of activities taking place on the system. Ensure that the following minimum
audit trail capabilities exist. Other audit log or audit trail requirements may exist depending on the system or
application and the classification of the data.
16.1.1. Audit logging capability must be enabled and monitored based on agency risk management
decisions.
16.1.2. Audit records shall contain sufficient information to establish what events occurred, when the events
occurred (date and time), the source of the events (user or system account), the cause of the events
(service or process), and the event outcome.
16.1.3. The movement of production data from platform to platform is required to be traceable.
16.1.4. Log files (audit trails) of each electronic file transfer execution must be maintained in accordance with
records retention schedules or other State and Federal requirements.
16.1.5. Information systems shall be configured to allocate sufficient audit record storage capacity to record
all necessary auditable items.
16.1.6. All job execution audit trails are platform specific and independent of each other.
16.1.7. All electronic file transfers are to be performed by a job scheduled in either the automated enterprise
scheduler or an approved alternative.
16.1.8. Audit information and audit tools shall be protected from unauthorized access, modification, and
deletion.
16.1.9. The audit trail shall be restricted to personnel routinely responsible for performing security audit
functions.
16.1.10. The information system shall alert appropriate HHS organizational officials in the event of an audit
processing failure and take the appropriate additional actions for prompt resolution.
16.1.11. Audit logs and audit trails must enable the routine review of audit records for indications of unusual
activities, suspicious activities or suspected violations, and report findings to appropriate officials.
16.2. Security Monitoring
The purpose of the Security Monitoring Standard is to ensure adequate controls are in place, are followed, and
are effective.
16.2.1. All security monitoring tools or processes must employ continuous monitoring capabilities to ensure
that security controls are followed and effective.
16.2.2. Automated monitoring tools provide real-time notification of suspected or actual wrongdoing and
vulnerabilities. These devices should be deployed to the maximum extent possible. Security
baselines should be developed for monitoring tools used to report exceptions.
16.2.3. Files may be checked for signs of wrongdoing and vulnerability exploitation at a frequency
determined by their defined level of risk. Such files include:
a. Automated intrusion detection logs
b. Firewall logs
c. User account logs
HHS EISSG v.5.1
Page 35 of 75
d. Network scanning logs
e. System error logs
f. Application logs
g. Backup and recovery logs
h. Network printer and network fax logs
i. Help desk trouble tickets
j. Telephone activity-call detail reports
k. E-mail logs
16.2.4. The following areas will be reviewed at least annually to assure compliance:
a. Appropriate use of passwords
b. Unauthorized network connected devices
c. Unauthorized personal web servers
d. Unsecured sharing of network connected devices
e. Unauthorized modem use
f. Remote access session monitoring
g. Unapproved Wireless access points
h. Operating system and software licenses
i. Unencrypted transmissions of confidential data
17.
Identification and Authentication (IA)
The HHS CISO requires the identification of information system users, processes acting on behalf of users, or
devices and authenticates (or verifies) the identities of those users, processes, or devices as a prerequisite to
allowing access to HHS information systems.
17.1. Passwords
The HHS Password Standard establishes rules related to the User authentication process, including the creation,
distribution, safeguarding, termination and reclamation of those mechanisms. Exceptions to this policy may be
allowed temporarily for certain legacy systems.
17.1.1. All passwords must:
a.
b.
c.
d.
Contain a minimum of eight (8) and a maximum of sixteen (16) characters with at least one (1) from
each of the following categories:
- upper case alpha (ABC)
- lower case alpha (abc)
- number (0 to 9)
- special character (@ # $ % ^ % * ( ) _ + | ~ - = \ ’ { } [ ] : ” ; ’ < > / );
- dictionary names or words are prohibited. Not be words in any dictionary including, slang, dialect,
jargon, etc.
Enforces a minimum of four (4) changed characters when a new password is created;
Encrypts passwords in storage and in transmission.
17.1.2. User chosen passwords must adhere to a minimum length, format as defined by current agency
password guidelines.
17.1.3. Users shall commit passwords to memory and must not write down passwords and store them near
their computer.
17.1.4. Users must not share their passwords.
17.1.5. If a password’s security is in doubt, it must be changed immediately.
17.1.6. If a User suspects his/her password has been compromised, he/she must change it immediately and
notify his/her supervisor and the agency Help Desk of the suspected compromise.
17.1.7. New or temporary passwords must be changed upon User’s receipt of the password.
17.1.8. All passwords must have an expiration period as defined by current agency password guidelines.
Subsequent passwords must be modified in accordance with current agency password guidelines.
17.1.9. Passwords shall be changed every 90 days, at a minimum, for standard user accounts to reduce the
risk of compromise through guessing, password cracking or other attack & penetration methods.
17.1.10. Passwords shall be changed every 60 days, at a minimum, for privileged user accounts to reduce the
risk of compromise through guessing, password cracking or other attack and penetration methods.
HHS EISSG v.5.1
Page 36 of 75
Privileged users are individuals who have access to system control, monitoring, or administration
functions (e.g., system administrators, information security officers, maintainers, system
programmers).
17.1.11. Password changes for standard and privileged users shall be systematically enforced where possible.
17.1.12. Privileged users shall be able to override the minimum password age limit for users only when
necessary to perform required job functions.
17.1.13. HHS network administrators will not circumvent the password policy for the sake of expediency.
17.1.14. Unsuccessful account access attempts must be monitored and accounts locked after failed attempts
as determined by a documented risk assessment. Account lockout duration shall be permanent until
an authorized system administrator reinstates the user account. In some cases this may not be
technically feasible; such as certain web-systems that that lock users out for a period of time and
then open back up automatically after a specified period of time. However, in this case system
administrators should monitor this activity and implement the control based on risk assessed and
current system functionality available.
17.1.15. Passwords shall be systematically disabled after 90 days of inactivity to reduce the risk of
compromise through guessing, password cracking or other attack and penetration methods.
17.1.16. Where possible, Users shall be prohibited from using their last six passwords to deter reuse of the
same password.
17.1.17. Default vendor passwords shall be changed upon successful installation of the information system
product.
17.1.18. Stored passwords must be encrypted.
17.1.19. User account passwords must not be divulged to anyone. HHS IT staff or its
contractors/representatives will not ask for User account passwords except as allowed by law.
17.1.20. Users may not circumvent password entry with auto logon, application remembering, embedded
scripts or hard coded passwords in client software. (NOTE: Exceptions may be made for specific
applications with the approval of the HHS IT management. All exceptions must include a procedure
to change the password if necessary.)
18.
System and Communications Protection (SC)
The HHS CISO (i) requires the monitoring, control, and protection of HHS communications (information
transmitted or received by HHS information systems) at the external and key internal boundaries of the
information systems; and (ii) employs architectural designs, software development techniques, and systems
engineering principles that promote effective information security within HHS information systems.
18.1. Electronic File Transfers
When transmitting confidential or sensitive personal information; including PHI and PII, the following information
systems controls, or safeguards must be in place. For further information on FTP processes in HHS, see
http://hhscx.hhsc.state.tx.us/tech/infrastructure/Processes.html. For more information about protecting
confidential, sensitive, PII or PHI data.
18.1.1. HHS agencies are required to maintain an inventory of all confidential file transfers. At minimum, the
inventory should include a brief description of the data, the sender and receiver, the source,
destination, and schedule of the transfers.
18.1.2. Any connections to the Internet, or other external networks or information systems, shall occur
through controlled interfaces. The operational failure of the boundary protection mechanisms shall
not result in any unauthorized release of information outside of the information system boundary.
Information system boundary protections at any designated alternate processing site shall provide
the same levels of protection as those of the primary site.
18.1.3. Boundary protections include ensuring that only properly authorized network interconnections
external to the system boundaries are established. Carefully consider the intrinsically shared nature
of commercial telecommunications services in the implementation of security controls associated with
the use of such services. Commercial telecommunications services are commonly based on network
components and consolidated management systems shared by all attached commercial customers,
and may include third party provided access lines and other service elements. Consequently, such
interconnecting transmission services may represent sources of increased risk despite contract
HHS EISSG v.5.1
Page 37 of 75
security provisions. Therefore, when this situation occurs, either implement appropriate
compensating security controls or explicitly accept the additional risk.
18.1.4. All electronic file transfers must maintain transmission integrity and confidentiality. Transmission
integrity includes employing cryptographic mechanisms to recognize changes to information during
transmission unless otherwise protected by alternative physical measures. Transmission
confidentiality includes employing cryptographic mechanisms to prevent unauthorized disclosure of
information during transmission unless otherwise protected by alternative physical measures.
18.1.5. All electronic file transfers must ensure the implementation of a managed interface (boundary
protection devices in effective information security architecture) with any external telecommunication
service, implementing controls appropriate to the required protection of the confidentiality and
integrity of the information being transmitted.
18.1.6. All electronic file transfers must ensure that automated boundary protection mechanisms are
evaluated and that supporting procedures shall be developed, documented, and implemented
effectively to monitor and control communications at the external boundary of the information system
and at key internal boundaries within the system.
18.1.7. Encryption methods employed must meet acceptable standards as designated by HHSC Office of the
CISO. The recommended encryption method to secure data in transport is Advanced Encryption
Standard 128 (AES) or triple DES (DES3) if AES is unavailable. When cryptography (encryption) is
employed within the information system, the system must work to ensure these modules are
compliant with NIST guidance, including performing all cryptographic operations using Federal
Information Processing Standard (FIPS) 140-2 validated cryptographic modules with approved
modes of operation.
18.1.8. All data files being electronically transferred are to follow a documented file naming convention
process as defined by agency operational environments.
18.1.9. All script names (performing the electronic file transfer) on file transfer servers are to conform to
documented job naming conventions as defined in by the agency operational environment. All
scripts used for FTP, or other data transmission methods, are to be managed under software
configuration management and reside in a production library management system as defined in by
the agency operational environment. If a data transmission process includes multiple platforms, then
the job on each platform must contain the name of the originating job, plus identification of the server
it is executing on.
18.1.10. The IP address, user-id, and password used for electronic file transfers are to reside in a secure file
environment. The IP address, user-id, and password must not be displayed during the execution of
the job performing an electronic file transfer.
18.1.11. All production applications that include data file transfers are to have flowcharts that document the
entire process from point of origin to the final destination address. Require support documentation on
all jobs that perform electronic file transfers be kept current.
18.1.12. All electronic file transfers are required to be properly tested and are not to adversely impact
performance on that platform. When using production data for test and development of a secure file
transfer solution either encrypt or de-identify the data before use. The electronic transfer of test data
from platform to platform or to an external entity must follow the same requirements as for production
data. No electronic transfers of production data are to be performed manually. This includes
production data that is destined to be used in a test environment.
18.1.13. Confidential data files must be deleted from electronic file transfer servers periodically based on
agency risk management decisions.
18.2. Intrusion Detection / Prevention
The purpose of the HHS Intrusion Detection/Prevention Standard is to describe requirements to monitor events
on the information system, detect attacks, identify unauthorized use of the system and respond to intrusions.
18.2.1. The following must be enabled on all HHS systems as appropriate to the risks determined for the
particular system:
a. Operating system, user accounting, and application software audit logging processes,
b. Alarm and alert functions of any firewalls and other network perimeter access control systems,
c. Audit logging of any firewalls and other network perimeter access control systems.
HHS EISSG v.5.1
Page 38 of 75
18.2.2. System integrity checks of firewalls and other network perimeter access control systems must be
performed as appropriate to the risks determined for that system.
18.2.3. Audit logs for servers and hosts must be reviewed as appropriate to the risks determined for that
system.
18.2.4. Host based intrusion Detection/Prevention tools will be utilized and reviewed as appropriate to the
risks determined for that system.
18.2.5. All trouble reports shall be reviewed for symptoms indicating intrusive activities.
18.2.6. All suspected and/or confirmed instances of successful and/or attempted intrusions must be
immediately reported according to the Incident Management Standard. (See also: Section 9.1Incident
Management)
18.2.7. Users should be trained to recognize and report any anomalies and signs of wrongdoing. Refresher
training must be completed at least annually.
18.3. Mobile Code
18.3.1. Mobile code is obtained from a trusted source, and is designated as trusted. The mobile code is
digitally signed and the digital signature is properly validated by the client runtime environment prior
to the execution
18.3.2. Mobile code technologies include, for example, Java, JavaScript, ActiveX, PDF, Postscript,
Shockwave movies, Flash animations, and VBScript.
18.3.3. All mobile code must be authorized by agency official.
19.
Privacy Policies
The Privacy program class of controls for an information system is the administrative, technical, and physical
safeguards employed to protect PII within HHS. This class consists of eight security policies: Authority and
Purpose (AP), Accountability, Audit, and Risk Management (AR), Data Quality and Integrity (DI), Data
Minimization and Retention (DM), Individual Participation and Redress (IP), Security (SE), Transparency (TR),
and Use Limitation (UL).6.4.1
19.1 Authority and Purpose (AP)
The HHS requires that HHS (i) identify the legal bases that authorize a particular PII collection or activity that
impacts privacy; and (ii) specify the purposes for which they collect PII in their privacy notices
19.2 Accountability, Audit, and Risk Management (AR)
The HHS requires that HHS is complying with all applicable privacy protection requirements and minimizing their
overall privacy risk. This policy is intended to enhance public confidence through effective governance controls,
monitoring controls, risk management, and assessment controls.
19.3 Data Quality and Integrity (DI)
The HHS requires compliance with Section 552a (e)(2) of the Privacy Act of 1974 and enhances public
confidence that any PII collected and maintained by the organization is accurate, relevant, timely, and complete
for the purpose for which it is to be used, as specified in the public notice.
19.4 Data Minimization and Retention (DM)
The HHS requires that HHS implements the data minimization and retention elements of the Privacy Act, which
requires organizations to collect, use, and retain only PII that is relevant and necessary for the specified purpose
for which it was originally collected. The HHS organization retains PII for only as long as necessary to fulfill the
specified purposes and in accordance with a National Archives and Records Administration (NARA)-approved
record retention schedule.
HHS EISSG v.5.1
Page 39 of 75
19.5 Individual Participation and Redress (IP)
The HHS requires that individuals are active participants in the decision-making process regarding the collection
and use of their PII, as required by the Privacy Act. The controls in this family enhance public confidence in
agency decisions that are based on PII by providing individuals with access to their PII and the ability to have it
corrected or amended, as appropriate.
19.6 Security (SE)
The HHS requires administrative, technical, and physical measures are in place to protect PII collected or
maintained by agencies against loss, unauthorized access, or disclosure, as required by the Privacy Act, and
ensures that agency planning and responses to privacy incidents comply with OMB policies and guidance.
19.6.1 Privacy Standards
This section establishes the standards for privacy of Users on HHS networks. Privacy classifies data that is
defined by federal, state or agency rules. Organizations need to secure public information according to the threat
and impact of disclosure. Additionally, Users should expect that data, other than that deemed private or protected
by applicable law, be subject to examination by authorized Users or through open records requests.
19.6.1.1 Internal Users of HHS IR should have no expectation of privacy with respect to the use of those
resources, except as otherwise provided by law.
19.6.1.2 External Users of HHS IR should have the expectation of privacy, except in the case of suspected
wrongdoing.
19.6.1.3 Electronic files created, sent, received, or stored on information resources owned, leased,
administered or otherwise under the custody and control of HHS employees are not private resources
and may be accessed by other authorized HHS employees at any time without knowledge or consent
of the of the information resource User.
19.6.1.4 To enforce security, HHS may log, review, and otherwise utilize any information stored on or passing
through HHS IR in accordance with provisions and safeguards provided by Title 1 Texas
Administrative Code (TAC) Chapter 202.
19.6.1.5 To enforce security, HHS may capture User activity such as telephone numbers dialed or web site
visited in accordance with provisions and safeguards provided by 1 TAC Chapter 202.
19.6.1.6 To ensure secure removal of electronic confidential information, including Protected Health
Information) from any electronic media before re-use or disposal, 1 TAC Chapter 202 must be
followed. All electronic storage devices to be reutilized or surplus must be sanitized and the data
removal must be documented. Supervisors or internal HHS management must ensure data removal
documentation is maintained in accordance with records retention requirements.
19.6.1.7 Employees, independent contractors, vendors, and third parties of covered entities must comply with
the HIPAA Administrative Simplification combined rule text and the HIPAA Privacy Rule's general
rule, which states that covered entities may not use or disclose protected health information (PHI)
without a valid authorization except in those circumstances permitted under the Privacy Rule. It
should be noted that the scope of information covered in the Privacy Rule is referred to as ‘‘protected
health information; however, the requirements of the HIPAA Security Rule are aligned with the HIPAA
Privacy Rule with regard to the scope of information covered, and requires the same protections,
except that the Security Rule only covers that information if it is in electronic form. For additional
guidance about electronic PHI and other confidential information.
19.7 Transparency (TR)
The HHS requires that agencies implement Sections 552a (e)(3) and (e)(4) of the Privacy Act and Section 208 of
the E-Government Act which requires public notice of an agency’s information practices and the privacy impact of
government programs and activities.
19.8 Use Limitation (UL)
The HHS requires that agencies comply with the Privacy Act, which prohibits uses of PII that are either not
specified in notices, incompatible with the specified purposes, or not otherwise permitted by law. Implementation
of the controls in this family requires that the scope of PII use is limited accordingly.
HHS EISSG v.5.1
Page 40 of 75
20. Supporting Security Controls and Procedures
HHS defines and maintains the specific security controls and operating procedures necessary to enable fulfillment
of the security policies contained in this document. Control IDs and control family names are listed in Appendix A
starting on page 41.
21. Security Policies Exceptions
Exceptions will be reported to the Deputy Executive Commissioner, Information Technology (DEC-IT).
See Appendix D for a template of this form.
22. Laws, Regulations, and Guidance
Federal, state, and industry laws and regulations, along with guidance’s in the form of organizational policies and
standards, are often mandatory and are critical drivers for an information security program. Listed below are some
of the federal, state, industry, and organizational laws, regulations, and guidance documents that define the
requirements for data privacy and information system security that the HHS Security Program and the security
policies in this document are based upon.
Federal

Federal Information Security Management Act of 2002 (FISMA): P.L. 107-347, E-Government Act
of 2002

OMB M-06-16 Memorandum for the Heads of Departments and Agencies, Protection of Sensitive
Agency Information, June 23, 2006

Health Insurance Portability and Accountability Act of 1996 (HIPAA): P.L. 104-191

The Health Information Technology for Economic and Clinical Health (HITECH) Act, ARRA
Components, January 6, 2009

Internal Revenue Service Publication 1075, Tax Information Security Guidelines for Federal,
State, and Local Agencies and Entities.

Centers for Medicaid & Medicare Services Policy for the Information Security Program Version 4,
August 31, 2010

Federal Information Processing Standards Publication 200, Minimum Security Requirements for
Federal Information and Information Systems, March 2006

United States Code, Title 18, Section 1030. “Fraud and related activity in connection with
computers”

Family Educational Rights and Privacy Act (FERPA) (20 U.S.C. § 1232g; 34 CFR Part 99)

NIST SP800-53 Rev 3 Recommended Security Controls for Federal Information Systems and
Organizations

Title 1, Part 10 Texas Administrative Code Chapter 202: Information Security Standards

Texas - Business and Commerce Code Title 11, Subtitle B- Chapter 521 Unauthorized Use Of
Identifying Information

Texas - Health and Safety Code - Title 2, Subtitle I- Chapter 181 Medical Records Privacy

Payment Card Industry Data Security Card (PCI DSS) v1.2

ISO 27002 Information Technology – security techniques – Code of practice for information
security management
State
Industry
Organization

HHS EISSG v.5.1
HHS Circular C-021 HHS Enterprise Information Security Policy.
http://www.hhs.state.tx.us/news/circulars/C-021.shtml
Page 41 of 75
Appendices
Appendix A – HHS Information Systems Security Controls Catalog
The security controls catalog is represented by the below icon.
Appendix A- HHS
Information Systems
HHS EISSG v.5.1
Page 42 of 75
Appendix B - HHS Data Classification
Introduction
This document expands on the data classification and handling guidelines defined in the HHS Enterprise
Information Security Standards and Guidelines (EISSG), version 5.0, dated June 29, 2012, 2011 and provides
additional objectives on protecting HHSC sensitive information.
Drivers
The following are the primary drivers for the objectives developed during this analysis effort:

Address audit findings – An audit dated December 23, 2011 and performed by the HHSC Internal
Audit Division identified a number of issues with the current design and implementation of HHS’s
IT Security program; the objectives were developed to address those issues to the greatest
degree possible.

Leverage existing investments – The objectives were developed to leverage existing HHS
investments in people, process and technology to the greatest degree possible.

Minimize impact to users – Any additional controls should be as transparent to the end-users as
possible.

Increase maturity – HHS is currently building out a broad-based security program; the objectives
should support the end goal of a mature security environment.
Objectives
There are two types of objectives provided in this document:

Short-Term – These objectives are designed to address short-term issues and can be
implemented within a six-month period with a moderate resource investment.

Long-Term – These objectives are focused on increasing long-term maturity and may require a
greater resource investment.
Classification types
Data Classification
Data Classification provides a framework for managing data assets based on value and associated risks and for
applying the appropriate levels of protection as required by state and federal law as well as proprietary, ethical,
operational, and privacy considerations. All HHS data, whether electronic or printed, should be classified as to
data type. Consistent use of data classification reinforces with users the expected level of protection of HHS data
assets in accordance with HHS security policies.

HHS data created, sent, printed, received, or stored on systems owned, leased, administered, or
authorized by the HHS agency are the property of the HHS agency and its protection is the responsibility
of the HHS owners, designated custodians, and users.
Data Elements Required by Law
HIPAA and HITECH (Federal Law Identifiers)
The following identifiers of the individual or of relatives, employers, or household members of the individual must
be removed to achieve the “safe harbor” method of de-identification:
a. Names;
b. All geographic subdivisions smaller than a State, including street address, city, county, precinct, zip code,
and their equivalent geocodes, except for the initial three digits of a zip code if, according to the current
publicly available data from the Bureau of Census (1) the geographic units formed by combining all zip
HHS EISSG v.5.1
Page 43 of 75
c.
d.
e.
f.
g.
h.
i.
j.
k.
l.
m.
n.
o.
p.
q.
r.
codes with the same three initial digits contains more than 20,000 people; and (2) the initial three digits of
a zip code for all such geographic units containing 20,000 or fewer people is changed to 000;
All elements of dates (except year) for dates directly related to the individual, including birth date,
admission date, discharge date, date of death; and all ages over 89 and all elements of dates (including
year) indicative of such age, except that such ages and elements may be aggregated into a single
category of age 90 or older;
Telephone numbers;
Fax numbers;
Electronic mail addresses:
Social security numbers;
Medical record numbers;
Health plan beneficiary numbers;
Account numbers;
Certificate/license numbers;
Vehicle identifiers and serial numbers, including license plate numbers;
Device identifiers and serial numbers;
Web Universal Resource Locators (URLs);
Internet Protocol (IP) address numbers;
Biometric identifiers, including finger and voice prints;
Full face photographic images and any comparable images; and
Any other unique identifying number, characteristic, or code, except as permitted for re-identification
purposes provided certain conditions are met. In addition to the removal of the above-stated identifiers,
the covered entity may not have actual knowledge that the remaining information could be used alone or
in combination with any other information to identify an individual who is subject of the information. 45
C.F.R. § 164.514(b).
Texas Business and Commerce Code (State Law Identifiers)
Sec. 521.002. DEFINITIONS.
(a) In this chapter:
(1) "Personal identifying information" means information that alone or in conjunction with other
information identifies an individual, including an individual's:
(A) name, social security number, date of birth, or government-issued identification number;
(B) mother's maiden name;
(C) unique biometric data, including the individual's fingerprint, voice print, and retina or iris image;
(D) unique electronic identification number, address, or routing code; and
(E) telecommunication access device as defined by Section 32.51, Penal Code.
(2) "Sensitive personal information" means, subject to Subsection (b):
(A) an individual's first name or first initial and last name in combination with any one or more of the
following items, if the name and the items are not encrypted:
i.
social security number;
ii.
driver's license number or government-issued identification number; or
iii.
account number or credit or debit card number in combination with any required security
code, access code, or password that would permit access to an individual's financial account;
(B) information that identifies an individual and relates to:
i.
the physical or mental health or condition of the individual;
ii.
the provision of health care to the individual; or
iii.
payment for the provision of health care to the individual.
(b) For purposes of this chapter, the term "sensitive personal information" does not include publicly available
information that is lawfully made available to the public from the federal government or a state or local
government.
HHS EISSG v.5.1
Page 44 of 75
HHS Data Classifications
Data and associated IT assets should be classified as follows:
1. Restricted which includes ‘IRS FTI’ and ‘Verified SSA’ – Data that is subject to specific federal or state
regulatory requirements and must a) remain encrypted at all times while at rest, in use or during
transmission, b) be comprehensively monitored for access/distribution and c) provide for comprehensive
access, distribution and audit controls. This includes:
a. Internal Revenue Service Federal Tax Information (IRS FTI) – Any tax or information return,
declaration of estimated tax, or claim for refund required by, or provided for or permitted under, the
provisions of IRS titles which is filed with the Secretary of the Treasury by, on behalf of, or with
respect to any person, and any amendment or supplement thereto, including supporting schedules,
attachments, or lists which are supplemental to, or part of, the return so filed. This includes any
personal identifier combined with:
1. The nature, source, or amount of a taxpayer's income, payments, receipts, deductions,
exemptions, credits, assets, liabilities, net worth, tax liability, tax withheld, deficiencies, overassessments, or tax payments,
2. Whether the taxpayer’s return was, is being, or will be examined or subject to other investigation
or processing,
3. Any other data, received by, recorded by, prepared by, furnished to, or collected by the Secretary
of the Treasury with respect to a return or with respect to the determination of the existence, or
possible existence, of liability (or the amount thereof) of any person under this title for any tax,
penalty, interest, fine, forfeiture, or other imposition, or offense.
b. Verified Social Security Administration (SSA) information – Any SSA information that has been
verified by the Social Security Administration. This does not include information collected by the
client. The protections implemented for verified SSA information will be similar to that provided for
IRS FTI.
2. Confidential which includes ‘SPI’, ‘PI’, ‘PHI’ or ‘LEA’ – Data that is subject to specific federal or state
regulatory requirements and must a) be encrypted during transmission to an outside agent or when
stored on a mobile device, b) be monitored and c) provide strong access, distribution and audit controls.
This includes:
a. Personal Identifiers (PI) or Personally Identifiable Information (PII) – Information which can be used
to distinguish or trace an individual's identity, such as their name, social security number, biometric
records, etc. Note that by themselves personal identifiers are generally not considered sensitive. For
example, a combination of names and addresses would not be considered sensitive, since that
information is publically available (e.g. a phone book). This includes:
i.
Name
1. Full name
2. First and last names combined
3. First initial and last name combined
ii.
Addresses
iii.
Dates directly related to an individual, including birth date, admission date, discharge
date, date of death
iv.
Phone numbers
v.
Fax numbers
vi.
Electronic mail addresses
vii.
Online identity identifiers (e.g. Facebook account, Twitter account, etc.)
viii.
Social Security numbers
ix.
Military service number
HHS EISSG v.5.1
Page 45 of 75
x.
Medical record numbers
xi.
Health plan beneficiary numbers
xii.
Account numbers (e.g. bank, utility, etc.)
xiii.
Certificate/professional license numbers
xiv.
Passport number
xv.
Driver’s license number
xvi.
State-issued ID number
xvii.
Vehicle identifiers and serial numbers, including license plate numbers
xviii.
Device identifiers and serial numbers (e.g. personal computer name, etc.)
xix.
Web Universal Resource Locators (URLs) for personal web pages
xx.
Internet Protocol (IP) address numbers assigned to individuals or identifiable locations or
assets
xxi.
Biometric identifiers, including finger and voice prints
xxii.
Full face photographic images and any comparable images
xxiii.
Any other unique identifying number, characteristic, or code
b. Sensitive Personal Information (SPI) – When certain PI data is combined, or when certain PI data is
combined with other types of sensitive information, the resulting data is considered Sensitive
Personal Information. This includes any unique personal identifier combined with:
1. Social Security Account Number (SSAN)
2. Any financial data, including financial account numbers
3. Driver’s license number
4. Passport number
5. State-issued ID number
6. Date of birth
7. Mother’s maiden name
8. Social program benefits information, including:
a. Supplemental Nutrition Assistance Program (SNAP)
b. Temporary Assistance for Needy Families (TANF) program
c.
Family Violence Program
d. Refugee Resettlement Services
c.
Protected Health Information (PHI) – Any personal identifier combined with information in the medical
record or designated record set and that was created, used, or disclosed in the course of providing a
health care service such as diagnosis or treatment. Drivers for this category include HIPAA/HITECH,
CHIP, Medicare and Medicaid. Information includes:
1. The individual’s past, present or future physical or mental health or condition,
2. The provision of health care to the individual
3. The past, present, or future payment for the provision of health care to the individual
d. Law Enforcement Activity (LEA) – Any information related to law enforcement activities, including
investigations, criminal records, and law enforcement personnel.
HHS EISSG v.5.1
Page 46 of 75
Confidential data includes to the extent permitted under the laws and constitution of the State of Texas, all
information designated by the Enterprise as confidential, including but not limited all information designated as
confidential under the Texas Public Information Act, Texas government Code, Chapter 662.
Moreover, confidential data is described as information that is utilized, developed, received, or maintained by the
Enterprise, a contractor or participating State agencies for the purpose of fulfilling a duty or obligation under an
agreement that has not been publicly disclosed.
3. Agency Internal – Data that is not is subject to specific regulatory or other external requirements but is
considered HHS sensitive. This includes:
a. HHS-specific legal information such as employment agreements, separation agreements, nondisclosure agreements (NDAs) and contracts
b. Financial information related to organizational accounting such as balance sheets, purchase orders,
contracts and budget information
c.
Financial information related to employee compensation, such as offer letters, salaries,
compensation, severance, retirement plans and benefits
d. Technical information pertaining to HHS' IT infrastructure, including network diagrams, system
descriptions, network addresses, etc.
e. Internal organizational charts and contact/phone/email lists
f.
Internal communications
g. Internal operational procedures
h. Information pertaining to legal proceedings which include or may impact HHS
i.
Intellectual property, such as Copyrights, Patents and Trade Secrets
4. Public – Information intended or required for public release as described in the Texas Public Information
Act
Control Requirements
The following sections define specific control requirements objectives based on each defined classification.
Access Control
The ability to control access to sensitive information is one of the cornerstones of protecting that information.
Access control should be driven by the paradigm of ‘need to know’, which mandates that in order to have access
to any sensitive information an individual needs said access in order to effectively perform their job. The following
objectives apply:
Short-Term Objectives:

HHS should fully implement Active Directory (AD) as their central identification, authorization and access
control system. This includes elimination of any alternate access mechanisms such as local system or
application accounts.

All accounts should be associated with a single individual – shared or general access accounts should not be
allowed.

AD groups should be employed to control access to all resources (e.g. network shares, databases, etc.) in
the environment, with a unique group defined for each resource. Individual accounts should not be assigned
access permissions for any resources.

HHS should implement a centralized account request system which includes the ability for a data owner to
request that individuals be added/removed from group memberships.

An AD group naming convention should be established that incorporates information regarding the resource
and its classification level (e.g. Restricted, Confidential, etc.). In this context resources include applications,
network shares, etc.

A primary responsible manager should be defined for each unique AD group.
HHS EISSG v.5.1
Page 47 of 75

Membership in each group should be reviewed on a regular basis by the responsible manager to verify ‘need
to know’ still applies. Recommended review schedules are:
o
Restricted(all types) – Monthly
o
Confidential (all types) – Quarterly
o
Agency Internal – Annually

HHS Human Resources should have the ability to disable any AD user account in the event of termination or
legal/criminal investigation proceedings.

All non-AD local accounts should be disabled. If local accounts are required for emergency purposes these
accounts should be registered and documents and reviewed annually for continued relevance. Any accesses
to the accounts should result in an alert being generated by RSA enVision for further investigation.
Additional Requirements: The following capabilities must be implemented by HHS in order to support these
objectives:
o Full implementation and integration of all users into a centralized Microsoft Active Directory forest
o
Creation and management of unique AD groups for access control
Unstructured Content
Unstructured content in the form of documents and emails generally represents some of the most significant
factors for managing risks associated with sensitive information. In recent DLP scans HHS discovered thousands
of inappropriately protected documents containing sensitive information. Defining a strong policy related to the
creation and management of unstructured content is critical to protecting sensitive information.
Short-Term Objectives:

The recommended format for creating any unstructured content containing Restricted through Agency
Internal data should be Microsoft Word 2007, Excel 2007, PowerPoint 2007, Access 2007 or PDF. These
formats provide for a much greater degree of protection and access control as newer technology control are
implemented in the future.

The preferred format for communicating any unstructured Restricted through Agency Internal documents to
external agencies or individuals should be a read-only password protected PDF file. This allows any
communication mechanism (e.g. plain email) while maintaining an acceptable degree of security for the
content. The document password should be communicated to the receiver via an alternate communications
channel (e.g. verbally on the phone, instant messaging, etc.).

If a read-only password protected PDF file cannot be used for business reasons the secondary method
should be the use of the built-in password protection capabilities on Office 2007. As with a PDF file any
communication mechanism (e.g. plain email) can be used while maintaining an acceptable degree of security
for the content. The document password should be communicated to the receiver via an alternate
communications channel (e.g. verbally on the phone, instant messaging, etc.).

If password protected file cannot be used or a Microsoft Office 2007 document does not meet business
requirements, the Voltage SecureMail transfer should be used to transfer the content.

Microsoft Office 2007 documents should incorporate metadata properties that include
o
Document owner
o
Document creator
o
Classification (Restricted-XXX, Confidential-XXX, Agency Internal or Public)
o
Description of the purpose of the document
o
Expiration date

Storage of sensitive unstructured content should be restricted to approved resources (e.g. network shares,
SharePoint sites, etc.) with a classification level equal to or higher than the classification of the content.

Develop a minimum password strength policy for documents.
HHS EISSG v.5.1
Page 48 of 75

See the section titled ‘Labeling’ for unstructured content labeling requirements.
Long-Term Objectives:

HHS should implement a centralized rights-management solution to define and apply access and encryption
controls to documents. This would allow access, distribution and protection policies to be deployed directly in
the content. Potential solutions include Microsoft’s Rights Management Server and EMC’s Documentum
Information Rights Manager.

HHS should implement a centralized content/workflow management system to provide active positive control
over all unstructured content and eliminate the use of email and network shares for sharing unstructured
content internally and implementing workflow.
Additional Requirements: The following capabilities must be implemented by HHS in order to support these
Objectives:

Upgrade all HHS users to Microsoft Office 2007 or later.
Structured Content
Another source of sensitive content within HHS is the structured databases utilized by various applications.
Short-Term Objectives:

For databases containing category Restricted content, any tables containing sensitive content should be
encrypted at a minimum. Optionally, the whole database can be encrypted.

For Restricted and Confidential level databases detailed database monitoring should be enabled. See
recommended logging events starting on page 64.

All Restricted through Agency Internal databases should be documented and tracked in the data catalog
inventory system. This includes enterprise databases as well as local personal databases (e.g. MS Access,
MySQL, etc.). DLP should be used to scan all servers and endpoints to locate these databases initially.
Long-Term Objectives:

All sensitive data fields within any database containing category Restricted or Confidential data should be
tokenized. HHS can leverage their existing investment in RSA Data Protection Manager to provide this
capability. Note that tokenizing the data removes a significant portion of the related environment from the
scope of any relevant regulations.
Storage Containers
Storage containers represent physical media that can be removed from HHS’s control. This includes disk drives
(both server as well as array-based), mobile devices and backup tapes. Loss of control of one of these devices
that contains sensitive information represents a breach for HHS; however, by encrypting these physical devices
HHS can leverage the ‘safe harbor’ clause provided by most regulations. Note that end-point removable media
such as USB drives and writable optical disks are discussed in the section entitled ‘Endpoint Removable Media’.
Short-Term Objectives:

All physical devices that could potentially contain sensitive information of category Restricted or Confidential
should be encrypted. This includes:
o
System and data disks in servers. Note that system disks are included due to address the potential for
sensitive information being stored in some form of cache.
o
All disks within a LUN presented to a host and potentially used to store sensitive information.
o
All backup tapes.
o
All USB drives.
o
All replicas of devices that store sensitive information (e.g. snapshots, clones, disaster recovery copies,
etc.).
HHS EISSG v.5.1
Page 49 of 75
Endpoint Removable Media
Another technology the represents a significant risk factor for HHS is removable media on end point devices; this
includes USB thumb drives, USB disk drives and writable optical disks.
Short-Term Objectives:

Copying of sensitive content onto endpoint removable media should only be allowed if a) the content itself is
internally encrypted (e.g. password-protected Microsoft Word document) or b) the media is a HHS-provided
encrypted device.

HHSC should acquire and distribute encrypted USB drives to all employees that may be required to manually
transfer sensitive data. The serial numbers for these USB drives should be entered into the appropriate DLP
endpoint policy.

Copying sensitive content to a writable optical drive (e.g. CD, DVD or Blu-ray disk) should only be allowed if
the content is internally encrypted.

RSA DLP endpoint should be configured to enforce these requirements.
Labeling
Labeling is the action of incorporating metadata within a resource in order to identify the classification of that
resource or the sub-resources it ‘touches’.
Short-Term Objectives:

All unstructured content (e.g. documents), regardless of classification, should be labeled in a humanreadable format
o Human-readable labels should be as follows:

‘HHS Restricted – XXX”, where ‘XXX’ is ‘PCI’ or ‘FTI’

‘HHS Confidential - XXX’, where ‘XXX’ is ‘SPI’, ‘PI’, ‘PHI’, ‘LEA’, etc.

‘HHS Internal’ - Data that is not is subject to specific regulatory or other external requirements but is
considered HHS Internal.

‘HHS Public’
o
Microsoft Word, PowerPoint and PDF documents should have footer on each page with the humanreadable classification label, including the cover page.
o
Microsoft Excel spreadsheets should include footer with the human-readable classification label that will
be included on any hardcopy documents.

All unstructured content should include the classification level (Restricted through Public) in the name of the
document.

All system names should include a classification level in the name indicating the highest classification of
information that system stores or processes.

All network shares should include a classification level in the name indicating the highest classification of
information that share stores. DLP should be employed to scan each network share on a regular basis to
verify no information higher than the assigned classification is present.
Network Shares
HHS utilizes a large number of network shares to share data internally. These shares typically contain a large
number of files, many of which in turn may contain sensitive information. Access control to these shares is not
tightly controlled.
Short-Term Objectives:

All network shares should be from controlled file servers or network attached storage devices under
centralized control.
HHS EISSG v.5.1
Page 50 of 75

HHS should enable and enforce a policy to prevent network shares from desktop and other unauthorized
systems, and implement a tool to scan for unauthorized network shares on a daily basis. Any unauthorized
network shares should be disabled and the owner’s manager notified of the violation.

All authorized network shares should be registered and documented. A simple online process to request a
new network share should be instituted.

Network shares containing any Restricted through Agency Internal data should be created for specific
business functions with access limited to specific individuals or groups. As recommended under the section
titled ‘Access Control’, the access lists for these shares should be reviewed on a regular basis to ensure a
continuing ‘need to know’ by all individuals with access.

Any general access network shares should be scanned on a daily basis for the presence of Restricted
through Agency Internal classified data. If any such data is located it should be quarantined and the owner
notified.

All Restricted through Agency Internal network shares should be scanned on a weekly basis to determine if
any content that exceeds the classification level of the share is present; if any s found it should be
quarantined and the owner notified.

All network shares should be scanned on a monthly basis to identify any content that has exceeded the
retention requirements defined by HHS Legal. The owner of any content found in violation should be
automatically notified.

RSA DLP should be configured to scan all content being copied from endpoints to network shares and deny
attempts to copy sensitive content to a network share that is classified at a lower level (e.g. attempting to
copy a confidential document to an Agency Internal share).

All copying of content to or from a Restricted or Confidential network share should be logged.
Long-Term Objectives:

HHS should implement a centralized content management/workflow management system to handle the
creation, sharing and management of unstructured content for the most common workflows and eliminate the
use of network shares to the greatest degree possible.
External Communication
The current solution utilized by HHS for secure communication of sensitive content to external agencies via email
is the Voltage SecureMail product, which provides a secure web-based transfer capability. While this capability is
effective and meets HHS’s requirements, some users have complained about the extra steps required to utilize it.
HHS also utilizes FTP for the external exchange of large files.
Short-Term Objectives:

Unless specific business requirements mandate otherwise, all unstructured content classified as Restricted
through Agency Internal to be shared external to HHS should be formatted as a password protected readonly PDF document.

As discussed in the section titled ‘Unstructured Content’, HHS should utilize the built-in protection capabilities
in Microsoft Office to secure sensitive content prior to transmission via the standard email system.

RSA DLP should be deployed to detect and block all attempts transfer unprotected Restricted through
Agency Internal data out of HHS’s environment by any mechanism other than SecureMail. The person
attempting the transfer should be automatically notified of HHS’s policy.

FTP transfers:
o
FTP sites should be created for specific functions and segregated – no general purpose FTP sites should
be allowed.
o
All unstructured content containing sensitive information uploaded to a FTP site by HHS users should be
protected as previously defined.
o
All content should be automatically deleted from FTP sites after 24 hours.
HHS EISSG v.5.1
Page 51 of 75

o
Anonymous users should not be permitted to download files from any HHS FTP site. Anonymous file
uploads can be permitted; however, any information that is uploaded to a HHS FTP site anonymously
should be automatically moved to a secured location after uploading and the original upload securely
deleted.
o
Procedures for requesting access to HHS's FTP sites should be published, including a self-service option
for creating temporary accounts and passwords that can be shared with external organizations.
o
All uploading of content to a Restricted through Agency Internal FTP site should be logged.
Removable disk (e.g. USB, writable optical disk, etc.) transfers.
o
All files being transferred onto removable storage should be scanned by DLP to detect Restricted through
Agency Internal content and ensure that such content is internally encrypted. Note that while encrypted
storage devices may provide secure transfer, the content can later be copied off the secure device and be
subsequently exposed or breached while out of HHS control.
Long-Term Objectives:

Integrate RSA DLP with Archer to identify all outgoing encrypted documents (email, FTP, removable drives,
etc.) and verify that the document has been registered with the Archer data management system. Note that
this may require some custom integration effort.
Lifecycle Management
As identified in the initial DLP scan performed by HHS a significant number of compliance violations were
identified for content that was very old and most likely no longer required. In addition to the potential compliance
risks associated with this older information, maintaining it consumes significant resources.
Short-Term Objectives:

Associated processes for creating and maintaining the inventory.

Work with the Legal team to define a set of data and record retention requirements for each unique type and
classification of information.

Ensure all users receive regular awareness training on the retention requirements.

Scan all logical storage containers (e.g. file systems, network shares, etc.) on a regular basis to identify
information being stored for longer than the allowed retention period (based on the creation date); if a
violation is identified automatically move the content to a quarantined area and notify the content owner that
the content will be deleted in a pre-defined time period unless an exception request is submitted and
approved (including Legal approval).

Require all documents created within HHS to include an expiration date in the document’s metadata
properties.

Ensure that a secure erasure capability is utilized for any unprotected sensitive content.
Sensitive Asset Configuration Requirements
The configuration of assets that ‘touch’ sensitive information can have a critical impact on the security and
compliance of HHS’s environment. This includes servers (both physical and virtual), applications, network
devices, network shares, storage devices, etc.
Short-Term Objectives:


Define a set of security configuration requirements for each type of asset that ‘touches’ sensitive information
within HHS’s infrastructure. Configuration items should include:
o
Access policies;
o
Security configuration (e.g. HIDs, firewalls, network segregation, file integrity monitoring, DLP scans, etc.).
Collect and monitor event logs utilizing RSA enVision based on the classification of the asset. Recommended
event log types are defined in Appendix C.
Long-Term Objectives:
HHS EISSG v.5.1
Page 52 of 75

Implement a tool that performs automated security configuration compliance scanning for all sensitive assets,
utilizing he Security Content Automation Protocol (SCAP).
Roles and Responsibilities Matrix
This matrix defines roles and responsibilities in the HHSC Enterprise Security Management process.
Role
Remedy Service Desk
Enterprise Security
Management – DLP
Incident Responder
Manager, Enterprise
Security Management
Description
Responsibilities
Initial Single Point of Contact (SPOC) for
handling incidents and requests, handling
first level information security related
problems and answering questions from
HHSC employees.
The Remedy Service Desk is
responsible for manually opening an
alert/event ticket, gathering initial data
for potential DLP incidents, and
contacting HHSC Enterprise Security
Operations to initiate triage and analysis
protocols.
A DLP Incident Responder is the Single
Point of Contact for receiving and
evaluating all potential DLP alerts/events
from all input sources.
The DLP Incident Responder (IR) is the
primary contact for the initial intake of
DLP security incidents. The IR triages
the potential incident, determines the
nature and scope of the event, and will
classify the severity and priority of the
incident. The IR is a primary resource
with responsibility to assist in all phases
of the DLP incident response lifecycle.
A supervisory role who manages the
development and implementation of
HHSC’s enterprise security strategies and
program.
The Enterprise Security Manager
represents HHSC Information Security
and has the ultimate responsibility for the
following:
The Enterprise Security Manager is the
primary escalation contact for the Incident
Responder in case of a major DLP
information security incident.
Develop information security policies,
procedures, standards, and guidelines.
Develop and implement a
comprehensive information security
training and awareness program.
Establish procedures for assessing and
ensuring compliance with information
security policies through inspections,
reviews, and evaluations.
Coordinate initiatives with the agency
ISOs.
DLP Incident Response.
Produces reports and trending analysis
to management based on pre-defined
KPIs and metrics.
HHS EISSG v.5.1
Page 53 of 75
Role
Chief Information
Security Officer –
CISO
Description
Responsibilities
The leader of HHSC’s enterprise-wide
information security.
Accountable for all aspects of
Information Security Program
Development and Management.
The role accountable for implementation
of a methodical process to evaluate and
resolve each DLP incident in a timely
manner.
The Process Owner’s responsibilities
include sponsorship, design, and
continual improvement of the DLP
process and its metrics.
Monitor the effectiveness of DLP
strategies, technologies, and processes.
Drive improvements to the DLP
processing infrastructure and capabilities
to meet defined business requirements.
Evaluate new technologies for DLP
monitoring and reporting as necessary.
Agency ISOs serve as agency’s internal
and external point of contact for all
information security matters.
Administer the agency Information
Security Program.
Develop and recommend polices to
ensure the security of information
resources.
Establish and recommend procedures
and practices to ensure the security of
information resources.
Agency ISOs
Ensure that security policies,
procedures, standards, and guidelines
are implemented to protect agency’s
information resources.
Establish procedures for assessing and
ensuring compliance with information
security policies through inspections,
reviews, and evaluations.
Develop and implement a
comprehensive information security
training and awareness program.
Monitor the effectiveness of defined
controls for mission-critical information.
Report on the status and effectiveness of
information resources security controls.
HHS EISSG v.5.1
Page 54 of 75
Role
Legal
Service Providers
Description
Responsibilities
Legal is a key stakeholder in the
establishment of DLP Classification and
Data Map Framework activities, including
DLP Incident Response protocols. The
legal representative will determine how to
proceed during an incident with minimal
legal liability and maximum ability to
prosecute offenders as appropriate.
Legal should review all DLP program
elements, including policies and
procedures, to ensure compliance with
all relevant statutes and guidelines.
HHSC Technology Infrastructure and
Operations Support, including Capgemini,
Xerox/ACS and Northrop-Grumman
(TIERS).
Participate in all phases of DLP program
strategy development, as well as
implementation and on-going system
administration tasks.
Regional Tech Centers (RTCs)
The RTCs will use the accepted EISSG
guidelines for data classification, data
management, and DLP incident
response protocols.
Business Units are a division or
department of system/ application owners
and data stewards at HHSC, including:
Responsible for data and application
ownership and participation in DLP
identification and remediation activities.
Regions
Business Units
Provide guidance if there is reason to
believe that a DLP incident may have
legal ramifications, including evidence
collection, prosecution of a suspect, or a
lawsuit.
- DFPS
- DARS
- DADS
- DSHS
Executive Management is accountable for
the overall effectiveness of the enterprise
DLP strategy and program.
The following roles are part of the
Executive Management Team:
HHSC Executive
Management
- Executive Commissioner
Responsible for defining the importance
of DLP strategies and guidelines, and
linking program objectives to business
drivers. Ensures there are appropriate
vendor contracts in place and a training
program for the DLP support team to
ensure skills are available for program
maturation and incident response.
- Inspector General
- Deputy Executive Commissioner
- CIO
- CISO
- Legal
HHS EISSG v.5.1
Page 55 of 75
Role
HHS
Communications
Description
Responsibilities
HHS Communications facilitates
information and knowledge exchange with
internal and key external groups.
HHS Communications is responsible for
the DLP Incident message creation and
media responsibility. If a need exists
they will inform the media and the public
of the incident.
Violations
HHS should clearly define and enforce penalties for violations of policies regarding sensitive information.
Exception Request Process
In some instances it may be required or desirable for business reasons for an individual to operate upon sensitive
information in a manner that violates defined policies. HHS should have a clearly defined process, implemented in
Archer, for requesting exceptions to the policy.
Short-Term Objectives:

Implement an exception request process utilizing Archer.

All approved exceptions should be time-limited and tracked to verify termination.
Recommended Event Types for Logging
Different asset classifications are required to generate and communicate different types of event log information.
The following sections identify specific Objectives for each classification type. Since different asset types (e.g.
servers, applications, switches, storage arrays, etc.) from different vendors may utilize different event naming
conventions, the required events are defined at the category level. For additional guidance on whether a specific
event type should be logged, please contact the HHSC Enterprise Security Manager.
In addition to the category, required events are also classified based on their severity level. As with events
names, different assets types and vendors may utilize different naming conventions for defining severity levels;
however, most vendors commonly define four levels of severity. For the purpose of this standard these four levels
are defined as:

Critical (includes Alert, Emergency, Panic, etc.);

Error;

Warning;

Informational.
For assistance in mapping asset/vendor-unique severity levels, please contact the HHSC Enterprise Security
Manager.
If a given asset falls under more than one classification, all event types defined for the highest classification will
be enabled.
Restricted Assets
Recommended event categories:

All authentication activities, all severity levels.
o Examples include Successful/failed logins.

All access activities, all severity levels.
o Examples: include Successful/failed database access.

HHS EISSG v.5.1
Realized or potential asset configuration changes, all severity levels.
Page 56 of 75
o
Examples:

Device driver installed.

Application installed.

Service enabled.

All identity activities, all severity levels.
o
Examples:

New account creation.

Account lock out.

All audit-related activities, all severity levels.
o
Examples:

Changes in event logging.

Deletion of event logs.

All privilege elevation activities, all severity levels.
o
Examples include SUDO on Unix systems.

All activities performed at an elevated privilege level, all severity levels.

All other security-related events, all severity levels.
Confidential Assets
Recommended event categories:

All failed authentication activities, all severity levels.
o
Examples include Failed logins.

All failed access activities, all severity levels.
o
Examples include Failed database access.

Realized or potential asset security configuration changes, all severity levels.
o
Examples:

Device driver installed.

Application installed.

Service enabled.

All identity activities, all severity levels.
o
Examples:

New account creation.

Account lock out.

All audit-related activities, all severity levels.
o
Examples:

Changes in event logging.

Deletion of event logs.

All privilege elevation activities, all severity levels.
o
Examples:

SUDO on Unix systems, privileged account login.
HHS EISSG v.5.1
Page 57 of 75

All other security-related events, all severity levels.
Agency Internal Assets
Recommended event categories:

All failed authentication activities, all severity levels.
o
Examples include Failed logins.

All failed access activities, all severity levels.
o
Examples include Failed database access.

All identity activities, all severity levels.
o
Examples:

New account creation.

Account lock out.

All audit-related activities, all severity levels.
o
Examples:

Changes in event logging.

Deletion of event logs.

All other security-related events, Critical or Error severity levels.
Public Assets

HHS EISSG v.5.1
All security-related events, Critical or Error severity levels.
Page 58 of 75
Appendix C - Recommended Events for Logging
1. Generate audit records for the following events:
(a) User account management activities,
(b) System shutdown,
(c) System reboot,
(d) System errors,
(e) Application shutdown,
(f) Application restart,
(g) Application errors,
(h) File creation,
(i) File deletion,
(j) File modification,
(k) Failed and successful log-ons,
(l) Security policy modifications, and
(m) Use of administrator privileges.
2. Enable logging for perimeter devices, including firewalls and routers.
(a) Log packet screening denials originating from un-trusted networks,
(b) Packet screening denials originating from trusted networks,
(c) User account management,
(d) Modification of packet filters,
(e) Application errors,
(f) System shutdown and reboot,
(g) System errors, and
(h) Modification of proxy services.
3. Verify that proper logging is enabled in order to audit administrator activities.
4. (For Federal Tax Information (FTI) only) Generate audit records for the following events in addition to those
specified in other controls:
(a) All successful and unsuccessful authorization attempts.
(b) All changes to logical access control authorities (e.g.: rights, permissions).
(c) All system changes with the potential to compromise the integrity of audit policy configurations,
security policy configurations and audit record generation services.
(d) The audit trail captures the enabling or disabling of audit report generation services.
(e) The audit trail captures command line changes, batch file changes, and queries made to the
system (e.g.: operating system, application, and database).
HHS EISSG v.5.1
Page 59 of 75
Appendix D - Exception Request Form (Template)
See form on next page.
HHS EISSG v.5.1
Page 60 of 75
Information Security Office
Security Policy Exception/Standard Risk Acceptance
It is the intent of HHSC Information Security Office that all Owners, Custodians, and Users of
HHS Information Resources comply with all HHS information security standards. However, the
Information Security Office understand there will be situations where the strict application of a
standard would significantly impair the functionality of a service and security standards must be
modified to accommodate specific requirements. Where immediate compliance would disrupt
critical operations, a temporary exception may be granted.
This document is intended to meet the necessary standards for documenting an exception to
compliance with a published HHS standard as documented in HHS Enterprise Information
Security Standards and Guidelines (EISSG).
Instructions for completing this request form:
1. Requestor(s) must fill in all required information in the request form below.

To edit, double click or select the highlighted text and type over it.

Please do not alter fonts, colors, or layout in the form.
2. The Information Security Office and Customers should collaborate on the information provided in this
request to ensure it is complete and accurate before submission.
3. Save the completed request with a unique name (not with the template file name).
4. Submit the request:

Agency ISO
5. The Information Security Office will review the submitted exception request for clarity and validity
before further processing. Any clarifications will be addressed with the customer technical contact.
Once exceptions are formally approved by the required parties, the HHSC Information Security Office will
forward a copy of the final exception document to the customer.
Page 61 of 75
Information Security Office
Security Policy Exception/Standard Risk Acceptance
Reference Number: (completed by ISO)
Date Requested: (mm/dd/yyyy)
Business Unit or Department
Requestor (Name, Title)
Email:
Phone:
Technical Contact (Name, Title)
Email:
Phone:
Exception Requested: (A detailed explanation of the exception being requested and the business reason
supporting non-compliance)
Scope of Requested Exception: (What parts of the environment are included in this exception;
systems, server names, server grouping, host names, IPs). For all applications, systems, products or
features identified please provide the purpose or business function, as well as the location and intended user
community.
Description of Data Types Impacted: (For detailed list of confidential HHS data or sensitive personal
information; including PII and PHI refer to the EISSG document)
Restricted – which includes ‘IRS FTI’ and ‘Verified SSA’
Confidential – which includes ‘SPI’, ‘PI’, ‘PII’, ‘PHI’ or ‘LEA’
Agency Internal – Data that is not is subject to specific regulatory or other external requirements but is
considered HHS sensitive.
Public Data
Other (Please describe below in detail type(s) of data
Page 62 of 75
Information Security Office
Security Policy Exception/Standard Risk Acceptance
Description of Non-Compliance: (Which rules, regulations, security policy, standards, guidelines or
procedures apply to the exception)
Assessment of Risk Associated with Non- Compliance
(Describe the potential threats/risks to the environment allowing these exceptions as well as any information
related to impact should the risk occur. Include the SISAC RA Subcommittee defined Business Risks and
an Other option)
Compensating Controls in Effect to Reduce, Transfer or Eliminate Risk
(Describe the secondary controls, alternative settings, or other actions being taken to reduce identified risk)
Duration/Expiration: (Anticipated length of non-compliance)
Corrective Action Plan: (To attain compliance and reduce the identified risk condition)
Review Date to Evaluate Progress Towards Compliance (Review date cannot be more than one
year from the request date)
Formal Acceptance of Risk
I am aware of and understand the risks associated with implementation of this exception
request. I am formally accepting all risks resulting from implementation of this exception
request and non-compliance with the HHSC Information Security Standards and Guidelines.
X
Information Owner
___________________________________
Printed Name and Title
___________________________________
Business Unit
___________________________________
Email Address
___________________________________
Phone
Page 63 of 75
Information Security Office
Security Policy Exception/Standard Risk Acceptance
This section to be completed by the HHS Agency
The IRM has temporarily approved your exception request.
The IRM has determined that your request is a security risk to the agency that requires
additional authorization by the Information Resource Manager or Chief Information Officer prior
to temporary exception approval. Please complete following form, acquire the necessary
signatures, and then return the form back to the Information Security Office.
___
Exception Approved by: (IRM)
Date Approved:
Additional Comments:
Review Date:
This section to be completed by the HHS Agency
The Information Security Office has temporarily approved your exception request.
The Information Security Office has determined that your request is a security risk to the
agency that requires additional authorization by the Information Resource Manager or Chief
Information Officer prior to temporary exception approval. Please complete following form,
acquire the necessary signatures, and then return the form back to the Information Security
Office.
Exception Approved by: (HHS CISO)
Date Approved:
Additional Comments:
Review Date:
Page 64 of 75
Information Security Office
Security Policy Exception/Standard Risk Acceptance
Exception Approved by: (HHS CIO)
Date Approved:
Additional Comments:
Review Date:
Page 65 of 75
Information Security Office
Security Policy Exception/Standard Risk Acceptance
Appendix E - Acronyms and Glossary
Acronym
Definition
ARS
Acceptable Risk Safeguards
A broad set of the Centers for Medicare and Medicaid Services (CMS) security controls, which are based on
NIST requirements.
CISO
Chief Information Security Officer
A senior-level executive responsible for establishing and maintaining the enterprise vision, strategy, and
program to ensure information assets are adequately protected.
CMS
Centers for Medicare & Medicaid Services
Federal agency that administers Medicare, Medicaid, and the Children’s Health Insurance Program.
CVE
Common Vulnerability and Exposures
Funded by Homeland Security and maintained by MITRE Corporation, CVE is a system that provides a
method of referencing publicly known information security vulnerabilities and exposures.
DDoS
Distributed Denial of Service
An attempt to make a computer or network resource unavailable to its intended users.
DHCP
Dynamic Host Configuration Protocol
A network configuration protocol for hosts on Internet Protocol (IP) networks. The most essential
communication configuration information is an IP address, and a default route and routing prefix. DHCP
automates that task and provides a central database of devices that are connected to the network, eliminating
duplicate resource assignments.
EISSG
Enterprise Information Security Standards and Guidelines
A State of Texas document that, along with the Enterprise Information Security Policy document, serves to
protect Health and Human Services (HHS) information resources in accordance with applicable state and
federal laws, rules, and regulations.
ePHI
Electronic Personal Health Information
An electronic version of demographic information, medical history, test and laboratory results, insurance
information, and other data that is collected by a health care professional to identify an individual and
determine appropriate care.
FERPA
Family Educational Rights and Privacy Act
A federal law that protects the privacy of student education records. The law applies to all schools that receive
funds under an applicable program of the U.S. Department of Education.
FIPS
Federal Information Processing Standards
A publicly announced standardization development by the U.S. federal government for use in computer
systems.
FISMA
Federal Information Security Management Act of 2002
Requires each federal agency to develop, document, and implement an agency-wide program to provide
information security for the information and information systems that support the operations and assets of the
agency, including those provided or managed by another agency, contractor, or other source.
FTI
Federal Tax Information
Any tax return or tax return information received directly or indirectly from the U.S. Secretary of the Treasury.
HHS
Health and Human Services
A Texas system composed of five agencies that operate under the oversight of the Health and Human
Page 66 of 75
Information Security Office
Security Policy Exception/Standard Risk Acceptance
Acronym
Definition
Services Commission;
HHSC
Health and Human Services Commission
Oversees the operations of the health and human services system, provides administrative oversight for
Texas health and human services programs and directly administers some programs.
HIPAA
Health Insurance Portability and Accountability Act of 1996
Provides federal protections for personal health information held by covered entities and gives patients an
array of rights with respect to that information.
HITECH
Health Information Technology for Economic and Clinical Health
Enacted as part of the American Recovery and Reinvestment Act of 2009, HITECH was signed into law on
February 17, 2009, to promote the adoption and meaningful use of health information technology. Subtitle D
of the HITECH Act addresses the privacy and security concerns associated with the electronic transmission of
health information, in part, through several provisions that strengthen the civil and criminal enforcement of the
HIPAA rules.
IDS
Intrusion Detection System
Software that automates the intrusion detection process.
IM&O
Infrastructure Management & Operations
A department of HHSC that manages shared services and assets that support HHS agencies (HHSC, DADS,
DARS, DFPS, DSHS).
ISO
Information Security Officer
A formally designated security professional responsible for the implementation of the agency Security
Program.
MDCN
Medicare Data Communications Network
A secure closed private network currently used to transmit data between Medicare fee-for-service (FFS)
contractors and the Centers for Medicare and Medicaid Services, as well as for transmission of electronic
transactions in some cases from certain providers and clearinghouses to FFS contractors.
MPLS
Multiprotocol Label Switching
A mechanism in high-performance telecommunications networks that directs data from one network node to
the next based on short path labels rather than long network addresses, avoiding complex lookups in a
routing table.
NARA
National Archives and Records Administration
An independent agency of the U.S government charged with preserving and documenting government and
historical records.
NIST
National Institute of Standards and Technology
A federal technology agency that works with industry to develop and apply technology, measurements, and
standards.
NVD
National Vulnerability Database
A U.S. government online repository of standards-based vulnerability management data, operated by NIST.
OMB
Office of Management and Budget
An agency of the Executive Office of the President of the United States.
PCI DSS
Payment Card Industry Data Security Standard
Provides an actionable framework for developing a robust payment card data security process -- including
prevention, detection and appropriate reaction to security incidents.
Page 67 of 75
Information Security Office
Security Policy Exception/Standard Risk Acceptance
Acronym
Definition
PDA
Personal Digital Assistant
A mobile device that functions as a personal information manager.
PHI
Personal Health Information
Also referred to as protected health information, generally refers to demographic information, medical history,
test and laboratory results, insurance information, and other data that is collected by a health care
professional to identify an individual and determine appropriate care.
PIN
Personal Identification Number
A secret numeric password shared between a user and a system that the system uses to authenticate the
user.
POA&M
Plan of Action and Milestones
A document that identifies tasks to be accomplished. It details resources required to accomplish the elements
of the plan, any milestones for completing the tasks, and scheduled completion dates for the milestones.
RA
Risk Assessment
The evaluation of potential vulnerabilities in order to protect information systems from threats.
SAR
Safeguard Activity Report
An annual IRS-required report from agencies that advises the IRS of minor changes to the procedures or
safeguards described in the Safeguard Procedures Report (SPR).
SDLC
System Development Life Cycle
The overall process of developing information systems using a multistep process.
SOW
Statement of Work
A formal document that captures and defines work activities, deliverables, and timelines for a project.
Standard regulatory and governance terms and conditions are included.
SOX
Sarbanes-Oxley Act of 2002
An act passed by U.S. Congress in 2002 to protect investors from the possibility of fraudulent accounting
activities by corporations. The Sarbanes-Oxley Act mandated strict reforms to improve financial disclosures
from corporations and prevent accounting fraud.
SPR
Safeguard Procedures Report
An IRS-required report that describes the procedures established and used by an agency for ensuring the
confidentiality of information received from the IRS.
SSP
System Security Plan
A formal plan that provides an overview of the security requirements of a system. It describes the controls in
place or planned and the responsibilities and expected behavior of all individuals who access the system.
ST&E
Security Testing and Evaluation
A means of determining or verifying that information security controls are operational, adequate, and effective
in preventing inadvertent or deliberate disclosure, alteration, or destruction of agency information and
resources.
TAC
Texas Administrative Code
A compilation of all state agency rules in Texas.
TFC
Texas Facilities Commission
A state agency responsible for planning, providing, and managing facilities for state agencies.
Page 68 of 75
Information Security Office
Security Policy Exception/Standard Risk Acceptance
Acronym
Definition
TSP
Telecommunications Service Priority
Established by the Federal Communications Commission (FCC), TSP is a regulatory, administrative, and
operational framework that authorizes national security and emergency preparedness organizations to receive
priority treatment for vital voice and data telecommunications services.
VoIP
Voice over Internet Protocol
A family of technologies, methodologies, communication protocols, and transmission techniques for the
delivery of voice communications and multimedia sessions over Internet Protocol (IP) networks, such as the
Internet.
VPN
Virtual Private Network
A network that uses primarily public telecommunications infrastructure, such as the Internet, to provide remote
offices or traveling users’ access to a central organizational network.
Terms
Definitions
Access
To approach, view, instruct, communicate with, store data in, retrieve data from, or otherwise make
use of information resources.
Abuse of Privilege
When a User willfully performs an action prohibited by organizational policy or law, even if technical
controls are insufficient to prevent the User from performing the action.
Backup
Copy of files and applications made to avoid loss of data and to facilitate their recovery in the event
of such loss.
Boundary Protection
Monitoring and control of communications at the external boundary of an information system to
prevent and detect malicious and other unauthorized communications, through the use of boundary
protection mechanisms. Protection mechanisms are devices implemented at the information system
boundary and at layered or internal system boundaries, including, as appropriate, firewalls,
gateways, proxies, routers and network intrusion detection systems.
Change Management
The process of controlling modification to hardware, software, firmware and documentation to ensure
that information resources are protected against improper modification before, during and after
implementation.
Chief Information
Security Officer
The senior person within an organization responsible for the protection of information resources.
Computer Security
Incident Response Team
(CSIRT)
Personnel responsible for coordinating the response to any computer security incident.
Computer Security
Incident
A violation or imminent threat of violation of computer security policies, acceptable use policies, or
standard security practices. An “imminent threat of violation” refers to a situation in which the
organization has a factual basis for believing that a specific incident is about to occur. For example,
the antivirus software maintainers may receive a bulletin from the software vendor, warning them of a
new worm that is rapidly spreading across the Internet. The terms “incident” and “computer security
incident” are used interchangeably. An “event” is a negative occurrence that can be observed,
verified, and documented, while an “incident” is a series of events that negatively affects the
organization and/or impacts its security posture.
Confidential Information
Information that is exempted from disclosure requirements under the provisions of the Texas Public
Information Act or other applicable state or federal law. b) Any information by which the identity of a
client or employee can be determined either directly or by reference to other available information if
Page 69 of 75
Information Security Office
Security Policy Exception/Standard Risk Acceptance
Terms
Definitions
the identity cannot be disclosed under federal or state law.
Consent
Authorization to disclose identifying or other confidential information given by an individual person or
entity with authority as described by law.
Countermeasures
A countermeasure or safeguard is put into place to mitigate a potential security risk exposure. A
countermeasure may be a software configuration, a hardware device, or a procedure that eliminates
vulnerability or reduces the likelihood of a threat agent. Examples of countermeasures include:
Network Address Translation (NAT) segmentation, shielded twisted pair cabling, switched VLAN
technology, fiber optic medium, IP Security (IPSec) configured for virtual private network (VPN)
connections, Secure Sockets Layer (SSL), and digital certificates. Typically, countermeasures are
implemented in combination or at various layers of the system’s infrastructure.
Control
A protective action, device, policy, procedure, technique, or other measure that reduces exposure of
an information resource. Any method of restricting access to resources, allowing only privileged
entities access to those resources. Controls include, but are not limited to, mandatory access
controls, discretionary access controls, time-of-day and classification controls.
Custodian
The holder of data or agent charged with implementing the controls specified by the Owner. The
Custodian is responsible for the processing and storage of information.
De-identify
To remove identifiers of an individual from data as well as identifiers for the individual’s relatives,
employers, or household members before it can be shared with the public. Examples of identifying
data include, but not limited to: Name, address, social security number, phone or fax numbers,
medical records and account numbers.
E-mail
Electronic mail. Any message, image, form, attachment, data, or other communication sent,
received, or stored within an electronic mail system.
Electronic Messaging
The transmission of any message via an electronic means. This includes, but is not limited to, email, instant messaging, wireless-broadband connectivity used in the transmission of data via handheld devices, and/or cellular transmissions.
Emergency Change
Any immediate response to imminent critical system failure to prevent widespread service disruption.
Encryption
A method for rendering information unusable to anyone without a “key” with which they are able to
“translate” the information into a readable format. The process involves translating readable data
into hidden data through the use of scrambling algorithms and a “key” which permits authorized
Users to unscramble the data into a useable format. When cryptography (encryption) is employed
within the information system, the system must work to ensure these modules are compliant with
NIST guidance, including performing all cryptographic operations using Federal Information
Processing Standard (FIPS) 140-2 validated cryptographic modules with approved modes of
operation.
Extranet
An extranet is a private network that uses Internet technology and the public telecommunication
system to securely share part of a business's information or operations with suppliers, vendors,
partners, customers, or other businesses. An extranet can be viewed as part of a company's intranet
that is extended to users outside the company.
Federal Tax Information
(FTI)
Tax return information protected by the confidentiality provisions of the Internal Revenue Code (IRC)
section 6103. IRC sections 7213, 7213A and 7431provides for civil and criminal sanctions for
unauthorized access of returns and tax return information.
HIPAA
Health Insurance Portability and Accountability Act of 1996, as amended, Title II includes
requirements for both information and facility security compliance.
Incident
Unintentional, willful or negligent unauthorized activity that affects the availability, confidentiality, or
integrity of IR.
Page 70 of 75
Information Security Office
Security Policy Exception/Standard Risk Acceptance
Terms
Definitions
Information Resources
(IR)
Any and all computer printouts, online display devices, magnetic storage media, and all computerrelated activities involving any device capable of receiving e-mail, browsing Web sites, or otherwise
capable of receiving, storing, managing, or transmitting electronic data including, but not limited to,
mainframes, servers, personal computers, notebook computers, hand-held computers, personal
digital assistant (PDA), pagers, distributed processing systems, network attached and computer
controlled medical and laboratory equipment (i.e. embedded technology), telecommunication
resources, network environments, telephones, fax machines, printers and service bureaus.
Additionally, it is the procedures, equipment, facilities, software, and data that are designed, built,
operated, and maintained to create, collect, record, process, store, retrieve, display, and transmit
information.
Information Resources
Manager (IRM)
The IRM is the individual responsible to the State of Texas for management of the department IR.
The designation of a department IRM is intended to establish clear accountability for setting policy for
IR management activities, provide for greater coordination of the state department's information
activities, and ensure greater visibility of such activities within and between state agencies.
Information Technology
(IT)
The elements, structure, objectives, and resources that establish a department-level information
resources management program.
Internet
A global system interconnecting computers and computer networks. The computers and networks
are owned separately by a host of organizations, government agencies, companies, and colleges.
Intranet
A private network for communications and sharing of information that, like the Internet, is based on
TCP/IP, but is accessible only within an organization.
Local Area Network
(LAN)
A group of computers and associated devices that share a common communications line. A LAN
provides authentication, resources to its users, and an overall controlled inner environment.
LAN User
Any computer User with authorized access to the LAN, including applications and software.
Malicious Code
A destructive program (including virus, worm, Trojan and other malware) hidden in an attractive or
innocent-looking program, application or enclosure such as a game, graphics program or screen
saver.
Offsite Storage
An alternative location used for the temporary or permanent storage of data in the event that the data
is unavailable at its normal site.
Owner
A person responsible: a) for a business function and b) for determining controls and access to
information resources supporting that business function.
Password
A combination of letters, numbers and/or special characters that allow an authorized User ID to
access information within the controls defined by the information Owner.
Peer-to-Peer
Process whereby computers can trade information between each other without having to pass the
information through a centrally controlled server.
Personal Digital
Assistants
PDA’s include any portable computing device that is capable of transmitting data or connecting to an
HHS Information Resource. These include but are not limited to: Blackberries, Palm-Pilots, iPhones,
Treo, or other similar devices, handheld devices or computers, digital or cellular phones, mobile
phones or smart-phones, any web-enabled devices, portable media players.
PHI
Protected Health Information (PHI) - is information that is linked to, or could be linked to, a specific
person by name, Social Security Number (SSN), date of birth (DOB), geographic area or other
individually identifiable information, and is related to that person’s past, present, or future physical or
mental care condition; the provision of health care to that person; or the payment for the provision of
health care.
Page 71 of 75
Information Security Office
Security Policy Exception/Standard Risk Acceptance
Terms
Definitions
PII
Personally Identifiable Information (PII) - is any information that can be used alone or in conjunction
with any other personal information to identify a specific individual. PII includes any information that
can be used to search for or identify individuals, or can be used to access their records. Examples
include name, SSN, DOB, Social Security benefit data, State or government issued driver’s license
number.
Portable Computing
Device
Any easily portable device that is capable of receiving and/or transmitting data to and from an
Information Resource. They include, but are not limited to, laptop and notebook computers,
handheld computers, Personal Digital Assistants (PDA’s), pagers and digital/cellular telephones.
Privileged Users
Privileged users are individuals who have access to system control, monitoring, or administration
functions (e.g., system administrators, information system security officers, maintainers, system
programmers).
Provider
Any individual or entity, excluding those who qualify under the definition of vendor, contracted to
perform a service (typically client services).
Remote Access
Access to an organizational information system by a user (or an information system) communicating
through an external, non-organization-controlled network (e.g., the Internet) Examples of remote
access methods include dial-up, broadband, and wireless.
Removable Media
Includes any storage device containing data and refers to storage media which can be removed from
its reader device, conferring portability on the data it carries. For HHS purposes, this includes
removable disks or diskettes, tapes, DVD and/or compact disks (CD’s), Memory cards/sticks used in
various portable digital devices, FireWire / USB “Flash/ Key/ Pen/ Thumb” drive memory devices,
and any portable mass storage devices.
Restricted Personal
Information
Includes an individual’s social security number or data protected under state or federal law (e.g.,
financial, medical or student data).
Sanitized
Overwriting data using software tools and procedures to comply with the National Institute of
Standards and Technology (NIST) Special Publication 800-88 Guidelines for Media Sanitization
(SP800-88). For specific types of storage media, see NIST SP800-88, Appendix A - Minimum
Sanitization for Media Containing Data.
Scheduled Change
Formal notification received, reviewed and approved by a review process in advance of the change
being made.
Security Risk Analysis
The process of identifying and documenting vulnerabilities and applicable threats to information
resources and shall be updated based on the inherent risk.
Security Risk
Assessment
The process used to determine the potential magnitude of harm resulting from the unauthorized use,
access to, or disclosure of confidential or private data.
Spam
An electronic message is “spam” if: a) The recipient’s personal identity and context are irrelevant
because the message is equally applicable to many other potential recipients; AND b) The recipient
has not verifiably granted deliberate, explicit, and still-revocable permission for it to be sent; AND c)
The transmission and reception of the message appears to the recipient to give a disproportionate
benefit to the sender.
Storage Device
Any fixed or removable device that contains data and maintains the date after power is removed from
the device.
Test
A simulated or documented “real live” incident for which records are kept of the incident.
Unscheduled Change
Failure to present notice in compliance with an approved formal process in advance of the change
being made.
User
An individual or automated application authorized to access an information resource in accordance
Page 72 of 75
Information Security Office
Security Policy Exception/Standard Risk Acceptance
Terms
Definitions
with the Owner-defined controls and access rules.
Vendor
Any non-employee person or entity that exchanges goods or services (typically commercial goods
and services) for money.
Vulnerability
Assessment
A measurement of vulnerability, which includes the susceptibility of a particular system to a specific
attack and the opportunities available to a threat agent to mount that attack.
Vulnerability Report
A computer related report containing information described in 2054.077(b), Government Code, as
that section may be amended from time to time.
VPN
Virtual Private Network is a secure, private connection through a public network or an otherwise
unsecure environment. It is a private connection because the encryption and tunneling protocols are
used to ensure the confidentiality and integrity of data in transit. A VPN requires a tunnel to work
and it assumes encryption. A tunnel is a virtual path across a network that delivers packets that are
encapsulated and usually encrypted. Examples of protocols used for VPNs are: Point to Point
Tunneling Protocol (PPTP), IPSec (IP Security), and Layer Two Tunneling Protocol (L2TP).
Wireless Access
one or more of the following technologies to access the information resources systems of a state
agency or institution of higher education:
Wireless Local Area
Networks
Based on the IEEE 802.11 family of standards.
Wireless Personal Area
Networks
Based on Bluetooth, wireless USB, Infrared or other limited range technologies.
Wireless Handheld
Devices
Includes text-messaging devices, Personal Digital Assistant (PDAs) and smart phones.
Wireless Security
Guidelines
The National Institute of Standards and Technology Special Publication 800-48, Wireless Network
Security 802.11, Bluetooth and Handheld Devices.
Page 73 of 75
Information Security Office
Security Policy Exception/Standard Risk Acceptance
Appendix F - Security References
Please refer to these specific laws, directives, policies, standards, and guidelines for further guidance. In
addition, more information about NIST can be found online at the Computer Security Resource Center.
1. Federal Information Processing Standards Publication 140-2, Security Requirements for
Cryptographic Modules, with Change Notice December 3, 2002.
http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf

This publication provides the standard to be used by Federal organizations when these
organizations specify that cryptographic-based security systems are to be used to
provide protection for sensitive or confidential data.
2. Federal Information Processing Standards Publication 200, Minimum Security Requirements
for Federal Information and Information Systems, March 2006.
http://csrc.nist.gov/publications/fips/fips200/FIPS-200-final-march.pdf

This publication specifies minimum security requirements for information and information
systems supporting the executive agencies of the federal government and a risk-based
process for selecting the security controls necessary to satisfy the minimum security
requirements.
3. Federal Information Security Management Act (44 U.S.C. § 3541, et seq.), December 2002.
http://csrc.nist.gov/drivers/documents/FISMA-final.pdf

This act requires each federal agency to develop, document, and implement an agencywide program to provide information security for the information and information systems
that support the operations and assets of the agency, including those provided or
managed by another agency, contractor, or other source.
4. Internal Revenue Service Publication 1075, Tax Information Security Guidelines for Federal,
State and Local Agencies, OMB No. 1545-0962.; http://www.irs.gov/pub/irs-pdf/p1075.pdf

This publication provides guidance in ensuring that the policies, practices, controls, and
safeguards employed by recipient agencies or agents and contractors adequately protect
the confidentiality of the information they receive from the Internal Revenue Service.
5. OMB-M-06-16 MEMORANDUM FOR THE HEADS OF DEPARTMENTS AND AGENCIES,
Protection of Sensitive Agency Information, June 23, 2006.

This is a U.S. OFFICE OF MANAGEMENT AND BUDGET Memorandum that was added
to the HHS IRS Computer Matching Agreement as of June 5, 2008.
6. National Institute of Standards and Technology, Annex A: Approved Security Functions for
FIPS Pub 140-2, Security Requirements for Cryptographic Modules, Draft, May 2007.
http://csrc.nist.gov/publications/fips/fips140-2/fips1402annexa.pdf

This publication provides a list of the approved security functions applicable to FIPS Pub
140-2. Categories include symmetric key, asymmetric key, message authentication, and
hashing.
7. National Institute of Standards and Technology Special Publication 800-53, Recommended
Security Controls for Federal Information Systems, Revision 3, August 2009.
http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final_updatederrata_05-01-2010.pdf
Page 74 of 75
Information Security Office
Security Policy Exception/Standard Risk Acceptance

This publication provides guidelines for selecting and specifying security controls for all
components of any information system that processes, stores, or transmits federal
information.
8. National Institute of Standards and Technology Special Publication 800-66, An Introductory
Resource Guide for Implementing the Health Insurance Portability and Accountability Act
(HIPAA) Security Rule, Revision 1, October 2008.
http://csrc.nist.gov/publications/nistpubs/800-66-Rev1/SP-800-66-Revision1.pdf

This publication summarizes the HIPAA security standards and explains some of the
structure and organization of the Security Rule, which specifically focuses on the
safeguarding of electronic protected health information.
9. National Institute of Standards and Technology Special Publication 800-92, Guide to
Computer Security Log Management, September 2006.
http://csrc.nist.gov/publications/nistpubs/800-92/SP800-92.pdf

This publication assists organizations in understanding the need for sound computer log
management and provides practical guidance on developing, implementing, and
maintaining effective log management practices throughout an enterprise.
10. National Institute of Standards and Technology Special Publication 800-100, Information
Security Handbook: A Guide for Managers, October 2006.
http://csrc.nist.gov/publications/nistpubs/800-100/SP800-100-Mar07-2007.pdf

This publication provides a broad overview of information security program elements to
assist managers in establishing and implementing an information security program.
11. Social Security Administration, Attachment C: Information System Security Guidelines for
Federal, State, and Local Agencies Receiving Electronic Information from the Social Security
Administration, Version 3, March 2007.

This document provides guidelines to assist Social Security Administration’s (SSA)
information exchange partners in understanding the criteria SSA will use when
evaluating and certifying the system design and security features and protocols used for
electronic access to SSA information.
12. Centers for Medicare and Medicaid Services (CMS) Policy for the Information Security
Program http://www.cms.hhs.gov/InformationSecurity/Downloads/PISP.pdf

This document creates the Centers for Medicare & Medicaid Services (CMS) Information
Security (IS) Program Policy. CMS collects, generates, and stores financial, health care,
and other sensitive information. Most of this information relates to the health care
provided to the nation’s Medicare and Medicaid beneficiaries and has access restrictions
required by legislative and regulatory directives. The IS Program Policy aims to reduce
the risk, and minimize the effect of computer security incidents.
13. HIPAA Administrative Simplification additional guidance
http://www.hhs.gov/ocr/privacy/hipaa/administrative/securityrule/securityruleguidance.html

The security rule establishes national standards for the security of electronic health care
information. The rule specifies a series of administrative, technical, and physical security
procedures for covered entities to use to assure the confidentiality of electronic protected
health information.
Page 75 of 75