lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <000301c3680f$55a28be0$2b02a8c0@dcopley>
From: dcopley at eeye.com (Drew Copley)
Subject: SCADA providers say security not our problem

Excellent post, thanks for sharing the info.

> -----Original Message-----
> From: full-disclosure-admin@...ts.netsys.com 
> [mailto:full-disclosure-admin@...ts.netsys.com] On Behalf Of 
> Michael Scheidell
> Sent: Wednesday, August 20, 2003 7:41 PM
> To: full-disclosure@...ts.netsys.com; intrusions@...idents.org
> Cc: snpmarq@...uritynewsportal.com; 
> bugtraq@...urityfocus.com; Content@...oolboom
> Subject: [Full-Disclosure] SCADA providers say security not 
> our problem
> 
> 
> The Factory automation and SCADA systems providers have not 
> shown much willingness to take any responsibility for the use 
> (or misuse) of their systems, having washed their hands of 
> the security and stability functions once the system is 
> declared 'on line', saying that the security of their systems 
> in ow in the hands of the end-user.
> 
> This attitude amoung major manufactures of FA and SCADA 
> systems has in the past lead to break downs ("see Ohio Power 
> plant shut down by slammer worm" 
> http://www.security-focus.com/news/6767 ) 
> 
> I have contacts in the FA/SCADA field, having run the worlds 
> largest distributor of QNX (an RTOS used by FA/SCADA systems) 
> and having been the Director of Business Development for 
> VenturCom (they have a product called 'RTX' which is an RTOS 
> kernel for Windows, and they 'invented' embedded
> NT) 
> 
> During my years in both companies I have seen how and what 
> Windows can be used for (and what its forced to do) and I can 
> tell you by experience that while DCOM on NT may not be used 
> directly for real time control functions, it is in fact used 
> to do supervisory and monitoring ('traffic cop') type functions. 
> 
> Originally, FA and SCADA systems ran on proprietary backbones 
> like the Allen-Bradley links, 4 wire control and signaling systems.
> 
> With the advent of 10/100 and 1GB switched networking, many 
> control systems are now using ethernet for control.  Its 
> cheaper to install and maintain and comes with it the promise 
> of direct backoffice and manufacturing systems integration. 
> 
> However, with the combination of COTS (commercial off the 
> Shelf) systems like Windows, and transports like ethernet, 
> many once isolated FA systems are now combined, integrated, 
> reachable (and hackable) via administrative networks that 
> themselves have full internet access.
> 
> Should the installers and manufacturers of these systems make 
> sure they are compatible with current service packs and 
> patches?  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? 
> What about their promise of integration? integrated back 
> office and manufacturing functions?  How will they do that 
> without direct links? 
> 
> Should the purchaser of these systems be required, or even 
> permitted to upgrade an patch these systems? 
> 
> Who is responsible for damages if (and when) these 
> unprotected systems get hacked? 
> 
> 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? 
> 
> What do you think of this response by a major manufacturer of 
> SCADA systems?  Is it up to the end customer to keep these 
> systems isolated? 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? And how reasonable is that 
> in light of recent revelations of failures at that above 
> mentioned Ohio power plant?
> 
> "   But it is impossible for us to keep our SCADA systems 
> secure.  Once we
>     get a version out there, and it is installed performing 
> some function
>     like power plant automation, customers don't mess with 
> it.  They only use
>     it.
> 
>     It will become vulnerable over time due to stagnant 
> technology.  Our
>     focus, and your focus, needs to be on secure access to 
> it.  Not making
>     the product itself bullet proof.
> 
>     Interesting questions about the liability.  Contracts 
> would need to
>     be structured to highlight Best Efforts on security, not 
> perfection.  The
>     bottom line is that a service provider will give you more security
>     because they live it and it is their focus."
> 
> What is your opinion? what you you tell your HIPAA, or SEC 
> regulated company if their vendors refused to take 
> responsibility or even washed their hands once the system is 
> installed?
> 
> --
> 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/
> 
> 
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
> 


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ