Re: SCADA

OK - I expected this. As I stated I was/am not trolling. Heck - check 
the email headers - This noise is coming from Thunderbird on a WinXP Pro 
system. I don't expect this system is secure even with two different 
firewalls and an AV software product installed. Marcus - I've really 
enjoy your works/writings/postings and sincerely did not mean any 
offense.  I've read over and over about SCADA security issues but find 
practically nothing on the market to effectively address them. We can 
write a lot on the Firewall Wizards list about the woes of mixing 
today's connected business needs with yesterdays isolation is a form of 
security. My basic question is why aren't those who have a clue creating 
solutions to meet the business needs?  This is where I think our time is 
better spent (and the.the $$$ are). If I can rephrase my original 
question it would be more like: "I think we can do better, If we build 
it will they come?"

Thanks,

Dan Hassler

Marcus J. Ranum wrote:
> 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.