University of Wisconsin-Milwaukee HIPAA Security Guidelines

Transcription

1 University of Wisconsin-Milwaukee HIPAA Security Guidelines Created by Steve Brukbacher Information Security Coordinator University of Wisconsin Milwaukee, Information and Media Technologies Last Revised January 2, 2007 Adapted, with permission, from University of Wisconsin - Madison HIPAA Security Best Practices. Board of Regents of the University of Wisconsin System on behalf of the University of Wisconsin Milwaukee, 2006.

2 Table of Contents: Foreword Page 3 Definitions Page 5 Account Creation and Access Control Page 8 Audit Controls Page 12 Contingency Planning Page 15 Network Device Security Page 17 Remote Access to EPHI Page 20 Password Management Page 23 Portable Device and Media Page 26 Server Security Page 29 Wireless Communication Page 36 Workstation Use and Security Page 38 2

3 FOREWORD This document is intended to provide guidelines to University of Wisconsin Milwaukee ( UWM ) departments on the technical aspects of complying with the HIPAA Security Rule. The Security Rule provides procedures for safeguarding Electronic Protected Health Information ( EPHI ) and preventing access to such confidential information by unauthorized persons. The Security Rule defines EPHI as Protected Health Information ( PHI ) that is stored or transmitted by electronic media. EPHI includes PHI that is stored on hard drives or portable memory media (disks and CDs) as well as PHI that is transmitted via or the internet. The Security Rule requirements are in addition to those mandated by the HIPAA Privacy Rule discussed in detail in UWM s Policies and Procedures for Protection of Patient Health Information Under the Health Insurance Portability and Accountability Act ( HIPAA ). UWM has designated certain Covered Departments within the University that provide, bill and are paid for health care. All employees and volunteers in Covered Departments must comply with the Privacy and Security Rules. In developing the Guidelines which follow, every effort was made to be general and not too proscriptive or specific. The Guidelines are written for a wide audience, and, as such, all of the suggestions contained herein may not be appropriate for all units or departments. For example, the security procedures required to protect EPHI in a one person research office may differ considerably from the security procedures necessary to protect EPHI in a larger department. Efforts were also made to be clear when something is mandatory. If a safeguard detailed in a given Guideline is mandatory, it includes a must instead of a should or should consider. Whenever possible, we also tried to reflect the flexibility of methods allowable under the HIPAA Security Rule. The Security Rule rarely mandates exactly how to mitigate any given security risk, rather it allows for considerable flexibility. In developing the Guidelines which follow, we have attempted to retain this flexibility of method while at the same time providing guidance to departments and I&MT or other IT staff. How to Use this Document: Each Guideline is titled by topic and contains safeguards meant to address technical solutions suggested or required by the Security Rule. It is important to note that many of the provisions contained in the HIPAA Security rule, by their nature, tend to be addressable by a policy or procedural solution. We attempted to address each safeguard discussed in the HIPAA Security Rule at least once. However, you should not assume that because you have covered all of the items in these Guidelines, that your HIPAA compliance is complete. You should refer to the UWM HIPAA website for complete HIPAA compliance program details ( The Guidelines should be 3

4 reviewed and referenced when designing the computing environment of a Covered Department and safeguards that have been taken care of by way of a technical configuration should be noted. Then, the Guidelines should be reviewed with the management of the Covered Department to work out additional policies and standards that need to be developed and processes that need to be documented. Computer configuration choices do not take the place of this step, as the Security Rule requires the adoption of certain policies and processes, in addition to the implementation of technical safeguards. 4

5 DEFINITIONS Access Control: Access Control represents the administrative and technical safeguards used to control access to resources such as computers and data. This term also includes the act of limiting a specific user's access to certain data or files as determined by the security requirements. Access Level: The "rights" a user account has concerning access to a file or data. These rights will vary among operating systems or applications, but usually include: read (the ability to look at a file or its contents), write (the ability to create a file or modify an existing file's contents), and delete (the ability to erase a file). Account Creation: The process of creating an account (or some other access point) on a computer system, database or application and granting it permission to access or use some subset of files or data. Security policies and their underlying processes and guidelines developed by the Covered Department should govern this process. The policies should not only address account creation, but should also address how long the account exists and describe the conditions by which the Covered Department terminates the account. Archive: Complete copy of data, usually for long term storage purposes. Authentication: Authentication is the process of verifying the identity of a person. Authentication can take place via something you know, something you have or possess, or something you are, such as biometric data (fingerprint) or a token device containing a one-time password hash. Backup: Complete, exact and retrievable copy of current data for the purposes of ensuring data availability and integrity. Business Continuity: Maintaining the ability to provide services in the event of a disaster. Cable Modem: Cable companies such as Charter Communication provide Internet access over Cable TV coaxial cable. A cable modem accepts this coaxial cable and can receive data from the Internet at over 1.5 Mbps. Cable is currently available only in certain communities. Covered Departments: UWM departments or units that provide health care, generate records containing PHI or provide administrative services to such departments or units. For a list of UWM Covered Departments, click here. Data Browsing: The act of viewing data or records which a user has not been explicitly authorized to view. For example, a health care provider looking at records of patients not under that provider's care. 5

6 Dial-in Modem: A peripheral device that connects computers to each other for sending communications via telephone lines. The modem modulates the digital data of computers into analog signals to send over the telephone lines, then demodulates back into digital signals to be read by the computer on the other end; thus the name modem for modulator/demodulator. Disaster: A disaster is defined as a sudden, unplanned catastrophic event that significantly impedes an organization s ability to access EPHI. A disaster could be the result of significant damage to a portion of operations, a total loss of a facility, or the inability of employees to access computing resources. DSL: Digital Subscriber Line (DSL) is a form of high-speed Internet access competing with cable modems. DSL works over standard phone lines and supports data speeds of over 2 Mbps downstream (to the user) and slower speeds upstream (to the Internet). Dual Homing: Having concurrent connectivity to more than one network from a computer or network device. Examples include: being logged into the campus network via a local Ethernet connection and dialing into AOL or other Internet service provider (ISP); being on a UWM-provided Remote Access home network, and connecting to another network, such as a spouse s remote access. EPHI or Electronic Protected Health Information: PHI or Protected Health Information that is stored or transmitted by electronic media. EPHI includes PHI that is stored on hard drives or portable memory media (disks and CDs) as well as PHI that is transmitted via or the internet. External USB Hard Drive: A hard drive enclosed in a housing with a USB connection to the computer. Handheld Computer: A small computer running a portable version of an operating system. HIPAA or the Health Insurance Portability and Accountability Act of 1996: A set of privacy regulations (the Privacy Rule ) and security regulations (the Security Rule ) designed to protect the confidentiality of PHI and EPHI generated or maintained in the course of providing health care services. UWM has developed a list of Covered Departments which must comply with HIPAA. Laptop Computer: Portable computer running a standard operating system (OS). Off-site Backup: Mechanism to backup or archive EPHI in a physical location other than that in which the data is primarily stored. PDA or Personal Digital Assistant: Handheld device used to store a variety of personal information such as contacts and schedules. It is also capable of storing digital data such as PHI. 6

7 Portable Media: Floppy Disk, CDROM, DVD, or other media designed to store data. Portable Storage Device: Device used for storing data such as USB flash Drives, USB Hard Drive, or I-pod. PHI or Protected Health Information: Information relating to the past, present or future physical or mental health conditions of an individual, the provision of health care to an individual, or the past, present or future payment for the provision of health care to an individual. Remote Access: In general terms, this refers to remote access to a network attached device. This could occur from on campus or from off campus. This includes things like remote control software and file sharing technologies. Split-tunneling: Simultaneous direct access to a non-company network (such as the Internet, or a home network) from a remote device (PC, PDA, WAP phone, etc.) while connected into a corporate network via a VPN tunnel. Tablet Computer: A portable computer that allows the user to enter data by writing on the computer screen. USB Thumb Drive: A small flash memory device which plugs in to a USB port on a computer for data storage. Virtual Private Network or VPN: A computer network that is constructed from the system resources of a relatively public, physical (i.e., real) network (such as the Internet), often by using encryption, and often by tunneling links of the virtual network across the real network. For example, if a corporation has LANs at several different sites, each connected to the Internet by a firewall; the corporation could create a VPN by (a) using encrypted tunnels to connect from firewall to firewall across the Internet and (b) not allowing any other traffic through the firewalls. 7

8 UNIVERSITY OF WISCONSIN MILWAUKEE HIPAA SECURITY GUIDELINES 1. Guideline Name: Account Creation and Access Control 2. Purpose: The purpose of this guideline is to provide recommendations for creating user accounts on, and defining access control to, computer systems in order to reduce the risk of data access by unauthorized subjects. This guideline applies to all Covered Departments. 3. References: A. HIPAA: The recommendations in this guideline address the concerns found in the following HIPAA regulations: (a) (1), (3), (4) (a)(8) (a) (d) B. Other: UW-Milwaukee s "Appropriate Use" policy: 4. Account Creation and Access Control Guidelines: A. Storage and Transmission: Applications and systems that store or transmit EPHI must: 1. Require Authentication of individual users to the extent that individual access to EPHI is recorded; 2. Not allow passwords to be stored in clear text or in any easily reversible form; 3. Provide a means for auditing Authentication success attempts and other activities as applicable; 4. Allow for auditing of each individual user s activities; and 5. Automatically log a user off or employ a password protected screensaver after a predetermined time of inactivity. 8

9 B. Account Creation: Note: Some applications (such as large database systems) may utilize separate accounts in addition to (or in place of) the operating system's accounts. Administrators of such systems should consider these guidelines both for system level access and application level access. 1. Accounts that grant access to EPHI must be authorized by the management of the Covered Department. Management may delegate this process to a data custodian or other individual. 2. An account creation policy should exist which clearly defines who is eligible for an account. Only those who need access to such account as part of their job responsibilities should be eligible. 3. The policy should also describe the procedure for requesting an account. An administrative authority (such as a supervisor or manager) should write such a request. Rights assignments must be reviewed regularly. 4. The assignment of roles including supervisor, appropriate administrative manager, and data custodian require approval by the management of the Covered Department. 5. The name of each account must be unique within the University. 6. The system administrator should assign an initial, strong password to the account and configure the account so that the employee must change the password at the first login. For details on password guidelines, please see the University of Wisconsin - Milwaukee s HIPAA Security Guidelines: Password Management Guideline. 7. The Covered Department should implement a policy which defines the duration of the account. 8. The Covered Department should implement a policy which defines or explains the conditions under which accounts should be terminated. These conditions may include employment termination or reassignment (i.e. any employment change that ends the employee s need to have access to PHI). Removal of access to EPHI should be among the sanctions for policy violations. A technical process for removal of access to EPHI must also be developed. C. Access Control: Two basic components of Access Control are Identification and Authentication. Identification is the unique login ID or username 9

10 assigned to a specific user. Authentication is a secret key which consists of something an individual knows, has, or is. Appropriate user identification and authentication are essential to any Access Control Policy. Careful configuration of access controls, can reduce both security breaches and the risks of inappropriate modification. For example, denying read access helps to protect the confidentiality of information, and denying unnecessary write (modify) access can help maintain the integrity of such information. 1. The access control technology implemented must employ a mechanism for uniquely identifying each user entity or application and provide a method for authenticating them. At a minimum, access to EPHI must require password Authentication. Ideally a second factor of Authentication beyond simple password usage such as a hardware token or biometric information should be considered to further protect EPHI. This includes information systems, such as databases that store EPHI, and computer systems. 2. Choose a file system that lets you define access rights. For example, the Windows FAT file structure does not have any built-in security features; the NTFS structure does. You should move EPHI to systems that use file/folder rights to determine access. 3. Identify files and folders containing EPHI, and list those people authorized to use them and their access level (read, write, delete, administer). A good way to separate rights for EPHI versus non- EPHI files is to create a matrix listing file categories (EPHI being one category) on one axis and users or user groups on the other axis. At each file/user intersection, record the appropriate rights. 4. User groups are a recommended way to maintain access rights to files, folders or database views. However, an access control policy should provide for periodic review of these groups and the use of caution in their maintenance to ensure, by way of group membership, that an individual is not accidentally given unauthorized access to EPHI. 5. Configure access control to EPHI and other files: a. Assign rights (read, write, delete, other) to groups or users as appropriate.; b. Disable write access to executable or binary files; c. Restrict access to operating system files to the "read" level, wherever possible; 10

11 Published: [July 2006] Revised: d. Prevent users from installing software, scripts, or other executables; and e. Be aware of rights inheritance. Rights given to a group of users in one folder may not be appropriate in subfolders. Many operating systems by default allow subfolders to inherit rights from parent folders. 6. Wherever possible, implement file encryption on records or databases containing EPHI. Note: Encryption methodologies should be accompanied by technical and administrative precautions for decrypting data in cases where the key is lost. For instance, operating systems sometimes relate encryption keys to user accounts. If you delete those accounts (when the user leaves), you may lose the ability to decrypt files. Other encryption technologies use public and private encryption keys. The private keys should be securely and centrally escrowed to ensure administrative access to data in the event of a lost key or an unexpected employee departure. 7. For database environments, use views to restrict viewing of data. 8. Databases and medical record software should be configured so as to disallow a user from viewing, printing or downloading more than one record at a time. The user should not be able to download large amounts of patient data, nor should they be able to place more than one record at a time on the screen. 9. Document access control rights, and review the documentation periodically. Update the documentation whenever rights change, new users are added, or when old users are deleted. Include not only the users/groups and the rights given to files, but also the rationale for assigning or denying certain rights. Documentation should also exist showing that the individual was granted access to that information by the management of the Covered Department, the data custodian, or their authorized delegate. 10. Password policies must be in keeping with the University of Wisconsin-Milwaukee s HIPAA Security Guidelines, Password Management Guideline. 11

12 UNIVERSITY OF WISCONSIN MILWAUKEE HIPAA SECURITY GUIDELINES 1. Guideline Name: Audit Controls 2. Purpose: The purpose of this guideline is to provide recommendations for auditing access to and use of EPHI. For purposes of this guideline, Audit means the retrospective review of access to electronic records and the reporting of the findings of such review. Audits may be conducted to: ensure the integrity, confidentiality, and availability of information and resources; investigate possible security incidents to ensure that policies are being conformed with; and monitor the use of system activity where appropriate. This guideline applies to all Covered Departments. 3. References: The recommendations in this guideline address the concerns found in the following HIPAA regulation: S (b) 4. Audit Control Guidelines: A. Levels of Auditing Capability: The sophistication of the auditing capability for access to EPHI is a function of: existing access controls to the EPHI data; the size of the workforce accessing the EPHI; and the risk of an inappropriate access event. Auditing capabilities may take on a three-tiered level of sophistication and can be characterized as follows: 1. Multi-user, multi-document, multi-application system with nonsegregated user access: This is a situation where any user can see any data in the database and no access-limiting walls exist within the data or within the log-on process. Electronic tracking of all access events which document user identity, date, time and records accessed may be appropriate for this type of system. Typically large numbers of people access the database, a large amount of EPHI is included in the database, and risk of inappropriate access is significant. 2. Multi-user, multi-document, multi-application system with segregated access: Users are granted access to parts of the database that they need to access but not the entire database. Electronic 12

13 tracking of database access which can log user identity and date/time accessed, but not specific records accessed, may be appropriate for this type of segregated access system. 3. Single-user, multi-document, multi application system: No electronic tracking may be needed to record EPHI data access, which is limited to a single user. This system would require the ability to document EPHI related data that resides within the database. A researcher s data file on her PC is an example of this type of system. B. Cost and Degree of Risk: When considering electronic audit capability, the Covered Department should consider both the cost of implementing various levels of audit capability and the degree of risk of inappropriate access to EPHI. C. Audit Logs: Audit logs must be kept for the longer of: the time period required by UWM or the time period required by the responsible Covered Department. D. Proactive and Reactive Auditing: System and data owners are required to proactively and reactively engage audit processes to detect unauthorized access attempts. 1. Proactive audits should be performed periodically, with the intent of sampling the data set to look for possible inappropriate use or activity. 2. Sampling does not have to be random. Proactive audits can sample from the entire log population or from areas known to be of higher risk. For example, when reviewing access logs to patient records, it may be appropriate to intentionally sample from the population of employee patients, as well as from the patient population as a whole. 3. Proactive auditing can serve as a deterrent to would-be voyeurs. Therefore, it is important that system users are aware that proactive auditing takes place. 4. Reactive audits are performed whenever a defined event triggers the need for an audit. An "event" might be a patient or employee complaint or a security system alarm. 13

14 5. It is also advisable to audit appropriate logs when unusual or extreme situations occur, such as a highly publicized accident involving victims treated at your facility, an illness of an employee known to coworkers with access to systems containing the employee's PHI, or the involuntary termination of an employee. E. Monitoring: All systems containing EPHI must be monitored for potentially malicious activity. F. Records: Audit records must be archived or backed up in a centralized repository (apart from the source data) for the timeframe required by UWM s Retention Policy. Published: [July 2006] Revised: 14

15 UNIVERSITY OF WISCONSIN MILWAUKEE HIPAA SECURITY GUIDELINES 1. Guideline Name: Contingency Planning 2. Purpose: The purpose of this guideline is to define the requirements for contingency planning. This guideline applies to all Covered Departments. 3. References: A. HIPAA: The recommendations in this guideline address the concerns found in the following HIPAA regulations: (a)(7) (a)(1) (a) 4. Contingency Planning Guidelines: Each Covered Department must develop a Contingency Plan to address the possibility of significant loss of data due to an emergency or disaster such as fire, vandalism, system failure, or natural disaster affecting systems containing EPHI. This consists of the following elements: A. Assessing Applications and Data Criticality: Each Covered Department should assess applications and data by developing an inventory of software, hardware, and data critical to providing services or continuing operations. Databases and file systems, information on servers and desktops, and physical equipment should be included in this inventory. B. Creating a Data Backup Plan: 1. Each Covered Department will develop a process to address regular data backup of all EPHI. This plan shall include a schedule for incremental backup, archiving, tape rotation and off-site backup. Procedures must be outlined to recover any data lost from backup. 2. A full archive of EPHI should be taken weekly and stored off-site. Such archives should be encrypted and secured in a locked facility. 3. For more details regarding backup and recovery requirements, please see University of Wisconsin - Milwaukee s HIPAA Security Guidelines: Server Security Guideline. 15

16 C. Creating a Disaster Recovery Plan: 1. Consider specific causes of disruptions including damage/destruction to your facility or area where your data is stored, situations where staff cannot come to work, natural disasters, power outages or civil unrest. 2. Covered Departments should be able to restore access to EPHI from backups in the event of irrevocable damage or destruction to systems. Covered Departments should establish a timeline with I&MT or other IT staff serving their department for recovery of their systems. D. Creating an Emergency Mode Operation Plan: Each Covered Department should develop an Emergency Mode Operations plan to continue operations in the event that data and systems are not available. Consider 1, 5 and 14 day outages for specific systems. For those Covered Departments delivering clinical services, a Business Continuity Plan must be developed that describes the sequence involved in ensuring the ability of the Covered Department to deliver business critical services in the event of loss of access to data and systems utilized in providing those services. E. Testing and revising the Contingency Plan: 1. Data Recovery and Business Continuity Plans must be sufficiently documented to allow for periodic testing. 2. Data Recovery and Business Continuity Plans must be periodically tested. Published: [July 2006] Revised: 16

17 UNIVERSITY OF WISCONSIN MILWAUKEE HIPAA SECURITY GUIDELINES 1. Guideline Name: Network Device Security 2. Purpose: The purpose of this guideline is to increase the security of network devices. Network devices include routers, Ethernet switches, Ethernet hubs, wireless access points, load balancers and similar equipment. Related devices include network servers providing infrastructure protocols such as DHCP, DNS, and NTP. Additional devices beyond these include any proxy servers you might have. These devices control where your network packets are routed and at what rates. Just as you cannot maintain your HIPAA security without physical security for your buildings, you cannot maintain your HIPAA security without proper security for your network devices. Network devices should be managed in a secure manner, guided by current best practice standards in the industry. Note that several other guidelines regarding VPN, wireless and workstation security all interact strongly with your network device security policy. This guideline applies to all Covered Departments. 3. References: A. HIPAA: While there is no specific requirement under HIPAA that Covered Departments have a network device security policy, compliance with the following regulations is achieved by the implementation of this Guideline: (a)(1) (risk management) (a)(5) (protection from malicious software) (a)(6) (response and reporting) (a)(7) (emergency mode operation plan) (a) (facility security plan) (e) (integrity controls) B. Other: Cisco network security best practices whitepaper: Center for Internet Security Cisco router benchmark: Firewall Checklist: 17

18 NIST Firewall Guide: 4. Network Device Security Guidelines: A. Approval: The management of a Covered Department must approve all network device implementations. Once approved, network devices and services should only be installed and configured by I&MT or other IT staff serving the Covered Department. B. Physical Security: Physical security of network equipment, including wiring facilities, should be as strong as possible. Access should be restricted to rooms containing network equipment and wiring closets. Such areas should be locked at all times. Shared use of these areas is strongly discouraged. C. Default Passwords: Ensure that the default administrator passwords for network devices have been changed to strong passwords based on the University of Wisconsin -Milwaukee s HIPAA Security Guidelines: Password Management Guideline. D. Management Interfaces: Management interfaces for network devices should be as segregated as practical. Management interfaces should be put on separate Ethernets, separate VLAN's, use unrouted RFC 1918 IP addresses, or use serial connections to a dedicated management console. E. Encrypted Connections: Encrypted connections should be used for device management. SSH should be used in place of Telnet, and HTTPS should be used rather than HTTP. F. Access Points: For incident response purposes, it should be possible to quickly locate devices on the network (room and wall jack) based on either a MAC or IP address. Covered Department management and I&MT or other IT staff serving the Covered Department should be aware of all networking equipment and access points. G. Multiple Network Connections: Any computer with multiple possible network connections such as Ethernet + modem or Ethernet + wireless is a potential router and must be managed as a high risk device. This includes many laptops and any home PC's which bring up VPN connections - particularly when a home has either a wireless base-station or a LAN with additional PC's, a typical situation. H. Business Continuity: Consider business continuity in any network hardware implementation. Power backup and hardware redundancy should be considered. 18

19 I. Subnets: Ideally, Covered Departments should be placed on private screened subnets which implement restrictions regarding traffic that is allowed to pass within the Covered Departments and to and from outside the Covered Departments subnet. Network traffic should be limited to business appropriate and approved non-work related traffic if possible. Restricting computers from direct internet access helps ensure the confidentiality of EPHI. J. SNMP: Where SNMP is used, the community strings must be defined as something other than the standard defaults of public, private and system and must be different from the passwords used to log in interactively. A keyed hash should be used where available (e.g., SNMPv2). Published: [July 2006] Revised: 19

20 UNIVERSITY OF WISCONSIN MILWAUKEE HIPAA SECURITY GUIDELINES 1. Guideline Name: Remote Access to EPHI 2. Purpose: The purpose of this policy is to define standards for connecting to the internal network or computing resource containing EPHI of any UWM Covered Department. This policy applies to all UWM employees, contractors, vendors and agents using a computer or workstation to connect to an internal Covered Department network or computing resource containing EPHI. Remote access implementations that are covered by this policy include, but are not limited to, dial-in modems, DSL, VPN, SSH, and cable modems. 3. References: A. HIPAA: The requirements in this guideline address the concerns found in the following HIPAA regulations: (a) (e) B. Other: The SANS Institute: 4. Remote Access Guidelines: A. Approval: Remote access to EPHI or Covered Department computers or networks must be specifically approved by the management of the Covered Department and configured by I&MT or other IT staff serving the Covered Department. Technical and administrative controls should be in place to ensure that any remote access to EPHI is specifically authorized by management. B. Access Control: Remote access must be restricted to individual authorized users for appropriate and authorized use only. Access controls must follow the University of Wisconsin Milwaukee s HIPAA Security Guidelines: Account Creation and Access Control Guideline. C. Log: Remote sessions should be logged and should include user name, time, data accessed, duration of session and unsuccessful login attempts. Such logs should be regularly reviewed. 20

21 D. Business Associate Agreements: Business Associate Agreements must be in place with contractors and other non-uwm entities prior to remote access consideration. E. Microsoft Windows Remote Desktop: 1. Remote Desktop should be configured to work only with the UWM VPN implementation. 2. This should not be the same VPN configuration available to the general public for encrypting wireless traffic. 3. Ensure that only authorized user accounts can remotely access individual systems by adding or removing them from the Remote Desktop Users Group in Windows or through Microsoft Active Directory. 4. A process must be in place for approval of such access and for removal of that access when an employee no longer requires this to perform the job. F. Encryption: Remote access mechanisms that transmit data via the Internet must secure all transmissions using a level of encryption sufficient to minimize the likelihood that an intercepted transmissions could be decrypted. G. Authentication: Remote access control must be enforced via password authentication or public/private keys with strong passphrases. Passwords must follow the University of Wisconsin - Milwaukee s HIPAA Security Guidelines: Password Management Guideline. H. Equipment: Equipment used to provide remote access to a UWM Covered Department, regardless of who owns the equipment, must meet the standards outlined in University of Wisconsin - Milwaukee s HIPAA Guidelines: Workstation Use and Workstation Security Guideline. I. Password Protection: At no time should any UWM employee provide his or her login or passwords to anyone, including family members. J. Network Isolation: Remote access connections should be isolated from other network activity. It is the responsibility of the user to ensure that their remote system is not connected to any other network at the same time, with the exception of personal networks that are under the complete control of the user. Configuration of a user s remote equipment for the purpose of split tunneling or dual homing is not permitted. 21

22 K. Non-UWM Accounts: UWM employees and contractors with remote access privileges to an internal UWM network must not use non-uwm accounts (i.e., Hotmail, Yahoo, AOL), or other external resources to conduct University business, thereby ensuring that official business is never confused with personal business. L. Configuration: The computer or resource being accessed remotely must be configured to limit inbound remote connections to subnet or IP range provided by the VPN implementation. M. Unauthorized Devices: At no time should EPHI be stored on an unapproved device or a personal home computer or device. Steps should be taken to minimize the likelihood that EPHI may be stored inadvertently or intentionally on unauthorized devices or media. N. Access: The remote access technologies chosen should allow for management of the Covered Department to allow access and authorized sharing in the workplace without, by default, granting such access from home or outside the workplace unless such access is specifically authorized. Published: [July 2006] Revised: 22

23 UNIVERSITY OF WISCONSIN MILWAUKEE HIPAA SECURITY GUIDELINES 1. Guideline Name: Password Management 2. Purpose: Two basic parts of Access Control are Identification and Authentication. Identification is the unique login ID or username assigned to a specific user. Authentication is a secret key which consists of something you know, have or are. A password is commonly used to provide this service. Passwords are an important aspect of computer security. They are the front line of protection for user accounts. A poorly chosen or compromised password may result in the compromise of a Covered Department's confidential information. As such, all Covered Department employees (including contractors and vendors with access to the Covered Department s systems) are responsible for taking the appropriate steps, as outlined below, to select and secure their passwords. 3. References: 1. HIPAA: The requirements in this guideline address concerns found in the following HIPAA regulations: (a)(1) (a)(4) (a)(5) (a) (d) 2. Other: The SANS Institute Security Policy Sample Password Policy: 4. Password Management Guidelines: A. Password Life: Passwords should be changed regularly. The change interval should be chosen by the management of a Covered Department, based on risk assessment. The suggested maximum password life is 6 months. B. History Files: The use of password history files is recommended to ensure passwords are not reused. C. Passwords must not be inserted into messages or other forms of electronic communication unless encrypted. Passwords should never be displayed in plain text. 23

24 D. Sharing: Passwords for accounts granted specifically to an individual should never be shared. In cases where password sharing is unavoidable, restricted accounts should be established with no access to EPHI. E. General Password Construction Guidelines: Characteristics of a strong password include the following: 1. It should contain both upper and lower case characters (e.g., a-z, A- Z); 2. It should contain digits (numbers) and other non-letter characters such as!@#$%^&*()_+ ~-=\`{}[]: ; <>?,./ ; 3. It should be at least 8 characters long; 4. It should not be a word in any language, slang, dialect, jargon, etc.; and 5. It should not be easily ascertained from research of publicly available information, such as names of family members, school names, addresses, etc. F. Password Management Guidelines: 1. If passwords need to be written down, they must be stored in a locked drawer or other locked area separate from the application or system that is being protected by the password. 2. Electronically stored passwords should be encrypted and stored in an application or area of an application designed for password storage. Access controls and passwords for such an application must meet the standards included in the University of Wisconsin - Milwaukee HIPAA Security Guidelines: Account Creation & Access Control. Methods and practices for storing passwords should be approved by a Covered Departments management and implemented by I&MT or other IT staff serving the Covered Department. 3. An Escrow Account of critical system and user passwords should be maintained in a secure environment as defined in part F, sections 1 and 2 of this document. 4. Users should never use the Remember Password feature of applications (e.g., Eudora, Outlook, Netscape Messenger, browsers). 24

25 5. If an account or password is suspected to have been compromised, staff should immediately report the incident to the Covered Department s management and change any potentially affected passwords. 6. Password cracking or guessing may be performed on a periodic or random basis by the management of a Covered Department or its delegates. If a password is guessed or cracked during one of these scans, the user will be required to change it. Published: [July 2006] Revised: 25

26 UNIVERSITY OF WISCONSIN MILWAUKEE HIPAA SECURITY GUIDELINES 1. Guideline: Portable Devices and Media 2. Purpose: The purpose of this document is to define standards for use of portable devices for storage and transmission of EPHI. A. Portable devices include but are not limited to the following: 1. Laptop/tablet/handheld computers; 2. Handheld computers (PDA s); and 3. Portable Storage Devices: a. External USB Hard Drives; b. USB Thumb drives; c. Ipods; and d. External CD Burners, Zip Drives, Floppy drives. B. Portable media includes but are not limited to the following: 1. CD s; 2. Floppy Disks; and 3. Zip Drives. Portable storage devices and media that contain EPHI must be subject to safeguards to protect the confidentiality of the data. This guideline outline the steps needed to ensure the proper use and administration of portable devices that contain EPHI. This guideline applies to all Covered Departments. 3. References: A. HIPAA: The requirements of this guideline address the concerns found in the following HIPAA regulations: (a)(1) (d)(1) 26

27 B. Other: The SANS Institute: 4. Portable Devices and Media Guidelines: A. Approval: All portable devices and media must be approved by the Covered Department for storage or transmission of EPHI. This includes all personally owned and UWM owned devices. B. Registered Users: Any portable device containing EPHI should be used only by the individual who has registered it with management of the Covered Department unless transfer or sharing was specifically approved. No portable device containing EPHI should be used by any individual outside the Covered Department. C. Authentication: Access to data on portable devices and media must be protected by the use of authentication such as a password. For details on password strength and password management, see the University of Wisconsin-Milwaukee s HIPAA Security Guidelines: Password Management Guideline. D. Encryption: Any portable device or media containing EPHI should protect the data using encryption. E. Wireless Transmission: Wireless data transmission to and from the portable device, including the syncing of PDAs, must be done via an encrypted connection. F. Theft: Any portable devices or media containing EPHI must be safeguarded from theft or loss. Devices and media must be secured in a locked drawer or cabinet or secured with a cable lock whenever possible. G. Marked for Return: All portable devices and media containing EPHI must be marked as confidential and indicate method of return if found. Any misplaced portable device must be immediately reported to the department administrating it. H. Visibility Restriction: All applicable safeguards detailed in University of Wisconsin Milwaukee s HIPAA Guidelines: Workstation Use and Security Guideline must be applied to portable devices. This includes restricting visibility of display in public areas. I. Back-Up: All EPHI contained on portable devices must be backed up periodically. 27

28 J. Synchronization: Portable devices are to be synchronized only to Covered Department approved computers. K. Disposal: Disposal of any portable device or media must follow University of Wisconsin Milwaukee HIPAA Guidelines: Workstation Use and Security Guidelines for Disposal of PHI. L. Minimum Use: Use of portable devices and media for storage and transmission of EPHI should minimized to the greatest extent possible while still allowing job functions to be fulfilled in order to ensure proper administrative control over EPHI storage, transmission and disposal. Published: [July 2006] Revised: 28

29 UNIVERSITY OF WISCONSIN MILWAUKEE HIPAA SECURITY GUIDELINES 1. Guideline Name: Server Security 2. Purpose: The purpose of these guidelines is to provide guidance and recommendations for the installation, configuration, and maintenance of the security of servers that contain or transmit EPHI. These practices are intended to reduce the risks to the confidentiality, integrity, and availability of EPHI. For the purposes of this document, a "server" is defined as any computer that is used to provide application, data or system services to users, other computers, or to applications. This guideline applies to all Covered Departments. 3. References: A. HIPAA: The requirements in this guideline address the concerns found in the following HIPAA regulations: B. Other Tripwire, Inc: NIST Computer Security Special Publications: 4. Server Security Guidelines: A. Installation and Configuration 1. Install operating system software according to manufacturer/ developer guidelines, including consideration of the following: a. Ensure the security of the original code. Use known original media and, if installing open source software, ensure security hatches match; and b. Ensure appropriate network isolation of the server while installing operating system, security patches and updates throughout the configuration process. 2. Limit the availability of unneeded services: 29

30 a. If the server is not used as an server, disable related services. b. If the server is not used to move files, disable file transferrelated services (e.g., FTP). Wherever possible, remove the software completely. 3. Install, monitor and maintain a host-based firewall on all servers. A firewall or alternate technology should provide the following services: a. The server should be on a subnet not accessible by the general public. IP addresses in this range should only be accessible with administrative authority from I&MT or other IT staff serving a Covered Department; b. Outside access to the server needs to be limited as much as possible. Packet filtering should be employed in the form of ACLs on networking equipment, or on a hardware firewall; c. Incoming packets should be explicitly denied unless explicitly allowed; and d. All inbound traffic should be denied unless an application has requested this service. A hardware or software firewall may fill this need. B. Access Control: Servers storing or transmitting EPHI should adhere to all applicable points in the University of Wisconsin Milwaukee s HIPPA Security Guidelines: Account Creation and Access Control Guideline and Password Management Guideline. In addition to adhering to these guidelines, the following should also be implemented: 1. Restrict the number of accounts and level of privilege to only those who need it to perform their job functions. a. Recommended review period: every six months or once a semester; b. Make appropriate updates and deletions as a result of staffing changes; and c. Ensure processes and mechanisms exist to quickly remove, modify and reassign accounts and privileges on servers. 2. Require authentication for access by individuals to the server using strong passwords. See University of Wisconsin 30

31 Milwaukee s HIPAA Security Guidelines: Password Management Guideline. 3. Require re-authentication after idle periods. Recommended time: 20 minutes. 4. Configure servers to deny logins after a limited number of failed attempts. Recommended number: 5 attempts. 5. Configure servers for secure remote administration by providing encrypted transmissions between the server and the remote administration workstation. 6. Restrict remote access to specific IP addresses and/or ranges. For remote access details, refer to the University of Wisconsin Milwaukee s HIPAA Security Guidelines: Remote Access Guideline. C. Securing Transmissions: 1. Implement secure data exchange protocols and controls. Whenever possible, restrict the use of insecure data exchange and insecure authentication. 2. Use Secure Socket Layer (SSL) to transmit EPHI and authentication over the web. SSL works by using private keys to encrypt data before it is transferred. SSL is often used to encrypt and transmit login credentials over the internet: a. For peer-to-peer transaction between two known parties, the use of a self-signed certificate is adequate. b. In dealing with the public in cases where a high level of public trust is needed, a trusted third party certificate may be a better choice. 3. Use SSH in place of Telnet connections. 4. Use the UWM VPN for any remote administration of the server. Remote administrative access to the server should be limited to a specific private subnet supplied by network operations for EPHI specifically. D. Operations: 1. Ensure accurate time stamping using Network Time protocol. See 31

32 2. Implement procedures and accountability for evaluating and applying operating system and application updates, hot fixes, and patches. a. Design a specific individual and an alternate to monitor for new patches and fixes; b. Join a mailing list to receive notification of patches and fixes; and c. Recommended monitoring frequency: daily. 3. Set up system logging capabilities and assign responsibility for periodic review of logs: a. Designate a specific individual and an alternate to review server system logs. Recommended review period: daily; and b. Enable system logging available on operating system. It is recommended that logs minimally include: restart and shutdown attempts; configuration changes, logon and logoff attempt failures; changes to user and group management; and changes to security policy. 4. How system logging is enabled and what system logs are available is highly dependent up the operating system used: a. Refer to operating system installation guides or Sans documents for details; b. Retain system logs for an adequate amount of time. Recommended minimum retention period: six years; and c. Ensure time and date are accurately configured on the server. 5. Implement procedures for performing periodic vulnerability scanning product, such as Nessus ( or scanning tools available from Microsoft for their operating system: a. Designate a specific individual and an alternate to review run scans. Recommended scanning and review period: quarterly; and b. Additional scans should be done for new vulnerabilities when such vulnerabilities are announced. 32

33 6. Perform periodic routine backups, develop recovery procedures and test occasionally. Note: these backup practices are meant as a means of providing disaster recovery, not as a means of providing records retention for archiving. a. Recommended back up frequency: Full weekly, incremental daily. b. Recommended retention: Full four weeks, incremental one week. c. Recommended testing frequency: annually. d. Store a copy of full backups offsite and update them weekly. e. Regularly test backup restoration processes at least annually. f. Backup media must be secured at all times in a locked area. Access must be limited to the least number of employees as possible. g. Backups stored offsite must be logged by the server administrator prior to transport. Backups must be in a locked box or other container for transport. h. Backups must be labeled with the date and marked confidential and indicate where they should be returned in case of loss. i. Backups containing EPHI should be encrypted if possible. 7. Business Continuity Planning: a. Document alternate processes for University services dependent on the server or servers in case of outage; b. Arrange for path of communication between server administrators/managers and those dependent on the services provided by the servers; and c. For further details, refer to the University of Wisconsin Milwaukee s HIPAA Security Guidelines: Contingency Planning Guideline. 33