Product data

[Project Number] [Project Name]
[Date] [Project Location]
28 10 00 22
Electronic Access Control/Intrusion Detection
18. The operator will be able to quickly sort event records by clicking on the column header above the record
field he wishes to sort by.
W. Web Browser interface
1. The web browser shall be able to be used remotely and allow for all programming functions offered by the
ACS software.
X. Scripting
1. The ACS software shall have a scripting GUI that allows for:
a. automatic lock down of all doors
b. send e-mail messages on events or alarms
c. attach events to linking alarms
d. attach alarms to linking actions
e. automatically arm and disarm the Intrusion Detection System
f. disable any or all card readers
g. Choose an individual card or input to automatically perform and event when the card is presented
to a reader/s or the input goes active in a normal or abnormal state.
Y. Continental FIPS 201, TWIC, FRAC & NIST 800-116 Credential Validation with the CoreStreet Approach
1. Continental Access System shall be capable of PIV enabling to the CA 3000 software as to validate the
card with the Government PKI database and the TWIC Hot List database. This function shall be done at
the database on every cardholder within the system at the time of enrollment with checks, no longer than
18 hours, of the revocation list.
a. The checks that shall be accomplished are:
1) Path discovery – The path from the PIV certificate to an embedded trust anchor.
2) Path signature verification – establishing that every certificate in the path is genuine and not
counterfeit.
3) Data object signature verification – establishing that every signed data object on the card
was signed by a trusted issuer (e.g. certificates, fingerprint template, facial image template)
to ensure they are genuine and not counterfeits.
4) Cross checking data object identifiers – all signed data objects on the PIV card have an
identifying number (FASC-N) unique to that card. Checking that each data object contains
the same FASC-N (or CHUID) ensures they all belong to the same credential.
5) Various PKI conformity and freshness checking (key usage, expiration dates, etc.)
6) PIN check –to ensure the card holder is bound to the credential to mitigate the threat of lost
or “shared” cards.
7) Private Key challenge – to ensure the certificate is bound to the token to which it was issued
and has not been copied or cloned.
8) Biometric check – to ensure the card holder is the same person that was issued the PIV
card. This mitigates the threat of “shared” cards and disclosure of the card’s PIN.
9) Periodic checking of the revocation status of the PIV Authentication certificate.
10) Periodic revalidating the full path – to ensure all of the certificates in Access Control
database remain valid and have not been revoke.
2. Validation during enrollment shall include all of these checks to ensure at the highest level possible that
all enrollees are in fact who they claim to be. This would typically be done as a function at or in conjunc-
tion with the PACS head-end.
3. Validation at the time of access shall involve a subset of these checks depending upon the assurance
level required and authentication mechanism chosen for the specific access point being addressed.
Z. Hardware Definitions:
1. Menu configurations: The System software shall allow for the configuration and programming of the
Access Control Panel through the use of a simple graphical user interface (GUI).
2. Access Control Panel Memory Allocation: The allocation of memory for cardholder data, event storage,
time schedules and access groups within each Access Control Panel will be user-definable from the
‘Configuration’ menu.