Question

Richman Investments is an investment and consulting firm. Richman wants to expand its business operations both in the U.S. and in foreign countries. Richman intends to eventually have 10,000 employees in 20 countries.   

The Richman corporate headquarters is located in Phoenix, Arizona. Currently there are eight branch offices in:

• Atlanta, Georgia
• Chicago, Illinois
• Cincinnati, Ohio
• Denver, Colorado
• Los Angeles, California
• Montreal, Canada
• New York City, New York
• Washington, D.C.

The North American offices have a total of 5,000 employees who use desktops, laptops, and wireless devices. All offices deal with several sensitive applications. Management from each office shares application information hosted at the corporate office.

Instructions:

Based on the security objectives in the following table, design an enterprise encryption strategy—a public key infrastructure (PKI) that supports internal employees, external business partners, and clients. Include the design and reasoning for using the selected encryption strategy.

Security Objective	Description
Privacy or confidentiality	Keeping information secret from all but those who are authorized to see it
Integrity	Ensuring information has not been altered by unauthorized or unknown means
Entity authentication or identification	Corroborating the identity of an entity, for example a person, a computer terminal, or a credit card
Message authentication	Corroborating the source of information, also known as data origin authentication
Signature	Binding information to an entity
Authorization	Providing conveyance, to another entity, of official sanction to do or be something
Validation	Providing timeliness of authorization to use or manipulate information or resources
Access control	Restricting access to resources to privileged entities
Certification	Endorsing information by a trusted entity
Timestamping	Recording the time of creation or existence of information
Witnessing	Verifying the creation or existence of information by an entity other than the creator
Receipt	Acknowledging that information has been received
Confirmation	Acknowledging that services have been provided
Ownership	Providing an entity with the legal right to use or transfer a resource to others
Anonymity	Concealing the identity of an entity involved in some process
Nonrepudiation	Preventing the denial of previous commitments or actions
Revocation	Retracting certification or authorization

Answer 1

CA Hierarchy Design(ca- certification authority)

Since Richman inv. technical support is centralized, and due to the nature of separating Richman inv. offices to child domains under the forest root domain, CA servers will be hosted on the root forest domain and will issue certificates to certificate recipients hosted on child domains.
CA server’s location will be centralized in Richman inv. data centers (Hierarchy by location) because of:

• Each region is connected to Richman inv. data center.
• Business requirements for CA availability in the event of disaster in one data center.
• Localize distribution, management and enrollment of certificates

Defining PKI Management Staff

• CA administrator. Responsible for managing the configuration of the certification authority computer, including defining the CA’s property settings and certificate managers. A user is delegated this role through the assignment of the Manage CA permission at the CA. This rule is given to the infrastructure team in Richman inv. head office.
• CA officer. Responsible for certificate management. Also known as the certificate manager. Tasks include certificate revocation, issuance, and deletion. In addition, the certificate manager extracts archived private keys for recovery by a key recovery agent. A user is given this role through the assignment of the Issue and Manage Certificates permission at the CA. This rule is given to the infrastructure team in Richman inv. head office.
• Backup operator. Responsible for the backup and recovery of the CA database and CA configuration settings. A user is delegated this role through the assignment of the Back Up Files and Directories or the Restore Files and Directories user rights at the Group Policy Object (GPO) assigned to the certification authority server. This rule is given to the IT operations team in Richman inv. head office.
• Auditor. Responsible for defining the events generated on each certification authority server and for reviewing the security logs for events related to PKI management and operations. A user is given this role through the assignment of the Manage Auditing and Security Log user right at the GPO applied to the certification authority server. This role is given security team.

Defining PKI Hardware Resources

Learning how to design a PKI hierarchy involves planing hardware resources. Hardware resources depend on the level of security required and the type/number of PKI applications involved.
Storing the CA keys on Hardware Security Modules (HSM) is the most secure way, but also most expensive ways. At Richman inv., CA keys will be kept on the local computer store, thus eliminating extra cost and providing satisfying level of security.
Offline Root CA is to be hosted on a virtual machine, thus eliminating the need to purchase a new hardware for it. The initial implementation of the Richman inv. PKI project consists of an offline root CA hosted on a virtual machine and another online Policy/Issuing CA server. All CA keys are stored locally by choosing Microsoft CSP to generate the keys.
In summary, hardware resources for the initial implementation are the online issuing CA server hardware since the Offline Root CA will be hosted in a virtual machine. No other issuing CA servers will be installed in the first phase of the PKI implementation.

Number of Tiers

To design a PKI hierarchy involves knowing your PKI tears. Richman inv. IT team has decided that a two-tier PKI topology is the most suitable for their organization. A two-tier hierarchy consists of an offline root CA and one or more issuing CAs. The issuing CA will hold the role of issuing and policy certification authority.

To ensure security in a two-tier hierarchy, root CA is deployed as a standalone root CA. This allows an organization to deploy the root CA offline—that is, the CA is removed from the network to provide the computer with additional security layer.

In a multi-tier CA hierarchy, it does not matter which second-tier CA issues the certificates to computers, users, services, or network devices. All that matter is that the certificate issued by the second-tier CA chains to a trusted root CA—the offline root CA in this configuration.

To enhance the availability of certificate services, two or more issuing CAs must exist at the second tier. This prevents certificate services from being unavailable due to a single point of failure. The number of issuing CAs depends on the organization’s requirements. For example, a CA hierarchy can have different CAs for each geographic region, each sector or business unit, or each identified certificate policy used to validate a certificate’s subject. In the initial implementation, one issuing CA will be installed. Later, other issuing CA servers will be installed.

Choosing an Architecture

In this section of how to design a PKI hierarchy, I will be talking about choosing your architecture, placing your CA server and how to think of validity periods. The more certificates distributed, the more CAs required. A common design places issuing CAs at major hub sites in the network topology to provide regional site availability. This also provides high availability for certificate services, since clustering is not supported for CA servers at the time of writing this post. Having multiple Issuing CAs ensures that the organizations can still issue certificates in case one of the issuing CAs is down. Separating the issuing CAs in geographically separated hubs ensures that a big disaster hitting one hub will not bring the whole PKI system down.

Determining Certificate Validity Periods and renewal strategy

A certificate has a pre-defined validity period that consists of a start date/time, and an end date/time. An issued certificate’s validity period cannot be changed after certificate issuance. Determining the validity period at each tier of the CA hierarchy, including the validity period of the certificates issued to users, computers, services, or network devices, is a primary step when defining a CA hierarchy.

The recommended strategy for determining certificate validity periods is to start with the certificates issued to users, computers, services, or network devices by issuing CAs. The main point to remember is that a CA should not issue a certificate that exceeds the remaining lifetime on the CA certificate (actually the CA will NOT issue certificates with validity period that exceeds the remaining lifetime on the CA certificate). Although allowed by the standards, this scenario can lead to certificates with remaining validity periods to expire when the issuing CA’s certificate expires. It should be ensured that CA has enough remaining lifetime on its certificate to issue certificates with the required validity periods. A good rule of thumb is to make the CA certificate validity period at least twice the validity period of any CA-issued certificates.

In addition to doubling the validity period, we can also follow best practices and ensure that the CA renews its CA certificate value at half of the remaining validity period. The first time we renew an issuing CA certificate (after a period of five years in this scenario), we renew it with the original key pair. After the next five years pass, we renew the CA certificate with a new key pair. This ensures that the same key pair is never used for a period longer than the intended original validity period of 10 years.
Note: Setting the validity period for issued certificates on an issuing CA will determine the maximum validity period for any issued certificate, but this does not mean that any issued certificate will have such maximum validity. CA administrator can define certificate templates that has shorter certificate validity periods.

Example

In this example, an issuing CA has certificate (version 1) valid from t=0 to t=10 and pair of public and private keys called [key pair x]. A CA will renew its certificate (version 2) with the same [key pair x] with validity between t=5 to t=15. CA will renew its certificate again (version 3) with new [key pair Y] with validity between t=10 to to=20.
It is also important to mention that the CA will issue certificates with validity of 5 years which is the half period of the issuing CA certificate validity period.
Let us say that a user got a certificate on t=3, it will be signed with CA [key pair x] and will be valid till t =8. During the period (t=3 to t=8), the certificate can be used since the CA certificate that issued it (version 1) is valid until t=10.
Let us assume also that a user got a certificate on t=7, it will be signed with the CA [key pair x] and will be valid till t =12. During this period (t=7 to t=12), the certificate can be used since the CA certificate that issue it (version 2) is valid until t = 15.
It is important to remember that the CA when renewing its certificate, it keeps the old certificate in its store for the certificates issued with the old one to continue being used during their validity.

In the case of a standalone CA, the definition of a validity period defines the validity period for all CA-issued certificates. In the case of an enterprise CA, the maximum validity period acts as a maximum value for any CA-issued certificates. An issued certificate is always assigned the lesser value of the remaining validity period of the CA certificate and the configured maximum validity period. In other words, if you define the maximum validity period as four years and the CA only has three years remaining in its certificate’s validity period; the validity period of a newly issued certificate is three years.

In the case of an enterprise CA, another variable enters the picture. Enterprise CAs issue certificates based on certificate templates. Each certificate template has its own configured validity period. The applied validity period for certificates issued by an enterprise CA is the minimum value of the CA certificate’s remaining validity period, the CA’s maximum validity period setting, and the certificate template’s validity period.

Let me explain more here, suppose that the CA certificate will expire in 3 years, and the CA is configured via (Certutil.exe utility) with validity period for issued certificate equals to 4 years , and a certain certificate template is configured with validity period of 5 years .The resultant is an issued certificate with 3 years validity!