ICS-CERT Releases 3 Lesser Communications Advisories

While everyone is still talking about Black Energy the DHS ICS-CERT released three advisories today concerning lesser vulnerabilities in three applications used in control systems communications. One was a follow up to an alert issued last Halloween, while the other two are newer vulnerabilities that were released earlier this month on the US-CERT secure portal.

Nordex Advisory

Last Halloween ICS-CERT published an alert about an uncoordinated disclosure (complete with exploit) of a cross-site scripting vulnerability in the Nordex Control 2 (NC2) application. Today ICS-CERT announced that Nordex has (I think) produced a patch to mitigate the vulnerability; needless to say no one has contacted the uncooperative researcher, Darius Freamon, to verify its efficacy.

ICS-CERT reports that a relatively low skilled attacker could use the publicly available exploit to remotely “execute arbitrary script code in the user’s browser”.

I said ‘I think’ parenthetically above because of the wording of the following sentence in today’s advisory:

“Nordex will release a patch for all affected NC2-SCADA versions until the end of 2014.”

I think that that means that the patch is available but Nordex will only be applying the patches through the end of the year. The Advisory notes that the patching of the wind turbine control system has to be done by Nordex. A year to wait for the vendor to fix a cross-site scripting error and then have to wait until they can get around to your site to apply the fix; I hope Nordex is including all of this in their sales material.

Meinberg Advisory

This advisory reports another cross-site scripting vulnerability, this time in Meinberg Radio Clocks GmbH & Co. KG LANTIME M400 web interface. This was originally reported by Aivar Liimets of Martem Telecontrol Systems in a coordinated disclosure. ICS-CERT reports that Meinberg has produced a firmware update that has been verified by Liimets. This advisory was originally released on the US-CERT secure portal on October 2^nd.

ICS-CERT reports that a relatively unskilled attacker could remotely exploit this vulnerability to “cause the time server to provide misinformation to devices”.

Accuenergy Advisory

This advisory reports two authentication vulnerabilities in the AXN-NET Ethernet module from Accuenergy. The vulnerabilities were reported by Laisvis Lingvevicius in a coordinated disclosure. According to ICS-CERT Accuenergy has produced a firmware update that has been validated by Lingvevicius. This advisory was also released on the US-CERT secure portal on October 2^nd.

The two vulnerabilities are:

• Authentication bypass vulnerability, CVE-2014-2373; and

• Password disclosure vulnerability, CVE-2014-2374

ICS-CERT reports that a relatively low skilled attacker could remotely exploit these vulnerabilities to change network settings for the AXM-NET module web server as part of a denial of service attack.

Interestingly, the Accuenergy web site offers the following information about the firmware update:

“Redesign and improve encryption method on web-server, tested and verified by Department of Homeland Security, industrial control system cyber emergency response team [sic]”.

In light of discussions about what ICS-CERT really does (see most recently Dale Peterson’s blog post “What Does ICS-CERT Do?”) it is nice to see positive signs of actual involvement in the process of fixing vulnerabilities. Of course there are lots of businesses out there that are trying to make payroll by doing the same sort of thing.

Of course Accuenergy could just be blowing smoke to try to make their own efforts look good.

ATF Sends Explosives Registration Final Rule to OMB

Yesterday the OMB’s Office of Information and Regulatory Affairs (OIRA) announced that it had received a copy of the final rule implementing the Safe Explosives Act registration requirements from the Justice Department’s Bureau of Alcohol, Tobacco, Firearms, and Explosives. The Interim Final Rule (68 FR 53509) on this rulemaking has been in effect since September 30^th, 2003.

There is no telling at this point what changes might be included in this Final Rule.

ICS-CERT Adds Hash Validations for Yara Downloads

This afternoon the DHS ICS-CERT published its first update for yesterday’s alert about the newly identified (but old in the field) Black Energy compromise of control systems from multiple vendors. Today’s update provides the information necessary to complete a validation of the Yara binaries that ICS-CERT provided for download.

Those binaries were provided to allow owner/operators to check their systems to see if they were part of the compromised control system environment. Unfortunately, unless you are part of the twisted minority that can actually read binaries, downloading and executing binary that have not been verified is probably the single most unsecure action anyone can do on the internet. And there was ICS-CERT asking critical infrastructure owners to do just that.

Now, to be fair, I did not point this out last night because I made the same assumption that ICS-CERT probably expected everyone to make. These files came publicly from ICS-CERT so they were properly vetted, verified and safe. And that is almost certainly true (I don’t know because I can’t read binaries) if you downloaded them from the ICS-CERT site (unless of course someone hacked the ICS-CERT site and modified the binaries posted there). If you downloaded them from a bogus copy of the ICS-CERT site, or got them from some other site as a ‘true copy’ of the ICS-CERT supplied, or you got them in an email that appeared to come from someone you should be able to trust, or any number of alternative methods, then you would need some independent method of insuring that the binaries are the ones that ICS-CERT provided in the first place.

Fortunately, there are some people around who are less trusting. One such last night was OMG ‘H’AXOR (@SynAckPwn) who noted: “Juicy watering hole target identified: ICSCERT just reco'd control sys owners go to gDrive linked from github, DL EXE, run on ICS systems”. That comment spawned a very interesting series of Twitversations last night. Apparently, ICS-CERT was listening as they quickly (for a government agency VERY QUICKLY) provided the necessary data to verify the binaries.

Is it enough? It depends on how many noids you have. If you have a pair you might point out that anyone could still set up a mirror site and post modified binaries with modified hash information and they would still own any system upon which this binary was used to check for the Black Energy compromise. In a truly paranoid world you would want the two items to come from different sources with appropriate separate authentication for each source. But, let’s face it; even that could be hacked.

BTW: The REALLY PARANOID would never have seen this information in the first place because it was published in a .PDF document; and NOBODY in the right mind would open a .PDF.

But, I think that ICS-CERT should still be given credit for taking the effort. This time. They really should come up with a better method for sharing this information in any future action of this sort.

ICS-CERT Publishes Long Term Anti-ICS Campaign Advisory

This evening the DHS ICS-CERT published an alert about a long term anti-ICS campaign that has been compromising various control systems from multiple vendors since at least 2011. ICS-CERT is reporting that, at a minimum, HMI from GE, Advantech and Siemens have been compromised in this campaign. They are not currently reporting any damage to control systems or to operations that are controlled by those systems.

ICS-CERT is publicly providing detailed information about how these compromised HMI can be identified and it is asking all potentially affected system owners to check their systems and notify ICS-CERT if evidence of compromise exists.

As one would suspect with something that is apparently as serious as this, ICS-CERT has released an alert (ICS-ALERT-14-281-01P) on the US-CERT secure portal and has already published an update to that alert. ICS-CERT is also taking the unusual step of publicly describing that alert and notifying “US critical infrastructure asset owners and operators” that they can request a copy of the alert by email (ICS-CERT@HQ.DHS.gov).

As I have already mentioned on TWITTER®, this is the most detailed ICS-CERT alert that I have ever seen, especially on an initial publication. This is the type of information that we should be able to expect from ICS-CERT. This is also the type problem that we really need to be able to expect them to delve deeply into. I suspect, however, that we will be receiving the bulk of our information on this from private sector researchers who will have more resources and expertise to throw at this problem. That would be a good topic for a congressional investigation.

BTW: Here is an interesting question about this issue from Chris Sistrunk: “Could the BlackEnergy ICS malware be related to the vulns discovered by Z0mb1E and amisto0x07 from ZDI and the Metasploit mods they wrote?”

BTW: The alert contains a link to the GE security page. Nothing specific there except a brief note that: “The CIMPLICITY Webview server that existed in prior versions of CIMPLICITY, has been removed due to security concerns.” No further information available.

BTW: Siemens Product-CERT also is saying nothing. 

Small Unmanned Aircraft Systems (sUAS)

On Saturday the OMB’s Office of Information and Regulatory Affairs (OIRA) announced that the FAA had submitted a notice of proposed rulemaking (NPRM) for Operation and Certification of Small Unmanned Aircraft Systems (sUAS). This rulemaking was mandated by the FAA Modernization and Reform Act of 2012 {§332(b) PL 112-95} with the final rule to be published by August 14^th, 2014 (Oops).

According to the Unified Agenda abstract for this rulemaking:

“This rulemaking would adopt specific rules for the operation of small unmanned aircraft systems (sUAS) in the national airspace system. These changes would address the classification of small unmanned aircraft, certification of their pilots and visual observers, registration, approval of operations, and operational limits in order to increase the safety and efficiency of the national airspace system.”

It is way too early to tell if this rulemaking will have any critical infrastructure security implications.

ICS-CERT Issues 2 New Advisories and Updates 2 Siemens Advisories

ICS-CERT has been busy this week. Today they issued two new control system advisories and updated two Siemens advisories. The new advisories are for vulnerabilities in Fox DataDiode Proxy Server and the IOServer application. The two Siemens advisories have already been mentioned here this week.

Fox Advisory

This advisory concerns a cross-site request forgery (CSRF) vulnerability in the web administration interface. It was reported by Tudor Enache of HelpAG in a coordinated disclosure. A new release has been produced that mitigates the vulnerability, but there is no mention if the efficacy has been verified by Enache. This advisory was originally released on the US CERT secure portal on September 26^th.

ICS-CERT reports that a two phase social engineering attack would be required to remotely exploit this vulnerability to conduct a DOS attack.

IOServer Advisory

This advisory concerns an out of bound read vulnerability reported by Sistrunk-Crain (ICS-CERT changed up the order of the team name) in a coordinated disclosure. A new version mitigates the vulnerability and the efficacy has been verified by Adam Crain.

ICS-CERT reports that a moderately skilled attacker could remotely exploit this vulnerability to crash the OPC Server application.

There is an interesting comment by ICS-CERT in the Vulnerability Characterization section of the advisory. They state:

“A vague interpretation of the DNP3 protocol may allow a null header to cause an out of bound read command to create large numbers of entries in the master in some implementations. This is not a universal problem for all DNP3 users, vendors or integrators [emphasis added], but it may occur.”

That plus a reference to a DNP3 Application Note addressing this issue seems to indicate that this is a problem that might affect other systems. Not that Chris and Adam have ever found vulnerabilities in DNP3 implementations that affect multiple platforms (sorry for the low level sarcasm here). As of 9:00 pm CDT this advisory is not listed on the Project Robus web site.

Siemens OpenSSL Update

Well it looks like we are going to need at least update G to get this correct. Yesterday ICS-CERT reported that ROX 1 was the only outstanding affected system without an update; completely missing the APE 1 with eLAN and ROX 2 with eLAN. Well, with the Siemens ProductCERT announcement today that the ROX 1 update was now available ICS-CERT is still failing to report the continuing vulnerabilities in APE 1 with eLAN and ROX 2 with eLAN. Well, maybe tomorrow.

Ruggedcom Certificate Update

ICS-CERT missed the earlier announcement that the ROX 2 update was available, but they did catch up today when Siemens ProductCERT announced that the ROX 1 update was now available. So far so good. Unfortunately, ICS-CERT also changed their reporting of the affected versions of these two devices. It was correct and had not changed in the latest Siemens report. I know; minor details.

I’m beginning to wonder if anyone at ICS-CERT actually reads the Siemens alerts. The bigger question is how accurate are the other vulnerability reports from ICS-CERT, the ones that we can’t check because the vendor is not as meticulous in reporting their vulnerabilities as is Siemens?

ICS-CERT Updates Bash and Siemens OpenSSL - Issues Pyxis Advisory

Today the DHS ICS-CERT published four documents concerning vulnerabilities in control systems. One is actually a correction to yesterday’s Siemens OpenSSL update. Then they updated the BASH advisory and issued a supplement to that advisory. Finally they published a new advisory for a medical supply system with multiple vulnerabilities.

Siemens OpenSSL Update

Yesterday ICS-CERT published an update for the Siemens OpenSSL advisory that reported that all affected systems had updates available. Today they are reporting that what Siemens actually said was that a new update was available for ROX 2-based devices. And it reports that Siemens is still working on an update for ROX 1.

Oops, no, they got it wrong again. According to the Siemens ProductCERT advisory, the newest update only affects ROX V2.6.0 with Crossbow V4.2.3.  There are three products listed by Siemens that do not currently have updates available:

• APE 1 with eLAN installed: All versions <= 1.0.1;

• ROX 1: All versions (only affected if Crossbow is installed);

• ROX 2 with eLAN installed: All versions < V2.6.0

Sorry. I did not read the Siemens ProductCert advisory on this yesterday; I trusted ICS-CERT to get it right. Well, maybe they’ll get it right tomorrow. And that will be version ‘F’ when we should still be on version ‘C’. Oh well….

BASH Advisory Update and Supplement

Back in September ICS-CERT published a brief advisory on the Bash command injection vulnerability. I was kind of busy at the time and didn’t write about their advisory because much more complete information was readily available elsewhere. Well, today the published an update to that advisory that was not much better. The only change was the addition of the following paragraph:

“ICS-CERT sent out a query to vendors we have collaborated with in the past. Many have responded back with information about which products are affected by this bash vulnerability. ICS-CERT created a supplement to this advisory that contains this information. It can be found at the following web location: https://ics-cert.us-cert.gov/advisories/Supplement-ICSA-14-269-01. This supplement will be updated with additional information as it becomes available, without updating this advisory.”

So now we have a new ICS-CERT document that will be periodically updated so they don’t have to update the advisory so often??? Okay, what ever.

Okay, the supplement provides some useful information. First it provides a list of companies that have responded to ICS-CERT inquiries about potentially vulnerable systems. Then it provides a list of vulnerable systems (by vendor) with links to further information. It is not clear that systems from vendors on the first list that are not listed on the second list are actually not vulnerable. I think that that may be a dangerous assumption to make. In any case, selected products from the following vendors are reportedly at least potentially vulnerable:

• ABB;

• Cisco;

• Digi;

• eWON;

• Meinberg;

• Moxa;

• Red Lion (pardon me; use bash shell but “are not considered to be vulnerable or exploitable”; and

• Siemens (okay, this lets them off the hook for not mentioning the Siemens ProductCERT advisory yesterday).

Pyxis Advisory

NOTE: This is for a medical supply control system, not really an industrial control system, but hey the FDA won’t touch this and ICS-CERT doesn’t have anything else going on right now….

This advisory is for multiple authentication vulnerabilities in the CareFusion Pyxis SupplyStation reported by Billy Rios. CareFusion has produced a new version of the software that mitigates three of the four vulnerabilities. No mention if Billy was given the chance to verify the efficacy of the fix.

ICS-CERT reports that the vulnerabilities are:

• Hard-coded password, CVE-2014-5422;

• Hard-coded credentials, CVE-2014-5421 and CVE-2014-5420; and

• Insecure temporary files, CVE-2014-5423

ICS-CERT reports that a relatively low skilled attacker could remotely exploit these vulnerabilities to manipulate the locking controls on the automated medical supply cabinets. I don’t expect that these are used to dispense narcotics or else the DEA would be involved.

CareFusion reportedly will not be offering a fix to one of the hard-coded credential vulnerabilities because it would only allow access to some application files, but not the physical access controls. That would seem to be a reasonable risk assessment decision if it was made by the system owner, not the manufacturer. Good news, it will be fixed in future versions.

ICS-CERT Acknowledges 1 of 3 Siemens Updates

Earlier today the DHS ICS-CERT published an update (#4) for the Siemens OpenSSL advisory that was last updated in August. It ignored updates for a RuggedCom certificate verification vulnerability (ICSA-14-135-03) originally published in May and an update for the Siemens GNU Bash vulnerability that ICS-CERT still has not reported. Batting 1 for 3 in baseball is pretty good; in security it SUCKS. All three updates were published yesterday on the Siemens ProductCert web page.

Open SSL Update

This update reports that Siemens now has updates available for all of the affected product lines. Steady progress made since the vulnerability was reported earlier this year with regular updates to public notifications by Siemens.

Certificate Verification Update

ICS-CERT may not care, but Siemens is reporting that it has firmware updates available for ROX 2 devices and continues to work on updates for ROX 1 devices.

GNU Bash Update

Siemens is reporting that the same ROX 2 firmware upgrade that fixed the certificate verification vulnerability also addresses their GNU Bash issue. Two vulnerabilities with a single upgrade, good move. ICS-CERT apparently still does not know that Siemens is affected by GNU Bash so the update passes unnoticed.

OMB Approves CSAT ICR Renewal

On Friday the OMB’s Office of Information and Regulatory Affairs (OIRA) announced that it had approved the DHS information collection request (ICR) for the on-line Chemical Security Assessment Tool (CSAT) that is used to collect program information from facilities affected by the Chemical Facility Anti-Terrorism (CFATS) program. The 30-day ICR notice for this collection was published back in March, 2013.

This announcement provides links to the supporting documents for this ICR. It provides a link to the American Chemistry Council comment [.PDF download link] that was responsible for the changes to the method of calculating the burden estimate for the SSP Tool. While DHS did modify their burden estimate, it seems clear to me that there is still some level of disagreement about how they calculate the hours of support activity that goes into the SSP documentation. 

While this disagreement is not fully explained in the ICR documentation I suspect that it relates to how much of the time that the ACC is claiming for SSP burden is used for preparing the SSP data submission and how much is for the preparation of the SSP. It would be helpful if the folks at the DHS Infrastructure Security Compliance Division (ISCD) would explain this distinction.

NOTE: The other two CFATS ICR’s (CVI and CFATS) that were submitted at the same time as this were approved on September 30^th. I did not report them here as they were both submitted as renewals without revision. The length of time necessary for the approval of these ICR’s is almost certainly a measure of the political problems that the CFATS program has been facing in Congress. It is apparent that these have been approved now as a result of the apparent change in the support for HR 4007 in the Senate. We still have one CFATS ICR outstanding and that is the one for the CFATS Personnel Surety Program; due to congressional (read industry in this case) opposition to the way ISCD has structured that program the ICR will not be approved.

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.