[SystemSafety] IEC TR 63069

[Peter Bernard Ladkin]

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





-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20190109/e00ae870/attachment.sig>