Why traditional approaches for securing Industrial Control Systems Fail

Friday, November 09, 2012

Mikko Jakonen


I recently visited a workshop delivering a crash course for ICS security. Most of all, the theme is such important and accurate at the moment. Actually, it has been over years already. We all know WHY the topic is center of such interest at the moment, so I do not need to touch that particulary n depth any more. Funny thing is that while the 'phenomenon' exist since beginning of industry automation, only malware - just a targeted binary with some deception capabilities revealed the ugly truth - or did it?

But what makes the topic interesting in addition of it is target for cyber warfare is how the situation has evolved to this point and why I believe that models imported from information security management models mostly may fail on securing ICS, as it has been the way to do it.

There are not too many technical articles describing in-depth the security theory and practice behind of ICS / SCADA environments and I am not creating one here either.

Well - what is WRONG?

'Many' - for lack of better word. I'll demonstrate few things revealing how the approach typically set in place for securing Industrial Control Systems fails and what should be taking into account.

The fact with ICS, SCADA - the whole ensemble including field bus technologies existing is that the security controls, protocols and understanding is very low. That is by design, not by accident. Though, I do have to tell my own opinion which is industry has been a bit ignorant to adopt some good security models derived from the 'office world'.

The one principle which drives ICS is 'keep it running', availability over anything. Very little for the resilience is still allowed in long run, so industry is sticking on the 'fortify' theme with the allowed, narrow down capabilities.

Lets review the 'standard model' quickly: We have security policy agreed and supported by the management, then we have security controls established within the environment followed by FERC or any other reference model adapting ISO27001 and bought necessary technology to deploy them. OK, what then?

Security policy established says that co-operation body (engineering company et al) must maintain their security well and there are sanctions in place their screw up with it. Luckily, our partner is doing such an excellent job with their compliance on security that they do maintain their security by applying patches, training people and by
utilizing novel VPN and such techniques to protect customer assets.

So our imaginary use-case follows pretty much standard line: We have environment, there is multiple instances of organizations maintaining ICS -some of them doing it remotely, some of them doing it on site with their own gadgets, followed by our security policy.

To understand the issue correctly, let's just review the policy again - what is it: The policy is actually an undersigned paper of common understanding agreed to work under criterium established and management by co-operation body to secure our assets. Right? It is: NOTHING MORE.

See where this follows? I am NOT saying that security policy is NOT needed, I am saying it is irrelevant by the view of the malicious adversary trying to gain the access on the environment. The only thing that may repel such actor is technical controls established. And here is the catch: Technical controls SHALL require novel approaches which for example FERC or any other suitable reference model DOES NOT require nor import.

Ok - so security policy is by view of 'adversary' just agreement for proxy to maintain their environment. The maintenance of such environment does not necessary mean anything either. Imagine engineering company with multitude of large customers and very little amount of administrative resources. They do use SSL VPNs, possible a HDD crypto too and patching, but they lack understanding how their environment may be utilized to gian access towards the objective, ICS environment managing potentially interesting national target.

Yes, someone could say - that's why you need the policy to make sure engineering company is adopting security on required level. No, does not help either. Just a piece of paper again. Lack on KNOWLEDGE is still the issue and the FACT engineering company is bound to technical rules existing in ICS world. There is very little security controls existing on that world. Following a strict guideline surely helps to maintain the environment, but don't count on that ADVERSARY is doing same way.

The controls. Controls may help if established, managed and maintained correctly. Just remember that the rules exists. Only way your are able to succeed here is simply 'do not trust your partners' - even the policy exits. It does not guarantee your site is up in the morning and delivering comfort for the citizens.

I believe it is relatively easy to adopt some details from nuclear safety for the not 'nuclear world'. Yes, you've got it correctly - there are some principles that may save yours and your customers, ordinary Joe's day.

One of the principles is defense in depth. This is not a new thing, but what it means here while established correctly? It means you must deploy such controls in end-to-end manner, all the way the service architecture flows. Correct: Engineer maintaining the environment IS utilizing end2end service architecture.

Second thing to adapt is principle of 'differential safety' or so. What I mean is that applying a different grid of security measures to protect another security controls vulnerabilities should exist. A different technology.

Third thing to obey: Parallelism. While I promised to NOT come back for our beloved 'Stux', the way it would have been potentially- be early noticed is to have separate control system in parallel for the one running production. Parallelism, having security technology and controls in parallel to verify each other could save the date.

Utilizing novel approaches, such as white listing and even more cooler encryption within the environment to secure only needed 'heap' is executed supports this all. I believe there is article in my blog detailing such, here: http://mikk0j.wordpress.com/2012/10/02/legitimate-thought-for-securing-restricted-environments-of-usb-carry-in-threats/

Just remember that discipline in controls is the beginning for good operational security. Including good command of SOPs telling what is possible and what is not.

So to conclude: Criminals or 'adversaries' do not care your papers. Period. Only skilled set of controls, amount of wisdom, sneakiness to intel security posture like them and discipline in management secures the environment. They will utilize every mean to gain access your beloved environment, making scenarios, playing with STRIDE - YOU should too!

Maybe it would be wise to begin establishing security from the bottom this time. What is really needed? Understand the environment. What is really achievable and how to implement such controls in place --> leading ultimately to the question what technology I need here. Then define the policy according the capabilities existing in the environment, not traditionally say 'we have defined it SHOULD be like this', yeah...right.

General General SCADA Enterprise Security General Impersonation Breaches
Post Rating I Like this!
C Meyer Note to Author: Watch the grammar!
Mikko Jakonen Granted. From 'C Meyer' I would accept also ideas regarding the topic itself.
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.