1 Federal CIO Council Information Security and Identity Management Committee Identity, Credential, and Access Management Open Solutions for Open Government Judith Spencer Co-Chair, ICAM Subcommittee Office of Governmentwide Policy GSA
2 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
3 ICAM Scope
4 Enabling Policy and Guidance The E-Gov Act 0f 2002 The Government Paperwork Elimination Act 0f 1998 The Implementing Guidance: OMB M December 16, 2003 The Technical Spec: SP June 2004 The Implementing Guidance: OMB M August 5, 2005 The Mandate: HSPD-12 August 27, 2004 The Implementing Guidance: OMB M 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 December 20,
5 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 T) 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
6 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
7 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
8 Measuring Success
9 Increasing the Trusted Credential Community Back to Basics M and NIST 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
10 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
11 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 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
12 ICAM Identity Assurance Governance PIV Credentials PIV- Interoperable Credentials Open Solutions - OpenID - icard - SAML - WSFed - Etc. Federal PKI Trust Frameworks
13 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.
14 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 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
15 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
16 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
17 ICAM Identity Assurance Governance PIV Credentials PIV- Interoperable Credentials Open Solutions - OpenID - icard - SAML - WSFed - Etc. Federal PKI Trust Frameworks
18 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 and SP are observed and In a manner that promotes individual privacy protections
19 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
20 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
21 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 Identity Providers approved via this process will be placed on a certified identity provider list
22 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.
23 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.
24 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.
25 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.
26 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.
27 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 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
Creating Effective Cloud Computing Contracts for the Federal Government Best Practices for Acquiring IT as a Service A joint publication of the In coordination with the Federal Cloud Compliance Committee
Checklist to Assess Security in IT Contracts Federal Agencies that outsource or contract IT services or solutions must determine if security is adequate in existing and new contracts. Executive Summary
NIST Special Publication 800-66 Revision 1 An Introductory Resource Guide for Implementing the Health Insurance Portability and Accountability Act (HIPAA) Security Rule Matthew Scholl, Kevin Stine, Joan
National Spatial Data Infrastructure Strategic Plan 2014 2016 Federal Geographic Data Committee December 2013 Federal Geographic Data Committee Federal Geographic Data Committee, Reston, Virginia: 2013
Federal Communications Commission Information Technology Strategic Plan Implementing technology today to meet FCC business needs tomorrow Office of the Managing Director Information Technology Center July
NATIONAL STRATEGY FOR TRUSTED IDENTITIES IN CYBERSPACE Enhancing Online Choice, Efficiency, Security, and Privacy APRIL 2011 THE WHITE HOUSE WASHINGTON Table of Contents Executive Summary 1 Introduction
Practice Guide Reliance by Internal Audit on Other Assurance Providers DECEMBER 2011 Table of Contents Executive Summary... 1 Introduction... 1 Principles for Relying on the Work of Internal or External
GUIDANCE ON EXHIBITS 53 AND 300 INFORMATION TECHNOLOGY AND E-GOVERNMENT Table of Contents 1. Why must I report on information technology (IT) investments? 2. What background information must I know? 3.
Report of the Small Business Paperwork Relief Act Task Force June 28, 2004 Table of Contents 1. Executive Summary...3 2. The Small Business Paperwork Relief Task Force...4 2.1. Introduction 2.1.1. What
The attached Special Publication 800-63-1 document (provided here for historical purposes) has been superseded by the following publication: Publication Number: Special Publication 800-63-2 Title: Publication
H. R. 2458 48 (1) maximize the degree to which unclassified geographic information from various sources can be made electronically compatible and accessible; and (2) promote the development of interoperable
Online Lead Generation: Data Security Best Practices Released September 2009 The IAB Online Lead Generation Committee has developed these Best Practices. About the IAB Online Lead Generation Committee:
ICC CYBER SECURITY GUIDE FOR BUSINESS ICC CYBER SECURITY GUIDE FOR BUSINESS Acknowledgements The ICC Cyber security guide for business was inspired by the Belgian Cyber security guide, an initiative of
DEPARTMENT OF DEFENSE (DoD) CLOUD COMPUTING SECURITY REQUIREMENTS GUIDE (SRG) Version 1, Release 1 12 January 2015 Developed by the Defense Information Systems Agency (DISA) for the Department of Defense
Transforming the Way Government Builds Solutions > ACT-IAC Institute for Innovation 2013 American)Council)for)Technology Industry)Advisory)Council:)) The American Council for Technology (ACT) is a non-profit
National Emergency Communications Plan 2014 This page intentionally left blank. MESSAGE FROM THE SECRETARY Since the Department of Homeland Security (DHS) was established in 2003, one of its top priorities
Cloud Service Level Agreement Standardisation Guidelines Brussels 24/06/2014 1 Table of Contents Preamble... 4 1. Principles for the development of Service Level Agreement Standards for Cloud Computing...
Standards for Internal Control in New York State Government October 2007 Thomas P. DiNapoli State Comptroller A MESSAGE FROM STATE COMPTROLLER THOMAS P. DINAPOLI My Fellow Public Servants: For over twenty
U.S. Department of Energy Office of Inspector General Office of Audits and Inspections AUDIT REPORT The Department of Energy's Management of Cloud Computing Activities DOE/IG-0918 September 2014 Department
2014 Australian Government Information Security Manual CONTROLS 2014 Australian Government Information Security Manual CONTROLS Commonwealth of Australia 2014 All material presented in this publication
Software-as-a-Service (SaaS) and Physical Security Management for Federal Systems Adapting to the forces of HSPD 12, Convergence, and FISMA April 18, 2008 1 Abstract Working to meet the requirements of
NIST Special Publication 800-52 Revision 1 Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations Tim Polk Kerry McKay Santosh Chokhani http://dx.doi.org/10.6028/nist.sp.800-52r1
United States Government Accountability Office Report to Congressional Requesters April 2014 INFORMATION SECURITY Agencies Need to Improve Cyber Incident Response Practices GAO-14-354 April 2014 INFORMATION
Summary of Responses to an Industry RFI Regarding a Role for CMS with Personal Health Records Table of Contents EXECUTIVE SUMMARY... 4 1. INTRODUCTON... 7 2. CMS ROLE WITH PHRs... 9 What PHR functionalities
Department of Health and Human Services OFFICE OF INSPECTOR GENERAL NOT ALL RECOMMENDED FRAUD SAFEGUARDS HAVE BEEN IMPLEMENTED IN HOSPITAL EHR TECHNOLOGY Daniel R. Levinson Inspector General December 2013