Thursday, June 22, 2017

OMB Approves EPA TSCA Guidance Document

Yesterday the OMB’s Office of Information and Regulatory Affairs announced the approval of the publication of a new EPA guidance document supporting the implementation of some of the requirements of the Frank R. Lautenberg Chemical Safety for the 21st Century Act (PL 114-182). Specifically, this document, “Guidance to Assist Interested Persons in Developing and Submitting Draft Risk Evaluations Under the Toxic Substances Control Act (TSCA)”, should provide information to industry in determining what information should be included in requesting EPA risk evaluations under 15 USC 2605 as modified by §6 of the Act (130 Stat 460).

OIRA was pretty quick in approving this publication (submitted on June 13th), especially considering that it was substantially written under the Obama Administration. It is unclear how soon this will be published by the EPA since two of the regulations that this supports are still under review by OIRA (here and here) at the notice of proposed rulemaking (NPRM) stage. Technically this could move forward without those rules being approed since those regulations probably have more effect on EPA actions taken on the submitted data than upon industry submitting the data.

Obviously, the Trump Administration will not meet the June 22nd (today) deadline for implementing the requirements of §6. To be fair neither would have the Obama Administration. That deadline was totally unrealistic given the rulemaking process and the complexity of the issues involved. I do suspect that we will see the two TSCA NPRMs published this summer.

Wednesday, June 21, 2017

ICS-CERT Publishes New Advisory and Updates 2 Siemens Advisories

Yesterday the DHS ICS-CERT published a new control system security advisory for a product from Ecava. They also update two previously published advisories for products from Siemens.

Ecava Advisory

This advisory describes an SQL injection vulnerability in the Ecava IntegraXor. The vulnerability was reported by Tenable Security. Ecava has produced a new version that mitigates the vulnerability. ICS-CERT reports that Tenable has verified the efficacy of the fix.

ICS-CERT reports that a relatively low skilled attacker could remotely exploit the vulnerability to effect unauthenticated remote code execution.


This update provides additional information on an advisory originally published on May 9th, 2017 and updated on June 15th, 2017. This update provides new affected version data and links to updates for Primary Setup Tool (PST): All versions prior to  V4.2 HF1.

Interestingly, this information on the PST was made available in the same updated version of the Siemens Advisory published on June 13th that was used for the previous ICS-CERT update. A close comparison of the original Siemens Advisory and the June 13th versions shows that there was an additional product that was updated, but also not mentioned in the earlier ICS-CERT update or in this update; the Security Configuration Tool (SCT): All versions < V5.0.

Industrial Products Update

This update provides additional information on an advisory originally issued on November 8, 2016 and then updated November 22nd, 2016; December 23rd, 2016; February 14th, 2017; March 2nd, 2017 and May 9th, 2017. This update provides the same new information as the ICS-CERT updated described above. Interestingly (and kudos to ICS-CERT for really prompt reporting), Siemens published their updated Security Advisory just yesterday morning (ICS-CERT time).

NOTE: Siemens also announced (via TWITTER®; @ProductCERT ) yesterday that they had published a new security advisory (SSA-126840) and updated another advisory (SSA-275839)with the same SCT information noted above. I expect that we will see those reflected on the ICS-CERT site today or tomorrow.

Monday, June 19, 2017

Committee Hearings – Week of 6-18-17

With both the House and Senate in session the focus this week remains budget hearings. There are no budget hearings of specific interest this week, but the budget process is still taking up a large portion of congressional focus. There is only one cybersecurity hearing currently scheduled for this week though there may be cybersecurity amendments offered in the NDAA markup process that also begins this week.


The FY 2018 National Defense Authorization Act (NDAA) is another priority moving forward. HR 2810 currently has no cybersecurity provisions, but there are gaping holes in the bill that will be filled-in during the markup process. That process starts this week in subcommittees of the House Armed Services Committee:


On Wednesday, the Senate Homeland Security and Governmental Affairs Committee will be holding a hearing on “Cybersecurity Regulation Harmonization”. The witness list includes:

• Christopher F. Feeney, BITS/Financial Services Roundtable
• Dean C. Garfield, Information Technology Industry Council
• Daniel Nutkis, Health Information Trust Alliance
• James "Bo" Reese, National Association of State Chief Information Officers

This will certainly focus on IT cybersecurity, but there may be some minor attention paid to control system security.

Sunday, June 18, 2017

HR 2825 Amended and Approved in Committee

Last week the House Homeland Security Committee held a markup hearing on HR 2825, the DHS Authorization Act of 2018 [corrected date 6-19-17 0710 EDT]. The Committee adopted a large number of amendments, including substitute language.

Substitute Language

The original bill was extremely light in its coverage and was obviously missing some titles. The substitute language offered by Rep. McCaul (R,TX) substantially enlarged and expanded the coverage of the bill. New sections in the substitute language that may be of specific interest to readers of this blog include:

§403. Cyber at ports.
§409. Repeal of interagency operational centers for port security and secure systems of transportation.
§572. Surface transportation security assessment and implementation of
risk-based strategy.
§577. Surface transportation security advisory committee.
§583. Study on surface transportation inspectors.
§584. Security awareness program.
§585. Voluntary use of credentialing.
§586. Background records checks for issuance of hazmat licenses.
§587. Recurrent vetting for surface transportation credential-holders.
§588. Pipeline security study.
§589. Repeal of limitation relating to motor carrier security-sensitive material
tracking technology.
§620. Cyber preparedness.
§642. Medical Countermeasures Program.

The provisions I discussed in my post about the original bill remain essentially unchanged.

Maritime Security

Title IV of the substitute language addresses maritime security issues. Most of the provisions found in this title were included in HR 2831, the Maritime Security Coordination Improvement Act that I reviewed yesterday. That bill includes provisions not seen in this bill, so it is likely to continue forward. I suspect that the duplicate provisions in this bill are those that McCaul considers the most important.

The cybersecurity provisions that I discussed in HR 2831 are included in this bill (§403) essentially unchanged.

Surface Transportation Security Studies

The substitute language contains a new Title V, Subtitle G (sections 571 thru 589) that addresses a number of surface transportation security issues. Many of them deal with various study and report requirements. There are two studies outlined in this subtitle that may be of specific interest to owners and operators of surface transportation organizations and activities.

Section 583 would require the Government Accountability Office (GAO) to conduct a study looking at potential duplications or redundancies between TSA and DOT “relating to surface transportation security inspections or over sight” {§583(1)}. While TSA has been given the responsibility for overseeing all transportation security issues, its main (some would say almost exclusive) focus has been on passenger air transportation security. As a result, the DOT modal agencies have continued to oversee the pre-TSA security requirements that were initiated by the modal agencies. There exists a very real potential that this study could lead to the disbanding of the TSA surface transportation security program as duplicative and ineffective.

Section 588 requires a separate GAO study of the TSA/DOT oversight conflict in the pipeline security arena. Of particular interest to readers of this blog is the specific inclusion of cybersecurity issues in the study parameters. The GAO is tasked with looking at how the current memorandum of understanding between DHS and DOT adequately delineates the responsibility for {§588(a)(1)}:

• Protecting against intentional pipeline breaches and cyber-attacks;
• Responding to intentional pipeline breaches and cyber-attacks; and
• Planning to recover from the impact of intentional pipeline breaches and cyber-attacks.

The big problem here is that most of the activities that are used to respond to a pipeline breach are the same for both intentional and accidental breaches. Given the fact that accidental breaches are much more common than intentional breaches, the DOT pipeline safety folks will have much more practical experience in this field.

The one area that is not specifically identified in the §588 requirements is having the GAO study identify if either PHMSA or TSA have enough people with the requisite skill and background in control system security to deal with cyber-attacks.

Other Amendments

An amendment offered by Rep. Thompson (D,MS) amended the new requirement for surface security awareness training outlined in §584. The Thompson amendment would reiterate that this new requirement would not “replace or affect in any way the security training program requirements” specified in 6 USC sections 1137, 1167, and 1184. Readers of this blog will remember that TSA finally published a notice of proposed rulemaking (NPRM) on those requirement last December. This amendment was adopted by voice vote.

An amendment offered by Rep. Langevin (D,RI) would add a new section to the bill that would require the FEMA Administrator to conduct a study on the use of grant funds awarded pursuant to 6 USC §604 (Urban Area Security Initiative) and §605 (State Homeland Security Grant Program) to support efforts to prepare for and respond to cybersecurity risks and incidents (as such terms are defined in 6 USC 148. Readers should see my discussion on HR 2831 on why the reference to 6 USC 148 ignores control system security issues. This amendment was adopted by voice vote.

Moving Forward

The amended substitute language on this bill passed by a voice vote. Even with the Democrats losing party line votes on six amendments, there is still substantial bipartisan support within the Committee for the amended bill. If McCaul can get buy in from the House leadership (including the chairs of a number of other potentially interested committees) to bring this bill to the floor, it is almost certain to pass. Convincing the Senate leadership to bring the bill to the floor in that body will be another intra-party, political issue.

Saturday, June 17, 2017

HR 2831 Introduced – Port Security Corrections

Last week Rep. Rutherford (R,FL) introduced HR 2831, the Maritime Security Coordination Improvement Act. The bill makes a number of changes to laws pertaining to port security operations conducted by the Coast Guard. Changes of specific interest to readers of this blog would be increased emphasis on cybersecurity and changes to Maritime Transportation Security Act (MTSA) inspection requirements.


Section 4 of the bill address three separate issues related to port cybersecurity related to different levels of cybersecurity interest; DHS/CG, Captain of the Port (COTP), and MTSA covered facility owner.

Section 4(b) of the bill specifically adds cybersecurity to the areas of potential weakness that DHS/CG is required to look at when they are assessing the “detailed vulnerability assessment of the facilities and vessels that may be involved in a transportation security incident” 46 USC 70102(b)(1)(C).

Section 4(a) addresses cybersecurity at the COTP level by adding a new requirement for Area Maritime Security Advisory Committees (AMSAC) under 46 USC 70112(a)(2)(A). The AMSACs would be specifically required to “shall facilitate the sharing of information relating to 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 address port-specific cybersecurity risks and incidents, which may include the establishment of a working group of members of such committees to address such port-specific cybersecurity risks and incidents” {§70112(a)(2)(A)(i)}.

At the facility owner level the bill would require vessel and facility security plans under 46 USC 70103(c) to specifically address “prevention, management, and response to cybersecurity risks and incidents (as such terms are defined in section 227 of the Homeland Security Act of 2002 (6 U.S.C. 148) [link added])” {new §70103(c)(3)(C)(v)}.

Facility Inspections

Section 5 of the bills makes a change to the requirements for the Coast Guard to inspect MTSA covered facilities under 46 USC 70103(c)(4)(D). Instead of inspecting at least twice a year (one conducted without advanced notice), the new requirement would reduce that to at least once a year without notice.

Moving Forward

Rutherford and all three of his cosponsors {including Chairman McCaul (R,TX)} are members of the House Homeland Security Committee, one of the two committees to which the bill was assigned for consideration. This bill will almost certainly be considered (and approved) in the Homeland Security Committee; consideration by the Transportation and Infrastructure Committee is much less assured.

There does not appear to be anything in the bill that would raise any significant opposition in the House. If McCaul can get the bill to the floor of the House, it is likely to eventually reach the President’s desk.


There are no cybersecurity definitions in the bill beyond reference to the terms ‘cybersecurity risks’ and ‘incident’ from §148(a). Those definitions both rely on the definition of ‘information system’ which §148 takes from 44 USC 3502(8). That definition is very IT-centric; “the term ‘information system’ means a discrete set of information resources [emphasis added] organized for the collection, processing, maintenance, use, sharing, dissemination, or disposition of information”. Thus, it could be argued that these cybersecurity requirements do not address control system, security system, or building maintenance system security issues.

In many industries (finance, commercial sales, and healthcare for example) protecting information is the paramount concern when we talk about cybersecurity. In port operations, however, the operational side of the house is probably more significant than is the need to protect just information. Thus, it would behoove Congress to ensure that the language in this bill reflects the importance of operational cybersecurity.

The only place that currently expands the IT-centric definitions of cybersecurity to include operations technology is 6 USC 1501(9). There the definition of ‘information system’ is still based on a reference to §3502, but it was specifically expanded by adding subparagraph (B) “includes industrial control systems, such as supervisory control and data acquisition systems, distributed control systems, and programmable logic controllers”.

The problem is, however, that §1501 does not also include the terms ‘cybersecurity risks’ or ‘incident’. One could use the current reference to §148 for those terms but specify that the term ‘information system’ is based upon §1501. Doing that in both instances where the first two terms are currently used would be very wordy and potentially confusing.

It would probably be better to add a new paragraph to §4 of the bill that provides definitions that would be used in the Port Security chapter of the US Code (46 USC 70101). If I were doing this, I would add the following definitions:

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

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

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

(4) The term ‘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;

With these definitions in place the references to §148 are superfluous and should be removed. Then the intent would be clear that the bill would be addressing both the information and control system cybersecurity of port operations. And that is almost certainly the intent of the crafters of this bill.

Bills Introduced – 06-16-17

With both the House and Senate gone for the weekend there were 8 bills introduced in a proforma session in the House. Of those one may be of specific interest to readers of this blog:

HR 2930 To develop a civil unmanned aircraft policy framework, a pilot program, and for other purposes. Rep. Lewis, Jason [R-MN-2]

I will be watching this bill to see if it addresses issues related to UAS and critical infrastructure security.

Public ICS Disclosure – Week of 6-10-17

This week Richard Young described a privilege escalation vulnerability on the APC UPS Daemon. The Seclist – Full Disclosure report notes that Young has attempted a coordinated disclosure, but received an inadequate response from the vendor. He reports that:

“The default installation of APCUPSD allows a local unprivileged user to run arbitrary code with elevated privileges by replacing the service executable apcupsd.exe with a malicious executable, which will run with SYSTEM privileges at startup.”

The APCUPSD web site reports that the program supports Modbus (via both serial and USB connections) making this UPS support program vulnerability potentially a control system security issue.
/* Use this with templates/template-twocol.html */