IEC TR 63069, Security Environments and Security Risk Analysis

Abstract

The recently published IEC technical report IEC TR 63069 purports to give guidance on how to conduct cybersecurity-related analysis during the development of safety-related Industrial Automation and Control Systems (IACS). I propose that this guidance is significantly flawed. This paper explains why.

Full text

IEC TR 63069, Security Environments and Security Risk Analysis
Peter Bernard Ladkin
Version 2 of 20190112
IEC TR 63069 [IEC63069] proposes a “framework” for functional safety and security in industrial
automation and control systems (IACS). A key proposal is that a "security environment"
(henceforth, SE) shall be established. Within that SE, it is suggested that safety engineers are to
perform their risk analysis1 (RiskAn) and risk evaluation under the assumption that cybersecurity is
assured by the SE2.
The definition of SE is an “area of consideration where all relevant security countermeasures are in
place and effective” [IEC63069 subclause 3.1.5].
This raises a number of questions.
First, what is an "area of consideration"? Is it a geographical location within which everybody is
very polite to each other? Is it some sort of geometrical object imposed upon the ground? Is it
something like a “zone”, a “grouping of logical or physical assets that share common security
requirements” [IEC62443 subclause 3.2.117]?
Second, what is it for security countermeasures to be “effective”? Consider, for example, a measure
S intended to provide only authorised access (phrased in terms of “countermeasure”, that would be
to inhibit unauthorised access) to control-system-command execution. Suppose person A is
“authorised”. And person M, who is not authorised, obtains person A's credentials (those
belongings assigned to and characteristics of person A which S checks in order to grant A
command-execution access). Person M can use these credentials to obtain access to command
execution. This can theoretically happen with any such S (indeed, how to generate sufficient
credentials to inhibit it as far as possible is an ongoing area of security research for the last few
thousand years, and shows no sign of letting up).
So S cannot infallibly guarantee access to and only to those people the owners/operators intend
should have it. Is S to be counted as “effective”? Or is S ineffective because it is not perfect? Does
“effective” mean “pretty d**n good” (that is, devised and implemented by the top engineering
scientists in the field); does it mean “fulfils its specification perfectly” (and how good is the
specification?); does it mean “fulfils the design intent perfectly” (that is, it invariably excludes all
M's) ? We don't know and I can find no hint.
Actually, there is a further elaboration of what an SE is intended to be. It is just a set, namely a set
of countermeasures [IEC63069 subclause 4.2, sic]:
The security environment .... is understood as the overall collection of countermeasures
1 Risk analysis is defined in [IEC51]; see in particular Figure 2. Formally, it is the systematic use of available
information to identify hazards and to estimate the risk [IEC51 subclause 3.9]. “Risk” is defined to be the
combination of the “probability” (I would say likelihood) of occurrence of harm with the severity of that harm
[IEC51 subclause 3.8]. It is understood that he probability of occurrence includes the exposure to a hazardous
situation, the occurrence of a hazardous event, and the possibility to avoid or limit the harm.
2 “1) Guiding principle 1: protection of safety implementations. Security countermeasures should effectively prevent
or guard against adverse impacts of threats to safety-related systems and their implemented safety functions.
Evaluations of safety functions should be based on the assumption of effective (security) countermeasures.
[IEC63069 Clause 5, my emphasis]
IEC TR 63069, Security Environments and Security Risk Analysis
Peter Bernard Ladkin
Version 2 of 20190112
IEC TR 63069 [IEC63069] proposes a “framework” for functional safety and security in industrial
automation and control systems (IACS). A key proposal is that a "security environment"
(henceforth, SE) shall be established. Within that SE, it is suggested that safety engineers are to
perform their risk analysis1 (RiskAn) and risk evaluation under the assumption that cybersecurity is
assured by the SE2.
The definition of SE is an “area of consideration where all relevant security countermeasures are in
place and effective” [IEC63069 subclause 3.1.5].
This raises a number of questions.
First, what is an "area of consideration"? Is it a geographical location within which everybody is
very polite to each other? Is it some sort of geometrical object imposed upon the ground? Is it
something like a “zone”, a “grouping of logical or physical assets that share common security
requirements” [IEC62443 subclause 3.2.117]?
Second, what is it for security countermeasures to be “effective”? Consider, for example, a measure
S intended to provide only authorised access (phrased in terms of “countermeasure”, that would be
to inhibit unauthorised access) to control-system-command execution. Suppose person A is
“authorised”. And person M, who is not authorised, obtains person A's credentials (those
belongings assigned to and characteristics of person A which S checks in order to grant A
command-execution access). Person M can use these credentials to obtain access to command
execution. This can theoretically happen with any such S (indeed, how to generate sufficient
credentials to inhibit it as far as possible is an ongoing area of security research for the last few
thousand years, and shows no sign of letting up).
So S cannot infallibly guarantee access to and only to those people the owners/operators intend
should have it. Is S to be counted as “effective”? Or is S ineffective because it is not perfect? Does
“effective” mean “pretty d**n good” (that is, devised and implemented by the top engineering
scientists in the field); does it mean “fulfils its specification perfectly” (and how good is the
specification?); does it mean “fulfils the design intent perfectly” (that is, it invariably excludes all
M's) ? We don't know and I can find no hint.
Actually, there is a further elaboration of what an SE is intended to be. It is just a set, namely a set
of countermeasures [IEC63069 subclause 4.2, sic]:
The security environment .... is understood as the overall collection of countermeasures
1 Risk analysis is defined in [IEC51]; see in particular Figure 2. Formally, it is the systematic use of available
information to identify hazards and to estimate the risk [IEC51 subclause 3.9]. “Risk” is defined to be the
combination of the “probability” (I would say likelihood) of occurrence of harm with the severity of that harm
[IEC51 subclause 3.8]. It is understood that he probability of occurrence includes the exposure to a hazardous
situation, the occurrence of a hazardous event, and the possibility to avoid or limit the harm.
2 “1) Guiding principle 1: protection of safety implementations. Security countermeasures should effectively prevent
or guard against adverse impacts of threats to safety-related systems and their implemented safety functions.
Evaluations of safety functions should be based on the assumption of effective (security) countermeasures.
[IEC63069 Clause 5, my emphasis]

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.
This is, however, confused. An SE is a set (or "collection"). But it has a "perimeter", according to
the first bullet point above. Sets have no perimeter. A zone has a perimeter, but an SE is not a zone
(NOTE 2).
One of the authors of [IEC63069] has explained that
The security environment is constituted by ALL countermeasures as defined in the Security
Threat-Risk Assessment [Lai19].
This brings something else in, namely that
•a "Security Threat-Risk Assessment" is required, and
•it is the Security Threat-Risk Assessment which apparently defines the SE.
So what is a “Security Threat-Risk Assessment”? Could we presume it is a "threat-risk assessment
<security>", the term used specifically in [IEC63069 subclause 7.3]? But see below.
BTW, cybersecurity analysis gets all kinds of different names in the literature. In the engineering-
scientific literature it is often called "security risk analysis". ETSI calls it "risk-based security
assessment" [ETSI203251]. Elsewhere, ETSI calls it "Threat, Vulnerability, Risk Analysis (TVRA)"
[ETSI1021651]. Standards associated with [IEC63069] call it a "security risk assessment", and
purport to explain how to do one [IEC62443-3-2]. But even within that draft document, Figure 1
speaks instead of "cybersecurity risk assessment". I shall call it here a security-risk analysis (SRA)3.
A notion of Security Environment is also defined in [ETSI1021651]:
5.1.1.1 Security environment
The security environment describes the security aspects of the environment in which the
3 I regard the hyphen as essential. I have argued in [La17 Chapter 14] that security-risk is something other than a
combination of probability and severity, because chances of occurrence change rapidly and discretely with the
stages leading towards an attack. Hence the standard IEC concept of “risk” cannot be used unmodified.
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.
This is, however, confused. An SE is a set (or "collection"). But it has a "perimeter", according to
the first bullet point above. Sets have no perimeter. A zone has a perimeter, but an SE is not a zone
(NOTE 2).
One of the authors of [IEC63069] has explained that
The security environment is constituted by ALL countermeasures as defined in the Security
Threat-Risk Assessment [Lai19].
This brings something else in, namely that
•a "Security Threat-Risk Assessment" is required, and
•it is the Security Threat-Risk Assessment which apparently defines the SE.
So what is a “Security Threat-Risk Assessment”? Could we presume it is a "threat-risk assessment
<security>", the term used specifically in [IEC63069 subclause 7.3]? But see below.
BTW, cybersecurity analysis gets all kinds of different names in the literature. In the engineering-
scientific literature it is often called "security risk analysis". ETSI calls it "risk-based security
assessment" [ETSI203251]. Elsewhere, ETSI calls it "Threat, Vulnerability, Risk Analysis (TVRA)"
[ETSI1021651]. Standards associated with [IEC63069] call it a "security risk assessment", and
purport to explain how to do one [IEC62443-3-2]. But even within that draft document, Figure 1
speaks instead of "cybersecurity risk assessment". I shall call it here a security-risk analysis (SRA)3.
A notion of Security Environment is also defined in [ETSI1021651]:
5.1.1.1 Security environment
The security environment describes the security aspects of the environment in which the
3 I regard the hyphen as essential. I have argued in [La17 Chapter 14] that security-risk is something other than a
combination of probability and severity, because chances of occurrence change rapidly and discretely with the
stages leading towards an attack. Hence the standard IEC concept of “risk” cannot be used unmodified.

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……...
[end quote]
This definition is more helpful to those implementing cybersecurity measures than considering an
SE to be a possibly-arbitrary collection of measures. It relativises the SE to an explicit collection of
threats and threat-agents. So, to take my example above, you consider explicitly A and M and A's
set of credentials when considering this threat (and you would consider whether those credentials
suffice for the current purpose, or need to be strengthened. In any case, the “residual vulnerability”,
as we may call it, is explicit in this formulation). It is prima facie clear that you cannot necessarily
expect protection against an unlisted threat or agent. Further, there is some hope of showing relative
completeness of your SE, for you can perform BAN-logic analysis of your measures to assure
they suffice (that is, theoretically you can do so if you are clever enough. It is not as if BAN-logic
inference is easy).
Notice that, on the basis of the ETSI definition of SE, one cannot assume that cybersecurity is
assured, for there might well be threats not listed in your SE and thereby maybe not countered by
measures in it. Hence, a safety engineer performing a risk analysis can at most presume that the
system is secure against the enumerated threats, and will have to consider the possibility of other
threats unforeseen in the SE definition and the possible effects of these threats upon safety
functions. That is, cyber-insecurity must still be considered by a safety engineer performing a
“Hazard and Risk Analysis” according to [IEC61508-1 subclause 7.2].
The substantive content of IEC TR 63069 can be reduced to the following scheme (parts given in
parentheses are actions which need to be performed, but are not necessarily explicit in the
document).
1. (Perform 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).
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……...
[end quote]
This definition is more helpful to those implementing cybersecurity measures than considering an
SE to be a possibly-arbitrary collection of measures. It relativises the SE to an explicit collection of
threats and threat-agents. So, to take my example above, you consider explicitly A and M and A's
set of credentials when considering this threat (and you would consider whether those credentials
suffice for the current purpose, or need to be strengthened. In any case, the “residual vulnerability”,
as we may call it, is explicit in this formulation). It is prima facie clear that you cannot necessarily
expect protection against an unlisted threat or agent. Further, there is some hope of showing relative
completeness of your SE, for you can perform BAN-logic analysis of your measures to assure
they suffice (that is, theoretically you can do so if you are clever enough. It is not as if BAN-logic
inference is easy).
Notice that, on the basis of the ETSI definition of SE, one cannot assume that cybersecurity is
assured, for there might well be threats not listed in your SE and thereby maybe not countered by
measures in it. Hence, a safety engineer performing a risk analysis can at most presume that the
system is secure against the enumerated threats, and will have to consider the possibility of other
threats unforeseen in the SE definition and the possible effects of these threats upon safety
functions. That is, cyber-insecurity must still be considered by a safety engineer performing a
“Hazard and Risk Analysis” according to [IEC61508-1 subclause 7.2].
The substantive content of IEC TR 63069 can be reduced to the following scheme (parts given in
parentheses are actions which need to be performed, but are not necessarily explicit in the
document).
1. (Perform 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.)
I consider Steps 3 and 4 very dubious. It is only reasonable to assume in a RiskAn that
cybersecurity is assured if indeed there has been an attempt to ensure that this is so and the attempt
has been successful. But there is no suggestion, anywhere in [IEC63069] or elsewhere, that the SRA
has to be evaluated for completeness! Just assuming that the defined SE suffices, without making an
explicit effort to check it, I regard as inappropriately rash.
There needs to be inserted a further step:
2a. Show that the SE is complete. That is, that it thwarts all cyberattacks.
I and others consider this to be a pipe-dream [Tho19], highly unrealistic. I suggest it is realistic to
perform an ETSI-type TVRA and achieve the following:
2b. Show that the (ETSI-type) SE is relatively complete. That is, it successfully thwarts
cyberattacks which follow the enumerated threats.
But then Step 3 is inadequate: as argued above, a safety engineer performing a RiskAn will need to
consider possible cyber-insecurities which are not listed in the (ETSI-type) SE.
Finally, I consider an IEC 63069-type “threat-risk assessment <security>”. This is a process which
seems to involve somewhat more than a TVRA, or more than SRAs to be found elsewhere in the
literature. [IEC63069 subclause 7.3.2] explains:
7.3.2 Recommendation to the threat-risk assessment <security>
The following should be applied during the threat-risk assessment process:
1) The detailed safety description should be prepared;
2) The threats and their potential impacts to the security environment should be identified;
3) Hazards that can result from attacks should be identified;
4) The system operations and/or the system architecture and how they could introduce
vulnerabilities should be identified.
5) Based on the information collected, the necessary security countermeasures establishing
an effective security environment should be defined and identified.
Regarding Point 1), It is not said what a “safety description” is. Maybe it is a list of safety
functions?
Regarding Point 2), there seems to be no requirement for any check on completeness. Relative
completeness can maybe be attained if one relativises the SE explicit to those threats identified in
Point 2) (as in the ETSI conception), but then Guiding Principle 1 must (at best) be relativised to
only assume “effective” countermeasures to the explicitly-identified threats. And it would be
appropriate for the “effectiveness” (whatever that is) of the countermeasures to be assessed and
assured (such evaluations can in principle be carried out through the use of BAN-logical
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.)
I consider Steps 3 and 4 very dubious. It is only reasonable to assume in a RiskAn that
cybersecurity is assured if indeed there has been an attempt to ensure that this is so and the attempt
has been successful. But there is no suggestion, anywhere in [IEC63069] or elsewhere, that the SRA
has to be evaluated for completeness! Just assuming that the defined SE suffices, without making an
explicit effort to check it, I regard as inappropriately rash.
There needs to be inserted a further step:
2a. Show that the SE is complete. That is, that it thwarts all cyberattacks.
I and others consider this to be a pipe-dream [Tho19], highly unrealistic. I suggest it is realistic to
perform an ETSI-type TVRA and achieve the following:
2b. Show that the (ETSI-type) SE is relatively complete. That is, it successfully thwarts
cyberattacks which follow the enumerated threats.
But then Step 3 is inadequate: as argued above, a safety engineer performing a RiskAn will need to
consider possible cyber-insecurities which are not listed in the (ETSI-type) SE.
Finally, I consider an IEC 63069-type “threat-risk assessment <security>”. This is a process which
seems to involve somewhat more than a TVRA, or more than SRAs to be found elsewhere in the
literature. [IEC63069 subclause 7.3.2] explains:
7.3.2 Recommendation to the threat-risk assessment <security>
The following should be applied during the threat-risk assessment process:
1) The detailed safety description should be prepared;
2) The threats and their potential impacts to the security environment should be identified;
3) Hazards that can result from attacks should be identified;
4) The system operations and/or the system architecture and how they could introduce
vulnerabilities should be identified.
5) Based on the information collected, the necessary security countermeasures establishing
an effective security environment should be defined and identified.
Regarding Point 1), It is not said what a “safety description” is. Maybe it is a list of safety
functions?
Regarding Point 2), there seems to be no requirement for any check on completeness. Relative
completeness can maybe be attained if one relativises the SE explicit to those threats identified in
Point 2) (as in the ETSI conception), but then Guiding Principle 1 must (at best) be relativised to
only assume “effective” countermeasures to the explicitly-identified threats. And it would be
appropriate for the “effectiveness” (whatever that is) of the countermeasures to be assessed and
assured (such evaluations can in principle be carried out through the use of BAN-logical

formulations and inference). That would presumably occur after the vulnerabilities have been
identified, which is in Point 4). So it looks as though it should happen under the action in Point 5).
In which case, Point 5) is also incompletely specified.
A key issue to note is contained in Point 3). Point 3) says that a (limited) HazID is to be performed.
A HazID is a process which is performed by safety engineers. So the process of “threat-risk
assessment <security>” necessarily involves some safety analysis and thereby safety engineering
and thus safety engineers. It is not a TVRA. It is not a SRA as elaborated elsewhere in the literature.
It is somehow a security-for-safety analysis.
I conclude that the analysis proposed by IEC TR 63069 in subclause 7.3.2, the “threat-risk
assessment <security>” is underspecified. It is a process which necessarily involves cybersecurity
analysis as well as safety analysis and therefore necessarily involves both security engineers and
safety engineers. In lieu of a precise designation of what the steps in such a process would be, it
remains only a broad and incomplete guide to doing something which might help safety analysis in
a cyber-insecure environment.
Bibliography
[ETSI1021651] European Telecommunications Standards Institute, ETSI TS 102 165-1 V5.2.3
(2017-10), CYBER; Methods and protocols; Part 1: Method and pro forma for Threat,
Vulnerability, Risk Analysis (TVRA), Technical Specification, ETSI 2017. Available from
https://www.etsi.org/deliver/etsi_ts/102100_102199/10216501/05.02.03_60/ts_10216501v050203p.
pdf , accessed 2019-01-11.
[ETSI203251] European Telecommunications Standards Institute, ETSI EG 203 251 V1.1.1,
Methods for Testing & Specification; Risk-based Security Assessment and Testing Methodologies,
Final Draft, ETSI Guide, ETSI 2017. Available from
https://www.etsi.org/deliver/etsi_eg/203200_203299/203251/01.01.01_50/eg_203251v010101m.pd
f , accessed 2019-01-11.
[IEC51] International Organization for Standardization/International Electrotechnical Commission,
Guide 51, Safety aspects – Guidelines for their inclusion in standards, Edition 3, ISO/IEC 2014.
[IEC61508-1] International Electrotechnical Commission, IEC TR 62443-1-1, Industrial-process
measurement, control and automation – Functional safety of electrical/electronic/programmable
electronic safety-related systems – Part 1: General requirements, Edition 2, IEC 2010.
[IEC62443-1-1] International Electrotechnical Commission, IEC TR 62443-1-1, Industrial-process
measurement, control and automation – Network and system security – Part 1-1: Terminology,
concepts and models, IEC 2009.
[IEC62443-3-2] International Electrotechnical Commission, IEC , Security for industrial
automation and control systems – Part 3-2: Security risk assessment and system design, Committee
Draft, 2018. Note this document is, according to IEC procedures “not to be used for reference
purposes”. A Committee Draft is, however, clear evidence of an IEC project with an intent to
produce such a document.
[IEC63069] International Electrotechnical Commission, IEC TR 63069, Industrial-process
measurement, control and automation – Framework for functional safety and security, IEC 2019.
[Lad17] Peter Bernard Ladkin, A Critical-Systems Manifesto: Issues Arising from IEC 61508,
2017. Available from https://rvs-bi.de/publications/RVS-Bk-17-01.html , accessed 2019-01-11.
[Lai19] Holger Laible, personal communication with the author and others, 2019-01-09 at 14:21
MET.
formulations and inference). That would presumably occur after the vulnerabilities have been
identified, which is in Point 4). So it looks as though it should happen under the action in Point 5).
In which case, Point 5) is also incompletely specified.
A key issue to note is contained in Point 3). Point 3) says that a (limited) HazID is to be performed.
A HazID is a process which is performed by safety engineers. So the process of “threat-risk
assessment <security>” necessarily involves some safety analysis and thereby safety engineering
and thus safety engineers. It is not a TVRA. It is not a SRA as elaborated elsewhere in the literature.
It is somehow a security-for-safety analysis.
I conclude that the analysis proposed by IEC TR 63069 in subclause 7.3.2, the “threat-risk
assessment <security>” is underspecified. It is a process which necessarily involves cybersecurity
analysis as well as safety analysis and therefore necessarily involves both security engineers and
safety engineers. In lieu of a precise designation of what the steps in such a process would be, it
remains only a broad and incomplete guide to doing something which might help safety analysis in
a cyber-insecure environment.
Bibliography
[ETSI1021651] European Telecommunications Standards Institute, ETSI TS 102 165-1 V5.2.3
(2017-10), CYBER; Methods and protocols; Part 1: Method and pro forma for Threat,
Vulnerability, Risk Analysis (TVRA), Technical Specification, ETSI 2017. Available from
https://www.etsi.org/deliver/etsi_ts/102100_102199/10216501/05.02.03_60/ts_10216501v050203p.
pdf , accessed 2019-01-11.
[ETSI203251] European Telecommunications Standards Institute, ETSI EG 203 251 V1.1.1,
Methods for Testing & Specification; Risk-based Security Assessment and Testing Methodologies,
Final Draft, ETSI Guide, ETSI 2017. Available from
https://www.etsi.org/deliver/etsi_eg/203200_203299/203251/01.01.01_50/eg_203251v010101m.pd
f , accessed 2019-01-11.
[IEC51] International Organization for Standardization/International Electrotechnical Commission,
Guide 51, Safety aspects – Guidelines for their inclusion in standards, Edition 3, ISO/IEC 2014.
[IEC61508-1] International Electrotechnical Commission, IEC TR 62443-1-1, Industrial-process
measurement, control and automation – Functional safety of electrical/electronic/programmable
electronic safety-related systems – Part 1: General requirements, Edition 2, IEC 2010.
[IEC62443-1-1] International Electrotechnical Commission, IEC TR 62443-1-1, Industrial-process
measurement, control and automation – Network and system security – Part 1-1: Terminology,
concepts and models, IEC 2009.
[IEC62443-3-2] International Electrotechnical Commission, IEC , Security for industrial
automation and control systems – Part 3-2: Security risk assessment and system design, Committee
Draft, 2018. Note this document is, according to IEC procedures “not to be used for reference
purposes”. A Committee Draft is, however, clear evidence of an IEC project with an intent to
produce such a document.
[IEC63069] International Electrotechnical Commission, IEC TR 63069, Industrial-process
measurement, control and automation – Framework for functional safety and security, IEC 2019.
[Lad17] Peter Bernard Ladkin, A Critical-Systems Manifesto: Issues Arising from IEC 61508,
2017. Available from https://rvs-bi.de/publications/RVS-Bk-17-01.html , accessed 2019-01-11.
[Lai19] Holger Laible, personal communication with the author and others, 2019-01-09 at 14:21
MET.

[Tho19] Martyn Thomas, comment to the Safety Critical Systems List, 2019-01-09 at 1913 MET.
Available at http://www.systemsafetylist.org/4480.htm , accessed 2019-01-11.
[Tho19] Martyn Thomas, comment to the Safety Critical Systems List, 2019-01-09 at 1913 MET.
Available at http://www.systemsafetylist.org/4480.htm , accessed 2019-01-11.