Tuesday, October 17, 2017

ICS-CERT Publishes Progea Advisory

Today the DHS ICS-CERT published a control system security advisory for the Progea Movicon SCADA/HMI. It describes two vulnerabilities in the product. The vulnerabilities were reported by Karn Ganeshen. Progea has only provided a generic Microsoft workaround for DLL hijacking at this point. ICS-CERT does not report any further scheduled response.

The two reported vulnerabilities are:

• Uncontrolled search path element - CVE-2017-14017; and
• Unquoted search path or element - CVE-2017-14019

ICS-CERT reports that a relatively low skilled attacker could remotely exploit the vulnerabilities to allow privilege escalation or arbitrary code execution.

HR 4038 Introduced – DHS Oversight

Last week Rep. McCaul introduced HR 4038, the DHS Accountability Enhancement Act. The bill would remove the limited authority that the DHS Secretary has to reorganize the Department.

The bill would repeal 6 USC 452. That section allows the Secretary to “allocate or reallocate functions among the officers of the Department, and may establish, consolidate, alter, or discontinue organizational units within the Department” within some very specific limitations.

Most of the authority granted by this section was related to the initial organization of the Department when it was formed. The remaining authority requires DHS to provide prior “notice of such action to the appropriate congressional committees, which shall include an explanation of the rationale for the action” {6 USC 452(a)(2)}.

Moving Forward

McCaul is the Chair of the House Homeland Security Committee so this bill will be considered favorably in Committee. The fact that the Ranking Member {Rep. Thompson (D,MS)} would indicate that there will be broad bipartisan support for the bill in Committee and likely on the floor. The Committee hearings are likely to occur next week when the House returns from working in their districts.


This bill is almost certainly a response to on-going Department efforts to re-arrange the cybersecurity efforts currently found scattered through the Office of Infrastructure Protection. McCaul has his own cybersecurity re-organization plan (HR 3359) for DHS that was ordered reported favorably by the Homeland Security Committee (report has not yet been published) shortly after it was introduced in July.

A positive slant on this bill would be that McCaul is attempting to avoid having DHS undergo multiple reorganizations when (if) his bill passes. A more negative take on this bill is that McCaul is attempting to stop DHS from undermining his authority as the Chair of the Committee. As with most things in the real world, the real intent probably lies somewhere in between.

Committee Hearings – Week of 10-15-17

With just the Senate in session this week most of the congressional hearings concern nominations. There is one cybersecurity hearing that may be of interest to readers of this blog.

The Senate Armed Services Committee will be holding a hearing on Thursday looking at “Roles and Responsibilities for Defending the Nation from Cyber Attack”. This is an open hearing, but there may be a closed (classified) session at the end. The witness list includes:

• Rob Joyce, National Security Council
• Kenneth P. Rapuano, Department of Defense
• Scott Smith, Federal Bureau Of Investigation
• Christopher C. Krebs, Department Of Homeland Security

There is a distinct possibility that control systems security issues associated with the electric grid may be discussed at this hearing, but at a policy level not a technical discussion given the participants.

Sunday, October 15, 2017

ISCD Updates CSAT 2.0 Web Site

Last week the DHS Infrastructure Security Compliance Division (ISCD) updated their Chemical Security Assessment Tool (CSAT) web page; this is part of the extensive web site for the Chemical Facility Anti-Terrorism Standards (CFATS) program. The only change to the CSAT page was the addition of a link to the new CFATS Site Security Plan (SSP) Submission Tips web page.

This new web page is part of the on-going ISCD outreach program to the CFATS regulated community. It is not a substitute for the SSP manual and the Risk Based Performance Standards (RBPS) Guidance manual, but rather a highlight of those types of things that have apparently been found lacking in many SSP submissions in the past. It highlights four major areas of concern:

• Consider what security measures to address;
• Detail current security measures;
• Describe planned security measures; and
• Specify facility-wide or asset-specific security measures

 What Security Measures

Of course, facilities are going to need to address security measures in each of the 18 RBPS that are applicable to the DHS chemicals of interest (COI) identified on the facility tiering letter. This section of the web page addresses five “overarching objectives” of the SSP:

• Detection;
• Delay;
• Response;
• Cyber; and
• Security Management

These are covered in short (one paragraph) discussions and links to the four RBPS fact sheets that ISCD began issuing earlier this year:

RBPS 8, Cyber Fact Sheet  
RBPS 9, Emergency Response Fact Sheet  
RBPS 12, Personnel Surety Program Fact Sheet  
RBPS 18, Records Fact Sheet 

Current Security Measures

This section briefly covers two rather broad topics:

• Be as detailed as possible; and
• Don’t overlook safety and environmental measures already in place that contribute to security.

In my conversations with folks in the field the first point is probably the most important for a successful SSP submission. This new web page says it well and succinctly:

“The text boxes in the Chemical Security Assessment Tool’s (CSAT) (/chemical-security-assessment-tool) SSP application have been included so that facilities can more fully describe current security measures, including how the measures address the relevant RBPS. The better DHS can conceptualize and understand your approach to security measures, the better DHS can evaluate whether they meet the applicable RBPSs.”

Facility-Wide vs Asset-Specific

The discussion here is important, though more than a little simplified (to be expected in a short document like this). It boils down to this. Security measures can be quite expensive, especially as the size of a facility increases. Since different types of COI may require different types of security measures, a facility may be able to significantly reduce costs by confining certain security measures to just those areas where their listed COI are stored or handled. Provisions are made in the CFATS to allow facilities to do this.


Again, ISCD has consistently tried to reach out to the CFATS community and provide the necessary information to successfully comply with the program requirements. This is part of that outreach. It is not (nor was it intended to be) the ultimate word in developing a successful SSP submission. It is just part of the process.

Facility security personnel will find this helpful only if they are familiar with the RBPS Guidance document and the SSP manual. Another source of useful information in this matter are two of the recently published presentations from the 2017 Chemical Sector Security Summit:

In fact, the CSSS web site has links to additional presentations from previous years that will also be helpful. The whole CSSS program is helpful for anyone interested in chemical facility security issues.

One final point, cybersecurity continues to pop up regularly in any discussions about the CFATS program. ISCD is certainly taking great pains to mention the topic whenever they discuss site security plans or compliance inspections. They have taken particular care to ensure that they try to communicate that ‘cybersecurity’ is not only important for the control systems that touch on the handling and/or storage of covered COI, but also includes cybersecurity measures to protect security controls (surveillance, intrusion detection, and access control systems) as well as business systems that affect the handling (ordering, selling or transporting), or storage of covered COI.

Saturday, October 14, 2017

Common Chemical Accident Causes Building Evacuation

Yesterday a 49-story office building in downtown Chicago was evacuated when a common chemical accident occurred on the roof of the building resulting in the release of chlorine gas. Six people were injured severely enough to be transported to local hospitals.

The Incident

Very little information is available in the news reports on the incident (here, here, here and here). The common thread is that “chlorine and acid were accidentally mixed on the roof of the building”. Based upon that this is likely what happened.

A maintenance crew was cleaning/disinfecting the water side of the cooling tower for the building HVAC system. These systems have been implicated in a number of Legionnaire outbreaks, so the cleaning/disinfection of these roof top systems is a fairly normal maintenance task. The ‘acid’ was likely muriatic acid (dilute hydrochloric acid); it is commonly used for pH adjustment, and cleaning metal or concrete. The ‘chlorine’ was almost certainly a solution of sodium hypochlorite (bleach); it is commonly used as a disinfectant and cleaning solution.

In disinfecting a small body of water the muriatic acid is added to lower the pH of the water. Then the chlorine is added to kill off bacteria. With adequate mixing or an appreciable time between adding the two chemicals to the water there is no problem. If the two chemicals are added in close physical or temporal proximity the they remain concentrated enough to allow a very quick exothermic action to occur. A byproduct of that reaction is the release of chlorine gas.

Unless someone is really stupid in the amount of bleach added to the water, there will not be enough chlorine gas released to kill anyone unless they are in a small, confined space above the surface of the water. Relatively small, non-fatal, amounts of chlorine gas will cause severe irritation to the eyes, nose and respiratory tract. Prompt medical evaluation is routinely recommended for anyone experiencing eye pain or difficulty breathing after relatively minor chlorine gas exposures.


In hind sight, there was almost certainly no need to evacuate the building. The amount of chlorine gas released would not have been medically significant beyond the immediate are of the release on the roof. I suspect that enough gas got into one of the HVAC air intakes to allow some people to detect the odor of chlorine (detectable by the average person at very low levels). Complaints of a strange chemical odor reported in the building coupled with the report of a chemical incident on the roof would be sufficient, however, to make any emergency response incident commander order a precautionary evacuation.

One of the reasons for this is that the same reaction between hypochlorite and muriatic acid make for a pretty interesting improvised chemical munition in closed quarters like a building. Without the diluting effect of a small body of water, the fast and strong exotherm results in low order explosion (no flame but and expanding gas cloud) that releases chlorine gas. Both chemicals are easy to buy and the only difficulty in constructing these bombs is how to keep the two chemicals apart until you want the reaction to take place. Again, unless the ‘bomb’ is really large, there is little real danger outside of the immediate area of ‘detonation’, but the loud bang and chlorine odor will do a nice job of starting a panic in a crowded building.

I expect that the investigation of this incident will ultimately place the blame for this incident on ‘human error’ and inadequate training of the maintenance personnel. People really can handle these two relatively innocuous industrial chemicals safely with just a modicum of training and supervision. But, the reason that this is such a common accident is that the process looks so simple and the chemicals look very common, so no one really takes the safety issues seriously until it is too late.

DHS Publishes 2017 CSSS Presentations

Yesterday DHS updated the 2017 Chemical Sector Security Summit (2017 CSSS) web page with links to some of the presentations that were made at this year’s Summit. Unfortunately, even with the Summit including web casts of several of the presentations, the links provided only provide copies of the slides used in the presentations.

The presentations available (in .PDF format) include:

How Vulnerable Are You? - Effective Strategies for Assessing Cybersecurity Risk
Global Partnerships: International Chemical Security Efforts
CTRA 4.0 – Chemical Terrorism Risk Assessment
When Disaster Strikes: Security Roles during a Disaster
A New Frontier: Unmanned Aircraft Systems (UAS)
Chemicals on the Move: Updates in Transportation Security

As I have mentioned a number of times, just providing copies of the slides, while better than nothing, are frequently frustrating. For example: in the ‘Chemicals on the Move’ presentation from the Coast Guard slide #2 is down-right cruel. In the discussion of the TWIC Reader Rule it lists one of the issues with that rule as being “Unintended consequences of Final Rule”. It would have been real interesting to hear what those consequences are as I am sure that people who attended the Summit did.

Having said that, there are some interesting bits of information included in these slides. They include:

• ‘A New Frontier’ provides a link to the “Unmanned Aircraft Systems (UAS) - Critical Infrastructure” web site;
• ‘CFATS Compliance Lessons Learned’ specifically mentions ‘cybersecurity’ as one of the things to pay attention to in the new Tiering letters being issued under CSAT 2.0;
• ‘What to Expect During a CFATS Inspection’ includes an important note: “Prepare list of attendees to the Opening Meeting. Have CVI numbers for each attendee ready.”
• ‘CTRA 4.0’ presentation notes that only 71 of the 185 chemical compounds assessed by Chemical Security Analysis Center (CSAC) are CFATS chemicals of interest (COI);
• ‘CFATS Regulatory Update’ mentions that “Will begin the Paperwork
Reduction Act process to expand [Personnel Surety Program] to Tiers 3 & 4 in the coming year”;
• ‘How Vulnerable Are You’ makes an important point: “A non-segmented network where CROWN JEWELS are not isolated will always be prone to failure from the failure of the weakest link”;

Remembering my complaint expressed above about the basic inadequacy of slides, I really do think that reviewing these presentations is worthwhile for anyone in the chemical facility security community. They do not take much time to review and there is some interesting information.

Having said that, the two most worthwhile presentations to review are the ones dealing with cybersecurity and disaster planning. As stand-alone documents, they both provide valuable and useful information. The latter is especially important (and in some ways prophetic) in light of the problems seen in the aftermath of Harvey.

One final note: The 2017 CSSS page provides a link to the page with the links to the presentation. It is odd, however, that the list of presentations is not an HTML page but rather a .PDF page. This makes loading a tad bit slow (as are the documents). And, as always, the Federal government’s reliance on .PDF documents with the attendant security issues is problematic (and more than a little ironic on a page devoted to security issues). Is there a more secure manner of presenting unalterable documents?

Friday, October 13, 2017

ISCD Publishes Personnel Surety Program Fact Sheet

Today the DHS Infrastructure Security Compliance Division (ISCD) posted a link to a new program fact sheet on the Chemical Facility Anti-Terrorism Standards (CFATS) Knowledge Center. The fact sheet provides some basic data on the implementation of the personnel surety program, or the screening for terrorist ties portion of the Risk Based Performance Standard (RBPS) 12.

As with all of these Fact Sheets that ISCD has been publishing over the last year or so, there is no really new information provided. All of the information is already available on either the CFATS Personnel Surety Program web page, or in the Federal Register Notice that announced the implementation of the program. What has been done is a relatively simplified presentation has been made available that provides highlights of the program.

The most valuable knowledge condensation here is the basic list of security considerations that facilities need to address in their site security plan for the option(s) being used by the facility to screen personnel authorized unaccompanied access to security areas of covered chemical facilities. This information was explained in more detail here in the Federal Register Notice, but the table in this fact sheet provides the basic information.

Bills Introduced -10-12-17

Yesterday, with only the House in session and preparing to leave for a week working in their districts (fund raising, campaigning and constituent support), there were 49 bills introduced. Remembering that most bills introduced in these situations are proposed to provide talking-points back home (not serious attempts at legislating), there were six bills that may be of interest to readers of this blog:

HR 4036 To amend title 18, United States Code, to provide a defense to prosecution for fraud and related activity in connection with computers for persons defending against unauthorized intrusions into their computers, and for other purposes. Rep. Graves, Tom [R-GA-14]

HR 4038 To amend the Homeland Security Act of 2002 to reassert article I authorities over the Department of Homeland Security, and for other purposes. Rep. McCaul, Michael T. [R-TX-10]

HR 4050 To support research, development, and other activities to develop innovative vehicle technologies, and for other purposes. Rep. Dingell, Debbie [D-MI-12]

HR 4051 To direct the Secretary of Transportation to establish a bollard installation grant program, and for other purposes. Rep. Espaillat, Adriano [D-NY-13]

HR 4053 To amend the Fair Credit Reporting Act to require an independent audit of the cybersecurity practices of certain consumer reporting agencies, and for other purposes. Rep. Fortenberry, Jeff [R-NE-1]

HR 4064 To impose restrictions on the sale of binary explosives, and for other purposes. Rep. Soto, Darren [D-FL-9]

Any changes made to 18 USC 1030 are going to be of potential interest to the cybersecurity research community. This may be an attempt to carve out an exemption for ‘hacking back’. Definitions would be very important here.

It is unusual for a Republican (and a Committee Chair) to introduce a bill reasserting congressional oversight during a Republican administration. I suspect that this may be related to pending changes in the organization of National Protection and Programs Directorate (NPPD), including the move of ICS-CERT to NCCIC.

HR 4050 sounds like a research grant program for automated vehicles. It will be interesting to see if it specifically includes cybersecurity provisions.

Bollards are a common security measure to prevent vehicles from going where they are not wanted. I suspect that HR 4051 is a response to recent vehicle attacks on pedestrians, but definitions matter and this could be used by chemical facilities to fund bollards used to prevent access by vehicle borne explosives. Again, definitions will be critical.

I am certainly not going to expand this blog to include coverage of credit reporting agencies (Brian Krebs has that space covered really well), but the idea of ‘independent cybersecurity audits’, may prove to be an interesting way of regulating cybersecurity.

Congress has mixed success with establishing regulatory schemes for explosives. The ATF has a pretty robust program going, but attempts to get DHS involved in the control of the sale of ammonium nitrate are still stalled since the regulations were authorized in 2007. It will be interesting to see how HR 4064 addresses the situation for binary explosives.

Thursday, October 12, 2017

ICS-CERT Publishes 5 Advisories and 1 Update

Today the DHS publishes five control system security updates for products from ProMinent, WECON, Envitech, NXP Semiconductor, and Siemens. They also updated a previously published control system security advisory for products from Marel Food Processing Systems.

Siemens Advisory

This advisory describes two vulnerabilities in the Siemens BACnet Field Panels. The vulnerabilities are self-reported. Siemens has developed a new firmware version that mitigates the vulnerabilities.

The two reported vulnerabilities are:

• Authentication bypass using an alternate path or channel - CVE-2017-9946; and
• Path traversal - CVE-2017-9947

ICS-CERT reports that a relatively low skilled attacker could remotely exploit the vulnerability to allow unauthenticated attackers with access to the integrated webserver to download sensitive information. The Siemens security advisory notes that the first vulnerability requires network access to exploit.

NXP Advisory

This advisory describes two vulnerabilities in the NXP MQX real time operating system (RTOS). The vulnerability was reported by Scott Gayou. ICS-CERT reports that NXP intends to issue a new version in January to mitigate the vulnerabilities. NXP provides a work around for the first vulnerability in the latest version (the second does not exist in that version) and recommends that users upgrade to that newer version pending the January update.

The two reported vulnerabilities are:

• Classic buffer overflow – CVE-2017-12718; and
• Out-of-bounds read – CVE-2017-12722

ICS-CERT reports that a relatively low skilled attacker could remotely exploit the vulnerabilities to cause a buffer overflow condition that may, in turn, cause remote code execution or out-of-bounds read conditions, resulting in a denial of service.

Envitech Advisory

This advisory describes an improper authentication vulnerability in the Envitech EnviDAS Ultimate web application. The vulnerability was reported by Can Demirel and Deniz Çevik of Biznet Bilisim. Envitech has a new version that mitigates the vulnerability. ICS-CERT reports that the researchers have verified the efficacy of the fix.

ICS-CERT reports that relatively low skilled attacker could remotely exploit the vulnerability  to view and edit settings without authenticating and execute code remotely.

WECON Advisory

This advisory describes a stack-based buffer overflow vulnerability in the WECON LeviStudio HMI Editor. The vulnerability was reported by Andrea “rgod” Micalizzi, working with iDefense Labs. WECON has developed a new version that mitigates the vulnerability. There is no indication that Micalizzi was 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 effect a denial of service and arbitrary code execution.

ProMinent Advisory

This advisory describes multiple vulnerabilities in the ProMinent MultiFLEX M10a Controller. The vulnerabilities were reported by Maxim Rupp. ICS-CERT reports that ProMinent has not mitigated the vulnerabilities.

The reported vulnerabilities are:

• Client-side enforcement of server-side security - CVE-2017-14013l;
• Insufficient session expiration - CVE-2017-14007;
• Cross-site request forgery - CVE-2017-14011;
• Information exposure - CVE-2017-14009; and
• Unverified password change - CVE-2017-14005

ICS-CERT reports that a relatively low skilled attacker could remotely exploit the vulnerabilities  to bypass protection mechanisms, assume the identity of authenticated users, and change the device configuration.

Marel Update

This update provides additional information on an advisory originally published on April 4th, 2017 and updated on August 17th. This update provides information on the firewall update for the Pluto platform that Marel has released.

The advisory still states that “Marel has created an update for Pluto-based applications, which was scheduled for release in October, 2017. This update will restrict remote access by implementing SSH authentication”.

Can Off-Site Changes Effect CFATS Tiering?

I have discussed the ‘material modifications’ reporting requirements {6 CFR 27.210(d)} of the Chemical Facility Anti-Terrorism Standards (CFATS) program on a number of occasions. Those discussions have centered around modifications made by the facility. What happens when the modifications are made off-site by someone other than the facility? This question is being raised in Buffalo, NY (see here and here).

The Problem

The issue in Buffalo is being raised because a developer is trying to reconfigure an existing facility in an industrial complex to a commercial rather than industrial facility. The proposed facility would be a “commercial office and flex space, with the possibility of space for a coffee shop or restaurant, primarily to serve tenants of the complex” according to one of the news reports.

The issue raised by the CFATS facility is two-fold. First, from the CFATS perspective, the additional people coming into the immediate vicinity (this is a six-acre industrial park) of the chemical facility could result in the DHS Infrastructure Security Compliance Division (ISCD) revisiting the risk tiering of the facility and potentially raising the security standards necessary for an approved site security plan. Those higher security standards would almost certainly cost the company more money.

The second part is the nuisance problem with people not used to working in an industrial environment complaining about the smells associated with chemical manufacturing (sulfuric acid manufacturing in this particular case) or the heavy truck and rail traffic transiting the area in support of that manufacturing.

On the other side, the owner of the property being redeveloped is concerned about his right to obtain the maximum financial return on the investment in the property. Apparently, this commercialization of an industrial property appears to be the best way to ensure that return.

Material Modification Reporting

The specific wording of §27.210(d) reads:

“If a covered facility makes material modifications to its operations or site, the covered facility must complete and submit a revised Top-Screen to the Department within 60 days of the material modification. In accordance with the resubmission requirements in §27.210(b)(2) and (3), the Department will notify the covered facility as to whether the covered facility must submit a revised Security Vulnerability Assessment, Site Security Plan, or both.”

The initial phrase of that paragraph; ‘covered facility makes material modifications’; would not seem to be applicable in this instance since the modifications are being made by someone else. However, looking back to §27.200(a) we see that DHS specifically has the authority to “at any time, request information from chemical facilities that may reflect potential consequences of or vulnerabilities to a terrorist attack or incident”.

Taking both sections into account, it would seem reasonable that a facility has a responsibility to report to notify ISCD of changes near the facility that would affect those potential consequences. Initially filing a new Top Screen may not be required, however. I suspect that a phone call to the CFATS Help Desk {(866) 323-2957} would be the most appropriate first step.


Conflicts such as these are not as uncommon a problem as one would like to think. Here in my current home town of Columbus, GA there is a day-care facility that shares a fence line with a chemical manufacturing facility. Another chemical facility in the same industrial park had to buy a piece of adjacent property to stop a milk processing facility from being built less than a hundred yards from hazardous material storage tanks.

Zoning issues, what gets built where, are a local matter for local governments to resolve. Unfortunately, many (most?) local governments do a less than stellar job of looking at the potential for industrial accidents on adjacent properties when making these types of decisions. The most obvious case in recent history is the ammonium nitrate explosion in West, Texas. The Chemical Safety Board report [.PDF download] on the incident includes an entire section on the land use planning problem.

It looks to me like the local Planning Board failed to take into consideration the potential for industrial accidents so close to a commercial facility in making its decision. At the very least it is setting up the community for a rising number of nuisance complaints being made to the local fire department and police department about ‘unusual odors’ and ‘chemical releases’.

Sulfuric acid fumes are irritating and easily detectable at very low levels; levels considered to be safe. Folks in an industrial setting quickly learn to ignore them due to frequent exposure and knowledge of what is going on. Customers periodically visiting the area are not going to have that level of experience and are certain to complain, particularly at eating establishments where smell is an important part of the experience.

Planning boards that fail to take problems like these into account when making zoning decisions in industrial areas are setting the municipal government up for future problems; problems that could be avoided by keeping reasonable separations between industrial operations and non-manufacturing concerns.

House Passes IT Cybersecurity Measure

Yesterday the House passed HR 2105, the NIST Small Business Cybersecurity Act of 2017, by a voice vote under the suspension of the rules process. The twenty-five minutes of debate on this bill consisted solely of speakers supporting the measure. The bill would require the National Institute of Standards and Technology (NIST) to consider small businesses when it facilitates and supports the development of voluntary, consensus-based, industry-led guidelines and procedures to cost-effectively reduce cyber risks to critical infrastructure.

I have not covered this bill to this point because it is entirely IT-centric. The bill requires that the NIST provided resources “vary with the nature and size of the implementing small business concern, and the nature and sensitivity of the data collected or stored on the information systems or devices of the implementing small business concern” {§3(c)(2)(B)}.

The bill is very similar to S 770 which passed in the Senate last month under the unanimous consent process. It is not clear, at this point, whether or not the Senate will take up HR 2105 as a separate measure or if the leadership will arrange for these two bills to be considered as one and work out the differences in conference. In any case, there is little chance that either bill will be modified to include industrial control systems in the NIST support requirements.

Wednesday, October 11, 2017

Safety Railcar

From time to time I receive interesting emails from readers of this blog. Yesterday it was one from a designer of a new ‘Safety Railcar’ that caught my attention. The email was brief; “Please see my patent pending idea.” Attached was a .PDF copy of the Patent Application Document from the US Patent Office.

The Problem

Now I have mentioned a couple of times on this blog that one of the big problems with railcar derailment fires is getting the right fire-fighting equipment to the scene in a timely manner. For many burning liquids the use of water is probably going to be contraindicated, especially with fluids like crude oil and various fuels. Various fire-fighting foams have been developed and successfully used, but most small community fire companies do not have the equipment to use foam, nor should they be expected to stock the various types of foams that would be necessary to fight fires from the variety of flammable liquids transported by rail.

I have suggested that trains with large numbers of crude oil cars {now formally called Highly Hazardous Flammable Trains (HHFT) by FRA} should carry a train car containing the specific foam necessary to fight crude oil fires. The local fire departments would still have to have the foam equipment, but they would not need to stockpile the foam making material.

The Safety Railcar

Now Robert E. Glen has done me one better. He has designed a railcar that would contain not only the foam making material but the equipment to mix and dispense the foam as well. See the basic diagram of the car below.

Safety Rail Car Design

I am not going to go into any great detail on the design of the car. Robert has done that in patent document with a very detailed description of the components and their employment in a derailment fire. In brief, his design purports to provide for both automated fire-fighting based upon data obtained from sensors on the car and for traditional firefighters unrolling hoses from the car to fight a fire. The document suggests that the Safety Railcar would be deployed every 15 to 20 cars in a unit train, ensuring that in the event of a major derailment, there would be at least one Safety Railcar near the scene of the resulting derailment fire to provide at least initial fire-fighting response.


While I have done some untrained volunteer grass-fire fire-fighting and even helped haul 2” fire hoses (well away from the nozzle) on occasion, I am not a fire fighter, nor am I a railway design engineer. Having said all of that, this looks like an interesting concept that might be worth exploring.

Because of the expense of building railcars, I suspect that Robert’s work on this has been limited to paper design work. I really doubt that he has a working model available for testing. What would be helpful, I suspect is for some people with experience in the field taking a look at this proposal and seeing what holes can be poked in it. Robert has posted this information to the NFPA.org site for comments; that may be a more practical place for the technical discussion to take place rather than on this blog (though I would love to see reader comments).

Now on the practical side: if this is a workable idea, it will be a long road to get something like this into production and rolling down the rails. Railroads are not going to be big supporters, it would be like admitting that they have responsibility for preparing for accidents. Shippers are not going to be buying these cars because they will not produce any revenue. It is going to be either the government or insurance companies that demand that a service like this is provided.

Fortunately for the public (and unfortunately for Robert’s idea) there has been a significant reduction in the number and size of the crude-oil-train fires that we saw too frequently a couple of years ago. While HHFT restrictions and safety work by the railroads have contributed to the decline, the root cause is almost certainly the sharp reduction in the number of crude oil and ethanol shipments over the last two years for economic reasons.

There will be more crude-oil train derailments and the chances are still there for another Lac-Megantic type catastrophe. It looks like something like Robert’s Safety Train may be one of the tools that could prevent a derailment from turning into a catastrophe.

Tuesday, October 10, 2017

ICS-CERT Publishes 2 Advisories and Updates 5

Today the DHS ICS-CERT published two new control system security advisories for products from JanTek and Lava Computers MFG. They also updated five previously published control system security advisories from GE and Siemens (4).

JanTek Advisory

This advisory describes two vulnerabilities in the JanTek JTC-200 TCP/IP converter. The vulnerabilities were reported by Karn Ganeshen. JanTek will not fix the vulnerability as a replacement product is expected later this year.

The two reported vulnerabilities are:

• Cross-site request forgery - CVE-2017-5789; and
• Improper authentication - CVE-2017-5791

ICS-CERT reports that a relatively low skilled attacker could use a publicly available exploit to remotely exploit the vulnerability to allow for remote code execution on the device with elevated privileges.

Lava Advisory

This advisory describes an authentication bypass spoofing vulnerability in the Lava Ether-Serial Link. The vulnerability was reported by Maxim Rupp. ICS-CERT reports that Lava Computer MFG has not responded to requests to work with ICS-CERT on this reported vulnerability.

ICS-CERT reports that a relatively low skilled attacker with uncharacterized access to spoof the IP address of an authenticated user, assume the authenticated user’s identity, and gain privileges or access to the system.

GE Update

This update provides additional information on an advisory that was originally published on October 5th, 2017. The new information includes a link to a new version that mitigates the vulnerability. There is no indication that the researcher reporting the vulnerability was provided an opportunity to verify the efficacy of the fix.

Ruggedcom Update

This update provides additional information on an advisory that was originally published on September 28th, 2017. The new information is a new link for contacting Siemens about the firmware update that mitigates the vulnerability.


This update provides additional information on an advisory that was was originally published on July 6th, 2017, and updated on July 18th and again on July 28th. The new information includes updated affected version information on (and firmware update information for):

• Firmware variant Modbus TCP: All versions prior to V1.11.00;
• SIPROTEC 7SJ66: All versions prior to V4.20;
• SIPROTEC 7SJ686: All versions prior to V4.83;
• SIPROTEC 7SD686: All versions prior to V4.03


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

• V7.2 and prior: All versions
• V7.3: All versions prior to V7.3 Update 15
• V7.4: All versions prior to V7.4 SP1 Upd1


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

• SIMATIC CP 1243-1 and CP 1243-1 IRC: All versions prior to V2.1.82;
• SIMATIC CP 1243-1 IEC: All versions;
• SIMATIC CP 1243-1 DNP3: All versions;
• SCALANCE M-800,S615: All versions prior to V04.03;

• SINAMICS DCM: All versions prior to V1.4 SP1 HF5;

HR 3958 Introduced – Energy Infrastructure Security

Last week Rep. Ruppersberger (D,MD) introduced HR 3958, the Securing Energy Infrastructure Act of 2017. This bill is very similar to S 79, introduced earlier this year. This is not technically a companion bill because several additions have been made to the language of the bill, but it does serve the same purpose.

Changes Made

This bill adds some relatively minor bits of language to that found in S 79. Those include:

• Section 2(2) – Adds the definition of ‘Director’ as the DOE Director of Intelligence and Counterintelligence;
• Section 5(a) – Adds a requirement for an interim report to Congress at 180 days; and
• Section 5(c) – Adds a definition of ‘Appropriate Committees of Congress’.

Moving Forward

Neither Ruppersberger, nor his single co-sponsor {Rep. Carter (R,TX) are members of the House Science, Space, and Technology Committee to which this bill was assigned for consideration. This means that the bill is not likely to be taken up by that Committee.

There are some funds authorized by this bill ($10 million for the pilot and $1.5 million for government study and report) which makes passage of the bill more complicated. Ruppersberger and Carter are both on the House Appropriations Committee, so that problem may be lessened. There is nothing else in this bill that would engender any significant opposition if brought to a vote.


As I mentioned when a version of this bill was introduced in the 114th Congress, I think that this is potentially game changing legislation. It is one of the few bills that actually tries to address a control system security issue with something that appears to be a workable route to a solution. The fact that funding is specifically provided instead of requiring an executive agency to rob Peter to pay Paul is especially encouraging.

It will be interesting to see if either this bill or S 79 moves forward at all in this session. The both bills have been introduced early enough that there should be no procedural hurdle to their consideration. It remains to be seen if the leadership of either house really has any intention of moving legislation forward that actually does something about a cybersecurity issue.

HR 3895 Introduced – Smart Technology

Earlier this month Rep. DelBene (D,WA) introduced HR 3895, the Smart Cities and Communities Act of 2017. The bill is designed to “promote smart technologies and systems to improve community livability, services, communication, safety, mobility, energy productivity, and resilience” {§2}. It includes a workforce training and development grant program supporting smart technology implementation.


Cybersecurity concerns are mentioned throughout the bill. For example, in the discussion about the purpose of the bill in §2, it mentions the protection of “the security of data and systems” {§2(2)}. Again, in the definition of ‘smart city or community’ the bill includes, as one of the inclusive actions taken by such communities, measures “to ensure the resilience of civic systems against cybersecurity threats and physical vulnerabilities and breaches” {§3(6)(B)(vi)(I)}.

Section 101 of the bill requires the establishment of the Interagency Council on Smart Cities “to promote the coordination of the activities and funding from Federal agencies relating to smart cities or communities” {§101(a)(1)(A)(i)}. The Council would consist of the Secretary of Commerce (Chair), the Secretaries of Energy, HUD, and Transportation, and the Director of the National Science Foundation.

The long list of priorities {§101(b)} for the Council includes the safeguarding of cybersecurity, specifically including by “promoting industry practices regarding cybersecurity” {§101(a)(1)(B)(vii)}. Three separate ‘considerations’ are listed in that paragraph supporting the cybersecurity priority {§101(a)(1)(C)}:

• Take into account existing Federal, State, and local frameworks, guidelines, and best practices when considering their application to smart city technologies;
• Take into consideration software quality, especially as that quality impacts reproducibility, maintainability, reliability, and security; and
• Ensure the privacy of individuals through the use of technologies with inherent privacy and security considerations

Building upon existing Department of Commerce (DOC) programs (eg: Internet Policy Task Force and the Digital Economy Leadership Team) §202 of the bill requires DOC to establish the Cybersecurity Working Group “to develop tools for communities to use to evaluate the cybersecurity of smart city or community technologies” {§202(b)(1)}. Membership of the Group would include {§202(b)(2)}:

• Representatives of consumer groups;
• Representatives of small units of local government;
• Representatives of large units of local government;
• Manufacturers of smart city or community devices, equipment, and software;
• Individuals with expertise in communications networks;
• Federal, State, and local law enforcement officials; and
• Such representatives of the Council as the Secretary determines to be appropriate.

The Group would be tasked with the requirement to {§202(b)(3)}:

• Leverage and build on previous activities carried out by the Department of Commerce relating to Internet of Things technology;
• Develop tools for communities to evaluate the cybersecurity of smart city or community technology being considered by the communities for adoption in those communities; and
• Develop tools for communities to protect against cybersecurity threats relevant to the technology the community has chosen to adopt.

Additionally, the Group would be specifically directed to assess {§202(b)(3)(D)}:

• Whether Internet of Things cybersecurity standards should exist;
• Whether the standards should be voluntary or mandatory; and
• Identify which entity is appropriate to devise the standards

Moving Forward

While DelBene is not a member of the House Energy and Commerce Committee (the primary of four committees assigned consideration of this bill), her single co-sponsor {Rep. Lujan (D,NM)} is. This means that it is possible that that Committee could take up this bill. Some fairly large amounts of money for the various grant programs included in this bill will be the biggest stumbling block to potential consideration and adoption of this bill. If the House Leadership can be convinced that those funds are reasonable and supportable then this bill should be able to pass with bipartisan support.


While cybersecurity is mentioned throughout the bill there is not a single definition related to cybersecurity provided. Nor is there a working definition of the technologies encompassed by the term ‘smart technologies’. This makes it difficult to assess whether or not operations systems would be addressed by the cybersecurity concerns outlined in the bill. The lack of specificity means that they could be, but there is no clear congressional intent that they will be addressed.

The other thing that concerns me about the bill is the lack of inclusion of the Department of Homeland Security in the Council. DOC could invite DHS to provide representation, but it is not required to do so. While DOC certainly has a great deal of cyber expertise, DHS has the mandate to be responsible for the cybersecurity information sharing activities of the Federal government and ICS-CERT has specific responsibility for that information sharing when it comes to operational technology. I do not think that this was an intentional slight of DHS by the crafters of this bill, but rather reflects a general lack of congressional appreciation for the scope of the problem.

Finally, I am disappointed in not seeing the bill provide for a grant program for continued studies on the development of cybersecurity tools and strategies supporting the smart technology covered in this bill. While the grant program included in the bill (the TechHire Workforce Training and Development Pilot Program in §203) is required to include “privacy and cybersecurity considerations” {§203(b)(3)} in its curriculum, there is no on-going program to address the inevitable changes in the cybersecurity realm caused by developing technology and changes in the threat landscape.

Friday, October 6, 2017

Bills Introduced – 10-05-17

As the House and Senate get ready to leave Washington for a long weekend in the House and for a week in their home State in the Senate there were 72 bills introduced. Of those, three may be of specific interest to readers of this blog:

HR 3968 To amend the Small Business Act to provide loan guarantees for the acquisition of cybersecurity technology and services by eligible small businesses, and for other purposes. Rep. Schneider, Bradley Scott [D-IL-10]

HR 3985 To establish a working group of public and private entities led by the Food and Drug Administration to recommend voluntary frameworks and guidelines to increase the security and resilience of Internet of Medical Things devices, and for other purposes. Rep. Trott, David A. [R-MI-11] 

S 1934 A bill to prevent catastrophic failure or shutdown of remote diesel power engines due to emission control devices, and for other purposes. Sen. Sullivan, Dan [R-AK]

It will be interesting to see what definitions of cybersecurity HR 3968 uses to see if the loan program would include support for control system cybersecurity.

A new cyber term (Internet of Medical Things – IoMT) has been introduced in the description of HR 3985. It will be interesting to see if the language of the bill uses the term, and, if so, how it is defined.

S 1934 is about a specific type of control system and it will be interesting to see what definitions are used. I would like to be able to say that I expect to see some cybersecurity language in the bill, but I am not that naïve. But, I can always hope.

ICS-CERT Publishes Two Advisories

Yesterday the DHS ICS-CERT published two control system security advisories for products from Siemens and GE.

Siemens Advisory

This advisory describes an authentication bypass vulnerability in the Siemens 7KT PAC1200 data manager. The vulnerability was reported by Maxim Rupp. Siemens has produced new firmware that mitigates the vulnerability. There are not indications that Rupp has been provided an opportunity to verify the efficacy of the fix.

ICS-CERT reports that a relatively low skilled attacker could remotely exploit this vulnerability to bypass authentication mechanisms and perform administrative functions. The Siemens security bulletin reports that the attacker must have network access to the device to exploit the vulnerability.

GE Advisory

This advisory describes a stack-based buffer overflow vulnerability in the GE CIMPLICITY software. The vulnerability was reported by David Atch of CyberX.  GE has released a new version that mitigates the vulnerability. There is no indication that Atch 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 cause the device that the attacker is accessing to crash; a buffer overflow condition may allow arbitrary remote code execution.

Thursday, October 5, 2017

Senate Committee Amends/Approves S 1885 – Automated Vehicles

Yesterday the Senate Commerce, Science, and Transportation Committee adopted 26 amendments to S 1885, the AV START Act and then passed the bill on a voice vote. Only 7 of the 26 amendments dealt with cybersecurity measures in the bill.

Minor Changes

Most of the cybersecurity related amendments made minor changes or additions to the current language of the bill. These included:

Hassan 4 – Added supply chain concerns to definition of ‘cybersecurity’ and to the requirements for the cybersecurity plan in §14;
Klobuchar 2 – Added informing driver of cyber vulnerabilities to definition of ‘cybersecurity’;
Schatz 2 – Added requirement for manufacturers to make a summary of the cybersecurity plan available to public;
Gardner 2 – Added requirement for manufacturers to provide employee training on their cybersecurity plan;
Klobuchar 1 – Added requirement for the Technical Committee to review vehicle communications with ‘roadway and infrastructure assets’.

Major Additions

The two remaining amendments added new sections to the bill.

Wicker 2 addressed consumer cybersecurity education in two new sections. First it added requirements for DOT to “develop educational cybersecurity resources to assist consumers in maintaining awareness of and minimizing potential motor vehicle cybersecurity risks” {new §15(a)(1)}. Those resources would be made available on the National Highway Traffic Safety Administration (NHTSA) web site. It would then require manufacturers to direct consumers to those resources.

Inhofe 2 provided requirements for the establishment of an HAV [Highly Automated Vehicle] Data Access Advisory Committee. This Committee would be tasked with making policy recommendations to Congress about “the ownership of, the control of, or access to information or data that vehicles collect generate, record or store” {new §15(d)(1)}. It also prohibits the Federal Government from making any rules on the regulation of such data until the Committee makes its recommendations.

In making its recommendations that Committee will consider the following factors {new §15(d)(4)(B)}:

• Motor vehicle safety;
• Intellectual property protections;
• Compliance with the Motor Vehicle Safety Act;
• Customer privacy;
• Cybersecurity;
• Confidential business information;
• Public safety; and
• Transportation planning.

 Moving Forward

The voice vote approval of this bill in Committee is indicative of the expected broad bipartisan support for this bill. If this bill makes it to the floor of the Senate, I would expect that support to continue.


My concerns about the conflicting and inadequate cybersecurity related definitions included in this bill were not addressed. In fact, the changes to the specific definition of ‘cybersecurity’ {new §30107(b)(4)} made by Hassan 4 and Klobuchar 2 described above only make things more confusing. The revised definition reads:

CYBERSECURITY. The minimization of cybersecurity risks to safety including evaluation of elements of the supply chain to identify and address cybersecurity vulnerabilities and the exchange of information about any vulnerabilities discovered from field incidents, internal testing, or external security research and mechanisms for alerting the human driver or operator about cyber vulnerabilities.

The use of this definition is limited to the requirements for the safety evaluation report to be prepared by vehicle manufacturers introducing new HAV’s, but it still reflects congressional technology confusion and a tendency to glop together fad terminology rather than understand complex concepts.

Bills Introduced – 10-04-17

With both the House and Senate in session yesterday there were 42 bills introduced. Of those, on may be of specific interest to readers of this blog:

HR 3958 To establish a pilot program on securing energy infrastructure, and for other purposes. Rep. Ruppersberger, C. A. Dutch [D-MD-2]

I will be watching this bill for its cybersecurity provisions, particularly the definitions that it uses.

Wednesday, October 4, 2017

HR 3855 Introduced – DOD Grid Security

Last week, Rep. Rosen (D,NV) introduced HR 3855, the Securing the Electric Grid to Protect Military Readiness Act of 2017. The bill is a companion measure to S 1800; identical bills submitted in each house of congress to allow for parallel processing in committee or a way around a committee road block in the other house.

Both Rosen and one of her three cosponsors {Rep. Stefanik, (R,NY)} are members of the House Armed Services Committee to which this bill was referred for consideration. This means that this bill could be considered in Committee. Again, as with S 1800, I do not see anything in this bill which would attract any significant opposition to its passage if it were considered. The only question is if the House or Senate leadership finds it expedient to move either of these bills forward; a question that only time will answer.

Tuesday, October 3, 2017

ICS-CERT Updates Siemens Advisory

Today the DHS ICS-CERT published an update to a control system security advisory for Siemens industrial products. The advisory was originally published on 8-31-17.

This update removes the following product versions from the list of covered products and removes references to those devices from the mitigation list:

• SIMATIC PCS 7; V7.1 and earlier versions;
• SIMATIC WinCC; V7.0, V7.3, V7.4

The update also expands the coverage of the advisory to all versions of SIMATIC IT Production Suite.

Bills Introduced – 10-02-17

Yesterday with both the House and Senate in session, there were 30 bills introduced. Of those, two may be of specific interest to readers of this blog:

HR 3895 To promote the use of smart technologies and systems in communities, and for other purposes. Rep. DelBene, Suzan K. [D-WA-1]

HR 3901 To direct the Secretary of Transportation to establish the Strengthening Mobility and Revolutionizing Transportation (SMART) Challenge Grant Program to promote technological innovation in our Nation's cities. Rep. DeSaulnier, Mark [D-CA-11]

I suspect that neither bill will be covered here in the future, but I will be watching to see if there are any cybersecurity provisions in either bill. If you are going to promote smart technology, it would seem to me to be smart to include promoting the cybersecurity of that tech. Anyone wanna take any bets on how smart congresscritters are?

Monday, October 2, 2017

Committee Hearings – Week of 10-01-17

This week with the House and Senate both in session in the first day of the new fiscal year, the lawmakers’ focus expands. We have four hearings of potential interest, two markup hearings and two cybersecurity hearings.

Markup Hearings

As I mentioned earlier, the Senate Commerce, Science, and Transportation Committee will hold their markup hearing on Wednesday. In addition to the markup of S 1885, the Committee will also take-up S 1872 [note: this is a link to the committee draft], the TSA Modernization Act. I mentioned this briefly when it was introduced last week, but I will not really cover this bill since it has little to do with surface transportation security. I will note that it is attempting to finally reword the current DOT referenced authorization of the TSA {49 USC 114} to move it to where it actually resides in DHS.

Also on Wednesday, the Senate Homeland Security and Governmental Affairs Committee will hold a markup hearing that will cover a number of bills (many that have yet to have been introduced). It will specifically include S 1281, the HACK DHS Act of 2017. I would like to note that in my post on the bill, I made the statement that Sen. Hassan (D,NH) was not a member of the Homeland Security Committee, but she is currently a member.

Cybersecurity Hearings

The Cybersecurity and Infrastructure Protection Subcommittee of the House Homeland Security Committee will hold a hearing on Tuesday on “Examining DHS’s Cybersecurity Mission”. The witness list includes:

• Patricia Hoffman, DOE;
• Christopher Krebs, DHS; and
• Jeanette Manfra, DHS

It will be interesting to see if this hearing addresses the reorganization of DHS cyber activities that includes the move of ICS-CERT to NCCIC.

On Tuesday the Information Technology Subcommittee of the House Oversight and Government Reform Committee will hold a hearing on “Cybersecurity of the Internet of Things”. This hearing was originally scheduled for 09-27-17. The witness list includes:

• Matthew J. Eggers, US Chamber of Commerce;
• Josh Corman, Atlantic Council;
• Tommy Ross, The Software Alliance (BSA); and
• Ray O’Farrell, VMware

According to the hearing website the purpose of the hearing is:

• To examine the use of devices that comprise the Internet of Things (IoT) and their current and potential uses in federal government.
• To explore potential cyber threats posed by the use of IoT devices.

• To review private sector recommendations for securing the IoT, and explore potential legislative solutions. 

Sunday, October 1, 2017

S 1885 – Introduced – Automated Vehicles

Last week Sen. Thune (R,SD) introduced S 1885, the American Vision for Safer Transportation through Advancement of Revolutionary Technologies (AV START) Act. As I mentioned in an earlier post I am writing this analysis based, not upon the official GPO version of the bill (not yet released), but a committee draft because the bill will be marked up in the Senate Commerce, Science, and Transportation Committee on Wednesday.

While this bill is, according to the Thune press release, based upon the “bipartisan provisions from the SELF-DRIVE Act (H.R. 3388) [link added]”, it is actually a fairly comprehensive rewrite of the provisions of that bill.


The bill does not use many of the definitions provided in HR 3388, preferring instead to us technical definitions from the Society of Automotive Engineers (SAE J3016A) for most of the automated vehicle terminology. It does add some definitions {new §30108(a)} missing from the house bill concerning cybersecurity. Those definitions are based upon exiting definitions in US law:

• ‘Cybersecurity incident’ – 6 USC 148(a)(3);
• ‘Cybersecurity risk’ – 6 USC 148(a)(1); and
• ‘Cybersecurity vulnerability’ – 6 USC 1501(17).

Actually, there is no term ‘cybersecurity vulnerability’ in §1501, the term used there is ‘security vulnerability’. All three of these terms are based upon the IT-centric security concern with the confidentiality, integrity, and availability of an information system or its information. Section 1501(9) does, however, specifically include control systems in its definition of ‘information system’.

Cybersecurity Provisions

Section 14 of the bill adds a new §30108 to 49 USC Chapter 301. This new section specifically addresses cybersecurity issues with automated vehicles. In addition to adding the definitions describe above, it requires each manufacturer to “develop, maintain, and execute a written plan for identifying and reducing cybersecurity risks [emphasis added] to the motor vehicle safety of such vehicles and systems” {new §30108(b)(1)}. That plan would include process to address {new §30108(b)(2)}:

• The risk-based prioritized identification and protection of safety-critical vehicle control systems and the broader transportation ecosystem, as applicable;
• The efficient detection and response to potential vehicle cybersecurity incidents [emphasis added] in the field;
• Facilitating expeditious recovery from incidents as they occur;
• The institutionalization of methods for the accelerated adoption of lessons learned across industry through voluntary exchange of information pertaining to cybersecurity incidents, threats, and vulnerabilities [emphasis added], including the consideration of a coordinated cybersecurity vulnerability disclosure policy or other related practices for collaboration with third-party cybersecurity researchers;
• The identification of the point of contact of the manufacturer with responsibility for the management of cybersecurity;
• The use of segmentation and isolation techniques in vehicle architecture design, as appropriate; and
• Supporting voluntary efforts by industry and standards-setting organizations to develop and identify consistent standards and guidelines relating to vehicle cybersecurity, consistent, and to the extent appropriate, with the cybersecurity risk management activities described in section 15 USC 272(e).

Paragraph (c) broadly address the issue of coordinated disclosure. It requires DOT “to incentivize manufacturers to voluntarily adopt a coordinated vulnerability disclosure policy and practice in which a security researcher privately discloses information related to a discovered vulnerability to a manufacturer and allows the manufacturer time to confirm and remediate the vulnerability”.

Moving Forward

As I mentioned earlier this bill is being marked up this week. With the support of both Chairman Thune and the two Detroit (er… Michigan) senators (Democrats Peters and Stabenow), I suspect that this bill will fly through Committee with no significant opposition (and probably no amendments). The question then will be, if the Senate leadership decides to take up automated vehicle legislation this session (an open question), whether it will move this bill or HR 3388 to the floor. I suspect that the House bill will be considered and then this bill will be used as substitute language.


First off, the cybersecurity provisions of this bill are going to be affected by the existing cybersecurity definitions adopted by the bill. Attacks on the vehicle control systems could cause death and destruction without ever having any effect on “confidentiality, integrity, and availability of an information system”. The sooner politicians begin to realize that information systems and operations systems are inherently different and require different security approaches the better.

In an earlier blog post on a port cybersecurity bill, I attempted to provide a useful series of definitions that could be used to address both information security and control system security in instances where both could be considered at risk. I included the existing definition of ‘information system’ and provided a very broad definition for ‘control system’. Then I provided the following definition of ‘cybersecurity risk’:

The term ‘cybersecurity risk’ means:
(A) threats to, and vulnerabilities of, information, information systems, or control systems and any related consequences caused by or resulting from unauthorized access, use, disclosure, degradation, disruption, modification, or destruction of such information, information systems, or control systems, including such related consequences caused by an act of terrorism; and
(B) does not include any action that solely involves a violation of a consumer term of service or a consumer licensing agreement;

The next problem with this bill is that it only requires DOT to provide incentives for manufacturers to establish a coordinated disclosure policy. This is keeping with the Republican abhorrence of regulations, but it is demonstrably ineffective in this instance. Without an outside referee between the security researcher and the manufacturer there is nothing to stop manufacturers from attempting to quash any inconvenient vulnerability disclosure. This is especially true with automotive manufacturers who have already attempted to stop automotive hobbyists from hacking their cars control systems to improve or modify performance.

The bill should have established the National Highway Transportation Safety Administration (NHTSA) as the clearing house for reporting automotive cybersecurity vulnerabilities. This easily could have been incorporated in the existing safety defects reporting systems under 49 USC 30118. Security researchers could then have been required to report vulnerabilities to NHTSA, who would then investigate/coordinate with the manufacturer to ensure that the vulnerabilities are corrected.

Finally, the bill is missing the ultimate measure to protect the cybersecurity of automated vehicles. There are no provisions that specifically make it a crime to hack a motor vehicle control system in a manner that jeopardizes the life or safety of the vehicle occupants, endanger people outside of the affected vehicle, or damage property.
/* Use this with templates/template-twocol.html */