Tuesday, October 31, 2017

ICS-CERT Publishes Two Advisories

Today the DHS ICS-CERT published two control system security advisories for products from Trihedral Engineering and ABB. The ABB advisory addresses a vulnerability that I addressed ten days ago.

Trihedral Advisory

This advisory describes two vulnerabilities in the Trihedral VTScada. The vulnerabilities were independently reported by Karn Ganeshen and Mark Cross. Trihedral has a new version that mitigates the vulnerabilities. There is no indication that either researcher has been provided the opportunity to verify the efficacy of the fix.

The two reported vulnerabilities are:

• Improper access control - CVE-2017-14031;
• Uncontrolled search path element - CVE-2017-14029

ICS-CERT reports that a relatively low skilled attacker with uncharacterized access could exploit the vulnerability to allow execution of arbitrary code.

NOTE: If one were to look for one possible explanation about why owner/operators are slow to update their ICS software, one would need to look no further than the Trihedral upgrade notes for moving from v11.2 to the current version. Lots of work and lots of tools do not carry over to the newest version.

ABB Advisory

This advisory describes an improper input validation vulnerability in the ABB FOX515T. The vulnerability was reported by Ketan Bali. ABB reports that the device has been phased out and is no longer being supported. The ABB cybersecurity advisory reports that there are no work around available for this vulnerability.

ICS-CERT reports that a relatively low skilled attacker with uncharacterized access could exploit this vulnerability to craft a malicious script that would enable retrieval of any file on the server.


Two security researchers independently detecting and reporting the same vulnerabilities is not real common, but I suspect that is more due to the reporting component of that statement rather than the detection component. This is an important concept for security researchers and vendors to remember when they decide whether or not to communicate vulnerabilities.

For vendors trying to determine whether or not to report an in-house detected vulnerability they first have to determine if they are going to (or can) patch/upgrade to mitigate the vulnerability. If they do not patch, they are risking having an independent researcher/team discover the vulnerability and either misuse it or selling it to somewhere.

If the vendor fixes the vulnerability the question arises of whether or not to report the underlying vulnerability or letting the update stand on routine improvements to the device/system. As I have mentioned before, ICS owners are slow to update for any number of reasons; the risk of a security vulnerability un-fixed may be the incentive needed to upgrade to a newer version.

Monday, October 30, 2017

HR 4120 Introduced – ICS Research

On Wednesday Rep. Bera (D,CA) introduced HR 4120, the Grid Cybersecurity Research and Development Act. The bill would provide for a comprehensive interdisciplinary research and development initiative to strengthen the capacity of the electricity sector to neutralize cyberattacks.


Section 3 of the bill provides the working definitions for the bill. Since this is a stand-alone bill (not amending existing legislation) these definitions are very important. The terms include:

• Critical electric infrastructure information – uses definition from 16 USC 824o-1 (incorrectly printed in the bill as ‘824a-1’);
• Cybersecurity – “means a set of preventative measures to protect information from a digital device or system, including a device or system used to manage the electric grid, from being stolen, compromised, or used to carry out an attack” {§3(2)};
• Human factors research – “means research on human performance in social and physical environments, and on the integration of humans with physical systems and computer hardware and software” {§3(5)};
• Human-machine interface – “means technologies that present information to an operator about the state of a process or system, or accept human instructions to implement an action, including visualization displays such as a graphical user interface” {§3(6)}; and
• Transient devices – “means removable media, including floppy disks, compact disks, USB flash drives, external hard drives, mobile devices, and other devices that utilize wireless connections for limited periods of time {§3(8)}.

Energy Cybersecurity R&D

Section 4 of the bill requires the Secretary of Energy, in coordination with a variety of federal, state and local agencies and private sector groups, to “carry out a research, develop23
ment, and demonstration initiative to harden and mitigate the electric grid from the consequences of cyber attacks by increasing the cybersecurity capabilities of the electricity sector and accelerating the development of cyberse curity technologies and tools” {§4(a)}. It specifically identifies responsibility to carry out activities to {§4(b)}:

• Identify cybersecurity risks to the communication and control systems within, and impacting, the electricity sector;
• Develop methods and tools to rapidly detect cyber intruders and cyber incidents, including the use of data analytics techniques to validate and verify system behavior using multiple data streams reflecting the state of the system;
• Assess emerging energy technology cybersecurity capabilities, and integrate cybersecurity features and protocols into the design, development, and deployment of emerging technologies, including renewable energy technologies;
• Develop secure industrial control system protocols and identify vulnerabilities in existing protocols;
• Improve the physical security of communication technologies and industrial control systems, including remote assets;
• Integrate human factors research into the design and development of advanced tools and processes for dynamic monitoring, detection, protection, mitigation, and response;
• Advance the capabilities and use of relevant interdisciplinary mathematical and computer simulation modeling and analysis methods;
• Evaluate and understand the potential consequences of practices used to maintain the cybersecurity of information technology systems on the cybersecurity of industrial control systems;
• Increase access to and the capabilities of existing cybersecurity test beds to simulate impacts of cyber-attacks on industrial control system devices, components, software, and hardware; and
• Reduce the cost of implementing effective cybersecurity technologies and tools in the electricity sector.

Additionally, the Energy Department is specifically tasked with working “with manufacturers to build or retrofit security features and protocols into” {§4(b)(5)}:

• Communication and network systems and management processes;
industrial control and energy management system devices, components, software, firmware, and hardware, including distributed control and management systems and building management systems;
• Data storage systems and data management and analysis processes;
• Generation, transmission, distribution, and energy storage technologies;
• Automated and manually controlled devices and equipment for monitoring or managing frequency, voltage, and current;
• Technologies used to synchronize time and develop guidance for operational contingency plans when time synchronization technologies are compromised;
• End user elements that connect to the grid, and
• The supply chain of electric grid management system components.

Technical Guidance and Standards

Section 5 of the bill addresses support activities required by DOE and other federal agencies in developing and sharing technical guidance documents and standards.

DOE is required to facilitate the updating of {§5(a)(1)}:

DOE is also required to develop voluntary guidance to improve forensic analysis capabilities to include {§5(a)(2)}:

• Developing standardized terminology and monitoring processes;
Identifying minimum data needed; and
• Utilizing human factors research to develop more effective procedures for logging incident events; and
• Developing a mechanism to anonymize, aggregate, and share the testing results from cybersecurity industrial control system test beds to facilitate technology improvements by public and private sector researchers.

DOE and the National Institute of Standards and Technology (NIST) are tasked with developing voluntary, consensus-based standards to improve cybersecurity for {§5(c)(1)}:

• Emerging energy technologies;
• Distributed generation and storage technologies, and other distributed energy re24
• Electric vehicles; and other technologies and devices that connect to the electric grid that can affect voltage stability.

Vulnerability Testing

Section 6 of the bill requires DOE to work with owner/operators and the national laboratories to {§6(a)}:

• Utilize a range of methods, including voluntary vulnerability testing and red team-blue team exercises, to identify vulnerabilities in physical and cyber systems;
• Develop cybersecurity risk assessment tools and provide confidential analyses and recommendations to participating stakeholders;
• Work with stakeholders to develop methods to share anonymized and aggregated results in a format that enables the electricity sector, researchers, and the private sector to advance cybersecurity efforts, technologies, and tools;
• Identify information, research, staff training, and analysis tools needed to evaluate industrial control system cybersecurity issues and challenges in the electricity sector; and
• Facilitate the sharing of information and the development of tools needed to evaluate industrial control system cybersecurity issues.


Section 11 of the bill provides the authorization for spending money to support the various programs called for in this bill. It sets the following annual authorization amounts:

$65,000,000 for fiscal year 2018;
$68,250,000 for fiscal year 2019;
$71,662,500 for fiscal year 2020;
$75,245,625 for fiscal year 2021; and
$79,007,906 for fiscal year 2022.

Moving Forward

Bera is a member of the House Science, Space, and Technology Committee to which the bill was assigned for primary consideration. His three cosponsors are also influential Democrats on that Committee. This means that there may be enough influence to have the bill be considered in Committee. The one problem here is that there are no Republican cosponsors of the bill, indicating a potential lack of bipartisan support.

Since no regulatory actions are included (or authorized) by the bill the only thing that will draw any real opposition is the authorized spending. Those monies will have to come from somewhere in the budget and probably from the DOE budget. With money already tight, this will be the major stumbling block that the sponsors will have to overcome to see this bill considered in Committee and move it to the floor of the House.


The Committee Staff members that crafted this bill are to be commended on developing a comprehensive energy sector cybersecurity bill. Section 2 of the bill, the Congressional Findings that support the need for the bill, is one of the best non-technical descriptions of the cybersecurity problems facing the electrical grid that I have seen. It includes an appropriately nuanced attention to the differences between information and operational technology and a realistic appreciation of the role of human factors in the problem. Good job.

Having said that, there are a few short comings that need to be addressed. The first is the issue of Critical Electric Infrastructure Information (CEII), the controlled but unclassified information system protecting information shared by the electric grid industry and the Department of Energy. Throughout this bill there are numerous references rightfully reiterating that the information shared by industry with DOE is protected from public disclosure under this program.

There are multiple references in the bill to ‘aggregating and anonymizing information’ as this is the key to ‘sharing’ the information provided under the CEII program. Unfortunately, the federal government does a poor job generally (and I suspect DOE specifically) of sanitizing and sharing restricted information. This may not be a problem within the grid operation community (I don’t have the information necessary to make the assessment), but DOE does not play well with outsiders.

This is a problem here because large amounts of the ICS cybersecurity research and development efforts outlined in the bill could have enormous positive impacts on the remainder of the ICS community. DOE has no incentive, nor even a mechanism, to share this valuable information outside of their regulated community.

This problem is further compounded by the failure to specifically include ICS-CERT in the federal agencies to be included in this development effort. ICS-CERT is the only federal agency with the sole focus on the cybersecurity of industrial control systems. And they have the mechanisms in place to share information with the remainder of the ICS security community.

The other major issue is the lack of attention to the issue of vulnerability disclosures. The bill attempts to address the issue in §6 of the bill, but it only really looks at system testing at the facility level. While this is certainly a valuable part of vulnerability testing, it ignores the much larger issue of the cybersecurity testing of individual components of the control systems done on a daily basis by independent security researchers and relatively small research companies.

Congress needs to come up with a way to incentivize those researchers to share their information with DOE instead of with the other existing organizations that pay researchers for their identified vulnerabilities and then provide the information to paying customers. DOE needs to establish a coordinating mechanism so that vulnerability reports from researchers are coordinated with the vendors and the mitigation measures are reported to the user community. OR the bill could just recognize the already existing mechanisms established by ICS-CERT and provide for priority disclosure of vulnerabilities and their mitigations to grid operators (and establishing a mechanism for doing that).

Saturday, October 28, 2017

Bills Introduced – 10-27-17

Yesterday, with the House meeting in proforma session (probably three congresscritters present), there were 8 bills introduced. Of those one may be of specific interest to readers of this blog:

HR 4163 To establish a voluntary program to identify and promote Internet-connected products that meet industry-leading cybersecurity and data security standards, guidelines, best practices, methodologies, procedures, and processes. Rep. Lieu, Ted [D-CA-33] 

This is probably a companion bill to S 2020 that was introduced Thursday.

Friday, October 27, 2017

Bills Introduced – 10-26-17

Yesterday, as the House and Senate were preparing to leave for the weekend, 50 bills were introduced. Of those three may be of specific interest to readers of this blog:

HR 4147 To amend title 49, United States Code, to provide certain port authorities, and for other purposes. Rep. Nadler, Jerrold [D-NY-10]

HR 4151 To promote the use of smart technologies and systems in communities, and for other purposes. Rep. Comstock, Barbara [R-VA-10]

S 2020 A bill to establish a voluntary program to identify and promote Internet-connected products that meet industry-leading cybersecurity and data security standards, guidelines, best practices, methodologies, procedures, and processes. Sen. Markey, Edward J. [D-MA]

It is not clear whether or not HR 4147 or HR 4151 include cybersecurity provisions at this point. If they do, they will receive further mention.

S 2020 looks like it will be another overly broad effort by Markey to address a very real cybersecurity concern. This bill will only receive further mention here if the definition of ‘Internet-connected products’ includes industrial control systems.

Thursday, October 26, 2017

ICS-CERT Publishes 2 Advisories

Today the DHS ICS-CERT published two control system security advisories for products from Korenix and Rockwell.

Rockwell Advisory

This advisory describes a reusing a nonce, key pair in encryption vulnerability in the Rockwell Stratix 5100 Wireless Access Point. This is the ‘KRACK’ (Key Reinstallation Attack) vulnerability that has been in the news lately (see here for example). The advisory reports that the vulnerability was discovered by Mathy Vanhoef; this attribution is for the KRACK vulnerability generally, not necessarily the specific instance of the vulnerability in this device. Rockwell will produce a new firmware version that mitigates the vulnerability in this device.

ICS-CERT reports that an uncharacterized attacker presumably with access to a wi-fi signal could exploit the vulnerability with a publicly available exploit to operate as a “man-in-the-middle” between the device and the wireless network.

NOTE: The advisory only claims CVE-2017-13082. This is just one of the 10 CVE’s associated with the KRACK vulnerability. It is not clear if this is just an oversight or if this is the only part of the vulnerability found in this particular implementation of the WPA2 standard. I suspect that it is the former.

Korenix Advisory

This advisory describes two vulnerabilities in the Korenix JetNet ethernet switch. The vulnerabilities were reported by Mandar Jadhav of the Qualys Vulnerability Signature/Research Team. Korenix has produced new firmware that mitigates the two vulnerabilities. There is no indication that Jadhav 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 gain remote access to the device to run arbitrary code and perform man-in-the-middle attacks.


It is odd that ICS-CERT published the Rockwell Advisory without publishing a general alert about the KRACK vulnerability. Any control system devices that provide for wi-fi access while using the WPA2 security protocol are most likely affected by KRACK.

Fixing just one side of the communications link could still possibly leave the network vulnerable to this vulnerability, particularly since this is potentially 10 separate vulnerabilities. This is addressed in the advisory; noting that:

“Rockwell Automation recommends that all users patch the clients that connect to the Stratix 5100 WAP/WGB, and recommends contacting your supplier to get the most updated patch that is compatible with your client devices. However, patching the client only protects the connection formed by that specific client.”

ICS-CERT certainly needs to address this vulnerability since it potentially affects a wide-swath of the wi-fi capable control system devices; a quickly-growing number of devices if vendor ads are any indication.

Bills Introduced – 10-25-17

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

HR 4120 To provide for a comprehensive interdisciplinary research and development initiative to strengthen the capacity of the electricity sector to neutralize cyber attacks. Rep. Bera, Ami [D-CA-7] 

Any such research should be beneficial to the ICS community as a whole.

Wednesday, October 25, 2017

ISCD Updated More FAQs

Today the DHS Infrastructure Security Compliance Division (ISCD) updated 18 frequently asked question (FAQ) responses on the Chemical Facility Anti-Terrorism Standards (CFATS) Knowledge Center web site. While none of the changes reflect new major policy changes, ISCD did specifically mention these updates in the ‘Latest News’ section of the page.

The FAQ responses that were changed include:

Inconsequential Changes

A number of the changes are inconsequential changes in wording. Typically, they have been made necessary by recent regulatory and legislative revisions to the CFATS program. These include:

• Removing/replacing references to ‘§550’ CFATS program authorization (FAQ# 1178, and FAQ# 1657);
• Removing confusing references to ammonium nitrate “as an explosive” (FAQ# 1228);
• Adding links to CFR references (FAQ# 1228, FAQ# 1382, FAQ# 1481, FAQ# 1743, and FAQ# 1746);
• Removing the name of ISCD Director from the recipient address used to mail CFATS communications (FAQ# 1275, and FAQ# 1756);
• Removing references to the old Tier finalization after SVA submission process (FAQ# 1660);

Previously Announced Policy Changes

Most of the changes in responses were made to reflect policy changes that have been explained in more detail in other places on the CFATS web site. These include:

Added references to the DHS policy of indefinitely extending due dates for Top Screen submissions from facilities with only COI present in a gasoline mixture (FAQ# 1457);
Added comment about ISCD Policy for Assessing a Civil Penalty (FAQ# 1554);
Removed reference to statutory EAP submission deadlines relative only to the initiation of that program (FAQ# 1746);
Removed reference to Memorandum of Understanding between DHS and NRC (FAQ# 1782).

Nuanced Changes in Policy

The remaining changes are more nuanced changes in the wording of the responses, that were made for clarification purposes or to reflect possible minor changes in the way that ISCD looks at an issue.

FAQ# 1194. In the last sentence of the note at the bottom of the FAQ response the words ‘Laboratory quantities of” were replaced with ‘Threshold quantities of’. This reflects the fact the quantities only have to be reported on the Top Screen if they exceed the screening threshold quantity (STQ). Laboratory quantities of theft/diversion and contamination chemicals of interest (COI) need to be included in the inventory used to determine if the STQ has been met.

FAQ# 1373. Adds a brief mention of the 87.5% concentration limit for propane that was outlined in a Federal Register Notice on March 21st, 2008. Unfortunately, the revised FAQ response does not provide the reference (link) for that policy explanation.

FAQ# 1382. Adds a note that COI in piping is only counted for release COI since theft/diversion and contamination COI are only counted when in transportation packaging. This makes sense when explained, but may not have been obvious otherwise.

FAQ# 1635. The wording change in the first paragraph of this response seems to clarify that a “facility may choose [emphasis added] to inform DHS about other chemicals [other than DHS chemicals of interest] at a covered facility that pose risks comparable to, or that substantially contribute to, the risks posed by COI listed in Appendix A” in reference to the discussion of the terms "hazardous materials" in RBPS 5 and "potentially dangerous chemicals" in RBPS 6.

The apparent clarification is muddied by the unchanged wording in the second paragraph of that response that explains that facilities can seek assistance from DHS “in determining which chemicals and hazardous materials must be addressed [emphasis added] under RBPS 5 or 6”.

FAQ# 1735. This FAQ response was changed by removing the following (2nd) paragraph:

“In addition, corporations with numerous CFATS covered facilities may be able to work with DHS to coordinate inspection schedules. This may allow for a staggered inspection schedule, staggered Site Security Plan/Alternative Security Program SSP/ASP submissions and/or multiple inspections to take place in one week, which may provide efficiencies for both DHS and the corporation.”

NOTE: Yesterday’s reported FAQ update was included in today’s ‘Latest News’ listing.

HR 3101 Passed in House – Port Cybersecurity

Yesterday the House passed HR 3101, the Strengthening Cybersecurity Information Sharing and Coordination in Our Ports Act of 2017, by a voice vote.

As I noted in an earlier post the version of the bill approved yesterday is not the same version that was reported by the House Homeland Security Committee. The amended text is available in the Congressional Record. The change is inconsequential; a reformatting of the list of organizations to be included in the information sharing recommendations in §2(5).

This bill had wide bipartisan support in the House and will likely have the same in the Senate if it reaches the floor for consideration, not a necessarily guaranteed action. I do suspect that the bill will eventually be considered under the Senate’s unanimous consent provisions with no debate, no vote, and few Senators on the floor of the Senate. Nothing untoward in this, it is just the way that the Senate expeditiously handles non-controversial legislation. A single objection from the floor would prevent the action going forward, so the leadership is careful about how the process is used.

As I have noted in previous discussions, this bill continues to use the IT-limited cybersecurity definitions of 6 USC 148. This means that the provisions of this bill do not specifically include control system cybersecurity in the vulnerability assessment and security plan provisions the added cybersecurity requirements for 46 USC §70102 and §70103. This is a serious deficiency in the bill, and it will not be corrected as no further amendment processes are likely to be included in the future consideration of the bill.

Tuesday, October 24, 2017

ISCD Updates Co-location FAQ

Today the DHS Infrastructure Security Compliance Division (ISCD) updated a frequently asked question (FAQ) on their Chemical Facility Anti-Terrorism Standards (CFATS) Knowledge Center. FAQ 1143 deals with the determination of who is responsible for submitting Top Screens when two or more facilities are co-located.

The change was extremely small; the substitution of a comma for a misplaced period in the fifth sentence (after the word ‘circumstances’) of the FAQ response. A very easily overlooked typographical error; I wonder who caught it? I never would have.

This FAQ was previously updated on March 30th, 2017.

HR 4036 Introduced – “Hack Back Bill”

Earlier this month Rep. Graves (R,GA) introduced HR 4036, the Active Cyber Defense Certainty Act. The bill would amend 18 USC 1030 to, according to a Graves press release, “to allow use of limited defensive measures that exceed the boundaries of one’s network in order to monitor, identify and stop attackers.”

Attributional Technology

Section 3 of the bill would add a new paragraph (k) to §1030 that introduces the concept of ‘attributional technology’. It defines the term as “any digital information such as log files, text strings, time stamps, malware samples, identifiers such as user names and Internet Protocol addresses and metadata or other digital artifacts gathered through forensic analysis” {new §1030(k)(2)}.

The new paragraph would exempt the use of attributional technology from prosecution under §1030 when used by “a defender who uses a program, code, or command for attributional purposes that beacons or returns locational or attributional data in response to a cyber intrusion in order to identify the source of an intrusion” {new §1030(k)(1)}. The ‘program, code or command’ must have been removed from the defender’s computer by the unauthorized user being attributed. Further the ‘program, code or command’ cannot “result in the destruction of data or result in an impairment of the essential operating functionality of the attacker’s computer system, or intentionally create a backdoor enabling intrusive access into the attacker’s computer system” {new §1030(k)(1)(B)}.

Active Cyber Defense

Section 4 of the bill would add a new paragraph (l) to §1030 that introduces the concept of ‘active cyber defense’. The term is defined as actions taken by (or at the direction of) a defender accessing without authorization the computer of the attacker to the defender’s own network to gather information in order to {new §1030(l)(3)(B)(i)(II)}:

• Establish attribution of criminal activity to share with law enforcement and other United States Government agencies responsible for cybersecurity;
• Disrupt continued unauthorized activity against the defender’s own network; or
• Monitor the behavior of an attacker to assist in developing future intrusion prevention or cyber defense techniques.

The definition goes on to exclude any actions that {new §1030(l)(3)(B)(ii)}:

• Intentionally destroys or renders inoperable information that does not belong to the victim that is stored on another person or entity’s computer;
• Recklessly causes physical injury or financial loss as described under subsection (c)(4);
• Creates a threat to the public health or safety;
• Intentionally exceeds the level of activity required to perform reconnaissance on an intermediary computer to allow for attribution of the origin of the persistent cyber intrusion;
• Intentionally results in intrusive or remote access into an intermediary’s computer;
• Intentionally results in the persistent disruption to a person or entities internet connectivity resulting in damages defined under §1030(c)(4); or
• Impacts any computer described under §1030(a)(1) regarding access to national security information computers, or to §1030(c)(4)(A)(i)(V) regarding a computer system used by or for a Government entity for the furtherance of the administration of justice.

Section 5 of the bill adds a new paragraph (m) to §1030 that further limits the use of an ‘active cyber defense’ by requiring a requirement for advance notification of its use to the FBI. Approval is not required, but acknowledgement of receipt is a prerequisite for the use of ‘active cyber defense’ measures. The notification would be required to include {§1030(m)(2)}:

• The type of cyber breach that the person or entity was a victim of, the intended target of the active cyber defense measure, the steps the defender plans to take to preserve evidence of the attacker’s criminal cyber intrusion;
• The steps they plan to prevent damage to intermediary computers not under the ownership of the attacker; and
• Other information requested by the FBI to assist with oversight.

Other Provisions

Section 6 of the bill would require the FBI to establish a program “to allow for a voluntary preemptive review of active defense measures” {§7(a)}. It would provide for the review to provide an assessment of “how the proposed active defense measure may be amended to better conform to Federal law, the terms of section 4 [new §1030(l)], and improve the technical operation of the measure” {§7(b)}.

Section 7 of the bill would provide for the obligatory report to Congress.

Section 8 of the bill would require the Department of Justice to update it’s ‘‘Prosecuting Computer Crimes Manual’’ to reflect the changes made by this legislation.

Section 9 of the bill would provide for a two-year sunset provision; removing the changes to §1030 two years after the bill is enacted.

Moving Forward

Neither Graves nor his cosponsor {Rep. Sinema (D,AZ)} are members of the House Judiciary Committee to which this bill was referred for consideration. That means that it is unlikely that the bill will be considered in that Committee.

A number of attempts have been made to amend §1030 over the last couple of sessions (see for example here) carving out exemptions to the provisions of the statute. There is a natural legislative inertia when it comes to changing criminal law. I expect that the same inertia would apply to this bill, above and beyond the lack of influence that the sponsors have to move the bill forward.


This bill has received lots of attention in the press (see here, here and here for example) when it was introduced but it seems that many have missed an important component of the legislative requirements; any tool used to ‘hack back’ would have to be extracted from the defenders computer by the attacker. The defender would have to construct a honey-target (smaller than a honey-pot) file that the attacker downloads from the defended system. That file would include some sort of communications protocol that would send information back to the defender that provides attributional information on the attacker.

If this sounds like what a hacker does when they use a phishing attack or boobytrapped web site, that is almost certainly deliberate. It requires the attacker to be explicitly involved in ultimately providing information from their system to the original defender. This may end up causing problems in using the information obtained under the self-incrimination provisions of US law. Lawyers will have fun arguing both sides of this.

What the bill does not allow, and in fact explicitly prohibits, is either the establishment of a backdoor or actively pivoting through the attacker’s system searching for information. This is the typical next step of an attack on a computer system. This is what distinguishes the bills ‘hacking back’ (the term is not actually used in the bill) from the prohibited actions of §1030.

The requirements for pre-notification help to ensure that the new provisions are not used by nefarious hackers as an extraneous tool in defending against prosecution for traditional hacking prohibited by §1030.

It is important to note that the active cyber defense provisions are not an exemption from prosecution under §1030, instead it allows them to be used as a defense against federal charges under §1030. That means that prosecution for a properly notified active defense measure is still possible at the discretion of the government. A judge would have to decide if the active cyber defense measures actually-employed met the requirements of the revised §1030. FBI ‘approval’ of the proposed active defense measures would obviously be beneficial in convincing a judge of the appropriateness of the activities.

More importantly, the active cyber defense provisions in the bill are specifically not allowed to be used as a defense in a civil action undertaken under §1030(g). That paragraph allows anyone who suffers ‘damage or loss’ from unauthorized access to a system to obtain “compensatory damages and injunctive relief or other equitable relief” in federal courts. The reasoning is that active cyber defense measures cannot, by definition, cause damage or loss, so proving damage or loss means that an authorized ‘active cyber defense’ measure was not employed.

Unfortunately, the provisions in this bill would only apply to attackers using computers located in the United States. This is an inevitable problem cause by international law; each country has sovereign control of the rules prohibiting access to computers physically located within their boundaries. Prosecution would have to take place in the target country, but extradition could be possible depending on the extradition status of the country involved.

The problem here is that, by definition, a defender would not know the location of the target computer when they initiated active cyber defense measures. Thus, a defender could end up violating foreign law by executing measures allowed by this bill and could be potentially extradited to face charges for that violation. This bill should include provisions that require a judge at an extradition hearing from taking specific cognizance of the provisions of this bill as a defense against extradition. This would not, however, protect a defender against arrest and prosecution while traveling outside of the US.

Monday, October 23, 2017

House Passes HR 4038 – DHS Reorganization

This afternoon the House passed HR 4038, the DHS Accountability Enhancement Act, by a voice vote. There was only six minutes of debate on the bill.

I suspect that the bill will be taken up in the not too distant future in the Senate. It will most likely be considered in that body under their unanimous consent process; less debate and not even the easy formality of the voice vote.

HR 3101 Reported in House – Port Cybersecurity

Last week the House Homeland Security Committee published their report on HR 3101, the Strengthening Cybersecurity Information Sharing and Coordination in Our Ports Act of 2017. The same day, the House Transportation and Infrastructure Committee was discharged from further consideration of the bill.

HR 3101 was ordered reported without amendment when it was considered by the Committee on 9-7-17. This typically means that there is little to be gained by reviewing the report. But, with Transportation and Infrastructure Committee being discharged from consideration, it is important to look at the included letter (pgs 15) from the Chair of that Committee {Rep. Shuster (R,PA)} to see if there were any conditions imposed when he acquiesced in allowing the bill to move forward.

Sure enough, there were two conditions, both agreed to by Chairman McCaul (R,TX). The second, is the standard requirement that the Transportation and Infrastructure Committee be represented in any conference (if required) on the bill. The first is:

“Further, this is conditional on our understanding that mutually agreed upon changes to the legislation will be incorporated into the bill prior to floor consideration.”

There are no changes in the reported version of HR 3101, as I would expect given the fact that no amendments were adopted by the Committee. We will not be able to see the changes that are being made until today’s Congressional Record is published tomorrow (remember, the bill is being considered on the floor today). Interestingly, neither will any of the members of Congress that will be voting on the bill. Such is the power of committee chairs.

I do not expect that the changes will be major and I do not really look for them to make changes to affect the IT-centric nature of this bill.

Committee Hearings – Week of 10-22-17

With both the House and Senate in Washington at the same time for the first time in two weeks, the most interesting congressional actions are taking place behind closed doors as the HR 2810 conference committee starts to work out the differences between the two versions of the 2018 National Defense Authorization Act. On the public side, there will be three cybersecurity hearings this week that may be of specific interest to readers of this blog.


On Tuesday two subcommittees of the House Homeland Security Committee will hold a joint hearing on “Public-Private Solutions to Educating a Cyber Workforce”. A witness list is not yet available for this hearing. The Committee has a number of bills pending that address this topic.

On Wednesday the Oversight Subcommittee of the House Science, Space, and Technology Committee will hold a hearing on “Assessing the Risk of Kaspersky Lab Products to the Federal Government”. The witness list includes:

• Donna Dodson, National Institute of Standards and Technology;
• David Shive, General Services Administration;
• James Norton, Play-Action Strategies LLC; and
• Sean Kanuck, International Institute for Strategic Studies

Kaspersky has volunteered to testify before this type of hearing. News reports indicate that he will probably appear at a future date as part of an on-going review of this topic by the Committee. I expect that at some point both the FBI and DHS will make similar appearances.

On Thursday the Senate Energy and Natural Resources Committee will hold a hearing on “Cyber Technology and Energy Infrastructure”. No witness list is currently available.

On the Floor

The House will take up two cybersecurity bills this week under the suspension of the rules provision. This means there will be limited debate and no floor amendments. More importantly, it typically indicates that the House leadership expects to see substantial bipartisan support for the bills since these rules require a 75% supermajority to pass the bill. The two cybersecurity related bills are:

HR 4038 (today), the DHS Accountability Enhancement Act; and

HR 3101 (Tuesday), the Strengthening Cybersecurity Information Sharing and Coordination in Our Ports Act of 2017

Saturday, October 21, 2017

Public ICS Disclosure – Week of 10-15-17

We have two publicly disclosed industrial control system product vulnerabilities this week that were not addressed by ICS-CERT; one reported by a security researcher and the other self-reported by the vendor.

HP Vulnerability

On Wednesday Maor Shwartz from SecuriTeam described on FullDisclosure a cross-site scripting vulnerability in the Hewlett Packard Baseline Smart Gig SFP 24 ethernet switch. This product was acquired by HP from 3Com (3Com Baseline Switch 2924 SFP Plus Switch) and is no longer supported, so no fix is forth coming. The SecuriTeam blog provides a proof of concept exploit for the vulnerability.

ABB Vulnerability

On Tuesday Joel Langill, on LinkedIn, pointed out a cybersecurity advisory from ABB on their FOX515T release 1.0 communications equipment. It describes a local file inclusion vulnerability in the embedded web server. This is another out-of-service product with no fix in the works.


Joel and I had a brief discussion on LinkedIn about this type of out-of-service vulnerability reporting. I had my typical snarky comment about no one using out-of-service equipment in the ICS realm. Joel had a very interesting reply:

“Like so many of the ICS-CERT advisories. Still wonder why they waste valuable time on disclosures of unsupported equipment. My lab is still a wealth of discovery and exploitation! But I prefer to keep these vulns quiet.”

I have to vigorously disagree with Joel. I think that someone needs to publicize these types of vulnerability reports because so many facilities are actually continuing to use ‘outdated’ control system devices on the ‘if it ain’t broke don’t fix it’ model. Depending on the severity of the vulnerability (and the site-specific risk calculation) the disclosure of these vulnerabilities may be just the ‘it is broke’ incentive that owners need to replace the equipment to avoid the vulnerability. Holding these vulnerabilities in-house (either at a researcher or vendor level) provides little service to owners.

Now, there is a legitimate question if this is an appropriate function for ICS-CERT to perform. I point at them as the default government agency in the control system security realm, but they do not have a specific mandate to do this nor do they have a specific mandate of any kind. They are an agency created out of whole cloth by DHS without specific authorization by Congress. A necessary move, to be sure, but there has been no public discussion of, or political determination of, the specific role of the organization. That really needs to change.

Friday, October 20, 2017

HR 3985 Introduced – IoMT Security

Earlier this month Rep. Trott (R,MI) introduced HR 3985, the Internet of Medical Things Resilience Partnership Act of 2017. The bill would 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.

The Working Group

The Working Group would be chaired by the FDA Commissioner. The other members would represent {§2(b)(3)}:

• The Center for Devices and Radiological Health of the Food and Drug Administration;
• The Office of the National Coordinator for Health Information Technology of the Department of Health and Human Services;
• The Office of Technology Research and Investigation of the Federal Trade Commission;
• The Cybersecurity and Communications Reliability Division of the Federal Communications Commission;
• The National Institute of Standards and Technology of the Department of Com1merce; and
• The National Cyber Security Alliance

Additionally, the Chair would appoint three members each from the following private sector groups {§2(b)(4)}:

• Medical device manufacturers;
• Health care providers;
• Health insurance providers;
• Cloud computing;
• Wireless network providers;
• Enterprise security solutions systems;
• Health information technology;
• Web-based mobile application developers;
• Software developers; and
• Hardware developers.

The Group would have 18 months to prepare a report to Congress that provides recommendation that {§2(c)}:

• An identification of existing cybersecurity standards, guidelines, frameworks, and best practices that are applicable to mitigate vulnerabilities in the devices described in subsection (a);
• An identification of existing and developing international and domestic cybersecurity standards, guidelines, frameworks, and best practices that mitigate vulnerabilities in such devices;
• A specification of high-priority gaps for which new or revised standards are needed; and
• Potential action plans by which such gaps can be addressed.

Moving Forward

While Trott is not a member of the House Energy and Commerce Committee (the Committee to which this bill was assigned for consideration), his co-sponsor, Rep. Brooks (R,IN) is. This means that it is possible that this bill may be considered in Committee.

I see nothing in the bill that would engender any specific opposition, so the bill would probably draw at least some bipartisan support and could pass in Committee and on the floor. It would all depend on how much leadership support could be generated for the consideration of this bill.


Congress frequently uses these types of study committees to develop workable solutions to complex technical problems. Unfortunately, there is no guarantee that the solutions prepared by such a working group would ever actually be considered by Congress, or converted into a legislative proposal for regulating the cybersecurity of medical devices.

The lack of any real definitions of terms or the extent of the problem provides the Group with a rather wide mandate. This could be a good thing, but it is more likely to dilute the energy of the group into spending too much time in defining the scope of the problem rather than working on proposals to solve the problem.

Finally, I see two major shortcomings; gaps in the proposed membership, and the lack of organizational details.

On the membership issue, it is clear to me that ICS-CERT should have been included in the list of government agencies that should be represented in the Working Group. That and the lack of inclusion of security researchers would seem to indicate that Trott and Brooks (and more likely, their staffs) are deliberately ignoring the problem of the identification of security vulnerabilities in specific devices by the independent security research community affects the cybersecurity of medical devices. The lack of any formal coordinated disclosure process is an obvious hole in medical device security that needs to be addressed.

Because the Working Group includes both governmental and private sector representatives, the lack of any reference to the rules regarding advisory groups is a glaring omission in this bill. Thus, the Group would again have to expend time and resources working out their rules for their meetings, including public accessibility and notifications of meetings. Again, with an 18-month time limit, they do not need that distraction.

Thursday, October 19, 2017

ICS-CERT Publishes 2 Advisories and 1 Update

Today the DHS ICS-CERT published one medical control system security advisory for a product from Boston Scientific. Additionally, they published an industrial control system advisory for a product from SpiderControl. They also updated a medical control system advisory for a product from Becton, Dickinson and Company.

Boston Scientific Advisory

This advisory describes two vulnerabilities for the Boston Scientific ZOOM LATITUDE Programmer/Recorder/Monitor (PRM). The vulnerabilities were reported by Jonathan Butts and Billy Rios of Whitescope. Boston Scientific has provided mitigating controls. ICS-CERT reports that Boston Scientific will not be fixing the vulnerabilities.

The two reported vulnerabilities are:

• Use of hard-coded cryptographic key - CVE-2017-14014; and
• Missing encryption of sensitive data - CVE-2017-14012

ICS-CERT reports that an uncharacterized attacker with physical access to the device could exploit these vulnerabilities to obtain patient health information (PHI).

SpiderControl Advisory

This advisory describes an uncontrolled search path element vulnerability in the SpiderControl MicroBrowser, a touch panel operating system. The vulnerability was reported by Karn Ganeshen. SpiderControl has provided a new version that mitigates the vulnerability. There is no indication that Ganeshen 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 execute arbitrary code on the target system.

BD Update

This update provides additional information on an advisory that was originally published on February 7th, 2017. The updated information includes:

• The identification of “Researchers at Zingbox” as being involved in the reporting of the vulnerabilities;
• The expansion of the impact statement to include the ability to “compromise the confidentiality, integrity, and availability of the device”;
• The information that an internal removeable flash drive which in some versions provides access to “wireless network authentication credentials and other sensitive technical data on the affected device’s removable flash memories”;
• Updated mitigation measures; and

• A link to the updated BD security bulletin [.PDF download] which provides additional details on the information accessible due to the reported vulnerabilities

A New ICS Security Paradigm?

Yesterday I took a quick drive up to Atlanta to visit a cybersecurity startup to view a demo of a new ICS security tool. I was introduced to Roger Hill, the founder of Veracity, a couple of weeks ago at an Atlanta cybersecurity meetup. In a brief discussion that night he convinced me that yesterday’s trip could be interesting and he was correct.


What Roger demonstrated yesterday was a product called Cerebellum (name and email registration required). It is based upon a pretty standard SEL ethernet switch and provides an organization with a new way to control and monitor communications on a control system network. Ethernet switches are certainly not new; they are a ubiquitous part of all sorts of networks. What Veracity has done is to change the basic rules those switches use to direct traffic on the network to a more sophisticated software tool to establish software defined networks (SDN).

The Cerebellum GUI allows the user to specifically define the place of every control system device within the facility network. Based upon the standard Purdue Model of system architecture, it allows the user to define the networks and subnetworks and to establish what devices are allowed to communicate with each other within and across those networks and what information could be pushed across those channels. And, because it is a software defined network, it allows for establishing changes to those communications rules based upon specific non-standard conditions (maintenance for example).

Okay, that is about all I am technically qualified to explain about how the system works and I am certainly not qualified to assess how well this system works in actual practice. If you are in Atlanta next week for the 2017 ICS Cybersecurity Conference, Roger and his team will be providing a demonstration of the operation of Cerebellum.

Digital Forensics

There are a couple of interesting side benefits to the use of this SDN tool. First is that when any device is either physically connected or reconnected to the network, it is automatically isolated from the SDN. Information about the ‘new’ device (a digital fingerprint) is automatically recorded. This includes any communications that it tries to send out on the physical network.

Additionally, any time that a non-permitted communication is attempted, the system can be programed to record and report that communication. Even allowed communications (for example from an engineering work station to a PLC) can be set up so that they are recorded/reported. This allows for more detailed forensic analysis in the event of incidents or attacks.

Roger pointed out that it was also possible to establish honey net networks and to divert non-permitted communications to those networks. This allows the network administrator to watch what a possible network infiltrator is attempting to do as all communications across the honey net can be recorded. It would also allow for feeding incorrect information to an attacker during the reconnaissance phase of their attack.

Management of Change

Cerebellum can also be used as a management of change tool. Approval to changes on the network require approvals and different approval requirements can be set for different parts of the networks and subnetworks. The change messages and the approvals can be recorded as part of the MOC process for the facility.

Ease of Implementation

Installing this tool simply requires replacing existing ethernet switches with new switches. Initially, the new switches can be run in the data acquisition mode, allowing standard switch communication rules to operate while recording communications across the network. The implementation of the Cerebellum rule set can be done on a subnetwork basis first and then further up the network chain. This allows for minimal interruption operations during the implementation of the new security controls.


The sharp-eyed reader will have probably noticed that I think that this looks like a very interesting addition to the tool set that can be used to protect industrial control systems. Now what I saw yesterday was a software demonstration and there are limits to what you can learn from such demonstrations. Even the hardware-based demonstration that Roger plans for next week is going to provide only limited information on the efficacy of the system.

Roger is working on a DOE project (Chess Master) on the Use of Cerebellum in the grid security application, but he is looking for opportunities to expand the application of his new technology to other sectors. If you are going to be in Atlanta for the conference next week, be sure to look him up.

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.
/* Use this with templates/template-twocol.html */