ICS-CERT Publishes Six Advisories

Today the DHS ICS-CERT published six control system security advisories for products from Automated Logic Corporation, Moxa, OPW Fuel Management Systems, and Siemens (3). The ALC advisory was originally published on the NCCIC Portal on May 30, 2017.

ALC Advisory

This advisory describes an improper restriction of XML external entity reference vulnerability in the ALC ALC WebCTRL, Liebert SiteScan, and Carrier i-VU building automation applications. The vulnerability was reported by Evgeny Ermakov from Kaspersky Lab. ICS-CERT reports that ALC has developed patches for the WebCTRL and Carrier i-VU applications that mitigate the vulnerability. There is no mention of mitigation measures for the Liebert SiteScan. There is no indication that Ermakov has been provided an opportunity to verify the efficacy of the fix.

ICS-CERT reports that a relatively low skilled attacker could remotely exploit the vulnerability to the disclosure of confidential data, denial of service (DoS), spoofing of a request from an upstream device, port scanning from the perspective of the machine where the parser is located, and other system impacts.

Moxa Advisory

This advisory describes an improper neutralization of special elements used in an SQL command in the Moxa SoftCMS Live Viewer, a video surveillance software designed for industrial automation systems. The vulnerability was reported by Ziqiang Gu from Huawei WeiRan Labs. Moxa has provided a software update to mitigate the vulnerability. There is no indication that Gu has been provided an opportunity to verify the efficacy of the fix.

ICS-CERT reports that an uncharacterized attacker with uncharacterized access could exploit the vulnerability to access SoftCMS Live Viewer without knowing the user’s password.

OPW Advisory

This advisory describes two vulnerabilities in the OPW Fuel Management Systems SiteSentinel Integra and SiteSentinel iSite consoles. The vulnerabilities were reported by Semen Rozhkov of Kaspersky Lab. OPW has produced a new version to mitigate the vulnerability and recommends that it be applied even if the systems are protected from exploitation by running off-line or located on a protected network. There is no indication that Rozhkov has been provided an opportunity to verify the efficacy of the fix.

The two reported vulnerabilities are:

• Missing authentication for a critical function - CVE-2017-12733; and

• Improper neutralization of special elements used in an SQL command - CVE-2017-12731

ICS-CERT reports that a relatively low skilled attacker could remotely exploit these vulnerabilities to create an account on the device or access the device’s database.

NOTE: I have never had to update software on an ICS device before, but it seems to me that if it is normally as complicated as the procedures provided for these devices then it would be a wonder if anyone ever upgraded device software.

7KM PAC Advisory

This advisory describes an uncontrolled resource consumption vulnerability in the Siemens 7KM PAC Switched Ethernet PROFINET expansion module. Siemens is self-reporting this vulnerability. They have produced a firmware update to mitigate the vulnerability.

ICS-CERT reports that a relatively low skilled attacker with uncharacterized access could exploit the vulnerability to cause a denial-of-service condition in the affected component that may require a manual restart of the main device to recover. The Siemens security advisory notes that the attacker must have network access to the local Ethernet segment (Layer 2) to exploit the vulnerability.

LOGO Advisory

This advisory describes two vulnerabilities in the Siemens LOGO!8 BM devices. The first vulnerability listed below was reported by Maxim Rupp; the second was self-reported by Siemens. Siemens has developed a new firmware version that mitigates the vulnerabilities. There is no indication that Rupp was provided an opportunity to verify the efficacy of the fix.

The two reported vulnerabilities are:

• Insufficiently protected credentials - CVE-2017-12734; and

• Channel accessible by non-endpoint - CVE-2017-12735

ICS-CERT reports that a relatively low skilled attacker could remotely exploit these vulnerabilities to hijack existing web sessions. The Siemens security advisory notes that the first vulnerability requires network access to the integrated web server on port 80/tcp to exploit.

Industrial Products Advisory

This advisory describes an improper restriction of XML external entity reference vulnerability in the Siemens Industrial products using the Discovery Service of the OPC UA protocol stack by the OPC foundation. The vulnerability was reported by Sergey Temnikov of Kaspersky Lab. Siemens has produced new software versions for some of the listed products; other updates are still pending. There is no indication that Temnikov has been provided an opportunity to verify the efficacy of the fix.

ICS-CERT reports that a relatively low skilled attacker could remotely exploit the vulnerability to access various resources. The Siemens security advisory reports that an attacker must have network access to the affected devices to exploit the vulnerability.

Harvey Chemplant Explosion – Part I

It looks like this organic peroxide plant situation will be continuing news. It seems that late last night there were two ‘explosions’ at the facility (see here and here for news reports) and a number of police officers are being treated for chemical exposure issues.

NBC News Tweeted® a copy of the Arkema statement about last night’s incident. It makes a very important point: “We want local residents to be aware that product is stored at multiple locations on site, and a threat of additional explosions remains.”

Health Effects

First, we need to remember that the smoke from any fire contains some number of toxic elements and should be avoided. This is especially true when you see thick black smoke; that indicates incomplete combustion and you are going to have a wide variety of chemicals and physical particles that will, at the very least, irritate the lungs.

I am not an industrial health expert, by any stretch of the imagination, but organic peroxides will almost certainly have some level of toxicity due to their chemical nature. The free radicals produced in the initial decomposition are very reactive and will almost certainly react with body tissues. Fortunately, they also react very quickly with oxygen in the air, so this toxicity is typically greatly decreased the further you get from the un-decomposed organic peroxide.

Police officers are always going to be at risk from smoke inhalation injuries due to the nature of their duties since they do not have ready access to necessary personal protective equipment. The standard issue protective mask (used mainly for riot control situations where tear gas may be employed) may not be effective protection against all components of the smoke of an industrial fire. This is why fire fighters carry the heavy and awkward breathing air tanks on their backs.

For more information on the toxicity of organic peroxides you can visit the Arkema web site and find the Safety Data Sheets for the Luperox® line of organic peroxides. I am not sure which of those are manufactured at this particular facility (the local fire department has that list), but you can get an idea of the types of solvents used and the general toxicity information.

SADT

Those SDS also contain another interesting bit of information, the temperature at which a self-accelerating decomposition reaction (SADR) begins {referred to as the self-accelerating decomposition temperature (SADT)}. This is the decomposition reaction that I described in last night’s blog post. This is the critical temperature that I talked about. Looking at a random selection of the Luperox products this morning, it would seem that most have a SADT in excess of 100° F.

Unfortunately, even below the SADT some level of decomposition remains, and the exothermic nature of that decomposition reaction will raise the temperature of the mixture. The SADT is the point of no return. When it reaches the SADT there is essentially nothing that can be done to prevent catastrophic decomposition rates.

The higher the SADT, the longer it is going to take for those containers to reach their failure point, prolonging the current problem. Of course, a fire on the site will change all of that as it would quickly raise the temperature well above the SADT point while weakening the structure integrity of the storage containers.

Storage Issues

One last item that needs to be taken into consideration. Organic peroxides are normally shipped in five-gallon plastic containers. I would expect that this facility would store those on pallets with the containers stacked two or three high. The containers at the center of the stack are going to generally be the first to fail as they are insulated from the cooling effects of the air surrounding the stack.

It would not be unusual to expect that, depending on how the pallets are stacked in relation to each other, that we could see several small ‘explosions’ of individual containers before the bulk of a certain product releases. This could also cause a relatively small fire in the storage area that could expedite other products reaching their SADT.

It will be interesting to see how much detail is included in the monitoring of these storage areas. We could get some very important data on failure rates and effects that could be beneficial in preventing future incidents at these types of facilities.

Harvey Related Chemplant Explosion Predicted

It is not often that we get to watch a major chemical safety event as it progresses to its catastrophic end-point. As unusual as such an event is, it is hardly surprising that it is Harvey that is the proximate cause of the incident. News stories (here, here and here) provide the background to the unfolding event.

Organic Peroxides

Organic peroxides are a class of chemicals that contain an oxygen-to-oxygen bond in the central portion of the molecule (commonly represented as RCOOR; where R is any of a variety of organic compounds). These molecules are important in chemical manufacturing because they decompose to produce free-radicals (commonly represented as •OR). Free radicals are necessary to start many industrial chemical reactions; many polymerization reactions, for example, require the use of free radical technology.

From a process chemical point of view, organic peroxides are very useful because each organic peroxide starts its decomposition process at a characteristic temperature and has a characteristic rate of decomposition. This makes it relatively easy to control the resulting chemical reactions by controlling the temperature of the mixture containing the organic peroxide.

The bad thing about organic peroxides from a process safety point of view is that the decomposition process produces excess energy that heats the mixture containing the peroxide (most are sold in a solution with an organic solvent to ease handling). The rising temperature increases the rate at which the free radicals are formed, which raises the amount of energy produced. The cycle proceeds quite quickly once it passes a critical characteristic temperature for that particular compound.

Unless controlled by external cooling, the temperature can easily exceed the boiling point of the solvent, causing pressure to rise in the container until it reaches the point where the container catastrophically fails. While not technically an explosion (no burning has taken place at this point in the process) most observers would characterize the failure of the container as an ‘explosion’. This is especially true since the resulting solvent cloud can ignite when it comes in contact with the atmosphere and a source of ignition.

Safety Measures

I have worked in a couple of different facilities that used organic peroxides in industrial chemical manufacturing operations. Whenever organic peroxides are introduced to a facility a safety review typically comes up with the same safety procedures to try to prevent decomposition incidents and to limit the damage if such an incident does occur. First, an industrial cooler/freezer is obtained to store the material at a temperature well below the critical decomposition temperature. That storage temperature is monitored and alternative cooling methods are identified for when the storage temperature starts to approach the critical temperature. At a facility near Baton Rouge in 2012 when Hurricane Issac approached, we filled the freezer with dry ice before we closed-up the facility and kept it topped with dry ice after the storm passed until power was restored.

The problem is quite different at a facility that manufactures organic peroxide, like this one in Crosby, TX. While I’m sure that they would manage their inventories quite closely, they are going to have a lot more of the material on hand at any given time than a facility that just uses the organic peroxide in a manufacturing process. Thus, they can be expected to have more formal backup measures in place. According to at least one of the articles that I have seen, the plant lost both their primary and two separate backup power supplies to their cooling systems.

The Problem

The problem here is, of course, that Harvey presented a situation beyond the design basis for the facility. I do not know what the facility safety management team used for their flooding risk basis, but I am almost positive that it was not the 40+ inches of rain that the facility received. Flooding is not unexpected in that part of Texas (flat does not begin to describe the topography), but six-foot of standing water was certainly not expected by anyone.

What is interesting here is that the temperature monitoring systems are still working in the storage area. Another of the news reports mentions that the company is still able to watch the temperatures rise. We will ignore for the moment that this situation could be used as a text book example of why facility management wants to see remote access to industrial control systems, but this will almost certainly provide the company the ability to provide emergency response personnel with quite good predictions of when to expect the onset of catastrophic consequences.

There are going to be other chemical safety events associated with the aftermath of Harvey. The Chemical Safety Board has published a brief safety reminder about the special challenges in starting up chemical manufacturing process after a catastrophe like Harvey. While the information there is very valuable, it fails to address the type issue being seen in this unfolding event. There are a large number of other industrial chemicals (monomers come quickly to mind) that have decomposition issues related to lack of cooling. Generally, they are not quite as severe as organic peroxides, but they do provide their own safety issues that will have to be dealt with during the recovery phase from this unusual storm.

ICS-CERT Publishes Three Advisories

Today the DHS ICS-CERT published two control system security advisories for products from Advantech and AzeoTech. They also published a medical device advisory for products from Abbott Laboratories.

Advantech Advisory

This advisory describes nine vulnerabilities in the Advantech WebAccess HMI platform. The vulnerabilities were reported by  Fritz Sands, independent researcher rgod, Tenable Network Security, and an anonymous researcher (all via Zero Day Initiative), and Haojun Hou and DongWang from ADLab of Venustech. Advantech has released a new version to mitigate the vulnerabilities. There is no indication that any of the researchers have been provided an opportunity to verify the efficacy of the fix.

The nine reported vulnerabilities are:

• Improper neutralization of special elements used in an SQL command - CVE-2017-12710;

• Improper restriction of operations within the bounds of a memory buffer - CVE-2017-12708;

• Stack-based buffer overflow -CVE-2017-12706;

• Heap-based buffer overflow - CVE-2017-12704;

• Use of externally-controlled format string - CVE-2017-12702;

• Improper authentication - CVE-2017-12698;

• Incorrect permission assignment for critical resource - CVE-2017-12713;

• Incorrect privilege assignment - CVE-2017-12711; and

• Uncontrolled search path element - CVE-2017-12711

ICS-CERT reports that a relatively low skilled attacker could remotely exploit these vulnerabilities to allow remote code execution or unauthorized access and could cause the device that the attacker is accessing to crash.

NOTE: Earlier this month I mentioned that there were  a large number of ‘pending’ vulnerability reports on Advantech products currently listed on the ZDI web site. These are not those vulnerabilities; those are still apparently being resolved.

AzeoTech Advisory

This advisory describes two vulnerabilities in the AzeoTech DAQFactory HMI. The vulnerabilities were reported by Karn Ganeshen. AzeoTech has produced a new version that mitigates the vulnerabilities. There is no indication that Ganeshen was provided an opportunity to verify the efficacy of the fix.

The two reported vulnerabilities are:

• Incorrect default permissions - CVE-2017-12699; and

• Uncontrolled search path element - CVE-2017-5147

ICS-CERT reports that an authenticated user with local access could exploit the vulnerabilities to escalate their privileges and modify or replace application files.

Abbott Labs Advisory

This advisory describes three vulnerabilities in the Abbot Labs (formerly St. Jude Medical) pacemakers. The vulnerabilities were reported by MedSec. Abbott has produced a firmware update that mitigates the vulnerability. ICS-CERT reports that an unidentified third-party has verified the efficacy of the fix. The FDA Safety Communication notes that the firmware update must be applied during “an in-person patient visit with a health care provider”.

The three reported vulnerabilities are:

• Improper authentication - CVE-2017-12712;

• Improper restriction of power consumption - CVE-2017-12714; and

• Missing encryption of sensitive data - CVE-2017-12716

ICS-CERT reports that an uncharacterized attacker near the patient could exploit the vulnerabilities to gain unauthorized access to a pacemaker and issue commands, change settings, or otherwise interfere with the intended function of the pacemaker.

ICS-CERT Publishes 2016 Vulnerabilities Review

Yesterday the DHS ICS-CERT published their 2016 Annual Vulnerability Coordination Report. This is the second such report from ICS-CERT and many of the same problems exist in this year’s report. Additionally, ICS-CERT further complicates their reporting by making changes to the way they are ‘counting tickets’ in the report so that numbers are not directly comparable to previous years. Oh, yes, they are also reporting both FY 2016 and CY 2016 data, just to throw another monkey wrench into the data analysis comparison problem.

Changes in Data Reporting

The change in the way that ICS-CERT counted tickets makes a fundamental change in the data reported. ICS-CERT explains the change:

The method used to collect and report vulnerability data changed in 2016 from that used in prior years. In 2016, ICS-CERT began reporting metrics data on vulnerability tickets closed within the FY or CY accounting periods. This prevents reported metrics changing based on work accomplished throughout the life of an open ticket. In previous year’s reporting methods, actions taken prior to ticket closure could result in additional follow-on work being required, which in turn could change the reported metrics. It is therefore important to note that some information reported in published alerts and advisories in 2016 may not be included in the FY or CY data cited herein, since the associated vulnerability ticket may still be open. Data for tickets will be included in the reporting period in which the ticket is closed.

While the change in data accounting is a legitimate attempt to make the numbers more meaningful in the long run, it does make 2016 data to the same data from earlier years. This report makes that clear at multiple points in the discussion, but they continue to provide graphics comparing the numbers all the way back to 2010. I predict that a number of agencies and organizations will not make the distinction clear when they report on ICS-CERT vulnerability data.

Two Reports Make a Difference

Figure 3 in this year’s report shows how changes in vulnerability detection may be making major changes in how future reports may look. The final two columns in the table report 2016 data including a “2 ticket anomally”. The report explains these two tickets this way:

“The increase is primarily associated with two (2) tickets closed in 2016 that contain 1,418 and 460 vulnerabilities. Because these 1,878 validated vulnerabilities were associated with a small subset of affected products, there is some concern that these outliers could bias the metrics associated with vulnerability type and Common Vulnerability Scoring System (CVSS) scores. As a result, these are included in the total number of vulnerabilities reported to ICS-CERT; however, this data is not included in other metrics treated throughout this document.”

The two advisories are not named. They were a medical system advisory for a product from CareFusion and another from Philips Medical. Lest one thinks that this is just a medical device issue, there have been two similar large-vulnerability-number advisories already published this year for control system products from Rockwell (62) and Schneider (365). In each case the vulnerabilities come from third-party software or libraries included in the control system product.

ICS-CERT reports that these types of large-scale vulnerability detections have been made possible “by using automated scanning tools”. It would seem that the use of such tools will become more widespread and will almost certainly become a prime tool for researchers working for organizations with criminal or nefarious intent. This is of particular concern since many of these identified vulnerabilities are very old (in cyber years) and many have well known exploits available.

CWE-CVSS Analysis

This year’s report takes a completely different tack in looking at the variety of vulnerabilities reported. Last year much use was made of pie charts and word descriptions of the vulnerabilities. This year ICS-CERT goes to a more formal use of Common Weakness Enumeration (CWE) numbers and replaces multiple pages of pie charts with a single histogram showing the most frequent CWE numbers reported.

ICS-CERT has, instead of giving us greater detail on the types of vulnerabilities, provided more detail on the effectiveness of those vulnerabilities via a look at a compilation of the Common Vulnerability Scoring System (CVSS) data on those vulnerabilities. This includes a table of impact score results and a histogram for access vector analysis.

What is interesting in the impact scoring table is that the NIST CVSS impact categories are not equal size portions of the 10.0 scale used. The ‘critical’ category, for instance, is only one unit wide, while the ‘low’ category is four units wide, while the ‘medium’ and ‘high’ categories are three and two units wide respectively. Thus, if we were to see a random distribution of CVSS impact scores, we would expect to see a disproportionate share in the two lower categories. Instead what we see in the report’s Table 4 is a concentration in the two smaller categories at the dangerous side of the spectrum. This is further reflected in the table’s reported ‘CVSS Statistics’; an average value of 7.8 and a mean value of 7.5. Unfortunately, ICS-CERT again fails to provide a key statistic, the standard deviation, that provides more depth to the statistics reported.

Rating the Report

ICS-CERT has a mixed history with its wide variety of annual reports that it produces. I have very little use for many of the reports that they produce because of their lack of internally consistent definitions and misleading data. This report is fortunately better than average for ICS-CERT. The information is useful for its summary of the types of vulnerability reports that ICS-CERT produced over the year in question and the limited details available from those reports.

Unfortunately, ICS-CERT is still guilty of publishing four-color glossy corporate reports that do more to confuse than to clarify. The unexplained combining of fiscal year and calendar year reporting provides no new insights into the process. The changing of definitions of what constitutes a reportable ticket makes analysis of year-to-year trends questionable, but these trends will inevitably be carefully misreported in the press and abused by politicians and activists.

I did like the addition of a start to look at the numerical data found in CVSS data. More of that should be included in next year’s report. Unfortunately, reporting that data is going to have to include some sort of statement about the consistency of that data. While the CVSS system is an attempt to provide repeatable information about vulnerabilities, it is not a physical measure. This means that there is some bias in that data, depending on who scores the vulnerability. If ICS-CERT is providing the individual scores used in the system, that bias is at least somewhat consistent. If vendors are the source of the scoring, the bias will be much less structured. The data source needs to be disclosed.

In any case, I do recommend that those with an interest in the security of industrial control systems should read this report. Just be careful on how you use the inconsistent data.

ICS-CERT Publishes Two Advisories

Today the DHS ICS-CERT published two control system security advisories for products from Rockwell and Westermo. The Rockwell advisory was originally published on the NCCIC Portal on July 27, 2017.

Rockwell Advisory

This advisory describes an SNMP remote code execution vulnerability in the Rockwell Allen-Bradley Stratix and ArmoStratix. The vulnerability was originally reported by Cisco and subsequently self-reported by Rockwell as affecting their switches. Rockwell has produced a newer version of one of the affected product families that mitigates the vulnerability. Rockwell has produced compensating controls for the remainder of the affected products pending further updates.

ICS-CERT reports that a relatively low skilled attacker could remotely exploit the vulnerability to execute code on an affected system or cause an affected system to crash and reload.

As always when these types of vulnerabilities from third party systems are reported, we have to ask what other vendors have also been using the same system and thus have the same vulnerabilities?

Westermo Advisory

This advisory describes three vulnerabilities in the Westermo MRD-305-DIN, MRD-315, MRD-355, and MRD-455 routers. The vulnerabilities were originally reported by Mandar Jadhav from Qualys Security. Westermo has produced a new firmware to mitigate the vulnerabilities. There are no indications that Jadhav was provided an opportunity to verify the efficacy of the fix.

The three reported vulnerabilities are:

• Cross-site request forgery - CVE-2017-12703;

• Hard-coded credentials - CVE-2017-12709; and

• Use of hard-coded cryptographic key - CVE-2017-5816

Westermo reports in their security advisory [.PDF Download] that a fourth vulnerability was reported by the researcher, but the default user account identified is not interactive and is not accepted in the existing management interfaces and is therefore not an immediate attack vector. It has, however, been removed from the updated firmware.

ICS-CERT reports that a relatively low skilled attacker could remotely exploit the vulnerabilities to obtain hard-coded cryptographic keys, hard-coded credentials, or trick a user into submitting a malicious request, resulting in the attacker gaining unauthorized access to the device and running arbitrary code.

DHS Publishes Regulatory Agenda

Today DHS published their section of the Administration’s Semiannual Regulatory Agenda in the Federal Register (82 FR 40290-40299). This provides some additional information on some of the regulatory activities planned by the Administration that were listed in the Unified Agenda last month.

Items that may be of specific interest to readers of this blog include:

• Chemical Facility Anti-Terrorism Standards (CFATS);

• Ammonium Nitrate Security Program;

• Updates to Maritime Security; and

• Security Training for Surface Transportation Employees

There really is not much in the way of new information here. DHS has provided ‘expected dates’ for the next rulemaking action for the CFATS update (10-17) and the TSA security training rule (09-18). Since these ‘expected dates’ have little or no relationship to actual future actions these dates cannot really be classified as ‘new information’.

The only really new information here is that the Coast Guard’s Updates to Maritime Security has been officially removed from the regulatory agenda. This rulemaking activity has never really gone anywhere, bouncing back-and-forth between the Current Agenda and the Long-Term Agenda on the Unified Agenda. Even the abstract that was listed in the last Obama Administration Unified Agenda was short on specifics of what the rulemaking would have included.

HR 3411 Introduced – Automated Vehicle Advisory Council

Last month, as part of a series of bills on highly automated vehicles that were introduced on the same day as HR 3388 was revised by the House Energy and Commerce Committee, Rep. Costello (R,PA) introduced HR 3411. This bill would require DOT to establish the Automated Driving System Cybersecurity Advisory Council. An identical provision was included as §9 in HR 3388.

The Council

The Council would be established under the provisions of the Federal Advisory Committee Act (5 USC Appendix). It would consist of 15 to 30 members representing “business, academia and independent researchers, State and local authorities, safety and consumer advocates, engineers, labor organizations, environmental experts, a representative of the Na1tional Highway Traffic Safety Administration, and other members determined to be appropriate by the Secretary” {§1(b)}.

The Council would advise the DOT Secretary on “cybersecurity for the testing, deployment, and updating of automated driving systems with respect to supply chain risk management, interactions with Information Sharing and Analysis Centers and Information Sharing and Analysis Organizations, and a framework for identifying and implementing recalls of motor vehicles or motor vehicle equipment” {§1(e)}.

Moving Forward

As with the other two bills that I have discussed in this series (HR 3401 and HR 3407), it looks like this bill was introduced so that key components of HR 3388 could still be passed by the House if the Republican leadership determined that some of the more controversial (and non-cybersecurity related) provisions of the bill would prohibit consideration of HR 3388. If the leadership decides not to move forward with HR 3388 I expect most of this series of bills would be considered in a single day under the suspension of the rules provision. That would allow for limited debate and no floor amendments. I suspect that the three cybersecurity related bills would pass with a substantial bipartisan majority.

Commentary

The DOT has a long history of using these advisory committees to produce consensus rulemakings on deeply technical topics. The involvement of industry representatives and various activist organizations helps to ensure that a multitude of voices are heard in the development process.

Having said that, I am disappointed that two groups were not specifically identified in the list of entities to be included. I would have liked to see Automotive ISAC specifically listed as a central industry group that should be represented. On the government side, I would have liked to have seen the DHS ICS-CERT specifically mentioned as an agency (along with the current mention of NHTSA) that would have a representative on the Council. I think that these two would be important additions to provide specific cybersecurity expertise for these the complex control systems associated with highly automated vehicles.

The Secretary still has a great deal of leeway to add representatives of these two organizations to the Council, but a Congressional mandate for at least the ICS-CERT would have made the inter-departmental appointment much easier.

ICS-CERT Publishes 3 Advisories

Today the DHS ICS-CERT published three control system security advisories for products from SpiderControl (2) and Automated Logic Corporation.

SCADA Web Server Advisory 

This advisory describes a path traversal vulnerability in the SpiderControl SCADA Web Server. The vulnerability was reported by Karn Ganeshen via the Zero Day Initiative (ZDI). SpiderControl has produced a new version that mitigates the vulnerability. There is no indication that Ganeshen has been provided an opportunity to verify the efficacy of the fix.

ICS-CERT reports that a relatively low skilled attacker could remotely exploit the vulnerability to gain read access to system files through directory traversal.

SCADA MicroBrowser Advisory

This advisory describes a stack-based buffer overflow vulnerability in the SpiderControl SCADA MicroBrowser. The vulnerability was reported by Karn Ganeshen via ZDI. SpiderControl has produced a new version that mitigates the vulnerability. There is no indication that Ganeshen has been provided an opportunity to verify the efficacy of the fix.

ICS-CERT reports that a relatively low skilled attacker could remotely exploit the vulnerability to gain access to the system, manipulate system files, and potentially render the system unavailable.

Automated Logic Advisory

This advisory describes three vulnerabilities in the ALC WebCTRL, i-Vu, and SiteScan Web. The vulnerabilities were reported by Gjoko Krstic from Zero Science Lab. ALC has produced patches that mitigate the vulnerabilities. There is no indication that Krstic has been provided an opportunity to verify the efficacy of the fix.

The three reported vulnerabilities are:

• Unquoted search path or element - CVE-2017-9644;

• Path traversal - CVE-2017-9640; and

• Unrestricted upload of file with dangerous type - CVE-2017-9650

ICS-CERT reports that a relatively low skilled attacker could remotely exploit the vulnerabilities to elevate his or her privileges to execute arbitrary code on the system.

TSA Publishes EXIS ICR Revision Notice

Today the DHS Transportation Security Administration (TSA) published a 60-day information collection request (ICR) notice in the Federal Register (82 FR 39900-39901) seeking to renew and update their ICR supporting the Exercise Information System (EXIS).

The TSA is estimating an 19.8% annual increase in EXIS participants. This is significantly less than the 67% increase that TSA estimated in their previous EXIS ICR. Still an increase from 364 participants at the last ICR submission to the apparent 6581 used as a base for this estimate in just three years is impressive.

There is no explanation on how TSA reached this 19.8% growth rate estimate. In fact, the 19.8% rate was not actually provided by TSA, I had to calculate it from the numbers provided by TSA in the notice. This is a common problem with the ICR submissions made by TSA (and many other federal agencies). I wish that more agencies prepared ICR submissions in the same level of detail that the DHS Infrastructure Security Compliance Division has been using in their numerous ICR submissions for the CFATS program.

The TSA is soliciting public comments on this ICR revision. Comments may be emailed to TSA (TSAPRA@dhs.gov). Comments should be received by TSA by October 23^rd, 2017.

Commentary

The TSA continues to choose not to use the Federal eRulemaking Portal to manage the comments on their EXIS ICRs. This has the perhaps unintended consequence that the public is not privy to whatever comments are made on the ICR. We have to trust that the TSA is not ignoring any serious concerns raised in the comment process.

For example, the supporting information page on the previous ICR submission shows that there were three public comments submitted. Two of those submissions were submitted years before the previous 60-day ICR was published. Both, were actually submitted for the first ICR for the program. The apparent 3^rd comment is nothing more than a copy of an email the respondent received about the 60-day ICR notice. To be fair the inclusion of the earlier comments is just as likely to be an error made by the OMB’s Office of Information and Regulatory Affairs as one made by TSA.

For all intents and purposes, it looks like there were no comments received on the previous ICR. While that is not an unusual occurrence, we have no independent method of verifying that apparent fact.

BTW: I will be emailing a copy of this post as a comment on this ICR.

HR 3407 Introduced – Automated Vehicles Cybersecurity

Last month Rep. Kinzinger (R,IL) introduced HR 3407, which would add a requirement to 49 USC for manufacturers of highly automated vehicles to provide a cybersecurity plan for those vehicles. This is part of a series of bills that were introduced by members of the House Energy and Commerce Committee that could serve as alternatives to the passage of the amended HR 3388 that was adopted by the Committee on July 27^th.

This bill would provide the same new §30130, Cybersecurity of automated driving systems, found in the revised HR 3388. I discussed this section in detail in my earlier blog post on HR 3388.

Commentary

I have heard it suggested that this series of bills may have actually preceded the amendment of HR 3388, rather than, as I explained in my post on HR 3401, serving as an alternative to passing the more complex bill to ensure that key provisions make it into law. There are two different items in this bill that support my contention. First, the definitions found in this bill {§2(b)} are identical to those provided both in HR 3388 {§13(a)} and HR 3401 {§1(b)}. This shows significant staff coordination during the crafting of these three bills.

Second §1(a) of this bill is identical to §5(a) of HR 3388. They both introduce the proposed §30130, saying:

“IN GENERAL.—Chapter 301 of subtitle VI of title 49, United States Code, is amended by inserting after section 30129 (as added by section 4) [emphasis added] the following new section:”

There is no section 4 in this bill; there is no §30129 mentioned in this bill. What this clearly means is that §1(a) of this bill was lifted en toto from the revised HR 3388. The staff did not do a really good job of cutting (editing) and pasting when they prepared this bill. It does provide clear insight, however, into the order of crafting HR 3388 and the subsequent series of bills introduced on the same topic.

Chlorine Incident Kills Two

This weekend there was an unusual incident in Mississippi where an auto accident involved a rural water treatment works. It resulted in the breach of a chlorine gas cylinder and the death of the two occupants of the car. As is usual, the details about the accident are sketchy, but with the help of Google Maps® and some industry knowledge, we can ferret out some lessons.

The Facility

The news article reports that two people were in a stolen car driving down a rural road when the “car slammed into the utility station, rupturing a large tank of chlorine”. In rural America, the only kind of ‘utility station’ that houses chlorine gas is a local drinking water pumping station. Searching Google Maps we can find that utility station here, on the west side of the road.

Looking at it on Street View®, we see a large, white, horizontal tank within a chain-link fenced enclosure. There is a small box-like structure, a pipe, a well-pump and an electric service pole with a nearby electrical panel.

I suspect that the reporter thought that the large white tank was a chlorine tank, but that is certainly not the case. First off, that tank is way too large; it would contain multiple years’ worth of chlorine gas for a facility this size. Second, chlorine gas is delivered in portable cylinders. For a facility of this size, that is typically a 50-pound cylinder that looks somewhat like a welding-gas cylinder. Two such cylinders will be found in the white box to the right of the tank; the one in current use and the backup for when the first is emptied. By the way, that large tank is a water tank, providing the pumping station with surge capacity.

The Accident

Looking at the map, I would guess that the car was proceeding north on Palmer Creek Drive, probably at a high-rate of speed. Instead of making the curve to the right, it continued straight and hit the large water tank. As part of the collision either the chlorine control box, or more likely the chlorine gas line from the box to the water system was damaged, releasing a small yellowish green cloud of chlorine into the atmosphere. It is not clear (and will not be until the autopsies are complete) if the chlorine gas, the injuries from the collision of a combination of the two caused the deaths of the occupants of the car.

There were chlorine gas related injuries to ‘several responding deputies and at least one fire fighter’. The Street View data is from 2013 and I cannot see any chlorine gas warning signs. It is quite possible that deputies responding to the accident did not know about the chlorine gas at the facility and approached the scene too closely. Fortunately, the small cloud would have dispersed enough to leave it a less-than-deadly concentration that they walked into, so the injuries were reportedly fairly minor.

Local residents were instructed to shelter-in-place in an abundance of caution. Again, with the small amount chlorine gas present, there was almost certainly no more danger at nearby residences than would be found in sniffing at the top of an open household bleach container.

Commentary

Since the incident happened on Saturday night it was almost certainly a joy-riding accident. If it had happened twelve hours later, there would have been a very remote chance of it being an attack. There is a church located next to the treatment works it would have been remotely possible that the incident was an inept attempt to gas the congregation.

It would have been fairly easy to accomplish that type of attack by entering the facility with a pair of bolt cutters and a pipe wrench. But, again, releasing the chlorine gas at the facility would have resulted in a less than deadly gas cloud at the church, even if the breeze was blowing in the correct direction.

Of course, an even more effective attack could have been executed by removing the gas cylinders from the facility and then piping the connection into any sort of facility air-handling equipment that the attackers desired. Depending on the size of the facility, a lethal concentration of chlorine gas could possibly be introduced fast enough to cause some deaths. A large number of serious injuries and panic could certainly be an expected result.

There are no requirements under either the EPA water facility security regulations or the DHS Chemical Facility Anti-Terrorism Standards for physical security of the chlorine tanks at facilities of this sort; the facilities are just too small to make regulations cost effective. As is fairly typical, the padlocked gate on the chain-link fence and a padlock on the chlorine control box are the only security measures in place. Even if video surveillance or intrusion detection devices were in place, the response time to such rural locations is long enough to allow perpetrators to successfully leave the facility.

Bills Introduced – 08-18-17

Yesterday, both the House and Senate met in pro forma sessions. There were ten bills introduced, including one in the Senate. Senate rules do not normally allow for bill introductions during pro forma sessions, but an exception was made in this case. Interestingly, that is one bill that may be of specific interest to readers of this blog:

S 1761 An original bill to authorize appropriations for fiscal year 2018 for intelligence and intelligence-related activities of the United States Government, the Community Management Account, and the Central Intelligence Agency Retirement and Disability System, and for other purposes. Sen. Burr, Richard [R-NC]

As is usual with authorization bills, I will be watching this for cybersecurity mentions.

ICS-CERT Publishes an Advisory and Three Updates

Today ICS-CERT published a medical device security advisory for products from Philips. Three previously published industrial control system security advisories for products from Siemens (2) and Marel were updated with new information.

Philips Advisory

This advisory describes two vulnerabilities in the Philip DoseWise Portal (DWP) web application. The vulnerability was self-reported by Philip. ICS-CERT is reporting that Philip will be supplying a new product version later this month to mitigate the vulnerability.

ICS-CERT reports that an uncharacterized attacker could remotely exploit these vulnerabilities to gain access to the database of the DWP application, which contains patient health information (PHI). Potential impact could therefore include compromise of patient confidentiality, system integrity, and/or system availability.

NOTE: the Philips security page notes that the discovery of these vulnerabilities was based upon the findings of a customer submitted complaint and vulnerability report.

Marel Update

This update provides additional information on an advisory that was originally published on March 4^th, 2017. The new information includes:

• Clarification of affected equipment;

• Adds a notice of an upcoming (10-1-17) update for the Pluto based systems;

• Explains that the M3000 terminal based products reached the end of their supported life in 2012;

• Added a new improper access control vulnerability to the advisory; and

• Added a link to the recently published Marel security notification

Comment: In the original advisory, the stand-alone statement “Marel has not produced an update to mitigate these vulnerabilities” seemed to indicate that Marel was not being cooperative. It now seems more that they were being slow to move forward and perhaps did not understand the need to communicate with ICS-CERT. Either that, or the publication of the ICS-CERT advisory was a slap in the corporate face that woke Marel up and got them to work on the vulnerability. I cannot tell which (properly so) from the ICS-CERT publication. In either case mitigations appear to be on the way.

It might be helpful if ICS-CERT had some sanction available that could provide some sort of intermediate push between doing nothing and publishing a zero-day that could put system owners at risk. The goal is to get a mitigation in place as soon as practicable and ICS-CERT has no authority to provide impetus to require recalcitrant vendors to do something.

PROFINET 1 Update

This update provides additional information on an advisory that was originally published on May 9^th, 2017 and updated on June 15^th, 2017, on June 20^th, 2017, on July 6^th, 2017, and again on July 25^th, 2017. The update provides new affected version information and mitigation links for:

• STEP 7 - Micro/WIN SMART: All versions prior to V2.3;

• SIMATIC Automation Tool: All versions prior to V3.0; and

• SINUMERIK 808D Programming Tool: All versions prior to V4.7 SP4 HF2

PROFINET 2 Update

This update provides additional information on an advisory that was originally published on May 9^th, 2017 and updated on June 15, 2017, and again on July 25^th, 2017. The update provides new affected version information and mitigation links for:

• SIMATIC CP 1543SP-1, CP 1542SP-1 and CP 1542SP-1 IRC: All versions prior to  V1.0.15,

• SIMATIC ET 200SP: All versions prior to  V4.1.0,

• SIMATIC S7-200 SMART: All versions prior to V2.3,

• SINUMERIK 828D – V4.5 and prior: All versions prior to V4.5 SP6 HF2

Missing Siemens Updates and Advisories

ICS-CERT has yet to publish update or advisory for the following TWITTER® announcements from Siemens:

An advisory has been updated: SSA-286693: Vulnerabilities in Laboratory Diagnostics Products from Siemens; Aug 7^th, 2017;

A new advisory has been published: SSA-131263: SMBv1 Vulnerabilities in Mobilett Mira Max from Siemens Healthineers; Aug 7^th, 2017

NHTSA Sends Automated Vehicle Guidance to OMB

Yesterday the DOT’s National Highway Transportation Safety Administration (NHTSA) sent their Voluntary Guidance on Automated Driving Systems document to the OMB’s Office of Information and Regulatory Affairs (OIRA) for review. Guidance documents are not normally described in the Unified Agenda, so there is no public indication about what DOT will be including in this guidance document.

NHTSA hosted a series of public discussions on the topic last year. They also published an automated vehicles technology guidance document and a vehicle-to-vehicle notice of proposed rulemaking (NPRM) last year. The later document did include cybersecurity requirements.

Make America Secure and Prosperous Appropriations Act, 2018

The House Rules Committee announced today that is working on massive, multi-department spending bill to be considered when the House returns from summer recess. It is a move to cut short the spending process so that there may be a chance to pass a government spending bill before the September 30^th deadline. The Rules Committee is calling for submission of amendments by 10:00 am on August 25^th.

The combined bill is a complete re-write of HR 3354, the Department of the Interior, Environment, and Related Agencies Appropriations Act, 2018. The draft language incorporates most of the language from that bill and:

HR 3268 – Agriculture, Rural Development, Food and Drug Administration, and Related Agencies Appropriations Act, 2018;

HR 3267 – Commerce, Justice, Science, and Related Agencies Appropriations Act, 2018;

HR 3280 – Financial Services and General Government Appropriations Act, 2018;

HR 3355 – Department of Homeland Security Appropriations Act, 2018;

HR 3358 – Departments of Labor, Health and Human Services, and Education, and Related Agencies Appropriations Act, 2018;

HR 3362 – Department of State, Foreign Operations, and Related Programs Appropriations Act, 2018; and

HR 3353 – Transportation, Housing and Urban Development, and Related Agencies Appropriations Act, 2018

The House has already passed a combined spending bill for the other four spending bills not covered above. That bill, HR 3219, included the following spending bills:

• The Department of Defense Appropriations Act, 2018;

• The Legislative Branch Appropriations Act, 2018;

• The Military Construction, Veterans Affairs, and Related Agencies Appropriations Act, 2018; and

• The Energy and Water Development and Related Agencies Appropriations Act, 2018.

Combining eight spending bills into one big package could greatly reduce the amount of time required on the floor of the House for debate. I expect the Rules Committee would come up with a structured rule, with a few hundred floor amendments. The bill would almost certainly be passed in the House in a single week. The big question is whether or not the Senate would be allowed to take up the giant bill. Depending on what riders make it into the House passed version, I could almost expect to see an unusual amalgam of liberals and conservatives combining to block the moderate majority from considering and passing the bill.

ICS-CERT Publishes Two Advisories

Yesterday the DHS ICS-CERT published a medical device security advisory for products from BMC Medical and 3B Medical (one advisory). They also published a control system security advisory for products from Advantech

BMC Medical Advisory

This advisory describes an improper input validation vulnerability in the Luna continuous positive airway pressure (CPAP) therapy machine produced jointly by BMC Medical and 3B Medical. The vulnerability was reported by MedSec. Newer versions (after July 2017) have had the problem corrected; ICS-CERT reports that the company’s do not plan on providing mitigation measures for ‘older’ (before July 2017) machines.

ICS-CERT reports that a relatively low skilled attacker with adjacent network access could exploit the vulnerability to cause a crash of the device’s Wi-Fi module resulting in a denial-of-service condition affecting the Wi-Fi module chipset. This does not affect the device’s ability to deliver therapy.

NOTE: Buyers of CPAP devices should take careful note of the lack of post-production cybersecurity support demonstrated for this brand of devices.

Advantech Advisory

This advisory describes a heap-based buffer overflow vulnerability in the Advantech WebOP operator panels. The vulnerability was reported by Ariele Caltabiano (kimiya) via the Zero Day Initiative. ICS-CERT reports that Advantech was unable to verify the validity of this vulnerability. (NOTE: this obviously means that no mitigation measures appear to be forthcoming.)

ICS-CERT reports that a relatively low skilled attacker with uncharacterized access could use publicly available exploits to exploit this vulnerability to cause the target device to crash and may allow arbitrary code execution.

NOTE: There are a large number of ‘pending’ vulnerability reports on Advantech products currently listed on the ZDI web site.

ISCD Updates CFATS Knowledge Center

Today the DHS Infrastructure Security Compliance Division (ISCD) updated the Chemical Facility Anti-Terrorism Standards (CFATS) Knowledge Center by adding a link to a new CFATS fact sheet for colleges and universities and revised four frequently asked questions (FAQ) (according to the ‘Latest News’ blurb posted today on the Knowledge Center).

Colleges and Universities

The Colleges and Universities brochure is an update of a tri-fold brochure that was originally published in December 2010. The new brochure provides a brief overview of the CFATS program including a very brief description of the Top Screen reporting requirements. There is more detail in the new version and provides a number of important links to CFATS documents.

The one major shortcoming of the brochure is that, while it briefly describes chemicals of interest (COI) categories and explains that the list can be found in ‘Appendix A of the CFATS regulation’ there is no link to list of COI that is provided on the CFATS landing page, nor are the CFATS regulations actually listed (6 CFR 27).

New FAQs

The four ‘revised’ FAQ’s are:

#1274 How can a person contact the Chemical Security Assessment Tool (CSAT) Help Desk?

#1288 How does a facility count the amount of a release-flammable Chemical of Interest (COI) in a mixture with a National Fire Protection Association (NFPA) rating of 4?

#1606 How does a person access a Chemical Security Assessment Tool (CSAT) letter that needs to be acknowledged?

#1785 How does the Department of Homeland Security (DHS) Notify a Facility of Its Tiering?

The revised #1274 removes the mailing address [Infrastructure Security Compliance Division, Office of Infrastructure Protection, ATTN: CSAT, Department of Homeland Security, Building 5300, MS 6282, PO Box 2008, Oak Ridge, TN 37831-6282] and the messenger service delivery address [Infrastructure Security Compliance Division, Office of Infrastructure Protection, ATTN: CSAT, Department of Homeland Security, Building 5300, MS 6282, 1 Bethel Valley Road, Oak Ridge, TN 37831-6282] from the modes of contact for the CFATS Help Desk. I have no idea whether or not those old addresses are still good; but if they are, ISCD does not apparently want them used.

The revised #1288 adds regulatory references [§27.203(b) and §27.204(a)(2)] for the answer and a link to just the first reference. I have provided the link to the second.

FAQ #1606 is actually a new FAQ number, but the question and answer are very similar to an older FAQ (#1662) which is no longer on the current FAQ list (.PDF download). The new FAQ does not include any information (which was included in #1662) about a requirement to be CVI (Chemical-terrorism Vulnerability Information – the protocol for protecting the sensitive but unclassified information associated with the CFATS program) trained to be able to view/download the letter. Nor does the new FAQ mention that an Adobe Reader will be necessary to open the letter. NOTE: #1662 was still on the current FAQ list as of 8-4-17; the last time changes were made to the FAQ list.

FAQ #1785 is also a new FAQ number. There was an earlier article on the CFATS Knowledge Center (#1610) that addressed some of this information, but that article was prepared in 2010 and included copious descriptions of the old tiering process that was supplanted by CSAT 2.0 and the new Risk Assessment process. That article was removed sometime in early April of this year. The new FAQ very briefly mentions the tiering process and notes that facilities will be notified via the Chemical Security Assessment Tool (CSAT) that a tiering notification letter is available. It then briefly describes how to access that notification letter; and this time that discussion does include a mention of the CVI training requirements.

HR 3401 Introduced – Automated vehicles

Last month Rep. Schakowsky (D,IL) introduced HR 3401, a bill that would require the DOT’s National Highway Transportation Safety Administration (NHTSA) to establish new automotive safety standards for highly automated vehicles. This bill was introduced the same day that the House Energy and Commerce Committee  amended HR 3388 to do the same thing.

This bill is nearly identical to Section 4 of the revised HR 3388 adopted by the Committee. There is one area where the paragraph numbering is slightly different, but there are no substantive differences between the requirements. It would amend 49 USC by adding a new §30129, Updated or new motor vehicle safety standards for highly automated vehicles.

It would require DOT to “issue a final rule requiring the submission of safety assessment certifications regarding how safety is being addressed by each entity developing a highly automated vehicle or an automated driving system” {new §30129(a)(1)}.

It would also require DOT to submit to Congress a regulatory and safety priority plan designed to accommodate the development and deployment of highly automated vehicles while ensuring “the safety and security of highly automated vehicles and motor vehicles and others that will share the roads with highly automated vehicles” {new §30129(c)(1)}. That plan would include a requirement for NHTSA to “identify elements that may require performance standards including human machine interface and sensors and actuators, and consider process and procedure standards for software and cybersecurity as necessary” {new §30129(c)(2)(B)}.

Moving Forward

Ms. Schakowsky is the ranking member of the Digital Commerce and Consumer Protection Subcommittee of the House Energy and Commerce Committee. Normally this would probably allow her to have this bill considered in Committee. In this case, however, because this bill was introduced the same day that HR 3388 was, it seems as is the bill was introduced as a backup measure to ensure that the safety standards provisions of this bill could end up being considered separately from the remainder of the provisions of the larger bill if that bill was determined to be too controversial to be considered on the floor of the House.

I suspect that this bill will not see any further action until the House Leadership determines whether or not HR 3388 will make it to the floor. If it does not, this bill will likely be moved to the floor for a vote without going through a separate review by the Committee.

Commentary

I did not mention the cybersecurity requirements described above in my discussion of HR 3388 because they were duplicative of the requirements that I described but were not as expansive as the cybersecurity requirements in §5 of HR 3388.

What is important (and unusual from a cybersecurity perspective) here is that both bills would require the establishment for safety standards for HMI, sensors and actuators. It does not include any guidance on what those standards would include, but that would normally be expected to be developed by the technical experts at NHTSA. But this would end up being where the Federal government took its first crack at developing safety (and perhaps specific cybersecurity) standards for key components found in (almost by definition) these critical components of control systems. Those standards could end up being ground breaking regulatory standards for the ICS industry.

OMB Approves PHMSA Shipping Papers ICR Revision

Last Friday the OMB’s Office of Information and Regulatory Affair approved the Pipeline and Hazardous Materials Safety Administration’s (PHMSA) information collection request (ICR) revision supporting requirements for hazardous material shipping papers and emergency response information. This ICR was filed in support of the most recent international harmonization of PHMSA hazardous material shipping regulations.

According to the abstract included in the recent notice, the ICR made the following changes to the ICR burden:

“This rulemaking reduced the burden to shippers by removing the requirement to provide a lithium battery handling document when shipping smaller lithium cells and batteries. While the rulemaking decreased the burden overall, the requirement that shippers communicate prototype or low production run battery shipments on a shipping paper resulted in an increase. The rulemaking also added new marine pollutant entries in Appendix B of § 172.101.”

While OIRA did not require any changes to the approved ICR, they did put PHMSA on notice about additional requirements that would be necessary for the next renewal of this ICR next spring. They noted that:

If PHMSA has not published a regulatory notice in the Federal Register seeking public comment on paperless hazard communication by the time PHMSA must publish a 60 day notice to extend OMB approval of this collection, PHMSA should include at least the following information in the 60 and 30 day notices for extending approval of this collection, in addition to the standard information required by the PRA:

• Identification and explanation of any technical and other barriers to paperless hazard communication by mode and environment (e.g., rural, urban) if applicable, and requests for public comment on ways to address those barriers;

• Identification and explanation of any safety problems associated with paperless hazard communication that are not present with paper-based hazard communication;

• Identification of safety, business and any other benefits associated with paperless hazard communication, by mode if possible; and

• At least rough estimates of the potential burden and cost reduction from fully allowing paperless hazard communication, by mode if possible, the methodology/inputs for the estimates, and request public comment on those estimates.

PHMSA will probably have to publish the 60-day ICR notice in the next couple of months to be able to get the comment period and time to review the responses before it becomes necessary to publish the 30-day notice before April 30^th, 2018.

Commentary

This is not the first time that the Trump Administration’s OIRA has provided instructions to regulators to proactively move to electronic submission of information. This continues a regulatory theme that we have been seeing for the last couple of administrations. Not only will the electronic data collection reduce the data handling costs for the government, but it should provide at least some time burden reduction for industry.

As with my earlier post this morning, I do have some concerns about the cybersecurity protections for the data exchange process. If the data is submitted via email (a not very effective form of electronic data submission), this would provide a large number of emails (with attachments) from probably unauthenticated and unknown senders; a very sure method of increasing the general attack surface at PHMSA.

If, on the other hand, the data is directly provided to the database via a public web page, the security of that data can be subverted if the cybersecurity of the database (and the submission page) has not been properly implemented. More importantly, the cybersecurity protections need to be included in the design of the application and periodically reviewed and updated. This is an additional cost associated with electronic data submission that appears to be at least some what overlooked in the discussion of paperless government innovations.

EPA Sends Hazwaste Electronic Manifest Final Rule to OMB

On Saturday, the Environmental Protection Agency sent the final rule for the implementation of the Hazardous Waste Electronic Manifest rule to the OMB’s Office of Information and Regulatory Affairs (OIRA) for approval. This bill implements the fee setting and implementation date requirements of the Hazardous Waste Electronic Manifest Establishment Act (PL 112-195).

Commentary

With the Trump Administration’s concern about the ‘cost of regulation’ and how it effects business, it will be interesting to see how this final rule is being implemented. The congressional requirements for establishing the fund {42 USC 6939g(c)} are fairly comprehensive, leaving little room for fee reductions. There were no small business exceptions provided for in the authorizing legislation.

Since the authorizing legislation was written in 2012, there are no specific provisions requiring any cybersecurity protections of the E-Manifest system. Cybersecurity just was not on the Congressional radar at that point. It will be interesting to see if there are any attempts by the EPA to address such issues in this regulation.

CG Publishes CSF Profile Document for Passenger Operations

Earlier this week the Coast Guard published on their Home Port web page (https://homeport.uscg.mil > Cybersecurity > Cyber News > Passenger Operations Cybersecurity Framework Profile Review; sorry the CG does not use links on its HomePort) a new cybersecurity guidance document and requested public comments on the document. The new document is the “Content Preview of the Passenger Operations Cybersecurity Framework Profile”. The Coast Guard’s blog did provide a real link to the document.

The Profile

This document is an attempt by the CG to help affected organizations (US passenger vessel operations) implement the National Institute of Standards and Technology’s (NIST) Cybersecurity Framework (CSF). According to the CG’s blog:

“A profile implements the NIST Cybersecurity Framework, which was developed in 2014 to address and manage cybersecurity risk in a cost-effective way based on business needs and without placing additional regulatory requirements on businesses. The profile is how organizations align the Framework’s cybersecurity activities, outcomes, and informative references to organizational business requirements, risk tolerances, and resource allocations.”

The Profile is a .PDF document that first provides a list of 13 passenger vessel mission objectives with a brief description of each. These objectives include:

• Maintain human safety;

• Maintain marine safety and resilience;

• Maintain environmental safety;

• Maintain guest support and basic hotel services;

• Maintain regulatory compliance;

• Assure secure communications by function and mode;

• Optimize guest experience and value;

• Maintain supply chain and turnaround;

• Disembarking, embarking, and turnaround;

• Coordinate port operations;

• Assure (optimize) lifecycle asset management;

• Maintain passenger information and accounting systems; and

• Manage, monitor and maintain non-guest-facing office technology

The Profile then provides a CSF matrix showing each of the functions, categories and subcategories listed in the CSF with a listing for each of the 13 mission objectives listed above; categorizing them as either ‘High Priority’, ‘Moderate Priority’ or ‘Other Implemented Categories’. It is interesting that they do not use the pejorative term ‘Low Priority’ in the categorization.

Public Comments

The Coast Guard is asking for public comments on the Profile. They have provided a comment submission form (download .XLS) very similar to the format used by NIST to request comments during the development of the CSF. Comments can be emailed to  HQS-SMB-CG-FAC-CYBER@uscg.mil. Comments should be submitted by September 7^th, 2017.

Commentary

I really do like the general format of this Profile document. The mission statement provides a general overview of what the affected organizations are supposed to be attempting to accomplish in the operations. Tying that back into the CSF matrix with a prioritization scheme provides a workable management tool for implementation of the CSF.

There are two specific areas where ‘process control systems’ (a very interesting substitute for the term ‘industrial control systems’ that I would typically use) are prominently discussed in the Mission Objective portion of the Profile. First in the description of ‘Maintaining Human Safety’ it starts: “Recognizing cybersecurity-effects on process control systems that impact personnel safety.” Similarly, in ‘Maintain environmental safety’ it addresses cybersecurity effects “on process control systems that impact environmental safety”. Additionally, there are at least two other mission objectives that include mention of “manage support systems security”, a clear reference to various process control systems.

I am more than a little surprised at the prioritization of these ‘process control systems’ in many areas of the CSF implementation matrix, but that may be more of reflection on my lack of familiarity with passenger vessel operations than anything else. I was pleased, however, to see both the human safety and environmental safety objectives receive ‘high profile’ rankings under two of the Risk Assessment subcategories:

ID.RA -3: Threats, both internal and external, are identified and documented; and

ID.RA - 5: Threats, vulnerabilities, likelihoods, and impacts are used to determine risk

Unfortunately, that pleasure was more than offset by the ‘other’ ranking across the board for the “ID.RA -2: Threat and vulnerability information is received from information sharing forums and sources” in the same Risk Assessment Category. That hardly supports the ‘high profile’ rankings noted above.

I really do recommend that everyone with an interest in maritime safety (not just passenger vessels) take a good look at this 16-page document. It provides an interesting perspective on CSF implementation in an often-overlooked area of operations. Likewise, the control system security community (particularly those with maritime experience) should also give the document a good review. The Coast Guard deserves a wide variety in the thoughtful comments it receives on this Profile.