Securing SCADA systems from APTs like Flame and Stuxnet – Part 2

Submitted by Eric Byres on Tue, 2012-06-19 21:00

Professor Paul Dorey recently presented a paper about the seven important lessons the IT world has learned in managing Advanced Persistent Threats (APTs). In this article, I will discuss lessons #2, #3 and #4, and how to apply these lessons to ICS and SCADA security.

APTs have been discussed in some depth in previous blogs, so if you aren’t familiar with the concept (or need a review) check out Part #1 of this series. If you want real world examples of APTs, especially ones that have impacted the energy and chemical industries, browse some of my previous blogs on Nitro, Night Dragon and Duqu.

Energy companies were targeted by recent known Advanced Persistent Threats such as Night Dragon and Duqu.

Professor Dorey’s talk discussed the seven advanced approaches that the best companies are using to deal with APTs. His Advanced Approach #1 involved setting what he called “‘Controls Coverage”. The objective is to focus protection efforts on your company’s most important assets, rather than using the shotgun approach of trying to protect everything equally.

Lesson #2: Focus on Detection, Not Protection

Advanced Approach #2 centers on “Control Focus”. If you are going to spend money on security controls, what types of controls are the most effective? Professor Dorey notes that Detective Controls (i.e. those technologies and processes that detect attacks) are more effective against modern cyber threats when compared to Preventative Controls like firewalls, data diodes and anti-virus software.

Now you might think that a person that designs and sells ICS/SCADA firewalls for a living (me) would be dead against Professor Dorey’s approach. I’m not. The fact is, after reviewing countless control systems and attacks against control systems, the industrial automation world is terrible at detecting anything unusual on their control network. Few companies can even discover when a contractor has attached an unauthorized laptop to their system, never mind detect a sophisticated, stealthy attack.

The old “security in the dark” approach has to end. SCADA and ICS engineers need to get a better handle on what sort of traffic is travelling over the control network. To address this, a major focus at Tofino Security in the past year is the addition of strong reporting technologies into the Tofino product line. For example, modules like the Secure Asset Management LSM are designed to detect and report if unexpected devices join your network.

Similarly Tofino’s deep packet inspection (DPI) modules for the Modbus and OPC protocols provide detailed reporting to 3rd party Security Incident and Event Monitoring (SIEM) systems. So if your read-only remote operator station suddenly starts to try to program a PLC, you can get an immediate alert that trouble is brewing in your control system. Expect to see more detection technologies from the Tofino Security team soon. It is something we strongly believe in.


Seven Advanced Approaches for dealing with Advanced Persistent Threats. From Professor Dorey’s presentation "Advanced Persistent Threats - A Real Problem with Real Solutions".

Lesson #3: Move Your Perspective from Perimeter-based to Data-centric

The third lesson for successful APT containment is to change your security focus from controlling the perimeter to controlling specific collections of data, regardless of where they are in space and time. For example, if a financial company can ensure that customer credit card records are encrypted at all times (and the keys to decrypt the records are not leaked), then the loss of a laptop with these records is of limited importance.

Or take the case of Bradley Manning, the young US Army private that leaked thousands of classified documents to WikiLeaks. If these sensitive documents had been always encrypted and Bradley had only been able to view them with a controlled application at his desk, then his ability to share so many documents would have been limited. Instead, it is clear that the US Army’s security strategy was to leave them unencrypted, (or in a form that was easy to convert to an unencrypted form) and hope these documents never left the perimeter of the US military-base. Obviously, this “perimeter-focused” strategy failed badly.

A defense that only focuses on defending the perimeter is a weak defense, as was learnt by the Davis-Besse Nuclear Power Plant incident in 2003.

At first glance, applying this lesson to ICS and SCADA systems appears to be difficult as data confidentiality is of far less importance to the control system. But substitute the word “process” or “asset” for the word “data”, and it makes sense. A “process-centric” or “asset-centric” approach to managing security means making sure that specific high value processes continue to function reliably regardless of what else is happening around them. The safety world, with standards like IEC61508 and IEC61511, has a long history of using this sort of approach.

Lesson #4: Why Log? Compliance versus Threat Detection

The final Advanced Approach lesson for today’s blog looks at the reason we log security events (assuming we log them at all). Too many of the sites I visit, especially sites trying to pass NERC-CIP audits, log only for compliance reasons. They generate massive log collections, but if anyone ever bothers to analyze the logs, it is only after something really bad has happened. By then it is too late.

Now effective threat detection doesn’t mean pouring over thousands of logs every day. It means optimizing what information you collect so that dangerous anomalies standout, rather than get buried in the noise.

Lessons #1 to #4 – A Realistic Unified Security Strategy

Look back at Lesson #1 – “Focus protection on your most important assets” and compare it with the three lessons from today. What you will notice is that these four lessons are highly related around the concept of focused effort. For example, effective threat detection is only possible if you focus your controls on detection and focus your coverage on what matters. Unfocused approaches to security that try to protect everything inside a perimeter are too complex and too expensive.

So think about what processes and assets you really want to protect in your SCADA or ICS system and start focusing on those. Think about what would indicate trouble in your system and focus on detecting that. Advance your security approach from scattered to focused and save time, money and effort. Most importantly, you might just save your company from the next APT.

Do you agree with a focused approach to industrial cyber security? Let me know your thoughts.

Related Content to Download

Presentation - "Advanced Persistent Threat: A Real Problem, with Real Solutions"

 

Download this presentation and benefit from:

  • Definitions of APT and The Threat Continuum
  • Examples of Advanced Persistent Threat (APT) attacks on major companies
  • A summary of the advanced approaches companies use to defend against APTs

Practical SCADA Security thanks Professor Dorey for making this presentation available to our readers.

Related Links

 

RSS Feed Subscribe to the "Practical SCADA Security" news feed

Author Eric Byres

Comments

8
Submitted by Maryna (not verified) on Tue, 2012-06-19 14:57

Eric,

my comment is probably not directly but somewhat relevant to your posts (Part 1 and 2). You put major stress on the cyber-side of the control domain security. What about process security? This is a real crown jewel. At the end, to win the battle (not the war) the companies should be able fail-safe in the presence of a targeted attack. From the few examples of practical attacks (e.g. exploiting Aurora vulnerability), it is clear, that safety/protections systems fail/may fail to take over if a device or a process is manipulated in "unnatural" way. It is important to be able to detect manipulations of unusual or unnatural nature. E.g., the fact that the Iranian centrifuges were speeding up and slowing down was unusual, but safe from safety point of view. Safety/protection systems did not take over to prevent centrifuges' breakdown, as they were not design without having in mind possibility of intentional manipulations.

Submitted by Eric Byres on Wed, 2012-06-20 16:47

Hi Maryna

Excellent point - I agree that the real crown jewel is the process itself. The closer we can get to protecting the process, the better off we are. Protection at the perimeter is the worst solution, protecting the controller network is better, protecting the SIS itself is even better and your solution of an intrinsically secure process is the best.

My concern is that we are so far from designing a secure process that at least we better do the next best thing and protect as close to the process as possible. For me that is protecting systems like the SIS.

Unfortunately we are going the wrong way in this area as well. We have designed our safety systems to protect our processes from a probabilistic event, not a deliberate event. We have also introduced the possibility of common-cause failures by simply repeating the same CPU multiple times. That works well when a controller fails due to a mechanical fault, but poorly when the cause is something as simple as a network traffic storm.

Hopefully industry starts to move to secure processes, rather than hiding behind perimeters.

Submitted by Ragnar Schierholz (not verified) on Wed, 2012-06-20 00:17

Hi Eric,

Thanks for your summary of Prof. Durey's talk - interesting for those who couldn't attend the talk itself (incl. me).

The concept of asset-centric / process-centric protection very much sounds like a different phrasing for a risk-based approach that has been called for by many for a good while. Is that understanding correct? And if so, did Prof. Durey touch on the question of how to quantify risk, especially the likelihood part? Did he address the black swan risk category?

Cheers,

Ragnar

Submitted by Eric Byres on Wed, 2012-06-20 16:33

I never thought about it that way, but I think you are right; the concept of asset-centric / process-centric protection is similar to a risk-based approach. Now in fairness to Prof. Dorey, he only talked about the IT world's issues with respect to ATPs, which usually revolves around data confidentially risks. For data loss, the risk models are getting more sophisticated and thus that didn't come up in the session.

For better or worse, it was my idea to extend Prof. Dorey's ideas to ICS/SCADA security, a land where data confidentiality is less important and the risk models are still evolving. Unfortunately I don't have a good solution yet for the black swan risk category in ICS/SCADA, but it is something I have been thinking about a lot these days. I will keep you posted.

Submitted by Maryna (not verified) on Thu, 2012-06-21 04:07

I am curious whether data confidentiality is less important. I used to believe in that. But in the light the of the recent spying attacks it seems that clear-text protocols is an issue. While observing the traffic (sitting on the fieldbus) an attacker can identify features of the process (PV, OV, SP), all the equipment (type, manufacturer, working mode), architecture (who is talking to whom), etc. With this info the attacker can later design a targeted destructive attack. As you once mentioned, control networks are about ease of production, not ease of security.

Submitted by Jean-Pierre HAUET (not verified) on Wed, 2012-06-20 00:26

Hi Eric,
It seems to me that the lesson 3 is contradictory with the "zones and conduits" paradign developed in ISA99. The definition of security zones is supposed to avoid having to implement a comprehensive protection inside each zone.
How do you reconcile these two approaches ?
Regards

Submitted by Eric Byres on Wed, 2012-06-20 16:23

Hi Jean-Pierre

You bring up a very interesting point. Yet based on my experience, I haven't seen a conflict between Lesson #3: Move Your Perspective from Perimeter-based to Data-centric (Asset-centric for ICS/SCADA) and the "Zones and Conduits" model.

The reason is it hasn't been a problem for me is centered around intention. I believe that the core reasons for using the security zone strategy are to:
a) Avoid the bastion/perimeter strategy that creates a "hard on the outside, soft and chewy in the middle" defence.
b) Formalize a "defence in depth" strategy for control systems.
c) Allow security efforts to be focused where they are most needed.
d) Allow security efforts to be tailored to the capabilities of assets they are protecting.

Perimeter strategies tend to result in monolithic solutions that treat everything inside the perimeter identically. Yet from experience we know that security solutions need to be tailored to match the protected systems. For example, an anti-virus (AV) strategy for HMI computers might be a good solution, but AV just isn't possible for PLCs. Similarly, the protection needed for a PLC managing a wood chip pile, might need to be very different from a PLC running a chlorine system.

So using zones isn't intended to avoid having to implement a comprehensive protection inside each zone, but rather offering the flexibility to fit the protection to match the needs of the assets in the zone. In other words, the Zone and Conduit model lets you move from Perimeter-based strategy to an asset-centric strategy for ICS/SCADA security.

The strategy to focus on the assets that matter is more effective than trying to roll out a "one-size-fits-all" solution for everything inside the perimeter. It also can be a lot more cost effective.

Submitted by Ragnar Schierholz (not verified) on Thu, 2012-06-21 04:51

In addition to what Eric already explained, I would say another reason to use the zones and conduits model is to better support containment of incidents. As we all (should) know, there is no 100% security. So, eventually, there will be some form of a breach. However, if we have a properly designed zoning model and good detection capabilities, we are in a better position to limit the effects of the eventual breach.

Certainly, the zones and conduits model is not to encourage perimeter-only protection schemes.

Add new comment