Tuesday, January 17, 2017

ICS-CERT Publishes Two Advisories

Today the DHS ICS-CERT published two control system security advisories for products from GE and Phoenix Contact. The GE advisory was previously published on the NCCIC Portal on December 1st, 2016.

GE Advisory


This advisory describes an insufficiently protected credentials vulnerability in the GE Proficy Human-Machine Interface/Supervisory Control and Data Acquisition (HMI/SCADA) iFIX, Proficy HMI/SCADA CIMPLICITY, and Proficy Historian software. The vulnerability was reported by Ilya Karpov of Positive Technologies. GE has produced new versions that mitigate the vulnerability. There is no indication that Karpov has been provided the opportunity to verify the efficacy of the fix.

ICS-CERT reports that a highly skilled attacker could exploit the vulnerability with local access and user interaction. This, however, was the vulnerability that ICS-CERT thought posed enough of a threat to critical infrastructure that it required advance notice to critical infrastructure facilities.

Phoenix Contact Advisory


This advisory describes a default password vulnerability in the Phoenix Contact mGuard product that was induced in the system by updating with version 8.4.1. Phoenix Contact self-reported this vulnerability.

ICS-CERT reports that a relatively unskilled attacker could remotely exploit the vulnerability.

Saturday, January 14, 2017

OMB Approves FHWA V2I Guidance Document

Yesterday the OMB’s Office of Information and Regulatory Affairs (OIRA) announced that it had approved an interim guidance document from the DOT’s Federal Highway Administration concerning vehicle to infrastructure (V2I) communications. This was not listed in the Fall 2016 Unified Agenda, but this is certainly part of the DOT’s ongoing intelligent transportation system program.

The FHWA published a draft of this document in 2014. That draft promised the development of a guide to V2I cybersecurity that would include:

“Provides deployers with: (1) an analysis of extensibility of security and trust systems to additional points of connection, including V2I, devices, backhaul, and others; (2) an analysis of additional risks from extensibility and cybersecurity; (3) an analysis of potential impacts to the existing transportation system/networks. It will also provide definitions of the organizational functions and processes for operating the security function, along with cost models for operations and maintenance.”


It will be interesting to see if that management speak is better presented in this new interim guidance document. More importantly, it would be helpful if the cybersecurity guidance was actually included in the upcoming document and not just mentioned as a future project.

Bills Introduced – 01-13-17

With only the House meeting in Washington yesterday there were 76 bills introduced. Of those, only one may be of specific interest to readers of this blog:

HR 526 To amend the Homeland Security Act of 2002 to establish in the Department of Homeland Security a board to coordinate and integrate departmental intelligence, activities, and policy related to counterterrorism, and for other purposes. Rep. Katko, John [R-NY-24]

This bill will only be of interest here if it specifically addresses cybersecurity matters.


There is one other bill that I would like to mention in passing, HR 571, to permit members of the House of Representatives to donate used computer equipment to public elementary and secondary schools designated by the members. I am torn between hoping that the bill sets standards for removing sensitive information from those computers prior to their donation or hoping that computer education programs at those institutions teach the students to look for sensitive information on those computers as a cybersecurity learning aid. I will not be mentioning this bill again on this blog….

Friday, January 13, 2017

HR 59 Introduced – Chemical Facility Security

Last week Rep. Jackson-Lee (D,TX) introduced HR 59, the Frank Lautenberg Memorial Secure Chemical Facilities Act. This bill is nearly identical to HR 54 introduced last session and very similar to bills introduced by Ms Jackson-Lee and Rep. Thompson (D,MS) over the last eight years. It provides a complete re-write of the current chemical facility security rules passed in the 113th Congress.

The bill includes all of the button pushing issues that the Democrats love and the Republicans hate, so there is little chance (actually no chance) that this bill will be considered at any time during this session of congress. In fact, the last time that the Democrats controlled both the House and Senate a similar bill was passed in the House but could not make its way to the floor of the Senate for consideration.

There are, however, some cyber security provisions in this bill that readers of this blog might find of interest.

First the bill would take the current cybersecurity requirements found in 6 CFR 27.230(8) and include them in the language of the newly proposed 6 USC 2203(d)(8). The only changes being made to the language are solely intended to make the requirements more readable (physical formatting changes). Both sets of language require covered chemical facilities to have measures in place to “deterring cyber sabotage, including by preventing unauthorized onsite or remote access to critical process controls” and then lists the general types of systems to be protected, including:

• Supervisory control and data acquisition systems;
• Distributed control systems;
• Process control systems;
• Industrial control systems;
• Critical business systems; and
• Other sensitive computerized systems

The sole purpose of moving the existing risk-based performance standards from the CFR to the USC is to make it harder for DHS to make changes to these standards by regulatory means.

Secondly, under a new §2206, Timely Sharing of Threat Information, the owner/operator is required to notify DHS of “any intentional or unauthorized penetration of the physical security or cyber security of the covered chemical facility, whether successful or unsuccessful” {new §2206(b)(1)(B)}. While the lack of definition of the key term ‘penetration’ is not unusual, it does provide an added measure of lack of clarity when it comes to cybersecurity.

Finally, we see again the requirement for hackers (specifically including “blue hat, red hat, and white hat hackers {§2111(b)(6)}) to “validate the security measures instituted to address cyber based threats”. Ignoring for the moment the lack of definition of key terms including the different colored hats, the requirement does not make any sense. Penetration testing, properly done, can certainly be a good thing for evaluating security controls, but this requirement is placed in the section dealing with conducting assessments of “methods to reduce the consequences of a terrorist attack” not security protocols.

A similar problem is seen in the previous subparagraph in the same section. It refers to:

The design of computing systems and development of plans, exercises, and drills to re-engage computing systems used in the processing, transport, storage of chemicals that are designed as a ‘‘risk’’ by the Secretary using protocols for trusted recovery under the worse case conditions;”


Again, this sounds like good cybersecurity planning and both of these requirements (with adequate definitions of key terms) should be included in the performance standards portion of the bill, not the inherently safer technology portion. I am not sure if it was added here as a mistake or a serious misunderstanding of the role of cyber security.

OMB Approves EPA TSCA NPRM

Yesterday the OMB’s Office of Information and Regulatory Affairs (OIRA) announced that it had approved a notice of proposed rulemaking (NPRM) from the EPA; Procedures for Evaluating Existing Chemical Risks Under the Toxic Substances Control Act. This rulemaking is implementing congressional requirements under the Frank R. Lautenberg Chemical Safety for the 21st Century Act (PL 114-182).

While many of the details associated with this NPRM may end up being controversial, this rulemaking was mandated by a Republican controlled congress with much support from industry. This rulemaking is almost certainly to be expected to proceed under the Trump administration.


We can expect to see this NPRM published in the Federal Register next week.

Bills Introduced – 01-12-17

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

S 133 A bill to authorize appropriations for fiscal year 2017 for intelligence and intelligence-related activities of the United States Government, the Community Management Account, and the Central Intelligence Agency Retirement and Disability System, and for other purposes. Sen. Burr, Richard [R-NC]


S 133 is the Intel Authorization bill (one of the so called ‘must pass’ bills) that never got passed last session. The House passed three different versions of the bill, but the Senate never could get a bill to the floor. Maybe it will be different this session. As usual, I will be watching for cybersecurity measures in this bill.

Thursday, January 12, 2017

ICS-CERT Publishes Three Advisories

Today the DHS ICS-CERT published three control system security advisories for products from Carlo Gavazzi, VideoInsight, and Advantech. ICS-CERT also published their latest ICS-CERT Monitor for November and December 2016. I am not going to review this publication any longer.

Carlo Gavazzi Advisory


This advisory describes three vulnerabilities in the Carlo Gavazzi VMU-C EM, VMU-C PV web servers. The vulnerabilities were reported by Karn Ganeshen. Carlo Gavazzi has produced a new firmware version that mitigates the vulnerability. ICS-CERT reports that Ganeshen has verified the efficacy of the fix.

The reported vulnerabilities are:

• Access control flaws - CVE-2017-5144;
• Cross-site request forgery - CVE-2017-5145; and
• Sensitive information stored in clear text - CVE-2017-5146

ICS-CERT is confused on the exploitability of these vulnerabilities. At the start of the advisory they report that the vulnerabilities are: “Remotely exploitable/low skill level to exploit.” But later in the body of the advisory it reports: “Not remotely exploitable. High skill level is needed to exploit.” I suspect that the first is correct and the second may be an artifact of the new format ICS-CERT is using to report advisories; more on that later.

VideoInsight Advisory


This advisory describes an SQL injection vulnerability in the VideoInsight Web Client. The vulnerability was reported by Juan Pablo Lopez Yacubian. VideoInsight has produced a new version to mitigate the vulnerability. ICS-CERT reports that Yacubian has verified the efficacy of the fix.
ICS-CERT reports that a relatively low skilled attacker could remotely exploit the vulnerability to execute arbitrary commands on the target system.

Advantech Advisory


This advisory describes two vulnerabilities in the Advantech WebAccess application. The vulnerabilities were reported by Tenable Network Security via the Zero Day Initiative. Advantech has produced a new version to mitigate the vulnerability. There is no indication that the researchers have been provided an opportunity to verify the efficacy of the fix.

The two reported vulnerabilities are:

• Authentication bypass - CVE-2017-5152; and
• SQL injection - CVE-2017-5154

ICS-CERT reports that a relatively low skilled attacker could remotely exploit the vulnerabilities to access pages unrestricted; the SQL injection condition may allow remote code execution.

New Advisory Format


ICS-CERT has started 2017 with a new format for their advisories. Any change is going to have plusses and minuses and it is easy to pick out the problems with the new format. Fortunately, there are more good things in this change, so I would like to highlight those.

First, ICS-CERT has obviously taken a hard look at what they think is the important information in the advisory and has moved that information to the top of the advisory. The first five items on the advisory are short listings of:

• CVSS v3 Score;
• Exploitability;
• Vendor;
• Affected equipment; and
• Vulnerability listing

These are certainly very important pieces of information. Their placement at the top of the format makes it easier to do a quick review of the advisory.

This is followed by essentially the same affected versions, impact, and mitigation measures. There are no significant changes to these sections. At the end of the advisory we now some major revisions to the vulnerability overview. Those changes include actual links to the CVE instead of a footnote to the URL; and more detailed background information on the types of vulnerabilities. That takes the form of links to the Common Weakness Enumeration (CWE) dictionary documenting the vulnerability.

The last section before the contact information of the advisory is the researcher section; listing the researcher's name and affiliation. It will be interesting to see how ICS-CERT handles self-identified vulnerabilities in this section.

The major downside of the new format is that the title of the advisory is taken from the first item on the advisory, the CVSS score. This will provide all sorts of misunderstandings and difficulties in finding specific advisories as the year goes on. This could be easily remedied by changing the order of the initial listing to show the vendor name first.

The second problem that I see is that ICS-CERT has taken out any information about what industries are affected by the advisory or the regions of the world in which the affected equipment is deployed. With the major players like Siemens and even mid-level players like Advantech this is not a real problem, but two of today’s advisories are for vulnerabilities in equipment from less well known vendors.


The last problem is more a matter of appearances than an actual problem; the moving of the researcher’s name to the end of the advisory. This certainly does nothing to tell the public (or the researcher) of the importance on the security researcher in the vulnerability reporting process. In my opinion the researchers name and affiliation should be included in the summary information at the top of the advisory.
 
/* Use this with templates/template-twocol.html */