Appendix A Passive Inspection

The example implementation demonstrates the ability to perform passive inspection of encrypted TLS connections. The question of whether or not to perform such an inspection is complex. There are important tradeoffs between traffic security and traffic visibility that each organization should consider. Some organizations prefer to decrypt internal TLS traffic, so it can be inspected to detect attacks that may be hiding within encrypted connections. Such inspection can detect intrusion, malware, and fraud, and can conduct troubleshooting, forensics, and performance monitoring. For these organizations, TLS inspection may serve as both a standard practice and a critical component of their threat detection and service assurance strategies.

The example implementation uses Symantec’s SSL Visibility to perform passive inspection and is one example of how to accomplish passive inspection. The implementation demonstrates how to securely copy private keys from several different TLS servers to the SSL Visibility Appliance. The SSL Visibility Appliance can also securely replace expiring keys on servers—and immediately copy those keys to the SSL Visibility Appliance before expiration—manually and via standardized automated certificate installation.

This appendix discusses how the SSL Visibility Appliance was configured to support passive inspection. The goal was to demonstrate how to provision and revoke TLS certificates in an enterprise environment. To verify this is being done, analysis of the traffic between the TLS clients and the TLS servers was executed. The SSL Visibility Appliance can inspect traffic while located in line between the TLS clients and TLS servers on the network, or it can perform passive observation of all the network traffic between all the clients and servers mirrored to a port accessible to the server. The TLS lab configured its switching fabric to support passive monitoring of traffic utilizing traffic mirroring.

Mirroring the traffic from the virtual TLS lab environment to its physical appliances presented a few challenges. The TLS lab environment is housed within a larger VMWare and physical networking architecture. VMware’s Virtual Distributed Switch Virtual Distributed Switch (VDS) provides a centralized interface for the virtual machines’ access switching in the larger NCCoE environment where the TLS lab lives as a resident. The TLS lab also has its own physical switching connections several routing hops away from the NCCoE datacenter where VMWare resides. The VDS can route traffic internally between multiple labs and virtual machines within each lab. However, VDS does not mirror VMWare’s local east-west traffic between virtual machines to other physical systems outside of the VDS environment. This design limits the traffic that can be mirrored from TLS’ virtual machines that live on VMWare to physical switches in the TLS lab.

To remediate this issue, the NCCoE IT team worked with VMWare senior engineers on a solution. VMware advised the NCCoE IT team to configure remote SPAN (RSPAN) on the VDS. The IT team mapped the traffic to a RSPAN port that resided in a VLAN on an external switch. This external switch connects all the VMWare TLS hosts to the physical TLS lab. An additional RSPAN instance was configured on the TLS lab external switch, which is a physical NCCoE-managed and controlled device connected to all the TLS team-managed and controlled physical internal switches. The external switch was configured to carry the RSPAN traffic to the internal physical access switch in the TLS lab. A SPAN was created on the internal access switch in the TLS lab and configured as source from the RSPAN VLAN. The destination was set to the physical interface connected to the SSL Visibility Appliance.

Network packets captured from VMWare vSphere workloads must be forwarded to the physical remote monitoring appliance; the packet must traverse the switch fabric between the VMWare ESXi cluster and the physical remote monitoring appliance. Two factors must be considered from a solution feasibility perspective:

• Low end switches–Have limitations on how many Remote SPAN sessions can be configured to run concurrently. The switch fabric must establish a Remote SPAN Session between the VMWare ESXi cluster and physical remote monitoring appliance. An alternative solution is to deploy a robust network physical tap in lieu of leveraging the switch fabric between the VMWare ESXi cluster and physical remote monitoring appliance.

• VMWare vSphere workloads–VMWare High Availability Features move from one ESXi host to another, as computer resources are monitored and workloads are rescheduled. This requires the ESXi cluster to automatically re-route the path that captured packets will take from a given VM workload, as it moves from one ESXi host to another when migrated or when rescheduled by Distributed Resource Scheduler to run on another host. The captured packets must egress the ESXi cluster from the specific ESXi host on which the VM workload is running.

Successful deployment of this use case requires selection of the appropriate VMWare vSphere 6.x Port Mirroring configuration option. VMWare vSphere 6.x offers 5 options:

• Distributed Port Mirroring

• Remote Mirroring Source

• Remote Mirroring Destination

• Encapsulated Remote Mirroring (L3) Source

• Distributed Port Mirroring (Legacy)

This use case that depends on the switch fabric having a Remote SPAN configured to pass traffic between the VMWare ESXi cluster and the physical remote monitoring appliance, option 2, Remote Mirroring Source, is the appropriate choice. When configured, this option will establish a Remote SPAN VLAN that will span the VMWare distributed switch. It also utilizes the physical switch fabric and leverages a distributed port group mapped to a pre-selected/pre-configured NIC on each ESXi host in the ESXi cluster. Packets are automatically re-routed from captured VM workloads that are transient between the ESXi hosts in a VMWare vSphere ESXi cluster. When a VM workload moves, vSphere will note the change of the networking state of the VM and automatically re-establish an egress path for captured packets on the NIC of the ESXi host on which the VM is running.

Appendix B Hardening Guidance

Hardening secures systems to reduce their vulnerabilities and minimizes the attack surface, which improves security. To harden the systems, the TLS team implemented the Defense Information Agency’s Security Technical Implementation Guides (STIGs). STIGs are technical configurations applied to systems to maintain their security posture. This hardening guidance provides the baseline standard for a variety of Operating Systems—see the link below to download the STIG guidance:

https://public.cyber.mil/stigs/

NIST’s Security Content Automation Protocol (SCAP) is used to generate compliance reports of the security health of systems. To further strengthen security of systems, use SCAP in conjunction with STIGs. Nessus is another option that can scan for vulnerabilities and misconfigurations.

STIGs are implemented through GPOs that define policy settings for computer and user settings across the network. Configure GPOs in AD to comply with STIGs. Refer to the link below to download the current DISA STIG GPO Package and select those applicable to your environment.

https://public.cyber.mil/stigs/gpo/

Follow the steps below to implement STIGs using GPOs in AD:

1. Open Group Policy Management Console (GPMC):

   1. Go to Start > Administrative Tools > Group Policy Management.

2. Create an OU in the domain:

   1. Go to GPMC > right-click on the <YOUR DOMAIN> > click New Organizational Unit.

   2. In the Name box on the New OU dialog box, type a descriptive name for the OU > click OK.

3. Create a GPO in the domain:

   1. Go to GPMC > <YOUR DOMAIN> > right-click Group Policy Objects > click New.

   2. In New GPO dialog box enter a descriptive name > click OK.

4. Import DISA GPOs:

   1. Go to GPMC > <YOUR DOMAIN> > Group Policy Objects > right-click on the GPO to edit > click Import Settings.

   2. The Import Settings Wizard appears > click Next > select the folder location of the DISA GPO being used. The TLS lab used GPOs for MS Computer, MS User, DC Computer and DC User.

      Note: To apply desired security configurations edit settings in the specific GPO.

5. Edit a GPO in the domain, an OU, or the Group Policy objects folder:

   1. Go to GPMC > <YOUR DOMAIN> > select Group Policy Objects to display all GPOs in the domain.

   2. Right-click the desired GPO > click Edit > the GPO will open in the Group Policy Management Editor (GPME).

   3. In the GPME, edit the Group Policy settings as preferred.

6. Link a GPO to a domain or OU:

   1. Go to GPMC> right-click <YOUR DOMAIN> or OU to link to the GPO > click Link an Existing GPO.

   2. The Select GPO dialog box appears - > select the GPO you want linked to the domain or OU > click OK.

   *Shortcut: Drag the GPO from the Group Policy Objects folder and drop it onto the OU you want it linked to.

7. Optional:

   • Unlink a GPO from a domain or OU:

     1. Go to GPMC > click <YOUR DOMAIN> or OU containing the GPO you want to unlink.

     2. Right-click the GPO > click Delete.

     3. In the Group Policy Management dialog box, confirm deletion and click OK.

        Note: Unlink a GPO when it no longer applies. Unlinking a GPO from a domain or OU does not delete the GPO—it deletes the link. After unlinking the GPO, you can still find it in the Group Policy Objects folder.

   • Add computer to OU:

     1. Go to Start > Administrative Tools > Active Directory Users and Computers.

     2. Click on <YOUR DOMAIN> > refresh. The newly added OU will appear.

     3. Go to Computers > right-click the desired computer > click Move.

     4. Select the desired OU to move the computer to > click OK.

     5. To apply new settings > log out and log back in.

Appendix C Venafi Underlying Concepts

The following background information may help users better understand some of the configurations we made in the configuration management databases (CMDBs) implementation of Venafi TPP.

Venafi TPP is one machine identity protection platform that enables enterprises to address TLS server certificate security and operational risks. Venafi TPP served as the certificate management platform for the TLS lab.

The following diagram illustrates the process of architecting, deploying, configuring, and using Venafi TPP to manage certificates and keys in enterprises.

Venafi TPP interfaces with a variety of different types of systems and people/groups, including:

1. Venafi TPP Database: Venafi TPP requires a database to store certificates, private keys, and configuration information (all private keys and credentials are encrypted prior to storage in the database). Venafi TPP supports the use of Microsoft SQL Server to host its database.

2. HSM: Stores and protects the symmetric key used to encrypt private keys and credentials in the Venafi TPP database.

3. Identity Directory: Venafi TPP integrates with identify management systems such as AD, LDAP directories, or proprietary directories, and enables the use of existing user accounts and groups.

4. CAs: Venafi TPP integrates supports direct integration with over two dozen public and private CAs for the automated enrollment, renewal, and revocation of certificates.

5. SIEM/Email/Ticketing: Venafi TPP integrates with SIEM systems to pass certificate and cryptographic key event information. It integrates with ticketing systems for the automated creation of change tickets and approvals and with email systems for the notifications to certificate owners for impending expirations or errors.

6. Other Enterprise Systems: Venafi TPP can be integrated with a variety of other enterprise systems, such as CMDBs, enterprise dashboards, and custom applications.

7. Systems with Certificates: Venafi TPP communicates directly with systems with certificates to automatically discover and manage those certificates.

8. Certificate Services Team: This team manages the Venafi TPP servers and supports Certificate Owners.

9. Certificate Owners: These are groups and individuals responsible for systems where certificates are deployed using Venafi TPP for automating a variety of functions, including scanning, inventory, enrollments, and installation of certificates.

The following diagram is a high-level view of these components.

Depending on an organization’s needs, it’s possible to deploy one or more Venafi TPP servers centrally or distributed in different network zones as well as different geographies. The number and placement of Venafi TPP servers is an important step to create an effective certificate management solution that supports the environmental and operational needs of an enterprise. The criteria driving the number and placement of Venafi TPP servers includes:

1. Venafi TPP Services: Each Venafi TPP can host one or more services, including network discovery scanning, certificate enrollment, certificate installation, administrative UI, etc. Depending on the size and structure of an organization, these services can be deployed on a single Venafi TPP server or, more likely, across multiple servers. The services that a Venafi TPP server can be configured to perform include:

   1. Hosting administrative and user interfaces

   2. Network discovery scanning

   3. Onboard discovery

   4. CA import

   5. Certificate expiration monitoring

   6. Certificate operation monitoring (validation)

   7. Automated certificate enrollment

   8. Agentless certificate installation

   9. Agent management

   10. CRL expiration monitoring

   11. Revocation status monitoring

   12. Report generation

   13. Venafi TPP REST API access

   14. Log event management and notifications

   15. Trust store management

2. Load and Performance Requirements: The number of certificates and systems that must be managed by Venafi TPP plays an important part in the choice of how many Venafi TPP servers to deploy. Venafi TPP is a based on a load-balanced architecture that enables multiple servers to share in the processing of work.

3. Fault Tolerance: Due to the critical role of certificate management, deployment architectures may include multiple Venafi TPP servers deployed across primary and disaster recovery sites to ensure continuous availability of certificate management services.

4. Network Zones and Boundaries: Network architectures often place limits on the type of traffic that can traverse between network zones (across firewalls). For example, a firewall may limit the allowed ports between two network zones, necessitating the placement of a Venafi TPP server directly inside a network zone to enable network discovery scans to run.

5. Geographic Distribution: Organizations are often distributed across multiple cities, states, countries, and continents. Ensuring that network latencies do not negatively impact the performance of certificate management services at each geographic location often involves distributing Venafi TPP servers near the systems and certificates being managed.

C.1 Venafi TPP Object Model

To understand how Venafi TPP maintains inventory information, first review the Venafi TPP data model. Venafi TPP uses an object-based storage model where configuration information for certificates, associated devices, and applications are stored as objects and attributes in the Venafi TPP database. Several different object types exist in Venafi TPP—each of which includes associated attributes that store data relevant to the object. For example, a certificate object includes attributes for issuer, key length, common name, organization, etc.

The object types in Venafi TPP include:

1. Folder: Folders are containers that facilitate the hierarchical organization certificates, devices, applications, and other objects within Venafi TPP.

2. Certificate: These objects hold configuration data for certificates managed by Venafi TPP, including certificate authority (CA), key length, certificate owner, approver, and other information. A certificate object can have one or more applications objects—each indicating a location where the certificate is installed.

3. Device: These objects hold configuration information about the systems where certificates are deployed, including the network address and port, authentication credentials, and other information for the system.

4. Application: These objects hold information about the specific application (e.g., Apache, F5, Java, etc.) that uses a certificate on a device. Each device may have one or more applications that use certificates. The attributes and information stored in an application object depends on the type of application. For example, an F5 application object stores information such as the SSL profile, virtual server, and partition for the associated certificate on the F5 device.

5. Workflow: Workflow objects store the rules that are enforced for workflow gates within Venafi TPP. They include the stage of the certificate lifecycle where approval is needed, the required approvers, and even actions that may be automatically perform when the workflow gate is triggered.

6. CA Template: These objects store information about CAs from which Venafi TPP requests certificates and the specific certificate templates that the CAs will use.

7. Credential: These objects hold credential information that Venafi TPP uses to authenticate to other systems, including CAs, systems where certificates are managed via agentless management, etc. Passwords and private keys used in credentials are stored in encrypted form in the Venafi TPP database.

C.2 Certificate Metadata in Venafi TPP

Certificates are stored in Venafi TPP in binary form (i.e., the DER encoded version of the certificate). In addition, the individual X.509 fields and extensions of each certificate are parsed and stored in unique database fields, to enable rapid searching and filtering. The certificate fields parsed and stored for rapid searching in Venafi TPP include:

• X.509 Version: V1, V2, or V3

• Serial Number: A unique identifier assigned by the issuing certificate authority

• Issuer Distinguished Name: The full X.500 distinguished name of the issuing-CA.

• Valid From: The date and time from which the certificate was issued. This is commonly referred to as an issue date.

• Valid To: The date and time after which the certificate should no longer be considered valid. This is commonly referred to as the expiration date.

• Subject Distinguished Name (SAN): The full X.500 distinguished name for the subject of the certificate (the entity to which the certificate was issued)—for example: “CN = iis2.int-nccoe.org, O = NCCOE, L = Gaithersburg, S = Maryland, C = US”.

• Subject Alternative Names: One or more identifiers for the subject of the certificate (the entity to which the certificate was issued). There could be additional DNS host names (e.g., server1.int-nccoe.org), IP address, or other types of identifiers.

• Signature Algorithm: The asymmetric and hashing algorithms that sign the certificate (e.g., sha256RSA).

• Subject Key Identifier: A unique identifier for the public key within the certificate. Because the public and private key are inextricably associated, this identifier applies to both of them.

• Authority Key Identifier: A unique identifier for the public/private key that the certificate authority uses to sign the certificate.

• CRL Distribution Points: One or more addresses where the CRL for the CA that issued the certificate can be retrieved.

• AIA: The location(s) where information and services, such as where to retrieve the CA certificate chain or access online certificate status protocol for the CA that issued the certificate.

• Key Usage: Defines the purposes for which the key within the certificate can be used, including digital signature, key encipherment, and key agreement.

• Enhanced Key Usage: Defines the purposes for which the certified public key within the certificate may be used, including server authentication, client authentication, and code signing.

• Basic Constraints: Defines whether the subject of the certificate is a CA and the maximum depth of certification path (number of CAs below this CA allowed).

• Policy: Policies defined within the certificate.

• Key Size: The length of the public key in the certificate.

In addition to certificate field and extension information, Venafi TPP stores other metadata relevant to each certificate, including:

• Certificate Owner(s): Groups and/or individual assigned to manage and receive notifications (e.g., expiration notices, processing errors, etc.) for the certificate

• Approver(s): Groups and/or individuals assigned to approve operations for the certificate

• Processing Status: Indicates whether the certificate processing is proceeding normally, is in error, or has completed

• Processing Stage: The current stage of processing (e.g., creating CSR, retrieving certificate from CA, installing certificate) for the certificate

• Last Network Validation Time & Date: The last date and time a network validation was performed to determine the operational status of the certificate

• Network Validation Status: The result of last network validation

• Installation Location(s): The devices and applications where the certificate is installed

• CA Chain: The chain of CA certificates from the root to the TLS server certificate

• Management Method: Determines if the certificate should be automatically enrolled and installed, or manually enrolled and installed

• Log Information: Logs of all administrative changes and automated operations performed on the certificate via Venafi TPP

C.3 Custom Fields

With thousands of certificates, it is critical that organizationally-relevant information—such as cost center, application identifiers, business unit, and applicable regulations—can be associated with certificates. As a result, searches and reporting can return the certificates most relevant to a particular group or business function. Venafi TPP supports the definition of “custom fields” that can be assigned to certificates. The value of the custom fields (e.g., Cost Center = “B123”) can be assigned to individual certificates or folders, thereby flowing down and applying to all subordinate certificates. It should be noted that custom fields can be assigned to other assets such as devices associated with certificates.

C.3.1 Organizing Certificate Inventory

Many large enterprises have thousands or tens of thousands of certificates, often with hundreds of certificate owners across many different groups. To help effectively manage certificates across these broad environments, Venafi TPP enables the creation of a hierarchical folder structure where certificates and associated system configuration information can be placed.

The design of a Venafi TPP folder hierarchy for the organization of certificates is dependent on the needs and requirements of an enterprise—similar to having multiple approaches to create folder hierarchies when organizing files. However, through experience in working with many large enterprises, Venafi professional services has developed a set of guidelines, including:

• Certificate Ownership: The primary factor for designing a Venafi TPP hierarchy is based on the organization of certificate owners. Once a folder is assigned to a certificate owner, certificates and other assets placed within the folder automatically inherit the permissions, contacts, and approvers, so that ownership does not need to be managed on individual certificates (though ownership information can be managed on individual certificates in Venafi TPP, if necessary).

• Policies: Policies such as allowed key lengths, signing algorithms, and CAs are an important consideration in the organization of Venafi TPP folders.

• Workflow and Approvals: Workflow rules are assigned at the folder level in Venafi TPP. If an enterprise applies different workflow rules across their organizational groups, the design of the folder hierarchy may be adjusted to easily assign those rules as needed.

C.3.2 Policy Enforcement

Venafi TPP supports the enforcement of written policies through the assignment of policies to any folder within the hierarchy. It is possible to define Venafi TPP policies for a broad set of areas, including allowed CAs, allowable domains, certificate contents (e.g., key length), approvers, and application configurations.

Policies set on a folder flow down to subordinate folders and objects within the folders. This makes it possible to configure group-specific policies on folders assigned to those groups and policies with broader applicability to higher level folders, so that they apply to all certificates, devices, applications across subordinate folders. Policies can be set as suggested, to provide a default value that users are able to change if desired, or enforced, where users are required to use the set value.

C.4 The Domain Allowlist

Because certificates serve as trusted credentials, they should only be issued for authorized domains. To aid in this, Venafi TPP supports establishing allowlists of domains that can be used in certificates. For example, it is possible to only allow common names (CNs) and subject alternative names (SANs) that have the suffix “.int-nccoe.org”, which only allow CNs and SANs such as server1.int-nccoe.org and server2.ops.int-nccoe.org.

C.4.1 Certificate Owner Assignment

The assignment and maintenance of certificate ownership is critical to prevent outages and respond to security incidents. Depending on the size of groups and the number certificates they manage, certificate management responsibilities may be assigned to one person or distributed among several different individuals. For larger groups managing greater numbers of certificates across a broad set of systems, the roles may vary for each team member. For example, a core group of technical people may be responsible for managing the configuration of certificates. That same group plus a manager may need to receive alerts and reports. To accommodate these differences in roles, Venafi TPP enables the assignment of permissions and contact information (for sending alerts) at the certificate or folder level.

C.4.2 Permissions

In Venafi TPP, groups and individual users can be granted permissions to folders and individual objects (e.g., certificates). Venafi TPP can assign the following permissions:

• View: See an object in a folder and select it (but not see its configuration parameters). For example, an administrator with view rights to an application can associate that application to a certificate for which they are responsible.

• Read: Read an object’s configuration parameters and status.

• Write: Edit an object’s configuration parameters.

• Create: Create new objects under the object to which the Create permission is assigned. Applies only to objects that contain other objects.

• Delete: Delete the specified object or objects contained within it (unless blocked below).

• Rename: Rename the object.

• Revoke: Revoke a certificate. This only applies to certificates only but can be set on policies, devices, or applications for any certificates contained under them.

• Associate: Associate a certificate to one or more applications from within that certificate object.

• Admin: Grant users or groups permissions to the object.

• Private-Key Read: Retrieve the private-key for a certificate only applies to certificates but can be set on policies, devices, or applications for any certificates contained under them.

• Private-Key Write: Upload or overwrite the private-key for a certificate. This only applies to certificates but can be set on policies, devices, or applications for any certificates contained within them. The private-key write privilege is required for an administrator to extract a private-key and certificate from an application to be stored in the Venafi TPP database.

• Permissions: Permissions assigned to a folder are inherited subordinate objects and folders. Wherever possible, it’s a best practice to assign permissions to groups to quickly grant a new team member the needed permissions simply by being added to the group. It is also best to assign permissions at the folder level, applying to all subordinate certificates. When a new system and certificate are needed, they can be added within the folder and the permissions automatically apply.

C.4.3 Contacts

Effectively managing certificates in an enterprise requires the ability to automatically notify the certificate owners of impending expirations, errors, or other events that affect their certificates. It’s possible to assign one or more groups or individuals as “contacts” to folders or individual objects in Venafi TPP. Contact assignment to folders are inherited by the objects below them.

Appendix D List of Acronyms

ACME	Automated Certificate Management Environment
AD	Active Directory
ADCS	Active Directory Certificate Services
ADS	Active Directory Services
AIA	Authority Information Access
API	Application Programming Interface
CA	Certificate Authority
CAPI	Cryptographic Application Programming Interface (also known variously as CryptoAPI, Microsoft Cryptography API, MS-CAPI or simply CAPI)
CDP	CRL Distribution Point
CEP	Certificate Enrollment Policy
CES	Certificate Enrollment Service
CMDB	Configuration Management Database
CN	Common Name
CNG	Cryptography API: Next Generation
CPU	Central Processing Units
CRL	Certificate Revocation List
CSR	Certificate Signing Request
DB	Database
DC	Domain Controller
DevOps	Development Operations
DMZ	Demilitarized Zone
DNS	Domain Name System
EULA	End User License Agreement
EV	Extended Validation
FIPS	Federal Information Processing Standards
FQDN	Fully Qualified Domain Name
GPMC	Group Policy Management Console
GPO	Group Policies Objects
HSM	Hardware Security Module
HTML	Hypertext Markup Language
http	Hypertext Transfer Protocol
https	Hypertext Transfer Protocol Secure
IdP	Identity Provider
IETF	Internet Engineering Task Force
IIS	Internet Information Server (Microsoft Windows)
IMAP	Internet Message Access Protocol
IP	Internet Protocol
IT	Information Technology
ITL	Information Technology Laboratory
KSP	Key Storage Provider
LDAP	Lightweight Directory Access Protocol
LTM	Local Traffic Manager (F5)
MSQL	Microsoft SQL
MTA	Mail Transfer Agent
MUA	Mail User Agent
NAT	Network Address Translation
NCCoE	National Cybersecurity Center of Excellence
NIST	National Institute of Standards and Technology
NTL	Network Trust Link
NTLS	Network Trust Link Service
OS	Operating System
OVA	Open Virtualization Appliance
OVF	Open Virtualization Format
PCI-DSS	Payment Card Industry Data Security Standard
PED	PIN Entry Device
PIN	Personal Identification Number
PKI	Public Key Infrastructure
PSCP	PuTTY Secure Copy Protocol
RA	Registration Authority
RAM	Random Access Memory
REST	Representational State Transfer (API)
RHEL	Red Hat Enterprise Linux
RMF	Risk Management Framework
RSA	Rivest, Shamir, & Adleman (public key encryption algorithm)
RSPAN	Remote Switched Port Analyzer
Thales TCT	Thales Trusted Cyber Technologies
SAN	Subject Alternative Name
SCAP	Security Content Automation Protocol
SCEP	Simple Certificate Enrollment Protocol
SCP	Secure Copy Protocol
SIEM	Security Information and Event Management
SMTP	Simple Mail Transfer Protocol
SOAP	Simple Object Access Protocol
SP	Special Publication
SPAN	Switched Port Analyzer
SQL	Structured Query Language
SSL	Secure Socket Layer (protocol)
SSL VISIBILITY	SSL Visibility (Symantec Appliance)
STIGs	Security Technical Implementation Guides
TCP	Transmission Control Protocol
TLS	Transport Layer Security (protocol)
TMSH	Traffic Management Shell
TPP	Trust Protection Platform (Venafi)
UCS	User Configuration Set
UDP	User Datagram Protocol
UPN	User Principal Name
URL	Uniform Resource Locator
VDS	Virtual Distributed Switch
VE	Virtual Edition
VLAN	Virtual Local Area Network
WinRM	Windows Remote Management

Appendix E Glossary

Active Directory	A Microsoft directory service for the management of identities in Windows domain networks.
Application	1. The system, functional area, or problem to which information technology (IT) is applied. The application includes related manual procedures as well as automated procedures. Payroll, accounting, and management information systems are examples of applications. (NIST SP 800-16 ) 2. A software program hosted by an information system. (NIST SP 800-137)
Authentication	Verifying the identity of a user, process, or device, often as a prerequisite to allowing access to a system’s resources. (NIST SP 800-63-3)
Automated Certificate Management Environment	A protocol defined in IETF RFC 8555 that provides for the automated enrollment of certificates.
Certificate	A set of data that uniquely identifies an entity, contains the entity’s public key and possibly other information, and is digitally signed by a trusted party, thereby binding the public key to the entity. Additional information in the certificate could specify how the key is used and its validity period. (NIST SP 800-57 Part 1 Rev. 4 [D3] under Public-key certificate) (Certificates in this practice guide are based on (.)
Certificate Authority	A trusted entity that issues and revokes public key certificates. (NISTIR 8149)
Certificate Chain	An ordered list of certificates that starts with an end-entity certificate, includes one or more certificate authority (CA) certificates, and ends with the end-entity certificate’s Root CA certificate, where each certificate in the chain is the certificate of the CA that issued the previous certificate. By checking to see if each certificate in the chain was issued by a trusted CA, the receiver of an end-user certificate can determine whether it should trust the end-entity certificate by verifying the signatures in the chain of certificates.
Certificate Management	Process whereby certificates (as defined above) are generated, stored, protected, transferred, loaded, used, and destroyed. (CNSSI 4009-2015) (In the context of this practice guide, it also includes inventory, monitoring, enrolling, installing, and revoking.)
Certificate Revocation List	A list of digital certificates that have been revoked by an issuing CA before their scheduled expiration date and should no longer be trusted.
Certificate Signing Request	A request sent from a certificate requester to a CA to apply for a digital identity certificate. The certificate signing request contains the public key as well as other information to be included in the certificate and is signed by the private key corresponding to the public key.
Client	1. A machine or software application that accesses a cloud over a network connection, perhaps on behalf of a consumer. (NIST SP 800-146) 2. A function that uses the PKI to obtain certificates and validate certificates and signatures. Client functions are present in CAs and end entities. Client functions may also be present in entities that are not certificate holders. That is, a system or user that verifies signatures and validation paths is a client, even if it does not hold a certificate itself. (NIST SP 800-15)
Cloud Computing	A model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. (NIST SP 800-145)
Common Name	An attribute type commonly found within a Subject Distinguished Name in an X.500 directory information tree. When identifying machines, it is composed of a fully qualified domain name or IP address.
Configuration Management	A collection of activities focused on establishing and maintaining the integrity of IT products and information systems, through control of processes for initializing, changing, and monitoring the configurations of those products and systems throughout the system development life cycle. (NIST SP 800-53 Rev. 4)
Container	A method for packaging and securely running an application within an application virtualization environment. Also known as an application container or a server application container. (NIST SP 800-190 )
Cryptographic Application Programming Interface	An application programming interface (API) included with Microsoft Windows operating systems that provides services to enable developers to secure Windows-based applications using cryptography. While providing a consistent API for applications, the Cryptographic Application Programming Interface (CAPI) allows for specialized cryptographic modules (cryptographic service providers) to be provided by third parties, such as Hardware Security Module (HSM) manufacturers. This enables applications to leverage the additional security of HSMs while using the same APIs they use to access built-in Windows cryptographic service providers. (Also known variously as CryptoAPI, Microsoft Cryptography API, MS-CAPI or simply CAPI)
Cryptography API: Next Generation	The long-term replacement for the CAPI.
Demilitarized Zone	A perimeter network or screened subnet separating a more-trusted internal network from a less-trusted external network.
Development Operations (DevOps)	A set of practices for automating the processes between software development and IT operations teams, so they can build, test, and release software faster and more reliably. The goal is to shorten the systems development life cycle and improve reliability while delivering features, fixes, and updates frequently in close alignment with business objectives.
Digital Certificate	Certificate (as defined above).
Digital Signature	The result of a cryptographic transformation of data that, when properly implemented, provides origin authentication, assurance of data integrity and signatory non-repudiation. (NIST SP 800-133)
Digital Signature Algorithm	A Federal Information Processing Standard for digital signatures, based on the mathematical concept of modular exponentiations and the discrete logarithm problem. (FIPS 186-4)
Directory Service	A distributed database service capable of storing information, such as certificates and CRLs, in various nodes or servers distributed across a network. (NIST SP 800-15 ) (In the context of this practice guide, a directory services stores identity information and enables the authentication and identification of people and machines.)
Distinguished Name	An identifier that uniquely represents an object in the X.500 directory information tree. (RFC 4949 Ver 2)
Domain	A distinct group of computers under a central administration or authority.
Domain Name	A label that identifies a network domain using the Domain Naming System.
Domain Name System	The system by which Internet domain names and addresses are tracked and regulated as defined by IETF RFC 1034 and other related RFCs.
Extended Validation (EV) Certificate	A certificate used for https websites and software that includes identity information, subjected to an identity verification process standardized by the CA Browser Forum in its Baseline Requirements which verifies the identified owner of the website for which the certificate has been issued has exclusive rights to use the domain; exists legally, operationally, and physically; and has authorized the issuance of the certificate.
Federal Information Processing Standards (FIPS)	A standard for adoption and used by federal departments and agencies that has been developed within the Information Technology Laboratory (ITL) and published by the National Institute of Standards and Technology, a part of the U.S. Department of Commerce. A FIPS covers some topic in IT to achieve a common level of quality or some level of interoperability. (NIST SP 800-161)
Hardware Security Module (HSM)	A physical computing device that provides tamper-evident and intrusion-resistant safeguarding and management of digital keys and other secrets, as well as crypto-processing. (FIPS 140-2) specifies requirements for HSMs.
Host Name	Host names are most commonly defined and used in the context of DNS. The host name of a system typically refers to the fully qualified DNS domain name of that system.
Hypertext Transfer Protocol (HTTP)	A standard method for communication between clients and Web servers. (NISTIR 7387)
Internet Engineering Task Force (IETF)	The internet standards organization made up of network designers, operators, vendors, and researchers that defines protocol standards (e.g., IP, TCP, DNS) through process of collaboration and consensus.
Internet Message Access Protocol	A method of communication used to read electronic mail stored in a remote server. (NISTIR 7387)
Internet Protocol (IP)	The IP, as defined in IETF RFC 6864, is the principal communications protocol in the IETF Internet protocol suite for specifying system address information when relaying datagrams across network boundaries.
Lightweight Directory Access Protocol (LDAP)	The LDAP is a directory access protocol. In this document, LDAP refers to the protocol defined by RFC 1777, which is also known as LDAP V2. LDAP V2 describes unauthenticated retrieval mechanisms. (NIST SP 800-15)
Microservice	A set of containers that work together to compose an application. (NIST SP 800-190)
Organization	An entity of any size, complexity, or positioning within an organizational structure (e.g., a federal agency or, as appropriate, any of its operational elements). (NIST SP 800-39) This publication is intended to provide recommendations for organizations that manage their own networks (e.g., that have a chief information officer).
Outage	A period when a service or an application is not available or when equipment is not operational.
Payment Card Industry Data Security Standard	An information security standard administered by the Payment Card Industry Security Standards Council that is for organizations that handle branded credit cards from the major card schemes.
PIN Entry Device	An electronic device used in a debit, credit or smart card-based transaction to accept and encrypt the cardholder’s personal identification number.
Post Office Protocol	A mailbox access protocol defined by IETF RFC 1939. POP is one of the most commonly used mailbox access protocols. (NIST SP 800-45 Version 2)
Private Key	The secret part of an asymmetric key pair that is used to digitally sign or decrypt data. (NIST SP 800-63-3)
Public CA	A trusted third party that issues certificates as defined in IETF RFC 5280. A CA is considered public if its root certificate is included in browsers and other applications by the developers of those browsers and applications. The CA/Browser Forum defines the requirements public CAs must follow in their operations.
Public Key	The public part of an asymmetric key pair that is used to verify signatures or encrypt data. (NIST SP 800-63-3)
Public Key Cryptography	Cryptography that uses separate keys for encryption and decryption; also known as asymmetric cryptography. (NIST SP 800-77)
Public Key Infrastructure (PKI)	The framework and services that provide for the generation, production, distribution, control, accounting, and destruction of public key certificates. Components include the personnel, policies, processes, server platforms, software, and workstations used for the purpose of administering certificates and public-private key pairs, including the ability to issue, maintain, recover, and revoke public key certificates. (NIST SP 800-53 Rev. 4)
Registration Authority	An entity authorized by the certification authority system (CAS) to collect, verify, and submit information provided by potential Subscribers which is to be entered into public key certificates. The term RA refers to hardware, software, and individuals that collectively perform this function. (CNSSI 4009-2015)
Representational State Transfer (REST)	A software architectural style that defines a common method for defining APIs for web services.
Risk Management Framework	The Risk Management Framework (RMF), presented in NIST SP 800-37, provides a disciplined and structured process that integrates information security and risk management activities into the system development life cycle.
Rivest, Shamir, & Adleman (RSA)	An algorithm approved in [FIPS 186] for digital signatures and in [SP 800-56B] for key establishment. (NIST SP 800-57 Part 1 Rev. 4 )
Root certificate	A self-signed certificate, as defined by IETF RFC 5280, issued by a root certificate authority. A root certificate is typically securely installed on systems, so they can verify end-entity certificates the receive.
Root certificate authority	In a hierarchical public key infrastructure (PKI), the CA whose public key serves as the most trusted datum (i.e., the beginning of trust paths) for a security domain. (NIST SP 800-32)
Subject Alternative Name	A field in an X.509 certificate that identifies one or more fully qualified domain names, IP addresses, email addresses, URIs, or UPNs to be associated with the public key contained in a certificate.
Simple Certificate Enrollment Protocol (SCEP)	A protocol defined in an IETF internet draft specification that is used by numerous manufacturers of network equipment and software who are developing simplified means of handling certificates for large-scale implementation to everyday users, as well as referenced in other industry standards.
Secure Hash Algorithm 256	A hash algorithm that can be used to generate digests of messages. The digests are used to detect whether messages have been changed since the digests were generated. (FIPS 180-4 [March 2012])
Secure Transport	Transfer of information using a transport layer protocol that provides security between applications communicating over an IP network.
Server	A computer or device on a network that manages network resources. Examples include file servers (to store files), print servers (to manage one or more printers), network servers (to manage network traffic), and database servers (to process database queries). (NIST SP 800-47)
Service Provider	A provider of basic services or value-added services for operation of a network; ­generally refers to public carriers and other commercial enterprises. (NISTIR 4734)
Simple Mail Transfer Protocol (SMTP)	The primary protocol used to transfer electronic mail messages on the internet. (NISTIR 7387)
Special Publication	A type of publication issued by NIST. Specifically, the Special Publication 800-series reports on the ITL’s research, guidelines, and outreach efforts in computer security, and its collaborative activities with industry, government, and academic organizations. The 1800 series reports the results of NCCoE demonstration projects.
System Administrator	Individual responsible for the installation and maintenance of an information system, providing effective information system utilization, adequate security parameters, and sound implementation of established Information Assurance policy and procedures. (CNSSI 4009-2015)
Team	A number of persons associated together in work or activity. (Merriam Webster) As used in this publication, a team is a group of individuals assigned by an organization’s management the responsibility to carry out a defined function or set of defined functions. Designations for teams as used in this publication are simply descriptive. Different organizations may have different designations for teams that carry out the functions described herein.
Transport Layer Security (TLS)	An authentication and security protocol widely implemented in browsers and web servers. TLS is defined by RFC 5246 and RFC 8446.
Trust Protection Platform (TPP)	The Venafi Machine Identity Protection platform used in the example implementation described in this practice guide.
User Principal Name	In Windows Active Directory, this is the name of a system user in email address format, i.e., a concatenation of username, the “@” symbol, and domain name.
Validation	The process of determining that an object or process is acceptable according to a pre-defined set of tests and the results of those tests. (NIST SP 800-152)
Web Browser	A software program that allows a user to locate, access, and display web pages.

Appendix F References

D1

U.S. Department of Commerce, Security Requirements for Cryptographic Modules, Federal Information Processing Standards (FIPS) Publication 140-2, (including change notices as of 12-03-2002). https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-2.pdf.

D2

Joint Task Force Transformation Initiative, Security and Privacy Controls for Information Systems and Organizations, Draft NIST Special Publication (SP) 800-53 Revision 5, August 2017. https://csrc.nist.gov/CSRC/media//Publications/sp/800-53/rev-5/draft/documents/sp800-53r5-draft.pdf.

D3

E. Barker, Recommendation for Key Management: Part 1: General, NIST Special Publication (SP) 800-57 Part 1, Revision 4, January 2016. http://doi.org/10.6028/NIST.SP.800-57pt1r4.

D4

Framework for Improving Critical Infrastructure Cybersecurity, Version 1.1, National Institute of Standards and Technology, April 16, 2018. See https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.04162018.pdf.

D5

T. Dierks, E. Rescorla, The Transport Layer Security (TLS) Protocol Version 1.2, RFC 5246, Internet Engineering Task Force, August 2008. https://www.ietf.org/rfc/rfc5246.txt.

Appendix G Supplemental Architecture Configurations

G.1 Mail Server Configuration Files

The Postfix mail server and Dovecot mail client were both used to create an alert and administrative email server for all alerts received from the various TLS security components used in the TLS lab. The main.cf is the primary configuration file for Postfix and the dovecot.conf is used to configure the Dovecot mail user agent. Links to both files used in the TLS lab are provided below as a quick start to setting up the same mail server and client used in the TLS lab. The main.cf and dovecot.conf files are stored in the same repository as this Volume D document on the NCCoE web page.

• https://www.nccoe.nist.gov/sites/default/files/library/supplemental-files/sp1800-16/main.cf

• https://www.nccoe.nist.gov/sites/default/files/library/supplemental-files/sp1800-16/dovecote.conf