Computer Virus in Electric Utility in Australia

M

Matt Warshawsky

OK, here is an idea to solve the problem: instead of connecting the business network and the control network over Ethernet, use a serial connection to pass the data. The control network remains standalone with no outside contact except for the serial connection. What virus or worm could possibly transmit across a serial connection? It'd have to be pretty targeted. A denial of service attack would have no effect. If the business network went down, the control network would simply be unable to get the business data, but otherwise would be unaffected.

Thoughts?
 
A

Andrey Romanenko

>OK, here is an idea to solve the problem: instead of connecting the business network and the control network ....

[]

No, this is not sufficient. Just run PPP or good old SLIP protocol on the serial wire, run TCPIP over that and open up DCOM and the virus will be able to crawl in. Another example is that you cannot avoid viruses switching from Ethernet to wifi or fiber optic or Arcnet. What is important is what protocol you run over the physical medium and how much of the system you have to expose to use it.

In that respect, as simple protocol like Modbus RTU or ASCII may work better on a serial cable. Probably it is still possible to carry out stack smashing via badly formatted packets but good software should have relevant checks. In any case, the consequences are far from those of a virus attack as there will be no propagation.

I have heard some plant DCS have one-way links to the outside through a few digital outputs. You can also cut off TXD on one end of the serial cable and only send data, but then you will not be able to run Modbus or any other handshake requiring protocol (not even Modbus).

Best Regards,
Andrey Romanenko
Ciengis - Advanced Process Control and Optimization
 
Michael,

I think that I am more or less in agreement with your sentiment. The problem I have is that in my experience which is mostly with large operating sites the customer has to retain the responsibility for security because:

- The customer is the organisation that accepts the risk of bad things happening and receives the benefit of good things. Therefore decisions regarding risk must come from here.
- There are many different systems involved when integrating SCADA/DCS to business systems from different vendors. Each vendor cannot know everything and so there must be some coordinating party. For many reasons the customer is best placed to do this e.g. they define requirements, confidentiality. I don't think any vendor will ever supply the whole suite of applications a large business requires.

From the little dealings I've had with pure IT people this applies to business systems also.

Most large vendors that I have come across will not walk away unless you tell them to, as you said, in fact some will oversell their expertise given the chance. That said the way maintenance is done varies. Some users do it themselves others use support contracts with the vendor. It is not always visible to those that make the decision (who/how much) what the implications are even if the systems are making the money - which they are.

Some of the SCADA package vendors and PLC manufacturers have been slower on the uptake on the security issue. I think they'll some round in the end. I agree that they have to take a wider view in order to improve the state of things and to continue to work on the issue - or start - in conjunction with their customers.

Interesting debate!

DaveMH
 
In reply to Matt Warshawsky: I don't think we need to go to the lengths of installing serial connections to avoid this problem. If we look at the Australian incident, we see that the control systems which were running Solaris (a brand of Unix) were not themselves infected by the virus. It was the operator terminals which were using MS Windows to run X-terminal software which were affected.

In one of the news reports cited by another poster, the company regained control of their system by bringing over some computers from their software developers that used Linux (which was also immune to the viruses). That wouldn't have been a "million dollar security strategy". That would have been *cheaper* than the insecure method they had been using.

When we are talking about viruses, we need to be clear that this is a software problem with MS Windows. It isn't a problem that is inherent to "PCs" (however much Apple might like to equate the two).

To cover this topic completely would take more than I could possibly cover here. I'll take your example of the serial connection however.

If you simply passed through all the messages (TCP over RS-232), you would have limited the rate at which data could be transferred, but that wouldn't actually stop a virus. What you would need to do is to decide to only allow certain specific data to pass between the two systems and to provide an application program which does that task only.

As an example, have a computer with two network cards. One network card connects to the business network, while the other connects to the control network. Install an OS that isn't affect by viruses (Solaris, Linux, BSD, etc.).

Next, find or write a program that acts as a proxy between the two systems. On the business side it provides a web service protocol that the ERP and reporting systems can poll to read or write certain defined values (production quantities, part numbers, reject rates, cycle times, etc.).

On the control side it would offer a common industrial protocol to talk to the control devices. It could do this as a server, in which case the polling rate would be dictated by the control devices. It could do this as a client, in which case the polling rates and target clients would be scanned at a fixed rate determined in a configuration.

Both sides of this transaction would store their data in a common data table. That would decouple the scanning rates from any events happening on either side.

Now that is a fairly simple solution, and it has a lot of advantages besides just security. For example, it decouples the ERP and reporting systems from the individual controls, so you can make major changes to the controls without involving other departments.

So, there are a lot of solutions to these types of problems. I don't think the traditional ostrich approach (install anti-virus and pray) however is a good one.
 
M

Matt Warshawsky

It was never my intention to simply pass the same traffic over serial, but instead to use a simple protocol like Modbus. As mentioned, there needs to be decoupling and by using serial instead of TCP in addition to protocol decoupling, you ensure that the OS or other software doesn't, without your knowledge, start using the transport layer (serial) to do things it shouldn't. With two ethernet cards and software you could decouple in software, but I'd be worried that the OS would use the second cards to pass traffic without my knowledge.

As for other OS's not having virus, that is not really correct. Any OS is subject to viruses, windows just happens be have the most by a rather large margin. This is partially because its the most used OS, especially by end-users who don't know better. Some may argue also that its because the OS itself isn't as secure (probably because it does too much).

And while other OS's may be more secure, they also require a fair bit more expertise to install, or at least less commonly available expertise. Windows systems are very easy to install and so while the licensing costs may be higher than an open source linux install, the installation and maintenance costs are likely much lower. I am not saying I'm a big lover of Windows, but most of the companies I work with are much smaller than this company we keep referencing and can't always afford to have the expertise to maintain these other OS's on staff or retainer.

I suppose to some extent we are going around in circles. There really is no one solution for this problem and each installation must be evaluated separately based on needs, risk, and budget. But as said, in all instances we can't just stick our heads in the sand and rely on antivirus to save us.
 
C
One of the better solutions for this connection from an automation network to a business network might be a dual homed PC with transfer between networks OOB (out of band) and no routing. If the transfer were restricted to only the data of interest, it should be fairly safe. Of course, it would need to be on a machine running an OS that is secure or obscure. Running it on Windows would accomplish nothing. But having the transfer occult to a virus writer should protect the automation network. If this sounds like a gateway, it is not. The purpose is to completely isolate the networks from each other except for a non network pass through.

Regards
cww
 
C
I just posted much the same thought. But the connection doesn't have to be serial. Anything unique enough to be outside the malware's scope would work. Shared memory would be network fast and flexible. And since the generic worm or virus would "know" nothing about it, it would be secure. The whole problem is using well known, insecure methods and software.

Regards
cww
 
In reply to Matt Warshawsky: I don't want to flog this issue to death, but there are a couple of points you brought up that I want to address.

First, you said: "As for other OS's not having virus, that is not really correct. Any OS is subject to viruses ..."

Yes, in theory viruses could affect any programmable device. The engine controller in your car could in theory get a virus. A PLC could in theory get a virus. But I like to be a practical sort of guy. Let's look at what viruses are *actually* affecting, not what hypothetically could happen. When we're talking about viruses, we're talking about Microsoft Windows.

If you are using Solaris (as in Australia) or Linux, or BSD, you're not going to get a virus because there aren't any that run on those operating systems. Most high volume servers that are connected to the Internet today use one of those operating systems, so it hasn't been for lack of opportunity. There aren't any viruses for them now and that probably isn't going to change any time in the near future either.

As for ease of installation, with a typical desktop Linux distro, you stick a disk in the computer, answer a few questions, (what time zone are you in, what password do you want to use, etc.), and then walk away. 20 minutes later you come back and it's done, including having installed all your application software at the same time.

I don't see why SCADA vendors can't do the same. Since the OS and application software would all be set up together as part of one process they could set things to whatever reasonable security defaults they recommend. It's for ease of use reasons that I think they should do this. If you are counting on every SCADA user to figure out security for themselves, it simply isn't going to happen. If there's a reason the vendors don't do something like this, it's a business reason, not a technical one.
 
In reply to curt wuollet: Most of the rationals for connecting business and control networks seems to revolve around production reporting. In this case it probably makes a lot of sense to either have the "bridge" computer do the production reports itself, or to provide a web service protocol to whatever business systems want to talk to it.

That lets you control which data is writable by the business systems. As well as virus security, you don't have to worry about some nitwit in the ERP department writing over PLC addresses that he wasn't supposed to touch.
 
C
Yes, the complete package idea is an extremely powerful idea. Imagine how much you could cut your support costs if every customer at least started with the same configuration. Same OS, same version, no SP this or that. Half the questions on here seem to be how do I get this to work with that. Easy to do, as this is the norm for Linux distributions, they come up with the applications installed. And for the user, it would be even easier than having a good installer, your app would just be there and work. No DLL hell, no virii, no incompatibility. And no obsolescence, you can use the same set up as long as you like. Or you can attempt to handle the Windows chaos and churn. Hard to understand why vendors want to do that.

Regards,
cww
 
C
Yes, but in any case, all they could trash was the "office" side with good coding. In most cases you could make it one way so it's read only.

Regards,
cww
 
Y
How about this design?

All terminals and servers on the SCADA network runs Linux, with operator terminals as touch screen kiosks. A few admin terminals and development terminals in this network should be allowed to have normal PC environment (no windows, all linux) but controlled under strict security policies and operated by knowledgeable staff only.

Business network is the usual collection of Windows desktops and Windows/Linux servers. Should be operated under security policies also, but not trusted. Connection to Internet is allowed.

A PC running linux having two network cards is connected to both networks. All bridging is STOPPED. The networks cannot see one another. This pc runs a webserver, and all other network access from the business side is blocked. No files will be exchanged. Only webservice request/responses will be allowed.

I don't see any threat from the business side reaching the SCADA. Corrupting the operator kiosks is prevented by refusing physical access to the system box.
 
In reply to Yeasir Rahul: That would work, and it would have prevented the virus problem the company in Australia had.
 
Top