The Three A s of Security

The Three A's of Security

To accomplish the first objective of information security ”that is, to protect data and infrastructure ”you must develop a cost-effective strategy for restricting access to data and infrastructure to authorized users only. The ingredients of such a strategy consist of the "three A's": access control, authorization, and administration.

There are many types of authorization and access controls. They range in type and function from simple user identification (ID) and password systems, implemented directly in the program code of an application program, operating system boot-up or network login process, to more complex encrypted key systems that run outside of the application itself. ID and Password safeguards may be supplemented through the use of hardware IDs for client machines and/or biometric identification methods that use fingerprints , retina artery patterns, hand geometry, or other physical attributes to establish the identity of the user seeking access.

Generally speaking, the purposes of such controls are to (1) verify the identity of a person requesting access to protected data assets and infrastructure based on something he or she possesses (key), knows (password), or is (retina scan), and (2) to grant the kind of access to the user that is consistent with his/her predefined privileges or permissions.

The third "A" ”administration ”refers to how information used for authorization and access is gathered, managed, and maintained . Most application security administration approaches require the registration or "enrollment" of a user, often using a security administration application or database, prior to enabling access to any data or infrastructure components . Once the user is enrolled, he/she may be assigned access privileges to certain data assets and not to others, to certain applications and not to others, or to certain infrastructure elements (servers, storage devices, or networks) and not to others. In addition, administration approaches may set access periods that limit a user's access to certain days of the week or hours of the day.

The administration of authorization methods and access controls (see Figure 10-1) is often the most expensive aspect of data and infrastructure security because it tends to be the most labor- intensive . Administration tasks involve:

• Collecting and verifying identification information;

• Associating authenticated identities with applications and/or infrastructure elements;

• Configuring applications and/or infrastructure elements with authenticated identity information and setting permissions;

• Issuing and tracking passwords, encryption keys, or other authentication tokens; and/or

• Maintaining all of the above against a backdrop of constant change.

Figure 10-1. Security administration is a 24/7 job.

Given the amount of work typically involved in administering security, it is not surprising that it frequently comes up as a pain point in surveys of server administrators. With the current attention to storage security, security administration is likely to rise to the top of the pain charts in storage administration as well.

Paying close attention to administration requirements as you evaluate potential technologies for use protecting storage infrastructure is another facet of the quest for a balanced approach. Technologies that impose complex administrative burdens tend not to be implemented. Take, for example, the case of IPsec.

The Internet Engineering Task Force IP Security (IPsec) standard (the current version of the RFC dates to 1998) was intended to provide a security architecture for communications across the Internet. ^[4] It consists of a collection of protocols including:

• Authentication Header (AH): AH provides an authenticity guarantee for packets by attaching strong cryptography checksums to packets. AH supports a key exchange approach to authentication (see below), provides a checksum to assure the recipient that a packet was generated by the expected sender and not by an impostor , and reassures the recipient that the packet arrived intact, and was not modified in transit.

• Encapsulating Security Payload (ESP): ESP provides a confidentiality guarantee for packets by encrypting packets with encryption algorithms. If you receive a packet with ESP and successfully decrypt it using a unique key that only you and the sender possess, you can be sure that no one could have eavesdropped upon or wiretapped the packet in transit.

• IP payload compression (IPcomp): ESP provides services for encrypting packets. However, encryption tends to conflict with efforts to compress data traversing a network, so IPcomp provides a way to compress packet before its encryption by ESP.

• Internet Key Exchange (IKE): As noted above, AH and ESP needs shared secret key between peers. IKE provides a means to share keys secretly so they can be used to encrypt data before it traverses a secure Virtual Private Network "tunnel" established between two secure end points.

The Internet Key Exchange (IKE) approach embedded in IPsec, and illustrated in Figure 10-2, tracks its origins in part to PKI, short for Public Key Infrastructure. PKI is an implementation of public key encryption techniques intended to ensure the confidentiality of data communicated between two parties. PKI, as the name implies, involves using two software keys ”one public, the other private ”to encode a message or file so that the file cannot be read by anyone other than the authorized recipient.

Figure 10-2. Internet Engineering Task Force IP Security (IPSEC) standard.

The owner of the public/private key pair provides a copy of his or her public key to those with whom he or she routinely communicates. The public key is usually stored in a Digital Certificate or digital passport, which is essentially an "attachment" to an electronic message that conforms to the X.509 certificate standard recommendation under development at the International Telecommunication Union (ITU). Recipients of public keys can store them in a key repository for use in encrypting any message or file sent to the key owner.

Once encrypted using the public key, a message or file cannot be decrypted by anyone other than the owner of the public/private key pair. The recipient decrypts the message or file using a private key that is different from, but mathematically related to, his or her public key.

This method of secure file encryption was deemed so robust that, in the late 1990s, the U.S. government (together with the governments of other countries ) sought a strategy for ensuring access to the contents of files and messages encrypted using the technique. In the United States, a system of Certificate Authorities was set up to 1) control the issuance of public/private key pairs, 2) verify the identity of the key pair recipient and issue a digital certificate containing the public key, and 3) maintain a copy of the public/private key pair in escrow should the government, under power of a court -issued warrant , ever need to decrypt encrypted traffic of the key pair holder.

PKI has been touted as the best approach to facilitate secure communications in decentralized computing environments, particularly the Internet, where centralized security administration is difficult or impossible to implement. And, as stated earlier, it is at the core of IPsec.

However, implementation of IPsec ”and of IKE in particular ”has been hampered by the complexity and management burden imposed by the key exchange system itself and by other issues including:

• Enrollment difficulties: Distributing digital certificates from and to all parties involved can be difficult, and maintaining the list and identifying revoked certificates can be labor intensive.

• Competing standards for digital certificate formats: There are two formal standards and several informal ones.

• Security concerns: The cryptographic algorithms used to decode traffic have been successfully broken by kids with standard PC processors.

• No trust in the gatekeepers: Certificate Authorities are widely perceived as the weak link in the trust-based system based on publicized incidents involving misuse or mistaken issuance of certificates by Certificate Authorities.

By 2001, IETF participants were calling for a moratorium on new features in IKE because, while the technology was sound from an engineering point of view, enhancements were only contributing to the complexity problems that had already stalled IPsec adoption by end-users. ^[5] Guidance from one open source development group held that "the configuration of IPsec is NOT EASY. There are way too many knobs to play with, and debugging is very hard due to wiretap-resistant nature of IPsec. Basically, we can't guess what is going on from packet trace. Try reading some books and standard documents/RFCs, hire consultants or whatever, before you try to configure it." ^[6]

The point is that complexity can inhibit the implementation and use of even the best security technologies. It is also worth noting that the issues surrounding the efficacy of IPsec promise to reassert themselves as IP-based storage protocols come into greater use.