10 Security Stack Worksheet for Encryption (continued)

Encryption Summary

Worksheet 3. 10 Security Stack Worksheet for Encryption (continued)

Differentiate between these approaches in your security plan. Your security plan should reflect an understanding of where data in transport is encrypted and where it is not and what the related impact is.

Plan for the network encryption protocol impact on firewall, proxy server, caching, and load balancing systems.

Application

Determine what applications may require encryption, and define needed encryption statefulness.

______________________________________________________________________ ______________________________________________________________________ ______________________________________________________________________ Identify existing application-level encryption mechanisms and key management

approaches.

______________________________________________________________________ ______________________________________________________________________ ______________________________________________________________________ Develop a plan for the how, when, where, and why of encryption at the application level.

______________________________________________________________________ ______________________________________________________________________ ______________________________________________________________________ Differentiate between file-level and data-level encryption approaches relative to your requirements.

Operating System

Determine operating system-level encryption requirements such as encryption of sensitive system files.

______________________________________________________________________ ______________________________________________________________________ ______________________________________________________________________ Identify encryption technologies within your operating system that may be used at the network and application levels.

______________________________________________________________________ ______________________________________________________________________ ______________________________________________________________________ Assess the strength of the key management mechanism used for file system encryption at the operating system level.

Consider the effect on your intrusion-detection systems. Encryption within the network can affect your ability to perform intrusion detection because intrusion-detection systems cannot read encrypted network traffic nor decipher hacker signature behavior that is indicative of an intrusion or potential intrusion.

APPLICATION

In your plan, specify the what, why, how, when, and where of encryption at the application level. That means determining what you want to encrypt, why you believe it should be encrypted, how you will do it, when you will encrypt/decrypt, and finally where the encrypted and decrypted information will be stored. We already considered different encryption approaches as they relate to the network, noting the general difference between encrypting information as it moves through the network versus encrypting it for long-term storage on a computer. When we look strictly at the application layer, we are able to consider certain approaches that provide some of the best of both worlds. An excellent example of such an approach would be encrypted electronic mail. To keep a hacker out of email, you need to encrypt it. Encrypted email allows information to be encrypted, long term, on a computer’s hard drive; at the same time, it can be used across the network. The two most popular secure mail standards are Secure MIME (S/MIME) and Pretty Good Privacy (PGP). S/MIME support is built into most popular email software such as Microsoft Outlook, Netscape Messenger, and Lotus Notes. S/MIME relies on the use of a PKI; therefore, those that use it must have a digital certificate and a secure mechanism to store and pro- tect their private key. Secure key storage mechanisms include a smart card or, with the disadvantages previously noted, a hard drive or floppy disk. Other example application-level approaches to encryption include database encryption, directory server encryption, or encryption of the data used by a general application of some kind. With these approaches, a key is somehow managed within the application. Often, with these approaches, software vendors offer you relatively weak but easy-to- administer solutions and very strong, but more difficult-to-administer, PKI-based encryption approaches. For the strongest encryption

approach, a stationary hardware cryptographic device that can securely hold the private key is required. Because applications have detailed knowledge about the information they manage, they are in a better posi- tion than the operating system (discussed next) to streamline encryption decisions such as when information should and should not be encrypted and decrypted.

OPERATING SYSTEM

Encrypt in the operating system. Perhaps the most obvious example of operating system encryption would be file system-based encryption. In this case, the operating system manages the encryption keys used to encrypt files on the hard drive. Generally speaking, file system encryption does make hacking more difficult; but, because the operating system is inherently limited in the assumptions it can make about the use of information, encryption at the file level, rather than at the individual application-managed data component level (as in a field in a database or an email message), results in more security vulnerabilities than when encryption is performed at the application level. Operating system-level encryption tends to result in more information being left in the clear more often and with fewer safeguards.

Life-Cycle Management

Use Worksheet 3.11 here.

TECHNOLOGY SELECTION

Focus on encryption algorithms enough to understand the consensus view on their strength. Often, when selecting encryption-based technologies, people start by developing an understanding the strength of one encryption algorithm versus another. They become lost in a sea of terms relating to key length, randomization, RC this, DES that, and so forth. Strength, and making sure algorithms you choose remain strong or are updated over time for strength, is indeed important and some- thing your security plan should address. At the same time, you don’t need to turn yourself into a full-fledged cryptographer in order to plan a security solution; in fact, if you do, you run the risk of missing the forest for the trees. You can obtain a consensus view by doing simple research on the Internet. (If you are interested in learning more about cryptogra- phy in general, check out the references in “For Further Reading” at the back of this book.)

Estimate performance of encryption algorithms and key management schemes. This requires addressing very important and relevant topics that affect your implementation and the day-to-day practicality of encryption: key management, including recovery, statefulness of encryption (in transport, at the application, in the operating system), and how encryption is integrated into your application and the network. While many encryption algorithms are surprisingly efficient, some encryption plans, when all elements are considered, including public key and private key operations associated with dynamic secret key negotiation, introduce some kind of performance burden that should be quantified and managed over time. You can assess this by running your application

under load without encryption and measuring computer CPU utilization and qualitative application response time. Next, turn encryption on and perform the same measurements. Finally, compare the measurements.

Select your encryption technology so that it can be integrated in the intended way, with your intrusion-detection and vulnerability analysis systems. As mentioned earlier in the discussion on encryption at the network layer and IPSec, SAs, and SSL/TLS, encryption can introduce challenges to your intrusion-detection and vulnerability analysis systems.

Select key storage and management solutions. Fundamental to technology selection are the ease, convenience, and scalability of the key storage and management mechanisms. Using PKI implies a significant infrastruc- ture investment (see Chapter 5). Hardware storage of keys and smart cards also introduce considerable overhead. Keys stored on floppy disks and hard drives decrease security. There is no easy solution here, so you will have to drive your decisions based on your impact analysis and security budget.

IMPLEMENTATION

Carefully monitor system performance over time. Do this as you phase in your deployment of encryption; include CPU loading, system response times, and measures of system stability (uptime). Perform measurements before and after encryption is enabled. Validate any performance

assumptions you make over time by regularly reviewing performance statistics as encryption is more heavily used.

OPERATIONS

Give the operations group a solid method of dealing with key management. Include retrieval of backup keys, should they exist, resetting of keys (unencryption with old key, re-encryption with new key). Or, better yet, design a comprehensive operational architecture that simplifies life, wherever possible, based on a well-implemented PKI architecture and simplified key management plan.

INCIDENT RESPONSE

Ensure that the incident response team knows, to the extent possible, what has been encrypted, when, by whom, and how. This demands strong logging capability within your encryption architecture. If your corporate privacy policies and procedures allow for it, this team should be able to make use of key recovery mechanisms to look at data encrypted by a suspect employee or contractor. For example, the team may want to look at encrypted electronic mail stored on a company desktop computer. In order to do that, your organization would need to implement a key

recovery mechanism when issuing digital certificates for S/MIME. The team may also need the ability to request that new keys be used as part of the encryption process in the event they believe the keys of one form or another have been compromised. Also, the incident response team should have a process to respond to outside legal entities, as in regula- tory agencies or the government in general, should they be requested as part of an investigation to provide access to information that is encrypted.

In document Mission Critical Security Planner pdf (Page 149-153)