From 96a26fcaf3898a9ca77b9f71c691ab41d2b14800 Mon Sep 17 00:00:00 2001 From: Ken Myers <61115074+idmken@users.noreply.github.com> Date: Thu, 7 Sep 2023 13:49:46 -0400 Subject: [PATCH 01/80] Update 404.html updated list of hyperlinks based on search.gov results --- 404.html | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/404.html b/404.html index 59b9f50a5..28a5220ef 100644 --- a/404.html +++ b/404.html @@ -12,7 +12,14 @@

Page not found

We’re sorry; we can’t find the page you're looking for. It might have been removed, had its name changed, or is otherwise unavailable.

-

If you typed the URL directly, check your spelling and capitalization. Our URLs look like this: www.idmanagement.gov/content-area.

+

If you typed the URL directly, check your spelling and capitalization. Our URLs look like this: www.idmanagement.gov/content-area. For example: +

+

Visit our homepage for helpful tools and resources, use our search bar in the upper right, submit an issue, or contact us and we’ll point you in the right direction.

-# Introduction +## Introduction These Windows Domain configuration guides will help you configure your Windows _network domain_ for smart card logon using PIV credentials. @@ -89,7 +89,7 @@ Submit an [Issue]({{site.repourl}}/issues/new){:target="_blank"}{:rel="noopener -# Step 1 - Network Ports and Protocols +## Step 1 - Network Ports and Protocols Your workstations, servers, network domain controllers, and applications need to validate the [revocation status]({{site.baseurl}}/university/pki/#revocation-checking) of the PIV certificates and all intermediate certificate authority (CA) certificates. In addition, the [certificate chain]({{site.baseurl}}/university/pki/#establishing-trust) path building may retrieve and download the intermediate CA certificates. @@ -163,7 +163,7 @@ To enable communications with these Federal Common Policy Certificate Authority You should consider allowing two protocols (ports): HTTP (80) and DNS (53). Although the web services for publishing CRLs are not currently served over HTTPS (443), you may want to allow HTTPS (443) to future proof for any expansion. -# Step 2 - Domain Controllers +## Step 2 - Domain Controllers To use smart cards and PIV credentials for network authentication, all domain controllers need to have domain controller authentication certificates. @@ -209,11 +209,11 @@ Collaborate with your CISO or Information Security Office for a definitive answe If you do have a local enterprise CA, [here are some tips](#step-7---local-certificate-authority). -# Step 3 - Trust Stores +## Step 3 - Trust Stores Follow [Step 3 - Distribute to Operating System from the distribute FCPCA configuration guide]({{site.baseurl}}/implement/trust-fcpca/#step-2---distribute-to-operating-systems). -# Step 4 - Account Linking +## Step 4 - Account Linking *Account linking* refers to the process of associating a certificate on a user's PIV credential with their domain account. @@ -373,7 +373,7 @@ It's possible to revert to UPN account linking by removing the registry setting Use group policy objects or other centralized management options to manage registry options. -# Step 5 - Group Policies and Enforcement +## Step 5 - Group Policies and Enforcement The U.S. federal government publishes the [United States Government Configuration Baseline (USGCB)](http://usgcb.nist.gov/usgcb_content.html){:target="_blank"}{:rel="noopener noreferrer"}{:class="usa-link usa-link--external"} for use by Executive Branch agencies to promote uniform configurations for commonly used operating systems. The USGCB configuration guidelines for specific operating systems include references to some configurations related to smart card (PIV) logon and should be referenced first. @@ -429,7 +429,7 @@ These prompts happen when the kerberos ticket lifetime expires and a new authent You can find additional information on configuring kerberos policies given the following [reference documentation](https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/maximum-lifetime-for-user-ticket){:target="_blank"}{:rel="noopener noreferrer"}{:class="usa-link usa-link--external"}. -# Step 6 - Network Tuning +## Step 6 - Network Tuning You can tune the network domain settings to help you and your users have a better experience and reduce errors. This section highlights some of the _common_ tuning configurations for network domain logon. There are additional tuning configurations and we encourage you to start with these first and contribute others. @@ -473,7 +473,7 @@ By default, Microsoft Windows will retrieve and cache 50 OCSP Responses for any Source:  [Optimizing the Revocation Experience](https://technet.microsoft.com/en-us/library/ee619783%28v=ws.10%29.aspx){:target="_blank"}{:rel="noopener noreferrer"}{:class="usa-link usa-link--external"} -# Step 7 - Local Certification Authority +## Step 7 - Local Certification Authority This page provides some tips for using a local certification authority (CA) to issue a domain controller certificate. This is for local Microsoft CAs. Other platforms may be used and have different procedures. @@ -553,7 +553,7 @@ The domain controller(s) certificate must contain valid information. These steps If successful, you will see a new domain controller certificate in the **_Certificate (Local Computer) -> Personal -> Certificates folder_**. At the **Certificate Template** tab, you will also see a certificate generated with the custom certificate template. -# Step 8 - Authentication Assurance +## Step 8 - Authentication Assurance When a user authenticates to your network and you've enabled Single Sign-on to applications inside your network domain, you need to know which of these authenticators was used: @@ -687,7 +687,7 @@ Use the Windows Registry Editor to set the _AMA Priority_ above _Most Recently I Refer to the [AMA Step-by-Step Guide](https://technet.microsoft.com/en-us/library/dd378897(v=WS.10).aspx){:target="_blank"}{:rel="noopener noreferrer"}{:class="usa-link usa-link--external"} to understand the implementation of AMA. -# Troubleshooting PIV Logon +## Troubleshooting PIV Logon Within the federal enterprise, Windows smart card logon with a PIV card (PIV logon) is one method to satisfy Federal Information Security Management Act (FISMA) and National Institute of Standards and Technology (NIST) Risk Management Framework security controls for authentication. A PIV card enables Authenticator Assurance Level 3, two-factor authentication to a Windows desktop. Under normal conditions, this system is simple and easy for an end user to use. However, if this logon mechanism breaks, it can be difficult to troubleshoot logon and authentication errors. This page includes common symptoms and suggested steps to diagnose and solve these issues. From 035a0be6e79f03d6b5a52d2e1097a0dc085782bb Mon Sep 17 00:00:00 2001 From: Clayton J Barnette Date: Mon, 2 Oct 2023 17:49:40 -0400 Subject: [PATCH 41/80] SEO: Updated 8 H1s to H2s --- _implement/whfb.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/_implement/whfb.md b/_implement/whfb.md index be441d235..b1209f5a9 100644 --- a/_implement/whfb.md +++ b/_implement/whfb.md @@ -62,7 +62,7 @@ The available sign-in options for Windows Hello for Business include: Biometric data is stored locally on the device, and it is never sent to external devices or servers. As stated previously, authentication occurs via the asymmetric key. Users can delete or remove their biometric information by visiting **Settings** \> **Accounts** \> **Sign-in options.** -# Assumptions +## Assumptions This playbook assumes that devices are cloud-only and there is no hybrid device configuration with Active Directory. Deploying Windows Hello for Business in a hybrid environment requires configuring Azure AD Connect, Azure AD Kerberos and deploying either a Cloud Trust Device Configuration Profile in Microsoft Intune (Intune), a Key trust deployment in on-premises Active Directory, or a hybrid certificate trust deployment, which requires Active Directory Federated Services (ADFS). Of these three hybrid options, the Cloud Kerberos trust deployment is recommended. More on that here: [Windows Hello for Business cloud Kerberos trust clients configuration and enrollment | Microsoft Learn](https://learn.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-kerberos-trust-provision?tabs=intune){:target="_blank"}{:rel="noopener noreferrer"}{:class="usa-link usa-link--external"} This playbook assumes that all devices have a TPM 2.0 module that complies with Federal Information Processing Standards (FIPS). All devices should be on Windows 10 version 1709 (or later) or Windows 11. Preferably, all devices should be Windows 10 version 1903 or later. @@ -72,14 +72,14 @@ This playbook also assumes that: - Devices are equipped with an infrared camera or fingerprint reader to perform biometric authentication. - Microsoft Intune (Intune) is the Windows MDM solution. -# Prerequisites +## Prerequisites Devices must be Azure AD registered at minimum, and it's preferable that devices are Azure AD joined. Users must have a Microsoft Intune license feature as a stand-alone license or as part of a bundled license (Microsoft 365 E3 for GCC High and Microsoft 365 E5 for GCC High). It's also preferable that all users have an Azure AD Premium P1 or P2 subscription, which is needed for automatic MDM enrollment when the device joins Azure AD. Azure AD Premium P1 licenses also grant access to Azure AD Multi-Factor Authentication (MFA) through Conditional Access policies. -# Technology and terms +## Technology and terms [Introduction to device identity and join types](https://learn.microsoft.com/en-us/azure/active-directory/devices/overview){:target="_blank"}{:rel="noopener noreferrer"}{:class="usa-link usa-link--external"} @@ -122,7 +122,7 @@ Learn more about [hybrid Azure AD joined devices](https://learn.microsoft.com/en Device management enables organizations to administer and maintain devices, including virtual machines, physical computers, mobile devices, and IoT devices. Microsoft Intune is the mobile device management (MDM) solution for the Microsoft 365 platform. -# Prepare users to use Windows Hello +## Prepare users to use Windows Hello ### Using Windows Hello and biometrics @@ -161,7 +161,7 @@ Suppose you sign in on **Device B** and change your password for your Microsof 5. Sign in with new password. 6. The next time that you sign in, you can select **Sign-in options \> PIN** to resume using your PIN. -# WHfB policy configuration +## WHfB policy configuration Windows Hello for Business can be enabled multiple ways through Microsoft Intune. The first method is through Windows Device Enrollment. This method can be used for devices that are Azure AD joined but have not yet enrolled in Intune. The second method, Device Configuration Profile, is used for devices already enrolled in Intune. @@ -431,7 +431,7 @@ Select **Next** to continue. ![Figure 13: Windows Hello for Business Configuration Profile Completion]({{site.baseurl}}/assets/playbooks/whfb/13-Intune-WHfB-ConfigProfile-review.png) -# WHfB user experience +## WHfB user experience This section details the user experience for setting up Windows Hello for Business. View the [minimum device requirements for fingerprint and facial recognition sensors.](https://learn.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-biometrics-in-enterprise#has-microsoft-set-any-device-requirements-for-windows-hello){:target="_blank"}{:rel="noopener noreferrer"}{:class="usa-link usa-link--external"}{:aria-label="The minimum device requirements for fingerprint and facial recognition sensors"}. @@ -734,7 +734,7 @@ Security keys also can be used for Windows Hello for Business authentication. Th View [additional methods for enabling Windows security keys](https://learn.microsoft.com/en-us/azure/active-directory/authentication/howto-authentication-passwordless-security-key-windows#enable-security-keys-for-windows-sign-in){:target="_blank"}{:rel="noopener noreferrer"}{:class="usa-link usa-link--external"}{:aria-label="additional methods for enabling Windows security keys"}. -# Windows Hello for Business FAQs +## Windows Hello for Business FAQs Some of the most commonly asked questions about WHfB are presented below. View the [full list of common questions](https://learn.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-faq){:target="_blank"}{:rel="noopener noreferrer"}{:class="usa-link usa-link--external"}{:aria-label="full list of common questions"}. From f38bd5dfd5e6c45ac1eb779eae82564e144aea22 Mon Sep 17 00:00:00 2001 From: Clayton J Barnette Date: Tue, 3 Oct 2023 14:38:19 -0400 Subject: [PATCH 42/80] SEO: Updated 4 H1s to H2s --- _implement/fpki_notifications.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/_implement/fpki_notifications.md b/_implement/fpki_notifications.md index 78b1c711a..a5ac12364 100644 --- a/_implement/fpki_notifications.md +++ b/_implement/fpki_notifications.md @@ -31,7 +31,7 @@ This page contains information that is helpful in identifying changes in the Fed 3. [PIV Issuer Information](#piv-issuer-information) - List of active PIV issuing CAs with end entity certificate distribution points. 4. [FPKI System Change and Notification](#notifications) - List of changes to FPKI CA endpoint URL such as Certificate Revocation List Distribution Points, Online Certificate Status Protocol (OCSP) endpoints and other CA certificate activity. -# FPKI Announcements +## FPKI Announcements These announcements and hot topics concern Federal Public Key Infrastructure changes that may affect your agency's operations. Announcements are removed after three years. @@ -57,7 +57,7 @@ These announcements and hot topics concern Federal Public Key Infrastructure cha -# FPKI Graph +## FPKI Graph @@ -106,7 +106,7 @@ Most CA certificates will also have an SIA extension with a URI to the CA certif The FPKI Graph was built by using the same tools and code as the [Berkley ICSI SSL Notary](https://www.icsi.berkeley.edu/icsi/node/5065){:target="_blank"}{:rel="noopener noreferrer"}. -# PIV Issuer Information +## PIV Issuer Information {% assign branches = "" | split: "" %} {% for piv in site.data.fpkicustomers %} @@ -642,7 +642,7 @@ These CA certificates have issued PIV, PIV-I and/or Derived PIV authentication c - SHA-1 Hash: dc5b590800765864587902af983c21a7209be320 - CRL DP: [http://onsite-crl.pki.digicert.com/USDepartmentofTransportationFAAPIVG4/LatestCRL.crl](http://onsite-crl.pki.digicert.com/USDepartmentofTransportationFAAPIVG4/LatestCRL.crl){:target="_blank"}{:rel="noopener noreferrer"} -# FPKI System Changes and Notifications +## FPKI System Changes and Notifications This page lists the changes to certification authorities and supporting systems operating within the Federal PKI community. From 166e1f56c6f79e87991726c12c829eae32fc1260 Mon Sep 17 00:00:00 2001 From: Clayton J Barnette Date: Tue, 3 Oct 2023 14:48:56 -0400 Subject: [PATCH 43/80] SEO: Updated 3 H1s to H2s --- _ficampmo/ficampmo.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/_ficampmo/ficampmo.md b/_ficampmo/ficampmo.md index 6f4f42d6a..6573a3839 100644 --- a/_ficampmo/ficampmo.md +++ b/_ficampmo/ficampmo.md @@ -19,13 +19,13 @@ subnav: href: '#federal-public-key-infrastructure-policy-authority' --- -# Introduction +## Introduction The GSA Federal ICAM (FICAM) program helps federal agencies plan and manage enterprise identity, credentialing, and access management (ICAM) through collaboration opportunities and guidance on IT policy, standards, implementation, and architecture. Most of the guidance and best practices found on this website are developed through interagency working groups. The FICAM Program is a Federal CIO Council initiative managed by the GSA Office of Government-wide Policy. The main difference between the GSA OGP FICAM program and an agency ICAM program (including GSA's own enterprise ICAM program) is the GSA OGP FICAM program focuses on government-wide initiatives that support interoperability between organizations. -# Federal Workforce Identity Framework +## Federal Workforce Identity Framework The FICAM Program governs through a four-part framework for identity federations. @@ -51,7 +51,7 @@ Through this four-part framework, the GSA FICAM Program leads or coordinates the 1. [FIPS 201 Evaluation Program]({{site.baseurl}}/fips201ep/) - Tests and certify services and commercial products used in PIV credentialing systems and physical access control systems. 2. [Federal PKI Annual Review Process]({{site.baseurl}}/fpki/#annual-review-requirements-for-all-certification-authorities) - Independent compliance audit requirement and schedule of Federal PKI Certification Authorities. -# ICAM Governance Bodies +## ICAM Governance Bodies The GSA FICAM Program coordinates and oversees governmentwide ICAM initiatives as directed by the Federal CISO Council and the Office of Management and Budget. It accomplishes this mission through various governance bodies outlined below. From 8cfcd05395d5808bcd94e412207d5149e9305f19 Mon Sep 17 00:00:00 2001 From: Clayton J Barnette Date: Tue, 3 Oct 2023 14:53:47 -0400 Subject: [PATCH 44/80] SEO: Updated 6 H1s to H2s --- _ficampmo/fpki.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/_ficampmo/fpki.md b/_ficampmo/fpki.md index 1d6807bf8..dc77cf33c 100644 --- a/_ficampmo/fpki.md +++ b/_ficampmo/fpki.md @@ -32,7 +32,7 @@ This page contains information to help Federal Public Key Infrastructure (FPKI) For any questions, please contact fpki at gsa.gov. -# Federal PKI Policies and Profiles +## Federal PKI Policies and Profiles The Federal Public Key Infrastructure (FPKI) provides the government with a trust framework and infrastructure to administer digital certificates and public-private key pairs. For more information on the FPKI, PIV, and PIV-I visit the following links: - [FPKI 101]({{site.baseurl}}/university/fpki/) @@ -56,7 +56,7 @@ The FPKI has the following supplementary guidance: - [Archived copies of Certificate Polices, Profiles, and other FPKI-related documents]({{site.baseurl}}/fpki/#federal-pki-document-archive) - This pages contains three years of FPKI-related documents. -# Annual Review Requirements for All Certification Authorities +## Annual Review Requirements for All Certification Authorities Independent compliance audits are the primary way that the Federal Public Key Infrastructure Policy Authority (FPKIPA) ensures that entities participating in the FPKI comply with the requirements identified in the appropriate Certificate Policies (CPs). Audits are an important component of the Annual Review Requirements. @@ -92,7 +92,7 @@ Audits are required annually for supporting functions and elements of each entit | WidePoint NFI | Affiliate PKI | May 31 | | WidePoint SSP | SSP | May 31 | -# Compliance Test Tools for Annual Reviews +## Compliance Test Tools for Annual Reviews The FPKI Program support two remote PIV, PIV-I and digital certificate test tools to support FPKI annual reviews. @@ -119,7 +119,7 @@ If you are running the Card Conformance Tool as part of the annual requirement t {% include alert-warning.html heading="Note" content="Failure to submit a complete CCT Package may delay review of your testing results and completion of your annual FPKI PIV/PIV-I testing requirement." %} -# Audit Information for the FPKI Management Authority +## Audit Information for the FPKI Management Authority This section contains information on audits performed on the Federal Common Policy Certification Authority and the Federal Bridge Certification Authority. @@ -132,7 +132,7 @@ The FPKIMA Certification Practice Statement (CPS) documents the operational prac - [U.S. FPKI Audit Letter of Compliance (PDF, September 2022)]({{site.baseurl}}/docs/fpki-fpkima-audit-letter.pdf){:target="_blank"}{:rel="noopener noreferrer"} – Results of the 2020-2021 Compliance Audit for the FPKI Trust Infrastructure Systems. - [FPKI Trust Infrastructure “HTTP.FPKI.Gov” URL Site Map (PDF, September 2022)]({{site.baseurl}}/docs/fpki-fpkima-sitemap.pdf){:target="_blank"}{:rel="noopener noreferrer"} -# Report an Incident +## Report an Incident FPKI affiliates include federal agencies and commercial service providers operating a certification authority certified by the Federal PKI Policy Authority. FPKI affiliate responsibilities related to the incident management process include: 1. Communicating security incidents involving infrastructures or services to the FPKI Authorities, users/customers, and known relying parties. 2. Providing additional investigation support and/or information about incidents to the FPKI Authorities as they become known, and @@ -210,7 +210,7 @@ Repository availability is an uptime metric for Certificate Revocation List avai | Verizon SSP CA A2 | FCPCA | 100 | | WidePoint ORC SSP 5 | FCPCA | 100 | --> -# Federal PKI Document Archive +## Federal PKI Document Archive {% assign categories = "" | split: "" %} {% for docs in site.data.fpkidocs %} From be510cc30c7abbda33a9a94a104f1d5859361989 Mon Sep 17 00:00:00 2001 From: Clayton J Barnette Date: Tue, 3 Oct 2023 14:58:18 -0400 Subject: [PATCH 45/80] SEO: Updated 2 H1s to H2s --- _ficampmo/fips201ep.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/_ficampmo/fips201ep.md b/_ficampmo/fips201ep.md index 81b6a86e8..a80acd53d 100644 --- a/_ficampmo/fips201ep.md +++ b/_ficampmo/fips201ep.md @@ -97,7 +97,7 @@ Review the testing agreements, and sign and submit the appropriate agreement wit - [Approved Product List Application Guidance Document (PDF, April 2022)]({{site.baseurl}}/docs/fips201ep-Application-guidance.pdf){:target="_blank"}{:rel="noopener noreferrer"} – Provides a checklist of which documents are required when submitting a new or upgraded solution. - [Removed Products List (RPL) Process Document (PDF, April 2022)]({{site.baseurl}}/docs/fips201ep-rplprocess.pdf){:target="_blank"}{:rel="noopener noreferrer"} – If your product has been removed from the APL, review this document for the procedures. -# Personal Identity Verification Credentials +## Personal Identity Verification Credentials - [Annual PIV Credential Issuer (PCI) Testing Application Form (PDF, February 2020)]({{site.baseurl}}/docs/fips201ep-pcitestform.pdf){:target="_blank"}{:rel="noopener noreferrer"} – If you are an agency or organization applying for your Annual Review Audit for the Federal Public Key Infrastructure (FPKI), submit this form to fips201ep at gsa.gov; two testing options are available: - In-person Lab Testing - testing organizations can provide available dates and times to visit the GSA FIPS 201 lab when sending in their application form, or @@ -124,7 +124,7 @@ Agencies that wish to issue D-PIV credentials should follow these steps: Upon successful completion of DPCI testing, the agency or organization will be granted approval to issue D-PIV credentials. -# Physical Access Control System +## Physical Access Control System GSA tests and validates the interoperability of PIV and CAC credentials with the software and hardware used to restrict physical access to government facilities. From 2b681dd77c96199ad9eb874dbb27fc39790e1af3 Mon Sep 17 00:00:00 2001 From: Clayton J Barnette Date: Tue, 3 Oct 2023 15:03:30 -0400 Subject: [PATCH 46/80] SEO: Updated 9 H1s to H2s --- _university/pki101.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/_university/pki101.md b/_university/pki101.md index 1879edf28..26c8b49e8 100644 --- a/_university/pki101.md +++ b/_university/pki101.md @@ -28,13 +28,13 @@ subnav: --- -# Introduction +## Introduction Public Key Infrastructure or PKI is a cost effective tool to ensure the confidentiality, integrity, and availability of electronic transactions. PKI utilizes asymmetric cryptography, meaning a different key is used to encrypt (public key) than is used to decrypt (private key). Only the private key can be used to decrypt a message; the amount of confidentiality provided is based on the size of the key (in bits) that is used. An encrypted hash value or digest of the message is also created to ensure integrity and authentication of the originator. PKI is the technology used to issue digital certificates like the certificates on the PIV credential. -# Establishing Trust +## Establishing Trust Digital certificates are issued and digitally signed by a _certification authority (CA)_. The _CA_ that signed and end entity certificate (like your PIV credential certificate) is called an _**intermediate** CA_ because it was issued a certificate by another _CA_. This process of issuing and signing continues until there is one _CA_ that is called the _**root** CA_. @@ -53,7 +53,7 @@ The [FPKI Graph]({{site.baseurl}}/fpki/notifications/#fpki-graph){:target="_blan A trust anchor is a trusted certification authority (CA). These may be commonly called trust root, trusted CA, or root CA. Everything in PKI traces its trust back to a trust anchor. The trust anchor operated by Federal PKI, including PIV and PIV-Interoperable, is the [Federal Common Policy CA]({{site.baseurl}}/fpki/#fpki-third-party-trust). A common misconception is that the Federal Bridge is the root of trust. Keep reading to understand why that is not the case. Every software program that interacts with a certificate installs trust anchors in a native trust store or uses the trust store of the operating system. A trust store is a list of **root, intermediate, and sometimes user certificates** that the operating system or application trusts to process transactions. For more information on trust stores, see the [PKI trust store page]({{site.baseurl}}/university/fpki/#fpki-third-party-trust). -# Path Discovery and Validation +## Path Discovery and Validation Public Key Infrastructure (PKI) certificates follow a process called Path Discovery and Validation (PDVal) to verify if a certificate is valid and trusted. This playbook provides an overview of this PDVal process in the context of the Federal PKI. If you have heard terms like PDVal, trust paths, certificate paths, trust fabric, trust anchors, and Microsoft CAPI to name a few, you are in the right place. Knowledge of the Federal PKI is not needed to understand PDVal. If you're interested in more information about the Federal PKI, go to the [Federal PKI Program Page]({{site.baseurl}}/fpki/). @@ -109,7 +109,7 @@ The most important factor is the trust anchors. By limiting which trust anchors -# Certification Path Discovery +## Certification Path Discovery The first step of PDVal is finding a certification path for the certificate that needs to be verified. The process for finding the path is called path discovery or path development. Verifying a PIV card is a straightforward procedure involving only one or two CA certificates (see the Example Certification Path 1 image in the previous section). In other situations, such as validating a PIV-I certificate, the procedure can involve many CAs and significantly more challenging path discovery requirements. If path discovery adheres to RFC 5280, all possible paths should be discovered and details like certificate policies would be considered at each hop; the process shouldn't wait until a single path is selected without considering additional information. @@ -179,7 +179,7 @@ This mechanism becomes essential when CAs get a new key, called key rollover. CA A diagram illustrating prior key rollover. -# Certification Path Validation +## Certification Path Validation With a path discovered, now we need to see if it is valid. @@ -219,7 +219,7 @@ A CA puts information in certificates it issues to other CAs that limit the trus The key takeaway is that CAs can place restrictions (constraints) on certificates they issue. These restrictions limit how the certificates they issue can be used. Detailed processing of these constraints is a complicated matter and is beyond the scope of this playbook. -# Basic Certificate Checks +## Basic Certificate Checks PDVal performs basic checks on every certificate except for the trust anchor. @@ -259,7 +259,7 @@ A CA revokes a certificate by placing the certificate serial number (primary cer Additionally, CAs may operate **Online Certificate Status Protocol (OCSP)** servers to provide revocation status for single certificates. Instead of a potentially large CRL, software can leverage OCSP to obtain status for a certificate quickly. This is especially useful for end-user applications that do not need to track the revocation status of every certificate issued by a CA. -# Certificate Policies +## Certificate Policies When found in a CA certificate, these policies indicate that the CA complies with applicable security requirements and is authorized to issue the policy certificates. When found in a certificate issued to a person or a device, the policies communicate security and identity proofing requirements. They may also display the intended use case for the certificate. In the FPKI, all certificates contain certificate policies, and path validation software must confirm that all certificates are valid for one or more policies. @@ -294,7 +294,7 @@ In the example above, the DoD certificate contains DoD policies and the path val - 1.3.6.1.4.1.16334.509.2.7 - Northrop Grumman Medium Assurance-256 Software - 1.3.6.1.4.1.16334.509.2.8 - Northrop Grumman Medium Assurance-256 Hardware -# Putting It All Together +## Putting It All Together The Cross-certificates between the Bridge and the affiliate CA in the bridge environment PKI image contains policy mappings in the [Choosing CA Certificates](#choosing-ca-certificates) section. They are an essential part of the cross-certificate because they express the literal security common ground between an issuer and the community baseline established by the Bridge. As an issuer, you can always exceed a security control or requirement, but you must at least meet the requirement. As an issuer, you could state that both shoes and socks are not allowed in your house, but the Bridge might be happy as long as you at least enforce shoe removal. Path validation ensures that the minimum level of assurance you have set as your trust policy meets the security controls of other CAs in the trust framework. This trust mapping is a compelling capability because it affords trust at scale safely. Here also, we are leveraging the transitive property to accomplish this effect. @@ -302,7 +302,7 @@ The Cross-certificates between the Bridge and the affiliate CA in the bridge env

Example Policy Mapping - Federal Bridge to DoD Interoperability Root

-# References +## References PDVal is a complex subject. For more detailed technical information about PDVal, consult the following resources: From 5242bcbaa8e1066616b9d9d1a2d73f8a9bbc1630 Mon Sep 17 00:00:00 2001 From: Clayton J Barnette Date: Tue, 3 Oct 2023 15:33:06 -0400 Subject: [PATCH 47/80] SEO: Updated 3 H1s to H2s --- _university/fpki101.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/_university/fpki101.md b/_university/fpki101.md index 9ac8bd570..322489d76 100644 --- a/_university/fpki101.md +++ b/_university/fpki101.md @@ -16,7 +16,7 @@ subnav: --- -# Introduction +## Introduction Welcome to the **Federal Public Key Infrastructure (FPKI) Guides**! In these guides, you will find commonly used links, tools, tips, and information for the FPKI. @@ -87,7 +87,7 @@ The Federal PKI is important to federal agencies, other government entities, and * [X.509 Certificate and CRL Extensions Profile for PIV-I Cards]({{site.baseurl}}/docs/fpki-x509-cert-profiles-pivi.pdf){:target="_blank"}{:rel="noopener noreferrer"} specifies certificate and CRL extensions profiles for use with Personal Identity Verification Interoperable (PIV-I) cards. * [OMB Circular A-130, Managing Information as a Strategic Resource (2016)](https://obamawhitehouse.archives.gov/sites/default/files/omb/assets/OMB/circulars/a130/a130revised.pdf?msclkid=b1259175c7f211ec8144311a36ca5067){:target="_blank"}{:rel="noopener noreferrer"}{:class="usa-link usa-link--external"} establishes general policy for the planning, budgeting, governance, acquisition, and management of federal information, personnel, equipment, funds, IT resources, and supporting infrastructure and services. -# Certification Authorities +## Certification Authorities A **_certification authority_** is a system that issues digital certificates. These digital certificates are based on _cryptography_ and follow the X.509 standards defined for information security. @@ -152,7 +152,7 @@ The overarching policies of the Federal PKI are the Federal Common Policy Framew **Code signing certificates are not allowed under the Federal Common Certificate Policy.** -# FPKI Third Party Trust +## FPKI Third Party Trust The Federal Common Policy leverages third party trust stores or public trust store to ensure interoperability of federally-issued digital certificates. From e978630c627d7a8e7eea76981b54abec556a3776 Mon Sep 17 00:00:00 2001 From: Nelson R <125207848+TheInfinityBeyonder@users.noreply.github.com> Date: Wed, 4 Oct 2023 09:29:46 -0400 Subject: [PATCH 48/80] Update outlook.md corrected 2 spellings --- _implement/outlook.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/_implement/outlook.md b/_implement/outlook.md index 22accd0ba..f33a26ca1 100644 --- a/_implement/outlook.md +++ b/_implement/outlook.md @@ -28,7 +28,7 @@ The following guide walks you through configuring Outlook to leverage the digita {% include alert-info.html heading = "Know your Email Provider Capabilities" content="Although several email client applications have options to support digital signatures or encryption (S/MIME), not all email providers organically support S/MIME with third party PKI certificates. S/MIME support often times varies with different tiers of service. Coordinate with your email and workstation administrators to ensure S/MIME cpabilities are available on both email servers and user workstations, especially if accessed through a browser." %} -The following steps pertain to Microsoft Outlook 2016, and may also be applicable to newer versions up through Outlook 2021. These steps may not be applicable to cloud email users, but you may find addtional configurations below for both Exchange Online and O365 in [Other Helpful References](#other-helpful-references). +The following steps pertain to Microsoft Outlook 2016, and may also be applicable to newer versions up through Outlook 2021. These steps may not be applicable to cloud email users, but you may find additional configurations below for both Exchange Online and O365 in [Other Helpful References](#other-helpful-references). 1. Insert your PIV card in your computer's smart card reader. 2. Browse to **File** > **Options** > **Trust Center** > **Trust Center Settings...** and select **Email Security**. @@ -50,7 +50,7 @@ The following steps pertain to Microsoft Outlook 2016, and may also be applicabl ### Publish Your Certificates to the Global Address List -The Global Address List (GAL) is a shared, enterprise-wide contact list in Microsoft Active Directory. Publishing your certificates to the GAL will add your encryption certificate and assoicated public key to an enterprise address book, making it easier for other internal agency users to send you an encrypted email. +The Global Address List (GAL) is a shared, enterprise-wide contact list in Microsoft Active Directory. Publishing your certificates to the GAL will add your encryption certificate and associated public key to an enterprise address book, making it easier for other internal agency users to send you an encrypted email. 1. Insert your PIV card in your computer's smart card reader. 2. Browse to **File** > **Options** > **Trust Center** > **Trust Center Settings** and select **Email Security**. From 7d1dbbda241e38ab5e0c76fae79a065022346c77 Mon Sep 17 00:00:00 2001 From: Clayton J Barnette Date: Wed, 4 Oct 2023 15:48:16 -0400 Subject: [PATCH 49/80] SEO: Updated 5 H1s to H2s --- _university/piv101.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/_university/piv101.md b/_university/piv101.md index 037c9cfd2..47ae019eb 100644 --- a/_university/piv101.md +++ b/_university/piv101.md @@ -20,7 +20,7 @@ subnav: --- -# Introduction +## Introduction This **Personal Identity Verification (PIV) 101** is intended to help you understand the purpose and uses of a PIV credential at your organization. This PIV 101 focuses on using PIV credentials for _logical access_ such as authenticating to networks or applications or digitally signing and encrypting. Using PIV for _physical access_ is available in the [PACS 101]({{site.baseurl}}/university/pacs/){:target="_blank"}{:rel="noopener noreferrer"}. @@ -78,7 +78,7 @@ To review the standards, there is a [National Institute of Standards and Technol The [Card Conformance Tool (CCT)](https://github.com/GSA/piv-conformance/wiki/User-Guide){:target="_blank"}{:rel="noopener noreferrer"} can remotely test PIV and Personal Identity Verification–Interoperable (PIV-I) on several common operating systems. The purpose of the CCT is to validate that commercially available PIV and PIV-I comply with relevant standards. -# PIV Overview +## PIV Overview There are two main categories for the features of a PIV credential: 1. [_physical_ features](#physical-features) and @@ -127,7 +127,7 @@ Provided below are links to example forms you can use as templates to create or - [USAccess acknowledgment](https://ack.usaccess.gsa.gov/acknowledgement/activation.aspx){:target="_blank"}{:rel="noopener noreferrer"} - [DoD PKI Certificate Acceptance DD From 2842](https://www.esd.whs.mil/Portals/54/Documents/DD/forms/dd/dd2842.pdf){:target="_blank"}{:rel="noopener noreferrer"} -# PIV Readers and Middleware +## PIV Readers and Middleware You need two items to begin using your PIV credential: @@ -205,7 +205,7 @@ The table below outlines the general information for the PIV credential certific | Encryption |Sometimes | Key Encipherment | Specific EKUs are required for certificates issued after June 2019 | rfc822name = email address | Email address is **not** required by policy. Encryption certificates that represent available, retired encryption key pairs may exist, depending on the PIV issuer. | | PIV Content Signer | Always | Digital Signature | id-PIV-content-signing | N/A | The PIV content signer ensures the integrity of the digital information stored on the card. Physical Access Control Systems (PACS) are the primary relying party for these certificates. This certificate is unavailable in most logical trust stores, but users can leverage the [Card Conformance Tool (CCT](https://github.com/GSA/piv-conformance/releases) if they would like to extract and view the PIV content signing certificate. | -# How to View PIV Credential Certificates +## How to View PIV Credential Certificates You can use these simple methods to view, export, and understand the information stored on a PIV credential. @@ -242,7 +242,7 @@ To view your certificate information: In-depth details on the certificate profiles are contained in the current and historical Federal Public Key Infrastructure (FPKI) policy documents. The most recent policy and certificate profile documents may be found on IDManagement.gov's [FPKI Policy and Compliance Audit]({{site.baseurl}}/fpki/#audit-information-for-the-fpki-management-authority){:target="_blank"}{:rel="noopener noreferrer"} page. -# PIV Unique Identifiers +## PIV Unique Identifiers In applications including network domains, you will associate the PIV credential with your accounts. This process is not unique to PIV credentials and usage; it is a general concept that occurs in many applications, including your personal email accounts, your bank accounts, or your favorite social media app. From f299361097989cf69e0a3f397f02f66dd443f9aa Mon Sep 17 00:00:00 2001 From: Clayton J Barnette Date: Wed, 4 Oct 2023 15:51:05 -0400 Subject: [PATCH 50/80] SEO: Updated 9 H1s to H2s --- _university/pivi101.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/_university/pivi101.md b/_university/pivi101.md index 70848d47f..41e3ff77b 100644 --- a/_university/pivi101.md +++ b/_university/pivi101.md @@ -100,7 +100,7 @@ This guide helps federal agencies understand how federal issuers and Non-Federal -# Executive Summary +## Executive Summary Federal agencies are interested in issuing and acquiring identity credentials and credential services that are not Personal Identity Verification (PIV) credentials, but rather are: @@ -122,7 +122,7 @@ This guide advocates a set of minimum requirements for PIV-I credentials that th For additional information on PIV-I, please contact fpki at gsa.gov. -# 1. Introduction +## 1. Introduction The Federal Government's reliance (trust) on PIV credentials establishes a baseline for identity assurance, authenticator assurance, and personnel vetting assurance. Federal agencies and issuers of identity credentials express a desire to produce interoperable smart card-based credentials with the Federal Government PIV infrastructure. Agencies can trust these PIV interoperable credentials in authenticating facilities, networks, and systems. This guide provides a definition for a PIV-I credential to address the following: @@ -152,7 +152,7 @@ The following assumptions apply: 3. User privileges and entitlements (authorization) are determined solely by the federal government relying party. 4. PIV-I credentials will not be considered a substitute or alternative credential for populations otherwise subject to PIV requirements. -# 2. Minimum Credential Requirements +## 2. Minimum Credential Requirements There is a lack of standard terminology to distinguish between characteristics of PIV and PIV-I credentials. This lack of common language results in confusion, uncertainty, or misunderstanding when identifying and understanding how to integrate PIV-I credentials in a federal agency. @@ -343,7 +343,7 @@ Table 3 outlines the different scenarios for issuers of PIV-I credentials, the p {% include alert-info.html heading="Use Card UUID for Account Linking" content="In all scenarios, it is recommended that agencies update their PACS to use the Card UUID value for PIV-I account linking." %} -# 3. Special Considerations for Federal Agencies +## 3. Special Considerations for Federal Agencies Federal agencies have identified the need to clarify the differences between: @@ -435,7 +435,7 @@ This must be a condition of the contract; contract language should make it clear The System of Records Notice (SORN) should also be taken into consideration. Many agencies should, wherever possible, be able to leverage the SORN associated with the issuance of PIV credentials for PIV-I credentials, since the purpose of PIV-I issuance is within its scope. -# Appendix A: Technical Information +## Appendix A: Technical Information This appendix provides additional technical information in support of the technical requirements. The following table provides a comparison of the requirements for each credential type. @@ -515,7 +515,7 @@ This appendix provides additional technical information in support of the techni -# Appendix B: Glossary +## Appendix B: Glossary | Term | Definition | |:----:|------------| @@ -529,7 +529,7 @@ This appendix provides additional technical information in support of the techni | PIV-I credential | An identity credential that is conformant with the federal PIV Standards for identity assurance and authentication assurance. | | Public Key Infrastructure (PKI) | A service that provides cryptographic keys needed to perform digital signature- based identity verification, and to protect communications and storage of sensitive data.| -# Appendix C: Acronyms +## Appendix C: Acronyms | Acronym | Definition | |:-------:|------------| @@ -556,7 +556,7 @@ This appendix provides additional technical information in support of the techni | U.S.| United States | | UUID | Universally Unique Identifier | -# Appendix D: Document References +## Appendix D: Document References ## Policies 1. [HSPD-12: Policy for a Common Identification Standard for Federal Employees and Contractors](https://www.dhs.gov/homeland-security-presidential-directive-12){:target="_blank"}{:rel="noopener noreferrer"}{:class="usa-link usa-link--external"} @@ -575,7 +575,7 @@ This appendix provides additional technical information in support of the techni 5. [NIST SP 800-78: Cryptographic Algorithms and Key Sizes for Personal Identity Verification](https://csrc.nist.gov/publications/detail/sp/800-78/4/final){:target="_blank"}{:rel="noopener noreferrer"}{:class="usa-link usa-link--external"} 6. [NIST SP 800-79: Guidelines for the Authorization of Personal Identity (PIV) Verification Card Issuers (PCI) and Derived PIV Credential Issuers (DPCI)](https://csrc.nist.gov/publications/detail/sp/800-79/2/final){:target="_blank"}{:rel="noopener noreferrer"}{:class="usa-link usa-link--external"} -# Footnotes +## Footnotes [^1]: In particular, these requirements are specified in FIPS 201-3 Section 2.1 Control Objectives, related to adjudication of fitness and personnel vetting, and are common minimum personnel assurance for all federal PIV holders. [^2]: This includes Card Management Systems and any associated software or hardware components used to collect and manage information used in the issuance and lifecycle management for PIV or PIV-I credentials. From c82c5232a8cf3374a174978bc62413d9733fafe4 Mon Sep 17 00:00:00 2001 From: Clayton J Barnette Date: Wed, 4 Oct 2023 15:54:48 -0400 Subject: [PATCH 51/80] SEO: Updated 10 H1s to H2s --- _university/pacs101.md | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/_university/pacs101.md b/_university/pacs101.md index 0158c0ff5..b388eae9d 100644 --- a/_university/pacs101.md +++ b/_university/pacs101.md @@ -30,7 +30,7 @@ subnav: --- -# Introduction +## Introduction The **Physical Access Control System (PACS) 101** will help you understand concepts related to _Federal Identity, Credential, and Access Management_-compliant PACSs. At a high level, a PACS is a collection of technologies that control physical access at one or more federal agency sites by electronically authenticating employees, contractors, and visitors. @@ -40,7 +40,7 @@ The **Physical Access Control System (PACS) 101** will help you understand conce We want to thank the Secure Technology Alliance, especially the members of the Access Control Council, for contributions to the original PACS Guides which is now the PACS 101 page and permission to reuse content from their presentations and the *How to Plan, Procure and Deploy a pacs-Enabled Physical Access Control System* webinar training. -# PACS Explained +## PACS Explained A Physical Access Control System (PACS) grants access to employees and contractors who work at or visit a site by electronically authenticating their PIV credentials. Although PACSs are information technology (IT) systems, they must be designed, deployed, and operated in cooperation with Physical Security teams to successfully meet agency mission needs. @@ -61,7 +61,7 @@ The following table defines common PACS components: {% include alert-info.html content="All agency-purchased PACS components must be FIPS 201-compliant and selected from GSA's Approved Products List (APL) for PACS Products. The products in this list have undergone vulnerability and interoperability testing through the FIPS 201 Evaluation Program. As an IT system, a PACS must still complete Certification and Accreditation and obtain an Authority to Operate from your agency before connecting to the network." %} -# Compliant PACS Characteristics +## Compliant PACS Characteristics In May 2019, the Office of Management and Budget (OMB) released memorandum [M-19-17](https://www.whitehouse.gov/wp-content/uploads/2019/05/M-19-17.pdf){:target="_blank"}{:rel="noopener noreferrer"}{:class="usa-link usa-link--external"}, _Enabling Mission Delivery through Improved Identity, Credential, and Access Management_. Related to PACS, M-19-17 rescinded memorandum [M-11-11](https://obamawhitehouse.archives.gov/sites/default/files/omb/memoranda/2011/m11-11.pdf){:target="_blank"}{:rel="noopener noreferrer"}{:class="usa-link usa-link--external"}, _Continued Implementation of Homeland Security Presidential Directive (HSPD) 12 – Policy for a Common Identification Standard for Federal Employees and Contractors_. The updated guidance adds further specificity to require the use of PIV credentials for physical access to federal facilities, implemented per _[The Risk Management Process for Federal Facilities: An Interagency Security Committee Standard](https://www.cisa.gov/sites/default/files/publications/The%20Risk%20Management%20Process%20-%202021%20Edition_2.pdf){:target="_blank"}{:rel="noopener noreferrer"}{:class="usa-link usa-link--external"}_ and NIST [SP 800-116, Revision 1](https://csrc.nist.gov/publications/detail/sp/800-116/rev-1/final){:target="_blank"}{:rel="noopener noreferrer"}{:class="usa-link usa-link--external"}, _ Guidelines for the Use of PIV Credentials in Facility Access_. @@ -77,7 +77,7 @@ The FIPS 201 Evaluation Program in collaboration with the [PACS Modernization Wo - [PACS Assessment Toolkit Version 1.0]({{site.baseurl}}/docs/fips201ep-pacs-self-tool.pdf){:target="_blank"}{:rel="noopener noreferrer"} -# Deployment Models +## Deployment Models There are two PACS deployment models. @@ -123,7 +123,7 @@ Here are some key E-PACS advantages to consider: * Server hardware * System security assessment and accreditation -# Aligning Facility Security Level and Authentication +## Aligning Facility Security Level and Authentication Federal agencies rely on Physical Access Control Systems (PACSs) and Personal Identity Verification (PIV) credentials to confirm that an employee, contractor, or visitor _is_ or _is not_ authorized to access a site and its critical assets, such as systems, information, and people. @@ -246,7 +246,7 @@ This page provides a sample PACS Procurement Checklist. You can reuse or tailor Agency staff are encouraged to participate in steps where their roles are listed in bold underlined font. -# PACS Procurement Best Practices +## PACS Procurement Best Practices @@ -557,7 +557,7 @@ Agency staff are encouraged to participate in steps where their roles are listed - [GSA’s eBuy](https://www.ebuy.gsa.gov/ebuy/){:target="_blank"}{:rel="noopener noreferrer"}{:class="usa-link usa-link--external"} RFQ online system enables you to post requirements, obtain quotes, and issue orders electronically. - Approved [Certified System Engineer ICAM PACS (CSEIP) List]( https://www.securetechalliance.org/activities-cseip-registry/){:target="_blank"}{:rel="noopener noreferrer"}{:class="usa-link usa-link--external"}. Agencies must use FIPS 201-approved integrators and other contractors. The "lead designer" for FIPS 201-approved integrators must possess a Certified System Engineer ICAM PACS (CSEIP) certification or be certified by another federally recognized certification program. -# Training +## Training Specialized training is essential for Physical Access Control System (PACS) technical leads and team members. This page describes roles, responsibilities, and training opportunities. @@ -614,7 +614,7 @@ In 2018, GSA hosted a _PACS Reverse Industry Day_ conference that featured gover - [Morning Session](https://www.youtube.com/watch?v=r9X1XtrLjMg){:target="_blank"}{:rel="noopener noreferrer"}{:class="usa-link usa-link--external"} - [Afternoon Session](https://www.youtube.com/watch?v=bS8jdkW_WUI){:target="_blank"}{:rel="noopener noreferrer"}{:class="usa-link usa-link--external"} -# Lessons Learned +## Lessons Learned Federal agencies have shared these PACS lessons learned: @@ -667,7 +667,7 @@ Federal agencies have shared these PACS lessons learned: - Create and maintain a training plan that formally documents training requirements. - Provide role-specific training to agency stakeholders, such as HR, IT, or Security. -# References +## References ## Public Law @@ -738,7 +738,7 @@ E.O. 13636 and PPD-21 - ["Fact Sheet: Improving Critical Infrastructure Cybersec ["Federal Building Security: Actions Needed to Help Achieve Vision for Secure, Interoperable Physical Access Control"](https://www.gao.gov/products/GAO-19-138){:target="_blank"}{:rel="noopener noreferrer"}{:class="usa-link usa-link--external"}, Government Accountability Office (GAO), December 20, 2018 -# Glossary +## Glossary {% include alert-info.html content="NIST SP-800-116, Revision 1, \"Guidelines for the Use of PIV Credentials in Facility Access\" Appendix G contains additional PACS-related terms and definitions." %} From 95f79546815a5a6cc910f0ff429adc6688fd14aa Mon Sep 17 00:00:00 2001 From: Clayton J Barnette Date: Wed, 4 Oct 2023 15:58:19 -0400 Subject: [PATCH 52/80] SEO: Updated 6 H1s to H2s --- _playbooks/playbook-cloud.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/_playbooks/playbook-cloud.md b/_playbooks/playbook-cloud.md index e9e2a8fbe..5ef2127d1 100644 --- a/_playbooks/playbook-cloud.md +++ b/_playbooks/playbook-cloud.md @@ -95,7 +95,7 @@ This playbook is a collaboration between the Federal Chief Information Security | 1.1 | 10/11/22 | Updated federation section for trust framework examples. | | 1.0 | 01/20/22 | Initial draft. | --> -# Executive Summary +## Executive Summary This Cloud Identity Playbook is a practical guide to assist federal agencies as they start to or further expand the use of workforce Identity, Credential, and Access Management (ICAM) services in a cloud operating model. Workforce identities are digital identities or accounts owned and managed by the agency, including employees and contractors. The most common Cloud Identity example is Identity as a Service (IDaaS). An IDaaS is typically an Identity Provider that offers Single Sign-on, multifactor authentication, and directory services in a single platform as a core set. It also may provide additional features. @@ -149,7 +149,7 @@ The primary audience for this playbook is agency Identity, Credential, and Acces The Cloud Identity Working Group of the Federal Chief Information Security Officer Council ICAM Subcommittee, in collaboration with the Federal Chief Information Officer Council Cloud & Infrastructure Community of Practice, developed this playbook. U.S. Federal Executive Branch agencies can use this playbook to plan Cloud Identity services related to the [FICAM Architecture Services Framework]({{site.baseurl}}/arch/#services-framework-and-service-descriptions){:target="_blank"}{:rel="noopener noreferrer"}. This playbook is not official policy or mandated action, and it does not provide authoritative information technology terms. It includes best practices to supplement existing federal policies and builds upon [Executive Order 14028](https://www.federalregister.gov/documents/2021/05/17/2021-10460/improving-the-nations-cybersecurity){:target="_blank"}{:rel="noopener noreferrer"}{:class="usa-link usa-link--external"}, [Office of Management and Budget Memorandum M-19-17](https://www.whitehouse.gov/wp-content/uploads/2019/05/M-19-17.pdf){:target="_blank"}{:rel="noopener noreferrer"}{:class="usa-link usa-link--external"}, and existing Federal ICAM (FICAM) guidance and playbooks. Subject areas with intersecting scopes, such as cloud operating models, Federal Risk and Authorization Management Program (FedRAMP), and enterprise governance, are considered only to the extent that they relate to ICAM services delivered in a cloud service model. Privileged access management (e.g., superusers, domain administrators) is outside the scope of this playbook. -# Cloud Identity 101 +## Cloud Identity 101 Identity is foundational to security both on-premises and within cloud environments. It is the first touchpoint to access data and impact user experience. In cloud environments, application access acts as a perimeter to protect applications and workloads. Traditionally, network-based defenses perform this function. In this playbook, on-premises refers to an agency operating identity services on agency-owned and -maintained infrastructure. @@ -179,7 +179,7 @@ The adoption of cloud services adds challenges. Cloud services operate on a shar See the [Data Center and Cloud OptimizationInitiative Cloud Strategy Guide](https://community.max.gov/display/Egov/Agency%2BIT%2BModernization%3A%2BEducational%2BResources%2BBuilding%2BBlocks){:target="_blank"}{:rel="noopener noreferrer"}{:class="usa-link usa-link--external"} for a holistic cloud strategy. Additionally, read the [OMB Cloud Smart Strategy](https://cloud.cio.gov/strategy/){:target="_blank"}{:rel="noopener noreferrer"} to understand the federal government's overarching strategic guidance on cloud adoption. -# Cloud Identity Journey Steps +## Cloud Identity Journey Steps Any journey has a map, but not all are the same. Use these four steps to plan your Cloud Identity Journey. Your agency may already support and encourage cloud services while others do not. @@ -514,7 +514,7 @@ IDaaS products may vary in configuration and operation. This section provides te 5. Testing. 4. **Test and Implement Workflow.** After finding an optimal workflow, it is time to test and implement it. If possible, test in a non-production environment. If testing is only available in production, limit the impact to a small community of users or a non-mission critical task. -# Emerging Topics +## Emerging Topics The Cloud Identity Working Group discussed two emerging topics: Cloud Infrastructure Entitlement Management and DevSecOps Identity. @@ -541,7 +541,7 @@ Since the goal of the DevOps team is to get software operating in production qui See the [GSA Guide](https://tech.gsa.gov/guides/dev_sec_ops_guide/){:target="_blank"}{:rel="noopener noreferrer"} on DevSecOps for more information. -# Appendix A. Policies, Standards, and Guidance +## Appendix A. Policies, Standards, and Guidance ## Policies @@ -578,7 +578,7 @@ See the [GSA Guide](https://tech.gsa.gov/guides/dev_sec_ops_guide/){:target="_bl 16. [Open Authorization (OAuth)](https://oauth.net/){:target="_blank"}{:rel="noopener noreferrer"}{:class="usa-link usa-link--external"} 17. [System for Cross-Domain Identity Management (SCIM)](https://scim.cloud){:target="_blank"}{:rel="noopener noreferrer"}{:class="usa-link usa-link--external"} -# Appendix B. Acronyms +## Appendix B. Acronyms | Acronym | Definition | | --- | --- | From 78a1dbd9d5d7d5ff4e09dd1f3edd008f6e60813c Mon Sep 17 00:00:00 2001 From: Nelson R <125207848+TheInfinityBeyonder@users.noreply.github.com> Date: Wed, 4 Oct 2023 16:25:50 -0400 Subject: [PATCH 53/80] Update outlook.md correct 1 spelling --- _implement/outlook.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_implement/outlook.md b/_implement/outlook.md index f33a26ca1..939729b08 100644 --- a/_implement/outlook.md +++ b/_implement/outlook.md @@ -26,7 +26,7 @@ The following guide walks you through configuring Outlook to leverage the digita ## Configure Outlook to Send Secure Email -{% include alert-info.html heading = "Know your Email Provider Capabilities" content="Although several email client applications have options to support digital signatures or encryption (S/MIME), not all email providers organically support S/MIME with third party PKI certificates. S/MIME support often times varies with different tiers of service. Coordinate with your email and workstation administrators to ensure S/MIME cpabilities are available on both email servers and user workstations, especially if accessed through a browser." %} +{% include alert-info.html heading = "Know your Email Provider Capabilities" content="Although several email client applications have options to support digital signatures or encryption (S/MIME), not all email providers organically support S/MIME with third party PKI certificates. S/MIME support often times varies with different tiers of service. Coordinate with your email and workstation administrators to ensure S/MIME capabilities are available on both email servers and user workstations, especially if accessed through a browser." %} The following steps pertain to Microsoft Outlook 2016, and may also be applicable to newer versions up through Outlook 2021. These steps may not be applicable to cloud email users, but you may find additional configurations below for both Exchange Online and O365 in [Other Helpful References](#other-helpful-references). From 5c1229afb06d7349d16326a53beb26587f0130e9 Mon Sep 17 00:00:00 2001 From: Nelson R <125207848+TheInfinityBeyonder@users.noreply.github.com> Date: Wed, 4 Oct 2023 16:33:11 -0400 Subject: [PATCH 54/80] Update fpki_notifications.md correct 1 spelling --- _implement/fpki_notifications.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_implement/fpki_notifications.md b/_implement/fpki_notifications.md index 78b1c711a..04798c8e6 100644 --- a/_implement/fpki_notifications.md +++ b/_implement/fpki_notifications.md @@ -683,7 +683,7 @@ Subject: FPKI System Notification - System Name - ca_cdp_uri: Certificate Revocation List link - ca_aia_uri: the authority information access certificate bundle for the CA certificate - ca_sia_uri: the subject information access certificate bundle for the CA certificate -- ca_ocsp_uri: the OCSP address generally conatined in the AIA for the CA certificate +- ca_ocsp_uri: the OCSP address generally contained in the AIA for the CA certificate - ee_cdp_uri: the CRL DP link for end entity certificates signed by the CA certificate - ee_ocsp_uri: the OCSP link for end entity certificates signed by the CA certificate From a69f1754774ee63469213995a7ac2a57b0c60307 Mon Sep 17 00:00:00 2001 From: Nelson R <125207848+TheInfinityBeyonder@users.noreply.github.com> Date: Wed, 4 Oct 2023 16:34:08 -0400 Subject: [PATCH 55/80] Update highlights.html correct spelling --- _includes/highlights.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_includes/highlights.html b/_includes/highlights.html index af934af4a..e6ebdca2d 100644 --- a/_includes/highlights.html +++ b/_includes/highlights.html @@ -57,7 +57,7 @@

Acquisition professionals

- Adopt innovative identity, credential, and access nanagement ICAM products and services to meet your agency's mission-needs. + Adopt innovative identity, credential, and access management ICAM products and services to meet your agency's mission-needs.

From 051ebdc5b4625011251aecb5e216c37f3f74add5 Mon Sep 17 00:00:00 2001 From: Nelson R <125207848+TheInfinityBeyonder@users.noreply.github.com> Date: Wed, 4 Oct 2023 16:39:22 -0400 Subject: [PATCH 56/80] Update architecture.md correct spelling --- _arch/architecture.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_arch/architecture.md b/_arch/architecture.md index 9b5c160ce..93d743ee7 100644 --- a/_arch/architecture.md +++ b/_arch/architecture.md @@ -409,7 +409,7 @@ The Governance services in the FICAM architecture include Identity Governance, A | Service | Description | Keywords | | --- | ------ | -----| -| Identity Governance | The systems, solutions, and rules that link enterprise personnel, applications, and data to help agencies manage access and risk. | Management Framework, Rules and Procedures, Access Reviews and Recertifications | +| Identity Governance | The systems, solutions, and rules that link enterprise personnel, applications, and data to help agencies manage access and risk. | Management Framework, Rules and Procedures, Access Reviews and Re-certifications | | Analytics | Leverage continuous analytics data to identify if someone has entitlements that conflict with access requirements. | Data collection, Monitoring, Review, Data Certification, Auditing and Reporting | | Mitigation | Correct the problems and address risks, discovered by analysis, that may occur during standard operations. | Redress, Remediation | From bf99d9e9408137824ee43c69544d1b78d03495c8 Mon Sep 17 00:00:00 2001 From: Nelson R <125207848+TheInfinityBeyonder@users.noreply.github.com> Date: Wed, 4 Oct 2023 17:02:01 -0400 Subject: [PATCH 57/80] Update introduction.md --- _implement/introduction.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_implement/introduction.md b/_implement/introduction.md index 422cc67be..eca592ade 100644 --- a/_implement/introduction.md +++ b/_implement/introduction.md @@ -48,7 +48,7 @@ The majority of engineering guides are focused on helping agencies configure PIV ICAM can leverage a number of open source protocols for interoperability and data transfer. The Federal PKI is also a large, distributed ecosystem of over 180 certification authorities. Each certification authority operate independently which presents a challenge in trying to troubleshoot why a PIV card can't validate. This is a list of tools to help troubleshoot ICAM issues. 1. Federal PKI Validation - 1. [FPKI Ecosytem Changes]({{site.baseurl}}/fpki/notifications) - This page contains three distinct pages of information as well as an associated certificate bundle. + 1. [FPKI Ecosystem Changes]({{site.baseurl}}/fpki/notifications) - This page contains three distinct pages of information as well as an associated certificate bundle. 1. [FPKI Graph]({{site.baseurl}}/fpki/notifications/#fpki-graph) - The FPKI Graph displays the relationships between the certification authorities in the Federal PKI (FPKI) ecosystem. 2. [PIV Issuer Information]({{site.baseurl}}/fpki/notifications/#piv-issuer-information) - List of active PIV issuing CAs with end entity certificate distribution points. 3. [FPKI System Change and Notification]({{site.baseurl}}/fpki/notifications/#notifications) - List of changes to FPKI CA endpoint URL such as Certificate Revocation List Distribution Points, Online Certificate Status Protocol (OCSP) endpoints and other CA certificate activity. From a13fe743298cb33e0741c1010b95a1b68754e524 Mon Sep 17 00:00:00 2001 From: Nelson R <125207848+TheInfinityBeyonder@users.noreply.github.com> Date: Wed, 4 Oct 2023 17:04:20 -0400 Subject: [PATCH 58/80] Update scl-windows.md --- _implement/scl-windows.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/_implement/scl-windows.md b/_implement/scl-windows.md index 8b6954736..fc06c47f2 100644 --- a/_implement/scl-windows.md +++ b/_implement/scl-windows.md @@ -416,10 +416,10 @@ This is the only difference when implementing the policy: which objects in your You can set the policy option on a single user by checking the _Smart Card is required for interactive logon_ check box in the user account properties. You can also apply this setting using group policy objects. When the **scforceoption** setting is applied, the SMARTCARD_REQUIRED flag is added to the UserAccountControl (UAC) and the DONT_EXPIRE_PASSWORD attribute is set to true. -## Defining Kerberos Policies for Reauthentication +## Defining Kerberos Policies for Re-authentication Although users can PIV authenticate to domain controllers, the client and the domain controller mantain those sessions using kerberos tickets. -Group policies can be configured by domain administrators to align with local security policies for maximum lifetimes of kerberos user tickets. This may cause users to be prompted to reauthenticate with their PIV when prompted with one of the following options: +Group policies can be configured by domain administrators to align with local security policies for maximum lifetimes of kerberos user tickets. This may cause users to be prompted to re-authenticate with their PIV when prompted with one of the following options: - Windows Needs Your Current Credentials - Please Lock this computer, then unlock it using your most recent password or smart card From 85a4e6363fec2a2669099c0ecd0312ce33b5a6f5 Mon Sep 17 00:00:00 2001 From: Nelson R <125207848+TheInfinityBeyonder@users.noreply.github.com> Date: Wed, 4 Oct 2023 17:04:42 -0400 Subject: [PATCH 59/80] Update scl-windows.md --- _implement/scl-windows.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_implement/scl-windows.md b/_implement/scl-windows.md index fc06c47f2..0b18a7569 100644 --- a/_implement/scl-windows.md +++ b/_implement/scl-windows.md @@ -417,7 +417,7 @@ This is the only difference when implementing the policy: which objects in your You can set the policy option on a single user by checking the _Smart Card is required for interactive logon_ check box in the user account properties. You can also apply this setting using group policy objects. When the **scforceoption** setting is applied, the SMARTCARD_REQUIRED flag is added to the UserAccountControl (UAC) and the DONT_EXPIRE_PASSWORD attribute is set to true. ## Defining Kerberos Policies for Re-authentication -Although users can PIV authenticate to domain controllers, the client and the domain controller mantain those sessions using kerberos tickets. +Although users can PIV authenticate to domain controllers, the client and the domain controller maintain those sessions using kerberos tickets. Group policies can be configured by domain administrators to align with local security policies for maximum lifetimes of kerberos user tickets. This may cause users to be prompted to re-authenticate with their PIV when prompted with one of the following options: From 9ea68ee27711bb72278359663c86adc226664b74 Mon Sep 17 00:00:00 2001 From: Nelson R <125207848+TheInfinityBeyonder@users.noreply.github.com> Date: Wed, 4 Oct 2023 17:16:59 -0400 Subject: [PATCH 60/80] Update fpkinotifications.yml --- _data/fpkinotifications.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_data/fpkinotifications.yml b/_data/fpkinotifications.yml index 8b5c984b7..11f609789 100644 --- a/_data/fpkinotifications.yml +++ b/_data/fpkinotifications.yml @@ -906,7 +906,7 @@ - notice_date: November 23, 2022 change_type: CRL and OCSP Outage system: Entrust Federal CRL and OCSP Service - change_description: On Wednesday, Novebmer 23, 2022, Entrust reported intermittent availability issues their CRL and Federal OCSP Service between 11 AM ET and 4:45 PM ET. + change_description: On Wednesday, November 23, 2022, Entrust reported intermittent availability issues their CRL and Federal OCSP Service between 11 AM ET and 4:45 PM ET. contact: support at entrust dot com cdp_uri: Multiple, http://sspweb.managed.entrust.com/CRLs/EMSSSPCA3.crl, http://feddcsweb.managed.entrust.com/CRLs/FedDCSCA1.crl ocsp_uri: ocsp.managed.entrust.com, ocspproofs.managed.entrust.com, nfiocsp.managed.entrust.com, doesspocsp.managed.entrust.com, hhspkiocsp.managed.entrust.com, feddcsocsp.managed.entrust.com From a0179f4ed860f6d424ffb3c495ba1d31a981c40b Mon Sep 17 00:00:00 2001 From: Nelson R <125207848+TheInfinityBeyonder@users.noreply.github.com> Date: Wed, 4 Oct 2023 17:17:26 -0400 Subject: [PATCH 61/80] Update ficampmo.md --- _ficampmo/ficampmo.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_ficampmo/ficampmo.md b/_ficampmo/ficampmo.md index 6f4f42d6a..104edd753 100644 --- a/_ficampmo/ficampmo.md +++ b/_ficampmo/ficampmo.md @@ -88,7 +88,7 @@ The ICAMSC charters working groups based on a defined-purpose and timeline. See ### Other ICAM Working Groups -Other ICAM working groups may be charted under other committess or subcommittees of the Federal CIO Council. +Other ICAM working groups may be charted under other committees or subcommittees of the Federal CIO Council. | Working Group Name | Purpose | Activities | Membership Requirements | Meeting Schedule | | --------- | ---- | ---------- | ------- | ----------- | From 984e7d1cb56a07955909c63e4717ca1a491522e2 Mon Sep 17 00:00:00 2001 From: Clayton J Barnette Date: Wed, 4 Oct 2023 17:44:26 -0400 Subject: [PATCH 62/80] SEO: Updated 10 H1s to H2s --- _playbooks/playbook-pam.md | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/_playbooks/playbook-pam.md b/_playbooks/playbook-pam.md index 4f5918f06..443e4c4cf 100644 --- a/_playbooks/playbook-pam.md +++ b/_playbooks/playbook-pam.md @@ -103,7 +103,7 @@ December 29, 2022 --> This playbook is a collaboration among the General Services Administration Office of Government-wide Policy Identity Assurance and Trusted Access Division, Federal Chief Information Security Officer Council ICAM Subcommittee, and the Department of Homeland Security (DHS) Cybersecurity and Infrastructure Security Agency (CISA) Continuous Diagnostic and Mitigation (CDM) Program. -# Executive Summary +## Executive Summary Privileged users are unique user types that perform various security-related duties. As such, privileged accounts are most likely to be targeted by cybercriminals or abused by malicious insiders. **Unwanted behavior or compromised privileged accounts are responsible for the most high-profile federal and private security breaches.** It is a critical Identity, Credential, and Access Management (ICAM) capability to secure privileged access. There are three prominent use cases to identify a privileged account or user: @@ -135,7 +135,7 @@ Below are key terms used throughout this playbook. A linked term denotes an offi This playbook is informative. The General Services Administration Office of Government-wide Policy, in collaboration with the Department of Homeland Security (DHS) Continuous Diagnostic and Mitigation (CDM) Program and the Federal CISO Council ICAM Subcommittee developed this playbook with input from federal identity and security practitioners. This playbook is limited to high-level guidance for privileged users accessing Federal Government information systems. This playbook shouldn't be interpreted as official policy or mandated action and doesn't provide authoritative definitions for IT terms. -# Protect Federal Identities and Logical Assets +## Protect Federal Identities and Logical Assets Government employees and contractors need a privileged account to perform necessary administrative and security functions, which creates an inherent risk of insider threat or account compromise. As a result, agencies should implement privilege user controls that reduce this risk without hindering their ability to carry out assigned job duties. In creating a secure physical and virtual workplace for privileged users, agencies align efforts with the [FICAM Architecture]({{site.baseurl}}/why/icam/). The following are the four primary high-level steps to establish or enhance an agency's privileged user management function of an agency's ICAM program. @@ -151,7 +151,7 @@ Implementing privileged user management may require a multi-year project to add {% include alert-success.html heading="Is this Privileged Access Management or Account Security?" content="Different vendors may use other terms for their products. Some vendors may use Privileged Access or Account Management (PAM), Privileged Identity Management (PIM), Privileged Security, or something in between. For the intent of this playbook, the agnostic privileged identity is used to encompass different privileged activities." %} -# Step 1. Develop a Privileged User Policy +## Step 1. Develop a Privileged User Policy Privilege compromise within an agency's privileged user population can significantly hurt its mission. See Figure 1 for the _Privilege Compromise Journey_. Poor management of an agency's privileged user population can lead to catastrophic events such as: - exfiltration of sensitive or classified data; @@ -245,7 +245,7 @@ Metrics are an essential aspect of privileged user management which can help ide | Administrator count | List and number of users with administrator-level privileges. | | Secret rotation frequency | A set period to rotate a secret such as after every use or every 30 days. | -# Step 2. Define and Identify +## Step 2. Define and Identify Agencies are responsible for managing all user privileges. Individuals entrusted with privileged accounts comprise an agency's privileged user population. ## Define a Privileged User @@ -315,7 +315,7 @@ Once the definition of a privileged user is established, an agency can identify
-# Step 3. Implement as an Enterprise ICAM Service +## Step 3. Implement as an Enterprise ICAM Service ICAM is the set of tools, policies, and systems an agency uses to provide the right individual with access to the right resources, at the right time, for the right reason in support of federal business objectives. In the context of privileged users, ICAM supports: @@ -387,7 +387,7 @@ Access management is how an agency authenticates privileged users and authorizes -# Step 4. Prioritize and Execute +## Step 4. Prioritize and Execute This step explains the technical capabilities necessary to accomplish privileged user management goals and objectives. An agency should complete the following steps: @@ -429,11 +429,11 @@ An agency should consider using a privileged access management (PAM) tool that c 1. **Session monitoring** records each privileged session. This can help with monitoring, logging, and auditing or be used for training purposes. A session recording can include an actual live screen recording or keystroke recording. 2. **Advanced Automated Account Discovery** provides immediate control over rogue accounts and devices as soon as they are created or discovered. This feature is key to mitigate a [malicious Active Directory ticket-granting activity](https://www.cisa.gov/uscert/ncas/alerts/aa22-110a){:class="usa-link usa-link--external"} such as "Kerberoasting" or a Golden Ticket attack. -# Conclusion +## Conclusion Privileged users are at the core of protecting federal information technology assets. Government employees and contractors need elevated access to perform necessary administrative and security functions however, this creates an inherent risk of insider threat or account compromise. Agencies can reduce privileged user risk by implementing and maintaining privileged user management that encompasses both human and non-human users. It is recommended to integrate the management of your privileged users with your agency ICAM tools and provide enterprise-wide services to all agency mission applications. Prioritize privilege identity control over highest risk systems and execute on the requirements to keep federal data secure. -# Appendix A: Reference Documentation +## Appendix A: Reference Documentation The following documentation references help inform the development and direction of a privileged user program. 1. [National Insider Threat Policy, November 2012](https://www.dni.gov/files/NCSC/documents/nittf/National_Insider_Threat_Policy.pdf){:target="_blank"}{:rel="noopener noreferrer"}{:class="usa-link usa-link--external"} @@ -464,7 +464,7 @@ The following documentation references help inform the development and direction 8. [Common Sense Guide to Mitigating Insider Threats (6th Edition), February 2019](https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=540644){:target="_blank"}{:rel="noopener noreferrer"}{:class="usa-link usa-link--external"} - The Software Engineering Institute at Carnegie Mellon University’s Insider Threat Center released the Common Sense Guide to provide the federal government and industry with recommendations on insider threat mitigation, based on a database of more than 700 cases. This work was sponsored by the Department of Homeland Security, Office of Cybersecurity and Communications and the U.S. Secret Service. The Common Sense Guide presents readers with 19 best practices to mitigate insider threats. -# Appendix B: Privileged User Agreement +## Appendix B: Privileged User Agreement An agency can tailor [this template]({{site.baseurl}}/docs/template-pua.docx){:target="_blank"} to help meet mission goals and business needs to support privileged user access for logical and physical resources. An agency should obtain and retain a digitally signed copy of such instruction and ensure that privileged user access to the identified protected resource is prohibited without a signed acknowledgment of system-specific rules and a signed acknowledgment of said instruction. @@ -492,7 +492,7 @@ Printed Name: Date: Digital Signature (preferred): -# Appendix C: NIST SP 800-53 Privileged User Overlay +## Appendix C: NIST SP 800-53 Privileged User Overlay In seeking to implement cohesive, integrated privileged user practices, an agency should consider existing controls and practices that can assist in safeguarding the enterprise’s protected resources from privileged compromise. This section provides an analysis of countermeasures for privileged user compromise by leveraging NIST SP 800- 53 security controls. From 4f25d7133fe5216865462c088b8627d0a3c4ae5e Mon Sep 17 00:00:00 2001 From: Clayton J Barnette Date: Wed, 4 Oct 2023 17:48:33 -0400 Subject: [PATCH 63/80] SEO: Updated 9 H1s to H2s --- _playbooks/playbook-dira.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/_playbooks/playbook-dira.md b/_playbooks/playbook-dira.md index 705640a52..07d33d2fe 100644 --- a/_playbooks/playbook-dira.md +++ b/_playbooks/playbook-dira.md @@ -101,11 +101,11 @@ December 29, 2022 --> | 1.1 | 11/17/21 | Inserted Key Point box at the end of Step 2. | | 1.0 | 09/13/20 | Initial Draft | --> -# Acknowledgments +## Acknowledgments This playbook reflects the contributions of the Digital Identity Risk Assessment working group of the Identity, Credential, and Access Management Subcommittee (ICAMSC). The working group was co-chaired by members from the Internal Revenue Service (IRS) and the Environmental Protection Agency (EPA). Contributions were made by the members of services or agencies representing the Center of Medicare and Medicaid Services (CMS), Department of Defense (DOD), Department of Health and Human Services (HHS), Department of Homeland Security (DHS), Department of Justice (DOJ), Department of the Treasury (USDT), Department of Transportation (DOT), and General Services Administration (GSA). -# Introduction +## Introduction Digital identity represents each individual engaged in an online transaction. However, an individual’s real-life identity may not be known when used to access a digital service.[^1] Identity proofing helps establish that the individual is who they claim to be. Digital authentication provides reasonable risk-based assurances that the individual accessing the application is the same individual who previously accessed the service. This playbook is a method to apply the National Institute of Standards and Technology (NIST) Special Publication 800-63-3 Digital Identity Guidelines. Federal agencies can perform a Digital Identity Risk Assessment (DIRA) to determine the appropriate identity, authenticator, or federation level outlined to access an application. @@ -149,7 +149,7 @@ This playbook does not apply to: The following sections describe a basic DIRA process and provide plays to help you implement efficiency into your agency’s processes. -# High-Level DIRA Process +## High-Level DIRA Process The DIRA process begins when a new application or system is identified or a time-driven or event-driven reassessment is triggered. Once it is determined that a DIRA is needed, application data is identified, collected, and analyzed to determine the assurance levels and produce a Digital Identity Assessment Statement (DIAS), as shown in Figure 1. @@ -349,7 +349,7 @@ If an event triggers a security impact analysis, an agency may perform a DIRA ou - How information, including PII, is processed; or - How information is processed, stored, or transmitted by the system. -# Agency Process Plays +## Agency Process Plays This section introduces six plays for your agency to create efficient and consistent processes for a DIRA. @@ -439,7 +439,7 @@ Reconsider the business process carefully and validate the current and future de {% include alert-info.html heading="Key Point" content="Some public, business, or partner users may only interact with the government process and application once a year or less.

Revisit your process and application, and allow users to complete the transaction once before opting in to create an account." %} -# Appendix A. Policy, Standards, and Guidance +## Appendix A. Policy, Standards, and Guidance This section provides links to the federal laws, policies, standards and other guidance that impact and shape DIRA implementations. NIST also publishes useful [Frequently Asked Questions](https://pages.nist.gov/800-63-FAQ/){:target="_blank"}{:rel="noopener noreferrer"}{:class="usa-link usa-link--external"} for agencies, and [Implementation Resources](https://www.nist.gov/system/files/documents/2020/07/02/SP-800-63-3-Implementation-Resources_07012020.pdf){:target="_blank"}{:rel="noopener noreferrer"}{:class="usa-link usa-link--external"} for solution developers. @@ -463,7 +463,7 @@ This section provides links to the federal laws, policies, standards and other g | NIST SP 800-53A | NIST Special Publication 800-53A, Revision 5, [Assessing Security and Privacy Controls in Information Systems and Organizations](https://csrc.nist.gov/publications/detail/sp/800-53a/rev-5/final){:target="_blank"}{:rel="noopener noreferrer"}{:class="usa-link usa-link--external"}, Updated January 2022 | | NIST RMF Overview               | NIST [Risk Management Framework Overview](https://csrc.nist.gov/projects/risk-management/about-rmf){:target="_blank"}{:rel="noopener noreferrer"}{:class="usa-link usa-link--external"}, November 30, 2016| -# Appendix B. Examples and Templates +## Appendix B. Examples and Templates This appendix provides examples and templates of existing resources to help establish or improve DIRA processes. It includes the following sections: @@ -507,7 +507,7 @@ This section includes additional example process flow diagrams used by some agen This [Digital Identity Acceptance Statement template]({{site.baseurl}}/docs/playbook-dira-dias-template.docx){:target="_blank"}{:rel="noopener noreferrer"} is provided as one sample for agencies. -# Appendix C. NIST Special Publication 800-63-3, Requirements Traceability Matrix +## Appendix C. NIST Special Publication 800-63-3, Requirements Traceability Matrix This appendix includes both normative requirements and informative references from NIST SP 800-63-3 Digital Identity Guidelines. Only requirements related to the agency processes for digital identity risk assessments are included. The Playbook Consideration column includes comments on the standards statements and alignment to this playbook’s development. @@ -526,7 +526,7 @@ This appendix includes both normative requirements and informative references fr | Agencies shall implement procedures to document both the justification for any departure from normative requirements and detail the compensating control(s) employed. | 5.4 | Supports the proposed process step to standardize Digital Identity Acceptance Statements and the examples provided by agencies. | | In analyzing risks, agencies shall consider all of the expected direct and indirect results of an authentication failure, including the possibility that there will be more than one failure or harms to more than one person or organization.

The definitions of potential impacts contain some relative terms, like “serious” or “minor,” whose meaning will depend on context. The agency should consider the context and the nature of the persons or entities affected to decide the relative significance of these harms. Over time, the meaning of these terms will become more definite as agencies gain practical experience with these issues. The analysis of harms to agency programs or other public interests depends strongly on the context; the agency should consider these issues with care. | 6 | Supports the proposed play to add context when determining risk with application owners and business teams. | -# Appendix D. Updates to NIST Special Publication 800-63 +## Appendix D. Updates to NIST Special Publication 800-63 In June 2017, NIST replaced the Electronic Authentication Guideline[^24] with the Digital Identity Guidelines.[^25] The new standard provides agencies increased security and privacy, more flexibility to meet their mission and constituent needs, and better alignment with digital identity best practices. It outlines the digital identity risk assessment methodology that federal agencies must implement. @@ -558,7 +558,7 @@ The revised guidance provides individual assurance levels that can be mixed and - Enhanced privacy, and - Reduced risk. -# Footnotes +## Footnotes [^1]: A digital service is any federal Information Technology (IT) system or application accessible over the public internet or agency intranet. [^2]: A Digital Identity Risk Assessment is a method of applying Digital Identity Risk Management required by OMB Memorandum 19-17: Enabling Mission Delivery through Improved Identity, Credential, and Access Management, and NIST Special Publication 800-63-3 Digital Identity Guidelines. From 108a03f08af6a950aa1cc01f1b7267eb27366b27 Mon Sep 17 00:00:00 2001 From: Clayton J Barnette Date: Wed, 4 Oct 2023 18:13:48 -0400 Subject: [PATCH 64/80] SEO: Updated 8 H1s to H2s --- _university/pm101.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/_university/pm101.md b/_university/pm101.md index 2e929cdc6..9cd75e18e 100644 --- a/_university/pm101.md +++ b/_university/pm101.md @@ -26,7 +26,7 @@ subnav: --- -# Introduction +## Introduction The **ICAM Program Management 101** explains how to plan and implement an Identity, Credential, and Access Management (ICAM) Program, as outlined in the [Federal Identity, Credential, and Access Management (FICAM) Architecture]({{site.baseurl}}/arch/){:target="_blank"}{:rel="noopener noreferrer"}. You'll find content for ICAM program managers who need agency-level planning best practices to drive adoption of ICAM services within their organizations. You'll also find information on how to govern the program, identify and communicate with stakeholders, manage risk, and other related topics. @@ -53,7 +53,7 @@ The following list includes the necessary components of an ICAM program. - [**Performance Management**](#performance-management) - Measure and report progress, effectiveness, and improvements. - [**Privacy Requirements**](#privacy-requirements) - Manage risks associated with handling personally identifiable information (PII). -# Program Governance and Leadership +## Program Governance and Leadership In any Identity, Credential, and Access Management (ICAM) program, you'll need someone to develop, manage, and enforce agency-specific policies, processes, and performance measures. @@ -157,7 +157,7 @@ The figure below represents a sample ICAM PMO structure. An agency should design Sample ICAM PMO Structure. -# Workstreams +## Workstreams In the context of this guide, workstreams are the focus areas or projects within an Identity, Credential, and Access Management (ICAM) framework. @@ -210,7 +210,7 @@ The following image depicts a series of ICAM administrative workstreams, adapted ICAM Governance Responsibilities. -# Stakeholder Management +## Stakeholder Management A stakeholder is an individual or organization that has an interest in the program, either because the stakeholder is actively involved in the program or might be affected by the program’s outcome. @@ -282,7 +282,7 @@ To encourage collaboration, develop working groups that comprise stakeholders ac You can also stand up smaller focus groups or tiger teams devoted to specific program issues or direct implementation support. You'll promote consistency and stakeholder buy-in by encouraging better understanding, inclusion, and ownership in the program. -# Communication Plan +## Communication Plan A communication plan outlines an Identity, Credential, and Access Management (ICAM) program's objectives, goals, themes, and approach. You should create a communication plan early in the lifecycle to communicate consistently and effectively with users and stakeholders. @@ -302,7 +302,7 @@ You should tailor the messages and delivery methods to the stakeholders. The goa {% include alert-success.html heading = "Lesson Learned" content="Communicate changes that impact users early and often and across multiple messaging vehicles." %} -# Performance Management +## Performance Management Program leadership and stakeholders need tools to monitor progress, determine program effectiveness, and identify areas of improvement. To accomplish this, assign performance measurements to your agency's Identity, Credential, and Access Management (ICAM) program. @@ -323,7 +323,7 @@ Incorporate relevant metrics in your Exhibit 300 for any ICAM investment to trac Tie your agency's ICAM program accomplishments directly to the responsible individual's yearly performance plan. This helps leadership and management assume ownership and feel accountable for the ICAM program's success. -# Privacy Requirements +## Privacy Requirements All federal agencies and programs that collect, retain, or use personally identifiable information (PII) are required to complete and maintain program documents to support these activities. @@ -353,7 +353,7 @@ The table below describes each of the FIPPs and gives practical implementation c | **Security** | Protect PII through safeguards against risks such as loss, unauthorized access or use, destruction, modification, or unintended or inappropriate disclosure. | Your agency must ensure the security of information at all stages (collection, transmission, storage, destruction) in accordance with various legal and policy requirements, such as FISMA and OMB M-07-16. Examples of techniques for securing data include:

• Encryption.

• Strong authentication procedures.

• Time-out functionality.

• Minimum security controls to make information unusable by unauthorized individuals. | | **Transparency** | Be transparent about the information your agency collects and shares, and notify the individual regarding collection, use, dissemination, and maintenance of PII. | A foundational principle in federal privacy law is that people have the right to know what information the government collects and retains about them and, to a great extent, the right to control how that information is used. Consider this principle and ensure the following before each occurrence of information collection or transmission:

• Inform the user about which information elements you'll collect.

• Inform the user who will receive the information.

• Inform the user about how you'll use the information.

• Allow the user to affirmatively choose to participate before you transmit any information. | -# PM Implementation Examples +## PM Implementation Examples We recommend leveraging existing resources to establish your Identity, Credential, and Access Management (ICAM) program and define roles and responsibilities across the enterprise. From 3bf05ec5125d6f586eb161a022f67433e0ed7ac7 Mon Sep 17 00:00:00 2001 From: Clayton J Barnette Date: Wed, 4 Oct 2023 18:22:02 -0400 Subject: [PATCH 65/80] SEO: Updated 10 H1s to H2s --- _playbooks/playbook-dw.md | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/_playbooks/playbook-dw.md b/_playbooks/playbook-dw.md index ba6947410..61a8d091c 100644 --- a/_playbooks/playbook-dw.md +++ b/_playbooks/playbook-dw.md @@ -94,7 +94,7 @@ This playbook is a collaboration between the Identity, Credential, and Access Ma | 1.1 | 11/18/2021 | Renumbered tables | | 1.0 | 01/05/2021 | Initial Draft | --> -# Executive Summary +## Executive Summary The Digital Worker Identity Playbook is a practical guide to manage digital worker identities. This playbook helps federal agency ICAM programs as well as CIO and CISO offices determine the risk of and define a process for digital worker identity management. A digital worker is an automated, software-based tool, application, or agent that performs a business task or process similar to a human user and uses Artificial Intelligence (AI) or other autonomous decision-making capabilities. OMB memo 19-17 requires agencies to ensure the digital identity of automated technologies are “distinguishable, auditable, and consistently managed.” However, agencies face implementation challenges when establishing identities for digital workers. Most often, they attempt to use human worker processes, which may hinder digital worker creation or access. Common challenges include: - Human worker identity attributes that do not apply to a digital worker. For example, some agencies create ad hoc digital worker identity attributes based on requirements for human users, some of which do not apply (e.g., work station location). Conversely, the scope of identity attributes required for human users may not include some attributes that are needed for digital workers (e.g., custodian names). @@ -126,7 +126,7 @@ The list below includes the most common types of digital workers. This playbook was developed by the General Services Administration Office of Government-wide Policy with input from federal IT practitioners. This document shouldn’t be interpreted as official policy or mandated action, and doesn’t provide authoritative definitions for IT terms. Instead, this playbook supplements existing federal IT policies and builds upon the Office of Management and Budget (OMB) Memorandum 19-17 (M-19-17), Enabling Mission Delivery through Improved Identity, Credential, and Access Management and existing federal identity guidance and playbooks. Subject areas with intersecting scope, such as the ethical use and development of digital workers, are considered only to the extent that they relate to digital identity management and credentialing for digital workers. Specific security control implementations are out of scope of this playbook, as are any elements of data protection requirements and the suitability process for a digital worker sponsor and custodian. -# A Three-Step Process for Digital Worker Identity Management +## A Three-Step Process for Digital Worker Identity Management The three-step process outlined below is a structured, iterative approach with discrete actions to create a digital worker identity management process. _CIO and CISO offices_ are the intended audience for this guide. Use this guide to write, update, or enhance existing enterprise identity management policies. Agencies are encouraged to tailor these steps to meet organizational structures, unique requirements, and mission needs. @@ -149,7 +149,7 @@ The Digital Worker Impact Evaluation Matrix is a scoring tool. It uses six facto This playbook should aid agencies in integrating digital worker identity management processes into existing enterprise identity management policies. -# Step 1. Determine the Impact +## Step 1. Determine the Impact The process of establishing digital worker identities. Step 1 is Determine the impact. Step 2 is Create an identity. Step 3 is Provision an identity. The Step 1 portion is dark blue. The Step 2 and Step 3 portions are gray. @@ -246,7 +246,7 @@ The four adverse impact levels represent a different scale of harm a digital wor | 56-90 | **High** | Effects of an error or accident are wide-ranging and could result in serious or long-term impact on organizational missions/business functions, organizational assets, or the nation. This includes significant financial losses for the agency; substantially reduced capacity to conduct mission critical business; loss of PII, Business Identifiable Information, or PHI; and/or damage to agency image or reputation. | | 91+ | **Critical** | Effects of an error or accident are extensive and will have severe or catastrophic impact on organizational missions/business functions, assets, or the nation. This includes major financial losses for the agency or other organizations, loss of government continuity of operations or ability to conduct mission critical business, life-threatening injury or loss of life, and/or harm to national security. | -# Step 2. Create an Identity +## Step 2. Create an Identity The process of establishing digital worker identities. Step 1 is Determine the impact. Step 2 is Create an identity. Step 3 is Provision an identity. The Step 1 portion is gray. The Step 2 portion is dark red. The Step 3 portion is gray. @@ -310,7 +310,7 @@ Use Table 5 for specific validation actions aligned with adverse impact level. {% include alert-info.html heading="Key Point" content="VD-3, VD-4, and VD-5 are validating the code, ethics, and bias reviews that have been conducted. It is up to the individual agencies to ensure a standard for conducting such reviews is followed. Agency representatives, such as the sponsor or custodian, should collaborate within a community of practice to capture best practices on how to perform the various reviews in Step 2.2." %} -# Step 3. Provision an Identity +## Step 3. Provision an Identity The process of establishing digital worker identities. Step 1 is Determine the impact. Step 2 is Create an identity. Step 3 is Provision an identity. The Step 1 and Step 2 portions are gray. The Step 3 portion is dark green. @@ -359,7 +359,7 @@ Agencies may store and track identity governance data elements in an existing sy | DF-17 | **Digital Worker Bias Review Completion Date** | _Specify the digital worker bias review completion date (refer to VD-5 for more details). Recommend including the date in the format specified by agency guidelines (e.g., 01/01/2020)._ | | DF-18 | **Next Bias Review Date**
_(optional)_ | _Track when the next bias review date must be conducted. This can be tracked as a formula based on the last bias review date and adverse impact level requirements, or a format and method specified by agency guidelines._ | -# Conclusion +## Conclusion Digital worker identity management requires new government-wide policies and guidance tailored to digital workers' unique functional and security considerations. Government-wide adoption and implementation of this playbook provide agencies distinct actions on how to manage and maintain their digital workforce. @@ -369,7 +369,7 @@ Digital worker identity management requires new government-wide policies and gui This playbook is iterative, and agencies are encouraged to collaborate, share best practices, and share lessons learned. Consider joining a federal committee and community of practice to learn and engage in digital worker identity management. -# Appendix A. Digital Worker Impact Evaluation Factors +## Appendix A. Digital Worker Impact Evaluation Factors This section provides a detailed breakdown of the information contained in Table 1, the Digital Worker Impact Evaluation Matrix. @@ -440,7 +440,7 @@ This factor assesses the extent to which a human is involved in approving the de | **6b)** Digital worker develops insights and acts on the insights after human review | The digital worker is used first to develop insights. A human then reviews the insight and either edits or approves the insight. (e.g., a digital worker is used to diagnose a patient based on medical history data, then the tool will use the data to develop a diagnosis and recommended treatment [insight]. The doctor will review the diagnosis and recommended treatment. If the doctor disagrees with the insight, they will amend it; if the doctor agrees, they will approve it. Then, the digital worker administers the treatment to the patient.) | 5 | | **6c)** Digital worker develops insight and acts on the insights without human review or approval before the action is taken | The tool develops insights and then uses the insight to determine a course of action. The tool proceeds with this action without human review of the initial insight. (e.g., a digital worker recommends a diagnosis and treatment based on data from the patient’s medical history. The digital worker acts on this recommendation by administering treatment to the patient without a doctor’s intermediary review.) | 10 | -# Appendix B. Critical Case Study +## Appendix B. Critical Case Study A government hospital uses a digital worker to diagnose patients. - The digital worker uses an unattended machine learning algorithm on internal networks. @@ -514,7 +514,7 @@ After the sponsorship and validation activities are complete and documented, the | DF-18 | **DW Bias Review Completion Date** | 07/11/2020 | | DF-19 | **DW Next Bias Review Date** _(optional)_ | 01/11/2021 | -# Appendix C. Low Case Study +## Appendix C. Low Case Study A digital worker helps the General Services Administration gather data on COVID-19. - The digital worker is unattended, uses a standard system account, and has internal and external network access. @@ -542,7 +542,7 @@ A digital worker helps the General Services Administration gather data on COVID- This digital worker impact level is Low. Its effect of an error or accident is minimal, resulting in negligible impacts. Low does not require a unique identity for a digital worker. The impact level is documented and a reminder is set to reassess the impact level with any code change. -# Footnotes +## Footnotes [^1]: Digital worker is not synonymous with non-person entity (NPE), as NPE encompasses all entities with a digital identity including organizations, hardware devices, software applications, and information artifacts. [^2]: OMB Memorandum 19-17 instructs federal agencies to designate an integrated agency-wide ICAM office, team, or other governance structure in support of its Enterprise Risk Management capability to effectively govern and enforce ICAM efforts. From aeebffb451964643e89f841b792150664e1f7ac7 Mon Sep 17 00:00:00 2001 From: Clayton J Barnette Date: Wed, 4 Oct 2023 18:29:44 -0400 Subject: [PATCH 66/80] SEO: Updated 10 H1s to H2s --- _playbooks/playbook-whfb.md | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/_playbooks/playbook-whfb.md b/_playbooks/playbook-whfb.md index 0098717e2..b3e9f0f27 100644 --- a/_playbooks/playbook-whfb.md +++ b/_playbooks/playbook-whfb.md @@ -93,7 +93,7 @@ August 14, 2023 --> The purpose of this playbook is to guide ICAM program managers and Entra ID administrators through planning, configuring, testing, and implementing a **Windows Hello for Business (WHfB) configuration when devices are cloud-joined**. WHfB also allows design for hybrid-joined devices. Hybrid-joined relies on either a 3rd party mobile device manager or Windows devices managed through an on-premise Active Directory. This configuration can be more complex and architecture-specific. Due to this, the playbook only covers a cloud-join configuration. WHfB offers two-factor authentication by combining a device authenticator (something you have) and either a PIN (something you know) or a biometric (something you are). -# Why Windows Hello for Business +## Why Windows Hello for Business Windows Hello for Business is a phishing-resistant FIDO2 platform authenticator native to Azure AD that does not require additional hardware or software. It is an alternative authenticator for use cases where using PIV is impractical. An agency could also develop a Derived PIV solution for WHfB requiring PIV authentication before registering WHfB. Some everyday use cases where PIV is impractical or unavailable may include the following: @@ -104,7 +104,7 @@ Windows Hello for Business is a phishing-resistant FIDO2 platform authenticator Traditionally in these scenarios, agencies leverage a policy exception process where the exception authenticator is either a time-limited username and password or a One-Time Pin. Unfortunately, these exception authenticators are susceptible to sophisticated phishing attacks, which can convincingly spoof official applications and involve dynamic user interaction. Users can be fooled into providing a one-time code or responding to a security prompt that grants the attacker account access. These attacks can be fully automated and operate cheaply at a significant scale. -# Lessons Learned from FIDO2 Community of Action +## Lessons Learned from FIDO2 Community of Action The FIDO2 Community of Action is an Office of Management and Budget initiative to help agencies rapidly replace exception authenticators with a phishing-resistant alternative either as an alternative or a backup authenticator. The most common authenticators piloted by the CoA agencies include WHfB, FIDO2 security keys, and Derived PIV on a government mobile device or a FIDO2 security key. For common questions with WHfB, see the FAQs. Below is a list of lessons learned from CoA agencies in the piloting and production use of WHfB. @@ -132,7 +132,7 @@ The available sign-in options for Windows Hello for Business include the followi WHfB PINs may seem similar to passwords at first glance. However, there is a fundamental difference: PINs typically are local to the device and not transmitted over the internet, unlike a Microsoft 365 or Azure Active Directory (Azure AD) User Principal Name and Password combination. Device PIN creation establishes a trusted relationship with the identity provider (Azure AD). It also creates an asymmetric key pair that is used for authentication. Transmittal of the public key to the authentication server completes the sign-in request. When paired with a Trusted Platform Module (TPM) chip, tamper protection is enabled. This feature protects the key material from attackers and locks the device after too many incorrect PIN attempts. Biometric data is stored locally on the device and never sent to external devices or servers. As stated previously, authentication occurs via the asymmetric key. Users can delete or remove their biometric information by visiting **Settings** \> **Accounts** \> **Sign-in options.** -# Assumptions +## Assumptions This playbook assumes that devices are cloud-only joined and that no hybrid configuration with Active Directory exists. Hybrid deployments come in multiple designs with constraints based on on-premise components. This playbook is meant to support agencies in implementing the Federal Zero Trust Strategy action steps for application action and reducing the use of network authentication. Deploying Windows Hello for Business in a [hybrid environment](https://learn.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-identity-verification#hybrid-deployments){:target="_blank"}{:rel="noopener noreferrer"}{:class="usa-link usa-link--external"} comes in four configurations driven by how devices are managed. 1. Cloud kerberos trust 2. Key trust @@ -141,14 +141,14 @@ This playbook assumes that devices are cloud-only joined and that no hybrid conf These hybrid deployments require configuring Azure AD Connect, Azure AD Kerberos and deploying either a Cloud Trust Device Configuration Profile in Microsoft Intune (Intune), a Key trust deployment in on-premises Active Directory, or a hybrid certificate trust deployment, which requires Active Directory Federated Services (ADFS). Of these three hybrid options, the Cloud Kerberos trust deployment is recommended. -# Prerequisites +## Prerequisites For cloud-joined deployment, this playbook assumes that: - all devices have a TPM 2.0 module that complies with Federal Information Processing Standards (FIPS). All devices should be on Windows 10 version 1709 (or later) or Windows 11. Preferably, all devices should be Windows 10 version 1903 or later. - Devices are equipped with an infrared camera or fingerprint reader for biometric authentication. - Microsoft Intune (Intune) is the Windows MDM solution. - Not required, but it's preferable that all users have an Azure AD Premium P1 or P2 subscription, which is needed for automatic MDM enrollment when the device joins Azure AD. Azure AD Premium P1 licenses also grant access to Azure AD Multi-Factor Authentication (MFA) through Conditional Access policies. -# Technology and terms +## Technology and terms See this Microsoft primer on [Introduction to device identity and join types](https://learn.microsoft.com/en-us/azure/active-directory/devices/overview){:target="_blank"}{:rel="noopener noreferrer"}{:class="usa-link usa-link--external"} @@ -191,7 +191,7 @@ Learn more about [hybrid Azure AD joined devices](https://learn.microsoft.com/en Device management enables organizations to administer and maintain devices, including virtual machines, physical computers, mobile devices, and IoT devices. Microsoft Intune is the mobile device management (MDM) solution for the Microsoft 365 platform. -# Prepare users to use Windows Hello +## Prepare users to use Windows Hello ### Using Windows Hello and biometrics @@ -230,7 +230,7 @@ Suppose you sign in on **Device B** and change your password for your Microsof 5. Sign in with new password. 6. The next time that you sign in, you can select **Sign-in options \> PIN** to resume using your PIN. -# WHfB policy configuration +## WHfB policy configuration Windows Hello for Business can be enabled multiple ways through Microsoft Intune. The first method is through Windows Device Enrollment. This method can be used for devices that are Azure AD joined but have not yet enrolled in Intune. The second method, Device Configuration Profile, is used for devices already enrolled in Intune. @@ -500,7 +500,7 @@ Select **Next** to continue. ![Figure 13: Windows Hello for Business Configuration Profile Completion]({{site.baseurl}}/assets/playbooks/whfb/13-Intune-WHfB-ConfigProfile-review.png) -# WHfB user experience +## WHfB user experience This section details the user experience for setting up Windows Hello for Business. The minimum device requirements for fingerprint and facial recognition sensors can be found [here](https://learn.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-biometrics-in-enterprise#has-microsoft-set-any-device-requirements-for-windows-hello){:target="_blank"}{:rel="noopener noreferrer"}{:class="usa-link usa-link--external"}{:aria-label="The minimum device requirements for fingerprint and facial recognition sensors can be found here"}. @@ -546,7 +546,7 @@ After signing out once, WHfB is configured with a PIN (minimum requirement), as ![Figure 19: Windows Sign-in with PIN]({{site.baseurl}}/assets/playbooks/whfb/19-whfb_sign_out_experience.png) -# Windows Hello for Business: Microsoft Authenticator Setup for iOS and Android +## Windows Hello for Business: Microsoft Authenticator Setup for iOS and Android ## iOS - Microsoft Authenticator setup @@ -797,7 +797,7 @@ Follow the prompts to lift your finger and touch the sensor again in order to ma If users choose to do so, they can add multiple fingerprints for improved recognition. -# Windows Hello for Business FAQs +## Windows Hello for Business FAQs Some of the most commonly asked questions about WHfB are presented below. A full list of common questions can be found [here](https://learn.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-faq){:target="_blank"}{:rel="noopener noreferrer"}{:class="usa-link usa-link--external"}{:aria-label="A full list of common questions can be found here"}. From fedaef33084d5a24cfcfbd64598b69453123881a Mon Sep 17 00:00:00 2001 From: Clayton J Barnette Date: Wed, 4 Oct 2023 18:32:18 -0400 Subject: [PATCH 67/80] SEO: Updated 6 H1s to H2s --- _arch/architecture.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/_arch/architecture.md b/_arch/architecture.md index 9b5c160ce..3f4211906 100644 --- a/_arch/architecture.md +++ b/_arch/architecture.md @@ -95,7 +95,7 @@ June 30, 2023 --> -# Introduction +## Introduction FICAM is the federal government’s implementation of Identity, Credential, and Access Management (ICAM). @@ -181,7 +181,7 @@ In 2015, ICAM experts from across the federal government collaborated on an upda This site contains the current version for the FICAM Architecture. The FICAM Roadmap and Implementation Guidance v2.0 is superseded by both the FICAM Architecture updates and other complementary modernized playbooks developed by ICAM committees across government. -# Goals and Objectives +## Goals and Objectives The Goals and Objectives identify the aims and outcomes of a federal agency enterprise ICAM program. The goals and objectives align with ICAM functions and map to government-wide policies, cross-agency priorities, and strategic government initiatives. @@ -212,7 +212,7 @@ The visual below presents the three goals, each with its own objectives. - 3.2 Evaluate, rationalize, and migrate to modern, cloud-smart solutions for ICAM services. - 3.3 Promote interoperability and efficiency across the federal government by buying and building ICAM solutions that use open, commercially adopted standards. -# Services Framework and Service Descriptions +## Services Framework and Service Descriptions The Services Framework is a tool designed for ICAM program managers and information technology enterprise architects. It identifies the services that provide functionality within the scope of ICAM and assists in distinguishing between business requirements and technical solutions. The services framework includes the five practice areas and services within. @@ -413,7 +413,7 @@ The Governance services in the FICAM architecture include Identity Governance, A | Analytics | Leverage continuous analytics data to identify if someone has entitlements that conflict with access requirements. | Data collection, Monitoring, Review, Data Certification, Auditing and Reporting | | Mitigation | Correct the problems and address risks, discovered by analysis, that may occur during standard operations. | Redress, Remediation | -# Use Cases +## Use Cases These use cases are designed for ICAM Enterprise Architects and business owners and describe some of the most common ICAM business processes. @@ -801,7 +801,7 @@ You can combine or build upon the ICAM use cases to support your agency’s scen
-# Reference Example +## Reference Example This reference example include sample enterprise ICAM tools (e.g., solutions, applications, and software) aligned with ICAM service areas that illustrate ICAM functionality at an agency. The reference examples are designed for enterprise architects, security engineers, and solution architects to facilitate discussions regarding the technology solutions to integrate with enterprise applications and the business requirements. @@ -883,7 +883,7 @@ Agency endpoints may include: - Government cloud email services - Government facilities -# Policies and Standards +## Policies and Standards See the [ICAM Policy Matrix]({{site.baseurl}}/university/policymatrix/) for the latest set of ICAM policies and standards. From 818ca0ffa63c6db489d6be03786cdd1259a69855 Mon Sep 17 00:00:00 2001 From: Nelson R <125207848+TheInfinityBeyonder@users.noreply.github.com> Date: Wed, 4 Oct 2023 19:25:27 -0400 Subject: [PATCH 68/80] Update laws-policies-standards.yml --- _data/laws-policies-standards.yml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/_data/laws-policies-standards.yml b/_data/laws-policies-standards.yml index cd8b016a5..6e42a9f1e 100644 --- a/_data/laws-policies-standards.yml +++ b/_data/laws-policies-standards.yml @@ -672,7 +672,7 @@ shortName: "ICAM Governance Framework" longName: "Identity, Credential, and Access Management Governance Framework" description: >- - The ICAM Governance Frameowork Working Group, composed of ICAM practitioners from + The ICAM Governance Framework Working Group, composed of ICAM practitioners from several federal agencies, developed this ICAM Governance Framework as a tool to help agencies build and improve ICAM governance structures, processes, and policies. published: 2021-09-01 @@ -686,7 +686,7 @@ shortName: "NISTIR 8149" longName: "NIST Interagency Report 8149: Developing Trust Frameworks to Support Identity Federations" description: >- - Desecribes trust frameworks for identity federations, which provide a secure method for leveraging shared + Describes trust frameworks for identity federations, which provide a secure method for leveraging shared identity credentials across communities of similarly-focused online service providers. published: 2018-01-12 externalURL: "https://csrc.nist.gov/publications/detail/nistir/8149/final" @@ -863,7 +863,7 @@ - Access Management - Authentication - &PLAYBOOKS type: Guidance - shortName: "FICAM Playboks" + shortName: "FICAM Playbooks" longName: "FICAM Playbooks" description: >- A playbook is a comprehensive guide on a technical topic, describing both overarching strategy From 8441b8bc8e06d1670060f49feedb25080d1dac64 Mon Sep 17 00:00:00 2001 From: Nelson R <125207848+TheInfinityBeyonder@users.noreply.github.com> Date: Wed, 4 Oct 2023 19:27:26 -0400 Subject: [PATCH 69/80] Update playbook-cloud.md --- _playbooks/playbook-cloud.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_playbooks/playbook-cloud.md b/_playbooks/playbook-cloud.md index e9e2a8fbe..385cab9bc 100644 --- a/_playbooks/playbook-cloud.md +++ b/_playbooks/playbook-cloud.md @@ -554,7 +554,7 @@ See the [GSA Guide](https://tech.gsa.gov/guides/dev_sec_ops_guide/){:target="_bl 1. [NIST Special Publication 800-63 - Digital Identity Guidelines](https://pages.nist.gov/800-63-3/){:target="_blank"}{:rel="noopener noreferrer"}{:class="usa-link usa-link--external"} 2. [NIST Special Publication 800-145 - The NIST Definition of Cloud Computing](https://csrc.nist.gov/publications/detail/sp/800-145/final){:target="_blank"}{:rel="noopener noreferrer"}{:class="usa-link usa-link--external"} -3. [NIST Special Publication 800-204B - Attribute-Based Access Control for Microservices-Bbased Applications Uusing a Service Mesh](https://csrc.nist.gov/publications/detail/sp/800-204b/final){:target="_blank"}{:rel="noopener noreferrer"}{:class="usa-link usa-link--external"} +3. [NIST Special Publication 800-204B - Attribute-Based Access Control for Microservices-Bbased Applications Using a Service Mesh](https://csrc.nist.gov/publications/detail/sp/800-204b/final){:target="_blank"}{:rel="noopener noreferrer"}{:class="usa-link usa-link--external"} 4. [NIST Special Publication 800-207 - Zero Trust Architecture](https://csrc.nist.gov/publications/detail/sp/800-207/final){:target="_blank"}{:rel="noopener noreferrer"}{:class="usa-link usa-link--external"} 5. [NIST Special Publication 800-210 - General Access Control Guidance for Cloud Systems](https://csrc.nist.gov/publications/detail/sp/800-210/final){:target="_blank"}{:rel="noopener noreferrer"}{:class="usa-link usa-link--external"} From 1d0ab51079c9d94597b81bbeb344acb407505b0c Mon Sep 17 00:00:00 2001 From: Nelson R <125207848+TheInfinityBeyonder@users.noreply.github.com> Date: Wed, 4 Oct 2023 19:28:06 -0400 Subject: [PATCH 70/80] Update playbook-ilm.md --- _playbooks/playbook-ilm.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_playbooks/playbook-ilm.md b/_playbooks/playbook-ilm.md index 501facbc1..681e514bf 100644 --- a/_playbooks/playbook-ilm.md +++ b/_playbooks/playbook-ilm.md @@ -165,7 +165,7 @@ It’s common in the federal ICAM community to synonymously refer to everything This playbook has two distinct sections. 1. The first section is an overview of identity lifecycle management. It explains the distinct processes involved in managing identities and gives a brief description of the similarities and differences in managing a PIV card versus managing an identity. -2. The second section contains plays on how to create an identity lifecycle management process within your agency. It includes four steps to create a policy, architect a solution, create a master user record, and then integrate the master user record for entrprise-wide use. +2. The second section contains plays on how to create an identity lifecycle management process within your agency. It includes four steps to create a policy, architect a solution, create a master user record, and then integrate the master user record for enterprise-wide use. The next section will outline the identity lifecycle process. From 53be5e258d3ed72496bd1caac18310e5531007e0 Mon Sep 17 00:00:00 2001 From: Nelson R <125207848+TheInfinityBeyonder@users.noreply.github.com> Date: Wed, 4 Oct 2023 19:34:43 -0400 Subject: [PATCH 71/80] Update trust-services.md --- _partners/trust-services.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_partners/trust-services.md b/_partners/trust-services.md index ab02f432d..9fef16b53 100644 --- a/_partners/trust-services.md +++ b/_partners/trust-services.md @@ -22,7 +22,7 @@ subnav:

DigiCert PKI Shared Services Decommission and Transition

- DigiCert announced it is decommissiong it's federal shared services platform and transitioning out of the PKI Shared Service Provider program by 2024. They will transition existing customers and not accept any new customers. For transition information, contact FPKI at GSA.gov. + DigiCert announced it is decommissioning its federal shared services platform and transitioning out of the PKI Shared Service Provider program by 2024. They will transition existing customers and not accept any new customers. For transition information, contact FPKI at GSA.gov.

From 17743ae8947ba80161cbaf5f6c35490d81e7128f Mon Sep 17 00:00:00 2001 From: Nelson R <125207848+TheInfinityBeyonder@users.noreply.github.com> Date: Wed, 4 Oct 2023 19:36:28 -0400 Subject: [PATCH 72/80] Update scl-macos.md --- _implement/scl-macos.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_implement/scl-macos.md b/_implement/scl-macos.md index 0641cacff..cfd551004 100644 --- a/_implement/scl-macos.md +++ b/_implement/scl-macos.md @@ -86,7 +86,7 @@ An agency may deploy a plist through various remote mechanisms. 2. Leveraging an [Apple specific configuration tool](https://apps.apple.com/us/app/apple-configurator-2/id1037126344?mt=12){:target="_blank"}{:rel="noopener noreferrer"}{:class="usa-link usa-link--external"} via the App Store 3. Direct configuration profile delivery via an email, webpage, or [over-the-air profile delivery](https://developer.apple.com/library/archive/documentation/NetworkingInternet/Conceptual/iPhoneOTAConfiguration/Introduction/Introduction.html#//apple_ref/doc/uid/TP40009505){:target="_blank"}{:rel="noopener noreferrer"}{:class="usa-link usa-link--external"} -If a remote deployment it not availabler, the administrator may also perform the configuration locally following Step 1 and 2. +If a remote deployment is not available, the administrator may also perform the configuration locally following Step 1 and 2. ## Helpful References 1. [Apple Deployment Guide - Use a smart card in macOS](https://support.apple.com/guide/deployment/use-a-smart-card-depc705651a9/web){:target="_blank"}{:rel="noopener noreferrer"}{:class="usa-link usa-link--external"} From 13b18bc9b43b973459138d535cf6a1437455c64b Mon Sep 17 00:00:00 2001 From: Nelson R <125207848+TheInfinityBeyonder@users.noreply.github.com> Date: Wed, 4 Oct 2023 19:37:10 -0400 Subject: [PATCH 73/80] Update fpki_tools_cite-guide.md --- _implement/fpki_tools_cite-guide.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_implement/fpki_tools_cite-guide.md b/_implement/fpki_tools_cite-guide.md index 6efd4a386..a55c01e25 100644 --- a/_implement/fpki_tools_cite-guide.md +++ b/_implement/fpki_tools_cite-guide.md @@ -143,7 +143,7 @@ CITE Participants shall provide the FPKI Technical Working Group with email and The table below lists the current test to production OID equivalent used by the FPKIMA and CITE Participants. -1. [Federal PKI Trust Infrascture Test OIDs](#federal-pki-trust-infrastructure-test-oids) +1. [Federal PKI Trust Infrastructure Test OIDs](#federal-pki-trust-infrastructure-test-oids) 2. [Federal Agency PKI Test OIDs](#federal-agency-pki-test-oids) 3. [Federal Shared Service Provider (SSP) Test OIDs](#federal-shared-service-provider-ssp-test-oids) 4. [Non-Federal Issuer (NFI) Test OIDs](#non-federal-issuer-nfi-test-oids) From b18b10af13f9c6d109c152768445b4d8a7a724e6 Mon Sep 17 00:00:00 2001 From: Nelson R <125207848+TheInfinityBeyonder@users.noreply.github.com> Date: Wed, 4 Oct 2023 19:37:33 -0400 Subject: [PATCH 74/80] Update 12_cpct_update.md --- _implement/announcements/12_cpct_update.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_implement/announcements/12_cpct_update.md b/_implement/announcements/12_cpct_update.md index 0686c9a5b..572554359 100644 --- a/_implement/announcements/12_cpct_update.md +++ b/_implement/announcements/12_cpct_update.md @@ -18,7 +18,7 @@ In order to account for the recent FPKIPA approval of Common Policy X.509 Certif **CPCT Update Instructions:** -In order to update the CPCT tool you will need to remove any existing instances of the Docker image, and subsequently reintall the latest release. Please find the following links with more detailed instructions on this updgate process: +In order to update the CPCT tool you will need to remove any existing instances of the Docker image, and subsequently reintall the latest release. Please find the following links with more detailed instructions on this update process: 1. [Remove the current Docker image](https://github.com/GSA/cpct-tool/wiki/Removing-Docker-Images){:target="_blank"}{:rel="noopener noreferrer"}{:class="usa-link usa-link--external"} 2. [Update the CPCT Tool](https://github.com/GSA/cpct-tool/wiki/Updating-the-CPCT-Tool){:target="_blank"}{:rel="noopener noreferrer"}{:class="usa-link usa-link--external"} From 51fc74a0f70f0c4705a91ebdc611991b738672c3 Mon Sep 17 00:00:00 2001 From: Nelson R <125207848+TheInfinityBeyonder@users.noreply.github.com> Date: Wed, 4 Oct 2023 19:39:02 -0400 Subject: [PATCH 75/80] Update playbook-dw.md --- _playbooks/playbook-dw.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_playbooks/playbook-dw.md b/_playbooks/playbook-dw.md index ba6947410..5f342406f 100644 --- a/_playbooks/playbook-dw.md +++ b/_playbooks/playbook-dw.md @@ -306,7 +306,7 @@ Use Table 5 for specific validation actions aligned with adverse impact level. | VD-6 | **Validate the sponsor has recertified acknowledgment of responsibility for the digital worker at required intervals.** | N/A | ✓
Verify sponsor recertification annually | ✓
Verify sponsor recertification annually | ✓
Verify sponsor recertification every six months | | VD-7| **Validate the custodian has recertified acknowledgment of responsibility for the digital worker at required intervals.** | N/A | ✓
Verify custodian recertification annually | ✓
Verify custodian recertification annually | ✓
Verify custodian recertification every six months | -{% include alert-info.html heading="Key Point" content="SP-3 is a similar but separate activity than VD-6. In SP-3 the sponsor acknowledges their role and responsibilities initially and reacknowledges them every six months. VD-6 is validation of the acknowledgment. Perform each action together or separately, but they are tracked separately for flexibility." %} +{% include alert-info.html heading="Key Point" content="SP-3 is a similar but separate activity than VD-6. In SP-3 the sponsor acknowledges their role and responsibilities initially and re-acknowledges them every six months. VD-6 is validation of the acknowledgment. Perform each action together or separately, but they are tracked separately for flexibility." %} {% include alert-info.html heading="Key Point" content="VD-3, VD-4, and VD-5 are validating the code, ethics, and bias reviews that have been conducted. It is up to the individual agencies to ensure a standard for conducting such reviews is followed. Agency representatives, such as the sponsor or custodian, should collaborate within a community of practice to capture best practices on how to perform the various reviews in Step 2.2." %} From 825ffabe767523b2e0edfaab8063ff0d4e0b23f4 Mon Sep 17 00:00:00 2001 From: Nelson R <125207848+TheInfinityBeyonder@users.noreply.github.com> Date: Wed, 4 Oct 2023 19:39:19 -0400 Subject: [PATCH 76/80] Update playbook-signword.md --- _playbooks/playbook-signword.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_playbooks/playbook-signword.md b/_playbooks/playbook-signword.md index d644d1dc4..2feca4f4c 100644 --- a/_playbooks/playbook-signword.md +++ b/_playbooks/playbook-signword.md @@ -118,7 +118,7 @@ _Each successive approver will be able to open the document and double-click the ## Add Multiple Invisible Digital Signatures -Multiple approvers may digitally sign a document. Use the same procedures as you would to add one invisibile digital signature: [Add an Invisible Digital Signature](#add-an-invisible-digital-signature). +Multiple approvers may digitally sign a document. Use the same procedures as you would to add one invisible digital signature: [Add an Invisible Digital Signature](#add-an-invisible-digital-signature). _The final approver will see multiple "invisible" signatures in the document._
A screenshot of a Microsoft Word Valid Signatures box, with two names highlighted and dates beside the names. From 28d047a30e78afce19fce7852d90aa145a14ca96 Mon Sep 17 00:00:00 2001 From: Ken Myers <61115074+idmken@users.noreply.github.com> Date: Thu, 5 Oct 2023 10:29:06 -0400 Subject: [PATCH 77/80] Update 404.html --- 404.html | 2 ++ 1 file changed, 2 insertions(+) diff --git a/404.html b/404.html index 28a5220ef..9209bab2a 100644 --- a/404.html +++ b/404.html @@ -14,10 +14,12 @@

Page not found

If you typed the URL directly, check your spelling and capitalization. Our URLs look like this: www.idmanagement.gov/content-area. For example:

Visit our homepage for helpful tools and resources, use our search bar in the upper right, submit an issue, or contact us and we’ll point you in the right direction.

From 62bffda301576db2a391bb2f23c9675e565a73ec Mon Sep 17 00:00:00 2001 From: Ken Myers <61115074+idmken@users.noreply.github.com> Date: Thu, 5 Oct 2023 13:03:46 -0400 Subject: [PATCH 78/80] Update 404.html --- 404.html | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/404.html b/404.html index 9209bab2a..2fb581c21 100644 --- a/404.html +++ b/404.html @@ -14,12 +14,12 @@

Page not found

If you typed the URL directly, check your spelling and capitalization. Our URLs look like this: www.idmanagement.gov/content-area. For example:

Visit our homepage for helpful tools and resources, use our search bar in the upper right, submit an issue, or contact us and we’ll point you in the right direction.

From 8659e0efaf0374c7962431c72ee36a07f70f043b Mon Sep 17 00:00:00 2001 From: Ken Myers <61115074+idmken@users.noreply.github.com> Date: Thu, 5 Oct 2023 14:20:23 -0400 Subject: [PATCH 79/80] Update CODEOWNERS --- CODEOWNERS | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/CODEOWNERS b/CODEOWNERS index 607fb7465..2508bf0ab 100644 --- a/CODEOWNERS +++ b/CODEOWNERS @@ -1,7 +1,7 @@ # Global owners -* @idmken @JBPayne007 +* @idmken @JBPayne007 @id2win # Layouts and Includes and other Jekyll structural changes # Site content changes -*.md @JillTunick +*.md @claytonjbarnette @0Vanessa0 From c0e07932ccea9f26fb855b89a7b0a53b392e1673 Mon Sep 17 00:00:00 2001 From: Ken Myers <61115074+idmken@users.noreply.github.com> Date: Thu, 5 Oct 2023 14:54:10 -0400 Subject: [PATCH 80/80] Update 404.html --- 404.html | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/404.html b/404.html index 2fb581c21..4ae507260 100644 --- a/404.html +++ b/404.html @@ -14,12 +14,12 @@

Page not found

If you typed the URL directly, check your spelling and capitalization. Our URLs look like this: www.idmanagement.gov/content-area. For example:

Visit our homepage for helpful tools and resources, use our search bar in the upper right, submit an issue, or contact us and we’ll point you in the right direction.