DHS Updates CFATS Stats

Once again it is time for the monthly update of CFATS statistics from the folks at DHS Infrastructure Security Compliance Division (ISCD). They have published their CFATS Fact Sheet that covers through October 1^st. Below are the standard charts that I have been publishing showing the changes in these statistics over time.

The data shows continued improvement in the total number of authorized and approved facilities. The rate at which progress is being made is running about the same as it has been in the last couple of months; the variation is almost certainly due to the changing mix of facilities being evaluated.

The last chart is of increasing concern. My friends in the environmental activist community will be happy to see a decline in the number of facilities with ‘dangerous chemicals’ on site. I remain concerned about the lack of transparency on a program level (I don’t want to know plant details) about how many of these facilities are dropping out of the program due to process changes, inventory manipulation, or going out of business. Without that kind of data we cannot gauge the actual increase in safety/security involved in these numbers.

ICS-CERT Updates Two Advisories – Ignores Siemens GNU Bash Report

This afternoon the DHS ICS-CERT updated two earlier advisories, one from Siemens and one from Schneider. Interestingly they ignore the unique Siemens ProductCERT report on GNU Bash vulnerabilities in Siemens products.

Siemens Update

This advisory was originally published back in July. Since then Siemens has provided a new update for the still vulnerable SIMATIC PCS7. The original advisory was published with only a SIMATIC WinCC update available.

Schneider Update

This advisory was originally published almost three weeks ago. Since then Schneider has made the promised service packs available to correct the vulnerabilities:

• ClearSCADA 2010 R3.2, Released October 2014, and

• SCADA Expert ClearSCADA 2014 R1.1, Released October 2014.

Siemens GNU Bash Report

ICS-CERT has not yet published an advisory for the recently self-reported ProductCERT advisory for separate vulnerabilities related to the GNU Bash problem. Siemens tweeted about this advisory yesterday morning.

The advisory reports specific vulnerabilities in the DHCP client (ROX 1 and ROX 2 products) and the web interface of their ELAN system (APE Linux); nothing especially new here.

The interesting report here is the mention of a ‘generic Bash’ vulnerability in a number of listed products, but only after “major custom modifications by the user (such as installation of additional software or custom scripts)”. The public identification of a post-modification vulnerability marks a real commitment to customer support.

NHTSA Publishes Cybersecurity RFI

Today the DOT’s National Highway Traffic Safety Administration (NHTSA) published a notice in the Federal Register (79 FR 60574-60583) concerning its research program on determining the need for safety standards with regard to electronic systems in passenger motor vehicles. Such standards could include cybersecurity requirements for such systems. NHTSA is seeking public comments on these issues.

On July 6, 2012 the President signed into law MAP-21 (PL 112-141). Section 31402 required DOT to examine electronic systems in passenger motor vehicles. Part of that examination was to include a look at “the security needs for those electronic systems to prevent unauthorized access” {§31402(a)(1)}. A portion of today’s notice specifically addresses that cybersecurity examination. In this section NHTSA identifies two general approaches to vehicular cybersecurity:

• Design and quality control processes that focus on cybersecurity issues throughout the lifecycle of a product; and

• Establishing robust information sharing forums such as an Information Sharing and Analysis Center (ISAC)

Cybersecurity Design

NHTSA notes that there are no current cybersecurity design standards for the automotive industry. It does point at the NIST Cybersecurity Framework and notes that “this framework could allow the automotive industry to develop a security program for modern-day automobiles analogous to information security programs [emphasis added] in place for information technology (IT) systems in general”. This would make it seem that NHTSA intends to treat automotive electronic systems as information systems rather than control systems.

NHTSA does note the European Union’s efforts in this area, specifically the EVITA program which has apparently done nothing since it produced its final report in 2012.

Information Sharing

NHTSA reports that it has examined [.PDF download link] the Information Sharing and Analysis Center (ISAC) that has been used by other industries. It also notes that the Alliance of Automotive Manufacturers (Alliance) and the Association of Global Automakers (Global Automakers) are considering [.PDF download link] the formation of an automotive sector ISAC.

NHTSA Ongoing Research

NHTSA reports that its ongoing automotive cybersecurity research program targets four areas:

• Preventive methods and techniques;

• Real-time intrusion detection methods;

• Real-time response methods; and

• Treatment methods.

Public Comments

Before they complete their required report to Congress on automotive cybersecurity NHTSA is soliciting public comments on this topic. They are specifically asking for input in the following topic areas:

• Suggested areas for further research;

• Security process standards; and

• Security performance standards.

Comments may be submitted via the Federal eRulemaking Portal (www.Regulations.gov; Docket #NHTSA-2014-0108). Public comments should be submitted by December 8^th, 2014.

No Responses to NIST RFI

Back in August the National Institute for Standards and Technology published a request for information about organizational experience with the Cybersecurity Framework (CSF) that was published last February. With five days left in the comment period NOT ONE RESPONSE has been posted to the NIST web site. I suppose that it could be that NIST is so overwhelmed with responses that they just haven’t had a chance to get them up on their site, but I don’t really expect that that is the case.

I suspect that while the information security press has had qualified good things to say about the CSF that it is mainly a dead issue with industry in general. We have seen no movement by the regulatory agencies that might have been able to use the CSF as a tool to help gauge cybersecurity management to publicize much less use this tool.

It is a shame. The folks at NIST, and many folks in the private sector, spent a great deal of time and effort coming up with a consensus document that is either so perfect that no one sees a need to improve it, or is so lame that nobody thinks that it is fixable. 

NOTE: Thanks to a TWEET by Aristotle Tzafalias I learned that NIST has said that they will only post the comments to their web site after the close of the comment period. Certainly an odd way of doing things, but within their prerogative. 10-16-14 04:20 CDT.

HSAAC Meeting Announced – 10-22-14

DHS is publishing a notice in Monday’s Federal Register (79 FR 60179-60180; available on line today) announcing a public meeting of the Homeland Security Academic Advisory Council in Washington, DC on October 22^nd, 2014. Subcommittee reports will include a report by the Cybersecurity Subcommittee.

According to the HSAAC web site the Cybersecurity Subcommittee is mainly tasked to look at cyber-workforce issues. At their last meeting [.PDF Download] they made suggestions like:

• DHS should continue hosting monthly tours of DHS' National Cybersecurity and Communications Integration Center (NCCIC) for secondary, post-secondary and veteran students involved in cybersecurity and other STEM disciplines;

• DHS should target outreach efforts at underserved communities to improve their pathways to cyber-related educational and career opportunities;

• DHS should identify and leverage existing college and university cyber boot camps for ROTC cadets as a model for student veterans; and

• DHS should foster the growth of the U.S . Coast Guard Academy's (CGA) cyber-related educational opportunities and programs;

The one area of non-workforce related focus of the Cybersecurity Subcommittee; better with individual campus information technology departments on the risks towards and attacks on computer systems and networks; did not receive any mention in the last HSAAC meeting.

BTW: There is no subcommittee that looks at hazardous chemical security issues. Given the perennial complaints from the schools that are forced to report Top Screen information for their chemical inventories and the smaller number that have CFATS covered facilities on campus you would think that this might be a focus. Silly me.

FRA Publishes Crude EO 30 Day ICR Notice

Today the DOT’s Federal Railroad Administration (FRA) published a 30-day information collection request (ICR) notice in the Federal Register (79 FR 59891-59893) to extend the current emergency ICR that supports the crude oil train routing reporting requirements of the most recent FRA emergency order regarding crude oil trains.

The bulk of this notice is a response to the single public comment that was submitted directly to the FRA as a result of the 60-day notice on this ICR renewal. That comment was jointly submitted by the Association of American Railroads (AAR) and the American Short Line and Regional Railroad Association (ASLRRA). The FRA is apparently going to ignore the three public comments submitted via the Federal eRulemaking Portal. Admittedly those comments are more about crude train hazards than about the actual ICR and thus probably don’t require specific comments.

The railroad comment reportedly objected to the SERC reporting requirements of the emergency order on three grounds:

• The routing information is sensitive information on a security basis and thus should be protected from subsequent disclosure;

• The routing information is sensitive information on a commercial competitive information basis and thus should be protected from subsequent disclosure; and

• The reporting requirement is duplicative of voluntary industry standard disclosure and thus un-necessary.

FRA dismisses the security sensitive claim by noting that the information does not fall under any of the fifteen enumerated categories of sensitive security information (SSI) set forth in 49 CFR §15.5 or §1520.5. It is interesting, going back and closely reading those categories of information that there is only one specific reference to rail transportation security and it would not appear to apply in this instance;

“(8) Security Measures. Specific details of aviation, maritime, or rail transportation security measures, both operational and technical, whether applied directly by the Federal government or another person”

There is another DOT regulation that makes railroad hazmat route information SSI. Section 172.820(i)(2) [.PDF Download] specifically applies SSI rules to such routing information for selected hazardous material shipments; toxic inhalation hazard railcars, for instance. Crude oil railcars are not currently included in this category. Interestingly the PHMSA High Hazard Flammable Trains NPMR would modify §172.802(a) to include trains carrying 20 car loads of flammable liquids. This would place the routes for crude oil trains of 100 cars clearly under the SSI requirements.

The sixteenth category (Secretarial discretion for either DOT or DHS) in both of the SSI rules is dealt with by noting that “DOT finds no basis to conclude that the public disclosure of the information is detrimental to transportation safety”. Given the fact that DOT has a rulemaking in progress that that specifies that these train routes require SSI protection, the decision by the Secretary not to designate this material as SSI requires some serious reconsideration either in this ICR or in the proposed changes in the NPMR.

The FRA response on the business confidentiality issue is also interesting. Their claim is that since the disclosures are made to State agencies not the Federal government, then State disclosure laws apply and it is out of the hands of DOT. This is the reason that most rules requiring sensitive information disclosure to State and local government agencies specifically spell out that the disclosures are exempt from State and local government disclosure laws.

Finally, the FRA notes that voluntary disclosures are all well and good, but they are voluntary and may fall short of the requirements of the emergency order without penalty. Placing the requirements in the emergency order provides DOT with a way to enforce the requirement.

FRA is soliciting public comments on this 30-day ICR notice. Comments should be sent directly to the OMB’s Office of Information and Regulatory Affairs. They may be sent by email (oira_submissions@omb.eop.gov). Comments should arrive by November 3^rd, 2014.

FDA Issues Guidance on Management of Cybersecurity in Medical Devices

Today the Food and Drug Administration (FDA) published a notice in the Federal Register (79 FR 59493-59494) announcing that it had published a new guidance document about cybersecurity for medical devices; “Content of Premarket Submissions for Management of Cybersecurity in Medical Devices”. A draft version of this non-binding guidance document was released for public comment in June of 2013.

The document is designed to address cybersecurity issues to be addressed in premarket data submissions for “devices that contain software (including firmware) or programmable logic as well as software that is a medical device organized. It is divided into sections dealing with:

• Definitions;

• General Principles;

• Cybersecurity Functions;

• Cybersecurity Documentation; and

• Established Standards

General Purposes

After stating the obvious that “medical device security is a shared responsibility between stakeholders, including health care facilities, patients, providers, and manufacturers of medical devices” (pg 3) the FDA goes on to explain that:

“Manufacturers should address cybersecurity during the design and development of the medical device, as this can result in more robust and efficient mitigation of patient risks. Manufacturers should establish design inputs for their device related to cybersecurity, and establish a cybersecurity vulnerability and management approach as part of the software validation and risk analysis that is required by 21 CFR 820.30(g).” [Link added] (pg 4)

Cybersecurity Functions

In the only documented reference in this guidance to the recent NIST Cybersecurity Framework (CSF), the FDA identifies the five cybersecurity functions outlined in the CSF; Identify,

Protect, Detect, Respond, and Recover. Unfortunately, the FDA totally ignores the opportunity to reference the CSF as a way to identify cybersecurity activities, desired outcomes, and

applicable references that a medical device manufacturer could use to establish their cybersecurity management program.

Instead the Guidance document relies on two pages of bullet points of the ‘motherhood and apple pie’ variety. For example, under the ‘Limit Access’ category they include such earth shattering recommendations as:

• Limit access to devices through the authentication of users (e.g. user ID and password, smartcard, biometric); and

• Where appropriate, provide physical locks on devices and their communication ports to minimize tampering;

Cybersecurity Documentation

As you might expect for a guidance document that is focused on cybersecurity information that will be submitted to FDA as part of the device approval process, the most specific guidance is found under this heading. The FDA outlines five specific types of documentation that may be specifically required for the approval process. They are (pg 6):

• Hazard analysis, mitigations, and design considerations pertaining to intentional and unintentional cybersecurity risks;

• A traceability matrix that links your actual cybersecurity controls to the cybersecurity risks;

• A summary describing the plan for providing validated software updates and patches as needed throughout the lifecycle of the medical device;

• A summary describing controls that are in place to assure that the medical device software will maintain its integrity (e.g. remain free of malware) from the point of origin to the point at which that device leaves the control of the manufacturer; and

• Device instructions for use and product specifications related to recommended cybersecurity controls appropriate for the intended use environment.

Interestingly, in this section the FDA specifically abdicates responsibility for cybersecurity system updates, noting that: “The FDA typically will not need to review or approve medical device software changes made solely to strengthen cybersecurity.”

Public Comments

Even though this is the ‘final’ version of the Guidance document, the FDA is soliciting comments from the regulated and affected communities. Comments may be submitted via the Federal eRulemaking Portal (www.Regulations.gov; Docket # FDA-2013-D-0616).

You can find copies of public responses to the draft guidance document published last year in the same docket. Unfortunately, there is nothing in today’s notice or final guidance document that provides any insight into how the FDA addressed the concerns outlined in the 26 public and industry responses to that draft document.