Government Compliance Document FIPS 201, FIPS 197, FIPS 140-2

Transcription

1 Government Compliance Document FIPS 201, FIPS 197, FIPS AMAG Technology has been providing tailored and unified security solutions across a range of government agencies facilities for many years. Our range of flexible Symmetry Homeland Security Management Solutions are ideally suited to help protect and secure Government buildings. Symmetry Homeland is a physical access control system (PACS) designed to provide powerful integrated access control and security management solutions for those users that need to comply with Federal regulations such as FIPS 201, FIPS 197, SP , M and HSPD-12 in support of smart card programs such as PIV, CAC, TWIC and FRAC. Symmetry Homeland also supports your non-piv visitors through included visitor management, badging, and optional DESFire card encoding Manhattan Place Torrance, CA USA

2 FIPS 201 Connecting the Dots When the US Government decides to use a common technology across the entire bureaucracy it is an important event. When this decision means that every department and agency will have to update and/or replace systems, industry pays particular attention. Such may be the case with President Bush s directive to move the entire US Government to a smart card-based identity program. In August of 2004, the President signed Homeland Security Presidential Directive (HSPD) 12. This outlined four objectives for a new standard including streamlining (cost savings) government processes, increased protection of personal privacy, and additional measures to prevent unauthorized access to government resources and facilities. The National Institute for Standards and Technology (NIST) is the body responsible for creating government standards. NIST created Federal Information Processing Standard (FIPS) publication 201, also known as FIPS 201, as a federal standard in response to HSPD-12. FIPS 201, Personal Identity Verification (PIV) of Federal Employees and Contractors, is broken into two parts: the first defines requirements of a role-based identity verification and card issuance system, and the second defines the card technology and application of the credential (called a PIV card) for interoperable use throughout the US Government. The intent is that a government worker issued a PIV card can use that credential for access (logical and physical) as well as identification at a variety of facilities for which he/she has been granted privileges. FIPS 201 is a standard that describes the minimum requirements to meet HSPD-12 interoperability and other intentions. As such, an agency can choose to implement systems that meet the minimum requirements or ones that go beyond as long as they do so in a compliant manner. For instance, FIPS 201 defines levels of Confidence that the cardholder is in fact the person they claim to be. The standard does not dictate that any particular level of Confidence must be used, but if a HIGH level of confidence is defined by an agency to be used at a particular security portal, then the standard dictates how that is to be met. In order that the standard itself not necessitate constant updating, particulars of the data model and other areas that are expected to change with new technologies are relegated to the Special Publications. The SP documents are designed to be updated and modified with less bureaucracy than the FIPS standard. There are a number of SP documents identified by the FIPS 201 standard including the SP and SP These define the card data model and the biometric data encoding to be used, respectively. Since the standard does not provide enough information to a security manager to implement a compliant system, there are a number of support documents that have come out and are expected to be released such as the Federal Identity Management Handbook, the SCEPACS-TIG 2.3, and GSC-IS v2.2. These documents attempt to provide additional information as guidance for implementation. However, most cases of federal 2

3 department or individual agency implementation will be unique, and so face-to-face discussions are most informative. Industry groups such as Security Industry Association (SIA) and Smart Card Alliance Physical Access Council (SCA-PAC) are providing forums for individuals from NIST, GSA, OMB, and various departments and agencies to meet and ask questions. 3

4 Historic Timeline 1993 SEIWG-012 standard is published by the Security Equipment Integration Working Group (SEIWG) for use on magstripe credentials AMAG wins US Navy MARC program to use smart cards for physical access control Government Smart Card Interagency Advisory Board (IAB) is formed to guide government adoption of smart card technology IAB releases version 1.0 of Government Smart Card Interoperability Specification (GSC-IS v1.0) SEIWG recommends use of SEIWG-012 standard for smart card applications such as DoD Common Access Card (CAC) IAB releases GSC-IS v2.1. This version identifies interoperability requirements for contactless smart cards as well. Mifare DESFire is selected as the base platform. August 2004 February 2005 HSPD-12 signed by President George Bush. FIPS 201 published by Department of Commerce/NIST DoD issues 4 millionth CAC. October 2005 February 2006 October 2006 October 2007 October 2008 Office of Management and Budget (OMB) deadline for government agencies to comply with PIV-I requirements for credential issuance. NIST opens FIPS 201 to public review. OMB deadline for government agencies to initiate PIV-II compliance. OMB deadline for government agencies to be fully compliant to PIV-II requirements. All employees and contractors should have PIV cards, and most should have completed background checks. OMB deadline for completion of all background checks (including 15+ year employees). 4

5 Glossary FIPS 201 Federal Information Processing Standard publication 201, Personal Identity Verification (PIV) of Federal Employees and Contractors. This is the standard created by NIST to meet HSPD-12 NIST SEIWG PAIIWG FASC-N CHUID Nation Institute of Standards and Technology. NIST is an agency under the Department of Commerce, and is responsible for creating standards that apply to federal systems. NIST cooperates with other standards organizations and is required to use existing standards to the greatest extent possible. Security Equipment Integration Working Group. This group was formed of security managers from various federal departments with the aim to provide a common interface for identification that could be used by commercial equipment manufacturers. The concept was not widely accepted by the manufacturers at the time, but has seen more adoption since the inception. The name SEIWG and the format that was created, SEIWG-012, is no longer used. Today the working group is called the PAIIWG, and the format is called FASC-N. Physical Access Inter-agency Interoperability Work Group. This is the latest incarnation of the original SEIWG. This group is made up of government agency employees (mainly those responsible for security systems), and they provide guidance to other federal agencies on best practices for implementing security systems. Federal Agency Smart Credential Number. This is the latest version of the original SEIWG-012 format. The SSN field has been removed to protect the cardholder s personal privacy. The FASC-N (or portions of it) is the primary identifier of a cardholder in a physical access control system. On a PIV card, the FASC-N is encoded as part of the CHUID. Card Holder Unique Identifier. This is the container encoded on the PIV card, and it is available as a free read through either the contact or contactless interface. The CHUID contains the FASC-N as well as a card expiration date (based on the time of encoding, but not updated), additional identifying information if the FASC-N is not sufficiently unique, an alternate identifier called the GUID, and a digital signature. The GUID and the digital signature may have more important implications for future systems than they do today. PIV Personal Identity Verification. This is the designation given to FIPS 201 (the two sections of FIPS 201 are referred to as PIV-I and PIV-II) and to the smart card that is defined in PIV-II. GUID Global Unique Identifier. This is a 16-byte field in the CHUID, but is expected to be encoded as defined in the IPV6 format. Such a number 5

6 SP SP GSC-IS SCEPACS-TIG OMB GSA would provide a significant volume of IDs that virtually every person, computing device, etc. could have a unique number for the next 20 years. While a lot of assumptions go into that estimate, the single large number is expected to be the replacement for the Wiegand card number. Special Publication This is a NIST document that accompanies FIPS 201. The title is, Interfaces for Personal Identity Verification. This document provides the specifics of the PIV card data model (this is specific to PIV-II) and the card edge commands that are used by the card and the reader to pass information back and forth. Special Publication This is a NIST document that accompanies FIPS 201. The title is, Biometric Data Specification for Personal Identity Verification. This document provides the specifics of the biometric data required to be on the card. The reader must be cautious not to confuse the biometric data required to be on the card with other biometric data that may also be encoded on the PIV card. Basically, fingerprint templates that comply with INCITS 378 (template A) are required to be encoded on the card for interoperability between sites. Government Smart Card Interoperability Specification. This document was the pre-cursor to FIPS 201, and provided government agencies with a standard to which they could refer for smart card application. The document covered logical and physical access control, and also described both contact and contactless interface requirements. At the present time the latest officially released version of the GSC-IS is version 2.1, however version 2.2 is in draft form and will be released soon. This follow-up accounts for FIPS 201. This document is produced by the IAB. Smart Card Enabled Physical Access Control Systems Technical Implementation Guidance. This document provides guidance to federal agency security managers for the implementation of smart cards in PACS. The latest released version is 2.2, however a 2.3 and a 3.0 are in the works. Since FIPS 201 does not adequately address physical security use of the PIV card, the PACS updates are expected to provide very useful information. Office of Management and Budget. This is a federal agency that is directly under the President. OMB is responsible for defining policy across the federal government. As their responsibilities relate to FIPS 201, OMB approves agency/department plans to implement systems in support of FIPS 201 compliance. General Services Agency. This is the arm of government that is responsible for providing purchasing vehicles for federal agencies. The GSA has issued guidance that federal agencies should not purchase 6

7 IAB new systems that are not certified to be compliant to FIPS 201. This does not relate to Physical Access Control Systems, and a revision of the guidance is expected soon. GSA is also working on a categorized list of certified products. Presently there are no categories associated with PACS. Inter-Agency Board. This group is made up of federal employees and is tasked with providing guidance and interoperability specifications to government entities. 7

8 AMAG Technology Support of Integration for FIPS 201 Compliance Federal Information Processing Standard (FIPS) publication 201, also known as FIPS 201, is a federal standard in created in response to Homeland Security Presidential Directive 12 (HSPD-12), signed by the President in August HSPD-12 dictates that the US Government will standardize on a single identification card, and that this card will be used for a variety of applications to streamline government processes and management requirements. FIPS 201 and the associated Special Publications by NIST define minimum standards to enable interoperability among the vast landscape of government departments, agencies and bureaus. The intent is that a government worker issued a PIV card can use that for access (logical and physical) as well as identification at a variety of facilities for which he/she has been granted privileges. Physical access control is one component of the Personal Identity Verification (PIV) system. The PACS will use the contactless interface of the PIV card in particular the CHUID container to relay user identity information to the access control system. The PACS will base its access decision on the ID information off the card, validity information within the PACS database, and privileges assigned to the user. The PACS system relies on the validity of the ID information off the card in its access control decision. The validity of this information is determined by centralized certificate authorities; however, the AMAG system has no direct interface to these services. Therefore, a Card Management System (CMS) or Identification Management System (IDMS) is responsible for relaying validity information to the AMAG database. The most likely method for this communication is XML via Web Services. XML and Web Services are recognized as being fundamental in the move to distributed computing on the internet. They are an industry standard for achieving easy communication between diverse systems, irrespective of the programming languages or platforms that the different systems use. XML and Web Services use Web-based technologies, enabling easy and cost-effective implementation, particularly for companies that already have a Web infrastructure. The interface allows many routine SMS operations to be carried out, such as to: Import details of card holders and visitors. You can, for example, add new card holders, delete card holders, modify existing card holder data, make cards inactive and change access rights. Obtain the details of card holders and visitors who are already in the SMS database. View, acknowledge and clear outstanding SMS alarms. Send a command to a device (e.g. to open a door or switch on a CCTV camera). View the status of an SMS device (e.g. to determine whether a door is locked or unlocked). 8

9 Import alarms from external equipment, such as intruder systems. As an example of the data flow expected in a FIPS 201 compliant system, the employee would submit identity documentation to the IDMS. The IDMS communicates with the CMS to produce and personalize a PIV card. The card is issued to the employee. The IDMS may or may not be responsible for defining PACS access privileges, but at a minimum the PIV CHUID information and validity (expiration date) is passed to the PACS. In a more sophisticated solution, the IDMS will also control PACS access rights, and alarm information can be collected by the IDMS and filtered for employee information that may be stored in the IDMS/personnel database. Card Management System ID Records Personnel Data Employee XML Interface IIS Identity Management System (IDMS) WS Security Web Service SMS Database Certificate Authority Bridge-Certified CA Security Management System (SMS) Import Database 9

10 FIPS 201 Compliant Solutions: From Card Issuance to Operational Use A Symmetry Whitepaper Issue 1, 1 February

11 Introduction In August of 2004, the President of the United States issued Homeland Security Presidential Directive (HSPD) 12 stating that it was in the best interest of the nation that the federal government adopts a consistent credential for the purposes of authenticating identity of government employees and federal contractors. In order for a credential to be interoperable across agencies of the federal government the identification proofing and vetting process must be trusted by all agencies. In response to HSPD-12, the National Institute of Standards and Technology (NIST) produced Federal Information Processing Standard (FIPS) 201, Personal Identity Verification (PIV) of Federal Employees and Contractors to define a standard approach to identity vetting, card issuance, and credential management. FIPS 201 defines the requirements for an identity proofing and vetting process that can be trusted across the enterprise. The PIV programs being implemented by the Federal Government are very complex. A complete, end-to-end solution accomplishes tasks associated with identity proofing, identity vetting, card personalization and issuance, and provides infrastructure for the appropriate use of the card as dictated by HSPD-12. This white paper is intended to describe for the reader the basic components of a FIPS 201 compliant solution how an individual is vetted, provided with a PIV card, and how that card is used across an enterprise. The discussion then goes into how a physical access control system (PACS) from AMAG Technology meets the requirements of FIPS 201 as well as the recommendations of special publication and the Federal Identity, Credential and Access Management (ICAM) segment architecture. Furthermore, AMAG Technology is assisting customers interested in implementing FIPS 201 compliant PACS solutions to fulfill the intent of HSPD-12 that the PIV card be used for physical and logical access to federal facilities. In the last part of this document advanced card authentication methods are described. The intent of HSPD-12 is to make exclusive use of the PIV card for identity authentication. Where the security risk assessment indicates a high-valued asset at appreciable risk, authentication of persons gaining access must utilize higher assurance levels. 11

12 Identity Vetting and Identity Management The first part of FIPS 201 speaks to a multi-role, multi-phase solution for card issuance. Figure 1 is from the standard and outlines 8 steps for an employee or contractor to get their PIV card. Figure 1: FIPS 201 Part 1 System Infrastructure Process 1. Employee completes application for PIV card in the IDMS 2. Supervisor or other authority sponsors the application 3. A separate authority validates the request and approves the application 4. Employee is invited back to submit biometric information and identity documentation 5. The IDMS packages the information and submits for the appropriate NAC/NACI or other background check 6. The background check is performed and reviewed by the approval authority 7. The data package is submitted to card production 12

13 8. The card is provisioned and activated for use employee authenticates before being provided the card. There are no fewer than five (5) participants 1. Employee/applicant, 2. Supervisor/sponsor, 3. Approval authority, 4. Background check investigator, and 5. Card issuance agent. Systems infrastructure applications manage this process. The COTS products available today to perform this function also handle the Identity Management systems (IDMS) function as well. The SI/IDMS software controls the flow of information, imposes the work flow rules, and disseminates information to other systems. Symmetry has some specific identity information such as the information stored about cardholders, but does not manage the vetting and issuance process as described above. Therefore, solutions from partners (see Identifying the Components below) are used to meet these specific requirements, and data is passed into and out of Symmetry as needed. Operational Use of the PIV Card The second part of the FIPS 201 standard goes into the card technology and how the card is to be used for authentication to physical and logical systems for access to government facilities and information resources. Figure 2 on the following page shows how the Physical Access Control System (PACS) and Logical Access Control System (LACS) interact with the Identity Management System (IDMS) which is part of the PIV system infrastructure for issuance in Figure 1. Traditional PACS did not attempt to authenticate the card the mere fact that the card was readable by the system card reader was good enough. Validation was performed on the card number. In future operational systems, the card can no longer be intrinsically trusted. Authentication must be performed on the card including verifying the credential was issued by a trusted authority and that authority must confirm the credential is still valid. The credential can then be validated against an access control list by the PACS. Therefore, the function of the 13

14 PACS is to manage the physical access privileges. Copies of specific identity information are generally stored at the PACS so that all information required by the PACS is stored locally. As shown in Figure 2, the PKI services interact directly with components of the PACS to provide the necessary card authentication and certificate validation services. 14

15 Figure 2: Operational use of PIV card 15

16 Additionally, the physical security design of a facility should account for the level of protection to be afforded to various parts of the facility. In general a facility can be divided into multiple areas with varying degrees of risk associated with those areas. The specific risks to each area are identified and vetted through a security risk assessment process. The description of the security risk assessment is outside the scope of this document, but there are numerous resources available on-line and in print. The security risk assessment will generate detailed data that can be used to form the facility security plan including definition of the various areas within the facility, the specific risks to those areas, the business impact (or life safety impact or national security impact) if those areas were to be compromised, and measures to be taken to avoid that compromise. The facility security plan will define the measures taken to defend against various risks to the facility. Areas within the facility can be categorized into uncontrolled, controlled, limited, and exclusion depicted by the different color shades in Figure 3. Each of these, when proceeding from outer to inner, is more exclusive than the previous. Not every site will have all types of areas, but for the purposes of discussion this general framework has been used in NIST Special Publication , A Recommendation for the Use of PIV Credentials in Physical Access Control Systems. Figure 3 depicts this concept. The circled numbers in the figure represent different use cases defined in SP They are not pertinent to this discussion. The description of the authentication designations are given in the Glossary at the end of this document. 16

17 Figure 3: Facility Map Showing Areas In general, the facility security director will want to have incremental levels of authentication to access successively higher exclusion zones. However, the concepts of security-in-depth (building upon successive layers of security) and security in context (considering that the employee or cardholder has already passed through various security checkpoints) simplify the types of authentication that must occur at each individual portal. For instance, in figure 3 use-case (4) shows that using the Card Authentication Key (CAK) with an attended or unattended biometric match is sufficient to go from uncontrolled directly to either Controlled, Limited or Exclusion areas. However, use-case (1) shows that CAK alone is sufficient to enter a controlled area. If use-case (1) were implemented, then getting into a Limited area from that Controlled area would only need the biometric (attended or not) because the CAK was already authenticated. 17

18 Identifying the Components In FIPS 201, there are specific categories or components and these categories are also referred to by the GSA SIN approval process. These categories within FIPS 201 specifically address the components necessary for establishing an identity and issuing a credential. The additional components like PACS and LACS are added in order to achieve the goal of HSPD-12 for use of the credential. As depicted in figures 1 and 2 there are a variety of components that make up a full end-to-end solution for FIPS 201. Assembling a commercial off-the-shelf (COTS) product to perform these functions the following pieces must all work together. Identity Management collecting identity information, identity proofing and vetting, and providing the rules to enforce ownership, safeguarding, and utilization of identity information Card Management interfacing with identity repository, creation of various credentials and digital certificates to validate those credentials, print and personalize/encode the cards for issuance Logical Access Control create access privileges and allow card to be used for access to IT resources, encrypt , and digitally sign documents PKI Authentication Services interface with the card management service to validate digital certificates, create digital certificates with public and private key pairs, and generate the CRL Physical Access Control manage access privileges and allow PIV card to be used for access to facilities, and interface with PKI for card authentication. In this scenario, the physical access control system (PACS) is made up of a variety of components including the access rights management software, credential enrollment, database, graphical user interface, field control panels, and card readers. The traditional access control system made assumptions about the authenticity of the card presented at the reader if the reader could read the card, if the facility code was recognized and the card number was registered in the database, then the card was likely authentic and valid. NIST Special Publication points out to the PACS community that if you don t perform an authentication of the card you cannot trust the data that comes from it. That authentication could be a visual inspection of the card, but more appropriately it should be an electronic authentication using public/private key challenge and response. Such operations have been common in the IT sector for some time; however in an IT solution, you have the power of the PC to perform the operations. Until recently, the ability to perform these functions in a stand 18

19 alone reader at the door was not widely available. A strong authentication should rightfully be performed before enrolling the card in the system as well. Therefore there are additional categories of functions that are rolled up into the PACS function. These are: PACS Enrollment a subsystem that is capable of performing a full card authentication and three (3) factor authentication of the card and cardholder PACS Card Reader a device at the portal that will locally perform the appropriate level of card and cardholder authentication. This may be something as simple as performing a free read of the CHUID (when such simple authentication is acceptable), or may entail card authentication, certificate validation, PIN verification, and biometric cardholder verification Mobile PACS Solution a device that is easily portable and generally held in a single hand allowing the other hand to be available to manipulate the device (enter keystrokes, use a stylus, or swipe a card). The Mobile PACS solution interfaces with the PACS server over a WiFi wireless network or when docked in a connected cradle. The Mobile PACS solution is a force multiplier allowing the manned security force to monitor the PACS for alarm activity while patrolling the facility. Video Surveillance the ability to view areas of the facility remotely through cameras strategically positioned to provide the appropriate visibility. Video surveillance is a force multiplier allowing a single security officer to view strategic areas of the entire facility without leaving the alarm monitoring station. Security Communications the ability to provide bi-directional voice communications to strategic areas of the facility. Security communications provides the ears where video surveillance provides the eyes. AMAG Technology partners with a large number of vendors to bring comprehensive solutions to our customers. AMAG s Symmetry security management solution offers various options for integration with external systems. Table 1: Component Manufacturers From GSA Approved Products List and Other Function Vendor Product Physical Access Control AMAG Technology Symmetry PACS Enrollment Innometriks Codebench MorphoTrak Inno-NetSync-Server PIV Check Plus PIV-TWIC-Connect 19

20 Function Vendor Product PACS Card Reader Mobile PACS Solution Video Surveillance PKI Authentication Svcs Innometriks HID, XceedID, Farpointe Data Veridt, MorphoTrak, L1, Bridgepoint DAP/Hawkeye Datastrip/Codebench Axis, Sony, Panasonic, Bosch Pelco, OnSSI, Milestone Corestreet XTEC Rhino Hawkeye Mobile PIV Check Plus Validation Authority AuthentX Security Communications Stentofon AlphaCom Identity Management Card Management Card Production Intellisoft Quantum Secure ActivIdentity Intercede XTEC HID/Fargo Datacard ICEware SAFE ActivID CMS MyID AuthentX HDP5000, DTC550 SP75 Logical Access Control ActivIdentity ActivClient NIST SP NIST special publication was mentioned earlier. This document is a recommendation from NIST on the use of PIV credentials in PACS systems for government agencies. The document identifies a number of critical issues. First is that every PACS system must be designed in consideration of a physical security risk assessment. The risk assessment will identify for the security designer what assets are at risk, what the risks are, the consequences 20

21 of compromised security, and other design aspects. Armed with this information the security designer can go about defining levels of authentication for different areas around the facility. Next the document reinforces the concept of security in context - that security at any one location within a facility should be taken in context of what assets are within successively more secure areas of a facility, and what assurances have already been provided having gotten to the point in question. Such a solution assumes that an additional concept of security in depth (additional security for successively more sensitive information) is in place. For instance, if a PKI card authentication challenge is issued at the perimeter of the facility, it can well be assumed that further card authentication is not necessary for that particular card. Therefore, if the PACS has a means of tracking an individual through the facility such as anti-passback, then additional authentication of the same type is simply redundant. Consider also, that checking the digital signature of signed elements on the PIV card provides assurance that the data was generated by a trusted entity; however if the digital signature is validated at enrollment, then do additional checks of the signature at each portal provide any additional assurances? By performing the traditional validation of the card information in the local PACS database, one achieves the same level of confidence in the credential. SP also highlights the fact that if you have not established your trust in the PIV cards authenticity, then you cannot trust any of the data that comes from it. This level of trust is often tied to the number of factors of authentication that have been performed to gain the trust. Those factors are: something you have (a PIV card issued by a trusted authority), something you know (your PIN validated by the PACS or by the card), and something you are (your biometric as verified by an appropriate device). Per the recommendation, if you have not authenticated the card (performed the challenge and response to the PIV authentication key or the Card authentication key (CAK, pronounced like cake ) and validated the digital certificate through the chain of trust) then you cannot trust the FASC-N number the card reports as a full single factor. Furthermore, since the card could be a counterfeit, and since the card itself validates the PIN supplied from the cardholder, if the card is not authenticated the card-validated PIN is also not a trusted factor. However, as a side note, a PACS-validated PIN is a trusted factor since the PACS is trusted. This is not to say that threefactor authentication is required or even desired at every portal. Such an extreme level of assurance would have the negative impact of low throughput, high rate of false rejection, significantly higher cost of installation and maintenance. Finally, SP describes a PIV Implementation Maturity Model (PIMM). The maturity model lists five levels of implementation sophistication for which the PIV card has been embedded in the physical security solution. The highest level is described in this way. Maturity Level 5 Access to Exclusion, Limited, or Controlled Areas by PIV or Exception Only. Access to Controlled areas (showing evidence of organizational affiliation, or registration for a visitor, with or without escort) is permitted by PIV authentication or 21

22 exception only. At Level 5, currently deployed non-piv PACS cards are not acceptable for authentication to any areas. That is, only the PIV Card is an acceptable credential for Federal employees and contractors. Symmetry supports use of the PIV card for access to exclusion, limited, or controlled areas. Furthermore, by implementing various reader technologies, solutions can be implemented that provide 1-, 2-, or 3-factor authentication for access to those areas as defined by the facility security risk assessment. 22

23 Federal Identity, Credential and Access Management (ICAM) The Federal CIO Council has released additional guidelines to consolidate the practices around PIV use for authentication to access physical and logical resources. The Federal ICAM Roadmap provides courses of action, planning considerations, and technical solution information across multiple federal programs spanning the disciplines of identity, credential, and access management. 1 Integral to the discussion of consolidated identity, credential and access management is the recognition that the goal is to help the Federal enterprise leverage digital infrastructure to securely conduct business electronically between Federal agencies, their business and coalition partners and with the American public, by promoting the use of authentication, digital signature, and encryption technologies. The primary compliance driver for the development of the Federal ICAM Roadmap was electronic authentication (E-authentication) Policy Framework. Two of the enablers of this policy are HSPD-12 and Federal PKI initiatives. The previous section has described NIST SP , and that document s clear statement that recognition of a credential does not provide a sufficient level of authenticity for the purposes of Federal ICAM. Therefore, some sort of challenge to the card authentication private key or other mechanism for credential authentication is required before the card can be determined to be valid, non-counterfeit, and presented by the rightful owner. All of the guidance is designed to shed light on the fact that too many assumptions have been made in the past, and that technology now provides a means of better achieving these goals. ICAM goes well beyond the scope of physical access control. The ICAM roadmap offers an approach to identity management wherein creation and management of digital identity records are shifted from stove-piped applications to an authoritative enterprise view of identity that enables application or mission-specific uses without creating redundant, distributed sources that are harder to protect and keep current. The PACS may intersect with the ICAM framework in that the PIV card is interoperable across federal agencies and even has the potential to be interoperable with PIV-I cards issued outside of the federal government. Therefore, PACS design must recognize and support the ICAM framework. The Symmetry security management system has supported the concept of federated identity management for many years pre-dating FIPS 201, HSPD-12 or the Federal ICAM Roadmap. Initially this concept was implemented by integrating with existing human resource applications such as PeopleSoft or SAP. These applications were the pre-cursors to identity management in a commercial enterprise. They provided the centralized authoritative source for identity 1 All quotes are from Federal Identity, Credential, and Access Management (FICAM) Roadmap and Implementation Guidance, November 10,

24 information within the enterprise. Eventually this was expanded to an IT directory service such as Active Directory or other LDAP products as the authoritative source. Through integration directly to database applications and with third-party products, the Symmetry system continues to leverage ICAM concepts in commercial and federal installations. Without a centralized identity management, each application that relies on identity information, then must develop a stove-piped approach to identity management that aggregates identity, credential, and access management (ICAM) for the specific application. With a large array of application all performing the same functions to varying levels of accuracy, sophistication, or compliance with federal regulations it becomes quite obvious that the duplication of effort alone provides a return on investment to the end user. Furthermore, by federating or centralizing the identity and credential management to applications suited for that purpose, the access (physical or logical) management can focus on the application specific functions. The ICAM roadmap includes use-cases, and one of these is specific to granting physical access to an employee of a federal agency or a contractor. The document analyzes the typical approach in many agencies with legacy access control systems, analyzes the target situation, and comes up with three areas of gaps. Inability for many PACS to meet new requirements for electronic authentication AMAG Technology, in concert with partners, can provide a PACS solution that meets these requirements. Lack of integration between PACS and other ICAM systems (provisioning and credentialing systems) Symmetry provides standards-based APIs for integration to other ICAM systems, and can be delivered today with integration to provisioning and credentialing systems. Need to determine which PIV features are required to adequately mitigate the inherent risks associated with physical access control for agency facilities Symmetry PACS solutions have been fielded in a variety of installations to meet everything from basic functionality to extremely sophisticated security requirements. Therefore, it is clear that through integration, the availability of standards-based APIs, and deployment by certified installation teams Symmetry meets the expectations of future Federal ICAM-enabled projects. 24

25 Conclusion Guidance for federal security directors from NIST and other federal government sources recommends that a security risk assessment be conducted and act as the foundation of a facility security plan that describes what level of authentication is required at various locations within the facility. Therefore, there is no single solution that will meet the needs of various government facilities. Instead, the solution offered by AMAG Technology is one that allows personalization to the specific requirements of the customer. Using Symmetry Homeland security management system as the PACS platform, allows seamless integration with components to round out the entire end-to-end solution in support of credential usage as defined in FIPS 201, SP , and the Federal ICAM standards and guidance. Furthermore, the same solutions can be used to deploy advanced solutions for TWIC, FRAC or other FIPS 201- based credentials. For instance, multi-factor authentication at the enrollment station supports local registration of centrally issued PIV cards, integration supports registration through CMS directly, biometric/card readers at the edge of the network can support local authentication (such as reading the CHUID) or perform challenge and response as well as certificate validation. Periodic checks against a CRL are also supported. Furthermore, a variety of readers are supported. Readers from Innometriks and others can support all of the recommendations of SP provided the PIV card supports the authentication mechanisms. Readers from AMAG Technology and others support a variety of lower authentication mechanisms. End-to-end solutions start with the personnel enrollment and sponsorship process. The system infrastructure provides the mechanisms by which the identities are proofed, vetted, and issued a credential. The individual is provided with a card, but all of that effort is for naught if the card is not used exclusively for the purpose of authenticating identity for access to physical and logical assets. For this reason AMAG Technology and our partners work together to provide solutions to meet customer needs. Interested parties are advised to contact AMAG Technology Director of Federal Systems, Terry Crawford, ([email protected]). 25

26 Glossary BIO BIO-A CA CAK CHUID CIO CMS COTS CRL FASC-N This is the designator defined in FIPS 201 for a biometric authentication. This is the designator defined in FIPS 201 for a biometric authentication that is attended by a human operator that monitors the process to discourage inappropriate actions. Certificate Authority. The CA may itself require a signing certificate issued by a trusted party. The CA is responsible for generating digital certificates on demand and managing those credentials over their lifespan (digital certificates have a defined expiration date). Card Authentication Key. This is a digital certificate defined in FIPS 201. The CAK is an optional data element, and some agencies have chosen not to implement this item. CAK can be used to provide PKI card authentication over the contactless interface. Card Holder Unique Identifier. The CHUID is a container on the card as defined by FIPS 201. This container is a free read (no authentication is required to access the data), and is a mandatory data element so it is guaranteed to be on every compliant card. CHUID also refers to the designation from FIPS 201 of a system that only reads the CHUID to provide access. CHUID authentication is considered 0 factors by NIST and as alluded to in SP Chief Information Officer. The CIO Council, made up of CIOs of various government agencies, approved the release of the Federal ICAM segment architecture in September of Card Management System. This could also be referred to as the credential management system. A credential is a physical or electronic token that is associated with a person s identity. A card can be a credential, but a smart card can carry various credentials (one used to encrypt while a different one used to authenticate the card, etc.). Commercial off-the-shelf. This refers to a commercially available product as opposed to a custom-designed solution. Certificate Revocation List. This is a list of digital certificates issued by a particular CA that have since been revoked by the CA. Federal Agency Smart Credential Number. The FASC-N is defined by FIPS 201 as a unique identifier (in fact the first 3 fields provide a unique identification) within the federal government. The FASC-N is made up of multiple fields including the Agency code, System Code, and Credential number. These fields are only defined for the federal government, and therefore to prevent numbering conflicts, nongovernment use of the PIV 26

27 FICAM FIPS FRAC GSA HSPD ICAM IDMS LACS NAC NACI NIST Federal ICAM. See ICAM. Federal Information Processing Standard. In the context of this document only FIPS 201 is referenced but NIST has generated standards for a number of other programs that affect federal government. Often one standard will reference another. First Responder s Access Credential. The FRAC is issued to emergency personnel (police, fire fighters, medical personnel, etc.). The FRAC is based on FIPS 201, but also includes information about the individual s particular certifications and specialty. The FRAC could be interrogated by perimeter security to authenticate the individual and direct them to the proper area in a disaster event. General Services Administration. The GSA developed the Managed Service Offering (MSO) to provide PIV card provisioning for those agencies that did not want to implement a full system infrastructure for themselves. Homeland Security Presidential Directive. HSPD-12 was signed by President Bush in August of Identity, Credential and Access Management. ICAM is a recent program in the federal government that recognizes that efforts such as eauthentication, FISMA, and FIPS 201 overlap and intersect. The Federal ICAM roadmap is guidance for security directors to implement solutions that cover all of the requirements. Identity Management System. An IDMS is responsible for the management of identity data. This process starts with the identity proofing (proving the individual is who they claim to be), and goes to identity vetting (background checks to ensure that a level of responsibility can be given to the individual), and association of the physical identity with electronic credentials. Often the IDMS will also include the work flow required to implement FIPS 201 systems infrastructure. Logical Access Control System. The LACS is a component of a complete PIV-based security system. The responsibility of the LACS is to manage access to information assets and electronic resources. National Agency Check. This is a form of background check referenced in FIPS 201 for the vetting of identity information in order to be issued a PIV card. National Agency Check with Written Inquiries. This is a more in-depth version of the NAC identity vetting background check. National Institute of Standards and Technology. NIST is responsible for developing and promoting standards for information processing within the federal government. 27

28 OCSP PACS PIMM PIN PIV PIV-I PKI TWIC On-line Certificate Status Protocol. This protocol allows a system or device reading a smart card with one or more digital certificates to determine the current validity status of the certificate. The server implementing OCSP will have access to the CRL or the CA directly. Physical Access Control System. The PACS is a component of a complete PIV-based security system. The responsibility of the PACS is to manage access rights for individuals. A credential issued to the individual is assigned access rights in the PACS and then the PACS will be called upon by various systems to validate access requests. PIV Implementation Maturity Model. The PIMM was introduced by NIST in special publication It offers the security director a metric by which their agency s progress toward exclusive use of the PIV card for identity authentication can be measured. SP is a recommendation for using PIV cards in a PACS, but PIMM has application in LACS as well. Personal Identification Number. A PIN is a secret that is known only to the individual. Therefore, if the PIN is considered an authentication factor if it is validated by a trusted entity. If the PIN is validated by a card that has not been authenticated, then the PIN validation cannot be trusted. The PACS is a trusted entity so a PIN validated by the PACS would count as an authentication factor. Personal Identity Verification. This is also the generic name used to reference the federal government programs designed to implement FIPS 201 solutions. PIV-Interoperable. This refers to a card produced by a non-government organization that is designed to be interoperable with the federal government PIV system. Public Key Infrastructure. This term commonly refers to the process as well as the infrastructure to make the process work. Therefore a PKI card reader is one that communicates out over the network to infrastructure components such as OCSP responders, etc. Transportation Worker Identity Credential. The TWIC is a card issued by the TWIC program office of the Transportation Security Agency. TWIC is only issued to those individuals that have a business reason for being at a port or other regulated facility. A valid TWIC is required for unescorted access to areas of the facility that are deemed secure areas. TWIC is based on FIPS 201, but offers an encrypted fingerprint template over the contactless interface that is not available on most PIV cards. 28

29 VIS This is the designator defined in FIPS 201 for a visual authentication of the PIV card. It requires an operator be able to recognize the card, inspect it for anti-counterfeit features, and match the printed picture to the cardholder. VIS is considered a single factor card authentication. Revision History 23 Dec 2009 Initial draft release, Issue Feb 2010 Incorporated feedback from reviewers. Added Glossary, Issue

30 800 Readers Series is FIPS 201 Compliant Letter: To Whom It May Concern: This letter is to define for you the compliance to Federal Information Processing Standards (FIPS) of the 800-series readers from AMAG Technology. The AMAG 800-series readers come in different varieties to read different card types. When it comes to Federal identity systems, the readers of note are the 844 contactless smart card reader, the 884 contactless LCD keypad smart card reader, and the 874 outdoor smart card reader. These readers are appropriate to further the objectives of HSPD-12 and FIPS 201. All three of these readers (and derivations with and without keypads, for instance) are designed to read ISO Type A and Type B contactless smart card credentials per NIST SP and NIST SP To meet the needs of the Federal government and other associated users, these readers are designed to be interoperable with PIV cards from all Federal agencies including the Common Access Card from the Department of Defense. These readers are simultaneously capable of reading DESFire cards locally encoded through the Symmetry Security Management System from AMAG Technology. Whereas the Federal government has set up the General Services Administration (GSA) Approved Products List (APL), the 844 is already listed as a transparent reader. The 884 and the 874 are pending testing and will be added to the list of transparent readers as well. The GSA APL does not currently have a category for physical access control systems (PACS) and therefore, there are no other components of our typical deployment that are required to be listed on the GSA APL. AMAG Technology is able to field solutions that meet various levels of strong authentication and that can be deployed to mitigate the threats identified in your facility risk assessment. Where appropriate, the Symmetry readers (which do not perform card authentication/validation) can be used for access control. However, more secure areas should utilize readers providing card authentication/validation and perhaps biometric authentication. Thank you for considering AMAG Technology for your security needs. Sincerely, Adam Shane Product Manager, Identity 30

31 AMAG Technology s Symmetry Software Portfolio Becomes FIPS 197 Certified Torrance, CA, September 2, 2010 AMAG Technology, a security management and digital video solution provider, announces that its Symmetry Security Management software portfolio has obtained Federal Information Processing Standard 197 (FIPS 197) certification. FIPS 197 is the US Government specification for the Advanced Encryption Standard (AES). National Institute of Standards and Technology (NIST) has set up a validation program for the AES implementations that includes passing the Advanced Encryption Standard Algorithm Validation Suite in a NIST National Voluntary Laboratory Accreditation Program accredited Cryptographic Module Testing laboratory. Considered a benchmark for security in government, FIPS 197 is used by Federal departments and agencies when security information needs cryptographic protection. Symmetry s FIPS 197 certification meets the requirements of numerous Federal government customers. The FIPS 197 certification demonstrates AMAG s commitment to the Federal market to provide security that meets the highest government standards, said AMAG Technology, Senior Vice President of Sales and Marketing, Matt Barnette. For more information about AMAG Technology s FIPS 197 Certified Symmetry Product Portfolio, visit or contact Customer Service at About AMAG Technology AMAG Technology s Symmetry Security Management and Video Solutions can be found in a wide spectrum of markets: government, commercial, education, transportation, healthcare, utilities and banking. Based out of Torrance, California with sales and support located throughout the US, AMAG sells its Symmetry Product Portfolio of access control and network video systems through its Symmetry Authorized Resellers throughout North America. AMAG Technology is part of G4S Technology, a leading manufacturer of scalable, integrated security management systems headquartered in Tewkesbury, 31

32 NIST Advanced Encryption Standard Algorithm Validation List Updated 8/31/2010 The page provides technical information about implementations that have been validated as conforming to the Advanced Encryption Standard (AES) Algorithm,as specified in Federal Information Processing Standard Publication 197, Advanced Encryption Standard. The list below describes implementations which have been validated as correctly implementing the AES algorithm, using the tests found in The Advanced Encryption Standard Algorithm Validation Suite (AESAVS). This testing is performed by NVLAP accredited Cryptographic And Security Testing (CST) Laboratories. For the original modes of operation (ECB, CBC, CFB, OFB), this information consists of the modes of operation tested (e.g., ECB, CBC, CFB, OFB), states (encryption(e) and/or decryption(d)), and key sizes (128-bit, 192-bit, and/or 256-bit) for which the implementation was validated. For Counter (CTR) mode, the counter source (internal(int) and/or external(ext)) is also indicated. Validation No. Vendor Implementation Operational Environment Val.Date Modes/States/ Key sizes/description/ Notes 1314 G4S Technology LimitedChallenge House, International DriveTewkesbury, Gloucestershire GL20 8UQUnited Kingdom-Steve AmosTEL: FAX: Kevin HollingworthTEL: FAX: Symmetry Cryptographic ModuleVersion Intel Core 2 Duo w/ Microsoft Windows XP Professional SP3 (x86); Intel Core 2 Duo w/ Microsoft Windows Vista SP2 (x86); Intel Core 2 Duo w/ Microsoft Windows 7 (x86); Intel Quad Core Xeon w/ Microsoft Windows Server 2003 SP2 (x86); Intel Quad Core Xeon w/ Microsoft Windows Server 2008 SP2 (x86) 4/13/2010 CFB128(e/d; 256)"The Symmetry Cryptographic Module provides AES 256 bit encryption functionality to enable a client application to provide a secure channel for transmission of data across a network." Data captured from 32

33 FIPS Validation Certificate 33

34 34

35 Contact Information For more information or a free Symmetry TM demo, we invite you to contact an AMAG Regional Sales Manager or our Business Development team. phone: , [email protected] visit our site at 35