Securing Certificate Services

Standalone and Enterprise Root servers contain the single copy of the company's private key. This component is essential in authenticating any and all access to the PKI-secured data and entry points.

Physical security and data security are both very important tasks in an administrator's role.

Locking Down Servers

Microsoft provides very well-defined baseline security guidelines for locking down the operating system, IIS, and administrative access.

Change the local administrator and guest account names . Don't use the same administrator and guest account name on every server.

Separating Server Roles

Placing more than a single role on a server makes an attacker's job easier. It then becomes possible to compromise several roles in the company's PKI infrastructure. Certificate Services storage and enrollment can be separated. The following list includes some of the tiers that can be physically placed on separate servers:

Root CA Server
Root Subordinates (Intermediate CA)
Issuing CA Server
Certificate Storage in Active Directory
IIS

Assigning Administrative Roles

Administrators need to work with senior executives to define the roles that will be assigned to personnel within the company when it comes to managing the PKI and smartcard system.

The persons entrusted with issuing smartcards within an organization are known as enrollment agents . Enrollment agents are typically members of the help desk, IT security, or company security staff. In locations where one of these personnel isn't readily available another trusted individual such as that location's supervisor or manager can be the enrollment agent.

Delegating the authority to issue smartcards has administrative as well as security benefits. Some of those benefits are listed here:

Administrators can delegate this time-consuming process.
Enrollment agents process all certificate and smartcard requests .
Smartcard users can be stepped through the enrollment process.

There are also some disadvantages to delegating smartcard enrollment. Here are several points to consider:

The trustworthiness of the enrollment agent could come into question.
Overcoming concerns could require more personnel resources.
Remote locations might not have an available enrollment agent full-time .
An agent can perform only a limited number of smartcard enrollments per work day.

Getting the Most Out of Smartcards

Any security measure that makes it harder for end-users to do their job is never accepted whole-heartedly. Administrators have to perform extensive planning and usability studies within their organizations.

Contact-less Smartcard Support

Windows Server 2003 and Windows XP do not support the type of devices known as contact-less smartcards.

Choosing an Appropriate Smartcard

There are a variety of smartcards and USB tokens from which to choose. Smartcards that are used in a Windows Server 2003 environment run on the Microsoft Smartcard operating system. Smartcards and their readers must adhere to the ISO 7816 standard. To ensure compatibility you should always test the smartcard with the reader and confirm that USB ports will be available for token type devices.

Administrators have to plan for the usage requirements for the smartcards or USB tokens. The following list includes some considerations for the physical card or token:

Hardware type (card or USB token)
Memory requirements
Company's intended lifetime of device
Company's intended roles for device
Reader hardware
Physical location and availability of USB ports
Device management software

Memory Requirements

Smartcards and tokens use their memory to store the certificate of the user, the smartcard operating system, and additional applications. To use the smartcard in a Windows logon environment, you must be able to program the card to store the user 's key pair, retrieve and store an associated public certificate, and perform public and private key operations on behalf of the user (enrollment agent).

Smartcards come in two common memory configurations8KB and 32KB. To use the Microsoft Smartcard operating system, you need to specify the 32KB device.

Maximum Length of User's Logon Certificate

The maximum length of the user's logon certificate is 1,024 bits due to fact that it is the largest certificate that will fit in the 2.5KB space provided on the smartcard.

The components that make up the memory storage requirements on a typical 32KB smartcard device are listed in Table 3.1

Table 3.1. Typical Smartcard Memory Use (32KB Device)

Content	Memory Used
Windows for Smartcards operating system	15KB
Smartcard Vendor Applications	8KB
Smartcard logon certificate	2.5KB
Company Custom Applications (if any)	1.5KB
Free Space	5KB

The memory configuration of the smartcard is ultimately up to the company and the administrator. Smartcards can be divided into public and private memory spaces. You can define separate protected memory for the operating system, certificates, e-wallets, and other applications. This section of the card's memory can be allocated as Read Only.

The memory capacity on smartcards is increasing as vendor technology improves . This allows for more applications and certificates to be stored on the card or token. Multiple uses can be specified for the cards and the memory requirements that affect these applications should be taken into consideration when deciding to purchase such devices.

Multiple Applications Must Use a Single Smartcard Logon Certificate

Multiple applications, such as physical access and secure logons , must use a single smartcard logon certificate. Windows Server 2003 and Windows XP do not support the use of multiple certificates on a single smartcard device.

Smartcard Roles

Administrators have three roles of smartcards at their disposal. When planning the company's smartcard deployment you need to determine the number and type of each card.

Enrollment cards are issued to personnel who will be enrolling smartcards on behalf of other users. These cards have a special enrollment agent certificate that enables the card's user to act on behalf of the administrator.
User cards can be permanently issued and point to a permanent certificate server
User cards can also be temporary use cards that point to temporary certificates.

In better defining the user cards, the two types are as follows :

Permanent cards are issued to the employees to be carried with them at all times. These cards contain the cardholder's credentials, certificates, data, and custom applications. Customization of the cards might include company logos and a photograph of the cardholder.
Temporary cards are issued for limited-use and are issued to users such as guests, temporary employees, and employees who have forgotten their permanent cards

Smartcard Life Expectancy

Administrators must take into account a few factors when deciding on the type and durability of the smartcards or tokens. These considerations should be based on the normal wear and tear expected on the device and the length of end-user's usage.

When purchasing the smartcard device you should ask the vendor(s) for expected lifetime documentation for the device

Smartcard Reader

The physical device that the computer uses to interface with the smartcard is known as the "smartcard reader." The readers come in a few form factors, including USB, RS-232 serial port, and Personal Computer Memory Card International Association (PCMCIA) Type II slot.

The USB style token device is the simplest of the smartcard/reader combinations because it doesn't require a separate smartcard reader. One item to consider when choosing this type of device is the physical availability and access to open USB ports on the end-user's computer.

Smartcard Management Tools

You need to evaluate the bundled software that comes with the smartcard or token device. The management software can enable you and the company's developers to customize the memory allocation and custom applications.

Some smartcard and token device manufacturers supply additional security management software as well. This is important when the deployment of smartcards is transitioning from pilot to production as well as maintaining the user's smartcard credentials on the devices.

Custom application development requires a robust application programming interface (API) from the smartcard vendor. This is especially important when combining multiple uses of the smartcard such as building access and secure logon and application access.

Making Users Use Smartcards

By using group policies you can enforce user's behavior. The policies that affect smartcards are shown in Figure 3.1 and Figure 3.2.

Figure 3.1. Group policy smartcard enforcement.

graphics/03fig01.gif

Figure 3.2. Group policy smartcard removal behavior.

graphics/03fig02.gif

Many company expenditures are underused, if used at all, because of increasing end-users perceived complexity. The smartcard is one device that can make the users' experience actually become easier.

Users will find that they don't have to memorize those hard-to-remember strong passwords. Administrators won't find yellow Post-it notes with the user's strong password stuck to the lower-corner of the user's monitor or under her keyboard.

Providing Security Reports

More laws are passed every year that place companies and consultants at risk of not protecting users and client's data.

To Take Advantage of Windows Server 2003 Auditing...

To take advantage of Windows Server 2003 auditing you need to enable Audit object access by using the Group Policy Object Editor and drilling down to Computer Configuration/Windows Settings/Security Settings/Local Policies/Audit Policy and double-clicking on Audit Object access.

By verifying who a user is and when and where he signed on to the system, it makes it easier to prove that person's identity and possibly his intentions.

Security and financial auditors need to be able to read reliable reports of not only hacking attempts but also normal day-to-day network usage and system access.

Administrators of Windows Server 2003based CA servers can provide reporting on the following functions.

The CA audit log generates two types of events:

Access check
System events

CA- related system events are generated in seven key categories:

Back up and restore the CA database
Change CA configuration
Change CA security settings
Issue and manage certificate requests
Revoke certificates and publish CRLs
Store and retrieve archived keys
Start and stop Certificate Services

Administrators can enable and configure CA event auditing by performing the following steps:

Log on to the server with an account with one of the following permissions: Domain Administrator, Certificate Authority Administrator, or Certificate Authority Auditor .
Click on Start, Programs, Administrative Tools, Certification Authority.
In the console tree, right-click on the name of the CA on which you want to enable event monitoring and select Properties.
On the Auditing tab, click on the events to audit as shown in Figure 3.3.

Figure 3.3. Enabling auditing on the Certification Authority.