Podcast: Play in new window
| Download (Duration: 1:07:46 — 62.0MB)
Episode 2015:2 SANS ICS Security Training and Certification
SANS provided four individuals for our Unsolicited Response podcast on the 5-day ICS 410: ICS/SCADA Security Essentials training course and the related Global Industrial Cyber Security Professional (GICSP) certification.
- Scott Cassity, Managing Director of GIAC
- Mike Assante, SANS Lead for ICS/SCADA security training
- Justin Searle, SANS Instructor and major course content creator
- Graham Speake, SANS Instructor and participant in GICSP creation
In the hour long discussion we cover:
- Why SANS developed an ICS certification and training course
- The difficulties and benefits of having a mix of IT Security and OT students in the class
- How the course and certification were created and how they are structured
- Early feedback on the course and certification along with likely changes and possible future courses (2-day course) and certifications
- The number of students trained and the number of certified GICSP
- Why SANS courses are so expensive relative to other courses
- How should a potential employer view an individual who has the GICSP certification
I also gave the SANS team a chance to answer the criticism that this is an IT Security course from an IT security organization.
I appreciate SANS providing so much time and resources to the podcast. I think there is a fair argument on how the SANS course rates in comparison to the competition, and it might depend on the attendee profile and goal of taking the course. The one thing that SANS has going for it is they know how to scale up to train thousands of students, and this is needed in the ICS security space.
I’m committed to a minimum of 20 podcasts in 2015; this is episode 2. 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.
Subscribe to the Unsolicited Response Podcast in iTunes.
Digital Bond is pleased to announce the 2nd edition of S4xJapan will be held on November 5 – 6 in Tokyo.
The event will be in the Mori Building, Roppongi Hills. The Academy Hills facilities on the 49th floor were perfect for the event last year. The room where the sessions are held have desks/power/Internet for all with a tiered seating so there isn’t a bad seat in the venue.
Thursday, November 5th will be Operations Technology Day (OTDay) where we will focus on real world examples of operating and securing critical control systems implementations.
Friday, November 6th will be the S4 Technical Sessions. You will hear the latest offensive and defensive ICS security research and technicals in technical detail.
Our goal is to have the sessions in English and half in Japan, with simultaneous translation as appropriate. You can see some of last years sessions our video site, and we will be posting the remainder over the next two months.
We also will have a social event after the Thursday sessions in the Academy Hills library. Last year it was food, drink and the Kaspersky ICS Simulation Game. We are planning something fun for this year as well.
The Call For Presentations will be released just after Golden Week, so be thinking about what research you will want to submit to be a part of the event.
Continuing in the line of CANBus research and tools release I’d like to announce some quick work on a proof-of-concept CANBus IPS called, unoriginally, the CANBus Protector. I took some time to work on defense of CAN after conducting a lot of vulnerability research in recent weeks.
The trouble with trying to defend insecure by design protocols is that you can’t. CANBus is a protocol that cannot be done correctly….ever. I don’t think I’m being unreasonable in stating so. When considering defensive security methods there really is only one design that makes any sense.
CANBus protector is a system built on two separate pieces of hardware that use one-way communication to get information out of the “trusted” vehicle network. The only way I could see protecting the bus was to create a “server” which would sit on the actual CAN and perform the queries for vehicle information. This is done through standard set of OBDII queries made by the server (e.g. Vehicle Speed, RPM, VIN, etc). Future expansion of the project would include more queries and manufacturer specific information. The server then publishes that information via one-way communication to a “client”. The client sets up an entirely separate CANBus where any third party systems would sit. These third party systems requiring vehicle information would not be aware they are not speaking to the actual vehicle network.
This limits the attack surface by removing the risk of third party dongles plugged into a vehicle OBDII port. This device does not attempt to address the vehicle manufacturer itself attaching a network-enabled system directly to the CAN (which is happening). That particular action cannot be protected against except by vehicle manufacturers. The best one could hope for out of a third party solution is alert the user if a certain type of message is seen on the bus. If that message is malicious, however, it may be too late. It could certainly work as a “black box” of sorts though. Hmm…perhaps vehicle CAN forensics will be the next project.
If you are so inclined you can download the source and create your own CANBus Protector. The repo can be found at https://github.com/digitalbond/canbus-protector
The Capture The Flag (CTF) contest in the ICS Village at S4x15 was a big hit. We have had numerous requests from attendees and those that heard about it for more information and data. So Stephen has put together a page of information. The page includes:
- Examples of flags in each of the five categories
- Packet captures with ICS protocol and attack data (the most requested item)
- Screenshots of detected data and the scoreboard
- Pictures from the ICS Village
- An explanation of the event
You may also want to watch an interview with the team that won the CTF.
Great job by Stephen and the team of volunteers who put the CTF together and kept it running under three days of attacks. It puts a lot of pressure on the team to make it bigger and better for S4x16.
Ralph Langner presented at ICSage: ICS Cyber Weapons during S4x15 Week. As always Ralph is introducing new thoughts to push the industry forward, but this session is more on how to orient and organize the ICS communities’ thinking on attack / defense on ICS.
There is entirely too much attention paid to 0days and compromising an ICS computer or application. This is still trivial to do based on code quality and is almost always unnecessary. A more useful line of thinking is what would or could an attacker do with this access, what would be the intended result, and what can we do to defend against it.
- At the 9 minute mark, Ralph discusses different types of ICS cyber-physical attacks.
- At the 22 minute mark, he breaks down impact categories of cyber-physical attacks.
- At the 29 minute mark, he discusses examples of how to identify the defensive controls to prevent catastrophic results.
The pull quote, in my opinion, was “is there any combination of bits and bytes that if I throw that at this plant will result in harmful physical effects? This is a question that can be answered through engineering methodology”.
I’d like to make a quick post with the release of some CANBus analysis tools I wrote.
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 repository is available at https://github.com/digitalbond/canbus-utils.
Happy Vehicle Hacking,
ISA99 Working Group 7 has a draft document out entitled “Recommendations to align safety and security for industrial automation control systems“.
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 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“.
If you are interested in the Safety/Security approach moving forward in ISA99/IEC62443 it would be worthwhile to spend some time with the Leveson’s: Engineering a Safer World: Systems Thinking Applied to Safety (Engineering Systems).
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).
Kyle Wilhoit has found and analyzed a large portion of the ICS malware found in 2014 / 2015. He goes into the details of:
– The Sandworm group looking for Internet exposed HMI and their targets
– Blacken / Black Energy targeting the GE Cimplicity HMI
– Havex scanning OPC Servers (including videos showing it being installed and exploiting the system)
– Trojanized SCADA software … WinCC (32 samples), Advantech (24), and Cimplicity
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.