HSPD-12_IDMS_Functional_Requirements_Document.pdf

Functional Requirements Document (DRAFT) 4-23-2013

Identity and Credential Management System

Functional Requirements Document (DRAFT)

Date Approved

Identity Management Division (IMD)

Contents

1.0 INTRODUCTION

1.1 Project Description

1.1.1 Background

1.1.2 Purpose

1.1.3 Assumptions and Constraints

1.1.4 Interfaces to External Systems

1.2 Points of Contact

1.2.1 Information

1.2.2 Coordination

1.3 Document References

2.0 FUNCTIONAL REQUIREMENTS

2.1 Data Requirements

2.2 Technical Solution Requirements

2.3 Workflow Management Requirements

2.4 User Interface Requirements

2.5 PIV Sponsorship

2.6 PIV Pre-enrollment

2.7 PIV Enrollment

2.8 Issuance

2.9 Re-Issuance

2.10 Card Revocation

2.11 Revocation List

2.12 Auditing

2.13 Searching/Reporting

2.14 IDENT Integration

2.15 Consumable and Supply Chain Management

2.16 PIV Card Issuance Facilities (PCIF)

3.0 OPERATIONAL REQUIREMENTS

3.1 Security

3.2 Audit Trail

3.3 Data Currency

3.4 Reliability

3.5 Recoverability

3.6 System Availability

3.7 Fault Tolerance

3.8 Performance

3.9 Capacity

3.10 Data Retention

3.11 Interfaces

4.0 REQUIREMENTS TRACEABILITY MATRIX

APPENDIX A – GLOSSARY

APPENDIX B – Applicable Laws, Directives, Policies, Regulations, and Standards APPENDIX C – Data Requirements APPENDIX D – Requirements Traceability Matrix

1.0 INTRODUCTION

The present Identity Management System (IDMS) was designed in 2008 and has remained basically unchanged since its inception. New more capable methods are now available that must be evaluated and implemented to move the IDMS process into compliance with HSPD-12; Office of Management and Budget (OMB) Memorandum M-11-11, Continued Implementation of Homeland Security Presidential Directive (HSPD)-12 – Policy for a Common Identification Standard for Federal Employees and Contractors, February 3, 2011 (“M-11-11”); and Federal Identity, Credential and Access Management (FICAM) Roadmap and Implementation Guidance, Version 1.0, November, 2009. In addition, the IDMS technical solution shall be built following FICAM Roadmap and Implementation Guidance which provides overarching architecture and implementation guidance in support of HSPD-12, National Institute of Standards and Technology (NIST) specifications, and other mandates and guidance. This Functional Requirements Document (FRD) provides the preliminary requirements for reengineering and integrating the IDMS, a key DHS identity repository.

1.1 Project Description

1.1.1 Background

Since 2008, DHS has provided an IDMS to serve as the focal point for aggregating and correlating personnel biometric, biographic, attributes, cryptographic, certificate and credential information for DHS employees and contractors. The IDMS supports Federal Information Processing Standard (FIPS) 201-1 compliant enrollment and issuance processes. The IDMS manages the lifecycle of personnel data and related attributes, including the Facility Agency Smart Credential Number (FASC-N) and electronic data interchange personal identifier (EDI-PI) for the purposes of identification and access management.

It supports the issuance of the PIV card to all qualified DHS personnel, as well as a Facility Access Card (FAC) for personnel who need short-term physical access but do not require a PIV card (i.e.

employees/contractors working for less than 6 months). The IDMS also provide a web portal interface for administrative, audit/reporting, data entry and ad hoc queries. The current solution supports data segmentation in accordance with DHS Component structure (e.g. CBP, DHS HQ, FEMA, FLETC, ICE, TSA, USCIS and USSS), security and business needs. The IDMS supports integration with the following:

• US Treasury PKI (manages DHS PKI Certificate Authority) for certificate issuance and management.

• DHS Integrated Security Management System (ISMS), which is the authoritative system for personnel security records for DHS employees and contractors, and acts as the sponsor for the PIV card issuance process. The ISMS provides key data elements for each managed identity.

• DHS Automated Biometric Identification System (IDENT), which is the official clearinghouse for all biometrics used by DHS. Fingerprints collected by the IDMS during the enrollment process are submitted to IDENT for background check/investigation processing. Results are returned to IDMS, which passes them along to ISMS for validation, adjudication, and storage.

• FBI’s Criminal Justice Information System (CJIS), which is a repository of criminal fingerprints and history records that will be searched by DHS. Information provided by CJIS will be used for background check/investigation processing.

• Component and Enterprise Physical Access Control System (PACS), which is the authoritative system for controlling and monitoring access to specific physical facilities (e.g., buildings, rooms, airports, warehouses) and integrates with the IDMS to improve security and process efficiencies through data provisioning and synchronization.

• Component and Enterprise Logical Access Control System (LACS), which are processes and technologies for controlling and monitoring access privileges to online resources (e.g., active directories, networks, files, computers, databases) and integrates with the IDMS to improve security and process efficiencies through data provisioning and synchronization.

• Card/Credential Management System (CMS), which is responsible for managing the disposition of credentials for personnel and associated data managed by the IDMS.

• Hardware Security Module, which is responsible for storing, protecting and managing sensitive cryptographic key materials used by the IDMS for encrypting or signing data or establishing and managing data sessions (e.g. global platform sessions for PIV card management).

• Enrollment and Issuance Workstations (EIWS), which are PC based platforms used for data input and management for enrolling, updating, issuing, encoding, and managing the lifecycle of PIV and other credentials. The EIWS consists of a PC, smart card reader, card printer for card http://en.wikipedia.org/wiki/Electronic_data_interchange_personal_identifier http://en.wikipedia.org/wiki/Electronic_data_interchange_personal_identifier printing and encoding, camera and fingerprint reader for biometric fingerprint and facial image capture, and a document scanner for capturing personnel identification cards and other data.

• Light Activation Stations, which are lightweight PC based interfaces to the CMS that support self-service PIV card updates, unlocks, and Personal Identification Number (PIN) resets.

1.1.2 Purpose

The Functional Requirements Document (FRD) defines the functional requirements for a commercial-off-the-shelf (COTS) IDMS which will manage DHS identity data and access to the CMS. This document serves as a basis for mutual understanding between the user community, the COTS software vendors, and system developers. It provides the basis for development of criteria for system tests on candidate COTS products. Subsequent to product evaluations, it should serve as a basis in determining the required areas and elements of necessary customization of the selected products to better meet the needs of DHS and estimate accompanying costs.

1.1.3 Assumptions and Constraints

The following are assumptions or constraints for the IDMS:

• The IDMS shall support on-line operations.

• The COTS vendor must be on the GSA schedule. This constraint facilitates the procurement process to meet program milestones.

• The COTS product must be customizable, and it should conform to HSPD-12; OMB M-11-11; and

FICAM Roadmap and Implementation Guidance.

1.1.4 Interfaces to External Systems

External System Owner Description US Treasury PKI Manages DHS PKI Certificate Authority for certificate issuance and management DHS Integrated Security Management System

(ISMS)

DHS, Office of the Chief Security Officer (OCSO), Security Systems Division

(SSD)

Authoritative system for personnel security records for DHS employees and contractors, and acts as the sponsor for the PIV card issuance process. The ISMS provides key data elements for each managed identity.

DHS Automated Biometric Identification System

(IDENT)

DHS, United States Visitor and Immigrant Status Indicator Technology (US- VISIT) Program

Official clearinghouse for all biometrics used by DHS. Fingerprints collected by the IDMS during the enrollment process are submitted to IDENT for background check/investigation processing. Results are returned to IDMS, which passes them along to ISMS for validation, adjudication, and storage.

FBI’s Criminal Justice Information System (CJIS)

Repository of criminal fingerprints and history records that will be searched by DHS.

Information provided by CJIS will be used for background check/investigation processing.

Physical Access Control Systems (PACS)

DHS Components An authoritative system for controlling and monitoring access to specific physical facilities (e.g., buildings, rooms, airports, warehouses, etc.).

Logical Access Control Systems (LACS)

DHS Components Processes and technologies for controlling and monitoring access privileges to online resources (e.g., active directories, networks, files, computers, databases, etc.).

1.2 Points of Contact

1.2.1 Information

The Points of Contact below lists the points of organizational contact (POCs) that may be needed by the document user for informational and troubleshooting purposes for the IDMS. The table further identifies the type of contact, contact name, organization, telephone number, and e-mail address.

Type of Contact Name Organization Phone Email Project Manager Government Technical Representative

Government Technical Monitor

Government Information System Security Official

IDMS Subject Matter Expert

ICAM Subject Matter Expert

1.2.2 Coordination

The HSPD-12 Program coordinated and participated in Information Exchange Meetings with the following organizations for the development of the IDMS Functional Requirements Documents.

Participants appear below:

Name Organization

1.3 Document References

Appendix B identifies reference documents supporting this technical solution.

2.0 FUNCTIONAL REQUIREMENTS

2.1 Data Requirements

Appendix C further identifies the data requirements of the IDMS.

2.1.1 Biographic

2.1.2 Contact Email

2.1.3 Information System

2.1.4 Affiliation

2.1.5 Person Identifier

2.1.6 Facility

2.1.7 Public Key Infrastructure (PKI)

2.1.8 Personal Identity Verification (PIV)

2.1.9 Security Clearance

2.1.10 Federal Emergency Response Official (FERO)

2.1.11 Law Enforcement (LEO)

2.1.12 Identity Source Documents

2.1.13 Fingerprint

2.1.14 Credential

2.1.15 Person Attributes

2.2 Technical Solution Requirements

2.2.1 Technical solution must meet current FIPS 201, associated special publications, and OMB guidance. See Appendix B.

2.2.2 Provide HSPD-12 compliant capabilities for the issuance, management, and lifecycle use of the

PIV card.

2.2.3 The PIV cards issued by the system shall be capable of use for LACS and PACS, digital signatures, data encryption, and personnel identification for both internal DHS processes as well as with external partners.

2.2.4 Integrate via web services with USVISIT IDENT, FBI IAFIS and OPM to streamline the background investigation and fingerprint capture process, reduce duplicative infrastructure, establish a technical chain of trust and provide continuous vetting.

2.2.5 Provide segmented identity and credential databases that support the Department’s and Component’s security and business needs, enforcing need to know and separation of duties.

This includes segmenting access between DHS Components.

2.2.6 Integrate with the US Treasury PKI to facilitate PIV card and credential issuance and management.

2.2.7 Integrate via web services with the Integrated Systems Management System (ISMS) to send identity records and serve as the sponsor for the issuance of the PIV credentials.

2.2.8 Integrate with DHS infrastructure, networks, monitoring, configuration and patch management solutions, and Data Centers, where applicable.

2.2.9 Provide capabilities and workflows to manage person data and their associated attributes enforcing segmented, multi-person controls.

2.2.10 Be hosted within the DHS data center and at a minimum will provide a primary, backup and test environments.

2.2.11 Integrate and interface with Component ICAM infrastructure to facilitate PIV card use, improve credential and access management, and support the convergence of physical and logical access control systems.

2.2.12 Deliver capabilities and workflows to issue and manage other credentials as defined by the government to include: PIV-I, Visitor Cards (i.e., Facility Access Cards (FAC)), Personal Identity Verification (PIV) PIV Derived Credentials, and others as needed. Where applicable the solution shall integrate with other credentialing systems people, their identity attributes and associated credentials (e.g. Secure ID, derived credentials).

2.2.13 Provide integrated scheduling capabilities for managing the PIV enrollment, issuance and management process. This includes but is not limited to:

• Location management to identify site-specific work schedule, holidays, services and duty assignments.

• Internet accessibility to support applicant schedule management.

• Web based interfaces for administration and user access and management

2.2.14 Track and manage the full lifecycle of PIV cardstock, from initial receipt from the Government Printing Office (GPO) or card manufacturer, through final disposition, either destruction or lost/stolen declaration.

• Management of the release/receipt of PIV cards held by the PCI

• Location where PIV card issuance took place

• Status of PIV cards throughout its lifecycle

• Track PIV cards issued by PIV Card Issuance Facility (PCIF)

• Track how many PIV cards issued successfully by PCI and by PCIF

• Track how many PIV cards issued unsuccessfully by PCI and by PCIF

2.2.15 Track and manage biometric, biographic, attribute, card, certificate, and credential attributes during the operational and audit lifecycle of an individual’s identity lifecycle.

2.2.16 Aggregate data from authoritative and non-authoritative data sources and as well as correlating, searching and linking and de-conflicting personnel identity data.

2.2.17 Deliver a scalable, secure and high performance solution capable of supporting the Department’s distributed population and facilities; at a minimum 300,000 personnel records and 16,000 facilities (offices, warehouses, industrial buildings, labs, housing, museums, schools, data centers, and any building under the control of DHS).

2.2.18 Deliver bi-directional communications with Department and infrastructures and attribute correlation services (e.g. attribute hub), to support information discovery, information sharing, data provisioning and de-provisioning and access management.

2.2.19 Scale to support issuance and management of credentials to other Federal agency, operating independently, and utilizing segmented identity and credential management databases. This includes expansion up to 1M identities and associated credentials, and the ability to support multiple trust paths, issuers, and data sources both internal to and external to DHS.

2.2.20 Provide technical capabilities to capture and transmit biometric and biographic data, for the purposes of establishing and managing the identity and supporting the background investigation process. These capabilities include:

• Processing

• Storage

• Translation

• Correlation

• Data management tools

• Integrated workflows

2.2.21 Interface with the following systems to facilitate the background investigation process.

• ISMS

• FBI systems including but not limited to IAFIS and NCIC

• DHS Infrastructure including but not limited to Active Directory, ISMS, IDENT, Component

Biometric and Biographic Store and forward systems, Component ICAM Solutions

• OPM

• Enterprise ICAM solutions

2.2.22 Adhere to the standards of the requisite community for capture, storage, transmission, receipt and audit, where applicable (e.g. FBI EBTS, IDENT IXM)

2.2.23 Provide the workflow to capture fingerprint data for the purposes of PIV and other credentialing

2.2.24 Provide workflows and capture and processing capabilities to link the prints captured for the background investigation process with those that are used on the credential and managed through the lifecycle of the individual

2.2.25 A evidentiary chain of trust shall be established which captures and audits the data and events necessary to create and image an individual’s biometric, biographic, electronic ID and suitability during the operational lifecycle of the individual

2.2.26 Provide workflows that integrate with existing DHS data sources and processes to include:

• Personnel Vetting and Adjudication

• PIV Issuance, Management and Destruction (e.g. disposition of cards from manufacture to destruction)

• Establishment and of person digital identity and associated attributes and roles

• Issuance and management of other credentials and/or integration with other credential management systems (e.g. Secure ID)

2.2.27 Deliver capabilities to correlate, de-conflict, and link biometric, biographic and identity attribute information. This capability shall be configurable from fully automated to manual and shall generate alerts and reports as well as provide integrated workflows to facilitate data management, propagation and administration.

2.2.28 Provide Attribute Exchange Services that support interconnection with data sources and applications. At a minimum this includes:

• LDAP (Active Directory, PKI and other repositories)

• Web Services (SAML, SPML, XML)

• SMTP

• SQL

2.2.29 Deliver workflows and tools to identify and address orphan accounts, data and attributes orphan Accounts

2.2.30 Provide local and centralized PIV card printing, interfaces and workflows

2.2.31 Provide card activation, update and unlock services via a scalable cost effective service delivery model that includes:

• enrollment, issuance, printing and personalization station

• lightweight card update, unblock and activation station

• centralized card production and personalization

2.2.32 Automate existing paper based processes through the use of automated workflow and digital signatures, to include but not limited to:

• Paperless sponsorship and adjudication

• Establishment and management of Identity and Identity attributes

• Biometric capture and processing

• PIV card issuance and management and approvals

• PIV card end user acceptance

• Administrative tasks and approvals (e.g. role and privilege assignment)

• Consumable and supply chain management (e.g. card stock management)

2.2.33 Comply with DHS processes to include:

• DHS SELC

• DHS Security Authorization

• PIV Policies and process

• PKI Policies and Process

• DHS EA

2.2.34 Provide user self service functionality to facilitate card diagnostics, data update and verification and PIN unblock and change.

2.2.35 Issue and manage key encipherment keys per FIPS 201-2 for current and escrow keys

2.2.36 Issue and manage the following certificates:

• PIV authentication key and certificate

• PIV digital signature key and certificate

• PIV key encipherment keys and certificates (current and escrow, at least 20)

• PIV card authentication key

2.2.37 Support facial, fingerprint and iris biometric, per FIPS 201-2

2.3 Workflow Management Requirements

2.3.1 Workflow Management System

2.3.1.1 The system shall incorporate a workflow management system that will automate the PIV processes – sponsorship, enrollment, adjudication, identity, eligibility, issuance, re-issuance, use, maintenance, retrieval, revocation, person and attributes, and ability to enforce access based on role. Management structure needs to be hierarchical to mimic organizational structure but also enforce multi person control.

2.3.2 Request Differentiation

2.3.2.1 Define and automate the following types of requests:

• Pre-enrollment

• Enrollment

• Issuance

• Re-issuance

• Privilege granting

• Revocation

• Card Maintenance (PIN reset, email address updates, certificate updates, person/attribute update)

• Adjudication

• Fingerprint Capture

2.3.2.2 Be able to differentiate between various types of workflow requests that are initiated.

2.3.2.3 Integrate with existing Departmental processes.

2.3.3 Request Routing

2.3.3.1 Of the different request types, allow users to determine the task(s) necessary to complete the request.

2.3.3.2 Require the requestor to enter (for record) all data components necessary to process the request.

2.3.3.3 Define and incorporate distinct steps that represent the actions/tasks required to process the request.

2.3.4 Rejection Steps

2.3.4.1 Provide a mandatory field to document the reason for rejection

2.3.5 Escalation Capabilities

2.3.5.1 Automatic escalation will occur when the priority of a request meets a pre-defined threshold criterion

2.3.6 View Requests

2.3.6.1 The individual creating/submitting a request shall have the ability to view the status of the request at any point of the workflow process.

2.3.7 Auto Populate Fields

2.3.7.1 Auto-populate workflow fields that have valid values already present and do not need to be entered by the end user.

2.3.7.2 Auto-populated fields will be grayed out and non-editable.

2.3.8 System Role Definition and Assignment

2.3.8.1 Assign system role to all users.

2.3.8.2 Users shall submit requests based on their system role.

2.3.8.3 Define all system roles to which the users may be assigned.

2.3.9 Field Manipulation

2.3.9.1 Users shall edit fields based on the requestor's system role.

2.3.10 Workflow Step Status

2.3.10.1 Communicate the status of process tasks as in suspension, rejection, cancellation, acceptance, or successful.

2.3.11 Administrator Roles

2.3.11.1 The workflow organization shall allow for permissions and parameters for system roles to be created.

2.4 User Interface Requirements

2.4.1 Screens

2.4.1.1 Provide the ability for the user to retrieve and update applicant information or data received.

2.4.1.2 Provide the workflow management system interface.

2.4.1.3 Provide read-only reporting capabilities.

2.4.2 Role-based Security

2.4.2.1 Access to the PIV web service functions based upon a role-based security model.

2.4.2.2 System role assigned to a user shall be invoked upon login to the web service.

2.4.2.3 Specific system roles defined within the PIV web service security model according to the job functions performed by the users. At a minimum, the systems roles defined should include the following:

• Applicant

• PIV Sponsor

• PIV Registrar

• Enrollment Official (EO)

• PIV Issuer

• PIV Digital Signatory

• PIV Authentication Certification Authority (CA)

• System Administrator

• Information System Security Manager and Official (ISSM/ISSO)

2.4.2.4 Require all users to use card, biometric and PIN verification upon login.

2.4.3 Workflow Management

2.4.3.1 The web service shall feature an interface to the workflow management system.

2.4.3.2 Initiate and track to completion the following workflow request types:

• Sponsorship

• Pre-enrollment

• Enrollment

• Issuance

• Card Activation

• Reissuance

• Revocation

• Card Maintenance

2.5 PIV Sponsorship

2.5.1 Enable the authoritative database (ISMS) to communicate and record acknowledgement for the sponsorship of an applicant.

2.5.2 Enable the registered sponsor to batch transfer employee information to pre-populate the enrollment record.

2.5.3 Acknowledgement of submission of (SSN to EDIPI) ISMS information from the IDMS

2.6 PIV Pre-enrollment

2.6.1 The system shall be able to import and store additional information regarding DHS PIV applicants.

2.6.2 The system shall be able to process and accept an applicant's electronic signature.

2.6.3 The system shall allow the use of DOB and SSN to facilitate the creation of the identifier. The

SSN shall be encrypted.

2.7 PIV Enrollment

2.7.1 Claimed Identity Documentation

2.7.1.1 The system shall provide the capability to scan and collect documents. DHS accepts only the following identity source documents, selected from Form I-9, OMB No. 1615-0047 (Employment Eligibility Verification):

• I-9 LIST A: Documents that establish both Identity and Employment Authorization.

o U.S. Passport or U.S. Passport Card o Permanent Resident Card or Alien Registration Receipt Card with photograph (Form I-

151 or I-551) o Foreign passport that contains a temporary I-551 stamp or temporary I-551 printed notation on a machine-readable immigrant visa o Employment Authorization Document that contains a photograph (Form I-766) o In the case of a nonimmigrant alien authorized to work for a specific employer incident to status, a foreign passport with Form I-94 or Form I94A bearing the same name as the passport and containing an endorsement of the alien’s nonimmigrant status, as long as the period of endorsement has not yet expired and the proposed employment is not in conflict with any restrictions or limitations identified on the form o Passport from the Federated States of Micronesia (FSM) or the Republic of the Marshall Islands (RMI) with Form I-94 or Form I-94A indicating nonimmigrant admission under the Compact of Free Association Between the United States and the FSM or RMI

• I-9 LIST B: Documents that Establish Identity o Driver's license or ID card issued by a state or outlying possession of the United States provided it contains a photograph or information such as name, date of birth, gender, height, eye color and address o ID card issued by federal, state or local government agencies or entities, provided it contains a photograph or information such as name, date of birth, gender, height, eye color and address.

a. United States Driver’s License

b. DHS Federal Credential and/or DHS Federal Law Enforcement Credential

c. DHS Personal Identity Verification (PIV) Card o U.S. Military card or draft record o Military dependent’s ID card o U.S. Coast Guard Merchant Mariner Card o Native American tribal document o Driver’s license issued by a Canadian government authority

• I-9 LIST C: Documents that Establish Employment Authorization o U.S. social security card issued by the Social Security Administration (other than a card stating it is not valid for employment) o Certification of Birth Abroad issued by the Department of State (Form FS-545) o Certification of Report of Birth issued by the Department of State (Form DS-1350) o Original or certified copy of a birth certificate issued by a State, county, municipal authority or territory of the United States bearing an official seal o U.S. Citizen ID Card (Form I-197) o Identification Card for Use of Resident Citizen in the United States (Form I-179) o Employment authorization document issued by the Department of Homeland Security

2.7.1.2 Digitally capture, store, receive and archive identity documentation and allow for viewing documents stored at a later date.

2.7.1.3 Validate the authenticity of identity documentation.

2.7.1.4 Provide the capability for an EO to cancel an application at any step in the application process

2.7.1.5 Allow for the administrator to over-ride approval of an enrollment record if the appropriate number of quality documents is not met and require the EO to document reason for override

2.7.1.6 Automatically implement, document and display the identification document authentication system score and provide guidance to the EO.

2.7.1.7 Provide a free form field to allow the EO to record an explanation for canceling a requestor's application

2.7.1.8 Be capable of referencing and attaching the identity documentation to the enrollment record.

2.7.1.9 Indicate the identity documents scanned as part of the enrollment process.

2.7.1.10 Conduct enrollment of 15 minutes or less

2.7.1.11 Require all users to use card, biometric and PIN verification to login and operate the system.

2.7.2 Enrollment Data Capture

2.7.2.1 Enable the EO to record the requestor's biographical data required to complete an application.

2.7.2.2 Enable an EO to record the type of claimed identification documents presented by the applicant.

2.7.2.3 Provide ability to update cardholder enrollment records

2.7.2.4 Maintain a log of application cancellations and record the User ID and Unique Identifier of the

EO performing the cancellation

2.7.2.5 Require an EO to collect a digital photograph, fingerprints or any other biometric as required from the applicant.

2.7.2.6 Provide the ability to accept and collect 10 flat fingerprints. System should allow for fingerprint overrides in accordance with policy.

2.7.2.7 Extrapolate two electronic fingerprints from the ten fingerprints template provided by the applicant and place the two fingerprints on the Smartcard.

2.7.2.8 Provide capability to provide legacy card conversion/enrollment.

2.7.2.9 Require all users to use card, biometric and PIN verification to login and operate the system

2.7.2.10 All data records (IDMS) backed up daily

2.7.3 Biometric 1:N Search

2.7.3.1 Allow application processing with fewer than 10 fingerprints if unable to capture 10 fingerprints. This option shall require a manual over-ride by policy.

2.7.3.2 Initiate a 1:N biometric search of the IDMS, with the ability to match a biometric file against both enrolled (i.e. cardholders) and non-enrolled (i.e. those who attempted enrollment and were denied) individuals and determine if a match is present.

2.7.3.3 Provide the ability to compare electronic fingerprints against a standard template to validate the accuracy of the capture at enrollment.

2.7.3.4 Provide the ability to display previously collected file information on all individuals having a match to a biometric search.

2.7.3.5 Provide the capability to adjust the specifications for a biometric search

2.7.3.6 Provide the capability to annotate the results and accuracy of the biometric match on the enrollment record and within the IDMS.

2.7.3.7 Provide a capability for an administrator to override fingerprint quality metrics.

2.7.3.8 Capture the EO and administrator's (if needed) user ID/unique identifier, when recording the results of a biometric match or overriding policy.

2.7.3.9 Provide the ability to use biometric verification against the IDMS and Card Management

System (CMS) interfaces to enable post-issuance capabilities such as PIN reset

2.7.3.10 Provide the capability for fingerprint flow redesign (i.e., encompasses skip/rescan retake a print, improved amputation/bandage handling).

2.8 Issuance

2.8.1 Card Production

2.8.1.1 Capable of providing the appropriate information needed to produce the card.

2.8.1.2 Capable of placing a unique Component identifier on cards produced for employees of that

Component.

2.8.1.3 Capable of providing options for Components to select from with the purpose of using the optional fields.

2.8.1.4 Provide the ability to place a reference number, unique to each Smartcard, in one of the optional data areas on the Smartcard.

2.8.1.5 Provide the ability to electronically lock the card prior to shipping to the designated enrollment/issuance center.

2.8.1.6 Provide the ability to notify the IDMS that the card has been shipped to the designated enrollment center.

2.8.1.7 Provide the ability to track the card from the manufacturer to the employee/contractor.

2.8.1.8 Capable of providing access to the production status of card to EOs/ Component

Administrators/Issuers.

2.8.1.9 Capable of incorporating multiple security features (will update this requirement with specific requirements once determined).

2.8.1.10 Capable of local card personalization.

2.8.1.11 Provide the ability to print a card reference number.

2.8.2 Card Issuance

2.8.2.1 Capable of generating a notification that the card is ready for issuance.

2.8.2.2 Provide the ability to electronically unlock the card prior to issuance.

2.8.2.3 Provide the ability to test the card prior to issuance.

2.8.2.4 Provide the capability for the card to be checked against the current card revocation list.

2.8.2.5 Provide the ability of updating and recording card issuance in the IDMS/CMS.

2.8.2.6 Provide the status of card to the PIV Card Issuer.

2.8.2.7 Provide card activation and PIN management capabilities.

2.8.2.8 Ensure that all expiration dates match the card’s topology, integrated surface chip, and certificate and does not exceed the card’s expiration date.

2.8.2.9 Enrollment software must have the capability to provide an expiration date.

2.8.2.10 Card and certificate validity and expiration shall be configurable by policy, DHS Component, Community of Interest and by credential type; certificate expiration shall not exceed card validity.

• PIV cards shall be configurable from 1 year to 5 years.

• Other cards and credentials (e.g., FAC) this shall be configurable from 1 hour to 5 years.

2.8.2.11 Ability to issue cards to existing applet in accordance with FIPS 201 standard.

2.8.2.12 Ability to perform pre- and post- issuance updates and shall do so in accordance with Global platform requirements to include but not limited to:

• Card applet instantiation

• Card applet update

• Card personalization (printing and encoding)

• Post issuance certificate and data attribute updates (e.g., UPN, email)

• PIN establishment, unblock, reset and update

2.9 Re-Issuance

2.9.1 Re-Issuance Application

2.9.1.1 Capable of tracking and providing status workflow, identity, card and credential status for the following scenarios (to include, but not limited to):

• PIV workflow status

• Identity Status

• Card Status

• Certificate Status

• PIV lifecycle ( lost, stolen or damaged card, return, and replacement card transaction)

• System status and alarms

• Notifications to DHS role holders and credential holders

2.9.2 Re-Issuance Revocation Verification

2.9.2.1 To apply for re-issuance of a new card, the system shall require EO to verify completion of revocation of the lost, stolen or damaged card before re-issuance process can continue.

2.9.3 Re-Issuance Enrollment Verification

2.9.3.1 Provide positive 1:1 verification of the DHS PIV holder's reference biometric stored in IDMS to verify record of previous enrollment within IDMS.

2.9.3.2 If the 1:1 biometric check does not yield a positive match (i.e. the applicant is not already enrolled, or provided biometric does not match reference template), the system shall NOT allow for reissuance, PIN unblock or deny authentication for the requested function.

2.9.4 Re-Issuance Card Production

2.9.4.1 Upon positive verification of the 1:1 biometric check, the system shall generate a re-issuance record to IDMS so physical issuance of a new DHS PIV can be initiated

2.9.4.2 Capable of assigning a new reference number to the replacement card.

2.9.5 Re-Issuance Digital Photo Capture

2.9.5.1 Allow a new digital photo to be captured, stored and printed on the re-issued DHS PIV.

2.9.5.2 Allow for use of the existing digital photo (on record in IDMS) to print on the re-issued DHS PIV-functionality shall be locked.

2.10 Card Revocation

2.10.1 Record a submitted request and request submitter information for revocation.

2.10.2 Record a reason code indicating the reason for requesting card revocation. All corresponding certificates will be revoked.

2.10.3 Provide the capability to place any card that is reported lost, stolen, damaged, revoked or otherwise unusable onto the revocation list.

2.10.4 Document the reason a card is revoked and shall notify the applicable authoritative source to request certificate revocation and/or key deactivation.

2.10.5 Capable of positively acknowledging a completed revocation and deactivation request to the requesting entity.

2.10.6 Physical and logical systems must be alerted upon card revocation. The system shall provide standards based interfaces to support this function. This includes but is not limited to:

• PKI (e.g., PKIX)

• LDAP

• Web

• RBDMS

• SQL

• X.500

2.10.7 Provide the capability to archive records for all DHS PIV cards that have been revoked.

2.11 Revocation List

2.11.1 Capable of generating and tracking the status of card and certificate revocations.

2.11.2 Capable of generating certificate and attribute revocation requests and transmitting to the appropriate issuing authority (e.g. PKI).

2.11.3 Capable of interfacing with Physical and Logical Access systems and data stores to communicate card validity and status.

2.11.4 Capable of suspending as well as revoking a card and corresponding certificates and keys.

2.12 Auditing

2.12.1 Annotate the record with the date, time and location when the enrollment record is completed.

2.12.2 Record the user ID while performing PIV workflow, credential workflow, identity workflow, administrative, security or audit functions.

2.12.3 Record a date/time stamp for each logon and logoff attempt by the user accessing the system.

2.12.4 Record activities that might modify, bypass, or negate information security safeguards.

2.12.5 Record security-relevant actions associated with processing.

2.12.6 Record all activities performed using an administrator’s identity.

2.12.7 Provide capability for audit records to be reviewed by the System Owner and CISO/ISSM/ISSO.

2.12.8 Protect audit records and audit logs from unauthorized access, modification, or destruction.

2.12.9 At a minimum audit trail records shall be maintained online for at least ninety (90) days.

2.12.10 Audit trail records shall be preserved for a period of seven (7) years as part of managing records for the IDMS to allow audit information to be placed online for analysis with reasonable ease.

2.13 Searching/Reporting

2.13.1 Access to reporting, search, and audit data shall only be provided by authorized personnel.

Access shall be role based to include DHS Enterprise, DHS Component, PIV role, System, Administrative, Audit, Security, Reporting, Performance, Use (for self service functions), and Community of Interest.

2.13.2 Provide the ability to show the total number of cards issued per Component in real-time and be expandable to create reports on an as needed basis.

2.13.3 Provide a method for an authorized system role to query the status of a DHS PIV application.

2.13.4 Capable of searching and creating reports for processes in each stage of the DHS PIV lifecycle.

At a minimum, reporting elements shall include, but are not limited to:

• Details of key biographical data components for applicants

• Details of enrollment process for individual applicants including number of visits to enrollment center and number of unsuccessful enrollment attempts

• Details of failed/successful biometric capture attempts

• Details of incomplete enrollment records

• Detailed transaction and session information for each authorized user

• Status of enrollment and issuance process

• Details of PIV cards issued per specific location

• Details of PIV cards reported lost, stolen, damaged, or inoperable

• Details of revocation statistics

• Details of PIV cards information based on the card’s profile (CUID, ASCN, MSN, CIN, IIN)

2.13.5 Provide a report that documents an audit trail for Enrollment Issuance and approval.

2.13.6 Provide methods for reporting status, progress, and benefits of IDMS services in as close to real-time as possible. The approach should minimize the need for self-reporting and emphasize automated collection of data to transparently measure and report performance metrics.

2.14 IDENT Integration

2.14.1 IDENT Functional

2.14.1.1 Interface with IDENT to perform biometric verification of individuals to facilitate the background investigation process.

2.14.1.2 Capture and process prints for new and existing contractors, employees, and other applicants.

2.14.1.3 IDMS Integration with IDENT will leverage the existing enrollment stations for capturing the fingerprints of applicants, contractors and employees, sending finger print data to IDENT for processing and returning results to ISMS.

2.14.1.4 Perform biometric and biographic correlation and identify duplicate encounters of biometric and/or biographic information (i.e. social security)

2.14.1.5 The biometric captures as part of the personnel on boarding process shall be used as the basis for identification and correlation for an individual, their identity record, and their access credentials (i.e. PIV Card)

2.14.1.6 Establish a technical chain of trust, based on the biometric and biographic data captured from an applicant from the time of on-boarding to the time of separation

2.14.1.7 Integrate with existing process to support the initial background investigation process, perpetual vetting, PIV card issuance, and lifecycle management

2.14.1.8 Establish workflows which integrate the fingerprint check with the BI process.

2.14.1.9 Provide an integrated fingerprinting workflow and interfaces that support fingerprint capture, submission, lifecycle management.

2.14.1.10 Integrate with existing DHS systems and services to include ISMS, IDENT, IAFIS, OPM and

Personnel Identity and Fingerprint capture systems.

2.14.1.11 Use PIV enrolment stations for supporting fingerprint capture, processing and lifecycle management of fingerprint data for BI processing, PIV workflow and Identity Management.

2.14.1.12 Integrate with existing Component fingerprint systems to support BI processing.

2.14.2 IDENT Planning

2.14.2.1 A pragmatic, efficient and cost-effective integration approach will be developed.

2.14.2.2 IDMS and IDENT Integration shall adhere to the DHS SELC.

2.14.3 IDENT Technical

2.14.3.1 Interface with ISMS via a web based interface.

2.14.3.2 Leverage the IXM specification for interfaces with IDENT.

2.14.4 IDENT Policy

2.14.4.1 Policies shall be developed to ensure that DHS Agencies appropriately use the services provided through the integration of the DHS IDMS with USVISIT IDENT.

2.14.5 IDENT Audit

2.14.5.1 Log transaction related events associated with the submission, response and status of each request.

2.14.5.2 Provide the capability of analyzing and correlate audit logs to trace all activity for a given individual.

2.15 Consumable and Supply Chain Management

2.15.1 Consumables Inventory Tracking

2.15.1.1 Track related events associated with the status of consumables supporting PIV cards from initial receipt the manufacturer through delivery to the PCIF.

2.15.1.2 Track available inventory of consumables at each PCIF.

• Consumable Identification (ID)

• Consumable Name

• Consumable Description

• Consumables on hand

• Reorder Points

• Lead Times

2.15.2 HSPD-12 Equipment Inventory Tracking

2.15.1.1 Track related events associated with the status of HSPD-12 equipment supporting PIV card issuance from initial receipt the manufacturer through delivery to the PCIF.

2.15.1.2 Track available inventory of HSPD-12 equipment at each PCIF.

• Inventory Identification (ID)

• Equipment Name

• Equipment Description

• Inventory on hand

• Equipment Physical Location

• Serial Numbers

• IP Addresses

• Linked equipment

2.16 PIV Card Issuance Facilities (PCIF)

2.16.1 PCIF Tracking

2.16.1.1 Track related events associated with the status of each PCIF

• Track PCIF location (address, phone number(s), hours of operation, directions, etc.)

• Track the current status of the PCIF (open, closed, temporary)

• Track Component responsible for overseeing the PCIF

• Track all PCIF moves

• Track PCIF Manager and contact information

• Track personnel assigned to the PCIF

2.16.1.2 Location management to identify site-specific work schedule, holidays, services and duty assignments

2.16.2 PCIF Scheduling Tool

2.16.2.1 Internet accessibility to support applicant schedule management.

2.16.3 PCIF Personnel Management

2.16.3.1 Track related events associated with the status of personnel assigned to the PCI and PCIF.

• System Role Requests

• System Role Assignments

• System Training Requests

• System Training Status (pending, completed, history)

3.0 OPERATIONAL REQUIREMENTS

3.1 Security

3.1.1 Require all users to use card, biometric and PIN verification to login and operate the system.

3.1.2 Function as a SAML 2.0-compliant Service Provider to support PIV-based Federated Single Sign-

On for previously authenticated PIV-based web sessions (chain-of-trust).

3.1.3 Enable secure access to web-based, LAN-based, and WAN-based applications or networks, depending on the capabilities of the location.

3.1.4 Automatically close the active session when there has not been keyboard or mouse activity for

20 minutes.

3.1.5 Capable of encrypting and compressing data, and scheduling data transfer using rules-based processes

3.1.6 Provide the ability to segment data so only certain information is viewable per DHS

Component.

3.1.7 Provide security down to the data element as to who can view or modify each data element.

3.1.8 Manufactured in the United States.

3.1.9 Provide the ability to protect VIP data and monitor those viewing VIP data.

3.1.10 Pass US Common Policy Annual Audit and DHS Registration Practice Statement.

3.1.11 Satisfy FISMA C&A and achieve the Authority to Operate (ATO).

3.2 Audit Trail

3.2.1 Record the following information for each successful login:

• Date/time stamp of entry/access

• DHS PIV service access location

• Login username

• Attempts resulting in lockout

3.2.2 Record the following, for each planned equipment outage:

• Date and time for start of outage by location

• Estimated date and time for completion of outage

• Actual date and time for completion of outage

• Reason code and description/explanation for outage

3.2.3 Provide an audit and inspection process including a remote electronic audit capability.

3.2.4 Provide an alerting/reporting mechanism that is triggered for specified events or activities within the IDMS. Examples include, but are not limited to:

• Cards issued, but never activated

• Change in cardholder information that has been determined to represent an unreasonable security risk

• Cards shipped from DHS/GPO, but with no record of receipt at the PCIF

3.3 Data Currency

3.3.1 Provide the ability to archive data according to a defined schedule.

3.4 Reliability

3.4.1 Service Level of Agreement (SLA) of 99.95%

3.5 Recoverability

3.5.1 Capable of being remotely diagnosed for problems.

3.5.2 Hosted at a DHS data center and third data center provided by the contractor. Third data center shall meet SCIF facility requirements. Recoverability should be automatic failover.

3.6 System Availability

3.6.1 Provide power backup solution that provides a graceful shutdown procedure in the event of power disruption

3.6.2 Provide database availability of 99.99%. Database outages will not be counted toward the

99.99% for planned database upgrades, planned database backup procedures, nor natural or manmade disasters.

3.6.3 Include a power backup that ensures data is retained in event of power loss

3.7 Fault Tolerance

3.7.1 Data Transfer Accuracy- Accuracy is determined by the percentage of data sets that are accurately read or written by the Integrated Circuit Chip on the DHS PIV to the application that the DHS PIV is interfacing with. To insure confidence and credibility of the DHS PIV, the requirement for data transfer accuracy will be 100%.

3.8 Performance

3.8.1 Maintain average enrollment transaction time of not more than 10 minutes for initial enrollees, not more than 8 minutes for replacement cards, and not more than 2 minutes to validate identity and activate / issue the DHS PIV when it arrives from the production center.

3.8.2 Capable of providing, tracking, reporting performance metrics. The collected metrics must be actionable and help improve the system's operational performance, security, utility, cost, or ease of use.

3.8.3 Capable of measuring overall lost card rates and lost, stolen or damaged card rates, as well as rates within target populations.

3.8.4 Capable of collecting and reporting metrics on a as needed basis.

3.8.5 Capable of transferring data with the capability of retrying on failure or interruption.

3.8.6 Provide the capability to pull security log and enrollment data from the field and aggregate such data for 1:N biometric check

3.8.7 Enrollment and issuance workstation needs to operate as a consolidated workstation.

3.9 Capacity

3.9.1 Be scalable to accommodate a minimum of 1 million cardholder records and be able to accommodate the associated transaction loads expected.

3.10 Data Retention

3.10.1 Provide the capability to maintain records of biometric data for applicants who have successfully enrolled as well as applicants who have failed enrollment attempts.

3.11 Interfaces

3.11.1 Transfer all data in a secure manner.

3.11.2 Provide an open, non-proprietary, FIPS 201 compliant, industry standards-based interface and authentication for all DHS PIV equipment.

3.11.3 Provide the capability to facilitate the transfer, in single or batch, valid DHS PIV holders, to the local facility's access control system.

3.11.4 Results of the fingerprint portion be returned to Personnel Security.

3.11.5 Provide the capability to interface with Active Directory.

3.11.6 Communicate over existing network circuits using the following TCP/IP port numbers:

• HTTPS: Port 443

• HTTPS: Port 5067

• HTTPS: Port 22

4.0 REQUIREMENTS TRACEABILITY MATRIX

Appendix D identifies the Requirements Traceability Matrix of the IDMS.

APPENDIX A – GLOSSARY

Term/Acronym Description/Definition 3DES Triple Data Encryption Algorithm AES Advanced Encryption Standard ATO Authority to Operate CA Certificate Authority CAS Civil Applicant System C&A Certification and Accreditation CIO Chief Information Officer CM Configuration Management CMS Card/Credential Management System Components Department of Homeland Security Agencies CONUS Continental United States COTS Commercial Off The Shelf CSO Chief Security Officer Department Department of Homeland Security DHS Department of Homeland Security DOB Date of Birth DOJ Department of Justice EA Enterprise Architecture EBTS Electronic Biometric Transmission Specification EDIPI Electronic Data Interchange Personal Identifier EIWS Enrollment and Issuance Workstation EO Enrollment Official EPEAT Electronic Product Environmental Assessment Tool FAC Facility Access Card FASC-N Federal Agency Smart Credential Number FBI Federal Bureau of Investigations FICAN Federal Identity, Credential and Access Management FIPS Federal Information Processing Standard FISMA Federal Information Security Management Act FRD Functional Requirements Document GFE Government Furnished Equipment GOTS Government Off The Shelf GPO Government Printing Office GUI Graphical User Interface HLS EA Homeland Security Engineering Architecture HSPD Homeland Security Presidential Directive HTML Hyper-Text Markup Language (HTML) is a…