ICS-CERT Updates Kabona Advisory

Today the DHS ICS-CERT published an update for a control system security advisory for the Kabona WebDatorCentral (WDC) application that was originally published on October 13^th, 2016.

This update provides information on a new vulnerability; a plain-text storage of password vulnerability - CVE-2016-0872. There is no explanation of why this vulnerability was not reported in the original advisory. Apparently, the new version of the WDC software originally reported also corrects this ‘new’ vulnerability.

CFATS Reauthorization – Cybersecurity

The current authorization for the Chemical Facility Anti-Terrorism Standards (CFATS) program expires on December 18^th, 2018. Sometime within the next year, Congress will most likely be taking up some form of reauthorization of the program. While we might expect to see simple inclusion of extension language in the DHS spending bill, it would be more efficient if Congress took up a standalone reauthorization bill that updated the program. This is the first in a series of posts that looks at what I would like to see included in such a bill. It should come as no surprise to readers of this blog that I would like to see cybersecurity addressed in some detail.

Definitions

I might as well start out this discussion by providing realistic definitions of cybersecurity that address the differences between security in information technology and operations (control systems) technology. Readers of this blog will recognize that these definitions have been proposed here in other contexts.

6 USC 621 is amended by adding at the end:

(15) The term ‘information system’ has the meaning given the term in section 3502 of title 44;

(16) The term ‘control system’ means a discrete set of information resources, sensors, communications interfaces and physical devices organized to monitor, control and/or report on physical processes, including manufacturing, transportation, access control, and facility environmental controls;

(17) 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;

(18) The term ‘cybersecurity incident’ means an occurrence that actually, or imminently jeopardizes, without lawful authority:

(A) the integrity, confidentiality, or availability of information on an information system,

(B) the timely availability of accurate process information, the predictable control of the designed process or the confidentiality of process information, or

(C) an information system or a control system;

Incident Reporting

There are currently no regulatory requirements for CFATS facilities to report cybersecurity incidents. The closest current regulations come is in 6 CFR 27.230(8) is a requirement to ‘deter cyber sabotage’ or the more general requirement. There is a strong suggestion in the Risk Based Performance Standards (RBPS) guidance document that {Metric 8.5.4; pg 80}: “Significant cyber incidents are reported to senior management and to the DHS’s US-CERT at www.us-cert.gov.” To date, there is no public record that any such reports have been made.

I think that this suggestion should be a requirement of the CFATS program and further strengthened. I propose that the following amendment to 6 USC 622:

(f) Cybersecurity Incident Reporting

(1) The Secretary will revise 6 CFR 27.230(15) to include requirements for the reporting of cybersecurity incidents or suspected cybersecurity incidents. Those revisions will address:

(A) Reporting cybersecurity incidents related to information systems to the DHS US-CERT or successor organization;

(B) Reporting cybersecurity incidents related to control systems to the DHS ICS-CERT or successor organization;

(C) Insuring that information provided to US-CERT or ICS-CERT in such reports will be protected under provisions outlined in 6 USC 23;

(D) Requiring US-CERT or ICS-CERT to provide copies of the final reports on such incidents to the head of the agency designated for the enforcement of the CFATS regulations. Anonymized information about such incidents will be further shared with CFATS covered facilities as deemed appropriate.

(2) The Secretary will revise 6 CFR 27.230(15) to ensure that significant cybersecurity incidents will be reported to the FBI.

Control System Vulnerabilities

There are no provisions in the current CFATS regulations or the RBPS Guidance documents that address the identification and mitigation of control system vulnerabilities. To correct that missing element of control system security I would propose the following additional amendment to 6 USC 622:

(g) Control System Vulnerabilities

(1) The Secretary will revise 6 CFR 27.230(8) to address the identification and mitigation of vulnerabilities in control system identified in facility site security plans. The revision will address requirements to:

(A) Identify critical control system components that effect the storage, use, or movement of DHS chemicals of interest identified in the facility tiering letter;

(B) Maintain a list of vulnerability reports from ICS-CERT and/or the vendor concerning those components;

(C) Conduct a risk assessment of those reported vulnerabilities; and

(D) Maintain a record of the outcome of those risk assessments that includes if/when appropriate mitigation measures were implemented.

(2) The Secretary will require ICS-CERT, or successor organization, to identify control system security advisories and alerts that could apply to chemical facilities and notify the agency responsible for the enforcement of the CFATS regulations when such advisories and alerts are published.

ISCD Publishes New Anhydrous Ammonia FAQ

On Friday the DHS Infrastructure Security Compliance Division (ISCD) published a new frequently asked question (FAQ) on the Chemical Facility Anti-Terrorism Standards (CFATS) Knowledge Center. The question, FAQ# 1786, addresses the effect of change of state in anhydrous ammonia in a refrigeration system on the reporting requirements for the CFATS Top Screen.

The response to the question reads:

“The total mass quantity within the system and the physical state, temperature, and pressure of the ammonia as it exists in the vessel(s) downstream of the condenser(s) should be reported.”

The ‘mass quantity’ portion of that response refers to the information that would need to be provided to question ‘Q1.70.010 Total Onsite Quantity’ on the Top Screen. The remainder of the response addresses the requirements to answer ‘Q1.70.030 Circle 1 Details’ for the largest quantity location for anhydrous ammonia.

ISCD Publishes CFATS Update – November 2017

On Friday the DHS Infrastructure Security Compliance Division (ISCD) published their Chemical Facility Anti-Terrorism Standards (CFATS) Monthly Update for November. The casual CFATS web site observer would be surprised to hear this since this has not been shown on either the Critical Infrastructure: Security Compliance web page or the CFATS Knowledge Center web page.

Published Data

Table 1 below shows the data published indicating the compliance data published for the facilities currently covered under the CFATS program. The numbers show a continued increase in the number of covered facilities and the number of compliance inspections being conducted.

Current Facilities	Oct 2017	Nov 2017	∆
Covered Facilities	3,492	3,517	+25
Authorization Inspections	2,374	2,400	+26
Approved Security Plans	2,270	2,273	+3
Compliance Inspections	2,106	2,122	+16

Table 1: Current CFATS Facilities

Table 2 shows the data showing the data on all facilities since the program was initiated back in 2007. Again, we see increases across the board.

Total Facilities	Oct 2017	Nov 2017	∆
Authorization Inspections	2,975	3,015	+20
Approved Security Plans	2,766	2,779	+13
Compliance Inspections	2,807	2,954	+61

Data Analysis

Figure 1 below is a graph showing the number of authorization inspections conducted since ISCD resumed reporting in May of this year. Both lines show a slight uptick in the number of inspections conducted. This is to be expected as facilities have had a chance to begin submitting SVA/SSPs for the new tiering letters that have begun to be issued under the new risk assessment process was implemented. We can expect to see a sharper increase in coming months.

Figure 1: Authorization Inspections

The compliance inspection information continues to require us to make some assumptions about how ISCD is counting the difference between current and total compliance inspections. Figure 2 shows the data reported since May.

Figure 2: Compliance Inspection Data

The total number of compliance inspections data continues to show a fairly consistent rate of increase (linear regression analysis shows R² of .996) since May. This would be consistent with ISCD’s current emphasis on ensuring that facilities with approved site security plans are in compliance with those plans. As ISCD begins to conduct more authorization inspections on newly submitted SSPs this rate will probably flatten out as the limited manpower available to the Division is re-purposed.

When we compare the current to total compliance inspection data we begin to see some discrepancies; a much steeper increase in the total number of compliance inspections as compared to the relatively flat increase in current inspections. When we look at the number of current compliance inspections compared to the number of currently approved SSPs we have to draw the conclusion that ISCD is reporting only one ‘current’ compliance inspection per facility with an approved SSP.

There are only two ways that ISCD can be reporting a large number of new inspections each month with only a small increase in the number of current SSP’s; either there are a significant number of facilities exiting the CFATS program or there are multiple compliance inspections being conducted on current facilities. The number of currently approved SSPs does show a slight decrease (8) since reporting resumed in May even though the total number of SSPs that have been approved has increased by 60. That would seem to indicate that some facilities have left the program (68?) during the reporting period and that is within the magnitude of what ISCD reported back in April.

The change in the number of compliance inspections tells a completely different story. Since May there has been an increase of 901 total compliance inspections completed and only an increase of 191 current compliance inspections. Since a facility must have an approved SSP prior to having a compliance inspection the 68 disappearing SSPs does not explain the difference of 710 compliance inspections. Combining the two data sets we can see that there have been 642 (710 – 68) compliance inspections that are not accounted for in the total number of current compliance inspections.

The only thing that I can conclude is that ISCD chemical security inspectors have conducted at least 642 compliance inspections since reporting resumed in May where the facility was not in compliance with the currently approved SSP. How many of these are unique facilities vs facilities with multiple non-compliant inspections results cannot be determined from the data presented in these reports.

Public ICS Disclosure – Week of 10-29-17

This week Karn Ganeshen provided proof of concept (POC) information on three previously published ICS-CERT vulnerabilities and Joel Langill provided a link to an ABB KRACK advisory.

POC Information

Karn continues to use the FullDisclosure web site to provide to provide additional information about control system vulnerabilities that he has previously disclosed through the DHS ICS-CERT. This week he has provided POC information on the following control system vulnerabilities:

• Progea Movicon SCADA/HMI – earlier reported here (there was no mention of publicly available POC in the ICS-CERT advisory);

• JanTek JTC-200 – earlier reported here (publicly available POC was mentioned in ICS-CERT advisory); and

• SpiderControl SCADA Web Server – earlier reported here (there was no mention of publicly available POC in the ICS-CERT advisory)

Based upon past experience, I do not expect ICS-CERT to update their vulnerability reports to reflect the fact that POC information is now available. Given the fact that ICS-CERT has reported that relatively low skilled attackers could exploit these vulnerabilities, I think that it is important that owners of these systems has this information available to help them appropriately assess the risks to their systems.

KRACK Vulnerability

Joel’s post on LinkedIn pointed at a cybersecurity advisory from ABB for their  ABB TropOS wireless mesh products concerning the WPA2 Key Reinstallation Vulnerabilities (also known as the Key Reinstallation Attack – KRACK).

As I pointed out in the resulting LinkedIn conversation this is the second vendor specific advisory on the KRACK vulnerability. Unlike the earlier report, ABB includes 7 of the 10 CVE found in the KRACK report, indicating that they have probably reviewed all 10 of the vulnerabilities in their system.

I continue to be disappointed in ICS-CERT for not having published a control system alert for the KRACK problem since these vulnerabilities will affect almost all ICS products that use WPA2 security for wireless communications in their control system products.

ICS-CERT Publishes Two Advisories

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

Advantech Advisory

This advisory describes two vulnerabilities in the Advantech WebAccess HMI platform. The vulnerabilities were reported by Steven Seeley via the Zero Day Initiative. Advantech released a new version to mitigate the vulnerability. There is no indication that Seeley has been provided an opportunity to verify the efficacy of the fix.

The two reported vulnerabilities are:

• Stack-based buffer overflow - CVE-2017-14016; and

• Untrusted pointer dereference - CVE-2017-12719

ICS-CERT reports that a relatively low skilled attacker could remotely exploit these vulnerabilities to allow remote code execution.

Siemens Advisory

This advisory describes an improper input validation vulnerability in the Siemens SIMATIC PCS7 distributed control system. The vulnerability was reported by Sergey Temnikov and Vladimir Dashchenko of Kaspersky Labs. Siemens has issued an update for some versions to mitigate the vulnerability. There is no indication that the researchers were provided an opportunity to verify the efficacy of the fix. Siemens has provided interim mitigation suggestions pending updates to the other versions.

ICS-CERT reports that a relatively low skilled attacker could remotely exploit the vulnerability to crash services on the device. The Siemens security advisory reports that: “The attacker must be member of the group administrators and have network access to an affected system.”

NOTE: Siemens reported this vulnerability on October 18^th.

HR 4151 Introduced – STREET Act

Last week Rep. Comstock (R,VA) introduced HR 4151, the Smart Technology for Resilient, Efficient, Economic and Reliable Transportation in Cities and Communities (STREET) Act. The bill is designed to to promote smart technologies and systems to reduce transportation costs, traffic congestion, air pollution, energy use, and carbon emissions for communities of all sizes.

Definitions

Section 2 of the bill provides a number of lengthy definitions of the terms used in the bill. There are no specific cybersecurity definitions, but the terms ‘secure’ and ‘cybersecurity’ are used in the definition of ‘Smart System or Community’ in §2(7). It includes as a characteristic of a smart system or community the integration of measures “to enhance the resilience of civic systems against cybersecurity threats and physical and social vulnerabilities and breaches” {§2(7)(B)(v)(I)}.

Resource Guide

The Department of Energy (in coordination with the departments of Transportation, Housing and Urban Development, and the National Science Foundation) is required in §4 to publish on-line “a resource guide designed to assist States, communities, and cities in developing and implementing smart city or community programs” {§4(a)(1)}. The guide is permitted to include “voluntary, industry-led, international consensus standards and best practices, in collaboration with the National Institute of Standards and Technology, for safeguarding cybersecurity and appropriate data management and data privacy” {§4(b)(3)(C)}.

Grant Program

Section 5 of the bill would require DOT to establish another round to the Smart Cities Challenge “provide grants on a competitive basis to small- and medium-sized communities to implement smart transportation proposals” {§5(a)}. The grants would range between $20 million and $40 million and $100 million would be authorized for the grant program in each fiscal year between 2018 and 2022.

Moving Forward

Both Comstock and her cosponsor, Rep. Etsy (D,CT), are members of both the House Transportation and Infrastructure Committee and the Science, Space, and Technology Committee, the two committees  to which the bill was assigned for consideration. The bipartisan sponsorship increases the likelihood that the bill could be considered by the two committees.

The only portion of the bill that could raise significant opposition to its consideration is the inclusion of authorization for the grant program. As with any new money authorization, the money would have to come from some other program, probably within the Transportation Department.

Commentary

While there are no specific cybersecurity definitions within this bill (or references to existing cybersecurity definitions) there are numerous references to ‘information’ and ‘privacy’ and no references to control systems or vehicle operations. This would certainly lead one to conclude that this is an IT-centric bill if not actually limited to IT systems.

The bill should have included a definition of the term cybersecurity since the term is used in multiple places in the bill. Because of the rising importance of operations in smart technology the drafters would have been ill advised to use an IT-limited definition like that found in 6 USC 148.

In an earlier blog post I provided a definition of ‘cybersecurity risk’ after providing supporting definitions of ‘information system’ and ‘control system’. Using the same supporting definitions I would like to provide a legislative definition of ‘cybersecurity’:

The term cybersecurity means a set of actions, procedures or processes under taken to protect information systems or control systems 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.