Life at the edge part 3: Resistance to failure

by Michael Cobb

Resistance to failure

Security has to be understood and implemented at the architecture, protocol and application levels in order to provide successive protection. Only by understanding all these elements will you be able to build and maintain a system that can resist attack. Bear in mind when designing your network architecture that its survivability is as much protocol-based as topology-based. Particular attention has to be given to any traffic that crosses a trust boundary.

@11265 Once you build the network perimeter, you must test it to demonstrate that routing, packet filtering, and logging and alert capabilities all perform as expected. An excellent document covering firewall testing is available from the CERT Security Improvement Modules at CERT.org. http://www.cert.org/security-improvement/practices/p060.html.

Using encryption
An unencrypted link between your Web site and a browser is essentially an open one. This is not a problem -- if nothing on your site is confidential. But, if you wish to make proprietary information available or take online orders, then you need to protect data as it travels between server and browser. Encryption can be used to provide extra layers of defense for such data, as well as protect it as it crosses trust boundaries. Encryption can be used to support user authentication, data stored in files or communications across a network. For example, Windows NTFS file encryption can be used to augment a server's access control for highly sensitive documents. However, when file encryption is used with a Web site, it's generally done to encrypt specific elements of data for application-specific purposes, such as protecting credit card numbers in a customer database. The most common and practical use for encryption on a Web site is to encrypt sensitive information with SSL/TLS as it is being sent to a browser over a network. The SSL and TLS protocols provide very strong encryption.

SSL, digital certificates and public-key infrastructure
SSL encryption is accomplished by a symmetric cipher after one-time session keys are securely exchanged via public-key encryption. The public-key encryption is RSA, and the default symmetric cipher is RC-4. In addition, all data sent over encrypted connections is protected with a mechanism that detects tampering by determining whether the data has been altered in transit. SSL can be combined with digital certificates to authenticate a Web site. A digital certificate is a digital document that vouches for the identity of an individual or a computer system. The set of products and processes required in order to securely issue, maintain and manage digital certificates is called a public-key infrastructure (PKI). One of the components of PKI is a certificate authority (CA), which operates a certificate server and issues certificates. A CA is responsible for verifying the identity and key ownership of an individual or organization before issuing the certificate.

If you operate an e-commerce Web site or allow users to access confidential information via a Web site, you must use a digital certificate and the SSL/TLS protocol to encrypt communications. A browser authenticates a digital certificate installed on a Web site by comparing the certificate's signature to the public key of the CA's root certificate that is installed on the browser. Thus, the browser verifies that the site belongs to the organization it claims to represent. You can purchase a certificate from a commercial CA such as Verisign, or you can choose to act as your own certificate authority using a product such as Microsoft Certificate Server.

Your server's digital certificate allows users to authenticate your server, but what if you need to authenticate those coming to your site? Internet Information Server (IIS) lets you choose how to handle certificates presented by visitors. You can use client certificates for authentication and prevent users who do not have a valid certificate from accessing the secure content of your site. You can also map client certificates to Windows user accounts on your Web server. If you enable this mapping, then each time a user logs on with a client certificate, your Web server automatically associates that user with the appropriate Windows user account. Using this feature, you can automatically authenticate users who log on with client certificates, without requiring the use of Basic, Messaging Digest or Integrated Windows authentication.

Using IIS secure communications
To configure IIS to handle encrypted sessions you need to:

• Create a public-key pair in IIS to submit to a CA when you request a certificate
• Request a server certificate from the CA
• Install the certificate
• Configure the directories and pages that you want to secure

Request a certificate from a commercial CA via their Web site. Once your certificate is installed, complete the rest of the SSL/TLS configuration. In order to do this properly, think through your site's organization. Most Web sites, even when they use encryption, also have a non-encrypted section, as it's very costly to encrypt every Web page. Most organizations place marketing material, contact information and anything else that they want the public to have easy access to in separate, unencrypted directories. Create a separate directory -- or for very sensitive transactions a different site -- for content that is for confidential access, and encrypt only that information.

IIS directory encryption works differently than Windows 2000/2003 directory encryption. In Windows Explorer the information is encrypted on disk. However, it is not practical to use on a high-volume Web site, because encrypting all the site's data would bog down even the most powerful server. In contrast, SSL/TLS encrypts information as it is being sent over the network to a browser client. To ensure that your site is safe, you should not use less than 128-bit encryption.