Message-ID: <3F44F6F9.21874.1D2D223@localhost>
From: cta at hcsin.net (Bernie, CTA)
Subject: SCADA providers say security not our problem

Right on target Michael, and exactly the point most of us in 
this and related threads have pivoted from. The Blackout was the 
result of poor or nonexistent system security engineering, 
implementation, and auditing. 

We may be able to accept that the initial trigger incident that 
caused the Blackout may have very well been a broken 
transmission line and the subsequent loss of a generation plant. 
However, such an incident should have been autonomously 
identified and protection measures taken to instantaneously and 
autonomously compensate by either shutting down supply to local 
sub-stations or cities "loads", and/or shifting the load toward 
other generation power sources. Consequently, it appears that 
the trigger incident, as well as the status of operating 
parameters went unnoticed, and/or the safeguard failed to 
respond to abate the surge from cascading. 

One could only deduce that certain monitoring systems and 
devices within the Power Utilities / Sub Stations / Grids 
protection system topology were either offline (why? Blaster, 
Slammer, etc?), compromised by Blaster, Slammer, etc, or 
otherwise operationally infective in safeguarding the 
infrastructure do to the poorly throughout design and 
implementation of the security topology. 

I believe that like the HIPAA Security rules, regulations should 
be established to set Security standards which the Power 
Utilities, as well as and Gas, Water should be held to comply 
with. This is critical infrastructure not. Of course, such 
standards and regulations should include all covered-entities, 
(just like HIPAA), meaning software and hardware vendors.  It 
time to produce secure software and hardware, and yes get paid 
for it.

I can recall back in the late 70s designing the kernel for a 
microprocessor controlled baby incubator. (I think it was 8080A 
based) One of the TOP design requirements of the safeguard 
subsystem was to prevent any potential failure from accidentally 
frying its occupants. This requirement became not only a 
critical design objective but also a condition of testing and an 
element of final QC. 

We designed and wrote our programs, in assembly, with this 
requirement, as well as others less critical to the maintenance 
of the health and safety of the baby, as a test condition for 
every functional operation. If the software's function, process, 
or resulting action failed, or system component failed, to 
satisfy this safety condition, then it was back to redesign. 
Ultimately, the security (e.g. analysis of and response to: 
Threats, Vulnerabilities, Unexpected, Unauthorized or Illegal 
Actions) of this critical care system was paramount, and all 
engineers, programmers, technicians, assemblers, QC, as well as 
executives were held accountable. 

The same system security engineering practice should be applied 
to the design and implementation of our Nations / Worlds 
critical infrastructure, requiring 100% compliance or no go. 

Yes, such a pragmatic system security approach will cost more 
money. Hell, with such design constraints I wouldn't lift a 
finger to design a circuit or program one line of code unless I 
was well paid. Nonetheless, it must be done. 
Needless to say, I would not be the least surprised if the 
Utilities involved soon offer up a fall guy/gal to take the heat 
and spotlight off of them, as they do not want the public to 
know of the security inadequacies, or more regulations 
controlling there cash flow. 


On 20 Aug 2003 at 22:41, Michael Scheidell wrote:

> 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?
> 

-
-
****************************************************
Bernie 
Chief Technology Architect
Chief Security Officer
cta@...in.net
Euclidean Systems, Inc.
*******************************************************
// "There is no expedient to which a man will not go 
//    to avoid the pure labor of honest thinking."   
//     Honest thought, the real business capital.    
//      Observe> Think> Plan> Think> Do> Think>      
*******************************************************

Powered by blists - more mailing lists