Securing the Hatches

Today, the whole world is looking at security. As the world becomes more information connected, issues of information privacy are on everyone's mind. Several government mandates have been issued in the area of securing identity information for medical histories and for information regarding children.

Commerce across networks in the arena of business to business and business to consumer have all raised questions about whether credit card information is being stored securely or whether online transactions are safe. These issues have spawned many technologies and the corporate world has adopted many of these for internal security. As access to information becomes easier and easier, it is more and more critical to ensure that data and data transmissions are protected.

Security and Company Reputation

In today's market, if a company is to keep its customers, the customers must have faith in the company. Large online retailers are dependant on the confidence of their customers in their security in order to continue doing business. So long as customers feel secure that their financial information is being transmitted and stored securely, they will continue to do business with a company online.

If one of these online retailers was to become compromised and information such as credit card numbers was stolen, it could potentially destroy the company. The reputation of the company is tied directly to its security. Failure to be diligent in securing the hatches of a company can quickly lead to its downfall.

Implementing Transport Layer Security

The concept of Transport Layer Security (TLS) is that conversations between networked devices should be held in a manner such that any other device that might have intercepted the communications will be unable to use the information. TLS, which is similar to SSL, is based on an x.509 certificate which must be published from a trusted Certificate Authority (CA). TLS can do the following:

• Detect message tampering

• Detect message interception

• Detect message forgery

To use TLS for client/server communication, the following steps are used:

1. Handshake and cipher suite negotiation.

2. Authentication of parties.

3. Key- related information exchange.

4. Application data exchange.

By default TLS will accept any cipher; this can be locked down further by GPO to limit the cipher choices through modification of the following Registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\ Ciphers

You will find multiple cipher choices listed and can enable or disable them as appropriate.

The TLS Handshake Protocol involves the following steps:

1. A "client hello" is sent from the client machine to the server, along with a random value and a list of supported cipher suites.

2. A "server hello" is sent in reply to the client along with the server's random value.

3. The server sends its certificate to the client to be authenticated and it might request a certificate from the client as well. This results in a "Server hello done" message. The client sends the certificate if it was requested by the server.

4. The client then creates a random Pre-Master Secret and encrypts it via the public key from the server's certificate. This encrypted Pre-Master Secret is then sent to the server.

5. Upon receipt of the Pre-Master Secret, the server and client each generate the session keys and Master Secret based on the Pre-Master Secret.

6. The client sends a "Change cipher spec" message to the server to indicate that the client will begin using the new session keys for encrypting and hashing messages. The client also sends a "Client finished" message.

7. The server receives the "Change cipher spec" message and switches its record layer security state to use symmetric encryption based on the session keys. The server sends a "Server finished" message to the client.

8. The client and server can now exchange data over the secured channel that they have established. All data and communications sent from client to server and from server to client are encrypted using the session key.

Requiring Digital Signing

Older implementations of Small Message Block (SMB) communications were susceptible to what is known as a man-in-the-middle attack. A man-in-the-middle attack occurs when an attacker masquerading as one of the legitimate parties inserts messages into the communications channel. This allows the attacker to send its own credentials and causes the other host to accept its connection. By placing a digital signature into each SMB, which is verified by both the server and the client, there is a mutual authentication that verifies the validity of both the server and the client. If this security setting is enabled on a server, the clients must support digital signing of communications or they will be unable to communicate with the server.

This can be configured in the Default Domain Controller Security Settings under Security Settings/Local Policies/Security Options/Microsoft Network Server: Digitally Sign Communications (always)Enabled.

Leveraging PKI

Not surprisingly, certificate-based technologies require access to certificates. Specifically, certificates that have been issued by a trusted Certificate Authority. Companies have the option of using an external trusted Certificate Authority such as Verisign, SecureNet, or Globalsign. One advantage of using one of these external Certificate Authorities is that Internet Explorer comes preloaded with these as trusted root authorities. This means that clients won't have to contact those root CAs and prompt the user to accept the certificate. The other option is for a company to establish its own Certificate Authority. This could be a root CA or an Enterprise CA that was built based on a certificate provided by another Root CA.

If a company is going to issue its own certificates, client machines can be preloaded with the certificate via GPO settings. For example, if a company will be using digital certificates in their intranet, they might push a server certificate to the clients to define the server as an Intermediate Certification Authority. To push a certificate to clients, do the following:

1. Launch the GPO editor.

2. Choose User Configuration, Windows Settings, Internet Explorer Maintenance, Security, Authenticode Settings.

3. Choose Import Existing Authenticode Settings.

4. Click Modify Settings.

5. Click Import. This launches the Import Certificates Wizard.

6. Click Next.

7. Click Browse, and then browse to the certificate file. Choose Open and then click Next.

8. Choose Browse and select the appropriate certificate store.

9. Choose Next and then click Finish.

The Wizard will inform you that you are about to install a certificate claiming to be from a particular source. If this information is valid, select "yes". The Wizard will inform you that the certificate was successfully installed.

Installing Certificate Services

Installing certificate services in Windows Server 2003 requires taking a Windows 2003 server and adding the Certificate Services component on the server. The process of adding Certificate Services to a Windows 2003 is as follows :

1. Choose Start, Control Panel, Add or Remove Programs.

2. Click Add/Remove Windows Components .

3. Check the Certificate Services box.

4. A warning dialog box will be displayed, as illustrated in Figure 1.1, indicating that the computer name or domain name cannot be changed after you install Certificate Services. Click Yes to proceed with the installation.

   Figure 1.1. Certificate Services warning.

   

5. Click Next to continue.

6. The following screen, shown in Figure 1.2, enables you to create the type of CA required. In this example, choose Enterprise Root CA and click Next to continue.

   Figure 1.2. Selecting the type of CA server to install.

   

7. Enter a common name for the CAfor example, CompanyABC Enterprise Root CA.

8. Enter the validity period for the Certificate Authority and click Next to continue. The cryptographic key will then be created.

9. Enter a location for the certificate database and then the database logs. The location you choose should be secure, to prevent unauthorized tampering with the CA. Click Next to continue. Setup will then install the CA components.

10. If IIS is not installed, a prompt will be displayed, shown in Figure 1.3, indicating that Web Enrollment will be disabled until you install IIS. If this box is displayed, click OK to continue.

    Figure 1.3. IIS warning in the CA installation procedure.

    

11. Click Finish after installation to complete the process.

If IIS Is Installed on the Server, a Dialog Box Will Appear

If IIS is installed on the server, a dialog box will appear noting that the IIS services will be temporarily stopped . When prompted whether it is okay to stop and restart the IIS service, choose Yes unless the service is actively in use at the time of certificate services installation.

Importance of Physical Security

Network security is essentially useless if the servers involved aren't physically secured. Computers don't know the difference between a local break-in and a legitimate password recovery. Although security information is stored in the Active Directory, the Active Directory still consists of a database stored on servers. This information is laid out in a specific structure and a person with physical access to a hard drive that contains an NTDS.DIT file, a sector editor, and sufficient knowledge can compromise the security database.

Servers should always be located in locked data centers. Access to these data centers should be limited and audited . Security logs [%systemroot%\System32\config\SecEvent.Evt] should be duplicated in a separate location to prevent tampering. Applications like Microsoft Operations Manager, which centralize management of event logs, are useful for this task. Implementation of a syslog server will also work well for this.

Access to secured data centers should require multiple forms of authentication. For example, rather than just rely on a badge reader, the lock might consist of a combination of a badge reader and a PIN code that must be entered. This way, theft of a badge would not be enough to compromise the data center.

BEST PRACTICE: Certificate Server Integrity

Building an internal certificate server is not a trivial event and although it can be done in the 11 relatively simple steps noted in this chapter, certificate server security needs to be taken very seriously by organizations. Certificate authority only provides security and a sense of security when the integrity of the certificate creation process is ensured. If anyone can walk up to an organization's certificate server and create a certificate, no one would know whether the certificate they have is one issued by the real certificate administrator or by an unauthorized individual. If no one knows the validity of the certificate, the security of the data transmission, logon authentication, or data encryption has been greatly compromised.

Because an enterprise or root certificate server is authoritative for an organization's domain name (such as companyabc.com), that organization would not want its root certificate server compromised. If no one trusted whether any certificate-based authentication for the organization is valid, the organization has no credibility to its certificate-based security because someone who has unauthorized access to the certificate server could potentially issue certificates on behalf of the organization.

When building their enterprise or root certificate server, many large organizations distribute the task of certificate creation, hardware management, and system operations. The hardware is secured in a place that has extremely limited access. Creating certificates must be done on the server console, not set up for remote access. Access to the server requires two to three individuals to log on and access the appropriate utilities to create a certificate. All steps are videotaped and securely stored.

This whole process, although it seems to be extremely time- and process- intensive , is common for an organization because it protects the integrity of the organization's certificates.

Great care must be taken in ensuring that the creation of a Root CA is done in a secure and auditable fashion. A compromise of the Root CA essentially compromises every Enterprise and Subordinate CA that was built with a certificate from the Root CA. This, in turn , compromises every certificate issued by the CA hierarchy.