Details about Data Encryption

For basic information about data encryption, read Introduction to Data Encryption.

Recent news stories about personally identifying public health data being lost or stolen have made encryption an important issue for any organization handling sensitive data. Encryption can help prevent security breaches that would compromise NPCR programs' commitment to protecting the confidentiality of patient records.

All NPCR programs maintain confidential data that should be encrypted before, during, and after traveling across the Internet and any network. NPCR registries are recommended to use electronic security measures to protect data from criminal intrusions or third-party surveillance.

Encryption and Cryptography

Encryption converts plain text into ciphertext, and decryption converts ciphertext back into plain text. Ciphertext looks like random characters, but is actually the result of the application of a key to the plain text. A key is usually a mathematical algorithm known only to the sender and the intended recipient of the message.

A cryptosystem is a system for encrypting and decrypting data. A strong cryptosystem has many possible keys, so a third party would be unlikely to find the correct key by trying all possible keys. A strong cryptosystem also produces ciphertext that appears random to all standard statistical tests and resists all known methods for breaking codes.

Access Control

Before implementing encryption, an organization needs to ensure access to the database is limited to authorized users. Access controls that should be addressed include rules for creating users, users' privileges to access objects, and users' permissions to perform commands and various tasks.

The following diagram illustrates how access control and encryption work together to secure data:

Security Requirements for Data Encryption

• All digital communications and databases containing confidential data that leave the security boundary of the NPCR program network should be encrypted. This includes data sent via the Internet, FTP, and e-mail, and data stored on media such as laptops, USB drives, CD-ROMs, PDAs, and tape backups.



• Communications and confidential data stored within the security boundary of the NPCR program should be encrypted if possible.



• Confidential data that are backed up are subject to the encryption requirements above.



• No single solution can protect a system properly. More than one layer of security is required.

Encrypting Data in Motion

Data in motion are data that aer being transmitted across a local or wireless network or the Internet. Encrypting data in motion hides information as it moves across the network, between the database and the client. Encrypting data before transmission prevents—

• Interception of confidential data as it moves between the client and database
• Session hijacking (redirecting data)
• Replay attacks (replaying an authentication session to fool a computer into granting access)

Standards for encrypting data in motion include Secure Socket Layer (SSL), Transport Layer Security (TLS), and Internet Protocol Security (IPSEC).

Encrypting Data at Rest

Most system administrators have adopted data-in-motion safeguards, but do not protect data at rest because protection is perceived as too complicated and costly. However, most attacks do not occur on data in motion, but rather at the end points, where data sits for long periods of time. Data at rest are data that are stored in a database. Your Chief Technology Officer (CTO) should develop and follow an NPCR program-specific security policy that conforms with institutional and other data security requirements. NPCR standards include the CDC Unified Process Guide, which explains the National Institute of Standards and Technology's (NIST) Federal Information Processing Standard (FIPS) 140-2 requirement to encrypt confidential data files. CDC will provide and help you interpret this set of documents.

Databases can be encrypted in two ways. Encrypting the entire database file offers strong protection, but can degrade performance and impact user access control. Encrypting the database by column or row allows only the most sensitive information such as Social Security numbers to be encrypted, and adds minimal overhead since only a small portion of the database is encrypted. However, this method can restrict sensitive data from authorized users, even system administrators.

Key Management

Often the most difficult problem in database encryption is key management, which should include generation, use, change, archival, and deletion of keys. Security depends on two factors: where the encryption keys are stored, and who has access to the encryption keys. Any database protection effort is only as secure as the key management that supports the system. The fear of losing decryption keys (and thus their data) has kept many organizations from encrypting stored data.

If the keys are not protected adequately, the security gained from encryption is diminished. For example, a key that is hard-coded into a procedure or script undermines security since a simple examination of the code reveals the key. On the other hand, too much security degrades system performance and maintainability, forcing administrators and developers to circumvent security to complete their work. The process of generating, storing, and protecting keys should require minimal user intervention. The security plan should explain how often the encryption keys should change.

Impact on Performance

Encryption must be planned carefully to make sure it does not slow your system's performance. Encryption can be done at three levels, but only one level is required. Performance is ranked from best to worst—

• Hardware such as chips or hard drives
• Operating systems such as Microsoft^® Windows^® or Linux
• Encryption applications from NIST-certified vendors

Vendor benchmarks for all three levels of encryption indicate that systems will experience only a fraction of a percent loss in performance, and the end user should not notice the difference. More benchmarks may be needed to verify these claims. Staff who provide technical support to other programs in your institution may have this information; if not, CDC's NPCR can work with NPCR programs to compile a list of benchmarks.

Plan carefully before encrypting information on indexed fields, since this can degrade performance seriously and add unnecessary computational overhead.