Sunday, June 16, 2019

STSAC Meeting Announcement – 07-11-19


Yesterday the DHS Transportation Security Administration (TSA) published a meeting notice in the Federal Register (84 FR 27795) for a meeting of the newly established Surface Transportation Security Advisory Committee (STSAC) on July 11th, 2019 at TSA Headquarters in Arlington, VA.

The agenda includes:

Unclassified Surface Transportation Intelligence Briefing
TSA Organizational Structure
Surface Transportation Rulemaking
Organization of STSAC
Public Comments

Public participation is welcomed, but advanced registration (for the purpose of clearing people for access to the TSA HQ) is required. Oral or written comments may be submitted, but advanced notice is required. That notification should be made by June 30th, 2019. Apparently there are no provisions for webcasting the meeting.

Commentary


This is the initial meeting of STSAC so it is way too early to tell how effective this Advisory Committee will be. Some agencies (DOT in particular) have made their advisory committees an integral part of the regulatory development process. The broad membership of this Committee should make for a reasonable level of expertise that should be of benefit to the understaffed and underfunded surface transportation folks at TSA. Yet to be determined, however, is how well the Committee and its inevitable subcommittees work together and how much attention TSA pays to their recommendations.

On the later, I hope that the lack of a meeting webcast or even teleconference monitoring is not an indication of lack of support from TSA management for this congressionally mandated Advisory Committee.

Committee Amended and Adopted HR 1668 – IoT Cybersecurity


This week the House Oversight and Reform Committee adopted substitute language for HR 1668, the Internet of Things (IoT) Cybersecurity Improvement Act of 2019, by a voice vote. The new language was a complete re-write of the bill.

Changes in Definitions


In §2 of the bill there were significant changes in the definition provided. First the revised language added definitions for ‘Director of OMB’ and ‘Director of the Institute’ (NIST).

Next the definition of ‘covered device’ was substantially changed. The ‘connected to the internet’ and ‘computer processing capability’ portion of the original definition was kept (but reformatted), but the ‘is not a general-purpose computer’ exception portion of the definition was expanded and revised. The new language included a substantial revision of the ‘programmable logic controls’ language of the original bill to now read{§2(2)(C)(iv)}:

Programmable logic controller with an industrial control system specifically not designed for connection to the internet;

A new exception was also added to the definition{§2(2)(C)(v)}; ‘subcomponent of a device’. The new ‘covered device’ definition also removed provisions in the original bill that would have required OMB to establish a process for petitioning for a device to be specifically considered a ‘covered device’.

Finally, the freestanding definition of ‘security vulnerability’ was changed to an incorporation of the definition from 6 USC 1501. The earlier definition was essentially an expansion of the §1501 definition (it had added ‘firmware’ and ‘combination of 2 or more of these factors’), but the §1501 definition relies on the expanded definition of ‘information system’ that specifically includes control system language.

Security Standards


Section 3 of the original bill was spread out into two separate sections. The first would require the National Institute of Standards and Technology (NIST) to complete its current activities ‘regarding considerations for managing the security vulnerabilities of Internet of Things’ {§3} by December 31st, 2019. This is essentially the same language from §3(a)(1) of the original bill with a revision of the date (extended three months) to complete the actions.

The provisions of §3(b) in the original bill were expanded and modified in §4 of the revised language. First the requirement for NIST to establish ‘standards’ for use of internet of things devices by federal government was changed to establishing ‘guidelines’ which the OMB would later convert to ‘standards’.

The closing paragraph of §4 of the revised language requires that “the Federal Acquisition Regulation shall be revised to implement” the standards required to be set by OMB in §4(b). The simplified language in this new paragraph was designed to accomplish the requirement of §4(a) and (b) of the original language.

New Petition Requirement


The petition requirement that was removed from the definition of ‘covered device’ was moved to and expanded in §5 of the revised language. The new section would allow an ‘interested party’ to petition for a covered device to be exempt from the standards set in §4(b). The petitioner would have to establish that the procurement of the covered device {§5(b)(3)(A)}:

With limited data processing and software functionality would be unfeasible; or
That does not meet the standards promulgated by the Director of OMB under this Act is necessary for national security or for research purposes.

Coordinated Disclosure


Section 6 of the revised language is a substantial rewrite of §5 and §6 of the original bill. It would still require NIST to establish guidelines with respect to “reporting, coordinating, publishing, and receiving of information” {§6(a)(1)} security vulnerabilities of covered devices and the resolution of those vulnerabilities. The new language does add a requirement for ‘consultation’ with the DHS Cybersecurity and Infrastructure Security Agency (CISA) in the development of the guidelines.

Another important new addition to the guideline requirements is found in §6(b)(3); ensure such guidelines are consistent with the policies and procedures developed by CISA under 6 USC 659(m).

OMB would be required to convert the guidelines developed by NIST into standards to be used by government agencies using covered devices. This requirement specifically applies to including those standards in Federal Acquisition Regulations (FAR).

Section 7 of the bill requires all contractors to comply with the requirements of the standards developed by OMB. It would specifically require each agency Chief Information Officer to “determine if such offeror or contractor has complied with each standard promulgated under section 6(c) with respect to such covered device” {§7(a)(1)(A)}.

Moving Forward


Technically, the House Science, Space, and Technology Committee still needs to act on this bill. This could end up being something as simple as a letter from the Chair saying that he agrees with the changes being offered by the Oversight Committee. Or we could see a full committee markup of the bill.

In any case, this bill may actually see its way to the floor of the House. With the bipartisan support that the revised language received in Committee, it is likely that it would be considered under the suspension of the rules process and would probably pass with similar support.

Commentary


Well, Rep. Kelly (D,IL), or more probably her staff, tried to correct the problems with the definition of ‘covered device’ that I had previously identified in the Senate version of this bill (S 734). Unfortunately the changes made just confuse the issue more.

First, we have a measure of grammatical confusion. As written “programmable logic controller with an industrial control system specifically not designed for connection to the internet” would make it seem that an ‘industrial control system’ was part of a PLC instead of the other way around. Next, there is some subject confusion with the phrase ‘specifically not designed for connection to the internet’ (not to mention the awkward word order); does it refer to the PLC or the ICS. If we are to keep the intended (I think) concept here I would suggest the following revision of this language{§2(2)(C)(iv)}:

“programmable logic controller that is a component of an industrial control system which is specifically designed not to connect to the internet;”

There are still problems with this definition, mainly because it uses terms that are not further defined in the bill nor are they a part of general government usage. Does an ICS include building environmental systems or access control systems? Does the existence of a port designed to allow network connections to the device equate to ‘connect to the internet’ or must the device be physically (cable or WiFi or Bluetooth, or radio) attached to a network that connects to the internet?

If Congress does not specify in legislation than agencies like NIST and OMB get to make the decision. In many ways this can make for more agile regulation development. Unfortunately, it may leave the efficacy and the impact of the regulations to the whims of the regulators. In this case, an aggressive NIST or OMB staffer could decide that a close interpretation of the current exemption language would only apply to the PLC of a building environmental control system, but not the HMI used by the system or the sensors or actuators attached to the PLCs. Since those devices were equipped with ports that could allow internet connections, they would be included in the ‘covered device’ definition and would be regulated by the OMB standards. Or they could go the other way and decide that no one would intend to connect these devices to the internet (even though they had components that could allow such a connection) so they were not ‘covered devices’ and thus not regulated.

While I understand that congresscritters are not technically equipped to make many of these decisions, I am still uncomfortable in allowing the kind of regulatory leeway that I describe above to be exercised by nameless bureaucrats who may (NIST probably, OMB not so sure) a better technical background to make such decisions.

Saturday, June 15, 2019

Public ICS Disclosure – Week of 06-08-19


This week we have two new vendor notifications from Schneider and 18 researcher reports from Talos of vulnerabilities in products from Schneider. We also have four updated notifications from Schneider (2) and Siemens (2). Additionally, we have two vendor updates for advisories about the Microsoft® RDP vulnerability from Philips and Drager.

Schneider Advisories


1. Schneider published an advisory for a credential exposure vulnerability in the Schneider PowerSCADA Expert product (NOTE: According to Schneider this also affects the AVEVA CitecSCADA, but no AVEVA advisory has yet been published). This vulnerability is apparently self-reported. Schneider has a new version that mitigates the vulnerability.

2. Schneider published an advisory for three vulnerabilities in the Schneider ProClima product. The vulnerabilities were reported by Kushal Arvind Shah (Fortinet), Telus, and Haojun Hou and
Yongjun Liu (NSFOCUS). Schneider has a new version that mitigates the vulnerability. There is no indication that the researchers have been provided an opportunity to verify the efficacy of the fix.

The three reported vulnerabilities are:

Code injection - CVE-2019-6823;
Buffer errors - CVE-2019-6824; and
Uncontrolled search path element - CVE-2019-6825

Talos Reports on Schneider Vulnerabilities


Talos has provided reports with exploits on 18 vulnerabilities in two products from Schneider; Modicon 580 UMAS and UnityPro PLC. These are coordinated disclosures, but Schneider has not yet published advisories for these vulnerabilities. Because of the volume I am not going to attempt to go into details.

Modicon 580 UMAS

Information disclosure - CVE-2018-7845;
Denial of service - CVE-2018-7854;
Denial of service - CVE-2018-7853;
Denial of service - CVE-2018-7849;
Improper authentication - CVE-2018-7842;
Unauthenticated file write - CVE-2018-7847;
Denial of service - CVE-2018-7855;
Denial of service - CVE-2019-6807;
Denial of service - CVE-2018-7856;
Information disclosure - CVE-2018-7844;
Information disclosure - CVE-2019-6806;
Information disclosure - CVE-2018-7848;
Denial of service - CVE-2018-7852;
Denial of service - CVE-2018-7846;
Denial of service - CVE-2018-7857; and
Denial of service - CVE-2018-7843

UnityPro

Remote code execution - CVE-2019-6808;
Untrusted inputs - CVE-2018-7850;

NOTE: There are still 10 reports pending on Schneider vulnerabilities on the Talos Zeroday Reports web page. Someone has been spending a great deal of time testing Schneider equipment.

Schneider Updates


1. Schneider updated an advisory for the Schneider Embedded Web Servers for Modicon V2 (Note: this has not been reported by NCCIC-ICS). The new information is the addition of researcher acknowledgements.

2. Schneider updated an advisory for the Schneider – U.motion Builder software (Note: this has not been reported by NCCIC-ICS). Schneider is reporting that this vulnerability has been exploited by Mirai malware. Schneider is making an unusual recommendation: “It is imperative customers cease using U.motion Builder software and remove it from their systems immediately.”

Siemens Updates


1. Siemens updated an advisory for Foreshadow/L1 terminal fault vulnerabilities in Industrial Products (Note: this has not been reported by NCCIC-ICS). The new information is added mitigation measures for:

SIMATIC S7-1500 Software Controller;
SIMATIC ET 200 SP Open Controller; and
SIMATIC ET 200 SP Open Controller (F)

2. Siemens updated an advisory for Vulnerabilities in the additional GNU/Linux subsystem of the SIMATIC S7-1500 CPU. The update adds information for new firmware V2.6.1

RDP Vulnerability


Two vendor advisories were updated this week:

Philips; and
Drager

Friday, June 14, 2019

Bills Introduced – 06-13-19


Yesterday with both the House and Senate preparing to leave for the weekend (and the House only about half-way through consideration of HR 2740, the first FY 2020 spending minibus) there were 104 bills introduced. Six of those bills are likely to see future consideration in this blog:

HR 3256 To amend the Homeland Security Act of 2002 to reauthorize and improve the Chemical Facility Anti-Terrorism Standards Program, and for other purposes. Rep. Richmond, Cedric L. [D-LA-2]

HR 3261 To direct the Secretary of Transportation to establish a Smart Technology Traffic Signals Grant Program, and for other purposes. Rep. Cardenas, Tony [D-CA-29] 

HR 3266 To direct the Secretary of Defense to carry out a program to enhance the preparation of students in the Junior Reserve Officers' Training Corps for careers in computer science and cybersecurity, and for other purposes. Rep. Fletcher, Lizzie [D-TX-7]

HR 3270 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 3290 To provide for mandamus actions under chapter 601 of title 49 of the United States Code. Rep. Speier, Jackie [D-CA-14]

S 1867 A bill to amend the Homeland Security Act of 2002 to establish in the Department of Homeland Security an Unmanned Aircraft Systems Coordinator, and for other purposes.

I will be watching HR 3261 for cybersecurity requirements and HR 3266 for control system security language. HR 3270 is the ‘hack back’ bill that was in the news yesterday. Chapter 601 is the Pipeline Safety portion of the USC.

Thursday, June 13, 2019

3 Advisories Published – 06-13-19


Today the DHS NCCIC-ICS published two control system security advisories for products from WAGO and Johnson Controls. They also published a medical device security advisory for products from BD.

WAGO Advisory


This advisory describes three vulnerabilities in the WAGO 852 Industrial Managed Switches. The vulnerability was reported by T. Weber of SEC Consult Vulnerability Lab. WAGO reports that the latest firmware for the affected products mitigate the vulnerabilities. There is no indication that Weber has been provided an opportunity to verify the efficacy of the fix.

The three reported vulnerabilities are:

Use of hard-coded credentials - CVE-2019-12550;
Use of hard-coded cryptographic key - CVE-2019-12549;
Use of components with known vulnerabilities

Note: The CERT VDE advisory lists the following component vulnerabilities:

BusyBox (v 1.12.0) - CVE-2013-1813, CVE-2016-2148, CVE-2016-6301, CVE-2011-2716, CVE-2011-5325, CVE-2015-9261, CVE-2016-2147, CVE-2017-16544 etc.; and
GNU glibc (v 2.8) - CVE-2010-0296, CVE-2010-3856, CVE-2012-4412, CVE-2014-4043, CVE-2014-9402, CVE-2014-9761, CVE-2014-9984, CVE-2015-14 etc.

NCCIC-ICS reports that a relatively low-skilled attacker could remotely exploit the vulnerabilities to allow a compromise of the managed switch, resulting in disruption of communication, and root access to the operating system. The SEC Consult report includes proof of concept code for the first two vulnerabilities.

Johnson Controls Advisory


This advisory describes an improper authorization vulnerability in the Johnson Controls exacqVision Enterprise System Manager. The vulnerability was reported by @bzyo_. Johnson Controls reports that the latest version mitigates the vulnerability. There is no indication that @bzyo_ has been provided an opportunity to verify the efficacy of the fix.

NCCIC-ICS reports that an uncharacterized attacker with uncharacterized access could exploit the vulnerability to allow malicious code execution.

BD Advisory


This advisory describes two vulnerabilities in the BD Alaris Gateway Workstation. The vulnerability was reported by Elad Luz of CyberMDX. BD reports that the latest firmware mitigates the first vulnerability and provides generic mitigations for the second. The is no indication that Luz has been provided an opportunity to verify the efficacy of the fix.

The two reported vulnerabilities are:

Improper access control - CVE-2019-10962; and
Unrestricted upload of file with dangerous type - CVE-2019-10959

NCCIC-ICS reports that a relatively low-skilled attacker could remotely exploit the vulnerability to allow an attacker to view and edit device status and configuration details as well as cause devices to become unavailable.

Wednesday, June 12, 2019

HR 1668 Hearing – IOT Cybersecurity


This morning the House Oversight and Reform Committee will be holding a business meeting that will include the markup of HR 1668. Rep. Kelly (D,IL), the sponsor of the bill, is offering substitute language for the bill which is essentially a complete re-write. Changes include a complete rewrite of the definition of ‘covered device’ which specifically excludes a wide range of devices including {§2(2)(c)(iv)}:

Programmable logic controller with an industrial control system specifically not designed for connection to the internet [emphasis added].

I will have more on this revised language in a future blog post.

S 1466 Introduced – Cybersecurity Apprenticeships


Last month Sen. Rosen (D,NV) introduced S 1466, the Cyber Ready Workforce Act. The bill would require the Department of Labor to establish a grant program “to support the establishment, implementation, and expansion of registered apprenticeship programs in cybersecurity” {§4(a)}. This is a companion bill (identical language) to HR 2721.

Rosen is a member of the Senate Health, Education, Labor, and Pensions Committee. This means that there is a good chance that this bill will be considered in Committee.

As with HR 2721 there is nothing in this bill that would engender any significant opposition. The vague ‘such funds as may be necessary’ authorization included in the bill may be weasel-worded enough to prevent spending issues from clouding the consideration of the bill. If the bill receives substantial bipartisan support in Committee, this bill would likely move to the floor of the Senate under the unanimous consent process.

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