Why no-one gets SCADA security right

SCADA is an acronym for Supervisory Control and Data Acquisition.  That's a bit of a mouthful and unless you've studied Engineering it's not clear what it means, so here's a simple definition: SCADA is computer controlled physical processes.  The common examples given are power stations and water treatment plants, but it's much more than that.  Building management systems that control the temperature, lights and door locks: that's SCADA.  The production line at a large bakery that makes your bread: that's SCADA.  The baggage system at the airport that loses your bags: that's SCADA.  The traffic lights that annoy you on your drive to work: that's SCADA.

It's everywhere.  It's all around us.  And it's all implemented badly.  Maybe that's too strong - it's all implemented inappropriately for the threat model we have in 2013.

We have to set the way back machine to the 1980s to understand why we are in the mess we are today.

Traditionally SCADA systems were designed around reliability and safety.  Security was not a consideration.  This means that the way the engineers think of security is different.  In IT security we consider Confidentiality first, then Integrity and finally Availability.  This matches with our real world experience of security.  But in SCADA systems it's the other way around - Availability first, then Integrity, and finally Confidentiality a very distant third.

There are two very good reasons for this approach.

Firstly: Keeping SCADA systems running is like balancing a broom stick on your finger - you can do it, but it takes a lot of control, and if you stop thinking about it, the broom stick falls.  This is the fundamental reason that the dramatic scenes where the bad guy blows up a power station as shown in movies just can't happen.  If you mess up the control the power stations stops generating power, it doesn't explode.

Secondly: Every business that controls real world processes has a culture of safety: they have sign boards telling how many days since the last lost time injury, and are proud that the number keeps going up.  Anything that gets in the way of human safety is removed.  That's why control workstations don't have logins or passwords.  If something needs to be done for a safety reason, it can't be delayed by a forgotten password.

All of this made perfect sense in the 1980s when SCADA systems were hard wired analog computers, connected to nothing, staffed by a large number of well-trained engineers, and located in secure facilities at the plant.

That isn't true now.  Today SCADA systems are off-the-shelf IT equipment, connected to corporate networks over third party WAN solutions and sometimes the Internet, staffed by very few over-stressed Engineers, sometimes not located even in the same country.

So what happened in between?  Nothing.  Really.  SCADA systems have an expected life of about 30 years.  The analog computers were replaced by the first general purpose computers in the late 1980s, and they are only now being replaced again with today's technology.  They will be expected to run as deployed all the way to 2040.

I hope you've stocked up on candles.

Phil Kernick Chief Technology Officer
@philkernick www.cqr.com 

Printing to the Internet

You've deployed a brand new networked printer, and after getting it all set up and working, what's the next step?  How about connecting it to the public Internet.  So that anyone, anywhere, at any time can print anything they want and waste all your paper and toner.

Madness you say!  Not it would seem in universities in Taiwan, Korea and Japan.

A little Google hacking and we have 31 internet connected Fuji Xerox printers.  Some of them have public IP addresses, but many of them have been actively published through a NAT firewall.  So this was a conscious choice!

Perhaps it's just a clever way for attackers to exfiltrate data, but I've learned not to attribute to malice that which is better explained by incompetence.

Here's my advice: If you want to print to a work printer from home, this is not the way to do it.

Phil Kernick Chief Technology Officer
@philkernick www.cqr.com 

Information Security Themes for 2013

Everyone else is making predictions as to what will be the important information security trends in 2013.  I think they are all wrong.  Not because the writers are uninformed, just because they are unimaginative.  It’s easy to look to the past, draw a line through the dots, scale it up and to the right, and predict the future.  Except these sort of predictions are safe, boring and they never allow for disruptive events.

Here are a few of the safe predictions that others have made:

·         mobile malware will increase

·         state sponsored attacks will increase

·         malware will get smarter

·         hactivists will get smarter

·         IPv6 security will matter

I agree with all of them, but then who wouldn’t.  Up and to the right.  And nearly everyone making these predictions sells something to mitigate them.

So what do I think the themes for 2013 will be?  I have only one information security theme that I think really matters.  Only one theme that will confound the industry, and add to the number of grey hairs sported by CIOs.  Only one theme we cannot avoid, even though we are really trying to do so.

Authentication.

Everything else pales in comparison.  It really is back to basics.  2012 was the year that we saw more password dumps than ever before.  It was the year the hash-smashing as a service became mainstream, and not just performed by spooky government agencies.  It was the year that we saw a mobile version of the Zeus crime-ware toolkit to attack SMS two factor authentication.  It was the year logging into sites via Facebook became the norm, and not the exception.

And these are all symptoms of an underlying problem.  Passwords suck.  Passphrases are just long passwords, and they also suck.  Every two factor scheme out there really sucks – mostly because I have so many different tokens that I have to carry around depending on what I want access to.

The problem is that we are tied into the past: something you know, something you have, something you are.  We spend more and more time trying to prove these to so many disparate systems that the utility of the systems asymptotes to zero.

So instead of looking back we need to look forward: somewhere I am, something I do, something I use.

Instead of trying to authenticate the user, we need to instead authenticate the transaction.  And that is a hard problem that our backward looking way of thinking makes even more difficult to address.  Happy 2013.

Phil Kernick Chief Technology Officer
@philkernick www.cqr.com