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