MEETING HIPAA/HITECH DATA ACCESS AND PASSWORD REQUIREMENTS IN THE WINDOWS HEALTHCARE ENTERPRISE

Transcription

1 Specops Software presents: MEETING HIPAA/HITECH DATA ACCESS AND PASSWORD REQUIREMENTS IN THE WINDOWS HEALTHCARE ENTERPRISE By Derek Melber, MCSE, MVP

2 Meeting HIPAA/HITECH Data Access and Password Requirements In The Windows Healthcare Enterprise... 3 Core Security Model... 3 Data Security...4 Weak Link in Core Security Model...4 HIPAA/HITECH Password Requirements... 5 Password Attacks...6 Brute Force Attack... 7 Rainbow Tables... 7 Dictionary Attacks... 8 Attacks Are Imminent... 8 Developing Strong and Secure Passwords...9 Windows Default Password Requirements...9 Windows Server 2008 Fine-Grained Password Policies...9 Solving Password Compliance with Group Policy Extensions Solving Self-Service Password Reset for Users About the Author Specops Software U.S.A Inc 2

3 Meeting HIPAA/HITECH Data Access and Password Requirements In The Windows Healthcare Enterprise Securing IT assets is paramount for most healthcare organizations. Computing assets might be hardware (desktops, servers, printers), software, and data. Hardware is typically protected by physical controls and written policies. Software is hard to steal, as most software is so complex to install it takes more than just an.exe to obtain the application. However, one of the most important assets that must be protected is data. Data encompasses any digital file that is stored on a computer. Files encompass all types of data, which might include: Databases Spreadsheets Documents Executables Drivers Configurations Security settings At the heart of securing data in a Windows environment is the core security model. This model starts with the authentication process and ends with the user attempting to access, typically remotely, the data which is stored on a computer. It is this security model that must be understood to secure the data on your networks. Once the security model is understood, it is then that the healthcare organizations can address the most essential aspect of protecting assets, which is the delineation of users and their risk. All employees with access to electronic protected health information (ephi) need additional security controls in place to ensure confidentiality of this information as directed in the HIPAA and HITECH acts. These employees include IT administrators, helpdesk personnel, doctors, nurses, and any other employees that access ephi data. Core Security Model The core security model for Windows and Active Directory is initiated by a user attempting to logon to the network. This logon process is familiar to all of us, as this is how we access our home and office computers. We must input a username and password in order to access the computer we are sitting at. In a corporate environment, when we logon we must also select which domain we belong to. This is typically shown in the logon screen and our default domain is typically selected for us. After we insert our username, password, and select our domain, we send this information to a domain controller for that domain. The domain controller receives the request and then proceeds to authenticate the user. The authentication process is controlled by an authentication protocol. For Windows, the authentication protocol of choice is Kerberos, but NTLMv2 might also be used. (NTLM and LM are also supported by Microsoft, but are not desired due to their poor security) Specops Software U.S.A Inc 3

4 The domain controller takes the username and password and compares them to the Active Directory database to ensure the password matches the username. If the username and password are correct, the domain controller returns an authentication token to the user. This authentication token contains the following information: User Security Identifier (SID) Domain group SIDs User Rights (Privileges) for the domain controllers Data Security When data is placed on a Windows computer it is placed on NTFS volumes, which is the Microsoft file system. NTFS not only provides a platform for storing the data, but also provides the security to protect the data. NTFS security consists of an Access Control List (ACL), which contains accounts and their permissions. An account on the ACL could be a user, group, or computer. Permissions range from Read, Write, Delete, Full Control, etc. In order for a user to access data, they must have access to the data via the ACL. Since the ACL contains a list of user and group names, the user can be listed on the ACL via one of these accounts. Although the interface shows the friendly name for the account, NTFS stores the SID for the account along with the data. When the user attempts to access the data, their authentication token is compared to the ACL to determine the access. If the SID(s) from the token are on the ACL, the user will receive the permissions based on the least restrictive accumulation of permissions from all matching SIDs. If there is no match of SID(s) from the token to the ACL, the user is not granted any permissions or access to the data. Weak Link in Core Security Model If all of the parts of the security model and data security are evaluated, there are not that many parts to consider. Username Password Domain name SIDs ACL Authentication protocol Permissions Of these parts, the aspects that are variables are username, password, and domain name. The domain name is usually not a security aspect, but is rather just a name that is associated with the corporation or entity in some way Specops Software U.S.A Inc 4

5 The username is an important aspect of the security model, but in many instances follows the same naming convention for every user in the company. So, if John Doe has a logon with username jdoe, then all other usernames would be known if the same naming convention is used for all other users. Also, most companies use the logon name for the user as their account, so the logon names are well known and not used as a key aspect for security. That leaves the password as the key security part for all logon and data access. If the password is blank, a common password (Pa$$word for example), weak, short, or anything that is easily discovered, nearly any attacker can access data on the network. It is this reason why so many compliance regulations are putting effort into making the user password more secure and forcing the restrictions on how long the password can be valid. If the password in the security model is made to be strong, long, hard to guess, and hard to crack, then the core security model is much more effective. The HIPAA/HITECH security and privacy rules clearly state that employees that have access to ephi information must be addressed with higher security measures than those that don t. These users are clearly a higher risk and have access to more sensitive data. The only way to increase the security of these users in comparison to other users on the network is to increase their password complexity requirements. This can be done on a tiered structure, as these users have more access and more risk associated with the ephi data. An example might be IT having a 20+ character password, doctors and nurses having a 15 character password, and all other employees having an 8 character password. HIPAA/HITECH Password Requirements HIPAA (The Health Insurance Portability and Accessibility Act) was first implemented in 1996 to protect data controlled by healthcare agencies. HIPAA is designed to help protect protected healthcare information (PHI) by establishing rules and regulations on how the data is stored, accessed, and protected. The original HIPAA regulations do not have explicit content requirements and restrictions for user passwords, however they are strongly implied by a strong emphasis on the storage of and access control to ephi. Section (a)(5)(ii)D states that Procedures for creating, changing and safeguarding passwords must be established. Section (a) states (a) Standard: Access control. Implement technical policies and procedures for electronic information systems that maintain ephi to allow access only to those persons or software programs that have appropriately granted access rights. The new healthcare act, HITECH (Health Information Technology for Economic and Clinical Health Act), is not so lenient to data breaches and unauthorized disclosure of health information when it was released in February The HITECH act clarifies and supplements HIPPA requirements and raises the financial penalties charged to healthcare organizations that violate the HIPAA Privacy and Security rules. The net result is that users that have access to ephi must have higher security controls in comparison to those that don t have that access. This can easily be accomplished as we will show by assigning more complex passwords to higher risk user groups Specops Software U.S.A Inc 5

6 The best practices around passwords are to establish passwords to meet these HIPAA/HITECH requirements that would include at a minimum: Minimum 8 character password length The password must use multiple password characters (uppercase, lowercase, numeric, symbols, etc.) The user will be forced to change the password on a regular interval The password cannot contain words from the dictionary, proper names, logon names, or usernames Additional procedures must be implemented that secure the management of passwords (creation, changing, and safeguarding of passwords) Users should have a secure self-service password changing interface to protect password exchanges Users should be forced to provide unique information to change their password (favorite color, mother maiden name, high school mascot, etc.) Password Attacks There are many common attacks that pose a threat to a user password. Historically, many of the threats have been negated by technology that Microsoft implements in newer operating systems. For example, the ability to delete the local security accounts manager (SAM) only to have a new SAM created with a blank password for the Administrator account is no longer valid. However, there are still many attacks that are valid against a Windows user password. These attacks have been around for a long time and have matured, making some of them highly effective Specops Software U.S.A Inc 6

7 Brute Force Attack The brute force attack on a password is not all that powerful against a good, strong, long password. However, passwords for many organizations do not meet even the worst guidelines, so they are susceptible to a brute force attack. In essence, a brute force attack is when a computer application takes all possible permutations of the character set (A-Z, a-z, 0-9, symbols) and generates hashes from the options. Most password attack applications (L0phtCrack, Cain and Able, etc) allow you to pick the number of characters in the password, for example 5 to 10 characters, as well as the character set. The more restrictive the options selected, the less time it takes to come up with all of the password hashes. After the password hashes are generated, they are compared to the actual acquired password hashes. If there is a match, the application knows the password. If there is not a match, the original password was either out of the range of the password length or contained a password character that was not included in the character set. Brute force attacks take a long time, which is why they are not all that valid. Rainbow Tables Brute force attacks are the foundation for rainbow tables. Rainbow tables are nothing more than stored brute force attack generated hashes. Instead of generating the hash every time an attack is performed, the rainbow table just does a hash lookup and compare, which takes about 1/10th the time of a brute force attack. Most password attack applications provide the ability to include a rainbow table and then perform an attack to use the table. Rainbow tables can either be downloaded from the Internet or self generated from Rainbow Table Generators, also available for free from the Internet. There is one inherent issue with Rainbow Tables, they get large in size. As the number of characters in the password increases, so does the table. The storage of the hashes does not linearly increase with the number of characters, rather, it increases exponentially. It is this large size and portability that makes Rainbow Tables break down in their ability to attack more complex passwords. For example, here are the sizes of the Rainbow Tables for the following character sets against the NTLM hash: Character Set Numeric Lower case alpha Lower case alpha - numeric Upper & Lower case alpha - numeric Size of Table 8.75 GB 28 GB 64 GB 80 GB Studies have proven that if you can use a password, using all four character types, of length greater than 15 or so characters, that the Rainbow Table sizes get too large to be useful. (Reference Specops Software U.S.A Inc 7

8 Dictionary Attacks A dictionary attack is not all that different from the two attacks above. Instead of a random character set, the dictionary attack uses predefined character configurations to generate hashes that are compared to acquired password hashes. The only caveat is that the dictionary might not be the Webster s Dictionary; rather it is an attack dictionary. An attack dictionary will contain normal words, such as hospital, plane, world, etc, but it will also contain character configurations that are similar to these words, such as: H05pita1 P1@n3 W0r1D So, using character replacements for standard words is not a good password alternative. Although they are hard to remember by a human, they are just documented in a word list and used to attack passwords. All of the password attack applications have the ability to use a dictionary list. Dictionary lists can be self generated, downloaded from the Internet, or a combination of the two. Attacks Are Imminent If you feel that password attacks are not real, not occurring every day, or not successful, then hopefully this will change your mind. Consider that the majority of all attacks to your computers occur within your organization. This eliminates that issue of malware, viruses, and Internet attacks as the major attack threat. If the attacks are coming from within your organization, it is coming from a user within the domain. That user knows the domain name, all the usernames, and has a computer that is associated with the domain that they work on every day. The only missing piece for an internal attacker is the password. A recent study and report ( illustrates these points clearly. First, the report indicates that 99.9% of all data loss was from servers, which indicates that the data on the servers were not secure. Looking back at our discussion of data access, the weakest link is the password. The report also indicates that breaches occur due to stale and weak passwords. A recent SQL attack was to a server that has the Administrator password still password. Good password policies would have negated this and stopped the attack. In other situations, the attack might be due to a lost laptop. This story, search_method=all, clearly indicates that a weak password is no defense against a lost laptop. With the laptop in the hands of an attacker, all password hashes can be obtained and the laptop compromised. Only a secure password would make the laptop extremely difficult to attack Specops Software U.S.A Inc 8

9 Developing Strong and Secure Passwords With the research and analysis that has been done over the years with regards to passwords, the outcome is that passwords can be protected with the right policies in place. The policies must enforce that passwords meet certain criteria, to protect against hackers and their tools. Strong and secure passwords should meet the following criteria: Configure different password policies in the same Active Directory domain (IE. IT, sales, and executives each have a different password policy) Not be in any dictionary list Be well over 15 characters, 20 is a good length Require all four types of characters in the password Not include the user account name or logon name Be in form of a pass phrase, such as I wish I owned a Porsche 930 Turbo. Don t allow incremental passwords Password changed often Passwords changes should be through a secure self-service method Windows Default Password Requirements Starting with a Windows Active Directory Server 2003 domain, Microsoft now forces user account passwords to contain at least some characters and not be blank. Windows passwords must meet a baseline of password security settings before they can be established or reset. There are 5 essential password settings that can be set, all of which are pre-configured for the latest Windows environments: Password Setting Minimum password length Password complexity Minimum password age Maximum password age Password history Default Configuration 7 characters Enabled 1 day 42 days 24 passwords For Windows Server 2000 and 2003 Active Directory domains, there can only be one password policy for all user accounts in the domain. This limitation means that standard users and administrators will be bound by the same password settings, even if one set of users should have a more stringent password policy. Windows Server 2008 Fine-Grained Password Policies If you have an Active Directory domain that only contains Windows Server 2008 domain controllers, you have the capability of configuring multiple password policies in the same domain. This capability is not implemented through Group Policy, like it has been in the past; rather it is implemented by adding new Active Directory 2010 Specops Software U.S.A Inc 9

10 objects via ADSIEdit. The same password policy setting options are available, but now IT administrators can have a password policy that is stricter than the password policy that controls standard users. The configuration of fine-grained password policies is done using ADSIEdit or some other Windows LDAP compliant tool. This requires knowledge of Active Directory objects, types, and input format. Figure 1 illustrates one of the entries that are required for the configuration of a fine-grained password policy using ADSIEdit. Figure 1. Fine Grained Password Policies for Windows Server 2008 are configured using ADSIEdit by default. Although the new fine-grained password policies provide multiple password policies in the same domain (as long as all domain controllers are Windows Server 2008), they still don t provide the granular control required to meet HIPAA/HITECH password requirements especially for users with access to ephi. Solving Password Compliance with Group Policy Extensions Unfortunately, the password policy settings in Windows 2000, 2003, and even 2008 don t come close to solving these password requirements that HIPAA/HITECH require. But, Group Policy can still be leveraged by extending it to incorporate new and more powerful password policy settings. The most efficient and effective solution to extending Group Policy and the enforcement of strong and secure password policies can be accomplished by Specops Password Policy, which provides the following basic features of a strong and secure password: Configure different password policies in the same Active Directory domain (IE. IT, sales, and executives each have a different password policy) Include a dictionary list so users can t use these words Force password length greater than 15 characters Require all four types of characters in the password Require at least a, x, y, and z number of characters from each character type Not include the user account name or logon name Don t allow incremental passwords Many more 2010 Specops Software U.S.A Inc 10

11 Specops Password Policy works with all versions of Active Directory, all Windows server versions, and all Windows desktop versions. It is a simple Group Policy extension that provides the most granular control over passwords possible. Solving Self-Service Password Reset for Users The new HIPAA/HITECH requirements clearly indicate that users need to be able to reset their own passwords. This is a good security measure and one that all companies should implement. The requirement also indicates that the user must input unique answers to questions that only the user would know. Again, this is an excellent security measure. These issues are solved by innovative technology like Specops Password Reset. Password Reset is configured using Group Policy and provides the end user with a Web-based interface to control the resetting of their password. The ability to reset the password is secured by the end user enrolling in the service by answering unique and private questions, then communicating with an encrypted interface to answer the questions and reset the password. High risk user groups can be further secured by using one use verification codes sent to the user s mobile phone or handheld device. Password Reset will greatly reduce the administrative overhead that comes with routine IT staff helping end users with resetting their passwords. Password Reset will also increase security of data by eliminating the IT and Helpdesk staff from ever knowing the end user password. About the Author Derek Melber, MCSE, MVP, is an independent consultant and speaker, as well as author of many IT books. Derek educates and evangelizes Microsoft technology, focusing on Active Directory, Group Policy, Security, and desktop management. Derek is President and CTO of BrainCore.Net. As one of only 8 MVPs in the world on Group Policy, Derek s company is often called upon to develop end-to-end solutions regarding Group Policy and security for companies. Derek is one of only a few in the industry that has a deep knowledge of Group Policy, and Group Policy Preferences. Derek is the author of The Group Policy Resource Kit by Microsoft Press and over 10 other IT books. Derek is a contributing editor for WindowSecurity.com, RIAG Journal, IT Audit newsletter, and various other publications Specops Software U.S.A Inc 11