| |
|
| |
SAFEnet System Specifications & Capabilities Matrix |
| |
|
|
| BADGES |
| Unique badge types |
The system shall have ability to design and produce individual badges for both permanent users and different categories of visitors |
| Multiple badge formats |
The system shall have ability to add, store and read multiple badge formats for use at any portal |
| Re-useable badges |
The system shall be able to re-use visitor badges without losing the ability to recall badge use by individual or badge number for a specific time period |
| Temporary badges |
The system shall have the ability to issue a temporary badge to a badge holder. The access privileges of the original badge shall be automatically suspended until the temporary badge is returned |
| Badge timeouts |
The system shall automatically assign an expiration time and date based on base type (visitor and temporary). Visitor badges shall be automatically deactivated if not used within a user-specified time |
| Badge bit formats |
The system shall support multiple badge bit formats (I.e. 31, 26, 37, 75, 200) |
| Special event badge production |
The system shall provide the capability to design and produce badges for special events |
| ACCESS CONTROL |
| Identify personnel who have not accessed an area within a user-defined timeframe |
The system shall be able to produce a report of individuals who have not used their badge to access a specified reader since a given date |
| Automatic display of card holder images |
The system shall be able to produce a report of individuals who have not used their badge to access a specified reader since a given date |
| Display images of all users flagged as Do Not Admit |
The system shall be able to display, on demand, thumbnail images of all individuals flagged as Do Not Admit at a portal workstation. This feature could be a stand alone application or run in conjunction with the Automatic Display application (Requirement 6). |
| Display images of all users flagged as VIPs |
The system shall be able to display, on demand, thumbnail images of all individuals flagged as Do Not Admit at a portal workstation. This feature could be a stand alone application or run in conjunction with the Automatic Display application (Requirement 6). |
| Revoke a badge holder's authorization |
The system shall allow authorized operators to revoke a badge holder's authorization to all or selected controlled areas from any workstation |
| Invalid access transaction reporting |
The system shall have the ability to immediately annunciate invalid access transactions |
| Invalid access transaction reporting |
The system shall have the ability to select the workstation(s) specific invalid access transactions will be displayed on |
| Invalid access transactions |
Invalid access transactions shall include but not be limited to: Invalid Badge, Passback Alarm, Badge Expired, Badge Lost, Badge Suspended, PIN Duress, Invalid PIN, Do Not Admit, Early Badge. The system shall allow the user to prioritize invalid access transactions and select if and how they are to be annunciated to include displaying the individual's image |
| Change reader operation |
The system shall allow a reader to switch from a high security setting (Card & PIN) to a low security setting (Card or PIN), based on a time schedule, operator command and external activity trigger with the ability to reverse the action. |
| Trace single badge activity in real time |
The system shall be able to place a trace on an individual badge holder and provide the ability to display trace activities as they occur. The system shall save all trace activities (valid and invalid transactions) in historical files for reports that are distinct. |
| User-selectable PIN |
The system shall support PIN selection by the badge holder as well as an auto-generated PIN with a predefined length of 4, 5 or 6 digits |
| ANTI-PASSBACK |
| Anti-Passback |
The system shall provide Anti-Passback capability across different field panels and/or sites to include separate regional servers (i.e., multi-facility). The system shall allow the user to select how anti-Passback violations are handled (ignored, logged, disable badge, etc.) |
| Badge reset after an anti-Passback violation |
If a badge is disabled for an anti-Passback violation, the system shall allow an authorized operator to restore the user's privileges from any workstation |
| Number of entries/exits a badge is authorized |
The system shall be able to automatically authorize a specified number of entries/exits allowed based on badge type (e.g., visitor - 1 entry/1 exit; temporary - unlimited entry/exit) |
| Area accountability |
The system shall be able to produce a report of all individuals who are currently logged into a specific area |
| DATABASE |
| Field masking |
The system shall be able to restrict the viewing and editing of selected database fields to authorized operators |
| View stored pictures |
The system shall allow an authorized operator to view badge holder pictures from any workstation |
| Badge holder data |
The system shall retain all badge holder data to include user-defined fields |
| Database purging |
The system shall support automatic daily purging of selected database records older than a user-defined time period |
| Unique identifier field |
The system shall verify that duplicate data hasn't been entered in a badge holder's unique identifier field (e.g., SSN) |
| System database |
The system shall be configured with SQL 2000 Enterprise or later |
| Query capability |
The system shall allow an operator to initiate a database query on any field |
| Expansion of badge database fields |
The system shall allow user-defined fields to be added to the badge holder database. These fields may include drop-down lists to ensure data conformity & support for Microsoft SQL Stored Procedures |
| Required fields |
The system shall allow the user to flag selected badge holder database fields as "required" |
| Database flags |
The system shall allow user-selected badge holder fields to trigger a user-defined event (e.g., a badge holder identified as a law enforcement officer shall not allow the portal magnetometer to alarm) |
| System capacity |
The system shall support, at the individual panel level, 1,000,000 badge holders with at least 128 access levels each |
| Archive capability |
The system shall archive all system activity to include valid and invalid access transaction, operator actions and database changes to historical logging purposes. |
| Photo and signature capture |
The system shall have the ability to capture, store, and reproduce portrait photographs of individuals and their signatures |
| Credential request authority and approval authority |
The system shall provide the ability to limit credential request authority and approval authority by credential type to selected individuals |
| Export and print picture files and dossier photos |
The system shall have the ability to export and print picture files and dossier photos |
| Image capture |
The system shall support both video cameras and digital cameras for badge photos |
| ID scanning for image and data capture. |
The system shall support scanning of government issued ID for image and data capture. |
| Data import/export utility |
The system shall have a data import/export utility, at a minimum using comma-separated values (CSV) |
| Document exchange with external systems |
The system shall support Extensible Markup Language (XML) formatted files for standardized document exchange with external systems |
| Open Database Connectivity (ODBC) and Application Programming Interfaces (APIs) |
Data contained in system databases shall be available to interfacing information systems through Open Database Connectivity (ODBC) and Application Programming Interfaces (APIs) |
| Database import capability |
The system shall provide a database import capability (visitors, alarms, badge holders). |
| Data structure |
Data structure shall be user definable including number of fields, size and type of fields, and the relationship of fields, to include the capability to define user customizable fields |
| Historical data files |
The system shall have a historical data file that retains the most recent one million event transactions without having to access the archived media |
| Historical storage file capacity notification |
The system shall alert the user when archiving of historical data is required before data is over-written |
| Historical logs from archived media |
The system shall be capable of recalling historical events directly from the archived media without having to interrupt normal online activities |
| Database archiving |
The system shall provide scheduled database archiving. |
| Database access |
The system shall not restrict the number of workstations that can simultaneously view a single database record |
| Database protection |
The system databases shall be protected from unauthorized access or inadvertent modification |
| Partial search |
The visitor application shall support the ability to do a partial search and select. Search for "John S" will result in a list of all John SA to SZZZZZ and allow the operator to select the desired entry. |
| Separation of Databases |
The visitor and permanent badge holder databases shall be physically separate and distinct from each other |
| Export capability |
The system shall be able to selectively export, as a minimum, the cardholder database to include user-defined fields, system configuration files and all historical log files |
| REPORTS |
| Customized reports |
The system shall be able to create customized reports and store them for future use (Crystal Reports). |
| Sort sequences |
The system shall allow the operator to sort displays and reports on any field |
| Report production |
The system shall be able to display and/or print reports of online data within 60 seconds of requests |
| Reports |
Reports shall run concurrently, without affecting system performance. Reports shall not have to be run after hours. |
| Statistical reports |
The system shall be able to produce statistical reports including the number of valid accesses, rejected access attempts, and read errors, reported by selected readers, or group of readers, or by selected areas, over a selected date and time period |
| "Canned" reports |
The system shall allow the operator to select from a list of "canned" reports for report generation |
| PANELS |
| Update field panels within 2 seconds of a cardholder database change |
The system shall automatically update the field panels within 2 seconds of a badge being adding or deleted from the system |
| Firmware updates |
The system shall support flash memory for down loading firmware updates. |
| Relay outputs |
The system shall provide relay outputs for control of devices in the vicinity of the field panels |
| Line supervision |
The system shall support supervised devices using end-of-line resistance. |
| Field panel configuration |
The field panels shall be configured from a central location. |
| Change of status reporting |
The field panels shall communicate distinct status change signals, including but not limited to: alarm, tamper, AC power fail, and low battery, to the head end within one second of occurrence |
| Local field panel storage |
The system shall provide for activity storage (10,000 events minimum) in the field panel until transfer to the head end is confirmed and while off-line and shall report all events once the field panel is back on line. |
| POWER |
| Battery backup |
The system shall provide a minimum of 8 hours of battery backup for all field panels |
| Surge suppression |
All discrete field panel I/O board and all reader boards shall have built in surge suppression |
| COMMUNICATIONS |
| Head-end to field panel communications |
The system shall function over multiple LAN subnets for head end to field panel communications |
| Field panel communications formats |
The system shall support RS-485 communication format to the field panel. |
| Redundant field panel communications |
The system shall support redundant communications to the field panels |
| Encrypted field panel communications |
The system shall support DCID 6/9 encryption between the head-end and field panels either on-board or with the use of third party add-ons |
| Communications loss |
The system shall report communication loss to or from any field panel |
| READERS AND OTHER DEVICES |
| System reader |
The system shall be able to use a card reader at a portal workstation to automatically populate the badge number field in a badge holder record (visitor or permanent) |
| HSPD-12 and FIPS-201 compliance |
The system shall be able to read and store the CHUID associated with a PIV II card |
| Type of card readers |
The system shall be able to interface with any badge technology (prox, mag stripe, bar code) with or without a PIN on a multi-technology reader |
| Reader LCD displays |
Card readers can be provided with an LCD display that provides messages such as: Present Badge, Enter PIN, Re-enter PIN, Proceed, Access Denied - See Officer, Etc. |
| Hand held card readers |
The system shall interface with a wireless hand held card reader for guards at portals to verify valid badge holders within a vehicle. The reader shall include a red and green status light. The wireless connection shall be encrypted. |
| Photo display at hand held card readers |
The wireless hand held card reader shall have the ability to display the photo of badge holders. |
| Hand held card reader data protection. |
The wireless hand held card reader shall have provisions to automatically destroy it's database if not used within a user-defined time period |
| Scramble keypad |
The system shall support a keypad that provides a scrambled display for entering a PIN |
| Biometrics |
The system shall be able to include biometric verification as part of the access control process (subject to Requirement 11) |
| NETWORK |
| System communications |
The system shall function through routers, smart switches and firewalls for server, workstation and field panel communications |
| System health and status |
The system shall be able to monitor and record in a historical log file the entire health and status of the system to include all alarm points |
| Server/workstation communications |
The server and workstations shall have the capabilities to function on a TCP/IP based network |
| SERVERS |
| System storage |
The system shall support RAID, tape, Zip-Disk, CD, and/or Mirrored Drives. |
| Database synchronization |
The system shall provide automatic database synchronization for all servers (and multiple sites when required). |
| Server redundancy |
Redundant fault-tolerant servers shall be provided for immediate availability and automatic failover |
| Off-site servers |
The system shall support the separation of redundant servers to an off-site location. |
| Incremental system backups |
The system shall provide an operator application to perform incremental system backups daily |
| WORKSTATIONS |
| Workstation operation |
The system shall allow all workstations to monitor access control events independently from each other. |
| Workstation recovery |
Applications on workstations shall recover automatically and come back to log on state. |
| Workstation limitation |
The system shall not be limited in the number of workstations that can be accessing information |
| Online operator help |
The system shall provide online operator help |
| Mobile Workstation |
The system shall support the ability to have a mobile workstation to allow tracking of large groups of visitors |
| GRAPHICAL USER INTERFACE |
| Graphical User interface screens |
Graphical User interface screens shall be changeable |
| Product development |
The system manufacturer shall be capable of analyzing, developing and if needed customizing their application to meet a unique Graphical User Interface look and feel. |
| Color-coded fields |
The system shall support the ability to assign unique color codes to fields within the GUI. |
| Multi-tabbed GUI layout |
The visitor application shall support the ability to create multiple tabs or pages that may look similar but are used for various types of visits. I.e. Contractor Tab, Employee Temp Card tab, Visitor Tab, VIP Tab, etc. |
| SOFTWARE |
| Revision compatibility |
System hardware and software shall be forward and backward compatible a minimum of 2 generations of equipment from the same manufacturer to prevent obsolescence |
| LOGON/LOGOFF |
| Operator actions |
The actions of each Operator shall be archived |
| Workstation login |
The system shall have the capability to restrict a user login to a specific workstation. |
| Operator login |
The system shall provide definable capabilities per operator login. |
| CERTIFICATIONS |
| Underwriters Laboratories (UL) certification - UL294 |
The system shall be UL 294 certified for access control functions |
| Underwriters Laboratories (UL) certification - UL1076 |
The system shall be UL 1076 certified |
| DICAP Certification |
System has been certified under the provisions of the Department of Defense Information Assurance Certification and Accreditation Process |
| DCID 6/9 SCIF Standards |
The system shall be capable of meeting the DCID 6/9 standards for SCIFs |
| MISCELLANEOUS |
| E-mail messages |
The system shall provide automatic delivery of e-mail messages to pre-defined individuals or groups when specific alarm conditions occur, and resolution notifications when the alarm condition is cleared |
| Third-party application integration |
The system shall provide the ability to integrate with third-party applications |
| Vehicle Association |
The system shall support the ability to associate a visitor or employee to a vehicle |
|
| |
|
|
|
HOME
iTRUST 2.0 
