[SystemSafety] IEC TR 63069

[Matthew Squair]

So,

Are the authors assuming in the third dot point that there are absolutely no negative interactions between countermeasures of the security environment and the safety properties of the system being secured? 

Alternatively does that non-interaction need to be designed into the system? If so it would seem to be a security engineering responsibility as the safety engineers can (apparently) ignore security. If they are ignoring security then how do the security engineers ‘know’ what countermeasures might adversely affect the systems safety properties?

Regards, 



> On 10 Jan 2019, at 1:50 am, Peter Bernard Ladkin <ladkin at causalis.com> wrote:
> 
> Y'all remember the one? The technical report, about to be published any day by IEC, which claims to
> reveal a "framework" for dealing with functional safety + cybersecurity (FS+Cybersec) in IACS?
> 
> We have at least one person here who was on IEC TC65 WG20, which formulated the document.
> 
> A key contention is that a "security environment" (henceforth, SE) shall be established; and, within
> that SE, safety engineers are to perform their RiskAn (or, as it is redundantly called in IEC 61508
> Subclause 7.2, a Hazard and Risk Analysis) under the assumption that cybersecurity is assured by the
> SE.
> 
> The definition of SE in IEC TR 63069 Clause 3 (Terms and Definitions) is not very helpful:
> 
> [begin quote]
> 
> 3.1.5
> security environment
> 
> area of consideration where all relevant security countermeasures are in place and effective
> 
> [end quote]
> 
> What is an "area of consideration"? A geographical location within which everybody is very polite to
> each other? Some sort of geometrical object imposed upon the ground?
> 
> Actually, it is just a set, namely a set of countermeasures, as elaborated in Section 4.2 as follows:
> 
> [begin quote]
> 
> The security environment .... is understood as the overall collection of
> countermeasures required to ensure an efficiently protected environment for operations of the
> safety functions, however it is not limited to protect the safety functions only.
> 
> The security environment includes but is not limited to the following countermeasures:
> 
> - all countermeasures protecting the perimeters of the security environment under evaluation,
> - all countermeasures concerning the interaction between different functional Units at the security
> 	 environment,
> - all countermeasures to be applied at the functional units within the security environment.
> 
> NOTE 1 In practical applications, countermeasures might not be exclusive for the safety functions.
> 
> NOTE 2 The security environment is not the same as a "zone" as described in IEC 62443 series.
> 
> NOTE 3 The security environment can incorporate the “defence in depth” strategy (see IEC 62443-1-1
> Chapter 5.4) for achieving sufficient resilience of an application.
> 
> [end quote]
> 
> Note this is confused. An SE is a set (or "collection"). But it has a "perimeter" (first bullet
> point above). What is the "perimeter" of a set or collection? Sets have no perimeter. (But an IACS
> zone does. Are the authors equivocating?)
> 
> One of the TR authors just said the following.
> 
> [begin quote]
> The security environment is constituted by ALL countermeasures as defined in the Security
> Threat-Risk Assessment.
> [end quote]
> 
> So this brings something else in, namely that a "S T-R A" is required and it is that which defines
> the SE.
> 
> BTW, cybersecurity analysis is called different things on different days of the week. In the
> engineering-scientific literature it is often called "security risk analysis". ETSI calls it
> "risk-based security assessment". Elsewhere, in ETSI TS 102 165-1 V5.2.3 (2017-10), ETSI calls it
> "Threat, Vulnerability, Risk Analysis (TVRA)". I had understood that it was officially called a
> "security risk assessment" (SRA) within the IEC, according to the title of IEC 62443-3-2, which it
> supposed to say how to do it. But even within that document, Figure 1 speaks instead of
> "cybersecurity risk assessment". In IEC TR 63069 the term "threat-risk assessment <security>" is
> used (the title of subclause 7.3, for example).
> 
> SE is defined in ETSI TS 102 165-1 as
> 
> [begin quote]
> 
> 5.1.1.1 Security environment
> 
> The security environment describes the security aspects of the environment in which the asset is
> intended to be used. It shall include:
> 
> • Security assumptions:
> 	- the intended use of the implementation;
> 	- the physical, user and connection aspects of the environment in which an
> 	  implementation will operate.
> • Assets:
> 	- the assets with which the asset under analysis will interact with;
> 	- the nature of the asset's interaction with other assets.
> 
> • Threats and threat agents:
> 	- all threats against which specific protection is required within either the implementation
> 	  of a standard or its expected environment;
> 	- the threat agents that will be used to enact the identified threats.
> 
> • Organizational security policies:
> 	- any security policies or rules with which an implementation of a standard shall comply.
> 
> The description of the security environment shall be tabulated following the format illustrated in
> the example. [following]
> 
> [end quote]
> 
> I think that is more helpful than considering it to be a possibly-arbitrary collection of measures.
> It is certainly more helpful in the context of any "framework" for FS+Cybersec, as I note below.
> 
> So the substantive content of IEC TR 63069 can be reduced to the following. The parts in parentheses
> are actions which need to be performed, but are not necessarily explicit in the document.
> * 1. (Do a SRA. Formulate cybersecurity requirements on the basis of the SRA, and cybersecurity
> 	 measures to assure the cybersecurity requirements are fulfilled.)
> * 2. Define a SE (= the collection of formulated cybersecurity measures).
> * 3. Perform a (safety) RiskAn assuming that cybersecurity is assured.
> * 4. (Then follow the rest of your system development based as usual on the results of that RiskAn.)
> 
> Steps 3 and 4 have some of us say that this approach is very wrong-headed. It is only reasonable to
> assume in your RiskAn that cybersecurity is assured if indeed you have made some attempt to ensure
> that this is so. But there is no suggestion, anywhere, that your SRA has to be evaluated for
> completeness! Just assuming your SE suffices, without making an explicit effort to check it, is
> inappropriately rash.
> 
> ETSI is better. It relativises the SE to an explicit collection of threats and threat-agents. So it
> is prima facie clear that you cannot necessarily expect protection against an unlisted threat or
> agent. But then a safety engineer cannot assume cybersecurity is assured, for there might be threats
> not listed in your SE. Further, there is some hope of showing relative completeness of your SE if
> you actually list the threats, for you can perform BAN-logic analysis of your measures to assure
> they suffice (well, you can theoretically. It is not as if BAN-logic inference is easy).
> 
> PBL
> 
> Prof. Peter Bernard Ladkin, Bielefeld, Germany
> MoreInCommon
> Je suis Charlie
> Tel+msg +49 (0)521 880 7319  www.rvs-bi.de
> 
> 
> 
> 
> 
> _______________________________________________
> The System Safety Mailing List
> systemsafety at TechFak.Uni-Bielefeld.DE
> Manage your subscription: https://lists.techfak.uni-bielefeld.de/mailman/listinfo/systemsafety