Unsolicited Response

The CyberX report is interesting because they are pulling hard data from 375 different ICS networks and some of the statistics were not what I expected. In this episode I talk with Phil Neray of CyberX about their Global ICS & IIoT Risk Report.  

We start on the data, then we dive into some of the more interesting statistics. Throughout the discussion we talk about ways the statistics could be improved for future updates of the report. I'd welcome your suggestions and will pass them along to Phil.

I had 20 minutes to interview Eugene about the US Government claims that Kaspersky software is subject to Russian Government influence and needs to be removed and not used from USG computers. As you can imagine he defends the security of his company's products and makes the case why the US Government's claims are strictly political. We also cover the Kaspersky OS and their ICS products and services.

After the interview I give my thoughts on the Kaspersky issue and cyber nationalism.

Eric and I had gone at in a series of blogs on whether he was a SCADA Apologist or SCADA Realist. I coined the term SCADA Apologist as someone who:

1. Is highly knowledgeable in ICS and ICS security, often a well recognized expert.
2. Knows the ICS systems, devices and protocols are highly insecure. They are insecure by design and loaded with easily found and exploitable bugs.
3. And then says nothing can be done about this for many years or decades.

Eric responded with a series of blog posts that my position was unrealistic and unhelpful. Despite the spirited written debate, we are good friends, and thought it would be useful to have this argument in a debate format on the S4x14 stage.

Michael Toecker moderates the debate and their are questions from the audience. 

I can't say for certain that my SCADA Apologist and other rants instigated change, although I like to think they raised awareness and played a role. The good news is that in 2017 we are finally seeing the insecure by design issue addressed, and now the argument is when these more secure systems will get into the field. So the "it will take decades" forces are still out there.

Dale Peterson interviews Patrick Miller of the Archer Security Group about how NERC CIP security standards have affected the security of electric generation and transmission in the US. We try to stay clear of the compliance issues, which is difficult, and focus on the real impact in reducing the risk and improving the security posture of the bulk electric system in the US.

This month Synopsys put out their State of Fuzzing 2017 report. It's useful data, but the context of the collection and the metrics used to evaluate failures is very important. I talked with Chris Clark, Principal Security Engineer for Strategic Initiatives at Synopsys, to discuss the report.

Key points from the podcast and report include:

• The data comes from the yearly totals of usage by Synopsys customers. The data is anonymized.
• This means the protocol stacks are likely in development or QA and being tested. Some percentage of these flaws are fixed prior to release. The numbers may not be as grim as they appear.
• You need to understand the market and protocol history to make sense of the numbers.

Two examples on the last point.

1. The CAN protocol testing for the automotive sector is almost entirely of ECU's in a lab environment, not deployed in the automobile. There are large numbers of ECU's in cars as opposed to a single or very small number of protocol stacks in a PLC or even in an entire SCADA or DCS. 
2. The Modbus TCP numbers look terrible. Modbus TCP is such a simple protocol that many, if not most, code up their own Modbus TCP stack. Most large and established ICS vendors have fuzzed and fixed their Modbus TCP stacks. So the numbers don't likely reflect the robustness of the deployed Modbus TCP stacks.
   
   Contrast this to DNP3 that has a smaller number of stacks and most stacks purchased from a single vendor, or OPC UA where the complexity of the stack encourages buying rather than building.

Other points:

• The number of protocol stacks in each protocol (Modbus TCP, OPC UA, etc.) varies and is based solely on customer use. It could be one stack or 21 stacks.
• The number of tests and test methodology is entirely determined by the Synopsys customer. It is not uniform.
• The detection of failure is also not as rigorous as you would see if the device was monitored for performance of its full role. 

As Chris stated, this should be considered a top level view of the state of the ICS protocol robustness. The key is to understand where these numbers come from and not read more into them than the constraints warrant. And we should appreciate that ICS vendors are doing this type of testing.

Note: I apologize for the voice quality of this. It was a combination of a mistake I made in setup and marginal line quality. It is not difficult to understand, but not pleasant to the ear. I will do better.

This episode begins with a 10 minute monologue from Dale Peterson on why demonstrations of insecure by design, no SDL and modifying physical processes is not particularly interesting for the advanced ICS security audience ... and why it is still important.

Then we play Dale Peterson's interview with Steve Bitar of ExxonMobil on the Open Process Automation (OPA) initiative. If the OPA is new to you, you will learn what it is. Then asks Steve the tough questions.

Dale Peterson interviews Rob Lee, founder and CEO of Dragos - SANS 515 Creator - former SCADA Diva - Chief FUD Debunker - ..., focusing on how an asset owner should select an advanced IDS detection solution from a crowded market of 25+ new offerings.

Here is a breakdown of the episode:

3:50 What surprised Rob most about the response to Crashoverride?

8:40 What should be in place before an asset owner considers an advanced threat detection solution, and how many and what type of people are required to gain the benefits of a sophisticated detection solution.

13:30 Rob's controversial view that their should be a separate ICS Secure Operations Center (SOC) rather than integrating it into an existing Enterprise SOC.

Then we talk about Rob's breakdown of four different classes of ICS detection solutions

15:55 Configuration Analysis Solutions

19:15 Statistical Analysis (Modeling, Baseline, Threshold and Time) Solutions

24:50 Indicator (signatures) Solutions

30:35 Behavioral Solutions compared to other three approaches

35:50 How does an asset owner choose between the 25+ offerings?

37:40 Rob's view that vendors in this space are startups and can't do a good job in multiple classes. They need to focus on one class and a small number of sectors to be credible.

39:35 Depth v. Breadth and the push to please VC's by saying you cover the entire ICS space

43:50 You got to test it

 

Signup for the ICS Security: Friday News & Notes email

Check Out the S4 Events YouTube Channel

 

Joel Langill, aka the SCADAHacker, joined me on the Unsolicited Response podcast to discuss ICSsec training and workforce development. As you can imagine the interview covered a lot of other related areas.

Joel is the Director of ICS Cybersecurity at AECOM, see http://www.aecom.com/solutions/converged-resilience/. He also runs the popular ICS security website https://scadahacker.com/ , and details on the training he describes in the podcast is available at that site.

Here are some podcast highlights.

2:15 - Joel's background in ICS/automation prior to getting involved in security.

13:05 - How Joel's background has informed his approach to security.

16:50 - Started discussing ICSsec workforce development.

18:50 - What would be the ideal training for an ICS security professional?

23:25 - Using a pharma company as an example, how many people in that company would require ICSsec training. What type of training for what roles? .

26:05 - Where should the ICS security talent be located in a company?

27:40 - How to scale training, online training, and how he structures his online training

29:55 - Joel's belief that an online class is more effective than an in person course and a discussion of the course Labs.

32:10 - What has Joel learned in training 500+ students.

35:20 - If 40 hours is not enough to get you where you need to be as an ICSsec professional, how do you or the market address the need for additional training? Joel notes most students did not meet the criteria/skill set to fully benefit from the class.

38:40 - The benefits of a hands on assessment to determine current skill level and needs to select required training.

41:20 How Joel's joining AECOM will affect the SCADAhacker training.

 

 

Dale Peterson interviewed John Matherly, the creator of Shodan, in Kuwait. Lots of good content with the breakdown of highlights and times:

3:10 What is Shodan?

4:45 John's background and why he started Shodan

9:10 Adding ICS to Shodan ... originally John  thought it was too risky

10:45 How fast he can add new ICS protocol support (less than a day)

13:00 Looking to add more support for medical devices

16:00 How are the customers using Shodan, external network monitoring is most common use case ... but few ICS related customers ... more ICS vendors

19:30 Does John see Shodan ever scanning an internal network?

21:00 Shodan does legitimate request scanning ... a proper handshake

24:45 What does he do when someone doesn't want Shodan to scan their address space?

27:30 What has been the industry impact of his Internet connected ICS map?

29:20 The number of Internet connected ICS has only increased since he has been tracking

32:15 The Omron example

35:00 What else are you going to do with all this data, the real value of Shodan's database 

38:15 John's request of the ICS Community

And at the end we get a bit into the weeds about what Shodan can and should do with various ICS protocol examples.