Friday, December 15, 2017

Bills Introduced – 12-14-17

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

HR 4650 To amend the Homeland Security Act of 2002 to develop and make available guidance relating to domestic preparedness for and collective response to terrorism regarding active shooter and mass casualty incident response assistance, and for other purposes. Rep. Aguilar, Pete [D-CA-31]


I will only be following this bill if it includes language requiring the guidance to include specific information for facilities that store, produce or ship hazardous chemicals relating to the special chemical hazards associated with the use of firearms at such facilities.

ISCD Publishes CFATS Quarterly – 12-15-17

Today the DHS Infrastructure Security Compliance Division (ISCD) published the latest issue of the Chemical Facility Anti-Terrorism Standards (CFATS) Quarterly on the CFATS Knowledge Center. This two page newsletter provides an update on what has been going on in the CFATS program over the last quarter.

Actually, as befits a year-end issue, a goodly portion of the Quarterly provides a brief review of what has been going on in the Program over the last year. Most of the stuff included has been talked about here (and in other ISCD forums) in more detail, but there were two paragraphs that deserve special mention; a short recognition of the lessons learned during the 2017 Hurricane Season and a terse forward look at the upcoming (?) reauthorization of the CFATS program.

Other items included in this issue include:

• A very brief CFATS numbers update;
• An inspection best practices article;
• A brief (and far from comprehensive) list of CFATS program resources;
• A brief blurb on the NAS Improvised Explosives Study; and
• A list of recently published CFATS fact sheets and notices


So far, ISCD seems to be doing a good job avoiding turning this publication into a three-colored, glossy corporate report. I hope they can keep it up.

Thursday, December 14, 2017

Another ICS Attack in the Wild

It has not made the mainstream news yet, but today FireEye and Dragos are both reporting an attack on an industrial control system in an unnamed facility in Saudi Arabia. While the details being released are sketchy (paying customers are presumably getting more details), the important take-away from these two reports is that both organizations confirm that a successful attack (plant shutdown) was made on the safety-instrumented-system (SIS) at the facility.

For those readers with a good technical background, read the two reports noted above; these two organizations have a much better grasp of the technical details than I. For those with a less technical background read-on (and note: the mistakes of interpretation are mine).

Safety Instrumented Systems


For most automated manufacturing systems, if something really goes wrong with the system, then some product is messed up, maybe some workers get injured, or maybe someone gets killed; but the results are local. For some manufacturing systems, however, the consequences can be much larger and harder to control. Some chemical plants and nuclear power generation facilities come readily to mind.
For these types of automated facilities there is another (additional) type of control system that stands between normal operations and catastrophe, the Safety Instrumented System. These generally separate control systems rely on the fact that at some intermediate point between normal operations and catastrophe there is a point that, if the proper steps are taken in a timely manner, the process can be safety shut-down before catastrophe becomes inevitable and everyone has to run for the hills.

We used to rely on human operators to perform these emergency shutdowns. But, as processes became more complex and the paths to catastrophe became more numerous, it quickly became apparent that only automated control systems could be relied upon to recognize the burgeoning problem and take the appropriate timely actions necessary, each and every time. And safety instrumented systems were born.

At its most basic, a SIS consists of a computer, a limited number of sensor, and a limited number of process actuators (valves and such). The computer is programed to watch the sensor(s); if they reach certain value(s) then the actuator(s) are operated, and the process is safely terminated. The product is almost certainly bad, local equipment may be damaged, some cleanup and downtime will be required, but catastrophe will have been averted.

If the SIS fails, there is one final layer of protection that will help mitigate the resulting catastrophe. These are things like pressure relief valves, rupture disks, sprinkler systems, and spill control systems. Unfortunately, if these were truly effective responses to the catastrophic failure, then a SIS would not probably be employed. The SIS is a pain to design (each is a custom design), expensive to install and a maintenance problem. They are typically not employed if the worst-case scenario for a facility will be contained within the facility.

SIS Security


While industrial control system security has been problematic at best, SIS security is a slightly different story. Not because anyone was really concerned about hackers, but because no one wanted human error to get in the way of proper system operation. So, SIS were generally the last systems to be connected to any outside networks and most include the need for the operation of an actual, true-to-life physical key, to program the computer.

The SIS is placed in the program mode where it is programed, tested, and then placed in the stop mode with the key removed from the system. Before the hazardous process is started, the key in re-inserted, and the SIS is placed in the run mode and the key is again removed. The process is reversed when the hazardous process is over. This should be just about as good as it gets.

Unfortunately, someone again has proved that what man can secure, some other man can hack. Again, for details, read the two reports.

Take Away


DO NOT PANIC This is not the end of industrial control system safety. Who ever attacked this facility went to an awful lot of work. First to reverse engineer the SIS system involved, second to understand the process at the facility where this attack was initiated, and third to compromise the security at the facility to get the hack initiated. A lot of time, engineering and money (sounds like a nation-state to me) went into this attack and it failed. It screwed up and apparently unintentionally shutdown the process (safely) which ended up alerting the system owners to the apparent hack.


If you want to know how to protect your SIS, read either (better, both) reports, but there is really nothing new there. Isolate your SIS from the internet and other networks, secure access (physical and virtual) to the SIS equipment and follow SIS operations guidelines. And from me, train your operations personnel so that they fully understand the processes they control and listen to them when they report anomalous system behaviors.

Wednesday, December 13, 2017

Bills Introduced – 12-12-17

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

HR 4629 To direct the Department of Transportation to issue regulations to require enhanced security measures for shipments of security sensitive material, and for other purposes. Rep. Norton, Eleanor Holmes [D-DC-At Large]

S 2220 A bill to provide for the development, construction and operation of a backup to the Global Positioning System, and for other purposes. Sen. Cruz, Ted [R-TX]

Something odd going on with HR 4629, the current security regulations for ‘security sensitive materials’ are not DOT regulations, but rather TSA (49 CFR 1580.101). Having said that, Norton is well known for her concern about the security of rail transportation of hazardous materials because there is a major rail transshipment point in Washington, DC (very close to the Capital) that handles large volumes of hazardous materials.


S 2220 will be followed here if it specifically includes a backup to the GPS timing system used by many industrial control systems. BTW: The Cosponsor for this bill is Sen. Markey (D,MA); talk about a political odd couple; firebrands from both the Right and Left.

Tuesday, December 12, 2017

ICS-CERT Updates Smiths Medical Advisory

Today the DHS ICS-CERT updated a medical control system security advisory for products from Smiths Medical. The advisory was originally published on September 7th, 2017. The update provides information on a patch that is available to mitigate the vulnerabilities as well as additional point of contact information for the company.

House Passes HR 3359 CISA Authorization

Yesterday the House passed HR 3359, the Cybersecurity and Infrastructure Security Agency Act of 2017 by a voice vote. The bill is Rep. McCaul’s (R,TX) long awaited reorganization of the DHS National Protection and Programs Division (NPPD).

Commentary


This bill is really nothing more than an exercise in bureaucratic shuffling. The existing NPPD is now called CISA; an Under Secretary will be known as the Director and a number of sections in 6 USC are being renumbered. The most important part of the bill is found in section 4 of the bill; nothing in the bill confers new authorities or reduces existing authorities existing the day before this bill is enacted.

There is one subtle change made by this bill in the new definitions section 2201. There are two cybersecurity related definitions in this new section; both taken from existing statutes. The bill uses the IT-limited definition of ‘cybersecurity risk’ from the current 6 USC 148 (moving to §2209) and the ICS-inclusive definition of ‘cybersecurity threat’ from 6 USC 1501. The definitional disconnect between these two very similar (and closely intertwined) terms could cause some interesting confusion about the authority of this ‘new’ agency to address control system security issues.

Moving Forward



The bill moves forward to the Senate where it will pass with similar bipartisan support if it reaches the floor for consideration. The big question is whether or not the bill will have the leadership support necessary to bring it to the floor for consideration. At this point, I am not sure that it does.

Monday, December 11, 2017

ISCD Changes Monthly Status Reporting

Today (okay, yesterday now on the East Coast) the DHS Infrastructure Security Compliance Division (ISCD) changed the way they are reporting progress on the implementation of the Chemical Facility Anti-Terrorism Standards (CFATS) program. They scrapped the monthly .PDF CFATS Fact Sheet format and added a new web-page to the CFATS web-site that provides a slightly different look at the progress being made.

Inspection Reporting


Long-time readers of this blog will no doubt recall the monthly parsing of data that I have been doing since the CSAT 2.0 reporting began back in May of this year. With ISCD reporting inspection data both on inspections ‘since the inception of the program’ and on ‘at currently covered facilities’ I had fun trying to figure out how many inspections had actually been completed that month and how many facilities were undergoing multiple inspections due to failure to achieve compliance.

The new web page changes that reporting. It still carries on with reporting the number ‘since the inception of the program’, but it now simply reports a single number for the number of inspections (Authorization, Compliance, and Compliance Assistance) conducted during the month. The table from the November 2017 reporting is shown below.

Activity
Since Inception     
November 2017
Authorization Inspections (AIs) 
     3,102
     70
Compliance Inspections (CIs)
     3,065
     87
Compliance Assistance
Visits (CAVs)
     3,723
     92

If we try to compare the ‘since inception’ numbers from this newest report and those from the old style November report (ISCD used to name their reports for date of reporting not the month the inspections were done). It would appear that there were 87 AIs completed and 111 CIs done in November. This discrepancy may be due to reporting format changes or a couple of other possible program issues. It is hard to tell from a single data point.

Facility Status Reporting


A new set of data being reported on the web page is CFATS Facility Statuses. Kind of an ugly title but, it is an interesting new set of information. Previously, ISCD only published monthly numbers on the number of facilities covered under the CFATS program and the number of currently approved site security plans (SSPs). The new web page provides a table showing a snapshot of the current status of facilities in the program.

Status
Currently Covered
Tiered
     843
Authorized
     429
Approved
     2,276
Total
     3,548

This new table provides us with data on the number of facilities that have received Tiering Letters (Tiered) but have not yet had their site security plan authorized. It also tells us how many are pending approval of their SSPs, how many have approved SSPs and the sum of the above tells us how many facilities are currently covered by the CFATS program.

Interestingly, since the resumption of program status in May, there has been a net gain of 978 facilities in the program. Most of these, presumably, were added due to the revised risk assessment process and CSAT 2.0 resubmission of Top Screens, though ISCD has continued to vigorously reach out to the chemical community to identify facilities that should have been submitting Top Screens, but, for one reason or another, have failed to do so. This is a fall smaller number than the 1272 facilities that have not yet had their SSPs approved. It is highly unlikely that a significant number of the new facilities have had their SSPs approved since May. Thus, it looks like we may have had about 300 facilities fall-out of the CFATS program since reporting resumed in May. That would not be out of line with what ISCD reported as being the drop-out rate for the new risk assessment process.

Missing Data


I continue to have problems with the ISCD compliance inspection data. The data being reported today for ‘compliance inspections since inception’ and the numbers reported in the last monthly report show that there should have been 111 compliance inspections completed in November, not the 87 being reported here. Again, there could be a number of different explanations, but I continue to suspect that the 87 inspections being reported in November only reflects one-inspection (the latest) per facility.

In the past couple of months, I have been focusing on the potential for these re-inspections being required because of facilities failing their compliance inspection and thus requiring a re-inspection. ISCD broadly points out another category of facilities being re-inspected:

“It is also important to note that this regulatory program is cyclical in nature, meaning activities such as Compliance Inspections are recurring. ISCD began conducting recurring Compliance Inspections in March 2017.”

It would be helpful if ISCD were a little more specific what the 87 number being reported actually means. Was that the total number of compliance inspections done in November or the increase in the number of facilities with a current compliance inspection. And just to make things perfectly clear, it would be helpful to have a number of compliance inspections passed/failed as well.


Actually though, I really am impressed with the effort that ISCD takes to keep the chemical security community up-to-date on the progress that is being made in the program. And the progress really is an important reflection on the daily efforts by the 150 or so Chemical Security Inspectors working with the employees and contractors at the 3,548 CFATS sites on an on-going basis to reduce the risk of a terrorist attack on these facilities. Everyone involved is to be commended on the time and effort being put into this program.

Saturday, December 9, 2017

NIST Publishes 2nd Draft for CSF 1.1 for Comment

This week the National Institute of Standards and Technology (NIST) published their second draft of version 1.1 of the Cybersecurity Framework (CSF) and a fact sheet that broadly outlines the changes made to the CSF.

The fact sheet makes the point that the revised CSF is applicable to information technology, operational technology, cyber-physical systems, and internet of things. Since the original CSF core already provided references to ISA 62443-2-1:2009 and ISA 62443-3-3:2013 that are found in this revision it does not seem that the new version changes much with respect to OT/IOT security.

OT/IOT Changes


In fact, if you look at the list of changes made to the CSF (starting at page 50) there are only four references to OT/IOT changes:

• Section 1.0 (pg 7): ‘Framework Introduction’ was updated to reflect security implications of a broadening use of technology (e.g. ICS/CPS/IoT) and to more clearly define Framework uses;
• Appendix C (pg 53): ‘Acronyms’ - was modified to include CPS - Cyber-Physical Systems;
• Appendix C (pg 53): ‘Acronyms’ – was modified to include IoT - Internet of things;
• Appendix C (pg 53): ‘Acronyms’ - was modified to include OT - Operational Technology

The introduction section discussion referenced above addresses OT/IOT security issues this way:

“The critical infrastructure community includes public and private owners and operators, and other entities with a role in securing the Nation’s infrastructure. Members of each critical infrastructure sector perform functions that are supported by the broad category of technology, including information technology (IT), industrial control systems (ICS), cyber-physical systems (CPS), and connected devices more generally, including the Internet of Things (IoT). This reliance on technology, communication, and interconnectivity has changed and expanded the potential vulnerabilities and increased potential risk to operations. For example, as technology and the data it produces and processes is increasingly used to deliver critical services and support business decisions, the potential impacts of a cybersecurity incident on an organization, the health and safety of individuals, the environment, communities, and the broader economy and society should be considered.”

Unfortunately, the terms ‘CPS’ and IoT are not used in the revised CSF Core. In short, the CSF does not specifically address the specific cyber-physical consequences of security breaches in OT/IoT systems.

Suggested OT/IOT Changes


Unfortunately, this revision to the CSF still does not adequately address the potential cyber-physical consequences of a cybersecurity incident. At a minimum, the core should have an additional subcategory under Risk Assessment:

ID.RA-X: Worst-case cyber-physical events need to be identified that effect either on-site operations and/or the off-site community.

This would then lead to requiring an additional Risk Management Strategy subcategory:

ID.RM-X: Appropriate emergency response agencies are notified of potential off-site community effects of cyberphysical incidents.

The on-site effects on operations would be addressed by the current IR.RM-4. To clarify that addition, I would reword the subcategory title to read: “Potential business impacts (including on-site and off-site effects of cyber-physical incidents) and likelihoods are identified.”

Broadening Information Security Focus


While the verbiage in the introduction to the CSF would indicate that NIST intends to broaden the focus of CSF to include OT/IoT security, there are still a number of references to ‘information security’ in the CSF core that really should be revised to indicate that broadened focus. For example ID.GV-1 still refers to ‘information security’ when the intent should reflect a broader ‘cybersecurity’; the words should be changed to reflect this. Similar wording changes need to be made to ID.GV-2, ID.SC-3, PR.AT, and PR.AT-5,

Public Input



NIST is asking for public input on this second draft for CSF 1.1. Comments need to be submitted by January 19th, 2018. Comments can be submitted by email to cyberframework@nist.gov.

NOTE: A copy of this blog post was submitted as a comment to NIST on 12-9-17 14:50 EST.

Public ICS Vulnerability Disclosures – Week of 12-03-17

Yesterday Joel Langill pointed out a vulnerability report from ABB that was published over two weeks ago. The report addresses an authentication vulnerability in the ABB Ellipse 8 products. The ABB report notes that the vulnerability exists in the implementation of the Lightweight Directory Access Protocol (LDAP) that would allow an attacker with local network access to sniff the unsecured authentication credentials sent between the Ellipse device and the LDAP/AD server.

As with any vulnerability that is found to exist in an implementation of an industry-wide standard, the question arises; what other vendors are using this vulnerable implementation?


NOTE: The ABB report states that the vulnerability was reported in a “responsible disclosure”, but does not name the researcher making the disclosure.

Friday, December 8, 2017

Senate Sends CR to President

Yesterday, shortly after action was complete in the House, the Senate passed HJ Res 123, Further Continuing Appropriations Act, 2018, by a largely bipartisan vote of 82 to 14. The 14 Nays included 6 Republicans and 7 Democrats (and 1 Independent). The CR would extend the current spending (at FY 2017 rates) until December 22nd, 2017.

No procedural votes preceded the consideration of the bill indicating that a strong deal had been achieved to ensure passage of the bill. The 30 minutes of debate allocated for the bill only drew two speakers; one of which spent the time praising his home State of Alaska; 8 minutes of the ‘debate’ went unused.


The Congress now has an additional two weeks to try to come up with a final spending deal for FY 2018. There has been some discussion in the press of potentially seeing an additional CR carrying the current spending over until January.

Thursday, December 7, 2017

House Approves Short Term CR

This afternoon the House approved HJ Res 123, the Further Continuing Appropriations Act, 2018 by a very slightly bipartisan (18 Republicans voted Nay and 14 Democrats voted Aye) vote of 235 to 193. This short-term continuing resolution will extend the current spending bill until December 22nd.

The 14 Democrats voting for the measure may be an indication that enough Democrats will vote at least procedurally for the bill tomorrow in the Senate to allow it to come to a final vote. Congress has until Friday night at midnight to get a CR to the President to continue government operations.


A lot of details and deals have to be worked out before the final FY 2018 spending is approved.

ICS-CERT Publishes 3 Advisories and 1 Alert

Today the DHS ICS-CERT published three control system security advisories for products from Phoenix Contact, Rockwell and Xiongmai Technology. The also published a control system security alert for a WAGO programable logic controller (PLC).

Phoenix Contact Advisory


This advisory describes a cross-site scripting vulnerability in the Phoenix Contact FL COMSERVER, FL COM SERVER, and PSI-MODEM/ETH industrial networking equipment. The vulnerability was reported by Maxim Rupp. Phoenix Contact has released new firmware versions to mitigate the vulnerabilities. There is no indication that Rupp 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 change configuration variables on the device. The VDE-CERT advisory notes that network access is required to exploit the vulnerability.

Rockwell Advisory


This advisory describes an improper input validation vulnerability in the Rockwell FactoryTalk Alarms and Events component of the Factory Talk Services Platform. The vulnerability was reported by an unnamed major oil and gas company. ICS-CERT reports that newer versions or existing patches mitigate the vulnerability.

ICS-CERT reports that a relatively low-skilled attacker could remotely exploit the vulnerability to cause a denial of service condition in the in the history archiver service running on FactoryTalk Alarms and Events.

QUESTIONS: Does it seem odd to anyone else that a ‘major oil and gas company’ would be using an out-of-date version of this product? Or is this a problem that is endemic to the ICS user community? Did Rockwell notify their customers (or even just their major customers) when they discovered and fixed this vulnerability? (It does not sound like it.)

Xiongmai Technology Advisory


This advisory describes a stack-based buffer overflow vulnerability in the Xiongmai IP Cameras and DVRs. The vulnerability was reported by Clinton Mielke. ICS-CERT reports that has not responded to requests to coordinate with NCCIC/ICS-CERT.

ICS-CERT reports that a relatively low-skilled attacker could remotely exploit the vulnerability to cause the device to reboot and return to a more vulnerable state in which Telnet is accessible.

WAGO Alert


This alert describes an unconfirmed improper authentication vulnerability in the WAGO PFC200 PLC. This is the vulnerability that I discussed almost a week ago. SEC Consult reported that they had coordinated with CODESYS and that the vendor was planning on issuing a patch next month.

I am not sure why ICS-CERT issued an alert for the WAGO vulnerability and an advisory for the Xiongmai vulnerability. It would seem to me that those reporting formats probably should have been reversed.


NOTE: There is still no word on the Hikvision vulnerability that I reported in the same blog post as this WAGO vulnerability.

Bills Introduced – 12-06-17

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

HR 4569 To require counterterrorism information sharing coordination, and for other purposes. Rep. Gallagher, Mike [R-WI-8]


I will be watching this bill to see if it addresses the problems associated with trying to share classified information with the private sector.

Wednesday, December 6, 2017

Rule Approved for Short Term CR

This afternoon the House Rules Committee met, in part, to approve the rule for the consideration of HJ Res 123, the Further Continuing Appropriations Act, 2018, a short term continuing resolution extending the current CR (PL 115-56) until December 22nd, 2017. The Committee approved a closed rule with one hour of debate and no amendments.


I had noted in an earlier post that the extension date might be extended to December 30th, but that was not done. This means that there will only be two weeks before Congress will have to take action again on the FY 2018 spending. At this point, it looks like that next bill will be another CR until sometime early next year. If that happens, Congress will likely take a two-week recess for Christmas.

Committee Hearings – Week of 12-03-17

With the end of year holidays fast approaching the Congressional hearing calendar is getting light. There are two hearings this week that may be of specific interest to readers of this blog; the Continuing Resolution and a cybersecurity hearing.

CR


The House Rules Committee Hearing that I mentioned yesterday has been postponed until today with the House leadership trying to work out the political bugs in its consideration. This would lead to a vote in the House tomorrow and the Senate on Friday. Any further slippage could cause some problems since the current funding runs out at midnight on Friday.

This CR (HJ Res 123) will only kick the can down the road a piece. The leadership still needs to come up with a deal to fund the government for the rest of the year. Speaker Ryan’s problem is that he is trying to find a Republican-only-bill that can make it past the Democrat’s filibuster in the Senate.

Grid Cybersecurity


On Friday the Oversight and Investigations Subcommittee of the House Energy and Commerce Committee will be holding a hearing on “Examining the Role of the Department of Energy in Energy Sector Cybersecurity”. Only one witness is scheduled; Bruce J. Walker, Assistant Secretary, Office of Electricity Delivery and Energy Reliability, Department of Energy. This is going to be more of a policy type discussion rather than addressing the nuts and bolts of cybersecurity issues.

Tuesday, December 5, 2017

ICS-CERT Publishes 1 Advisory and 1 Update

Today the DHS ICS-CERT published a control system security advisory for a product from Siemens. It also updated a previously issued advisory for products from Siemens.

Siemens Advisory


This advisory describes an improper input validation vulnerability in the Siemens Industrial Products. The vulnerability was reported by George Lashenko of CyberX. Siemens has produced a firmware update that mitigates the vulnerability. There is no indication that Lashenko 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 conduct a denial-of-service (DoS) attack. The Siemens security advisory notes that the attacker requires network access to the affected devices.

Siemens Update


This update provides additional information for an advisory that was originally published on November 14th, 2017. The new information is updated affected version and mitigation information for:

• SCALANCE W-700 (IEEE 802.11n): All versions prior to V6.2.1

The associated Siemens updated security advisory also provides additional mitigating factors for:

• SCALANCE W-700 devices operated in Access Point;
• RUGGEDCOM RX1400 and RS9xxW;

KRACK Rant


The first vendor has now published a fix for the Key Reinstallation Attack – (KRACK) set of vulnerabilities that make control systems utilizing wireless systems using WPA2 security vulnerable to man-in-the-middle attacks; this is good news. Unfortunately, ICS-CERT still has not issued an alert outlining the extent of the vulnerability to the control system community. Nor have they even provided links to either the KRACK web site or the original paper describing the vulnerabilities. So much for ICS-CERT being interested in keeping the ICS community up to date on wide ranging vulnerabilities.

Bills Introduced – 12-04-17

Yesterday with both the House and Senate back in Washington after a real 2-day weekend break, there were 28 bills introduced. Of those, one may be of specific interest to readers of this blog:

HJ Res 123 Making further continuing appropriations for fiscal year 2018, and for other purposes. Rep. Frelinghuysen, Rodney P. [R-NJ-11]

The official version of this continuing resolution (CR) is currently available. It would extend the current continuing resolution (PL 115-56) from December 8th, 2017 to December 22nd, 2017. It also addresses the lack of funding for the Children’s Health Insurance Program (CHIP) for the first quarter of FY 2018.

The House Rules Committee will meet this afternoon to formulate the rule to consider this bill. It will almost certainly be a closed rule with limited debate and no floor amendments. The bill will be considered on Wednesday to allow the Senate time to take up the bill before the Friday current Friday deadline.


There is a news report that the expiration date on this CR may be changed to December 30th. That change would be addressed in today’s Rules Committee Hearing.

Sunday, December 3, 2017

OMB Approves PHMSA EPC Decision

On Friday the OMB’s Office of Information and Regulatory Affairs (OIRA) announced that it had approved the DOT’s Pipeline and Hazardous Material Safety Administration (PHMSA) notice on the status of electronically controlled pneumatic (ECP) breaks on highly-hazardous flammable trains (EFFT).

Yes, this is the same notice that was submitted to OIRA on Thursday. Such one-day turnaround of an OIRA approval is highly unusual and typically reflects an impending legal deadline. As I noted last Friday this PHMSA action has a congressionally mandated deadline of December 4th to complete this action. PHMSA will miss that deadline since Monday’s Federal Register has already been published and this notice was not included.


The OIRA notice classifies this as a ‘Pre-Rule’ action. I would have expected it to be classified a ‘Final Rule’ or at least a ‘Notice of Proposed Rule’ designation if this were to be an action to vacate the ECP requirements in 49 CFR 174.310(a)(3)(ii). I suspect that this will be the regulatory impact analysis notice required in §7311(c)(1)(B) of the 2015 FAST Act (PL 114-94). This notice would come with a 30-day public notice requirement before DOT could proceed with any action.

Saturday, December 2, 2017

NIST Mapping Framework Core to NIST SP 800-171

This week the National Institute of Standards and Technology published a new supporting document for the Cybersecurity Framework on the CSF web page. This is a Excel spread sheet mapping CSF Subcategories to NIST SP 800-171, Revision 1, Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations.

A disclaimer in spread sheet notes that:

“NIST SP 800-171 focuses on protecting the confidentiality of Controlled Unclassified Information (CUI) in nonfederal systems and organizations, and recommends specific security requirements to achieve that objective. The requirements recommended for use in SP 800-171 are derived from FIPS Publication 200 and the moderate security control baseline in NIST Special Publication 800-53 and are based on the CUI regulation (32 CFR Part 2002, Controlled Unclassified Information). The tailoring criteria applied to the FIPS Publication 200 security requirements and the NIST Special Publication 800-53 security controls is not an endorsement for the elimination of those requirements and controls—rather, the tailoring criteria focuses on the protection of CUI from unauthorized disclosure in nonfederal systems and organizations.”

This is another effort by NIST to expand the usefulness of the CSF.


NOTE: The disclaimer cell in the spread sheet is overly large, making it difficult to see the mapping cells. To be able to see a reasonable number of mapping lines, reduce the height of line 2 of the spread sheet or even hide it.

Public ICS Disclosure – Week of 11-25-17

This week there were two industrial control system vulnerability disclosures on the Full Disclosure web site. They addressed products from Hikvison and CODESYS.

Hikvision Vulnerability


This report by IOT Sec describes a Wi-Fi access vulnerability in Hikvision Wi-Fi IP Cameras installed in a wired configuration. A default wireless SSID exists in the products with a setting of no WiFi encryption or authentication.

This disclosure was coordinated with Hikvision. No fix has been reported but a work around was described.

The disclosure timeline reported by IOT Sec includes an unsuccessful attempt to coordinate the vulnerability with ICS-CERT {as recommended by (US-?)CERT}. While IP cameras are only industrial control systems in the broadest sense, ICS-CERT has posted advisories for these products in the recent past (including some of the specific devices included in this report). I am very surprised that ICS-CERT did not respond to IOT Sec; I would hope that this was due to miscommunications issues, not bureaucratic inaction.

CODESYS Vulnerability



This report by SEC Consult describes an improper authentication vulnerability in the CODESYS WAGO PFC 200 Series. This appears to be an extension of a previously reported vulnerability. ICS-CERT reported on that advisory that it would affect products from as many as 260 other vendors that used the affected code. This disclosure was a coordinated with CODESYS and SEC Consult reports that CODESYS will release a patch next month.

Friday, December 1, 2017

PHMSA Sends ECP Breaking Decision to OMB

Yesterday the OMB’s Office of Information and Regulatory Affairs (OIRA) announced that it had received from DOT’s Pipeline and Hazardous Material Safety Administration (PHMSA) their Notice of the Department of Transportation's Decision on ECP Braking for review.

While this was not published in the 2017 Unified Agenda update, it appears that this has been prepared in response to a congressional mandate in 2015 FAST Act (PL 114-94). In §7311 Congress addressed the PHMSA rule {174.310(a)(3)(ii)} on the use of electronically controlled pneumatic (ECP) breaks on highly-hazardous flammable trains (HHFT); requiring additional testing of the efficacy of ECP breaking systems in preventing damage to railcars used to transport crude oil.

While the National Academy of Sciences final letter report was not able to make a conclusive statement “concerning the emergency performance of ECP breaks relative to other breaking systems” (pg ii), congress mandated {§7311(c)(2)} that by December 4th of this year DOT would either publish a notice of why the ECP mandate was justified or, if not justified, repeal the requirement.


It will be interesting to see how the anti-regulatory Trump administration comes down on this decision.

ICS-CERT Publishes 2 Advisories and 3 Updates

Yesterday the DHS ICS-CERT published two control system security updates for products from Geovap and Siemens. They also updated three previously published control system security advisories, all for products from Siemens.

Geovap Advisory


This advisory describes a cross-site scripting vulnerability in the Geovap Reliance SCADA software management platform. The vulnerability was reported by Can Demirel. Geovap has released a new version that mitigates the vulnerability. There is no indication that Demirel has been provided an opportunity to verify the efficacy of the fix.

ICS-CERT reports that a relatively low-skilled attacker could remotely exploit this vulnerability to inject arbitrary JavaScript in a specially crafted URL request that may allow for read/write access.

NOTE: The Geovap update notes for this new version would seem to indicate that they also fixed one or more vulnerabilities in the Reliance Smart Client.

Siemens Advisory


This advisory describes multiple vulnerabilities in the Siemens SWT 3000 Teleprotection system. The vulnerabilities are self-reported. Siemens has produced updated firmware that mitigates the vulnerability.

The reported vulnerabilities are:

• Improper authentication (2) - CVE-2016-4784, CVE-2016-4785;
• Authentication bypass using an alternate path or channel (2) - CVE-2016-4785, CVE-2016-7114; and
• Improper input validation - CVE-2016-7113

ICS-CERT reports that a relatively low-skilled attacker could remotely exploit these vulnerabilities to perform a denial-of-service attack. The Siemens security advisory notes that network access to the devices is required for exploitation.

OPC/UA Update


This update provides new information on an advisory that was originally published on 8-31-17 and updated on October 3rd, 2017. The update provides new version information and mitigation measures for:

• SIMATIC IT Production Suite: Versions between V6.5 and V7.1

SIPROTEC Update


This update provides new information on an advisory that was originally published on July 6th, 2017, and updated on July 18th, on July 28th, and then again on October 10th. The update provides new version information and mitigation measures for:

• SIPROTEC 7SD686: All versions prior V4.05

The Siemens updated security advisory explains why there are two separate affected versions for SIPROTEC 7SD686. Versions <4 .05="" affected="" also="" and="" are="" by="" o:p="" versions="" vulnerability="">

SIMATIC Update


This update provides new information on an advisory that was originally published on February 14th, 2017 and updated on June 15th,  and again on July 6th. The update provides new version information and mitigation measures for:


• SIMATIC IT: All versions prior to V7.1

Thursday, November 30, 2017

ICS-CERT Publishes Latest Monitor – Sep-Oct 2017

Yesterday the DHS ICS-CERT published the latest version of the ICS-CERT Monitor. Long time readers of this blog will no doubt understand that I have become less than enamored with this periodical in recent years. It has become more of a corporate selfie than a real communications tool, but occasionally there is an information gem that is worthy of note.

Selfie Components


The Monitor starts with a Trumpian, “look how great I am”, article on a recent training program conducted by ICS-CERT in Japan. It then goes on to announce the publication of a 2-page, color glossy ‘fact sheet’ looking back at last year’s “Recommended Practice: Improving Industrial Control System Cybersecurity with Defense-in-Depth Strategies” update.

There is one page dedicated to ICSJWG news, including an announcement of the Spring meeting dates; April 10–12 in Albuquerque, NM. Unfortunately the ICSJWG web site still does not include an agenda for the fall 2017 meeting, nor is there any mention of the rumored announcement that was made about the reorganization/abolishment/fusion of ICS-CERT.

Finally, we have the standard elements that we have come to know and ignore:

• ICS-CERT Assessment Activity;
• Recent Product Releases;
• Coordinated Vulnerability Disclosure; and
• Upcoming Events

The Gem


Okay, this may be more of a sparkler than a true precious stone, but there is an interesting and worthwhile full-page article on updating of antivirus software in ICS systems. The core assumption in this article is found in the second paragraph:

“The recommended secure network architecture for ICS (Figure 1) places the antivirus, Windows Server Update Services (WSUS), and patch server(s) in the control center LAN DMZ. In this architecture, each level should only send or receive traffic to any directly adjacent level, which precludes the antivirus/WSUS/patch server from communicating directly with either the vendor antivirus servers or the organizational antivirus servers.”

This, of course, leads to the need for downloading the daily AV signature update onto removable media, checking that media for malware, checking the hash, running the update on test environment, and finally, updating the AV on the appropriate ICS systems. All very neat and tidy, and security compliant; I wonder how many folks actually do this. Or is this really the reason that so many folks are starting to talk about how outdated/useless AV is?


Of course, the same process would be required for updates for all Windows OS, control systems, and device software. Again, does this explain the apparently widespread practice of overlooking/ignoring system updates?

Wednesday, November 29, 2017

Bills Introduced – 11-28-17

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

HR 4474 To enhance the security of surface transportation assets, and for other purposes. Rep. Watson Coleman, Bonnie [D-NJ-12]


Looking at the bill fact sheet prepared by Watson-Coleman’s office this looks like it will be a very comprehensive surface transportation security bill. While it does not appear to specifically address chemical transportation security issues, it would require DOT to complete their rulemaking on transportation security training and may address transportation cybersecurity issues.

ICS-CERT Publishes Two Advisories and Two Siemens Updates

Yesterday the DHS ICS-CERT published a medical device security advisory for products from Ethicon and a control system security advisory for products from Siemens. It also published two updates of control systems advisories for products from Siemens. The Siemens advisory and the two updates were announced by Siemens last week.

Ethicon Advisory


This advisory describes an improper authentication vulnerability in the Ethicon Endo-Surgery Generator Gen11. This vulnerability is apparently self-reported. A field cybersecurity update is reportedly being made available today. There is no FDA advisory for this vulnerability.

ICS-CERT reports that a highly skilled attacker with local access could exploit this vulnerability to allow for unauthorized devices to be connected to the generator, which could result in a loss of integrity or availability.

Siemens Advisory


This advisory describes multiple vulnerabilities in the Siemens SCALANCE, network interfaces. These vulnerabilities are being self-reported. Siemens is reporting work-around mitigation measures pending the development of updates for these products.

The reported vulnerabilities are:

•Uncontrolled resource consumption (3) - CVE-2017-13704, CVE-2017-14495, and CVE-2017-14496; and
• Improper restriction of operations within the bounds of a memory buffer - CVE-2017-14491

ICS-CERT reports that a relatively low skilled attacker with remote access could exploit these vulnerabilities to crash the DNS service or execute arbitrary code by crafting malicious DNS responses. The Siemens security advisory reports that the buffer vulnerability requires the attacker to be in a man-in-the-middle position to exploit the vulnerability.

S7-300 Update


This update provides new information on an advisory that was originally published on December 13th, 2016 and then updated on May 9th, 2017 and July 25th. This update provides new version information and an update link for the SIMATIC S7-400 V6PN.

PROFINET 2 Update


This update provides new information on an advisory that was originally published on May 9th, 2017 and updated on June 15, 2017,on July 25th, 2017, on August 17th, 2017, on October 10th and most recently on November 14th. This update provides new version information and update links for:

• SCALANCE X200: All versions prior to V5.2.2
• S7-400 PN/DP V6 Incl. F: All versions prior to V6.0.6

Missing Siemens Update



On the same day that Siemens announced their advisories for the updates listed above, they also announced an update for their advisory for the DROWN (Decrypting RSA with Obsolete and Weakened eNcryption; CVE-2016-0800) vulnerability in their industrial products. The ICS-CERT advisory for this vulnerability was last updated on July 15th of this year.

OOPS. I missed the ICS-CERT update for this advisory (0725 EST 11-29-17).

Sunday, November 26, 2017

NMSAC to Discuss CG Cybersecurity Guidance

On Friday the Coast Guard published a meeting notice in the Federal Register (82 FR 55847-55848) for a teleconference of the National Maritime Security Advisory Committee (NMSAC) on December 14th, 2017. The conference will discuss the Cybersecurity Working Group’s recent work on the draft of the Navigation and Vessel Inspection Circular (NVIC) 05-17 (Note: the new CG Homeport does now support standard links, yeah); Guidelines for Addressing Cyber Risks at Maritime Transportation Security Act Regulated Facilities, that was released earlier this year.


The teleconference is open to the public but registration is required. There will be a public comment period at the end of the NMSAC discussion.

Wednesday, November 22, 2017

ICS-CERT Publishes Another Vendor KRACK Advisory

Yesterday the DHS ICS-CERT published a control system security advisory for WLAN enabled products from Phoenix Contact. This is for the  Key Reinstallation Attack – (KRACK) set of vulnerabilities. ICS-CERT credits the original KRACK researcher, Mathy Vanhoef of imec-DistriNet, for reporting the vulnerability, but this instance was self-reported by Phoenix Contact.

This advisory only reports three of the ten reported KRACK CVE. It is not clear if the vendor has evaluated the other potential KRACK instances and found them missing (not implemented) on their devices, or just thought that these were the most serious implementation issues in their devices.

The Phoenix Contact advisory at CERT@VDE provides much more detailed information about the extent of the vulnerability. They report:

“PHOENIX CONTACT embedded devices running in AP mode are not affected by these vulnerabilities. If devices are used in client or repeater mode, an attacker could in theory decrypt any packet sent by the client. Devices of the FL WLAN 110x, 210x, and 510x product families are only affected to a very limited extent. With these devices, only data packets sent within three seconds after key renewal could possibly be decrypted by a successful attacker. In general, if TCP SYN packets are decrypted, this can be used to hijack TCP connections and inject malicious traffic into unencrypted protocols. However, to perform the attack, the attacker must be significantly closer to the WLAN client than the access point. In industrial or indoor applications, the attacker would have to be inside the plant. A successful external attack therefore seems to be very difficult. Furthermore, the WPA2 password cannot be compromised using a KRACK attack. It is not possible for the attacker to gain full access to the network. However, note that if WPA-TKIP is used instead of AES-CCMP, the impact of this vulnerability is much more severe, because an attacker can then not only decrypt packets, but also forge and inject packets directly into the WLAN.”


TIRADE ALERT – Another vendor provides information on KRACK and ICS-CERT has still failed to publish an alert about the vulnerability, or even just a link to the original paper. I have been complaining about this inaction on the part of ICS-CERT where ever I talk about ICS security issues. I had an interesting conversation with Anton Shipulin, of Kaspersky Labs, over on LinkedIn about the issue and he noted that this could be the result of the recent NCCIC reorganization that ‘moved’ ICS-CERT into NCCIC. I still have not seen anything from DHS about the move, but if the reorganization changed the information sharing responsibilities of ICS-CERT to the control system security community, then DHS needs to reverse that change as quickly as possible. Perhaps Congress needs to look into this.

Saturday, November 18, 2017

Public ICS Disclosure – Week of 11-12-17

Today this is not about a new disclosure but about some new information on an ICS-CERT advisory that was published this week. SEC Consult published additional information on the Siemens SICAM vulnerabilities on the FullDisclosure web site.

The ICS-CERT advisory reported that publicly available exploits were available, but did not provide a link. This report from SEC Consult provides proof of concept code for exploiting the first two vulnerabilities and a link to a very old (2003) link to an earlier report on the code injection vulnerability. That link leads to a report by Luigi Auriemma, a name that hasn’t been seen on this blog in quite some time.

The Luigi report is about the GoAhead web server that was apparently used by Siemens in the affected versions of the SICAM devices. This is not noted in either the ICS-CERT advisory or the Siemens security advisory. Luigi describes GoAhead this way:

“Goahead (sic) webserver is an embedded OpenSource server that can be build (sic) on a lot of systems (CE, Ecos, GNU/Linux, Lynx, MacOS, NW, QNX4, VXWORKS, Win32 and others).
“It is supported by a lot of companies that use it for their projects and it is also used like ‘base’ for other webservers, furthermore it has been developed for be very tiny and to run on embedded systems.”

Apparently, Siemens used an unpatched version of the webserver (Luigi reported that the vulnerability he reported was fixed in December 2003) in the affected versions of the SICAM devices. Since Siemens (and almost all other ICS vendors) did not start to take control system security seriously until after 2010 (STUXNET), it is not surprising that a newer version of the webserver was not incorporated in these devices; in fact, it is quite possible that they were not informed of the vulnerability.

This is an old, but continuing problem, with third party software used in many of the control system devices used still today. If the original vendor does not have an active method for sharing vulnerability information with all of its customers, the using vendor may not become aware of the vulnerability until some third-party researcher discovers the problem.


More disturbing in this case is the fact that neither ICS-CERT nor Siemens mentioned that the vulnerabilities (apparently all three) in the SICAM devices were based upon vulnerabilities in a GoAhead web server. If it were not for this separate SEC Consult disclosure, the community would not realize that that there was a third-party vulnerability involved that may still exist in other non-Siemens devices.

Friday, November 17, 2017

S 2083 Introduced – Port Cybersecurity

Earlier this month Sen. Harris (D,CA) introduced S 2083, the Strengthening Cybersecurity Information Sharing and Coordination in Our Ports Act of 2017. This bill is essentially identical to the version of HR 3101 that was passed in the House last month.

While Harris is not a member of the Senate Commerce, Science, and Transportation Committee (the committee to which this bill was assigned for consideration), her co-sponsor, Sen Sullivan (R,AK) is. This means that there is a chance that the Committee could take up the bill.

It is unusual for companion legislation to be introduced this late in the process. It probably means that Harris does not think that there is a reasonable chance that the Senate will take up HR 3101, even though there was bipartisan support for that bill in the House. That is not unusual, the House passes a lot of bills that are never taken up by the Senate; the Senate is slower to pass legislation.

If this bill is marked up by the Commerce Committee there will be a better chance that it will be taken up by the whole Senate. Unless there are significant amendments made to the bill, there is a good chance that the House would accept the Senate version of the bill and not require it to go to conference.


It is unlikely that this bill will receive any consideration this year.

CSB’s Arkema Investigation Update

Earlier this week the Chemical Safety Board (CSB) held a news conference (note this link is to a copy of the email that I received about the press conference, the Sutherland statement is not currently available on the CSB web site) to provide an update on their investigation of the fires at the Arkema site in Crosby, TX after Hurricane Harvey (discussed in this blog here). As part of that news conference, CSB released a video showing the time-line of activities that took place during the incident.

The Time Line


CSB shared the following time-line graphic at that news conference



Commentary


Sutherland concluded her statement by saying: “There is a valuable lesson that facilities in the Gulf and elsewhere should note:  Reassess continuity of operations plans and worst case (sic) scenario assumptions.  Plan and plan again. Don’t be lulled into a false sense of safety by thinking that ‘it can’t/ won’t happen here.’”

A key part of that planning process is the identification of the key assumptions made during that process. Here, for example, the assumption was that flood waters would not exceed 2-ft. I would be surprised if this assumption was made and documented in any formal fashion, but it was made when it was decided to elevate the backup generators by that much.

If the facility had documented the reasoning process that lead to that decision, a periodic review of the plan may have noted that the increased rainfall that storms have been producing in the north-western Gulf Coast in recent years might have called for a revision of that assumption.

All emergency response plans need to be formally reviewed a recurring basis. For example, along the Gulf and Atlantic Coast, chemical facilities should formally review their hurricane response plans every spring, well before the start of the season. That review should include:

• Lessons learned from previous seasons;
• Assumptions about storm action levels;
• Assumptions about worst-case scenarios;
• Shutdown decision points;
• Evacuation decision points;
• Coordination activities with local community responders;
• Facility protection plans; and
• Recovery plans.

Worst-case scenario planning, it must be remembered, should not start with an assumption about what is the worst thing that could happen to the facility. It should start with an analysis of what is the worst thing that can happen at a facility. At the Arkema facility this would have been the decomposition/fire/explosion of the material in one of the cold storage buildings. From that worst-case incident the planning process needs to identify possible routes to that incident and the mitigation measures necessary to prevent those causes.

Was the worst-case planning at the Arkema facility adequate? In hind sight, it is easy to come to the conclusion that it was not; easy, but not necessarily correct. Three feet of flood water had never been documented in that area, so it is hard to fault Arkema (or any of its neighbors) for planning for such flooding. Plans going forward will have to be revised for that eventuality, but it was not reasonable pre-Harvey.

The other thing about emergency planning that we see clearly from this event is that plans need to be modified on the fly as situation change. It is clear from the timeline presented by CSB, that Arkema continued to recognize that the situation was changing for the worst and that they adapted in a timely and proactive manner to those changes. This is one of the reasons that facility evacuation plans in the face of storms like these must consider leaving a team on site to respond to changing conditions.

Any stay behind team needs to include knowledgeable management and operations/maintenance personnel that have the authority and skills to react to changing conditions. They must be protected against the potential storm effects and provided with communications tools to be able to coordinate with local response agencies if required.


As I have noted before in discussing this event, the CSB investigation of the incident should focus on the planning process that was in place for this facility. The result of the investigation should include recommendations for emergency planning actions that chemical facilities should take to prevent damage (with off-site consequences) from predictable natural disasters like hurricanes, floods, tornados, and earthquakes (all in appropriate areas of the country).

Thursday, November 16, 2017

ICS-CERT Publishes Two Advisories

Today the DHS ISC-CERT published two control system security advisories for products from Siemens and Moxa.

Siemens Advisory


This advisory describes multiple vulnerabilities in Siemens SICAM RTU products. The vulnerabilities were reported by SEC Consult Vulnerability Lab. Siemens is recommending that the web server be disabled after system commissioning to mitigate the vulnerabilities in current versions.

The three vulnerabilities reported are:

• Missing authentication for critical function - CVE-2017-12737;
• Improper neutralization of input during web page generation - CVE-2017-12738; and
• Improper control of generation of code - CVE-2017-12739

ICS-CERT reports that a relatively low-skilled attacker could remotely exploit the vulnerability using a publicly available exploit to execute arbitrary code. The Siemens security advisory notes that network access to the affected devices is required.

Moxa Advisory


This advisory describes multiple vulnerabilities in the Moxa NPort serial network interface products. The vulnerabilities were reported by Florian Adamsky. Moxa has a new firmware version that mitigates the vulnerability. There is no indication that Adamsky has been provided an opportunity to verify the efficacy of the fix.

The three vulnerabilities reported are:

• Improper neutralization of special elements in output used by downstream component - CVE-2017-16719;
• Information exposure - CVE-2017-16715; and
• Uncontrolled resource consumption - CVE-2017-14028

ICS-CERT reports that a relatively low-skilled attacker could remotely exploit the vulnerability to allow for remote code execution on the device.
 
/* Use this with templates/template-twocol.html */