Thursday, July 20, 2017

Chemical Plants and Ransomware

There has been an interesting and on-going discussion on TWITTER® related to how chemical plants may be affected by ransomware like WannaCry. It was the result of the publication of two DHS-OCIA FOUO documents about WannaCry (here and here). They were published by PublicIntelligence.

The on-going TWITTER discussion was really based upon one entry in a chart in the second document described above; (U) Table 1—Ransomware Targeting and Susceptibility by Sector. The entry for the Chemical Sector contained the statement: “Chemical plants have manual overrides in place to ensure the safe containment of chemical processes in case cyber defenses fail. In some cases, it may be possible to run the chemical plant independently of cyber controls, otherwise the plant will most likely shut down.”

Most of the discussion has been on where the supporting data for that statement comes (short answer, no one knows) and how accurate that statement is. I cannot provide any information on the first, but a reasonable answer to the second will take more than 140 characters to explain.

Chemical Plant Automation


There is a great deal of variety in the level and sophistication of automation in chemical manufacturing processes. I have worked in a plant where there was absolutely no automation. Sensors were either analog or digital with no connections beyond a power supply. All operations are directly controlled by the operator manually operating various valves and power switches. Plants like this are unusual in this day and age. They are small plants typically running experimental processes on a shoestring budget. They are going to essentially be unaffected by ransomware except on the business process side of the house.

The most sophisticated facilities (and I have seen some of these, but never worked in one) have almost completely automated their chemical manufacturing processes. The extensive and complicated control system requires limited operator oversight; taking a wide mix of sensor data (temperature, pressure, flowrates and valve states for example) processes that data to develop (via a complex process control algorithm) commands to various operations devices (transfer valves, heating, cooling and vacuum controls for example) to control the manufacturing process. The operator actions are fairly limited to starting or stopping the process, making small manual adds of chemicals to the process and watching for process upset conditions.

Most specialty chemical manufacturing (batch processes) have a level of automation somewhere between these two extremes. An operator typically watches sensor data on a human machine interface (HMI) display and operates controls via the same HMI in response to a written set of instructions, training and experience. There may be some manual valve movements made by the operator or his assistants, but most are remotely operated via electrical or pneumatic operations.

Safety systems are in use (hopefully) in all plants regardless of the level of automation. They may be simple mechanical devices such as pressure relief valves or rupture disks. They could be process alarms that require operators to take manual corrective actions. They could be simple interlocks where a specific sensor output generates a direct command to operate a specific valve. Or they could be complex algorithmic responses to a variety of sensor readings resulting is a number of automatic operational changes to the process. These automated safety systems can reside in a stand-alone computer system with dedicated sensors and valves that are not in any way connected to the main process control system (the safest system) or various parts (or all of) the safety system could reside on the same computer system running the chemical manufacturing process.

In a perfect world, what determines the level of sophistication (and thus cost) of the safety system is the potential outcome of the process upset that it controls. The more serious the potential consequence of the process upset (again in a perfect world) the more complex and involved the safety system becomes. Where there are potential catastrophic, off-site consequences one would like to expect to see sophisticated stand-alone safety systems to prevent those catastrophic results.

Ransomware Effects


For purposes of this discussion I am going to assume that the ransomware has effected all networked controls system computers and that any stand-alone safety systems remain operational, these would include sophisticated systems, mechanical devices and most electro-mechanical interlocks (those not controlled through a PLC).

For the least automated systems the affects would be mainly cosmetic; operators would still be controlling the process, it would be more physical control with the operator going out and manually operating controls instead of using the HMI. This is assuming that there are still sensor readouts that do not go through the HMI. This would require either analog gauges or 4/20ma gauges wired to old-style displays.

Double displays with their associated wiring are a pain to maintain and frequently are considered a wasteful duplication of resources. The absence of analog gauges or non-computer sensor-output displays would mean that the operator would have no view of the key process control variables, and thus, no control of the process.

The consequences of going to full operator manual control of processes would be immense. I made the transition from full manual to semi-automated process control. We were able to add more sensors to better understand the process variables and those new sensors were in locations that were not readily accessible by the operator. Just those additional sensors decreased process times (and thus process costs) significantly as well as reducing product variability and off-spec products. We also significantly reduced the number of operators that were necessary to operate multiple processes that typically run at specialty chemical plants. Some plants would be able to operate at significantly reduced capacity, but increased product variability problem could have downstream quality effects on customer operations.

For fully automated chemical facilities (typically found in continuous process facilities like refineries) an instantaneous change to manual operation would not be possible. The lack of analog gauges and local sensor readouts and the relatively inaccessible manual controls would make it physically impossible for operators to coordinate the operation of the connected portions of the process in real time.

Safety Effects


Again, properly designed and implemented safety systems would be expected to stop any catastrophic consequences of sudden loss of control in chemical manufacturing systems. There were a number of very important qualifiers in that previous sentence. The major problem with designing safety systems is that it is very difficult to completely understand catastrophic failure modes in a manufacturing environment.

Typically, one has to use lab scale data to understand the physical parameters of those failure modes (NO ONE wants to do FULL SCALE testing of such failure modes) and then apply various models to try to scale up those test results to be able to plan for preventive actions to stop or mitigate the failures. No matter how sophisticated the modeling efforts they are, in the end, based upon educated guesses as to how the system will behave. Then systems are designed to try to best control those failure modes. And, it is not generally acceptable to really test those systems to see how they actually work in practice (in the emergency environment).

The OCIA Statement


The OCIA statement that started this discussion is almost certainly not based upon any survey of the chemical industry. It is a reasonable brief attempt by outsiders with a non-chemical manufacturing background to categorize the potential consequences of a non-chemical emergency event on generic chemical manufacturing.

If I were to attempt to reword this statement from a chemical manufacturing process point of view, it would read something like this:

“Chemical manufacturing facilities should have safety systems in place to contain catastrophic consequences in the event of loss of control. The efficacy of those systems and their operation in an instantaneous loss of computer control situation would have to be evaluated on a case-by-case basis. Continued commercial production without replacing/fixing affected computer based process controls could be possible is some unknown number of facilities. It would be difficult to accurately predict which facilities could continue commercially viable production.”


Bills Introduced – 07-19-17

Yesterday, with both the House and Senate in session, there were 54 bills introduced. Of these only one may be of specific interest to readers of this blog:

H Res 459 Expressing the sense of the House of Representatives that the United States should support the development of programs that better prepare students for careers in cybersecurity by actively promoting ethical hacking skills. Rep. Garrett, Thomas A., Jr. [R-VA-5]


Generally speaking, ‘sense of Congress’ resolutions are fairly meaningless political statements with no practical effect. I will be watching this one, however, to see how it is worded and what definitions, if any, it uses. I do not expect that it will actually see consideration in committee or on the floor of the House.

Wednesday, July 19, 2017

Bills Introduced – 07-18-17

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

HR 3282 To amend title 49, United States Code, with respect to electronic logging devices, and for other purposes. Rep. Babin, Brian [R-TX-36]


I will only be providing additional coverage of this bill if it includes specific language addressing chemical transportation or if it contains cybersecurity provisions.

Tuesday, July 18, 2017

ICS-CERT Publishes Advisory and Updates Another

Today the DHS ICS-CERT published a new control system security advisory for products from Rockwell. They also updated another control system security advisory for products from Siemens. The Rockwell advisory was originally published in the NCCIC Portal on May 18, 2017.

Rockwell Advisory


This advisory describes an improper input validation vulnerability in the Rockwell MicroLogix 1100 Controllers. The vulnerability was reported by Mark Gondree of Sonoma State University, Francisco Tacliad and Thuy Nguyen of the Naval Postgraduate School. Rockwell has a newer firmware version that mitigates the vulnerability. There is no indication that any of the researchers have been provided an opportunity to verify the efficacy of the fix.

ICS-CERT does not provide any information on skill level or type access required to exploit this vulnerability. They just note that a successful exploit could lead to a denial of service condition.

Siemens Update


This update provides additional information on an advisory that was originally published on July 6th, 2017. The new information included updated version information for:

• Firmware variant Modbus TCP: All versions prior to V1.10.01,
• Firmware variant DNP3 TCP: All versions prior to V1.03, and
• SIPROTEC 7SJ66: All versions prior to V4.23
• SIPROTEC 7SJ686: All versions prior to V4.86
• SIPROTEC 7UT686: All versions prior to V4.01
• SIPROTEC 7SD686: All versions prior to V4.04

The only change seen in the security reporting from Siemens was affected version information and the update link for DNP3 TCP. The other updated version information was provided in the ‘Mitigation’ section of the earlier ICS-CERT version of the advisory, but not in the ‘Affected Products’ section.

Commentary


I have not done an actual tally to confirm this, but it seems to me that we see a much higher percentage of Rockwell product advisories making it to the NCCIC (or the old US-CERT) secure portal before being publicly disclosed than we do for Siemens products. Since it is not clear how this decision is made for limited disclosure, it would be unfair to say something untoward was happening; but, it does seem odd.


If the decisions are made based upon company requests for the delay, then this is a marketing call by the respective companies with no foul noted. If the decision is being made just by ICS-CERT, then the community probably deserves some process explication.

HR 3101 Introduced – Port Cybersecurity

Last month Rep. Torres (D,CA) introduced HR 3101, the Strengthening Cybersecurity Information Sharing and Coordination in Our Ports Act of 2017. The bill establishes a number of modest cybersecurity requirements for (and in support of) port operations.

Federal Requirements


Section 2 of the bill establishes federal requirements for cybersecurity risk assessments, information sharing and coordination. First it requires DHS to conduct (and subsequently evaluate) a risk assessment for maritime cybersecurity based upon the NIST Cybersecurity Framework. Next, it requires DHS to ensure that at least one maritime information sharing analysis committee (ISAC) participates in the National Cybersecurity and Communications Integration Center.

Paragraph (4) requires DHS to establish “guidelines for voluntary reporting of maritime-related cybersecurity risks and incidents (as such terms are defined in section 227 of the Homeland Security Act of 2002 (6 U.S.C. 148)) to the Center [NCCIC]”. The next paragraph then requires DHS to “to report [on] and make recommendations to the Secretary on enhancing the sharing of information related to cybersecurity risks and incidents between relevant Federal agencies and State, local, and tribal governments”.

Local Requirements


Section 3 of the bill establishes local cybersecurity requirements. First it requires each Maritime Security Advisory Committee “to facilitate the sharing of cybersecurity risks and incidents to address port-specific cybersecurity risks, which may include the establishment of a working group of members of Area Maritime Security Advisory Committees to address port-specific cybersecurity vulnerabilities” {§2(1)}. Next it requires all new maritime or facility security plan (under 46 USC 70103) to “include a mitigation plan to prevent, manage, and respond to cybersecurity risks” {§2(2)}.

Specifically §4 amends two separate provision of 46 USC {§70102(b)(1)(C) – facility and vessel assessments – and §70103(c)(3)(C) – vessel and facility security plans} by adding the word “cybersecurity” after “physical security”. It would also add a requirement for vessel and facility security plans to address the “prevention, management, and response to cybersecurity risks” {new §70103(c)(3)(C)(v)}.

Moving Forward


While Torres is not a member of either committee to which the bill has been assigned for consideration, two of her cosponsors are {Rep. Correa (D,CA) – Homeland Security; and Rep. Wilson (D,FL) – Transportation and Infrastructure}. This means that there is at least a chance that either or both of these committees could consider HR 3101.

I do not see anything in the bill that would engender any significant opposition. If the bill were to be considered on the floor of the House it is likely that it would pass, probably under the suspension of the rules provision.

Commentary


Once again, the provisions of this bill rely on the 6 USC 148(a)(1) definition of ‘cybersecurity risk’, a definition that is limited to information systems and does not include control systems. This would mean that the requirements of this bill would not apply to operation of any of the many critical control systems found on vessels or in maritime facilities.


I would again like to point to a solution to this definitional problem in port cybersecurity legislation that I proposed in an earlier blog post. It would still use the existing, IT-centric, definition of ‘information system’, but would add a new definition for ‘control system’ and then combine both terms in the definition of ‘cybersecurity risk’.

Committee Hearings – Week of 7-16-17

With both the House and Senate in session there is a wide slate of congressional hearings this week. Spending bills are finishing up in the House and the Senate continues to plug away on nomination hearings. There are two cybersecurity hearings of potential interest, one a markup and one addressing energy security.

Spending Bills


The House Appropriations Committee is still working on ginning out their spending bills with two more hearings being conducted during the remainder of the week:


Cybersecurity Mark-up


On Wednesday the Digital Commerce and Consumer Protection Subcommittee of the House Energy and Commerce Committee will mark-up a staff draft of a bill on highly automated vehicle testing and deployment. The Committee Draft of the bill contains a section on “Cybersecurity of automated driving systems” which I will try review later today.

Energy Security


Later this morning the Senate Energy and Natural Resources Committee will hold a hearing to examine the status and outlook for U.S. and North American energy and resource security. Cybersecurity is certainly going to be part of this discussion. The witness list includes:

• Fatih Birol, International Energy Agency;
• Stephen Cheney, American Security Project;
• Robert Coward, American Nuclear Society;
• Dan McGroarty, Carmot Strategic Group;
• Mark Mills, Manhattan Institute; and
• Jamie Webster, Center for Energy Impact

On the Floor of the House


Today the House will consider HR 3050, Enhancing State Energy Security Planning and Emergency Preparedness Act of 2017, under their suspension of the rules procedure. This means that there will be limited debate and no amendments will be considered. This usually means that the House leadership considers this to be a non-controversial bill with a high-probability of passage (which requires a super-majority). NOTE: The committee report on the bill has not yet been published, it will probably be submitted today, but will not actually be available on the Congress.gov site until later this week.


NOTE: The House Rules Committee called for amendments to HR 2997, 21st Century Aviation Innovation, Reform, and Reauthorization Act. This is the House version of the FY 2018 FAA reauthorization. I have not published a review of this bill yet because there is currently nothing of real interest included in the introduced version. It looks like that will be changing. No hearing is scheduled yet, but it may happen later this week.

Bills Introduced – 07-17-17

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

HR 3266 Making appropriations for energy and water development and related agencies for the fiscal year ending September 30, 2018, and for other purposes. Rep. Simpson, Michael K. [R-ID-2]

HR 3267 Making appropriations for the Departments of Commerce and Justice, Science, and Related Agencies for the fiscal year ending September 30, 2018, and for other purposes. Rep. Culberson, John Abney [R-TX-7]

HR 3268 Making appropriations for Agriculture, Rural Development, Food and Drug Administration, and Related Agencies programs for the fiscal year ending September 30, 2018, and for other purposes. Rep. Aderholt, Robert B. [R-AL-4]

As with all spending bills, I will be watching these for potential cybersecurity provisions.


 
/* Use this with templates/template-twocol.html */