Federal CIO Council Information Security and Identity Management Committee Identity, Credential, and Access Management www.idmanagement.gov Open Solutions for Open Government Judith Spencer Co-Chair, ICAM Subcommittee Office of Governmentwide Policy GSA Judith.Spencer@GSA.Gov
What is ICAM? ICAM represents the intersection of digital identities, credentials, and access control into one comprehensive approach. Key ICAM Service Areas Include: Digital Identity Credentialing Privilege Management Authentication Authorization & Access Cryptography Auditing and Reporting
ICAM Scope
Enabling Policy and Guidance The E-Gov Act 0f 2002 The Government Paperwork Elimination Act 0f 1998 The Implementing Guidance: OMB M-04-04 December 16, 2003 The Technical Spec: SP 800-63 June 2004 The Implementing Guidance: OMB M-05-24 August 5, 2005 The Mandate: HSPD-12 August 27, 2004 The Implementing Guidance: OMB M-00-10 April 25, 2000 The Standard: FIPS-201 February 25, 2005 Special Publications Technical Specs. Federal Bridge Model Policy Federal PKI Common Policy Framework The Implementing Guidance: OMB M-05-05 December 20, 2004 4
ICAM Drivers Increasing Cybersecurity threats There is no National, International, Industry standard approach to individual identity on the network. (CyberSecurity Policy Review) Security weaknesses found across agencies included the areas of user identification and authentication, encryption of sensitive data, logging and auditing, and physical access (GAO-09-701T) Need for improved physical security Lag in providing government services electronically Vulnerability of Personally Identifiable Information (PII) Lack of interoperability The ICAM segment architecture will serve as an important tool for providing awareness to external mission partners and drive the development and implementation of interoperable solutions. (President s FY2010 Budget) High costs for duplicative processes and data management 5
FICAM Development Process The development process involves coordination and collaboration with Federal Agencies, industry partners, and cross-government working groups. Interagency Security Committee (ISC) Information Sharing Environment (ISE) White House National Science and Technology Council (NSTC) Committee for National Security Systems (CNSS) Office of Management and Budget National Institute of Standards and Technology (NIST) Office of National Coordinator (ONC) for Health IT Multiple agencies represented within the CIO council subcommittees and working groups The Roadmap team identified the key outputs of the Federal Segment Architecture Methodology (FSAM) needed for an ICAM segment architecture and coordinated these groups to develop workable approaches to enable cross-government solutions. 6
FICAM Roadmap & Implementation Guidance Overview The Federal ICAM Roadmap outlines a strategic vision for identity, credential, and access management efforts within the Executive Branch of the Federal Government and how the Executive Branch of the Federal Government will interact with external organizations and individuals. PART A: ICAM Segment Architecture (Phase 1 of the effort) ICAM Segment Architecture. Standards-based architecture that outlines a cohesive target state to ensure alignment, clarity, and interoperability across agency initiatives. ICAM Use Cases. Illustrate the as-is and target states of high level ICAM functions and frame a gap analysis between the as-is and target states. Transition Roadmap and Milestones. Defines a series of logical steps or phases that enable the implementation of the target architecture. PART B: Implementation Guidance (Phase 2 of the effort) ICAM Implementation Planning. Augments standard life cycle methodologies as they relate to specific planning considerations common across ICAM programs. Implementation Guidance. Provides guidance to agencies on how to implement the transition roadmap initiatives identified in the segment architecture, including best practices and lessons learned. 7
Measuring Success
Increasing the Trusted Credential Community Back to Basics M-04-04 and NIST 800-63 are still the foundational policy/technical guidance for identity management in the Federal government. Establish unified architecture for Identity Management Outreach to communities of interest Explore natural affinities Increase the community of trust through innovative interfederation at all levels of assurance Promote strong credential usage through Federal PKI partnerships with industry providers
Assurance Levels M-04-04:E-Authentication Guidance for Federal Agencies OMB Guidance establishes 4 authentication assurance levels Level 1 Level 2 Level 3 Level 4 Little or no confidence in asserted identity Some confidence in asserted identity High confidence in asserted identity Very high confidence in the asserted identity Self-assertion minimum records On-line, instant qualification out-ofband follow-up On-line with out-ofband verification for qualification Cryptographic solution In person proofing Record a biometric Cryptographic Solution Hardware Token Assertion-based Crypto-based
Maximum Potential Impacts FIPS 199 Risk/Impact Profiles Potential Impact Categories for Authentication Errors Inconvenience, distress or damage to standing or reputation Assurance Level Impact Profiles 1 2 3 4 Low Mod Mod High Financial loss or agency liability Low Mod Mod High Harm to agency programs or public interests N/A Low Mod High Unauthorized release of sensitive information N/A Low Mod High Personal Safety N/A N/A Low Mod High Civil or criminal violations N/A Low Mod High
ICAM Identity Assurance Governance PIV Credentials PIV- Interoperable Credentials Open Solutions - OpenID - icard - SAML - WSFed - Etc. Federal PKI Trust Frameworks
PIV Interoperability The scope of HSPD-12 is restricted to establishing a mandatory, Government-wide standard for secure and reliable forms of identification issued by the Federal Government to its employees and contractors (including contractor employees). FIPS 201 standard is applicable to identification issued by Federal departments and agencies to Federal employees and contractors (including contractor employees) for gaining physical access to Federally controlled facilities and logical access to Federally controlled information systems. Organizations external to the U.S. Federal government have expressed a desire to establish identity credentials that are interoperable with the Federal Personal Identity Verification (PIV) card.
PIV Interoperability for Non Federal Issuers Guidance Provides guidance to non-federal issuers on attaining technical interoperability and enabling trust Presupposes that the technical requirements of SP 800-73 are met Answers the three questions: How do we perform identity proofing? How do we enable digital credentials? How do we satisfy the unique identifier requirements? Does not put any requirements on Federal agencies concerning the acceptance/trust of NFI PIV interoperable credentials
Continuing Activity - PIV-I Certification ICAM PIV-Interoperability Tiger Team (PIVITT) is developing a change proposal to the Federal Bridge CA Certificate Policy Additional definition around Identity Proofing Additional definition concerning Hardware Token UUID usage information New certificate profile New Policy object identifiers proposed for: PIV-I Authentication equivalent to PIV-Authentication PIV-I Card Authentication equivalent to PIV Card Authentication PIV-I Content Signing A set of Frequently Asked Questions concerning PIV-I will be released in the near future
Trust Frameworks Leverage Industry credentials for Government use Make Government more transparent to the Public Make it easier for American Public to access government information Avoid issuance of application-specific credentials Leverage Web 2.0 technologies Demonstrate feasibility with application(s) assessed at Assurance Level 1 Support applications at higher assurance levels as appropriate
ICAM Identity Assurance Governance PIV Credentials PIV- Interoperable Credentials Open Solutions - OpenID - icard - SAML - WSFed - Etc. Federal PKI Trust Frameworks
Approach Identity, Credential, and Access Management Adopt technologies in use by industry (Scheme Adoption)... Adopt industry Trust Models (Trust Framework Adoption)...... While ensuring the principles of M-04-04 and SP 800-63 are observed and...... In a manner that promotes individual privacy protections
Scheme Adoption Scheme specific type of authentication token and associated protocols (e.g. user ID & password; PKI; SAML assertion) Adoption requires reviewing technical processes of an identified scheme and developing a Profile for use with government. The Federal Profile defines MUSTs, SHOULDs, SHOULD nots, etc. for identity providers and relying parties Does not change the existing technical standard
Trust Frameworks: Open Solutions for Open Government The ICAMSC: Establishes Federal Profiles for Open identity solutions Established Trust Framework Provider Requirements Worked the CIO Privacy Committee to establish Privacy Principles Reviews and Approves Trust Frameworks: Kantara Open Identity Exchange InCommon Trust Framework Provider Graphic Courtesy of Open Identity Exchange
Trust Framework Adoption Trust Framework Provider organization engaged in the assessment of identity providers to determine assurance level(s) inherent the identity credentials offered and conformance to Federal Scheme Profile Establishes the ground-rules for industry selfcertification Federal community will recognize assessor organizations through Trust Framework Adoption Considers requirements of NIST SP 800-63 Identity Providers approved via this process will be placed on a certified identity provider list
Trust Framework Privacy Principles 1. Opt In Identity Provider must obtain positive confirmation from the End User before any End User information is transmitted to any government applications. The End User must be able to see each attribute that is to be transmitted as part of the Opt In process. Identity Provider should allow End Users to opt out of individual attributes for each transaction.
Trust Framework Privacy Principles 2. Minimalism Identity Provider must transmit only those attributes that were explicitly requested by the RP application or required by the Federal profile. RP Application attribute requests must be consistent with the data contemplated in their Privacy Impact Assessment (PIA) as required by the E- Government Act of 2002.
Trust Framework Privacy Principles 3. Activity Tracking Commercial Identity Provider must not disclose information on End User activities with the government to any party, or use the information for any purpose other than federated authentication. RP Application use of PII must be consistent with RP PIA as required by the E-Government Act of 2002.
Trust Framework Privacy Principles 4. Adequate Notice Identity Provider must provide End Users with adequate notice regarding federated authentication. Adequate Notice includes a general description of the authentication event, any transaction(s) with the RP, the purpose of the transaction(s), and a description of any disclosure or transmission of PII to any party. Adequate Notice should be incorporated into the Opt In process.
Trust Framework Privacy Principles 5. Non Compulsory As an alternative to 3rd-party identity providers, agencies should provide alternative access such that the disclosure of End User PII to commercial partners must not be a condition of access to any Federal service. 6. Termination In the event an Identity Provider ceases to provide this service, the Provider shall continue to protect any sensitive data including PII.
Summary Identity, Credential, and Access Management Identity and Access Management Are Foundational to Information Sharing and Collaboration First release of Trust Framework Provider Approval Process and Identity Scheme Adoption Process available for public review www.idmanagement.gov Federal Profiles completed for: OpenID IMI 1.0 Industry Partners are Fielding Identity Credentials as well as Creating Federations for Sharing & Collaboration Open ID Foundation infocard Foundation InCommon Federation Progress Depends on Public-Private Partnering 27