Wednesday, February 29, 2012

Late Robo-SCADA Vulnerability Advisory

Yesterday ICS-CERT published an advisory for a buffer overflow vulnerability in a number of ABB products associated with the control of industrial robots. The vulnerability was initially reported by Luigi and was coordinated through the Zero Day Intiative (ZDI). The vulnerability could allow a relatively low skilled attacker to execute a denial of service attack on the robot controllers while a skilled attacker could exploit the vulnerability to execute arbitrary code on the system. ABB has released a patch for the problem.

In short this is essentially your standard HMI buffer overflow situation on a specialized SCADA system. The only odd thing about this advisory is the timing. ZDI took care of the coordination between the vendor and the researcher (the same type thing that ICS-CERT does regularly) and published their report on the vulnerability after ABB made their patch available and contacted their customers. That was a week ago today.

Based upon past history we would have expected to see this advisory a day or two later. Okay, so maybe they missed it. Dale Peterson noted the ZDI report in his Friday News & Notes on Digital Bond last week. Missing both mentions is a bit of a stretch. Unfortunately, ICS-CERT hasn’t provided any explanation for the delay in releasing this advisory.

TWIC Reader Report Available

Well it finally was released yesterday, the long awaited report on the TSA’s study of TWIC Readers. This study was the last hold-up in the completion of the TWIC regulatory process; telling MTSA covered facilities and vessels how to implement the electronic verification of the TWIC as a method for access control.

I have not had a chance to review the document in detail, but the most important statement (from a regulatory point of view at least) is found on page iv of the Executive Summary:

“It was determined that TWIC reader systems function properly when they are designed, installed and operated in a manner consistent with the characteristics and business needs of the facility or vessel operation.”

As is to be expected there are limitations and challenges. The next page states:

“A number of operational and technological difficulties were documented that affected the overall success at many pilot locations.”

We’ll have to look at the reported details to see just how much of a problem these ‘difficulties’ will be to overcome. More on the report later.

Tuesday, February 28, 2012


John C.W. Bennett has an interesting post over on his Maritime Transportation Security News and Views blog that discusses, in part, the portion of the recent National Maritime Security Advisory Committee (NMSAC) that deals with the Transportation Workers Identification Credential (TWIC). The discussion is lengthy but well worth reading.

TWIC Cards will Die on Expiration

There were two interesting exchanges noted in Bennett’s post one of which will be of specific interest to the chemical facility security community. The more general note first; Bennett notes (without quotes so I’m not sure where the data comes from) that:

“With regard to proposals to extend the expiration dates on TWICs until readers are in place, the chips on TWICs expire when the card’s expiration date is reached. They will no longer work with a TWIC reader and the biometric data can no longer be accessed.”

This is something that I had not heard before. It does make a great deal of sense to design the cards this way. Of course since only a few facilities are currently using TWIC readers at this point I’m not sure how much of an issue this will be for preventing Congressional pressure to extend the current TWIC expiration.


Bennet reports an interesting exchange between the NMSAC chair and John Schwartz from the TSA about the potential general use of TWICS.

“The NMSAC Chair noted that the original legislation had called for one security card for all transportation modes and asked why airport pass offices couldn’t be used as TWIC enrollment centers, since they all have collection and transmission capabilities. Mr. Schwartz [TSA] answered that their systems weren’t set up the same way. The airports bounce information off of TSA, but they make their own access/pass issuance determinations.”

This is one of the potential problems with using the TWIC as the sole method of vetting employees. Since the TWIC background check also includes criminal checks and has its specific list of disqualifying criminal offenses, facility managers would be giving up their right to make a decision as to how those particular offenses weigh in personnel issues. Presumably, facilities that would use a TWIC as their personnel surety program would forgo other background checks as duplicative and miss criminal behavior that would be of concern to their organizations but are not considered as part of the TWIC checks.

The current CFATS rules only require the use of a criminal background check but leave the decision as to which offenses under what circumstances would prohibit an employee unaccompanied access to a restricted area up to facility management. The use of the TWIC as the personnel surety program removes that discretion from the facility management.

Monday, February 27, 2012

Propane Revisited

It has been a while, but let’s look at a recent chemical incident as very briefly reported at A propane explosion caused a reported $1 million dollars in property damage at a construction site in Mukilteo, WA when a valve was knocked off a tank when it was being moved.

How much propane did it take to produce a ‘300-foot blast zone’? It only took about 300 gallons or about 2,000 lbs. It doesn’t take much flammable gas to provide a really significant explosion when the conditions are right. That is why DHS set the screening threshold quantity (STQ) for flammable gasses at 10,000 lbs; about five times as much as was involved in this explosion.

OOPS. I should have said all flammable gasses except propane. At the urging of the propane industry, and more importantly the agriculture industry, DHS set the STQ for propane at 60,000 lbs. This means that all but the largest commercial propane tanks and the wholesale tanks at distributors are presumed to not be a threat to homeland security if successfully attacked by terrorists.

While politics certainly had a part to play in the DHS decision on the listing of propane, one must also assume that in a twisted sense reality also had a great deal to play in that decision. I have not seen reliable figures on how many tanks holding 10,000 lbs or more exist in the United States, but I would surely bet that it was more than the 40,000+ number of facilities that did submit Top Screens to the CFATS program.

That means that we could have had more than 80,000 Top Screens submitted with a similar doubling of the about 4,000 facilities going into the site security planning process. And you think that DHS has had problems processing site security plans now? OMG!

Of course the tank at this facility could have been designed to hold 60,000 lbs of propane, the article doesn’t say. One would like to think that you pretty much empty a propane tank when you move it, just to prevent this type of accident. You also reduce the cost of the crane that has to lift it if you lighten the load. So it is possible that this sight could actually have been covered by CFATS.

OOPS. Wrong again. You see it was a water treatment facility. So, even if it did have a 60,000 lb propane tank on site, it would not have been covered by CFATS. Nor would it have been covered by the much weaker EPA regulations that don’t require security plans. The EPA is concerned with protecting the purity of the drinking water (a very important concern to be sure) not with protecting the public from terrorist attacks on the chemicals on site.

Oh well. I guess the good people of Mukilteo, WA will just have to hope that their water facility management can provide adequate anti-terrorism security without federal oversight.

Congressional Hearings – Week of 02-27-12

Well Congress comes back this week from a week of celebrating President’s Day and there are some interesting hearings on this week’s schedule and two hearings already scheduled for the following week that may be of interest to the chemical and cyber security communities. This week we have a water security hearing, a cybersecurity hearing and an NPPD Budget hearing.

Water Security

Okay that may be a stretch but water facility security issues just might be mentioned in the hearing on “Local Government Perspectives on Water Infrastructure” on Tuesday being held by the Water and Wildlife Subcommittee of the Senate Environment and Public Works Committee. Local governmental officials are on the witness list. Any security related questions would come from Sen. Lautenberg (D,NJ) who has introduced legislation on water facility security issues (S 711).


On Tuesday the House Energy and Commerce Committee’s Subcommittee on Oversight and Investigations is holding a hearing on “Critical Infrastructure Cybersecurity: Assessments of Smart Grid Security.” The current witness list includes two GAO representatives (Gregory C. Wilshusen, Director of Information Security Issues and David Trimble, Director, Natural Resources and Environment) and a Congressional Research Service representative. It doesn’t sound like any control system expertise is involved; but Smart Grid isn’t about control systems is it? It’s all about personal privacy issues.

NPPD Budget

Under Secretary Rand Beers will be appearing at a closed door (classified) budget hearing before the Homeland Security Subcommittee of the House Appropriations Committee on Thursday. I have seen at least one news report that this hearing is all about the CFATS problems, but I really doubt that. The NPPD budget hearing is typically classified and the Subcommittee has too much on its plate this early in the budget cycle to concern itself in detail about the management issues in a small agency like ISCD.

No doubt that Beers will be questioned about the ISCD problems in this hearing; probably by Rep. Dent (R,PA) who has a history concern about the program and is the sponsor of the only one of the three House bills (HR 916) that has been ignored by both the Energy and Commerce Committee and the Homeland Security Committee.

I really expect that the bulk of the questions that require this classified briefing will have to deal with securing government information systems.

Preview of the Following Week

We already have two hearings on the schedule for the following week that will be of interest to readers of this blog; both will be held a week from Tuesday.

The House Homeland Security Committee’s Cybersecurity, Infrastructure Protection and Security Technologies Subcommittee will hold a CFATS oversight hearing. No witnesses are yet scheduled but we can certainly expect to see Beers and Director Anderson. It will be interesting to see if anyone else from the current or past staff of ISCD will provide testimony.

Commandant Papp will testify at a Coast Guard budget hearing before the Homeland Security Subcommittee of the House Appropriations Committee. I’m pretty sure that we will hear questions about the TWIC Reader program and possibly extending the expiration of the current TWIC cards.

Saturday, February 25, 2012

TSA Air Cargo Screening ICR Renewals

Yesterday the Transportation Security Administration submitted their 60-day information collection requests renewal notices for two separate ICRs (1652-0040 and 1652-0053) in support of their Air Cargo Security Requirements program and the Certified Cargo Screening Program.

Typically these ICR renewals are not a big thing; just a rehash of old information necessary to keep the ICR files up to date. The numbers (number of submissions required and total response time requirements) are frequently just a cut and paste operation, but sometimes some interesting and often unexplained changes are included. That appears to be the case here.

Air Cargo Security ICR

This ICR is in support of TSA activities required under the Aviation and Transportation Security Act (ATSA; PL 107-71) for screening all property that will be carried aboard a passenger aircraft and the establishment of a system to ensure the security of cargo being carried on all-cargo aircraft. The individual collections covered under this ICR renewal, the expected number of annual submissions and the time needed to complete those submissions is listed below. The previous ICR was approved on 4-8-11 and expires on 4-30-12.

Initial Security Program
Security Program Updates
Security Program Appeal
STA Record Keeping
KSMS Manual
CSRI Record Keeping

 Air Cargo Security Requirements ICR Data

NOTE: KSMS - STA - Security Threat Assessment; Known Shipper Management System; CSRI - Cargo Screening Reporting Information

There are two reasons for the differences between the totals listed in the table above and the data from the previous submission. First TSA added the ‘STA Record Keeping’ to the ICR (NOTE: That was not specifically mentioned in the ICR though it probably should have been.).

The figures in the ‘Time’ column are my calculations not the numbers from the ICR as I noted three discrepancies; the ISP figure in the ICR was 606 not 608, the CSRI figure in the ICR was 6994 not 7020; and the CSRI Record Keeping figure was 3320 not 3334. The last was due to a rounding issue for the digital equivalent of 5 minutes (.083 vs .0833…) and may be a federal standard. I don’t know where the other two errors crept into the system but they have been included in previous ICR’s.

Certified Cargo Screening ICR

This ICR renewal is in support of the TSA’s certified air cargo screening program. Adoption of the final rule for this program last summer modified the necessary information collections to support that program and greatly reduced the number of submissions (127,050 down from 724,774) and the time required to submit the required information (143,785 hours down from 718,482 hours). That reduction was due to the elimination of the provisions regarding validation firms and dropping the requirements for airlines to become certified cargo screeners.

The individual collections covered under this ICR renewal, the expected number of annual submissions and the time needed to complete those submissions is listed below. The previous ICR was approved on 4-8-11 and expires on 4-30-12.

CCSF Application
STA Applications
Security Programs
Security Program Updates
Record Keeping
Cargo Reporting

Certified Cargo Screening Program ICR Data

NOTE: CCSF - Certified Cargo Screening; STA - Security Threat Assessment

The only new item included in this ICR is the provision for 593 new Security Program submissions; why this was not included in the previous ICR is not explained. There is an odd omission from the information collections listed in this (and previous versions of this) ICR. There is no provision for record keeping for the Security Threat Assessments as seen in the Air Cargo Security ICR.

Thursday, February 23, 2012

Criticizing ICS-CERT

Joe Weiss has an interesting blog post on criticizing ICS-CERT for their inappropriate coverage of SCADA/HMI vulnerabilities. He notes data from Bob Ravanovsky analyzing the “advisories, alerts, bulletins and notices” published by ICS-CERT from March 11th, 2010 through February 14th 2011 showing that 76.55% of those publications have been about HMI vulnerabilities and only 11.82% have been about actual vulnerabilities in control systems and their components. He closes by saying:

It appears that ICS-CERT seems to be focusing on the lesser important issues.

Now this isn’t new criticism of ICS-CERT. Dale Peterson at has been making the same complaint for some time. And this isn’t even the first time that Joe has made this general complaint, just the first with this particular empirical data. While I respect both of these individuals, and many of the other people voicing the same complaint, I’m afraid that I think their complaints are a little overblown; at least as they refer to the relative amount of time spent on HMI issues.

First off, ICS-CERT was established as a ‘Cyber Emergency Response Team’ not a research organization. Their alerts and advisories are information sharing exercises where they translate the work of independent security researchers and the responses of vendors into documents that are readily available to the ICS community. If the bulk of the research work of these independents has been focused on HMI systems not control systems that is not the fault of ICS-CERT.

Besides, it hasn’t been until relatively recently that the general view of the control system community was that their systems were isolated from various networks so that the only possible route of vulnerability was via the HMI. That made these applications fair game for researcher efforts. As Stuxnet made clear to the control system owner/user community that their isolated systems were actually vulnerable and researchers began to take detailed looks into that vulnerability.

Now, thanks to the work of Dillon Beresford and the folks working on Project Base Camp, it is clear that there are a large number of relatively simple to find vulnerabilities in the hardware-software (HIS) interface side of the control systems. I suspect that we will begin to see more and more ‘control system’ alerts and advisories out of ICS-CERT.

Wednesday, February 22, 2012

Reader Comment – Terms of Use

Last Saturday Dale Peterson, a long time reader and influential member of the control system security community (owner of posted a response to the terms of use portion of my blog post on the Friday ICS-CERT advisories. In part he wrote:

“At least you, and I, have the courtesy to link to the bulletin when we discuss it. ICS-CERT has not linked once to the Basecamp posts or pages that disclose the vulnerabilities even though they just paraphrase what we identify.”

Dale makes a very valid point. The vulnerability disclosures made by security researchers is intellectual property. Some of that property belongs to people like Dale who makes their living selling cybersecurity services. Dale and others like him in the cybersecurity services industry have worked hard to establish their reputations as knowledgeable service providers. A large part of that effort includes things like his blog, his somewhat annual S4 conference, and projects like Project Basecamp. Failure to properly recognize that effort when using the publicly available fruits of his labor and expertise does him a disservice and negatively impacts on his livelihood. For a government agency like ICS-CERT to do so is particularly aggravating.

Now to be fair ICS-CERT has improved their credit-sharing efforts. Six months ago they were not even identifying the names of researchers unless the disclosures were made in a coordinated manner; Basecamp would not even have been mentioned in the alerts if it had happened six months ago. I commended the folks at ICS-CERT when they made that change and continue to maintain that it was a step in the right direction.

However, in the digital communication age, mentioning a name is not enough; a link to the information when it is provided on the web is the absolute minimum of common courtesy. In the case of ICS-CERT alerts and advisories it is even more than that; it is a valuable service to the control system community that relies on ICS-CERT for information about system vulnerabilities.

The ICS-CERT communications are at best summaries of the information on vulnerabilities and the mitigations. They are designed to be, and serve their most valuable purpose when they are digests of information. If they were detailed discourses on the subject only the most dedicated cybersecurity nerds would read them. They would not be of any real service to the community.

A cybersecurity manager or consultant can easily review these products as they are published and make a quick determination of whether or not they may be applicable to their system. But to decide what action needs to be taken in their facility in order to properly respond to the potential vulnerability these people are going to need access to much more information. The vendor will certainly provide some the necessary details; which is why ICS-CERT provides links to the vendor patches and security documentation when it is available.

But, as we have seen over the last year, the adequacy of the responses of the vendors has been less than adequate in many instances. To have the information necessary to respond to a potential vulnerability a security manager or consultant is going to have to access the vulnerability data actually developed by the security researcher. This is the real reason that ICS-CERT should be including links to the original vulnerability reports in their alerts and advisories.

And remember, most security researchers are making at least a portion of their living from these efforts. If not adequately recognized, independent security researchers might turn to portions of the market place for cybersecurity vulnerability information that would be willing to pay for 0-day exploits. We really don’t need that.

So, I urge ICS-CERT to continue to evolve their researcher disclosure policy by including links to the original information on disclosures. It would be a valuable service to the entire cybersecurity community.

Tuesday, February 21, 2012

DHS Budget Hearings

Over the weekend I had a chance to view the videos of the two hearings in the House where Secretary Napolitano provided almost 5 hours of testimony on the FY 2013 Budget Request. Both hearings were held on the 15th, the first before the Appropriations Committee and the second before the Homeland Security Committee. As is common with most of these types of hearings the bulk of the questions supported the adage that ‘all politics is local’, with most of the questions dealing with program cuts and issues in the questioner’s district.


The CFATS program was brought up in both hearings. Chairman King did mention the problems in the implementation of the program in his opening remarks (only available on video, no printed version has been posted to the Committee site), but he failed to ask a single question about the program during his question periods.

Rep. Dent (R,PA) was the only one to ask any CFATS related questions the issue during the Appropriations Committee hearing (at 1:43 into the hearing video). He asked a pro forma question about the ISCD report and the ‘path forward’ and got a generic response from the Secretary; hardly intense questioning, but thats expected in a budget hearing.

Dent also asked a question about the use of the TWIC for the CFATS personal surety program that is still under review by OMB. There was actually some minor conversation about the issue between he and Napolitano. The end result was a promise to ‘look into the matter’ by the Secretary.


The general issue of cybersecurity funding came up in both hearings, it’s a fairly warm subject (you know, not quite really hot) on the Hill right now. It was mentioned in the Secretary’s prepared testimony, but there was no specific discussion of control system related issues in her testimony or any of the questions she answered.

Moving Forward

Unfortunately, during the budget process there is only one place where either CFATS or control system security is likely to come up in the House hearing process and that is during Under Secretary Beer’s scheduled appearance before the Homeland Security Subcommittee of the Appropriations Committee. That hearing is scheduled to be held on March 1st, but we won’t be able to see it as it will be a classified (closed) hearing.

No word on the Senate side when the Senate Homeland Security Committee will be taking up the FY 2013 budget. Their hearing schedule has been unusually quiet so far this year.

Monday, February 20, 2012

ICS-CERT Makes Minor Correction to Alert

On Saturday I noted that ICS-CERT had issued nearly identical alerts for two different products from 7-Technologies. I reported a variety of similarities including a common CVE number. I should have known that was a mistake and if I had called them about it, I could have claimed ‘forcing a correction’ on ICS-CERT when they updated the 7T TERMIS alert today. The only thing that it changed was the CVE number for the vulnerability. Now the two separate programs, while have nearly identical vulnerabilities will have unique CVE numbers for them.

New Video Surveillance Book

John Honovich over at has just updated his ebook on video surveillance systems. As he did with the first edition of this ebook in 2008, he is making the book available free of charge. Why? According to his IPVM web site he is doing it for three reasons:

  • Ensure that a free, non-vendor resource is widely available that helps the community learn about critical issues.
  • Make it easier for those wanting to get started with professional surveillance systems.
  • Introduce our world leading research and PRO member service to new people.
For  security managers, particularly for ones that have a limited security background, I think that the first two reasons are the important ones. John obviously wants to promote the 3rd because that is one of the ways that his organization survives.

This book will not make you a video surveillance system integrator and it certainly won’t allow you to install your own system. What it will do is to allow you to talk intelligently with a system integrator, understand the issues involved with selecting, installing and maintaining this important class of security systems, and make an informed decision about whatever type of video surveillance system your facility actually buys.

Full Disclosure: John is one of the people that have made financial donations to this site. All such donations are appreciated, but have no impact on what I write or recommend in this blog. I am a PRO member on his site and I follow many of the interesting discussions on his group.

Sunday, February 19, 2012

S 2102 Introduced – Cybersecurity Information Sharing

Last week Sen. Feinstein (D,CA) introduce S 2102, the Cybersecurity Information Sharing Act of 2012. This bill was later incorporated into S 2105 as Title VII of that bill, so this bill will be unlikely to be acted upon separately unless S 2105 is defeated or substantially amended. Since this is one of the areas of S 2105 that I have not specifically yet discussed (because of the apparent lack of coverage of industrial control systems) I will look at the provisions of this bill and this discussion will also apply to the provisions of Title VII of S 2105.

BTW: The official version of S 2105 is now available on the GPO web site.

Positive Coverage of ICS

This bill (and by extension Title VII of S 2105) does specifically apply to industrial control systems. You have to read past all of the references to ‘information systems’ in the bulk of the bill until you get to §9(10) [§708(10 in S 2105; this is the last time that I will list S 2105 section number; deducing the remaining section numbers will be left as an exercise for the student] that provides the definition of ‘information systems’ (BTW: bill crafters it would be very nice if definitions were put at the start of a bill or title instead of towards the end). That definition reads:

The term ‘‘information system’’ means a discrete set of information resources organized for the collection, processing, maintenance, use, sharing, dissemination, or disposition of information, including communications with, or commands to, specialized systems such as industrial and process control systems [emphasis added], telephone switching and private branch exchange, and environmental control systems.

There is one minor problem with this definition. It would appear that a direct cyber-assault on a piece of control equipment (a PLC for instance) that bypasses the ‘information system’ would not be covered. Of course one could argue that unless the attack was implemented by a direct physical connection (plugging into a USB port for instance) to the PLC, the use of a wireless connection, for instance, would still be covered under this broad definition of an information system.

I particularly like the phrasing “industrial and [emphasis added] process control systems” as this would include control systems for a variety of non-industrial uses. Thus things like power transmission systems, water treatment systems, which are arguably not ‘industrial’, would be covered. In fact, control systems in medical devices, data centers and automobiles would be covered under this wording. Kudos to Sen. Feinstein’s staff for this particular wording.

If this definition of ‘information system’ had been included in §2(12) of S 2105 it would have been clear that that bill was intended to specifically cover industrial control systems. Instead the definition used there was a reference to 44 USC 3502(8) which uses the generally accepted definition of “a discrete set of information resources organized for the collection, processing, maintenance, use, sharing, dissemination, or disposition of information”.

Authority to Self-Monitor

Section 2 of this bill provides specific ‘affirmative authority’ for a ‘private entity’ to monitor, and to take protective actions on its own information systems or to contract with a 3rd party to do that monitoring for them. While this action would seem to be self-evident to ICS owners it was designed to provide legal cover to information service providers monitoring “information that is stored on, processed by, or transiting [emphasis added] such information systems for cybersecurity threats” {§2(1)}.

Section 3 allows the private entity to share the information obtained via monitoring with another private entity. Privacy restrictions on sharing personal information are included. Sharing such information may only be made to protect the ‘information system’.

This will be an area with which the civil liberties folks will probably take issue. The crafters of this bill attempted to deflect such criticism by specifying in their definition of monitoring that the authorized monitoring is “for the purpose of identifying cybersecurity threats” {§9(13)}. There are additional civil liberties protections scattered throughout the bill, but this will continue to be a sticking point for any non-ICS cybersecurity legislation.

Cybersecurity Exchanges

The bulk of the rest of this bill (and Title VII of S 2105) deals with the establishment, operation and regulation of cyber exchanges. Cyber exchanges (CE) are organizations that are established “to efficiently receive and distribute cybersecurity threat indicators” {§4(b)}. The DHS Secretary will establish, by regulation, at least one governmental CE as the lead CE. It will act as “the focal point within the Federal Government for cybersecurity information sharing among Federal entities and with non-Federal entities” {§4(c)(1)}.

The bill allows the Secretary 60 days {§4(c)(3)(A)} to name the lead CE and the bill provides {§4(c)(3)(B)}  that in the interim the National Cybersecurity and Communications Integration Center (NCCIC) will serve as the lead CE. Since the crafters of this bill specifically prohibit the creation of “additional layers of Federal bureaucracy for the receipt and disclosure of cybersecurity threat indicators” {§4(g)} it seems clear that they intend for the NCCIC to be designated the lead CE.

The bill also suggests that the Secretary consider designating as CE other current Federal Cyber Security Centers. Those centers are listed in the definition section of the bill {§9(7)} and they include:

• Department of Defense Cyber Crime Center;

• Intelligence Community Incident Response Center;

• United States Cyber Command Joint Operations Center;

• National Cyber Investigative Joint Task Force;

• National Security Agency/Central Security Service Threat Operations Center, or

• United States Computer Emergency Readiness Team (US CERT)

Observant readers will note that the Industrial Control System Cyber Emergency Response Team (ICS-CERT) is not included in the list. The list is not intended to be an exhaustive list of potential CE’s (though its oversight should certainly be corrected in any subsequent amendment of this bill or S 2105) so the Secretary could still designate ICS-CERT as a CE. Since the organization is already fulfilling many of the requirements of a CE its designation is to be expected.

The bill also allows (it does not require) the Secretary to designate one or more CE’s outside of the Federal Government. Section 2(e) provides the information that the Secretary should take into account in this decision making process. Most of these items deal with the ability to protect and share information, but the last will be the largest hurdle to overcome; the “ability of the non-Federal entity to sustain operations using entirely non-Federal sources of funding” {§2(e)(1)(E)}. This is important because no new Federal funding for CE’s is authorized in this bill.

Voluntary Disclosure

The purpose of this whole bill is to encourage the private sector to share information with the Federal government about cybersecurity threats. As such §5 of the bill is the heart and meat of the matter, it provides for the voluntary disclosure of information to CE’s, prescribes how that information may be subsequently shared, and provides non-monetary incentives for sharing such information.

The main incentive is prevention of cyber-attacks, that is a given and not addressed in the bill. All of the other incentives are actually negations of existing disincentives to such information sharing. They include

• Ensuring that the information provided is only used for cyber-protection purposes {§5(b)};

• Exemption from public disclosure under the Freedom of Information Act {§5(d)};

• Exemption from ex parte communications rules {§5(e)};

• Exemption from waiver of privilege {§5(f)};

• Provides criminal and civil liability protections {§7(a)}: and

• Provides limitations on use for regulatory enforcement purposes {§7(c)}.

Oh, and one relatively small of this section {§5(c)} part deals with information shared by the CE’s with non-Federal entities. At first glance that would seem to mean private sector, but in reality it also includes information shared with State and local governments. As such it seems to be lacking any reference to those governments’ use of supplied information for regulatory or law enforcement purposes. This is only partially corrected in the §7 references. This oversight could chill the information sharing process.

Privacy and Civil Liberties

One of the main impediments to passing a comprehensive cybersecurity bill has been developing adequate protections of privacy and civil liberties. This bill {5(g)(4)}specifically places the onus for developing detailed procedures for these protections on the Secretary of DHS. Other federal agencies that are responsible for CE’s are required {5(g)(4)(B)} to adopt the procedures developed by the Secretary. Then the Attorney General is tasked {5(g)(4)(C)}with reviewing and approving these policies and procedures. Finally, copies of the approved procedures (and any subsequent revisions) will be provided to Congress for political review.

Classified Information

One of the complaints that the private sector (and State and local governments for that matter) has had about threat information sharing of any type is that most of that information developed by the Federal government is classified and that the flow of such classified threat information is practically non-existent. Section 6 of this bill attempts to deal with that complaint.

First the bill establishes a new class of non-Federal entities called certified entities {§9(1)}(oops we’ve already used the CE acronym in this bill). First these are entities that are protected (have contracted for cybersecurity services {§9(18)}), self-protected (provide their own cybersecurity services in-house {§9(19)}) or are cybersecurity providers {§9(4)}. Next they must have, or be able to maintain a security clearance {§9(1)(A)}. Finally they must demonstrate the ability to protect and use classified cybersecurity threat indicators {§9(1)(A)}.

Since ‘protected entities’ and ‘self-protected’ entities are by definition (see referenced paragraphs above) not individuals, and security clearances are only issued to individuals, the definition of certified entities certainly needs some work. Does every member of the entity have to have a security clearance (that doesn’t even happen in DOD) or is a single cleared individual on the payroll suffice (that would be a busy bugger just keeping up with the paperwork requirements for classified documents)?

Actually §6 of the bill attempts to address some of these issues. First it makes clear that classified threat indicators are to be shared only with “a person with an appropriate security clearance to receive such cybersecurity threat indicators” {§6(a)(3)}. It also restricts the use of such shared information by a certified entity “in a manner that protects such cybersecurity threat indicators from unauthorized disclosure” {§6(a)(4)}.

This still doesn’t address industry’s complaint that few of their personnel have such clearance, they are not easy (or timely) to obtain, and they may only be needed for a single communication of threat information. The bill addresses this issue by directing the Director of National Intelligence (DNI) to develop guidelines for issuing temporary security clearances to an employee {§6(b)(1)} or a certified entity {§6(b)(2)}, or to expedite the security clearance process {§6(b)(3)}.

Not Much Affect for ICS Organizations

This bill is an interesting attempt at dealing with the information sharing requirements that will be necessary for increasing the public-private partnership necessary to prevent cyber-attacks on industrial control systems. ICS-CERT already has a pretty impressive record of information sharing and little of it would be affected materially by this bill. I’m not sure how much classified threat information ICS-CERT receives from the intelligence community so it is hard to judge how the classified information sharing provisions would affect the ICS community.

What is absolutely missing from this bill from an ICS perspective is any mention of the relationship between software and system vendors and the owner/operators of industrial control systems. The slow, incomplete, or even non-existent response of vendors to the identification of vulnerabilities inherent in their system needs to be addressed in any information sharing legislation that would have meaningful effects on the cybersecurity of industrial control systems.

Finally, one other non-federal entity needs to be added to the list of providers of cyber threat information, the independent security researcher. In the last year we have seen a remarkable increase in the vulnerability disclosures made by these hard-working and oft maligned individuals and small organizations. Their efforts need to be acknowledged and protected in the information providers provisions of this bill.

Saturday, February 18, 2012

ICS-CERT Publishes Two Nearly Identical Advisories

Yesterday ICS-CERT published two nearly identical advisories for products made by 7-Technologies; TERMIS and AQUIS. They also published an update for the Advantech Alert published on Thursday.

7-Technologies Advisories

Both advisories identify a DLL Hijacking vulnerability in the systems that would allow a moderately skilled attacker to remotely exploit these vulnerabilities with the potential for execution of arbitrary code. 7T has developed separate patches for both systems.

Interestingly the TERMIS patch was released almost a month before the AQUIS patch, but ICS-CERT is publishing both advisories at the same time (and published both on their secure server on the same date last month). I would assume that 7T did not notify ICS-CERT about the earlier patch until the second patch was also available. This was probably done because a relatively intelligent hacker would have been able to quickly realize that the TERMIS vulnerability was also present in AQUIS.

The differences between the two advisories are trivial; the name and description of the affected software and the link to the patch are just about the limit of difference. ICS-CERT even provides the same (not yet active) CVE link for both advisories.

Advantech Alert

The update to the Advantech Alert adds two additional researchers, Rios and McCorkle, to the list of security researchers responsible for identifying the 18 vulnerabilities in the BroadWin WebAccess application.

ICS-CERT Terms of Use

ICS-CERT recently changed the working in the grey box at the bottom of the first page of these alerts and advisories. As late as February 14th the wording was: “Please see the DHS Disclaimer notice, available here:”. That probably wasn’t getting much click through so it was changed on the February 15th generic ICS alert to read: “This product is provided subject to the Terms of Use as indicated here:”.

Now I know (Sarcasm Alert) that everyone diligently reads and complies with all ‘Terms of Use’ requirements on every web site that that they click through. I do want to specifically note two items in their (US-CERT) “Terms of Use” section of the US-CERT Website Policies web site; their ‘permission to link’ requirements and ‘copywrite’ notice.

Their permission to link notice is relatively short so I’ll reproduce it in its entirety here:

“You may link to the US-CERT website by using "US-CERT" as a text hyperlink, provided the following text is included on the website: "This link is provided for informational purposes only and does not represent an endorsement by or affiliation with the Department of Homeland Security (DHS)." You are not permitted to use the US-CERT or DHS wordmark, logo, seal, or icon.”

I’m sorry, that doesn’t work for me (nor I’m assuming, very many other people). So, I am hereby providing public notice that I refuse to comply with the ‘permission to link’ requirements of US-CERT. I am relatively sure that the way I provide links to documents in this blog does not lead anyone to believe that I have or am claiming any affiliation with US-CERT or ICS-CERT. Using “US-CERT” as the text base for those alerts is just plain silly, it would interfere with readers clear understanding of what I was writing, and requiring me to use it is an infringement on my freedom of speech and/or expression.

Now as to the copyright permission limitations, I have always been taught that the Federal government cannot copyright any information that it produces. Now I have no intention of commercially reproducing the alerts or such that I find on the ICS-CERT web site nor would I typically consider posting a full copy of such documents on this blog or my web site (; not much there but I do use it to publish documents from time to time). I do provide quotes from US-CERT and ICS-CERT documents from time to time, but those would be governed by the fair use doctrine in any case and I think my attribution of those quotes is adequately clear to my readers.

So, in-short, I am pretty much going to ignore the ‘Copyright Permission’ as well. But I did think that these two requirements should be made clear to the remainder of the cybersecurity community so they could make their own determination of how they wanted to deal with this situation and didn’t run afoul of the Terms of Use by accident.

Friday, February 17, 2012

New ICS-CERT Vulnerability Record Set

In the last couple of days ICS-CERT has published a generic control system alert and an advisory that sets a new record for the number of multiple vulnerabilities listed in a single control system. That advisory combines information from two different alerts published last fall along with information from at least two separate coordinated vulnerability disclosures.

Generic Control System Alert

The alert issued late Wednesday, entitled “Increasing Threat to Industrial Control Systems” combines a reiteration of the data covered in the three alert updates issued on Valentine’s Day for the Basecamp tools released by Digital Bond with information about increased interest in attacking control systems. The last includes a valuable piece of threat intelligence. The Alert explains:

“ICS-CERT has recently seen a marked increase in interest shown by a variety of malicious groups, including hacktavist and anarchist groups, toward Internet accessible ICS devices. This increased activity includes the identification of Internet facing ICS devices and the public posting of IP address to various websites. In addition, individuals from these groups have posted online requests for others to visit or access the identified device addresses.”

I have previously noted that I thought that one of the main threats to control systems at high-risk chemical attacks would be from radical environmental activist groups. Recent physical break-ins at a Duke Energy coal-fired electrical power generation facility by Greenpeace activists aimed at stopping the use of coal show an increasing trend for high-profile actions to bring public attention to their cause. Spreading such actions into the cyber sphere is certainly to be expected.

ICS-CERT is to be commended for sharing this cyber-intelligence information with the control system security community. The inclusion of a listing of generic mitigation measures that system managers can use to help protect their control systems against these kinds of attacks increases the value of the information. I would also like to suggest that owners should directly contact their system vendors to see what additional actions can be taken to protect their specific system.

Record Vulnerabilities

It looks like ICS-CERT has decided to decrease the number of advisories that it has to produce by combining information from multiple disclosure sources whenever possible. The latest example of this is yesterday’s release of an Advisory about the Advantech BroadWin Access application. This advisory addresses two earlier alerts and coordinated disclosures from apparently at least two different sources (the earlier alerts pre-date the change in policy where ICS-CERT began identifying security researchers responsible for uncoordinated disclosures). Five separate researchers are identified in this advisory.

The Advisory reports 18 separate vulnerabilities in four general categories. That breaks the recently set record of 11 vulnerabilities reported in a Siemens advisory issued just last month. The categories are:

• Cross-site scripting (XSS);

• SQL injection;

• Cross-site report forgery (CSRF); and

• Authentication issues.

The advisory notes that all of the vulnerabilities are remotely exploitable with publicly available exploits for many of them. Attackers with low to moderate skills can exploit these vulnerabilities resulting in effects ranging from a DOS to running arbitrary code.

Advantech has released an updated version of WebAccess (ver. 7.0) to address these vulnerabilities. As in the Siemens advisory ICS-CERT reports varied successes with actually mitigating the problems. They note:

• ICST, iSIGHT, and ICS-CERT have validated that the new version mitigates Vulnerabilities 1 and 5−16.

• For Vulnerabilities 2 [SQL Injection] and 3 [Cross-Site Request Forgery], the patched version fixes the issue for unauthenticated users; however, the problem still remains for nonadmin project users.

• Vulnerability 4 [Information Leakage] was not patched, because Advantech does not consider it to be a security risk.

• Neither ICS-CERT nor independent researchers have validated that the new version resolves Vulnerabilities 17 [ActiveX Buffer Overflow] and 18 [SQL Injection].

The ‘non-security’ risk designation for vulnerability 4 is interesting. ICS-CERT describes the vulnerability this way:

“An unauthenticated user can access restricted information using specific URL addresses.”

From the point of view of the vendor, I suppose that since this does not directly alter the way the system behaves, it could be considered to be a fairly minor administrative issue. From the point of view of the facility owner that restricted information could be very valuable intellectual property about their manufacturing process. To decide not to patch this vulnerability sends a very bad message to current owners and potential customers.
/* Use this with templates/template-twocol.html */