ICS-CERT Publishes ABB Advisory – ABB Declines to Fix

Earlier today the folks at DHS ICS-CERT published an advisory for a buffer overflow vulnerability in a number of components of ABB products containing the ABB WebWare Server application. The vulnerability was discovered by Billy Rios and Terry McCorkle; presumably reported via a coordinated disclosure.

According to the Advisory a ‘medium skilled’ attacker could craft an exploit for these vulnerabilities that could be executed remotely. A successful attack could result in a denial of service, escalation of privilege, or execution of arbitrary code.

The vulnerable applications are, according to ABB, “legacy products nearing the end of their life cycle that are no longer actively supported”. As a result ABB is only providing generic mitigation strategies (and not even providing a direct link to those strategies) for this vulnerability. According to the Advisory; “ABB does not intend to patch these vulnerable components” (page 3).

Every software developer sets their own standards for what constitutes the ‘end of the life cycle’ for their products and establishes their own rules for what support they will provide for such ‘obsolete’ products. ABB has drawn their line in the sand here. What remains to be seen is how many of their legacy systems will remain in use with this uncorrected vulnerability. More importantly, how many of their customers will decide that the lack of support for correcting this security vulnerability will make them look to some alternative supplier for replacement systems.

EPA Publishes Ozone Depletion Chemicals Program ICR Notice

Today the Environmental Protection Agency published a 60-day information collection request renewal notice in the Federal Register (77 FR 20384-20385)  in support of their program to eliminate the use of ozone depleting chemicals like methyl bromide. This ICR was initially approved in 1992 and most recently approved in 2009.

Today’s notice indicates that both the number of expected respondents and total burden-hours in this renewal are smaller numbers than in the previously approved ICR. The EPA explains that this is “due to the continued phaseout and decreased use of Class I controlled substances, which subsequently reduces reporting obligations” (77 FR 20385). At the current rate of change (respondents: -727; and burden hours: -227) it will take another six years or so to close out this program.

Okay, time for standard rant: This is the program to phase out the use of methyl bromide (among other chemicals) that DHS in 2007 used to justify the removal of that toxic inhalation hazard chemical from the list of DHS chemicals of concern (COI) for the CFATS program. Methyl bromide needs to be re-introduced to the Appendix A list when that list is revised in the near future.

ICS-CERT Publishes Another Wonderware Advisory and New CSET

Today the folks at DHS ICS-CERT published another advisory on Invensys Wonderware (the last one was published just last Friday) and made available an updated version of their Cyber Security Evaluation Tool (CSET).

Wonderware Advisory

The Wonderware Advisory is based upon multiple vulnerabilities reported by Terry McCorkle and Billy Rios in a coordinated disclosure. The vulnerabilities involve:

• Cross-Site Scripting;

• SQL Injection; and

• Permissions, Privileges and Access Control.

All three vulnerabilities are remotely exploitable by an attacker with a low skill level even though there is no known exploit code publicly available for these vulnerabilities. A successful attack could result in denial of service or execution of arbitrary code. A social engineering attack ‘may’ be required to exploit these vulnerabilities.

Invensys has produced software updates that can be used to mitigate these vulnerabilities. Interestingly for this advisory there is an actual link to download the update where the previous advisory provided a link to an admin publication describing what to do to mitigate the vulnerabilities. I wonder why the different approaches.

I also wish that ICS-CERT would settle on one standard method of dealing with multiple advisories on the same applications. They have done it by updating an advisory with the additional vulnerabilities (makes a certain amount of sense). In this case they went with separate advisories. I can’t figure out why they would do this two different ways. Government agencies typically like consistency.

Cyber Security Evaluation Tool v, 4.1

I wrote about the publication of version 4.0 of this program last August. As best I can tell that information is relatively current. All of the supporting documentation (the Fact Sheet and the Download instructions) for the earlier version are identical to those currently on the CSET web site. You can also still send an email to CSET@dhs.gov to obtain the program on a DVD. Oh, and finally, you can still request ICS-CERT provide on-site assistance in applying the CSET evaluation to your control system.

The only difference that is noted on the ICS-CERT web site is that this latest version of CSET now includes the capability of preparing a network diagram using MS Visio®. The diagram can be drawn in Visio® and uploaded to the application, or drawn in the CSET application and downloaded as a Visio® file. Preparing a detailed network diagram in this manner makes it much easier for CSET to analyze the unique ICS layout for the installation. It also allows the program to formulate specific questions about your system architecture to help make the analysis more complete.

As I noted in the earlier blog post on this tool, the ICS-CERT folks have provided the capability for the tool to analyze the ICS security status for high-risk chemical facilities covered under CFATS. Since ISCD has almost no industrial control system security expertise (and I am almost certainly being generous here), showing that the facility has conducted a security assessment using this CSET should certainly go a long way to convincing the Chemical Security Inspectors that the facility has assessed and addressed their RBPS (Risk-Based Performance Standard) 8 (Cyber Security) requirements.

Until ISCD gets the necessary expertise in-house to do a real ICS cybersecurity assessment (unlikely any time soon) or signs a memorandum of understanding (MOU) with ICS-CERT to have them conduct that portion of the site security plan review, this will probably be the best way to address control system security requirements within CFATS.

TSA Publishes 30-Day ICR Notice for Rail Security Program

The Transportation Security Administration published a 30-Day information collection request (ICR) notice in today’s Federal Register (77 FR 19680-19681) in support of its rail security program. This is a follow-up to the 60-day ICR notice published in January.

In my blog about that earlier notice I noted that TSA failed to explain why there was the large change in the number of respondents between this proposed submission and the currently approved ICR from 2008. That earlier ICR called for an expected 88,145 responses and a total burden of 288,945 hours at a cost of $9.4 million. The current ICR notice shows only 54,023 hours and does not list a cost nor does it list a total number of expected responses. Again there is no explanation for the change in this public document.

HR 4263 Introduced – Cyber Security

Last Tuesday Rep. Bono-Mack (R,CA) introduced HR 4263, the “Strengthening and Enhancing Cybersecurity by Using Research, Education, Information, and Technology (SECURE IT) Act of 2012. While this bill has the same title as S 2151 and the language is nearly identical for large portions of the bill, there are a large number of not so subtle differences between the two bills.

First off there are a large number of relatively wording changes between the two bills. Most of these changes are insignificant and will be of interest only to legal scholars and lawyers arguing civil cases involving cybersecurity matters.

There are a number of significant additions in this bill not found in S 2151.  They include grant funding provisions (revised § 413), minor cloud computing provisions (new § 404), the creation of a cybersecurity university-industry task force (new § 405), the establishment of requirements of cybersecurity automation and checklists for government systems (new § 414) and the establishment of an NIST cybersecurity research program (new § 415).

Grant Funding

One thing this new bill does is to provide actual continuing funding authority for a number of cybersecurity grant programs over the next three fiscal years. Section 413 is completely re-written (from the S 2151 version) and it now provides funding for:

• Computer and Network Security Research Grants [$90,000,000/year]

• Computer and Network Security Research Centers [$4,500,000/year]

• Computer and Network Security Capacity Building Grants [$19,000,000/year]

• Scientific and Advanced Technology Act Grants [$2,500,000/year]

Of course there is no mention of where the money will come from for these grants. That will have to be worked out before this bill could come to the floor under House Rules.

Industrial Control Systems

 

None of the ICS security related provisions that I have identified in S 2151 have been significantly changed in this bill. There is one additional, if very brief, mention of industrial control systems in this legislation. It is found in the new §415 in a modification of §20 of the National Institute of Standards and Technology Act where it adds new ‘Intramural Security Research’ under sub-paragraph (e) it includes “carry out research associated with improving security of industrial control systems” {§415 adds §20(e)(4)}. It’s not much, but it is something.

OMB Receives Emergency ICR from DOE on Cybersecurity Model

According to the Office of Management and Budget web site, the Department of Energy submitted an emergency information collection request (ICR) to the OMB on the same day that it was first published in the Federal Register. In fact the submission was so hurried that it did not even include the Federal Register page number (77 FR 19276-19277) for official publication of the ICR.

According to the Federal Register submission the ICR the “proposed collection will be used by the Department and electric sector owners and operators to identify best practices and potential resource allocations for cybersecurity in terms of supply chain management, information sharing, asset, change and configuration management, and risk management, among others”.

The ICR will target a limited number of participants (17 according to the OMB request) that will evaluate a proposed ‘maturity model’ that is “designed to measure the sector's cybersecurity posture and to enable utilities to make strategic investments that will increase cybersecurity throughout the electricity sector” (77 FR 19277).

While the OMB web site maintains that the Federal Register publication is a 30-day ICR notice, the actual publication requires that comments be submitted within “15 days from the date of publication” and does not (as is typically done) provide an actual date for the close of the comment period. DOE is requesting actual approval of the ICR by April 17^th, 2012. That would not give any time for review of public comments on the request.

The DOE justification for an emergency ICR request is not found in the Federal Register Notice (which does not actually say that this is an ‘emergency’ request) but it is found on the OMB web site. That site notes that:

“The Electric Sector Cybersecurity Risk Management Maturity Initiative is under development with public and private sector partners to provide this capability to the sector as soon as possible. The initiative pilot, for which the emergency ICR is being requested, will test and validate the model and assessment tool so that it can be revised and improved. The results of the pilot can then be provided to the sector as whole to help them immediately begin to identify areas of their systems and processes where investments or resources can be made or reconfigured to bolster the security of their systems further protecting the reliability of the electric grid from disruptive or costly cyber threats.”

While I certainly applaud any federal initiative that legitimately increases the cyber security of the electric grid, the justification above hardly provides any information that makes it clear why the normal publish and comment procedures for information collection requests should be circumvented to allow evaluation of this model. Furthermore, the ICR does not provide any information on what entities may be selected for this evaluation process, or the criteria used for their selection.

This is clearly a hurried, knee-jerk, and very incomplete submission that should be rejected out of hand by the OMB.

PHMSA Pipeline Excavation Damage Prevention Enforcement NPRM

The Monday Federal Register (77 FR 19800-19834) contains a notice of proposed rulemaking (NPRM) from the Pipeline and Hazardous Material Administration (PHMSA) outlining proposed rules for the evaluation of State pipeline excavation damage prevention enforcement programs and establishing the process by which PHMSA will enforce such programs in States with inadequate protections in place.

According to the NPRM Objective this rulemaking is required by the Pipeline Inspection, Protection, Enforcement and Safety Act of 2006 (PIPES Act) and must be in place before PHMSA can “conduct an administrative enforcement proceeding against an excavator for violating Federal excavation standards” (77 FR 19801).

The NPRM notes that, while all 50 states have pipeline damage prevention laws on the books, no two laws are identical in their provisions. PHMSA has provided a summary of the provisions of each of the individual state laws on their web site.

The PIPES Act provides authority to the Secretary of Transportation to take civil enforcement actions against excavators. Again, this authority may only be exercised if PHMSA determines that the State enforcement program are inadequate. The actions that can trigger DOT civil enforcement proceedings include:

• Fail to use the one-call notification system;

• Disregard location information or markings; or

• Fail to report excavation damage to the pipeline owner or operator.

This NPRM proposes to establish:

• The criteria and procedures to be used to determine the adequacy of state pipeline excavation damage enforcement programs;

• An administrative process for states to contest notices of inadequacy;

• The Federal excavation requirements PHMSA will enforce in states with inadequate enforcement programs; and

• The adjudication process for administrative enforcement proceedings against excavators.

PHMSA is soliciting public comments on this NPRM. Such comments may be submitted via the Federal eRulemaking Portal (www.regulations.gov; Docket # PHMSA-2009-0192). Comments must be submitted by June 1, 2012.