Do not change the structure (including column widths) of this
Due on June 10, 2014 to
Document:
Project: ISA99 ballot
comment form.
crobinson@isa.org::
ISA-dTR62443-1-3 (draft 6, edit 5)
closing June 10, 2014.
Do use line numbers if they are available in the document under review. Do use the two-letter comment type codes listed in the page footer.
Your
initials
Line
number
Clause/
Subclause
(e.g. 17)
(e.g. 3.1)
Paragraph/
Figure/
Table/
(e.g. P3, F21)
1
JBN
Type of
comment2
Comments
ed
This version of the document is a significant
improvement over the previous versions. I like the
minimalist approach taken by the task group.
Gen
Part 1-3: System security conformance metrics
ge
The German National Committee estimates that
the submitted IEC/DTS 62433-1-3 does not
contribute to improve the security posture of
Industrial Automation and Control Systems and
recommends rejecting the submitted document.
ed
grammatical error
5
LW
te
The draft contains much material which seems to
be at most current research but not mature
enough for an international standard.
6
LW
te
The document does not fulfil the scope. It is
supposed to cover technical control functions
which enable the requirements specified in IEC
62443-3-3. None of the proposed compliance
metrics described in Table 2 has any relation with
the content of IEC 62443-3-3.
7
LW
te
The document does not fulfil the scope. None of
the proposed compliance metrics described in
Table 2 fulfils the requirements a) to e) of clause
1.
8
LW
te
Many of the metrics are theoretical and are not
practically implementable.
2
ELC
Title
3
LW
4
JTL
2
FORWARD
Type of comment:
ge = general
te = technical
Proposed change
Response by edit team
Noted
None in this document…make sure all other
related ISA 99 documentation uses the word
conformance rather than compliance when
referencing alignment with 1-3 metrics. (see
Overview Graphic in ISA 99 Wiki for an example
of the use of the word compliance).
Withdraw the document
“… define threshold values that are …”
Withdraw the document
Withdraw the document
Withdraw the document
Withdraw the document
Noted
Comment rejected. The
document will be
substantially revised and
resubmitted for comment.
Accepted. Change ‘which’
to ‘that. Watch correct
usage in revised draft.’
Comment rejected. The
document will be
substantially revised and
resubmitted for comment.
Comment rejected. The
document will be
substantially revised and
resubmitted for comment.
Comment rejected. The
document will be
substantially revised and
resubmitted for comment.
Comment rejected. The
document will be
ed = editorial
page 1 of 32
Based on ISO/IEC/CEN/CENELEC electronic balloting commenting template/version 2012-03
Do not change the structure (including column widths) of this
Due on June 10, 2014 to
Document:
Project: ISA99 ballot
comment form.
crobinson@isa.org::
ISA-dTR62443-1-3 (draft 6, edit 5)
closing June 10, 2014.
Do use line numbers if they are available in the document under review. Do use the two-letter comment type codes listed in the page footer.
Your
initials
Line
number
Clause/
Subclause
(e.g. 17)
(e.g. 3.1)
Paragraph/
Figure/
Table/
(e.g. P3, F21)
Type of
comment2
Comments
Proposed change
Response by edit team
substantially revised and
resubmitted for comment.
9
LW
te
Many of the metrics don’t have a value to improve
the security posture.
ED
Fowerds must not include requirements. The
bulleted items contain the “shall be” and “should
be” phrase.
Change to the following sample format:
Change “metric(s)” to “measurement” throughout
document.
10
DLB
Forward
11
MN
-
-
Ed
In this field, the term “metrics” is now generally
depreciated in favour of the term “measurement”.
12
RS
All
All
ge
I feel that this document is not fit for publication. It
does not meet its intended (and stated) scope
and the metrics specified don’t meet the quality
criteria defined within this document itself.
This has already been the case for the earlier
draft and we have submitted comments
suggesting approaches to solve the problems
identified in the draft. However, despite the
largely affirmative responses to these comments
as documented in IEC 65/537A/CC the
suggestions have not been followed and the
problems remain in the document.
Therefore we disapprove the draft.
Withdraw the document

Comment rejected. The
document will be
substantially revised and
resubmitted for comment.
Accepted in principle.
Conformance metrics are measureable in
the sense that they are consistently
measured with objective criteria
Comment rejected. A
metric is not a
measurement; the rewrite
will cite the difference
Comment rejected. See
rewrite to improve the
detail
See further comments for details.
13
RS
2
All
Type of comment:
All
ge = general
ge
te = technical
As the standard stands today, it merely lists
(incompletely) possible metrics that can be
applied, however, it does not provide the context
for these metrics nor does it give the rationale.
Provide context to the metrics which allow the
reader to understand how the metrics’ results are
to be interpreted in terms of compliance.
Comment rejected. The
rewrite will provide detail
consistent with the
approved charter and
scope.
ed = editorial
page 2 of 32
Based on ISO/IEC/CEN/CENELEC electronic balloting commenting template/version 2012-03
Do not change the structure (including column widths) of this
Due on June 10, 2014 to
Document:
Project: ISA99 ballot
comment form.
crobinson@isa.org::
ISA-dTR62443-1-3 (draft 6, edit 5)
closing June 10, 2014.
Do use line numbers if they are available in the document under review. Do use the two-letter comment type codes listed in the page footer.
Your
initials
Line
number
Clause/
Subclause
(e.g. 17)
(e.g. 3.1)
Paragraph/
Figure/
Table/
(e.g. P3, F21)
14
ZT
Type of
comment2
ge
15
EH
16
EH
Comments
Proposed change
Response by edit team
There is no guidance given on the range of values
for any of the metrics. Although “actionable” is
listed as a goal of the metrics, many of the
proposed metrics have no direct link to possible
remedial activities
Comment rejected.
Remedial activities are
outside the scope of this
document.
1 – I do not know how this could be applied, as is,
to any of my existing IACS systems, as the
measurement processes specified do not exist.
Comment rejected.
Measurement process are
beyond the scope of this
document.
Comment rejected.
Measurement process are
beyond the scope of this
document.
2 – At a minimum, the order of the CMs would
need to be changed, as access control is the
least important to me. Reliability of the
communications between IACS components is
most important, with data integrity next.
17
EH
3 – It is almost impossible to understand this
document without first reading the Jericho
information. The relevant information needs to be
in this document, giving credit to the Jericho
information. It also needs to be more specific,
there are more than one Jericho Forum
documents that it could refer to.
Comment rejected.
Measurement process are
beyond the scope of this
document.
18
EH
4 – More details on the how to measure are
needed, including verifying the order of most
likely source for the information.
Comment rejected.
Measurement process are
beyond the scope of this
document.
19
EH
5 – The order of the CM is not the order that I
would agree with my priority; 1 to 5 are much less
important than 6-9.
Noted
20
jw
2
96
-103
Type of comment:
GE
ge = general
te = technical
The paragraph reads too much like this is only
about COTS.
Add more about IACS
Accepted in principle
ed = editorial
page 3 of 32
Based on ISO/IEC/CEN/CENELEC electronic balloting commenting template/version 2012-03
Do not change the structure (including column widths) of this
Due on June 10, 2014 to
Document:
Project: ISA99 ballot
comment form.
crobinson@isa.org::
ISA-dTR62443-1-3 (draft 6, edit 5)
closing June 10, 2014.
Do use line numbers if they are available in the document under review. Do use the two-letter comment type codes listed in the page footer.
Your
initials
Line
number
Clause/
Subclause
(e.g. 17)
(e.g. 3.1)
Paragraph/
Figure/
Table/
(e.g. P3, F21)
Type of
comment2
Comments
Proposed change
Response by edit team
21
jw
98
TE
COTS code accounts for the bulk of the legacy
IACS environment.
I am not sure this is a true statement
Accepted in principle.
22
MF
98
ed
COTS ‘code’ may be understood by some but not
all. In fact, this entire introduction section could
use a rewrite. The lexicon used as descriptors
may not necessarily resonate with all users.
Rewrite the section in the context the goals of the
document. The problem statement should be
relevant to the issue of measurement as well as
the concept of using the appropriate metrics for
conformance. The bulk of the document appears
to have been written from a specific engineering
perspective but this introduction section doesn’t
seem to share the same flow.
Accepted in principle.
23
JTL
98
te
The sentences that describe COTS technology as
the “bulk of the legacy IACS” and as black boxes
is a new diversion from the accepted term of
COTS that has been implied to refer technologies
like common hardware platforms, operating
systems and applications.
This paragraph should be re-written to represent
accepted COTS form.
Accepted in principle.
24
JW
100
-102
TE
For these reasons, COTS-based, and in
particular legacy systems are not usually as
robust, in the IACS environment, as are systems
designed specifically as IACS at dealing with
cyber-attack for many reasons.
I do not believe this is a true statement for dealing
with cyber attacks
Accepted in principle.
Final draft will be reviewed
for accuracy
25
RS
100
0
ge
“For these reasons, COTS-based, and in
particular legacy systems are not usually as
robust, in the IACS environment, as are systems
designed specifically as IACS at dealing with
cyber-attack for many reasons.”
This sentence is too complicated.
Simplify the structure by moving the pieces
between the commas to a proper place in the
grammatical stricture of the sentence.
Accepted.
Will simplify the content for
international audiences
[tech editor review?]
26
RS
104
0
ge
What does pre-existing refer to? Pre- means
before. Pre-existing thus existing before... before
what?
Rephrase to e.g. “traditional IT and business”
Accepted in principle.
27
LcS
106
mE
“possible” may have excessive expense impacts
Replace word “possible” with “practical”
Accepted in principle.
2
Type of comment:
ge = general
te = technical
ed = editorial
page 4 of 32
Based on ISO/IEC/CEN/CENELEC electronic balloting commenting template/version 2012-03
Do not change the structure (including column widths) of this
Due on June 10, 2014 to
Document:
Project: ISA99 ballot
comment form.
crobinson@isa.org::
ISA-dTR62443-1-3 (draft 6, edit 5)
closing June 10, 2014.
Do use line numbers if they are available in the document under review. Do use the two-letter comment type codes listed in the page footer.
Your
initials
Line
number
Clause/
Subclause
(e.g. 17)
(e.g. 3.1)
28
DLB
122
Introduction
29
ECC
127
-129
2
Type of comment:
Paragraph/
Figure/
Table/
(e.g. P3, F21)
1
ge = general
Type of
comment2
Comments
Proposed change
Response by edit team
ED
This introduction has nothing to do with metrics. It
also seems to end before any point is reached,
except to say a cookbook doesn’t work. This
section needs to intro 62443-3-1 not the whole
set of standards.
Replace the introduction with:
Industrial Automation and Control System (IACS)
organizations make use of commercial-off-theshelf (COTS) technology developed for business
systems in their everyday processes, which has
provided an increased opportunity for cyber-attack
against the IACS equipment. COTS code
accounts for the bulk of the legacy IACS
environment. COTS products are generally black
boxes to the end-user which makes it difficult to
verify its software security. For these reasons,
COTS-based, and in particular legacy systems are
not usually as robust, in the IACS environment, as
are systems designed specifically as IACS at
dealing with cyber-attack for many reasons. This
weakness may lead to Health, Safety and
Environmental (HSE) consequences.
This part defines a set of metrics that can be used
to help determine how well cyber system security
is implemented in the IACS. These metrics
provide end users some degree of knowledge that
the policies, procedures, and technologies are
being correctly implemented and followed.
Organizations may try to use the pre-existing
information technology (IT) and business
cybersecurity solutions to address security for
IACS without understanding the consequences.
While many of these solutions can be applied to
IACS, they need to be applied in the correct way
to eliminate inadvertent consequences. For this
reason, the system cybersecurity conformance
metrics in this document are based on a
combination of functional and consequence
analysis.
Accepted in part. The
substituted paragraph is
concise and supports the
overall intent of the
section. However, certain
points made in the two
eliminated paragraphs are
also worthy of at least a
brief inclusion.
[Note: Be cautious of
how/when the term COTS
is used.]
TE
I was confused by the statement that the focus is
on metrics that “enable the requirements
specified in IEC 62443-3-3.” Is the intent to issue
te = technical
Clarify intent and any plans for future editions of
this document.
Accepted
ed = editorial
page 5 of 32
Based on ISO/IEC/CEN/CENELEC electronic balloting commenting template/version 2012-03
Do not change the structure (including column widths) of this
Due on June 10, 2014 to
Document:
Project: ISA99 ballot
comment form.
crobinson@isa.org::
ISA-dTR62443-1-3 (draft 6, edit 5)
closing June 10, 2014.
Do use line numbers if they are available in the document under review. Do use the two-letter comment type codes listed in the page footer.
Your
initials
Line
number
Clause/
Subclause
(e.g. 17)
(e.g. 3.1)
Paragraph/
Figure/
Table/
(e.g. P3, F21)
Type of
comment2
1
30
RS
128
-131
2
1st
129
Type of comment:
Proposed change
Response by edit team
subsequent editions of this document that define
metrics corresponding to the normative content in
the other documents in the 62443 series?
te
1
31
Comments
ed
ge = general
te = technical
“High-priority metrics focus attention on security
technical control functions which enable the
requirements specified in IEC 62443-3-3. The
underlying management governance policies,
procedures, and organizational directives
conforming to IEC 62443-2-1 are assumed to be
enforced by the IACS owner/operator.”
There is only one set of metrics specified in this
document. Which are the “high-priority metrics”
and why are those high priority while others aren’t
(and which are the others)?
One set of metrics cannot measure conformance
to -3-3 and to -2-1. The target audience and thus
the target of evaluation are fundamentally
different. -2-1 addresses the operator's security
management system, i.e. policies and
procedures, while -3-3 addresses technical
capabilities in a control system product,
independent of a given use context.
It should be clearly identified which requirements
are in focus of this document, i.e. compliance with
which standard is measured by applying the
metrics specified here. -3-3 specifies system
capabilities for control systems. It is expected that
conformity can be stated for a product, i.e. either
the product provides the capability or not – e.g.
SR 1.1: either the product supports authentication
of users or it doesn’t. Evaluation of the metrics
proposed in this draft require a system in live
operation for a certain period of time, otherwise
the events to be counted cannot be observed.
For measuring conformity to -3-3, metrics must be
phrased in terms of test cases which can be
evaluated in lab environments. These must not
depend on counting occurrences of events, but
should describe how to validate the effective
availability of the required capability.
For measuring conformity to -2-1, metrics must be
phrased in terms of inspections that can be
performed on documented policies and
procedures whether they meet the requirements in
-2-1 as well as inspections of the monitoring and
continuous improvement system which tracks
implementation and possible violations in
implementations.
Accepted in principle; the
revised document will
pertain only to part -2-4.
grammatical error
“… functions that enable …”
Accepted in principle,
change ‘which’ to ‘that.
[See also CA2 in IEC
comments]
ed = editorial
page 6 of 32
Based on ISO/IEC/CEN/CENELEC electronic balloting commenting template/version 2012-03
Do not change the structure (including column widths) of this
Due on June 10, 2014 to
Document:
Project: ISA99 ballot
comment form.
crobinson@isa.org::
ISA-dTR62443-1-3 (draft 6, edit 5)
closing June 10, 2014.
Do use line numbers if they are available in the document under review. Do use the two-letter comment type codes listed in the page footer.
Your
initials
Line
number
Clause/
Subclause
(e.g. 17)
(e.g. 3.1)
Paragraph/
Figure/
Table/
(e.g. P3, F21)
Type of
comment2
Comments
Proposed change
JTL
32
RS
Response by edit team
Watch correct usage in
revised draft.’
132
-137
Enumeratio
n
te
Item a) states the objective of this document:
measure conformance with other specifications
from the 62443 series
Product development is covered in -4-1, services
are covered in -2-4. Thus item b) is already
covered by item a).
Monitoring and managing the quality of securityrelated services is part of the PDCA cycle /
monitoring and continuous improvement
requirements in -2-1. Thus item c) is covered in
item a).
Disposal of information and assets are part of -21 (at least in the draft for edition 2). Thus item d)
is covered in item a)
If anything isn't, it wouldn't belong here, since
conformance metrics shall measure conformance
to existing requirements, not introduce new
requirements (compare definitions of
conformance and of compliance).
Remove items b) through d) or make them subitems of a)
Accepted in principle. This
clause will be
reviewed/rewritten based
on the revised scope of the
document.
P8
ED
I don’t think “manage” is the appropriate word.
Defining and monitoring metrics won’t “manage”
the development of secure IACS.
Replace “manage” with “promote” or “encourage”
or similar verb
Accepted in principle
te
No normative references? How can a
conformance spec be applied without the specs
of the actual requirements???
The documents which are in scope of the
conformance metrics must be a normative
reference, likely this would be -2-1 and -3-3 at this
time.
Accepted in principle. The
normative references will
be inserted as needed (in
this case -2-4)
1
33
JAC
135
1
34
RS
143
-146
2
35
JBN
156
2
te
62443-3-2 cannot currently be referenced as
normative because it has not been published.
Delete 62443-3-2 from normative references, but
keep it in the bibliography.
Accepted
36
RS
158
3.1.3
te
This definition of compliance is about one spec
complying with another, while the scope as
defined above is to measure the conformity of an
Clarify the definition
Accepted in principle.
Verify which definition
(from which document) is
2
Type of comment:
ge = general
te = technical
ed = editorial
page 7 of 32
Based on ISO/IEC/CEN/CENELEC electronic balloting commenting template/version 2012-03
Do not change the structure (including column widths) of this
Due on June 10, 2014 to
Document:
Project: ISA99 ballot
comment form.
crobinson@isa.org::
ISA-dTR62443-1-3 (draft 6, edit 5)
closing June 10, 2014.
Do use line numbers if they are available in the document under review. Do use the two-letter comment type codes listed in the page footer.
Your
initials
Line
number
Clause/
Subclause
(e.g. 17)
(e.g. 3.1)
Paragraph/
Figure/
Table/
(e.g. P3, F21)
Type of
comment2
Comments
Proposed change
implementation to a spec. How does that fit
together?
being used. This will be
fixed in the next version.
37
ECC
161
-236
3.1
ED
Please ensure that all terms listed have been
compared to and reconciled with those in the
ISA99 master glossary Wiki.
38
RS
166
3.1.3
te
“that implementation of specification B complies
with A.”
Let's assume spec A is 62443-2-1, spec B is an
asset owner's security management system and
implementation C is the operation of a specific
plant and IACS which is in scope of B.
There are two levels of conformity here. The first
level is conformity of B with regards to A, i.e.
assessing whether B is a security management
system in conformity with -2-1. Per the scope
definition in this document, this is what his
document is to define.
The second level is the conformity of C with
regards to B, i.e. the enforcement and monitoring
of the security policy and procedures in the
security management system in a given
operation. That is already part of the common
PDCA cycle and integrated into -2-1 (i.e. the
conformity assessment of an ICS-SMS should
also check for a monitoring and continuous
improvement part). How the ICS-SMS is enforced
and monitored is up to the ICS-SMS to specify as
it needs to be context-specific to address the
particular risks the given IACS is exposed to.
Recommendations or even requirements may be
given in -2-1, but here they would effectively add
requirements to -2-1 through the backdoor!
Adjust the example to match the definition of
conformity as a relationship between two
specifications.
The definition of the noun includes indefinite
article “an” as follows:
“an observable property of an entity”
Change
39
TT
2
173
3.1.2
attribute
Type of comment:
1
ge = general
Ed
te = technical
Response by edit team
No change to document
Noted Verify the origin of
each definition
Accepted in principle. The
definition will be clarified
consistent with ISA/IEC
glossaries.
Note: the line number
refers to the IEC version.
(Line 182 in ISA)
See also 40RT
“an observable property of an entity”
Accepted
(this was already corrected
in the IEC draft)
ed = editorial
page 8 of 32
Based on ISO/IEC/CEN/CENELEC electronic balloting commenting template/version 2012-03
Do not change the structure (including column widths) of this
Due on June 10, 2014 to
Document:
Project: ISA99 ballot
comment form.
crobinson@isa.org::
ISA-dTR62443-1-3 (draft 6, edit 5)
closing June 10, 2014.
Do use line numbers if they are available in the document under review. Do use the two-letter comment type codes listed in the page footer.
Your
initials
Line
number
Clause/
Subclause
(e.g. 17)
(e.g. 3.1)
Paragraph/
Figure/
Table/
(e.g. P3, F21)
Type of
comment2
Comments
ISO/IEC Directives part 2 which specifies the
rules of the standards orders to exclude the
articles in the definition of the noun.
As this document is scheduled to be an IEC
standard, this document should also follow the
ISO/IEC Directives part 2.
40
TT
176
3.1.3
Compliance
Te
Proposed change
To
“observable property of an entity”
The definition seems to say
replace
B complies A
If B is a subset of A.
relation between two specifications, A and B, that
holds when specification A makes requirements
which are all fulfilled by specification B (when B
complies with A)
This suggests that if B is null then B is a subset of
A, therefore B complies A.
This is strange.
ISO/IEC IS 10746 seems to say in part 2 that
Response by edit team
Accepted in part. The
revised definition will
conform to ISA/IEC
glossaries
With
fulfilment of a specified requirement; adherence of
an entity to the requirements of one or more
specifications or standards
Adherence to the requirements is called
compliance.
See the below from ISO/IEC IS 10746-2
“Requirements for the necessary consistency of
one member of the family of ODP standards with
another (such as the RM-ODP) are established
during the standardization process. Adherence to
these requirements is called compliance.”
41
RS
2
206
3.1.11
Type of comment:
te
ge = general
te = technical
This description is rather a measurement of the
security posture, i.e. an absolute or relative
measurement of security assurance/confidence.
As defined above, conformance is the fulfilment
of requirements in a specification by an entity.
Change the definition to match the general
description of conformance. E.g.:
quantitative measure to evaluate the fulfilment of
the system security requirements by a given
system.
(Line 217 in ISA).
Accepted in principle.
Definitions in next draft will
be checked against the
ISA Glossary, IEC
Electropedia and ISO
Concept Database.
ed = editorial
page 9 of 32
Based on ISO/IEC/CEN/CENELEC electronic balloting commenting template/version 2012-03
Do not change the structure (including column widths) of this
Due on June 10, 2014 to
Document:
Project: ISA99 ballot
comment form.
crobinson@isa.org::
ISA-dTR62443-1-3 (draft 6, edit 5)
closing June 10, 2014.
Do use line numbers if they are available in the document under review. Do use the two-letter comment type codes listed in the page footer.
Your
initials
Line
number
Clause/
Subclause
(e.g. 17)
(e.g. 3.1)
Paragraph/
Figure/
Table/
(e.g. P3, F21)
Type of
comment2
Comments
Proposed change
Response by edit team
42
jw
207
3.1.8
TE
Ability of an IACS organization, process
entity or system to resist being affected by
disruptions
Add: “and recovery”
Accepted in principle.
Definitions in next draft will
be checked against the
ISA Glossary, IEC
Electropedia and ISO
Concept Database.
43
JBN
217
3.1.10
te
The order of priority of security objectives is
shown as “availability, integrity, confidentiality”.
However, integrity should be higher priority than
availability because generally sending the wrong
value is usually worse than sending no value for
an IACS
Change to “integrity, availability, confidentiality”
Accepted.
A note to entry will be
added to identify this
change since common
usage is “confidentiality,
integrity, availability”. It
would be preferred that the
ISA definition of the term
be changed as well,
however the use of the
note may avoid this being
required.
44
EE
218
te
Or the system has been placed in such a state
that an unauthorized actor can cause such an
event.
Add to definition
Accept in principle.
(Definition shown is as in
the ISA99 Master
Glossary)
45
RS
233
4.1
ed
The reference to ISO 14253-1 is in the
Introduction not in the Foreword.
Replace Foreword with Introduction
(Line 246 in ISA)
Accept in principle. This
will be rewritten in the next
draft.
46
RS
237
4.2
te
So the checklist of table 1is the litmus test for
quality metrics? Why would this checklist change
with the publication of new parts of the 62443
series? There will be new metrics for the newly
published requirements for sure, but the quality
criteria for those new metrics should be the same,
shouldn't they?
Strike the sentence beginning with “Many of the
documents”
(Line 253 in ISA)
Accept in principle. Rather
than merely striking the
cited sentence, this
passage will be rewritten
for the next draft.
2
h.1
compromise
Type of comment:
ge = general
te = technical
ed = editorial
page 10 of 32
Based on ISO/IEC/CEN/CENELEC electronic balloting commenting template/version 2012-03
Do not change the structure (including column widths) of this
Due on June 10, 2014 to
Document:
Project: ISA99 ballot
comment form.
crobinson@isa.org::
ISA-dTR62443-1-3 (draft 6, edit 5)
closing June 10, 2014.
Do use line numbers if they are available in the document under review. Do use the two-letter comment type codes listed in the page footer.
Your
initials
Line
number
Clause/
Subclause
(e.g. 17)
(e.g. 3.1)
Paragraph/
Figure/
Table/
(e.g. P3, F21)
Type of
comment2
Comments
Proposed change
Response by edit team
te
Change ‘resist being affected by disruptions’ to
‘maintain critical services when system capability
degrades’
Replace text
(Line 207 in ISA?)
Accepted in part. Will
revise to match the
definition of ‘resilience’
currently in the IEC
Glossary. See 42jw
te
None of the metrics specified in table 2 meet this
criterion! Where is the association of metrics to
requirements from the other parts of 62443 series
to which the metrics measure compliance?
Provide mapping of the metrics to requirements
(Line 256 in ISA)
Accepted in principle.
It is expected that
extensive revisions to this
Table 1 will be made in the
next draft.
Ed
Several abbreviations are not used, or only used
one (when the abbreviation is explained). These
should be removed.
Remove AIC, ASTM, SR, SuC, and ToE
Accepted in principle. The
next draft may result in
additional (or fewer) uses
of each term.
4.3
te
“Table 2 defines the cybersecurity conformance
metrics (CM) that satisfy the criteria specified in
Table 1.”
No, they don’t. See above - none of entries in
table 2 meet the third criterion of being
associated with requirements!
Provide mapping of the metrics to requirements
(Line 258 in ISA)
Accepted in principle.
It is expected that
extensive revisions will be
made to the information in
Table 2 in the next draft.
243
3.3
Conventions
Te
There is no usage of “local matter.”
Delete the lines 243-245.
Accepted
52
ECC
248
4.1
1
ED
The term “forward” (sic) is mis-spelled. The
proper term for this context is “Foreword.”
Correct term
53
RS
250
4.3
Table 2
te
None of these metrics are associated (explicitly)
to requirements from other documents in the
62443 series. Hence they can't be used to
measure conformance with these requirements or
conformity with these specifications.
Provide mapping of the metrics to requirements
Specifically for metrics mapped to requirements
from -3-3: make sure that the evaluation of the
system capability can be done in a product type
test and doesn’t require a live operation of the
47
EE
239
h.1
resilience
48
RS
240
4.2
49
DLB
242
50
RS
242
51
TT
2
Type of comment:
Table 1, row
labelled 3
(in the
Priority
column)
ge = general
te = technical
Accepted
(Line 266 in ISA)
Accepted in principle
See 50RS
ed = editorial
page 11 of 32
Based on ISO/IEC/CEN/CENELEC electronic balloting commenting template/version 2012-03
Do not change the structure (including column widths) of this
Due on June 10, 2014 to
Document:
Project: ISA99 ballot
comment form.
crobinson@isa.org::
ISA-dTR62443-1-3 (draft 6, edit 5)
closing June 10, 2014.
Do use line numbers if they are available in the document under review. Do use the two-letter comment type codes listed in the page footer.
Your
initials
Line
number
Clause/
Subclause
(e.g. 17)
(e.g. 3.1)
54
JBN
251
5
55
RS
252
5
Paragraph/
Figure/
Table/
(e.g. P3, F21)
Type of
comment2
te
Comments
Proposed change
Response by edit team
Furthermore, all metrics count the number of
occurrences of certain events (some as a
percentage of occurrences of a specific type of
event in a total of occurrences of more general
events) or a time interval between two
occurrences of events. Measuring these metrics
requires a system in operation, thus they can't be
used to measure conformity of a product with the
capability requirements denied in -3-3.
product in an IACS. Metrics that involve counting
occurrences of certain events or measuring time
between such occurrences do not meet this
criterion.
It is not clear to me how this clause relates to
security metrics. This section describes a set of
supplier and operator responsibilities
(requirements) that must be specified in other
62443 documents, not this one.
Delete Clause 5
Accepted
The Jericho Forum has defined 11
commandments for security in de-parameterized
systems. They are not specifically related to
IACS. In fact the 62443 series specifically
recommends to setup an IACS with multiple
perimeters. The text on the second column is a
modification of the commandments, in some
cases major modification.
Remove clause 5
Accepted in principle. This
section is being
substantially rewritten in
the draft under
development
Change the URL accordingly, or rather accept the
next comment.
(Line 268 in ISA)
Accepted in principle. All
URLs used in the next
draft will be confirmed,
The commandments are irrelevant for conformity
/ compliance metrics with regards to the IEC
62443 specifications. Thus they have no place in
this document.
One could desire to map the requirements from
the 62443 series to the 11 commandments, but
that is certainly out of scope for this document!!!
56
RS
2
252
5
Type of comment:
ed
ge = general
te = technical
The URL given in reference 11 is no longer
accurate. The new URL should be
https://collaboration.opengroup.org/jericho.
ed = editorial
page 12 of 32
Based on ISO/IEC/CEN/CENELEC electronic balloting commenting template/version 2012-03
Do not change the structure (including column widths) of this
Due on June 10, 2014 to
Document:
Project: ISA99 ballot
comment form.
crobinson@isa.org::
ISA-dTR62443-1-3 (draft 6, edit 5)
closing June 10, 2014.
Do use line numbers if they are available in the document under review. Do use the two-letter comment type codes listed in the page footer.
Your
initials
Line
number
Clause/
Subclause
(e.g. 17)
(e.g. 3.1)
57
EJH
255
58
WJC
256
59
LcS
Paragraph/
Figure/
Table/
(e.g. P3, F21)
Type of
comment2
Table 1,
Priority 1
Proposed change
Response by edit team
Do not require meeting specification listed
elsewhere. If you want the user to meet
specifications, list them here.
Remove this requirement. List all requirements to
be met.
Accepted in principle. All
requirements contained in
the revised document will
be listed.
See 48RS
Table 1 - 1
ge
Seems odd to start your list of Prioritized checklist
with a reference to a book that is in the Other
References section [25]
Since this is a technical report I guess it is OK
No suggested change since I have not read [25]
Noted.
Table 1 will be extensively
revised, see 48RS
256
Table 1
mE
In Priority 1 Remark 3: “possible” may have
excessive expense impacts
Replace word “possible” with “practical”
Accepted, but see 48RS.
60
LcS
256
Table 1
Note 4
mE
In Priority 1 Note 4: “possible” may have
excessive expense impacts
Replace word “possible” with “practical”
Accepted, see 59LCS
61
jw
256
Table 1
TE
Note 5 is COTS-focused.
Remove Note 5
This comment was not
understood. Table 1 will
be extensively revised in
the next draft, see 48RS
62
MF
256
Table 1
te
Why is this book referenced? What analysis was
done to ensure that this book is appropriate and
as a standalone provides the criteria?
Noted. See 58WJC
ISA99, at its Florida
meeting a few years ago,
approved the use of the
Jaquith criteria for
evaluating validity of
metrics to be developed for
62443-1-3. See also
64DLB
62
MF
256
Table 1
NOTE 1 is actually Priority 2 on the next page
Noted. See 48RS
63
MF
256
Table 1
2
4.2
Comments
Type of comment:
ge = general
te
te = technical
NOTE 5 - I am unsure how special attention
should be given to unknown vulnerabilities
sometimes referred to as zero day events. Zero
day events is being used possibly incorrectly here
Replace the word events with vulnerabilities, as in
the context of cyber security they mean two very
different things
Accepted in principle. The
redraft of 62443-1-3 will
either clarify or remove
Note 5. See 48RS
ed = editorial
page 13 of 32
Based on ISO/IEC/CEN/CENELEC electronic balloting commenting template/version 2012-03
Do not change the structure (including column widths) of this
Due on June 10, 2014 to
Document:
Project: ISA99 ballot
comment form.
crobinson@isa.org::
ISA-dTR62443-1-3 (draft 6, edit 5)
closing June 10, 2014.
Do use line numbers if they are available in the document under review. Do use the two-letter comment type codes listed in the page footer.
Your
initials
64
DLB
2
Line
number
Clause/
Subclause
(e.g. 17)
(e.g. 3.1)
Paragraph/
Figure/
Table/
(e.g. P3, F21)
256
Type of comment:
Type of
comment2
TE
ge = general
te = technical
Comments
Proposed change
The description “Metrics shall satisfy the criteria
specified in [25}, is a reference to a non ISA, IEC,
or ISO document. If this is to be used, then the
list of criteria must be included in the standard.
Pull the criteria from the book “Jaquith, A.,
Security Metrics – Replacing Fear, Uncertainty,
and Doubt, Addison-Wesley, 2007”
Or see ISO 22400.01 with the following list:
A good KPI has certain criteria which ensure its
usefulness in achieving various goals in the
manufacturing operation. The criteria are listed
below along with the process for performing each
individual measurement.
a)
Aligned: The KPI is aligned to the
degree to which the KPI affects change in relevant
higher-level KPIs, where alignment implies a high
ratio of the percent improvement (assuming
positive impact) in important higher-level metrics
to the percent improvement in a KPI (or KPI set),
given no other changes in the system.
b)
Balanced: The extent to which a KPI is
balanced within its chosen set of KPIs.
c)
Standardized: The KPI is standardized
to the extent to which a standard for the KPI exists
and that standard is correct, complete, and
unambiguous; the standard can be plant-wide,
corporate-wide, or industry-wide.
d)
Valid: The KPI is valid to the extent of
the syntactic (i.e. grammar) and semantic (i.e.
meaning) compliance between the operational
definition of the KPI and the standard definition. If
no standard exists, then validity is zero.
e)
Quantifiable: The KPI is quantifiable to
the extent to which the value of the KPI can be
numerically specified; there is no penalty for the
presence of uncertainty, as long as the uncertainty
also can be quantified.
f)
Accurate: The KPI is accurate to the
extent to which the measured value of the KPI is
close to the true value, where a departure from the
Response by edit team
Accepted in principle.
See 62MF.
The redraft of 62443-1-3
will list the specific criteria
ed = editorial
page 14 of 32
Based on ISO/IEC/CEN/CENELEC electronic balloting commenting template/version 2012-03
Do not change the structure (including column widths) of this
Due on June 10, 2014 to
Document:
Project: ISA99 ballot
comment form.
crobinson@isa.org::
ISA-dTR62443-1-3 (draft 6, edit 5)
closing June 10, 2014.
Do use line numbers if they are available in the document under review. Do use the two-letter comment type codes listed in the page footer.
Your
initials
Line
number
Clause/
Subclause
(e.g. 17)
(e.g. 3.1)
Paragraph/
Figure/
Table/
(e.g. P3, F21)
Type of
comment2
Comments
Proposed change
Response by edit team
true value can be affected by poor data quality,
poor accessibility to the measurement location, or
the presence of substandard measurement
devices and methods.
g)
Timely: The KPI is timely to the extent it
is computed and accessible in real-time, where
real-time depends on the operational context.
h)
Predictive: The KPI is predictive to
extent to which a KPI is able to predict nonsteady-state operations.
i)
Actionable: The KPI is actionable to the
extent to which a team responsible for the KPI has
the knowledge, ability, and authority to improve
the actual value of the KPI within their own
process.
j)
Trackable: The KPI is trackable to the
extent to which the appropriate steps to take to fix
a problem are known, documented, and
accessible, where the particular problem is
indicated by particular values or temporal trends of
the KPI.
k)
Relevant: The KPI is relevant to the
extent to which the KPI enables performance
improvement in the target operation, demonstrates
real-time performance, allows the accurate
prediction of future events, and reveals a record of
the past performance valuable for analysis and
feedback control.
l)
Correct: The KPI is correct to the extent
that, compared to the standard definition (if one
exists), the calculation required to compute the
value of the KPI compared to the standard
definition (if one exists), has no errors with respect
to the standard definition.
m)
Complete: The KPI is complete to the
extent that, compared to the standard definition (if
one exists), the definition of the KPI, and the
2
Type of comment:
ge = general
te = technical
ed = editorial
page 15 of 32
Based on ISO/IEC/CEN/CENELEC electronic balloting commenting template/version 2012-03
Do not change the structure (including column widths) of this
Due on June 10, 2014 to
Document:
Project: ISA99 ballot
comment form.
crobinson@isa.org::
ISA-dTR62443-1-3 (draft 6, edit 5)
closing June 10, 2014.
Do use line numbers if they are available in the document under review. Do use the two-letter comment type codes listed in the page footer.
Your
initials
Line
number
Clause/
Subclause
(e.g. 17)
(e.g. 3.1)
Paragraph/
Figure/
Table/
(e.g. P3, F21)
Type of
comment2
Comments
Proposed change
Response by edit team
calculation required to compute the value of the
KPI, covers all parts, and no more, of the standard
definition.
n)
Unambiguous: The KPI is unambiguous
to the extent that the syntax (i.e. grammar) and
semantics (i.e. meaning) in the definition of the
KPI lacks ambiguity or uncertainty.
o)
Automated: The KPI is automated to
the extent that KPI collection, transfer,
computation, implementation, and reporting are
automated.
p)
Buy-in: The KPI has buy-in to the extent
that the team responsible for the target operation,
as well as teams responsible for both upper and
lower level KPIs, are willing to support the use of
the KPI and perform the tasks necessary to
achieve target values for the KPI; includes
difficulty of obtaining official approval by
management for the KPI.
q)
Documented: The KPI is documented
to the extent that the documented instructions for
implementation of a KPI are up-to-date, correct,
complete, and unambiguous, including instructions
on how to compute the KPI, what measurements
are necessary for its computation, and what
actions to take for different KPI values.
r)
Comparable: The KPI is comparable to
the extent that means are defined to reference
supporting measurements over a period of time,
and a normalizing factor to express the indicator in
absolute terms with appropriate units of measure.
s)
Understandable: The KPI is
understandable to the extent that the meaning of
the KPI is comprehended by team members,
management, and customers, particularly with
respect to corporate goals.
2
Type of comment:
ge = general
te = technical
ed = editorial
page 16 of 32
Based on ISO/IEC/CEN/CENELEC electronic balloting commenting template/version 2012-03
Do not change the structure (including column widths) of this
Due on June 10, 2014 to
Document:
Project: ISA99 ballot
comment form.
crobinson@isa.org::
ISA-dTR62443-1-3 (draft 6, edit 5)
closing June 10, 2014.
Do use line numbers if they are available in the document under review. Do use the two-letter comment type codes listed in the page footer.
Your
initials
Line
number
Clause/
Subclause
(e.g. 17)
(e.g. 3.1)
Paragraph/
Figure/
Table/
(e.g. P3, F21)
Type of
comment2
Comments
Proposed change
Response by edit team
t)
Inexpensive: The KPI is inexpensive to
the extent that the cost of measuring, computing,
and reporting the KPI is low.
65
DLB
256
66
TT
256
67
KPS
256
68
ZT
256
69
WJC
257
2
Table 1
4.2
4.3
Type of comment:
Description
TE
In the remarks, this contains the text “b) The
models and terminology in this document need to
be aligned with ISA-62443-1-1.”
Remove the remarks. These are editor notes, not
something that are actionable by the implementer.
Accepted in principle. The
redraft of 62443-1-3 will
either drop this note, or
revise to make clear that
“this document has been
aligned with
ISA-62443-1-1.”
Te
ISA standard should be public, and should not be
used to advertise a particular author or book.
Replace
Therefore the following statement is not
appropriate:
Metrics shall satisfy the criteria specified in Error!
Reference source not found.
Metrics shall satisfy the criteria specified in Error!
Reference source not found.
With
Accepted in part. Metrics
should be measurable, but
must also meet additional
criteria, and these should
be listed and justified
See 62MF
Metrics shall be measurable.
Table 1
Te
In the prioritized checklist listed in Priority 1 is
NOTE 5 which states “Special attention should be
given to unknown vulnerabilities, sometimes
referred to as zero-day events.” There are two
problems with this note: 1) How can you give
special attention to something that is unknown;
and 2) Once an event occurs it is no longer zeroday. Zero day refers to vulnerability that has not
turned into an event yet.
Noted See 63MF
Table 1
ed
The “Description” for priority 1 lists only the
reference number [25]. To be more useful, the
general categories should be listed in the table,
with a follow on reference
Noted See 64DLB
Title
ge
Since Priority 1 Note 2 mentions that the use of
High, Medium and Low should be avoided,
should you call this section Priority 1
ge = general
te = technical
Change title to use the term Priority 1
Accepted in part. The
information in Table 1 will
be revised for the next
draft, and the title of this
ed = editorial
page 17 of 32
Based on ISO/IEC/CEN/CENELEC electronic balloting commenting template/version 2012-03
Do not change the structure (including column widths) of this
Due on June 10, 2014 to
Document:
Project: ISA99 ballot
comment form.
crobinson@isa.org::
ISA-dTR62443-1-3 (draft 6, edit 5)
closing June 10, 2014.
Do use line numbers if they are available in the document under review. Do use the two-letter comment type codes listed in the page footer.
Your
initials
Line
number
Clause/
Subclause
(e.g. 17)
(e.g. 3.1)
Paragraph/
Figure/
Table/
(e.g. P3, F21)
Type of
comment2
Comments
Proposed change
Cybersecurity ...? I know it is picky but we should
try to be consistent. Or am I crossing terms?
70
BSO
259
GE
Table 2
71
JAC
260
4.3
P12
72
RS
261
6
73
JTL
266
74
JBN
266
2
Type of comment:
Table 2
ge = general
Response by edit team
clause will be consistent
with the terminology of the
clause.
Measurements in Table 1 seem to require a
leap of faith in terms of priority assessment
and coverage as a basis for managing all
IACS risks
Perhaps benchmark justification of proposed
metrics with existing frameworks (DHS catalog of
controls, ES-C2M2, NIST CSF, OSSTMM, SANS
Top 20, etc)
Accepted in principle.
Mapping to the frameworks
mentioned may be beyond
the new approved scope.
The information in Table 2
will be revised in the next
draft, see also 50RS.
TE
It is not practical to develop a set of metrics that
will manage “all” risks.
Remove the word “all”
Accepted
te
“Given a target of evaluation (ToE), operational
metrics developed from the design principles in
this document need to be tailored to fit their
operational environment.”
That is exactly the part of setting up a monitoring
and continuous improvement system in an ICSSMS conforming to -2-1. The metrics in this
document should describe how to check that a
given ICS-SMS meets the requirements from -21, not restate the requirements related to
monitoring and continuous improvement!
te
do not agree that the only measure should be on
the “source” IP address. Believe that it is actually
more important to understand repeated “target” IP
addresses as this could be an indicator of
additional latent security issues.
Create a new CM that would consider access
attempts associated with the destination address
recorded by each access point.
Accepted in principle.
Both source and
destination of an access
attempt are important
te
The desired behaviour or action for each metric is
not clearly stated.
Add a column that describes the desired
behaviour or action for each security metric
Accepted in principle.
Desired behavior of
metrics defined in the next
draft will be described.
te = technical
(Line 277 in ISA)
Accepted in principle.
The next draft will refer to
other documents which
define the requirements
this document will define
metrics associated with
such requirements.
[WG12 should determine
the extent to which this
document is mapped to -21.]
ed = editorial
page 18 of 32
Based on ISO/IEC/CEN/CENELEC electronic balloting commenting template/version 2012-03
Do not change the structure (including column widths) of this
Due on June 10, 2014 to
Document:
Project: ISA99 ballot
comment form.
crobinson@isa.org::
ISA-dTR62443-1-3 (draft 6, edit 5)
closing June 10, 2014.
Do use line numbers if they are available in the document under review. Do use the two-letter comment type codes listed in the page footer.
Your
initials
Line
number
Clause/
Subclause
(e.g. 17)
(e.g. 3.1)
Paragraph/
Figure/
Table/
(e.g. P3, F21)
Type of
comment2
Comments
Proposed change
Response by edit team
75
JBN
266
CM.1
Table 2
te
It is not clear why the total number of access
attempts is relevant to security or is actionable.
Delete CM.1
Accepted in principle;
rewrite CM1 rather than
delete it
76
JBN
266
CM.3
Table 2
te
Not sure how you would measure the percentage
of traffic that fails authentication. Most traffic is
not authenticated; authentication occurs at the
domain/host level.
Change the metric from “percentage of traffic” to
“number of failed authentication attempts” or
delete this metric
Accepted
77
JBN
266
CM.4.1
Table 2
te
Not sure what the desired behaviour or action is
for this metric.
Delete CM.4.1
Accepted
78
JBN
266
CM.5
Table 2
te
Separation of duties is defined by the Owner in
their governance policy
Add “in accordance with user-defined policies”
Accepted
79
MH
266
Table 2
te
It may be worth considering the addition of certain
metrics which allow us to measure the actual
system against the documentation at system FAT
and commissioning stages.
Add metric, inventory completeness- measure by
scanning tools compare against documented
inventory.
Accepted in principle.
80
MH
266
Table 2
te
Same as above
Add metric, accessible network services within the
IACS versus those that are documented as
required
Accepted in principle
81
MH
266
Table 2
te
Same as above
Add metric, to measure data flows between
inventory objects that define the IACS. Compare
against the documentation to identify gaps.
Accepted in principle
82
MH
266
Table 2
te
Additional to CM.11-
Add metric to CM.11 which measures the number
of instances of roll back from patching due to the
IACS not maintaining functionality or reliability due
to patching. This will give metrics for how fragile
or otherwise a given IACS is.
Accepted in principle
83
SVJ
266
T2
ge
Please provide clear definition for firewall log and
it’s access location. In general, the firewall log
can be resided in the respective devices such as
IACS computer, dedicated network switch etc.
2
4.3
Type of comment:
ge = general
te = technical
Accepted in principle.
Alternative locations may
be discussed.
ed = editorial
page 19 of 32
Based on ISO/IEC/CEN/CENELEC electronic balloting commenting template/version 2012-03
Do not change the structure (including column widths) of this
Due on June 10, 2014 to
Document:
Project: ISA99 ballot
comment form.
crobinson@isa.org::
ISA-dTR62443-1-3 (draft 6, edit 5)
closing June 10, 2014.
Do use line numbers if they are available in the document under review. Do use the two-letter comment type codes listed in the page footer.
Your
initials
Line
number
Clause/
Subclause
(e.g. 17)
(e.g. 3.1)
Paragraph/
Figure/
Table/
(e.g. P3, F21)
Type of
comment2
Comments
Proposed change
Response by edit team
84
jw
266
CM3.1
Table 2
ED
Number of authentication miss-matches between
authentication entities.
Spelling error
Accepted. Use
‘mismatches’
85
jw
266
CM11
Table 2
TE
Number of security incidents reported that have
been traced to a delay in deploying patches.
Remove: “that have been traced to a delay in
deploying patches”
Accepted in principle.
The number of security
incidents is important; the
number of incidents of
specific types may also be
important.
86
jw
266
Table 2
TE
No mention of security affecting operations
87
MF
266
Table 2
te
CM.1 - Can this be the number of attempts that
are good, bad or both?
Needs clarity
Accepted.
It could be whichever
qualifier is relevant.
88
MF
266
Table 2
te
Is IED the most appropriate acronym to be used
considering the audience?
Clarity – PLC? Device? Other word?
Comment rejected. IED
(Intelligent Electronic
Device) is an accepted
term used to describe
microprocessor-based
Noted
controllers
89
MF
266
Table 2
te
CM.3.2 - although the concept of tracking the
number of compromises or violations is
interesting, to ensure how they get measured is
unrealistic? Looking at the common data source
parallel to this entry am unsure of how the metrics
are going to be collected
Since these conformance metrics seem to support
hierarchical requirement to measure the
percentage of traffic that fail authentication
verification I think he needs to be a change from
percentage to some other measurable. If
percentage is the parent metric I might suggest
creating a conformance metric that measures if
and when the percentage of traffic that fails
authentication verification is either too high or too
low outside of an expected limit.
Accepted in principle;
Note: there is no mention
of percentage in the metric
description, only number of
compromises/violations.
90
MF
266
Table 2
te
CM.4.1 - measuring percentage of traffic
encrypted seems like an odd metric. Either the
traffic is going to be encrypted or it is not the
Replace % with other metric or define encryption
as either enabled or not enabled in appropriate
areas
Accepted in principle
2
Type of comment:
ge = general
te = technical
ed = editorial
page 20 of 32
Based on ISO/IEC/CEN/CENELEC electronic balloting commenting template/version 2012-03
Do not change the structure (including column widths) of this
Due on June 10, 2014 to
Document:
Project: ISA99 ballot
comment form.
crobinson@isa.org::
ISA-dTR62443-1-3 (draft 6, edit 5)
closing June 10, 2014.
Do use line numbers if they are available in the document under review. Do use the two-letter comment type codes listed in the page footer.
Your
initials
Line
number
Clause/
Subclause
(e.g. 17)
(e.g. 3.1)
Paragraph/
Figure/
Table/
(e.g. P3, F21)
Type of
comment2
Comments
Proposed change
Response by edit team
percentage is going to vary tremendously
otherwise
91
MF
266
92
DLB
266
93
DLB
266
2
Type of comment:
Table 2
te
CM.6 - the number of dropped a rejected packets
may have nothing to do with security and the
inclusion of activities to measure this from the
suggested data sources would require an
extensive investment. Out of range, corrupted,
replay, or out of sequence errors are common in
industrial automation and I’m unsure how
appropriate thresholds could be developed to
suggest that these datasets could be an indicator
of compromise or some other security problem
Working on it to try and create a chage
Accepted in principle
TE
Many of the metrics are “number of …”, but they
don’t specify a time frame or a rate.
Modify them as follows:
Number of access attempts associated with a
source address recorded by each access point, for
a specified time rage, such as per shift, day, or
week.
See ISO 22400-1:
a)
The timing context information should
specify the frequency of KPI calculation as
following:
1)
real-time (as the process is occurring):
after each new data acquisition event,
2)
periodically: done at a certain interval,
e.g., one time per day, or
3)
on-demand: after a specific data
selection request.
Accepted in principle.
Time intervals will be
specifically stated in the
revised draft.
Consider using the ISO 22400.02 and ISO
22400.01 as a template for defining KPIs and
Metrics. The ISO standard includes the actual
calculations and variable required to perform the
calculations. While this may be overkill for some
of these, it does remove all ambiguity.
ge = general
te = technical
Noted. This possibility will
be investigated during the
redraft
ed = editorial
page 21 of 32
Based on ISO/IEC/CEN/CENELEC electronic balloting commenting template/version 2012-03
Do not change the structure (including column widths) of this
Due on June 10, 2014 to
Document:
Project: ISA99 ballot
comment form.
crobinson@isa.org::
ISA-dTR62443-1-3 (draft 6, edit 5)
closing June 10, 2014.
Do use line numbers if they are available in the document under review. Do use the two-letter comment type codes listed in the page footer.
Your
initials
Line
number
Clause/
Subclause
(e.g. 17)
(e.g. 3.1)
Paragraph/
Figure/
Table/
(e.g. P3, F21)
Type of
comment2
Comments
Proposed change
Response by edit team
94
DLB
266
CM.4.1
Is this percentage on the total traffic or on the
percentage of messages? This sort of question is
why the model in ISO 22400 helps remove the
ambiguity.
Change to “Percentage of messages encrypted in
…”
Accepted in principle.
This possibility will be
investigated during the
redraft
95
DLB
266
CM.5
No definition of what “separation of duty
violations” really means
Add a note for clarification, this is not a commonly
used phrase outside of the military.
Accepted in principle
Consider “separation of
responsibility”
96
MN
266
4.3
Table 2
Te
The introduction (line 117) states “there is not a
one-size-fits-all set of cybersecurity practices”.
Yet this table is exactly that.
Revise technical approach in Clause 4 to achieve
the stated condition of line 117.
Accepted in principle. The
revised draft will pertain to
-2-4, with description of
how it will tie to future
approved sections.
97
TT
266
Table 2
Conformanc
e metric
Te
It is good to see typical concrete examples of
high-priority security mectircs. But it does not
suggest what metrics are appropriate for the
entire ISA-62443 series.
Either
1. provide the high-level abstract security metrics.
Accepted in principle. This
version of Part -1-3 will not
include metrics that pertain
to standards that have not
yet been approved.
98
KPS
266
4.3
Table 2
Te
Or
2. provide the metrics which can be easily traced
to the ISA 62443-*-* series requirements.
Throughout the table the common data source is
listed as “Firewall logs, network device (smart
routers and switches) logs, and IECs with
embedded challenge/response authentication
capabilities”. This leaves out many of the
components that make up and IACS. I don’t see
anything about host logs, domain logs,
application logs and logs from embedded
devices. All are important but the common data
source implies that they are not needed for
metrics.
Noted.
[How specific should
WG12 be in listing these
sources?]
99
KPS
266
4.3
Table 2
Te
CM ID CM.1 – local logs on what? It also implies
the only important embedded device is an IED.
Access attempts are made to everything.
Noted
100
266
4.3
Table 2
Te
CM ID CM 4.2 – the criteria for the metrics is that
they be automated where possible. This metric
Noted
2
Type of comment:
ge = general
te = technical
ed = editorial
page 22 of 32
Based on ISO/IEC/CEN/CENELEC electronic balloting commenting template/version 2012-03
Do not change the structure (including column widths) of this
Due on June 10, 2014 to
Document:
Project: ISA99 ballot
comment form.
crobinson@isa.org::
ISA-dTR62443-1-3 (draft 6, edit 5)
closing June 10, 2014.
Do use line numbers if they are available in the document under review. Do use the two-letter comment type codes listed in the page footer.
Your
initials
Line
number
Clause/
Subclause
(e.g. 17)
(e.g. 3.1)
Paragraph/
Figure/
Table/
(e.g. P3, F21)
Type of
comment2
KPS
Comments
Proposed change
Response by edit team
may not be able to be measured using automated
mechanisms.
101
KPS
266
4.2
Table 2
Te
CM ID CM.9 – The time delay as defined cannot
be obtained from the common data sources listed
for the requirement. The common data sources
contribute to the determination of the time delay
but the requirement is for the delay from detection
until the entity responsible is notified and if that
entity responsible is a person then all that might
be in logs that aren’t in the listed logs in the
specification is when something like a SMTP
message or some other message was sent.
Then you need to logs of when it was actually
sent from other sources.
Noted
102
KPS
266
4.2
Table 2
Te
CM ID CM.10 – time to recover state won’t be
able to be measured using only the common data
sources listed.
Noted
103
KPS
266
4.2
Table 2
Te
CM ID CM.11 – security incidents reported will
most likely not be only in the logs.
Noted
104
JAC
266
4.3
P12
TE
Table 2 is a good starting list of IACS cybersecurity
metrics. However, it is far from complete. Most of
the metrics are related to events that can be
detected and reported by network devices (e.g.
firewalls, network devices). Other components in
an IACS can provide valuable information that aid
in the identification of problems.
2
Type of comment:
ge = general
te = technical
Develop additional conformance metrics with
consideration given to information that can be
obtained from other IACS components such as
controllers and servers/clients.
Accepted in principle.
Metrics defined in the next
draft of 62443-1-3 will be
relevant to the
requirements stated in
62443-2-4. Later versions
of Part -1-3 will include
relevancy to those
additional parts that have
been approved at that
time.
ed = editorial
page 23 of 32
Based on ISO/IEC/CEN/CENELEC electronic balloting commenting template/version 2012-03
Do not change the structure (including column widths) of this
Due on June 10, 2014 to
Document:
Project: ISA99 ballot
comment form.
crobinson@isa.org::
ISA-dTR62443-1-3 (draft 6, edit 5)
closing June 10, 2014.
Do use line numbers if they are available in the document under review. Do use the two-letter comment type codes listed in the page footer.
Your
initials
105
TDG
Line
number
Clause/
Subclause
(e.g. 17)
(e.g. 3.1)
266
Paragraph/
Figure/
Table/
(e.g. P3, F21)
4.3
Type of
comment2
GE
Comments
Proposed change
Response by edit team
When I think of Conformance, I think of measuring
the system’s ability to achieve security objectives.
I want to measure something I have control over to
fix/correct. A number of the conformance metrics
in Table 2 seem like they are external factors
outside my SuC that I have no control over and
don’t help me measure how well my system is
meeting expectations. For example – CM.6 This
seems to more of a measure of the external entity
rather than the SuC. I have no controller over what
an external entity sends me. Why do I want to
make this a high priority conformance metric?
CM.1 – How does measuring the number of times
someone from an external device attempted to
access my IACS tell me how well I’m achieving my
security objective of protecting my IACS? The %
of times my SuC successfully rejected
unauthorized requests makes sense to me as a
security conformance metric.
I recommend re looking at the metrics based upon
the ToE and the boundaries for that SuC. We
may be interested in metrics about what is
happening at the boundary of our SuC, but they
may not be good measures of how well security is
being maintained within the SuC. I think metrics
on external factors should not be conformance
metrics of the SuC.
Accepted in part.
The next draft of 62443-13 will incorporate
considerations for
establishing an adequate
set of security metrics, with
the caveat that a complete
set of metrics applicable to
every IACS is beyond the
scope of the document.
I think we should be measuring how well the SuC
handles external situations that knock on the door
of the SuC or measure how well we are doing
within the SuC. For example – CM.3 makes sense
to measure if the traffic originates from within the
SuC. However if it originates from an external
source for which I have no control over, then I want
to know how well my SuC rejected the traffic
without unacceptable SuC degradation.
106
DT
2
266
CM.4.2
Type of comment:
T2
ge = general
TE
te = technical
Not sure how this would be gathered in an
automated fashion.
Accepted in part. The
rewrite will provide detail
relevant to Part -2-4 and
consistent with the
approved charter and
scope.
ed = editorial
page 24 of 32
Based on ISO/IEC/CEN/CENELEC electronic balloting commenting template/version 2012-03
Do not change the structure (including column widths) of this
Due on June 10, 2014 to
Document:
Project: ISA99 ballot
comment form.
crobinson@isa.org::
ISA-dTR62443-1-3 (draft 6, edit 5)
closing June 10, 2014.
Do use line numbers if they are available in the document under review. Do use the two-letter comment type codes listed in the page footer.
Your
initials
Line
number
Clause/
Subclause
(e.g. 17)
(e.g. 3.1)
Type of
comment2
Comments
Proposed change
Response by edit team
T2
TE
Not sure how this would be gathered in a manual
or automated fashion. This metric does not appear
to provide any guidance on how to collect. I don’t
see being able to determine the value of this even
technically possible.
Please provide an example of the use-case and
how it could be collected manually/automated.
Accepted in part. The
redraft will provide detail
relevant to Part -2-4 and
consistent with the
approved charter and
scope.
107
DT
266
108
DT
266
T2
TE
Metrics appear to overlook many of the 7
Foundational Requirements and sub-requirements
(e.g., malicious software prevention, use control).
For many of the 62443-3-3 requirements, there
could be metrics developed. For example:
Percentage of systems that support
antivirus. Percentage of systems with
antivirus installed. Percentage of systems
with up to date antivirus definitions.
Count of listening TCP/UDP ports per
device. Percentage of ports that are
required/documented/exposed etc.
Percentage of devices that have been
vulnerability scanned in the last
180/365/700 days.
Accepted in part. The
redraft will provide detail
relevant to Part -2-4 and
consistent with the
approved charter and
scope.
109
DT
266
T2
TE
There are no patch management related metrics.
Not sure if this is in scope of the 1-3 document.
TR62443-2-3 Clauses 5 and 6 contain
requirements that could be used to develop
cardinal value metrics related to the count of
patches at each stage of the patch management
lifecycle.
Accepted in part.
Development of metrics for
patch management is
applicable to Clause 5.11
of the new version of
ISA62443-1-3.
110
DT
266
T2
TE
There are no training metrics. Not sure if this is in
scope of the 1-3 document.
For example:
Count of personnel will logical, physical,
or remote access to the IACS.
Percentage of personnel with security
awareness training in the last X days.
Accepted in part.
Development of metrics for
training is beyond the
scope of this version of
ISA62443-1-3.
111
Ek
267
Who is “operator” and who is “supplier”
Terms shall be used as in other ISA62443 doc’s. I
guess this is “asset owner”, “system integrator”,
“system vendor”
Accepted in principle. If
any of these terms are
used in the analysis of
ISA62443-2-4, the
2
CM.5
Paragraph/
Figure/
Table/
(e.g. P3, F21)
5
Type of comment:
ge = general
te = technical
ed = editorial
page 25 of 32
Based on ISO/IEC/CEN/CENELEC electronic balloting commenting template/version 2012-03
Do not change the structure (including column widths) of this
Due on June 10, 2014 to
Document:
Project: ISA99 ballot
comment form.
crobinson@isa.org::
ISA-dTR62443-1-3 (draft 6, edit 5)
closing June 10, 2014.
Do use line numbers if they are available in the document under review. Do use the two-letter comment type codes listed in the page footer.
Your
initials
Line
number
Clause/
Subclause
(e.g. 17)
(e.g. 3.1)
Paragraph/
Figure/
Table/
(e.g. P3, F21)
Type of
comment2
Comments
Proposed change
Response by edit team
appropriate definition will
be included.
112
TT
267
Table 3
Supplier and
operator
responsibiliti
es to
achieve
each
metrics
objective
Te
It is good to see these metrics.
But the reader would like to see:
1. what are metrics to satisfy ISA 62443-2-1.
2. what are metrics to satisfy ISA 62443-2-3.
Could you provide the metrics for
1. metrics to satisfy ISA 62443-2-1.
2. metrics to satisfy ISA 62443-2-3.
3. what are metrics to satisfy ISA 62443-2-4.
4. what are metrics to satisfy ISA 62443-3-3.
3. metrics to satisfy ISA 62443-2-4.
5. what are metrics to satisfy ISA 62443-4-1.
6. what are metrics to satisfy ISA 62443-4-2.
4. metrics to satisfy ISA 62443-3-3.
5. metrics to satisfy ISA 62443-4-1.
Accepted in part. The next
draft will only address
metric issues of ISA
62443-2-4 (commenter’s
No. 3). Metrics for the
other listed parts are
outside the scope of this
document, as beyond
scope (See ISA99 WG12
Charter, Project
References, Note 1).
6. metrics to satisfy ISA 62443-4-2.
113
JAC
267
114
jw
268
2
5
Type of comment:
P13
ge = general
TE
The use of the “Jericho Forum” as a basis for
mapping of System Requirements to CM’s is
flawed. This document should use other
documents in the 62443 series as the basis
whenever possible. 62443-3-3 is an approved
standard that defines SR’s for IACS.
Eliminate clause 5 or completely rebuild table 3 to
use SR’s from 62443-3-3.
Accepted in part This
document will ultimately
address the requirements
identified in each of the
parts of62443. For the
draft currently being
developed, part -2-4 is the
only one within the present
scope (See ISA99 WG12
Charter, Project
References: Note 1).
TE
The Jericho Forum Error! Reference source not
found. has defined several design principles that
must be observed when developing an industrial
automation control systems for secure
operations.
I believe that ISA recommendations would be
more relevant than the Jericho Forum for IACS
Noted. Commenter
suggests use of ISArecommended design
principles, but does not
cite any such principles,
nor does he cite an ISA
source document (or
documents).
te = technical
ed = editorial
page 26 of 32
Based on ISO/IEC/CEN/CENELEC electronic balloting commenting template/version 2012-03
Do not change the structure (including column widths) of this
Due on June 10, 2014 to
Document:
Project: ISA99 ballot
comment form.
crobinson@isa.org::
ISA-dTR62443-1-3 (draft 6, edit 5)
closing June 10, 2014.
Do use line numbers if they are available in the document under review. Do use the two-letter comment type codes listed in the page footer.
Your
initials
Line
number
Clause/
Subclause
(e.g. 17)
(e.g. 3.1)
Paragraph/
Figure/
Table/
(e.g. P3, F21)
Type of
comment2
Comments
Proposed change
Response by edit team
115
DLB
268
The term “must” must not be used. The Jericho
Forum [26] has defined several design principles
that must be observed when developing an
industrial automation control systems for secure
operations “”
Also this is a requirement to an non ISA, IEC, or
ISO document, so these must be copied into the
standard and not used by reference.
Change MUST to SHALL and copy the design
principles into the standard.
Accepted in principle. In
normative sections ‘shall’
shall be used in place of
‘must’.
116
DLB
268
The term “must” is used.
Change all “must” to “shall”
Accepted in principle. See
previous comment.
117
WJC
275
ed
The header for this table hits at a page break, so
the header is repeated twice.
Force a page break
Accepted in principle.
However, Table 3 header
does not appear twice.
118
JTL
275
te
No really sure why the reference to IEDs here.
Why would we not also include RTUs as well?
Include more comprehensive statement for control
devices if they are to be referenced here along
with network appliances.
Accepted in principle.
Clarify which device types
are considered IEDs.
[definition of IED?]
119
JTL
275
ed
grammatical error
“… area of control that requires …”
Accepted in principle. Use
proper syntax in the next
draft.
120
JBN
275
Table 3
It is not clear to me how this clause relates to
security metrics. This section describes a set of
supplier and operator responsibilities
(requirements) that must be specified in other
62443 documents, not this one.
Delete Table 3
Accepted in part. Agree
that this document does
not assign responsibilities,
but recognition of such
responsibility may, in some
cases, be prudent. Table
3 may be unnecessary.
121
JBN
275
Table 3
The table includes roles for supplier and operator,
but is missing the role of system integrator
Add a column for system integrator
Accepted in principle.
Also, see previous
comment.
122
jw
275
NOTE Boundary firewalls need to be capable of
protecting themselves.
Remove note
Comment rejected.
Rationale not supplied.
2
5
Table 3
JR.8
JR.1
Type of comment:
Table 3
ge = general
TE
te = technical
ed = editorial
page 27 of 32
Based on ISO/IEC/CEN/CENELEC electronic balloting commenting template/version 2012-03
Do not change the structure (including column widths) of this
Due on June 10, 2014 to
Document:
Project: ISA99 ballot
comment form.
crobinson@isa.org::
ISA-dTR62443-1-3 (draft 6, edit 5)
closing June 10, 2014.
Do use line numbers if they are available in the document under review. Do use the two-letter comment type codes listed in the page footer.
Your
initials
Line
number
Clause/
Subclause
(e.g. 17)
(e.g. 3.1)
Paragraph/
Figure/
Table/
(e.g. P3, F21)
Type of
comment2
Comments
Proposed change
Response by edit team
123
jw
275
JR.2
Table 3
TE
All CMs for IEDs and network devices
Replace IEDs with IACS
Accepted in principle. An
IACS includes more than
IEDs. (A possible revision
might be to rewrite as, “All
CMs for IEDs and other
network devices”)
124
jw
275
JR.3
Table 3
TE
All CMs for IEDs and network devices.
Replace IEDs with IACS
Accepted in principle. See
previous comment.
125
jw
275
JR.4
Table 3
TE
All CMs for IEDs and network devices using open
system protocols.
Replace IEDs with IACS
Accepted in principle. See
123JW
126
jw
275
JR.5
Table 3
TE
All CMs for IEDs and network devices with
embedded security policy capability.
Replace IEDs with IACS
Accepted in principle. See
123JW
127
jw
275
JR.7
Table 3
TE
IACS IEDs must be capable of appropriate levels
of (mutual) authentication for accessing systems
and data
Remove term "IEDs”
Accepted in principle.
See 123JW
128
jw
275
JR.7
Table 3
TE
All CMs for IEDs and network devices with
embedded challenge/response capability.
Replace IEDs with IACS
Accepted in principle. See
123JW
129
jw
275
JR.8
Table 3
TE
All CMs for IEDs and network devices with
external interfaces.
Replace IEDs with IACS
Accepted in principle. See
123JW
130
jw
275
JR.9
Table 3
TE
Access to sensitive IACS data should be
controlled by the attributes of data itself.
Replace “attributes of the data itself” with
“appropriate policies”
Accept in principle.
131
EE
275
JR.9
ge
Security enabling capability definition is
confusing.
Needs to be clarified.
Accepted in principle.
132jj
jw
275
JR.10
TE
Data privacy (and the security of any IACS
asset of sufficiently high value) requires a
segregation of duties and privileges enforced
by strong RBAC mechanisms.
Replace “enforced by strong RBAC mechanisms”
with “appropriate policies”.
Accepted in principle. The
proposal is more general
than the original phrase,
but not in conflict, Will
consider replacing “by
strong RBAC mechanisms”
2
Type of comment:
Table 3
ge = general
te = technical
ed = editorial
page 28 of 32
Based on ISO/IEC/CEN/CENELEC electronic balloting commenting template/version 2012-03
Do not change the structure (including column widths) of this
Due on June 10, 2014 to
Document:
Project: ISA99 ballot
comment form.
crobinson@isa.org::
ISA-dTR62443-1-3 (draft 6, edit 5)
closing June 10, 2014.
Do use line numbers if they are available in the document under review. Do use the two-letter comment type codes listed in the page footer.
Your
initials
Line
number
Clause/
Subclause
(e.g. 17)
(e.g. 3.1)
Paragraph/
Figure/
Table/
(e.g. P3, F21)
Type of
comment2
Comments
Proposed change
Response by edit team
with “appropriate policies”.
.
133
Ek
275
5
Table 3
These requirements seem not to fit the
intention of a “metrics-document”
Delete paragraph and table and move it into a
more appropriate section of the standard series
(e.g. 62443-1-1 62443-3-3.
Accept in part. Agree that
this document does not
assign responsibilities, but
recognition of such
responsibility may, in some
cases, be prudent. (See
120JBN)
134
MF
275
Table 3
te
JR.1 Supplier Responsibility – does not make
sense
Can this be extended to also include supplier
responsibility includes capabilities to deter against
undefined cyber induced threats?
Accepted in principle.
JR1, if retained in the
rewrite, should be clarified.
275
Table 3
te
JR.1 Operator Responsibility - developing
directives to ensure reliable resilience to cyber
induced interruptions isn’t feasible. I am unaware
of a capability to predefined maintenance to
protect against unknown vulnerabilities or threats.
This responsibility does not correlate well with
previous sections associated with zero day issues
Accepted in principle.
Consider revising to read,
"Organizational directives
specify frequency of
security maintenance to
support reliability and
resilience against cyberinduced interruptions”.
135
MF
136
KPS
275
5
Table 3
Te
This comment is applicable for most of the table.
These metrics seem to only focus on IEDs and
network devices. IEDs and network devices
make up a very small percentage of IACS and in
the case of Process Control the metrics would
only apply to network devices and nothing else in
the system. This seems to be a very narrow
focus.
Noted. [Definition of IED
needed?]
137
KPS
275
5
Table 3
te
JR ID JR.3 – The statement “Enabling security
functions are not hard-coded and provide
sufficient adaptability to enable or disable the
function and to adjust the alarm trigger
mechanism” seems to be worded more like a
requirement in 62443-3-3. Why not just refer to
Agree in principle. Refer
to existing requirements
where they are consistent
with responsibilities stated
here.
2
Type of comment:
ge = general
te = technical
ed = editorial
page 29 of 32
Based on ISO/IEC/CEN/CENELEC electronic balloting commenting template/version 2012-03
Do not change the structure (including column widths) of this
Due on June 10, 2014 to
Document:
Project: ISA99 ballot
comment form.
crobinson@isa.org::
ISA-dTR62443-1-3 (draft 6, edit 5)
closing June 10, 2014.
Do use line numbers if they are available in the document under review. Do use the two-letter comment type codes listed in the page footer.
Your
initials
Line
number
Clause/
Subclause
(e.g. 17)
(e.g. 3.1)
Paragraph/
Figure/
Table/
(e.g. P3, F21)
Type of
comment2
Comments
Proposed change
Response by edit team
62443-3-3 requirements which specify
configurability and don’t repeat them here.
138
KPS
275
5
Table 3
Te
JR ID JR.4 – This entire requirement seems very
confusing. First it seems only specific to IEDs
and applications in the first column. Then the
second column says it only applies to IEDs and
network devices. It starts with open, secure and
then falls back to only open and listing security
issues. Then in the last column is has a note
about encryption. This entire row needs rework.
Accepted in principle.
Apparent conflicts should
be resolved. Commenter
made no
recommendations.
139
KPS
275
5
Table 3
Te
JR ID JR.6 – The operator responsibility column
seems pretty and should then drive language in
the operators SLA that is in place for contractor
support and maybe can use language
recommended by the supplier. Currently the
requirement seems backwards in that the supplier
is to write the policies and directives for
contractor support activity which seems self
serving for the supplier/contractor and since the
operator is actually responsible there does not
seem to be a linkage between the two.
Accepted in principle.
Apparent conflicts should
be resolved. Commenter
made no
recommendations.
140
KPS
275
5
Table 3
Te
JR.9, JR.10 and JR.11 – the requirement of DRM
seems prescriptive. There are other means to
achieve the requirement for protecting access
and this should be allowed in the standard.
Accepted in principle.
141
MF
275
Table 3
te
JR.1 Supplier Responsibility – does not make
sense
142
MF
275
Table 3
te
JR.1 Operator Responsibility developing
directives to ensure reliable resilience to cyber
induced interruptions isn’t feasible. I am unaware
of a capability to predefined maintenance to
protect against unknown vulnerabilities or threats.
This responsibility does not correlate well with
previous sections associated with zero day issues
2
Type of comment:
ge = general
te = technical
Can this be extended to also include supplier
responsibility includes capabilities to deter against
undefined cyber induced threats?
Comment rejected. No
specific recommendation
offered.
Accept in principle. If this
sub-clause is retained, it
should be rewritten to
make clear its intent to
specify frequency of each
security maintenance
activity. See 134MF
ed = editorial
page 30 of 32
Based on ISO/IEC/CEN/CENELEC electronic balloting commenting template/version 2012-03
Do not change the structure (including column widths) of this
Due on June 10, 2014 to
Document:
Project: ISA99 ballot
comment form.
crobinson@isa.org::
ISA-dTR62443-1-3 (draft 6, edit 5)
closing June 10, 2014.
Do use line numbers if they are available in the document under review. Do use the two-letter comment type codes listed in the page footer.
Your
initials
Line
number
Clause/
Subclause
(e.g. 17)
(e.g. 3.1)
Paragraph/
Figure/
Table/
(e.g. P3, F21)
Type of
comment2
te
Comments
Jr.4 Operator Responsibility - agree that
encryption should only be used when appropriate.
However, if the requirements demand protection
for data confidentiality (transit, rest) then
encryption does solve everything if the
cryptographic solution is sound, implemented
correctly, and requires effort or cost by the
adversary that exceeds the value of the data to be
accessed.
Proposed change
143
MF
275
Table 3
144
EJH
276
Table 3,
JR.8
145
MN
276
6
1
Te
There is little point in deriving metrics from design
principles in the hope that one can somehow
combine the results into something useful. Even
if one can, many of the measurements will have
no value, their results will not be used and the
process will therefore be inefficient and
bureaucratic.
Revise the technical approach to follow and align
with ISO/IEC 15939 and NIST SP 800-55.
Accept in part. Metrics
developed in the revised
draft of 62443-1-3 will
relate to the requirements
stated in 62443-2-4.
146
JAC
276
6
P15
ED
I’ve read this clause several times and do not
understand what information it is trying to convey
and how it is relevant to this document. Further, it
introduces terms that are not defined in the
document (e.g. ToE, SuC, SRL and SAR).
Eliminate the clause or rewrite it to be clear
Accept in principle. If this
clause is retained in the
revised draft of 62443-1-3
it will be rewritten for
clarity. Note: the terms
referenced in the comment
are defined in this clause,
as it is the only time they
appear in this draft.
147
MN
287
1
Note
Te
There are two published standards that are
directly relevant to measuring IACS security:
ISO/IEC 15939:2007 Systems and software
engineering – Measurement process; and
Add documents to bibliography. Either revise the
technical approach of this document to follow that
model, or explain why it is inappropriate.
Accepted
2
Type of comment:
ge = general
Challenge/Response is a specific type of
Authentication technique. Use the more generic
term 'authentication'.
te = technical
Maye take that NOTE out, as the box is talking
about supporting policies and procedures for
compensating controls. Not quite sure why
encryption is called out here.
Response by edit team
Supplier documentation describes embedded
authentication capability supported with a
declaration of ...
Accepted. Note is
unnecessary
Accepted.
ed = editorial
page 31 of 32
Based on ISO/IEC/CEN/CENELEC electronic balloting commenting template/version 2012-03
Do not change the structure (including column widths) of this
Due on June 10, 2014 to
Document:
Project: ISA99 ballot
comment form.
crobinson@isa.org::
ISA-dTR62443-1-3 (draft 6, edit 5)
closing June 10, 2014.
Do use line numbers if they are available in the document under review. Do use the two-letter comment type codes listed in the page footer.
Your
initials
Line
number
Clause/
Subclause
(e.g. 17)
(e.g. 3.1)
Paragraph/
Figure/
Table/
(e.g. P3, F21)
Type of
comment2
Comments
Proposed change
Response by edit team
NIST Special Publication 800-55 Revision 1 –
Performance Measurement Guide for Information
Security.
At the very least these two documents should
appear in the bibliography. And their approach of
first defining the “information need”, then working
out what measurements are required, is what I
recommend as the best technical approach for
measuring IACS network and system security.
148
MN
2
335
Biblio
[22]
Type of comment:
ge = general
Ed
te = technical
ISO/IEC 27004:2009 is currently under revision.
Mark list entry as such.
Accepted.
ed = editorial
page 32 of 32
Based on ISO/IEC/CEN/CENELEC electronic balloting commenting template/version 2012-03