federal identity, credential, and access management · pdf filefederal identity, credential,...

Federal Identity, Credential, and Access Management

(FICAM) Roadmap and Implementation Guidance

Part B: Implementation Guidance

Initial Phase 1 ICAM Public Release Draft

February 25, 2011

Powered by the Federal Chief Information Officers Council

and the Federal Enterprise Architecture

This page is intentionally left blank.

Document Note

This document represents a partial draft addition to the FICAM Roadmap and Implementation

Guidance, Version 1.0, published on November 20, 2009. The ICAMSC is developing and

publishing the content for Part B: Implementation Guidance of the document in two phases in

order to enable agencies to take advantage of this guidance immediately when working to

achieve the objectives and initiatives outlined in the ICAM segment architecture. The chapters

included in this draft (i.e., Chapters 6, 9, 10, and 11) have been prioritized for development first

because they address general planning guidance and the physical and logical access

modernization initiatives, which have the most aggressive implementation dates in the Transition

Roadmap (see Version 1.0, Section 5.2). The remaining chapters are currently under

development as part of Phase 2 of the Implementation Guidance development effort. They will

be included in Version 2.0 of the FICAM Roadmap and Implementation Guidance, currently

scheduled for publication on or around June 24, 2011.

Although this document is considered to be in draft form, agencies should not delay in working

to incorporate the guidance provided into their respective ICAM programs. The authors of the

document anticipate modifying the content to improve the flow and narrative and incorporate

additional information as the Phase 2 chapters are developed; however, the general intent and

direction of the guidance in the chapters provided is not expected to change.

This page is intentionally left blank.

FICAM Roadmap and Implementation Guidance Part B: Implementation Guidance, Phase 1 Initial Phase 1 ICAM Public Release Draft

February 25, 2011 Page i

Table of Contents

6. ICAM Implementation Planning ....................................................................................... 1

6.1. Program Organization and Management ........................................................................... 1

6.1.1. Program Governance ................................................................................................................................................. 1 6.1.2. Program Stakeholders ............................................................................................................................................... 4 6.1.3. Program Management Office (PMO) ........................................................................................................................ 12 6.1.4. Performance Reporting ............................................................................................................................................ 20

6.2. Incorporating ICAM into Existing Agency Processes ........................................................20

6.2.1. Management Accountability and Control .................................................................................................................. 21 6.2.2. Capital Planning ....................................................................................................................................................... 21 6.2.3. Enterprise Architecture ............................................................................................................................................. 24 6.2.4. IT Security and Risk Management ........................................................................................................................... 24

6.3. Privacy Considerations .....................................................................................................28

6.3.1. Applying the FIPPs .................................................................................................................................................. 29 6.3.2. Programmatic Support ............................................................................................................................................. 30

7. Initiative 5: Streamline Collection and Sharing of Digital Identity Data .......................32

8. Initiative 6: Fully Leverage PIV and PIV-I Credentials ...................................................33

9. Access Control Convergence .........................................................................................34

9.1. Resource Attribute Management ......................................................................................34

9.1.1. Resource Discovery and Inventory ........................................................................................................................... 34 9.1.2. Collecting and Organizing Resource Information ...................................................................................................... 36

9.2. Privilege Management ......................................................................................................38

9.2.1. Entitlement Attributes ............................................................................................................................................... 39 9.2.2. Privilege Management Lifecycle ............................................................................................................................... 40 9.2.3. Automated Provisioning Capability ........................................................................................................................... 41

9.3. Authorization ....................................................................................................................46

9.3.1. Access Control Models ............................................................................................................................................ 47 9.3.2. Policy Management ................................................................................................................................................. 51

9.4. Auditing and Reporting .....................................................................................................53

10. Initiative 7: Modernize PACS Infrastructure ...................................................................56

10.1. Physical Access Implementation Planning........................................................................56

10.1.1. Program Governance ............................................................................................................................................... 57 10.1.2. Facility Risk Assessments ........................................................................................................................................ 61 10.1.3. Program Funding ..................................................................................................................................................... 63 10.1.4. Schedule Planning ................................................................................................................................................... 65

10.2. Physical Access Architecture and Design .........................................................................70

10.2.1. Solution Architecture ................................................................................................................................................ 70 10.2.2. Solution Components ............................................................................................................................................... 72 10.2.3. Common Design Characteristics .............................................................................................................................. 74

10.3. Physical Access Technical Implementation ......................................................................76


February 25, 2011 Page ii

10.3.1. Automated Provisioning to PACS ............................................................................................................................. 76 10.3.2. Common Physical Access Scenarios ....................................................................................................................... 78

10.4. Local Facility Access ........................................................................................................83

10.5. Visitor Access ...................................................................................................................84

11. Initiative 8: Modernize LACS Infrastructure ...................................................................87

11.1. Logical Access Implementation Planning .........................................................................88

11.1.1. Program Governance ............................................................................................................................................... 88 11.1.2. Program Funding ..................................................................................................................................................... 90 11.1.3. Schedule Planning ................................................................................................................................................... 93

11.2. Logical Access Architecture and Design ......................................................................... 102

11.2.1. Solution Architecture .............................................................................................................................................. 102 11.2.2. Solution Components ............................................................................................................................................. 106 11.2.3. Common Design Characteristics ............................................................................................................................ 110

11.3. Logical Access Technical Implementation ...................................................................... 111

11.3.1. System Configuration ............................................................................................................................................. 111 11.3.2. LACS Enterprise Solution Integration ..................................................................................................................... 114 11.3.3. Common Logical Access Scenarios ....................................................................................................................... 117

12. Initiative 9: Implement Federated Identity Capability .................................................. 120

Appendix I Decision Trees for Component Migration Decisions ....................................... 121


February 25, 2011 Page 1

6. ICAM Implementation Planning

This chapter provides guidance for planning and establishing an ICAM program within a federal

agency. It is expected that agencies have general life cycle methodologies that they employ to

plan and execute programs. The guidance provided in this chapter is intended to supplement

these life cycle methodologies and introduce ICAM specific agency-level planning

considerations that drive the overall success and adoption of the ICAM segment architecture

within the Federal Government.

Chapter 6 has been divided into three elements:

Program Organization and Management. This section discusses the establishment of

ICAM governance bodies to manage and oversee complex ICAM programs within an

agency; suggests stakeholder management and communication strategies for engaging

and collaborating with the wide array of stakeholders involved in ICAM

implementations; and provides risk management guidance proven to successfully

mitigate the level of risk to agencies implementing ICAM programs.

Incorporating ICAM into Existing Agency Processes. This section discusses how

agencies should integrate ICAM into the capital planning, accountability, acquisition, and

security processes that are performed for all government programs.

Privacy Considerations. This section discusses privacy as one of the key drivers behind

the ICAM initiative and introduces guidance for ensuring the privacy of sensitive

information that is inherently contained within the various programs that fall under

ICAM.

6.1. Program Organization and Management

ICAM is a key enabler across the federal enterprise and within specific agency programs and

mission areas; therefore, it is imperative that federal agencies properly organize and manage

ICAM efforts. This section provides guidance on how an agency can establish effective

governance structures, collaborate with stakeholders, provide program management, and report

performance to executive leadership to ensure that these programs are implemented successfully

across the organization and to minimize any negative impact of ICAM on the agency‟s mission.

6.1.1. Program Governance

Goal 1 of the Federal ICAM Initiative, as identified in Section 2.2.1, is to align and coordinate

all of the laws, standards, and regulations that ICAM programs must adhere to, and establish and

enforce accountability for ICAM implementations within federal governance bodies. Achieving

this goal at the Federal Government level will allow supervisory bodies to evaluate the

compliance of agency level programs as a unified ICAM program, as opposed to examining each

of the ICAM component projects independently. In order to ensure that ICAM programs at the

agency level are compliant, each agency should have a formal governance structure, either by

leveraging an existing program structure or by establishing new governance as necessary. This

structure is responsible for aligning and consolidating the agency‟s various ICAM investments,

monitoring these programs for alignment with organizational objectives, and ensuring broad

awareness and understanding. Program governance should also establish goals, mission

priorities, organization, accountability, metrics, and management controls within an agency.



Lesson Learned

It is important for an ICAM governance structure to account for the interdependencies between its project management, investment management, and capital planning components. Health and Human Services enhanced its ICAM program governance by applying its Enterprise Performance Life Cycle framework, which incorporates structured investment processes, distinguished project management principles, and industry best practices.

Establishing a formal governance structure within a federal agency refers to both the creation and

assignment of a specific group or entity to provide oversight and management, and development

and enforcement of agency-specific policies, processes, and performance measures. Governance

encompasses the relationship between the oversight effort, mechanisms put in place to ensure

compliance, the enterprise's overall business direction, and the accountability framework to

encourage desirable behavior. It also encompasses all of the decision-making roles and

responsibilities involved in executing the program across the agency enterprise. The governance

needs to be structured in a way that facilitates coordination between the Department and

bureau/component level and promotes stakeholder buy-in. Program Governance involves

identifying individuals, such as an Executive Sponsor, to champion the ICAM program and

establishing coordinated governance groups at the Department and bureau/component levels,

such as the ICAM Executive Steering Committees (ESCs), addressed in the following section.

6.1.1.1. ICAM Executive Steering Committees

It is necessary to establish a linkage mechanism to ensure alignment between the agency‟s

business strategy and direction and the critical path required to achieve the desired outcomes

over the life of ICAM. Therefore, an oversight mechanism should be put into place to help

ICAM achieve its potential and deliver its promised value for the agency. An ESC is one of the

means by which an agency provides oversight for ICAM programs. The ESC is chartered by the

agency‟s executive leadership to govern and align the ICAM program with its agency‟s mission.

Typically, the ESC is comprised of departmental heads, bureau/component leadership, business

owners, and application owners. The ESC‟s charter should specify the group‟s authority to

enforce changes, when necessary, to align ICAM technology, policy and execution with the

agency‟s overall mission.

An ESC provides an agency with the ability to resolve many of the internal issues common to

ICAM by employing a top-down approach for managing implementation. For example, gaining

the support and buy-in necessary to ensure wide-scale enterprise adoption is often difficult given

the broad reach and technical nature of ICAM. ESCs help mitigate this risk by providing end-

users with a consistent message from their senior executives on how ICAM solutions can

streamline access to resources that support their mission work. Additionally, many of the ESC

participants are leaders within the stakeholder community, and as such, facilitate collaboration

between the diverse groups that contribute to successful ICAM implementation. Properly

chartered, an ESC will establish performance measurement and accountability mechanisms to

ensure that ICAM implementations comply with federal laws and regulations and fulfill the

desired goals and objectives. These specific performance mechanisms are discussed in Section

6.1.4.



Implementation Tip

Documenting and understanding key performance metrics and the expected performance improvements as a result of implementing ICAM are an excellent way to demonstrate program value to leadership and gain the support of the members of an agency’s Executive Steering Committee (ESC). Being able to demonstrate incremental, quantifiable benefits helps maintain program momentum.

As previously noted, the role and responsibilities of each agency‟s ESC are typically governed

by its charter. The following list describes some of the typical responsibilities that might be

assigned to an ESC:

Provide a means through which changes to the ICAM program or disputes between

ICAM and individual program offices are resolved;

Provide direction and counsel to the ICAM Program Management Office (PMO), if

applicable;

Ensure proper resource allocation to ICAM programs and projects;

Review and approve the program business architecture;

Provide input for, or participate in, the critical development stages of the ICAM program;

Take responsibility for overall stakeholder management to include internal and external

stakeholders;

Provide strategic guidance for cost, schedule, performance and technical solutions to

ensure program success;

Review post-implementation evaluations to ensure that forecasted benefits and outcomes

of the ICAM program are met;

Provide program status information to oversight organizations such as the Office of

Management and Budget (OMB), Office of Inspector General (OIG), and Government

Accountability Office (GAO), upon request; and

Establish collaboration to provide guidance, identify common agency challenges, identify

best practices, and share solutions.

Each of the responsibilities listed above contributes to an overarching level of governance and

support that is critical to ensuring the successful implementation of ICAM within an agency.

ESCs provide agencies with a means to ensure agency-wide adoption through strong executive

buy-in and support, ensure alignment with the organization‟s business need and mission, and

enforce compliance with applicable laws, regulations, and policies.

6.1.1.2. Bureau/Component Governance

Some agencies are made up of subgroups, typically called bureaus or components, which operate

in a decentralized manner. For agencies with this dynamic, it may be beneficial to create a

governance structure at the bureau/component level by way of an interdisciplinary team. This

team should be authorized and recognized by department-level leadership to enhance

communication and promote cohesion among the various subgroups within an agency. Obtaining

leadership buy-in at the department-level is an advantageous way to build the foundation of a

strong and recognized ICAM program. The mission of the bureau/component interdisciplinary

team is to provide ICAM-related recommendations to the department‟s ESC and help drive the

success of the ICAM program. These teams are typically comprised of working-level roles and

employ a bottom up approach for managing implementation. An interdisciplinary team at the

bureau/component level plays an important risk mitigation role by providing insight into the



implementation effort from a functional point of view. This information helps the ESC

understand the impact certain decisions may have on program executors and ultimately promote

buy-in across various stakeholders.

FAQ

What groups should be represented in ICAM governance? Governance structures should be made up of individuals that have a diverse blend of skills and experience; for example, business process operators, business process end users, administrative roles, security, privacy, legal and audit, IT, and financial groups. Inclusion of a variety of groups in the ICAM governance will ensure that different needs and opinions are represented and addressed, which contributes to the success of the program.

6.1.2. Program Stakeholders

A stakeholder is an individual or organization that is either actively involved in a program or

who might be affected by the program's execution or completion. It is critical to identify all

stakeholders, and not just those who may be positively affected by the project, in order to

understand the needs, responsibilities, and potential impacts of program decisions. Once the

stakeholders have been identified, an agency can work to engage its stakeholders in support of

the success of the program/project.

This section identifies key ICAM stakeholders, both at the government-wide level (associated

with the ICAM segment1 and the Federal ICAM Initiative) and the agency level (associated with

an agency‟s ICAM program and supporting projects). It then introduces approaches for

managing and engaging stakeholders to support ICAM program success.

6.1.2.1. Government-wide ICAM Segment Stakeholders

An early step in developing the ICAM segment architecture was identifying the stakeholders

related to the ICAM segment. The following table provides an overview of the stakeholders who

were identified as part of this process. The table lists many of the federal stakeholders for ICAM

but is not intended to be an exhaustive list of non-federal stakeholders. The role descriptions

provided for each stakeholder identify their overarching role or mission and their relevance to the

ICAM segment. The stakeholders all contribute to or are impacted by the Federal ICAM

Initiative.

Stakeholder

Group Stakeholder Name Role

Federal

Governance

Bodies

Office of Management and Budget (OMB)

Assists the President in overseeing the preparation of the federal budget and supervises its administration in Executive Branch agencies. Provides policy, direction, and oversight for the implementation of ICAM initiatives. The lead agency with respect to E-Government implementation.

1 ICAM is included the Federal Enterprise Architecture. Information on the other segments can be found in the Enterprise Architecture Segment Report.

http://www.whitehouse.gov/sites/default/files/omb/assets/fea_docs/Interim_FY09_Q4_EA_Segment_Report_Instruction_Guide_v1-3_Sept_2009.pdf




Stakeholder


The Federal Chief Information Officers (CIO) Council

Serves as the principal interagency forum for improving practices in the design, modernization, use, sharing, and performance of Federal Government agency information resources. Chartered the work of the Federal Identity Credentialing Committee (FICC), E-authentication initiative, and the Federal PKI Policy Authority, which have been consolidated into the newly chartered Information Security and Identity Management Committee (ISIMC) and Identity Credential and Access Management Subcommittee (ICAMSC). Also includes the Privacy Committee.

Information Security and Identity Management Committee (ISIMC)

Serves as the principal interagency forum for identifying high priority security and identity management initiatives and developing recommendations for policies, procedures, and standards to address those initiatives that enhance the security posture and protection afforded to Federal Government networks, information, and information systems.

Identity Credential and Access Management Subcommittee (ICAMSC)

Subcommittee of the ISIMC focused on initiatives related to Identity, Credential, and Access Management.

Privacy Committee The Privacy Committee is the principal interagency forum to improve agency practices for the protection of privacy. The Privacy Committee serves as the interagency coordination group for Senior Agency Officials for Privacy and Chief Privacy Officers in the Federal Government that provides a consensus-based forum for the development of privacy policy and protections throughout the Federal Government by promoting adherence to the letter and spirit of laws and best practices advancing privacy.

General Services Administration (GSA)

NOTE: GSA is also an Internal Service Provider

Managing partner for ICAM initiatives.

Provides government building space, acquisition solutions for government organizations and the military, and management best practices and efficient government operations.

Establishes and maintains acquisition vehicles and approved products for Homeland Security Presidential Directive 12 (HSPD-12) deployment.

Provides the USAccess HSPD-12 Managed Service Offering.

Office of Personnel Management (OPM)

NOTE: OPM is also an Internal Service Provider

Supports the Federal Government's workforce by shaping Human Resources (HR) management systems to effectively recruit, develop, manage and retain a high quality and diverse workforce and through technical assistance, employment information, pay administration, and benefits delivery for personnel.

Develops and implements uniform and consistent policies and procedures to ensure the effective, efficient, and timely completions of investigations and adjudications relating to determination of suitability and eligibly for logical and physical access. Conducts personnel background investigations as part of the screening process.

Owns the automated systems to support investigative processing.

Serves as the suitability executive agent for the Federal Government.

2

2 In accordance with responsibilities and duties outlined in Executive Order 13467, Reforming Processes Related to Suitability for Government Employment, Fitness for Contractor Employees, and Eligibility for Access to Classified National Security Information, June 30, 2008.

http://www.fas.org/irp/offdocs/eo/eo-13467.htm



Stakeholder


Suitability and Security Clearance Performance Accountability Council (PAC)

Interagency body established by Executive Order (EO) 134673

and supported by OPM to develop and implement uniform and consistent policies and procedures related to suitability, fitness, and clearance determination activities and processes.

The PAC serves as the most senior policy-making entity for the security and suitability reform effort and provides final determinations for resulting reports, such as the Security and Suitability Process Reform, Initial Report dated April 30, 2008

4

and the Federal Investigative Standards.5

The Federal PKI Policy Authority

Interagency body set up under the CIO Council to enforce digital certificate standards for trusted identity authentication across the federal agencies and between federal agencies and outside bodies, such as universities, state and local governments and commercial entities.

Interagency Security Committee (ISC)

Committee established by EO 12977,which is responsible for developing standards, policies and best practices for enhancing the quality and effectiveness of physical security in, and the protection of, nonmilitary federal facilities in the United States. The ISC provides a permanent body to address continuing government-wide security for federal facilities.

National Science and Technology Council

This Cabinet-level Council is the principal means within the executive branch to coordinate science and technology policy across the diverse entities that make up the federal research and development enterprise.

The NSTC Subcommittee on Biometrics and Identity Management provides leadership and federal coordination for ICAM issues.

Federal Enterprise Architecture (FEA) Interagency Group

Community of federal enterprise architects that support the development of the FEA practices, models and other assets.

Office of the National Coordinator for Health IT (ONCHIT)

Provides counsel to the Secretary of Health and Human Services (HHS) and departmental leadership for the development and nationwide implementation of an interoperable health information technology infrastructure.

Use of this infrastructure will improve the quality, safety and efficiency of health care and the ability of consumers to manage their health information and health care.

Federal Cloud Computing Advisory Council

Provides oversight to the Cloud Computing Initiative and PMO (formerly ITI LOB PMO).

Goal is to achieve an optimized, cost-effective, government-wide information technology infrastructure that supports agency mission, while providing reliability and security in service delivery.

Information and Communications Infrastructure Interagency Policy Committee (ICI-IPC)

The government's primary policy coordination body for secured global information and communications infrastructure.

Its focus is to achieve an assured, reliable, secure, and survivable global information and communications infrastructure and related capabilities, and is the policy forum for cybersecurity matters.

3 EO 13467, Reforming Processes Related to Suitability for Government Employment, fitness for Contractor Employees, and Eligibility for

Access to Classified National Security Information, June 30, 2008.

4 Security and Suitability Process Reform Initial Report, Joint Security and Suitability Reform Team, April 30, 2008.

5 Federal Investigative Standards, Joint Security and Suitability Reform Team, December 2008.

http://www.fas.org/irp/offdocs/eo/eo-13467.pdf

http://ftp.fas.org/sgp/othergov/omb/secsuit.pdf

http://georgewbush-whitehouse.archives.gov/omb/reports/joint_security_dec2008.pdf



Stakeholder


Information Sharing and Access Policy Interagency Policy Committee (formerly the Information Sharing Council)

Council first established under EO 13356 to review matters related to the improvement of sharing terrorism information.

The IPC holds responsibilities to advise the President and the Program Manager on the development of Information Sharing Environment (ISE) policies, procedures, guidelines, and standards, and to ensure proper coordination among federal agencies participating in the ISE.

National Security Staff (NSS)

The merged National Security Council (NSC) and Homeland Security Council (HSC). The mission of the NSS is to advise and assist the President on national security and foreign policies.

Committee of National Security Systems (CNSS)

Provides a forum for the discussion of policy issues in regards to the protection of national security systems.

6 The committee has

representation from 21 U.S. Government Executive Branch Departments and Agencies.

Internal

standards

body

National Institute of Standards and Technology (NIST)

Non-regulatory federal agency within the U.S. Department of Commerce that promotes U.S. innovation and industrial competitiveness by advancing measurement science, standards, and technology.

The NIST Computer Security Division has developed extensive standards that impact implementation of ICAM programs and their underlying IT systems under the statutory responsibilities of the Federal Information Security Management Act (FISMA).

NIST is an ANSI accredited standards development organization to develop biometric format standards.

External

industry

guidance and

standards

bodies

ASIS International ASIS International is the preeminent organization for End-User physical security professionals. Founded in 1955, ASIS is dedicated to increasing the effectiveness and productivity of security professionals by developing educational programs and materials that address broad security interests.

Information Card Foundation (ICF)

The ICF is a non‐profit foundation whose mission is to advance simpler, more secure and more open digital identity on the Internet, increasing user control over personal information while enabling mutually beneficial digital relationships between people and businesses.

Kantara Initiative/Liberty Alliance

Global body working to enable a networked world based on open standards where consumers, citizens, businesses and governments can more easily conduct online transactions while protecting the privacy and security of identity information.

OpenID Foundation (OIDF)

Organization formed to help promote, protect and enable the OpenID technologies and community.

The OIDF manages intellectual property, brand marks as well as fostering vital growth and global participation in the proliferation of OpenID.

Organization for the Advancement of Structured Information Standards (OASIS)

Not-for-profit consortium that drives the development, convergence and adoption of open standards for the global information society.

OASIS develops security standards (e.g., Security Assertions Markup Language (SAML) and WS*

7) needed in e-business and

Web services applications.

6 Although national security systems are outside the scope of this document, the NSS and CNSS have been included as stakeholders because they

coordinate with OMB and the ISIMC in areas where the ICAM initiative relates to national security efforts.

7 WS*(WS-SEC, Web Services Security, WSS): A family of web service standards/specifications published by OASIS WS-Security.



Stakeholder


Security Industry Association (SIA)

Non-profit international trade association representing electronic and physical security product manufacturers, distributors, integrators, and service providers. American National Standards Institute (ANSI)-approved Standards Development Organization involved in developing systems integration and equipment performance standards.

Smart Card Alliance (SCA) Not-for-profit, multi-industry association working to stimulate the understanding, adoption, use and widespread application of smart card technology.

SCA has authored numerous white papers that provide best practices in the area of credential management.

TechAmerica High-tech industry association active in Federal Information Security policy issues.

Transglobal Secure Collaboration Program (TSCP)

Government-industry partnership specifically focused on facilitating solutions for Aerospace and Defense (A&D) issues. Currently working on identity federation issues in international defense and aerospace programs.

Internal ICAM

Service

Providers

Department of the Treasury

A provider of PKI services and digital certificates for trusted identity authentication across the Federal Government and with external bodies.

Federal Bureau of Investigation (FBI)

Protects and defends the United States against terrorist and foreign intelligence threats, upholds and enforces the criminal laws of the United States, and provides leadership and criminal justice services to federal, state, municipal, and international agencies and partners.

Conducts national fingerprint and criminal history checks.

External ICAM

Service

Providers

Cooperative groups and initiatives

Partnerships formed to share information, the ability to authenticate across boundaries, or other ICAM function such as the Four Bridges Forum and Global Federated Identity and Privilege Management (GFIPM).

Industry Identity Access Management (IAM) providers

The issuers of electronic credentials to user communities. Similarly, providers of authentication technologies are stakeholders in assisting the government with the most appropriate services based on the needs of our customers and the state of the industry.

Also includes IDPs and Trust Providers.

Industry PKI Service Providers

Providers of PKI services and digital certificates for trusted identity authentication across the Federal Government and with external bodies.

Internal

Service

Consumers

Cross-agency shared service system owners

Accept and trust electronic assertions of identity in respective electronic or web-based systems.

Federal Agency Application Owners

Will accept and trust electronic assertions of identity in respective electronic or web-based systems. Also referred to as Relying Parties.

Federal Employees Core recipient of Personal Identity Verification (PIV) credentials and holders of legacy E-Authentication credentials.

Require access and user privileges for both physical and logical access.

A subset of federal employees also serves as implementers of FICAM initiatives.



Stakeholder


External

Service

Consumers

American Public and Businesses

The individuals and businesses that require access to government systems and resources.

Government-wide approach to ICAM must address the varying needs of these communities, focusing particularly on the characteristics of the two user segments: Government-to-Citizen and Government-to-Business. The Federal Government provides ICAM services to universities and contractors as business partners.

Privacy Community People and organizations that support privacy practices and regulation. Members can be users of government services and advocate for the secure handling of that data.

State, Local, Foreign and Tribal Governments

Transact business on behalf of their government or its constituency.

Partner with the Federal Government in identity management initiatives (e.g., State and Local partnership with the Department of Homeland Security (DHS) to develop the First Responder Access Card (FRAC) identity credential).

Figure 1: Federal ICAM Initiative Stakeholders

6.1.2.2. Agency-level ICAM Program Stakeholders

ICAM programs are large, complex initiatives that often span across several agency

bureaus/components; as such, it is critical to define the program objectives, boundaries, and

stakeholders early in the planning process. Identifying and managing the stakeholders

responsible for ICAM business processes and systems is critical to achieving a fully integrated

ICAM portfolio.

The following table provides an overview of many agency-level stakeholders within an agency-

level ICAM program. For each stakeholder, the table includes role descriptions identifying their

overarching role or mission within the agency and their relevance to the ICAM program. The

table is not intended to be an exhaustive list of agency-level stakeholders for all federal

organizations, but rather to highlight the most common groups that are involved in or impacted

by ICAM implementations.

Stakeholder Name Role

Agency Employees Employees of a federal agency. Employees comprise a large percentage of an agency’s total user population. Employees consume ICAM services by using their PIV cards to gain access to agency facilities and information systems.

Agency Partners and Affiliates Includes contractors working on behalf of the Federal Government and affiliates that do business with or consume the services provided by federal agencies. Portions of this population utilize the PIV card to access agency facilities and information systems, while others utilize non-PIV cards and require only occasional access to agency assets.

Business Process/System Owners Individuals within an agency responsible for managing a set of activities, programs, and systems that are critical to operations and use ICAM services.

General Counsel Responsible for providing legal oversight over an agency’s ICAM programs, administering security clearance review programs, and ensuring that ICAM programs abide by all applicable laws and regulations through use of an Inspector General (IG) led audit and accountability program.




Human Resources (HR) Responsible for conducting agency-level recruitment, on-boarding, wage, and benefit activities, and establishing personnel policies and regulations. As on-boarding officials, HR offices are generally responsible for collecting and managing biographical information on federal employees, which results in creation of a digital identity within the agency’s HR application.

HR works closely with Personnel Security during the recruiting and on-boarding processes to ensure that an appropriate background investigation is conducted for each new hire.

Office of the Chief Financial Officer

(OCFO)

Responsible for administering the agency’s budget, and reviewing and submitting budgetary/investment requests to OMB. OCFO is also responsible for developing and implementing fiscal planning activities to ensure alignment with the agency’s strategic and operational ICAM goals and objectives.

OCFO plays a significant role in processing and submitting budget requests for ICAM investments and ensuring that ICAM requirements and tools are leveraged across the agency’s investments.

Office of the Chief Information

Officer (OCIO) Responsible for maintaining the agency’s overall information security posture, defining and ensuring compliance with the agency’s enterprise architecture (EA), and planning for technology investments to meet current and future requirements. The CIO typically coordinates with the agency's Chief Financial Officer (CFO) to assure that the information technology programs and activities are executed in a cost-effective manner.

OCIO is heavily involved in ICAM implementations by ensuring that appropriate security controls are applied, determining how the ICAM solution will impact the security of existing applications, and incorporating ICAM into the agency’s EA.

Office of the Chief Information

Security Officer (OCISO)8

Responsible for developing, employing, and publishing security policies, programs, and standards to guard the agency’s personnel, property, facilities, and information. Overseeing projects related to credentials, badges, emergency signaling devices, etc.

OCISO has leadership and authority over security policy and programs within the agency and can coordinate with the Personnel Security and Physical Security divisions.

Personnel Security Responsible for coordinating with managers HR departments to determine position sensitivity levels for each position occupied within the agency, and coordinating with OPM to ensure that an appropriate background investigation and/or periodic reinvestigation is conducted for all agency employees and contractors.

Physical Security Responsible for managing and maintaining the security of agency buildings, including: resolving conflicts concerning entry to facilities, and verifying that those seeking to gain access to federal buildings are appropriately authorized to do so (including visitors).

PIV Credentialing Program Responsible for managing and maintaining the PIV card issuance process and infrastructure.

Privacy Office Responsible for administering policy to govern the use, collection, storage, and dissemination of personally identifiable information (PII) for all agency employees, contractors, and affiliates. Privacy Offices are also responsible for maintaining an agency’s System of Records Notices (SORNs), and supporting Privacy Impact Assessments (PIAs) for all IT investments, including ICAM.

Solution Providers Industry partners and/or system integrators that provide ICAM services to federal agencies.

8 The Office of the Chief Information Security Officer is the naming convention used by various Federal government agencies, although similar naming structure can be found as well such as The Office of the Chief Security Officer.




Unions Responsible for representing the interests of its federal employee members and conducting collective bargaining on their behalf. As representatives for federal employees, the unions are frequently involved in matters related to ICAM processes that collect personal information or introduce additional requirements for background investigations.

Figure 2: Agency-level ICAM Stakeholders

6.1.2.3. Stakeholder Management Strategies

Traditionally, ICAM programs have been managed in stove-pipes, which has led to challenges in

involving all relevant stakeholders. Stakeholder management, as it relates to ICAM, involves

coordination, collaboration, and communication with numerous entities within the agency. Each

of these entities often has a distinct mission requirement and performs a specific set of duties in

support of the overall agency mission. As such, these stakeholders all have important ties to

ICAM, but are not necessarily bound together by a single agency program or project. These

stakeholders will have different viewpoints that may conflict with one another or the overarching

ICAM program objectives. Furthermore, decisions made in one program area may impact

another; therefore, the ability to communicate and coordinate across stakeholder groups,

leveraging their inputs to the benefit of all, becomes increasingly important to the success of the

overall ICAM program. This section presents some high-level considerations for involving

stakeholders and promoting collaboration across an agency‟s ICAM portfolio to help overcome

many of the challenges typically associated with ICAM.

Collaboration is both a process and an outcome in which shared interest or conflict is addressed

by a group of key stakeholders. The collaborative process involves a synthesis of different

stakeholder perspectives to better understand complex problems. In the case of ICAM, the

stakeholder perspectives will range from business process owners needing access to data and

services to the agency end user needing gate access and access to data and services in order to

successfully perform his job. The benefits provided by streamlining agency processes using

ICAM solutions cannot be realized without close collaboration and consideration of all

stakeholder requirements.

Collaboration is usually achieved through the development of expert problem-solving teams,

such as working groups that are established to address issues and present solutions. Although

members of these groups have individual accountability, they come together to share information

and perspectives and produce shared work products. The success of these groups is heavily

reliant on participation and involvement from stakeholders across the program in order to ensure

that all requirements are considered. Within an agency‟s ICAM program, for example, each

bureau/component might assemble an interdisciplinary working group responsible for expressing

the concerns and interests of its business and system owners and users. These representatives

work with the group to incorporate their needs into agency-wide program capabilities and

requirements. Working groups of this nature are an excellent forum for identifying and escalating

business and technical challenges that may not be known at the enterprise level but could impede

ICAM implementation throughout the agency. Working groups are also used as a forum for

sharing implementation lessons learned across bureaus/components or individual programs in

order to reduce overall ICAM program risk and increase speed and efficiency in implementation.

In addition to working groups, an agency may choose to stand up smaller focus groups or tiger

teams for the purpose of resolving specific program issues or providing directed support for



implementation. This technique helps improve stakeholder buy-in associated with enterprise

approaches and services by promoting better understanding and a sense of inclusion and

ownership in the program. It also improves consistency across an agency‟s ICAM

implementation, a key goal when implementing the ICAM segment architecture. For example, an

agency‟s ICAM PMO staff could leverage small focus groups with expertise in the agency‟s

enterprise ICAM programs and tools to consult with and support implementation efforts at the

bureau/component level.

6.1.3. Program Management Office (PMO)

In addition to setting up an ICAM governance structure, an agency needs to establish a

mechanism for supporting execution and operations of the projects and workstreams within the

ICAM program. This section examines a PMO as one possible alternative for providing ICAM

program support.

Implementation Tip

In order for a Program Management Office (PMO) to be effective, it must be chartered to perform the functions as needed, have the support of executive leadership, be allowed to use resources as required, and have the skills and expertise to implement the ICAM program.

An ICAM PMO serves a complementary role to the ESC and while establishing both an ESC and

a PMO may not be strictly necessary, larger organizations may see the need to separate

governance and operational responsibility within their ICAM programs. A PMO helps ensure

that the individual projects and investments that comprise the ICAM program run smoothly and

achieve the expected results within the defined budgetary and schedule constraints. In addition,

an ICAM PMO provides an agency with a single coordination point for streamlining

management of ICAM programs at an operational level. This position allows the PMO to

facilitate close cooperation and synchronization between an agency‟s ICAM stakeholders and the

individual ICAM component activities to ensure alignment across the organization. The PMO

will typically be responsible for the supporting functions discussed throughout Section 6.1,

including:

Planning and coordinating implementation efforts across various ICAM stakeholders and

component programs (e.g., credentialing, physical access control, logical access control,

personnel security, etc.);

Maintaining an enterprise ICAM perspective to ensure alignment of all component

programs with organizational objectives;

Serving as a centralized point of contact for ICAM questions, issues, and concerns;

Planning for and securing program funding to execute ICAM capabilities;

Handling communications and outreach to both internal and external stakeholders; and

Managing program risks and issues to resolution across agency office/component/bureau

boundaries.



FAQ

What is the difference between an Executive Steering Committee (ESC) and a Program Management Office (PMO)? ESCs traditionally provide top-down leadership support and guidance across the programs within an agency and PMOs provide operational support for the day-to-day execution of a specific implementation.

To further promote the successful execution of the ICAM program initiatives, an ICAM PMO

may decide to assign separate workstreams to individuals who already have an active and

steadfast involvement in a particular area outside of the program. These “champions,” as the title

implies, must have the passion to drive the success of their piece of the ICAM puzzle and make

it their personal mission to achieve the performance outcomes defined for the ICAM target state.

Additionally, a workstream task lead manages the day-to-day activities of his/her individual

workstream and provides the ICAM PMO with critical and timely information related to the

planning, development, deployment, and activities of their initiatives.

Workstream Name Responsibilities

Ad

min

istr

ati

ve

Wo

rks

tream

s

Outreach and Communications Responsible for developing and executing the ICAM program’s Communications Plan, including:

Defining communication message types, media, target audience, and timing.

Communicating ICAM program concepts, activities, and progress to promote support for the implementation of improved ICAM capabilities.

Policy Responsible for setting the direction for the ICAM program and developing or finalizing all policies and standard operating procedures related to the ICAM program.

Budget Responsible for developing, managing, monitoring, and reporting on the ICAM program budget. The Budget Workstream will have key interfaces with an agency’s OCFO during the budget development and submission cycles.

Performance Management Responsible for tracking, managing, and reporting on overall ICAM program performance and metrics.

Pro

jec

t W

ork

str

ea

ms

Identity Management Responsible for ICAM processes and systems related to the management of digital identity data. This includes management and oversight of efforts to modernize the management of digital identities, such as HR modernization, in accordance with the ICAM target state initiatives.

Credential Management Responsible for ICAM processes and systems related to credential lifecycle management activities. Separate workstreams may be identified for various credential types, including agency PIV cards and local facility access cards.

Physical Access Responsible for ICAM processes and systems related to physical access control, including modernization efforts in accordance with the ICAM target state initiatives.

Logical Access Responsible for ICAM processes and systems related to logical access control, including modernization efforts in accordance with the ICAM target state initiatives.

Figure 3: Examples of ICAM Workstream Responsibilities

A PMO has many characteristics that make it a viable method for providing ICAM program

management. PMOs generally follow standardized project management policies, processes, and

methods. Within ICAM, a PMO provides opportunities to share lessons learned both within an

agency and across agencies. It may serve as an advisor to other agency offices or programs



impacted by the ICAM program (see Section 6.2) on addressing ICAM as appropriate within

other agency-wide capabilities. Additionally, an ICAM PMO acts as a single, centralized point of

contact for the agency‟s ICAM program. Finally, the PMO is the primary authority for

performing acquisition planning tasks and making procurement decisions. As a result, an ICAM

PMO can offer an agency the following benefits:

Enhanced efficiency

Streamlined overhead costs

Minimized redundancy of ICAM-related processes

Validated alignment with architecture and technical standards

Fostered communication and cooperation between interrelated programs

Consistent messaging to both internal and external stakeholders

Timely and accurate reporting

Minimized confusion

Facilitated agency-wide adoption

Minimized risk

Figure 4 represents a sample ICAM PMO structure. An agency should design its ICAM PMO

structure in a way that fosters communication, coordinates efforts, and appropriately aligns with

the agency‟s overall organizational structure.

Figure 4: Sample ICAM PMO Structure

Because program communications, risk management, and acquisition planning are critical

functions of the ICAM PMO, these functions are discussed further in the following sections.

6.1.3.1. Program Communications

Effective communication at all levels is key to the success of any program, in order to facilitate

support with stakeholders at various levels in the agency. In order to communicate consistently

and effectively, a Communications Plan should be developed early in the program life cycle for



programs such as ICAM. A Communications Plan will outline the objectives, goals, themes and

approach of the overall program. Some goals of the plan include the distribution of project

information, management of stakeholders‟ expectations and communication of project

performance. The following table provides a summary of some of the common communications

that an agency might incorporate as part of its ICAM program.

Communication Description Target Audience Delivery Media

ICAM program awareness materials explaining key program features and milestones

User population Brochure, posters, video

ICAM program website containing resources for stakeholders and users

Various stakeholder groups Website

Ad hoc updates for system rollout events and changes

User population E-mail, newsletter bulletin

Leadership briefing highlighting program objectives and status

Agency leadership Slide presentation, meeting

Lessons learned workshops ICAM implementers Meeting, teleconference, webinar

Messages from Leadership ICAM implementers, user population

Memo, e-mail

ICAM conference or All-hands ICAM implementers, user population

Meeting, teleconference, webinar

Figure 5: Sample ICAM Program Communications

When creating a Communications Plan, agencies should analyze the stakeholders that make up

their audience and tailor the message and delivery media in such a way that will produce the

desired response. The goal of this plan is to keep stakeholders regularly informed and involved

by providing appropriate and well-structured communications, ultimately helping to foster and

maintain stakeholder support and reduce risk.

Lesson Learned

Process or system changes that will impact users need to be communicated early and often in order to promote adoption. As many agencies learned when introducing the new PIV credential, employees and contractors needed to be made aware of the new requirements, processes, and their benefits before enrollments started to increase.

6.1.3.2. Program Risk Management

Risk management involves the identification of policies, procedures, and practices, as well as the

analysis, assessment, control, and avoidance of threats to the continuing efficiency, profitability

and success of program operations. Due to the complexity of ICAM and its cross-departmental

involvement, risks that threaten the success of an agency‟s ICAM program can have sweeping

effects. Therefore, proactive risk management is paramount within an agency‟s ICAM program.

This requires the involvement of the entire program management team and active maintenance of

issues. Other typical characteristics of a successful risk management program include:

Stakeholders at all levels within a project can identify a risk;

Processes exist to analyze, prioritize, and determine mitigation approaches for identified

risks;

Procedures are in place for assigning owner(s) of a risk and defining risk ownership

responsibilities;



A defined escalation path exists for flagging and resolving risks up to and including

executive leadership, as necessary;

There is an ability to track the resolution efforts and their effectiveness; and

Report on risk status to organizational leadership.

ICAM implementers should develop a Risk Management Plan that defines the way risks are

measured for the ICAM program, provides a process for identification and appropriate response,

and assigns roles and responsibilities for various stages in the process. Tools are available

commercially to help manage and track risks for a program. ICAM implementers should

determine if their agency has risk management tools that could be leveraged within the ICAM

program.

Another leading practice in ICAM Risk Management is the use of a Risk Registry (sometimes

referred to as a Risk Log), which aides in managing, assigning and tracking risk events. The Risk

Registry usually includes the description of the risk event, the date that the event occurred, how

the event was resolved, whether the resolution was effective, and the owner of the event. Review

and updating of the Risk Registry should be incorporated into ongoing management processes. A

Risk Registry was developed as part of the ICAM segment architecture to identify and track risks

for the Federal ICAM Initiative. It can be found in Appendix D Risk Registry. The following

table summarizes some of the common risks faced within an agency ICAM program and sample

mitigation approaches.

Item

No. Risk Description Mitigation Plan

1 If agency plans and budgets do not include ICAM activities, adequate funding may not be available for modernization efforts, the agency will not be able to meet target state requirements and deadlines for the ICAM segment architecture.

Develop consolidated ICAM business case and funding request to secure funding beginning in FY12.

Communicate funding needs to agency OCFO and explore existing funding sources within the agency. Determine if internal funding can be routed to ICAM efforts, for example, working capital.

2 If the agency’s ICAM transition plan does not gain support and adoption at the Assistant/Deputy Secretary level, including required compliance, the agency will not receive coordination and support from the necessary stakeholders in order to move forward with implementation.

Support institution of governance structure for ICAM (to include ESC). Develop and implement Communications Plan.

3 If the agency doesn’t meet the scheduled transition activity milestone dates, funding for ICAM and other agency systems may be impacted.

Based on agency ICAM segment architecture analysis, provide realistic completion targets for ICAM activities to OMB in the ICAM Transition Plan template.

4 If the bureaus/components fail to adopt enterprise ICAM services in a timely manner, overall agency ICAM implementation and compliance will be delayed.

Dedicate ICAM PMO resources and program funding to gain stakeholder buy-in and support bureau/component-level implementation requirements and efforts.

5 If the agency is unable to staff dedicated resources with the necessary technical knowledge, the agency will be unable to successfully execute technical implementation and the program schedule will lag.

Leverage cross-agency ICAM expertise via working groups and outreach in order to supplement staff knowledge.

Incorporate staff augmentation in the ICAM acquisition plan in order to ensure necessary skill sets.

6 If the ICAM effort is unable to gain acceptance by the user population, the agency will not be able to meet target state requirements and deadlines.

Dedicate additional ICAM PMO resources and program funding to increase the communication effort and promote awareness.



Item

No. Risk Description Mitigation Plan

7 If the ICAM solution vendor(s) goes out of business, the agency may experience program delays or incur additional costs to migrate to new solutions.

Include supply chain risk management in ICAM program Acquisition Plan and identify alternative solution component sources. Where possible, use approved vendors and products from established acquisition vehicles. Include activities for compiled software escrow and source code escrow.

Figure 6: Sample ICAM Program Risks and Mitigations

One area that can introduce significant risk to a program is procurement. It is imperative that the

PMO plan an approach for the acquisition of ICAM-related products and services that is cost and

time effective in order to minimize the overall impact on the program.

6.1.3.3. Acquisition Planning

When planning for the acquisition of products and services for its ICAM program, an agency

must comply with specified regulations and policies, the core system of regulations being the

Federal Acquisition Regulation9 (FAR). The FAR sets forth the rules governing the federal

acquisition process and includes several clauses specifically relevant to an agency‟s ICAM

program, as discussed later in this section. When purchasing products and services for its HSPD-

12 implementation, an agency must also follow OMB M-06-1810

and leverage the Federal

Information Process Standard 201 (FIPS 201) Evaluation Program Approved Products List

(APL). In addition to the requirements governing federal acquisitions, an agency has other

resources at its disposal to support acquisition for its ICAM program, including the GSA

Schedules, also addressed in this section.

FAQ

What is the difference between General Services Administration (GSA) Schedules and the Approved Products List (APL)? GSA Schedules are purchasing vehicles for a broad range of products and services. The resources available on the GSA Schedules have pre-approved vendors and pre-negotiated rates. The APL is a list of Homeland Security Presidential Directive 12 (HSPD-12) related products and services that have been tested per an approved NIST test procedure. An agency can use the GSA Schedules to purchase a resource that is included on the APL.

OMB M-06-18 provides guidance to federal agencies related to the acquisition of products and

services for HSPD-12 implementations. It introduced several amendments to the FAR, which

were codified in 48 C.F.R. Subpart 4.13,11

that require an agency to comply with HSPD-12 and

FIPS 201 for contractors who require routine logical or physical access and include language to

this effect12

in applicable solicitations and contracts. The addition to the FAR also requires that

agencies purchase only approved products and services in support of their HSPD-12

implementations. The FIPS 201 Evaluation Program was developed to organize and define a

standardized approval process for these products and services. All required NIST validation and

9 FAR, Volume 1, March 2005.

10 OMB M-06-18 Acquisition of Products and Services for Implementation of HSPD-12, June 30, 2006.

11 FAR Subpart 4.13- Personal Identity Verification.

12 48 C.F.R 52.204-9, Personal Identity Verification of Contractor Personnel, September 2007.

https://www.acquisition.gov/Far/current/pdf/FAR.pdf

http://www.whitehouse.gov/sites/default/files/omb/assets/omb/memoranda/fy2006/m06-18.pdf

https://www.acquisition.gov/far/html/Subpart%204_13.html

https://www.acquisition.gov/far/html/52_200_206.html#wp1139617



GSA testing must be met to be an approved product or service for HSPD-12 purchases.

Approved products and services, which have been demonstrated to meet NIST validation and

GSA testing and have been qualified by the Evaluation Program, can be found on the FIPS 201

APL.

The APL is continuously updated to reflect new products and technologies that have been

evaluated and approved. It is an agency‟s responsibility to stay current on these changes and

incorporate them into agency planning during regular technology refresh cycles as part of the

capital planning and budget process. A complete inventory of Government Certified and

Approved Services and Products Listings, including the FIPS 201 APL, Certified PKI Shared

Service Providers (SSP) List, and Qualified HSPD-12 Service Providers List, can be found on

GSA‟s website.13

In addition to the APL, there are several other activities underway in the Federal ICAM Initiative

to identify and recognize specific categories of products and services that meet advertised criteria

to support other functions within an agency‟s ICAM program. These include:

The Path Discovery and Validation (PDVAL) products approval process using the Public

Key Interoperability Test Suite (PKITS) to ensure compatibility and interoperability of

solutions within the Federal Bridge Certificate Authority (FBCA);

The Trust Framework Provider Adoption Process, which outlines the process that the

ICAM community uses to certify organizations that assess commercial Identity Providers

for use by the Federal Government (discussed further in Section 12.1.1); and

The Personal Identity Verification Interoperability (PIV-I) for Non-Federal Issuers (NFI)

guidance14

and supporting processes for approving an NFI.

Implementation Tip

Purchasing products off of the Homeland Security Presidential Directive 12 (HSPD-12) Approved Products List (APL) does not ensure interoperability or appropriateness for your agency’s implementation. Products bought from the APL must be properly integrated and configured to be interoperable with other ICAM programs and services. Furthermore, prior to acquiring, agencies should determine if the products are appropriate for the risk level and/or design of the ICAM solution.

Though not a required acquisition tool, GSA Schedules provide quick, flexible, cost-effective

procurement solutions and assist in compliance by including approved products. Overall, the

benefits offered by schedules result in reduced risk and, when applied to an agency ICAM

program, allow agencies to achieve the ICAM objectives of cost-effectiveness and efficiency.

There are two GSA Schedules that are relevant to the ICAM effort: IT Schedule 70 and Schedule

84.

IT Schedule 70 is under the Multiple Award Schedule (MAS) program and gives agencies direct

access to commercial experts who are able to address the needs of the government IT

Community through a series of Special Item Numbers (SINs). These SINs cover most of the

general purpose commercial IT hardware, software and services and should be used by agencies

as needed to meet their mission objectives as well as ICAM initiatives. Within IT Schedule 70,

GSA has set up SINs 132-60 through 132-62, which can help an agency meet the procurement

13 GSA FIPS 201 Evaluation Program Approved Products List

14 Personal Identity Verification Interoperability for Non-Federal Issuers, Version 1.1, CIO Council, July 2010.

http://www.idmanagement.gov/drilldown.cfm?action=gov_app_products

http://www.idmanagement.gov/documents/PIV_IO_NonFed_Issuers.pdf



needs of its ICAM program, including electronic credentials, Public Key Infrastructure (PKI)

services, and HSPD-12 products and services. With regard to HSPD-12, OMB M-06-1815

promotes the use of IT Schedule 70, SIN 132-62 and notes that agencies purchasing HSPD-12

products and services through acquisition vehicles other than GSA IT Schedule 70 bear the

responsibility for ensuring that they comply with the applicable federal standards and

requirements. In addition to IT Schedule 70, ICAM implementations often require acquisition of

security products and services, particularly items related to Physical Access Control Systems

(PACS). These items may be procured using Schedule 84, which includes a full suite of solutions

for law enforcement, security, facilities management, fire, rescue, clothing, marine craft, and

emergency/disaster response.

Agency procurement personnel may purchase resources off of both schedules to meet their

ICAM implementation needs. For example, an agency trying to modernize their PACS could

purchase new card readers for access control points off of Schedule 84 and purchase services

from the system integrator off of Schedule 70. Additionally, state and local governments are

authorized to purchase products and services through GSA Schedules 70 and 84 by way of the

Cooperative Purchasing Program. This arrangement may help achieve interoperability in

Government-to-Government (G2G) ICAM interactions in the target state.

FAQ

Why are some products and services not represented by a category on the FIPS 201 Product/Service category list? The FIPS 201 Evaluation Program evaluates and approves only products and services for which there are direct requirements specified in FIPS 201. Although they are not part of the Evaluation Program, GSA has also developed qualification requirements and a list of qualified vendor services for other products and services that may be necessary for HSPD-12 systems and deployments but have no direct requirements in FIPS 201 (e.g., integration services, contractor managed services and solutions). These can be found at www.idmanagement.gov.

Using the resources discussed in this section offers an agency the following benefits when

purchasing products and services to support its ICAM program:

More competitive rates and potentially lower implementation costs. Regardless of the

method used to access schedules 70 and 84, GSA has already negotiated fair and

reasonable prices for these products and services. It is prepared to help agencies leverage

both contracts to maximize the value for the materials and services purchased.

Shorter procurement time. GSA Schedules offer streamlined procurement over agency-

negotiated contracts, which can be cumbersome and costly. Additionally, tools such as

eBuy16

and GSA Advantage17

are available to assist in ordering from both Schedules.

These websites specifically provide procurement specialists with an extensive selection

of approved products and services from GSA contracts.

Reduced complexity and effort required to perform due diligence. Agencies

purchasing products not included on the GSA APL are responsible for ensuring that the

products and services procured meet all applicable federal standards and requirements,

15 OMB M-06-18, Acquisition of Products and Services for Implementation of HSPD-12, June 30, 2006.

16 www.ebuy.gsa.gov

17 www.gsaadvantage.gov


http://www.ebuy.gsa.gov/

http://www.gsaadvantage.gov/



ensuring conformance to applicable federal standards for the lifecycle of the components,

and maintaining a written plan for ensuring ongoing conformance to applicable federal

standards for the lifecycle of the components.18

This effort can be expensive,

burdensome, and time consuming.

Elimination of non-compliance with standards and requirements. If the GSA

Schedules and the APL are not used, an agency also runs the risk of potential non-

compliance if its conformance processes are incomplete or do not keep pace with changes

within the GSA Evaluation Program.

6.1.4. Performance Reporting

Performance measures are essential for successful program management and oversight.

Assigning performance measurements to an agency‟s ICAM program provides decision makers

and stakeholders with a useful tool to monitor progress, determine program effectiveness, and

identify areas that need more funding or process improvement. As shown in Figure 3, an agency

may choose to assign a dedicated workstream to the important task of measuring and reporting

performance.

Implementation Tip

It is important to make leadership and management feel ownership and accountability for the success of their agency’s ICAM program. One way to accomplish this is to tie any outcomes and accomplishments of the ICAM program specifically to the responsible individual’s yearly performance plan.

Performance reporting for ICAM programs has traditionally been focused on external reporting

requirements (e.g., E-authentication performance measures, PIV card issuance numbers). In

addition to mandatory reporting requirements, agencies should determine ways to leverage

performance reporting to improve alignment with the ICAM segment architecture and drive

progress on ICAM programs internal to the agency. Section 5.3 of the ICAM segment

architecture specifies 32 performance metrics that align with achieving the target state. These

serve as a starting point for agencies to measure the performance of their ICAM program and

report the results to executive leadership. It is recommended that agencies incorporate the ICAM

metrics into their ICAM program management practices and project reporting practices.

Additionally, agencies should incorporate relevant metrics into their Exhibit 300 business case

submissions for any ICAM investments as a means of tracking pertinent information and

demonstrating investment results and value to the agency.

At the end of FY 2010, agencies were required to provide their plans for implementing the use of

the PIV credential within the agency and an ICAM Reporting Template was provided for this

purpose (available on www.max.omb.gov). In addition, there is mandatory reporting via the

Cyberscope process for agency use of PIV credentials for physical and logical access.

6.2. Incorporating ICAM into Existing Agency Processes

In addition to planning specific to an ICAM program, there are numerous other systems and

processes within an agency that are impacted by the implementation of the ICAM segment

architecture. Each of the following subsections discusses an existing agency process or program,

18 FAR Subpart 4.13 – Personal Identity Verification

http://www.max.omb.gov/

https://www.acquisition.gov/FAR/current/html/Subpart%204_13.html



the impacts of the ICAM target state on that program, and guidance for addressing ICAM

considerations.

6.2.1. Management Accountability and Control

Management accountability, as defined by OMB Circular A-123,19

is the expectation that

managers are responsible for the quality and timeliness of program performance, increasing

productivity, controlling costs and mitigating adverse aspects of agency operations, and assuring

that programs are managed with integrity and in compliance with applicable law. Management

controls (i.e., organization policies and procedures) are tools to help program and financial

managers achieve results and safeguard the integrity of their programs.

In order to improve the ability to assess alignment with the ICAM segment architecture, it is

recommended that agencies leverage ICAM-specific evaluation criteria for use by agency

Inspectors General for evaluating ICAM implementation.20

These criteria should leverage the

characteristics of the ICAM target state architecture as a model for controlling ICAM program

costs and increasing efficiency. The performance architecture, as discussed in Section 3.2.1,

defines clear areas for managing and evaluating alignment of programs with the ICAM target

state. In particular, the performance metrics identify quantitative measures for evaluating ICAM

program success. Some common topic areas that could be included in evaluation criteria are:

Elimination of manual, paper-based processes for the collection of identity data;

Compliance with acquisition guidance for PIV card products and services as a component

of acquisition assessments;

Adoption of standards-based, commercially available products and technologies in ICAM

modernization efforts;

Streamlining of provisioning and authentication services through enterprise capabilities;

and

Coordinated ICAM program management and investment across supporting projects.

In addition OMB Circular A-123 includes, as a control, separation of duties for various

functions. An enterprise Logical Access Control System (LACS) service can support this

required control by detecting the conflict and allowing the corrective action. Additionally, an

automated enterprise auditing capability across agency applications offers enhanced visibility to

more easily control access to systems and sensitive information. This capability could be used to

support evaluating compliance with policy and applicable law.

6.2.2. Capital Planning

The Clinger-Cohen Act of 199621

was enacted to improve the acquisition and management of

information resources by the Federal Government. It introduces a structured, integrated approach

to selecting and managing investments called Capital Planning and Investment Control (CPIC).

CPIC supports alignment of investments to the agency‟s mission and supports business needs

while reducing risks and increasing returns throughout the investment‟s life cycle. The CPIC

process as a whole integrates strategic planning, enterprise architecture (EA), privacy, security,

19 OMB Circular A-123, Management‟s Responsibility for Internal Control, December 21, 2004.

20 ICAM-specific evaluation criteria for use by agency Inspectors General are under development by the ICAMSC.

21 The Clinger-Cohen Act of 1996.

http://www.whitehouse.gov/omb/rewrite/circulars/a123/a123_rev.html

http://www.cio.gov/Documents/it_management_reform_act_feb_1996.html



budgeting, portfolio management, procurement, and acquisition management of capital assets.

The primary product of the CPIC process is the Exhibit 300, which is defined by OMB Circular

A-11. Exhibit 300‟s are constructed and reviewed on an annual basis for both new and existing

capital investments.

Traditionally, agencies have submitted separate Exhibit 300 investment requests for various

ICAM activities (e.g., HSPD-12, E-authentication). In future budget submissions, however,

agencies may consider coordinating their capital planning efforts closely across individual ICAM

projects and Exhibit 300 business cases. The goal of this coordination effort is to ensure

alignment throughout the organization to consolidate and/or eliminate redundant ICAM

investments across agency components/bureaus. This supports collaboration across ICAM

projects and systems and will improve visibility and accountability of the agency‟s spending on

ICAM-related investments. ICAM implementers will need to evaluate their agency‟s specific

needs to determine the appropriate and most cost efficient Exhibit 300 submission approach.

In addition to updating the agency‟s approach to its ICAM investments, agencies should also

work to incorporate ICAM requirements, such as the need to use the PIV card as the

authentication mechanism for employees accessing agency systems, into its CPIC and

investment request processes. This will require identifying key criteria for an investment to be

considered aligned with the ICAM target state, incorporating that criteria into CPIC processes

and guidance, and communicating any changes to the relevant stakeholders and CPIC process

participants.

Furthermore, collaboration between all relevant stakeholders during each phase of the CPIC

process is critical to ensure that the overlapping elements of different ICAM activities are

addressed. The following figure highlights several of the key ICAM considerations relevant to

each phase of the standard CPIC process.

CPIC

Phase Phase Objective ICAM Considerations

Pre-Select Assess the business needs and resource requirements for the investment.

Investment business plans should state use of the PIV card for authentication within the security planning.

Educate Investment Review Board on ICAM requirements.

Select Ensure the selection of investments that best supports the mission and approach.

Review investment for alignment with agency’s ICAM segment architecture relative to accounts, authentication, access control, and auditing capabilities.

Investment data architecture should be evaluated to guard against the redundant collection of identity data.

Control Take actions to ensure investments will deliver the projected benefits through quality control and executive review.

Ensure that investment is properly integrated and aligned with the agency’s ICAM infrastructure.

Oversee development of investment and integration with enterprise ICAM services.

Evaluate Evaluate and analyze if investments have delivered what was expected, while remaining cost effective.

Investment should document and demonstrate return on investment (ROI) realized through use of ICAM infrastructure security services.

Determine opportunities to improve efficiency and update investment as enterprise ICAM capabilities mature.

Figure 7: ICAM Considerations within the CPIC Process



As part of the FY11 budget submission cycle, OMB provided additional guidance to agencies

related to their ICAM programs and the use of PIV cards across all IT investments. The

following table summarizes this guidance.

Fiscal Year OMB Guidance

2010 Complete detailed transition plans documenting efforts to align with the FICAM Roadmap. Plans should address use of electronic capabilities of HSPD-12 credentials to improve the agency’s security posture.

All new (unclassified) logical and physical access control systems (PACS) must be enabled to accept HSPD-12 credentials for authenticating federal employees and contractors.

2011 Agencies must use Development, Modernization, and Enhancement (DME) and/or Operations and Maintenance (O&M) funding to upgrade existing PACS and LACS to use HSPD-12 credentials.

2012 Agencies shall not spend DME and/or O&M funding on systems unless they use HSPD-12 credentials.

Figure 8: OMB Budget Guidance

As a result of this guidance, agencies must implement use of the PIV card for authentication

within all IT systems (as defined in the ICAM target state architecture) in order to receive future

investment funding from OMB. This begins with new investments in FY10 and extends to

funding for existing investments in FY12. The guidance also requires agencies to begin detailed

planning for aligning their investments with the ICAM segment architecture.22

These

requirements are reinforced by OMB M-11-11,23

which provides guidance on the continued

implementation of HSPD-12.

Agencies need to incorporate planning for PIV-enablement and alignment with the ICAM

segment architecture when completing capital planning activities and preparing their budget

submissions. As part of its adoption into the Federal Enterprise Architecture, the ICAM segment

architecture was added and assigned a segment code in the Enterprise Architecture Segment

Report (EASR).24

Agencies must code relevant ICAM costs to the ICAM segment code and

report them as part of their budget submissions via the Exhibit 53. The following figure provides

a summary of multiple common ICAM-related cost categories, which an agency can leverage to

help determine and report their ICAM costs in an organized manner.

Cost Category Description

New User Identity

Proofing

Costs associated with proofing the identity of new users at the necessary level of assurance.

Integration Integration costs from contractor services and additional software/hardware required for integration and testing.

Software Cost of software including licenses and maintenance fees that could be decommissioned or redeployed across all environments for development, testing, and production.

PKI software Licensing costs for PKI software as well as vendor maintenance fees to support all environments for development, testing, and production.

22 The ICAM segment architecture (Part A of this document) has been adopted as part of the Federal Enterprise Architecture (FEA), as an agency requirement. The FEA Framework was created in response to Executive Order 13011, „Federal Information Technology.‟

23 OMB M-11-11, Continued Implementation of Homeland Security Presidential Directive (HSPD) 12-Policy for a Common Identification

Standard for Federal Employees and Contractors, February 3, 2011.

24 Enterprise Architecture Segment Report (EASR).

http://govinfo.library.unt.edu/npr/library/direct/orders/27aa.html

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




Cost Category Description

Help desk calls Costs associated with the number of password related calls received by an agency.

Hardware Cost of hardware that could be decommissioned or redeployed across all environments for development, testing, and production.

IT Operations Services Costs of backups, monitoring, new development, enhancements, etc across all environments for development, testing, and production.

Training Costs associated with training and creating/acquiring materials for new software and services installation, integration, maintenance, business processes, and end user support.

Policy Compliance Costs associated with bringing the system into compliance with applicable ICAM policies.

Figure 9: ICAM Cost Categories Summary25

6.2.3. Enterprise Architecture

In general, EA is a strategic management tool that helps organizations view the relationships

among missions, information, technology, and transitional processes through depictions of

current environments (termed “As-is”) and future environments (termed “Target”). Successful

EA enables an agency to maximize the contribution of its resources, IT investments, and system

development activities to achieve its performance goals. The Federal Enterprise Architecture

(FEA) provides broad guidance for explaining a common approach for EA development

applicable across the Federal Government. Department-specific architectures must map back to

the FEA to demonstrate alignment and allow for investment management across the entire

Federal Government enterprise.

The development of the ICAM segment architecture was accelerated in order to allow agencies

to incorporate the target state vision for federal ICAM, including the detailed initiative and

milestone activities, into the FY11 budget submission. Agencies must develop a work plan for

completing the transition activities and achieving the target state identified therein, as required

by OMB M-11-11.26

In addition, the ICAM segment architecture and the agency detailed work

plan should be thoroughly reviewed when determining which investments to submit for funding

through the annual budget cycle.

Many agencies have already taken steps to integrate the ICAM segment architecture into their

own agency EA programs. Such adoption of the ICAM segment architecture and its use in

requesting investment funding will help ensure that IT investments are aligned with the common

vision for ICAM and that agencies can begin taking steps to eliminate redundancies and realize

synergies between individual ICAM investments. Additionally, conformance with the ICAM

Segment Architecture will minimize the risk associated with an agency‟s IT security program.

6.2.4. IT Security and Risk Management

IT Security involves protecting the confidentiality, integrity and availability of information.

Agencies are required to perform a risk assessment on a system to determine the extent of

potential threats associated with it. Risk assessments assist agencies in determining the proper

security mechanisms for IT systems commensurate with their level of risk. According to NIST

25 Cost category information has been adapted from the Agency E-Authentication Cost Template

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




SP 800-30, “Risk management is the process that allows IT managers to balance the operational

and economic costs of protective measures and achieve gains in mission capability by protecting

the IT systems and data that support their organization‟s mission.”

Since ICAM includes the management of identity data, accounts, and access, it is intrinsically

linked to an agency‟s IT security program. As a result of this linkage, ICAM solutions are

capable of supporting innovative approaches for IT risk management, ICAM implementations

also offer the ability to support required IT system security controls using common services for

the entire organization, significantly streamlining the accreditation process. The following

subsections discuss, in greater detail, the ways in which ICAM systems impact and are impacted

by IT security and risk management processes.

6.2.4.1. IT Risk Management Framework

FAQ

What is the difference between the Certification and Accreditation (C&A) process and the Risk Management Framework (RMF)? The six-step RMF fundamentally transformed the previous C&A process to allow an organization to track the security state of an information system on an ongoing basis and maintain the security authorization for the system over time. The C&A process was not a processed, multi-step approach like the RMF life cycle process. This life cycle gives agencies the flexibility to alter, enhance, or reassess their security systems continuously and easily.

IT systems implemented as part of an agency‟s ICAM program must meet all relevant FISMA

requirements, including application of the IT Risk Management Framework (RMF) defined in

NIST SP 800-37.27

The RMF is a security life cycle approach that was designed to help agencies

build information security capabilities into their IT systems, better monitor the real-time security

status of those systems, and provide relevant information to agency leadership to enable risk-

based decisions associated with their operation. The RMF includes six steps, which an agency

must apply to its ICAM systems in order to select, implement, and evaluate the appropriate

system security controls and adequately monitor the efficacy of those controls to support

responsibility and accountability in the overall security of the system.

The six steps in the RMF life cycle are summarized in the following figure. The RMF framework

allows agencies to move from and between steps as needed and allocate resources to each step as

they deem appropriate; however, equal emphasis should be placed on each step.

Step Step Description Objectives

1 CATEGORIZE

Information System

Categorize information based on mission and business objectives of the agency

Describe each information system, including: full name with acronym, location of the system, version number, types of information held in the system, system owner, and other specific agency requirements

Register the information system within specified program offices

2 SELECT Security

Controls

Select the appropriate security controls for the information system and document the controls in the security plan

Develop a strategy and create a continuous monitoring strategy to control

27 NIST SP 800-37, Guide for Applying the Risk Management Framework to Federal Information Systems: A Security Life Cycle Approach, February 2010.

http://csrc.nist.gov/publications/nistpubs/800-37-rev1/sp800-37-rev1-final.pdf



Step Step Description Objectives

the effectiveness and any changes to the information system, such as assessment frequency

Review the proposed security controls; ensure that the security plan has identified any possible risk to the agency

3 IMPLEMENT Security

Controls

Implement security controls from the security plan (created in step 2)

Document the implementation of the security controls into the security plan

4 ASSESS Security

Controls

Create and approve an assessment plan of the security controls and make sure it follows the documented procedures in the security assessment plan

Document any problems or suggestions from the assessment in an assessment report and adjust appropriate security controls, if needed

5 AUTHORIZE

Information System

Create a plan of action based on findings from the security assessment report ; when completed, submit to the authorizing agency official for review

The authorizing official reviews and determines the risk to the organizational operations, such as mission or assets

6 MONITOR Security

Controls

Review and determine the security impact of any changes to the information system

Make updates to the security plan, security assessment report, and plan of actions as needed during the continuous monitoring process

Following the monitoring strategy set forth, report the security status on a continual basis

Figure 10: Summary of the Risk Management Framework

As an agency implements ICAM, many other IT risk requirements and controls are achieved. For

example, the final step in the IT RMF is monitoring security controls. Several of the enterprise

services provided by ICAM (see Services Framework in Section 3.2.4), including automated

auditing and reporting, can be used to implement an agency‟s continuous monitoring capability.

These services provide a common control across an agency‟s IT system, which in turn supports

the RMF objective of leveraging inherited common controls to the maximum extent possible.

This allows an agency to increase the consistency, effectiveness, and timeliness of security

control implementation within its IT security program.

Terminology

Continuous monitoring – One of six steps in the Risk Management Framework (RMF)

described in NIST SP 800‐37. The objective of a continuous monitoring program is to determine if the complete set of planned, required, and deployed security controls within an information system or inherited by the system continue to be effective over time in light of the inevitable changes that occur.

Due to the privacy, data security, and trust concerns associated with the credentials and

information processed by PIV credential systems, HSPD-12 applications are subject to additional

unique accreditation requirements in addition to the requirements placed on all IT systems. For

example, PIV Card Issuers (PCI) are subject to additional assessment of security control

requirements to establish and maintain a known level of trust in the credential issuing processes,

so that trust can be extended to the authenticity of the credential. The PIV card specific

requirements are found in NIST SP 800-79,28

including:

28 NIST SP 800-79-1, Guidelines for the Accreditation of Personal Identity Verification Card Issuers, June 2008.

http://csrc.nist.gov/publications/nistpubs/800-79-1/SP800-79-1.pdf



Organizational Preparedness. Relates to the overall level of engagement of senior

management regarding the formation and operation of the PCI. Roles and responsibilities

must be clearly identified, and policies and procedures must be defined, documented, and

put in place.

Security Management & Data Protection. Concerns the provisioning of adequate

measures (e.g., management procedures, operational controls, technical protections) to

ensure that privacy requirements are addressed, the rights of individuals are

acknowledged, and personal data are protected.

Infrastructure Elements. Represents the sum of the activities required to procure,

deploy, and maintain the PCI information system components. PCI information system

components (e.g., PKI, biometrics, and card production) must meet the technical

specifications defined in FIPS 201 and related documents. Additionally, information

systems used within the PCI need to be assessed and authorized under SP 800-37 for

FISMA compliance.

Processes. Classes of functions that collectively span the entire PIV card lifecycle

activities such as sponsorship, enrollment/identity proofing, adjudication, card

production, card activation/issuance and maintenance.

Advancements in PACS technologies, the emergence of enterprise models for PACS, and

increasing interconnectivity with agency networks have highlighted the fact that PACS are

comprised of components from both physical security and information systems. As such, they

are subject to the RMF process and conformance with the security controls applicable to

information systems.

6.2.4.2. Security Controls

The RMF provides the process for selecting, implementing, assessing, and monitoring security

controls. An agency must incorporate considerations for these controls throughout the life cycles

of IT systems supporting its ICAM program. Additionally, many of the control families

identified in SP 800-5329

incorporate ICAM in their execution. Due to this interrelationship, an

ICAM implementation contributes to the FISMA compliance of a wide variety of IT systems.

This impact affects both the FISMA reporting process and the security of every application that

the ICAM solution interacts with. Figure 11 below describes the key NIST SP 800-53 control

families that are related to and impacted by ICAM implementations:

Control Family Description Relationship to ICAM

Access Control

(AC)

Controls falling under the AC category ensure that proper restrictions are in place to limit access to authorized users with a need to know.

IT resources use the ICAM program as their primary means of access control.

ICAM strengthens access control methods through the use of centralized account management, role-based access control, etc.

Audit and

Accountability

(AU)

Controls falling under the AU category ensure that applications properly record and review records of specific user actions.

ICAM presents agency implementers the opportunity to eliminate redundancy and increase accountability across the enterprise by centralizing audit capabilities within the ICAM.

Centralized audit capabilities enable the recording of actions at the user level for all IT

29 NIST SP 800-53, Recommended Security Controls for Federal Information Systems and Organizations, August 2009.

http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final_updated-errata_05-01-2010.pdf



Control Family Description Relationship to ICAM

resources that interact with the ICAM solution.

The redundancy from having all IT resources maintain separate audit logs is reduced.

Security is increased by providing a broader, centralized view of user actions across multiple applications.

ICAM implementers should determine an agency’s individual audit requirements and design ICAM audit capabilities to meet these individual needs.

Security

Assessment and

Authorization

(CA)

Controls falling under the CA are in place to ensure that an agency has the necessary processes in place to monitor the needed security controls.

ICAM implementers need to meet annual FISMA CA requirements.

ICAM implementers can leverage the parent control system interface connections to enable identity data sharing.

Identification and

Authentication

(IA)

IA controls are in place to ensure that users and devices are properly authenticated prior to allowing access to an IT resource.

ICAM implementations will simplify compliance with IA controls for all applications as agencies standardize on the PIV credential for internal users.

ICAM implementations will simplify compliance with IA controls as agencies enhance security and trust in authentications by incorporating electronic identification techniques.

Physical and

Environmental

Protection (PE)

Controls falling under the PE family are in place to ensure that an agency and its applications have proper processes and technology in place to prevent intrusion and damage to the physical environment (buildings, secured rooms, etc.), provide emergency resources, and monitor physical access of personnel and visitors.

The authentication support provided by ICAM implementations mentioned in the IA control family applies equally to authenticating people to a physical environment.

Risk Assessment

(RA)

Controls falling under the RA family are in place to ensure that an agency has the proper processes in place to adhere to their risk policies and adjust as risks change.

ICAM implementers should formally document their risk assessment polices and coordinate among components within the agency.

ICAM implementers should regularly review and update their current risk assessments.

Figure 11: NIST SP 800-53 Control Families and Relation to ICAM

In addition to the specific control families mentioned above there are numerous other security

controls that are interrelated with identity management. ICAM solutions have the potential to

provide the means to execute many of these controls when properly designed. Involving security

personnel throughout the ICAM implementation planning and design phases will not only impact

the security of the ICAM solution itself, but also opens up the opportunity to support the

agency‟s overall security mission.

6.3. Privacy Considerations

ICAM programs have significant privacy implications for federal agencies and must be treated

accordingly. These implications must be carefully considered by agencies to mitigate potential

privacy risks, while still providing the security intended for the identity management systems

(IDMS). Therefore, privacy should be considered a core component and mission critical



objective for all ICAM implementations and agency implementers should understand and

integrate privacy principles into ICAM programs early in the design stage. This section

introduces the Fair Information Practice Principles (FIPPs) and discusses how they can be

appropriately integrated into an agency‟s ICAM program.

6.3.1. Applying the FIPPs

Since ICAM programs involve the collecting, storing, sharing, and maintenance of personally

identifiable information (PII), federal agencies must implement solutions that actively support

privacy protections and the widely-recognized FIPPs. Under the Privacy Act, which is based on

the FIPPs, agencies are required to have certain processes and procedures governing their use of

PII in place. Agencies should first assess those processes and procedures and determine whether

the implementation of an ICAM program constitutes a new use of PII that requires adjustment of

existing processes and procedures. The following figure provides a description of each of the

FIPPs and discusses practical implementation considerations for applying them within an ICAM

program.

Fair Information

Practice Principle Description ICAM Implementation Considerations

Individual

Participation

Agencies should involve the individual in the process of using PII and, to the extent practicable, seek individual consent for the collection, use, dissemination, and maintenance of PII. Organizations should also provide mechanisms for appropriate access, correction, and redress regarding use of PII.

Agencies that currently interact with the public in a face-to-face context and/or engage in paper/telephone transactions must recognize that there will continue to be individuals who will not feel comfortable adopting technological processes. They should continue to offer physical alternatives for processes that are not inherently technology-based.

Agencies should also provide redress mechanisms in accordance with the Privacy Act that allow individuals to report and correct information that is inaccurate, lost, or compromised and damages resulting from incorrect authentication or unauthorized access. Redress mechanisms help enhance confidence in the program and promote individual participation.

Transparency Agencies should be transparent with respect to the information they collect and share, and provide notice to the individual regarding collection, use, dissemination, and maintenance of PII.

A foundational principle in federal privacy law is that an individual has the right to know what information the government collects and retains about him and, to a great extent, the right to control how that information is being used. When building ICAM programs, agencies should, first and foremost, consider this principle and ensure the following prior to each occurrence of information collection and/or transmission:

The user is clearly informed what information elements will be collected

The user understands who will receive the information

The user is clearly informed of how the information will be used

The user must affirmatively choose to participate before any information is transmitted

Purpose

Specification

Agencies should specifically articulate the authority that permits the collection of PII and specifically articulate the purpose or purposes for which the PII is intended to be used.

Data Minimization Agencies should only collect PII that is directly relevant and necessary to accomplish the specified purpose(s) and only retain PII for as long as is necessary to fulfill the specified

Agencies should only collect the information necessary to carry out ICAM business functions. Wherever possible, agencies should use assertions of an individual’s identity in lieu of identifying data elements. For example, if an application has an age limitation, the program should ask for proof of age rather than the



Fair Information

Practice Principle Description ICAM Implementation Considerations

purpose(s). exact birth date. Agencies should also determine how long specific categories of information associated with ICAM processes will be retained and implement procedures for destruction of the information at the end of the retention period.

Use Limitation Agencies should use PII solely for the purpose(s) specified in the notice. Sharing PII should be for a purpose compatible with the purpose for which the PII was collected.

The Privacy Act generally requires that once an individual consents to the collection of his information for a specific, stated purpose, that information can only be used for that purpose. This is particularly important to remember when considering the sharing of information between programs. If the programs have different purposes, such sharing will likely not be permissible without additional consent from the user. Agencies should carefully consider this limitation when crafting their privacy notices for ICAM programs.

Security Agencies should protect PII (in all media) through appropriate security safeguards against risks such as loss, unauthorized access or use, destruction, modification, or unintended or inappropriate disclosure.

Agencies must ensure the security of information at all stages (collection, transmission, storage, and destruction) in accordance with various legal and policy requirements (e.g., FISMA and OMB M-07-16).

Examples of techniques for securing data are encryption, strong authentication procedures, time out functionality, and minimum security controls to make information unusable by unauthorized individuals.

Data Quality and

Integrity

Agencies should, to the extent practicable, ensure that PII is accurate, relevant, timely, and complete.

Agencies should identify and implement means to ensure that PII is accurate, relevant, timely, and complete, including providing mechanisms for individuals to correct inaccuracies in their information.

Accountability and

Auditing

Agencies should be accountable for complying with these principles, providing training to all employees and contractors who use PII, and auditing the actual use of PII to demonstrate compliance with these principles and all applicable privacy protection requirements.

ICAM implementers should establish accountability measures to ensure that each of the other FIPPs is appropriately applied and effectively protect users’ privacy. Such measures can include ICAM program audits and reviews by agency privacy and security officials. Agencies should address accountability for specific requirements, such as the OMB M-07-16 requirement for annual certification of training for employees who handle PII. Clear accountability will promote confidence in ICAM programs.

Figure 12: Applying the FIPPs to ICAM

Adopting the FIPPs to support privacy-protecting ICAM solutions requires deliberate effort. One

example of such an effort is the development of the privacy requirements of the Trust

Framework Provider Adoption Process (TFPAP), ,which aims to enable the Federal Government

to leverage industry-based credentials that citizens already have for other purposes. In order for an

external entity to be certified to provide credentials for use by the Federal Government, it must

demonstrate compliance with a rigorous set of privacy requirements built around the FIPPs. This

topic is discussed in greater detail in Chapter 12.

6.3.2. Programmatic Support

All programs that collect, retain, or use personal information are required to complete and

maintain program documents to support these activities. Such processes for determining policies

and rules around collection and use of information ensure that agencies are not creating an

unnecessary burden on individuals; nor are they collecting or using information for purposes that



are not consistent with the intent of the program. Agencies should be extremely clear and

thorough when developing the documentation to support the collection, use, and retention of

personal information. Below are processes that agencies must complete in order to meet key

privacy requirements:

System of Records Notice (SORN). A notice published by an agency in the Federal

Register to notify the public of a system of record, a group of any records under the

control of any agency from which information is retrieved by the name of an individual

or by some identifying number, symbol, or other identifier assigned to the individual. The

SORN includes basic information about the system, including system name, categories of

individuals covered by the system, and categories of records in the system and addresses

the policies and practices for storing, retrieving, accessing, retaining, and disposing of

records in the system.

Privacy Impact Assessment (PIA). The process used to evaluate the potential

ramifications to the protection of privacy within IT systems. The resulting document

includes information related to the data in the system, access to the data, attributes of the

data, and maintenance of administrative controls for protecting it..An agency must

complete a PIA whenever a new system is being introduced or an existing system is

substantially modified.

Establishment of redress procedures. Procedures to allow an individual to review his

record in an IT system upon request and permit the individual to request amendment of a

record pertaining to him. In addition to enabling an agency to meet the requirements of

the Privacy Act of 1974, redress procedures also help enhance transparency, raise the

awareness of the mission, and promote user confidence.

Privacy Tip

It is encouraged that ICAM implementers provide redress mechanisms even when not required by the Privacy Act. Enabling users to file complaints and comments regarding an ICAM program and rectify this if their information is inaccurate, lost, or compromised will promote confidence in their interaction with the government.



7. Initiative 5: Streamline Collection and Sharing of Digital

Identity Data

This chapter is currently under development as part of Phase 2 of the Implementation Guidance

development effort. It will be included in Version 2.0 of the FICAM Roadmap and

Implementation Guidance, currently scheduled for publication on or around June 24, 2011.



8. Initiative 6: Fully Leverage PIV and PIV-I Credentials






9. Access Control Convergence

Physical and logical access control are intended to allow entry to or use of resources to

authorized users and entities based on an established set of rules that define appropriate access

permissions. Access control convergence refers to the common processes and technologies that

enable both physical and logical access control. As described in the target state of the ICAM

segment architecture, agencies should be moving toward providing access control services at the

enterprise level, which in turn necessitates the convergence of many physical and logical access

management activities and business processes. Enabling enterprise access control requires

management of information about the resources being protected, the users attempting to access

those resources, and the policies governing access control decisions. Improvement in these

process areas, as discussed in the following subsections, supports achievement of the target state

and enables more effective interoperability and information sharing.

Chapters 10 and 11, which address the modernization of PACS and LACS respectively, address

specific implementation considerations for many of the topics discussed throughout this chapter

in the context of the technical solutions and systems.

9.1. Resource Attribute Management

Resource Attribute/Metadata Management, as defined in the ICAM Services Framework, is the

process for establishing and maintaining data (such as rules for access, credential requirements,

etc.) for a resource/asset. This data defines the access, protection, and handling controls for a

resource. Resources may be both physical (campus sites, buildings, individual offices/areas, etc.)

or logical (IT applications, data, services, etc.). The information and guidance presented in this

section is intended to assist agencies in providing answers to several common resource

management questions, including:

Where might I find information about the resources within my agency that must be

protected?

Where can I find lists of these resources and information about them?

How can resources be organized or grouped to streamline access control for users that

require access to a set of common resources?

FAQ

Isn’t resource management the management of supplies, hardware, software, and other personal property?

No, not in the context of ICAM. Agencies are responsible for managing numerous types of resources, assets, and property under their custody. Within the context of ICAM, however, resource management refers specifically to managing information about resources that require access control. Some agencies also call this process asset management.

9.1.1. Resource Discovery and Inventory

When implementing access control solutions, many agencies find it challenging to determine a

complete inventory of the resources that need to be protected (both physical and logical) because

the processes to identify, track, and catalog resources are distributed across multiple programs

and systems. Each program or system typically collects and manages information about a subset



of the agency‟s resources in order to support a specific business function. For example, agencies

are required under FISMA to have a complete, current inventory of IT systems. ICAM

implementers must be able to retrieve information about these resources quickly and efficiently

in order to effectively manage access to them in a coordinated fashion. Additionally, physical

and logical resources typically are managed separately from each other within an agency.

Terminology

Metadata – Structured information that describes, explains, locates, or otherwise makes it easier to retrieve, use, or manage an information resource. Metadata is often called data about data or information about information.

30

Physical and logical access control systems often rely on metadata to accurately and reliably grant user access to protected resources.

Per a

For many existing resources, an agency should likely have already determined which resources

require protection and the level of protection (LOP) required. Information systems, devices, and

infrastructure protection requirements are outlined in existing policy guidance,31

and are the

responsibility of the resource owner to determine. Guidance for determining levels of protection

for facilities and work sites which require electronic security systems is provided by the

Interagency Security Committee (ISC). 32

It can be expected that an agency‟s physical security

group will have previously evaluated all existing facilities and sites within the agency‟s custody

and determined physical protection requirements, however, for geographically dispersed

organizations, this information may be managed locally. Figure 13 discusses several common

programs and functions that collect and manage this information, and may therefore provide a

starting point for ICAM implementers.

Agency Function Information Available Resource Type

Facility Management Group / Physical Security Group

Information regarding resources that must be secured using PACS.

Physical

Real Property Group Information regarding land, building, and improvements that are owned or leased by a federal agency.

Physical

Capital Planning and Investment Control (CPIC) Program

Investment information for capital assets submitted by a federal agency to OMB for funding.

Physical

Logical

Helpdesk/Trouble Ticket Solutions and Records

Often contain lists of resources and/or targets of privilege/access management requests, as they are frequently sources of problems and issues for users.

Physical

Logical

Enterprise Data Warehouse (EDW)

EA repository of electronically stored data about an organization’s resources and data, commonly maintained to facilitate reporting and analysis.

Physical

Logical

Information Resources Catalog (IRC)

Some agencies may have an existing IRC, which is a comprehensive catalog of resources and resource information.

Physical

Logical

IT System Inventory Inventory of IT applications and security compliance and reporting information.

Logical

30 Understanding Metadata, National Information Standards Organization (NISO), 2004.

31 OMB M-04-04, E-Authentication Guidance for Federal Agencies, Office of Management and Budget, December 23, 2003.

FIPS 199, Standards for Security Categorization of Federal Information and Information Systems, February 2004.

OMB Memorandum M-06-16, Protection of Sensitive Agency Information, July 2006.

32 ISC Physical Security Criteria for Federal Facilities, The Interagency Security Committee, 2010.

http://www.whitehouse.gov/sites/default/files/omb/memoranda/fy04/m04-04.pdf

http://csrc.nist.gov/publications/fips/fips199/FIPS-PUB-199-final.pdf




Agency Function Information Available Resource Type

Change Control Board (CCB) and/or Change Management System

Maintains the software, hardware, and application baselines for resources within the enterprise as a means of supporting change/upgrade efforts.

Logical

Figure 13: Resource Information Sources

Developing a comprehensive view of all agency resources (physical and logical) is reliant upon

locating and reconciling existing sources of information. Several agencies have taken steps to

create consolidated resource tracking solutions for the purpose of gathering the information

necessary to make informed access management decisions in a timely manner. While this is not a

requirement of ICAM, it is an example of a centralized repository of resource information to help

ICAM implementers streamline the development and deployment process.

Implementation Tip

Don’t wait until a complete agency inventory is in an automated system to begin developing access policies and tying resources into enterprise access control capabilities. Developing a complete inventory is a time-consuming process, and efficiency benefits and return on investment (ROI) can be realized by integrating even a small number of resources with automated ICAM capabilities once a representative sampling of major resource types has been identified.

9.1.2. Collecting and Organizing Resource Information

Collecting, analyzing, and understanding the information about a resource that leads to

determining the necessary LOP is critical to establishing effective access control policies. A core

component in determining access control policy is a resource‟s risk profile. Risk profiles are

indicators of the potential impact on the organization in terms of the loss of confidentiality,

integrity, or availability for logical assets, and the impact of loss due to specific vulnerabilities

for physical assets. Risk assessments are commonly performed for many agency resources as

part of existing security compliance processes. Risk assessments for physical resources are

governed by the Facility Risk Assessment process, outlined in the ISC‟s Physical Security

Criteria for Federal Facilities, which is discussed further in Chapter 10. Risk assessments for

logical resources are governed by the FISMA process (for overall security risk) OMB M-04-0433

(for authentication risk). The resulting risk profiles can be leveraged for access control purposes

without creating an additional burden for resource owners.

Risk profiles provide ICAM implementers with a baseline from which to determine core access

control requirements. However, additional information about a resource can be used to develop

more granular access controls to further increase the security and realize the efficiencies that can

be obtained through deployment of access control systems.

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




FAQ

Are there any tools available to help determine the level of authentication risk associated with my information systems?

Yes, the eAuthentication Risk and Requirements Assessment (e-RA) tool can be leveraged to assist in determining logical access control risks and appropriate levels of assurance, as defined in OMB M-04-04. e-RA is available on the Federal Government’s identity management website.

34 Additional guidance for conducting overall security risk

assessments is provided in FIPS 199.35

Contextual information about a resource is often required to support access control decisions.

This information can often be obtained by reviewing resource documentation and meeting with

resource owners/administrators to discuss how and why access is currently controlled. Chapter

11 also introduces the process for conducting Application Assessments, a best practice for

supporting the integration of applications with Logical Access Control Systems (LACS), which

can serve as an additional means for gathering contextual information about logical resources.

Examples of contextual information that can be used to support access control are provided in

Figure 14.

Information Component Description

Time-based access restriction Access to the resource is restricted during particular hours or certain times of the day, week, or year based upon resource requirements.

Certification-based access restriction

Access to the resource requires possession of a particular certification or permit.

Organizational affiliation restriction Resource access requires a particular affiliation with the organization (e.g., IT systems for federal employee access only), or affiliation with a particular bureau/component/office, etc.

Location-based restriction Access to the resource is restricted based on geographical location for both physical and logical resources, and/or IP and MAC location for IT resources and data.

Resource-based restriction Access to certain data or information is dependent upon it being accessed through a particular resource, thereby preventing direct access.

Data sensitivity restriction Certain IT resources or data elements may require that users possess a level of public trust or clearance (NACI, Public Trust, Secret, etc.) before being accessed.

Figure 14: Sample Resource Information Components

The examples in Figure 14 are not intended to be comprehensive; however, they can be used to

help implementers as they begin considering the additional information about a resource that is

needed to develop access control policies. They also help define the types of entitlement

information that an agency might need about its users in order to support access control

decisions, discussed further in Section 9.2.1. Developing access control policies is a multi-step

process to determine what access controls can be employed to improve security and create added

value for the organization. The steps involved in developing robust access control policies are

discussed in greater detail in Section 9.3.2.

Resources can be grouped based on common criteria as a means of providing baseline privileges

in an automated fashion. This is accomplished by examining the resource attributes, such as the

examples provided in Figure 14, that determine how users are granted access and looking for

34 GSA eAuthentication Risk and Requirements Assessment (e-RA).

35 FIPPS 199, Standards for Security Categorization of Federal Information and Information Systems, February 2004.

http://www.idmanagement.gov/drilldown.cfm?action=era

http://csrc.nist.gov/publications/fips/fips199/FIPS-PUB-199-final.pdf



similarities that drive access control decisions. Resources may be grouped in several ways,

including:

Physical Location. Many agencies with multiple offices/buildings in metropolitan areas

often grant access to all facilities within that area as a means of ensuring that personnel

can easily attend meetings in nearby offices, this may also extend to network/system

access associated with a geographic location.

Project/Program Affiliation. Projects or programs that rely on a small subset of

information systems or specified work locations can group those resources and grant

access based upon affiliation with the project or program rather than granting each person

access to each individual resource.

Organizational Relationship. Within an agency there may be components or bureaus

that grant access to resources based upon organizational affiliation (i.e., a

component/bureau specific information sharing tool).

Function/Purpose. Similar to Project/Program affiliation, certain resources may support

a common function or purpose within an organization (i.e., HR systems, accounting

systems, etc.).

In order to manage access control an agency must manage information about the individuals and

entities attempting to access its resources. The processes for supporting this are discussed in the

following section.

9.2. Privilege Management

Terminology

Privilege Management – A set of processes for establishing and maintaining the entitlement or privilege attributes that comprise an individual’s access profile. These attributes are features of an individual that can be used as the basis for determining access decisions to both physical and logical resources.

There are several other commonly used definitions of privilege management that include definition of access policies or even real-time execution of access control. These concepts are included in the ICAM Services Framework

36 as “Authorization and Access”

services and are addressed in this chapter.

Privilege management, as defined in the ICAM segment architecture, refers to a set of processes

for establishing and maintaining the entitlement or privilege attributes that comprise an

individual‟s access profile. Privilege management supports updates to privileges over time as an

individual‟s access needs change. Entitlement attributes are features of an individual that are

used as the basis for determining access decisions to both physical and logical resources. The

authorization decision relies on the presence or absence of one or more specific entitlement

attributes. Across the Federal Government, access privileges are managed using an array of

disparate processes and systems. Often, information about a person or entity is collected and

stored numerous times in multiple locations and managed by administrators at a local resource

level. This approach places a significant burden on local administrators to maintain user data,

and often leads to considerable security risks in the form of orphaned accounts and inappropriate

access based on out-of-date entitlement information.

36 The ICAM Services Framework can be found in Section 3.2.4.



Agencies should begin working to streamline and secure their existing privilege management

processes by mapping and correlating entitlement attributes based upon common resource access

needs and automatically provisioning37

these attributes from authoritative sources to the

appropriate resources. This section discusses the impacts of the ICAM segment architecture on

traditional privilege management processes and introduces the automated provisioning capability

that is outlined in the target state. Additionally, this section seeks to answer several common

privilege management questions, including:

What steps and activities are involved in managing privileges throughout the access

management lifecycle?

How can privilege management processes be improved by correlating similar information

and access needs into defined roles?

What does the automated provisioning capability do and what benefits does this approach

provide over current techniques?

9.2.1. Entitlement Attributes

Attributes about an individual can be broken down into two primary categories for the purposes

of access control, identity attributes and entitlement attributes. Identity attributes are

characteristics about a person that make it possible to uniquely identify them as an individual.

The creation, management, and use of identity attributes are discussed in great detail in Chapter

7. Entitlement attributes are those characteristics about an individual that are used to determine

access privileges. Privileges, when combined with access control policies and resource access

rules, are used to make intelligent access control (authorization) decisions.

Currently, entitlement attributes are obtained through a variety of user-reported paper-based and

technology-based workflows at a local resource level within federal agencies. This often results

in duplicative data collection and creates inefficiencies in which individual resource owners or

administrators are responsible for ensuring the accuracy and validity of each user‟s entitlement

attributes. The ICAM target state advocates minimizing the duplicative collection of this

information by automatically populating existing attribute data from authoritative sources within

the organization. Authoritative sources are typically repositories where there is an existing

business purpose for information to be regularly updated to ensure that the data is accurate,

current, and valid.

Implementation Tip

Defining the most commonly used entitlement attributes across multiple resources within your agency and automating sharing and use of this information will yield near term benefits while you continue to work on identifying additional attributes and making them available for sharing.

Generally speaking, there are several common categories of information about an individual used

to make decisions regarding access privileges, including38

:

37 Target state ICAM provisioning capabilities are discussed in detail in Use Case 7, Section 4.7.2 of Part A. Achievement of the ICAM target

state is discussed in Section 9.2.3.

38 The descriptions in this section are adapted from Defining User Attributes for Authority-Based Access Control, Waterman, K. Krasnow and Patricia K. Hammar, May 15, 2007.

http://colab.cim3.net/file/work/SICoP/DoDCoI/KWaterman05152007.pdf



Employer Details – information about an individual‟s employer and employment

affiliation, which defines how an individual is “mapped” within the organization. For

internal users, this would likely include the bureau/component or even the division an

individual supports, as well as the employee type (e.g., permanent, contractor, volunteer).

For external users, this could include employer name and other relevant designations tied

to a particular partner/customer organization.

Location – information related to the physical location of the individual. This typically

includes regional designation, city or metropolitan area, and facility/site assignments.

Location information can note an individual‟s permanent work location or temporary

travel or detail assignments.

Job Duties – information regarding an individual‟s job designation and responsibilities.

These attributes help define the resources, data, and sites that an individual requires

access to in order to carry out his job. For federal employees, this includes common

occupational series and job classification descriptions. This also includes job-related

authorities, such as management level, direct reports, and approval authorities.

Special Qualifications – information about special designations, skills, or certifications

an individual possesses. This includes security clearances, certifications/licenses,

education, etc. These attributes are related less to an individual‟s mapping and

responsibilities within the organization and more to a special skill or prerequisite

condition for access to restricted resources, sites, or data.

ROI

By managing access control using up-to-date entitlement attributes provided through an enterprise privilege management service, agencies can achieve process efficiencies and enhance overall security. These technologies are capable of rapidly granting or revoking access based upon changes to a user’s entitlement attributes, the operational environment, and established access control policies. This reduces the administrative burden associated with manually managing access control and eliminates the vulnerabilities associated with unnecessary user access.

Within each of the above categories there are a variety of entitlement attributes that can be used

to support access control decisions. Each attribute provides a unique piece of information about

the individual, which, when combined with information about a resource, is capable of

supporting a more granular level of authorization than is generally possible in most current

systems. Entitlement attributes can be organized in a variety of ways, several of which are

discussed in Section 9.3.1, for the purpose of streamlining the access control process. Most often,

collections of certain entitlement attributes are combined to develop access roles. Individuals in a

particular role share similar information needs and as a result they likely share similar

entitlement attributes. Use of roles or similar attribute groupings significantly reduces the

complexity involved in managing user privileges. User roles are further discussed in Section

9.3.2.

9.2.2. Privilege Management Lifecycle

As previously discussed, privileges must be defined and managed over time to ensure that access

decisions are based upon the most accurate and up-to-date information available. An individual‟s

entitlement attributes must be refreshed periodically to reflect job/role changes, updated

certifications, temporary assignments, etc. This section introduces a multi-stage privilege

management lifecycle, which has been designed to help agencies fill this need. The activities



discussed in Figure 15 should be tailored to suit the unique needs of an agency based upon

existing business processes and technical architecture.

Lifecycle Phase Description Common Activities

Attribute Definition Examining source systems to determine available entitlement attributes and select those that are necessary to determine access privileges.

Identify attribute stores

Determine if stores are authoritative

Examine available entitlement attributes

Select attributes necessary to enable access control

Provision Access Create user access accounts and assign access privileges associated with selected agency resources.

Provision user access to protected resources

Automate provisioning

Periodic Review Implement mandatory control mechanisms to re-validate access levels and modify entitlements at regular intervals. Access privileges may require adjustment based on promotions, job changes, role changes, situational variations, etc.

Establish periodic review criteria

Assess existing access privileges

Modify privileges as necessary (revoke access if not required)

De-provision Access Removal of user access privileges to resources when access is no longer required to complete job duties or when the individual leaves the organization.

De-provision user access rights from protected resources

Remove user from authoritative sources (if leaving the organization)

Retain and archive access records for de-provisioned users, if applicable

Figure 15: Privilege Management Lifecycle

At a general level, each of the phases described above is essential to ensuring that privileges are

managed consistently and accurately across the organization. Attributes should be defined and

leveraged from existing authoritative sources to eliminate redundant collection and use at a local

resource level. In order to maintain the integrity of the privilege management system, user

privileges need to be periodically re-validated to accommodate changes to an individual‟s access

requirements. Re-validation along with de-provisioning helps eliminate orphaned accounts

within resources and prevents individuals from having access to resources that are not required to

complete their job duties.

9.2.3. Automated Provisioning Capability

As defined in the ICAM Services Framework, Section 3.2.4.3, provisioning is the process of

creating user access accounts and assigning privileges or entitlements within the scope of a

defined process or interaction. Provisioning provides users with access rights to applications and

other resources that may be available in an environment, and may include the creation,

modification, deletion, suspension, or restoration of a defined set of access privileges.

Provisioning, as referred to in this document, includes the process for permanently removing an

individual‟s access to particular agency resources when it is no longer required to perform job

functions. This process is often referred to as de-provisioning.



Terminology

Orphaned Account – An account belonging to a user that has left the organization or no longer requires access to the resource. Orphaned accounts are most often the result of ineffective de-provisioning processes wherein user access privileges are not removed immediately upon a user leaving the organization. These accounts create security vulnerabilities, which may be exploited by individuals seeking to do harm.

In the current environment, provisioning to PACS differs slightly from provisioning user

privileges to other IT systems. Currently, automated provisioning capabilities that are integrated

with PACS solutions typically provision user identity data for the purpose of establishing a user

account, while entitlement privileges (e.g., access to specific sites or doors) are managed and

controlled within the PACS solution itself. In the ICAM target state, however, agencies should

develop automated provisioning capabilities that enable the provisioning of desired baseline

physical access privileges to the PACS solution.

Throughout the majority of the Federal Government, provisioning is currently performed via an

array of manual processes that create new instantiations of a user‟s identity within each resource,

often employing paper-based approval workflows. This heavily manual process greatly reduces

the ability to remove access when it is no longer needed (de-provision), in a timely fashion. This

arrangement creates a great administrative burden for local resource owners and administrators,

and is labor and time intensive. Additionally, the inability to efficiently and rapidly revoke

access can inadvertently allow users to retain access to information or sites unnecessarily, or

result in the existence of orphaned accounts. The target state ICAM segment architecture

proposes the use of automated provisioning capabilities as a means of reducing redundant

collection and use of digital identity data and streamlining the process of pairing identities and

resources.

ROI

The National Aeronautics and Space Administration (NASA) performed an analysis of its logical resources to determine what basic resource entitlements should be granted to new users. A provisioning capability was deployed to automatically grant new users access privileges to these resources immediately upon record finalization by HR. This has resulted in significant administrative and time savings for resource owners and allowed new users to gain access to resources immediately upon beginning employment.

Automated provisioning tools leverage existing, authoritative sources of digital identity data to

automatically link those identities to agency resources based on an analysis of the entitlement

privileges. This capability standardizes the provisioning process across an organization for all

protected resources. Figure 16 illustrates the numerous efficiencies that can be achieved by

deploying an enterprise-wide automating provisioning capability.

Benefit Category Example Benefits

User Experience

Reduced manual account linking

Automated account linking and reconciliation

Elimination of per-application paper-based workflow

Access provisioning when required by role

Reduced sign-on to non-web based applications

Faster access to resources

Operational Efficiency Streamlined provisioning of accounts for new users

Ability to establish foundational provisioning capabilities



Benefit Category Example Benefits

Reduction in per application account administration

Automated reconciliation response workflow

Attribute synchronization

Business friendly workflow for approvers and/or administrators

Security

Ability to easily automate detection, reporting, and response to orphaned accounts

Ability to detect and resolve excessive access privileges across multiple resources

Elimination of custom account linking code

Ability to centralize audit and access reporting

Standardized provisioning

Ability to digitally sign access approvals

Automation and enforcement of enterprise ID

Visibility into PII reduced based on business and job requirements

Centralized preventative policy enforcement

Figure 16: Benefits of Employing Automating Provisioning Capabilities

An effective provisioning framework has a strong foundation comprised of standardized, easily

deployable, and repeatable approaches that simplify processes, eliminate infrastructure

stovepipes, and streamline access control within agencies. Provisioning capabilities should be

tightly integrated with an agency‟s overall ICAM architecture and remain flexible enough to

accommodate resource-specific approval processes.

Privacy Tip

Using technology to automate manual paper-based provisioning processes does not eliminate the privacy requirements associated with the manual process. Privacy protections, such as approvals from required personnel, must be embedded into new electronic applications or processes that are replacing a paper format (e.g., a paper request form), in order to prevent additional privacy risk. Agencies should build these protections into the automated workflow from the initial design.

9.2.3.1. Common Design Characteristics

In order to successfully build and deploy an automated provisioning capability, as defined in the

target state ICAM segment architecture, it is necessary to understand the common characteristics

that the solution should include in order to meet the objectives of the ICAM target state. These

common characteristics are identified in Figure 17; however it is also important for agencies to

consider their specific needs when designing a provisioning tool.

Characteristic

ID

Automated Provisioning Characteristics

Provisioning 1 The automated provisioning service includes resource requirements for creating a valid resource user account.

Provisioning 2 The automated provisioning service includes network configuration requirements between provisioning component and resource user store.

Provisioning 3 The automated provisioning service includes workflows for provisioning resource accounts (including accounts for PACS solutions).

Provisioning 4 The automated provisioning service includes forms for requesting access to a protected resource (including physical sites, buildings, rooms, etc.).

Provisioning 5 The automated provisioning service includes approvals required for granting authorization to protected resources.



Characteristic

ID

Automated Provisioning Characteristics

Provisioning 6 The automated provisioning service includes requirements for how the identity management component will create / modify / delete authorization.

Provisioning 7 The automated provisioning service includes any data schema attributes needed for provisioning for each protected resource.

Provisioning 8 The automated provisioning service includes any notifications that will be triggered during the provisioning workflow.

Provisioning 9 The automated provisioning service includes audit/reporting requirements for provisioning workflows.

Provisioning 10 The automated provisioning service includes workflows for de-provisioning resource accounts.

Provisioning 11 The automated provisioning service includes the ability to map identities to resource accounts.

Provisioning 12 The automated provisioning service includes the ability to retrieve and evaluate authoritative attributes from other agency systems to make provisioning decisions.

Provisioning 13 The automated provisioning service includes the ability to detect and act on attribute changes to provision and de-provision access.

Provisioning 14 The automated provisioning service includes any resource account lifecycle management requirements.

Provisioning 15 The automated provisioning service includes any user interface requirements for provisioning workflows and providing help desk support.

Provisioning 16 The automated provisioning service includes the ability to detect, prevent, and resolve conflicts with established segregation of duties policies.

Figure 17: Common Characteristics of an Automated Provisioning Capability

9.2.3.2. Implementation Considerations

Deploying an automated provisioning capability is an undertaking that requires planning,

support, and coordination from various groups within an agency. Specific planning and

coordination considerations include the following:

Understand current workflows. Awareness of current provisioning workflows and

technologies allows integrators to fully understand which resources require which

information, while at the same time allowing integrators to analyze these needs and

streamline, where applicable.

Lesson Learned

When configuring automated provisioning workflows, consider leveraging a small set of baseline workflows to start. The workflows can then be modified and customized over time to support additional resource-specific needs or as mission and/or business needs change. National Aeronautics and Space Administration (NASA) found that a single baseline workflow with several alternate approval options enabled rapid deployment of provisioning services to the majority of its resources.

Determine approval requirements. Knowing resource authorization requirements

facilitates the mapping of roles and entitlements to access privileges. Providing an

escalation path when approvals (or denials) are not given in a defined timeframe can

significantly decrease the overall time taken to provision a user and improve the end user

experience.

Develop technical requirements. Define the development, test, and production

environment configurations in which the automated provisioning system will run,



including the solution architecture and configuration specifications for hardware

processing nodes, automated provisioning component deployment, communications

interfaces and protocols, network interfaces, and disk storage.

Define de-provisioning processes. A key benefit to automated provisioning solutions is

the ability to accurately and reliably de-provision user access when it is no longer needed.

Currently, many agencies have fewer triggers to review and remove access than for

providing access. An agency can see significant efficiencies and security benefits by

carefully defining rules for de-provisioning users, whether temporarily (suspend access)

or permanently (revoke access).

Determine appropriate auditing requirements. Logging defined approval and

provisioning steps is critical in establishing who has been given access to what and by

whom. Agencies should determine appropriate auditing requirements and ensure that the

provisioning solution is designed to log the appropriate events.

Define user reports or dashboards. Automated provisioning provides the ability to

capture information regarding account requests, approvals, and assigned permissions.

Agencies should determine requirements for user reports or dashboard capabilities using

this information to make the user management process more transparent to business and

application owners.

ROI

Automated provisioning capabilities support an enhanced level of transparency and a more accurate understanding of the number of required active user accounts for a given resource. Upon implementing its provisioning solution, a federal agency was able to significantly reduce its software licensing costs at the resource level by eliminating unnecessary user licenses for duplicate or orphaned accounts.

Determine technology needs. Automated provisioning capabilities can be custom

developed or purchased as part of a Commercial Off-The-Shelf (COTS) solution suite.

Agencies should analyze a variety of workflow products and existing investments,

aligning where appropriate, and determine which approach best suits the overall needs of

the organization. In some cases it may be more cost effective to build a custom

provisioning capability rather than purchase and configure a COTS product.

Determine appropriate provisioning architecture. Provisioning architectures typically

operate in one of two ways: by initiating the transmission of identity data (attributes,

roles, privileges, etc.) through data feeds at predetermined time intervals or based on

events; or by allowing relying parties (resources) to initiate the transmission of identity

data from LACS components by request, when needed. Agencies should evaluate the

business needs and technical constraints of the resources that will be integrated with the

provisioning solution and define the appropriate architecture.

Gain approval and seek funding. Regardless of the technology path chosen, agency

implementers will need to gain investment approval from ICAM decision makers and

secure funding if existing investments are not feasible sources.

Link user IDs to an enterprise digital identity. User identifiers often vary from

resource to resource. As part of implementing an automated provisioning capability,

these unique identifiers should be mapped to the user‟s enterprise digital identity to

provide visibility into user permissions across the organization. This concept is further

discussed in Chapter 7.



Maintain data privacy. Provisioning involves transmitting and/or sharing user data with

integrated resources to facilitate account creation and access control. Agencies must

ensure that appropriate controls are in place to maintain data privacy and prevent

unauthorized disclosure.

Communicate and train the user population. As with all other organizational changes,

an agency should ensure that the changes are communicated to the user population and

that appropriate training is provided. In provisioning, this is especially important for

personnel holding a sponsor or approver role.

Implementation Tip

When establishing automated provisioning workflows, it is important to evaluate current process steps and maintain necessary approval steps that are not inherently managed through the automated workflow (i.e., human intervention) to ensure that resource access is appropriately provisioned. In many cases, provisioning automation may allow an agency to streamline the account request steps. For example, approvals that were previously performed by sequentially signing a paper form may be approved concurrently, where appropriate, and offer non-repudiation of the approval through use of digital signatures.

In addition to planning considerations discussed above, implementation and enablement

considerations for automated provisioning solutions are provided for PACS and LACS solutions

in Chapters 10 and 11, respectively. Once an organization has a privilege management process in

place to grant access privileges to individuals and an automated provisioning capability, the next

step is correlating these access privileges with access rules that are intended to protect resources.

The resulting access control policies are then used to control access to protected resources based

on individual access privileges and may be reused with future resources. Authorization models

for streamlining access control and the process through which access control policies are

developed and enforced are discussed in detail in the following section.

9.3. Authorization

Authorization is the enforcement of access policies to ensure that the correct individuals and

entities are granted access to only the resources and information that they require. This relies

heavily on the “principle of least privilege,” which states that users should only be authorized to

access whatever is needed to do their job. In order to achieve successful authorization decisions,

agencies must define policies that specify how information about resources, users, and the

environmental context should be combined in order to determine when to grant or deny access.

The combination of all of these elements comprises authorization.

FAQ

What is the difference between authentication and authorization?

Authentication39

is the process of verifying that a claimed identity is genuine and based on valid credentials. In contrast, authorization is the process of granting or denying specific requests for access to resources. These two processes are tightly aligned and together support access control.

40

39 PIV-based authentication is discussed in detail in Chapter 8 – Fully Leveraging PIV and PIV-I.

40 A detailed discussion of authentication and authorization, and the role that they play in supporting access control is available in NIST SP 800-12.

http://csrc.nist.gov/publications/nistpubs/800-12/handbook.pdf

http://csrc.nist.gov/publications/nistpubs/800-12/handbook.pdf



The responsibility for determining the appropriate access control policies typically rests close to

the relying party resource (i.e., with the system owner or facility security manager). As agencies

move toward the target state ICAM architecture and enterprise approaches, models, and services

for access control, it is important to work with resource owners to understand and incorporate the

appropriate resource-specific workflows and policies. This offers agencies the ability to

streamline existing authorization processes and improve consistency, security, and reliability

without giving up local control of resource access criteria.

This section discusses the impacts that the ICAM segment architecture has on existing

authorization processes, introduces various models for evaluating attributes to make access

decisions, and examines the processes for managing access control policies throughout their

lifecycle. Additionally, this section seeks to answer several common questions about

authorization, including:

What are access control models and how are they used to streamline access control within

an agency?

What should I consider when evaluating the various access control models for my

agency?

How are access control policies defined and enforced within ICAM solutions, and what

benefits do digital access control policies offer?

9.3.1. Access Control Models

Successfully managing access to resources relies on pairing certain elements of information

about the resource (discussed in Section 9.1) with information about the user (discussed in

Section 9.2) within the appropriate context to make an access decision. An agency can employ

various access control models to determine how user and resource attributes should be handled

within access control transactions. Access control models are conceptual ways to express how an

access control system implements specific policies using its underlying infrastructure

components and security mechanisms. This section discusses common access control models,

their benefits and limitations, and examines when a particular model could be employed based

upon the needs of the agency. Many of the definitions and characteristics of various access

control models within this section are drawn from NISTIR-765741

.

Many systems today rely on Access Control Lists (ACLs), a basic method for performing access

control that grants access based on a list of the authorized entities and the actions they are

allowed to perform. ACLs offer a simple approach to managing access and require minimal

infrastructure; as such, they have been implemented widely across numerous applications.

Maintaining ACLs for individual resources or an enterprise can be time-consuming and prone to

errors. Additionally, approval processes for adding a user to an ACL often involve personal

knowledge of the individual, such as by a supervisor approving the request. Over time, as a

user‟s role or access needs change, it can be difficult to identify and remove access that is no

longer needed.

41 NISTIR-7657, A Report on the Privilege (Access) Management Workshop, March 2010.

http://csrc.nist.gov/publications/nistir/ir7657/nistir-7657.pdf



Terminology

Situational Access Control – An approach for adapting access control decisions for a resource to support the current operational environment. In this approach, the attributes about a user or resource typically do not change; however, their relevance to the situation impacts the access control decision. For example, an individual may be granted access to a location that he/she does not routinely have access to during an emergency situation based on his/her designation as an Emergency Response Official.

Situational Access Control is not a separate access control model but may be supported by several of the more robust access control models (e.g., Role-Based Access Control (RBAC), Policy-Based Access Control (PBAC), Attribute-Based Access Control (ABAC), and Risk-Adaptable Access Control RAdAC)

42 available.

As agencies move toward enterprise approaches to access control in the ICAM target state, many

ICAM implementers are looking for more flexible, granular approaches for managing access.

Several additional access control models are available that automate access based upon user

attributes and contextual resource information, including Attribute-Based Access Control

(ABAC), Role-Based Access Control (RBAC), Policy-Based Access Control (PBAC), and Risk-

Adaptable Access Control (RAdAC). Figure 18 describes each of these access control models

and discusses the benefits and limitations inherent to each model.

Access

Control

Model

How Access

Determinations are

Made

Benefits Limitations

Access

Control

List (ACL)

Access to resources is granted on a resource-by-resource basis, based upon an individual’s inclusion and corresponding privileges, as noted on the resource’s ACL.

Simple framework which does not require pre-existing infrastructure.

Supported by common operating systems.

Widely used and accepted throughout the Federal Government.

Controlled locally at the resource level.

Ability to evaluate individual access privileges becomes extremely complex as the list grows larger over time.

Criteria for access and individual role/job duties are fluid over time, thereby placing a significant administrator burden on resources owners.

Nearly impossible to manage at an enterprise level due to the sheer volume of resources and ACLs.

Requires manual changes to ACL, a time consuming and error prone process.

Revocation of access privileges may be delayed due to non-automated communication methods (e.g., word of mouth, e-mail, paper form distribution, etc.).

Role-

Based

Access

Control

(RBAC)

Individuals are assigned to various roles within an organization, down to the resource level based upon certain identity and entitlement attributes. Access is determined by having a particular role assignment that

Supports groupings of individuals with particular roles based upon well defined and trusted attributes.

Can accommodate centralized management.

Can be implemented at various levels within an

Can be difficult to manage as each protected resource generally has unique role requirements, thereby resulting in large numbers of potential role assignments within an organization.

Difficult to manage granular access of individuals due to the rigid nature of role assignments.

42 See Figure 18: Common Access Control Models for a description of these access control models.



Access

Control

Model

How Access

Determinations are

Made


corresponds to one or more resources.

organization, as long as a valid role is defined.

Supported by common operating systems and capable of group support as well.

Difficult to implement in a highly distributed agency (not centrally managed).

Requires significant level of effort to determine appropriate alignment of privileges for users not tied to the agency’s organizational structure.

Attribute-

Based

Access

Control

(ABAC)

Focuses on characteristics that describe people, resources and environments. The requester provides attributes which are compared to those documented as requirements for granting or denying access, at which point a decision is made.

Requires no advance knowledge of requestors.

An individual’s attributes can be correlated from multiple sources to create a unified identity.

Highly adaptable to changing needs; efficient for agencies where individuals come and go frequently.

Lengthy implementation time due to the need to correlate information and attributes from multiple sources for all potential users.

Reliant on authoritative identity/entitlement data – difficulty managing attribute conflicts between source systems.

Not natively supported by common operating systems.

Not appropriate for all environments (i.e., those with significant changes in risk level).

Policy-

Based

Access

Control

(PBAC)43

Determines access using rule sets, which consider the circumstances of the transaction and the policy.

Promotes compliance with standardized access controls.

Flexible in not being tied to only one type of access control.

Adapts quickly to new policy rules.

PBAC requires the design, deployment, and seamless integration of enterprise level systems (databases, directory services, etc.).

Policies must be absolutely unambiguous to avoid unintentional, unauthorized access.

Entire enterprise must use the same attributes for access and those attributes must be authoritative.


Risk-

Adaptable

Access

Control

(RAdAC)

Amount of information required of requesters to verify their identity depends on the current threat level, information includes personal trustworthiness and environmental factors.

Has the ability to make real time access control available.

Can control multiple diverse systems- including digital policies as some systems may require different authentication levels for the same user based transactions.

Supports flexible situations.

Cannot always be automatic, user judgments are needed.

Integrated systems must use standardized data exchange formats.

Policies must be unambiguous to avoid unintentional, unauthorized access.

Extensive considerations in adhering to policy and law – involves great care to be taken to ensure compliance.


Figure 18: Common Access Control Models

43 PBAC may also be referred to as Rule-Based Access Control.



The elements described above are intended to help agencies better understand access control

models and the value that they can provide. However, implementers should recognize that no

single model is perfect in all situations. There are several important considerations that ICAM

implementers should consider when evaluating access control models for a particular agency,

including44

:

Complexity vs. Simplicity. Agencies should seek to achieve a balance between

complexity and simplicity of the access control system‟s underlying architecture. Simpler

architectures are easier to manage and maintain; however, they may offer comparatively

fewer enhanced capabilities. Implementers should consider the agency‟s unique situation

in terms of its user base, resources, infrastructure, and attribute stores in order to

determine which model balances complexity with simplicity. Additionally, an agency

may begin with a simple architecture that is designed for extension to a more complex

model over time, which can be an effective way to support achievement of short and

long-term objectives.

Performance. Agencies should consider their mission needs and operating requirements

and evaluate against the access control system‟s ability to process user requests within a

time that is consistent with the needs of the enterprise. This can be accomplished by

examining the complexity of the decision-making algorithm, as well as through process

modeling and prototyping.

Policy Support. Access control models should support the organization‟s overall access

control policies, such as mandatory access control, discretionary access, separation of

duties, workflows, etc. Certain models may also be capable of combining various policies

to achieve enhanced capabilities, should they be desired.

Ease of Administration. Agencies should consider the level of administrative and

technical support necessary to manage the access control system. For example, the need

to support special languages and capabilities represents a significantly higher

administrative burden than use of a simple graphical user interface (GUI) to compose and

administer access control policy.

FAQ

Isn’t there one access control model that is the best?

Each of the access control models is a conceptual approach for how to use resource, user, and environmental data to drive the appropriate types of access control policies. In practice, agencies should review their access requirements choose the model or a combination of the capabilities of several models in order to best suit their needs. More robust access control models, such as role-based access control or policy-based access

control, can help an agency achieve the automation and efficiency goals and enhanced

security capabilities associated with the target state ICAM segment architecture.

Each access control model has been presented individually in order to allow for a comparison of

the benefits and limitations. In implementation, however, it is likely that many agencies will

utilize some type of hybrid approach that combines various aspects of multiple access control

models depending on the requirements of the resource. For example, RBAC often provides a

sufficient level of granularity to define access policies for many agency resources; however, an

application that has an extensive remote user population may require additional access

44 NIST IR 7657, A Report on the Privilege (Access) Management Workshop, March 2010.

http://csrc.nist.gov/publications/nistir/ir7657/nistir-7657.pdf



mechanisms capable of handling RAdAC contextual information. In this case, when a user from

an unknown location attempts to gain access, they may be prompted for additional information

for verification. Several of the access control models in this section provide efficiencies or more

granular security that is not possible in the current environment. The following section discusses

how these models may be applied to define and manage access control policies within an agency.

9.3.2. Policy Management

Access control policies are used throughout the Federal Government and serve as the linchpin

that enables successful authorization decisions to both physical and logical resources, supports

audit capabilities, and controls access to information. These policies are the rules that specify

how to use resource and entitlement attributes to make an access control decision.

FAQ

What is the difference between Policy-Based Access Control (PBAC) and Access Control Policies?

While both terms include the word “policy,” PBAC is just one of several access control models, which are used to describe how access control decisions are made within an access control system. Access control policies, on the other hand, are the specific rules that are executed by an access control system that define what users should be granted access to what resources. Policies are found in association with each of the various access control models discussed in the previous section.

Creation of secure, implementable access control policies hinges on having accurate, reliable,

and timely information about the resources that you are protecting, and the users and devices that

require access to them. Pairing this information results in the creation of rules/policies that define

what attributes a person must have in order to access a particular resource. Strategies for

managing access control policies vary widely within the Federal Government; however, it often

occurs at a local/resource level within federal agencies, where administrators modify policy to

suit local operational requirements. At a general level, policy management can be broken down

into a multi-step lifecycle, as depicted in Figure 19 below45

:

Lifecycle

Phase Description Common Activities

Policy

Definition

Process which defines the access control policy scope and requirements for a target asset or resource. The following considerations and inputs influence the access control policy definition process, including but not limited to: environment, users, unauthorized access risks; and existing policies, rules or internal processes which currently govern access to the resource or asset. The Policy Definition phase is usually facilitated by several interviews and working sessions.

Identify the asset or resource requiring discrete access control

Discover the environment in which access control policies will be developed and applied

Discover the users affected by the access control policies

Discover and document the risks associated with unauthorized access risks based on government standards (e.g., NIST SP 800-63

46, OMB M-04-04, etc.)

Discover and document the relevant policies, rules or internal processes which influence the access to the asset or resource

45 Additional information about policy management can be obtained in DoD‟s Enterprise Security Management, A Context Overview, March

2009.

46 NIST SP 800-63, Electronic Authentication Guideline, December 2008.

http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf



Lifecycle

Phase Description Common Activities

Policy

Analysis

Process which includes examining and analyzing the policy definition outputs and findings to help design access control policies which can be implemented. During this phase, the risks, rules, and inputs discovered will be analyzed to determine the authentication token type, the access control model, the relevant authorization model, and the tools used to enforce access.

Determine the access control model required (agency-level)

Determine authentication token type(s) required for enterprise based on industry standards and guidelines (e.g., NIST 800-63)

Determine access control authorization model by analyzing policy definition access

Determine the access control techniques, standards, and technologies required to enforce the access control policy

Develop metrics to measure effectiveness and performance of access control policies implemented

Conduct testing to evaluate effectiveness and performance of access control policies

Policy

Creation

Process of expressing access control policies using access control mechanisms and technology platforms.

Build access control policies on physical or logical systems based on the access control policies, rules, and designs developed

Develop test use cases which can be used during the access control policy evaluation phase

Policy

Evaluation

Process of testing the policy or policies designed and developed on test assets or resources.

Independently test the access control policy using the test use cases developed

Provide test feedback to improve access control policy created and ensure metrics defined are met

Policy

Implementation

& Enforcement

Process of implementing the newly created or revised access control policy on a production physical or logical asset or resource, and granting or denying access requests based upon policy-based authorization decisions.

Implement the newly created or revised access control policy on a production physical or logical asset or resource

Test the access control policy to ensure effectiveness

Policy Review

& Revision

Process which includes measuring the effectiveness of the access control policy implemented, determining whether the access control policy should be retired, or deciding if the access control policy should be revised.

Attestation certifying the effectiveness of the access control policy in production

Recommendations to asset or resource stakeholders when access control policy metrics are not met

Figure 19: Policy Management Lifecycle

Modernized PACS and LACS solutions, as discussed in Chapters 10 and 11, respectively are

capable of offering policy management services at an enterprise level. Enterprise level policy

management services provide the ability to administer access control policies at a local resource

level using authoritative data, common attributes, and job/role definitions through a centralized

construct. The target state ICAM segment architecture does not require the use of centralized

policy management services; however, certain efficiencies can be achieved by leveraging this

capability. Those include:

Reduced administrative burden. Local resource owners/administrators develop access

control policies to suit their specific needs; however the administrative burden associated

with storing policies occurs within the access control solution.

Policies based upon a common formal language. Utilizing policy management services

provided by centralized access control solutions ensures that access control policies



across an agency enterprise are based upon a single, common formal language and use a

single access control model for enforcement.

Ability to detect and address conflict. Coordinated management across agency policies

ensures that policy privileges are not conflicting or inconsistent across the enterprise and

are resolved before new policies are implemented.

9.4. Auditing and Reporting

This chapter has discussed the lifecycle management processes that support performing access

control for physical and logical resources within a federal agency. Conducting automated access

transactions will result in the logging of transaction event information, which can be used for

auditing and reporting. Auditing and reporting, as defined within the ICAM Services Framework

addresses the review and examination of records and activities to assess the adequacy of system

controls and the presentation of logged data in a meaningful context.

This section discusses the enhanced enterprise auditing and reporting capabilities that are

associated with the target state ICAM segment architecture. Additionally, this section seeks to

provide answers to several common auditing and reporting questions, including:

How will auditing and reporting differ in the ICAM target state?

How can ICAM solutions support security compliance and performance reporting, as

required by the ICAM target state?

What types of reports should I consider when designing my ICAM solution?

Across the Federal Government, information systems, including PACS solutions, are designed

and built to comply with specific accountability requirements, which mandate the capability to

review and report on various access events within individual applications. Each application

administrator (or his/her designee) is responsible for tracking and reviewing access control

events within their applications, and investigating anomalous entries. The processes for

completing this task vary widely across agencies, business units, and individual resources.

Typically, in order to provide contextual audit information in a meaningful manner, resource

owners/administrators have to manually correlate transaction event data from multiple sources

that may be paper-based and/or technology-based. Auditing and reporting capabilities are highly

dependent on technological constraints such as: network limitations, application setup,

application age, network infrastructure, etc. In addition, to the audit and reporting requirements

for all IT resources, PACS solutions must be capable of providing additional reporting services

for physical access events within the organization, as defined in the ISC‟s Use of Physical

Security Performance Measures.47

The target state ICAM segment architecture does not specify particular requirements for auditing

and reporting capabilities; however, many of the modernization efforts that agencies will be

performing on their physical and logical access control systems present an opportunity to

improve and automate their existing capabilities. For PACS, the transition to enterprise level

services increases the visibility into logged access event data and increases the ability to correlate

that data across individual site PACS, resulting in improved auditing and reporting capabilities.

For logical access, many of the commercially available solutions that can be used to provide

enterprise LACS services, as discussed in Chapter 11, include native auditing and reporting tools

47 Use of Physical Security Performance Measures, The Interagency Security Committee, 2009.



that can be configured to meet a variety of agency requirements. Agencies that choose not to

deploy enterprise level access control services may still be able to perform centralized auditing

and reporting; however, the consolidation processes required to do so are complex and time

consuming. NIST SP 800-92, Guide to Computer Security Log Management,48

provides a

detailed discussion of the processes that are required to consolidate logs from various sources.

ROI

Implementing an enterprise reporting and auditing capability in a centralized fashion allows agencies to achieve transparency across a wider array of resources, detect and resolve inappropriate access, and rapidly detect patterns of unauthorized access attempts across the organization in a manner not currently possible.

Figure 20 describes several types of access control reports that could be provided by an agency‟s

automated auditing and reporting services.

Report Type Description

User Access by Resource Provides an up-to-date account of successful user access attempts to both physical and logical resources, allowing the administrator/reviewer to select which resource they are primarily concerned about. This type of report may contain a large amount of data and its production could degrade solution performance. Agencies should consider when this type of report is necessary and determine when it could be produced with a minimum level of service interruption.

Unsuccessful Access Attempts Provides an account of all unsuccessful access attempts to any resource within the organization. Allows administrators to determine if individual users have a disproportionate number of unsuccessful access attempts across a wide range of resources.

Daily/Weekly/Monthly Activity Provides an account of all access activity for a particular resource within a set time period; typically daily, weekly, or monthly.

Individual User Audit Log Report Provides an audit log for all activities (successful and unsuccessful) attempted by an individual user.

Figure 20: Common Access Control Reports

The auditing and reporting improvements discussed in this section offer agencies significant

benefits and ROI for many of the modernization expenditures that are already required in order

to align with the target state ICAM segment architecture. These benefits include:

Ease of compliance with existing audit and accountability requirements. Agencies

are currently required to meet a myriad of auditing and accountability requirements

associated with program efficiency (OMB A-12349

) and access control. For IT systems,

these requirements are part of the FISMA reporting process and are outlined in the Audit

and Accountability (AU) control family detailed in NIST SP 800-53.50

For PACS

solutions, the ISC defines program efficiency measures to evaluate long-term

achievement of strategic security program goals.51

Additionally, enterprise access control

48 NIST SP 800-92, Guide to Computer Security Log Management, September 2006.

49 OMB 123 Management‟s Responsibility for Internal Control, December 21, 2004.

50 NIST SP 800-53, Recommended Security Controls for Federal Information Systems and Organizations, August 2009.

51 Use of Physical Security Performance Measures, The Interagency Security Committee, 2009.

http://csrc.nist.gov/publications/nistpubs/800-92/SP800-92.pdf

http://www.whitehouse.gov/omb/circulars_a123_rev




solutions can support compliance with the continuous monitoring requirements outlined

in NIST SP 800-37.52

Ability to meet security control enhancements for high baseline systems. NIST SP

800-53 specifies additional AU measures for high baseline information systems as a

means of ensuring increased levels of security on these highly sensitive resources. For

example, AU-3 and AU-653

specify centralized management of audit records and the

ability to correlate audit records across IT and physical security domains, respectively.

The enhanced audit and reporting capabilities provided by modernized access control

systems offer the ability to meet these security enhancements without placing an

additional burden on individual resources and administrators.

Ability to provide security information in new meaningful contexts, not currently

available. Access control systems, built in accordance with the target state ICAM

segment architecture, offer the ability to correlate and present large amounts of

information from resources across an agency enterprise in a near real-time fashion. As

part of reporting progress against the ICAM segment architecture, agencies are required

to produce performance metrics and reports in accordance with the ICAM Performance

Layer, as discussed in section 3.2.1. Currently, this requires significant manual

correlation and aggregation of information from an array of sources, whereas modernized

access control solutions are capable of performing this task in an automated, streamlined

manner.

Increased efficiency with auditing and reporting. Agency resources have historically

provided their own auditing and reporting capabilities, requiring resource owners design

and build their resources with these capabilities in mind. Building auditing and reporting

capabilities into each resource requires additional investment money and results in a

significant time commitment to manage at a local level. Providing these capabilities at an

enterprise level allows investment money to be reallocated to other mission critical areas

and frees resource owners/administrators to focus on their core job duties.

52 NIST SP 800-37, Guide for Applying the Risk Management Framework to Federal Information Systems: A Security Life Cycle Approach,

February 2010.

53 Audit and Accountability; AU-3: Content of Audit Records and AU-6: Audit Monitoring, Analysis and Reporting.


http://www.ncsu.edu/security/controls/audit_accountability.html



10. Initiative 7: Modernize PACS Infrastructure

Initiative 7, as introduced in Section 5.2.2, is an agency-level ICAM implementation initiative

that includes activities associated with upgrading PACS for routine access for PIV cardholders

and standardized visitor access for individuals with other acceptable credentials. As defined in

the ICAM segment architecture, a PACS is an automated system that manages the passage of

people or assets through an opening(s) in a secure perimeter(s) based on successful

authentication and associated authorization rules. The target state calls for a modernized PACS,

which includes the following characteristics:

Electronically authenticates PIV cards and accepts multi-factor authentication as defined

in NIST SP 800-116;

Supports an agency-wide approach to managing physical access services that links

individual PACS via an enterprise level network wherever possible and appropriate;

Interfaces with authoritative IDPs and data source(s) to supply user attributes and

credential information for automated provisioning and de-provisioning; and

Incorporates technologies that support secure, automated processes for requesting and

provisioning visitor access.

The guidance provided in this chapter is intended to help agencies achieve the target state

presented in the ICAM segment architecture Use Case 8, Grant Physical Access, and the

associated transition activities listed in Section 5.2.2.3.

This chapter is organized into the following five sections:

Physical Access Implementation Planning. This section discusses the activities and

processes that are necessary to properly plan for a modernized PACS implementation

within an agency. It includes existing standards and guidance, PACS program

governance, facility risk assessments, program funding, and schedule planning

considerations that are necessary to properly plan for a physical access deployment

within an agency.

Physical Access Architecture and Design. This section describes the architecture,

components, and key design characteristics common to a modernized PACS solution.

Physical Access Technical Implementation. This section covers common technical

considerations for deploying PACS solutions within federal agencies, including

automated provisioning and physical access scenarios.

Local Facility Access. This section presents guidance concerning populations that need

long-term local access but are ineligible for a PIV card.

Visitor Access. This section discusses common requirements of a visitor management

system (VMS) and other visitor access considerations.

10.1. Physical Access Implementation Planning

Providing reliable, robust physical security for its facilities and buildings is an important

responsibility for each agency. Additionally, physical security systems and procedures affect a

variety of users accessing federally-controlled facilities every day. As such, implementations of

modernized PACS solutions should be planned carefully to ensure success and prevent

disruptions to operations. Typically, decisions related to the selection and implementation of

PACS have been determined at the individual site level. As agencies move towards achieving the



target state, planning for a modernized PACS at the enterprise level offers many benefits,

including cost savings achieved from enterprise software licenses, decreases in redundant

collection and management of user identity data, and improved security through increased

consistency. Additional advantages are discussed throughout the rest of this chapter.

This section is targeted largely at those individuals responsible for setting the direction for and

planning an agency‟s PACS modernization effort. It will explore key aspects of implementation

planning, including: program governance, facility risk assessments, program funding, and

schedule planning. The OMB memorandum released on May 23, 200854

also provides agencies

with additional guidelines for consideration when planning or updating plans for the use of the

PIV card in their PACS, a central aspect of the ICAM target state.

FAQ

Does Physical Access Control System (PACS) infrastructure modernization require the use of an electronic PACS at every facility?

No. Selection of security countermeasures, including PACS, should be based on the risk assessment of a facility. Other access control approaches, such as lock and key, might provide adequate security and be more cost effective for an exceptionally low risk facility. As agencies develop their implementation plans in accordance with ICAM, they should first focus on the highest-risk facilities for PACS modernization. Over time, this should expand to lower-risk facilities in order to leverage the PIV credential wherever possible.


Chapter 6 provides guidance concerning overarching ICAM governance at the agency level. This

section is intended to supplement that guidance and highlight specific areas that agency

governance bodies should seek to address at an enterprise or component/bureau level to enable

successful PACS modernization efforts. For example, as part of the planning for a PACS

implementation, an agency should leverage its ICAM governance structure to coordinate the

PACS-related activities and investments across the bureaus/components and foster effective

communication and cooperation with other efforts, such as logical access and information

technology. Formalizing program governance for an agency‟s PACS effort within the ICAM

governance structure can ensure that change is managed properly, communications are delivered

effectively, and that policy is created or refined to support the target state.

The transition to a modernized PACS needs to incorporate an appropriate change management

approach to ensure that stakeholders embrace the changes associated with the implementation.

An agency should take advantage of the many tools associated with effective change

management, including following a project plan, developing communication tools, and

conducting training. The approach should also include steps to reinforce change such as

monitoring effectiveness, building stakeholder buy-in, and celebrating successes.

54 Guidance for Homeland Security Presidential Directive (HSPD) 12 Implementation, May 23, 2008.

Implementation Tip

To increase effectiveness, PACS governance should be made up of decision makers from each bureau/component. For example, the Change Control Board (CCB) for USDA’s enterprise PACS implementation, ePACS, includes representatives from each of its sub-agencies who are educated on PACS policies and help ensure activities and efforts at their sub-agencies meet USDA policies and common requirements.

http://www.cio.gov/Documents/guidance_hspd12_05-23-2008.pdf



Communication is important throughout the change management process and also plays a key

role in the other transition activities associated with modernizing a PACS. Because physical

security and access to buildings affects all government employees, contractors, and visitors,

communication with and education of the end-user population can significantly impact the

success of the implementation. For example, the PACS governance team should plan for and

communicate any revised policy and new procedures that are created early and often.

Additionally, as new ICAM services are deployed, an agency should communicate key changes

to its user populations well in advance to avoid disruptions. The communication options and

delivery media presented in Section 6.1.3.1 of this document can be leveraged by PACS

governance to ensure appropriate and effective messages are delivered at the right time.

Lesson Learned

Some of the simplest communication tools can also be the most effective. For example, posting signs at entry points displaying important information regarding the modernization can help individuals prepare for upcoming changes. One agency learned that employees planned to arrive early on the first day PIV cards would be used at the entrance of the building because they had read the signs and were expecting delays.

10.1.1.1. Existing Policy and Requirements

The first priority of physical security is life safety, protecting the people who occupy federal

buildings. In support of this paramount responsibility, there are standards, codes, and policies

that individuals in the physical security field are required to follow. The PACS is one of many

parts of the overarching physical security mission. Implementers must address additional

standards and guidance, such as the following:

Interagency Security Committee (ISC) Compendium of Standards. The ISC was

created to enhance the quality and effectiveness of physical security in, and the protection

of, federal facilities in the U.S. These authoritative standards are designed to help federal

security professionals implement effective security policies. Of particular relevance:

Facility Security Level (FSL) Determinations for Federal Facilities. Defines

the criteria and process to be used in determining the facility security level (FSL)

of a federal facility, a categorization which then serves as the basis for

implementing protective measures under other ISC standards.

Physical Security Criteria for Federal Facilities. Establishes a baseline set of

physical security criteria that provide a framework for the customization of

security measures to address unique risks at a facility.

Interim Design-Basis Threat Report. A stand-alone threat analysis to be used in

conjunction with the physical security criteria. It establishes a profile of the type,

composition, and capabilities of adversaries.

National Fire Protection Agency (NFPA) codes.55

The NFPA is the authority on fire,

electrical, and building safety and its mission is to reduce the burden of fire and other

hazards on the quality of life by providing and advocating consensus codes and standards,

research, training, and education. NFPA develops, publishes, and disseminates consensus

codes and standards intended to minimize the possibility and effects of fire and other

risks. Of specific note:

55 National Fire Protection Agency (NFPA).

http://www.nfpa.org/categoryList.asp?categoryID=124&URL=Codes%20&%20Standards



NFPA 101. The Code addresses those construction, protection, and occupancy

features necessary to minimize danger to life from the effects of fire, including

smoke, heat, and toxic gases created during a fire.

NFPA 72. Covers the application, installation, location, performance, inspection,

testing, and maintenance of fire alarm systems, supervising station alarm systems,

public emergency alarm reporting systems, fire warning equipment and

emergency communications systems, and their components.

Underwriters Laboratories (UL). An independent product safety certification

organization that tests products and writes standards for safety in an effort to promote

safe living and working environments, support the production and use of products which

are physically and environmentally safe and to prevent or reduce loss of life and property.

UL is the trusted resource across the physical security industry for product safety

certification and compliance. Standards of particular relevance:

UL 294. Specifies requirements for the construction, performance, and operation

of systems intended to regulate or control entry into an area or access to or the use

of a device(s) by electrical, electronic or mechanical means. These requirements

apply to computer equipment that, when used in conjunction with the main

control, is necessary for proper operation of the access control system.

UL 1076. Specifies requirements for the construction, performance and operation

of equipment intended for use in proprietary burglar alarm units and systems used

to protect against burglary.

UL 2050. Specifies requirements for the monitoring, signal processing,

investigation, servicing and operation of alarm systems.

Federal Information Security Management Act (FISMA). This act requires each

federal agency to develop, document, and implement an agency-wide program to provide

information security for IT systems. As covered under FISMA, PACS implementers must

meet all requirements associated with the RMF as defined in NIST SP 800-3756

and

implement the appropriate security controls outlined in NIST SP 800-53.57

They must

also comply with FISMA reporting guidelines.58

Open, Systems Integration and Performance Standards (OSIPS). A family of

standards developed by the Security Industry Association (SIA), an American National

Standards Institute (ANSI) accredited standards organization. These standards are

intended to promote interoperability between components in traditional access control

systems by providing a common interface and creating levels of performance. OSIPS

references architecture information for all parts of an integrated electronic security

system, including the PACS, and addresses how to use the standards within a compliant

ICAM implementation. Of particular note:

OSIPS-ACR-200x. Describes identity authentication and factors that are

presented in a transaction seeking access to an Accessible Component Collection.

56 NIST SP 800-37, Guide for Applying the Risk Management Framework to Federal Information Systems, U.S. Department of Commerce, February 2010.

57 NIST SP 800-53, Recommended Security Controls for Federal Information Systems, U.S. Department of Commerce, December, 2007.

58 OMB M-10-15 FY 2010 Reporting Instructions for the Federal Information Security Management Act and Agency Privacy Management, April 21, 2010.



http://www.whitehouse.gov/sites/default/files/omb/assets/memoranda_2010/m10-15.pdf



OSIPS-APC-200x. Describes the credentials presented to field devices at the

access point controller.

OSIPS-IDM-200x. Describes claims of identity that are authenticated by

comparing reference authentication factors with presented credentials.

In addition to these existing standards and regulations, the next section introduces recommended

agency governance efforts that may be used to support PACS modernization. It is important to

note that the recommendations in this document are not intended to replace or supersede existing

life safety or physical security standards and regulations.

10.1.1.2. Agency Governance Efforts

Policy is a key enabler of success during a PACS modernization. As part of implementation

planning, PACS governance should review existing agency policies to determine if they align

with the ICAM segment architecture, as well as relevant laws, government-wide policies, and

standards. As appropriate, the planning should address any policy gaps that are identified with

revisions to existing or the creation of new policies. This section is intended to supplement the

guidance around program governance found in Chapter 6 and highlight specific areas that agency

governance bodies should seek to address to enable successful PACS modernization efforts.

PACS-specific policies will vary based on an agency‟s size, mission and business requirements,

as well as the maturity of its physical access policies relative to the ICAM target state. Per OMB

M-11-11,59

agencies must develop and issue agency implementation policy requiring the use of

the PIV credential for access to the agency‟s facilities, networks, and information systems and

alignment with the ICAM segment architecture. There are also a number of other common topics

that should be incorporated in an agency‟s governance efforts to support the modernized PACS

implementation. Figure 21 includes a list of common governance efforts and describes how

agencies might consider utilizing them as a means to promote compliance and overcome

implementation challenges. Many of the governance efforts listed below are expected to apply to

logical access, discussed in Chapter 11, and may be combined at some agencies.

Governance Effort Description

Issue Policy Memorandum: Continued Implementation of HSPD-12

Agency-level policy, as required by OMB M-11-11, that includes provisions for several items related to PACS modernization, including:

Enforcing use of the PIV card for physical access and the movement away from separate (often bureau/component-specific) identification cards.

Procurement of services and products for PACS in accordance with OMB M-06-18

60 and the FAR.

61

Acceptance of PIV credentials issued by other federal agencies for physical access.

Alignment with the ICAM segment architecture, including completion of an agency transition plan that includes information regarding the agency’s PACS modernization.

59 OMB M-11-11, Continued Implementation of Homeland Security Presidential Directive (HSPD) 12- Policy for a Common Identification



61 FAR Subpart 4.13- Personal Identity Verification,







Issue Policy/Guidance Addressing Common Physical Access Scenarios

Policy or procedural guidance reflecting formal agency-level decisions for handling common physical access problem scenarios such as a lost/forgotten PIV card.

Issue Policy/Guidance Addressing Standardization of Local Facility Access Cards

Policy or procedural guidance for establishing a standard local facility access card and providing guidance around when and how they are issued. This topic is discussed further in Section 10.4.

Issue Policy/Guidance Addressing Visitor Management

Procedural guidance for establishing what types of credentials are considered acceptable for granting physical access to visitors. Direction should address additional procedures for handling individuals who are not PIV card holders (e.g., escort procedures).. This topic is discussed further in Section 10.5.

Define Baseline User Privileges for Physical Access

Effort to determine a set of baseline user privileges for physical access that can be tied into the agency’s automated provisioning capability to grant new users privileges to multiple access points automatically.

Bureaus/Component Modernization Plans

Effort by agency leadership and management to review and provide guidance related to bureau/subcomponent implementation plans for modernizing PACS. The review should take into consideration whether the proposed approach meets relevant requirements and is the most cost effective (e.g., upgrading an existing PACS rather than purchasing a new system).

Incorporate the PIV Card Implementation Maturity Model (PIMM)

Effort to incorporate the PIMM into PACS project performance measurement. The PIMM describes various levels of PIV card use to help agency leadership and PACS implementers determine the maturity of the PACS program and make decisions accordingly.

Figure 21: Sample PACS Governance Efforts

An important aspect of governance is the ability to measure project performance and maturity;

however, measuring the progress of a modernized PACS implementation can be complex due to

variations in the requirements, facility size, and amount of existing electronic PACS. NIST SP

800-116 presents the PIV card Implementation Maturity Model (PIMM),62

which should be used

by agencies to measure progress while working towards achieving the target state. The levels are

progressive and range from, “Ad Hoc PIV card Verification,” to “Access to Exclusion, Limited,

or Controlled Areas by PIV card or Exception Only.” The lowest level describes a site that has

the ability to authenticate PIV cards by performing required authentication mechanisms on an ad

hoc basis. The most mature level describes a site in which only the PIV card is an acceptable

credential for federal employees and contractors covered under HSPD-12. The PIMM can be

integrated into agency‟s ICAM performance management reviews to determine the success of

the modernized PACS implementation effort and set completion goals.

10.1.2. Facility Risk Assessments

Government facilities are a part of the nation‟s critical infrastructure, and as such, have certain

protection requirements. The following mandates and requirements underscore an agency‟s

responsibility for protecting federal facilities:

HSPD-7 Critical Infrastructure Protection Mandates. Establishes a national policy for

federal departments and agencies to identify and prioritize U.S. critical infrastructure and

key resources and to protect them from terrorist attack. HSPD-7 identifies 17 sectors that

62 NIST SP 800-116, A Recommendation for the Use of PIV Credentials in Physical Access Control Systems (PACS), U.S. Department of Commerce, November, 2008.

http://csrc.nist.gov/publications/nistpubs/800-116/SP800-116.pdf



require protective actions to prepare for, protect, or militate against a terrorist attack or

other hazards.

National Infrastructure Protection Plan (NIPP). Outlines the parameters for

infrastructure protection. The use of the NIPP risk management framework is a part of

the overall effort to ensure the protection and resiliency of our Nation‟s Critical

Infrastructure/Key Resources. The NIPP includes the Government Facilities Sector Plan,

which provides an approach to enhancing protection of government facilities.

Facilities and access points should be protected based on risk. The ISC Compendium of

Standards, discussed in section 10.1.1.1, provide agencies with guidance on how to perform

facility risk assessments, determine the appropriate FSL, and analyze the required LOP, to

determine and implement the appropriate security countermeasures. As described in OMB M-11-

11,63

DHS has also partnered with the GSA Public Building Service (PBS) to ensure that risk

assessment and implementation of physical access measures for buildings under PBS‟ purview

are implemented in accordance with the ISC and NIST guidelines. There are a variety of risk

assessment processes available for agency use. Figure 22 provides a summary of the main steps

that are commonly conducted as part of a facility risk assessment, as defined in the ISC guidance

and based upon industry best practices.

Step 1: Set Security

Goals Step 2: Identify Step 3: Assess Step 4: Categorize

Des

cri

pti

on

Define specific outcomes, conditions, end points, or performance targets that collectively constitute an effective protective posture or baseline.

Develop an inventory of the assets, systems, and access points that exist within a facility.

Determine risk by identifying potential consequences of vulnerabilities.

Categorize and analyze risk assessment results to develop a comprehensive picture of facility risk.

Key

Co

ns

ide

rati

on

s Agency’s security

control posture and risk tolerance.

Security requirements, including FICAM security targets for PACS.

Range of systems and assets within a given facility.

Calculated value of assets within a given facility.

Likelihood of occurrence.

Impact if vulnerabilities are exploited.

Local conditions and the area surrounding a facility.

Relevant legislation, policies, and standards.

Protection priorities and adequate countermeasures.

Figure 22: Common Risk Management Steps

The end result of the risk assessment is a complete risk profile of the facility. This information

helps physical security implementers make decisions regarding appropriate security

countermeasures to employ, including electronic (e.g., video surveillance, intrusion detection,

PACS, etc.), physical (e.g., bollards, gates), and guard force. The scope of this guidance is

limited to authentication-based access control and thus focuses on the electronic PACS as a

countermeasure; however, agencies can find additional guidance on selecting a full range of

alternative countermeasures in the ISC‟s Compendium of Standards64

. When applying the results

of the facility risk assessment to the design of its PACS, an agency needs to determine the risk

63OMB M-11-11 Continued Implementation of Homeland Security Presidential Directive (HSPD) 12- Policy for a Common Identification


64 Government users with a need to know may access the ISC standards that are For Official Use Only (FOUO) by requesting access at [email protected].


mailto:[email protected]



level of a particular facility and individual areas within the facility that will be protected by a

controlled access point. The agency should then determine the appropriate authentication

mechanism(s) that should be deployed at each access point, as defined in NIST SP 800-116. SP

800-116 uses the restricted area concept of “Controlled, Limited, Exclusion” areas to address

individual areas nested within a facility that may have specific security requirements. They are

defined as follows:

Exclusion Area. An exclusion area is a restricted area containing a security interest or

other matter of such nature that access to the area, or proximity resulting from access to

the area, constitutes access to the security interest or matter.

Limited Area. A limited area is a restricted area containing a security interest or other

matter of such nature that uncontrolled movement will permit access to the security

interest or matter. Access in limited areas may be controlled by requiring escorts or by

other internal restrictions and controls.

Controlled Area. A controlled area is that portion of a restricted area usually near or

surrounding an exclusion or limited area. Entry to the controlled area is restricted to

authorized personnel.

Lesson Learned

It can be difficult to analyze a site for its risks and know how to apply the appropriate guidance while keeping cost savings in mind. An agency might find value in assembling

a small team of cross functional resources (including physical security, IT, etc.) from its

ICAM program to help bureaus/components or individual sites conduct facility risk assessments and make decisions regarding the best way to achieve a compliant, modernized PACS.

Once an agency has determined the appropriate authentication mechanisms based on a facility‟s

risk, it should make decisions around the best PACS solution and how to fund its

implementation. The following section provides additional considerations and guidance on these

topics.

Implementation Tip

Focus on what you can control. Agencies frequently occupy leased space where the landlord controls the exterior physical security. If the existing system cannot process the PIV card for physical access, establish an access point at the entry to the agency-controlled space. This arrangement allows the agency to meet its requirements for PIV card authentication while still adhering to the leasing agreement.

10.1.3. Program Funding

A key aspect of physical access implementation planning is making decisions around the funding

and acquisition of a modernized PACS solution. This includes estimating solution costs,

determining the proper funding method, and planning for and completing acquisition of the

required products and services. This section discusses key considerations for estimating program

funding needs and potential funding models for an agency‟s PACS modernization. Additional

information on acquisition planning and the budget request process can be found in Section

6.1.3.3.



ROI

One large agency was able to save tens of thousands of dollars per site on costs associated with server hosting, hardware and software, and executing IT security requirements when their individual PACS were rolled into the enterprise service offering.

Choosing the PACS solution an agency is going to select is one of the first steps in planning how

a program will be funded. Agencies should chose a solution that aligns with the ICAM segment

architecture, supports their access control processes and requirements, leverages existing

infrastructure wherever possible, and provides the best value for their investment. Once a

solution has been determined, an agency should evaluate a number of factors in order to estimate

the costs that will be incurred. The items provided in Figure 23 are examples of common factors

and considerations that agencies should examine not only to determine costs, but also determine

the potential cost savings that various PACS solutions are capable of providing.

Evaluation Factor Description

Facility Size The number of users requiring access to a facility significantly impacts the level of administrative effort required to provision user accounts and manage access privileges. In addition, there may be potential cost breaks for certain volumes.

Level of PACS Services Provided

Agencies should determine at which level PACS services should be provided. There are cost savings and efficiencies that can be achieved by providing services at the enterprise-level. For example, an agency hosting a server for the bureaus/components.

Analysis of Population Organizations should examine populations (employees, contractors, short term, etc.) and facility tenants (federal, non-federal) to determine the types of groups requiring access. Complex user populations should be considered when making a decision on the type of PACS solution to implement. In addition, there should be capability to handle increased capacity as the modernization progresses and the amount/type of users change over time.

Number of PACS The number of PACS within an agency often dictates implementation time and can significantly affect implementation cost, depending on the resources’ connection requirements.

Type of PACS The type of PACS varies based on the vendors, platforms, operating systems, products, databases, etc. that are in use across the organization. These variances impact the complexity of integrating resources with the PACS infrastructure and require different integration processes.

Existing PACS Investments Agencies may have existing investments in place that are capable of providing physical access services in a manner consistent with the target state ICAM segment architecture. These investments should be leveraged wherever possible and offer the potential to achieve a modernized PACS state without requiring significant investment from the organization.

Credentials Supported As agencies move toward use of the PIV card for employees and contractors, they can expect a reduction in local printing and card management support traditionally associated with PACS operations. Agencies should examine the types of credentials that the PACS must support (including PIV-I) and incorporate any costs associated with validating acceptable credentials.

Protection Areas

Agencies should consider the number or combination of protection areas (limited, exclusion, controlled) when determining program costs. For example, a high number of exclusion protection areas may increase costs due to the added level of access control required to protect those areas.

Figure 23: Common PACS Acquisition Considerations

Once a solution has been identified and the potential costs and cost savings have been estimated,

agencies should make decisions around how to fund the PACS solution. Typically, PACS have

been selected and funded at the site level. As agencies look to move towards an enterprise model,



this can introduce challenges for funding and implementing enterprise PACS services, where

equipment and services will likely be purchased centrally. To date, agencies have taken several

different approaches to funding their PACS modernization efforts. These include:

Incorporate Costs into Existing Investment. Rather than having a separate PACS

investment, costs for PACS modernization can be included in an existing business case.

Investment Business Case. A new investment request to fund PACS modernization at

the enterprise level. The business case includes details of how the proposed investment

would support the agency‟s mission.

Working Capital Fund. A fund that is able to provide financing to agencies without

annual appropriation by Congress for operations that generate receipts. This funding

method works well for an agency that is providing the enterprise PACS as a centralized

service and has a fee structure for the users across the bureaus/components.

Implementation Tip

The products implementing and executing the cryptographic processes with the PIV card must comply with FIPS 140 and be approved by a NIST validated laboratory. Agencies should procure products and services from manufacturers who provide architectures that minimize the cost of FIPS 140 by producing components in very high volume, or by amortizing the cost into common components, such as a multi-door controller.

In addition to determining funding needs and obtaining funding, a key aspect of PACS

implementation planning is outlining the life cycle activities associated with the modernization

effort and determining the project schedule. This is addressed further in the following section.

10.1.4. Schedule Planning

Modernizing PACS projects requires close coordination across multiple workstreams within an

agency and may, in some cases, represent a multi-year effort. During this period, it is critical to

develop a transition plan that keeps the current PACS and physical security infrastructure in

place while reducing security system downtime. Because of this complexity, program/project

managers should consider following a system development life cycle (SDLC) that addresses key

activities and timing considerations. There are a variety of SDLCs that are commonly accepted

and used within the Federal Government. Each agency should have a defined and repeatable

SDLC that meets the agency‟s business needs and supports IT investments; these same concepts

can be applied to physical security investments. While individual agency SDLCs may be more

granular in detail and contain additional steps/phases, the activities and considerations presented

in this section can be adapted into any SDLC model.

Implementation Tip

An important aspect of developing a phased implementation approach is accurately documenting the activities that must occur during each phase and defining measurable exit criteria. This ensures that the implementation proceeds along a predictable path, which can help mitigate many common implementation risks.

The guidance presented in this document has been organized into a traditional, sequential five-

phase SDLC (waterfall) process, as it is the simplest and most commonly used model. The

phases discussed have been abstracted from a variety of individual agency SDLC models to suit

the needs of this document and create an appropriate basis for discussion. The five phases are:

Planning, Requirements and Design, Build, Implement, and Operate and Maintain. This section



examines each of the SDLC phases in greater detail and discusses the PACS-specific events that

should occur as part of each phase.

Implementation Tip

One large agency created a working group to gather information around its deployed PACS infrastructure, such as vendor, version and architecture. Collecting this data can help agency leadership determine how to leverage existing investments when planning and designing its target state PACS solution.

10.1.4.1. Planning Phase

Section 10.1 of this chapter discusses the overall planning considerations when implementing a

modernized PACS. This section describes planning as the first phase of the structured SDLC

process commonly used when executing complex solutions. Completing the Planning Phase is

critical for modernizing PACS solutions, as many of the common problems encountered can be

avoided through careful planning.

Lesson Learned

Investing in and installing multi-technology card readers gives program implementers access control during the transition from agency-specific proximity cards to PIV cards. It also allows proximity cards to be issued to resolve temporary physical access challenges such as lost, stolen, or damaged PIV cards.

Figure 24 provides a list of common activities that should occur during the Planning Phase and

notes estimated completion times for each; however, activities may occur in parallel, and actual

times can vary widely based on organizational size and project complexity.

Activity Description Completion Time

Develop Communications Plan

Develop the approach and plan to communicate (using a variety of mediums) the changes that a PACS modernization effort will bring to internal users, resource owners, and stakeholders. It should include some form of agency cultural education plan if changes will be significant.

2 – 4 weeks

Conduct Gap Analysis Determine the desired operation and use cases for the target state system and then compare against capabilities of the current equipment. This should be followed by an objective assessment of capabilities of the current PACS to determine what solution is required to achieve the desired target state.

2 – 4 weeks

Conduct Cost/Benefit Analysis

Evaluate organizational factors and conduct a cost/benefit analysis to determine an appropriate PACS solution.

3 – 6 weeks

Develop PACS Modernization Business Plan

Develop a business plan to support modernization of the existing PACS infrastructure or a new infrastructure. This should lay out the selected approach, timeline, resource requirements, and estimated costs.

4 – 6 weeks

Secure Funding Sources Utilize the PACS business plan to secure new or existing funding sources for the modernization effort. This should include determining if existing investments exist and how to leverage them.

6 – 10 weeks

Develop Implementation Plan/Schedule

Develop a phased implementation approach and schedule based on available information using standardized agency resources.

2 – 4 weeks




Categorize the PACS Conduct Step 1 of the Risk Management Framework: Categorize Information Systems based on mission/business objectives. Register the PACS in the agency’s IT system inventory.

4 – 12 weeks

Develop Risk Management Plan

Utilize existing risk management sources to develop a Risk Management Plan, as discussed in Chapter 6, for handling risks related to modernizing the PACS infrastructure.

2 – 4 weeks

Begin Field Prioritization Begin examining agency PACS and developing field assessment criteria in order to prioritize/organize deployment of modernized PACS services to agency facilities.

1 – 2 weeks

Develop Field Integration Guide

Develop a Field Integration Guide, a formal document used to outline the process that an agency’s physical security resources will go through to become integrated with the PACS solution.

6 – 8 weeks

Develop PACS Migration Plan

Develop a migration plan that outlines how the agency plans to transition its physical resources to use of the modernized access control system.

1 – 3 weeks

Develop Pilot Implementation Plan

Develop a plan and schedule for piloting the modernized PACS solution on a small subset of the user population with well defined resource requirements.

4 – 12 weeks

Figure 24: Planning Phase Sample Activities

10.1.4.2. Requirements and Design Phase

The Requirements and Design Phase follows the Planning Phase in the SDLC. In this phase, an

agency thoroughly documents the requirements for the PACS solution and defines how the

solution should operate within the existing infrastructure. Figure 25 provides a list of common

activities that should occur during the Requirements and Design Phase and notes estimated

completion times for each; however, activities may occur in parallel, and actual times can vary

widely based on organizational size and project complexity.


Gather PACS Solution Requirements

Conduct a requirements gathering exercise with stakeholders and impacted parties at all organizational levels to document requirements of the PACS solution. These requirements are critical as they will be used to drive the design, build, and configuration of the PACS capability.

4 – 6 weeks

Select Security Controls Conduct Step 2 of the Risk Management Framework: Select Security Controls by choosing the appropriate security controls and documenting the selected controls in the security plan.

2 – 4 weeks

Validate PACS Solution Requirements

Validate the documented requirements with the appropriate stakeholders in order to ensure that the PACS solution is properly designed and configured to meet the agency’s needs.

1 – 2 weeks

Document System Design

Draft an initial system design document that clearly states how the system should function within the agency’s environment. The design document and associated requirements are then used during the build phase as a reference for how the PACS system should operate.

2 – 4 weeks

Conduct Resource Acquisition

With funding sources secured, conduct the process of purchasing any required hardware or software and services.

4 – 12 weeks

Define and Configure Provisioning Workflows

Define provisioning workflows, which are used to determine how users are granted rights to access points and what approvals or additional steps are required. This process often involves configuring automated workflows based on existing manual processes.

2 – 4 weeks




Develop Solution Architecture

Develop an initial solution architecture for the PACS implementation. This architecture defines the solution components and describes their interactions.

2 – 4 weeks

Figure 25: Requirements and Design Phase Sample Activities

Implementation Tip

Be sure to include ICAM requirements for modernized PACS in facility arrangements, negotiations, and the procurement process for leased space. When these requirements are introduced during the Requirements and Design Phase, an agency can more easily ensure the proper requirements are incorporated into lease agreements.

10.1.4.3. Build Phase

Following the Design Phase, agencies enter the Build Phase, where the majority of the technical

solution development, configuration, and testing occurs. Figure 26 provides a list of common

activities that should occur during the Build Phase and notes estimated completion times for

each; however, activities may occur in parallel, and actual times can vary widely based on

organizational size and project complexity.


Stand Up Development and Test Environments

Establish development and testing environments so that PACS developers and testers can conduct build activities in an environment that does not impact the agency’s production systems.

4 – 6 weeks

Build/Configure Servers Build and/or configure servers to properly operate the PACS solution, as needed based upon the chosen implementation path.

1 – 2 weeks

Install Supporting Software

Install supporting software (i.e., COTS IAM Suite) on PACS servers, as needed based upon the chosen implementation path.

1 – 2 weeks

Configure Supporting Software

Configure PACS software to specifically meet the agency’s unique needs and/or perform certain functions, as needed based upon the chosen implementation path.

1 – 2 weeks

Implement and Assess Security Controls

Conduct Steps 3 and 4 of the Risk Management Framework by applying the controls identified in the requirements and design phase and by assessing the adequacy and effectiveness of the security controls and documenting the findings in an assessment report..

12 – 20 weeks

Conduct Testing on Initial Build

Perform testing on the PACS solution in a development and/or test environment to ensure that system errors are found and corrected before the solution is deployed on the agency’s network.

2 – 4 weeks

Conduct Pilot Implementation Deployment

Conduct a pilot implementation to expose a small subset of the agency’s user base to the PACS solution for the purpose of evaluating the solution’s operations against real-world requirements.

Varies on size of deployment (number of

facilities and access points)

Figure 26: Build Phase Sample Activities

10.1.4.4. Implement Phase

Once an agency has configured its PACS solution and tested to ensure that it meets agency and

government-wide requirements and performs appropriately, the program enters the



Implementation Phase. This phase consists of activities for migration of the PACS solution from

a development and test environment into the agency‟s production infrastructure. There may be an

overlap in access control services provided by the old and new PACS for a period of time until

the cardholder population is fully transitioned to the new PACS. Figure 27 provides a list of

common activities that should occur during the Implement Phase and notes estimated completion

times for each; however, activities may occur in parallel, and actual times can vary widely based

on organizational size and project complexity.


Authorize the PACS Conduct Step 5 of the Risk Management Framework: Authorize Information System by preparing and submitting the security authorization package to the authorizing official. The authorizing official chooses to accept the risk and authorize the system if the risk associated with operating the PACS is deemed acceptable.

1 – 2 weeks

Conduct User Acceptance Testing (UAT)

Conduct UAT to ensure that the PACS solution is acceptable to stakeholders and end users and performs the required functions in an appropriate manner.

2 – 4 weeks

Conduct User Training Develop training materials and conduct user training prior to PACS deployment to ensure that users are capable of accessing their worksites without disruption.

2 – 4 weeks

Deploy PACS Solution to Live Production Environment

Deploy the PACS solution on the agency’s network infrastructure and begin controlling access to facilities.

Varies according to deployment size

(number of facilities and

access points)

Perform Awareness and Outreach

Conduct awareness and outreach activities in accordance with the Communications Plan developed as part of the Planning Phase. This involves actively communicating to users that a new access control system is being deployed, the benefits and efficiencies that users can expect, and any steps necessary to begin using the new system.

This will occur as needed throughout

the deployment process

Figure 27: Implement Phase Sample Activities

10.1.4.5. Operate and Maintain Phase

After an agency has successfully deployed its modernized PACS solution to a live production

level, the program enters the Operate and Maintain Phase. This phase lasts for the remainder of

the time that the PACS solution is in use and consists of ongoing management and system

maintenance activities such as: conducting training, operating the PACS solution, and protecting

new resources as they come online.

Implementation Tip

Enterprise development often includes connection of multiple local PACS servers that may contain local user records. This will require a de-duplication process to remove redundant accounts in instances where one person has access to multiple sites. Additionally, agencies should have a plan for handling duplicate user records.

Figure 28 provides a list of common activities that should occur during the Operate and Maintain

Phase and notes estimated completion times for each; however, activities may occur in parallel,

and actual times can vary widely based on organizational size and project complexity.




Monitor Security Controls

Conduct Step 6 of the Risk Management Framework: Monitor Security Controls by monitoring changes to the information system and its environment of operation and conducting ongoing assessments of security controls in accordance with the monitoring strategy.

On-going

Ongoing User Training Continue to update and modify user training curriculums as the PACS solution matures and new technology is implemented. Conduct additional training as necessary.



Modify Provisioning Workflows

Update provisioning workflows as business needs and access rules change over time. Changes may also be required as resource owners experience the benefits that can be provided by modernized PACS services and provisioning workflows can be streamlined.

2 – 4 weeks per occurrence

Conduct Hardware/ Technology Refresh

Conduct periodic updates and/or upgrades to solution hardware and other technology over the lifespan of a PACS solution as a means of extending the usable life of the solution or adding new capabilities.

12 – 36 weeks

Software/Firmware Refresh

Update software and firmware to accommodate manufacturer improvements, bug fixes, or to remain compliant with the latest policies and standards.

15 minutes per device (reader or controller)

Figure 28: Operate and Maintain Phase Sample Activities

10.2. Physical Access Architecture and Design

In order to align with the ICAM segment architecture, agencies should design and implement an

enterprise-level, modernized PACS. This approach presents agencies with an opportunity to

increase efficiency, improve interoperability, and reduce costs. As an agency designs its

modernized physical access architecture, it should address the capabilities included in the ICAM

Services Framework (Section 3.2.4), as well as the existing PACS infrastructure.

This section provides a solution architecture diagram, discusses the components that comprise a

modernized PACS, and introduces common characteristics that an agency should consider when

designing its target state PACS. This section is targeted largely at enterprise and solution

architects who are responsible for the design of an agency‟s upgrade efforts. The information and

guidance provided in this section is intended to provide answers to several common PACS

architecture and design questions, including:

What does a modernized PACS infrastructure, compliant with the ICAM target state,

look like?

What are the components of a modernized PACS infrastructure, and how do they support

achievement of the ICAM target state?

What common characteristics should I consider when designing a PACS solution?

10.2.1. Solution Architecture

The ICAM segment architecture describes the PACS target state as agencies establishing an

enterprise approach to managing physical access that links individual PACS via a federated

network wherever possible. There are a number of ways to achieve this goal; however agencies

should implement a configuration that is cost effective and aligns with their needs and

organizational environment. Additionally, physical security should collaborate with IT staff to

gain consensus on an appropriate system design, since the OCIO has oversight responsibility for



ensuring that all IT systems meet relevant requirements. This section provides a high-level

example of a solution architecture that encompasses the necessary elements of a modernized

PACS. These components represent generic products and are not aligned with a particular vendor

or solution offering. Note that several of the items on the diagram, such as Certificate Authority

(CA) and Authoritative Sources, are common infrastructure components within an agency‟s

overall ICAM infrastructure. Many of these components are also depicted in the solution

architecture for the LACS in Section 11.2.1; however, they should not be viewed as separate and

independent for the two systems but rather as interconnecting. Figure 29 illustrates an enterprise

PACS solution model that incorporates the concepts described in the target state.

Figure 29: Physical Access Solution Architecture

The diagram represents the target state, in which the PACS is no longer a standalone system;

rather it ties into numerous components and provides enterprise physical access authentication

and authorization services. The Enterprise Physical Access Infrastructure represents the core

services of the PACS and includes critical services like central data storage, monitoring, and

control over all of the other components of that system. The enterprise PACS is depicted as a

piece of the larger Security Management System (SMS), which has interconnections with other

physical security elements such as video surveillance systems, intrusion detection, and fire

alarms. The Enterprise Physical Access Infrastructure relies on external interfaces to connect

with the authoritative sources where relevant user and credential information is stored and

maintained. The Enterprise Physical Access Infrastructure administers a variety of field

components, which are distributed system components that directly control access at the local

level. It is anticipated that many agencies will have numerous field components from multiple

vendors. In the target state, these devices and subsystems do not necessarily need to be replaced

with a single vendor product, but should be linked to an agency‟s PACS services at the enterprise



level. The diagram depicts an electronic VMS that is integrated with the Enterprise Physical

Access Infrastructure. The VMS is an optional element of the physical access solution

architecture; however, incorporating an electronic VMS into the enterprise PACS solution may

enable additional automation and cost savings. Some agencies may implement a PACS solution

in which visitor management is included as a part of the overall system or an agency may choose

to develop an independent VMS.

FAQ

If the PACS server is hosted by the enterprise and not at my site, how do I know that it is secure?

When PACS services are provided at the enterprise-level, servers are hosted at high-security areas with redundant information back-ups, high network availability, and robust disaster recovery protocols. The service level agreement for hosting of the system details the security controls and procedures in place. The hosting facility is also subject to FISMA auditing requirements to ensure adherence to security requirements.

10.2.2. Solution Components

Figure 29 illustrates the various components that comprise an enterprise PACS solution. This

section identifies those individual solution components and describes the functionality of each.

Section 10.2.2.1 discusses the components that make up the Enterprise Physical Access

Infrastructure, Sections 10.2.2.2 through 10.2.2.4 make up the field components, Section 10.2.2.5

provides an example of a component commonly included in external interfaces.

10.2.2.1. PACS Server

The PACS server is an administrative tool used by the PACS operator to provision and de-

provision access to a variety of physical resources, control and configure downstream access

control and alarm devices in the system, journal all system activities, and execute security-

related decisions. The PACS server is also typically the primary data source where a cardholder

is enrolled or registered in the Cardholder Database (depicted separately in Figure 29). In the

target state architecture, identity and credential data associated with the cardholder should be

provisioned to the cardholder database from authoritative enterprise data sources. The server

downloads cardholder record data and associated privileges to the relevant access control panel

and serves as an access decision resource when a field panel is presented a card that is not

currently stored in the panel database.

In a modernized PACS, the server communicates with the federated PKI infrastructure to offer a

high level of trust in the identity assertion made by the person presenting the card to the system.

Additionally, PACS servers in the target state become consumers of a user‟s authoritative digital

identity and card information, which is provisioned from the agency‟s authoritative data sources

(ADS).

Implementation Tip

PACS servers can be managed by the agency at the enterprise level or by a service provider using cloud computing approaches. This model, called Security-as-a-Service, involves a technology provider hosting the security management applications on behalf of the end user. This arrangement allows agencies to leverage the cost savings, flexibility, and ease-of-deployment and eliminate the server and storage infrastructure at each individual site.



10.2.2.2. Workstation

The workstation is subordinate to the PACS Server and provides administrative functions to

manage the PACS. In an enterprise network with a network-centric PACS, a workstation can be

placed where needed and connected to the network in order to operate in conjunction with the

PACS Server. Some of the typical functions controlled at a workstation are adding or removing

cardholders and credentials from the PACS, downloading cardholder data, and setting access

levels and functions of the field components. They may leverage thin clients using browser

interfaces only, or use thick clients that use locally installed software.

Implementation Tip

Close coordination with network administrators is required to successfully integrate workstations as part of the Physical Access Control System (PACS) solution. PACS implementers should coordinate with IT resources to help determine workstation location and set up network connectivity.

10.2.2.3. Controller/Panel

The controller/panel makes access control decisions and is connected to the PACS server, card

reader and door hardware. It contains a number of cardholder records, usually one per

cardholder, which typically consists of a cardholder record number, a cardholder photograph, a

unique identifier (card number), a list of authorized access points, and a time when access is

authorized. When a card is placed on a reader, the controller/panel receives the information and

compares this to data stored in its local database. Once the controller/panel determines that the

data is valid, it authenticates the cardholder with the credentials held on the card and makes an

access decision with the information coming from the reader. This decision is based on

credential revocation status, day of the week, time of day, and door location. The controller/panel

sends the decision result to the access control server for display and archiving. When the

controller/panel makes an access grant decision, it sends a signal to release the door locking

mechanism and disarm associated alarm sensors, such as door position monitors. Access control

data is stored locally so that the controller/panel can continue to operate during periods when

panel-server communication is interrupted. Controller/panels also have battery backups for

operation during times of power loss.

There are some PACS that operate without a controller/panel by connecting a variety of standard

reader types directly to a network through Internet Protocol (IP) bridges. This type of

architecture might typically be found in PACS architectures leveraging a Security-as-a-Service

model.

10.2.2.4. Card Reader

A card reader is the device located at an access point to provide access control. A card reader

may support communication with either the contact or contactless interface of the card, or in

some cases support both. A target state card reader should support bi-directional communications

with the system, processing the data and instructions from the card, sending the data to the

associated control panel, and receiving data and instructions back from the control panel within

an acceptable time frame.



Implementation Tip

Ensure that environmental factors are taken into consideration when designing your agency’s PACS, particularly when deciding what types of card readers to purchase. Environmental factors, such as exposure to weather conditions, can impact the successful use of a card reader through the contact mode. An agency may need to deploy additional equipment, such as a protective cover, in these scenarios.

In the target state, it is likely that a card reader will need to read and communicate various data

from the card in order to support transactions that use multiple authentication modes, including

Cardholder Unique Identifier (CHUID) and PKI authentication. There are a number of card

readers that are approved by the FIPS 201 Evaluation Program65

that can support various

transaction types in the target state. As an agency selects card readers for purchase, it is

important to ensure that the card reader chosen is capable of supporting the desired PIV

authentication mechanisms at a particular access point, as not all card readers support all

authentication mechanisms.

Implementation Tip

When selecting to use an “edge reader” or “IP reader,” it is suggested that agencies choose the two part variety. This ensures that the controller function and IP port are located on the secure side of the wall, opposite the reader.

10.2.2.5. Cardholder Provisioning System

A Cardholder Provisioning System is an example of an external interface that integrates between

a PACS and an agency‟s authoritative identity source(s) for the purpose of provisioning user

accounts and their associated card data to the PACS. The use of a Card Provisioning System

represents a shift in the target state, where the PACS is a consumer of identity and card

information. As such, there are a number of approaches that an agency can take to provide this

functionality within its PACS architecture. These are discussed in greater detail in Section

10.3.1.

10.2.3. Common Design Characteristics

In addition to identifying a solution architecture and the supporting components, agencies should

have an understanding of the common design characteristics necessary to successfully implement

a modernized PACS. Figure 30 describes, at a high level, the characteristics that agencies should

consider when designing a PACS solution that meets the target state. It is important for agencies

to make design decisions that are in line with their specific needs and relevant policy.

PACS

Characteristic

ID

PACS Solution Characteristics

PACS 1 Easily integrated into a centralized management and control system that combines access control with intrusion detection, event monitoring, and integrated video capabilities.

PACS 2 Supports access to its functionality through both a web-based native user interface and a programmatic application programming interface (API).

65 For more information on the different types of card readers, refer to the FIPS 201 Evaluation Program

http://fips201ep.cio.gov/



PACS

Characteristic

ID

PACS Solution Characteristics

PACS 3 Capable of validating the PIV card in accordance with the authentication mechanisms defined in NIST SP 800-116.

PACS 4 Supports validation of other credential types, as necessary, during migration stages to full PIV card implementation for physical access.

PACS 5 Provides middleware system(s) that seamlessly integrate the path validation of certificates required by FIPS 201.

PACS 6 Uses path validation to completely authenticate and validate the security relevant data objects within the PIV card and PIV-Interoperable Cards.

PACS 7 Provides system components that adhere to the Backend Attribute Exchange (BAE) Specification and are IPV6 addressable.

PACS 8 Provides a system controller that, with algorithms, will enforce all the rule checks prior to allowing access.

PACS 9 Adheres to the protocols and architecture recommended in chapter 10 Initiative 7: Modernization of PACS, requirements.

PACS 10 Uses PKI certificates as a basis for system administration and visitor management between trusted organizations.

PACS 11 Included within the FISMA Inventory of an organization.

PACS 12 Allows decision making logic to be local, rapid, located within the secure perimeter, and not dependent on a remote server.

PACS 13 Federated or synchronized with other identity stores that are used for logical access and other aspects of personnel management.

PACS 14 Consume and process credentials that were produced by authorities independent of the PACS, such as PIV and PIV-I cards.

PACS 15 Read and extract the full CHUID from the PIV card, and recognize within the controllers and server software.

PACS 16 Allows the PACS server authorization database to update access changes for affected user records in local PACS panels.

PACS 17 Provides a Personal Identification Number (PIN) entry method to the PIV card.

PACS 18 Requests and receives the PIV Authentication Certificate from the card, sends data to external PKI infrastructure [Online Certificate Status Protocol (OCSP), Server-based Certificate Validation Protocol (SCVP), Certificate Revocation List (CRL)], and if valid, send to PACS server authorization database.

PACS 19 Allows the PACS authorization database to integrate to external PKI infrastructure and perform automatic validation of all registered PIV Authentication Certificates.

PACS 20 Continually checks and updates credential status after the cardholder’s credentials are determined as valid and enrolled in a PACS.

PACS 21 Provides PACS server software and associated downstream hardware (controllers) that are web services-based in order to allow for more efficient customization to end-user requirements and integration into middleware and external systems components, including LACS.

PACS 22 Provides a capability to automatically change access level requirements for doors and portals according to preset Threat Condition levels.

PACS 23 Provides a capability to verify against an internal or integrated external watch list66

database when a card is presented to a reader for access. Ideally, the watch list should be stored both in the PACS server and controller.

PACS 24 Provides a capability to compile reports with data from access records.

Figure 30: Common PACS Design Characteristics

66 Watch list is used as a general term for a list of individuals to whom access should not be granted.



10.3. Physical Access Technical Implementation

Implementing a modernized PACS in alignment with the ICAM segment architecture introduces

several system changes and complex challenges. This section discusses two areas that represent

the biggest departure from the current state: automated provisioning and enabling the use of PIV

card authentication mechanisms as recommended per NIST SP 800-116. This section is targeted

largely at those individuals responsible for implementing and overseeing the technical execution

of an agency‟s PACS modernization efforts.

Lesson Learned

Direct guidance and “how-to” information will help implementers and provide consistency throughout the agency’s PACS modernization effort. For example, a large agency created a “field guide” to help its bureaus/components incorporate PIV-enabled solutions into their logical and physical access controls. It provides information on the tasks for preparation, the resources and tools that have been successfully used in implementation, and gives guidance on how the bureaus/components may best manage and execute the implementation.

10.3.1. Automated Provisioning to PACS

Automated provisioning to PACS has developed into an important aspect of consideration for

those who manage and maintain those systems. Automated provisioning of an individual‟s

digital identity into a PACS helps to address system resource management issues and several

overarching security concerns including, but not limited to:

Ensuring that an individual‟s user record is based on authoritative identity data;

Providing system administrators the ability to better manage their PACS databases and

keep records current; and

Allowing for centralized and automatic de-provisioning when an individual separates

from an agency.

Traditionally, the data elements needed to create an authorized cardholder within a PACS

database have been entered manually. In addition, the procedures for determining how someone

is granted access are disparate across the government and even within a single agency. This has

led to the realization that a set of standard data elements within a digital identity should be

available to the PACS for the creation of a cardholder profile. An agency will benefit from the

standardization that results from having the PACS populated with an established digital identity

from authoritative source(s). Additionally, the development and deployment of centralized

automated provisioning capabilities support achievement of Transition Activity 7.4, as discussed

in Section 5.2.2.3.

The target state of a modernized PACS is to realize a singular digital identity, which can be

added to, modified, and deleted by one or more ADS, as determined by each agency. The

complexity of the digital identity is dependent upon the size of the agency, the facilities to be

covered, and existing architecture in place to support the effort. The target state should be

supportive of a single digital identity being created and maintained at the agency level for

distributed cross-system use, a concept commonly referred to in the physical security community

as “single enrollment, many uses.”

Figure 31 compares commonly available automated provisioning approaches.



Approach Description Benefits Limitations

Integrated

Provisioning

Capability

A full automated provisioning capability that leverages a real time connector using open standards (i.e. extensible markup language (XML)) and enables two-way communication between the PACS and authoritative sources.

Significantly less level of effort for enrollment to PACS

Minimized development costs

Standardized naming conventions

Reporting capability

Works well if agency has a variety of vendors

More options for federation of PACS control into the enterprise

Security personnel have assurance that data integrity is maintained across the entire landscape of PACS

Provides the connected PACS with the most current cardholder account information, including access privileges

Provides a robust and flexible, oftentimes web-based, interface that can access data from the connected PACS in a seamless and intuitive fashion

Can function as a central point of revocation of cardholders’ accounts, further increasing an efficient security posture of the organization

Maintains connections on a near real-time basis using resource connectors or service interfaces

Often reliant on software vendor after installation for maintenance

Must maintain connectivity through real-time connectors or system interfaces to update systems

Upgrading software can be costly

Vendor

Interfaces

Leverages custom scripts written by a vendor using APIs and Software Development Kits (SDKs).

Allows data sharing between two systems on a long-term basis

Utilizes existing systems SDKs and vendor expertise

May be more open/flexible than batch processing

Pre-set schedules/time intervals for the transfer of new data/enrollments

Higher level of quality assurance with data integrity during data transfer than offered in the single-use option

Many current PACS and some legacy systems provide this option

Properly developed scripts are typically functional across a broad range of software versions

Incomplete mapping of cardholder information

Real time operation depends on vendor

Depending on vendor may require heavy investment

Multiple systems would increase complexity in cross-system cardholder record integrity

May create inconsistency among systems which can negatively impact security

Batch

Processes

Leverages a single-use scripted data transfer.

Is easy to implement when transitioning from a legacy PACS to a new access control system

Can utilize existing custom infrastructure

Minimized effort through targeted

May not completely eliminate manual operations as part of provisioning process

Complexity may increase database management issues

Possible difficulty in validating



Approach Description Benefits Limitations

scripts based on requirements

More flexible to meet particular agency requirements or unique existing infrastructure

data transfer

Generally used for one-time data transfer

No recurring data transfer as data changes in the authoritative source

Does not guarantee the quality and uniqueness of imported cardholder accounts

A scripted process is generally only functional within a small range of software versions

There can be disconnects between the individuals who build the data transfer script and those who are familiar with the PACS system itself

A significant time investment may be required to ensure cardholder accounts properly reflect the individuals they are representing

Figure 31: Comparison of Automated Provisioning Techniques

10.3.2. Common Physical Access Scenarios

A primary focus of the PACS modernization implementation is the capability for agency PACS

to electronically authenticate the PIV card in accordance with mechanisms specified in NIST SP

800-116. Using the PIV card for physical access offers an agency the opportunity to align with

the ICAM segment architecture and realize the enhanced security benefits of the authentication

mechanisms on the PIV card. For example, agencies can achieve a level of trust in the claimed

identity of the person presenting the PIV card as a result of authentication and validation

processes.

This section introduces each of the allowable PIV card authentication mechanisms for PACS,

discusses where it is appropriate to use each, and outlines the benefits and limitations associated

with each. An agency PACS cannot be considered PIV-enabled if it not leveraging the

authentication mechanisms contained in this section in accordance with the guidance in SP 800-

116.67

Specifically, use of the PIV card with legacy technologies (e.g., proximity antennas,

magnetic stripe, barcode, etc.) does not meet the intent of the ICAM target state and this

guidance. As its PACS implementations mature, it is also recommended that an agency move

towards the stronger authentication mechanisms, such as cryptographic authentication using the

PIV Authentication Key (PKI) as described in section 10.3.2.3.

67 Per OMB M-10-15, FY 2010 Reporting Instructions for the Federal Information Security Management Act and Agency Privacy Management, April 21, 2010.




Note: The ICAMSC Architecture Working Group is currently developing a supplemental

guidance document, the Federated PACS document, which addresses additional technical

content including variations of the PIV card authentication mechanisms, the potential security

attacks associated with each, and additional recommendations for selecting between

authentication mechanisms. It is anticipated that this section will be updated with further

detail once that document has been published.

10.3.2.1. CHUID Authentication

The CHUID is a mandatory data object on the PIV card, which includes the Federal Agency

Smart Credential Number (FASC-N) element that uniquely identifies the card. The CHUID is a

free-read data object that is available on the contactless interface of the PIV card. Of the

available PIV card authentication mechanisms, it is more closely aligned with legacy PACS

operations, which read and compare a number from the card against the PACS user database. In

the initial stages of an agency‟s PACS modernization effort, CHUID authentication is considered

a viable approach based on its relatively easy incorporation into existing PACS systems and

implementations; however, the CHUID is a weak one factor authentication method and should

only be used in the target end state for areas identified as having extremely low risk following a

careful facility risk assessment.

Implementation Tip

Educate your users on proper PIV card storage and handling. Improper storage or handling can break the contactless interface on the card, preventing use of certain authentication mechanisms, such as the CHUID, in your PACS and driving up program costs for replacing damaged cards. Failing to properly store the PIV card in its electromagnetically opaque holder when not in use can also increase security risks for the skimming of card data.

The CHUID numbering scheme is standardized by FIPS 201 and can be counterfeited easily;

however, modifications or alterations to a CHUID can be detected by validating the digital

signature of the Issuing Agency across the CHUID object. As indicated in SP 800-116, all PACS

access decisions are based on utilization of the complete FASC-N; therefore it is important that a

PACS be able to read at least the full FASC-N data subset. The FASC-N represents a viable

authentication mechanism for rapid access at high throughput access points due to the

abbreviated read of the CHUID. Additionally, PACS that cannot read the full FASC-N lose

uniqueness and risk data collisions. Based on the benefits and limitations listed in Figure 32 and

the recommendations found in SP 800-116, agencies may choose to leverage CHUID

authentication at access points separating two areas at the same impact level, either Controlled or

Limited. Agencies may also use the CHUID authentication mechanism, when paired with a

visual (VIS) authentication mechanism, at access points between Unrestricted and Controlled

areas.68


If the CHUID signature verification is performed, the PACS can be sure the CHUID came from a valid issuer and it has not been altered.

The CHUID read presents the simplest implementation alternative when migrating from legacy PACS.

The CHUID is a free read object on the PIV card; therefore it can be cloned.

Because of the risk of CHUID counterfeiting or cloning, the CHUID authentication mechanism, used in isolation, provides a confidence level that is

68 A description of the area types mentioned in this section can be found in Section 10.1.2.




In comparison with other mechanisms, the CHUID offers the smallest data read on the PIV card.

comparable to proximity cards in widespread use today.

To achieve single-factor authentication with CHUID, the relying parties must validate the signature on the CHUID.

Legacy technology cannot always accurately read the full CHUID, which can result in data collisions.

The CHUID with signature validation authentication method can only be used to enter controlled areas.

There is no standard for checking revocation status of a CHUID.

Figure 32: Benefits and Limitations of CHUID Authentication in PACS

10.3.2.2. CAK Authentication

Card Authentication Key (CAK) authentication involves verifying a claimed identity through

validation of a digital certificate on the PIV card issued by a trusted CA.

The CAK method is characterized by the following:

It may be used on either the contact or contactless interface, which is desirable in many

PACS implementations;

It does not require the entry of the PIN;

It allows the PACS to determine the validity of certificates in real time or by pre-

validating the certificates and storing the information in a cache;

It leverages asymmetric key cryptography,69

to perform certificate validation;

It is an optional certificate, and may not be present on all agency cards, which could

impact interoperability; and

It provides single factor authentication, and thus is appropriate only for access to

controlled areas, unless used in combination with another authentication factor.

The CAK authentication of the PIV card represents a stronger alternative than standard CHUID-

based authentication while meeting throughput expectations at facility access points.

Furthermore, SP 800-116 recommends that the asymmetric CAK authentication mechanism be

used instead of the CHUID authentication mechanism to the greatest extent practicable. Based on

the benefits and limitations of CAK authentication, agencies may choose to implement this

mechanism at access control points between Unrestricted and Controlled areas. When used in

combination with attended biometric authentication, CAK authentication provides three-factor

authentication and can be used at access control points between Limited and Exclusion areas.


CAK provides a higher assurance mechanism while still retaining the contactless capability.

Cached certificate validation can provide rapid authentication with an inherently stronger validation compared to a standard CHUID read.

Real-time certificate validation can provide strong authentication as it only relies upon the refresh rate of the published CRL.

Certificate validation technology can be marginally slower than a CHUID validation technology dependant on product selection.

Cached certificate results do not validate certificates in real-time, certificate status is based on PACS server to CRL refresh and server to panel refresh timeframes.

Real-time certificate validation technology can

69 While outside of the scope of this discussion, NIST does permit the CAK on a specific card to be symmetric. Agencies should note, however,

that this approach is based upon use of a shared secret and is not considered an acceptable approach for using the CAK validation mechanism in the ICAM target state due to security and interoperability concerns.




require a longer read time when compared to a standard CHUID or cached certificate read.

Not a native capability of many existing and available PACS systems, resulting in additional implementation costs and challenges.

The CAK authenticates the card, not the individual; therefore it provides only some assurance in the identity of the individual.

Figure 33: Benefits and Limitation of CAK Authentication in PACS

10.3.2.3. PKI Authentication

PKI authentication involves verifying a claimed identity through validation of a digital certificate

on the PIV card issued by a trusted CA. For the PIV card, this may be accomplished using the

PIV Authentication Key.

The PIV Authentication Key method is characterized by the following:

It provides two-factor authentication, since the cardholder must enter a PIN to unlock the

card in order to successfully authenticate;

It is a mandatory credential on the PIV card, and thus will be available on PIV cards of

visitors from other agencies;

Is accessible over the contact interface;

It requires the PACS to determine the validity of certificates when an individual presents

his card to a card reader; and

It may be used for authentication to areas up to and including exclusion areas.

The PKI validation of the PIV card represents a stronger alternative than standard CHUID-based

authentication while meeting throughput expectations at facility access points. Based on the

benefits and limitations of PKI authentication, agencies may choose to implement this

mechanism at access control points between Limited and Exclusion areas.


Cached certificate validation can provide rapid authentication with an inherently stronger validation compared to a standard CHUID read.

Real-time certificate validation can provide strong authentication as it only relies upon the refresh rate of the published CRL.

Certificate validation technology can be marginally slower than a CHUID validation technology dependant on product selection, real-time certificate validation technology can require a longer read time when compared to a standard CHUID or cached certificate read.

Cached certificate results do not validate certificates in real-time, certificate status is based on PACS server to CRL refresh and server to panel refresh timeframes.

Not a native capability of many existing and available PACS systems, resulting in additional implementation costs and challenges.

Figure 34: Benefits and Limitations of PKI Authentication in PACS

10.3.2.4. Biometric Authentication

Biometric authentication verifies an individual‟s identity by comparing the reference biometric

template on the PIV card with the sample biometric template provided at the time of the

transaction. This verification exchange occurs off-card, in the reader or on a server. Every PIV

card contains two fingerprint templates of the card holder in a standardized data format that is



described in NIST SP 800-76. Because these templates are standardized, they provide

interoperability across a federated system. As with several of the other objects on the card, the

biometric on the PIV card is signed by the issuer. It is recommended that the PACS verify the

digital signature on the biometric template data object to check the authenticity of the biometric.

PACS readers that incorporate biometric technology, supporting software, and hardware logic

are commercially available and utilized across multiple federal agencies. As a general premise,

biometric access points provide a higher level of authentication at the expense of a reduction in

throughput as biometric authentication requires a contact interface with cardholder PIN input.

Based on the benefits and limitations listed below, agencies may choose to leverage biometric

authentication at access points between Controlled and Limited areas When biometric

authentication is performed in the presence of an attendant (BIO-A), it mitigates the risk that the

user is presenting a fake card or fake or synthetic fingerprints that could falsely be accepted by

the reader. For this reason, BIO-A may be used at access control points between Limited and

Exclusion areas.


The biometric on the PIV card is signed by the issuer, so the authenticity of the biometric can be validated by the PACS.

Current biometric technology demonstrates low crossover error rates in NIST Minutia Exchange (MINEX) testing.

The 1:1 biometric match represents the closest cardholder to PIV card validation possible.

Provides mitigation against fraudulent authentication attempts with synthetic fingerprints when conducted in BIO-A mode.

Biometric authentication cannot be used on the contactless interface.

This authentication mechanism by itself does not include authentication of the PIV card.

Slower transaction time due to requirement for use of contact interface and user PIN entry.

Biometric readers may not be viable at external access points, where environmental conditions can cause rapid equipment deterioration.

Figure 35: Benefits and Limitations of Biometric Authentication in PACS

The FIPS 201 standard restricts access to the reference biometric fingerprint data stored on the

PIV card to transactions on the contact interface following PIN entry. This requirement presents

a challenge in physical access environments where use of the contactless interface is necessary to

support high throughput requirements (i.e., the time required to enter the PIV card into a card

reader and enter the PIN would create a bottleneck at the access point). In these scenarios, an

agency may consider implementing an approach where the biometric template is read from the

card the first time the card is used at the site, or alternatively in an earlier provisioning session,

and retained in a site-based biometric system with a local database of biometric objects read

from PIV cards.

This approach is viable because FIPS 201 does not restrict the length of time that an application

may retain the biometric object from the PIV card; however, it is critical to note that the

biometric object must be checked against the CHUID expiration date on the card, per SP 800-

116. When a card is presented for biometric authentication, the CHUID is read from the card,

and the FASC-N from the CHUID is used to look up the biometric object in the local database;

the expiration date from the CHUID is then checked to make sure the biometric object is still

valid. Following successful validation, the cardholder‟s live biometric sample is compared

against the biometric object.

Another potential challenge for using biometric authentication is environments where use of the

fingerprint biometric modality is not feasible, such as instances where fingerprints are



unavailable for a significant portion of the user population or environmental conditions at the

access point do not allow for an acceptable fingerprint capture. In these cases, an agency may

wish to implement an alternate biometric modality, such as iris. It is recommended that an

agency only pursue this approach in the extremely rare case where authentication cannot be

supported by another PIV authentication mechanism, as this approach incurs additional

administration costs and effort to collect, manage, and protect additional biometric data. Because

this approach requires locally-enrolled data to successfully complete the access transaction, it

also significantly limits interoperability, which is a key objective of the ICAM segment

architecture.

10.3.2.5. Multi-factor Authentication

As noted in the ICAM segment architecture, multi-factor authentication involves a combination of

three distinct types of authentication factors: a) something you have, in this case, a PIV card, b)

something you know, knowledge of the PIN to access protected areas of the PIV card, and c)

something you are, cardholder fingerprint comparison with biometric data stored on the card. Several

of the PIV card authentication mechanisms, including reading a signed object from the card or

performing challenge/response authentication with the card, only provide validation of possession of

the PIV card (i.e., something you have). Likewise, biometric authentication also only provides a

single factor of authentication (i.e., something you are). Combining different variations of PIV card

authentication provides an agency with the ability to overcome the drawbacks of single-factor

authentication while meeting facility area authorization requirements. As defined in SP 800-116,

two-factor authentication is specified for access to limited areas, and three-factor authentication

is specified for access to exclusion areas. Multi-factor authentication mechanisms should be

commonly leveraged in areas that require higher levels of access control. More information on

possible permutations of multi-factor authentication mechanisms can be found in the ICAM

Federated PACS Guidance.

10.4. Local Facility Access

Note: The ICAMSC Federation Interoperability Working Group is currently developing a

common government-wide approach for handling individuals with a need for sustained facility

access who are not within scope for receiving a PIV credential. It is anticipated that this

section will be updated with further detail once that document has been published.

HSPD-12 requires the use of identification that meets federal standards (i.e., the PIV card) in

order to gain physical access to federally controlled facilities; however, there are certain user

populations that need long-term physical access but may be ineligible for a PIV card (e.g., non-

federal building tenants, interns, visiting scientists etc.). Individuals that fall into these user

populations should be appropriately credentialed and validated in order to maintain adequate

security for all occupants located within the facility.

To meet the credentialing needs of these special user populations and align with the ICAM target

state, agencies should establish a common approach for issuing and accepting local facility

access cards. A local facility access card is an ID card that allows for access to local facilities

through electronic authentication mechanisms. Decisions around which user populations should

receive a local facility access card may be made at the bureau/component or site level, but

agencies should move away from multiple, inconsistent credentials for these populations and

leverage PIV and PIV-I technologies wherever possible.



ROI

Moving toward a common PIV-Interoperable local facility access card for non-PIV populations not only increases security, but also allows an agency to see a greater return on its investment associated with PIV card issuance and other PACS modernization efforts. One large agency found that standardizing local facility access cards and visitor badges across its bureaus/components eliminated redundant credentialing and access control processes and yielded cost savings within their ICAM PACS implementation.

When determining agency policies for local facility access cardholders, access should be limited

to the facility or specific areas within a facility that are appropriate for the individual. For

example, a child care worker assigned to a child care facility might also have access to a

facility‟s cafeteria or external restrooms, if necessary, but should not have unfettered access to

other areas of the building not related to his work assignment.

10.5. Visitor Access

In addition to managing physical access for its employees and contractors using a PIV card or

other affiliates using a local facility access card, agencies may also need to address physical

access for a wide variety of visitors to federal facilities. While it is expected that there will

continue to be a degree of variation in visitor processes and systems due to agency-specific

policy and security requirements, the ICAM segment architecture defines several key aspects of

developing and operating a visitor management capability in the target state. The target state

specifies that agencies move away from manual, paper-based methods for managing visitors and

implement an electronic enterprise VMS capability, leveraging automation wherever possible.

Privacy Tip

Privacy requirements should not be reduced or removed when technology is introduced to an agency’s visitor management procedures. The same privacy protections for paper-based, manual processes should be applied to electronic, automated versions. For example, some electronic visitor management systems (VMS) might offer the ability to scan an individual’s driver’s license to collect personal identifiers instead of having the individual handwrite his/her information. Agencies should ensure that only relevant and necessary information is obtained from the driver’s license and is handled in accordance with their privacy policies.

Agencies must accept PIV cards from visitors from another agency and electronically

authenticate them in accordance with applicable access control procedures. In addition, visitors

with PIV cards from another agency should be provisioned into the hosting agency‟s PACS and

electronically authenticated for access. These efforts will reduce risk, enhance interoperability,

improve efficiency, and positively impact customer service. Agencies should also seek to

leverage their existing infrastructure and accept PIV-I cards from visitors when they are

available.

Implementation Tip

Agencies should enable their security guard force with electronic authentication means wherever possible. This allows security guards to make access decisions based upon reliable, timely information. It also allows them to focus their time and attention on monitoring for other security threats, rather than performing visual authentication of credentials, which can help improve the overall security of the facility.



Agencies should consider a number of factors when designing their VMS capability and visitor

management procedures, including:

Type of visitor. The ICAM segment architecture defines a visitor as an individual

external to an agency who requires access (often short-term or intermittent) to a facility

or site controlled by the agency. This covers a wide variety of visitor types that an agency

may encounter, including federal employees from other agencies, business partners, or

members of the public. Agencies should analyze the visitor population(s) associated with

its facilities, as it may impact system design.

Type of credential/identification used. In most cases, the types of visitors an agency

encounters dictates the type of credential that is available for performing authentication.

For example, a visitor from another agency should have a PIV card, whereas, a member

of the public would likely only have a lower assurance credential available. An agency‟s

visitor management policy should specify what kinds of IDs are acceptable and the

procedures that will be used to authenticate them. Per OMB M-11-11,70

an agency must

accept and electronically verify PIV credentials issued by other federal agencies.

Additionally, as part of the ICAM target state, agencies should be implementing the

capability to accept PIV-I credentials from visitors, where an appropriate trust

relationship exists.

Background vetting. Different visitor types will have been subjected to varying levels of

background vetting. For example, visitors from another agency will meet the minimum

PIV card investigation standards, whereas members of the public may not have any

background vetting. An agency should consider the background vetting of its visitor

populations when determining visitor procedures, such as the requirement for an escort.

Areas to which a visitor requires access. Based on the facility risk assessment, an

agency would likely adjust its visitor procedures if a visitor requires access to an

exclusion area, as opposed to a controlled area. Additionally, access points may need to

be added to separate areas open to facility visitors from more restricted areas.

Visitor pre-registration. The use case for visitor access in the ICAM segment

architecture assumes that visitor access is substantiated by a sponsor, who validates the

visitor‟s need to access the facility or area. Agencies should establish a pre-registration

process to capture this sponsorship and provision visitor credential data, where applicable.

Additionally, many agencies encounter visitors who arrive at reception with no pre-

registration (e.g., members of the public visiting an open cafeteria or credit union).

Agencies encountering this scenario should include it in process and VMS planning.

FAQ

When should I require an escort for visitors at my facility?

Escort requirements should be based on the risk associated with the facility or area which a visitor is accessing. It is recommended that agencies have a consistent approach to escort policies while maintaining flexibility for decisions at the local site level, as each facility may have varying levels of risk.

It is recommended that agencies implement a standard, enterprise-wide approach to address

visitor types, levels of screening associated with these types, and standardized options for visitor

70 OMB M-11-11 Continued Implementation of Homeland Security Presidential Directive (HSPD) 12- Policy for Common Identification Standard for Federal Employees and Contractors, February 3, 2011.




credentials. This approach should incorporate considerations for interoperability, improving

efficiencies in handling large volumes of visitors, and reuse of existing agency investments for

physical access control. The business processes associated with providing credentials to visitors

should also leverage efficiencies and best practices from the processes associated with

established credentialing efforts, such as creation and issuance of PIV cards.

ROI

Leveraging PIV and PIV-I cards from visitors within the Visitor Management System (VMS) and PACS allows an agency to better utilize its investment in PIV card and PACS modernization efforts to incorporate PIV card. Furthermore, an agency can see reduced costs associated with manual, time-consuming authentication procedures for other credential types, which are also typically less secure.

When developing their electronic VMS capabilities, agencies should incorporate the following

common characteristics of a modernized, target state implementation:

Characteristic

ID Solution Characteristic

VMS 1 Supports validation of acceptable credentials of visitors, including PIV and PIV-I, using standard methods for each card type, including certificate checking.

VMS 2 Integrated into or interfaced with an electronic, modernized PACS, where possible.

VMS 3 Supports automatically provisioning and de-provisioning access rights for visitors based on length of stay.

VMS 4 Provides visitor pre-registration capability, where sponsors are able to enter biographic information for visitors, set up meeting times, and notify visitors.

VMS 5 Provides reporting and audit functions.

VMS 6 References the agency’s Watch List and denies access to those included on the list.

VMS 7 Allows security personnel to maintain their Watch List using a receptionist or administrator console.

VMS 8 Supports migration of select current data (or similar) from manual Watch List to VMS.

VMS 9 Supports automatic removal of visitor accounts after a specified period of inactivity.

VMS 10 Provides a central visitor database repository such that visitors do not have to repeat registration processes upon subsequent visits once their attributes have been captured.

VMS 11 Supports an additional level of security through advanced screening and background checks (if necessary).

Figure 36: Common VMS Design Characteristics

Lesson Learned

The value of the PIV card doesn’t have to be limited to sites with an electronic PACS. USDA has created a web-based Card Confirmation Service that allows individuals at smaller field locations to input card data to check the validity of a visitor’s PIV card against the authoritative security database.



11. Initiative 8: Modernize LACS Infrastructure

Initiative 8 of the ICAM Transition Roadmap, as introduced in Section 5.2.2, is an agency-level

initiative that includes activities associated with upgrading LACS to fully leverage the PIV card,

make better use of cryptographic capabilities, and automate and streamline capabilities to

increase efficiency and improve security. A LACS is an automated system that controls a user‟s

ability to access one or more computer system resources such as a workstation, network,

application, or database. A LACS validates an individual‟s identity through some mechanism

such as a PIN, card, biometric, or other token. Based on the selected implementation path, it also

grants or denies user access to resources based on pre-defined criteria, such as affiliation with the

organization, role, or individual privileges granted to further the agency‟s mission. Modernized

LACS implementations are capable of delivering significant value and ROI to federal agencies in

the form of streamlined, validated, and controlled access control processes; easier compliance

with legal and regulatory controls; and reduced administrative burden on resource owners and

administrators.

ROI

By implementing a modernized LACS solution, the U.S. Department of Agriculture (USDA) anticipates being able to reduce its staff currently dedicated to managing user accounts and application access by approximately 70 full-time resources, These functions can now be automated and performed electronically. USDA will be able to eliminate numerous contractor positions and reallocate agency employees to support mission programs.

The guidance provided in this chapter supports achievement of the target state Use Case 10,

Grant Logical Access, and the associated transition activities listed in Section 5.2.2.4. This

guidance primarily focuses on logical access control for internal agency users authenticating with

a FIPS 201 compliant PIV card71

for all resources, regardless of E-Authentication assurance

level.72

The guidance addresses authentication using the cryptographic capabilities of the PIV

card (Authentication X.509 certificate and user PIN); however, other authentication types (e.g.,

PIV biometric authentication) may be supported within an agency.

This chapter is organized into the following three primary sections:

Logical Access Implementation Planning. This section discusses LACS program

governance, investment planning, and schedule planning considerations that are

necessary to properly plan for a logical access deployment within an agency.

Logical Access Architecture and Design. This section describes the architecture,

components, and key design requirements common to LACS solutions and provides

reference architecture diagrams to illustrate how LACS solution components interact with

each other.

Logical Access Technical Implementation. This section covers common technical

considerations for deploying LACS solutions and their supporting infrastructure within

federal agencies, including workstations, servers, and networks.

71 Logical access guidance for external users at all four assurance levels is addressed further in Chapter 12. Initiative 9: Implement Federated

Identity Capability.

72 As specified in OMB M-04-04 and NIST SP 800-63.


http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf



11.1. Logical Access Implementation Planning

Planning for a LACS implementation is similar, in many respects, to planning for any other

large-scale IT program. The far reaching scope of LACS solutions, however, increases the

importance of planning activities to overall implementation success. This section examines

several specific areas that agencies should consider when initiating a LACS implementation

effort, including organizational governance, program funding, and schedule planning. Section

11.2 introduces a high-level solution architecture for achievement of the target state ICAM

segment architecture for LACS and discusses various solution components. This information

may be helpful for understanding the concepts and activities discussed throughout the remainder

of Section 11.1. The OMB memorandum released on May 23, 200873

also provides agencies

with additional guidelines for consideration when planning or updating plans for the use of the

PIV card in their LACS, a central aspect of the ICAM target state.

The information and guidance provided in this section is intended to provide answers to several

common LACS implementation planning questions, including:

How can organizational governance support my LACS implementation effort?

What factors within my agency‟s operational environment should I examine when

determining what type(s) of LACS solution to acquire?

What should I consider when building my LACS business plan?

What activities should I be aware of when planning a LACS implementation?

How can I secure program funding for my LACS modernization effort?


For many agencies, modernization of their LACS infrastructure in accordance with the target

state ICAM segment architecture may require changes to existing policies, processes, and

technologies. Chapter 6 introduces a variety of techniques for governing an agency‟s ICAM

program, including the modernization of LACS solutions. This section is intended to supplement

that guidance and highlight specific areas that agency governance bodies should seek to address

at an enterprise or component/bureau level to enable successful LACS modernization efforts.

Many federal agencies have existing policies that determine requirements, processes, and

technologies for controlling access to internal IT resources. As part of the LACS modernization

planning effort, agencies should evaluate their logical access policies and identify potential gaps

where revisions, updates, and new policies and/or standards are needed to drive the process and

underlying technology changes identified in the target state ICAM segment architecture gap

analysis for logical access. As outlined in Section 6.1.1, agencies may need to consider

establishing working groups and/or cross functional teams within the overall ICAM governance

structure to directly support LACS projects. This approach ensures that a responsible party is

established to evaluate, manage, and maintain LACS policies and procedures over time.

Updates to existing policy or creation of new policy, where appropriate, can help agencies

overcome many of the internal hurdles and challenges that most often hinder implementation

efforts. These challenges are particularly prevalent with LACS modernization efforts as their

success is heavily dependent on adoption and use at the user and resource level. Policy and

73 Guidance for Homeland Security Presidential Directive (HSPD) 12 Implementation, May 23, 2008.

http://www.cio.gov/Documents/guidance_hspd12_05-23-2008.pdf



governance structures are key enablers of ensuring enterprise adoption of LACS solutions, which

is critical if they are to achieve their desired outcome.

While each agency is unique in the maturity of its logical access policies, relative to the ICAM

target state, there are a number of common topics that should be incorporated to support LACS

modernization. Figure 37 includes a list of the common governance efforts and describes how

agencies might consider utilizing them as a means to support compliance and overcome

implementation hurdles.


Issue Policy Memorandum: Continued Implementation of HSPD-12

Agency-level policy, as required by OMB M-11-11,74

that includes provisions for several items related to LACS modernization, including:

Enforcing use of the PIV card for authentication to networks and applications.

Procurement of services and products for LACS in accordance with OMB M-06-18

75 and the FAR.

76

Acceptance of PIV credentials issued by other federal agencies for logical access.

Alignment with the ICAM segment architecture, including completion of an agency transition plan that includes information regarding the agency’s LACS modernization.

Common Logical Access Scenarios Policy or procedural guidance reflecting formal agency-level decisions for handling common logical access problem scenarios, such as granting access when a user forgets/loses PIV card or forgets PIN, requires mobile/remote access and does not have access to a smartcard reader, and hardware malfunction preventing use of PIV Card.

Define Agency Level Security Benchmarks

Procedural guidance for agencies to implement additional security benchmarks, beyond federal standards and guidance, for internally owned and operated IT resources to require use of LACS services and authentication mechanisms.

Identify Funding Incentives Effort to provide funding incentives for bureau/component pilot implementation participants helping to develop and improve enterprise LACS services to offset the costs of any required updates to applications or infrastructure.

Define Roles and Responsibilities for Cross Functional Working Groups

Effort to establish roles and responsibilities for cross functional working groups to facilitate collaboration and achievement of stated objectives between members from multiple groups, offices, and bureaus/components within the agency.

Define Enterprise Data and Attribute Format Standards

Effort to define standard data formats for identity and entitlement attributes to streamline provisioning and application integration processes. Agencies should leverage the guidance provided in Chapter 7 when completing this activity.

Determine Trusted Authoritative Sources (e.g., HR, Personnel Security, Payroll, Contracts, IDMS, or other systems)

Effort to define authoritative sources for identity and entitlement attributes to ensure access to accurate, reliable information. Agencies should leverage the guidance provided in Chapter 7 when completing this activity.

74 OMB M-11-11 Continued Implementation of Homeland Security Presidential Directive (HSPD) 12- Policy for a Common Identification



76 FAR Subpart 4.13- Personal Identity Verification,







Determine Core User Identity Attributes

Effort to define a core set of attributes that are required to uniquely identify an individual at an enterprise level to ensure consistency between the authoritative sources, LACS infrastructure, and IT resources. Agencies should leverage the guidance provided in Chapter 7 when completing this activity.

Define Baseline User Privileges for IT Access

Effort to define a set of baseline user privileges for IT access can be accomplished at various levels within the enterprise and should be considered where significant efficiencies can be achieved. When tied to an automated provisioning capability new users can be granted access to a large number of applications automatically, based on a well defined set of baseline needs.

Define a Stakeholder Messaging Strategy

Effort to develop a Stakeholder Messaging Strategy, which allows an agency to identify stakeholders and understand their individual motivations, and business drivers. Knowing these characteristics allows an agency to tailor multiple custom messages, which will improve adoption and overall buy-in. This strategy supports development of a Communications and Outreach Plan once the implementation begins.

Define a Job/Work Displacement Strategy

Effort to develop a plan to rotate/reallocate staff members whose positions may be automated (i.e., electronic account creation) as part of the LACS modernization effort.

Define Agency-level Privacy Requirements

Effort to assess whether existing privacy and data protection requirements/guidelines are sufficient to address privacy concerns associated with LACS automation and data sharing or if additional privacy requirements are needed for specific LACS services.

Figure 37: Sample LACS Governance Efforts

11.1.2. Program Funding

Logical access control deployments require adequate planning and consideration to ensure that

an agency achieves the best possible value for its investment. As noted throughout this chapter,

LACS projects offer agencies the potential to realize significant ROI in the form of cost

avoidance, reallocation of resources, productivity gains, and reduced administrative burden. In

order to achieve these benefits, an agency should evaluate its organizational structure, identity

stores/repositories, access control processes, and IT resources when planning new or modifying

existing LACS investments. This section discusses these considerations in greater detail and

examines the impact that these items may have on funding for the LACS implementation.

Additionally, the considerations discussed below provide an agency with guidance for evaluating

its own organizational factors to determine what LACS solution architecture best meets its needs.

In order to select an appropriate LACS solution that supports the agency mission and business

goals, agencies should look beyond the up-front costs associated with LACS investments. There

are additional factors that should be evaluated at an organizational and LACS project level when

determining what type of LACS solution best meets the organization‟s needs. The items

provided in Figure 38 are examples of common factors and considerations that agencies should

examine not only to determine implementation cost, but also determine the potential benefits that

various LACS solutions are capable of providing.


Organizational Size The number and type of users requiring access to agency IT resources, as well as the frequency of turnover of users, significantly impacts the level of administrative effort required to provision user accounts and manage access privileges.




Cost Effectiveness Agencies need to evaluate the ROI that their agency would gain compared with the upfront investment costs when planning for a LACS investment. Those agencies that would achieve low or negative ROI if implementing an enterprise-level LACS solution may opt for a variation on the architecture presented in Section 11.2.1.

Complexity of User Population Organizations with complex user and role management requirements should consider LACS solutions that offer services in these areas. User management complexity represents an opportunity to streamline existing processes or, potentially, an area that could significantly increase implementation costs. Additionally, the availability (or lack thereof) of user repositories can impact implementation costs.

Number of IT Resources The number of IT resources within an agency often dictates implementation time and can significantly affect implementation cost, depending on the resources’ connection requirements.

Type of IT Resources The type of IT resources varies based on the platforms, operating systems, products, databases, etc. that are in use across the organization. These variances impact the complexity of integrating resources with the LACS infrastructure and require different integration processes.

Complexity of Integrating with IT Resources

Resource integration complexity is a combination of several factors, including: age of resource, underlying infrastructure, operating requirements, and user base. Combined, these factors among others indicate how complex it is to integrate particular resources into the modernized LACS infrastructure. Large numbers of complex resources (including mainframe applications) can rapidly increase overall implementation costs. At a high-level the complexity and cost associated with common application types can be grouped as follows:

Web Based Applications – Low to Moderate Complexity

Client/Server Applications – Moderate to High Complexity

Distributed Applications – Varied Complexity

Mainframe/Legacy Applications – High to Very High Complexity

Business Goals/Drivers Internal agency policies and business needs as well as required compliance with external federal policies and regulations drive organizational requirements for LACS solutions. Certain solutions, while inexpensive, may not always create long term cost savings and may prohibit the organization from meeting certain business goals.

Workflow Requirements Agencies should examine the complexity of various manual and semi-manual workflows that are used to provision user accounts and access privileges to IT resources. The number and complexity of an agency’s workflows impacts the schedule and labor costs associated with implementing some LACS solutions.

Organizational IT Infrastructure Specific platforms and operating environments, particularly ones that leverage legacy products, may require additional support and/or custom configuration to achieve the maximum benefit from LACS solutions. This also includes potential costs associated with networking LACS components, high-availability components, etc. Additionally, environments that utilize non-standard Operating Systems may require additional investment to integrate to a modernized LACS infrastructure.

Vendor Product Compatibility and Interoperability with Existing Infrastructure

While it is not required for agencies to purchase a COTS Identity Access Management (IAM) product suite, agencies considering this option for modernizing their LACS infrastructure should evaluate the integration approach of these products to ensure interoperability, and identify and determine a best fit for their current infrastructures, applications, and business needs. Additionally, the availability of enterprise software licenses should be investigated, as these can significantly lower acquisition costs and influence an agency’s make or buy decision.




Existing LACS Investments Agencies may have existing investments in place that are capable of providing logical access services in a manner consistent with the target state ICAM segment architecture. These investments should be leveraged wherever possible and offer the potential to achieve a modernized LACS state without requiring significant investment from the organization.

Bureau/Component Level Application Integration Needs

Many agencies contain multiple bureaus/components that perform an array of mission-specific services. Often, these bureaus house IT resources that are used throughout the organization. Agencies should evaluate their internal structure to determine how LACS services can be provided to bureau resources. This could be done at an enterprise level or de-centralized at the bureau level based upon bureau-specific needs.

Prioritized Logical Access Services

When examining logical access needs, many agencies will recognize that large efficiencies and ROI can be achieved by prioritizing deployment of certain access control services. This will be dependent on the agency’s infrastructure and existing LACS investments, but should be considered when determining how to modernize LACS across the enterprise.

Figure 38: Common LACS Funding Considerations

The factors discussed in Figure 38 provide a baseline for agencies when determining what type

of LACS solution is best suited to meet the organization‟s unique needs. When making such a

determination agencies should seek to strike a balance between the up-front investment costs,

long-term potential cost savings, and ability to meet the organization‟s overall business

objectives to arrive at a total cost of ownership. The total cost of ownership is used to

realistically forecast LACS solution ownership costs in terms of 1-, 3-, and 5-, year cycles in

order to provide an accurate assessment of the solution‟s impact and benefit. This can be

accomplished through completion of a detailed cost/benefit analysis, which is generally

conducted as part of an organization‟s business and investment planning process.

11.1.2.1. Building a Business Plan for LACS Modernization

Using the factors discussed in Figure 38 along with others identified within the organization,

agencies should complete a cost/benefit evaluation and develop a business plan to outline the

selected LACS implementation approach, timeline, resource requirements, and estimated costs

necessary to complete a modernization of their LACS infrastructure. Completion of a LACS

business plan supports achievement of Transition Activity 8.4, as discussed in Section 5.2.2.4.

Implementation Tip

In order to justify the agency’s investment in an enterprise LACS solution, the General Services Administration (GSA) developed a detailed business plan that outlined the current access management situation, upcoming regulatory requirements that define the need to modernize, and discussed the various implementation alternatives at the agency’s disposal before arriving at a recommended implementation approach to best meet the agency’s current and future access management needs.

Many federal agencies have existing tools and templates designed to support development of

business plans for IT investments. The guidance presented in this document does not seek to

influence basic business plan development processes; however, it does highlight several

important factors and considerations, specific to LACS. The following list includes items and

areas that should be closely evaluated when constructing a business plan for a LACS

modernization effort, and weighed by key decision makers.



Alternatives Evaluation. There are a multitude of ways to modernize an organization‟s

LACS infrastructure, including a variety of solution alternatives and implementation

approaches. An effective business plan should thoroughly evaluate each potential

solution and a variety of implementation approaches, which might include varying

timelines, deployment scope, and deployment phasing. Such an evaluation ensures that

the agency is investing in a solution that will best meet its needs.

Make or Buy Decision Analysis. Within the multitude of possible LACS solution

variations, there are generally two ways to achieve the desired result – develop a custom-

built solution (make) or procure a COTS product (buy). An effective business plan should

evaluate the implementation alternatives and the make or buy factors for each. Agencies

may see the benefits of building a custom application if their infrastructure is ill

supported by COTS products; however, this often comes at greater cost and longer

development time. The business plan should evaluate these factors and identify a solution

that achieves the greatest balance.

Cost and ROI Forecasting. The purpose of LACS modernization is to achieve higher

levels of security while streamlining existing processes and promoting organizational

efficiency. In order to achieve this, agencies should examine the total cost of solution

ownership and maintenance for each potential alternative over a five year (at a minimum)

period. This allows leadership to examine cost of ownership beyond the initial up-front

investment cost, and accurately predict cost savings over a longer period of time.

Qualitative Benefits. Typical business plans and cost/benefit analyses focus primarily on

quantifiable cost savings. While this is important to LACS modernization efforts,

planners must not overlook the qualitative benefits (process efficiencies, data privacy,

information security, etc.) that can be gained through deployment of logical access

services. Specific implementation alternatives and approaches yield differing levels of

qualitative benefits based on each agency‟s unique needs. It is important that these

qualitative factors be addressed in the business plan as they may represent a critical

deciding factor between similar approaches.

Risk. Similar to qualitative benefits, each potential LACS modernization alternative

includes a certain level of risk. These risks could impact project cost, deployment

schedule, organizational security, and user acceptance depending on the scope of LACS

solutions. An agency must evaluate all alternatives and plan to manage risk appropriately,

regardless of the solution option selected.

11.1.3. Schedule Planning

LACS modernizations are complex undertakings and therefore require significant up-front

planning to ensure a successful deployment. Program/project managers should consider

following a structured lifecycle model to assist them with the planning process. Chapter 10

introduces a phased SDLC model that identifies key activities and timing considerations during a

PACS modernization. The five phases are: Planning, Requirements and Design, Build,

Implement, and Operate and Maintain. The SDLC model presented in Chapter 10 can be used by

program/project managers to plan for LACS modernizations. This section examines each of the

SDLC phases and discusses the LACS-specific events that should occur as part of each phase.



Privacy Tip

Agencies should involve representatives from their Privacy Office during the Requirements and Design and Build phases to ensure that solutions are designed in a manner that protects privacy. While many privacy activities typically occur during the Requirements and Design and Build phases, agencies should also consider data protection and privacy requirements throughout the entire LACS development life cycle and incorporate appropriate privacy measures. Privacy should not be overlooked when attempting to solve complex technical challenges, as the overarching goal of increased efficiency and security must be maintained.

11.1.3.1. Planning Phase

The Planning Phase is the first step in beginning a LACS modernization effort within a federal

agency. This phase includes many of the topics discussed in Chapter 6 and Section 11.1 of this

chapter. Completing the Planning Phase is critical for modernizing LACS solutions, as many of

the common problems encountered can be avoided through careful planning. Figure 39 provides

a list of common activities that should occur during the Planning Phase and notes estimated




Conduct Cost/Benefit Analysis

Evaluate the factors discussed in Section 11.1.2 and conduct a cost/benefit analysis to determine an appropriate LACS solution.

3 – 6 weeks

Develop LACS Modernization Business Plan

Develop a business plan to support modernization of the existing LACS infrastructure. This should lay out the selected approach, timeline, resource requirements, and estimated costs, and supports Transition Activity 8.4.

4 – 6 weeks

Identify and Secure Funding Sources

Utilize the LACS business plan to secure new or existing funding sources for the modernization effort. All IT investments need to include funding as appropriate to support ICAM activities.

6 – 10 weeks

Develop Implementation Plan/Schedule

Develop a phased implementation approach and schedule based on available information using standardized agency resources. This should include planning for future integration periods beyond the initial LACS deployment.

4 – 6 weeks

Categorize the LACS Conduct Step 1 of the Risk Management Framework: Categorize Information Systems based on mission/business objectives. Register the LACS in the agency’s IT system inventory.

4 – 12 weeks

Begin Application Prioritization

Examine IT resources and develop application assessment criteria in order to prioritize/organize deployment of modernized LACS services to agency IT resources.

4 – 6 weeks

Develop Risk Management Plan

Utilize existing risk management sources to develop a Risk Management Plan, as discussed in Chapter 6, for handling risks related to modernizing the LACS infrastructure.

2 – 4 weeks

Develop Communications Plan

Develop the approach and plan to communicate (using a variety of media) the changes that a LACS modernization effort will bring to internal users, resource owners, and stakeholders.

2 – 4 weeks

Develop Application Integration Guide

Develop an Application Integration Guide, a formal document used to outline the process that an agency’s IT resources will go through to become integrated with the LACS solution.

6 – 8 weeks




Develop LACS Migration Plan

Develop a migration plan that outlines how the agency plans to transition its logical resources to use of the modernized access control system.

2 – 6 weeks

Develop Pilot Implementation

Develop a plan and schedule for piloting the modernized LACS solution on a small subset of the user population with well defined resource requirements.

4 – 12 weeks

Figure 39: Planning Phase Sample Activities

11.1.3.2. Requirements and Design Phase

Once an organization has planned its LACS modernization effort it enters the Requirements and

Design Phase. This phase is where the agency thoroughly documents the requirements for the

LACS solution and defines how the solution should operate within the agency‟s infrastructure.

Figure 40 provides a list of common activities that should occur during the Requirements and

Design Phase and notes estimated completion times for each; however, activities may occur in

parallel, and actual times can vary widely based on organizational size and project complexity.


Finalize LACS Solution Requirements

Conduct a requirements gathering exercise with stakeholders and impacted parties at all organizational levels to document requirements of the LACS solution. These requirements are critical as they will be used to design, build, and configure the LACS capability.

4 – 8 weeks

Select Security Controls Conduct Step 2 of the Risk Management Framework: Select Security Controls by choosing the appropriate security controls and documenting the selected controls in the security plan.

2 – 4 weeks

Validate LACS Solution Requirements

Validate the documented requirements with the LACS stakeholders in order to ensure that the LACS solution is properly designed and configured to meet the agency’s needs .

2 – 3 weeks

Develop Solution Architecture

Develop an initial solution architecture for the LACS implementation, which defines the solution components and describes their interactions.

2 – 3 weeks

Identify Authoritative Stores

Identify the authoritative store(s) of user information that will be used with LACS solution to enable automated provisioning of user accounts.

4 – 8 weeks

Establish Common Rules, Roles, and Policies

Determine the common roles, rules, and policies that shall apply to all applications in the enterprise environment. These common rules serve as a base set of configurable items within a LACS solution, and added granularity can be provided on a per application basis.

4 – 6 weeks

Map Consolidated Rules, Roles, and Policies to Applications

Map the base set of rules, roles, and policies to those currently used by the target applications (e.g., the downstream IT resources being protected by the LACS infrastructure).

8 – 12 weeks (depending on scope

and complexity)

Document System Design

Draft an initial system design document that clearly states how the system should function within the agency’s environment. The design document and associated requirements are then used during the build phase as a reference for how the LACS system should operate. The design document will also demonstrate how common roles, rules, and policies will be applied to enterprise LACS applications, and will further demonstrate how granular level policies, rules, and roles are supported to meet the LACS application owner needs.

10 – 12 weeks




Conduct Resource Acquisition

With funding sources secured, conduct the process of purchasing any required hardware, software, or labor support that will be needed.

4 – 12 weeks

Document LACS Use Cases

Document detailed LACS use cases, which the designed solution should address in the build phase. These models should seek to capture existing manual processes that will be automated, along with any exception workflows that are not part of the primary workflow.

4 – 6 weeks

Define and Configure Provisioning Workflows

Define provisioning workflows, which are used to determine how users are granted access to logical resources and what approvals or additional steps are required. This process often involves configuring automated workflows based on existing manual processes. Provisioning workflows are based on a solid understanding of the enterprise approach to common rules, roles, and policies which are applied consistently across managed end-point applications.

2 – 4 weeks

Develop Demo Application

Consider development of a demo application that can be used for training business/resource owners on the LACS capabilities that the agency is implementing. Having such a capability provides LACS program management with the ability to showcase all the capabilities and streamline integration processes.

6 – 8 weeks

Determine Physical Deployed Architecture

Outline the physical elements that need to reside in data centers, and allow for advanced coordination of the end state solution that will need to be located/hosted there. Best practice dictates that the agency should include the production environment, pre-production testing environment, user acceptance testing environment, and the development testing environment. These four environments will need to be maintained throughout a solution life cycle to allow for proper testing, regression testing, and solution integration over time.

4 – 6 weeks

Conduct Detailed Application Assessments

As part of the application prioritization and integration process, conduct application assessments as a means of gaining information about resource configuration and existing workflows.

12 – 14 weeks

Conduct Privacy Assessment

Review the LACS design and solution requirements against established privacy guidelines and agency policies to ensure compliance.

4 – 6 weeks

Figure 40: Requirements and Design Phase Sample Activities

11.1.3.3. Build Phase

Following the Design Phase, agencies enter the Build Phase, where the majority of the technical

solution development, configuration, and testing occurs. Figure 41 provides a list of common

activities that should occur during the Build Phase and notes estimated completion times for

each; however, activities may occur in parallel, and actual times can vary widely based on



Stand Up Development and Test Environments

Establish development and testing environments so that LACS developers and testers can conduct build activities in an environment that does not impact the agency’s production systems.

4 – 6 weeks




Build/Configure Servers Build and/or configure servers to properly operate the LACS solution, as needed based upon the chosen implementation path. Agencies should align with acquisition activities (if applicable) to ensure that hardware is on-hand in an appropriate timeframe.

4 – 6 weeks

Install Supporting Software

Install supporting software (i.e., COTS IAM Suite) on LACS servers, as needed based upon the chosen implementation path.

8 – 10 weeks

Configure Supporting Software

Configure LACS software to specifically meet the agency’s unique needs and/or perform certain functions, as needed based upon the chosen implementation path

8 – 10 weeks

Implement and Assess Security Controls

Conduct Steps 3 and 4 of the Risk Management Framework by applying the controls identified in the requirements and design phase and by assessing the adequacy and effectiveness of the security controls and documenting the findings in an assessment report..

12 – 20 weeks

Build Resource Adapters, Service Interfaces, and Network Connectors

Build and configure network connectors, service interfaces, and resource adapters in order to deploy the LACS solution onto the agency’s network and integrate with IT resources.

2 – 4 weeks per resource

Develop a Test Plan and Test Scripts

Define a test plan and test scripts to organize the testing process and identify the key capabilities that must occur successfully to ensure that the LACS solution performs as it was designed and operates securely and efficiently.

2 – 3 weeks

Conduct Testing on Initial Build

Perform testing (including failover77

and regression testing, interoperability testing with other infrastructure components, and performance testing) on the LACS solution in a development and/or test environment to ensure that system errors are found and corrected before the solution is deployed on the agency’s network.

4 – 8 weeks78

Conduct Pilot Implementation Deployment

Conduct a pilot implementation to expose a small subset of the agency’s user base to the LACS solution for the purpose of evaluating the solution’s operations against real-world requirements.

4 – 6 weeks

Figure 41: Build Phase Sample Activities

11.1.3.4. Implement Phase

Once an agency has configured its LACS solution and tested to ensure that it meets agency

requirements and performs appropriately, the project enters the Implement Phase. This phase

consists of activities for migrating the LACS solution from a development and test environment

into the agency‟s production infrastructure. Figure 42 provides a list of common activities that

should occur during the Implement Phase and notes estimated completion times for each;

however, activities may occur in parallel, and actual times can vary widely based on


77 Failover is described in NIST SP 800-53 Recommended Security Controls for Federal Information Systems and Organizations.

78 Estimated time includes testing and remediation of findings.





Authorize the LACS Conduct Step 5 of the Risk Management Framework: Authorize Information System by preparing and submitting the security authorization package to the authorizing official. The authorizing official chooses to accept the risk and authorize the system if the risk associated with operating the LACS is deemed acceptable.

1 – 2 weeks

Conduct User Acceptance Testing (UAT)

Conduct UAT to ensure that the LACS solution is acceptable to stakeholders and end users and performs the required functions in an appropriate manner.

4 – 6 weeks79

Deploy LACS Solution to Live Production Environment

Deploy the LACS solution on the agency’s network infrastructure and begin controlling access to protected resources.

4 – 6 weeks

Conduct User Training Develop training materials and conduct user training prior to LACS deployment to ensure that users are capable of accessing their worksites without disruption.

3 – 4 weeks

Perform Awareness and Outreach

Conduct awareness and outreach activities in accordance with the Communications Plan developed as part of the Planning Phase. This involves actively communicating to users that a new access control system is being deployed, the benefits and efficiencies that users can expect, and any steps necessary to begin using the new system.


the deployment process.

Figure 42: Implement Phase Sample Activities

11.1.3.5. Operate and Maintain Phase

After an agency has successfully deployed its modernized LACS solution to a live production

level, the project enters the Operate and Maintain Phase. This phase lasts for the remainder of the

time that the LACS solution is in use and consists of ongoing management and system

maintenance activities such as: conducting training, operating the LACS solution, and protecting

new resources as they are integrated with the enterprise solution. Figure 43 provides a list of

common activities that should occur during the Operate and Maintain Phase and notes estimated




Monitor Security Controls

Conduct Step 6 of the Risk Management Framework: Monitor Security Controls by monitoring changes to the information system and its environment of operation and conducting ongoing assessments of security controls in accordance with the monitoring strategy.

On-going

Ongoing User Training Continue to update and modify user training curriculums as the LACS solution matures, new resources are protected, and new users are added. Conduct additional training as necessary.



Execute Change Control Board (CCB)

Conduct activities with the CCB to evaluate potential changes to the LACS solution and provide a governance structure for determining which solution changes should be implemented.

Occurs throughout the life cycle, as

changes are proposed

Build/Configure Resource Adapters and Service Interfaces

Build/configure additional resource adapters and service interfaces to properly connect and manage authentication to new applications as they are integrated into the LACS infrastructure.

2 – 4 weeks per resource

79 Estimated time includes testing and remediation of findings.




Modify Provisioning Workflows

Update provisioning workflows as business needs and access rules change over time. Changes may also be required as resource owners experience the benefits that can be provided by modernized LACS services and provisioning workflows can be streamlined.

3 – 4 weeks planning

5 – 8 weeks for development and

integration

Conduct Hardware / Technology Refresh

Conduct periodic updates and/or upgrades to solution hardware and other technology over the lifespan of a LACS solution as a means of extending the usable life of the solution or adding new capabilities.

12 – 36 weeks, depending on scope

and system size

Remove Sunsetted Resources

Ultimately, IT resources are replaced, upgraded, or consolidated over time as mission and business needs change. Accordingly, as applications become sunsetted, user privileges will need to be de-provisioned and the resource itself can be disconnected from the LACS solution.

1 – 2 weeks

Figure 43: Operate and Maintain Phase Sample Activities

11.1.3.6. Application Integration Planning

LACS solutions achieve their value primarily through integration with an agency‟s IT resources

(applications). Once integrated, the agency‟s applications utilize the LACS infrastructure to

perform PIV-based PKI certificate authentication, and consume additional access control

services (i.e., authorization, policy management, audit and reporting, etc.), if provided.

Successfully integrating applications requires detailed planning as certain types of applications

(e.g., legacy, custom built) are more complex to integrate and require additional time and

resources. For this reason, agencies should gather and evaluate information about their

applications in an effort to categorize and prioritize them for integration. Completion of this

planning activity aligns with the activities titled, “Begin Prioritizing Applications,” and

“Conduct Detailed Application Assessments,” in Figure 39 and Figure 40, respectively. Several

factors should be evaluated to successfully prioritize an agency‟s applications for integration

with the LACS infrastructure, including:

Risk Profile. Risk profiles for applications consist of an evaluation of the application‟s

compliance requirements, data sensitivity needs, data privacy requirements, and other

artifacts of the FISMA and RMF processes. It is wise to choose low impact applications

for inclusion in early integration activities, such as a pilot implementation, to avoid

disruptions to sensitive applications during deployment. Once the full enterprise LACS

capability has been established, an agency will likely prioritize its highest impact

applications for integration first.

Inclusion. In order to achieve widely accepted value across the enterprise, the agency

should integrate applications from a representative set of business and mission areas as

soon as possible.

Technical Readiness. As noted previously, applications vary widely in their use of

technology, platforms, operating systems, etc., and vary in maturity and usage. These

factors, along with the complexity of the application‟s interfaces and availability of

application connectors and service interfaces, contribute to the technical readiness of

applications for integration. Agencies should seek to prioritize the applications that are

the most technically ready as they are generally faster and easier to integrate.

Operational Readiness. Many agencies operate applications that support mission-

specific functions, which may dictate certain time periods where operational readiness is



of paramount concern. Agencies should seek to integrate applications during time periods

that make sense and when the resource could tolerate integration efforts.

Application Life Cycle Phase. An agency should prioritize integration of applications

that are under development such that they can be tied into the enterprise LACS solution

as they are deployed. Applications that are currently operational should be prioritized

based on the other factors relevant to the application, such as technical readiness. An

agency should identify any applications that are planned to be phased out, as these

applications do not need to be integrated with the LACS solution.

Each of the factors introduced above should be examined in greater detail against an agency‟s

mission needs and operational business requirements in order to determine an appropriate

weighting mechanism for evaluating the agency‟s applications. Once the factors are weighted,

each application should be evaluated and scored. This type of evaluation results in a score for

each application, which can then be used to determine integration priority.

Implementation Tip

When modernizing your agency’s logical access infrastructure, be sure to factor in support for emerging technologies. With the growing push to take advantage of the benefits offered by cloud-based computing,

80 agency LACS should be designed and built

in such a way that they are capable of appropriately securing an agency’s applications and services in the cloud. For example, GSA is in the process of migrating to a cloud-based e-mail system, which will be protected by the agency’s LACS.

Obtaining the information necessary to complete a comprehensive evaluation of an agency‟s

applications as part of the prioritization process can be achieved through a variety of

mechanisms. As discussed in Section 9.1, there are a variety of application information sources

available within an organization. Much of the information necessary to perform an application

evaluation can be obtained by reviewing the information available through these sources.

However, it may be necessary to gather additional information from application owners and

administrators. Agencies may evaluate and prioritize applications manually, which could be

advantageous when very similar or few applications exist. However, tools exist that utilize

technology to analyze and score applications in a semi-automated fashion, which significantly

reduces evaluation time in agencies with many applications.

Implementation Tip

The U.S. Department of Agriculture (USDA) utilizes Decision Lens to analyze, evaluate, and prioritize their applications for integration with the agency’s LACS infrastructure. This tool evaluates each application’s business continuity, operational risk, multi-agency applicability, and OMB Circular A-123 compliance factors, and automatically ranks them for integration based on a configurable weighting scale.

Part of prioritizing applications for integration is identifying a small subset of applications that

are relatively simple to integrate, are used by a well defined group, and are receptive to new

technologies. This subset should be targeted for integration with the LACS pilot implementation.

The next section discusses the establishment of pilot implementations and the benefits that they

provide.

80 OMB M-10-19, Fiscal Year 2012 Budget Guidance, June 2010 directs agencies to evaluate the potential to adopt cloud computing solutions by

analyzing computing alternatives for IT investments in FY 2012. The Federal Cloud Computing Strategy, released on February 8, 2011 also emphasizes the capability of cloud computing to reduce inefficiencies and improve government service delivery.


http://www.cio.gov/documents/Federal-Cloud-Computing-Strategy.pdf



11.1.3.7. Pilot Implementation Development

Pilot implementations are used to test newly developed solutions in a real-world environment on

a small, well-defined group of users within a small number of easily integrated applications. This

approach allows an organization to measure the effectiveness and user acceptance of the LACS

solution in an environment that offers relatively low risk, while finely tuning the solution to

ensure that it meets the organization‟s needs.

Privacy Tip

While pilot implementations are often small in size and scope, agencies should keep in mind that legal and regulatory requirements for privacy and data protection apply equally to pilot implementations. Agencies should involve appropriate personnel from privacy and security offices to ensure that adequate safeguards are in place prior to implementing pilot activities.

When establishing a LACS pilot implementation, agencies should consider several specific

factors, which influence not only the success of the pilot but may also impact the agency‟s ability

to predict the success of wide-scale deployment. These factors include:

Define scope of pilot. Start small with limited number of willing and informed users,

using agency PIV cards to access the agency‟s domain. Given the potential risk of delays

or inability for users to log on to their computers, agencies should consider excluding

personnel who require IT access with minimal disruption. Agencies should develop use

cases that fall within the scope of the pilot and identify exceptional use cases that can be

addressed based on the success of the initial pilot and lessons learned.

Identify potential privacy impacts of pilot. Agencies should evaluate the potential

privacy impact associated with the planned pilot implementation. This should include an

evaluation of the type of data that is being used and/or exchanged within the pilot to

determine if live production data containing any PII will be included. Agencies should

consider using alternative data sources, if available, or ensure that the live production

data is properly protected and disposed of in accordance with the agency‟s privacy and

data protection policies.

Identify metrics for success and determine how evaluation data will be collected. Defining a concrete set of objectives and measures up-front ensures clarity of purpose

and ensures that the results can be accurately evaluated. Collecting evaluation data

consists of evaluating the performance of the LACS solution in terms of the number of

authentication attempts (successful and unsuccessful), application downtime as a result of

solution usage, as well as measuring the acceptance and use of the solution by the pilot

participants.

Ensure coordination and communication. Pilot implementations require coordination

between LACS program management, resource owners and administrators, and program

stakeholders. The pilot project manager should be responsible for managing the overall

schedule and ensuring that updates, concerns, and lessons learned are communicated to

the pilot participants in a timely manner.

Identify pilot participants. Pilot participants are generally identified as part of the

application integration and prioritization effort, when specific applications are targeted

for involvement in pilot implementations. However, agencies should seek to involve

participants who will provide a broad representation of users‟ familiarity with using

smartcards, office, position, physical location, and hardware used. Additionally agencies



should consider the users‟ willingness to accept the risk associated with use of the new

technology and who may be easily helped if they experience problems.

Formally evaluate the success of the pilot implementation. When planning for a

LACS pilot implementation agencies should plan on holding a formal evaluation of the

criteria for success immediately following the program‟s conclusion. This allows the

agency to identify and correct any deficiencies with the LACS solution before wide-scale

deployment occurs.

Lesson Learned

The General Services Administration (GSA) recognized that a LACS deployment relies on “quick wins” to demonstrate success and build support throughout the organization for continuing along the LACS maturity curve. “Quick wins” can be achieved through thoughtful application prioritization and pilot integration – select applications with well defined user groups where user satisfaction and process streamlining can be easily evaluated.

11.2. Logical Access Architecture and Design

Designing a LACS solution requires agencies to consider the capabilities presented in the ICAM

target state, existing LACS investments, and the agency‟s overall IT infrastructure. The objective

of this effort is to determine how modernized LACS solutions will integrate with the agency‟s IT

infrastructure and provide logical access services, as defined in the ICAM Services Framework

(Section 3.2.4), to the agency‟s applications. This section provides a solution architecture

diagram, discusses the components that comprise a modernized LACS, and introduces common

characteristics that an agency should consider when designing its target state LACS. The

information and guidance provided in this section is intended to provide answers to several

common LACS architecture and design questions, including:

What does a modernized LACS infrastructure, compliant with the ICAM target state,

look like?

What are the components of a modernized LACS infrastructure, and how do they support

achievement of the ICAM target state?

What common characteristics should I consider when designing a LACS solution?

11.2.1. Solution Architecture

The ICAM segment architecture presented in Part A describes the LACS target state and

introduces logical access services as part of the ICAM Services Framework. One of the key

characteristics of the target state is moving toward providing common logical access services

(privilege management, authentication, and authorization) at an enterprise level. Many agencies

within the Federal Government are moving toward this model and the purpose of this section is

to illustrate how those services are aligned within a LACS solution. The solution architecture

outlined in Figure 44 is intended to illustrate the concept of leveraging shared agency resources

to provide a common set of logical access services across an agency‟s enterprise. The box at the

center of the diagram depicts the LACS infrastructure with a variety of common components

capable of supporting LACS services, as outlined in the ICAM Services Framework. These

components represent generic products and are not aligned with a particular vendor or solution

offering.



Figure 44: Logical Access Solution Architecture

The diagram above is intended to serve as a high-level depiction of the target state for LACS,

and is representative of the many solution variations/designs that agencies may choose to

implement. The solution components within the Enterprise Logical Access Infrastructure are

represented generically and could be implemented using a variety of COTS and purpose-built

products. This type of solution architecture provides both authentication and authorization

services at an enterprise level for all protected resources, and is the recommended means of

achieving the ICAM target state. The enterprise authentication and authorization solution is

discussed further in Section 11.2.1.1. While it is expected that enterprise LACS services, as

represented in Figure 44, will be the predominant solution model in the target state, this approach

may not be appropriate for all agencies or for all applications within a particular agency.

Situations may exist where it is either not feasible to deploy such a solution, or not practical or

cost effective to integrate particular applications if such a solution exists. In support of these

situations, sections 11.2.1.2, 11.2.1.3, and 11.2.1.4 discuss several of the most common

variations on the enterprise LACS services solution architecture presented above and provide

examples of where it may be advantageous to pursue an alternate approach.

11.2.1.1. Enterprise Authentication and Authorization

In the enterprise authentication and authorization architecture outlined in Figure 44, an agency‟s

IT resources are integrated with one or more central LACS solutions that provide both user

authentication and authorization services for the integrated resources. This model allows

resource owners to leverage authoritative identity data, centralized authentication, and enterprise

access control enforcement to streamline the management of users and privileges for their

resource. This approach is recommended for a wide variety of departments and agencies,



particularly large independent agencies, agencies that are geographically centralized, or agencies

with a large number of standardized web applications. Figure 45 highlights some of the potential

benefits and limitations associated with the enterprise authentication and authorization solution.


Agency aligns with the preferred model for achievement of the ICAM target state for LACS

Agency needs can be supported by a number of widely available COTS products/suites

Applications gain added security through use of a standardized authentication mechanism

Users may be able to experience Single Sign-On (SSO) capabilities across multiple applications

User authorization decisions are based on authoritative entitlement attributes and access privileges

Applications receive fine grained authorization decisions based on up-to-date user entitlements

Agencies realize an enhanced ability to manage user access across the user lifecycle

Agencies and resource owners gain an enhanced ability to detect and remediate compliance issues within resources (i.e. segregation of duties) and across one or more applications

Agencies have the ability to employ role-based access control based on user attributes

Agencies may require an up-front investment to build, configure, and deploy a LACS solution

Agencies may experience difficult and time consuming deployment across the enterprise due to the complexity of the organization

Legacy applications may not easily integrate with an enterprise solution

Agencies may realize that an enterprise solution is not financially feasible, based on size and scope of deployment

Figure 45: Benefits and Limitations of Enterprise Authentication and Authorization

11.2.1.2. Enterprise Authentication and Decentralized Authorization

Some organizations may require a hybrid approach to providing LACS services whereby

authentication is performed via enterprise authentication services, while authorization decisions

are performed natively by the resource. For example, many web access management products,

which could make up a part of an agency‟s enterprise authentication services, create and send an

identity assertion to each protected application when the user attempts to gain access.81

The

application itself accepts the assertion and relies on locally maintained access privileges to make

a user authorization decision. Additional system components within the authentication services

address other resource types, such as mainframe applications.

Terminology

Assertion – a statement from an entity that verifies a user’s identity, such as an enterprise authentication service, to a relying party that contains identity information about a user. Assertions may also contain verified attributes. Assertions may be digitally signed objects or they may be obtained from a trusted source by a secure protocol (e.g., Security Assertions Markup Language (SAML), Kerberos).

Agencies may choose this type of approach for legacy applications or in situations where it

makes sense for a local resource to maintain control over user authorization. For example, certain

legacy applications may be incapable of processing more granular authorization decisions (e.g.,

role- or attribute-based) or the application does not require robust or granular authorization

81 Examples of identity assertion-based authentication technologies that extend network login to applications while maintaining local authorization decisions include Kerberos and Secure Assertion Markup Language (SAML).



capability (e.g., applications with a single user role). Figure 46 highlights some of the potential

benefits and limitations associated with decentralized authorization approaches.


Applications benefit from the added security of a standardized authentication mechanism

Users may be able to experience SSO capabilities across multiple applications

Applications maintain local control over authorization decisions

Authorization decisions remain highly dependent on locally managed access privileges

Changes to the security model of the application require local code changes

Reduced ability to detect and remediate compliance issues within resources (i.e. segregation of duties)

Authorization may be managed inconsistently across the organization

Reduced ability to manage users across the user lifecycle

Resource owners must continue to maintain native reporting and auditing capability

Figure 46: Benefits and Limitations of Decentralized Authorization Approaches

11.2.1.3. Decentralized Authentication and Enterprise Authorization

Agencies may opt for an additional hybrid solution architecture, which utilizes a decentralized

approach for user authentication while leveraging an enterprise authorization service. In this

model, authentication occurs at a local level as applications are configured to accept and validate

user PKI certificates. Authorization occurs via an enterprise role and entitlement management

service provided by one or more centrally managed authorization products. This type of

approach is generally applied in agencies with very diverse or complex applications that require

custom connectors or service interfaces to accept authentication decisions, or for high-risk (e-

Authentication Assurance Level 482

) applications that require a direct link between certificate-

based authentication and the user‟s session. Figure 47 highlights some of the potential benefits

and limitations associated with decentralized authorization approaches.


Authorization decisions are based on authoritative user entitlement attributes and access privileges

Applications receive fine grained authorization decisions based on up-to-date user entitlements

Enhanced ability to manage user access across the user lifecycle

Enhanced ability to detect and remediate compliance issues within resources (i.e. segregation of duties) across one or more applications

Ability to employ role-based access control based on user attributes

Less support for enhanced enterprise level services (i.e., enterprise event auditing, SSO, etc.)

Resource owners must continue to maintain native reporting and auditing capability

Reduced ability to provision users in an automated fashion

Authentication may be managed inconsistently across the organization

Solution viable only at an operating system level; cannot be easily scaled for multiple web applications

Highly complex and onerous change management processes

Figure 47: Benefits and Limitations of Decentralized Authentication Approaches

11.2.1.4. Decentralized Authentication and Authorization

A decentralized LACS model relies on the native authentication and authorization capabilities

within each application to validate users and manage user privileges. When using the PIV

credential, this approach is most often achieved by enabling applications to accept and validate

82 As defined in NIST SP 800-63, Electronic Authentication Guideline, December 2008.

http://csrc.nist.gov/publications/PubsDrafts.html#SP-800-63-Rev.%201



PKI certificates to perform user authentication, and then performing authorization against locally

maintained access privileges. In the target state, it is expected that this type of approach will be

used in organizations with a relatively small number of applications where implementing a

centralized LACS infrastructure is not cost effective. An agency might also choose this approach

if its applications are based on proprietary technology and cannot be easily integrated with

enterprise services. Typically these organizations perform a cost/benefit analysis, as described in

Section 11.1.2, and discover that the cost of deploying an enterprise services solution outweighs

the benefits that could be achieved. Figure 48 highlights some of the potential benefits and

limitations associated with decentralized LACS approaches.


Lower up-front investment required to enable LACS

Implementation is generally faster than enterprise solutions

Resource owners maintain control over user authentication and authorization decisions

Low learning curve for managers and administrators

Inability to provide enhanced enterprise level services (i.e., enterprise event auditing, SSO, etc.)

Resource owners must continue to maintain application specific user account and privilege data

Authorization decisions remain highly dependent on locally managed ACLs

Reduced ability to provision users in an automated fashion

Authentication and authorization may be managed inconsistently across the organization

Reduced ability to detect and remediate compliance issues within resources (i.e. segregation of duties)

No visibility into whether appropriate application access on a per application basis creates policy violations when paired with other application access Inability to manage users across the user lifecycle

Figure 48: Benefits and Limitations of Decentralized Authentication and Authorization Approaches

11.2.2. Solution Components

LACS infrastructures consist of a variety of components, as shown in Figure 44, including

shared agency resources that make up the core Enterprise Logical Access Infrastructure,

authoritative identity stores, agency applications, and common components to support PIV card

authentication. This section examines the individual solution components that comprise the

Enterprise Logical Access Infrastructure. Each of these components can be provided by a variety

of commercial off-the-shelf (COTS) software products, in-house agency resources, and custom

built tools. Many of the components discussed may be referred to differently by different product

vendors; the component names used throughout this section are generic representations meant to

be descriptive of the functionality provided by the component. In some cases more than one

product or solution may be required to achieve the level of functionality described below. This

varies based on each agency‟s selected implementation approach, infrastructure, business, and

operational requirements. Agencies should evaluate the core capabilities of each component

discussed in this section when designing LACS solutions in order to ensure that software

capabilities are consistent with the ICAM Services Framework, regardless of technology and

terminology differences..



Privacy Tip

When customizing and configuring a COTS solution component or developing a purpose-built tool to address the capabilities discussed in Section 11.2.2 and its subsections, agencies must consider existing privacy requirements and regulations. Involving appropriate security and privacy personnel can help ensure that solution components are properly configured and capable of meeting data protection, transmission, storage, and disposal requirements.

11.2.2.1. Identity Manager

The Identity Manager is primarily designed to correlate identity attributes from a variety of

authoritative sources for the purpose of provisioning user accounts to agency resources. When

integrating with legacy applications, this may include integrating with the application‟s native

user stores (locally maintained user information for administering access control) or providing

service interfaces as a means of correlating existing user data with authoritative sources. The

Identity Manager automates the provisioning process (i.e., creating, updating, deleting, enabling,

and disabling user accounts in applications and/or directories used by enterprise access

management solutions).

The Identity Manager manages an array of automated workflows that leverage technology to

eliminate manual paper-driven provisioning processes.83

These workflows include self-service,

approval, escalation, manual tracking of approvals, ticketing requests, etc. The Identity Manager

eliminates redundant collection of user identity data at the local resource level and prevents

violations of segregation of duty (SOD) policies by not allowing accounts and entitlements to be

provisioned if they violate a policy. A variety of COTS and purpose-built products are available

to serve as the Identity Manager within a LACS infrastructure. Deployment of an Identity

Manager that provides automated provisioning capabilities supports achievement of Transition

Activity 8.2, as identified in Section 5.2.2.4.

11.2.2.2. Access Manager

The Access Manager provides runtime authentication and authorization decisions; enforcement

services for protected applications, networks, and operating systems; and can provide an

interface for managing access privileges and policies. Within the target state LACS solution

architecture presented in Figure 44, the Access Manager complements the Identity Manager by

integrating with the directories provisioned by the Identity Manager. Typical products that

provide Access Manager functionality offer flexibility and the ability to customize the way that

they are integrated into the LACS infrastructure and in the services that are provided at an

enterprise level.

The Access Manager performs session management, which enables a SSO experience from the

user perspective, wherein a user only authenticates with the PIV credential once and can access

protected applications, provided session and application policy allows it. This eliminates the

need for users to authenticate multiple times, thereby streamlining the access process and

creating efficiencies for end users. The authentication process occurs between the Access

Manager and the individual application in a manner that is transparent to the user.

83 Provisioning processes, workflows, technologies, and characteristics of an automated provisioning capability are discussed in detail in Section 9.2.3.



Terminology

Single Sign-On – a mechanism by which a single act of user authentication and log on enables access to multiple independent resources.

In practice, many organizations achieve a variation called reduced sign-on, whereby a user experiences single sign-on for a set of resources but is required to independently authenticate to a small set other resources due to resource-specific security requirements or technical constraints.

The Access Manager can also serve as a standalone component, without the need to integrate

with a dedicated Identity Manager. This is most often the case where an agency chooses to

integrate its Access Manager with an existing directory (e.g., Active Directory). This model uses

the agency‟s directory as its user store and relies on the Access Manager to manage policies and

privileges in addition to making runtime authentication and authorization decisions. While this is

a valid approach, the guidance presented in this chapter aligns with the preferred solution

architecture outlined in Section 11.2.1.1 and assumes that the Access Manager is integrated with

an Identity Manager component, unless otherwise indicated.

Lesson Learned

LACS architectures that use a standalone Access Manager (i.e., not integrated with an Identity Manager) may not be a viable solution for agencies that do not have a single authoritative user store, as there is no way to ensure uniqueness of users across the enterprise.

A large federal agency attempted to implement a standalone Access Manager solution with disparate data sources and quickly discovered this problem. By implementing an Identity Manager, the agency was able to create unique digital identities and successfully complete their LACS modernization effort.

A number of COTS and purpose-built products are available as an Access Manager and often

include a variety of pre-built or custom resource agents and service interfaces, which are used to

integrate with the application and provide enterprise authorization services though policy

decision making and enforcement. These agents and services allow the application to intercept

unauthenticated and/or unauthorized access attempts to ensure that applications are properly

protected. When designing a LACS solution agencies should consider the types of web

applications that exist within their IT infrastructure and select an Access Manager that most

closely aligns with the agency‟s existing investments and infrastructure requirements; this topic

is discussed further in Sections 11.1.2 and 11.3.2.

11.2.2.3. Role Manager

The Role Manager integrates with the Identity Manager and supports the process of engineering

roles that can be consumed by the Identity Manager and utilized in the provisioning process.

Role engineering can be performed in either a top-down (step-wise definition of roles based on

organizational characteristics) or bottom-up (mining existing entitlements from applications)

fashion or some combination of the two. By assembling individual entitlements into logical

groups the Role Manager supports business friendly RBAC.84

84 The definition of user roles and access control polices within an organization along with a discussion of access control models is provided in Section 9.3.



The Role Manager supports SOD policies by preventing the creation of roles that include access

entitlements in violation of established policy. The Role Manager allows business owners,

resource owners, and resource administrators to revise existing or create new access control

rules/policies as business and operational requirements change over time. A variety of COTS and

purpose-built products exist to perform Role Manager functions. Many of these products are

designed around role-based access control with the emergence of more granular models, as

described in section 9.3, as many commercial vendors offer tools which provide greater support.

When designing a LACS solution agencies should closely evaluate the Role Manager‟s ability to

interact and interface with other LACS components (both existing and new).

11.2.2.4. Directory Server

The Directory Server manages user identity data in a directory format and supports the identity

attribute correlation capabilities provided by Identity Manager. This is an optional component

within the LACS infrastructure and is typically used when integrating with or consolidating data

from one or more directory services, such as Microsoft Active Directory or Radiant Logic

Virtual Directory Server.

11.2.2.5. Federated Access Manager

The Federated Access Manager extends the functionality of the Access Manager to protect

resources and enable access for a variety of users and business partners using multiple credential

types. Within the ICAM target state, it is expected that this component could support

Government-to-Government (G2G), Government-to-Business (G2B), and Government-to-

Citizen (G2C) transactions for users with non-PIV cards. The Federated Access Manager can

also extend the SSO experience for agency users by passing the necessary identity information to

external partner websites. It can enhance privacy by providing user control over what

information is shared. The Federated Access Manager can also eliminate the need for users to

perform new account administration by extending provisioning capability to federated resources.

Considerations for deploying a federated identity management capability are discussed further in

Chapter 12.

11.2.2.6. Analytics and Reporting Tool

The Analytics and Reporting Tool provides the ability to collect and correlate logged data from

the other solution components discussed in this section into relevant information. Typically the

Analytics and Reporting Tool is used to create a variety of reports that can be presented on a

dashboard for various managers and administrators within the organization. The Analytics and

Reporting Tool offers the ability to tailor reports and dashboard information based upon the

user‟s role and management privileges. For example, a resource administrator may be allowed to

view information about his/her resource, but not that of another resource. The tool also provides

the capability to correlate information across multiple resources. This enables an enhanced

ability to identify duplicative or orphaned accounts, detect and resolve SOD violations, and

periodically re-certify a user‟s access need for certain resources or roles. Enhanced privilege

management is discussed further in Section 9.2.2. The Analytics and Reporting Tool supports

SOD by identifying where a user has been given access privileges on systems that are in conflict

with established SOD policies. Additionally, the tool provides an array of enhanced management

capabilities, including the ability to enable continuous monitoring and detect patterns of

unauthorized access across multiple resources.



The Analytics and Reporting Tool provides resource owners with access to audit, compliance,

and reporting data while reducing the administrative burden inherent with maintaining such a

capability natively within the application. The Analytics and Reporting Tool is an optional

component within the LACS infrastructure and while its absence does not degrade access control

functionality, agencies should consider implementing it in order to achieve the enhanced

capabilities that are offered.

11.2.3. Common Design Characteristics

In order to successfully build and deploy a modernized LACS solution, as defined in the target

state ICAM segment architecture, it is necessary to understand the common characteristics that

the solution should include in order to meet the objectives of the ICAM target state. These

common characteristics are identified in Figure 49; however it is also important for agencies to

consider their specific needs when designing a LACS solution.

LACS Characteristic ID LACS Solution Characteristics

LACS 1 Provides a mechanism to support enterprise level provisioning of user identities.

LACS 2 Provides a workflow engine for executing business logic.

LACS 3 Provides a set of common enterprise workflows with the flexibility to handle various approval and escalation steps.

LACS 4 Provides support for identity management industry standards.

LACS 5 Provides system interfaces that are flexible and scalable in order to support provisioning requests to existing in scope platforms.

LACS 6 Provides automated tools for existing account discovery and correlation with individual users to the target applications.

LACS 7 Provides a framework to determine that the identity profiles created within the Identity Management System (IDMS) have required integrity.

LACS 8 Supports deployment of connectors and service interfaces to provision identity profiles within an agency-defined timeframe [as defined in Service Level Agreements (SLA)] of receiving the identity/triggering event from sources based on entitlement policies.

LACS 9 Provides a management console for defining provisioning rules and policies.

LACS 10 Provides a provisioning repository for storage of workflow policy rules, in scope application and system attributes, access controls, and logs.

LACS 11 Provides interfaces to identity repositories that store identities, attributes, entitlements, roles, credentials, and other profile information.

LACS 12 Provides a secure self-service component for access by users over the intranet.

LACS 13 Allows schema extensions to accommodate custom agency data.

LACS 14 Provides the ability to define and enforce rules that are specific to an identity and its relationship to the agency.

LACS 15 Provides bi-directional communications to receive changes from the in scope managing system and to report changes made to the local resource.

LACS 16 Provides the ability to setup, schedule, monitor and review logs for automated jobs/events.

LACS 17 Minimizes the use of customized code, significant schema changes and other application customization.

LACS 18 Provides an authentication framework that can be used across the enterprise.

LACS 19 Provides easy to use and customer focused authentication methods that utilize the PIV-based PKI certificates for authentication.



LACS Characteristic ID LACS Solution Characteristics

LACS 20 Provides additional identity proofing that can be used to further an authentication attempt that may be flagged as questionable by the system.

LACS 21 Provides an interface for native and COTS application to turn over authentication decisions to the LACS components.

LACS 22 Provides an authorization management framework that includes entitlement administration, enforcement and audit.

LACS 23 Provides policy administration and authoritative policy store, a policy decision – making system and policy enforcement. This system should be aligned with the authorization management framework.

LACS 24 Provides policy creation tools that are designed for users and business owners.

LACS 25 Provides a role management framework that works in conjunction and integrates with other authorization systems in use.

LACS 26 Provides an authorization management framework that supports/interoperates with structured data, unstructured data, services and devices.

LACS 27 Provides an interface for native and COTS application to turn over authorization decisions to the LACS components.

LACS 28 Supports authentication and authorization of remote users using the PIV card.

LACS 29 Provides a requirement for the LACS system that it can differentiate between PKI policy OIDs.

LACS 30 Provides capability to secure IT resources provided by cloud services.

Figure 49: Common LACS Design Characteristics

11.3. Logical Access Technical Implementation

Implementing a LACS solution requires a well defined solution design backed by measurable

requirements that dictate how the solution should function when it is complete. While there are

many potential implementation paths that an agency could choose to follow, there are several

common areas that can affect the overall success and use of LACS solutions. This section

discusses these areas and provides guidance intended to streamline the implementation and

integration processes. The information and guidance provided in this section is intended to

provide answers to several common LACS technical implementation questions, including:

What should I consider when configuring my agency‟s workstations, networks, and

servers?

Are there any important considerations that I should be aware of when deploying the

components of my LACS solution and integrating agency applications?

What are the most common types of use scenarios that the LACS solution will need to

support?

11.3.1. System Configuration

When implementing a LACS solution, one of the most important steps is configuring the

agency‟s LACS and infrastructure components is to work together to support access based on

cryptographic authentication of the PIV card. This section discusses configuration changes,

including both hardware and software changes, to an agency‟s IT infrastructure (e.g.,

workstations, networks, and servers) based on the type of LACS solution that is being

implemented.



11.3.1.1. Workstation (Desktop/Laptop) Configuration

In order to achieve the ICAM target state and utilize modernized LACS services, as defined in

the ICAM Services Framework, agency workstations may require additional components in

order to utilize smartcards. These additional components include:

Smartcard readers. Includes internal or external hardware components and associated

device drivers necessary to access PKI certificate data stored on the smartcard.

Middleware. A software component that is required to allow communication between

the smartcard, smartcard reader, and workstation.

Third party plug-ins. A software component that may be required for workstations that

run an operating system that does not support certain protocols.

To allow users to authenticate using a PIV card, agency workstations must incorporate smartcard

readers. Readers may be either internal (built-in) or external (add-on) components, which can be

connected to workstations using existing universal serial bus (USB) connections (for external

readers). Many systems today provide built-in readers, and operating system software that

supports PIV card usage without middleware. Some older versions of operating systems will

require middleware to support PIV credential use, and agencies may also want to provide

middleware to support advanced card management features. Multiple middleware products, from

a variety of approved vendors are available through the GSA FIPS 201 Evaluation Program

Approved Products List.85

A third party plug-in may be necessary if the workstation OS does not natively support certain

protocols. An example would be the inability of an OS to create Online Certificate Status

Protocol (OSCP) requests or Server-Based Certificate Validation Protocol (SCVP) requests in

support of certificate validation. If the OS does not support OSCP or SCVP, then a third party

plug-in can be acquired and implemented to perform these capabilities. Windows XP does not

natively support OSCP or SCVP.

11.3.1.2. Network Configuration

Performing PIV-based cryptographic logon to an agency‟s network(s) requires the setup and

configuration of many different components, all of which must be available and configured

properly for PIV card logon to occur successfully. Configuring an agency‟s network to support

PIV card logon offers a number of benefits, one such benefit is that the client strongly

authenticates to the domain controller. This is accomplished through the establishment of trust

and issuance of PKI device certificates to the domain controller. Unless an agency‟s domain

controllers are already performing secure communication, it is unlikely they have a PKI device

certificate issued to them.

Within the Federal Government, all PKI certificates issued to individuals to assert identity must

conform to the Federal PKI Common Policy Framework86

(COMMON), as discussed in Section

4.5. This is not the case for non-person entities, particularly those that are internal facing only.

The guidance presented in this section assumes that the agency is enabling a Microsoft Windows

Server 2003 SP1 or later version. Agencies should consider the following:

85 GSA FIPS 201 Evaluation Program Approved Products List.

86 X.509 Certificate Policy For The U.S. Federal PKI Common Policy Framework, Version 3647 - 1.6, February 11, 2009.

http://fips201ep.cio.gov/apl.php

http://www.idmanagement.gov/fpkipa/documents/CommonPolicy.pdf



Install PKI certificates. All domain controllers require PKI certificates that have the

Enhanced Key Use of Client Authentication and Server Authentication. This is relatively

easy to do by installing a Microsoft CA, which comes with predesigned templates for

domain controller certificates.

Establish mechanism to validate certificate status. Agencies should determine where

Certificate Revocation Lists (CRLs) will be published and how they will be accessible on

the network and/or determine how to connect with an OCSP service.

Establish trust with the CA. As part of network configuration, an agency may need to

deal with distributing multiple trust chains. This situation occurs when an agency uses

PIV card certificates from one provider and receives device certificates from their own

Microsoft CA or a different PKI provider.

Map Windows user account setting to certificate. Certificate mapping provides a more

secure method for user authentication. With certificate mapping, a specific certificate is

linked to the Windows account of a user. A server application can then use public key

technology to authenticate the user by means of this certificate.

Implementation Tip

Mapping Windows user account settings to a specific public key is preferred over the approach of mapping to the User Principal Name (UPN) present in the user’s certificate. Mapping to a specific public key mitigates the risk of someone creating a digital certificate under Common Policy that contains the same UPN, which could create a situation where unauthorized access can occur.

Ensure high network availability. The network providing access to the CRLs, OCSP

services, and path validation services must be highly available. Authentication of PIV

cards will fail, if the certificate status or trust chain for the certificate is not available.

LACS components are considered high value, and should be segmented from the rest of the

network. A compromise of the LACS system provides an attacker with further access to all

connected resources. Components should be positioned within network segments based on a

least privilege approach. CRLs, OCSP, and SCVP responders are considered public and should

be in the demilitarized zone (DMZ), access management agents and proxies should be collocated

with the protected agency applications, whether on the enterprise Local Area Network (LAN), or

in the DMZ. Primary LACS components, Identity Manager, Access Manager, Role Manager,

Directory Server, Federated Access Manager, and Analytics & Reporting Tool, should be

configured in a protected subnet with access limited to only essential personnel at a network

level. Additionally, networks supporting LACS components must meet NIST87

standards for fail-

over/redundancy capabilities to ensure high availability.

11.3.1.3. Server Configuration

Servers within a LACS infrastructure either host solution components or agency applications. All

agency servers should be hardened to federally recommended or required standards, with access

limited to only essential personnel. Configuring an agency‟s servers to support PIV card logon

requires that the servers be capable of validating PKI authentication certificates presented by

users. Each of the various types and models of servers deployed across the Federal Government

requires a different level of configuration to support PKI authentication and PIV-based logon as

87 Specific requirements are contained in NIST SP 800-53Recommended Security Controls for Federal Information Systems and Organizations.




the native capabilities can vary widely based on age, manufacturer, and supporting software.

Agencies should work with their server manufacturers and IT personnel to determine what

specific configuration steps are necessary to support the LACS implementation effort. Web-

based applications utilizing the PIV credential for authentication must perform certificate status

validation using CRLs or OSCP requests to ensure the validity of the authentication certificate

and possibly SCVP to validate the certificate chain.

FAQ

What level of support do some of the common server platforms provide for certificate status validation?

Internet Information Services (IIS) 6.0 with Windows Server 2003 performs CRL checks, but not OCSP or SCVP requests. Microsoft Internet Information Services (IIS) 7.0 with Windows Server 2008 and IIS 7.5 with Windows Server 2008 R2 can perform both CRL checks and OCSP requests. In all current Windows Server implementations, if the server chain is not locally available then a third party plug-in is required to perform SCVP validation.

11.3.2. LACS Enterprise Solution Integration

Integrating and deploying a LACS solution into the agency‟s infrastructure involves evaluation

of a number of different factors. This section examines several topics that agencies should

consider as part of the integration and deployment process, including:

Component Design. An agency should determine which solution components are

required to fulfill its logical access control requirements. As noted in Section 11.2.2,

several of the components described in the solution architecture are optional.

Additionally, an agency may be able to fulfill some of the functionality of the enterprise

logical access services with existing infrastructure or capabilities. Existing EA also needs

to be revisited and possibly re-designed in order to best leverage the LACS solution. An

agency should also consider and plan for adequate performance capabilities of the system

to ensure that the appropriate capacity is available to operate the system and there are

response provisions for server or data failures.

Integration Approach. The process and technology used to integrate agency

applications with the LACS infrastructure can differ for each type of application. Most

major directories, databases, operating systems, and web applications can be integrated

using commercially available standards-based plug-in solutions or service interfaces for

provisioning and managing user accounts and access. Some legacy applications may

require custom application program interfaces or web service calls to provide the

necessary capabilities to support enterprise LACS services.

Security and Risk. Agencies should consider the integrity, confidentiality, and

availability considerations associated with deploying a LACS solution. This includes

properly securing the digital identity data that is transmitted between LACS solution

components, authoritative identity sources, and agency applications. Additionally,

agencies should establish appropriate recourse and reconstitution measures, should a

LACS component fail, as a means of ensuring that agency applications remain secure.

The following subsections discuss considerations for the deployment of Enterprise Logical

Access Infrastructure components and integration of those components with the agency‟s

infrastructure.



11.3.2.1. Component Deployment

The first step in deploying a modernized LACS is the installation and configuration of the core

LACS components. Each LACS solution component has different considerations which must be

evaluated as part of the deployment process. Figure 50 contains a list of sample considerations

that agencies should evaluate when planning to deploy LACS solution components.

Solution Component Deployment Considerations

Identity Manager Availability of authoritative source(s). An agency should determine what

source(s) are authoritative for digital identity data for its users. Integration with these sources will impact how the Identity Manager is deployed.

Identity data cleansing and normalization. Identity data within authoritative

source(s) must be properly formatted (in accordance with defined standards) and reviewed for consistency and quality prior to integration with the Identity Manager.

Ability to reconcile data changes within authoritative source(s). An agency

should consider how often and how quickly the Identity Manager should detect changes in the authoritative source(s) data. Changes could happen immediately though real-time messaging or in scheduled increments through either flat file reconciliation or lightweight directory access portal (LDAP)/database queries.

Define a unique identifier. An agency should define a unique identifier for its

users. The Identity Manager will key off of this identifier to reconcile and synchronize digital identity data with authoritative source(s) and when provisioning to resources.

Provisioning. An agency should determine which applications, directories, or

Access Managers to provision accounts and digital identity data. Provisioning may lead to increased data integrity as well as improved access control.

Access Manager Availability of out-of-the-box capabilities. Many commercially available products

offer a number of out-of-the-box service interfaces, web/application server plug-ins, or resource agents that are capable of supporting integration with most standards-based applications. An agency should determine which of these capabilities should be deployed based on its requirements.

Customization requirements. An agency should consider the level of effort

required to perform modifications and integrate with resources, even when using out-of-the-box tools, to accept information via headers or assertions when identities are asserted or mapped during run-time authentication.

Application modification. Applications will likely require modification to support

integration with an Access Manager. Modifications usually include changing the application’s login module to automatically authenticate the account of the userid passed in the HTTP request header.

Performance requirements. In order to prevent performance issues when

externalizing authorization decisions to an Access Manager, it is important to consider how the system will handle multiple queries to the Policy Decision Point (PDP), as well as a PDP’s ability to handle complex queries.

Role Manager Degree of integration. The Role Manager can be integrated with the Identity

Manager and Access Manager. Because the degree of integration dictates the Role Manager’s capabilities to administer roles and handle SOD, an agency should consider the appropriate level of integration for this component.

Directory Server Performance requirements. The Directory Server is a LACS’ identity store and

sometimes, the authentication source. The infrastructure should be appropriately scaled to handle the volume of authentication and authorization requests.

Reuse of existing infrastructure. Most agencies typically have an agency-wide

directory. An agency should consider leveraging this existing directory or migrating the directory to one that will serve as the LACS’ identity store. This will prevent duplication of digital identity data and likely reduce the risk of data discrepancies across the identity stores.

Consolidation of directories. In situations where multiple, fragmented directories

exist, agencies should consider consolidating into a single agency directory to streamline the integration process and minimize the risk of having duplicative,



Solution Component Deployment Considerations

conflicting data.

Federated Access

Manager

Intra-agency federation. Often, organizations within agencies already have LACS

solutions in place. To capitalize on the resources committed and investments made, leveraging a federated access management model should be considered. Regardless of which organization within the agency is the IDP or service provider (SP), a key consideration is the identification and synchronization of digital identity data between the organizations. The agency should strive to enforce a common unique identifier across the agency’s organization in order to more easily federate across existing systems.

Inter-agency federation. An agency should perform a cost/benefit analysis to

determine whether federating across agencies is more cost-effective than requiring each agency to simply provision/manage an account as if the user belonged to that agency. Currently, the number of users who need to access applications across agencies may not be at a critical mass. Furthermore, digital identity data management across agencies may prove challenging. If inter-agency federation is required, agencies should strive to define and enforce the use of an inter-agency unique identifier (e.g., user id pre-pended by an agency code).

Leveraging standards. An agency should select an approach (and product) that

leverages industry standards, such as SAML and Kerberos. This will help interoperability between other federated access manager systems.

Analytics and

Reporting Tool

Existing reporting requirements. An agency should examine its existing reporting

requirements and model the reporting capabilities of the Analytics and Reporting Tool to meet its needs.

Relevance of log data. An agency should determine what access event log data is

applicable and to whom. The Analytics and Reporting tool should be configured to present this information as well as notifications and alerts.

Figure 50: LACS Solution Component Deployment Considerations

11.3.2.2. Application Integration

Once the core LACS solution components have been deployed, the next step is integrating the

agency‟s applications and resources with the solution. A modernized LACS solution integration

provides enterprise automated provisioning, authentication, authorization, analytics, and

reporting and auditing services for the agency‟s resources. Utilizing a modernized LACS

solution to manage access to IT resources supports achievement of Transition Activity 8.1, as

discussed in Section 5.2.2.4. An agency should consider the following when integrating

applications to deploy these capabilities:

Automated Provisioning.88

The Identity Manager utilizes a number of out-of-the-box

plug-ins and services interfaces to connect to agency resources. It works in conjunction

with the Role Manager component to determine which target applications to provision or

de-provision based on attributes like employee status, geographic location, or title

change. The Identity Manager should be integrated to perform all tasks of the user

lifecycle, including transfers, role changes, approval workflow and delegation, and

notifications. It should also be integrated to handle outlier scenarios involving user

accounts on the target systems, such as addressing orphaned or questionable accounts.

88 Development and deployment of a centralized automated provisioning capability supports achievement of Transition Activities 8.2, 8.3, and 8.5, as discussed in Section 5.2.2.4.



FAQ

What is the difference between “push” and “pull” provisioning architectures?

In “push” provisioning architectures, LACS components initiate the transmission of identity data (attributes, roles, privileges, etc.) through data feeds at predetermined time intervals or based on events, such as when the data is updated. In “pull” provisioning architectures, however, relying parties initiate the transmission of identity data from LACS components by request, when needed. Agencies should evaluate the viability of both “push” and “pull” architectures based on their unique business needs and technical requirements.

Authentication. Authentication responsibility is assigned to the Access Manager.

Applications should be integrated with the Access Manager to manage specific user

access to web applications across the enterprise. Integration for authentication tools must

not be limited to just web services, but should also have a set of APIs available for tighter

integration. The use of digital certificates or shared secrets between the Access Manager

and other LACS solution components for authentication services ensures that integrated

applications can trust the authentication decisions.

Authorization. Authorization responsibility belongs to the Access Manager component.

The goal is to externalize the Policy Decision Point (PDP). There should also be

considerations on how the Policy Enforcement Point (PEP) will capture requests to data.

The requests will come either through a Uniform Resource Locator (URL) or a tight

integration with the application. Considerations should be made around how tightly

coupled (or de-coupled) a PDP and PEP are, and if/how policies for these components are

stored, administered, and extracted. Additionally, an agency should consider whether to

allow applications to externalize their authorization model and require the Access

Manager component to perform fine-grained authorization.

Reporting/Auditing. The reporting and auditing functionality of a LACS solution is very

important to the integrity of all the systems. Therefore, it is important to first understand

the auditing requirements and reporting requirements and benchmarking the reports based

on each organization‟s requirements. Reporting tools should be flexible and able to

generate reports based on any number of scenarios. For example, the report tool should

handle the generation of reports based on any attributes stored within an identity manager

component. It should also be able to generate report activity based on a particular role

from the role manager component.

Implementation Tip

When integrating agency IT resources with an enterprise LACS solution, an agency should analyze existing provisioning (and de-provisioning) workflows and ensure that these workflows are accurately replicated within the automated provisioning capability. This ensures that existing decision points and approval processes are maintained, while achieving the benefits afforded by leveraging technology to streamline paper-based provisioning processes.

11.3.3. Common Logical Access Scenarios

When implementing a LACS solution for PIV-based access across an enterprise, there are a

number of common scenarios that the solution must be capable of supporting. This section

identifies and discusses two of these common scenarios, network logon and client authentication

to servers. Each subsection explains how these scenarios are accomplished, and introduces



specific considerations that agencies should be aware of when configuring and deploying their

LACS solution.

Implementation Tip

While transitioning an agency’s networks and applications to support PIV card logon as part of a LACS modernization effort agencies should consider implementing short term transitional solutions to help mitigate the risk of inadvertently causing users to lose access to IT resources. An example of such a solution is acceptance of multiple credentials (e.g., username/password, PIV card, token, etc.) during the transitional period. This ensures that users can continue to logon using the legacy authentication process while preparing for and transitioning to the target state PIV credential authentication process.

11.3.3.1. Network Logon

Network logon is the process through which agency users utilize their PIV cards to access an

agency‟s computer networks and shared information systems. Successfully logging onto an

agency‟s network using a PIV card is reliant on proper configuration of agency infrastructure and

LACS solution components, as discussed in Sections 11.3.1 and 11.3.2, respectively. The

process involved in logging onto an agency network involves the user presenting a PIV-based

authentication certificate to the network‟s domain controller, validation of the certificate through

CRL, OCSP, and SCVP processes, and matching of the user‟s identity to one recognized and

accepted by the network‟s identity repository. When implementing network logon capabilities

agencies should consider the following challenges:

Extracting and matching UPN. The UPN must be extracted from the user

authentication certificate and matched to an identity stored in the network‟s identity

repository (e.g., Microsoft Active Directory, Radiant Logic Virtual Directory Service).

This process ensures that the identity repository does not store the certificate information,

but possesses the key attribute required for certificate mapping. Alternatively, the

certificate could be stored within the identity repository and compared with the live

authentication certificate presented. If the UPN cannot be extracted from the certificate or

matched with an existing identity, then the authentication attempt will fail.

Achieving SSO. It is possible to achieve SSO through network logon by passing identity

assertions in the form of cookies, Kerberos tickets, or encrypted HTTP headers to

applications, or through agent-based authentication (i.e., through use of an Access

Manager). The application handles the identity assertion and need not process the user‟s

authentication certificate.



ROI

Enabling remote access servers and virtual private network (VPN) clients to accept the PIV not only satisfies relevant security requirements related to remote access,

89 but also

offers significant benefits over separate tokens or devices. Use of the PIV eliminates the costs and administrative burden of operating a separate token infrastructure and enables an agency’s users to take advantage of the digital signature and encryption capabilities of the PIV card when working remotely.

11.3.3.2. Client Authentication to Servers

Client authentication to servers is the process through which users utilize their PIV cards to

access an agency‟s IT resources that reside on web or application servers. Successfully accessing

an agency‟s IT resources through a web or application server using a PIV card is reliant on

proper configuration of agency infrastructure and LACS solution components, as discussed in

Sections 11.3.1 and 11.3.2, respectively. The process through which the authentication occurs is

very similar to the process for logging on to an agency‟s network, presented in Section 11.3.3.1,

whereby the user‟s authentication certificate is validated by the server, and the user‟s identity

matched to an existing identity within the identity repository. When implementing a LACS

solution agencies should consider the following challenges:

Enabling two-way Transport Layer Security (TLS) authentication. Also known as

mutual TLS authentication, this allows a TLS client to confirm the identity of the TLS

server, and vice versa as a means of supporting cross-certificate trust. The TLS client

communicates the identity of the user via the authentication certificate to the application

or web server.

89 As described in OMB M 06-16, agencies must allow remote access with only two-factor authentication. Per OMB M 11-11, an agency must

require the use of the PIV credential as the means for authentication to access its networks and information systems.





12. Initiative 9: Implement Federated Identity Capability






Appendix I Decision Trees for Component Migration

Decisions

As part of the planning phase for PACS modernization discussed in Section 10.1.4.1, an agency

determines its approach for migrating to a modernized PACS. Because PACS impacts all

employees entering federal facilities, adequate migration planning is critical during the

implementation of a modernized PACS. A successful migration plan allows the integration of the

new solution to have a low impact on existing infrastructure and operations. In addition,

migration plans evaluate existing hardware and infrastructure to determine to what extent they

can be reused. The figures in this appendix address the criteria an agency is to use when

determining if existing PACS components can be reused in the target state modernized PACS

solution.



PACS Server

Database

If online connectivity

is required, can the

current PACS server

database be

integrated with the

agency PIV IT

infrastructure?

Contact the system

manufacturer or

system integrator for

upgrade availability

Replace

PACS

Application

PACS Server

Hardware

If online connectivity

is required, can the

current PACS server

hardware be upgraded

to interface with the

agency PIV IT

infrastructure?

Contact the system

manufacturer or

system integrator for


Upgrade

PACS

Database

Upgrade

Server

Hardware

Replace

PACS Server

PACS server is ready

for connection to IT

infrastructure

PACS Server

Updated

Are

upgrades

available?

YES

NO

NO

NOYES

YES

NO

Are

upgrades

available?

YES

Figure 51: PACS Server Migration



PACS Control

Panel

Does the current

control panel require

a facility code?

Contact the system

manufacturer for

upgrade to non-

facility code operation

PACS Control

Panel –

Reader Input

Can the current panel

accept the

bidirectional reader

communication from a

PIV card reader as

specified in the ICAM

segment architecture?

Contact the system

manufacturer for

upgrade availability to

accept data from GSA

Approved Product

List readers

Upgrade

PACS

Control

Panel

Upgrade

PACS

Control

Panel

PACS

Control

Panel

Upgraded

Are

upgrades

available?

NO

NO

NOYES

YES

Are

upgrades

available?

YES

NO YES

Replace

PACS

Control

Panel

Replace

PACS

Control

Panel

Figure 52: PACS Control Panel Migration



PACS Reader

Is the reader HSPD-12

compliant and capable

of bi-directional

communications with

a control panel to

read/send/receive the

required data?

Contact reader

manufacturer or

system service

provider for


Upgrade

PACS

Reader

PACS

Reader

Upgraded

Are

upgrades

available?

NOYES

Replace

PACS

Reader

YES NO

Figure 53: PACS Reader Migration