Update the agency enterprise identity management policies to include digital worker identity management.
diff --git a/_playbooks/playbook-ilm.md b/_playbooks/playbook-ilm.md index abd2fc801..e6794a620 100644 --- a/_playbooks/playbook-ilm.md +++ b/_playbooks/playbook-ilm.md @@ -204,11 +204,11 @@ The most common way to integrate non-PKI-derived credentials is through a modern ## Shift From Managing Credentials to Managing Identities -This playbook intends to help agencies achieve OMB Memo 19-17 outcomes to shift the focus operating model from managing access based solely on credentials to managing the lifecycle of identities and the appropriate job functions and roles as they evolve over time in an agency or the federal government. The [Identity Management services in the Federal ICAM architecture]({{site.baseurl}}/arch/servicesframework/#identity-management){:target="_blank"}{:rel="noopener noreferrer"} include Creation, Identity Proofing, Provisioning, Maintenance, Identity Aggregation, and Deactivation. These services are collectively known as Identity Lifecycle Management (ILM). +This playbook intends to help agencies achieve OMB Memo 19-17 outcomes to shift the focus operating model from managing access based solely on credentials to managing the lifecycle of identities and the appropriate job functions and roles as they evolve over time in an agency or the federal government. The [Identity Management services in the Federal ICAM architecture]({{site.baseurl}}/arch/#services-framework-and-service-descriptions){:target="_blank"}{:rel="noopener noreferrer"} include Creation, Identity Proofing, Provisioning, Maintenance, Identity Aggregation, and Deactivation. These services are collectively known as Identity Lifecycle Management (ILM). ### Step 1. Document the Process in an Agency Policy -Document an agency policy to identify the roles and responsibilities required to implement an identity lifecycle management process. It is a good practice to coordinate the document through the agency’s ICAM governance body to ensure all interested stakeholders are aware of the initiative and their respective responsibilities. This document should complement or be included in the agency’s existing ICAM policy. For more information on ICAM program management or the ICAM governance body, see the [ICAM Program Management Playbook]({{site.baseurl}}/pm/governance/){:target="_blank"}{:rel="noopener noreferrer"} or the [ICAM Governance Framework]({{site.baseurl}}/docs/playbook-identity-governance-framework.pdf){:target="_blank"}{:rel="noopener noreferrer"}. The agency policy should include the following elements. +Document an agency policy to identify the roles and responsibilities required to implement an identity lifecycle management process. It is a good practice to coordinate the document through the agency’s ICAM governance body to ensure all interested stakeholders are aware of the initiative and their respective responsibilities. This document should complement or be included in the agency’s existing ICAM policy. For more information on ICAM program management or the ICAM governance body, see the [ICAM Program Management Playbook]({{site.baseurl}}/university/pm/#program-governance-and-leadership){:target="_blank"}{:rel="noopener noreferrer"} or the [ICAM Governance Framework]({{site.baseurl}}/docs/playbook-identity-governance-framework.pdf){:target="_blank"}{:rel="noopener noreferrer"}. The agency policy should include the following elements. 1. Outline the purpose of implementing ILM. 2. The roles and responsibilities are mapped to the authoritative attribute source. Such as: 1. Training Office to gather security training status. @@ -318,5 +318,5 @@ The ILM playbook outlined an identity lifecycle process and four steps to create 1. [Department of Defense ICAM Reference Design](https://dodcio.defense.gov/Portals/0/Documents/Cyber/DoD_Enterprise_ICAM_Reference_Design.pdf){:target="_blank"}{:rel="noopener noreferrer"}{:class="usa-link usa-link--external"} 2. [DHS CDM Max.gov Page](https://community.max.gov/download/attachments/1843519190/CDM-ARCH-2017-01.1.1-MUR-FUNCT-DESCR%2012082017.pdf?version=1&modificationDate=1568732697362&api=v2){:target="_blank"}{:rel="noopener noreferrer"}{:class="usa-link usa-link--external"} 3. [IDPro Body of Knowledge - An Overview of Digital Identity Lifecycle](https://bok.idpro.org/article/id/31/){:target="_blank"}{:rel="noopener noreferrer"} -4. [System for Cross-domain Identity Management (SCIM)](http://www.simplecloud.info/){:target="_blank"}{:rel="noopener noreferrer"}{:class="usa-link usa-link--external"} +4. [System for Cross-domain Identity Management (SCIM)](https://scim.cloud/){:target="_blank"}{:rel="noopener noreferrer"}{:class="usa-link usa-link--external"} diff --git a/_playbooks/playbook-pam.md b/_playbooks/playbook-pam.md index 0595c0976..5a3e2ce1e 100644 --- a/_playbooks/playbook-pam.md +++ b/_playbooks/playbook-pam.md @@ -151,7 +151,7 @@ A privileged user policy interacts with multiple initiatives across an agency. E - **High Value Asset (HVA)** - [OMB Memo 19-03](https://www.whitehouse.gov/wp-content/uploads/2018/12/M-19-03.pdf){:target="_blank"}{:rel="noopener noreferrer"}{:class="usa-link usa-link--external"} outlines requirements to identify, track, and manage an agency's most critical assets. [Guidance from CISA](https://www.cisa.gov/sites/default/files/publications/Securing%20High%20Value%20Assets_Version%201.1_July%202018_508c.pdf){:target="_blank"}{:rel="noopener noreferrer"}{:class="usa-link usa-link--external"} recommends using individual accounts, logging key security events, and implementing multi-factor authentication for all HVA users, particularly privileged users. - **Insider threat** - Includes programs to detect and prevent unauthorized disclosure of sensitive information. An insider threat program provides, access to information, centralized information integration, analysis, response, insider threat awareness training, and user activity monitoring on government computers. -- **Cybersecurity/ICAM** - Responsible for identity, credential, and access management services and coordination. Privileged Access Management is a service area under [Access Management]({{siate.baseurl}}arch/services/#access-management). +- **Cybersecurity/ICAM** - Responsible for identity, credential, and access management services and coordination. Privileged Access Management is a service area under [Access Management]({{site.baseurl}}/arch/#access-management). - **Continuous Diagnostic and Mitigation (CDM)** - Cybersecurity tools, integration services, and dashboards to help agencies reduce the attack surface, increase visibility into cybersecurity posture, improve response, and streamline FISMA reporting. - **Risk Management** - Identify and track the implementation and operation of security controls. @@ -408,7 +408,7 @@ The following documentation references help inform the development and direction 6. [NIST Interagency Report 7966 - Security of Interactive and Automated Access Management Using Secure Shell (SSH)](https://csrc.nist.gov/publications/detail/nistir/7966/final){:target="_blank"}{:rel="noopener noreferrer"}{:class="usa-link usa-link--external"} - This publication assists organizations in understanding the basics of SSH interactive and automated access management in an enterprise, focusing on the management of SSH user keys. -7. [Federal Identity, Credentials, and Access Management (FICAM) Architecture - Access Management]({{site.baseurl}}/arch/servicesframework/#access-management){:target="_blank"}{:rel="noopener noreferrer"}{:class="usa-link usa-link--external"} +7. [Federal Identity, Credentials, and Access Management (FICAM) Architecture - Access Management]({{site.baseurl}}/arch/#access-management){:target="_blank"}{:rel="noopener noreferrer"}{:class="usa-link usa-link--external"} - The FICAM Architecture is a framework for an agency to use in ICAM program and solution roadmap planning. Privileged Access Management is identified as a distinct service within the access management portion of the ICAM services framework. 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"} diff --git a/_playbooks/playbook-sso.md b/_playbooks/playbook-sso.md index b972563c8..a81542988 100644 --- a/_playbooks/playbook-sso.md +++ b/_playbooks/playbook-sso.md @@ -185,7 +185,7 @@ With any project, a business case is used to capture the strategic, business, an {% include alert-success.html heading="Best Practice - Building the Business Case" content="When building a business case, include qualitative aspects on how Enterprise SSO can improve user experience and security, a return on investment, and a cost-benefit analysis. Combining cost analysis (quantitative justification) and qualitative aspects may help obtain leadership support and funding." %} -Coordinate the business case development with your agency ICAM governance structure. The ICAM governance structure should oversee your ICAM projects and work streams and align ICAM services and management with your agency’s mission. For ICAM oversight and program management examples, see the [FICAM Program Management Guide]({{site.baseurl}}/pm/){:target="_blank"}{:rel="noopener noreferrer"}. +Coordinate the business case development with your agency ICAM governance structure. The ICAM governance structure should oversee your ICAM projects and work streams and align ICAM services and management with your agency’s mission. For ICAM oversight and program management examples, see the [FICAM Program Management Guide]({{site.baseurl}}/university/pm/){:target="_blank"}{:rel="noopener noreferrer"}. ### 1.4 Identify the Target State Establish a realistic and achievable “to be” target state for your agency at key intervals (such as at one, three, and five years). Sometimes system impact level, access or credential requirements, or other factors can affect whether applications can integrate with your service. All applications are written differently, in different languages, at different times, for different purposes. Not all agency applications may support an assertion protocol. Your agency implementation should provide a range of compatible options, which will help realize the highest return on investment from the start. diff --git a/_university/fpki101.md b/_university/fpki101.md index bba989ea1..9ac8bd570 100644 --- a/_university/fpki101.md +++ b/_university/fpki101.md @@ -134,7 +134,7 @@ We realize all the acronyms and labels may be confusing and welcome your input t |-----------|---------------| | PKI Shared Service Provider (SSP) Certification Authorities | An SSP CA operates under the Federal Common Certificate Policy and offer [federal workforce credentialing services]({{site.baseurl}}/trust-services/#government-identity-services){:target="_blank"}{:rel="noopener noreferrer"}. Any certificate that an SSP CA creates, signs, and issues to people or devices is in the FCPCA _trust chain_. An SSP must adhere to strict federal IT security standards and requirements. The SSPs are granted a FISMA Authority to Operate (ATO) by GSA, undergo continuous monitoring, and are contracted by the federal government to issue certificates to federal employees and contractors as well as devices that are deployed in federal agency networks. The primary certificate type issued by a PKI SSP are the certificates on a PIV card. There are some PKI SSPs authorized to issue other certificate types such as Common PIV-I. | | Non-Federal Issuer (NFI) Certification Authorities | A Non-Federal Issuer or NFI is a private sector CA that is cross-certified with the Federal Bridge CA. These organizations provide [business identity services]({{site.baseurl}}/trust-services/#business-identity-services){:target="_blank"}{:rel="noopener noreferrer"} for persons who do business with the federal government, but are not part of the federal workforce. Federal agencies may refer business partners to an NFI provider if the agency requires digital signatures and in some limited circumstances PKI authenticators. PIV-I along with other PKI credentials are issued by NFI providers. For more information on NFI PIV-I, see the [PIV-I Playbook]({{site.baseurl}}/university/pivi/). An NFI must adhere and receive 3rd party independent audits to validate equivalent operations and practices to the Federal Bridge Certificate Policy. A federal agency may need to configure their systems to validate NFI certificates by installing the intermediate CA certificates within the Federal Bridge _trust chain_. | -| Bridge Certification Authorities | Bridge CAs connect member PKIs and are designed to enable interoperability between different PKIs operating under their own certificate policies. A bridge CA is not a _root_ and are part of a [non-government PKI trust framework]({{site.baseurl}}/partners/trust-services/#non-government-pki-trust-framework){:target="_blank"}{:rel="noopener noreferrer"} provided through the Federal Bridge. A PKI Bridge must adhere and receive 3rd party independent audits to validate equivalent operations and practices to the Federal Bridge Certificate Policy. A federal agency may configure their systems to validate PKI Bridge certificates by installing intermediate CA certificates within the Federal Bridge _trust chain_. | +| Bridge Certification Authorities | Bridge CAs connect member PKIs and are designed to enable interoperability between different PKIs operating under their own certificate policies. A bridge CA is not a _root_ and are part of a [non-government PKI trust framework]({{site.baseurl}}/trust-services/#non-government-pki-trust-framework){:target="_blank"}{:rel="noopener noreferrer"} provided through the Federal Bridge. A PKI Bridge must adhere and receive 3rd party independent audits to validate equivalent operations and practices to the Federal Bridge Certificate Policy. A federal agency may configure their systems to validate PKI Bridge certificates by installing intermediate CA certificates within the Federal Bridge _trust chain_. | | Federal Agency Certification Authorities | A very small amount of government agencies self-operate CAs connected to the Federal PKI Trust Framework. These agencies include the Department of Defense, Department of State, Department of the Treasury, the Government Printing Office, and the U.S. Patent and Trademark Office. These agency PKIs operate under their own certificate policy which has been mapped to the FBCA CP for comparability.| ## Certificate Types within the Federal PKI diff --git a/_university/pki101.md b/_university/pki101.md index d2551c0ba..080cfc981 100644 --- a/_university/pki101.md +++ b/_university/pki101.md @@ -103,7 +103,7 @@ The most important factor is the trust anchors. By limiting which trust anchorsIf certification paths from your PIV certificates do not begin with the Federal Common Policy CA G2, follow the guidance found in - Distribute the certificate to operating systems + Distribute the certificate to operating systems to install the CA in the correct location.