DHS Secretary Napolitano announced Enhanced Cybersecurity Services — the US Government will share information on 0days and threats via a paid service offered by private government contractors like AT&T, Raytheon and Northrup Grumman. This would even include 0days purchased from researchers. Does this make or break the 0day market? How does this compare to a bug bounty? this is so odd it’s hard to even come up with a cogent argument for or against your tax dollars at work.

The US NIST published a document analyzing the request for information (RFI) responses to the upcoming cybersecurity framework. Respondents think it should be flexible, global, risk-based and leverage existing standards. Ok …

NIST issued Revision 1 of SP800-82 Guide to ICS Security. More importantly they announced an effort for a major update of this document to Revision 2 in the next year.

The NY Times and most other major media vaguely reported on cyber attacks on energy sector companies with the goal of sabotage or control of the ICS. The information is based on a non-public bulletin from ICS-CERT.

Anonymous announced Operation Petrol will start on June 20th against “greedy oil companies” and governments that support them.

The US Security and Exchanges Commission (SEC) reported that the 27 largest public companies sustained no major financial losses due to cyber attacks.

Tweet of the Week

the same public that says the #nist cyber security framework should be "risk based" says "baseball should include baseballs" #nistcsf #eo

about 21 hours ago via TweetDeckReplyRetweetFavorite

@sintixerr

Jack Whitsitt

Don’t forget to subscribe to this blog RSS feed and follow @digitalbond.com on twitter.

Worth Reading Articles

• CIO Magazine article Beware The Coming SEC Regulations on Cybersecurity
• Tom Aldrich post Meanwhile, Back at the (CIP v3) Ranch

Critical Intelligence’s ICS Security Event Calendar Updates

• ICS Security Session at Ventyx World, June 11-15 in San Francisco, California
• UTC Critical Infrastructure Communications Policy Summit, June 20 in Washington DC
• Australian National SCADA Conference, Aug 15-16 in Melbourne, Australia

Critical Intelligence provides reports and other information products on  Cyber Situational Awareness and Threat Intelligence services for Industrial Control System Owner/Operators, Vendors and Government stakeholders.

Image by ChrisInPlymouth

If you had any doubts about the thirst for ICS security news in the press, this week’s articles on some research from NC State provided a vivid demonstration. NC State puts out a press release on some early research, far away from anything that can be purchased, questionable if it would be of value in and ICS, and it turns into articles such as New Software Protects Networked Control Systems From Cyber Attacks.

Let me be clear that is not a knock on the research itself. We have been advocating and highlighting ICS security research for almost a decade now with our S4 conference. The researchers at NC State have an interesting approach that we might consider worthy of a slot at S4x14 or some future event as it develops.

The paper Convergence and Recovery Analysis of the Secure Distributed Control Methodology for D-NCS is available online.

The base idea is to eliminate sensor data from a process if the sensor or device passing the sensor data has been compromised. Actually, this could be due to any fault, not just a physical or cyber compromise. The challenge is how does the system know the sensor or device has been compromised?

The researchers rely primarily on a consensus algorithms, which I believe would severely limit it’s practical use. The example given in Section V.A is easy to understand. Eight temperature sensors take a measurement, and sensors 5 and 6 vary significantly from the converged value of the other six sensors. They are considered compromised and excluded from the process.

The problem with using consensus algorithms to detect cyber attacks or other anomalies is it requires the deployment and maintenance of a large number of additional sensors that don’t exist today in most control systems. Many times sensors are not redundant (let alone in numbers to allow consensus calculations), but data smoothing/interpolation takes place to remove and replace flawed or missing data. In a sense the researchers suggest doing this in a brute force way rather than through intelligent use of surrounding state and data.

There are high risk / high value sensors that implement a simple variant of the consensus algorithm suggested by the researchers. For example, you will sometimes see three sensors used in the chem sector, and one of the sensor’s data discarded if it varies more than a certain percentage from the other two sensors’ data.

If this is pushed out to the field or plant, as the researchers envision and makes sense, then the consensus algorithm would be implemented in the PLC which is much more likely to be attacked than the sensor. And there is still the data integrity issue in the PLC demonstrated by Stuxnet.

A more promising and realistic and difficult approach is to combine the suggested removal of data from a process with process anomaly detection rather than consensus algorithms. There have been a few sessions at S4 where researchers have tried to model possible states of a process and detect when impossible or unlikely states or state chains occurred. The most detailed have involved substation processes, and it has worked. The problem is it was very time consuming to develop the model to detect anomalies.

One minor item in  the paper particularly worried and bothered me. The researchers used the term Distributed Network Control System (D-NCS). DCS is a very common term if they wanted to focus on plant implementations, or the could have used ICS. Did they not know what terminology is commonly used by the people they hope will use the research?

The NC State press release was reasonable, not sensational, and sensible marketing of their research capabilities. The press are simply feeding the reading public what they want. The oddity is the interest in control system security is stronger outside the control system community than inside the community where the majority still hope the issue just goes away.

Image by chrissam42

First uses of a utility like this, could be fast scans of large subnets to identify PLCs. This could be PLCs of your own networks or PLCs of the internet, after all the blog post from scadastrangelove was titled “PLCScan the Internet”. It is only a matter of time before functionality of this sort gets added to searches like Shodan. A problem is that even this utility can cause issues on a production system if one does not know what kind of sensitivity comes along with these types of scans.

The more we use the control system protocols within to help identify the systems the more accurate information we will be able to get from the devices, also the safer the utilities will be to run. In recent blog post about practicing tools, Ralph Langner said “the device should be considered fragile by default, period”. I agree with this statement, especially for utilities like PLCScan, we should assume that we will bring the device offline if we are using a tool against a production network.

PLCScan could add great abilities to the assessment team. The utility can pull information from a PLC that then can be used as a reference point to validate information. This information could be information that the assessment team would had to manually pull from devices and configurations with screenshots. Information from the output from utilities like PLCScan are a lot easier to parse and utilize the data then reviewing screenshots.

Even with the risk of bringing the device offline the benefits to knowing what type of information that utilities like PLCScan can provide are very important to understand. Based on the testing we have performed with PLCScan, the script is well written and does take some errors into account to be the safest with the device as possible. It should be used against hosts and not subnets to start with as the only way to truly stop the scan may leave some devices in state that might crash the device.

Control system specific utilities like PLCScan will provide good information and a great value to the community if we keep helping projects like this get the most amount of information in the safest way possible. The more information we are able to gather about the systems on line we will be able to have accurate information about what is truly connected to the internet. If we can correctly identify the devices attached, we can remove them from the internet and protect them from malicious uses.

Image from Threatpost

ISA99 released another draft standard for comment this week – ISA-64432-4-1 Product Development Requirements. I’ll write up my thoughts on it in an article next week.

Kim Zetter of Wired covered another vulnerable ICS connected to Internet story this week. It normally wouldn’t warrant mentioning as loyal readers have certainly heard enough of this Shodan / Internet search story. However, it was a Google Building Energy Management System.

Tweet of the Week

1) Hack Google's Building Management System2) Report it to the Google Vulnerability Rewards Program3) …4) Profit?http://t.co/VvLJrjrr9N

6 May 2013 23:33 via TwitterrificReplyRetweetFavorite

@mikko

Mikko Hypponen ✘

Don’t forget to subscribe to this blog RSS feed and follow @digitalbond.com on twitter.

Worth Reading Articles

• Dan Goodin’s article on the use of Honeywords.

Critical Intelligence’s ICS Security Event Calendar Updates

Nothing this week.

Critical Intelligence provides reports and other information products on  Cyber Situational Awareness and Threat Intelligence services for Industrial Control System Owner/Operators, Vendors and Government stakeholders.

Image by ChrisInPlymouth

John The Ripper has been around for many years, and is one of the most common password cracking utilities out there. With an add-on plugin and a script that is easy to run, the password hashes are extracted out of  packet captures, and cracked using John The Ripper.

The use of John The Ripper outside of the normal workstations and servers inside of ICS environments is very limited, as most devices you can’t get the information required to run the software against the password hashes.

With the rise of password complexity requirements inside of ICS environments, auditing the password complexity of PLC and like devices can be difficult and rely a lot of how much you trust the engineer. As an example there is nothing to say that the PLC configuration that you are looking at on the engineer workstation is the one that is truly pushed out to the PLC. With the ability to gather information from a packet capture and then verify the password complexity adds that much assurance to an assessment.

However, this utility can be used for nefarious purposes, take an example where on a support portal for a vendor some one uploads a packet capture to try to get help, now this packet capture is downloaded by an attacker. This utility makes it easier for an attacker to crack the passwords of S7 devices. This gives an upper hand on the ability to write custom malware to alter configurations and the likes. Thats not to be said this couldn’t and wasn’t a capability before, this just took their ability and made it easier for them.

Password cracking is dependent on the hardware in which you are running the password cracking software on. The only testing I was able to perform was on some packet captures that were given to me from Sergey Gordeychik of Positive Technologies, and the passwords were very simple passwords that cracked within a second or two. The more complex the password the more time it takes to crack via brute force techniques, with more and more password breaches happening the word lists are getting bigger which helps the dictionary attacks get that much more powerful. I expect to see more ICS devices fall to this type of attack in the future.

Photo from awaitingdawn

I’m looking forward to conducting this training, as I’ve spent the past 8 or so years engaged in power generation work. There are nuances and concerns associated with Cyber Security for Power Generation, and I’m looking forward to sharing with attendees.  Cost is $495, which is a bargain for an 8 hour professional training.

For more details, please check out the event site.

The session explains n-gram analysis and shows the results of four different n-gram approaches on finding anomalies in 30-days of Modbus/TCP traffic on a water ICS and 7-days of SMB traffic on a gas SCADA. This was great to see because using real world data in ICS research is actually still rare.

The results of the n-gram models were better for the Modbus/TCP, but even the best model had 10 false positives a day even with the highly repetitive Modbus traffic.

Damiano then proposes a new method that is an extension of what is done in Tenable’s Passive Security Scanner, INL’s Sofia and other products. Those products will identify “normal” communication on the network by source IP, destination IP and destination TCP/UDP port. The example demonstrated in the presentation includes other ICS protocol parameters.

For example, it will identify what function codes are used and alert on new function codes. It will identify data lengths and alert on new data lengths. Obviously the similar the protocol the easier it is to do this. An application layer protocol like Modbus/TCP is relatively simple. A protocol that includes its own data and transport layer, like DNP3, could cause more false positives unless packet fragmentation is dealt with. A complex protocol like EtherNet/IP would be much more difficult. It is similar to the issues that require a preprocessor in signature based network IDS.

In fact, some of our early Quickdraw IDS signatures detect similar anomalous behavior. However, the signature based approach requires selecting and modifying the signatures manually. Damiano’s approach generates these rules automatically.

I’ve seen SCADA protocols brought low by a simple repetition of ‘AAA…’; and I’ve seen much more complex fuzzing efforts (such as those brought up by Terry McCorkle and Billy Rios in some of their advanced training). In normal IT, fuzzing often focuses effort on the ‘server’ or ‘input’ part of the communication, where the user can influence input sent to the server. This is because the user is determined to be the larger threat, and the server is considered the system to defend. There are exceptions to this, one of the notable ones are browser based bugs designed to infect users based on input received from a web server.

But most ICS deployments have the exact opposite use case. Yes, we use client-server type architectures, but the systems that require the most protection are often not the server ones (the PLCs), they are the client systems (the controlling HMIs, etc). For example, take a Modbus communication: The client requests point data directly from a PLC, which then responds back to the client with the point data requested.  Simple right?

However, when the client is requesting data it is also vulnerable to a malicious response. In most research I’ve read, this malicious response has usually been ‘bad data’, data designed to provide upstream operators with false readouts and influence decisions. Easy to do when your protocols lack integrity. But, what if there were buffer overflow conditions in code that processes a response? An attacker might be able to use these conditions to crash the upstream process, and potentially insert their own code.

This request-response type architecture is present everywhere in automation, and runs over both TCP/IP and bare serial protocols. The more interesting condition is that a control center (the client) communicates to potentially hundreds of end devices (the servers), and only a small portion of those end devices may have physical and cyber protections. I use this example because I see it in NERC CIP implementations everywhere, where you have a Control Center with a dozen critical substations and 4 dozen that are non-critical.

I had an opportunity to do some very basic fuzzing for clients in the past, and recently looked at this condition. While I lacked time (this was limited to about 4 hours of  hacking, including recording the requests and responses) to put together something truly magnificent, I did write-up some basic Python code to send back malformed data when a SCADA system requested it. I didn’t find anything with this, maybe you will. Use your best judgement in implementing this code, as it is intentionally designed to provide data intended to crash systems and process.

This code was written to pretend to be a Modbus device in a few very simple cases, allowing the Control Center to request data from it. The responses from the program were intended to be scripted, but you could build more intelligence in if necessary with the PyModbus project. Specifically, this code pretended to be a serial Modbus device, accessible through a Ethernet to serial converter. This made interception and monitoring of the communication much simpler than going through a bare serial interface.

The intent of the code was simple:

1. Listen for a specific requests from the control center
2. Queue up a valid response to that request
3. Randomly alter some of the parameters from a valid response
4. Respond to the control center
5. Log all information regarding the communications to flat file for analysis

The major limitation in this code is lack of CRC generation, which would ensure that the malicious data is accepted by the subsystem as valid, and then processed. I’ve also removed the payloads I worked with, you’ll need to generate your own valid requests and responses.

Link to code

title image by oskay

Readers looking for some detailed guidance or requirements on performing a security risk assessment or designing a security architecture will be disappointed. This standard is primarily a process document that tells an owner/operator the tasks that must be done in a risk assessment, but doesn’t provide much information on how to do the tasks.

The positive spin on this document is it provides a consistent process and terminology for performing an ICS risk assessment. For example there is a specific list of information that must be documented for each zone and conduit in Section 4.4.3.1.

The negative spin is it has requirements, “shalls”, without helping an owner/operator determine how to do this. A few examples:

• 4.5.1.1 “A list of the threats that could affect the assets contained within the zone or conduit shall be developed.”
• 4.5.2.1 “The zone or conduit shall be analyzed in order to identify and document the known vulnerabilities in the zone or conduit access points and in the assets contained within the zone or conduit.”
• And then the list of earlier required shalls are combined in a calculation such as 4.6.1.1 “The residual risk calculated for each threat 4.5.5 shall be compared to the organization’s tolerable risk (specified in 4.3). Additional security countermeasures must be applied if the residual risk exceeds the tolerable risk.”

This document is high level Risk Management 101. It’s actually a very short document and quick read with about 5 pages after you strip out the formatting and definition sections and an example annex.

It may be unfair to look at this document in isolation. ISA99 has a large set of standards and technical reports in process that interlock to hopefully form a complete picture. In addition, future annexes (appendices) are hinted at that could provide guidance on how to achieve these mandatory requirements. This is started with a partially completed annex on a chemical truck loading example, and another annex to be written with “several possible methodologies that can be used to assess the frequency of the threat hazard”.

There is guidance on security zones as the standard recommends (shoulds) that control, safety, corporate, wireless, and mobile devices all be in their own zones. All guidance is very broad such as “The organization’s tolerable risk for the SuC should be included in the security requirements specification.”

It’s a draft so there is still work to be done. Consider even the limited examples in this article. Specifying the organization’s tolerable risk is optional, but it is then required in Section 4.6.1.1. ISA99 has a comment form and is very welcoming of any suggested improvements.

In summary, ISA-62443-3-2 isn’t going to be of much assistance to an owner/operator doing a risk assessment or a security design unless there is substantial work on the annex. It likely will be a key component of the overall ISA99 standards framework.

Image by SludgeGulper

Heise, a major German publisher, introduced the German market to the Internet connected ICS. Nothing new here, but some good screen shots of what they found.

ICS-CERT strangely published 30+ mitigations for Shamoon. Why now? And what to these mitigations have to do with Shamoon? They are basic SCADASEC and INFOSEC 101. Backup, incident response, anti-virus, segment, … To be charitable this is a worthwhile message to put out over and over again, but if they wanted to take advantage of the Shamoon buzz to get this info out they are quite late. If they wanted to make a more compelling document, they could have tied the recommended controls into the attack and demonstrated how they would have helped prevent, detect or respond to Shamoon. ICS-CERT continues to be weak.

Rand Beers has been named the Acting Deputy Secretary of DHS. This may help ICSsec get a bit more attention since Mr. Beers was the Under Secretary for the National Protection and Programs Directorate (NPPD).

Patrick Coyle reports on a scheduled public meeting of the US Information Security and Privacy Advisory Board. The meeting will address issues related to President Obama’s Cybersecurity Executive Order.

Tweet of the Week

.@andrewsmhay One should aim higher than the target; also… if target is moving, one must lead the target

2 May 2013 10:03 via TweetDeckReplyRetweetFavorite

@joshcorman

Joshua Corman

Don’t forget to subscribe to this blog RSS feed and follow @digitalbond.com on twitter.

Worth Reading Articles

• SC Magazine Brief Interview with Marty Edwards < DP Note: Marty is that sincere, good guy you read in the interview. The last answer is a sad reality though.

Critical Intelligence’s ICS Security Event Calendar Updates

• ICSsec presentations at AusCERT, May 23-24 in Gold Coast, Australia
• APTA Securing Control and Communications Systems in Rail Transit Environments, June 5 in Philadelphia, Pennsylvania
• Rios/McCorkle Black Hat Training ICS for Pentesters, July 27-28 and July 29-30 in Las Vegas, Nevada
• Conference on Critical Information Infrastructures Security, Sept 16-18 in Amsterdam, The Netherlands
• ISA Advanced Industrial Cybersecurity, Sept 16-20 in Houston, Texas
• Cyber Security in the 21st Century for the Chemical and Petrochem Industries, Sept 24-25 in Houston, Texas
• Using ANSI/ISA99 (IEC 62443) Standards To Secure Your ICS, Oct 17-18 in Houston, Texas

Critical Intelligence provides reports and other information products on  Cyber Situational Awareness and Threat Intelligence services for Industrial Control System Owner/Operators, Vendors and Government stakeholders.

Image by duncan