Home' RTCA Documents for Review : DO-230H FRAC Contents 106
© 2017, RTCA, Inc.
private PIN contained in one individual user record. All other user records remain closed and are untouched
by the validation process. The risk of a card being successfully matched with the PIN belonging to a
different user is therefore eliminated. To minimize the risk of cardholders forgetting their PINs, some
agencies allow people to select their own private PINs.
Like other data, the PIN must be properly protected to avoid inadvertent or unintended exposure.
Countermeasures include securing the PIN entry process, supervising both the communication line and the
data packet sent from the keypad to controller, and securing the data repositories where user records are
stored and maintained.
When a PIN is used in conjunction with a token (as described above), the risk of an exposed PIN is reduced.
The PACS will not grant access to a user who enters a PIN without a card or to who presents a card without
a valid PIN. Both must be entered before the PACS authorization process begins. The process is very similar
to that used at an ATM where both a card and a PIN are used.
A PACS should maintain an audit log, event history file, of time stamped access transactions and other
events that occur on a routine basis. Most systems are capable of storing detailed events such as internal
system events, alarm and system response events, access-related events and PACS Operator activities.
Events that are stored and maintained in the PACS history file often include detailed records of when,
where, who and what have occurred. This information may be accessed, and authorized PACS Operators
will use this information to generate activity reports of past events. Event data may prove to be crucial
information during a post incident investigation where a record of who accesses any specific area, during a
specified period of time, can easily be generated. For example, generate a list of everyone who accessed a
specific access control point, or all access control points accessed by a specific individual. As an example
a report may be generated to list date, time and all who accessed the freight elevator between 22:15 and
23:00 the previous night.
The report may contain time and date stamped access transactions generated from several people who used
the elevator, such as Person A; Person B; and Person C. It is worth noting that all transactions are logged
in the system and a report may be generated to include any access request that was denied and the reason
why the system denied the access request. In case of a two-factor violation (Card+PIN), the denial entry in
the report may read “Good Card -Bad PIN.”
The value of such reports is only as good as the weakest link of the chain, reaching back to the process of
identity vetting and credentialing. However, the purpose of this example is to highlight the fact that as a
card based deployment the system will show access transactions by a card – not the person actually using
the elevator. The audit trail is only as accurate as the level of confidence in the presumption that the
credential was indeed in the hands of the authorized person. Binding the person-credential-authorization so
that there is a high level of confidence in the events contained in an activity report may be crucial. An
additional level of trust in the system may be accomplished by combining more than one authentication
factor. This may be important at access control points where high-value assets are stored, or to areas where
access by non-authorized persons carry great business risk or liability to the airport operator.
Authentication IT Infrastructure with PKI
Authentication of a federally-issued card requires integration to a federal IT infrastructure. As an increasing
number of PACS manufacturers are offering this integration as an option, a generic diagram of a PKI-
enabled PACS configuration is provided in Figure 4-15: Generic PKI-enabled PACS Configuration.
Links Archive Navigation Previous Page Next Page