Second Crack at SCADA Issues
I must confess that when I first heard about SCADA-related security issues, the first thing that came to my mind was some of the hype about the Millenium bug. It just seemed a bit too convenient that the people highlighting the issues were the people selling solutions to combat it. (SCADA refers to Supervisory Control and Data Acquisition, proprietary computer control networks used in a lot of industry, such as utilities and chemical plants, etc., etc.)
But Y2K was not all smoke, of course. In addition to providing a key trigger for the Indian consultancies, it prompted a lot of thinking about IT security, and some of it is relevant to SCADA. And we need to take this to the next level of depth.
If you saw Bruce Willis in Die Hard 4.0, you saw the bad guys hijack a lot of SCADA networks in order to generate pyrotechnics and chances for the hero to get out of DC. My understanding is that this is not at all realistic (What? A Hollywood action movie not realistic?) But we need to have this vetted.
My preliminary understanding of this is that security was not built into them when they were implemented and that organisations have been slow to build them in after the fact. As some of the functionality of SCADA networks migrated onto WANS and the Internet, network owners did not build in normal security protocols to protect from snooping, hacking and the same viruses and worms that bedevil all Internet users.
How correct is this preliminary understanding?
My casual reading of the literature suggests that precautions have been advised since 1999, that groups exist to highlight best practice and stimulate awareness of SCADA security issues, and that the problem is not so dire as to require the services of balding Yank action heroes.
Am I living in a dream world? Digital Bond, a security consultancy, would probably have you think so. This article in the August 22 issue of Forbes, the American business magazine, also expresses a level of concern that goes far beyond my preliminary assessment, talking about a successful penetration of a nuclear power plant’s SCADA network. IT Security expert Bruce Schneier wrote that he didn’t think SCADA was as much of a problem now as it would be in future, but in the same blog post he linked to a March 2007 story that detailed a serious hole found in the U.S. national infrastructure. I read this shortly after I blithely wrote on the Blindside wiki that I thought the maximum impact from SCADA issues was in the present, while solutions were being developed but adopted unevenly.
So which is it? Am I living in a dream world and ignoring a serious threat? Is SCADA security being over-egged by security vendors? Is the problem going to get worse?
We could use a little help on this one, folks.
August 28th, 2007 at 9:08 am
I think that as far as possible, these systems should simply be air-gapped from WANs and most especially the Internet.
August 28th, 2007 at 5:39 pm
Yes - the Forbes article is pretty scary reading.
wg
September 7th, 2007 at 12:00 pm
I have looked at the security of a number of large scale SCADA and some CNI SCADA. Here are the problems that come to mind immediately.
The PLCs are very low powered (in computing terms) devices which has led to highly efficient but low security code being developed. Also makes deploying network level encryption very hard.
PLCs have system lifecycles of up to 25 years meaning noone is getting replacements any time soon.
To patch a PLC for many of them requires physicaly visiting them and replacing the firmware with custom written code over a serial link, not feasible in estates with 10s of thousands of PLCs across large campuses or distributed around the country.
The PLCs were originally serial, the move to Ethernet (Or a variant of) generally meant wrapping a serial protocol up in an ethernet frame. The move to IP has meant wrapping those up again in an IP packet. No consideration was given in the protocol design to the threats in an IP environment.
There are no good security testing tools for the legacy SCADA protocols in the public domain. I know some end users are scanning PLCs with standard IT vulnerability scanners like nessus and assuming that tells them something about the state of their systems. We need ModBus network fuzzers and the like. These already exist in private.
Those PLCs that have had IP stacks and web servers added are generally used for monitoring rather than control (although this is changing). In general there is a good bet that the custom IP stack will have a flaw allowing at a minimum for denial of service and the web server will be using vanilla HTTP without authentication.
Somewhere along the line the SCADA industry decided to standardise on Microsoft DCOM as the transport for their interoperable control protocol OPC. Anyone from the more technical end of security would know thats like building a malaria hospital in a swamp. Just look at the number of OPC tunneling products that have been created to get OPC past corporate firewalls or the fact that the complexity of getting DCOM based authentication working across different domains/ADs means most deployments allow anonymous or unauthenticated access for simplicity. Then look at the number of DCOM vulnerabilities found in the early 2000s and remember the OPC clients/servers haven’t had that level of scrutiny applied yet.
There are plenty of other problems but imagine the SCADA/PLC world is where the Internet was 10 years ago, many the same sorts of problems will be found and need to be fixed and at the moment there is no way to deploy those fixes or a way to deploy new versions with the built in as part of the system refresh cycle.
September 7th, 2007 at 12:42 pm
Well, Phil, considering this is exactly what I hoped someone would do, how do I thank you? Well done. Wait–I know! Would you please know do this for every post I have ever written? (I could give you URLs of other blogs in addition to this one.) You’ve set the standard.