HIPAA Security Compliance – System Administrator Reference Guide

This reference guide is designed for the system administrator of a computer system that stores electronic Protected Health Information (ePHI) and makes ePHI data accessible to multiple people.

Everyone who comes into contact with ePHI is required to take HIPAA security training. As a system administrator you will be asked to identify the system(s) for which you are responsible at the end of the training module. Subsequently you will be probably be asked to complete a web-based survey regarding these system(s). The questions in the survey are closely linked to the content of this reference guide.

If you would like more detailed information on any of the topics covered here, you can use the URL's listed at the end of this guide.

General

What is Electronic Protected Health Information?

It is any Protected Health Information (PHI) which is created, stored, transmitted, or received electronically. Protected Health Information (PHI) under HIPAA means any information that identifies an individual and relates to at least one of the following:

• The individual's past, present or future physical or mental health.
• The provision of health care to the individual.
• The past, present or future payment for health care.

Information is deemed to identify an individual if it includes either the individual's name or any other information that could enable someone to determine the individual's identity. Examples include:

• date of birth
• address
• phone number
• medical record number
• social security number

See the full list of identifying information that is protected under HIPAA.

The Security regulations take effect 21 April 2005.

The focus of the HIPAA security rule is to protect the 'confidentiality', 'integrity', and 'availability' of electronic Protected Health Information (ePHI) that Yale University covered components create, receive, maintain, or transmit.

• Confidentiality is the assurance that ePHI data is shared only among authorized persons or organizations.
• Integrity is the assurance that ePHI data is not changed unless an alteration is known, required, documented, validated and authoritatively approved. Most important to HIPAA, data integrity ensures that we can rely on data in making medical decisions. It is an assurance that the information is authentic and complete, and that the information can be relied upon to be sufficiently accurate for its purpose.
• Availability is the assurance that systems responsible for delivering, storing and processing critical ePHI data are accessible when needed, by those who need them under both routine and emergency circumstances.

The rule covers information stored on hard drives, removable or transportable digital memory media such as magnetic disk or USB flash drives as well as information being transported electronically visa the Internet, email or other means.

Administrative Access controls

Eliminate generic user level accounts

Compliance with HIPAA requires knowing the identity of everyone who uses your computer. Since systems record activity based on the username used to log on to the system it follows that each username should always correspond to a unique individual unless absolutely unavoidable. Regular user level access using generic accounts i.e. accounts available to more than one individual must be removed or disabled.

Restrict root access as much as possible

Some system level activities may require the use of the “administrator” or “root (superuser)” account and more than one person may need access to that account. Remember that someone with “administrator” or “root” access can do anything they want, including “covering the tracks” of any actions they take. It is absolutely essential that root access is restricted only to those who need that level of access. The system administrator must know who has root access to the system at all times, and must review that list from time to time. If someone's root access is no longer appropriate, the root access password must be changed in order to deny root access for that person. It is also appropriate to restrict the route by which root access is made e.g. only by physical presence at the console, only by “su” from an individual (i.e. non-generic) account etc. Other means for securing “administrator” or “root” access such as “secure card” or a biometric device is also appropriate and desirable.

Use strong passwords

Since the password is still the primary means of securing access to a computer account, it is essential that the password be “strong”. In general that means a password that is difficult to guess. A password should be at least 7 or 8 characters, and use a mixture of letters, numbers, and punctuation characters (if the system allows). Don't make a password impossible to remember so that it has to be written down somewhere. If you do not have control over the passwords of your users, consider communications to your users reminding them of good password security.

Use the central Netid/password credentials if possible

Consider using the University Netid/password credentials to authenticate access to your application for your users. The Netid/password combination for people is registered by Human Resources and has several advantages as an authentication mechanism.

1. Netid's are issued by the University giving an assurance that they are associated with a unique individual.
2. Since the Netid/password combination is the primary means of access to confidential HR information (W2, Health Benefit information etc), it is more likely that individuals will keep their password secure and will not share with anyone else.
3. There are standard mechanisms available to ensure that the password is not sent over the network during the authentication and is thus safe from “sniffing” or other means of unauthorized capture of data traveling over the network. For web applications, consider using the Central Authentication Service (CAS) to authenticate your users. For other types of logon, consider other methods of authentication that can use the Netid/password credentials securely (e.g. Kerberos V, Windows NTLM, RADIUS etc). Using the Netid/password combination for authentication assumes that your system can be configured for external authentication for your application. If your application is from an outside software vendor, make sure that you have explored the options for external authentication using the Netid/password combination.

Remove unused accounts

HIPAA requires the prompt termination of access to ePHI by those whose job function no longer requires access, or whose access requirement has changed. This is one of the more difficult areas of system administration. The University provides reports of those who have moved to a new department or left the University (Move/gone reports). It is important to investigate whether these reports could be used to optimize management of your accounts

Separate the functions of authorization and access control

Unless the system administrator is also the owner of the ePHI data, authorization for system access should be the responsibility of the data owner. Separate procedures for authorization and account creation should be carefully documented.

Physical access controls

Remember physical access means full access

Remember that if someone has physical access to your computer, it is only a matter of time before they have access to all the data on the computer. Inserting and then booting from a CD or a Floppy Disk may give access within minutes. Removing a hard disk and installing it in another computer though more time-consuming, will give access to the data unless the data is encrypted.

Keep physical access as restricted as practical

Because physical access generally means full access, it is essential to restrict physical access as much as possible. Physically locating the system in an ITS or ITS-Med data center ensures a high-level of physical access control and should be carefully considered. If location in a data center is not possible, any “above-threshold” system should be in a locked room. This may be a room with a keyed lock, or an electronic lock (keypad, badge reader etc).

Review physical access regularly, making use of “move/gone” reports

The system administrator must know who has access the the room at all times and must review the list of those having access periodically. If it is appropriate to remove someone’s access, the key must be recovered, or electronic access removed by whatever method is appropriate. University “Move/Gone” reports should be investigated as one method for managing physical access to computer systems

Consider privacy screens

CRT style monitors have always had a wide horizontal angle from which the screen could be viewed. As flat panel screens have been perfected, their angle of view has “improved”. In both cases a wide angle of view may permit data to be viewed inappropriately. If the display from which data on your system is viewed is under your control, consider installing privacy screens to limit inappropriate viewing.

Administrative procedures

Develop, document, implement and follow a regular backup plan

Since the components of computer systems fail from time to time, it is imperative to consider the possibility that component failure may lead to loss of data. Various technologies are available to mitigate this risk but all have associated costs and a risk/benefit analysis is essential. The use of RAID (particularly RAID levels 1, 0+1 and 5) and SAN technology can go a long way to mitigate component failure. However, hardware and/or software failure can lead to data corruption so it is usually essential to keep recent copies of critical data that can be restored in the event of data corruption. Thus a backup plan must be devised that takes into account all the types of failure that might occur and how these failures would be remediated. The plan must be written down, so that it can be understood by others. The plan must be followed diligently. The plan must also be tested to ensure that data that is backup up can be retrieved and restored when the need arises.

Use a different set of backup media each day of the week (or each day of two weeks) so as to rotate sets of backup media. Backups should be performed so that each new file appears on at least two backup sets if possible. Make full backups on a weekly, bi-weekly or monthly basis and periodically (quarterly) save a set of full backups for at least a year as catastrophic backups.

Consider the role that ITS and ITS-Med data backup services might play in your backup plan.

See references for a backup plan template.

Store backup media away from system and possibly off-site

A data backup plan is useless if the event causing the loss of data also causes loss of the backup data. You must decide whether keeping backup data in a fireproof cabinet locally is required and sufficient, or whether backup data need to be stored off-site.

Securely erase all media before discarding

HIPAA requires that you protect ePHI when you dispose of systems or media that may contain ePHI. Simply deleting files doesn't remove data, it merely changes pointers so that the data doesn't appear in the device directory. Even formatting a disk may not remove data but may simply reset the device's directory track. Procedures are available from ITS or ITS-Med that will securely erase data by writing over every part of a device that may contain data. Even a non-functional computer should have its disks securely erased or physically destroyed before disposal. You must consider all the physical ways that your ePHI might leave your system and take all practical steps to eliminate or minimize risks from media disposal.

Develop, document, and test a disaster response plan (DRP)

What will you do if disaster strikes? Fire and flood are not uncommon and computer systems are extremely vulnerable to both. Yale self-insures its equipment. Even if your business manager says “Go buy what you need”, is everything available for purchase today to rebuild your system? Does your system have legacy components or components developed in-house that could not be re-purchased? You must have a disaster response plan that answers these questions. The plan must be written down so that others can understand, comment and agree to it. You should devise a method for testing your disaster response plan in as realistic a scenario as possible. Find out about ITS and ITS-Med disaster response test initiatives and consider taking part.

See references for a DRP template.

Develop, document, implement and test an emergency mode operation (EMO) plan if needed

If disaster strikes and your system is out of commission, what are the implications of the time-scale of your disaster response plan? Is your operation of such criticality that an emergency mode operation plan is needed to bridge the gap until the disaster response plan has been fully implanted. Can your operation be hosted temporarily on another system at the University or do you need a contract with an outside agency during this Emergency mode operation phase and, if so, how will HIPAA requirements be maintained? You may need an emergency mode operation plan that answers these questions. The plan must be written down so that others can understand, comment and agree to the plan. If your system is highly critical it may be essential to test the plan to ensure that it can meet the need.

See references for a EMO template.

Develop, document, implement and test a “break glass” procedure for emergency data access

There may be occasions where emergency access to your system is needed by someone who does not have credentials but for whom access is nevertheless appropriate. This access might be needed at a user level, for example to clinical data where there is a clinical emergency. Alternatively, access might be needed at the system level for example to remediate a security incident. In these cases, giving access by sharing a password is not appropriate because it leaves an incorrect access and audit trail. A “break glass” procedure is appropriate whereby the user can obtain unique appropriate credentials by following a set procedure that includes complete documentation of who acquired the credentials, when, and for what detailed reason. In this way, a “correct” access and audit trail is created. You should create, document and test this “break glass” procedure.

See references for “break glass” procedure recommendations.

Register new and existing systems with ITS or ITS-Med

If network monitoring procedures alert Information Security staff to a problem with a computer on the network, that alert will almost certainly reference the affected system, or systems, by IP address. In order to contact the system owner, Information Security staff must have current contact information correlating network IP address with the owner of the system. Accurate registration information also allows ITS personnel to contact system owners when advance warning is available for application or system problems or security vulnerabilities. Notify Information Security if you have systems containing ePHI which is primary source and/or shared.

Consider a Business Associates agreement with your vendor

If there is a vendor who has access to your system for any reason and whose access could be used to view the ePHI, then you need a Business Associates agreement with that vendor.

Technical security controls

Don't run unnecessary services

Every service running on the system that is open for incoming network connections is a potential security vulnerability. Buffer overflow attacks against specific services have been the single most commonly exploited route for system compromise after email borne attacks. Use system management tools to see which ports are open on your system and the applications that are listening on those ports. Unnecessary services should be removed.

Implement antivirus software if it exists for your platform

Antivirus software has a library of definition files used by the antivirus application to identify files on the system that are viruses, or that have viruses embedded in them. Antivirus software operates in two modes: real-time file protection and file-scan mode. Real-time file protection is essential as it identifies infected files when they are created, modified or accessed. Full systems scans should also be used if real-time protection has been disabled for any period of time, and when antivirus software is initially installed. It is absolutely essential that the virus definitions be kept up to date. ITS and ITS-Med provide anti-virus software for the PC environment. The “managed” client is recommended for Windows computers on Yale's network as it allows new virus definitions to be effectively “pushed” to each computer to keep the virus definitions as up-to-date as possible. If not using the managed client, make certain that the system is configured to download new signatures at least once per day and to run a disk scan overnight. Real-time protection for all files and file types should be enabled with the exception that email inbox files should be excluded since a quarantine action is unnecessary and can be a major problem

Keep OS and application software patched

Operating system and application software patches should be applied as soon as possible. However, there is a trade-off to be made. Applying patches as soon as they are available carries the risk that the patches may be faulty or have unexpected consequences. On the other hand, delaying implementation until others have tested the patches may leave the system open to an actual exploitation of the vulnerability. One solution is to apply “critical” patches within 24-48 hours, and allow 1-2 weeks for testing “non-critical” patches. Computers running Windows 2000 or XP that are in the active directory (YSM and YSM “OU”s only) can have patches installed automatically via the SUS servers. ITS and ITS-Med have a goal of approving ”critical” patches within 48 hours. Make sure that you are subscribed to “Alerts” lists and services so that you are informed about Operating System and Application patches for your system. Both ITS and ITS-Med have listserves for system administrators that are used to disseminate information about vulnerabilities and patches. Unmanaged (independent) systems (desktops and servers) should be configured to download and install software updates and patches whenever possible.

Consider local intrusion detection

Software tools can be deployed locally that detect changes made to a computer system and provide alerts when unexpected changes occur. Probably the best known of these is “Tripwire”. Tripwire records “binary signatures” for system files along with file sizes, expected changes of size, etc and monitors these values frequently. Since computer intrusions inevitably involve modifying files, Tripwire is able to provide an alert almost immediately a system becomes compromised. Local intrusion detection is especially useful in systems whose system files do not change much.

Host-based intrusion detection/prevention and firewall functionality should be configured and enabled whenever possible. Note that Tripwire functionality (cryptographic check-summing and checking of critical system files) is contained in a number of commercial and non-commercial packages (such as ISS System Scanner Agent and Advanced Intrusion Detection Environment - AIDE). Additional host-based security software (with COPS-Computer Oracle Password System and Crack type functionality to perform internal vulnerability assessment and patch management/gap analysis) is also highly recommended. Also consider packages such as 'swatch' to automate logfile analysis to notify you (via pager/email/etc) of alerts.

Encrypt sensitive data that travels over the internet or over wireless connections

Data traveling entirely within Yale's networks has a security advantage in that the network wiring, closet electronics and router systems are installed, maintained and controlled by Data Network Operations. In recent years, most hubs have been replaced with switches almost eliminating the problem of “sniffing”. The opportunity for unauthorized copying of data as it travels on Yale's internal network is small. This is not true for data traveling on the Internet or over wireless connections. Although the probability of unauthorized capture of data on the internet seems low, it is wise (and sometimes required) to encrypt sensitive data traveling over the internet. For wireless networks, where data is broadcast wirelessly and anyone within range can intercept it, it is imperative to encrypt sensitive data. If it is possible to restrict access to your system to protocols that ensure encryption (SSH, SFTP, etc) then do so. Use secure protocols (SSH, SFTP) instead of Telnet, and FTP, if possible. However, be careful in configuring SSH as it can be used for tunneling other protocols.

Implement application time-outs if appropriate

One of the main goals of HIPAA is to prevent viewing of ePHI beyond the “business need to know”. An application left running on an unattended workstation may provide an easy way for an unauthorized individual to view ePHI. As a system administrator you may be able to improve the security of your system by implementing application time-outs. The trade-off is that you do not want to disconnect a user of your system who is in the middle of entering data but is distracted by some other activity e.g. answering the telephone, helping a colleague etc. Consider whether a time-out after 10-15 minutes of inactivity can be applied to your system without inconveniencing users.

Implement "https://" protocols for Web services if appropriate

If you provide web services, using the “https” protocol will provide several advantages in the area of security. First, the protocol ensures that that the traffic will be encrypted. Secondly, the appearance of the “locked padlock” in many browsers provides visual assurance that the session is secure. Thirdly, the host encryption certificate can be examined to help increase the confidence that the host site is genuine.

Network controls

Consider a host based software firewall

A software firewall is an application running on your system that controls network traffic. The simplest firewall is one that limits inbound connections to specific ports. For example, a system that provides web services only could have all connections other than to port 80 blocked. More complex software firewalls control which specific applications can accept connections from the network. More complex firewalls control outbound connections, an important feature which can prevent a compromised system from attempting to spread its compromise to other systems. Most software firewalls allow the designation of a “trusted” zone to apply less stringent rules than to systems on the internet. Windows XP service pack 2 enables a software firewall of medium functionality.

Non-windows systems include “firewall like” controls such as iptables (Unix and Linux) and ipf (MAC OSX) which have fairly advanced configuration options. Note also that SSH can be configured to restrict access to a few IP addresses as well as configured to restrict/limit account access.

Consider using a hardware firewall

A hardware firewall is an appliance placed between one or more systems and their connection to the network. All network packets traveling in both directions are intercepted by the firewall and passed or discarded based on the firewall rules. Modern firewalls are “stateful”, meaning that the decision to pass or reject an individual packet is usually based on the context of the connection to which the packet belongs. Special attention is paid to the initial handshake that establishes a TCP/IP connection and if the rules allow the connection, an entry is made in a state table which allows all future packets associated with the connection to pass until the connection is dropped, or times out. Hardware firewalls often allow almost unlimited flexibility in selecting what types of connections are to be allowed to and/or from other hosts on the network. Rules can specify individual hosts, individual subnets, who groups of subnets or any combination of these.

A related device which functions as a firewall is the so-called NAT box, the most common example of which is the “Linksys NAT SOHO” router. The device functions as a firewall because it uses IP masquerading to allow multiple devices to share a single IP address on the network. Because inbound connections have to be specifically directed to a particular host on the “inside” of the router, by default all inbound connections are blocked. The “Linksys NAT SOHO” router is an effective and inexpensive firewall for protecting a small number of systems that do not need complex firewall controls.

Consider the role of private IPs

By convention, three ranges of IP address are not routed on the internet. They are the class A subnet 10.0.0.0, the class B subnets 172.16.0.0 thru 172.31.0.0 and the class C network 192.168.0.0. DNO has allocated 172.21.0.0 and 172.23.0.0 for use by devices and printers at the University and routes these addresses throughout the university network. These addresses are called “private”, “internal”, “non-routed”, or “RFC1918” addresses. Registering a system with a private IP will mean that the system is “invisible” from the internet, thus providing some increased security. To communicate with the internet, a device with a private IP can make use of a network proxy server for web services, or can initiate a temporary VPN session for full connectivity. Inbound access from the internet to devices with private IPs is also possible by establishing a VPN session. If you want to use a private IP that is routed at Yale (and have connectivity to the rest of the Yale campus network) you can specify that option when making a request for a network connection.

Develop and document a secure plan for vendor access if required

If you are dependant on your software vendor for maintenance or support of your system, the vendor will probably want administrative access to your system. It is imperative that this access meet or exceed the security you will establish for your regular users. If a single person supports your system from the vendor, one option is to register that person as an “unpaid consultant” with HR which will allow a netid to be allocated. This netid can then be used for VPN access to the university network and an account can be created on your system using that netid. Alternatively, the YSM Information Security Office can create an account in the Cisco Access Control System that can be used for VPN access without creating a netid. A more complex case occurs when multiple personnel from your vendor need access to your system. A point to point VPN connection, implemented by ITS or ITS-Med may be appropriate in that case.

Eliminate modem access if possible

Unless completely unavoidable, you should not use a dial-in modem to provide access to your system. Even if you provide logon security for a modem connection, the connection itself is not monitored. Network monitoring (using e.g. “Snort” log analysis) is one of the main methods by which Information Security staff can become aware of compromised systems. Also network connected systems are scanned periodically for vulnerabilities and/or weak passwords. Access to your system via modem cannot take advantage of these forms of security protection. If there is no other option than to use a dial-in modem, the modem should normally be powered down and only enabled specifically for vendor access and even then for the shortest possible time. Any dial-in modem access must be registered with, and approved by, ITS or ITS-Med.

System logs

Keep records of successful and failed logon activity

Auditing and tracking the use of your system is an important component of HIPAA security. At a minimum you should keep time-stamped records of successful and failed logons to your system. Make sure that the username is recorded and, if possible, the IP address of the system making the connection. Consider alarms and/or access lockouts for logon failure attempts that reach a pre-determined threshold. Windows systems registered in the active directory have group policy set to enable logging of both successful and failed logon attempts in the system event log.

You will need to document your logging procedure and log retention periods in a 'privacy policy' which you keep online (and posted if possible). It is essential to be consistent. Notify the Information Security Office, the HIPAA privacy Office and/or the Yale General Counsel if anyone requests access to your logs, or the data in them, including any requests from law enforcement.

Consider detailed access logging if supported by software

Some application software has the ability to track database use down to the record access level. For example, the application might be able to provide a time-stamped log of access to ePHI records with detail of who the record belongs to, what component of the application accessed the record, who the user was, and whether the record was changed or merely accessed. There is a trade-off to be made if keeping such logs causes a degradation of performance or produces so much data that extra resources are required just to store the data. If such logs are possible, you will need to decide whether they will be examined periodically to identify problems, or whether the logs should just be archived in case they are needed for an investigation at some future time. You should implement this type of logging if reasonably possible.

System audits

Check periodically that access and use is appropriate

At least once per year, you should examine your list of who has access to your system down to the application level if appropriate. You will need to devise a process to verify that appropriate access is being granted. University “move/gone” reports may help with this. Remember that you are responsible for who has access to your system and you may need to survey your users and have them verify that their access is appropriate.

Periodically examine and verify the efficacy of security measures

At least once per year, as a separate exercise, you should review the security measures that you have in place paying particular attention to things that may have changed. Are you using the latest versions of the operating system and the application software and are both fully patched? Have you added extra services to your system or enabled access from new network locations? Consider requesting a full system scan from the network side by Information Security Office staff.

Recognize system compromise

Familiarize yourself with the system commands and tools that can give you an early indication that your system has been compromised. Don't rely on Information Security to detect that a problem with your system. The earlier that you can detect that your system has been compromised, the greater the chance that you can lessen the damage and lower the risks associated with exposure, corruption of the system, or data loss of your system.

Look for signs of problems in the following areas:

• Performance problems. Learn your systems normal pattern of activity and be suspicious if cpu use, network traffic, memory utilization, or network utilization increases dramatically. Unexpected rebooting is a suspicious sign once hardware problems have been eliminated.
• Additional processes running. Be familiar with the names of processes that should be running. Be suspicious of any new processes especially if their names are peculiar or very similar to normal processes
• Unexpected ports open. Make a note of the TCP ports that your system has open after you shut down the applications that you know about. Be on the lookout for any new open ports and convince yourself that the processes that have these ports open are legitimate.
• Unexpected user log entries. Be on the lookout for unexpected users especially if they correspond to accounts with administrator or root access.
• Changes in logfiles. Be on the lookout for logfiles that are suddenly missing, empty, or have unusual entries.
• Changes to system files. Most systems have so many files that this may be almost impossible to do manually. Consider an automated process that checks for the appearance of new files and/or directories, especially if your system doesn't change much from day to day.

Do not hesitate to contact your Information Security Office if you suspect that your system has been compromised.

Information Security Offices

Consult with the local information security office on security issues

A primary function of the Information Security Offices ITSISO and ISO-Med is to consult and advise individual system administrators. The Information Security Offices also have a primary role in ensuring that the institution is compliant with HIPAA. Develop a working relationship with your ISO and jointly develop a plan for HIPAA compliance. Make use of the ISO web sites.

Report security incidents to your local information security office

Report all security incidents to your information security office. Even if you are certain that ePHI was not exposed by the incident, policies require that you report the incident. Reporting the incident also helps Information Security build a picture of ongoing events that may be affecting the wider community.

References

• hipaa.yale.edu || policies
• ITS-Med Information Security: web site || contact information
• ITS Information Security: web site || contact information
• Contingency Plan (includes Backup; EMO; DRP) template (Mirosoft Word)
• Break Glass Procedure: Granting Emergency Access to Critical ePHI Systems
• Criticality & Recovery Preparedness

Full List of Identifiers

Data are "individually identifiable" if they include any of the 18 types of identifiers, listed below, for an individual or for the individual's employer or family member, or if the provider or researcher is aware that the information could be used, either alone or in combination with other information, to identify an individual:

• Name
• Address (all geographic subdivisions smaller than state, including street address, city, county, ZIP code)
• All elements (except years) of dates related to an individual (including birth date, admission date, discharge date, date of death and exact age if over 89)
• Telephone numbers
• FAX number
• E-mail address
• Social Security number
• Medical record number
• Health plan beneficiary number
• Account number
• Certificate/license number
• Any vehicle or other device serial number
• Device identifiers or serial numbers
• Web URL
• Internet Protocol (IP) address numbers
• Finger or voice prints
• Photographic images
• Any other characteristic that could uniquely identify the individual

Instead of removing the data, sometimes making the information more general is sufficient for de-identification; for example, replacing birth date with an age range.