Re: SCADA

Daniel E. Hassler wrote:
> Forgive my ignorance but why is SCADA even allowed to run on a Windows 
> host?

Windows is just fine!!

Production Systems 101:
	Step 1: Set it up
	Step 2: Make it work
	Step 3: Leave it alone
	If it breaks, figure out what went wrong
		fix it, then go to step #3

There's nothing wrong with Windows at Steps #1 and #2. The
problem comes along in #3 - "leave it alone" does not include
"make it internet-accessible so that every hacker who can send
it a packet is able to mess with it" or "patch it every tuesday"
If all you wanted to do with a Windows system was have it
sit there and monitor a serial port connected to a widgiframus
and beep if the value sent over the port goes to high - Windows
is great for that. If you want it to sit there and be connected
to the Internet and ALSO monitor the serial port connected to
the widgiframus - then it's maybe not so good.

The problem in a nutshell is that systems were implmented in a
way that was OK for one objective (monitor the serial port on
the widgiframus) and it was automatically assumed that the
system was therefore OK for another objective (resist hackers
on the Internet)  Perhaps it is, perhaps it isn't!! Where we
all get stuck is when managers or whoever skip the part where
they are supposed to ask that question.

I know this is a ridiculous example but it's kind of like
concluding that, because a condom was successful (so far!)
at preventing one from getting STDs that it'd also make a
decent parachute.

There are a few of us grognards who like to point out - rightly,
I think, that there are huge swaths of the Internet that
have this problem: things worked fine for a simple job, but
they're not good enough to do the big job. But they're being
pressed into service because, well, they are. And it's resulting
in a situation where we move farther and farther from the
design and safety properties that we originally established.

With SCADA systems I've seen this a couple of times, in the
last 5 years. One organization had a perfectly reasonable
backend system to control a very complex and expensive
printing press system. It worked fine. The security
"architecture" (such as it was) was "everything is on a
private isolated LAN so security is not a problem." And
that's a perfectly valid and reasonable design. It's easy
to get right. But then the client decided to add a
wireless access point. And, then they decided to let their
customers hook the LAN to internal networks so that
diagnostic service guys could remotely access the systems
and check the printer's state over the Internet.  Suddenly
the design "everything is on a private isolated LAN so security
is not a problem" no longer applied. I'm sure that all
of the more seasoned veterans on this list have seen this
scenario, with slightly different details.

The point is that:
Initially Windows was just fine
Now it's not
But it's still in place

So, eventually something will go horribly wrong and everyone
will run around going "OMG! How did this happen!?!"  As I
pointed out in my security disasters paper, the disaster
happened when the security model of "isolated LAN" changed
to "something other than isolated LAN" and the other
underlying assumptions were not reviewed.


mjr.
-- 
Marcus J. Ranum		CSO, Tenable Network Security, Inc.
			http://www.tenablesecurity.com