Attachment_22_-_ICAM_Interim_Standard.pdf

SE-STD-XX-XX

PBGC OIT Identity, Credential, and Access Management Interim Standard

Purpose

The PBGC OIT Identity, Credential, and Access Management (ICAM) Interim Standard provides a list of shared services that Application Owners must consume in order to comply with the enterprise ICAM environment at PBGC.

Scope

The PBGC ICAM Standard defines mandatory requirements that IT solutions development activities shall consider when developing applications that require interfacing with other internal and external IT solutions or that can provide reuse and sharing of functionality.

This standard applies to all IT solutions development teams and the primary stakeholders and actors of those development activities that need to understand the target ICAM architecture.

Authority/ References

Homeland Security Presidential Directive 12 (HSPD-12); Federal ICAM Roadmap; and the Federal Information Security Management Act (FISMA) of 2002

Approving Body

Technical Review Board (TRB)

Owner Enterprise Cybersecurity Division (ECD)

Collaborators

Enterprise Architecture Division (EAD) / Information Technology Infrastructure Operations Department (ITIOD) / IT & Business Modernization Department (IT&BMD), Financial Operations Department (FOD), Benefits Administration and Payment Department (BAPD), Human Resources Department (HRD), Procurement Department (PD), Quality Management Department (QMD), Workplace Solutions Department (WSD)

Implementer ITIOD, IT&BMD Service Divisions

Standard Type

Technical

Control Number

SE-STD-XX-XX

Standard The PBGC OIT Identity, Credential, and Access Management (ICAM) Interim Standard defines PBGC standards for implementing solutions, tools, and applications that require any identity, credential, or access management through enterprise services.

The details of the standard are reflected in the attached methodology.

The requirements and design documents for projects/release/application should address the ICAM requirements contained in this document.

If any element of the standard cannot be met in a project/release/application – that information should be agreed upon by Integrated Project Team (IPT) members and be highlighted in the applicable requirements and/or design document. Additionally, a risk acceptance form will be required to provide a justification for non-compliance.

Metrics Compliance with CIO Council performance metrics for PIV Card usage to government IT resources and facilities

Owner Signature

Tim Hurr, Chief Information Security Officer

Approval Signature (TRB or GCB)

John Larsen, TRB Chair

PBGC Identity, Credential, and Access Management Methodology

V 1.4

DRAFT

DRAFT PBGC Identity, Credential, and Access Management Methodology i

Revision History

Document Version

Release Date

Section(s) Changed

Description/Comments

0.1 6/30/15 All Initial creation

0.2 6/30/15 All Federal Lead feedback incorporated

0.3 7/8/15 All Chief Architect feedback incorporated

0.4 7/14/15 All Acting ITIOD Director feedback incorporated

1.0 7/15/15 All Initial Draft for IPT Review

1.1 7/27/15 All IPT-approved version for broader socialization

1.2 7/28/15 All Incorporated additional IPT feedback

1.3 7/29/15 All Incorporated additional CISO feedback

1.4 8/24/15 All Updated per OIT Manager socialization (Round 1)

Approval

Signer/Title Signature Date

John Larsen Chair, Technology Review Board (TRB)

Tim Hurr Chief Information Security Officer Enterprise Cybersecurity Division ii

Contents

1 INTRODUCTION

Background

Purpose

2 IDENTITY, CREDENTIAL, AND ACCESS MANAGEMENT OVERVIEW

What is ICAM?

Identity Management

Credential Management

Access Management

Federation

Provisioning/De-Provisioning

3 ICAM AS A SERVICE

ICAM Segment Architecture

Design Principles

Design Approach

Design Requirements

APPENDIX A: FEDERAL POLICIES & KEY INITIATIVES

APPENDIX B: ICAM TAXONOMY & DEFINITIONS

APPENDIX C: BASELINE ICAM SYSTEMS AND SERVICES DIAGRAM

APPENDIX D: ROLE MANAGEMENT CHECKLIST

APPENDIX E: ROLE DESCRIPTION TABLE EXAMPLE

APPENDIX F: GENERIC CONFLICT MATRIX (SEGREGATION OF DUTIES)

1 Introduction

Background

Identity, Credential, and Access Management (ICAM) efforts within the Federal Government are a key component for addressing the nation‘s cybersecurity needs. There are a number of Federal mandates and guidance—such as Homeland Security Presidential Directive 12 (HSPD-12), Federal ICAM Roadmap, and the Federal Information Security Management Act (FISMA) of 2002—that serve as key drivers for PBGC’s ICAM program and that need to be understood, navigated, and right-sized to meet the needs of the Corporation.1

This Interim Standard was developed to enable the adoption of more consistent, efficient, and effective ICAM services across PBGC in the near term, and to ensure compliance with Federal mandates, guidance, and best practices.

Purpose The purpose of this Interim Standard is to outline a common framework for ICAM within the Pension Benefit Guaranty Corporation (PBGC) and to identify policies and guidance for PBGC and its information systems for near term implementation.

In support of the overall purpose, the Interim Standard was written to accomplish the following objectives:

Present an overview of identity, credential, and access management to ensure consistent understanding across PBGC stakeholders;

Illustrate the key players and compliance initiatives involved in ICAM program;

Give guidance on how to incorporate a segment architecture for ICAM program;

Provide a high-level vision for the target state of PBGC‘s use and management of ICAM services; and

Provide design standards that are applicable to identity, credential, and access management ICAM Services in the interim.2

The ICAM Interim Standard is intended as a resource for PBGC implementers and consumers of identity, credential, and access management services, and the Standard must be reviewed and modified as appropriate, to reflect changes to the environment. In the event that this document contradicts established Federal Government policies and standards, those documents take precedence.

1 A complete list of related Federal mandates and guidance can be found in Appendix A of this Standard.

2 Design standards apply to PBGC-owned systems only; managed services and external users are out of scope.

2 Identity, Credential, and Access Management Overview

What is ICAM?

This section provides an introduction to ICAM. ICAM comprises of the programs, processes, technologies, and personnel used to create trusted digital identity representations of individuals and Non-Person Entities (NPEs), bind those identities to credentials that may serve as a proxy for the individual or NPE in access transactions, and leverage the credentials to provide authorized access to an agency‘s resources. ICAM permeates a number of organizations, programs, and systems across PBGC and management of ICAM must be coordinated across these various entities. The following subsections provide additional detail on the constituent parts of ICAM and discuss the elements in greater detail.3 Definitions are strongly driven by the Federal Identity, Credential, and Access Management (FICAM) Roadmap and Implementation Guidance,4 and are represented in the FICAM Roadmap ICAM Conceptual graphic, shown in Figure 1, below.5

Figure 1: FICAM Roadmap ICAM Conceptual Diagram

3 To see a full taxonomy of ICAM elements and their associated definitions, see Appendix B of this document.

4 FICAM Roadmap and Implementation Guidance, version 2.0, December 2, 2011.

5 A representation of the baseline state for PBGC, as it aligns to the FICAM Roadmap Conceptual graphic, is provided in Appendix C of this document.

*FICAM Roadmap v2.0 http://www.idmanagement.gov/sites/default/files/documents/FICAM_Roadmap_and_Implementation_Guidance_v2%200_20111202_0.pdf

Identity Management

Identity management is the combination of technical systems, policies, and processes that create, define, govern, and synchronize the ownership, utilization, and safeguarding of identity information. The primary goal of identity management is to establish a trustworthy process for assigning attributes to a digital identity and to connect that identity to an individual.6

The concept of an enterprise identity is that individuals will have a single digital representation of themselves that can be leveraged across departments and agencies for multiple purposes, including access control. A digital identity is often comprised of a set of attributes that when aggregated uniquely identify a user within a system or enterprise. Attributes about an individual may be stored in various authoritative sources within an agency and linked to form an enterprise view of the digital identity. This digital identity may then be provisioned into applications in order to support physical and logical access and de-provisioned when access is no longer required.

With the establishment of an enterprise identity, it is important that policies and processes are developed to manage the life cycle of each identity. Management of an identity includes:

The framework and schema for establishing a unique digital identity, The ways in which identity data will be used, The protection of PII, Controlling access to identity data, The policies and processes for management of identity data, Developing a process for remediation; solving issues or defects, The capability to share authoritative identity data with applications that leverage it, The revocation of an enterprise identity, and

The system that provides the services and capabilities to manage identity.

As part of the framework for establishing a digital identity, proper diligence should be employed to limit data stored in each system to the minimum set of attributes required to define the unique digital identity and still meet the requirements of integrated systems. A balance is needed between information stored in systems, information made available to internal and external systems, and the privacy of individuals.

Credential Management According to National Institute of Standards and Technology Special Publication 800-63 (NIST SP 800-63),7 a credential is, “an object that authoritatively binds an identity (and optionally, additional attributes) to a token possessed and controlled by a person.”8 Credential management

6 Identity Management Task Force Report, National Science and Technology Council (NSTC) Subcommittee on Biometrics and Identity Management, 2008.

7 SP 800-63, Electronic Authentication Guideline, Version 1.0.2, NIST, April 2006. [SP 800-63].

8 The credentialing process principals and elements can also be applied for NPE digital identities; however, steps may vary during the credential issuance process (sponsorship, adjudication, etc.) based on an organizations security requirements. For examples of an NPE credential issuance please refer to X.509 Certificate Policy for the U.S. Federal PKI Common Policy Framework, Version 3647 – 1.6, February 11, 209.

http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf http://www.idmanagement.gov/fpkipa/documents/CommonPolicy.pdf supports the life cycle of the credential itself. PBGC examples of credentials are PIV Cards and their associated digital certificates. The PIV standards (Federal Information Processing Standards Publication 201 [FIPS 201], NIST SP 800-73, etc.) and Federal PKI Common Policy are examples of documents which have been in place and are foundational to agency-specific credential implementations.9

Credentialing generally involves five major components.

1. Sponsorship - an authorized individual sponsors an individual or entity for a credential to establish the need for the credential.

2. Enrollment/Registration - an individual enrolls for the credential, a process which typically consists of identity proofing and the capture of biographic and biometric data. The types of data required may depend on the credential type and the usage scenario.

3. Issuance - a credential must be produced and issued to an individual or NPE. As in the case of enrollment, these processes will vary based upon the credential type in question.

4. Credential Lifecycle Management - Identity proofing, production, and issuance requirements for other credential types typically include a subset of the processes or technologies depicted but follow the same general principles.

5. Self-Service - a credential must be maintained over its life cycle, which might include revocation, reissuance/replacement, re-enrollment, expiration, personal identification number (PIN) reset, suspension, or re-instatement.

A major distinction in the lifecycle management of credentials versus identities is that credentials expire. Your digital identity is comprised of attributes that may change or evolve over time, but your identity does not become invalid or terminated from a system perspective. Credentials, however, are usually valid for a pre-defined period of time and are considered a tool for authentication providing varying levels of assurance about the authentication of an individual.

Access Management Access management is the management and control of the ways in which entities are granted or denied access to resources. The purpose of access management is to ensure that the proper identity verification is made when an individual attempts to access security sensitive buildings, computer systems, or data.10

Access management has two areas of operations: logical and physical access. Logical access is the access to an IT network, system, service, or application. Physical access is the access to a physical location such as a building, parking lot, garage, or office.

To determine access to resources, access management leverages identities, credentials, and privileges by authenticating credentials. After authentication, a decision to grant access to the resource is made.

9 SP 800-73, Interfaces for Personal Identity Verification –Part 1: End-Point PIV Card Application Namespace, Data Model and Representation, NIST, February 2010.

10 FIPS Publication 201, Personal Identity Verification (PIV) of Federal Employees and Contractors, Introduction, Pg. 1, March

2006. [FIPS 201].

http://csrc.nist.gov/publications/nistpubs/800-73-3/sp800-73-3_PART1_piv-card-applic-namespace-date-model-rep.pdf http://csrc.nist.gov/publications/fips/fips201-1/FIPS-201-1-chng1.pdf

In order to allow agencies to obtain a level of assurance in the identity of the individual attempting access, they must meet the following:

Authentication: Ensure that all individuals attempting access are properly validated.

Confidentiality: Ensure that all access to information is authorized.

Integrity: Protect information from unauthorized creation, modification, or deletion.

Reliability, Maintainability, and Availability: Ensure that authorized parties are able to access needed information.

Nonrepudiation: Ensure the accountability of parties when gaining access and performing actions.

Another aspect of access management is access control. This is the ability to ensure that all individuals attempting access have a genuine need through authentication, authorization, and the business rules surrounding the data itself. Usually this is achieved by leveraging an enterprise identity for entitlements, privileges, multi-factor authentication, roles, attributes and different levels of trust. Privacy is provided by properly ensuring confidentiality and by refraining from collecting more information than that which is necessary.

Federation Federation is a term used to describe the technology, standards, policies, and processes that allow an organization to trust digital identities, identity attributes, and credentials created and issued by external organizations. Federation enables an agency to provide modernized logical access control services for users, by trusting and accepting credentials that those users already have.

The vast majority of federation transactions that occur within the Federal Government can be grouped into two categories, namely:

Interagency federation: Includes federation that occurs between two or more federal agencies based upon authentication of the PIV card. Interagency federation may include the passing of identity assertions between agencies.

Federation with entities external to the Federal Government: Includes federation that occurs between a federal agency and any other non-federal organization or entity (e.g., state, local, or tribal governments, commercial entities, and citizens).

Federation is made possible through the establishment and use of common exchange protocols and agreed-upon open standards/specifications that allow an agency to authenticate a user from another organization or trust an authentication conducted outside of the agency.

Provisioning/De-Provisioning

Provisioning is the process of creating user accounts and assigning roles and privileges to those accounts. Provisioning provides users with access rights to applications and other IT resources, and includes the creation, modification, or restoration of a defined set of access privileges.

De-provisioning includes the process for permanently removing an individual‘s access to particular agency resources when it is no longer required to perform job functions, through deletion or suspension of a defined set of access privileges. De-provisioning access when it is no longer needed is important for a number of reasons, including but not limited to security, privacy, and management of internal resources. De-provisioning requires deactivation of all accounts associated with the user, precluding any further access to PBGC’s network, systems, and data.

3 ICAM as a Service

ICAM Segment Architecture

The Federal Enterprise Architecture Framework is to provide a standards-based approach to ensure alignment, clarity, and interoperability and eliminate redundancies by identifying and sharing ICAM services.

A key objective of the ICAM segment architecture within the Federal Enterprise Architecture Framework is to implement a holistic approach for all identity, credential, and access management services which have traditionally been implemented as separate capabilities.

The FICAM Roadmap and Implementation Guidance presents the primary components of the ICAM segment architecture organized into five layers defined in the Federal Enterprise Architecture (FEA). The five layers are: performance, business, data, service, and technical. OMB has instructed agencies to ensure their ICAM programs align with the government wide segment architecture.11

Figure 2 Federal Enterprise Architecture Framework

Interestingly, ICAM itself is not a service but a collection of services that functionally provide capabilities to align technology and security to business operations and FEA. A high level representation of those services is provided below in Figure 3.

A target implementation of an ICAM SOA is provided in Figure 3. It supports the goal of HSPD-12, which is to issue a common credential to federal employees and contractors that can be used to access facilities and resources across the federal government.

11 OMB Memorandum M-11-11, Continued Implementation of Homeland Security Presidential (HSPD) 12 – Policy for a common Identification Standard for Federal Employees and Contractors, February 3, 2011.

https://www.whitehouse.gov/sites/default/files/omb/memoranda/2011/m11-11.pdf

Figure 3: Target ICAM SOA Architecture

From the user perspective portrayed in Figure 3, the following sequence of events are supported by the target architecture:

1. The user’s identity is confirmed and user is issued a PIV Card.

2. The user authenticates to exposed services (Authentication [AuthN], Federation [FED], Self Service [Self Svc]).

3. Access to facilities is enabled by the Physical Access Control System (PACS). Access to applications and network infrastructure is enabled by other means.

4. The shared services support the ability of managing user access and identity lifecycle.

5. The Shared Federal Infrastructure supports the use of PBGC-issued credentials at other

Federal entities.

6. Other Executive Level Departments and Agencies can access authorized services through the federal infrastructure using their issued PIV credential.

The following information is provided as a reference to the services and capabilities provided in Figure 3.

• Internal PBGC Shared Services – services handled within the PBGC infrastructure rather than within each system or application:

• Identity – provides services to users such as authentication, federation, and user self-service to support the ability to distinguish one entity from another based on a set of attributes.

• Credentialing (PIV) – a service binding an identity to a physical or electronic credential, which can subsequently be used as a proxy for the identity or proof of having particular attributes.

• Provisioning – a service that creates user access accounts and assigning privileges or entitlements within the scope of a defined process or interaction.

• Authorization – a service that grants or denies specific requests for obtaining and using information processing services or data and to enter specific physical facilities.

• Audit – a service that collects chronological records that are examined to reconstruct a sequence of events surrounding a specific operation, procedure, or event.

• Exposed shared services (Authentication, Federation [FED], and Self Service) – exposed user interfaces so that the end user can authenticate once to the shared infrastructure, and then access various systems without the need to re-authenticate.

• Authentication – a service that verifies that a claimed identity is genuine and based on valid credentials.

• Federation - A trust relationship that enables a relying party to accept credentials for an external Identity Provider in order to make access control decisions.

• Self-Service – electronic services such as password resets, credential and identity status updates, and access requests (e.g., application, network, and facility) that support user requests without supervisory intervention.

• Authoritative Data Sources such as HR, and others – a repository considered to be the primary responsible source of information (attributes) about an individual and that can be used to resolve identity data when mismatched or in conflict.

• PACS, Network (Virtual Private Network [VPN] & Local Area Network [LAN]), and Application – access to the shared infrastructure leverages shared identity, credentialing, provisioning, authorization, and auditing services.

• Identity Management System (IDMS) & Data - Authoritative Attribute Exchange Service (AAES) connects various authoritative data sources and shares data with the shared infrastructure.

SOA shared services, such as Identity, Provisioning, Audit, Authentication, Authoritative Data Sources, and Exposed Services, are connected to the agency’s shared infrastructure. These shared services are consumed by organizational applications, PACS, and Network Access Services (remote and network).

Since PIV is a managed service, otherwise known as a credential service provider (CSP), these services reside outside of the agency ICAM SOA and are depicted as such.

Agency ICAM implementations are integrated in with the shared federal infrastructure to leverage issued credentials for access to facilities and IT systems using the Federal PKI Bridge. In this instance, since the issuance of PIV Cards at PBGC is performed as a managed service, it is shown integrated into the shared infrastructure.

Design standards for enterprise SOA should include the following:

The ICAM SOA should be built to achieve FICAM SOA objectives.

Design Principles

The following principles apply to SOA based design and should be considered as part of any ICAM service implementation.12

Encapsulation: This principle advocates exposing a discrete system capability as an autonomous IT asset (that is, a service) that can be used by any application that requires that specific capability.

Separation of concerns: This principle advocates separating different aspects of a software system so that each aspect can be developed independently and maintained autonomously.

Loose Coupling: This principle advocates reducing dependencies between system components and making all remaining dependencies explicit.

o The more loosely they are coupled, the bigger they scale in a cloud environment o Design every component as a black box (able to operate without knowing the details of other components) o Implement loose coupling by load balancing requests across multiple systems/servers o Use queues to pass messages from one component to another

Business Traceability: This principle advocates using well-defined processes that maintain the “line of sight” from business requirements to the system capabilities that support them

Security: This principle advocates incorporating industry best practices and adherence to federal and legislative regulations, standards, and guidance should be incorporated during the design process to ensure the protection of personally identifiable information (PII) in accordance with Handbook for Safeguarding Sensitive PII published by the Department of Homeland Security (DHS).13

12 Design principles are primarily driven by PBGC EA-STD-01-05: OIT Software Services Standard and Methodology.

13 Handbook for Safeguarding Sensitive Personally Identifiable Information, Department of Homeland Security, March 2012.

http://intranet/it/it_governance/ppl/documents/EA-STD-01-05-PBGC-Software-Service-Standard-and-Methodology.pdf

Design Approach

A list of shared services that Application Owners must consume in order to comply with the enterprise ICAM environment at PBGC is provided below. The services exist within the enterprise and are available for re-use where appropriate.14 Infrastructure is required to provide these shared services, and business applications and infrastructure applications are required to consume the shared services.

Credential Management

Credential Management services are provided by a managed services provider and are available for re-use. The PIV credential issued by the system is consumed by other services and applications, both internal and external. Services and information specific to the credential management system should be seamlessly integrated into enterprise ICAM.

Consideration could be given to the cardholder repository as a potential authoritative source of digital identities (both contractor and employee) who are authorized access to IT resources, and used to supply a central authoritative source to consuming systems, applications, and business processes.

Design standards for re-use of credential management services include the following:

PIV Card usage must be enabled for access to facilities and IT resources.

The current credential management system, USAccess, provided by GSA, is the standard PIV Credentialing system.

Products that support the issuance of credentials, and their use by physical access control systems (PACS) must be procured from the GSA Approved Products list.

Identity Management

There are enterprise identity stores, and application-specific Identity stores focusing singularly on collecting user identities to be used to meet performance, business, and technical requirements and meet application specific requirements. In many cases, existing identity stores can meet the digital identity requirements of consuming applications. Paramount to any identity management service is the ability to assign attributes to a digital identity and to have some level of confidence that the digital identity is a representation of an actual user with a need to access that IT resource. Lifecycle management of digital identities which includes enrollment, attribute management, revocation, termination, delegation, attestation, and dormancy is important to safeguarding access to IT resources. Importance should also be placed on limiting the digital identity data stored and used by each system to ensure the privacy of individuals, while meeting the needs of systems and applications.

Design standards for re-use of identity management services include the following:

The digital identity stores in use by their respective applications should be maintained.

14 On those occasions where the design standards listed in this section cannot be met, the Information System Owner (or his/her designee) must submit a Risk Acceptance Form.

The authoritative identity store for federal employees is the HR system.

The authoritative identity store for contractors is Active Directory.

The authoritative identity store for background information is PI Manager.

The authoritative identity store for Physical Access is the Software House CCure 800 system.

The authoritative identity store for PIV credentials is the GSA Managed Service Card Management System (CMS).

Access Management

Access Management is the management and control of the ways in which entities are granted or denied access to resources. Access management also ensures that the proper identity verification is made when an entity attempts to access a resource. Two operational types of access are discussed below.

Design standards for re-use of access management services include the following:

The Personal Identity Verification (PIV) card is required to be used “as the common means of authentication for access to agency facilities, networks, and information systems.”15

Role Definition

Enterprise role base access control (RBAC) is a methodology used to map users to roles that have been assigned permissions to perform actions. Enterprise roles can be assigned to groups, and permissions granted to roles and groups can be based on policy, as shown in Figure 4, below.

RBAC typically tries to answer the questions who, what, and where. Within the operational environment, “who” defines which user or group are assigned permissions. The “what” decides the assigned permissions (i.e., CRUD). And the “where” determines the scope—meaning what objects can be read from or written to (e.g., specific group of users, servers, etc.).

Figure 4: Enterprise Role Base Access Overview

15 OMB Memorandum M-11-11, Continued Implementation of Homeland Security Presidential (HSPD) 12 – Policy for a common Identification Standard for Federal Employees and Contractors, February 3, 2011.

https://www.whitehouse.gov/sites/default/files/omb/memoranda/2011/m11-11.pdf

The challenge to implementing RBAC is that a set of roles and/or groups of roles must be defined to provide a representation whereby users can be mapped into roles by non-expert personnel and that conflicts regarding privileges do not occur when users are assigned roles. Roles typically are static, and have difficulty when assigned dynamically changing attributes such as time of day, location, and other such attributes.

As illustrated in Figure 5 below, role base access also supports the authentication (AUTHN) and authorization (AUTHZ) through rules enforcement in the Policy Information Point (PIP). The Policy Information Point (PIP) is a repository and provides permissions upon requests from the PDP. The Policy Decision Point (PDP) would evaluate the rules to produce an access decision. The request for access comes through the Policy Enforcement Point (PEP) and is processed by the PIP and PDP before being approved for access to the protected resource. Interface with AUTHN and AUTHZ services are required by applications when implementing role base access.

Figure 5: RBAC Access Enforcement

Design standards for RBAC services include the following:

Development teams are required to provide IT with a set of roles that need to be supported for development, test, and O&M.

The Application Owner is required to provide IT with a set of roles that the Application Owner requires to support acceptance testing, and operations for help desk and sustainment support.

Upon acceptance and delivery of the application, it is incumbent on the development team and Application Owner to provide IT with a list of roles and users for the purpose of revocation/termination.

During the development lifecycle, Application Owners and development team managers are required to coordinate any changes to roles.

At no time, is an Application Owner to use a generic test role for the purposes of acceptance testing.

Each Application Owner is required to provide their staff with a role dedicated to application testing and acceptance.

IT should ensure that Application Owners are familiar with use of the Conflict Matrix and role management and assignments.

Role Management

The purpose of a role management process is to provide approvers guidelines that can be used to ensure users only gain the access they need to do their job and reduce the possibility that a single person could be responsible for performing conflicting roles. In Figure 6 below, the process to identify roles; develop a conflict matrix; mitigate risks where role conflicts may exist; and assign roles to users is identified. At each step, Application Owners are provided with guidelines to help them with the role management process.

Figure 6: Role Management Process

The following information provides a description of the steps the Application Owner will take to create roles to be used in the provisioning/de-provisioning system.

1. Identify and document all application roles that a user can request in a Role Description Table.

2. Create a Role Conflict Matrix.

3. Review role information to ensure conflicts do not exist. In the event a conflict exists, complete the Risk Acceptance form.

4. Enter each role into the Service Catalog.

5. Generate a User Asset Report to confirm the Service Catalog Request has been completed correctly. In the event the role has not been created correctly in the Service Catalog, correct the entry.

6. Using the Role Conflict Matrix, assign users to roles, generating a service request in the Service Catalog. Verify the role has been assigned properly. In the event the role has not been assigned to the user properly, correct the entry.

A checklist is provided in Appendix D: Role Management Checklist. The checklist further elaborates on these steps and provides detailed guidance. An example of a Role Description Table is provided in Appendix E: Role Description Table Example. An example of a Role Conflict Matrix is provided in Appendix F: Generic Conflict Matrix (Segregation of Duties).

Logical Access

Logical Access is about accessing IT resources. Logical access is about the steps for authenticating, authorizing, or denying a user access to systems, applications, and data. Determining access is accomplished by meeting the objectives identified in OMB M-04-04 and implementing authentication mechanisms at the four levels of assurance. Compliance must be achieved through the use of a government-wide standard to conduct an e-authentication risk assessment on electronic transactions to ensure there are consistent practices across government. 16

Within the operational environment, two products provide single sign-on services: Oracle Single Sign-on (OAM) and AD/Kerberos, as shown in Figure 7, below.

Figure 7: Existing SSO Services

With Oracle based applications, there are licensing issues with respect to which single sign-on service to use. Table 1, below, provides a reference to the software licensing issues for single sign-on implementations. The purpose of the table below is to assist Application Owners and developers in their assessment of single sign-on implementation options available for use in the current development environment.

Application Type Oracle 10 Oracle 11g AD/Kerberos

New applications (being developed under Oracle 10 or Oracle 11)

N/A Must utilize No single sign-on licensing costs

Existing applications Oracle 10 application:

no additional single sign-on licensing costs

Oracle 11 application:

no additional single sign-on licenses

May utilize as a new capability No single sign-on licensing costs

16 OMB Memorandum M-04-04, E-Authentication Guidance for Federal Agencies, December 16, 2003.

Transitioning from Oracle 10 N/A

Must utilize No single sign-on licensing costs

Table 1: Oracle vs Kerberos Implementation Option

Applications currently using Oracle 10 can continue to use Oracle 10 single sign-on services.

Oracle 11g applications can continue to use Oracle 11g single sign-on services. There are no additional Oracle 11g single sign-on licenses to support the migration of an Oracle 10 application to Oracle 11g.17 Any new applications being developed under either Oracle 10 or Oracle 11g that require the use of Oracle single sign-on also require the purchase of a license.

Design standards for re-use of logical access management services include the following:

The PIV Card is the standard for access to networks and applications for both remote and internal access.

Active Directory is the standard for assigning roles and attributes to users to support role based access control to applications.

Privileged access must enable two factor authentication using the PIV card as the means of access.

Physical Access

Physical Access services are provided by a managed services provider and do not require any further consideration.

Design standards for re-use of physical access management services include the following:

The current Physical Access Control System (PACS), Software House CCure 800, is the standard PACS system.

Products supporting the PACS system such as turnstiles, card readers, and other access control devices must be procured from the GSA Approved Product List (APL).

PACS systems must be compatible with Federally approved and issued PIV cards

Provisioning/De-provisioning

Provisioning/De-provisioning is the process of creating a user account, and the assignment of the appropriate privilege attributes, and removing of an individual‘s access to particular agency resources when it is no longer required to perform job functions. Provisioning/De-provisioning is the process of linking digital identities to access privileges and specifically ties identity management, logical and physical access. Without provisioning access is unavailable.

Design standards for re-use of provisioning/de-provisioning services include the following:

Any ICAM services design, meeting the goals and objectives of provisioning/de-provisioning, should focus on automating provisioning/de-provisioning.

17 Oracle Fusion Middleware-based products require the use of Oracle Access Manager (OAM) to support Single Sign-On Services.

Continued use of OAM will be supported for Oracle Fusion Middleware-based products until such time as these applications are no longer in use at PBGC.

The current implementation of HP Service Manager 9 and Dell Quest ARS is the standard provisioning/de-provisioning system.

Federation

Federation services are being utilized within the enterprise to support access to Microsoft applications provided under the Microsoft 365 service. Federation services are provided by Active Directory Federation Services (ADFS), and provide the capability for credential sharing between business partners. Conceptually this means that credentials issued by one partner are recognized by the other partner and can be provisioned to access authorized applications, system, and services.

Design standards for re-use of federation services include the following:

Any implementation of Federation services, either those providing access services to external consumers or those providing access to internal users must standardize on the use of the PIV card for access to facilities and IT resources.

Design Requirements

The services design should:

Include a graphical description of the services and interfaces between applications.

Describe what capability the Service Component offers, a basic summary of how it accomplishes its functionality (process flow, algorithms), and exposure of all internal details.

Identify the type of invocation, data that is exchanged, format of the message and interactions for successful completion and error handling.

Discuss the use of technologies and their interactions as applicable.

Address complex nonfunctional requirements. Examples include transactions, security, addressing, trust, coordination, and so on.

Handle message processing and invocation.

Meet the use cases for services identified in the FICAM Roadmap and Implementation Guidance

Comply with PBGC Service Oriented Architecture requirements.

Appendix A: Federal Policies & Key Initiatives

Type Document Name Date

Issued Description

Legislation and

Regulations

Federal Information Security Management Act

(FISMA)

2002 and revised

This act requires each federal agency to develop, document, and implement an agency-wide program to provide information security for the information and information systems that support the operations and assets of the agency, including those provided or managed by another agency, contractor, or other source.

E-Government Act 2002 This act is intended to enhance the management and promotion of electronic Government services and processes by establishing a Federal CIO within the Office of Management and Budget (OMB), and by establishing a broad framework of measures that require using Internet-based information technology to enhance citizen access to Government information and services, and for other purposes.

Privacy Act 1974 This act protects certain Federal Government records pertaining to individuals. In particular, the Act covers systems of records that an agency maintains and retrieves by an individual's name or other personal identifier (e.g., Social Security Number [SSN]).

Government Paperwork Elimination Reduction Act

1998 GPEA requires Federal agencies, by October 21, 2003, to allow individuals or entities that deal with the agencies the option to submit information or transact with the agency electronically, when practicable, and to maintain records electronically, when practicable. The Act specifically states that electronic records and their related electronic signatures are not to be denied legal effect, validity, or enforceability merely because they are in electronic form, and encourages Federal Government use of a range of electronic signature alternatives.

Real ID Act 2005 This statute requires minimum performance standards to improve the integrity and security of state-issued driver's licenses and identification cards. (Regulations were promulgated by DHS).

Presidential Directives

Homeland Security Presidential Directive 12 Policy for a Common

August

HSPD-12 calls for a mandatory, government-wide standard for secure and reliable forms of identification (ID) issued by the Federal Government to its employees and employees of

Type Document Name Date

Issued Description

Identification Standard for Federal Employees and Contractors federal contractors for access to federally-controlled facilities and networks.

White House National Strategy for Trusted Identities in Cyberspace

April 2011 The National Strategy for Trusted Identities in Cyberspace (NSTIC) charts a course for the public and private sectors to collaborate to raise the level of trust associated with the identities of individuals, organizations, networks, services, and devices involved in online transactions

Trust Framework 2009 The FICAM Trust Framework Solutions (TFS) is the federated identity framework for the U.S.

federal government. It includes guidance, processes and supporting infrastructure to enable secure and streamlined citizen and business facing online service delivery.

CIO Council PIV-I for Non Federal Issuers

July 2010 This document advocates a set of minimum requirements for non-federally issued identity cards that can be trusted by the Federal government, and details solutions to the barriers to interoperability that currently preclude Federal government trust of non-federally issued identity cards.

Federal Identity, Credential, and Access Management (FICAM) Roadmap and Implementation Guidance

Dec 2, This document was developed to provide a common segment architecture and implementation guidance for use by federal agencies as they continue to invest in ICAM programs.

OMB M-04-04

e--Authentication Guidance

Dec 16, This guidance requires agencies to review new and existing electronic transactions to ensure that authentication processes provide the appropriate level of assurance. It establishes and describes four levels of identity assurance for electronic transactions requiring authentication.

Assurance levels also provide a basis for assessing CSPs on behalf of Federal agencies.

This document will assist agencies in determining their E-Government authentication needs. Agency business-process owners bear the primary responsibility to identify assurance levels and strategies for providing them. This

Type Document Name Date

Issued Description responsibility extends to electronic authentication systems.

M-03-22 Implementation of Privacy Provisions

Sep 26, The guidance provides information to agencies on implementing the privacy provisions of the E- Government Act of 2002

M-05-24 Implementation of Homeland Security Presidential Directive 12

(HSPD-12)

Aug 5, This memorandum provides implementing instructions for Homeland Security Presidential Directive 12 (HSPD-12) and FIPS 201.

M-11-11 Continued Implementation of

HSPD-12

Feb 3, 2011 Policy for the continued implementation of HSPD-12; requires agencies to designate a lead official and issue an implementation policy.

Enhancing and Strengthening Government’s Cybersecurity

June 12, Fact sheet instructing agencies improve Federal cybersecurity and protect systems against evolving threats and improve the resilience of Federal networks.

Accepting Externally Issued Credentials

Oct 6, 2011 To decrease the burden on users of government systems, and reduce costs associated with managing credentials, agencies are to begin leveraging externally-issued credentials, in addition to continuing to offer federally-issued credentials.

PKI X.509 Certificate Policy for the Federal Bridge Certification Authority (FBCA)

Dec 9, This Certificate Policy (CP) defines twelve certificate policies for use by the Federal Bridge Certification Authority (FBCA) to facilitate interoperability between the FBCA and other Entity PKI domains

PKI Certificate Policies

A certificate policy (CP) is a document which aims to state “what are the different actors of a public key infrastructure (PKI), their roles and their duties”.

PKI Certificate Practice Statements

A Certification Practice Statement (CPS) is a document from a Certificate Authority or a member of a web of trust which describes their practice for issuing and managing public key certificates.

NIST FIPS 201-2 Aug 2013 The Standard contains the minimum requirements for a Federal personal identity verification system that meets the control and security objectives of Homeland Security Presidential Directive-12 [HSPD-12], including identity proofing, registration, and issuance. The Standard also provides detailed specifications

Type Document Name Date

Issued Description that will support technical interoperability among PIV systems of Federal departments and agencies.

FIPS 199 Security Categorization for Information Systems

Feb 2004 This publication establishes security categories for both information and information systems.

The security categories are based on the potential impact on an organization should certain events occur which jeopardize the information and information systems needed by the organization to accomplish its assigned mission, protect its assets, fulfill its legal responsibilities, maintain its day-to-day functions, and protect individuals. Mandated by

FISMA.

FIPS 200 Minimum Security Requirements for Information Systems

March

This standard will promote the development, implementation, and operation of more secure information systems within the federal government by establishing minimum levels of due diligence for information security and facilitating a more consistent, comparable, and repeatable approach for selecting and specifying security controls for information systems that meet minimum security requirements..

Mandated by FISMA.

SP 800-37 Risk Management Framework

Feb 2010 The purpose of this publication is to provide guidelines for applying the Risk Management Framework to federal information systems to include conducting the activities of security categorization, security control selection and implementation, security control assessment, information system authorization, and security control monitoring.

SP 800-53-4

Security and Privacy Controls for Federal Systems and Organizations

April 2013 This publication provides a catalog of security and privacy controls for federal information systems and organizations and a process for selecting controls to protect organizational operations (including mission, functions, image, and reputation), organizational assets, individuals, other organizations, and the Nation from a diverse set of threats including hostile cyber-attacks, natural disasters, structural failures, and human errors. The controls are customizable and implemented as part of an organization-wide process that manages information security and privacy risk.

Type Document Name Date

Issued Description

SP 800-63-2

Electronic Authentication Guidance

Aug 2013 The guidelines in this document assume the authentication and transaction take place across an open network such as the Internet. In cases where the authentication and transaction take place over a controlled network, agencies may take these security controls into account as part of their risk assessment. This recommendation also provides technical guidelines to agencies to allow an individual to remotely authenticate his or her identity to a Federal IT system.

SP 800-73-3

Interfaces for PIV

Feb 2010 SP 800-73-3 contains the technical specifications to interface with the smart card to retrieve and use the identity credentials. The specifications reflect the design goals of interoperability and PIV Card functions. The goals are addressed by specifying a PIV data model, card edge interface, and application programming interface.

SP 800-79-1

Guidelines for the Accreditation of PIV Card Issuers

June 2008 The purpose of is to provide appropriate and useful guidelines for accrediting the reliability of issuers of Personal Identity Verification cards that are…