The Pipeline Security Guidelines are an interesting example of bureaucratic dualism. First TSA makes clear that this is a voluntary guidance document, specifically noting that it “does not impose mandatory requirements on any person” (pg 1). That one statement and the studious use of the word ‘should’ provide the needed assurances that no one needs to follow guidance provided in this document. Other than that, this publication reads very much like a regulatory document, setting time frames for security plan reviews and listing items that ‘should’ be included in the plan.
Communications with TSA
The description of the Corporate Security Program in this document briefly mentions that each operator should assign a “qualified primary and alternate staff member to manage the corporate security program”. It also mentions that the name and 24/7 contact information for these assigned individuals should be provided to TSA along with the telephone number of the operator’s “security operations or control center”.
The manual does not provide any information on why the operator should provide this information to TSA or to whom at TSA that the information should be provided. The original 60-day information collection request (ICR) notice for this data submission notes that the information will be provided to the TSA Pipeline Security Division, but no contact information for that Division is provided in this section. Buried at the end of Appendix B in the new manual is an email listing (pipelinesecurity@dhs.gov) for that Division. Presumably that is where this identification and contact information will be sent.
That ICR notice did explain what the contact information would be used for, something that the new manual does not do. TSA explained that:
“TSA's Pipeline Security Division will use the operator contact information to provide security-related information to company security managers and/or the security operations or control center. Additionally, TSA may use operator contact information to solicit additional information following a pipeline security incident.” (74 FR 37724).The same section in the manual notes that operators should notify TSA “of all security incidents by phone or e-mail as soon as possible”. Appendix B provides a relatively detailed list of the types of incidents that it expects to be reported as well as telephone and contact information for the Transportation Security Operations Center (TSOC, 866-615-5150, TSOC.ST@dhs.gov). It would probably be a good idea if TSA were to print up a flyer or small poster with this information that could be posted at the appropriate pipeline-operator phone locations.
Corporate Security Plans
In the CFATS program the emphasis is on facility level security planning. The TSA has taken a different tack; they recommend the development of a corporate security plan. There is a nice generic discussion of the type of information that should be included in such a plan.
Interestingly it includes a specific recommendation that a copy of the plan be available for TSA review and copying. This was addressed in the TSA Pipeline Corporate Security Review information collection request that I reported on back in November. That ICR has yet to be approved by OMB.
I mentioned in that blog posting that the 30-day notice contained no reference to the information being provided to TSA being protected as Sensitive Security Information. There is also no discussion in the Pipeline Security Guidelines of the SSI program or its applicability to any information described in the document. Since there is no specific Congressional mandate for a pipeline security program that specifies that this information would be protected, it might be argued that the SSI rules do not apply to pipeline security information.
Risk Assessment
Generic discussions of security are a hallmark of this document. The section on risk assessment carries on with that level of discussion. The closest thing that comes to an exception to that level of discussion is the coverage of the methodology that an operator would use to determine pipeline facility criticality. This is important because TSA only suggests that critical facilities would require a security vulnerability assessment.
There is a list of criteria that could be used to determine facility criticality. While the list looks to be fairly comprehensive, there are so many loosely or ill defined terms included in the descriptions that the list also becomes generic.
For example the first criteria listed suggests that if “required service or deliverability to installations identified as critical to national defense” (pg 9) was disrupted or significantly reduced if the facility were damaged or destroyed the facility would be defined as critical. Unfortunately there is no suggestion as to how an operator would know if an installation was ‘critical to national defense’.
Security Measures
The discussion of security measures is probably the most detailed and involved in the manual. First it describes two different levels of security measures, baseline and enhanced. It recommends that all pipeline operator facilities implement the baseline measures and critical facilities implement the enhanced measures.
Readers who are familiar with the Risk-Based Performance Standards Guidelines for CFATS covered facilities will recognize the wording of many of the standards listed in this pipeline manual. Unfortunately, this document does not reach anywhere near the level of detail supplied in the RBPS Guidelines.
For example the entire discussion of suggested barrier requirements for critical facilities is shown below.
“Create a security perimeter that deters unauthorized vehicles and persons from entering the facility perimeter or critical areas by installing and maintaining barriers (for example, fences, bollards, jersey barriers, or equivalent).” (page 12)Control System Security
There is an entire chapter related to control system security measures. This is one area where there are some significant improvements in the security measure discussion in this document over the RBPS Guidelines. The measures presented in this document are clearly control system measures rather than IT security measures. Unfortunately, in many instances they threw out the baby with the bath. For example there is no mention of the use of anti-virus software.
Even here though, there is a certain unevenness in the security protocols suggested. For instance in the baseline protocols they suggest the establishment of procedures for intrusion detection, but then only recommend reviewing network connections on an 18-month cycle. Under their enhanced security measures they list a number of different physical and software techniques for providing access control and then suggest a 36 month cycle for conducting ICS vulnerability assessment.
Enforcement
Since this is a strictly voluntary program (Congress has provided TSA with no specific authority to implement any other kind of program) there really are no provisions for enforcing any of the suggestions in this manual. The closest thing to enforcement is the Pipeline Corporate Security Review program. This is a very limited program where TSA ‘inspectors’ will visit up to 12 locations every year. The one day visits will provide very little opportunity for more than cursory program reviews. Even the ability to ask for copies of the Corporate Security Program will be of little use because there will be little or no opportunity for the inspector to verify that the operator is actually doing what is claimed in the program.
Still, this is better than nothing. After all, there have been no actual terrorist attacks on pipeline facilities in the United States (just one intercepted plot). It’s not like we were in Canada (where there have been a number of limited ecoterrorist attacks) or Mexico (where narco-gangs have stolen fuel and crude from government pipelines with sometimes catastrophic results).
No comments:
Post a Comment