Message-ID: <BMEKJADHPBMICEOGNHNICEPOEFAA.shoffman@computer.org>
Date: Mon, 25 Aug 2003 17:40:09 -0500
From: "Stan Hoffman" <shoffman@...puter.org>
To: <snpmarq@...uritynewsportal.com>, <bugtraq@...urityfocus.com>,
   <Content@...idents.org>
Cc: <full-disclosure@...ts.netsys.com>
Subject: FW: SCADA providers say security not our problem




-----Original Message-----
From: Stan Hoffman [mailto:shoffman@...puter.org]
Sent: Monday, August 25, 2003 5:37 PM
To: Intrusions
Subject: RE: SCADA providers say security not our problem


Having spent many years in the industrial automation field, I'll throw in my
$0.02.

> -----Original Message-----
> From: scheidel@...nap.net [mailto:scheidel@...nap.net]On Behalf Of
> Michael Scheidell
> Sent: Wednesday, August 20, 2003 9:41 PM
> To: full-disclosure@...ts.netsys.com; intrusions@...idents.org
> Cc: snpmarq@...uritynewsportal.com; bugtraq@...urityfocus.com;
> Content@...idents.org
> Subject: SCADA providers say security not our problem
>
>

 <snip>

>
> Should the installers and manufacturers of these systems make sure they
> are compatible with current service packs and patches?
This is not a regulatory issue.  This is a business issue.  Current software
from third-party(Non-OS vendor) sources is in the exact same position.  It
is the end-user's responsibility to regression test in a lab simulating the
ACTUAL live operating environment, including other 3rd party software.  If I
am dealing with a vendor that is consistently incompatible with a properly
secured buildout, I can vote with my dollars and look elsewhere.  However,
it is often more cost-effective to mitigate the vulnerabilities in other
ways, than to change out systems.

>Should they warn
> their clients that under no circumstances should these systems ever be
> linked, cross linked, even thorough a firewall to the corporate network?

No, why should they?  That would be trying to fit every possible use-case
scenario into an single, "can't possibly be secured" box.  That is very far
from the reality.  Security is not a thing. It is a complex process.  If I
can acheive an acceptable level of risk by utilizing a given method of
connecting my systems, why shouldn't I do it?  The key is making an informed
decision, not a frightened one.


> What about their promise of integration? integrated back office and
> manufacturing functions?  How will they do that without direct links?

N-Tier architecture comes to mind.  Not to mention proxied services and
connectors.  And, that is assuming that these are necessary in every case,
which they would not be.

> Should the purchaser of these systems be required, or even permitted to
> upgrade an patch these systems?

Of course.  The security and stability of my systems is my responsibility.
If I feel that I must remediate a system that is proprietary, then I take
that up with the vendor.  Just like with my Nokia/Checkpoint firewall and
Cisco routers.  This model is already in play.

> Who is responsible for damages if (and when) these unprotected systems get
> hacked?

Legally, according to the EULA that the user accepts, the end user is
responsible.  The same as with Microsoft, Cisco, Sun, and every other vendor
in the US.  The final responsibility for security is mine. So, why should I
try to shift the liability?  If I have issues with the product, I'll buy
someone else's.

> If a SCADA manufacturing company installs a (currently patched, reasonable
> secure) system in a health care or medical manufacturing company, and
> integrated back office functions include patient data, who is going to pay
> the HIPAA fines _WHEN_ that system gets hacked by a multi-mode worm?  Once
> that gets in via email on the administrative side, or is brought in via
> the vendor themselves during installation and testing functions?

How many SCADA systems handle PHI?  That aside, security is still the
responsibility of the Site Admin.

> What do you think of this response by a major manufacturer of SCADA
> systems?

Sounds like the old Microsoft line Circa Pre-2000.

> Is it up to the end customer to keep these systems isolated?

If necessary, Yes.

>And
> if so, should these companies stop pushing the ease of integration and
> integrated back office functions and just admit that there can be no
> connectivity between your internet accessible administrative network and
> the critical manufacturing system?

You mean like Office 2000 and MSDE integration?  That is marketing.  If
someon lets marketing hype guide their technical decisions, then their
issues are much larger than SCADA insecurity.

>And how reasonable is that in light of
> recent revelations of failures at that above mentioned Ohio power plant?

That was a failure in policy and enforcement.  Just like most security
breaches,  It didn't require anything more than that to occur.  The fact
that a SCADA system was impacted underscores the need for an improved policy
and enforcement regimen.  After all, if they let some one plant a pound of
C-4 on the PLC and detonate it, would that justify requiring the vendor to
make the system bomb-proof?  Of course not.

<snip>
>
> --
> Michael Scheidell, CEO
> SECNAP Network Security
> Main: 561-368-9561 / www.secnap.net
> Looking for a career in Internet security?
> http://www.secnap.net/employment/
>

Vendors being held responsible for system security and integrity....  Sure
would make my life easier <grin>

Regards, to all,

Stan Hoffman
CISSP,IAM,GCIA,CCNP,
CWSP,MCSE,CCSE, Security+
PM Consulting
Manvel, TX
shoffman@...puter.org



_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Powered by blists - more mailing lists