RE: [sc] SCADA Holes Allowed Remote Takedown of Siemens Systems



RE: [sc] SCADA Holes Allowed Remote Takedown of Siemens Systems

From: Royalty, Chuck <chuck.royalty_at_xxxxxx>
Date: Wed, 8 Jun 2011 13:23:20 -0700
Message-ID: <EE869ECFF31BC24F8DCB5BBC5DF600C73B0574B1E5@xxxxxx>
I'm not sure I'd say that *no* clear guidance has emerged.  RTCA SC-216 and Eurocae WG-72 have jointly produced DO-326/ED-202 "Airworthiness Security Process Specification" and are working on a mid-2012 release of companion documents for security methods and security aspects of continuing airworthiness.

The challenge, as you discuss below, is to address just the aspects of security that are related to safety (and hence to that very expensive process of certification and continuing airworthiness), leaving in place the traditional split that attempts to leave aspects not related to airworthiness outside the scope of the certification compliance activities.  Traditionally, the security discipline (processes and methods) do not clearly maintain such a distinction.  Some question whether it's possible to do so, in fact.

But I question whether it's realistic to expect to take two different development approaches to problems that manifest themselves in the same outcome ("a safety escape and a security breach can lead to the same unfortunate outcome") and not address them within a common framework.  I'm very familiar with how cyber (i.e., complex embedded digital system) security has been declared out of scope in a number of areas, while at the same time I personally don't understand or agree with that decision in general.

You only get to produce one airplane in any given effort.  You don't get to say, "Here's the safe version and here's the secure version - you choose which you want."  So I'm very much a proponent of system designers "owning" all the environmental aspects that are relevant to the safety of their design.  My opinion is that if cyber security (e.g., safety of access over networks) is a safety issue because of access security, then they need to learn to deal with it, or they need to be sure it doesn't happen.  DO-326 is a start at determining how to know (and show others, like regulators) if you've done it; it doesn't propose to tell you how to do it.

Regards
Chuck Royalty
Co-chair, RTCA SC-216

-----Original Message-----
From: safety-critical-request@xxxxxx [mailto:safety-critical-request@xxxxxx] On Behalf Of Tom Ferrell
Sent: Wednesday, June 08, 2011 11:53 AM
To: safety-critical@xxxxxx
Subject: RE: [sc] SCADA Holes Allowed Remote Takedown of Siemens Systems

Drawing a boundary around standards related to safety can be quite challenging where security is concerned.  In many cases, a safety escape and a security breach can lead to the same unfortunate outcome.  The only real difference is the intent or lack thereof behind the initiating cause.  The committee working on DO-178C has taken the same tack as the authors of IEC 61508, i.e. security is a different and distinct technical topic and therefore out of scope.  The latest draft does list security as a system consideration.  There are at least a few (myself
included) in the aerospace community who believe this may be more than a little shortsighted.  There is a separate RTCA committee working on security requirements but thus far no clear set of guidance for airborne systems has emerged.  It is a touchy subject because the airframers, the avionics developers, and the airlines all see this as likely to drive
significant cost.    
Received on Wed 08 Jun 2011 - 21:23:32 BST