This is part of a continuing series of blog posts about the
recently released Federal
Register notice about the implementation of the Chemical Facility
Anti-Terrorism Standards (CFATS) personnel surety program (PSP). The notice
outlines how the Infrastructure Security Compliance Division (ISCD) is planning
to implement the vetting of covered chemical facility personnel and visitors
against the FBI’s Terrorist Screening Database (TSDB) to determine if any
covered personnel are suspected of having ties to terrorist organizations.
Other posts in this series include:
The Four Options
ISCD’s new PSP program provides facilities with four
specific options on how the facility will implement the requirements of 6
CFR 27.230(a)(12)(iv). Those four option (described in detail
in the notice) can be briefly summarized this way:
Option 1 – Facility submits data and ISCD has TSA conduct
screening;
Option 2 – Facility submits data on personnel with previous
screening and ISCD has TSA confirm that screening is current;
Option 3 – Facility uses TWIC Reader to verify identity and
screening status of Transportation Workers Identification Credential (TWIC)
holder; and
Option 4 – Facility visually inspects TSDB based identity document
to verify that person had been screened against TSDB.
The facility can use any of the four options or combinations
of them to satisfy the terrorist ties vetting requirements of the CFATS
program. In practice it looks like most facilities will be using some
combination of the four options in their site security plan (SSP). As I
mentioned in the previous post, adding the facility’s terrorist screening program
to the SSP will be the first step in achieving compliance with the new portion
of the PSP.
Option 4 – Visual Verification
I am going to start this more detailed review with what ISCD describes as
the option providing the lowest amount of security, Option 4. This option
provides for using visual screening of existing TSDB based identification
credentials. This would include the TWIC, the Hazardous Material Endorsement to
a CDL and various traveler based vetting programs. The notice provides a more
detailed discussion of the problems associated with this option, but does note
that it has a legitimate (and Congressionally mandated) place in the vetting
program.
Actually, this option is pretty well suited to the vetting
of commercial truck drivers making deliveries to the facility or picking up
shipments from the facility. There is a fairly high likelihood that
over-the-road drivers will already possess a TWIC or HME. MTSA covered
facilities already have established the requirement that drivers coming to
their facilities must possess a TWIC or the load will be refused or not allowed
to be picked-up. CFATS facilities implementing Option 4 will have to notify
their vendors and transportation companies of the need for TWIC or HME for all
drivers entering the facility.
Facilities can increase the security of this option by
requiring that vendors and trucking companies provide advance notice of the
name and ID number of drivers coming to the facility.
There is a downside to this option for the trucking
industry. There is already something of a shortage of long-haul truck drivers.
Further limiting those be requiring a HME or TWIC (which both have criminal background
check requirements) is going to further aggravate the driver shortage.
When using this option ISCD is almost certainly going to
require the facility to spell out in its site security plan how facility
personnel are going to be trained to visually verify the validity of the
document (recognize and detect counterfeit documents) and verify the identity
of the document holder. Requiring advance notice (perhaps with copy of ID) will
help with that training requirement.
Option 3 – TWIC Reader
The TWIC was designed to be verified (both the document and
personal identity) with a TWIC Reader. Unfortunately the Coast Guard and TSA
have had problems with the TWIC reader implementation process and there is
still not an approved rule for the implementation of TWIC Readers in the MTSA
program. The TSA reports
that it has published a list of approved TWIC Readers, but I have not been able
to find such a list in an internet search, typical for all things related to
TSA.
There are a couple of problems currently associated with the
use of a TWIC Reader. First, and foremost, they are relatively expensive.
Second they must at least periodically be connected to the Internet (or a phone
line?) to update the list of expired/revoked TWICs. Finally, individuals must
apply for (and pay the application fee for) the TWIC which requires a trip to
one of the limited number of TWIC issuing facilities.
The TWIC Reader does not need to be used at facility
entrances to be effectively used as part of the PSP. The facility could require
TWIC holders to periodically (that period to be established in the SSP) present
themselves to a designated office (possibly an off-site 3rd party
office) where the TWIC and identity could be verified.
This option would be valuable for facilities that have a
high percentage of personnel that already have a TWIC. This would also be
valuable for corporations that also have MTSA covered facilities and have personnel
that move between facilities. Contractors doing periodic maintenance or
facility turnarounds that also serve MTSA covered facilities will have very
high TWIC densities and would probably want to use this option.
The notice provides a limited amount of
guidance on what ISCD would expect to see in the facility SSP for
implementing the TWIC Reader option. It also outlines the security downside to
the use of the TWIC, is a TWIC holder is subsequently identified as having
possible terrorist ties there is nothing that will trigger an investigation of
that person at the covered facility or allow for notification of the facility
until the next time the periodic check is made.
Option 2 – Data Submission
on Previously Vetted Personnel
This has long been the most controversial of the vetting
options proposed by ISCD. Industry has always assumed that previously vetted
(via TSDB) individuals would not require data submission to DHS. ISCD has
always maintained that such data submission is required to ensure that periodic
vetting is accomplished and that the facility can be notified if a previously
vetted individual is subsequently added to the TSDB.
ISCD also likes this option because it reduces their costs
of submitting data to TSA for vetting against the TSDB. They do not have to ‘pay’
for a full initial TSDB scan, they just have to verify that the previous
vetting was done. Ironically, this also means that the facility will have to
provide more data for this option because they need to provide data on the
previous screening program (program name, ID number, and expiration date).
Facilities using this option are going to have to include a
description of the training program that they use to train the personnel that
are visually verifying the legitimacy of the presented document and the
identity of the person submitting the document. Not specifically mentioned in
the notice, but almost certainly to be required in the SSP, is a discussion of
what will be done when the existing document expires.
Facilities that have a relatively high population of
personnel that have been vetted by another agency against the TSDB are going to
have to weigh the higher security benefits of Option 2 against the simpler
process for Option 4. ISCD would much prefer to see Option 2 used, but was
required by Congress to provide option 4. I suspect that this might mean that
Option 2 might not receive as close a level of scrutiny in the SSP review as
would Option 4.
Option 1 – Data Submission
and Screening
There is no doubt that this is the method that ISCD would
prefer to see all facilities implement as it provides the best ability for the
Department to conduct vetting of covered personnel and tie the resulting information
back to individual facilities. I suspect that this will be translated into a very
wide latitude in how the Department views SSP submissions implementing this
option.
ISCD will allow data submissions from either the corporate
level or the facility level (or both) and will have some system set up for mass
data submissions, probably via spread sheets. Third party data submissions will
also be allowed so that companies can use personnel management agencies or
background check agencies to do the actual data submissions. The use of the
agency that the facility is already using to do the other background and
identity verification checks currently required in the PSP will obviate the
need for detailed information in the SSP about the training of the personnel
collecting and verifying the data being submitted to ISCD.
A Blended Program
All but the smallest facilities are probably going to find
that they are going to use all four options in their SSP. Explaining how each
option would be used in the implementation of the new terrorist ties vetting
program will provide the facility with the widest latitude in how they start
and maintain the program over the coming years. Even if the facility does not
intend to initially adopt one or more of the options, putting them all in the
SSP will make it easier to start using an option as situations change (no subsequent
change to the SSP will be required).
Facilities are going to have to take a close look at the
employees, contractors and visitors before they decide how they are going to
implement the terrorist ties vetting in their personnel surety program. They
are going to have to balance the security needs of the facility to prevent
access by people with suspected terrorist ties with the complexity of the
program that will be used to identify those people.
ISCD has committed to working closely with each Tier 1 and
Tier 2 facility while they design and implement this final phase of the PSP. That
means that there will be a risk-based staggering of the initial SSP update
requirement. The time to start working on this, however, is now, not when ISCD
provides the facility with notification of the date by which the revised SSP
will have to be provided to Department.
Posts
No comments:
Post a Comment