Wednesday, April 30, 2014

Another Information-Sharing Draft Bill

There was a short article over on the Monday about a draft Senate bill addressing information sharing with respect to cybersecurity. The editors were kind enough to share a link to the possible proposed legislation that is being crafted by Sen. Feinstein (D,CA) and Sen. Chambliss (R,GA).

It is way too early in the process to delve too far into this bill as it is way early in the legislative process and may die without being introduced. Having said that, there are some interesting provisions being considered. Before going into those I must warn readers that this is at heart an IT bill with no mention of control systems and I want to remind readers that Senate cybersecurity bills normally die with even less action than in the House.

There is the definition of the term ‘malicious reconnaissance’ {§2(15)} that is an apparent attempt to deal with the separation of cyber-attacks from the mere act of unauthorized access of a system. This combined with the reference to First Amendment protections in the definition of ‘cybersecurity threat’ would seem to protect political hacking of a system for information gathering purposes.

The draft bill would provide limitations on the government use of information voluntarily shared with the Federal government. Those limitations would include the prohibition of:

• Public disclosure under Federal, State and local disclosure laws;
• Use in regulatory actions;
• Use in criminal prosecutions (without prior written consent of original discloser).

It would provide anti-trust exemptions for cybersecurity information sharing between private entities. This would address the issue raised by recent ephemeral DOJ opinions about the non-applicability of anti-trust laws.

Finally, I must repeat my cautionary statement about the potential for this bill to move forward in the Senate. There have been many cybersecurity bills discussed in the Senate that were never introduced. Few of those that have been introduced ever saw any Committee action and none have made it to the floor for a vote. This is still an interesting IT security bill.

OMB Announces Approval of DOD Counterfeit Electronics Rule

Yesterday the OMB’s Office of Information and Regulatory Affairs (OIRA) announced that it had approved DOD’s final rule amending the Defense Federal Acquisition Regulation Supplement (DFARS) to partially address the Congressional requirements (§818, PL 112-81) concerning counterfeit electronic parts. The NPRM for this rule was published last May (78 FR 28780-28785).

The announced approval was ‘consistent without change’ so it should not take long (possibly this week) for this final rule to appear in the Federal Register.

Since this is a FARS regulation and I don’t have a background in contracting matters, I doubt that I will cover this rule (I did not mention the NPRM). I mention this here, however, because DOD’s lead in handling counterfeit electronic parts may lead to similar actions in industry in general.

Tuesday, April 29, 2014

ICS-CERT Publishes 2 HeartBleed Updates and an Advisory

This afternoon the DHS ICS-CERT published updates on a Siemens HeartBleed Advisory, an update of their SA Alert on HeartBleed and one new advisory for an Ecava information disclosure vulnerability.

HeartBleed Updates

My followers on TWITTER® already heard about the Siemens update last Friday morning when Siemens @ProductCert tweeted about the publication of their updated HeartBleed advisory that included notification that their WinCC product now has an update available to fix the HeartBleed bug in that system.

ICS-CERT published their late update of the HeartBleed advisory that they issued on April 15th. The ICS-CERT Situational Awareness Alert was updated to show the new Siemens status. It also adds two new affected industrial control system notifications, one for ABB (Relion 650 series Ver. 1.3.0) and one for Digi (ConnectPort LTS, ConnectPort X2e, Digi Embedded Linux, and Wireless Vehicle Bus Adapter). Separate advisories are in the works. The links above are for the vendor notices.

The ABB mitigation measures are still under development and the Digi updates may already be available (the document was published on 4-18-14 with an availability date for the fix of 4-21-14). Digi is making the remote update service for remote devices available free of charge for 30 days.

ICS-CERT also added a list of Digi devices to the list of unaffected ICS services. This was also found on the Digi web site link identified above.

Ecava Advisory

This advisory reports on an information disclosure vulnerability on the Ecava IntegraXOR product that was reported by Andrea Micalizzi, aka rgod, in a coordinated disclosure via the Zero Day Initiative. Ecava has produced a new version that mitigates the vulnerability, but there is no indication in the advisory that Micalizzi has verified the efficacy of the fix.

ICS-CERT reports that a relatively unskilled attacker could remotely exploit this vulnerability to obtain clear text administrative credentials and own the system.

The Ecava vulnerability note provides additional mitigation measures that can be employed to mitigate the vulnerability until the patch is put into place. They note that since the complete project URL is need to exploit this vulnerability, owner/operators should avoid publication of the full URL. They also recommend avoiding the use of the default port number.

NARA Announces Meeting of NISPPAC

Today the National Archives and Records Administration (NARA) published a meeting notice in the Federal Register (79 FR 24019-24020) for a June 19th meeting of the National Industrial Security Program Policy Advisory Committee (NISPPAC). According to the notice the agenda includes a discussion of “National Industrial Security Program policy matters”.

The meeting is going to be held at the Gaylord National Resort in Prince George's Exhibition Hall B and due to “due to space limitations and access procedures” advanced registration is required? That might make some sense if sensitive matters were going to be discussed, but the notice clearly states that this meeting is ‘open to the public’.

And really: “The purpose of this meeting is to discuss National Industrial Security Program policy matters.” Does this fulfill the requirements of 41 CFR 02-3.150 to provide a “summary of the agenda, and/or topics to be discussed”? Of course NISPPAC is going to discuss NISP policy matters, but which ones?

Now NARA is to be commended for giving a month and a half notice instead of just the required 15 days, but is that just an effort to bury this meeting notice? I’m sorry but something smells here.

BTW: 41 CFR 102-3 addresses the management of Federal Advisory Committees not the long outdated 41 CFR 101-6.10 referenced in the notice. More obfuscation?

Bills Introduced – 4-28-14

House and Senate are both back in session after their two week Easter Recess and introduced 27 bills. Only one of those may be of specific interest to readers of this blog:

HR 4500 Latest Title: To improve the management of cyber and information technology ranges and facilities of the Department of Defense, and for other purposes. Sponsor: Rep Kilmer, Derek (D,WA)

Cyber warfare is not exactly cybersecurity, but this bill may contain some cybersecurity provisions of interest. We will just have to wait and see what it contains when it becomes available.

Homeland Security Committee Publishes CFATS Substitute Language

Today the Homeland Security Committee added a note to their web page for their Wednesday markup hearing (that I discussed this weekend) reporting that Rep. Meehan (R,PA) will be offering another set of substitute language for HR 4007. Since there is not an official version of the bill as marked up by Meehan’s Subcommittee it is difficult to sort out the ‘small’ changes in the language. The big changes are easy to see.

Personnel Surety

This bill continues to try to deal with industry complaints about the personnel surety program under development by DHS. The wording gets more confusing and it seems the only intent of the new wording is to eliminate the personnel surety program. The legislation spends much more time explaining what DHS cannot do than it does defining what should be accomplished by the program.

The one positive new addition in this portion of the bill is a requirement for DHS to “to expedite the development of a common credential that screens against the terrorist screening database on a recurrent basis and meets all other screening requirements of this title” §2101(d)(3)(C)(i). Unfortunately this is a far cry from a legislative mandate for a CFATS equivalent of the MTSA TWIC. Only a clear legislative mandate will make this a program that will be accepted by the entire chemical industry.

One of the objections that the Democrats have always had with all of the personnel surety programs discussed to date for CFATS is the lack of a redress process for personnel that believe they have been incorrectly identified as having terrorist ties. New language has been added to this bill to address that concern, kind of. The new language requires the Secretary to establish a personnel surety program that provides redress to an individual “who believes that the personally identifiable information submitted to the Department for such vetting by a covered chemical facility, or its designated representative, was inaccurate” §2101(d)(3)(A)(iii). This completely ignores that possibility of being incorrectly identified as having terrorist ties due to an error on the part of the Government.

Rail Facility Exemption

DHS has long maintained that the responsibility for regulating the chemical security of rail facilities lies with TSA. This was specifically addressed in the pre-amble to the CFATS interim final rule in the Federal Register (72 FR 17688-17745) (see page 17699 for that discussion). Apparently, someone has had some concerns with the final sentence in that discussion:

“DHS may in the future, however, re-evaluate the coverage of railroads, and would issue a rulemaking to consider the matter.”

In any case §2104(c)(1), Rail Transit, makes it explicitly clear that any rail facilities regulated under 49 CFR 1580 will not be affected by the new CFATS regulation. Those facilities would certainly include designated ‘rail secure areas’ for all railroad hazmat shippers handling rail sensitive materials {§1580.107(a)(2)} and for all railroad receivers in high threat urban areas receiving rail sensitive materials {§1580.107(a)(2)}.  

Then §2104(c)(2) goes one step further and exempts all railroad facilities as defined in 1580.3 as being exempt from requirements to submit a Top Screen. That definition states:

Rail facility means a location at which rail cargo or infrastructure assets are stored, cargo is transferred between conveyances and/or modes of transportation, where transportation command and control operations are performed, or maintenance operations are performed. The term also includes, but is not limited to, passenger stations and terminals, rail yards, crew management centers, dispatching centers, transportation terminals and stations, fueling centers, and telecommunication centers.”

This would specifically exempt most crude oil train loading facilities from CFATS regulations. This is even though the security at those facilities is not regulated by TSA since crude oil is not a rail sensitive material as defined in §1580.100(b).

Other Exemptions Removed

All language exempting other facilities from the CFATS coverage has been removed from this bill. This means that the following facilities would be required to submit a Top Screen to DHS if they had one or more of the 300+ DHS chemicals of interest (COI) listed in Appendix A to 6 CFR Part 27 at or above the screening threshold quantity set for that chemical in that Appendix:

• MTSA covered facilities;
• Public water systems;
• Treatment works;
• DOD owned facilities; and
• NRC regulated facilities

The language maintaining the current CFATS statutory exemption for these facilities had been found in the definition of ‘Covered Facility’ in what is now §2101(f)(1). There is no trace of that language there, or anywhere else in the bill. This is certainly a sweeping addition of responsibility for the folks at the DHS Infrastructure Security Compliance Division (ISCD). It is particularly surprising given the new exemption for rail facilities that are not covered by any security scheme.

Still Missing

This bill is still missing any language that would allow it to be considered successfully in the Senate. There is no mention of employee participation or inherently safer technology. Without even the most stripped down language addressing these areas there is no way that this bill, no matter how quickly it is passed in the House, would ever begin to see debate in the Senate, much less pass a cloture vote.

Democrats will certainly offer such language in Wednesday’s hearing. It will be interesting to see if they can craft language that will be acceptable to the Republican majority on the panel. If they cannot, then this bill will be effectively dead.

Monday, April 28, 2014

Energy and Commerce Committee Provides TSCA Witness Testimony

Today the House Energy and Commerc Committee [corrected committee 4-28-14 7:55 CDT] published the witness testimony for tomorrow’s hearing on the draft Chemicals in Commerce act. There is also a new witness added since I did my weekly Congressional Hearing post on Saturday; James Jones, Assistant Administrator, Office of Chemical Safety and Pollution Prevention, US EPA.

I probably will not have a chance to review the testimony or the revised bill before the weekend; happy reading.

HR 4435 Introduced – NDA FY 2015

As I mentioned earlier Rep. McKeon (R,CA) recently introduced HR 4435, National Defense Authorization Act for Fiscal Year 2015 (NDA FY 2015); a copy of which is finally available from the Government Printing Office.

Surprisingly I can find no mention of cybersecurity or cyber warfare provisions in the bill. I expect that this will be changed as the bill goes through the markup process and proceeds to the floor of the House.

This is a ‘must pass’ bill that will almost certainly reach the floor of the House well before the summer recess.

Saturday, April 26, 2014

Congressional Hearings – Week of 4-27-14

Congress comes back to Washington after its two week Easter Recess with a full slate of hearing. Three House hearings and one Senate hearing this week will be of specific interest to readers of this blog even though one of those is a closed hearing about which we will never know the details. The cybersecurity budget, TSCA reform, CFATS authorization and TSA oversight are the topics of interest. Oh, and the DOD FY 2015 authorization bill (which may contain cybersecurity language) is wending its way through multiple subcommittees this week.

Cybersecurity Budget

The Homeland Security Subcommittee of the House Appropriations Committee will hold a closed hearing on Tuesday to look at the cybersecurity budget for DHS. The three witnesses all come from the National Protection and Programs Directorate which has primary responsibility for the DHS cybersecurity mission both within the government and supporting critical infrastructure. This meeting was originally scheduled for April 8th.

TSCA Reform

The Subcommittee on Environment and the Economy of the House Energy and Commerce Committee will hold another hearing on the Chemicals in Commerce Act (no bill number yet as it hasn’t actually been introduced) on Tuesday. A new draft version of the bill will be considered; the Committee has thoughtfully provided a ‘redlined’ version showing changes from the previous public draft.

Witnesses for this hearing will include:

• Calvin Dooley, American Chemistry Council;
• Beth Bosley, Society of Chemical Manufacturers and Affiliates;
• Mark Greenwood, Greenwood Environmental Counsel;
• Len Sauers, Proctor & Gamble Company;
• Steven Goldberg, BASF;
• Andy Igrejas, Safer Chemicals and Healthy Families;
• Michael Moore, National Conference of State Legislatures 

CFATS Reauthorization

The House Homeland Security Committee will be holding a markup hearing on Wednesday looking at three bills; two of which are of potential interest to readers of this blog. They are HR 3283 (Integrated Public Alert and Warning System Modernization Act of 2013) and HR 4007 (Chemical Facility Anti-Terrorism Standards Program Authorization and Accountability Act of 2014).

No amendments are currently listed for the CFATS bill and substitute language is being offered for the public warning system bill. Both bills were previously marked up (HR 3283 and HR 4007) but the Committee web site does not provide copies of the version of HR 4007 that will actually be considered by the Committee (it doesn’t’ provide a marked-up copy of HR 3283 either but the substitute language makes that a moot point).

As mentioned earlier HR 4007 appears to be on the fast track in the Committee. I would not be surprised to see this on the House floor next month.

TSA Oversight

The Senate Commerce, Science and Transportation Committee will conduct an oversight hearing on the DHS Transportation Security Administration on Wednesday. As is typical for this type hearing the major focus will be on air passenger security issues (including airport perimeter security given recent incidents) but there is a good chance that rail and truck security issues will be raised, including some long over due rulemakings. Administrator Pistole is the only scheduled witness.

DOD FY 2015 Authorization

The House Armed Services Committee will look at HR 4435, the DOD FY 2015 authorization bill this week in a series of subcommittee hearings on Wednesday and Thursday. I don’t see any one hearing that will specifically address cybersecurity issues, so I’ll just list the hearings.

Floor Actions

There is nothing currently scheduled for consideration on the floor of the House this week of specific interest to readers of this blog. Who knows what Sen. Reid (D,NV) will bring to the floor of the Senate beyond the expected series of nomination considerations.

Friday, April 25, 2014

CG Seeking CTAC Applicants

Today DHS posted a notice in the Federal Register (79 FR 23003-23004) announcing that the Coast Guard is seeking applicants for membership on the Chemical Transportation Advisory Committee (CTAC). CTAC provides advice and consultation to the Coast Guard's Marine Safety and Environmental Protection Directorate with respect to the water transportation of hazardous materials in bulk. 

The notice explains that applicants should have experience in:

• Chemical manufacturing;
• Marine handling or transportation of chemicals;
• Vessel design and construction;
• Marine safety or security; or
• Marine environmental protection

CTAC members are volunteers serving at their own expense, including travel and per diem. CTAC's membership includes six vessel operators, five chemical shippers, five environmental response sector representatives, and five environmental safety and health officials.  The remaining members represent non-profit classification societies. The notice does not explain which of positions are included in the 10 positions for which they are seeking applicants.

Applicants may submit their applications via email ( by June 9th, 2014. Applications should include a a cover letter and resume and identify the position for which the application is being made.

Personal Note to Anonymous

I have not posted your comment to an older post out of a concern about some of the terms you used to describe the vendor. I am not in a position to verify their depth of despicability that you describe, though I have heard similar but significantly more moderately worded comments from others that I respect and trust.

Since I don’t know you or your background and don’t have personal knowledge to support your allegations I am reluctant to expose myself to legal actions by posting your comments. If you have some supporting evidence that you would be willing to share (even privately) I would be willing to reconsider.

Thursday, April 24, 2014

ICS-CERT Publishes 4 Advisories – Only 1 HeartBleed

Today the DHS ICS-CERT published four advisories for vulnerabilities in industrial control systems. The included vulnerabilities from InduSoft, Festo, Siemens and Certec. Only one advisory deals with HeartBleed. The advisory of note shows that ICS-CERT can get upset with vendor inaction.

InduSoft Advisory

This advisory describes a path traversal vulnerability in the InduSoft Web Studio application. It was reported by John Leitch in a coordinated disclosure through the Zero Day Initiative (ZDI). This advisory was originally released on the US-CERT secure portal on April 17th. A patch is available, but there is no indication that its efficacy has been evaluated by the researcher.

ICS-CERT reports that a relatively low skilled attacker could remotely exploit this vulnerability to gain further access that would allow arbitrary code execution.

Festo Advisory

This advisory describes multiple vulnerabilities in the Festo PLC. The vulnerabilities were reported by Reid Wightman of IOActive in a coordinated disclosure. ICS-CERT reports that Festo has opted to not address these vulnerabilities. The vulnerabilities include:

• Improper authentication (FTP Backdoor), CVE-2014-0760;
• Improper authentication (two unauthenticated ports), CVE-2014-0769;
• Improper access controls (using outdated CoDeSys runtime module), CVE-2012-6068; and
• Directory traversal (same outdated CoDeSys module), CVE-2012-6069

ICS-CERT reports that a relatively low skilled attacker could use publicly available code to remotely exploit these vulnerabilities.

I want to commend ICS-CERT for getting angry in one of their advisories, this is a situation that certainly appears to deserve an adversarial response. I think the best statement from ICS-CERT can be found in the Overview section of the Advisory:

“This advisory is being published to alert critical infrastructure asset owners of the risk of using this equipment [emphasis added] and for them to increase compensating measures if possible.”

I read Reid’s TWEET® about this advisory earlier today and was kind of surprised at his reaction. I am not surprised now. Again, kudos to ICS-CERT for reacting to this callous disregard for customer security. It will be interesting to see if there is a change in attitude Esslingen am Neckar, FRG.

Siemens Advisory

This advisory addresses two vulnerabilities in the Siemens SIMATIC S7-1200 PLC family. This is a mix of self-reported and researcher reported vulnerabilities. The researchers from OpenSource Training are Ralf Spenneberg, Hendrik Schwartke, and Maik Brüggeman. Siemens reports that they have produced a new version that mitigates the vulnerabilities though there is no indication that the researchers have validated the efficacy of the fix. The vulnerabilities include:

• Cross site scripting, CVE-2014-2908; and
• Improper neutralization of CRLF sequences, CVE-2014-2909

ICS-CERT reports that it would take a skilled attacker with physical access gaining the assistance of an authorized user to exploit these vulnerabilities. A successful exploit could result in a DoS attack.

Certec Advisory

This advisory is the one that was foretold in yesterday’s blog post about ICS-CERT HeartBleed publications. The Certec atvise SCADA product is susceptible to the HeartBleed bug. An update that includes a newer version of the OpenSSL software has been made available.

Wednesday, April 23, 2014

ICS-CERT Updates HeartBleed Alert

This afternoon the DHS ICS-CERT updated their ‘Situational Awareness Alert for OpenSSL Vulnerability’, commonly referred to as the HeartBleed bug. The information added to date is the most extensive to date and includes:

• An advance notice about an ICS-CERT Advisory for HeartBleed in Atvise;
• An extensive (but probably not exhaustive) list of ICS related applications and devices that have been determined not to be affected by HeartBleed;
• A reminder that while older versions of OpenSSL may not be affected by HeartBleed, they do have their own known vulnerabilities; and
• A reminder that the use of SHODAN and other search engines may make it relatively easy to find ICS components that are susceptible to HeartBleed.


ICS-CERT took the unusual step of announcing that an “ICS-CERT advisory [was] coming soon” for the Certec atvise scada products. It provides a link to the atvise notice about the vulnerability. That stilted notice (okay I lived in Berlin for 7 years and my German syntax was way worse at its best than this English language notice) claims that while some versions of their products have the HeartBleed bug “but wasn't affected by known attacks”. Now they “face new kinds of attacks found nearly daily”. I certainly look forward to hearing more about the ‘new kinds of attacks’ on a SCADA system.

Atvise does have a patch available for the vulnerable OpenSSL components.

Systems Not Affected

There is a fairly long list of systems here that are not affected by the HeartBleed bug because either they ‘don’t use OpenSSL’ or ‘don’t use an affected version of OpenSSL’. Unfortunately there is not an actual control system or component on the list. They are all either communications tools or security tools. This list will be invaluable to a security manager or integrator. It does let them concentrate of other parts of their systems, but it is strangely unhelpful for control systems.

The lack of any control system applications or devices on the list is more than a little disconcerting. Two weeks into the public discussion of HeartBleed and we have two vendors (Siemens and atvise) self-identifying their infection with this bug, but no one saying that they are infection free. At this point I think that any ICS system that has not identified itself as being free of HeartBleed should, for the sake of safety and security, must be considered to be infected until proven otherwise.

Other OpenSSL Vulnerabilities

There have been any number of system vendors that have bragged that their system uses an older version of OpenSSL that is not affected by HeartBleed. Today’s update reminds people that earlier versions of the software have their own problems that should not be ignored. The Update provides a link to the OpenSSL web page that lists a large number of reported vulnerabilities in the system. If all of the patches and upgrades have not been applied to earlier versions, there may be more serious problems than HeartBleed.

SHODAN and Others

Any time you have a widespread vulnerability like HeartBleed it is valuable to be reminded that search engines like SHODAN make it relative easy for people to find vulnerable systems. That combined with the wide spread availability of automated attack and exploit tools makes it easier for both the opportunistic and targeted attackers to gain access to improperly secured systems.

ICS-CERT notes in the Alert that: “As tools and adversary capabilities advance, ICS-CERT expects that exposed systems will be more effectively discovered, and targeted.” They also remind owner/operators that they can use many of the same tools to discover if their systems are vulnerable. Knowing that their systems are accessible and vulnerable should allow owners to better protect their systems.

ISCD Updates CFATS Knowledge Center – 04-23-14

Today the DHS Infrastructure Security Compliance Division (ISCD) made a minor revision to one of the frequently asked questions (FAQ) on the CFATS Knowledge Center. The change was so small that there was no mention of the revision in the ‘Latest News’ section of the page.

FAQ #329 (originally published in May of 2009 and revised last in June 2012) had a typographical error in the actual question. It used to read:

What is the Environmental Protection AgencyÂ’s (EPA) RMP*Comp?

It now reads:

What is the Environmental Protection Agency's (EPA) RMP*Comp?

This is certainly a very minor error correction, but it was an error nonetheless and ISCD is to be commended for their diligence. To be fair to ISCD I did not report (nor probably notice) the typo when I reported on the FAQ changes made that day, but my records show that it was certainly there.

EPA Extends Use of Methyl Bromide Product

Today the Environmental Protection Agency (EPA) published a notice in the Federal Register (79 FR 22669 – 22670) amending a pesticide cancellation order from May 20th, 2011 (76 FR 29238 – 29240) allowing for the use of existing stocks of two methyl bromide products on golf courses. The products were produced by Cardinal Professional Products and Trical, Inc; both of Hollister, CA.

Golf Course Soil Fumigant

The original order allowed for the use of existing stocks through December 31st, 2013. In January these two manufacturers notified the EPA that they still had stocks of the material and requested an extension of the allowed sale and allowed use dates. Neither of the two letters is currently posted to the docket at (Docket # EPA-HQ-OPP-2005-0123) so it is not clear how much of the two products is actually still available for use.

In today’s modification of that order the EPA allows:

• The sale and distribution of existing stocks of the affected products until November 30, 2014;
• The use of existing stocks of the products purchased prior to April 30, 2014 according to the directions on the label for the product until those stocks are exhausted; and
• The use of existing stocks that were purchased after April 30, 2014 only on golf courses according to the directions for that use on the label for the product until those stocks are exhausted.

Methyl Bromide and CFATS

Insert standard diatribe about methyl bromide being removed from list of DHS chemicals of interest (COI) because methyl bromide was ‘being phased out by EPA’.

It is not clear if this order revision would have any practical effect on chemical security rules under the CFATS program. Since we don’t currently know how much of the products the two organizations have on hand we don’t know if they would have enough (10,000 lb minimum if the standard toxic release chemical standard was used) to be required to submit a Top Screen to DHS. Certainly if they are currently covered under the CFATS program because of the possession of other, actually listed COI, this order will not affect their status.

Golf courses that use these two products will almost certainly not have anywhere near 10,000 lbs of this material on hand, so they would not have (if methyl bromide were a listed COI) to be concerned with CFATS reporting requirements.

Monday, April 21, 2014

Volunteer for CDCI Status

Last week I wrote about the notice published by DHS National Protection and Programs Directorate (NPPD) concerning the notifications made to organizations and facilities that have been designated Cyber Dependent Critical Infrastructure (CDCI). In that post I mentioned in passing that the request for reconsideration process outlined in that notice could be used by facilities that wished to be so designated. Today I want to look at why a facility might want to make such a request.

Program Benefits

The CDCI program is part of the President’s executive order on Improving Critical Infrastructure Cybersecurity (EO 13636) and is identified in §9 of that document. Actually, §9 only outlines the procedures for designating facilities as CDCI. The Notice published last week provides a brief listing of the positive impacts associated with the CDCI designation:

● Ability to request expedited processing through the DHS Private Sector Clearance Program, which may provide access to classified government cybersecurity threat information as appropriate;
● May be prioritized for routine and incident-driven cyber technical assistance activities offered by DHS and other agencies; and
● May receive priority in gaining access to Federal resources and programs to enhance the security and resilience of critical infrastructure against cybersecurity threats.

It is interesting to note that the Notice never uses the word ‘shall’ in the paragraph describing the positive impacts of the CDCI designation. The closest that it comes is in the final sentence:

“As Federal government resources and programs develop and improve to enhance the security and resilience of critical infrastructure against cybersecurity threats, cyber-dependent critical infrastructure will be a continued priority.”

There is nothing in the recent Notice or in §9 of the Executive Order that indicates that there are any specific requirements levied on a facility as a result of being designated as CDCI. The closest the Notice comes is a brief statement that the CDCI designees will be “encouraged to participate in the National Institute of Standards and Technology (NIST) cybersecurity framework for critical infrastructure”.

CSF Mandate

While the Administration has been very careful to talk about the voluntary nature of the cybersecurity framework (CSF) that was developed by NIST, the President made clear in the Executive Order that that there was the distinct possibility that certain organizations might be required to adopt the CSF. Specifically mentioned (but certainly not limited to) in §10(a) of the EO are the critical infrastructure identified under §9 of the order (the CDCI).

Agencies are required to determine which CDCI they currently have adequate regulatory authority to “establish requirements based upon the Cybersecurity Framework to sufficiently address current and projected cyber risks to critical infrastructure”. Where that authority does not currently exist, the EO directs the agencies to identify “any additional authority required”. The clear implication is that the implementation of the CSF will be required for identified critical infrastructure facilities.

Agencies have until May 16th, 2014, to make a determination if they currently have authority to mandate CSF implementation or make recommendations as to what additional authorities are necessary to require implementation. At this point there is no telling how long it might take to implement CSF requirements if the authority currently exists; it will depend on if a new rulemaking is required or just the publication of a notice. New authority will typically require Congressional action, which could take anywhere from years to decades to acquire.

There is also nothing that says that only CDCI will be required to implement the CSF. It will probably be easier for most regulatory agencies to require all existing critical infrastructure installations to implement the CSF than just a subset of the currently identified CI that has been selected by another agency of DHS. Either that, or agencies are going to have to come up with a separate designation process with criteria that are unique to their sector. That will just add an additional layer of complexity to the process; slowing it down even more.

Cost Benefit Analysis

Critical infrastructure facilities that have not been designated as CDCI have a choice to accept that lack of designation or request reconsideration of that decision. Such facilities will have to weigh the potential benefits vs the potential costs of the CDCI status to determine if they want to go through the reconsideration process.

Right now it looks as if the only ‘costs’ associated with the designation will be the potential requirement at some future time of implementing the CSF. For facilities that are already implementing or planning on implementing the CSF would not really a cost associated with the decision to request a positive reconsideration. Other facilities will certainly view a CSF mandate as a cost if and when the administrative processes for requiring the implementation are completed.

The other question that has to be taken into account in this cost benefit analysis is when the cost may be incurred. Since there is only a future possibility (a fairly high probability in my estimate) of a CSF implementation requirement, organizations might significantly discount that potential cost. This is particularly true because the EO calls for an annual review of the designation of CDCI; a future designation may come at a time when the potential cost is fully realized with CSF implementation regulations already in place.

Staying off the Bureaucratic Radar

There is one other downside cost that some organizations may perceive arising from the submission of a request for reconsideration; that of placing themselves on the DHS radar.  Organizations, particularly smaller organizations, that may not otherwise attract the notice of potential future regulators at DHS may want to avoid attracting the attention of Federal agencies. This is particularly true in this era of the intended increase of information sharing within the Federal bureaucracy.

On the other hand, small organizations are unlikely to have extensive in-house cybersecurity resources. Leveraging some of the assistance that may be provided by the CDCI program may give installations a significant boost in the cybersecurity realm. This may provide a competitive advantage in the market place, or at least reduce the advantage enjoyed by larger competitors with more developed internal cybersecurity capabilities.

Quick Decision
With the May 15th deadline for requesting reconsideration fast approaching, organizations are going to have to make a quick decision. Having said that; this is an annual process with a fairly high certainty that the selection criteria will almost certainly change somewhat in the next go around. Failure to file a request for reconsideration by the deadline does not mean that an organization will be kept out of the program (or be forced to remain in the program) in perpetuity.

What is not clear from last week’s Notice, however, is when the next round of designations will be made. The current list of CDCI facilities was initially provided to the President in July of last year, but it is not clear when the facilities were actually designated as CDCI. I would assume that the program was officially stood up in the last couple of months and that we should expect to see the next annual notice of the reconsideration period about this time next year.

In any case, if an organization wishes to avail themselves of the potential benefits of the CDCI program, it probably makes sense to take advantage of the current reconsideration process by submitting their request before the May 15th deadline.

Friday, April 18, 2014

Reader Questions – CSF Notifications

Yesterday I had two interesting questions posed to me about my post on the DHS designations of cyber dependent critical infrastructure.

First on TWITTER® from Aristotle Tzafalias - “Know of any non ‘Cyber dependent’ (as defined in prev) CI?”

And then on my blog from an anonymous reader - “Any thoughts on what sectors (and representative companies) make up the greatest representation?”

Both are important questions for homeland security reasons and I won’t be able to answer either definitively because DHS will not be disclosing either their list of ‘Critical Infrastructure’ facilities nor of their ‘Cyber Dependent Critical Infrastructure’ (CDCI) facilities for security reasons. That won’t, of course, stop me from offering my thoughts on the matter.

Critical Infrastructure

There are a number of variations of the basic definition of ‘critical infrastructure’ that are in current use. To make things easy let’s stick with the one found in §2 of the President’s executive order on Improving Critical Infrastructure Cybersecurity (EO 13636):

“As used in this order, the term critical infrastructure means systems and assets, whether physical or virtual, so vital to the United States that the incapacity or destruction of such systems and assets would have a debilitating impact on security, national economic security, national public health or safety, or any combination of those matters.”

With the large number of undefined terms in that sentence it is obvious that there is a wide leeway for determining what is or is not ‘critical infrastructure’. In the narrowest sense I can think of only a single entity, the New York Stock Exchange, whose incapacity or destruction would have a debilitating effect on national economic security.

If we look at ‘systems’ however, there are a much wider variety of systems that would fit the bill. These could include the electric grid, fuel distribution systems, communications systems. In fact, the President has identified 16 critical infrastructure sectors of the economy that would meet a broad definition of critical infrastructure. Again, it is hard to imagine that the failure of any single entity within those sectors would meet the definition of critical infrastructure by themselves, but a limited number of individual failures within a sector could certainly have debilitating effects on the national economy or security.

I think that a reasonable supposition about how DHS has gone about determining which facilities are to be considered critical infrastructure would be those facilities that, if more than a couple failed at about the same time, there would be debilitating consequences for the national security or national economy. I think that most reasonable people would agree that this type of methodology would be the most usable way of designating critical infrastructure.

Cyber Dependent Critical Infrastructure

Aristotle raised an interesting question in his TWEET®; in today’s age isn’t everyone ‘cyber dependent’? To a certain extent this is true, but some sectors rely on cyber-systems more heavily than others. The ‘Information Technology Sector’ certainly relies more on their computers than does the ‘Dams Sector’, but no sector could long survive with their various electronic systems not functioning.

Using the broadest interpretation of the definition provided in yesterday’s Federal Register notice I would be hard pressed to think of any organization that would not be considered ‘cyber dependent’. And if DHS used that broad sweep to include all critical infrastructure, then the whole point of the exercise was lost. Section 9(a) of the EO required DHS to “use a risk-based approach to identify critical infrastructure where a cybersecurity incident could reasonably result in catastrophic regional or national effects on public health or safety, economic security, or national security” [emphasis added].

So, instead of a complete loss of computer systems, DHS should have been looking at more limited incidents at these facilities that could result in ‘catastrophic’ effects. To be sure this would be a much more difficult standard to parse as DHS does not have a lot of internal information about most of these organizations and their systems. And again, even considering potential regional effects, there are very few facilities where a single cyber incident would cause catastrophic effects, so we should clearly expect that DHS would consider facilities where just a few related facilities affected by similar and concurrent attacks would cause catastrophic effects.

Now in my opinion, you are looking at just three types of facilities, the national stock exchanges, the electrical distribution system and fuel distribution pipelines. The remaining sectors have too much redundancy to be catastrophically disrupted by any reasonable set of cyber incidents. There could be economic disruptions in all sectors, but few that would even approach catastrophic on a regional or national basis.

Chemical Catastrophes

It might seem strange that I do not include the chemical sector or at least chemical facilities storing large quantities of toxic inhalation hazard (TIH) chemicals in the list of cyber dependent critical infrastructure. After all, we continue to hear organizations like Green Peace insist that a catastrophic release at many of these facilities could result in deaths of hundreds of thousands of people. Wouldn’t that be a catastrophe on a regional or national scale?

It certainly would, but I would have a hard time positing a reasonable cyber incident that would result in a catastrophic release of one of these chemicals. A release yes, even a release that resulted in off-site casualties; certainly. But not a catastrophic release of the scale discussed by these organizations (and to be fair by me here in this blog), that would take a failure of the physical structure of the tank. A cyber incident could, at most, result in a valve being opened to the atmosphere that would take dozens of hours to release the total contents to the atmosphere. Long before that happened, manual efforts to close the line would be successful.

What about water system contaminations like we saw in Charleston, WV? While the Freedom Spill was certainly disruptive, even severely disruptive, to the lives of the folks that live in that area, it was hardly a catastrophe. But let’s assume that the definition of ‘catastrophe’ was wide enough to encompass that scale of disruption. I would be hard pressed to define a ‘reasonable’ cyber incident that would cause that type of problem. You would have to find an upstream facility that held a chemical that would not be removed by the municipal water treatment facility and find a way to electronically release that chemical in a way that bypassed existing secondary containment. You could not have done it at Freedom Industries; their tank valves were all manually operated.

There may certainly be facilities where this could be done. Identifying them would be very difficult for DHS and nearly impossible for anyone else but an insider. I’m certainly not saying that DHS or EPA shouldn’t be looking at this, but it wouldn’t be part of the cybersecurity program; at least not initially.

What Has Actually Been Done?

So that is my take on the limitations of the cyber dependent critical infrastructure designations covered by this notice. How closely does that track with reality? I haven’t the foggiest idea, DHS is keeping this information fairly closely held; they certainly are not discussing it with me.

I would guess that they are using a wider set of criteria than those that I have describe above. There is a certain bureaucratic incentive to broadly define the problem. The more facilities that are designated CDCI the more responsibility that DHS has for their oversight and assistance. So I would guess they include many more, and different types of, facilities than I have described. Which ones and how many? I just have no way of knowing.

Thursday, April 17, 2014

ICS-CERT Publishes Siemens Advisory and Updates 3 HeartBleeds

Today the DHS ICS-CERT published a new control system advisory for a Siemens product and provided updates on three separate HeartBleed related documents.


The new Siemens advisory identifies three vulnerabilities in their SINEMA server. Siemens self-reported the vulnerabilities and has published a software update to mitigate the problems. The identified vulnerabilities include:

• Code injection, CVE-2014-2731 (incorrectly listed as CVE-2014-7231);
• Relative path traversal, CVE-2014-2732; and
• Improper input validation, CVE-2014-2733

According to ICS-CERT a relatively unskilled attacker could remotely exploit these vulnerabilities to execute arbitrary code, traverse through the file system, or cause a DoS.

HeartBleed Updates

ICS-CERT updated their HeartBleed Situational Awareness Alert by adding a list of ICS related products that have been identified as being specifically affected by the OpenSSL vulnerability. Only two vendors currently have products on the list, Innonminate and Siemens.

The Innominate HeartBleed Advisory was also updated. The Phoenix Contact branded versions of the Innominate devices is not affected by the HeartBleed vulnerability, but Innominate has upgraded them to the latest version to alleviate customer concerns. Only the 8.0.0 and 8.0.1 versions of the mGuard firmware are affected by the vulnerability

ICS-CERT has also provided a link to the latest FBI list of Snort Signatures that may be used to detect attempted exploitation of the HeartBleed vulnerability.

PHMSA Publishes Two Preemption Determination Requests

The DOT Pipeline and Hazardous Material Safety Administration (PHMSA) published two notices in today’s Federal Register {79 FR 21838-21840 (NY); 79 FR 21840-21842 (PA)} concerning requests by the American Trucking Association for determination of preemption of hazardous material permitting rules in New York City and Pittsburgh, PA. A determination of preemption would mean that the cities could not require the permits in question nor collect the fees for those permits.

New York City

The ATA has asked PHMSA to determine if the Federal Hazmat Transportation Law (49 USC Chapter 51) preempts the hazardous material transportation permitting requirements of Section 2702-02 of Title 3 of the Rules of the City of New York.


The ATA has asked PHMSA to determine if the Federal Hazmat Transportation Law (49 USC Chapter 51) preempts the hazardous material transportation permitting requirements of Chapter 801 of Title 8 of the Pittsburgh Code, Fire Prevention.

Public Comments

PHMSA is soliciting public comments on both petitions. Comments may be submitted via the Federal eRulmaking Portal {; Docket # PHMSA-2014-0003 (NY) or Docket # PHMSA-2014-0002 (PA)}. Comments should be submitted by July 16th, 2014.

NPPD Makes CSF Notifications

The DHS National Protection and Programs Directorate (NPPD) published a notice in today’s Federal Register (79 FR 21780-21782) announcing that it had, in accordance with §9 of the President’s executive order on Improving Critical Infrastructure Cybersecurity (EO 13636), completed notification of facilities that they have been identified as “critical infrastructure where a cybersecurity incident could reasonably result in catastrophic regional or national effects on public health or safety, economic security, or national security”. The notice also outlines the procedure by which a facility can appeal that designation.

The actual list of designated facilities was submitted to the President on July 19th of last year. The facilities have been designated as “cyber-dependent critical infrastructure” and the list will be reviewed on an annual basis.


Today’s notice provides several definitions that are important to understanding this program. They include:

Cyber incident; and

The above definitions seem to be IT system centric. For example the ‘cyber incident’ definition covers events that impair “the confidentiality, integrity, or availability of electronic information, information systems, services, or networks”. While this does not specifically exclude control systems, it certainly needs to be stretched to include them.

The definition of ‘critical infrastructure’ is taken verbatim from §2 of the EO. As I noted in an earlier blog the definition would be difficult to apply to any single production facility though national distribution networks (pipelines and the electric grid, for instance) would easily fall within the definition.

It is strange that NPPD did not use the §9(a) definition from the EO that expands coverage to facilities with potential catastrophic regional effects. This is especially true since §9(a) is the section directing DHS to prepare the list of critical infrastructure. Of course, since the list will not be publicly available, we will never really know how expansive the definition is in actual practice.

Listed Facilities

Being listed as a cyber-dependent critical infrastructure (CDCI) facility does not currently add to any regulatory burden, though adoption of the NIST Cybersecurity Framework (CSF) is encouraged. CDCI designation does provide facilities with the following perks:

● Ability to request expedited processing through the DHS Private Sector Clearance Program, which may provide access to classified government cybersecurity threat information as appropriate;
● May be prioritized for routine and incident-driven cyber technical assistance activities offered by DHS and other agencies; and
● May receive priority in gaining access to Federal resources and programs to enhance the security and resilience of critical infrastructure against cybersecurity threats.

Please note all of the permissive ‘mays’ in the descriptions. There are no guarantees provided. This is almost certainly due to the fact that this program is based upon an EO not legislative authority.

Status Appeal

The notice also provides instructions on how a facility can appeal their designation (or lack of designation) as a CDCI. The process for a request of reconsideration is actually quite simple in concept if not necessarily in actual execution. A letter or email is sent to the Under Secretary for NPPD requesting reconsideration. The request should include:

● The entity for which the reconsideration is being requested;
● The name, title, telephone number and email address of a designated point of contact, whether an employee or non-employee agent, for the owner or operator of that entity to whom all communications related to the reconsideration process will be directed; and
● If desired, a request for a meeting with DHS representatives.

After DHS confirms receipt of the initial request the process becomes less well defined as it involves the provision of information by the facility to DHS. That information will be the justification for why a facility should or should not be on the CDCI list. What the information might be and how much information will be necessary will vary considerably.

The notice does provide some very specific requirements for the formatting of information. It should be submitted by email (with certain exceptions) as a single attachment. It must be:

● Double-spaced;
● In 12 point Times New Roman text or visual material;
● Have 1” margins; and
● Have page numbers. 

The Notice specifically reminds submitters that the information provided may constitute Protected Critical Infrastructure Information (PCII) and provides a list of references about that program. Information designated as PCII (by the submitter) must be protected against disclosure by the Federal government and by anyone with whom it shares that information.

Anyone that submits information for this reconsideration process should become familiar with the PCII program as outlined in 6 CFR Part 29, and the PCII Program Procedures Manual (additional information can be found here). The single most important thing to remember is that information to be protected under the PCII program must be so designated {in a very prescribed manner, see §29.5(a)(3)} when it is submitted. If that is not done, the information is not required to be protected under the program.

The notice also reminds personnel submitting classified information that such information cannot be submitted by email.


Facilities or organizations wishing to request a reconsideration must have their initial request submitted to NPPD by May 15th, 2014. Requests received after that date will not result in reconsideration, but may be added to the consideration process in the preparation of the next annual list of CDCI.

Once NPPD notifies a facility that there request was received, facilities will have 60-days to submit supporting information.

Wednesday, April 16, 2014

Coordinated Disclosure is Complicated

The problem of when to publicly disclose discovered vulnerabilities in control systems is a much debated topic. Theoretically, I think that everyone in the control system vender and owner world would prefer to see researchers coordinate their disclosures so that the vendor has a chance to correct the vulnerability and the owner/operators have a chance to fix their systems before the vulnerability becomes public knowledge. But even when a researcher is committed to coordinated disclosure things can get complicated.

Coordinated Disclosure or Not

Yesterday Adam Crain, a well-known and well documented researcher, posted an interesting blog entry on his web site. In it he discusses a method of dealing with recalcitrant vendors that apparently make no effort to correct a vulnerability in their product that has been identified by an independent researchers and coordinated with both the vendor and ICS-CERT.

Historically (an odd term to use is in this young field) one of the reasons given by many grey hat researchers for not coordinating disclosures is that vendors have ignored them or failed to take action to correct identified vulnerabilities. In general the control system industry has gotten much better at responding to coordinated disclosures. This has been a major contributor to the decline in the number of Alerts that ICS-CERT has had to publish recently.

Unresponsive Vendors

But for every trend, there is an outlier. In this case it appears that Adam has identified one such outlier. Now Adam and his partner Chris Sistrunk have been the poster children for the coordinated disclosure process with the series of DNP3 vulnerabilities in 28 products that they have reported over the last year or so. They have been active proponents of fuzz testing of control system components, but they have been scrupulous in coordinating the disclosure of their serious vulnerability discoveries with vendors and ICS-CERT. But, even Adam and Chris have their breaking point.

Hidden Components

What is particularly disconcerting in this case is that this is not a vulnerable device that can be exposed to the community and provide owner/operators with the choice of how to deal with their vulnerable systems. In this case the identified vulnerability is in software library that may have been used by any number of vendors in developing the software and firmware for a wide range of control system products.

And the system owner/operators have no way knowing if that library has been used in any of their devices, so there is no way for them to protect their systems or even know if their systems need protecting. Okay, I suppose there is a way; Adam has made his fuzzing tool available free of charge and an energetic and system savvy owner could probably use the tool to find the hidden vulnerabilities. I’ll have to ask Adam about how likely is that his fuzzer would find these particular vulnerabilities in an off-line control system (NOTE: Never fuzz test a live control system).

This is an ongoing problem in the control system community (okay in the entire Cybersecurity community) where few organizations have the necessary talent or time to produce every line of code in-house that goes into their control system components. When a control system device (or software) vender buys (or uses open source) software they also get any vulnerabilities in that software. Identifying those underlying vulnerabilities and tying them to all other uses of that code is complicated at best.

We, the ICS security community, need to develop a methodology for identifying and tracking down all of the vulnerable iterations of code that are identified in one place as being vulnerable and used in other systems and applications. The ICS ISAC SARA program is designed to address part of this problem, but I am not sure that it will be capable of going deep enough into the architecture of control systems to really help alleviate this problem.

Continuing the Fight

Adam, of course, is not going to rely solely on outsiders to get this problem fixed. While he has still not publicly identified the particular vulnerability he is doing more than just writing this blog post of his about this specific vender. He is also taking the information to the ICS community; outing the vendor as one of the uncooperative ones. Not only is he attempting to use community coercion to encourage cooperative compliance, but he is in effect warning other vendors that there may be a bug in their systems that needs to be addressed.

I wish him the best of luck, but I don’t expect to see much action, at least publicly. Very few vendors have gotten to the point that they self-identify vulnerabilities in their systems (Siemens is a major exception) even if the vulnerability comes in with outside code.

UPDATED 4-17-14 7:30 CDT - Adam's blog post got an interesting response  (see first comment) from the company involved. They did not like him outing them. Too bad. If they had just talked with ICS-CERT and Adam this whole thing would never have blown-up like this.
/* Use this with templates/template-twocol.html */