CFATS Knowledge Center Update 03-05-12

I’m not sure when it happened (changes are not noted on this page) but I noticed today that the ISCD folks at DHS have added a new feature to their CFATS Knowledge Center web page; the CSAT Narrative Demonstration Application. The link to this new feature is located below the line of tabs across the center of the page under the ‘Help Options’ heading.

This ‘CSAT Narrative Demonstration Application’ is apparently a new information sharing tool. Currently the only ‘demonstration’ available is an audio-visual slide presentation about the Site Security Plan. It is a 64-slide narrated-presentation that explains the site security plan. I haven’t had a chance to review the complete presentation, but what I did see was a fairly informative presentation. Whether or not the presentation is sufficient to overcome the current problems with inadequate information being provided to ISCD on the SSP Tool submissions remains to be seen.

This is the kind of effort that we use to see out of ISCD on a recurring basis and it is good to see that the communications efforts are being resumed.

Congressional Hearings – Week of 3-5-12

The Senate is joining the budget hearing schedule in force this week, but the big news is the CFATS hearing before a subcommittee of the House Homeland Security Committee.

CFATS Problems

The Cybersecurity, Infrastructure Protection and Security Technologies Subcommittee of the House Homeland Security Committee will be holding a hearing tomorrow on the CFATS program problems. It looks like Chairman Lungren is serious about this hearing as there will be two panels testifying. The first panel will be the management team including Under Secretary Beers, Director Anderson, and Deputy Director Wulf. The second panel will be a tad bit more interesting; Bill Almond from SOCMA, Timothy Scott from Dow Chemical, and David Wright from the American Federation of Government Employees Local 918.

I would have preferred to hear some of the lower level management and some of the inspection force testify, but a union rep will probably have to do at this point.

It will be interesting to see what questions are asked. Hopefully the congress critters will be a tad bit more prepared and knowledgeable in this hearing, not like the fiasco in the February hearing before the Energy and Economy subcommittee.

Budget Hearings

Secretary Napolitano will make two Senate appearances on March 8^th to discuss the DHS budget request; one before the Senate Homeland Security and Governmental Affairs Committee and the other before the Homeland Security Subcommittee of the Senate Appropriations Committee. Nothing new expected in either hearing.

Admiral Papp will be making two Congressional appearances to discuss the Coast Guard’s budget request for FY 2013; one before the Homeland Security Subcommittee of the House Appropriations Committee tomorrow and one before the Senate Committee on Commerce, Science, and Transportation. The later hearing will be shared with the NOAA Administrator so that will certainly be a shallow hearing on the Coast Guard budget.

S 2152 Language

Thanks to two different readers I now have a copy of S 2151, the Strengthening and Enhancing Cybersecurity by Using Research, Education, Information, and Technology (SECURE IT) Act of 2012 that was introduced by Sen. McCain on Thursday. The copy I have is the final draft version from committee files, but until the GPO publishes the final version it’s the best available information. It is a much more limited cybersecurity bill than S 2105, not providing any additional regulatory powers to DHS.

Information Sharing

For the civilian portion of critical infrastructure there is little more in the bill that some provisions that authorize information sharing from the civilian sector to the federal government. While at first glance it would not seem necessary to authorize that sharing, the provisions of the bill allow the sharing of ‘cyber threat information’ with existing federal ‘cybersecurity centers’ or ‘any other entity’ for the purpose of “preventing, investigating, or otherwise mitigating threats to information security [emphasis added]” {§102(a)(2)(B)}. Again, this bill uses the common definition of ‘information security’ that does not specifically include control systems from 44 USC 3502(8).

Nothing in the definition of ‘cyber threat’ includes specific language that would include information systems linked to control systems. Nor is the ICS-CERT listed as one of the current agencies listed as ‘cybersecurity centers’. In short the information sharing section (Title I) of this bill has no effect on control system security, nor does it authorize sharing of cyber threat information concerning control systems.

The information sharing provisions of this bill are important because the exempt the sharing of cyber threat information from the communications limitations of various anti-trust rules and regulations; provide public reporting exemptions under the Freedom of Information Act and pre-empts state laws regarding information sharing.

Criminal Penalties

There is an important control system related change being made in this bill in that it provides for criminal penalties for attacks on control systems in critical infrastructure. It adds Section 1030A to 18 USC that makes it an offense to knowingly cause, or attempt to cause, damage to a ‘critical infrastructure computer’ or the critical infrastructure associated with the computer. It provides for a sentence of 3 to 20 years for each offense.

A ‘critical infrastructure computer’ is defined as “a computer that manages or controls systems or assets vital to national defense, national security, national economic security, public health or safety, or any combination of those matters, whether publicly or privately owned or operated” {§1030A(a)(2)} and then goes on to list the following included sectors:

• Gas and oil production, storage, and delivery systems;

• Water supply systems;

• Telecommunication networks;

• Electrical power delivery systems;

• Finance and banking systems;

• Emergency services;

• Transportation systems and services; and

• Government operations that provide essential services to the public.

If and when someone actually gets caught attacking a non-refinery chemical control system we will find out how broadly the courts will interpret ‘national economic security, public health or safety’ as it pertains to facilities in sectors not specifically listed in the bill. It would have seemed more appropriate to list all of the current 18 Critical Infrastructure Sectors.

Research and Development

Title IV of this bill provides for an amendment to the National High-Performance Computing Act of 1991 by adding research on networking and information technology to the goals and priorities section of that act without adding any additional funding for such research goals.

Section 404(b) of the bill provides for special emphasis on research on technical solutions in a variety of cyber technologies including cybersecurity {§404(b)(1)} and ‘cyber-physical systems’ {§404(b)(5)}. Cyber-physical systems are defined as “physical or engineered systems whose networking and information technology functions and physical elements are deeply integrated and are actively connected to the physical world through sensors, actuators, or other means to perform monitoring and control functions [emphasis added]” {§401(g)(4)}; a clear, unequivocal reference to industrial control systems.

The ‘cyber-physical systems’ research is to be focused on improving “the methods available for the design, development, and operation of cyber-physical systems that are characterized by high reliability, safety, and security [emphasis added]” {§402(b)(3)}.

No Real Control System Security

So once again we have a cyber-security bill that essentially ignores the unique problems with control systems. Nor are there any regulatory requirements that would allow the government to force software vendors to address vulnerabilities in software systems in either the information security sector or in the control system sector.

February 2012 ICS Monthly Monitor

On Friday the DHS Industrial Control System Cyber Emergency Response Team (ICS-CERT) published their February 2012 issue of the Monthly Monitor. This issue includes a brief description of a government facilities incident independently identified by ICS-CERT and a lengthy discussion about network-based intrusion detection systems (NIDS) for control systems.

Incident Description

The incident briefly described on the first page of the monitor deals with a government owned control system of a type frequently overlooked in the general discussion of industrial control systems, an environmental control system for a building. While not directly involved in the production of commercial products they may be used in an important support role in many manufacturing locations (clean rooms for instance).

In this instance ICS-CERT somehow (not discussed in the brief report for obvious reasons) detected the intrusion into the environmental control system of an unidentified state government building. Facility personnel had already detected unauthorized adjustments to the control system and had already reconfigured their system to remove internet access to the controls.

ICS-CERT determined that the access had been made through the Internet interface for the system even though it had been configured to require a password. The report does not note whether the password had been a default password, if it had been compromised or if it had been broken by a bruit-force attack.

The most interesting thing about this brief report is that ICS-CERT contacted the facility not the other way around. As with the ‘water system hack’ last year it is becoming increasingly evident that the services of ICS-CERT are not adequately known or facilities are reluctant to report incidents to the one government agency most likely to be able to help them deal with a control system intrusion or attack.

Situational Awareness

In the Situational Awareness article there is an informative write up about NIDS and two open source NIDS packages recently upgraded (SNORT) or being upgraded (Suricata) to be useful in detecting control systems intrusions. This information alone in the article makes it well worth reading, but the lengthy article also addresses two other ICS issues of at least equal importance; Project Basecamp and source code exfiltration.

Project Basecamp is certainly not new and it has been addressed by ICS-CERT in advisories and alerts, but this is the first time that ICS-CERT has actually described the Project Basecamp process and discussed its consequences (and yes, it does include the appropriate links to the source material). Nothing really new informationally here, but it is a valuable acknowledgement of the importance of Project Basecamp.

The recent public exposure of the source code for two Symantec products (Norton Anti-virus and PCAnywhere) is addressed in the portion of the article about source code. While these two specific incidents have been addressed in more depth elsewhere, this Monthly Monitor piece addresses the general potential importance of exfiltrating control system source code. While identification of system vulnerabilities is the most obvious problem with gaining access to the source code for any application this ICS-CERT write-up identifies an even scarier potential problem modifying the code to implant backdoors and other vulnerabilities and re-infiltrating the code on the vendor’s site for distribution. Similar problems could occur if doctored counterfeit copies of the system were sold on the black market.

The Situational Awareness article closes with a well-deserved plug for the ICS-CERT CSET Assessment Tool and the on-site assistance that ICS-CERT can provide for using that tool to conduct an in depth assessment of the security of a facility’s control system.

Another Good Monthly Monitor Issue

The other standard features of the Monthly Monitor provide a wealth of valuable ICS-CERT information (list of ICS-CERT alerts and advisories from February) and links to other sources of ICS security information. The plug for coordinated vulnerability disclosure includes even further expanded recognition of researchers who do not fully work ‘within the system’ on vulnerability disclosures by recognizing researchers who do assist in the validation of patches developed in response to their uncoordinated disclosures.

All in all this is another example of the type of open-source information sharing that should be the hallmark of any public-private partnership on ICS security.

S 2151 Introduced – Alternative Cybersecurity Legislation

Yesterday, as he promised during the hearing on S 2105, Sen. McCain (R,AZ) introduced S 2151 yesterday as an alternative method of regulating cybersecurity issues. McCain’s bill is not yet available on the GPO web site (nor anywhere else that I have looked in a cursory search) so I can’t really comment on the provisions of the bill. To see what the various sponsors think the bill says you can look at the press release on McCain’s Senate website.

An interesting procedural note; when the bill was introduced it was referred to the Senate Committee on Commerce, Science, and Transportation for action, not the Homeland Security and Governmental Affairs Committee. These two committees kind of share responsibility for cybersecurity issues in the Senate, so it isn’t too much out of the ordinary.

In the normal course of events one would suppose that the two bills being referred to two different committees would be a sign of a jurisdictional fight between them. That probably isn’t the case here as Chairman Rockefeller was a cosponsor of S 2105 and testified on its behalf before the Homeland Security Committee.

The bill will probably be available next week and I’ll take a detailed look at it then.

TSA Surface Enforcement Actions 2011

Today the Transportation Security Administration (TSA) published a notice in the Federal Register (77 FR 12865) announcing the availability of their annual report for 2011 summarizing the enforcement actions undertaken by the TSA “for violations of any surface transportation requirements under title 49 of the U.S. Code (U.S.C.) and for any violations of chapter 701 of title 46 of the U.S. Code, which governs transportation worker identification credentials” (77 FR 12865).

The actual report is only three pages long but it is not printed in the Federal Register notice. To see the actual report you have to go to www.regulations.gov (Docket # TSA-2009-0024). The folks managing this web page no longer provide direct links for individual documents; the closest you can get to that is the link for the page where you can get to the document. For this year’s report that page is: http://www.regulations.gov/#!documentDetail;D=TSA-2009-0024-0008 (for the 2010 report replace the last digit with a ‘5’; and for 2009 with a ‘2’).

Summary Data

The table below shows a summary of the data for 2011.

2011 TSA Surface Enforcement Actions	# of Incidents	Maximum Penalty
		Proposed	Imposed
Rail Car Chain of Custody	13	$6,000	$3,000
Rail Car Location	2
Reporting Security Concern	2	$3,000	$3,000
Use of another's TWIC	1
Allow another to use TWIC	2	$1,500	$1,500
Fraudulent Manufacture of TWIC	1
Total	21	$13,500	$8,500

Table 1: 2011 TSA Enforcement Summary

The rail car actions are based upon the freight rail security provisions at 49 CFR 1580.107. The reporting of security concerns are found in the same regulations at §1580.203. The TWIC actions are based upon §1570.7 of 49 CFR not the Coast Guard regulations regarding TWICs. The listing of these actions in the summary report also includes the case numbers for each action.

Not Much in the way of Fines

It is apparent from this report that TSA is not concerned much about collecting fines. Most of the ‘penalties’ noted in the report are administrative in nature. There are three separate administrative actions listed for the violations reported, unfortunately TSA does not provide any information about the relative level of severity or an explanation of the consequences for these actions. The three administrative actions listed are:

• Warning Notice;

• Letter of Correction; and

• Notice of Non-Compliance.

A total of only $8,500 collected in civil penalties for 21 separate enforcement actions would tend to indicate that TSA was more interested in working with the regulated community to correct security problems. That is probably a more effective use of the time available to the limited surface inspection force.

Having said that, TSA is obviously stepping up pressure to achieve compliance. In 2010 there were only 17 enforcement actions and no civil fines were levied and in 2009 (the first year of TSA’s authority to levy civil penalties) there were seven actions and not fines. Still the maximum allowed civil penalty is $10,000 and the highest fine levied was only $3,000.

While I applaud TSA’s working with industry to ensure security compliance, I was a tad bit disturbed to see no fine associated with the single instance of ‘Fraudulent Manufacture of TWIC’. That would seem to be a deliberate attempt to violate the rules which to my mind requires punishment not corrective action. Of course there are no details provided about any of these incidents, so it is really quite difficult to make an even somewhat informed second guess of the TSA’s actions in these cases.

Evolving Enforcement

The Regulation.gov web site still has the summary reports for 2009 and 2010 available for review. Table 2 below summarizes the number and types of enforcement actions completed in the first three years of the program. The one clear piece of data here is that there continues to be issues surrounding the requirements for chain of custody  documentation for rail security sensitive materials (RSSM). The limited data provided here does not allow, however, for a real assessment of how serious the problem is. To fully analyze the situation we would need to know how often, for example, TSA inspectors checked the documentation for chain of custody transfer.

2009 thru 2011 TSA Surface Enforcement Actions	# of Incidents
	2009	2010	2011
Did not allow TSA Inspection		2
Rail Car Chain of Custody	2	12	13
Rail Car Security		1
Rail Car Location			2
Reporting Security Concern		1	2
Use of another’s TWIC	1	1	1
Allow another to use TWIC	1		2
Direct the use of another’s TWIC	2
Fraudulent Manufacture of TWIC			1
Use of an altered TWIC	1
Total	7	17	21

Table 2: TSA Surface Enforcement Actions thru 2011

Another area where the inspection rate data would be of particular interest is with regards to the TWIC enforcement actions. One would like to assume that TSA isn’t spending a lot of time checking general TWIC use at port facilities; that enforcement would more likely fall to the Coast Guard. It is more likely that the TSA inspectors were checking the TWICs of train crews hauling RSSM in and out of port facilities. If that’s the case, and given the small number of available TSA Surface Security Inspectors, the four TWIC enforcement actions in 2011 could indicate a serious problem with rail crews and TWICs. This could be particularly important as more high-risk, non-MTSA, chemical facilities begin to use TWICs as a method of personnel surety vetting for transportation workers.

Congressional Oversight

Congress mandated {49 U.S.C. § 114(v)(7)(A)} that TSA provide these annual reports on enforcement actions. One would assume that the purpose of the report was to allow for Congress to have a relatively easy way to monitor the progress of the surface security programs mandated by law. TSA surface security programs are a relatively small part of the TSA operations and are frequently overlooked by Congress.

In light of the problems still being uncovered at ISCD with another relatively small security program, CFATS, it might be interesting for a responsible subcommittee of either the transportation or homeland security committees (of either the House or Senate) to use the occasion of this report to conduct an oversight hearing on the implementation of the surface security inspection programs.

More on TWIC Reader Pilot Study – Purpose of TWIC

Okay, I’ve had a chance to do a quick once thru of the TWIC Reader Pilot Study Report that I mentioned yesterday. Additionally, a long time reader pointed me at a publicly available summary prepared by JTAC consulting (okay ‘summary’ is a little misleading; its 24 pages long) that condenses the important information in the report. Both documents are worth reading in detail if you are planning on installing a TWIC Reader as part of your facility/vessel access control system. The JTAC web site has a number of other documents available that may also be of use, but I have not (and probably will not) reviewed each of them to be able to specifically recommend any specific information.

One thing is clear, installing a TWIC Reader as part of an access control system (either stand alone or as part of a more complete system) is going to be expensive. Right now, MTSA covered facilities are not required to use TWIC Readers (that may or may not change when the subsequent regulations are written) so a careful evaluation of the need for installing a reader is necessary.

Transportation Workers Identification Credential

First you need to understand what a TWIC is. The TWIC is a biometric based identity document that establishes that an individual has been vetted by a established background check process. The government has established by regulation what standards are used to approve a person for issuance of a TWIC and that approval can be removed (TWIC Cancellation) at any time that additional information is received through follow-up background checks.

A TWIC can be used as a photo ID (and that is all that it can practically be used for without a TWIC Reader). When used in that manner it only verifies that the pictured individual was, at the time of issuance, vetted by the TSA background check process. While TSA publishes daily lists of canceled TWICs, it is not practical for those lists to be checked at an access control station without a TWIC Reader. HR or Security could check those daily lists against approved employee lists, but that is unlikely to occur on a regular basis; and almost certainly will not be done on a daily basis.

An electronic chip within the card contains an electronically encoded sample of the holder’s finger print that allows for biometric confirmation that the person in possession of the card is actually the person vetted by TSA. This information is only accessible by a TWIC Reader.

MTSA covered facilities are required by law to use the TWIC as the method to identify individuals granted unaccompanied access to covered facilities and vessels. Facilities and vessels are allowed to further restrict access of TWIC holders as they deem fit.

The TWIC process was designed to provide port transportation facilities with a means of vetting a transient population that can change significantly on a daily basis. There is no other practical way for a facility to ensure that a known set of background checks (particularly screening against the Terrorist Screening Database –TSDB) have been completed on such a transient population.

TWIC and CFATS

There has been a lot of loose discussion about the use of the TWIC process as a substitute for a facility personnel surety program. Under current regulations that is not legally possible because a TWIC applicant is required to swear on their application that they are requesting a TWIC so that they can access an MTSA covered facility. There is only a very small percentage of CFATS employees that can so truthfully swear. Of course those regulations could be changed, but it is difficult to cross load regulatory requirements across different agencies (Coast Guard and NPPD in this case).

The TWIC system could be used to supplement the facility personnel surety program as a means for vetting transient populations, particularly truck drivers. To get the full benefit for such a population a TWIC Reader will be an absolute necessity as it is the only practical way of ensuring that the TWIC is currently valid.

Unfortunately not all truck drivers will have been issued a TWIC. For the TWIC to be used as the means of validating background checks for truck drivers (and the only alternative to ensure vetting against the TSDB is checking the Hazardous Material Endorsement – HME – to the driver’s CDL; again not issued to all truck drivers) the facility will have to establish with their vendors and supporting truck lines that all drivers entering the facility will be required to have a valid TWIC or HME. In many instances (particularly away from port areas) this may greatly restrict the number of drivers available to service a facility. This will inevitably add to shipping costs and shipping delays.

Practical Aspects of TWIC Readers

With that background information out of the way, I’ll discuss some of the practical implications for the use of TWIC readers in some subsequent blogs.