Setup PKI for new ITAR/CUI environment

This is Part 1 of a multi-Part Post.

Implementing a PKI into your Windows environment should not be taken lightly. If you fail to implement and secure it correctly it can result in the complete compromise of your Windows Active Directory environment, and all connected Azure AD or other environments. It will impact your company reputation, put ITAR/CUI at risk of compromise, and risk U.S. National Security.  

When considering the need for a PKI within your ITAR/CUI environment there are a number of items to ensure you consider.  Similar to Azure Active Directory vs Active Directory Directory Services you need to think through your scenarios before you implement.  

Options for PKI hosting

1. Host your own PKI with Active Directory Certificate Servers (ADCS)
   1. Supports
      1. Intune/JAMF Endpoint Certificates (Windows, MAC, iOS, Android)
      2. Smartcards, PIV, Yubikey
      3. Workstation\Server\Remote Desktop
      4. CodeSigning
      5. SSL/TLS, Kerberos\LDAPs
      6. VPN/802.1x access
      7. Email/SMIME signing
      8. SQL Encryption
   2. Pros
      1. Significant amount of flexibility on cert issuance and lifecycle
      2. Increased amount of certificate types allowed
      3. Allows infrastructure to stay within your infrastructure/network
      4. Additional flexibility on what you do with your certs in the future – Not locked to a PKIaaS provider
      5. Improved integration with Windows ecosystem
   3. Cons
      1. Requires more human skills to manage and secure
      2. Increased risk and cost to manage certificate lifecycles
2. Leverage a PKIaaS (PKI As A Service) from companies like https://digicert.com or https://entrust.com
   1. Supports
      1. Intune/JAMF Endpoint Certificates (Windows, MAC, iOS, Android)
      2. CodeSigning
      3. SSL/TLS, Kerberos\LDAPs
      4. VPN/802.1x access
      5. Email/SMIME signing
   2. Pros
      1. Reduced overhead on managing and securing systems
      2. Scalability of overall infrastructure
   3. Cons
      1. Increased Cost per certificate
      2. Cert requests and signed key infrastructure is cloud hosted
      3. Requires dependable network connection to PKIaaS provider risks outage

How to pick an option

1. Do you have human staff that knows PKI systems?  If not you are best to try to use a PKIaaS.
2. Do you need to issue SmartCards, PIV cards, or integrate with Hello for Business?  – ADCS is probably best option
3. Do you need to maintain an off-line or isolated system that doesn’t transmit sensitive information over internet – ADCS is probably best option

In the rest of this series of posts I will detail how to set an End to End ADCS PKI environment with:

1. Off-Line Root CA with a YubiKey HSM 2
2. Ensure Time syncing is fully setup across Domain systems and a TimeStamp Service
3. On-Line Issuing Enterprise CAs with AzureGov Thales Dedicated HSMs
4. Policies and Controls to minimize risks of compromise

Important setup items

1. Know your company policies, contract obligations, and any regulations/STIGS that apply to your environment.
2. Always have a PAW (Privileged Access workstation) setup before you begin – https://learn.microsoft.com/en-us/security/privileged-access-workstations/privileged-access-devices
3. Ensure you have at least 2 people available when creating key material
4. Only setup your PKI with HSMs from the beginning, do NOT port your keys
5. Always keep your root CA off-line
6. Have a SAFE and Tamper bags to maintain proper physical security and Auditing
7. Be sure your System time is fully in sync across all systems

In this post the intent was to outline how to pick an option of what PKI deployment type to use, define some of the baseline requirements.

In the next post I will cover actually setting things up.