1 The PIV Working Group appreciates the opportunity to provide guidance on the initial scope for ICAM Part B. In addressing your request we created three bodies of content: Required changes to Table 6 2 in FIPS 201 Elements of a Chapter 1 of ICAM B What is an End Point PACS? Discussion of architecture versus functionality Required changes to Table 6 2 in FIPS 201 We believe the following table summarizes reality today based on the body of PIV documents (specifically FIPS 201 1, SP ,) and the GSA Approved Products List. This table will make it easier for the consumer to understand the difference between a trusted and non trusted authentication factor, how they can be combined for higher confidence, and which to select for a given application. Required changes to FIPS 201, Table 6 2 Authentication Factors for Physical Access PIV Assurance Level at the Door Trusted Authenticati on Factors Single NO confidence 0 VIS, CHUID, BIO, PIN to CARD Combination VIS + CHUID, CHUID + BIO SOME confidence 1 BIO (S), CAK, PIN to PACS CHUID (S) HIGH Confidence 2 PKI PIN to PACS + CAK, CHUID (S) + PIN to PACS BIO (S) + CAK, BIO (S) + PIN to PACS, PKI + BIO, CHUID (S) +BIO (S) VERY HIGH Confidence 3 PKI + BIO (S), PIN to PACS + CAK + BIO (S). CHUID (S) + BIO (S) + PIN to PACS Notes: 1. The fundamental premise of ICAM is that only trusted authentication factors will be used, so there is a need to categorize assurance levels based on trusted authentication factors. 2. ICAM focuses on end to end results, including use of the PACS, and is not limited to the card. Hence PIN to PACs, a valuable trusted security measure is included above. 3. CHUID (S) incorporates the signature checking option which results in one trusted authentication factor. CHUID has on trusted authentication factors.
2 4. BIO (S) incorporates the signature checking option which results in one trusted authentication factor. BIO has no trusted authentication factors. 5. BIO A is not shown as there are not good directions for what the attendant should do or how to do it. 6. The assurance achieved at the door cannot be greater than the assurance validated at registration to the PACS. 7. CAK is an Option and may not be present. There are two versions Symmetric and Asymmetric, and either contact or contactless are permitted, though PKI is only Asymmetric on the contact interface. 8. The last entry in the VERY HIGH Confidence does not include a Challenge, though it is three trusted factors. This may deserve some consideration of whether a Challenge becomes a mandatory threshold. Chapter 1 What is an End Point PACS? Assumptions 1. All Options will be made Mandatory (via new or updated standards supported by vendors and users) a. To ensure Interoperability b. To avoid rejection of otherwise good cards c. To ensure only trusted objects are used d. To provide an alternative to the PIV Auth Cert for Physical Access 2. The standards will support HIGH and VERY HIGH Confidence Assurance Levels for Contactless to meet the need for convenient transactions and productivity a. Else folks will bypass the rules to avoid waiting in lines b. Else there will be no environmentally friendly solution 3. PIN to PACS will be recognized as a trusted authentication factor a. Else many agencies will not accept PIV b. Other out of band factors can also be recognized, but the issue of binding must be addressed, whether OTP, cell phone, etc.
3 i. Biometrics should be recognized and an excellent mechanism to bind the person to another trusted authentication factor 4. Cryptography will be used end to end all the time a. All components will carry the time to market and high cost burden of FIPS i. And the burden of transition to FIPS b. PACS Host and PACS Controllers will need to be tested for compliance 5. PKI techniques will be used for all critical components involved in identity processes a. Controller b. Reader if performing challenge/response, signature checking, cert checking i. Else can be done by another component c. Other Security Devices and Systems such as Video and Audio Surveillance 6. Support UUID in addition to or potentially in lieu of the FASC N 7. All PIV Cards will be reissued for compliance and interoperability. a. The normal refresh process can achieve this over time if the compliance changes become mandatory ASAP for all new cards being issued 8. End Point PACS provide direct solutions for card authentication a. They will have to meet the same criteria for their own components anyway b. Device authentication will establish trusted system components. Non Person Entities (NPE) will likely use certificate based authentication to achieve identity convergence between people and things. 9. PACS will continue to perform Intrusion Detection in a converged, UL Listed manner so as to preclude false alarms on authorized access onto secure areas. 10. The Controller will have the Power of a PC a. Able to download firmware for PIV Middleware changes i. And on to the reader if it participates in the process b. To fully utilize the power of the Card c. Will be able to synchronize with the PKI to provide response to local and off line credential validation queries
4 11. The Reader will be more like a sensor only or a USB Reader for a desktop environment a. To ensure only critical components are on the Attack side of the secure perimeter i. Two Part Readers (or Reader/Controller hybrids can also comply) b. To reduce the cost of firmware changes and FIPS 140 and GSA APL re submittal requirements c. Some implementations may consist of a reader that is also a single door controller designed to perform the security process. 12. All PACS will be FISMA Compliant 13. PACS will be bought with Professional Services from the Manufacturer and annual maintenance contracts. Figure 1 Significant Differences between PACS today and PACS ICAM. Discussion of Architecture versus Functionality 1. Multiple architectures exist and will appear over time to achieve the desired functionality
5 2. The functionality can reside anywhere in the architecture, whether in the reader, the controller, the host, or another component. 3. Response time will likely exceed expectations developed from past experiences with 125KHz Proximity cards. The customer should determine their response time requirements and interview suppliers to determine whether they comply. Faster response times might require different architectures or higher cost. Different response times might be acceptable depending on use case (high traffic entry vs, high security area) 4. Critical ICAM Functionality that will have to be in an end point PACS, requiring upgrade or replacement will include: a. Challenge/Response of the Card s Certificate(s) b. Signature Checking c. Certificate Status Checking d. Path Validation e. Ability to support up 128 bit UUID 5. Existing PACS (or indeed Security System) functionality needs to be sustained. For instance UL listings, intrusion integration to prevent false alarms on authorized access, continued operation even under degraded network capabilities, etc. 6. Additional new functionality or specification changes may impact the architecture of the End Point PACS contemplated today.
6 Current State PACS Client Server with PACS Software/Database Multi Door Controller Reader Interface Contactless Reader Figure 2 Current State of PACS
7 A B Server verifies certificates, updates user records Multi Door Controller with local certificates (updated daily) Example upgrade options for PACS to accommodate certificate validation (any transparent readers must replaced with challenge/response readers) C D Smart Reader Interface (to verify certificates) Next generation solutions Figure 3 Example Upgrade Options for PACS to Accommodate Certificate Validation
8 PIV Assurance Level at the Door Single Combination PKI + BIO (S) PIN to PACS + CAK + BIO (S) CHUID (S) + BIO (S) + PIN to PACS PKI PIN to PACS + CAK, CHUID (S) + PIN to PACS BIO (S) + CAK BIO (S) + PIN to PACS PKI + BIO CHUID (S) +BIO (S) BIO (S) CAK PIN to PACS CHUID (S) VIS PIN to CARD CHUID BIO Figure 4 PIV Assurance Level at the Door
Physical Access Control System (PACS) in a Federal Identity, Credentialing and Access Management (FICAM) Framework PACS Best Practices using PKI-Authentication A SIA White Paper Security Industry Association
The Convergence of IT Security and Physical Access Control Using a Single Credential to Secure Access to IT and Physical Resources Executive Summary Organizations are increasingly adopting a model in which
Firewall Strategies June 2003 (Updated May 2009) 1 Table of Content Executive Summary...4 Brief survey of firewall concepts...4 What is the problem?...4 What is a firewall?...4 What skills are necessary
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
The Critical Security Controls for Effective Cyber Defense Version 5.0 1 Introduction... 3 CSC 1: Inventory of Authorized and Unauthorized Devices... 8 CSC 2: Inventory of Authorized and Unauthorized Software...
Card-Not-Present Fraud Working Committee White Paper: Near-Term Solutions to Address the Growing Threat of Card-Not-Present Fraud Version 1.0 Date: April 2015 About the EMV Migration Forum The EMV Migration
PHYSICAL SECURITY OVER INFORMATION TECHNOLOGY GUIDANCE DOCUMENT March 2014 This guidance document has been produced by CPNI in conjunction with MWR InfoSecurity. Disclaimer Reference to any specific commercial
MOBILE DEVICE SECURITY FOR ENTERPRISES V.2 Final Draft September 12, 2014 firstname.lastname@example.org This revision incorporates comments from the public. Page Building Block 1 Comments 14 Certain commercial
The Future of Mobile Enterprise Security Gearing Up for Ubiquitous Computing August 2014 795 Folsom Street, 1 st Floor San Francisco, CA 94107 Tel.: 415.685.3392 Fax: 415.373.3892 Contents Introduction...
Security Standard The security and risk management baseline for the lottery sector worldwide Updated by the WLA Security and Risk Management Committee V1.0, November 2006 The WLA Security Standard is the
Standard: Version: Date: Requirement: Author: PCI Data Security Standard (PCI DSS) 1.2 October 2008 6.6 PCI Security Standards Council Information Supplement: Application Reviews and Web Application Firewalls
JANUARY 2013 REPORT OF THE DEFENSE SCIENCE BOARD TASK FORCE ON Cyber Security and Reliability in a Digital Cloud JANUARY 2013 Office of the Under Secretary of Defense for Acquisition, Technology, and Logistics
WHITE PAPER Securing Your Cloud-Based Data Integration A Best Practices Checklist A Report on Secure Integration Techniques Targeted at the Information Technology Executive Prepared by Mercury Consulting,
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
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...
Standard: Version: 2.0 Date: June 2011 Author: PCI Data Security Standard (PCI DSS) Virtualization Special Interest Group PCI Security Standards Council Information Supplement: PCI DSS Virtualization Guidelines
Report Number: I332-016R-2005 Security Guidance for Deploying IP Telephony Systems Systems and Network Attack Center (SNAC) Released: 14 February 2006 Version 1.01 SNAC.Guides@nsa.gov ii This Page Intentionally
FOREWORD A key component in protecting a nation s critical infrastructure and key resources (CIKR) is the security of control systems. WHAT ARE CONTROL SYSTEMS? Supervisory Control and Data Acquisition
Oracle WebCenter Content 21 CFR Part 11 Certification Kim Hutchings US Data Management Phone: 888-231-0816 Email: email@example.com Introduction In May 2011, US Data Management (USDM) was
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
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
WHITE PAPER IT Governance and the Emergence of Cloud Computing May 2011 IT governance and the emergence of cloud computing: using project and portfolio management to make effective cloud decisions Steven
Mobile Security Reference Architecture May 23, 2013 Product of the Federal CIO Council and Department of Homeland Security National Protection and Program Directorate Office of Cybersecurity and Communications