I’d like to make a quick post with the release of some CANBus analysis tools I wrote.
The tools are written in javascript using nodejs, which comes preinstalled on the Beaglebone black — my hardware of choice when doing CAN analysis. I wrote up a brief README on setting up a Beaglebone for use as a CAN analyzer which you can find at https://github.com/digitalbond/canbus-beaglebone. That README provides links to the hardware setup we used at the S4 CANBus Hacking Class along with some instructions for getting an environment set up to start doing vehicle work in javascript or python.
For Version 0.1.0 we are releasing four tools:
unique_ids: Watches the CAN and logs all IDs on which data is sent
watch_id: Prints out every data packet for a given ID or IDs. Bytes that change from one packet to another are colorized for easy viewing.
decode_obdii: Decodes any OBDII standard request/reply messages sent over the CANBus. Includes a description of the message type according to the spec.
canbus_IDS: A very simple Intrusion Detection System for CANBus that will take configuration via JSON and alert on messages of a given ID. TODOs are extending alerts to use beaglebone GPIO and allowing ctype configuration of message data to alert on things like a bit flag being set.
The code is licensed under MIT. Contributions, questions, complaints are welcome. Check out the README file for more details on using the tools.
The document begins by noting the failed efforts to find a “mathematical coupling” between Safety Integrity Level (SIL) calculations and the Security Levels being developed by ISA99. This failure was not due to lack of effort. ISA99 struggled with this for years because the idea is so appealing.
The key part of the document is Section 1.2.
TG1 adopted Leveson’s technical approach[8] which uses the mitigation potential of the hazard as an estimator of, or surrogate for, likelihood for two reasons:
1) The potential for eliminating or controlling the hazard in the design or operations has a direct bearing on the likelihood of the hazard occurring.
2) Mitigation potential of the hazard can be determined before architecture or design is defined.
This is very similar to the Bryan Singer session at S4x15 and related to the Ralph Langner ICSage session (video will be up next week). The basic concept is to identify the really bad things that can happen in a factory, pipeline, process, and then put in controls that cannot be hacked. These controls are not additional firewalls, application white listing, or other security products. They could be something as simple as a visual inspection before an action is taken or a safety control that cannot be altered via a network and doesn’t rely on data that can be maliciously altered via a cyber attack.
Safety engineering has done this for years with various forms of hazards analysis, but it did not take into consideration a malicious attacker. The good news is the number of really bad things that can happen in a process is smaller than you might think.
The document touches on the LOGIIC study of Safety Integrated Systems (SIS) with Control Systems. Some of the big vendors are pushing this integration, and the report lacked the courage to recommend against this integration. The report did admit that “greater integration may introduce greater risk“.
First in a series on IIoT, Industrial Internet and Industrie 4.0.
I attended the ARC Forum last month in Orlando, and the theme was what ARC has coined as the Industrial Internet of Things (IIoT). Theme does not accurately describe the emphasis. Every session was described in terms of the IIoT, and if the speaker did not bring up IIoT, the moderator from ARC did. Even a classic SCADA or DCS implementation that had been running for 5+ years was described as IIoT.
I’ve read the ARC white papers on the IIoT, talked with a few ARC Analysts, and reflected on my ARC experience, and my conclusion is that IIoT is a vacuous term of no value to the ICS community.
The term IIoT has no value to traditional SCADA, DCS and ICS. The fact that ICS continues a decade long trend to move to digital communication and monitoring more data is important. Calling it IIoT does not help us understand, architect, deploy or secure it better.
IIoT as a general term does not help us understand the benefits and requirements for the variety of use cases.
This is probably the most important point. At the ARC Forum, IIoT was used as a generic term for anything control system or control system data related, and the importance of securing IIoT was almost always included generically in the discussion. Beyond saying that IIoT implementations should be “secure by design”, little guidance was provided or specifics discussed.In fact it is very hard to identify the security requirements for a general term that involves different confidentiality, integrity and availability requirements, involves a variety of trusted zone scenarios, different user scenarios, different physical environments, …In order for IIoT to be useful, it would need to be divided into use cases or a taxonomy developed. Good practice security controls could then be specified for a well defined use case. The problem with this approach is …
Many of the more important use cases have a developing lexicon that IIoT makes less specific and more confusing.The example getting the most attention in the ARC documents is sending ICS data out so it can be analyzed for preventive maintenance and process efficiencies. There are tremendous opportunities in this growing field, but a set of terms are already developed around “the cloud” and “big data”. It is actually a step back to roll this up into a new general term that encompasses many other use cases with very different requirements.
The one area that IIoT might be an apt term for is vendor communication and interaction to consumer devices, but this is the Internet of Things (IoT).
Kaspersky announced their project to develop a Control System OS back in October 2012. We tried to get them to present some details on the design criteria and goals at S4x13 and S4x14 without success. So we were very happy to have Andrey Nikishin give a session on the Kaspersky.
In this video you will see:
– the OS is for “embedded connected devices” (examples given: Smart Grid, PLC, Medical Devices, Network Appliances, Automobiles)
– the OS is not a clone of any *nix
– a broad view of the architecture including separating the microkernal from the security server. The security server determines the “security verdict” for all communication.
– the concept of a “verdict cache”
There still are many unanswered questions, and Andrey forestalled these questions by asking the questions he would not answer at the end of the session.
The ICS Security Research Newsletter has been dormant for a while now, but Reid Wightman and the team at Digital Bond Labs has resurrected it. They are committed to at least a quarterly issue in 2015.
The first issue for 2015 includes:
Information on the IBAL extensions for IDA Pro
Equipment Disposal Failures
Latest Project Redpoint ICS Enumeration Scripts
Auto Hacking x 2
Additional items we found interesting, novel or important.
Details on Stuxnet version 0.5 that only spread through Siemens project files
The Unsolicited Response Podcast has been inactive for a while now, which is a shame because I enjoy doing it and get a lot of positive feedback. Much of the difficulty in recording the podcast has been solved now that I have a very mobile podcast rig that I can bring with while traveling.
I’m committed to a minimum of 20 podcasts in 2015, and there are a few compelling guests already lined up. We will wait until five episodes are recorded before bringing on podcast sponsors, but let us know if you are interested in sponsoring Unsolicited Response.
The ARC Advisory Group invited me to participate in one of the security panels at the annual ARC Forum this week in Orlando. It’s an event I always wanted to check out so I spoke and attended. Here are some brief thoughts from the event.
The best part of the event is the large number of ICS owner/operators that attend. This includes many higher level attendees, people that can drive strategy and decisions.
Some of the asset owner attendees presented great case studies. Nothing related to security, but as an example Pitney Bowes talked about their Big Data efforts, setbacks and successes in the last ten months.
The only useful case study on security I attended was from Tyler Williams of Shell. They have been working on security for years and have a program now focused on 11 controls they can measure.
In a continuing regrettable string of events, Gregory Touhill from DHS missed or passed on another opportunity to tell this audience their ICS are insecure and need to be upgraded or replaced. Instead he just gave pablum, cyber watch, here are DHS programs, … He’s a good speaker and could have delivered an important and powerful message, but it appears DHS is happy with the status quo as long as we share information better.
The vendor exhibits were quite interesting to me as I hadn’t seen some of the newer versions or offerings, such as Bedrock Automation new controller, the progress made in the GUI and capabilities in Industrial Defenders ASM, the NextNine solution that is powering the Yokogawa/Cisco/Shell support, and PAS application for change control + security.
What ARC calls the Industrial Internet of Things (IIoT) was part of almost every session. They are calling existing ICS and ICS functions as IIoT. It’s almost impossible to talk about security of IIoT in a productive manner when everything is IIoT, “everything will communicate with everything” is the main description, and there is no taxonomy or organized set of use cases to discuss specific security needs. I saw very little value in the discussions of securing the IIoT at the event, including my contribution in the panel.
The pronouncements on what the IIoT would and should allow or look like were frightening, especially during an ARC keynote on Tuesday. There was about 5 minutes when my jaw was on the floor.
I need at least five long blogs to discuss the IoT issues and what ARC calls the IIoT. I’ll develop those over the next few weeks.
Digital Bond Labs has been using the IDA Pro API to extend it and make it even more useful for gray / black box testing. At S4x15 Reid Wightman, who heads up the Labs, introduced the first IDA Binary Analysis Library (IBAL) that are released for public consumption on our GitHub.
The goal of IBAL is to improve the state of firmware analysis.
Fuzzing will find a lot of protocol parsing vulnerabilities, but it can also miss a lot of protocol parsing vulnerabilities.
The early IBAL modules start with entry point analysis and then builds up a list of accessible instructions from that entry point. Then a researcher looks for coding mistakes in that accessible code.
Watch the video for a much better technical description of IBAL and how to use it.
Alexander Bolshev of Digital Security in Russia gave a great talk at S4x14 on exploiting vulnerabilities in the HART protocol and devices. His latest research is testing a large number of field devices accessible via the FDT Group’s Device Type Manager (DTM) protocol. According to the FDT Group, “DTM provides a unified structure for accessing device parameters, configuring and operating the devices, and diagnosing problems.”
As you might expect, Alexander found a number of vulnerabilities, and they are beginning to show up on ICS-CERT as vendors fix these problems. However, the more interesting aspect of the research is how his team efficiently tested a large number of DTM’s. Specifically 114 HART DTMs from 24 vendors that were used in 752 products. This represented a 10% sample of the HART DTMs. And the team had to do this in one month.
Watch the video to see the challenges and how they overcame them. The one that seemed quite nasty was “DeviceDTM will send the next command only when it gets the correct answer to the previous command”.
I’d like to make a quick post with the release of some CANBus analysis tools I wrote.
