October 23, 2017

Wendt, Eric

CSOL 510

10/23/2017

2017Protecting Insuracare PHI

Executive Summary

The healthcare industry is perhaps the most targeted industry for cyber-attacks. In the last few years, the healthcare sector has been the most targeted sector for cybercriminals. The Breach Level Index, for example, a bi-yearly report on cyber-attacks, found that the healthcare industry was the hardest hit sector in the first half of 2017, experiencing 228 breaches, or 25 percent of the total number of data breaches in the United States, resulting in approximately 31 million stolen records (Gemalto, 2017). Given that the healthcare industry has the highest per-record cost in a data breach—estimated at an average of $380 per record—that is a staggering financial loss (HIPAA, 2017).

Figure 1: (Gemalto, 2017)

And that’s just data breaches. Consider ransomware attacks. According to a recent report in Healthcare Dive the healthcare industry was the victim of 88 percent of all ransomware attacks in the United States in 2016 (Mulero, 2017). One report found that a staggering 72% of all health care malware attacks in 2016 were ransomware. DDoS, or Distributed Denial of Service attacks against the healthcare sector increased by 13 percent in 2016, and are predicted to increase (Kim Cohen, 2017). The adversaries of the healthcare industry range from lone attackers looking for private health and identity information to sell on the Darknet, to State-sponsored hackers.

Attackers can take advantage of vulnerabilities found in the implementation of many system components, including operating systems, application software, and the system networks. Thus, to secure a system against threats, security must be placed strategically throughout the system architecture, for example in several of the (OSI or TCP\IP) network layers (Polk, Kerry, & Chokhani, 2014).

The threats are serious and increasing yearly, and the cost of non-compliance with HIPAA is high. HIPAA penalties for noncompliance or negligence range from $100 to $50,000 per violation or per patient record, with an annual maximum fine per violation of $1.5 million (Brown, 2014). Not only are the

1

penalties financially prohibitive, but HIPAA Privacy Rules are mandated by law and violation can even result in jail time.

As the pie chart to the left indicates, the exposure of Private Health Information (PHI) can occur in many different ways, from losses, to theft, to unauthorized disclosure. All these exposures can be mitigated by security controls or training. Some solutions, such as access control in the form of name badges or man traps, can be accomplished outside the IT department. Cybersecurity solutions, however, are the domain of the IT department.

The IT department plays a critical role in protecting PHI. Fortunately, HIPAA provides very clear guidelines for the

protection of PHI. Where these guidelines must be technical in nature—for example, where they must require a specific level of encryption or a PKI standard secure enough to protect PHI—HIPAA defers to the National Institute of Standards and Technology (NIST) (HHS, 2016). NIST Special Publication 800-66, currently in its second revision, defines these standards. All our recommendations either satisfy or exceed these NIST standards.

In this report, we provide recommendations for cryptographic implementations. As one cybersecurity expert writes, “Security is more than encryption, of course. But encryption is a critical component of security,” so we will give cryptography special consideration here (Schneier, 2016) .

Our recommended cryptographic implementations are as follows:

Cryptographic Algorithm: AES-256-bit encryption in CBC mode. Hashes: SHA-256 with HMAC message authentication Key Distribution Protocol: Kerberos 5 Authentication Protocol: Kerberos 5 Public Key Infrastructure (PKI): Verisign Security Controls: Endpoint Security, IDS/IPS

Each of these components are described in more detail below.

Encryption

Cryptographic algorithms primarily provide confidentiality. This is the reason that using an encryption protocol is so important. As we mention above, HIPAA, which defers to NIST for its technical security recommendations, recommends at least a 256-bit encryption, such as AES-256 (Scholl, et al., 2008). To enforce HIPAA confidential/privacy policy, we recommend following NIST standards and advocate implementing 256-bit AES (Advanced Encryption Standard) encryption in CBC-mode. It is well

2

Figure 2: (Thu Pam, 2011)

demonstrated that longer keys provide more security, and 256 bits is considered long enough to provide security against most attacks. As one writer put it, “the time required to crack an encryption algorithm is directly related to the length of the key used to secure the communication” (Larson, 2014). Thus, we recommend using the highest key-length available in AES, which is 256-bit. The length of the key also determines how long you will be able to use it before it is no longer secure. According to researchers, AES 256 could be viable for the next 30 years (Di Mauro, 2015).

Cipher Block Chaining provides an additional level of security. Basically, in cipher block chaining, each plaintext block is XORed with the immediately previous ciphertext block, and then encrypted. (http://searchsecurity.techtarget.com/definition/cipher-block-chaining).

Hashes

Hashes are meant to provide some guarantee of integrity. The do not provide confidentiality or authenticity. HIPAA requires the use of a hashing function to ensure the authenticity of PHI. Per NIST recommendations, we recommend using SHA-256 with HMAC message authentication (Scholl, et al., 2008). SHA-256 (or above) is recommended by NIST for situations where security is vital (NIST, 2017). NIST encourages application and protocol designers to implement SHA-256 at a minimum for any applications of hash functions requiring interoperability (NIST, 2017).

We recommend using an HMAC with SHA-256 because it adds an additional level of security. A MAC is a signature based on a secret key that provides assurance like public-key cryptography that the hashed data was produced by the person in possession of the private key (Krawczyk, Bellare, & Canetti, 1997). A MAC can be used in combination with any cryptographic hash function such as SHA-256 (Krawczyk, Bellare, & Canetti, 1997). HMAC is a specific kind of MAC that is a “random mapping with keys and messages as input” (Ferguson, Schneier, & Kohno, 2010). Because of this design, HMAC is more resistant to attacks such as collision attacks and key recovery attacks.

Key Distribution Protocol

Key Distribution Protocols add an important layer of confidentiality and authenticity. Kerberos has a number of benefits as a key distribution protocol, including single sign-on, so that authenticated users do not receive constant authentication challenges (Kerberos Consortium, 2008). It is also an industry standard, and although not specifically recommended by NIST for the protection of Protected Health Information (PHI) under HIPAA, it does meet NIST requirements since Kerberos 5 (the recommended version) uses NIST approved AES (128 or 256-bit) encryption (Microsoft, 2003).

It is important to note that Kerberos 4 is not recommended because of its use the DES algorithm, which NIST no longer considers secure and which is not recommended by NIST for the securing of PHI under HIPAA. For this reason, it is important to only deploy Kerberos 5 on our servers.

Finally, a security control that is part of Kerberos 5 and helps administer key distribution protocols, is the centralized key distribution center or KDC. The KDC is installed as part of the Windows Domain Controller and performs two important service functions: the Authentication Service (AS) and the Ticket-Granting Service (TGS), which we discuss below (Walla, 2000).

3

Authentication Protocol

The primary design goal of Kerberos is to eliminate the transmission of unencrypted passwords across the network. If used properly, Kerberos can reduce the threat that packet sniffers would otherwise pose on a network (redhat, 2017). Kerberos can also assist with Single Sign-On, since Kerberos can manage credentials across the domain forest. Kerberos also enables “mutual authentication,” meaning that parties at either end of a connection can verify that the party on the other end of the connection is who they claim to be (Microsoft, 2012).

There are also several Kerberos extensions available, such as the LDAP extension, which allows for the authentication of remote users (mediawiki, 2016).

The KDC, introduced above, has access to the Active Directory user account information and once a user is authenticated the user is granted a “Ticket to Get Tickets” (TGT) that is valid for the local domain (Walla, 2000). The user is then sent a TGT encrypted with a key that only the Ticket Granting Service (TGS) can decrypt, as well as a session key encrypted with the user's password hash, which will authenticate the user in all future communications with the KDC. Since the AS and TGS functions are separate within the KDC. This permits the user to use the TGT obtained from an AS in his domain to obtain service tickets from a TGS in other domains. This is accomplished through referral tickets.

Note: When setting up Kerberos in a production environment, it is best to have multiple slave KDCs alongside a master KDC. This helps ensure that the “Kerberized” services are continually available to clients (MIT, 2017).

4

Public Key Infrastructure (PKI)

The PKI environment is made up of five components:

Certification Authority (CA) -- serves as the “root of trust” that authenticates the identity of users and devices on the network.

Registration Authority (RA) -- is certified by a root CA to issue certificates for uses that are permitted by the CA. The RA is typically called a subordinate CA.

Certificate Database -- saves certificate requests as well as issued and revoked certificates from the RA or CA.

Certificate Store -- saves issued certificates and pending or rejected certificate requests from local devices.

Key Archival Server -- saves encrypted private keys in the certificate database for recovery purposes in case the Certificate Database is lost or damaged (Lawton, 2015).

PKI will be applied to a server that has Windows Server installed. The server should serve as the Domain Controller and be configured with Active Directory.

We recommend using Verisign, which is owned by Symantec, and uses 256-bit encryption. Verisign is currently one of the most trusted Certificate Authorities (CA’s) on the Internet (Sumastre, 2013). To create the private keys using Verisign we download the CA Root Certificate package from the Verisign website and run the code. The code uses OpenSSL.

Figure 3: A Diagram of how PKI systems work.

Additional Security Controls

Endpoint Security

Roughly 82 percent of large companies now have VPNs in place. These organizations often falsely assume that because their remote users are accessing the corporate network via a virtual private network (VPN), the access is therefore secure (Beyond Trust, 2013). But this is a false sense of security. While VPNs do provide a tunneled connection, ensuring that only authenticated users can access network resources, they are not a complete endpoint solution (Beyond Trust, 2013). VPNs cannot and

5

do not ensure that remote and mobile devices are free from software and configuration vulnerabilities. There must be a way to ensure that remote and mobile devices are free from critical vulnerabilities before connecting to the network via a VPN. Beyond Trust’s Retina Endpoint Intrusion Prevention and Symantec’s Secure Endpoint Protection (SEP) are two such solutions. We recommend using Symantec’s Secure Endpoint Protection, as it uses “Host Integrity checks” and quarantine policies to ensure that remote users have Symantec Endpoint Protection installed, and that they pass the company’s security policy requirements (e.g., have installed all security patches, have run required vulnerability scans, etc.) (Symantec, 2017).

Other security controls include: Stateful Firewalls with Ingress and Egress filtering, Access Control, Audit Control, Snort IPS/IDS, Cryptographic Key Management Systems (CKMS), and a Continuous Monitoring Implementation.

Relevant Laws, regulations, and standards

As mentioned above, the HIPAA Security Rule focuses on the protection Protected Health Information, and in specific the protection of electronically stored and transmitted private health information. The following entities are mandated to comply with Security Rule standards, and face financial penalties and or jail time for violations (Scholl, et al., 2008):

• Covered Healthcare Providers— Any provider of medical or other health services, or supplies, who transmits any health information in electronic form in connection with a transaction for which HHS has adopted a standard.

• Health Plans— Any individual or group plan that provides or pays the cost of medical care (e.g., a health insurance issuer and the Medicare and Medicaid programs).

6

• Healthcare Clearinghouses— A public or private entity that processes another entity’s healthcare transactions from a standard format to a nonstandard format, or vice versa.

• Medicare Prescription Drug Card Sponsors – A nongovernmental entity that offers an endorsed discount drug program under the Medicare Modernization Act (Scholl, et al., 2008).

Insuracare belongs to the second group, Health Plans, and therefore are required to abide by the Security standards/General rules section of the HIPAA Security Rule. Under these general rules, each covered entity must:

• Ensure the confidentiality, integrity, and availability of EPHI that it creates, receives, maintains, or transmits;

• Protect against any reasonably anticipated threats and hazards to the security or integrity of EPHI; and

• Protect against reasonably anticipated uses or disclosures of such information that are not permitted by the Privacy Rule.

• In complying with this section of the Security Rule, covered entities must be aware of the definitions provided for confidentiality, integrity, and availability as given by § 164.304:

• Confidentiality is “the property that data or information is not made available or disclosed to unauthorized persons or processes.”

• Integrity is “the property that data or information have not been altered or destroyed in an unauthorized manner.”

• Availability is “the property that data or information is accessible and useable upon demand by an authorized person” (Scholl, et al., 2008).

The cryptographic standards in this paper are intended to ensure that Insuracare complies with the above rules and standards.

Policies that need to be enforced

The HIPAA/NIST Security Rule divides security controls into Administrative, Physical, and Technical Controls (HHS, 2007). The technical controls can be further broken down into the following components: Access Control, Audit Control, Integrity, Person or Entity Authentication, and Transmission Security. Encryption and hashing, which we discussed previously, can handle Integrity, Person and Entity Authentication, and Transmission Security. But the Access Control and Audit Control components require security implementations that cryptography cannot provide. Endpoint Security, Stateful Firewall configurations, Role-Based Access Control (RABC), Intrusion Detection and Prevention systems (IDS/IPS), Cryptographic Key Management Systems (CKMS), and Continuous Monitoring are security controls that can supply solutions for Access Control and Audit Control, and that all networks should implement to protect Protected Health Information (PHI).

Threats and Vulnerabilities

We provided discussion of the threat environment in the Executive Summary, but to reiterate the threat, we remind the reader that the adversaries to the healthcare industry are formidable and range from lone attackers looking for private health and identity information to sell on the Darknet, to State-sponsored hackers. No doubt some attackers, such as state-sponsored hackers, and well-trained and well-equipped, and in order to face such attackers, healthcare companies such as Insuracare require

7

more than a cybersecurity policy that adheres to NIST standards. In such instances, the support of government cybersecurity experts may be required. The message here is that we cannot always “go it alone”. One of the biggest obstacles to the good cyber security is that organizations are fearful of admitting that they have been attacked, out of concern that shareholders may lower the value of their stock. But without transparency, that is, admitting when a data breach has occurred or when we have been attacked with ransomware, we can never receive the support we require to improve security and prevent future incidents.

Finally, it is important to conduct frequent risks assessments. In addition to the cryptographic mechanisms described in this paper, we recommend frequent and thorough risk assessments as a means of enforcing security policies in the presence of evolving threats. Since the threat environment is constantly evolving, Insuracare needs to ensure that our cryptographic and other security implementations are up-to-date and able to withstand these evolving threats.

Figure 4: Sample Risk Assessment Methodology

Hash vulnerabilities

Hashes are vulnerable to collisions, which is where two pieces of data will hash to the same value. In fact MD5’s vulnerability to collisions is one of the reasons it is no longer recommended by NIST. But collisions are extremely rare for the better algorithms like SHA-256 (Cruise, 2010). In fact, one security expert calculated that being hit by a massive, extinction-causing asteroid is 45 times more likely than a SHA-256 collision (Pornin, 2010).

8

MACs are also vulnerable to attack such as Length-Extension Attacks. But the length-extension problem can be solved using a secure HMAC implementation (Duong & Rizzo, 2009). HMAC is more secure in part because it calls the complete hash-function twice (Northcutt, 2008).

Key Distribution Protocol vulnerabilities

Since all authentication is controlled by the KDC, compromise of this authentication infrastructure can allow an attacker to impersonate any user (Walla, 2000). These sorts of attacks did occur in November 2014, and Microsoft released a patch (MS14-068) to fix the KDC vulnerability. The vulnerability reportedly allowed attackers to falsely authenticate and then elevate their privileges up to Domain level (Kerberos Consortium, 2008).

It should be said, however, that the threats from not properly deploying a distribution protocol like Kerberos are similar to the risks of not implementing a cryptographic system in general (Walla, 2000). The risk of not employing a good key distribution protocol far outweigh the risks of not employing one.

Authentication Protocols vulnerabilities

Kerberos does have some vulnerabilities. For example, if an attacker is able to gain access to the KDC then the entire Kerberos authentication system is at risk (redhat, 2017). The attacker will have access to the database of encrypted passwords, and will then also have access to the Kerberos software and configuration files, which they can alter to make the system authenticate users who should not be authenticated (Brennen, 2004).

A attacker could also exploit outdated software in the Kerberos infrastructure. Many problems have been found in Kerberos version 4, especially the fact that Kerberos 4 used DES in standard mode, which allows attackers to easily capture and modify the ciphertext of Kerberos tickets in a way that is virtually undetectable to network administrators (Brennen, 2004). Kerberos 5, however, uses the much more secure triple DES in Cipher Block Chaining (CBC) mode, so it is important to only install Kerberos 5.

Public Key Infrastructure (PKI) vulnerabilities

Risks to the PKI include attacks on the certification authority (CA), the theft of issued certificates which the attackers can use to decrypt messages, the theft of issued code signing digital certificates, and denial of service (DOS) attacks (Fahey, 2017).

Conclusion

In this report we have tried to demonstrate the cyber risks to healthcare businesses and to propose most robust cryptographic recommendations for protecting PHI under HIPAA. Our recommendations meet or exceed NIST security rule recommendations. It is our hope that this report provides tangible and coherent guidelines for securing Insuracare’s network and thereby its electronic PHI, and we look forward to working with executives to implement these cryptographic standards.

In conclusion, though a cryptographic system such as AES tends to be judged by the strength of its underlying algorithm and the length of its keys, it is important to understand that any cryptographic system, no matter how robust, is only as strong as the implementation of the cybersecurity system surrounding it (Harris, 2014). As one writer put it, “It is generally not a wise to depend on secrecy for security” (WikiBooks, 2009). Cryptography is indispensable for security, but just as a lock is useless when

9

not attached to a door, and the door to a solid doorframe, so a complex cryptographic algorithm is useless unless other supporting security measures are put into place.

10

ReferencesBarker, E. (2016, January). NIST Special Publication 800-57 Part 1: Recommendation for Key

Management. Retrieved from NIST: http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pdf

Bellare, Mihir, & Rogaway, Phillip. (1995). Provably Secure Session Key Distribution|. Retrieved from IETF: https://www.ietf.org/proceedings/53/slides/aaa-5.pdf

Beyond Trust. (2013). Best Practices for Securing Remote. Retrieved from Beyond Trust: https://www.beyondtrust.com/wp-content/uploads/Best-Practices-for-Securing-Remote-and-Mobile-Devices.pdf

Brown, M. (2014, January 9). What is the penalty for a HIPAA violation? Retrieved from TrueVault: https://www.truevault.com/blog/what-is-the-penalty-for-a-hipaa-violation.html

Cruise, B. (2010, April 28). Hashing Algorithm, its uses? Retrieved from StockOverflow: https://stackoverflow.com/questions/2726001/hashing-algorithm-its-uses

Di Mauro, A. (2015, February 26). The Big Debate, 2048 vs. 4096, Yubico’s Position. Retrieved from Yubico: https://www.yubico.com/2015/02/big-debate-2048-4096-yubicos-stand/

Duong, T., & Rizzo, J. (2009, September 28). Flickr's API Signature Forgery Vulnerability. Retrieved from Internet Archive: https://web.archive.org/web/20141014002037/http://netifera.com:80/research/flickr_api_signature_forgery.pdf

Fahey, R. (2017). Public Key Infrastructure (PKI) And The CISSP. Retrieved from InfoSec: http://resources.infosecinstitute.com/category/certifications-training/cissp/domains/asset-security/public-key-infrastructure-pki/#gref

Ferguson, N., Schneier, B., & Kohno, T. (2010). Cryptography Engineering. Indianapolis: Wiley Publishing, Inc.

Gemalto. (2017). Findings from the first half of 2017: Data Breach Report. Retrieved from Gemalto: http://breachlevelindex.com/assets/Breach-Level-Index-Report-H1-2017-Gemalto.pdf

Harris, S. (2014, October). CISSP cryptography training: Components, protocols and authentication. Retrieved from TechTarget: http://searchsecurity.techtarget.com/feature/CISSP-cryptography-training-Components-protocols-and-authentication

HHS. (2007, March). Security 101 for Covered Entities. Retrieved from HHS.gov: https://www.hhs.gov/sites/default/files/ocr/privacy/hipaa/administrative/securityrule/security101.pdf?language=es

HHS. (2016, February 23). Addressing Gaps in Cybersecurity: OCR Releases Crosswalk Between HIPAA Security Rule and NIST Cybersecurity Framework. Retrieved from HHS: https://www.hhs.gov/hipaa/for-professionals/security/nist-security-hipaa-crosswalk/index.html

HIPAA. (2017, June 21). Healthcare Data Breach Costs Fall to $380 Per Record. Retrieved from HIPAA Journal: https://www.hipaajournal.com/healthcare-data-breach-costs-2017-8854/

11

Kerberos Consortium. (2008, April 8). Why is Kerberos a credible security solution? Retrieved from Kerberos Consortium: http://www.kerberos.org/software/whykerberos.pdf

Kim Cohen, J. (2017, May 18). DDoS attacks on healthcare increase 13% since 2016: 7 survey insights. Retrieved from Beckers Hospital Review: https://www.beckershospitalreview.com/healthcare-information-technology/ddos-attacks-on-healthcare-increase-13-since-2016-7-survey-insights.html

Krawczyk, H., Bellare, M., & Canetti, R. (1997, February). HMAC: Keyed-Hashing for Message Authentication. Retrieved from IETF: https://tools.ietf.org/html/rfc2104

Larson, M. (2014, September 4). WHAT ARE THE DIFFERENCES BETWEEN DES AND AES ENCRYPTION? Retrieved from Townsend Security: https://info.townsendsecurity.com/bid/72450/what-are-the-differences-between-des-and-aes-encryption

Lawton, S. (2015, March 17). Introduction To Public Key Infrastructure (PKI). Retrieved from Tom's IT Pro: http://www.tomsitpro.com/articles/public-key-infrastructure-introduction,2-884.html

mediawiki. (2016, August 11). Extension:LDAP Authentication/Kerberos Configuration Examples. Retrieved from mediawiki: https://www.mediawiki.org/wiki/Extension:LDAP_Authentication/Kerberos_Configuration_Examples

Microsoft. (2003, March 28). What Is Kerberos Authentication? Retrieved from Microsoft: https://technet.microsoft.com/en-us/library/cc780469(v=ws.10).aspx

Microsoft. (2012, July 18). Kerberos Authentication Overview. Retrieved from Microsoft: https://technet.microsoft.com/en-us/library/hh831553(v=ws.11).aspx

MIT. (2017). Installing KDCs. Retrieved from Kerberos Consortium: https://web.mit.edu/kerberos/krb5-devel/doc/admin/install_kdc.html

Mulero, A. (2017, February 27). Charts: Must-know healthcare cybersecurity statistics. Retrieved from Healthcare Dive: http://www.healthcaredive.com/news/must-know-healthcare-cybersecurity-statistics/435983/

Munro, D. (2015, December 31). Data Breaches In Healthcare Totaled Over 112 Million Records In 2015. Retrieved from Forbes: https://www.forbes.com/sites/danmunro/2015/12/31/data-breaches-in-healthcare-total-over-112-million-records-in-2015/#3133e1a47b07

Northcutt, S. (2008, January). Hash Functions. Retrieved from SANS Technology Institute: https://www.sans.edu/cyber-research/security-laboratory/article/hash-functions

Polk, T., Kerry, M., & Chokhani, S. (2014, April). Guidelines for the Selection, Configuration, and Use of Transport Layer Security Implementations. Retrieved from NIST: http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r1.pdf

Pornin, T. (2010, October 25). Is it safe to ignore the possibility of SHA collisions in practice? Retrieved from StackOverflow: https://stackoverflow.com/questions/4014090/is-it-safe-to-ignore-the-possibility-of-sha-collisions-in-practice

12

Schneier, B. (2016, February 25). The Importance of Strong Encryption to Security. Retrieved from Schneier on Security: https://www.schneier.com/blog/archives/2016/02/the_importance_.html

Scholl, M., Stine, K., Hash, J., Bowen, P., Johnson, A., Dancy-Smith, C., & Steinberg, D. I. (2008, October). NIST Special Publication 800-66 Revision 1. Retrieved from NIST: http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-66r1.pdf

Sumastre, M. G. (2013, May 3). The Top 7 Most Reliable SSL Certificate Providers. Retrieved from Pluralsight: https://www.pluralsight.com/blog/software-development/top-reliable-ssl-certificates

Symantec. (2017). How Host Integrity works. Retrieved from Symantec: https://support.symantec.com/en_US/article.HOWTO101749.html#v85696746

Walla, M. (2000, May). Kerberos Explained. Retrieved from Microsoft: Windows 2000 Advantage Magazine: https://msdn.microsoft.com/en-us/library/bb742516.aspx

WikiBooks. (2009, December 26). Security Architecture and Design/Systems Security Architecture. Retrieved from WikiBooks: https://en.wikibooks.org/wiki/Security_Architecture_and_Design/Systems_Security_Architecture

13