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 */