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-next>] [day] [month] [year] [list]
From: scheidell at secnap.net (Michael Scheidell)
Subject: 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/


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ