Chapter 12 - Information Technology Security

8-12.1  INTRODUCTION

The Indian Health Service (IHS) is responsible for securing information that it collects, records, transmits, and uses in the performance of its mission.  Since this information includes Agency-sensitive information, such as personnel and financial records as well as individually identifiable health information, it is necessary to establish the conditions and rules under which the IHS electronic systems and networks will operate to ensure the confidentiality, integrity, and availability of the information.  This is especially critical in the health care environment, where health care personnel must balance the requirement for patient privacy with the requirement to provide sufficient data to health care professionals and Government agencies in support of each one's mission and responsibility to improve health care in the United States.  This chapter contains the IHS policies for implementing the IHS Information Technology (IT) Security (ITS) program.

1. PURPOSE.  In accordance with Title 18 of the United States Code (U.S.C.), the Computer Security Act, and Office of Management and Budget (OMB), Circular A-130, this chapter establishes standard requirements for the protection of IHS information and information system resources, and the management and oversight of the IHS ITS program.  The IHS ITS program is intended to ensure that each IHS Automated Information System (AIS) has a level of security commensurate with the risk and magnitude of the harm that could result from the loss, misuse, disclosure, or modification of the information contained in the system.  Generally accepted system security principles shall be implemented to ensure the following:
   1. The ITS program supports the Agency mission.
   2. The ITS program is an integral element of sound management.
   3. The ITS program is cost-effective.
   4. System owners have ITS responsibilities outside their own organization.
   5. Information Technology System accountability is explicit.
   6. The ITS program has an integrated approach.
   7. The ITS program is periodically reviewed.
   8. The ITS program is constrained by societal factors.
2. SCOPE.  This policy applies to all IHS employees, contract personnel, interns, externs, and other non-Government employees including consultants, temporary staff, and business representatives (hereinafter, collectively referred to as IHS "users") accessing and utilizing IHS sensitive information or information system resources from within IHS facilities as well as from remote locations.  Agency officials shall apply this chapter to contractor personnel, interns, externs, and other non-Government employees by incorporating such reference in contracts or memorandums of agreement as conditions for using Government-provided IT resources.  Indian Health Service sensitive information is defined as all information processed, stored, or transmitted via information system resources within the organization and not available to the general public.  This information includes data not originating from the IHS but identified as sensitive or critical to continued business operation and processed, stored, or transmitted via IHS information system resources.  These resources include, but are not limited to stand-alone computers; network computers; remote computing devices; network resources, including servers and routers; and associated peripherals such as printers, scanners, backup devices, and both internal and external storage devices.  This chapter applies to computer and network systems and data processed by these systems or stored in electronic format.  This includes major applications, general support systems, databases, electronic storage media, local area networks and wide area networks.  Although this chapter does not include the physical security of the overall facility, it does include the physical security of the actual IT components within a facility.  This chapter does not cover data deemed "classified" by the United States Government.  [See the Department of Health and Human Services (HHS), "Automated Information Systems Security (AISS) Program Handbook," Chapter II, Section C4.]
3. AUTHORITY.
   1. "Information Technology Management Reform Act of 1996," Clinger-Cohen Act, Division E, Public Law (P.L.) 104-106
   2. Chief Financial Officers Act of 1990, P.L. 101-576
   3. "Computer Fraud and Abuse Act of 1986, "P.L. 99-474
   4. "Computer Security Act of 1987," P.L. 100-235
   5. "Federal Information Technology," Executive Order 13011, Section 3(a)(1)
   6. "Electronic Records; Electronic Signatures; Final Rule," Food and Drug Administration, HHS, 21 Code of Federal Regulations, Part 11, Federal Register, Volume 62, No. 54, Page 13429, March 20, 1997
   7. Federal Acquisition Streamlining Act of 1994, P.L. 103-355
   8. Federal Managers' Financial Integrity Act of 1982, P.L. 97-255
   9. "The Freedom of Information Act," Amendments of 1996, P.L. 104-231
   10. "Government Information Security Reform Act of 1999" P.L. 106-398, Title X, General Provisions, Subtitle G, Government Information Reform, Sections 1061-1065
   11. Government Paperwork Elimination Act, 44 U.S.C., 3504, Title XVII, October 8, 1998
   12. Government Performance and Results Act of 1993, P.L. 103-62
   13. The "HHS Automated Information Systems Security Program Handbook," May 1994
   14. The "HHS Automated Information Systems Security Training and Orientation Program (AIS-STOP) Guide," November 1991
   15. The HHS General Administration Manual:
       1. Chapter 5-10:  Transmittal 90.05 dated August 15, 1990, "General Policy - Responsibility and Procedures for Reporting Misconduct and Criminal Offenses"
       2. Chapter 5-10-40:  "Procedures for Reporting and Investigating Allegations of Criminal Offenses"
   16. Department of Health and Human Services Information Resources Management (IRM) Policy:
       1. "Personal use of Information Technology Resources," HHS-IRM-2000-0003, January 8, 2001
       2. "Use of Broadcast Messages, Spamming and Targeted Audiences," HHS-IRM-2000-0004, January 8, 2001
       3. "Information Technology Security for Remote Access," HHS-IRM-2000-0005, January 8, 2001
       4. "Establishing an Incident Response Capability," HHS-IRM-2000-0006, January 8, 2001
       5. "Prevention, Detection, Removal, and Reporting of Malicious Software," HHS-IRM-2000-0007, January 8, 2001
       6. "Health Insurance Portability and Accountability Act," P.L. 104-191, August 21, 1996.
   17. National Institute of Standards and Technology (NIST) Special Publications:
       1. 800-12, "An Introduction to Computer Security: the NIST Handbook," October 1995
       2. 800-14, "Generally Accepted Principals and Practices for Securing IT Systems," June 1996
       3. 800-18, "Guide for Developing Security Plans for Information Technology Systems," December 1998
   18. Office of Management and Budget Circulars:
       1. Circular A-11
          1. Part 1, "Preparation and Submission of Budget Estimates,"
          2. Part 2, "Preparation and Submission of Strategic Plans and Annual Performance Reports,"
          3. Part 3, "Planning, Budgeting, and Acquisition of Capital Assets,"
          4. and the supplement to Part 3, "Capital Programming Guide"
       2. Circular No. A-130, "Management of Federal Resources," Appendix III, "Security of Federal Automated Information Resources"
   19. "Paperwork Reduction Act of 1995," P.L. 104-13
   20. Presidential Decision Directive 63, "Critical Infrastructure Protection," May 22,1998
   21. "Privacy Act of 1974," P.L. 93-579
4. ACRONYMS.
   
   

   (1)    AIS	Automated Information Systems
   (2)    AISS	Automated Information Systems Security
   (3)    AIS-STOP	Automated Information Systems Security Training and Orientation Program
   (4)     C&A	Certification and Accreditation
   (5)    CIO	Chief Information Officer
   (6)    CSSP	Computer System Security Plan
   (7)    DAA	Designated Approving Authority
   (8)    FIPS	Federal Information Processing Standard
   (9)    GSS	General Support Systems
   (10)   HHS	Department of Health and Human Services
   (11)  HIPAA	Health Insurance Portability and Accountability Act
   (12)  I&A	Identification and Authentication
   (13)  IHM	Indian Health Manual
   (14)  IHS	Indian Health Service
   (15)  IHSNET	IHS Network
   (16)  IRM	Information Resources Management
   (17)  ISC	Information Systems Coordinator
   (18)  ISSO	Information Systems Security Officer
   (19)  IT	Information Technology
   (20)  ITS	Information Technology Security
   (21)  I/T/U	IHS/Tribes/Urban
   (22)  JCAHO	Joint Commission on Accreditation of Healthcare Organizations
   (23)  MA	Major Applications
   (24)  NIST	National Institute of Standards and Technology
   (25)  OMB	Office of Management and Budget
   (26)  PUB	Publication
   (27)  RFP	Request for Proposal
   (28)  SPSO	Servicing Personnel Security Officer
   (29)  U.S.C.	United States Code
   (30)  WAN	Wide Area Network
   (31)  WWW	World-Wide Web

5. DEFINITIONS.
   1. Application.  The use of information resources (information and IT) to satisfy a specific set of user requirements.
   2. Authenticate.  To confirm the identity of an entity when that identity is presented.
   3. Authentication.  Security measure designed to establish the validity of a transmission, message, or originator, or a means of verifying an individual's authorization to receive specific categories of information.
   4. Computer Security Incident.  An event that may result in, or has resulted in:
      1. the unauthorized access to or disclosure of sensitive or classified information,
      2. the unauthorized modification or destruction of systems data,
      3. reduced, interrupted, or terminated processing capability,
      4. malicious logic or virus activity, or
      5. the loss, theft, damage, or destruction of any IT resource.
   5. Examples of a Computer Security Incident.  Examples include:
      1. unauthorized use of another user's account,
      2. unauthorized scans or probes, successful, and unsuccessful intrusions,
      3. unauthorized use of system privileges,
      4. execution of malicious code (e.g., viruses, Trojan horses, or back doors),
      5. unauthorized scans or probes,
      6. successful or unsuccessful intrusions, and
      7. insider attacks.
   6. Computer Virus.  An executable or self-replicating program spread from executables, boot records, and macros as a set of instructions that attaches itself to programs, files, diskettes, or other storage media.  This set of instructions can then be spread to other programs, files, disks, systems, or networks.  The instructions can display a message, erase or alter files or stored data, or potentially render a workstation or network inoperable.  Sometimes, instead of disruptive instructions, a virus can cause damage by replicating itself and depleting resources such as disk space, memory, or network connections.  Non-virus threats to user systems include worms, Trojan horses, and logic bombs.
   7. Detection.  Determining that a record, data file, or storage media is contaminated with a virus.
   8. Event.  Any observable occurrence in a system and/or network.  Examples of events include the system boot sequence, a system crash, and packet flooding within a network.
   9. Firmware.  The Read-Only-Memory (ROM)-based software that controls a computer between the time it is turned on and the time the primary operating system takes control of the machine.  Firmware tests and initializes the hardware, determines the hardware configuration, loads (or boots) the operating system, and provides interactive debugging facilities in case of faulty hardware or software.
   10. Information Resources.  Information and related resources, such as personnel, equipment, funds, and IT.
   11. Information Resources Management.  The process of managing information resources to accomplish Agency missions and to improve Agency performance, including the reduction of information collection burdens on the public.
   12. Information System.  A discrete set of IT, data, and related resources, such as personnel, hardware, software, and associated IT services organized for the collection, processing, maintenance, use, sharing, dissemination or disposition of information.
   13. Information Technology.  Any equipment or interconnected system or subsystem of equipment used in the automatic acquisition, storage, manipulation, management, movement, control, display, switching, interchange, transmission or reception of data or information by the Agency.  Information technology includes computers, ancillary equipment, software, firmware and similar procedures, services (including support services), and related resources.  Information technology does not include any equipment that is acquired by a Federal contractor incidental to a Federal contract.  For purposes of this definition, equipment is "used" by the IHS whether the IHS uses the equipment directly or it is used by a contractor under a contract with the IHS that:
       1. requires the use of such equipment; or
       2. requires the use, to a significant extent, of such equipment in the performance of a service or the furnishing of a product.
   14. Indian Health Service IT Resources.  The IHS IT resources include but are not limited to: personal computers and related peripheral equipment; and software, network and Web servers, library resources, telephones, facsimile machines, photocopiers, Internet connectivity and access to Internet services, all forms of e-mail and, for the purposes of this policy, office supplies.  It does not include data stored in or transported by such resources.
   15. Internet.  A worldwide electronic system of computer networks, which provides communications and resource-sharing services to Government employees, businesses, researchers, scholars, librarians, and students as well as the general public.
   16. Logic Bomb.  A type of virus or malicious software that is usually timed or event-triggered to do damage.
   17. Maintenance.  A set of activities which result in changes to the originally accepted baseline product set and which is done to keep the system functioning in an operational, evolving, and expanding-user environment.
   18. Major Application System.  An application that requires special security measures due to the potential risk or magnitude of harm that would result from the loss, misuse, unauthorized access to, or modification of the information in the application.
   19. Malicious Software.  Any code that is intentionally included in software or firmware for an unauthorized purpose.
   20. Program Area.  A representation of customer organizations.
   21. Program Management.  The planning, organizing, directing, and controlling of the resources and schedules that coordinate the prioritization and sequencing of a collection of similar or interdependent projects.
   22. Remote Access.  Computer access to IHS networks (IHSNET) or systems by authorized users accessing IHS automated information and systems from outside the protection of Agency firewalls.
   23. Remote Access Connections.  Resource components required to provide remote access to the IHSNET (e.g., hardware, software, service, link/signal).  Requirements will vary depending on the remote access location and work to be performed.
   24. Security Incident.  An event that may result in or has resulted in the unauthorized access to or disclosure of sensitive or classified information; unauthorized modification or destruction of systems data; reduced, interrupted, or terminated processing capability; malicious logic or virus activity; or the loss, theft, damage, or destruction of any IT resource.
   25. Sensitive System.  A system required for accomplishment of an Agency's mission in a sensitive system (it need not contain any sensitive data).  Any system or systems that require some degree of protection for integrity, availability, or confidentiality.  This includes systems and data of which improper use or disclosure could adversely affect the ability of an Agency to accomplish its mission.  Examples:
       1. Propriety data
       2. Records about individuals requiring protection under the Privacy Act
       3. Data not releasable under the Freedom of Information Act
   26. Spam.  Generally refers to commercial senders of massive amounts of e-mail to all addresses they can find.  Spam is frequently sent from addresses that are forged to bypass filters intended to block them.  The content of spam often involves commercial scams, gambling, messages presenting a religious or political bias, chain-letter e-mail, computer viruses, and the sale of pornography.
   27. Trojan Horse.  A destructive program that comes concealed in software that not only appears harmless but attractive to an unsuspecting user (such as, a game or graphic application).
   28. Unauthorized Software.  Any software that does not have a certificate of authority to operate.
   29. Website.  A collection of Web files on a particular subject that includes a beginning file called a home page.
   30. Worms.  Infiltrators of programs that alter or destroy data.
   31. World Wide Web.  A collection of Web pages (documents), which are developed in accordance with the Hyper Text Markup Language Web format standard and may be accessed via Internet connections using a World Wide Web (WWW) browser.  NOTE:  Events such as natural disasters and power-related disruptions are not generally within the scope of the IRT and should be addressed in the IHS's business continuity and contingency plan.
6. COMPLIANCE.  This chapter provides rules and guidelines to ensure the confidentiality, integrity, and availability of business and medical information contained in IHS's computer systems and networks.  The following sections define the ITS policies for management, information, operational, and technical controls required to provide ITS.
   1. Users.  All IHS users are responsible for assisting in the protection of IHS automated correspondence, data, systems, and equipment by complying with the security requirements contained in this chapter.
   2. Violations.  Any IHS user who violates this policy may be subject to disciplinary action.
   3. Legal Action.  Legal action may be initiated where employee/contractor actions are also in violation of Federal, State, or local laws, or when damage to IHS assets or facilities has resulted from employee or contractor violation of this chapter.
   4. Exceptions.  Requests for exceptions to this chapter may be made to the IHS Chief Information Officer (CIO).  All requests shall be in writing and shall state the reason for the requested exception.
7. RESPONSIBILITIES.  An effective security program is dependent upon supportive management and the assignment of responsibilities to personnel throughout the organization for implementing and enforcing the various aspects of the ITS program.  This section describes the roles and responsibilities of each IHS employee in implementing, enforcing, and assessing the effectiveness of the IHS security policies and ITS program.
   1. Director, IHS.  The Director, IHS, has the ultimate responsibility to ensure the IHS conforms to applicable laws and regulations.  The Director, IHS, shall be responsible for ensuring:
      1. an IHS ITS program is implemented to protect the privacy and security of IHS IT resources;
      2. security-aware individuals implement security measures in the IHS, and
      3. funding is available to adequately support security efforts.
   2. Director, Office of Management Support.  The Director, Office of Management Support (OMS), is responsible for:
      1. physical security of facilities and equipment external to computers or telecommunication lines, and
      2. all matters relating to background and security clearance investigations of personnel.
   3. Chief Information Officer.  The IHS CIO shall be responsible for:
      1. the security of all IHS information while the information is being processed and/or transmitted electronically, and for the security of the resources associated with these functions;
      2. the status of ITS within the IHS and the adequacy of operating unit ITS programs;
      3. reporting on the status of ITS, as required, to the Department;
      4. reviewing and approving system security policies;
      5. granting exceptions to the security policies, as necessary;
      6. ensuring all security controls as stated in this policy are being implemented on all IHS systems;
      7. ensuring certification and accreditation activities are performed for all major applications and general support systems; and
      8. coordinating with the IHS Privacy Officer and IHS Records Management Officer for interpretation of privacy and records management policies and ensuring these policies are being correctly implemented in IHS systems.
   4. Information Systems Security Officer.  The IHS Information System Security Officer (ISSO) shall be responsible for the following:
      1. Monitoring, evaluating, and reporting, as required, to the CIO on the status of ITS within the IHS and the adequacy of the ITS programs administered by the operating units.
      2. Developing policies, procedures, and guidance establishing, implementing, maintaining, and overseeing requirements for the IHS's ITS program to be followed by all IHS organizations.
      3. Providing guidance and technical assistance to operating units, including analyzing, evaluating, and approving all IT system security plans and requirements for IT systems security.
      4. Ensuring IHS ITS oversight through compliance reviews of operating units and organizations and ITS verification reviews of individual systems, and by participating in program management oversight processes.
      5. Maintaining a tracking system and records concerning implementation of the required controls and accreditation status of all IHS IT systems.
      6. Coordinating with Area ISSOs and periodically scheduling conference calls to discuss/disseminate information on ITS matters and concerns.
      7. Coordinating the review of controls and evaluating the adequacy of technical controls for accreditation.
      8. Acting as the central point of contact for the Agency for ITS-related incidents or violations.
      9. Investigating or initiating an investigation of any incidents or violations; maintaining records and preparing reports; disseminating information concerning potential threats; and reporting to the HHS senior ISSO any violations that come under his/her areas of responsibility or to the Assistant Inspector General for investigation any activity that may constitute a violation of law or otherwise is reportable to that office in accordance with District Attorney Order 207-10, "Inspector General Investigations."
      10. Coordinating information resources, security awareness, and training needs assessments; determining appropriate training resources; and coordinating training activities for target populations.  (See HHS AISS Program Handbook Chapter VII, "Personnel Security/Suitability Training" and AIS-STOP.
      11. Assisting project officers and appropriate application system managers in carrying out the provisions of the HHS AISS Program Handbook for solicitations and contracts; and certifying the proposals received in response to a Request for Proposal (RFP) and certified as winning proposals by the Project Officer, as in the HHS AISS Program Handbook, Chapter XIV, "Acquisitions and Contracts."
      12. Coordinating with the HHS senior ISSO on security matters of mutual interest.
   5. Area Director.  Each Area Director shall administer an Area ITS security program that ensures appropriate and adequate levels of protection for all IT systems within the Area.  The Area Director is responsible for the following:
      1. Designing an Information Systems Coordinator (ISC).
      2. Designating an Area ISSO and alternate for the Area.  The Area ISSO and alternate shall have staff responsibility for the Area ITS program.
      3. Ensuring appropriate and adequate levels of protection based on the security level designations of the AIS.
      4. Ensuring systems may only be run in a facility that has at least the same of higher security level designation.
   6. Area Information Systems Coordinator.  The Area ISC is responsible for the following:
      1. Serving as the designated accreditation authority for all sensitive systems within their organization.  This approval authority may only be delegated to a senior management official of a subordinate organizational unit if that official does not have direct control over the IT system being accredited.  Delegation of accreditation authority must be requested and approved in advance by the CIO.
      2. Ensuring ownership is assigned for all IT resources within the operating unit (i.e., hardware, software, data, telecommunications, etc.).
   7. Area Information Systems Security Officer.  The Area ISSO shall serve as the central point of contact for the Area ITS program in coordination with the Agency ISSO.  The Area ISSO is responsible for the following:
      1. Attending annual ISSO training conferences.
      2. Participating in conference calls to obtain current information on issues relating to Federal or IHS ITS policies, regulations, or guidelines.
      3. Sharing information with the other ISSOs about issues or concerns, and participating on special committees working to solve IHS-wide IT issues.
      4. Ensuring that a security-aware individual for each subordinate organizational component within the Area implements the component's ITS program (e.g., ensuring a security assistant is appointed for each service unit and IT system within the Area).
      5. Establishing and maintaining an up-to-date list of all IT systems within the operating unit and providing a copy of the list to the IHS ISSO when requested by the Department.
      6. Ensuring ITS plans are prepared for all major applications and general support systems owned and operated by the operating unit.
      7. Reviewing and commenting on individual ITS plans, ensuring that all corrective actions are completed, and submitting all plans to the IHS ISSO.  Specific requirements for ITS plans are contained in the HHS AISS Program Handbook and in the NIST Special Publication (PUB) 800-18, "Guide for Developing Security Plans for Unclassified Systems."
      8. Ensuring a risk analysis is completed for all sensitive IT systems within the operating unit.  Specific requirements for risk analysis are contained in this document and the HHS AISS Program Handbook, Chapter V, "Risk Management."
      9. Ensuring contingency and disaster recovery plans are developed for all sensitive IT systems within each operating unit.  Specific requirements for contingency and disaster recovery planning are contained in the HHS AISS Program Handbook Chapter VI, "Contingency Planning."
      10. Maintaining a tracking system of the required controls and accreditation status for all operating unit sensitive IT systems, as listed in the HHS AISS Program Handbook Chapter III, "Security Level Requirements".
      11. Acting as the central point of contact for accreditation of all sensitive IT systems within the operating unit.  Ensuring all certification requirements have been met for each system prior to accreditation.  Specific certification and accreditation requirements are contained in the HHS AISS Program Handbook, page IX-6 and the Federal Information Processing Standard (FIPS), PUB 102, "Guideline for Computer Security Certification and Accreditation."
      12. Conducting or initiating ITS verification reviews of all operating unit sensitive IT systems every 3 years.
      13. Ensuring all operating unit personnel are provided appropriate ITS awareness and training.  Specific ITS awareness and training requirements are contained in the HHS AIS-STOP.
      14. Acting as the central point of contact for the operating unit for any type of ITS related incidents or violations.
      15. Investigating or initiating an investigation of any incident or violation.  Maintaining records and ensuring reports are submitted to the IHS ISSO.
      16. Disseminating information on potential threats to system owners.
      17. Ensuring the operating unit complies with required virus detection and elimination software, and procedures are available to protect against these threats.  Specific malicious software protection and reporting requirements are contained in Part 8, Chapter 10, "Prevention, Detection, Removal, and Reporting of Malicious Software" of the Indian Health Manual (IHM) and in HHS AISS Program Handbook Chapter XIII, "Malicious Software and Intrusions."
      18. Assisting application system managers and users in establishing and implementing the appropriate security safeguards required to protect microcomputer hardware and data from improper use or abuse (see HHS AISS Program Handbook Chapter XI, "Microcomputers").
      19. Ensuring the operating unit has publicized the established IHS policy against the illegal duplication of copyrighted software.  (See Section 8-12.1H(1)f, “Software Copyright Laws.”)  Ensuring all systems are audited for illegal software at least annually and inventories of all software on each individual system are maintained to verify that only legal copies of software are being used.  Specific requirements for software copyright protection, auditing and reporting are contained in the Copyright Act, as amended.
      20. Coordinating with the IHS ISSO on security matters of mutual concern.  In the absence of the ISSO, the ISSO alternate shall be designated to perform all functions normally assigned to the ISSO for the Area ITS program.
   8. Component ISSO.  Not all operating units within the Areas will require a position at this level.  Any large organizational component with management responsibility for a number of individual IT systems performing separate functions (i.e., hospital, service unit, Area Office) may or may not require a component ISSO.  The Area ISSO shall serve as the central point of contact for the component organization's ITS program within the Area.  If this position is determined to be appropriate for the Area, the functions of the ISSO for the component organizations generally parallel those specified for the Area ISSO.
   9. Custodial Ownership Responsibility.  All information resources (hardware, software, facilities, data, and telecommunications) will be assigned to an “owner,” designated in writing to the senior IRM official of the operating unit, i.e., an owner of the general support system information resources in an operating unit may be the facility's manager.  Custodial responsibility for the protection of IT resources includes:
      1. an obligation to comply with applicable security policies and directives, and
      2. administering application owner specified controls and safeguards for the owner?s data and programs.
   10. Determination of Ownership.  Resources located within user areas (i.e., offices or service units) may be “owned” by the manager of those areas.  To assist with the determination of ownership, individual system boundaries must be established.  A system is identified by logical boundaries being drawn around the various processing, communications, storage, and related resources.  The systems must be under the same direct management control with essentially the same function, reside in the same environment, and have the same characteristics and security needs.  Each system will be designated either a general support system or an application system.  (See “Definitions” for the definition of a general support system and an application system.)

       Ownership of information and/or information processing resources may be assigned to an organization, subordinate functional element, a position, or a specific individual.  When ownership is assigned to an organizational or functional element, the designated head of the unit shall be considered the resource owner.  Some, but not necessarily all, factors to be considered in the determination of ownership are:

       1. the originator or creator of data,
       2. the organization or individual with the greatest functional interest, and
       3. physical possession of the resource.
   11. Support System Owners.  Some general “support system owners” are suppliers of data processing services for applications owned by other organizations.  Typically, these “support system owners” are custodians of software, data, input, and output produced by the data processing facility to support one or more application owners.  Many of the IHS'?'s local area networks (LAN) will fit into this category.
   12. System Owner.  The system owner shall be responsible for the following:
       1. Determining the sensitivity of the resources for which the owner is responsible.
       2. Determining the appropriate level of required security consistent with all Federal laws, regulations, HHS, and IHS directives.
       3. Ensuring the protection requirements of the system are maintained at an adequate level to protect the confidentiality and integrity of the system.
       4. Serving as the certifying official and completing all required certification actions; issuing a certification statement; and preparing an accreditation package that will be forwarded to the Designated Approval Authority (DAA) for formal accreditation of the system every 3 years or when major changes occur to the system, whichever is less. If the certifying official is at a higher level in the organization, the system owner will complete all required certification actions and forward the accreditation package to the certifying official, who will issue the certification statement. Refer to the HHS AISS Program Handbook for specific certification requirements.
       5. Monitoring compliance and periodically reevaluating previously specified levels of sensitivity and protection.
       6. Ensuring all systems are audited at least annually to verify that no illegal software is present and to maintain an inventory of all software on each individual system as proof that only legal copies of software are being used.  Specific requirements for software copyright protection, auditing, and reporting are contained in Section 8-12.1H(1)f, "Software Copyright Laws," of this chapter.
       7. Ensuring that each automated data processing position (including contract positions) is properly designated by the Division of Human Resources according to position sensitivity criteria and receives appropriate investigative processing.  Refer to the HHS AISS Program Handbook for further guidance.
       8. Appointing an individual to serve as the ISSO with responsibility to develop, implement, and manage the security of the system.
   13. System ISSO.  The ISSO for each sensitive system shall perform the following functions:
       1. Advise the IT system owner on matters pertaining to IT systems security.
       2. Develop, implement, and manage the execution of the ITS program.
       3. Prepare or initiate preparation of an IT system security plan in the proper format for the IT system.  Requirements for ITS plans are contained in the HHS AISS Program Handbook.
       4. Conduct or initiate a risk analysis on the system when there are major changes to the system or every 3 years, whichever occurs first.  Requirements for risk analysis are contained in the HHS AISS Program Handbook.
       5. Ensure contingency and disaster recovery plans are developed, maintained in an up-to-date condition, and tested at least annually.  Requirements for contingency and disaster recovery plans are contained in the HHS AISS Program Handbook.
       6. Establish and maintain liaison with any remote facilities or users served by the IT system, the Area ISSO, or if appropriate, the subordinate organization ISSO.
       7. Monitor changes in hardware, software, telecommunications, facilities, and user requirements to ensure security is not compromised or degraded.
       8. Exercise system responsibility or direct activities for password management.
       9. Arrange for ITS awareness training for the system staff and monitor the user training programs to ensure personnel receive security orientation before being allowed access to sensitive IT resources.
       10. Ensure positions requiring access to sensitive information or resources are identified and incumbents of these positions receive an appropriate level of security clearance before access is granted.
       11. Investigate or initiate an investigation of known or suspected security incidents or violations.
       12. Prepare reports of findings as required in the HHS AISS Program Handbook.
       13. Refer all incidents involving a physical security violation, such as theft or violations of personnel security, sensitive information, or local security programs to the appropriate Agency for investigation.
       14. Communicate through verbal and written reports to the IHS ISSO through the Area ISSO, if appropriate.
       15. Ensure the organization abides by IHS "malicious software" policies and has the required virus detection software, elimination software, and procedures available to protect against these threats.  Refer to the HHS AISS Program Handbook for specific "malicious software" protection and reporting requirements.
       16. Audit all the systems at least annually and maintain inventories of all software on each individual system to verify only legal copies of software are being used.  Requirements for software copyright protection, auditing, and reporting are contained in this chapter and the HHS AISS Program Handbook.
       17. Review IT-related procurement specifications for hardware, software, or services to ensure they include adequate security requirements and/or specification commensurate with the sensitivity of the system.
       18. Conduct or initiate all activities required for the certification of the system, including preparing the certification and accreditation packages for final approval every 3 years or when major changes occur to the system, whichever occurs first.
       19. Coordinate with the Area ISSO or IHS ISSO on issues of mutual interest.
   14. Servicing Personnel Security Officer.  The Servicing Personnel Security Officer (SPSO) is responsible for processing appropriate completed personnel clearance requests for each designated individual through the Deputy Assistant Secretary for Human Resources.  (See HHS Instruction 731-1, Personnel Manual.)  The SPSO is also responsible for maintaining a list of encumbered positions, with a corresponding list of clearances and the date each clearance was granted.
   15. Privacy Act Officer.  Each Privacy Act Officer/Coordinator is responsible for notifying his/her ISSO of developments, deletions, or changes to automated systems of records under the Privacy Act to permit assessment of the continued appropriateness of the system's security level designation and certification/accreditation status.
   16. Contracting Officer.  Each Contracting Officer is responsible for the following:
       1. Ensuring all pertinent AISS requirements specified in this chapter are sufficiently detailed in each solicitation issued and contract awarded.
       2. Ensuring the contractor's compliance with these security requirements.
       3. Ensuring the pre-certification statements of AISS requirements for successful proposals are signed by both the Project Officer and organization ISSO and are submitted with the proposals.
       4. Including a statement in the RFP requiring offerors to present a detailed outline of their present or proposed AISS Program in their proposals.
       5. Including a statement in the RFP offerors are required to comply with the Statement of Work and with the requirements of the Departmental AISS Program.
       6. Forwarding to the organization ISSO any forms a winning contractor must submit to verify or obtain personnel security clearances.
       7. Ensuring the technical evaluation reports either detail any AISS deficiencies or confirm that the proposals are in compliance with the requirements.
   17. Headquarters/Area Records Management Officer.  Headquarters/Area Records Management Officers are responsible for providing consultation to database managers to ensure record retention schedules are adopted in accordance with IHS guidance and records disposal procedures are undertaken in accordance with the sensitivity of the data.
   18. Supervisors.  Supervisors are responsible for the following:
       1. Ensuring their employees are aware of, and observe all the security requirements of the data, AIS, AIS facilities, Indian Health Service/Tribes/Service or Health Units, and microcomputers they use.
       2. Monitoring employee activities to ensure strict compliance with all legal requirements concerning the use of proprietary software, e.g., respecting copyrights and obtaining site licenses.
       3. Ensuring only authorized software runs on Government microcomputers and other Government hardware.
   19. Users.  The primary purpose of an IT system is to support the mission of the using organization.  User management bears a great deal of responsibility for the organization's systems and data.  In addition to defining the functions to be performed by the system and its security requirements, the user is directly responsible for the system resources, such as terminals and printers, located within the user's area.  In order to ensure adequate security where these resources are located, each user manager will appoint a person to be responsible for the ITS within the user manager's area.  This individual is responsible for implementing and enforcing the security program at the user's location.  The functions of this person generally parallel those specified for the Area ISSO.  Additionally, each employee of the IHS is responsible for the adequate protection of IT resources within his/her control or possession and for abiding by all HHS and IHS ITS policies.  Users are responsible for the following:
       1. Assisting in the development of contingency plans.  This responsibility particularly involves determining which parts of automated processes can revert to manual processing and which need priority automated processing.
       2. Using all of the security measures available to protect application systems and databases.
       3. Assisting Application System/Data File Managers in determining the required security level designations for application systems/databases.
       4. Assisting Application System Managers in defining security specifications and testing security features of application systems under development or being enhanced.
       5. Running application systems/databases only at AIS facilities and I/T/Us are certified at a level of security equal to or higher than the security level designated for their application systems/databases.
       6. Implementing specified security safeguards to prevent fraud, waste, or abuse of the hardware, application systems, and data of the microcomputers they are authorized to use.
       7. Conforming to security policies and procedures minimize the risk to AIS, AIS facilities, and I/T/Us from malicious software and intrusions.  (See Part 8, Chapter 10, "Prevention, Detection, Removal, and Reporting of Malicious Software," IHM, and the HHS AISS Program Handbook Chapter XIII, "Malicious Software and Intrusions.")
8. MAJOR CONTROL AREAS.  The IHS is required to establish controls to ensure adequate security for all information processed, transmitted, or stored in its AIS.  This section establishes three major management control areas for the IHS ITS program in accordance with the Computer Security Act of 1987 (P.L. 100-235), OMB Circular No. A-130, Appendix III, "Security of Federal Automated Information Resources," the General Accounting Office's "Federal Information System Controls Audit Manual," and the NIST Special PUB 800-26, "Security Self-Assessment Guide for IT Systems."  The three IHS ITS major control areas are management, operational, and technical security control.
   1. Management Controls.  This section emphasizes management controls affecting individual users of IT.  Management controls are techniques are normally addressed by management in the organization's computer security program.  In general, they focus on the management of the computer security program and of risk within the organization.  The IHS management controls provide a centralized structure for reporting procedures and policies as well as provide Area Offices with considerable autonomy in managing their Area security programs.  This section identifies a minimum set of management controls required for the IHS ITS program.
      1. Security Level Designation.  The importance of information is a major factor in determining the goals and objectives of the security requirements and controls that must be implemented.  The security level designation of AIS should be determined by considering the requirements for confidentiality, integrity, and availability of the information.  Laws, regulations, or policies may establish additional specific requirements.
      2. Security Level.  The system owner shall designate the security level of the AIS in terms of their information sensitivity and criticality.  The security level designation may be low, medium, or high, depending on the need for protection of the data. (See NIST Special PUB 800-18 for further guidance.)
      3. Appropriate Use of Government Equipment.  All IHS employees are permitted "limited use" of Government office equipment for personal needs if the use does not interfere with official business and involves minimal additional expense to the Government.  This privilege to use Government office equipment for non-Government purposes may be revoked or limited at any time by appropriate IHS of HHS officials.  (See Part 8, Chapter 6, IHM.)
      4. Information Controls.  Information controls are management controls placed on the processing and storage of information in the organization.  This includes controls placed on the sharing of information, electronic messaging, and the use of software for processing information.
      5. Labeling Sensitive and Confidential Data.
         1. Media (e.g., diskettes, CDs, printed material, and tapes) used to record and store sensitive information shall be labeled, protected, controlled, and secured when not in actual use.
         2. Media containing sensitive information shall be labeled "Sensitive Information."
         3. Users shall ensure media containing sensitive information are accessed only by persons with a clear "need to know" and proper security level clearance.
         4. When sensitive information is printed, a label identifying its sensitivity shall be displayed at the top of the page.  The data owner may enforce additional requirements.
         5. Data provided by one Department, Agency, or organization for use by another Department, Agency, or organization shall carry the security level designation assigned by the data owner.
         6. This policy does not cover data deemed "classified" by the US. Government.  (See HHS AISS Program Handbook, Chapter II, Section C4.)
      6. Software Copyright Laws.  The use of software purchased by the Government is governed by the terms and agreements established by the software vendors and the IHS procurement process.  Infringement of software copyrights may constitute theft.
         1. All IHS users shall not run unauthorized software programs on IHS computers and shall comply with all copyright requirements.
         2. The legality of software shall be established; it shall then be maintained by surprise audits, as needed.
         3. Requests to authorize a non-standard IHS application for use on IHS information system resources should be made through the appropriate ISC.
      7. Use of Freeware or Shareware.  Freeware or shareware is software provided free of charge or for a minimum charge and is generally posted on various Web sites and bulletin boards.
         1. Only software authorized for business purposes shall be used on Federal computers.
         2. All software shall be officially procured by the IHS.
         3. All IHS users are prohibited from downloading software executables directly from external systems or Web sites to IHS systems without prior approval from the appropriate ISC.
      8. Information Sharing.  The IHS shall establish a written inter-Agency agreement with each external organization with which information is shared which states the terms and conditions of the information sharing.  When information is provided, the written agreements will specify the type of protection required and the procedures for protecting the data.
      9. Electronic Messaging.  Electronic messaging can take many forms, such as facsimile, e-mail, and other types of Internet access.  These forms of communication are intended for official and authorized purposes.  The IHS computer systems, networks, and communication devices are provided for use as specified in Section 8-12.1H(1)c, “Appropriate Use of Government Equipment.”  Any use perceived to be illegal, harassing, offensive, in violation of other Government policies, or any other use would reflect adversely on the IHS can be the basis for disciplinary action up to and including termination or judicial action.  All users are expected to conduct their use of these systems with the same integrity as in face-to-face or telephonic business operations.
         1. Every IHS organization shall identify its sensitive electronic data and provide effective and appropriate protection for data to be transmitted electronically.
         2. Electronic communications shall not be used to transmit confidential or sensitive information unless the communications are encrypted.  The encryption shall meet the minimum Government standards based on the sensitivity of the data and the requirements of the written agreement between the IHS and the other Agency.
         3. All IHS electronic communications are Government property and IHS officials may access messages whenever there is a legitimate official purpose for such access.
         4. In situations where unclassified but sensitive information must be transmitted to respond to an emergency situation and encryption is not available, the sender shall obtain authorization to transmit the information from the owner of the data and verify the recipient has received the communication after it is transmitted.
      10. Information Management.
          1. Sensitive data shall only be given to those who have a need to know such data and are cleared to receive the data.
          2. The basis for disclosure of protected health information is informed consent.
          3. Sensitive data shall be secured and protected whenever unauthorized individuals are present, when the data is not in use, and at the close of business.
          4. Very sensitive data or data with restricted access within an office shall be properly labeled (See Section 8-12.1H(1)e, "Labeling Sensitive and Confidential Data") and stored in a locked cabinet or safe, or encrypted or password protected if stored on a computer system.  Encryption shall meet the requirements of Section 8-12.1H(3)f, "Encryption."
          5. Individually identifiable health information shall not be disclosed without the informed consent of the identified individual(s) except as required by law.
      11. Joint Commission on Accreditation of Healthcare Organizations Accreditation and Quality Assurance.  All IHS health care facilities are subject to Joint Commission on Accreditation of Healthcare Organizations (JCAHO) accreditation and quality assurance processes for health care facilities.  The security requirements defined by JCAHO must be reviewed and incorporated where applicable.  (See the JCAHO Comprehensive Accreditation Manual for Hospitals:  "The Official Handbook.")
      12. Certification and Accreditation.  The process of certification and accreditation (C&A) is the major tool for managing the risks associated with the use of Major Applications (MA) and General Support Systems (GSS) (see OMB Circular A-130).  Accreditation is the process for gaining formal approval to operate an MA or a GSS through a formal acceptance of the risk under a specific set of environments and circumstances.  The accreditation is based in large part on a detailed technical assessment called certification.  Certification is a technical evaluation conducted by an independent assessment of the technical, management, and operational controls used and enforced by the system.
          1. For new application systems, the certification process shall begin during the design and development stages.
          2. Major application systems and general support systems shall be accredited prior to implementation and re-accredited at least once every 3 years.  Systems shall be re-accredited if the safeguard requirements outlined in the HHS AISS Program Handbook change, or the system undergoes a significant modification or is violated.
          3. The certification recommendation shall be based on an evaluation of a certification package that includes the following:
             1. Computer System Security Plan (CSSP).
             2. Security Specifications and Security Test and Evaluation results.
             3. Contingency plans.
             4. An assessment of residual risk.
             5. Any other documents referenced by the CSSP.
             6. Informal risk assessments performed on small systems.
          4. The DAA is the official who shall decide whether to approve the system for operation.  Without DAA approval, the system is not permitted to operate.
          5. The System Owner shall include a line item in the budget for C&A activities.
      13. Life Cycle Management.  Integration of security into the life cycle of AIS is critical to providing quality security protection and controlling risk.  Security controls shall be incorporated throughout all five phases of the computer system life cycle:
          1. During system initiation to assess the sensitivity of the system.
          2. As the system develops (acquired) to specify and incorporate security safeguards.
          3. During implementation to turn on (test controls) and obtain formal management authorization for operation (accreditation).
          4. When in operation to maintain assurance of security controls, monitor access privileges, and periodically re-certify the system.
          5. At disposal (transition to new system) to purge, overwrite, demagnetize, or destroy old media.
      14. Risk Management.  Risk management is the process of assessing risk, taking steps to reduce it to an acceptable level, and maintaining level of risk.  For IT systems, this means identifying and analyzing the threats to IT systems, identifying vulnerabilities in products or implementations used, and implementing measures to correct the vulnerabilities or mitigate the effects of the threats.

          These measures may involve changing operational procedures, implementing new products and technologies, or accepting certain risks that are not cost-effective to protect against.  The objective of the risk analysis is to provide a measure of the relative vulnerabilities and threats to an installation so security resources can be effectively distributed to minimize the potential for future losses.  The risk analysis may vary from an informal, but documented, risk assessment or review of a non-critical installation to a formal risk analysis for a large or critical computer system.

          1. Risk Management Process.  All IHS organizations shall establish and implement a risk management process for all IT resources to ensure the balance of risks, vulnerabilities, threats, and countermeasures achieves a residual level of acceptable risk.  The acceptable level of risk is based on the sensitivity or criticality of the individual systems.
          2. Risk Analysis.  System owners shall conduct a periodic risk analysis (JCAHO requirements need not be duplicated) of each IT system to ensure cost-effective and appropriate safeguards are incorporated into existing/new systems.
          3. Risk Assessment.  At a minimum, a risk assessment shall be performed:
             1. prior to the approval of design specifications for new systems,
             2. whenever a system must be re-certified,
             3. at least once every 3 years or in conjunction with JCAHO activities, and
             4. utilizing specific information and guidance concerning the risk management and risk analysis requirements contained in the HHS AISS Program Handbook.
          4. Acquisitions, Specifications, and Contracts.  In accordance with the requirements of the HHS AISS Program, every RFP that involves the development of an AIS or the use of Departmental AIS resources must include appropriate security requirements.  Security requirements must be considered in all phases of the procurement cycle: planning, solicitation, source selection and award, and contract administration.  (See HHS AISS Program Chapter XIV, Section A.)  All contractors involved in developing an AIS for use by the IHS or in providing any other type of service for the IHS in which Federal Information Processing (FIP) resources are used shall be required to comply with the requirements of this section and HHS AISS Program Chapter XIV, Section C.
             1. All products used in IHS systems shall be reviewed to ensure they have sufficient security features to satisfy Federal security and privacy requirements and to meet this security policy.  The IHS CIO shall review IHS-wide procurements; the Area ISCs shall review Area-specific procurements.
             2. Products used within IHS applications shall be approved for operation by the IHS CIO to ensure proper options are utilized and IHS security policy is followed.
          5. Resource Planning and Cost Considerations.  Security benefits have both direct and indirect costs.  Direct costs include purchasing, installing, and administering security measures such as fire-suppression systems or access control software.  Additionally, security measures can sometimes affect system performance, employee morale, or retraining requirements.  All of these have to be considered in addition to the basic cost of the control itself.  In many cases, these additional costs may well exceed the initial cost of the control (as is often seen, for example, in the costs of administering an access control package).  The IHS will perform a cost-benefit analysis, by weighing the cost against the risk and cost of damage, and will implement the security controls determined to be reasonable and justified.
   2. Operational Controls.  Operational controls are security mechanisms implemented and executed by individuals.  Operational controls are put in place to improve the security of a system or group of systems by addressing security needs that cannot be met by either technical or management controls.  Operational controls rely on all categories of users.  For example; end-users follow procedures in protecting their passwords and not leaving their systems unattended.  System administrators follow procedures for routinely backing-up the AIS.  A minimum set of operational security controls required for the IHS ITS program follows:
      1. Physical and Environmental Protection.  The physical security measures employed shall be in proportion to the sensitivity of the IT resources and data, and the criticality of the supported functions.  Building and property maintenance are the responsibility of the local facility's provider.  It is the responsibility of each operational unit's director to ensure proper physical controls are maintained to protect the equipment from unauthorized use and abuse.  It is the responsibility of the system owner or manager to define the requirements for the rooms and areas where IT equipment is housed and used.
         1. Access to special rooms for storing computer equipment such as mainframes, servers, file storage units, power systems, hubs, routers, Data Service Units/Communications Service Units, and environmental controls shall be limited to those having an official need to be in the area.
         2. Controlled areas contain potentially sensitive information and/or resources essential for the processing and communication of sensitive data.  Controlled areas shall be protected by physical security and other means deemed appropriate for the sensitivity or criticality of the system.  At a minimum, this shall include locks.
         3. Contract maintenance personnel and others not authorized unrestricted access but required to be in the controlled area shall be escorted by an authorized person at all times when they are within the controlled area.  An audit log of all escorted persons entering controlled areas shall be maintained.
         4. All computer equipment located in public areas where they may be unattended and within reach of the general public shall be secured to prevent unauthorized access or theft.
         5. Computer equipment located in public or semi-public areas shall be positioned such the displays are not easily viewable to those passing by.
      2. Contingency Planning.  Management officials dependent upon IT systems for the support of essential functions are responsible for the development and maintenance of contingency plans for these functions.  These contingency plans shall describe the resources and procedures to be used for maintaining the continuity of applications critical to the mission of the IHS in the event of a disaster. These contingency plans shall be reviewed and stored by the ISSO.  Contingency plans for large systems support Area or IHS functions shall be fully documented (JCAHO disaster plan acceptable).  Smaller, local systems may have more abbreviated and less formal plans.  Each contingency plan shall be tested at least once a year and shall include the following:
         1. Procedures for back-up storage and recovery of data and software, including but not limited to frequency of back-ups, testing of back-ups for usability, and secure off-site storage of back-ups.
         2. Selection of a back-up or alternate operations strategy.
         3. Emergency response actions to be taken to protect life and property and to minimize the impact of the emergency.
         4. Procedures for initiating contingency operations.
         5. Procedures for resumption of normal operations.
         6. Annual testing procedures.
      3. Disposal of Electronically Stored and Generated Data.  Since electronic information is easy to copy and transmit, information sensitive to disclosure often needs to be controlled throughout the computer system life cycle so managers can ensure its proper disposition.  Media controls must he applied to tapes, diskettes, printouts, etc., to prevent loss of confidentiality, integrity, or availability of information, and to provide accountability for the actions of authorized personnel.  The IHS shall dispose of all retired, discarded, or unneeded sensitive data and the media used to hold the data in a manner that will prevent unauthorized persons from making use of them.  This policy includes but is not limited to ensuring all sensitive information is erased from storage media prior to repair or release and all sensitive hard-copy documents are securely destroyed when they are no longer needed.  The disposition will be in keeping with licenses or other agreements, if applicable.
      4. Backup and Retention.  Software and data critical to the organization's mission shall be backed up frequently and maintained away from the AIS/facility I/T/U.  Critical software and data include current operating software, critical applications software, and critical databases:
         1. The AIS shall be backed up, at a minimum, once a week.  More frequent back-ups are required for critical systems such as those containing medical information or financial transactions and those with critical databases upon which decisions are based.
         2. The back-up media shall be tested for usability, stored securely off-site, and retained according to established procedures.
      5. Personnel Security.  The HHS Personnel Security/Suitability Program is outlined in detail in Instruction 731-1 of the Department's Personnel Manual under "Personnel Security/Suitability Policy and Technical Guidance."  Instruction 731-1 sets forth HHS policy in the areas of position sensitivity, suitability for Federal employment, personnel investigations, waivers, access to classified materials, and other personnel security considerations, and deals comprehensively with the responsibilities of management officials who carry out these functions (See HHS AISS Program Handbook Chapter VII, Section A.).
         1. Personnel security clearances and background investigations shall be conducted in accordance with Instruction 731-1.
         2. All users given access to IHS systems containing individually identifiable health information or IHS sensitive information are required to sign an agreement stating they will comply with the IHS rules for use of computer resources and handling of IHS sensitive information.
         3. Prompt notification shall be made to the ISC and ISSO when an IHS user resigns, retires, has a change in job status, or is transferred to another organization.
      6. Security Training and Awareness.  The IHS shall establish ITS awareness and training programs to ensure all IHS users involved in the management, operation, programming, maintenance, or use of IT systems are aware of the accepted IHS security procedures and their security responsibilities, and can recognize symptoms that may be indicators of potential security incidents.  The IHS policies for security training and awareness are as follows:
         1. All new employees shall receive ITS awareness training as part of their orientation within 60 days of their appointment.
         2. The training shall ensure IT users understand their security responsibilities.
         3. The training shall include the rules for the use of the IT systems and how to recognize and handle incidents.
         4. The training shall include discussion of the security rules for using the Internet, e-mail, and facsimiles.
         5. Annual refresher computer security training shall be provided to all IT users and shall be a condition of continued access to the IT systems.  Refresher training will be based on the sensitivity of the information the employee handles.
      7. Additional Training.  Employees shall receive training whenever:
         1. there is a significant change in the IHS ITS environment,
         2. there is a significant change in the IHS ITS procedures, or
         3. an employee enters a new position that deals with sensitive information.
      8. Training.  Training shall be provided for users of major IT applications to make them aware of the security issues and possible security breaches connected with using each application.
      9. Security Training.  Security training above the awareness level shall be provided to all personnel who design, implement, or maintain systems.  The training shall include the types of security and internal control techniques that should be incorporated into system development, operations, and maintenance.
      10. Individual Responsibility.  Individuals assigned responsibilities for IT system security shall be provided with in-depth training about:
          1. security techniques,
          2. methodologies for evaluating threats and vulnerabilities affecting specific IT systems and applications, and
          3. the selection and implementation of controls and safeguards.
      11. Training ISSOs.  The training for the IHS ISSO, Area Office ISSOs, and System ISSOs shall include in-depth coverage of the threats and vulnerabilities related to their systems, techniques for detecting and reacting to incidents, and techniques for implementing Part 8, Chapter 12, "IT Security," IHM in their environment.
      12. Incident Handling,Response, and Prevention.  A computer security incident can result from a system intruder inside or outside the IHS or from a computer virus, computer worm, or other malicious code.  A computer security incident has the potential for threatening the integrity, confidentiality, and availability of an agency's data; disrupting normal processing; and rendering an agency unable to perform its mission.  Therefore, it is necessary to develop specific and appropriate responses to the various security incidents that may occur.  It is also necessary to provide feedback to senior management on significant incident situations.  Please refer to Part 8, Chapter 9, "Establishing an Incident Response Capability," IHM, and to Part 8, Chapter 10, "Prevention, Detection, Removal, and Reporting of Malicious Software," IHM, for specific IHS policies and procedures on intrusion detection, incident handling, and virus protection.
      13. User Access.  This section discusses security controls over user access, both internal and public, to IHS systems, data, and resources.
          1. System Banners.  In conjunction with a review of the legal propriety of keystroke monitoring, the Department of Justice advised the NIST that Government agencies should warn system users that, by using a system, they are expressly consenting to keystroke monitoring.  Provision of written notice in advance to only authorized users is not sufficient.  Since it is important that unauthorized intruders be given notice, some form of banner notice at the time of signing on to the system is required.  (See HHS AISS Program Handbook, Chapter XIII.G)  A system banner is a screen display that provides introductory information about the application or system before a user gains access to the system.  All computer systems shall have a banner that users view before logging in or signing on to a network, system, or application.  This banner shall do the following:
             1. Identify the system as an IHS computer system protected under the United States Criminal Code.
             2. State that violations, unauthorized access, or misuse are punishable by United States Criminal Code and that users are subject to having their activities monitored.
             3. State that anyone using the computer system consents to monitoring and that if monitoring reveals evidence of possible criminal activity, it may be turned over as evidence to law enforcement personnel; and warn system users that, by using a system, they are expressly consenting to keystroke monitoring.
          2. Account Management.  A user account shall be associated with one user.  When this one-to-one association is maintained between the authorized user and a valid user account, the actions the application performs on behalf of a user account can be traced back to an authorized user:
             1. A unique user account shall be established for each identified user.
             2. Each user account shall be assigned only the minimum number of privileges required for the user associated with the user account to perform his/her assigned duties.
             3. A user account shall be terminated or suspended by a responsible individual (e.g., system administrator, system manager, or project manager) when notified of:
                1. termination of user employment or contract, or
                2. non-use of account for 12 consecutive months.
      14. Privileged User Account.  Special authorized users, e.g., administrators, have the ability to perform tasks such as creating user accounts, enabling/disabling user account privileges, and enabling/disabling system security mechanisms of an application.  These and other capabilities are considered security-relevant privileges.  Any user account that has these capabilities is considered a privileged user account.
          1. Privileged user accounts shall be kept to a minimum, be subject to special audit, and be used only for those activities requiring “Super User” abilities.
          2. Maintenance accounts shall be disabled when not in use, and maintenance personnel shall have appropriate clearances or background checks.
          3. When a privileged user is terminated, all access to privileged accounts shall be promptly revoked, passwords used to provide privilege shall be changed, and appropriate site managers should be notified.
      15. Unattended Computers.  In the event a user needs to leave his/her computer workstation, located in either his/her official duty station or remote location, or a public work area for any length of time, the following shall apply:
          1. Users shall not leave a computer workstation when a critical application system is resident in memory.
          2. Users must log-off or lock the screen.
          3. The workstation shall be configured to automatically lock the screen or log-off the user.
      16. Users.  Users shall not:
          1. alter the pre-configured timing locks on their workstations, or
          2. disable the automatic screen-lock feature.
      17. Connections.  The IHS systems may be connected to other IHS systems and to non-IHS systems through a variety of network configurations.  The following sections define the policies for each type of connection and the restrictions on the connections to IHS systems and non-IHS systems.
          1. Remote System Access and Telecommuting.  Remote system access refers to authorized IHS users accessing IHS resources from a computer that is not directly connected to the IHSNET.  Remote access includes using home computers and portable computers via dial-in telephone modem or the Internet to access IHS systems.  Additional guidance on remote system access and telecommuting can be found in Part 8, Chapter 8, "IT Security for Remote Access," IHM.  The IHS policy for remote system access is as follows:
             1. Information regarding access to IHS computer and communication systems, such as dial-in modem phone numbers, is considered confidential.  This information shall not be posted on electronic bulletin boards, listed in telephone directories, placed on business cards, or made available to third parties.
             2. Users connected to the IHSNET are not permitted to install software that enables direct remote access to their computer via modem.
             3. Computers connected to the IHSNET shall not be configured with a modem.
             4. Only authorized IHS users and cleared contractors with valid accounts are permitted to access the network remotely.
             5. Guest accounts are not permitted.
             6. Strong authentication (e.g., token-based or biometric systems) shall be used to authenticate users for remote access.
             7. All remote access to the IHSNET shall be audited.
          2. Local Area Network Connections.  A LAN is a collection of workstations, servers, and shared resources at a single location.  The policy for LAN connections is as follows:
             1. Computer systems connected to the IHS LAN shall implement the IHS security policies.
             2. Limiting user access to Internet and Intranet resources is the responsibility of local site management.
          3. Intranet Connections.  An Intranet is a collection of networks that make up the IHSNET.  An Intranet connection is a connection between networks within the IHSNET.  The policy for Intranet connections is as follows:
             1. The networks directly connected to the IHS network shall implement the IHS security policies.
             2. Requests for modifications to routers or other communications configurations shall be made to the appropriate Area ISCs.
             3. Changes to network configurations shall be approved for security compliance by the organizational unit's ISC before implementation.
          4. Wide Area Network Connections.  A Wide Area Network (WAN) connection connects a non-IHSNET to the IHSNET.  Wide Area Networks include dedicated data lines between the IHS and other organizations.  Shared and dedicated data lines between the IHS and other organizations are a risk since the owner of the communication line and the external organizations cannot be held to following the IHS security policy.  All WAN connections shall be permitted only to the IHS and approved organizations under the following conditions:
             1. Restrictive routing rules shall be applied to ensure that only authorized traffic is permitted on the WAN.
             2. These routing rules shall be enforced by a firewall under the control of the IHS.  The firewall shall ensure that only authorized traffic is permitted between the IHS and the other organization.
             3. All IHS systems accessed by the other organization shall be isolated to restrict the degree of damage that could be caused by a compromise in security.
             4. The IHS CIO shall approve authorization for the installation of wide-area connections.
          5. Internet Connections.  An Internet connection provides connectivity to multiple networks and services such as the WWW and e-mail.  It is established by contracting with a service provider to provide a link that gives the IHS wide-area capability to unlimited sites.  The Internet connectivity policy is as follows:
             1. All access to the Internet shall be made through the use of the IHS provided/authorized connection.
             2. Connection to the Internet using private accounts with Internet Service Providers is prohibited within IHS facilities.
             3. The IHS services made available to the Internet shall be hosted on computer systems protected from Internet attack.  The IHS Intranet shall be protected from systems hosting Internet services by a firewall.
             4. Alerts shall be enabled on systems hosting services to the Internet, and audit logs shall be reviewed on a daily basis by the respective organization's IRM staff or designated ISSO.  Suspicious activity shall be reported to the IHS ISSO as a potential security incident.
             5. The IHS CIO may provide additional guidance for systems hosting Internet services.
      18. Configuration Management.  Configuration management is the process of keeping track of changes to the system and, if needed, approving them. Configuration management normally addresses hardware, software, networking, and other changes; it can be formal or informal.  The primary security goal of configuration management is ensuring that changes to the system do not unintentionally or unknowingly diminish security.  It is IHS policy that:
          1. configuration management shall be implemented for hardware, networks, and applications; and
          2. Indian Health Service users shall not add software or otherwise make configuration changes to their computer systems outside of the configuration management process.
   3. Technical Security Controls.  Technical security controls are security controls that the computer system executes.  They can provide automated protection from unauthorized access or misuse, facilitate detection of security violations, and support security requirements for applications and data.  This section identifies a minimum set of technical security controls required for the IHS ITS program.
      1. Identification and Authentication.  Identification and Authentication (I&A) are the means by which a user provides a claimed identity to a system or application, and the system or application establishes the validity of the claimed identity.  The IHS I&A policy is as follows:
         1. Each user with access to IHS sensitive information shall be uniquely identified to the system or application.  Users may not share a single username or account.
         2. The system owner will provide written approval for the creation of each user account.  Accounts for terminated personnel shall be disabled from the system immediately.
         3. At a minimum, passwords shall be used to authenticate users to computer systems.
         4. If the software system supports automatic enforcement of password rules, it shall be configured to provide this enforcement consistent with this section.
         5. If the system software does not support automatic enforcement, the system administrators shall verify that IHS password rules are enforced.
         6. Files used in I&A shall be appropriately protected by the underlying operating system.
      2. Logical Access Control.  Logical access control refers to the process of limiting user access to those system resources for which the user has been specifically granted permission.  The IHS access control policy is as follows:
         1. All IHS systems supporting multiple accounts or access by multiple users shall control user access to system resources.
         2. Each user accessing resources on the IHS network shall have a user account.
         3. The user is permitted to access only those systems for which the system owner has granted written permission.
         4. Access permissions shall be kept to a minimum on a "need to know" basis.
         5. Access permission to IHS information and information system resources for IHS users shall be established according to the requirements of their individual job functions and security clearance.
         6. User access permissions shall be re-evaluated when an employee resigns, retires, has a change in job status, or is transferred to another organization.
         7. Management is responsible for ensuring that separation of duties is enforced.
         8. Privileged accounts shall be kept to the minimum number possible.  Personnel assigned those powerful accounts shall have higher clearances and be assigned "regular" accounts to use for activities not requiring "super user" capabilities.
         9. Access controls shall be reviewed and audited regularly.
      3. Auditing.  A system security audit trail is the mechanism for associating actions on behalf of a user account with an authorized user.  A system security audit trail records a user's actions.  Knowledgeable individuals can use the system security audit trail to associate recorded actions with an authorized user.  The system security audit trail records the user-ID of the requesting user account along with the requested action.  The Health Insurance Portability and Accountability Act (HIPAA) requires the use of audit control mechanisms to record and examine system activity so that an organization can identify suspect data access activities, assess its security program, and respond to potential weaknesses.  The IHS policy regarding system security audit trails includes the following:
         1. The capability to generate a system security audit trail of all significant automated information security relevant events.  Whenever the system/application is connected to the IHSNET, the capability shall be enabled.  Examples of security-relevant events include failed authentication attempts, attempts to use privileges that have not been authorized, account creation, account permission changes, and system configuration or audit configuration changes.
         2. The ability to collect and maintain system security audit trail records in such a manner that they can be used to support appropriate action in response to computer abuse.
         3. The retention of system security audit trail records for at least 3 months and their protection from any unauthorized access or modification.
         4. Compliance with HIPAA technical security mechanisms of alarm, audit trail, entity authentication, and event reporting for data transmitted over a communications network.
         5. The collection and maintenance of audit trails of the activities performed by privileged users.
         6. The installation of additional monitoring tools, when feasible.
         7. The reporting and searching of utilities that allow the administrator to select and analyze the action of any user account or set of user accounts.
      4. System Security Audit Trail.  A system security audit trail is useless if it is not regularly reviewed and properly managed.  The IHS policy is as follows:
         1. System security audit trails shall be reviewed regularly.
         2. Any discrepancies or symptoms found that might indicate intrusive activity shall be reported in a timely fashion to the appropriate manager and the system ISSO.
         3. Managers are to authorize the analysis of audit trails only for valid reasons (i.e., to reconstruct events after a problem has occurred, to discern flaws in applications, or when there is reason to suspect impropriety on the part of a user).
      5. Reviews of High-risk Applications.  Reviews of high-risk applications, such as Internet firewalls and highly sensitive servers, shall be performed more frequently than less sensitive systems or applications.
      6. Encryption.  Encryption shall be used to protect sensitive information when it is transmitted over a network not certified for sensitive information.  The IHS shall follow Federal standards in the determination of devices, algorithms, and digital certificates that can be employed.  The IHS shall employ the following FIPS cryptographic standards unless the IHS CIO approves alternate algorithms:
         1. FIPS PUB 46-3, Data Encryption Standard
         2. FIPS PUB 140-1, Security Requirements for Cryptographic Modules
         3. FIPS PUB 171, Key Management Using ANSI X9.17
         4. FIPS PUB 180-1, Secure Hash Standard
         5. FIPS PUB 185, Escrowed Encryption Standard
         6. FIPS PUB 186-2, Digital Signature Standard
         7. FIPS PUB 188-2, Standard Security Labels for Information Transfer
         8. NIST Special PUB 800-2, Public Key Cryptography
         9. NIST Special PUB 800-9, Good Security Practices for Electronic Commerce, Including Electronic Data Interchange