-----Original Message----- From: Stan Hoffman [mailto:shoffmanat_private] 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: scheidelat_private [mailto:scheidelat_private]On Behalf Of > Michael Scheidell > Sent: Wednesday, August 20, 2003 9:41 PM > To: full-disclosureat_private; intrusionsat_private > Cc: snpmarqat_private; bugtraqat_private; > Contentat_private > 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 shoffmanat_private _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
This archive was generated by hypermail 2b30 : Mon Aug 25 2003 - 16:44:23 PDT