CSA-311 Overview

ISA Security Compliance Institute

CSA-311 Component Security Assurance - Functional security assessment for components, Version 1.5
Summary of Worksheets:
Overview Overview - this worksheet providing summary information about each worksheet
Tree Tree Structure - hierarchical summary of all requirements organized by the 7 Foundational Requirements
CCSC Common component security constraints - detailed requirements for common component security constraints
FR 1 Identification & authentication control - detailed requirements for 1st Foundational Requirement
FR 2 Use control - detailed requirements for 2nd Foundational Requirement
FR 3 System integrity - detailed requirements for 3rd Foundational Requirement
FR 4 Data confidentiality - detailed requirements for 4th Foundational Requirement
FR 5 Restricted data flow - detailed requirements for 5th Foundational Requirement
FR 6 Timely response to events - detailed requirements for 6th Foundational Requirement
FR 7 Resource availability - detailed requirements for 7th Foundational Requirement

Common structure used for all requirement worksheets:

Software Application

Embedded Device

Network Device
Host Device

Validation by
Validation Source of Capability Security
Requirement ID Reference Name Requirement Description Independent Test Rationale and Supplemental Guidance
Activity Requirement Level
Required (Yes/No)

Software Application - indicates whether each requirement applies to a software application

Embedded Device - indicates whether each requirement applies to an embedded device
Host Device - indicates whether each requirement applies to a host device
Network Device - indicates whether each requirement applies to a network device
Requirement ID - unique ID number assigned to each requirement within this document
Reference Name - name for each requirement that provides an indication of the scope / content (names from ANSI/ISA-62443-4-2, with name extensions to designate parts of requirements)
Requirement Description - text of the requirement from ANSI/ISA-62443-4-2
Validation Activity - defines activity that must be performed as part of the evaluation audit
Validation by Independent Test Required - indicates whether the auditor is required to perform independent testing as part of the validation activity
Source of Requirement - Reference in ANSI/ISA-62443-4-2 for the requirement
Capability Security Level - specifies those capability security levels to which the requirement applies in ANSI/ISA-62443-4-2
Rationale and Supplemental Guidance - additional information on the requirement from sub clause with this title in ANSI/ISA-62443-4-2

Copyright © 2018 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 1 of 42
 CSA-311 Tree
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 1.5
Software Application

Embedded Device

Network Device
Host Device
Capability
Section Requirement ID and Reference Name
Security Level

CCSC - Common Component Security Constraints

x x x x FSA-CCSC 1A Support of essential functions - account lock out 1, 2, 3, 4
x x x x FSA-CCSC 1B Support of essential functions - non-repudiation 1, 2, 3, 4
x x x x FSA-CCSC 1C Support of essential functions - failure of certificate authority 1, 2, 3, 4
x FSA-CCSC 1D Support of essential functions - I&A and SIF initiation 1, 2, 3, 4
x FSA-CCSC 1E Support of essential functions - authorization and SIF initiation 1, 2, 3, 4
x x x x FSA-CCSC 1F Support of essential functions - incorrect timestamps 1, 2, 3, 4
x FSA-CCSC 1G Support of essential functions - zone isolation 1, 2, 3, 4
x FSA-CCSC 1H Support of essential functions - DoS and SIF initiation 1, 2, 3, 4
x x x x FSA-CCSC 2 Compensating countermeasures 1, 2, 3
x x x x FSA-CCSC 3 Least privilege 1, 2, 3, 4
x x x x FSA-CCSC 4 Software development process 1, 2, 3, 4
FR 1 - Identification & Authentication Control
x x x x FSA-CR 1.1 Human user identification and authentication 1, 2, 3, 4
x x x x FSA-CR 1.1 RE(1) Unique identification and authentication 2, 3, 4
x x x x FSA-CR 1.1 RE(2) Multifactor authentication for all interfaces 3, 4
x x x x FSA-CR 1.2 Software process and device identification and authentication 2, 3, 4
x x x x FSA-CR 1.2 RE(1) Unique identification and authentication 3, 4
x x x x FSA-CR 1.3 Account management 1, 2, 3, 4
x x x x FSA-CR 1.4 Identifier management 1, 2, 3, 4
x x x x FSA-CR 1.5A Authenticator management - initialize authenticator content 1, 2, 3, 4
x x x x FSA-CR 1.5B Authenticator management - change default authenticators 1, 2, 3, 4
x x x x FSA-CR 1.5C Authenticator management - change/refresh all authenticators periodically 1, 2, 3, 4
x x x x FSA-CR 1.5D Authenticator management - protect authenticators 1, 2, 3, 4
x x x x FSA-CR 1.5 RE(1) Hardware security for authenticators 3, 4
x FSA-NDR 1.6 Wireless access management 1, 2, 3, 4
x FSA-NDR 1.6 RE(1) Unique identification and authentication 2, 3, 4
x x x x FSA-CR 1.7 Strength of password-based authentication 1, 2, 3, 4
x x x x FSA-CR 1.7 RE(1) Password generation and lifetime restrictions for human users 3, 4
x x x x FSA-CR 1.7 RE(2) Password lifetime restrictions for all users (human, software process, or device) 4
x x x x FSA-CR 1.8 Public key infrastructure (PKI) certificates 2, 3, 4
x x x x FSA-CR 1.9A Strength of public key-based authentication - check validity of signature of a given certificate 2, 3, 4
x x x x FSA-CR 1.9B Strength of public key-based authenticationn -validate certificate chain 2, 3, 4
x x x x FSA-CR 1.9C Strength of public key-based authentication - check certificate's revocation status 2, 3, 4
x x x x 2, 3, 4
x x x x FSA-CR 1.9E Strength of public key-based authentication - map authenticated identity to a user 2, 3, 4
x x x x FSA-CR 1.9F Strength of public key-based authentication - use of cryptography 2, 3, 4
x x x x FSA-CR 1.9 RE(1) Hardware security for public key-based authentication 3, 4
x x x x FSA-CR 1.10 Authenticator feedback 1, 2, 3, 4
x x x x FSA-CR 1.11A Unsuccessful login attempts - limit number 1, 2, 3, 4
x x x x FSA-CR 1.11B Unsuccessful login attempts - response 1, 2, 3, 4
x x x x FSA-CR 1.12 System use notification 1, 2, 3, 4
x FSA-NDR 1.13 Access via untrusted networks 1, 2, 3, 4
x FSA-NDR 1.13 RE(1) Explicit access request approval 3, 4
x x x x FSA-CR 1.14A Strength of symmetric key-based authentication - establish trust 2, 3, 4
x x x x FSA-CR 1.14B Strength of symmetric key-based authentication - secure storage for shared secret 2, 3, 4
x x x x FSA-CR 1.14C Strength of symmetric key-based authentication - restrict access to shared secret 2, 3, 4
x x x x FSA-CR 1.14D Strength of symmetric key-based authentication - use of cryptography 2, 3, 4
x x x x FSA-CR 1.14 RE(1) Hardware security for symmetric key-based authentication 3, 4
FR 2 - Use Control
x x x x FSA-CR 2.1 Authorization enforcement 1, 2, 3, 4
x x x x FSA-CR 2.1 RE(1) Authorization enforcement for all users (humans, software processes and devices) 2, 3, 4
x x x x FSA-CR 2.1 RE(2) Permission mapping to roles 2, 3, 4
x x x x FSA-CR 2.1 RE(3) Supervisor override 3, 4
x x x x FSA-CR 2.1 RE(4) Dual approval 4
x x x x FSA-CR 2.2 Wireless use control 1, 2, 3, 4
FSA-CR 2.3 Use control for portable and mobile devices
x FSA-SAR 2.4A Mobile code - control execution 1, 2, 3, 4
x FSA-SAR 2.4B Mobile code - control transfer by user 1, 2, 3, 4
x FSA-SAR 2.4C Mobile code - integrity check 1, 2, 3, 4
x FSA-SAR 2.4 RE(1) Mobile code authenticity check 2, 3, 4
x FSA-EDR 2.4A Mobile code - control execution 1, 2, 3, 4
x FSA-EDR 2.4B Mobile code - control upload by user 1, 2, 3, 4
x FSA-EDR 2.4C Mobile code - integrity check 1, 2, 3, 4
x FSA-EDR 2.4 RE(1) Mobile code authenticity check 2, 3, 4
x FSA-HDR 2.4A Mobile code - control execution 1, 2, 3, 4
x FSA-HDR 2.4B Mobile code - control upload by user 1, 2, 3, 4
x FSA-HDR 2.4C Mobile code - integrity check 1, 2, 3, 4
x FSA-HDR 2.4 RE(1) Mobile code authenticity check 2, 3, 4
x FSA-NDR 2.4A Mobile code - control execution 1, 2, 3, 4
x FSA-NDR 2.4B Mobile code - control transfer by user 1, 2, 3, 4
x FSA-NDR 2.4C Mobile code - integrity check 1, 2, 3, 4
x FSA-NDR 2.4 RE(1) Mobile code authenticity check 2, 3, 4

Copyright © 2018 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 2 of 42
 CSA-311 Tree
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 1.5
Software Application

Embedded Device

Network Device
Host Device
Capability
Section Requirement ID and Reference Name
Security Level

x x x x FSA-CR 2.5A Session lock- initiation 1, 2, 3, 4

x x x x FSA-CR 2.5B Session lock- removal 1, 2, 3, 4
x x x x FSA-CR 2.6 Remote session termination 2, 3, 4
x x x x FSA-CR 2.7 Concurrent session control 3, 4
x x x x FSA-CR 2.8A Auditable events - categories 1, 2, 3, 4
x x x x FSA-CR 2.8B Auditable events - data fields 1, 2, 3, 4
x x x x FSA-CR 2.9A Audit storage capacity - allocation 1, 2, 3, 4
x x x x FSA-CR 2.9B Audit storage capacity - exceeded 1, 2, 3, 4
x x x x FSA-CR 2.9 RE(1) Warn when audit record storage capacity threshold reached 3, 4
x x x x FSA-CR 2.10A Response to audit processing failures - maintain essential functions 1, 2, 3, 4
x x x x FSA-CR 2.10B Response to audit processing failures - actions taken 1, 2, 3, 4
x x x x FSA-CR 2.11 Timestamps 1, 2, 3, 4
x x x x FSA-CR 2.11 RE(1) Time synchronization 2, 3, 4
x x x x FSA-CR 2.11 RE(2) Protection of time source integrity 4
x x x x FSA-CR 2.12 Non-repudiation 1, 2, 3, 4
x x x x FSA-CR 2.12 RE(1) Non-repudiation for all users 4
x FSA-EDR 2.13 Use of physical diagnostic and test interfaces 2, 3, 4
x FSA-EDR 2.13 RE(1) Active monitoring 3, 4
x FSA-HDR 2.13 Use of physical diagnostic and test interfaces 2, 3, 4
x FSA-HDR 2.13 RE(1) Active monitoring 3, 4
x FSA-NDR 2.13 Use of physical diagnostic and test interfaces 2, 3, 4
x FSA-NDR 2.13 RE(1) Active monitoring 3, 4
FR 3 - System Integrity
x x x x FSA-CR 3.1 Communication integrity 1, 2, 3, 4
x x x x FSA-CR 3.1 RE(1) Communication authentication 2, 3, 4
x FSA-SAR 3.2 Protection from malicious code 1, 2, 3, 4
x FSA-EDR 3.2 Protection from malicious code 1, 2, 3, 4
x FSA-HDR 3.2 Protection from malicious code 1, 2, 3, 4
x FSA-HDR 3.2 RE(1) Report version of code protection 2, 3, 4
x FSA-NDR 3.2 Protection from malicious code 1, 2, 3, 4
x x x x FSA-CR 3.3 Security functionality verification 1, 2, 3, 4
x x x x FSA-CR 3.3 RE(1) Security functionality verification during normal operation 4
x x x x FSA-CR 3.4 Software and information integrity 1, 2, 3, 4
x x x x FSA-CR 3.4 RE(1) Authenticity of software and information 2, 3, 4
x x x x FSA-CR 3.4 RE(2) Automated notification of integrity violations 3, 4
x x x x FSA-CR 3.5 Input validation 1, 2, 3, 4
x x x x FSA-CR 3.6 Deterministic output 1, 2, 3, 4
x x x x FSA-CR 3.7 Error handling 1, 2, 3, 4
x x x x FSA-CR 3.8A Session integrity - invalidate session identifiers 2, 3, 4
x x x x FSA-CR 3.8B Session integrity - generate and recognize session identifiers 2, 3, 4
x x x x FSA-CR 3.8C Session integrity - random session identifiers 2, 3, 4
x x x x FSA-CR 3.9 Protection of audit information 2, 3, 4
x x x x FSA-CR 3.9 RE(1) Audit records on write-once media 4
x FSA-EDR 3.10 Support for updates 1, 2, 3, 4
x FSA-EDR 3.10 RE(1) Update authenticity and integrity 2, 3, 4
x FSA-HDR 3.10 Support for updates 1, 2, 3, 4
x FSA-HDR 3.10 RE(1) Update authenticity and integrity 2, 3, 4
x FSA-NDR 3.10 Support for updates 1, 2, 3, 4
x FSA-NDR 3.10 RE(1) Update authenticity and integrity 2, 3, 4
x FSA-EDR 3.11 Physical tamper resistance and detection 2, 3, 4
x FSA-EDR 3.11 RE(1) Notification of a tampering attempt 3, 4
x FSA-HDR 3.11 Physical tamper resistance and detection 2, 3, 4
x FSA-HDR 3.11 RE(1) Notification of a tampering attempt 3, 4
x FSA-NDR 3.11 Physical tamper resistance and detection 2, 3, 4
x FSA-NDR 3.11 RE(1) Notification of a tampering attempt 3, 4
x FSA-EDR 3.12 Provisioning product supplier roots of trust - protection 2, 3, 4
x FSA-HDR 3.12 Provisioning product supplier roots of trust - protection 2, 3, 4
x FSA-NDR 3.12 Provisioning product supplier roots of trust - protection 2, 3, 4
x FSA-EDR 3.13A Provisioning asset owner roots of trust - protection 2, 3, 4
x FSA-EDR 3.13B Provisioning asset owner roots of trust - inside zone 2, 3, 4
x FSA-HDR 3.13A Provisioning asset owner roots of trust - protection 2, 3, 4
x FSA-HDR 3.13B Provisioning asset owner roots of trust - inside zone 2, 3, 4
x FSA-NDR 3.13A Provisioning asset owner roots of trust - protection 2, 3, 4
x FSA-NDR 3.13B Provisioning asset owner roots of trust - inside zone 2, 3, 4
x FSA-EDR 3.14 Integrity of the boot process 1, 2, 3, 4
x FSA-EDR 3.14 RE(1) Authenticity of the boot process 2, 3, 4
x FSA-HDR 3.14 Integrity of the boot process 1, 2, 3, 4
x FSA-HDR 3.14 RE(1) Authenticity of the boot process 2, 3, 4
x FSA-NDR 3.14 Integrity of the boot process 1, 2, 3, 4
x FSA-NDR 3.14 RE(1) Authenticity of the boot process 2, 3, 4
FR 4 - Data Confidentiality
x x x x FSA-CR 4.1A Information confidentiality - at rest 1, 2, 3, 4
x x x x FSA-CR 4.1B Information confidentiality - in transit 1, 2, 3, 4

Copyright © 2018 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 3 of 42
 CSA-311 Tree
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 1.5
Software Application

Embedded Device

Network Device
Host Device
Capability
Section Requirement ID and Reference Name
Security Level

x x x x FSA-CR 4.2 Information persistence 2, 3, 4

x x x x FSA-CR 4.2 RE(1) Erase of shared memory resources 3, 4
x x x x FSA-CR 4.2 RE(2) Erase verification 3, 4
x x x x FSA-CR 4.3 Use of cryptography 1, 2, 3, 4
FR 5 - Restricted Data Flow
x x x x FSA-CR 5.1 Network segmentation 1, 2, 3, 4
x FSA-NDR 5.2 Zone boundary protection 1, 2, 3, 4
x FSA-NDR 5.2 RE(1) Deny all, permit by exception 2, 3, 4
x FSA-NDR 5.2 RE(2) Island mode 3, 4
x FSA-NDR 5.2 RE(3) Fail close 3, 4
x FSA-NDR 5.3 General purpose person-to-person communication restrictions 1, 2, 3, 4
FSA-CR 5.4 Application partitioning
FR 6 - Timely Response to Event
x x x x FSA-CR 6.1 Audit log accessibility 1, 2, 3, 4
x x x x FSA-CR 6.1 RE(1) Programmatic access to audit logs 3, 4
x x x x FSA-CR 6.2 Continuous monitoring 2, 3, 4
FR 7 - Resource Availability
x x x x FSA-CR 7.1 Denial of service protection 1, 2, 3, 4
x x x x FSA-CR 7.1 RE(1) Manage communication load from component 2, 3, 4
x x x x FSA-CR 7.2 Resource management 1, 2, 3, 4
x x x x FSA-CR 7.3 Control system backup 1, 2, 3, 4
x x x x FSA-CR 7.3 RE(1) Backup integrity verification 2, 3, 4
x x x x FSA-CR 7.4 Control system recovery and reconstitution 1, 2, 3, 4
FSA-CR 7.5 Emergency power
x x x x FSA-CR 7.6 Network and security configuration settings 1, 2, 3, 4
x x x x FSA-CR 7.6 RE(1) Machine-readable reporting of current security settings 3, 4
x x x x FSA-CR 7.7 Least functionality 1, 2, 3, 4
x x x x FSA-CR 7.8 Control system component inventory 2, 3, 4

Copyright © 2018 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 4 of 42
 CSA-311 CCSC
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 1.5
Software Application
Embedded Device

Network Device
Host Device Validation by
Rationale and
Independent Source of Capability
Requirement ID Reference Name Requirement Description Validation Activity Supplemental
Test Required Requirement Security Level
Guidance
(Yes/No)

The components of the system shall adhere to specific constraints as

described in clause 4 of ISA‑62443‑3‑3 [11].

(For reference, the specific items from Clause 4 of ISA-62443-3-3

Verify in design documentation that accounts used for essential functions
are copied below in this column, for rows FSA-CCSC 1A through
shall not be locked out, even temporarily. Verify by testing that accounts
1H, with the first item following, in this cell.)
used for essential functions are not locked out due to account management ISA-62443-4-2:
x x x x FSA-CCSC 1A Support of essential functions - account lock out Yes 1, 2, 3, 4
actions and locking functions implemented to meet FR 1. Record one of: CCSC 1
Access Controls (IAC and UC) shall not prevent the operation of
a. Met
essential functions, specifically:
b. Not met
- Accounts used for essential functions shall not be locked out, even
temporarily (see 5.5, SR 1.3 – Account management, 5.6, SR 1.4 –
Identifier management, 5.13, SR 1.11 – Unsuccessful login attempts
and 6.7, SR 2.5 – Session lock).

Verify that the supplier has performed and documented analysis and testing
Access Controls (IAC and UC) shall not prevent the operation of
to confirm that verifying and recording operator actions to enforce non-
essential functions, specifically:
repudiation does not add significant delay to system response time (see ISA-62443-4-2:
x x x x FSA-CCSC 1B Support of essential functions - non-repudiation - Verifying and recording operator actions to enforce non-repudiation No 1, 2, 3, 4
FSA-CR 2.12 – Non-repudiation). Record one of: CCSC 1
shall not add significant delay to system response time (see 6.14, SR
a. Met
2.12 – Non-repudiation).
b. Not met
If public key authentication is used by the component, determine by asking
the supplier, if this is a high availability component.
If public key authentication is used by the component and the supplier
asserts it is a high availability component, verify that the supplier has a test
case to confirm that the component maintains its essential functions upon
Access Controls (IAC and UC) shall not prevent the operation of failure of the certificate authority. Verify that this test has passed (See FSA-
essential functions, specifically: CR 1.8 – Public key infrastructure (PKI) certificates). Record one of:
Support of essential functions - failure of certificate ISA-62443-4-2:
x x x x FSA-CCSC 1C - For high availability control systems, the failure of the certificate a. Met No 1, 2, 3, 4
authority CCSC 1
authority shall not interrupt essential functions (see 5.10, SR 1.8 – b. Not met
Public key infrastructure (PKI) certificates). If public key authentication is not used by the component, record:
c. Not relevant - public key authentication not used
If public key authentication is used but the supplier does not assert this is a
high availability component, record:
d. Not relevant - not high availability component

If the component has a safety instrumented function (SIF), verify in design

documentation that Identification and authentication does not prevent the
initiation of the SIF (see FSA-CR 1.1 – Human user identification and
Access Controls (IAC and UC) shall not prevent the operation of
authentication and FSA-CR 1.2 – Software process and device
essential functions, specifically:
identification and authentication). Verify by testing that initiation of SIF
- Identification and authentication shall not prevent the initiation of ISA-62443-4-2:
x FSA-CCSC 1D Support of essential functions - I&A and SIF initiation occurs as designed regardless of the authentication state of component Yes 1, 2, 3, 4
the SIF (see 5.3, SR 1.1 – Human user identification and CCSC 1
users. Record one of:
authentication and 5.4, SR 1.2 – Software process and device
a. Met
identification and authentication).
b. Not met
If the component does not have SIF, record:
c. Not relevant
If the component has a safety instrumented function (SIF), verify in design
documentation that authorization enforcement does not prevent the
Access Controls (IAC and UC) shall not prevent the operation of initiation of the SIF (see FSA-CR 2.1 – Authorization enforcement). Record
Support of essential functions - authorization and SIF essential functions, specifically: one of: ISA-62443-4-2:
x FSA-CCSC 1E No 1, 2, 3, 4
initiation Authorization enforcement whall not prevent the initiation of the SIF a. Met CCSC 1
(see 6.3, SR 2.1 – Authorization enforcement). b. Not met
If the component does not have SIF, record:
c. Not relevant
Verify using design documentation that incorrectly timestamped audit
Incorrectly timestamped audit records (see 6.10, SR 2.8 – Auditable records do not adversely affect essential functions. (See FSA-CR 2.8 -
ISA-62443-4-2:
x x x x FSA-CCSC 1F Support of essential functions - incorrect timestamps events and 6.13 SR 2.11 – Timestamps) shall not adversely affect Auditable events and FSA-CR 2.11 Timestamps.) Record one of: No 1, 2, 3, 4
CCSC 1
essential functions. a. Met
b. Not met
Essential functions of an IACS shall be maintained if zone boundary There is no component level requirement associated with this requirement
ISA-62443-4-2:
FSA-CCSC 1G Support of essential functions - zone isolation protection goes into fail-close and/or island mode (see 9.4, SR 5.2 – in ISA-62443-3-3, therefore there is no validation activity. 1, 2, 3, 4
CCSC 1
Zone boundary protection).
If the component has a safety instrumented function (SIF), and requirement
FSA-CR 7.1 Denial of service protection has been met, record one of the
A denial of service (DoS) event on the control system or safety following as specified for that requirement, for the essential function SIF:
ISA-62443-4-2:
x FSA-CCSC 1H Support of essential functions - DoS and SIF initiation instrumented system (SIS) network shall not prevent the SIF from a. Met No 1, 2, 3, 4
CCSC 1
acting (see 11.3, SR 7.1 – Denial of service protection). b. Not met
If the component does not have SIF, record:
c. Not relevant

Copyright © 2018 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 5 of 42
 CSA-311 CCSC
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 1.5
Software Application
Embedded Device

Network Device
Host Device Validation by
Rationale and
Independent Source of Capability
Requirement ID Reference Name Requirement Description Validation Activity Supplemental
Test Required Requirement Security Level
Guidance
(Yes/No)

Identify any requirement derived from FR 1 - FR 7 such that:

- it is applicable to the certification level, and
- the result recorded for the validation activity in the present document is
"Met by integration into system."
There will be cases where one or more requirements specified in the
document cannot be met without the assistance of a compensating If there are such requirements, verify for each one that the component
countermeasure that is external to the component. When this is the documentation describes appropriate countermeasures applied by a
ISA-62443-4-2:
x x x x FSA-CCSC 2 Compensating countermeasures case the documentation for that component shall describe the system to allow the requirement to be met when the component is No 1, 2, 3
CCSC 2
appropriate countermeasures applied by the system to allow the integrated into that system. Record one of:
requirement to be met when the component is integrated into a a. Met
system. b. Not met

If there are no requirements that meet these criteria, record:

c. Not relevant

The SDLPA certification element under requirement SDLA-SG-6 in

document SDLA-312, requires information about user account
permissions and privileges required to use the product. If the evaluation for
When required and appropriate, one or more system components
SDLA-SG-6 has passed, verify that the supplier has performed and
(software applications, embedded devices, host devices and network
documented an analysis of tasks related to the component. Verify that this
devices) shall provide the capability for the system to enforce the
analysis shows the permissions provided and mapping capability allow least ISA-62443-4-2:
x x x x FSA-CCSC 3 Least privilege concept of least privilege. Individual system components shall 1, 2, 3, 4
privilege assignment of tasks to users.Record one of: CCSC 3
provide the granularity of permissions and flexibility of mapping those
a. Met
permissions to roles sufficient to support it. Individual accountability
b. Not met
shall be available when required.
If the evaluation for SDLA-SG-6 has not passed, record:
b. Not met
The SDLPA and SDA-E elements of certification verify this requirement. If
those elements have passed per the criteria for those elements described
in the certification criteria document for this evaluation (specification
All of the components defined in this document shall be developed
numbered 300), record: ISA-62443-4-2:
x x x x FSA-CCSC 4 Software development process and supported following the secure product development processes No 1, 2, 3, 4
a. Met CCSC 4
described in ISA‑62443‑4‑1 [12].
Otherwise, record:
b. Not met

Copyright © 2018 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 6 of 42
 CSA-311 FR 1
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 1.5
Software Application

Embedded Device

Network Device
Host Device Validation by
Capability
Independent Source of
Requirement ID Reference Name Requirement Description Validation Activity Security Rationale and Supplemental Guidance
Test Required Requirement
Level
(Yes/No)

If the component has human users, verify

that the component can identify and
Components shall provide the capability
authenticate all users at all accessible
to identify and authenticate all human
interfaces, either locally or by integration All human users need to be identified and authenticated for all access to the component. Authentication of the identity of these users
users according to ISA‑62443‑3‑3 [11]
into a system. Note that user identification should be accomplished by using methods such as passwords, tokens, biometrics or physically keyed lids etc., and in the case of
SR 1.1 on all interfaces capable of
and authentication may be role-based or multifactor authentication, some combination thereof. The geographic location of human users can also be used as part of the
human user access. This capability shall
group-based (such as, for some authentication process. This requirement should be applied to both local and remote access to the component. This requirement comes in
enforce such identification and
component interfaces, several users may addition to the requirement of having such an authentication and identification at the system level.
authentication on all interfaces that
Human user identification and share the same identity) Record one of: ISA-62443-4-2: Interfaces capable of human user access are local user interfaces such as touchscreens, push buttons, keyboards, etc. as well as
x x x x FSA-CR 1.1 provide human user access to the No 1, 2, 3, 4
authentication a. Met by component CR 1.1 network protocols designed for human user interactions such as hypertext transfer protocol (HTTP), HTTP secure (HTTPS), file transfer
component to support segregation of
b. Met by integration into system protocol (FTP), secure FTP (SFTP), protocols used for device configuration tools (which are sometimes proprietary and other times use
duties and least privilege in accordance
c. Not met open protocols). User identification and authentication may be role-based or group-based (such as, for some component interfaces,
with applicable security policies and
several users may share the same identity). User identification and authentication should not hamper fast, local emergency actions.
procedures. This capability may be
In order to support IAC policies, as defined according to ISA‑62443‑2‑1 [5], the component should verify the identity of all human users as
provided locally by the component or by
If the component has no human users, a first step. In a second step, the permissions assigned to the identified human user should be enforced (see 6.3).
integration into a system level
record:
identification and authentication system.
d. Not relevant

If the component has human users, verify

that the component can uniquely identify
and authenticate all human users at all user
accessible interfaces, either locally or by
integration into a system. Record one of:
Components shall provide the capability
Unique identification and a. Met by component ISA-62443-4-2:
x x x x FSA-CR 1.1 RE(1) to uniquely identify and authenticate all No 2, 3, 4
authentication b. Met by integration into system CR 1.1 RE(1)
human users.
c. Not met

If the component has no human users,

record:
d. Not relevant

If the component has human users, verify

that the component can provide the
capability of multifactor authentication for
all human users, either locally or by
Components shall provide the capability integration into a system. Record one of:
Multifactor authentication for all to employ multifactor authentication for a. Met by component ISA-62443-4-2:
x x x x FSA-CR 1.1 RE(2) No 3, 4
interfaces all human user access to the b. Met by integration into system CR 1.1 RE(2)
component. c. Not met

If the component has no human users,

record:
d. Not relevant

The function of identification and authentication is to map a known identity to an unknown software process or device (henceforth referred
to as an entity in 5.4.2) so as to make it known before allowing any data exchange. Allowing rogue entities to send and receive control
Components shall provide the capability system specific data can result in detrimental behavior of the control system.
to identify itself and authenticate to any All entities should be identified and authenticated for all access to the control system. Authentication of the identity of such entities should
other component (software application, be accomplished by using methods such as passwords, tokens or location (physical or logical). This requirement should be applied to
embedded devices, host devices and Vendor shall provide list of all software both local and remote access to the control system. However, in some scenarios where individual entities are used to connect to different
network devices), according to processes and devices to which the target systems (for example, remote vendor support), it may be technically infeasible for an entity to have multiple identities. In these
ISA‑62443‑3‑3 [11] SR1.2. component can connect. Verify that cases, compensating countermeasures would have to be applied.
If the component, as in the case of an evidence exists that the component can Special attention needs to be made when identifying and authenticating portable and mobile devices. These types of devices are a known
Software process and device ISA-62443-4-2:
x x x x FSA-CR 1.2 application, is running in the context of a identify itself and authenticate to each listed No 2, 3, 4 method of introducing undesired network traffic, malware and/or information exposure to control systems, including otherwise isolated
identification and authentication CR 1.2
human user, in addition, the process and device. networks.
identification and authentication of the Record one of: Where entities function as a single group, identification and authentication may be role-based, group-based or entity-based. It is essential
human user according to a. Met that local emergency actions as well as control system essential functions not be hampered by identification or authentication
ISA‑62443‑3‑3 [11] SR1.1 may be part b. Not met requirements (see clause 4 for a more complete discussion). For example, in common protection and control schemes, a group of
of the component identification and devices jointly execute the protection functions and communicate with multicast messages among the devices in the group. In these
authentication process towards the cases, group authentication based on shared accounts or shared symmetric keys are commonly used.
other components. In order to support identification and authentication control policies as defined according to ISA‑62443‑2‑1 [5], the control system verifies
the identity of all entities as a first step. In a second step, the permissions assigned to the identified entity are enforced (see 6.3, CR 2.1 –
Authorization enforcement)

Vendor shall provide list of all software

processes and devices to which the
component can connect. Verify that
evidence exists that the component can
Components shall provide the capability
Unique identification and provide a unique identification to each ISA-62443-4-2:
x x x x FSA-CR 1.2 RE(1) to uniquely identify and authenticate No 3, 4
authentication process and device to which the CR 1.2 RE(1)
itself to any other component.
component can connect.
Record one of:
a. Met
b. Not met

Copyright © 2018 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 7 of 42
 CSA-311 FR 1
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 1.5
Software Application

Embedded Device

Network Device
Host Device Validation by
Capability
Independent Source of
Requirement ID Reference Name Requirement Description Validation Activity Security Rationale and Supplemental Guidance
Test Required Requirement
Level
(Yes/No)

If component provides the capability to

identify and authenticate users of any type
(humans, software processes or devices),
either directly or by integration into a
system, verify component supports account
management functions by an administrator
Components shall provide the capability A component may provide this capability by integrating into a higher level account management system. If the capability is not integrated
type role to establish, activate, modify,
to support the management of all into a higher level account management system then the component is expected to provide the capability natively.
disable and remove accounts, either
accounts directly or integrated into a ISA-62443-4-2: A common approach meeting this requirement would be a component that delegates the valuation of authentication to a directory server
x x x x FSA-CR 1.3 Account management directly or by integration into a system. No 1, 2, 3, 4
system that manages accounts CR 1.3 (for example, LDAP or Active Directory) which provides the account management capabilities required by ISA‑62443‑3‑3 [11] SR 1.3.
Record one of:
according to ISA‑62443‑3‑3 [11] SR When a component integrates into a higher level system to provide the account management capabilities there needs to be consideration
a. Met by component
1.3. for the impact to the component in the event that the higher level system capability becomes unavailable.
b. Met by integration into system
c. Not met
If component does not provide the
capability to identify and authenticate users
of any type as described above, record:
d. Not relevant

If component provides the capability to

identify and authenticate users of any type
(humans, software processes or devices),
either directly or by integration into a
system, verify user documents indicate that
Components shall provide the capability Accounts created under CR 1.3 – Account management require the use of one or more identifiers to distinctly identify each account.
component allows managing identifiers by
to integrate into a system that supports These identifiers must be unique and unambiguous as to the account with which they are associated. Some examples of identifiers in
user, group, role and / or interface, either
the management of identifiers and/or common use are account names, UNIX user ids, Microsoft Windows account globally unique identifiers (GUID), and bound X.509
directly or by integration into a system. ISA-62443-4-2:
x x x x FSA-CR 1.4 Identifier management provide the capability to support the No 1, 2, 3, 4 certificates. A component may provide a local capability to associate identifiers with accounts. If the component is integrated into a system
Record one of: CR 1.4
management of identifiers directly that enforces a system-wide security policy it is highly recommended that identifiers be associated with the same account across all
a. Met by component
according to ISA‑62443‑3‑3 [11] SR components in the system. In order to accomplish this a component must be able to integrate into a system-wide identifier management
b. Met by integration into system
1.4. capability.
c. Not met
If component does not provide the
capability to identify and authenticate users
of any type as described above, record:
d. Not relevant

In addition to an identifier (see 5.6) an authenticator is required to prove identity. Control system authenticators include, but are not limited
to, tokens, symmetric keys, private keys (part of a public/private key pair), biometrics, passwords, physical keys and key cards. There
should be security policies in place instructing that human users must take reasonable measures to safeguard authenticators, including
maintaining possession of their individual authenticators, not loaning or sharing authenticators with others and reporting lost or
compromised authenticators immediately.
Authenticators have a lifecycle. When an account is created automatically a new authenticator needs to be created, in order for the
account owner to be able to authenticate. For example, in a password-based system, the account has a password associated with it.
Definition of the initial authenticator content could be interpreted as the administrator defining the initial password that the account
If component provides the capability to management system sets for all new accounts. Being able to configure these initial values makes it harder for an attacker to guess the
identify and authenticate users of any type password between account creation and first account use (which should involve the setting of a new password by the account owner).
(humans, software processes or devices), Some control systems are installed with unattended installers that create all necessary accounts with default passwords and some
either directly or by integration into a embedded devices are shipped with default passwords. Over time, these passwords often become general knowledge and are
system, verify user documents indicate documented on the Internet. Being able to change the default passwords protects the system against unauthorized users using default
ability to define initial authenticator content. passwords to gain access. Passwords can be obtained from storage or from transmission when used in network authentication. The
Components shall provide the capability
Authenticator management - Record one of: ISA-62443-4-2: complexity of this can be increased by cryptographic protections such as encryption or hashing or by handshake protocols that do not
x x x x FSA-CR 1.5A to support the use of initial authenticator No 1, 2, 3, 4
initialize authenticator content a. Met CR 1.5(a) require transmission of the password at all. Still, passwords might be subject to attacks, for example, brute force guessing or breaking the
content.
b. Not met cryptographic protection of passwords in transit or storage. The window of opportunity can be reduced by changing/refreshing the
If component does not provide the passwords periodically. Similar considerations apply to authentication systems based on cryptographic keys. Enhanced protection can be
capability to identify and authenticate users achieved by using hardware mechanisms such as hardware security modules like trusted platform modules (TPMs).
of any type as described above, record: The management of authenticators should be specified in applicable security policies and procedures, for example, constraints to change
c. Not relevant default authenticators, refresh periods, specification of the protection of authenticators or firewall procedures.
Besides the capabilities for authenticator management specified in this requirement, the strength of the authentication mechanism
depends on the strength of the chosen authenticator (for example, password complexity or key length in public key authentication) and the
policies for validating the authenticator in the authentication process (for example, how long a password is valid or which checks are
performed in public key certificate validation). For the most common authentication mechanisms, password-based and public key
authentication, 5.9, 5.10 and 5.11 provide further requirements.
Use of components for some operations may be restricted, requiring additional authentication (such as, tokens, keys and certificates) in
order to perform some functions.

Copyright © 2018 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 8 of 42
 CSA-311 FR 1
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 1.5
Software Application

Embedded Device

Network Device
Host Device Validation by
Capability
Independent Source of
Requirement ID Reference Name Requirement Description Validation Activity Security Rationale and Supplemental Guidance
Test Required Requirement
Level
(Yes/No)

If component provides the capability to

identify and authenticate users of any type
(humans, software processes or devices),
either directly or by integration into a
system, verify user documents indicate
ability to change default authenticators
(such as default passwords) at installation
Components shall provide the capability
time. Verify by testing that the component
Authenticator management - to support the recognition of changes to ISA-62443-4-2:
x x x x FSA-CR 1.5B recognizes these changes after installation Yes 1, 2, 3, 4 See FSA-CR 1.5A
change default authenticators default authenticators made at CR 1.5(b)
as expected. Record one of:
installation time.
a. Met
b. Not met

If component does not provide the

capability to identify and authenticate users
of any type as described above, record:
c. Not relevant

If component provides the capability to

identify and authenticate users of any type
(humans, software processes or devices),
either directly or by integration into a
system, verify user documents indicate
ability to function properly with
Authenticator management - Components shall provide the capability
changed/refreshed authenticators. Record ISA-62443-4-2:
x x x x FSA-CR 1.5C change/refresh all authenticators to function properly with periodic No 1, 2, 3, 4 See FSA-CR 1.5A
one of: CR 1.5(c)
periodically authenticator change/refresh operation.
a. Met
b. Not met
If component does not provide the
capability to identify and authenticate users
of any type as described above, record:
c. Not relevant

Copyright © 2018 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 9 of 42
 CSA-311 FR 1
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 1.5
Software Application

Embedded Device

Network Device
Host Device Validation by
Capability
Independent Source of
Requirement ID Reference Name Requirement Description Validation Activity Security Rationale and Supplemental Guidance
Test Required Requirement
Level
(Yes/No)

If component provides the capability to

identify and authenticate users of any type
(humans, software processes or devices),
either directly or by integration into a
system, verify design or user documents
indicate ability to protect authenticators
Components shall provide the capability
from unauthorized disclosure and
to protect authenticators from
Authenticator management - modification when stored, used or ISA-62443-4-2:
x x x x FSA-CR 1.5D unauthorized disclosure and No 1, 2, 3, 4 See FSA-CR 1.5A
protect authenticators transmitted by the component. Record one CR 1.5(d)
modification when stored, used and
of:
transmitted.
a. Met
b. Not met
If component does not provide the
capability to identify and authenticate users
of any type as described above, record:
c. Not relevant

Verify user or design documents indicate

The authenticators on which the ability to protect relevant authenticators with
Hardware security for ISA-62443-4-2:
x x x x FSA-CR 1.5 RE(1) component rely shall be protected via hardware mechanisms. Record one of: No 3, 4
authenticators CR 1.5 RE(1)
hardware mechanisms. a. Met
b. Not met

A network device supporting wireless

access management shall provide the Any wireless technology can, and in most cases should, be considered just another communication protocol option. Thus, it should be
capability to identify and authenticate all ISA-62443-4-2: subject to the same IACS security requirements as any other communication type utilized by the IACS. However, from a security point of
x FSA-NDR 1.6 Wireless access management Future entry Future entry 1, 2, 3, 4
users (humans, software processes or NDR 1.6 view, there is at least one significant difference between wired and wireless communications. Physical security countermeasures are
devices) engaged in wireless typically less effective when using wireless.
communication.

The network device shall provide the

capability to uniquely identify and
Unique identification and ISA-62443-4-2:
x FSA-NDR 1.6 RE(1) authenticate all users (humans, Future entry Future entry 2, 3, 4
authentication NDR 1.6 RE(1)
software processes or devices)
engaged in wireless communication.

If the component utilizes password-based

authentication, verify user documents
indicate that configurable password
strength can be enforced that meets
For components that utilize password- internationally recognized and proven
based authentication, those guidelines, either directly or by integration
components shall provide or integrate into a system. Record one of: The ability to enforce configurable password strength, whether it is based on minimum length, variety of characters, or duration of time
Strength of password-based into a system that provides the a. Met by component ISA-62443-4-2: (the minimum being a one-time password) is necessary to assist in increasing the overall security of user chosen passwords. Generally
x x x x FSA-CR 1.7 No 1, 2, 3, 4
authentication capability to enforce configurable b. Met by integration into system CR 1.7 accepted practices and recommendations can be found in documents such as NIST SP800-63-2, Electronic Authentication Guideline
password strength according to c. Not met [27].
internationally recognized and proven
password guidelines. If the component does not utilize password-
based authentication, record:
d. Not relevant

Copyright © 2018 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 10 of 42
 CSA-311 FR 1
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 1.5
Software Application

Embedded Device

Network Device
Host Device Validation by
Capability
Independent Source of
Requirement ID Reference Name Requirement Description Validation Activity Security Rationale and Supplemental Guidance
Test Required Requirement
Level
(Yes/No)

If the component utilizes password-based

authentication, verify user documents
indicate that password use for human users
Components shall provide, or integrate
can be limited to a specified lifetime, and re-
into a system that provides, the
use can be limited to a configurable
capability to protect against any given
number of generations, either directly or by
human user account from reusing a
integration into a system. Verify a source
password for a configurable number of
for the commonly accepted practices
Password generation and lifetime generations. In addition, the component ISA-62443-4-2:
x x x x FSA-CR 1.7 RE(1) followed. Record one of: No 3, 4
restrictions for human users shall provide the capability to enforce CR 1.7 RE(1)
a. Met by component
password minimum and maximum
b. Met by integration into system
lifetime restrictions for human users.
c. Not met
These capabilities shall conform to
commonly accepted security industry
If the component does not utilize password-
practices.
based authentication, record:
d. Not relevant

If the component utilizes password-based

authentication, verify user documents
indicate that the component supports the
capability to enforce password minimum
and maximum lifetime restrictions for all
types of users that support password
Components shall provide, or integrate
based authentication (humans, software
Password lifetime restrictions for into a system that provides, the
processes, devices), either directly or by ISA-62443-4-2:
x x x x FSA-CR 1.7 RE(2) all users (human, software capability to enforce password No 4
integration into a system. Record one of: CR 1.7 RE(2)
process, or device) minimum and maximum lifetime
a. Met by component
restrictions for all users.
b. Met by integration into system
c. Not met

If the component does not utilize password-

based authentication, record:
d. Not relevant

Review user documentation and determine

if public key authentication is used by the
component.

For reference, ISA-62443-3-3 SR 1.8

states: "Where PKI is utilized, the control
system shall provide the capability to
operate a PKI according to commonly
accepted best practices or obtain public
key certificates from an existing PKI." SR
1.8 has accompanying rationale also
included in ISA-62443-4-2 for CR 1.8, and
When public key infrastructure (PKI) is shown in the present document in the
The selection of an appropriate PKI should consider the organization’s certificate policy which should be based on the risk associated with
utilized, the component shall provide or "Rationale and Supplemental Guidance"
a breach of confidentiality of the protected information. Guidance on the policy definition can be found in commonly accepted standards
Public key infrastructure (PKI) integrate into a system that provides the column to the right. ISA-62443-4-2:
x x x x FSA-CR 1.8 No 2, 3, 4 and guidelines, such as the Internet Engineering Task Force (IETF) Request for Comment (RFC) 3647 [31] for X.509-based PKI. For
certificates capability to interact and operate in CR 1.8
example, the appropriate location of a certification authority (CA), whether within the control system versus on the Internet, and the list of
accordance with ISA‑62443‑3‑3 [11] If public key authentication is used, for
trusted CAs should be considered in the policy and depends on the network architecture (see also ISA‑62443‑2‑1 [5]).
SR1.8. certificates not obtained from an existing
PKI, verify user documents indicate that the
required public key infrastructure practices
per SR 1.8 are supported, either directly or
by integration into a system. Record one of:
a. Met by component
b. Met by integration into system
c. Not met

If public key authentication is not used by

the component, record:
d. Not relevant

Copyright © 2018 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 11 of 42
 CSA-311 FR 1
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 1.5
Software Application

Embedded Device

Network Device
Host Device Validation by
Capability
Independent Source of
Requirement ID Reference Name Requirement Description Validation Activity Security Rationale and Supplemental Guidance
Test Required Requirement
Level
(Yes/No)

Review user documentation and determine To meet the requirements in 5.11.1 does not necessarily require a real time connection to a certificate authority. Alternative out-of-band
if public key authentication is used. methods may be used to meet the requirements in 5.11.1. For example, a disconnected system could install and update certifications
using manual out-of-band processes.
If public key authentication is used, verify in Public/private key cryptography strongly depends on the secrecy of a given subject’s private key and proper handling of the trust
user documentation that signature validity relationships. When verifying a trust between two entities based on public key authentication, it is essential to trace the public key
can be determined, either directly or by certificate to a trusted entity. A common implementation error in certificate validation is to only check the validity of a certificate’s signature,
integration into a system, without but not checking the trust in the signer. In a PKI setting, a signer is trusted if they are a trusted CA or have a certificate issued by a trusted
communicating outside the same IACS CA, thus all verifiers need to trace certificates presented to them back to a trusted CA. If such a chain of trusted CAs cannot be
environment, such as out to the Internet or established, the presented certificate should not be trusted.
For components that utilize public-key- to a less secure IACS zone. If self-signed certificates are used instead of a PKI, the certificate subject itself signed its certificate, thus there never is a trusted third-
based authentication, those party or CA. This should be compensated by deploying the self-signed public key certificates to all peers that need to validate them via an
components shall provide directly or If the component directly supports the otherwise secured mechanism (for example, configuration of all peers in a trusted environment). Trusted certificates need to be distributed
Strength of public key-based
integrate into a system that provides the capability, also verify with the following test ISA-62443-4-2: to peers through secure channels. During the validation process, a self-signed certificate should only be trusted if it is already present in
x x x x FSA-CR 1.9A authentication - check validity of 2, 3, 4
capability within the same IACS in an environment without an Internet Yes CR 1.9(a) the list of trusted certificates of the validating peer. The set of trusted certificates should be configured to the minimum necessary set.
signature of a given certificate
environment to validate certificates by connection. Provide a certificate with an In both cases, validation needs to also consider the possibility that a certificate is revoked. In a PKI setting this is typically done by
checking the validity of the signature of invalid signature to the component. Verify maintaining certificate revocation lists (CRLs) or running an online certificate status protocol (OCSP) server. When revocation checking is
a given certificate. that this problem is detected and reported not available due to control system constraints, mechanisms such as a short certificate lifetime can compensate for the lack of timely
to the user. Record one of: revocation information. Note that short lifetime certificates can sometimes create significant operational issues in a control system
a. Met by component environment.
b. Met by integration in system It is expected that most components will integrate into an IACS and leverage the key authentication mechanisms provided by the
c. Not met underlying IACS. When implementing public key authentication at the component-level of an IACS, protection of the key becomes a
primary concern and objective of key storage on that component. Care should be taken in the implementation to assure that any private
If public key authentication is not used, keys stored within the component cannot be retrieved or tampered with (See 5.7, CR 1.5 – Authenticator management).
record: NOTE Tamper resistant design methodologies and technologies are available to assist with designing a secure private key protection
d. Not relevant mechanism.

Review user documentation and determine

if public key authentication is used.

If public key authentication is used, review

design documentation and determine if the
component has the capability, either directly
or by integration into a system, to validate
For components that utilize public-key-
the certificate chain without communicating
based authentication, those
outside the same IACS environment or in
components shall provide directly or
the case of self-signed certificates, by
integrate into a system that provides the
deploying leaf certificates to all hosts which
Strength of public key-based capability within the same IACS
communicate with the subject to which the ISA-62443-4-2:
x x x x FSA-CR 1.9B authentication -validate certificate environment to validate the certificate No 2, 3, 4 See FSA-CR 1.9A
certificate is issued. Examples of CR 1.9(b)
chain chain or, in the case of self-signed
communication outside the same IACS
certificates, by deploying leaf
environment are communication to the
certificates to all hosts that
Internet or to a less secure IACS zone.
communicate with the subject to which
Record one of:
the certificate is issued.
a. Met by component
b. Met by integration with system
c. Not met

If public key authentication is not used,

record:
d. Not relevant

Copyright © 2018 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 12 of 42
 CSA-311 FR 1
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 1.5
Software Application

Embedded Device

Network Device
Host Device Validation by
Capability
Independent Source of
Requirement ID Reference Name Requirement Description Validation Activity Security Rationale and Supplemental Guidance
Test Required Requirement
Level
(Yes/No)

Review user documentation and determine

if public key authentication is used.

If public key authentication is used, verify in

user documentation that the component
has the capability, either directly or by
integration into a system, to check
certification revocation status without
communication outside the same IACS
For components that utilize public-key- environment, such as to the Internet or a
based authentication, those less secure IACS zone.
components shall provide directly or
Strength of public key-based
integrate into a system that provides the If the component directly supports the ISA-62443-4-2:
x x x x FSA-CR 1.9C authentication - check certificate's Yes 2, 3, 4 See FSA-CR 1.9A
capability within the same IACS capability, also verify with the following test CR 1.9(c)
revocation status
environment to validate certificates by in an environment without an Internet
checking a given certificate’s revocation connection. Provide a certificate with a
status. revoked status. Verify that the problem is
detected and reported to the user.
Record one of:
a. Met by component
b. Met by integration into system
c. Not met

If public key authentication is not used,

record:
d. Not relevant

Review user documentation and determine

if public key authentication is used.

If public key authentication is used,

examine user documents to verify that key
pairs may be generated either directly or by
integration into a system, without
For components that utilize public-key- communicating outside the same IACS
based authentication, those environment, such as to the Internet or a
components shall provide directly or less trusted IACS zone. Verify by review of
Strength of public key-based
integrate into a system that provides the user and design documents that ISA-62443-4-2:
x x x x FSA-CR 1.9D authentication - establish user No 2, 3, 4 See FSA-CR 1.9A
capability within the same IACS corresponding private keys are only CR 1.9(d)
control of private key
environment to establish user (human, accessible by the owner of the key, whether
software process or device) control of human, software process, or device.
the corresponding private key. Record one of:
a. Met by component
b. Met by integration into system
c. Not met

If public key authentication is not used,

record:
d. Not relevant

Review user documentation and determine

if public key authentication is used.

If public key authentication is used,

examine user documents to verify that an
identity authenticated by public key
For components that utilize public-key- authentication is mapped to a component
based authentication, those user (human, software process, or device),
components shall provide directly or without communicating outside the same
Strength of public key-based
integrate into a system that provides the IACS environment, such as to the Internet ISA-62443-4-2:
x x x x FSA-CR 1.9E authentication - map No 2, 3, 4 See FSA-CR 1.9A
capability within the same IACS or a less trusted IACS zone. Record one CR 1.9(e)
authenticated identity to a user
environment to map the authenticated of:
identity to a user (human, software a. Met by component
process or device). b. Met by integration into system
c. Not met

If public key authentication is not used,

record:
d. Not relevant

Copyright © 2018 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 13 of 42
 CSA-311 FR 1
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 1.5
Software Application

Embedded Device

Network Device
Host Device Validation by
Capability
Independent Source of
Requirement ID Reference Name Requirement Description Validation Activity Security Rationale and Supplemental Guidance
Test Required Requirement
Level
(Yes/No)

Review user documentation and determine

if public key authentication is used.

If public key authentication is used, review

design documentation to verify that the
component provides the capability either
directly or by integration into a system, and
For components that utilize public-key-
without communication outside the same
based authentication, those
IACS environment, to ensure that
components shall provide directly or
algorithms and keys used for this comply
Strength of public key-based integrate into a system that provides the
with FSA-CR 4.3 - Use of cryptograpy. ISA-62443-4-2:
x x x x FSA-CR 1.9F authentication - use of capability within the same IACS No 2, 3, 4 See FSA-CR 1.9A
Examples of communication outside the CR 1.9(f)
cryptography environment to ensure that the
same IACS environment are
algorithms and keys used for the public
communication to the Internet or to a less
key authentication comply with CR 4.3 –
secure IACS zone. Record one of:
Use of cryptography.
a. Met by component
b. Met by integration into system
c. Not met

If public key authentication is not used,

record:
d. Not relevant

Review user documentation and determine

if public key authentication is used.

If public key authentication is used, review

design documentation to verify that
hardware mechanisms are used to protect
critical long-lived private keys, either directly
Components shall provide the capability
Hardware security for public key- by the component or by integration into a ISA-62443-4-2:
x x x x FSA-CR 1.9 RE(1) to protect critical, long-lived private keys No 3, 4
based authentication system. Record one of: CR 1.9 RE(1)
via hardware mechanisms.
a. Met by component
b. Met by integration into system
c. Not met

If public key authentication is not used,

record:
d. Not relevant

If the component locally provides an

authentication capability, verify component
is capable of obscuring feedback of
When a component provides an
authentication information. Record one of: Obscuring feedback protects the information from possible exploitation by unauthorized individuals, for example, displaying asterisks or
authentication capability, the component
a. Met ISA-62443-4-2: other random characters when a human user types in a username and/or password obscures feedback of authentication information.
x x x x FSA-CR 1.10 Authenticator feedback shall provide the capability to obscure No 1, 2, 3, 4
b. Not met CR 1.10 Other examples include the entry of secure socket shell (SSH) token entry and one-time passwords. The authenticating entity should not
feedback of authenticator information
provide any hint as to the reason for the authentication failure, such as “unknown user name.”
during the authentication process.
If the component does not locally provide
an authentication capability record:
c. Not relevant

If the component locally provides an

authentication capability, verify component
is capable of enforcing a limit of a
When a component provides an Due to the potential for denial of service, the number of consecutive invalid access attempts may be limited. If enabled, the application or
configurable number of consecutive invalid
authentication capability the component device may automatically reset to zero the number of access attempts after a predetermined time period established by the applicable
access attempts by any user (human,
shall provide the capability to enforce a security policies and procedures. Resetting the access attempts to zero will allow users (human, software process or device) to gain
software process or device) during a
Unsuccessful login attempts - limit of a configurable number of ISA-62443-4-2: access if they have the correct login credentials. Automatic denial of access for control system operator workstations or nodes should not
x x x x FSA-CR 1.11A configurable time period. Record one of: No 1, 2, 3, 4
limit number consecutive invalid access attempts by CR 1.11(a) be used when immediate operator responses are required in emergency situations. All lockout mechanisms should consider functional
a. Met
any user (human, software process or requirements for continuous operations so as to mitigate adverse denial of service operating conditions which could result in system
b. Not met
device) during a configurable time failures or compromising the safety of the system. Allowing interactive logins to an account used for critical services could provide a
period. potential for denial of service or other abuse.
If the component does not locally provide
an authentication capability, record:
c. Not relevant

Copyright © 2018 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 14 of 42
 CSA-311 FR 1
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 1.5
Software Application

Embedded Device

Network Device
Host Device Validation by
Capability
Independent Source of
Requirement ID Reference Name Requirement Description Validation Activity Security Rationale and Supplemental Guidance
Test Required Requirement
Level
(Yes/No)

If the component locally provides an

authentication capability, verify component
is capable of denying access for a
specified period of time or until unlocked by
When a component provides an
an administrator when a configured limit for
authentication capability the component
unsuccessful login attempts has been
Unsuccessful login attempts - shall provide the capability to deny ISA-62443-4-2:
x x x x FSA-CR 1.11B reached. Record one of: No 1, 2, 3, 4 See FSA-CR 1.11A
response access for a specified period of time or CR 1.11(b)
a. Met
until unlocked by an administrator when
b. Not met
this limit has been reached.
If the component does not locally provide
an authentication capability, record:
c. Not relevant

If component provides local human use

access/HMI, verify component is capable of Privacy and security policies and procedures need to be consistent with applicable laws, directives, policies, regulations, standards and
displaying user configurable system use guidance. Often, the main justification for this requirement is legal prosecution of violators and proving intentional breach. This capability is
When a component provides local
notifications before authenticating. Record thus necessary to support policy requirements, and might improve IACS security because it can be used as a deterrent. System use
human user access/HMI, it shall provide
one of: notification messages can be implemented in the form of warning banners displayed when individuals log in to the control system. A
the capability to display a system use
a. Met ISA-62443-4-2: warning banner implemented as a posted physical notice in the control system facility does not protect against remote login issues.
x x x x FSA-CR 1.12 System use notification notification message before No 1, 2, 3, 4
b. Not met CR 1.12 Examples of elements for inclusion in the system use notification message are:
authenticating. The system use
a) that the individual is accessing a system owned by the asset owner;
notification message shall be
If the component does not provide local b) that system usage may be monitored, recorded and subject to audit;
configurable by authorized personnel.
human use access/HMI, record: c) that unauthorized use of the system is prohibited and subject to criminal and/or civil penalties; and
c. Not relevant d) that use of the system indicates consent to monitoring and recording.

The network device should protect against unauthorized connections or subversion of authorized connections.
Examples of access to the network device via untrusted networks typically include remote access methods (such as, dial-up, broadband
and wireless) as well as connections from a company’s office (non-control system) network. The network device may provide ACL
The network device supporting device (Access Control List) functionality to restrict access by:
access into a network shall provide the Layer 2 forwarding devices such as Ethernet switches:
ISA-62443-4-2:
x FSA-NDR 1.13 Access via untrusted networks capability to monitor and control all Future entry Future entry 1, 2, 3, 4 a) MAC address
NDR 1.13
methods of access to the network b) VLAN
device via untrusted networks. Layer 3 forwarding devices such as routers, gateways and firewalls:
a) IP address
b) Port and protocol
c) Virtual Private Networks

The network device shall provide the

capability to deny access requests via ISA-62443-4-2:
x FSA-NDR 1.13 RE(1) Explicit access request approval Future entry Future entry 3, 4
untrusted networks unless explicitly NDR 1.13 RE(1)
approved by an assigned role.

Means should be defined for installing the keys into the component. This may include installing and managing the component key using
Review user documentation and determine out-of-band methods. This is necessary since a compromise of any symmetric keys that are stored within the component could lead to a
if symmetric key authentication is used. full compromise of the system using those keys.
In practice, there are two basic ways to perform the secure authentication of a device to another: either using asymmetric cryptography
If symmetric key authentication is used, (see 5.11) or by using symmetric cryptography. The choice between asymmetric and symmetric is dictated by several criteria, like key
For components that utilize symmetric verify user documents indicate ability for the management, trust provisioning, legacy support and efficiency. Examples of symmetric key authentication schemes are Needham-
keys, the component shall provide the component to establish mutual trust using Schröder or Kerberos. When symmetric key authentication is used, the party uses a secret key they have learned in the past (for
Strength of symmetric key-based ISA-62443-4-2:
x x x x FSA-CR 1.14A capability to establish the mutual trust the symmetric key. Record one of: No 2, 3, 4 example, through trust provisioning). The party proves their claimed identity by proving knowledge of the secret key (for example, by
authentication - establish trust CR 1.14(a)
using the symmetric key. a. Met answering a challenge submitted by the other party, the examiner). The examiner has the knowledge of the same secret (also learned in
b. Not met the past through trust provisioning) and is able to compute the answer to the challenge performing the same cryptographic operations as
the prover. The examiner can then compare the answer of the prover with its own computation. If they match, the examiner is convinced
If symmetric key authentication is not used, that the prover is the one they claim to be and the process can be conducted the other way around, switching roles, to achieve mutual-
record: authentication. This mechanism is secure only if the shared secret is only known by the prover and the examiner and if the secret is
c. Not relevant diversified per prover. One instance of such a mechanism is the proper use of cipher-based message authentication code (CMAC)
computations or alternatively the Galois counter mode (GCM)/Galois message authentication code (GMAC) operation modes.

Copyright © 2018 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 15 of 42
 CSA-311 FR 1
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 1.5
Software Application

Embedded Device

Network Device
Host Device Validation by
Capability
Independent Source of
Requirement ID Reference Name Requirement Description Validation Activity Security Rationale and Supplemental Guidance
Test Required Requirement
Level
(Yes/No)

Review user documentation and determine

if symmetric key authentication is used.
If symmetric key authentication is used,
verify user and design documents indicate
For components that utilize symmetric
ability to protect the shared secret from
Strength of symmetric key-based keys, the component shall provide the
unauthorized disclosure. Record one of: ISA-62443-4-2:
x x x x FSA-CR 1.14B authentication - secure storage capability to store securely the shared No 2, 3, 4 See FSA-CR 1.14A
a. Met CR 1.14(b)
for shared secret secret (the authentication is valid as
b. Not met
long as the shared secret remains
If symmetric key authentication is not used,
secret).
record:
c. Not relevant

Review user documentation and determine

if symmetric key authentication is used.

If symmetric key authentication is used,

verify design and user documents indicate
For components that utilize symmetric ability to protect the shared secret from
Strength of symmetric key-based
keys, the component shall provide the unauthorized use or modification Record ISA-62443-4-2:
x x x x FSA-CR 1.14C authentication - restrict access to No 2, 3, 4 See FSA-CR 1.14A
capability to restrict access to the one of: CR 1.14(c)
shared secret
shared secret. a. Met
b. Not met

If symmetric key authentication is not used,

record:
c. Not relevant

Review user documentation and determine

if symmetric key authentication is used.

If symmetric key authentication is used,

review design documentation to verify that
For components that utilize symmetric the component provides the capability to
keys, the component shall provide the ensure that algorithms and keys used for
capability to ensure that the algorithms this comply with FSA-CR 4.3 - Use of ISA-62443-4-2:
x x x x FSA-CR 1.14D No 2, 3, 4 See FSA-CR 1.14A
and keys used for the symmetric key cryptograpy. Record one of: CR 1.14(d)
authentication comply with CR 4.3 – a. Met
Use of cryptography Subclause 8.5. b. Not met

If symmetric key authentication is not used,

record:
c. Not relevant

Review user documentation and determine

if symmetric key authentication is used.

If symmetric key authentication is used,

review design documentation to verify that
hardware mechanisms are used to protect
Components shall provide the capability
Hardware security for symmetric critical long-lived symmetric keys. Record ISA-62443-4-2:
x x x x FSA-CR 1.14 RE(1) to protect critical, long lived symmetric No 3, 4
key-based authentication one of: CR 1.14 RE(1)
keys via hardware mechanisms.
a. Met
b. Not met

If symmetric key authentication is not used,

record:
c. Not relevant

Copyright © 2018 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 16 of 42
 CSA-311 FR 2
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 1.5
Software Application

Embedded Device

Network Device
Host Device Validation by
Capability
Independent Source of
Requirement ID Reference Name Requirement Description Validation Activity Security Rationale and Supplemental Guidance
Test Required Requirement
Level
(Yes/No)

Use control policies (for example, identity-based policies, role-based policies

and rule-based policies) and associated read/write access enforcement
mechanisms (for example, access control lists, access control matrices and
cryptography) are employed to control usage between users (humans, software
processes and devices) and assets (for example, devices, files, records,
software processes, programs and domains).
If the component provides the capability to identify and After the control system has verified the identity of a user (human, software
authenticate users of any type (humans, software process or device) (see 5.3, CR 1.1 – Human user identification and
processes or devices), either directly or by integration into authentication and 5.4, CR 1.2 – Software process and device identification and
a system, verify component enforces authorizations for authentication), it also has to verify that a requested operation is actually
Components shall provide an authorization users to control use of the component as configured by permitted according to the defined security policies and procedures. For
enforcement mechanism for all identified and account management. Record one of: ISA-62443-4-2: example, in a role-based access control policy, the control system would check
x x x x FSA-CR 2.1 Authorization enforcement No 1, 2, 3, 4
authenticated users based on their assigned a. Met CR 2.1 which roles are assigned to a verified user or asset and which privileges are
responsibilities. b. Not met assigned to these roles – if the requested operation is covered by the
If the component does not provide the capability to identify permissions, it is executed, otherwise rejected. This allows the enforcement of
and authenticate users of any type as described above, segregation of duties and least privileges. Usage enforcement mechanisms
record: should not be allowed to adversely affect the operational performance of the
c. Not relevant control system.
Planned or unplanned changes to control system components can have
significant effects on the overall security of the control system. Accordingly, only
qualified and authorized individuals should obtain the use of control system
components for purposes of initiating changes, including upgrades and
modifications.

Review user documentation and determine if software

processes or devices are supported as users.

If software processes or devices are supported as users,

verify component enforces authorizations for processes
Authorization enforcement for all Components shall provide an authorization and device users to control use of the component as
ISA-62443-4-2:
x x x x FSA-CR 2.1 RE(1) users (humans, software processes enforcement mechanism for all users based on configured by account management. Record one of: No 2, 3, 4
CR 2.1 RE(1)
and devices) their assigned responsibilities and least privilege. a. Met
b. Not met

If software processes or devices are not supported as

users, record:
c. Not relevant

If the component provides the capability to identify and

authenticate users of any type (humans, software
processes or devices), either directly or by integration into
a system, verify component provides the capability to map
Components shall, directly or through a permissions to roles for these users by an authorized
compensating security mechanism, provide for supervisory level account, either directly or through a
ISA-62443-4-2:
x x x x FSA-CR 2.1 RE(2) Permission mapping to roles an authorized role to define and modify the compensating security mechanism. Record one of: No 2, 3, 4
CR 2.1 RE(2)
mapping of permissions to roles for all human a. Met by component
users. b. Met by a compensating security mechanism
c. Not met
If the component does not provide the capability to identify
and authenticate users of any type as described, record:
d. Not relevant

If the component provides the capability to identify and

authenticate human users, either directly or by integration
into a system, verify that the component can support
supervisor override of role permissions. Verify that the
override can be configured to be in effect for a
Components shall support a supervisor manual
configurable time or sequence of events. Record one of: ISA-62443-4-2:
x x x x FSA-CR 2.1 RE(3) Supervisor override override for a configurable time or sequence of No 3, 4
a. Met CR 2.1 RE(3)
events.
b. Not met
If the component does not provide the capability to identify
and authenticate human users, record:
c. Not relevant

Verify that the component can provide the capability of

Components shall support dual approval when
dual approval if required. Record one of: ISA-62443-4-2:
x x x x FSA-CR 2.1 RE(4) Dual approval action can result in serious impact on the No 4
a. Met CR 2.1 RE(4)
industrial process.
b. Not met

Copyright © 2018 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 17 of 42
 CSA-311 FR 2
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 1.5
Software Application

Embedded Device

Network Device
Host Device Validation by
Capability
Independent Source of
Requirement ID Reference Name Requirement Description Validation Activity Security Rationale and Supplemental Guidance
Test Required Requirement
Level
(Yes/No)

If the component supports usage through wireless

Wireless use control may be implemented in different devices that make up the
interfaces,
system. Network devices may be one of the devices that assist with use control
verify with user documentation that the component can
through controls such as network admission control. For devices and
integrate into a system to authorize usage, monitor, and
applications that utilize wireless networks those devices should be able to
If a component supports usage through wireless enforce usage restrictions for wireless connectivity to the
properly utilize wireless network protection such as network admission control.
interfaces it shall provide the capability to component per commonly accepted security practices.
Components may also implement different limitations on access based on
integrate into the system that supports usage Record one of: ISA-62443-4-2:
x x x x FSA-CR 2.2 Wireless use control No 1, 2, 3, 4 whether the access is from wireless devices or wired devices. This does place a
authorization, monitoring and restrictions a. Met CR 2.2
need that the component be able to distinguish whether the interface is through
according to commonly accepted industry b. Not met
wireless or not. Some network devices provide the capability to scan for
practices.
unauthorized wireless network activity in the wireless spectrum. In order to
If the component does not support usage through wireless
prevent a negative impact on the performance of the control system
interfaces, record:
functionality, it is a good practice to deploy dedicated devices to perform checks
c. Not relevant
for unauthorized network activity.

Use control for portable and mobile There is no component level requirement ISA-62443-4-2:
FSA-CR 2.3 No validation activity
devices associated with ISA‑62443‑3‑3 SR 2.3. CR 2.3

Mobile code technologies include, but are not limited to, Java, JavaScript,
In the event that a software application utilizes
ActiveX, portable document format (PDF), Postscript, Shockwave movies, Flash
mobile code technologies, that application shall
animations and VBScript. Usage restrictions apply to both the selection and use
provide the capability to enforce a security policy
of mobile code installed on servers and mobile code downloaded and executed
for the usage of mobile code technologies. The ISA-62443-4-2:
x FSA-SAR 2.4A Mobile code - control execution Future entry Future entry 1, 2, 3, 4 on individual workstations. Control procedures should prevent the development,
security policy shall allow, at a minimum, for SAR 2.4(a)
acquisition or introduction of unacceptable mobile code within the control
each mobile code technology used on the
system in which the component resides. For example, mobile code exchanges
software application, action to control execution
may be disallowed directly within the control system, but may be allowed in a
of mobile code.
controlled adjacent environment maintained by IACS personnel.

In the event that a software application utilizes

mobile code technologies, that application shall
provide the capability to enforce a security policy
for the usage of mobile code technologies. The
security policy shall allow, at a minimum, for ISA-62443-4-2:
x FSA-SAR 2.4B Mobile code - control transfer by user Future entry Future entry 1, 2, 3, 4 See FSA-SAR 2.4A
each mobile code technology used on the SAR 2.4(b)
software application, action to control which
users (human, software process, or device) are
allowed to transfer mobile code to/from the
application.

In the event that a software application utilizes

mobile code technologies, that application shall
provide the capability to enforce a security policy
for the usage of mobile code technologies. The
security policy shall allow, at a minimum, for ISA-62443-4-2:
x FSA-SAR 2.4C Mobile code - integrity check Future entry Future entry 1, 2, 3, 4 See FSA-SAR 2.4A
each mobile code technology used on the SAR 2.4(c)
software application, action to control the
execution of mobile code based on the results of
an integrity check prior to the code being
executed.

The application shall provide the capability to

enforce a security policy that allows the device to
ISA-62443-4-2:
x FSA-SAR 2.4 RE(1) Mobile code authenticity check control execution of mobile code based on the Future entry Future entry 2, 3, 4
SAR 2.4 RE(1)
results of an authenticity check prior to the code
being executed.

Copyright © 2018 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 18 of 42
 CSA-311 FR 2
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 1.5
Software Application

Embedded Device

Network Device
Host Device Validation by
Capability
Independent Source of
Requirement ID Reference Name Requirement Description Validation Activity Security Rationale and Supplemental Guidance
Test Required Requirement
Level
(Yes/No)

Review user documentation and determine if the

embedded device uses mobile code technologies.

If the embedded device uses mobile code technologies, Mobile code technologies include, but are not limited to, Java, JavaScript,
In the event that an embedded device utilizes
review user documentation and verify that there is a ActiveX, PDF, Postscript, Shockwave movies, Flash animations and VBScript.
mobile code technologies, the embedded device
configurable option to prevent each mobile code Usage restrictions apply to both the selection and use of mobile code installed
shall provide the capability to enforce a security
technology used, either from being transferred to the on servers and mobile code downloaded and executed on individual
policy for the usage of mobile code technologies. ISA-62443-4-2:
x FSA-EDR 2.4A Mobile code - control execution device or from being executed on the device. Record one No 1, 2, 3, 4 workstations. Control procedures should prevent the development, acquisition
The security policy shall allow, at a minimum, for EDR 2.4(a)
of: or introduction of unacceptable mobile code within the control system in which
each mobile code technology used on the
a. Met the component resides. For example, mobile code exchanges may be
embedded device, action to control execution of
b. Not met disallowed directly within the control system, but may be allowed in a controlled
mobile code.
adjacent environment maintained by IACS personnel.
If the embedded device does not use mobile code
technologies, record:
c. Not relevant

Review user documentation and determine if the

embedded device uses mobile code technologies.

In the event that an embedded device utilizes If the embedded device uses mobile code technologies,
mobile code technologies, the embedded device review component documentation and verify that there is
shall provide the capability to enforce a security a mechanism to control, for each mobile code technology,
policy for the usage of mobile code technologies. which users (human, software process, or device) are
ISA-62443-4-2:
x FSA-EDR 2.4.B Mobile code - control upload by user The security policy shall allow, at a minimum, for allowed to upload mobile code to the device. Record one No 1, 2, 3, 4 See FSA-EDR 2.4A
EDR 2.4(b)
each mobile code technology used on the of:
embedded device, action to control which users a. Met
(human, software process, or device) are b. Not met
allowed to upload mobile code to the device.
If the embedded device does not use mobile code
technologies, record:
c. Not relevant

Review user documentation and determine if the

embedded device uses mobile code technologies.
In the event that an embedded device utilizes
If the embedded device uses mobile code technologies,
mobile code technologies, the embedded device
review component documentation and verify that there is
shall provide the capability to enforce a security
a policy mechanism to require that an integrity check
policy for the usage of mobile code technologies.
must run and pass prior to mobile code execution, for ISA-62443-4-2:
x FSA-EDR 2.4C Mobile code - integrity check The security policy shall allow, at a minimum, for No 1, 2, 3, 4 See FSA-EDR 2.4A
each mobile technology used. Record one of: EDR 2.4(c)
each mobile code technology used on the
a. Met
embedded device, action to control the execution
b. Not met
of mobile code based on the results of an
integrity check prior to the code being executed.
If the embedded device does not use mobile code
technologies, record:
c. Not relevant

Review user documentation and determine if the

embedded device uses mobile code technologies.

Review component documentation and verify that there is

that there is a policy mechanism to require that an
The embedded device shall provide the
authenticity check must run and pass prior to mobile code
capability to enforce a security policy that allows
execution. ISA-62443-4-2:
x FSA-EDR 2.4 RE(1) Mobile code authenticity check the device to control execution of mobile code No 2, 3, 4
Record one of: EDR 2.4 RE(1)
based on the results of an authenticity check
a. Met
prior to the code being executed.
b. Not met

If the embedded device does not use mobile code

technologies, record:
c. Not relevant

Mobile code technologies include, but are not limited to, Java, JavaScript,
In the event that a host device utilizes mobile ActiveX, PDF, Postscript, Shockwave movies, Flash animations and VBScript.
code technologies, the host device shall provide Usage restrictions apply to both the selection and use of mobile code installed
the capability to enforce a security policy for the on servers and mobile code downloaded and executed on individual
ISA-62443-4-2:
x FSA-HDR 2.4A Mobile code - control execution usage of mobile code technologies. The security Future entry Future entry 1, 2, 3, 4 workstations. Control procedures should prevent the development, acquisition
HDR 2.4(a)
policy shall allow, at a minimum, for each mobile or introduction of unacceptable mobile code within the control system in which
code technology used on the host device, action the host device resides. For example, mobile code exchanges may be
to control execution of mobile code. disallowed directly with the control system, but may be allowed in a controlled
adjacent environment maintained by IACS personnel.

Copyright © 2018 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 19 of 42
 CSA-311 FR 2
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 1.5
Software Application

Embedded Device

Network Device
Host Device Validation by
Capability
Independent Source of
Requirement ID Reference Name Requirement Description Validation Activity Security Rationale and Supplemental Guidance
Test Required Requirement
Level
(Yes/No)

In the event that a host device utilizes mobile

code technologies, the host device shall provide
the capability to enforce a security policy for the
usage of mobile code technologies. The security
ISA-62443-4-2:
x FSA-HDR 2.4B Mobile code - control upload by user policy shall allow, at a minimum, for each mobile Future entry Future entry 1, 2, 3, 4 See FSA-HDR 2.4A
HDR 2.4(b)
code technology used on the host device, action
to control which users (human, software process,
or device) are allowed to upload mobile code to
the host device.

In the event that a host device utilizes mobile

code technologies, the host device shall provide
the capability to enforce a security policy for the
usage of mobile code technologies. The security
ISA-62443-4-2:
x FSA-HDR 2.4C Mobile code - integrity check policy shall allow, at a minimum, for each mobile Future entry Future entry 1, 2, 3, 4 See FSA-HDR 2.4A
HDR 2.4(c)
code technology used on the host device, action
to control the execution of mobile code based on
the results of an integrity check prior to the code
being executed.

The host device shall provide the capability to

enforce a security policy that allows the device to
ISA-62443-4-2:
x FSA-HDR 2.4 RE(1) Mobile code authenticity check control execution of mobile code based on the Future entry Future entry 2, 3, 4
HDR 2.4 RE(1)
results of an authenticity check prior to the code
being executed.

Mobile code technologies include, but are not limited to, Java, JavaScript,
ActiveX, PDF, Postscript, Shockwave movies, Flash animations and VBScript.
Usage restrictions apply to both the selection and use of mobile code installed
In the event that a network device utilizes mobile on servers and mobile code downloaded and executed on individual
code technologies, the network device shall workstations. Control procedures should prevent the development, acquisition
provide the capability to enforce a security policy or introduction of unacceptable mobile code within the control system in which
for the usage of mobile code technologies. The ISA-62443-4-2: the component resides. For example, mobile code exchanges may be
x FSA-NDR 2.4A Mobile code - control execution Future entry Future entry 1, 2, 3, 4
security policy shall allow, at a minimum, for NDR 2.4(a) disallowed directly within the control system, but may be allowed in a controlled
each mobile code technology used on the adjacent environment maintained by IACS personnel.
network device, action to control execution of Mobile code could be secured by adding integrity, authenticity, and
mobile code. authorization checks to the code itself (application layer), or for “just-in-time”
code execution through transmitting the mobile code via a secure
communications tunnel which provides these attributes, or any mechanism
equivalent to these options.

In the event that a network device utilizes mobile

code technologies, the network device shall
provide the capability to enforce a security policy
for the usage of mobile code technologies. The
security policy shall allow, at a minimum, for ISA-62443-4-2:
x FSA-NDR 2.4B Mobile code - control transfer by user Future entry Future entry 1, 2, 3, 4 See FSA-NDR 2.4A
each mobile code technology used on the NDR 2.4(b)
network device, action to control which users
(human, software process, or device) are
allowed to transfer mobile code to/from the
network device.

In the event that a network device utilizes mobile

code technologies, the network device shall
provide the capability to enforce a security policy
for the usage of mobile code technologies. The
ISA-62443-4-2:
x FSA-NDR 2.4C Mobile code - integrity check security policy shall allow, at a minimum, for Future entry Future entry 1, 2, 3, 4 See FSA-NDR 2.4A
NDR 2.4(c)
each mobile code technology used on the
network device, action to control the execution of
mobile code based on the results of an integrity
check prior to the code being executed.

The network device shall provide the capability to

enforce a security policy that allows the device to
ISA-62443-4-2:
x FSA-NDR 2.4 RE(1) Mobile code authenticity check control execution of mobile code based on the Future entry Future entry 2, 3, 4
NDR 2.4 RE(1)
results of an authenticity check prior to the code
being executed.

Copyright © 2018 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 20 of 42
 CSA-311 FR 2
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 1.5
Software Application

Embedded Device

Network Device
Host Device Validation by
Capability
Independent Source of
Requirement ID Reference Name Requirement Description Validation Activity Security Rationale and Supplemental Guidance
Test Required Requirement
Level
(Yes/No)

Review user documentation and determine if the

component provides a human user interface, which may
be accessed locally or via a network.

If the component provides a user interface, verify user

If a component provides a human user interface,
documents include evidence that the component provides Session locks are used to prevent access to specified workstations or nodes.
whether accessed locally or via a network, the
the capability to initiate a session lock for a human user Components should activate session lock mechanisms automatically after a
component shall provide the capability to protect
triggered by one of: session inactivity longer than a ISA-62443-4-2: configurable time period. In most cases, the session locks are configured at the
x x x x FSA-CR 2.5A Session lock - initiation against further access by initiating a session lock No 1, 2, 3, 4
configurable time period or manual initiation by the human CR 2.5(a) system level. Session locks implemented as part of this requirement may be
after a configurable time period of inactivity or by
user owning the session. Record one of: pre-empted or limited by remote session termination, as defined in CR 2.6 –
manual initiation by the user (human, software
a. Met Remote session termination.
process or device).
b. Not met

If the component does not provide a human user

interface, record:
c. Not relevant

Review user documentation and determine if the

component provides a human user interface, which may
be accessed locally or via a network.

If the component provides a human user interface, verify

user documents include evidence that the component
If a component provides a human user interface, provides the capability for a session lock, once initiated
whether accessed locally or via a network, the for any type of user session (human, software process, or
component shall provide the capability for the device), to remain in effect until either a human user who
session lock to remain in effect until the human owns the session, or another authorized human user, re- ISA-62443-4-2:
x x x x FSA-CR 2.5B Session lock - removal No 1, 2, 3, 4 See FSA-CR 2.5A
user who owns the session, or another establishes access using appropiate identification and CR 2.5(b)
authorized human user, re-establishes access authentication procedures. Record one of:
using appropriate identification and a. Met
authentication procedures. b. Not met

If the component does not provide a human user

interface, record:
c. Not relevant

Review user documentation and determine if the

component supports remote sessions.

If the component supports remote sessions, verify the

If a component supports remote sessions, the component has at least one of these capabilities: it is able A remote session is initiated whenever a component is accessed across the
component shall provide the capability to to be configured to automatically terminate a remote boundary of a zone defined by the asset owner based on their risk assessment.
terminate a remote session either automatically session after a configurable time period of inactivity, or a This requirement may be limited to sessions that are used for component
ISA-62443-4-2:
x x x x FSA-CR 2.6 Remote session termination after a configurable time period of inactivity, local authority may terminate a remote session. Record No 2, 3, 4 monitoring and maintenance activities (not critical operations) based on the risk
CR 2.6
manually by a local authority, or manually by the one of: assessment of the control system and security policies and procedures. Some
user (human, software process or device) who a. Met components may not allow sessions to be terminated as the session might be
initiated the session. b. Not met part of an essential function of the component.

If the component does not support remote sessions,

record:
c. Not relevant

Verify the component is able to be configured to limit the

number of concurrent sessions per interface, for any given
user (human, software process, or device). For all
A resource starvation DoS might occur if a limit is not imposed. There is a trade-
Components shall provide the capability to limit interfaces, verify that the supplier has executed and
off between potentially locking out a specific user versus locking out all users
the number of concurrent sessions per interface passed a test to verify this limit is enforced, by attempting ISA-62443-4-2:
x x x x FSA-CR 2.7 Concurrent session control Yes 3, 4 and services due to a lack of resources. Product supplier and/or system
for any given user (human, software process or to create more than the maximum number of sessions CR 2.7
integrator guidance is likely required to provide sufficient information as to how
device). allowed and verifying denial of connection once the
the number of concurrent sessions value should be assigned.
threshold is reached. Record one of:
a. Met
b. Not met

Copyright © 2018 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 21 of 42
 CSA-311 FR 2
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 1.5
Software Application

Embedded Device

Network Device
Host Device Validation by
Capability
Independent Source of
Requirement ID Reference Name Requirement Description Validation Activity Security Rationale and Supplemental Guidance
Test Required Requirement
Level
(Yes/No)

Verify via user documentation that the component

Components shall provide the capability to supports capability to generate audit records relevent to
Devices may contain either embedded firmware or run an OS. While the intent
generate audit records relevant to security for the security for the following categories: access control,
of the requirement is to cover categories of events, at least all events from the
following categories: access control, request request errors, control system events, backup and restore ISA-62443-4-2:
above categories that can be generated by the firmware or OS are to be
x x x x FSA-CR 2.8A Auditable events - categories errors, control system events, backup and events, configuration changes, and audit log events. Yes CR 2.8(a)-(f) first 1, 2, 3, 4
included.
restore event, configuration changes, and audit Verify via sample logs that some records from each of sentence
NOTE Security event categories are only applicable if functionality itself is
log events. these categories are generated. Record one of:
provided by the component.
a. Met
b. Not met

Verify via user documentation that all audit records in the

categories listed in FSA-CR 2.8A include timestamp,
Individual audit records shall include timestamp,
source (originating device, software process or human
source (originating device, software process or ISA-62443-4-2:
user account), category, type, event ID, and event result.
x x x x FSA-CR 2.8B Auditable events - data fields human user account), category, type, event ID, Yes CR 2.8(a)-(f) 1, 2, 3, 4 See FSA-CR 2.8A
Verify via sample logs that all of these fields have values
and event result. second sentence
present for all categories of records. Record one of:
a. Met
b. Not met

Components should provide sufficient audit storage capacity, taking into

Verify that the capacity for audit record storage on the
account retention policy, the auditing to be performed and the online audit
device is documented, and that the device provides this
processing requirements. Components may rely on the system into which they
Components shall provide the capability to capacity. Verify that evidence exists that the supplier
are integrated to provide the majority of audit storage capacity. However, the
allocate audit record storage capacity according performed analysis to confirm that the capacity will meet ISA-62443-4-2:
x x x x FSA-CR 2.9A Audit storage capacity - allocation No 1, 2, 3, 4 components should provide enough local storage to buffer audit data until it can
to commonly recognized recommendations for business and regulatory requirements of users. Record CR 2.9(a)
be sent to the system.
log management. one of:
Guidelines to be considered may include NIST Special Publication (SP) 800-92
a. Met
[26]. The audit storage capacity should be sufficient to retain logs for a period of
b. Not met
time required by applicable policies and regulations or business requirements.

Review design documentation or perform testing to verify

Components shall provide mechanisms to that all functions of the component are maintained when it
ISA-62443-4-2:
x x x x FSA-CR 2.9B Audit storage capacity - exceeded protect against a failure of the component when reaches or exceeds audit storage capacity. Record one of: No 1, 2, 3, 4 See FSA-CR 2.9A
CR 2.9(b)
it reaches or exceeds the audit storage capacity. a. Met
b. Not met

Review user documents and confirm that the component

has the capability to issue a warning when allocated audit
Components shall provide the capability to issue
Warn when audit record storage record storage volume on the component reaches a ISA-62443-4-2:
x x x x FSA-CR 2.9 RE(1) a warning when the allocated audit record No 3, 4
capacity threshold reached configurable threshold. Record one of: CR 2.9 RE(1)
storage reaches a configurable threshold.
a. Met
b. Not met

Audit generation typically occurs at the source of the event. Audit processing
involves transmission, possible augmentation (such as, the addition of a
Verify via design documentation that software or hardware timestamp) and persistent storage of the audit records. Audit processing failures
errors related to audit processing, or failures in the audit include, for example, software or hardware errors, failures in the audit capturing
Components shall provide the capability to capturing mechanisms, do not cause loss of essential mechanisms and audit storage capacity being reached or exceeded. Guidelines
Response to audit processing protect against the loss of essential services and functions of the component. Record: ISA-62443-4-2: to be considered when designing appropriate response actions may include the
x x x x FSA-CR 2.10A No 1, 2, 3, 4
failures - maintain essential functions functions in the event of an audit processing a. Met CR 2.10(a) NIST SP 800-92, Guide to Computer Security Log Management [26]. It should
failure. b. Not met be noted that either overwriting the oldest audit records or halting audit log
Note that validation for FSA-CR 2.9B separately validates generation are possible responses to audit storage capacity being exceeded but
another aspect this requirement. imply the loss of potentially essential forensic information. Also alerting
personnel could be an appropriate supporting action in response to an audit
processing failure.

Copyright © 2018 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 22 of 42
 CSA-311 FR 2
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 1.5
Software Application

Embedded Device

Network Device
Host Device Validation by
Capability
Independent Source of
Requirement ID Reference Name Requirement Description Validation Activity Security Rationale and Supplemental Guidance
Test Required Requirement
Level
(Yes/No)

Verify user documents include evidence that the audit

function supports one or more common accepted industry
practices and recommendations upon lack of storage
space to record new events, for example overwrite oldest
audit records or stop generating audit records. Verify via
testing that the device takes the action under these
Components shall provide the capability to conditions as described in the user documentation.
support appropriate actions in response to an
Response to audit processing ISA-62443-4-2:
x x x x FSA-CR 2.10B audit processing failure according to commonly Verify in design documentation that in the event of Yes 1, 2, 3, 4 See FSA-CR 2.10A
failures - actions taken CR 2.10(b)
accepted industry practices and software or hardware errors related to audit processing,
recommendations. one or more actions are taken in accordance with
common accepted industry practices and
recommendations, for example logging the event or
generating a notification. Record one of:
a. Met
b. Not met

A good reference for the format of timestamps is ISO/IEC 8601:2004, Data

Components shall provide the capability to Verify by reviewing sample audit records in each category, elements and interchange formats – Information interchange – Representation
ISA-62443-4-2:
x x x x FSA-CR 2.11 create timestamps (including date and time) for that audit records include timestamps. Record one of: Yes 1, 2, 3, 4 of dates and times [15]. Care should be taken when designing a system that
CR 2.11
use in audit records. a. Met periodic time-shift events, such as daylight savings time in some locations, are
b. Not met taken into account.

Verify using user documentation that the component can

Components shall provide the capability to be configured to synchronize time stamps with a system
ISA-62443-4-2:
x x x x FSA-CR 2.11 RE(1) Time synchronization create timestamps that are synchronized with a wide time source. Record one of: No 2, 3, 4
CR 2.11 RE(1)
system wide time source. a. Met
b. Not met

Verify user documents include evidence that unauthorized

The time synchronization mechanism shall alteration of time synchronization is detected and creates
provide the capability to detect unauthorized an audit event record. Record one of: ISA-62443-4-2:
x x x x FSA-CR 2.11 RE(2) Protection of time source integrity No 4
alteration and cause an audit event upon a. Met CR 2.11 RE(2)
alteration. b. Not met

Review user documentation and determine if the

component provides a human user interface that permits
actions by human users.

If the component provides such a human user interface, Examples of particular actions taken by a user include performing operator
verify component requirements documentation states that actions, changing control system configurations, creating information, sending a
all actions taken by human users, and the human user message, approving information (such as, indicating concurrence) and receiving
If a component provides a human user interface, responsible for those actions, are logged in the audit a message. Non-repudiation protects against later false claims by a user of not
the component shall provide the capability to records. Further verify that supplier test cases are mapped having taken a specific action, by an author of not having authored a particular
determine whether a given human user took a to this requirement and have passed. Record one of: document, by a sender of not having transmitted a message, by a receiver of
ISA-62443-4-2:
x x x x FSA-CR 2.12 Non-repudiation particular action. a. Met No 1, 2, 3, 4 not having received a message or by a signatory of not having signed a
CR 2.12
Control elements that are not able to support b. Not met document. Non-repudiation services can be used to determine if information
such capability shall be listed in component originated from a user, if a user took specific actions (for example, sending an
documents. If a component does not provide a such a human user email and approving a work order) or received specific information. Non-
interface, verify that the user manual for the component repudiation services are obtained by employing various techniques or
documents that the component does not have the ability mechanisms (for example, user identification and authorization, digital
to log user actions. If this can be verified, record: signatures, digital message receipts and timestamps).
a. Not relevant

If this cannot be vertified, record:

b. Not met

Copyright © 2018 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 23 of 42
 CSA-311 FR 2
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 1.5
Software Application

Embedded Device

Network Device
Host Device Validation by
Capability
Independent Source of
Requirement ID Reference Name Requirement Description Validation Activity Security Rationale and Supplemental Guidance
Test Required Requirement
Level
(Yes/No)

Review user and design documentation and determine if

the component permits actions by other than human
users (software processes or devices).

If the component permits such actions, verify

requirements for the component state that all actions
taken by a given user (software process or device), and
the user responsible for those actions, are logged in the
Components shall provide the capability to audit records. Further verify that supplier test cases are
determine whether a given user (human, mapped to this requirement and have passed. Record one ISA-62443-4-2:
x x x x FSA-CR 2.12 RE(1) Non-repudiation for all users No 4
software process or device) took a particular of: CR 2.12 RE(1)
action. a. Met
b. Not met

If a component does not permit such actions, record:

c. Not relevant

(Note that the case for human users is covered by FSA-

CR 2.12.)

Examine the embedded device hardware, and design

documentation for all device models in scope for the Factory diagnostic and test interface(s) are created at various locations within
certification, and the threat model, to identify any the embedded device to assist the embedded device’s developers and factory
diagnostic and test interfaces that provide an ability to personnel as they test the functional implementation, and when errors are
control the embedded device or to access non-public discovered to subsequently remove them from the embedded device . However,
information. If there are such interfaces, review user or these same interfaces must be carefully protected from access by unauthorized
design documents to verify that authentication entities to protect the essential functionality provided by the embedded device
authorization of an authenticated user assigned to a role to the IACS.
Embedded devices shall protect against
authorized to use them, is required to access them (in If a diagnostic and test interface does not provide an ability to control the
Use of physical diagnostic and test unauthorized use of the physical factory ISA-62443-4-2:
x FSA-EDR 2.13 which case they would be subject for FR 1 requirements), No 2, 3, 4 embedded device or to access non-public information, then it will not need an
interfaces diagnostic and test interface(s) (e.g. JTAG EDR 2.13
or that they are otherwise protected against unauthorized authentication mechanism. This shall be determined via a threat and risk
Debugging).
access. assessment. An example of this would be JTAG debugging, in which JTAG is
Record one of: used to take control of the processor and execute arbitrary commands, versus a
a. Met JTAG boundary scan where JTAG is used to simply read information (which
b. Not met may be publicly available information).
There may be cases where the factory diagnostic and test interface(s) use
If there are no such interfaces, record: network communications with the device. When this is the case those
c. Not relevant interfaces are to be subjected to all of the requirements of this document.

If applicable diagnostic or test interfaces are found in

validation of FSA-EDR 2.13, verify by testing that an audit
log entry is generated when an attempt is made to access
Embedded devices shall provide active
any of these interfaces. Record one of:
monitoring of the device’s diagnostic and test
a. Met ISA-62443-4-2:
x FSA-EDR 2.13 RE(1) Active monitoring interface(s) and generate an audit log entry Yes 3, 4
b. Not met EDR 2.13 RE(1)
when attempts to access these interface(s) are
detected.
If such interfaces are not found in validation of FSA-EDR
2.13, then record:
c. Not relevant

Factory diagnostic and test interface(s) are created at various locations within
the host device to assist the component’s developers and factory personnel as
they test the functional implementation, and when errors are discovered to
subsequently remove them from the component. However, these same
interfaces must be carefully protected from access by unauthorized entities to
protect the essential functionality provided by the component to the IACS.
There may be cases where the factory diagnostic and test interface(s) use
Host devices shall protect against unauthorized
Use of physical diagnostic and test ISA-62443-4-2: network communications with the device. When this is the case those
x FSA-HDR 2.13 use of the physical factory diagnostic and test Future entry Future entry 2, 3, 4
interfaces HDR 2.13 interfaces are to be subjected to all of the requirements of this document.
interface(s) (e.g. JTAG debugging).
If a diagnostic and test interface does not provide an ability to control the host
device or to access non-public information, then it will not need an
authentication mechanism. This shall be determined via a threat and risk
assessment. An example of this would be JTAG debugging, in which JTAG is
used to take control of the processor and execute arbitrary commands, versus a
JTAG boundary scan where JTAG is used to simply read information (which
may be publicly available information).

Copyright © 2018 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 24 of 42
 CSA-311 FR 2
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 1.5
Software Application

Embedded Device

Network Device
Host Device Validation by
Capability
Independent Source of
Requirement ID Reference Name Requirement Description Validation Activity Security Rationale and Supplemental Guidance
Test Required Requirement
Level
(Yes/No)

Host devices shall provide active monitoring of

the device’s diagnostic and test interface(s) and ISA-62443-4-2:
x FSA-HDR 2.13 RE(1) Active monitoring Future entry Future entry 3, 4
generate an audit log entry when attempts to HDR 2.13 RE(1)
access these interface(s) are detected.

Factory diagnostic and test interface(s) are created at various locations within
the component to assist the component’s developers and factory personnel as
they test the functional implementation, and when errors are discovered to
subsequently remove them from the component. However, these same
interfaces must be carefully protected from access by unauthorized entities to
protect the essential functionality provided by the component to the IACS.
Network devices shall protect against There may be cases where the factory diagnostic and test interface(s) use
Use of physical diagnostic and test unauthorized use of the physical factory ISA-62443-4-2: network communications with the device. When this is the case those
x FSA-NDR 2.13 Future entry Future entry 2, 3, 4
interfaces diagnostic and test interface(s) (e.g. JTAG NDR 2.13 interfaces are to be subjected to all of the requirements of this document.
debugging). Note that if a diagnostic and test interface does not provide the ability to control
the product, or to access non-public information, then it will not need an
authentication mechanism. This should be determined via a threat assessment.
An example of this would be JTAG debugging, in which JTAG is used to take
control of the processor and execute arbitrary commands, versus a JTAG
boundary scan where JTAG is used to simply read information (which may be
publicly available information).

Network devices shall provide active monitoring

of the device’s diagnostic and test interface(s) ISA-62443-4-2:
x FSA-NDR 2.13 RE(1) Active monitoring Future entry Future entry 3, 4
and generate an audit log entry when attempts to NDR 2.13 RE(1)
access these interface(s) are detected.

Copyright © 2018 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 25 of 42
 CSA-311 FR 3
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 1.5
Software Application

Embedded Device

Network Device
Host Device Validation by
Capability
Independent Source of
Requirement ID Reference Name Requirement Description Validation Activity Security Rationale and Supplemental Guidance
Test Required Requirement
Level
(Yes/No)

Many common network attacks are based on the manipulation of data in transmission, for example manipulation of
network packets. Switched or routed networks provide a greater opportunity for attackers to manipulate packets as
undetected access to these networks is generally easier and the switching and routing mechanisms themselves can also
be manipulated in order to get more access to transmitted information. Manipulation in the context of a control system
could include the change of measurement values communicated from a sensor to a receiver or the alteration of
command parameters sent from a control application to an actuator.
Depending on the context (for example transmission within a local network segment versus transmission via untrusted
networks) and the network type used in the transmission (for example transmission control protocol (TCP) / internet
protocol (IP) versus local serial links), feasible and appropriate mechanisms will vary. On a small network with direct
Examine design and user documents and
links (point-to-point), physical access protection to all nodes may be sufficient on lower SLs if the endpoints’ integrity is
determine if the component provides the
protected as well (see 7.6, CR 3.4 – Software and information integrity), while on a network distributed in areas with
capability to protect the data it transmits against
regular physical presence of staff or on a wide area network physical access is likely not enforceable. If a commercial
changes to message content. Protection
service is used to provide communication services as a commodity item rather than a fully dedicated service (for
provided shall be beyond that provided by the
Components shall provide the example a leased line versus a T1 link), it may be more difficult to obtain the necessary assurances regarding the
transport layer. An example is the use of ISA-62443-4-2:
x x x x FSA-CR 3.1 Communication integrity capability to protect integrity of No 1, 2, 3, 4 implementation of needed security controls for communication integrity (for example because of legal restrictions). When
cryptographic hashes. Record one of: CR 3.1
transmitted information. it is infeasible or impractical to meet the necessary security requirements it may be appropriate to implement either
a. Met
appropriate compensating countermeasures or explicitly accept the additional risk.
b. Not met
Industrial equipment is often subject to environmental conditions that can lead to integrity issues and/or false positive
incidents. Many times the environment contains particulates, liquids, vibration, gases, radiation, and electromagnetic
interference (EMI) that can cause conditions that affect the integrity of the communication wiring and signals. The
network infrastructure should be designed to minimize these physical/environmental effects on communication integrity.
For example, when particulate, liquids, and/or gases are an issue, it may be necessary to use a sealed registered jack 45
(RJ-45) or M12 connector instead of a commercial-grade RJ-45 connector on the wire. The cable itself may need to use
a different jacket instead to handle the particulate, liquid, and/or gas as well. In cases where vibration is an issue, M12
connectors may be necessary to prevent the spring pins on an RJ-45 connector from disconnecting during use. In cases
where radiation and/or EMI are an issue, it may be necessary to use shielded twisted pair or fiber cables to prevent any
effect on the communication signals. It may also be necessary to perform a wireless spectrum analysis in these areas if
wireless networking is planned to verify that it is a viable solution.

Examine design and user documents and

Components shall provide the
determine whether the origin of data received
capability to verify the
Communication by the component can be validated by the ISA-62443-4-2:
x x x x FSA-CR 3.1 RE(1) authenticity of received No 2, 3, 4
authentication component. Record one of: CR 3.1 RE(1)
information during
a. Met
communication.
b. Not met

The application product supplier

shall qualify and document Protection from malicious code (for example, viruses, worms, Trojan horses and spyware) may be provided by the
which protection from malicious control system application or by an external service or application. Control system applications need to be compatible
Protection from malicious ISA-62443-4-2:
x FSA-SAR 3.2 code mechanisms are Future entry Future entry 1, 2, 3, 4 with mechanisms designed to protect them from malicious code. This requirement does not imply that the product
code SAR 3.2
compatible with the application supplier is to qualify and document all malicious code protection mechanisms which are compatible with the application
and note any special but implies that the product supplier is to qualify and document at least one mechanism.
configuration requirements.

Unauthorized software may contain malicious code and thus be harmful to the component. If an embedded device is
able to utilize a compensating control, it need not directly support protection from malicious code. It is assumed that the
Verify that design or user documents contain IACS will be responsible for providing the required safeguards. However, for scenarios such as having a local universal
The embedded device shall evidence that the embedded device supports serial bus (USB) host access, the need for protection from malicious code should be determined by a risk assessment.
Protection from malicious provide the capability to protect protections from installation and execution of ISA-62443-4-2: Detection mechanisms should be able to detect integrity violations of application binaries and data files. Techniques may
x FSA-EDR 3.2 No 1, 2, 3, 4
code from installation and execution unauthorized software. Record one of: EDR 3.2 include, but are not limited to, binary integrity and attributes monitoring, hashing and signature techniques.
of unauthorized software. a. Met Prevention techniques may include, but are not limited to, removable media control, sandbox techniques and specific
b. Not met computing platforms mechanisms such as restricted firmware update capabilities, No Execute (NX) bit, data execution
prevention (DEP), address space layout randomization (ASLR), stack corruption detection and mandatory access
controls. See 10.4 for an associated requirement involving control system monitoring tools and techniques.

Copyright © 2018 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 26 of 42
 CSA-311 FR 3
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 1.5
Software Application

Embedded Device

Network Device
Host Device Validation by
Capability
Independent Source of
Requirement ID Reference Name Requirement Description Validation Activity Security Rationale and Supplemental Guidance
Test Required Requirement
Level
(Yes/No)

There shall be mechanisms on

host devices that are qualified
by the IACS product supplier to
provide protection from Host devices need to support the use of malicious code protection (against, for example, viruses, worms, Trojan horses
Protection from malicious ISA-62443-4-2:
x FSA-HDR 3.2 malicious code. The IACS Future entry Future entry 1, 2, 3, 4 and spyware) . The product supplier should qualify and document the configuration of protection from malicious code
code HDR 3.2
product supplier shall document mechanisms so that the primary mission of the control system is maintained.
any special configuration
requirements related to
protection from malicious code.

The host device shall

automatically report the
Report version of code software and file versions of ISA-62443-4-2:
x FSA-HDR 3.2 RE(1) Future entry Future entry 2, 3, 4
protection protection from malicious code HDR 3.2 RE(1)
in use (as part of overall logging
function).

If a network device is able to utilize a compensating control, it need not directly support protection from malicious code.
The network device shall One such possible compensating control would be the use of network packet filtering devices to identify and remove
Protection from malicious ISA-62443-4-2:
x FSA-NDR 3.2 provide for protection from Future entry Future entry 1, 2, 3, 4 malicious code while in transit. It is assumed that the IACS will be responsible for providing the required safeguards.
code NDR 3.2
malicious code. However, for scenarios such as having a local USB host access, the need for protection from malicious code should be
evaluated.

The product supplier and/or system integrator should provide guidance on how to test the designed security controls.
Asset owners need to be aware of the possible ramifications of running these verification tests during normal operations.
Details of the execution of these verifications need to be specified with careful consideration of the requirements for
Verify component provides methods to test continuous operations (for example, scheduling or prior notification).
security functions during FAT, SAT and Examples of security verification functions include:
Components shall provide the scheduled maintenance. These security • Verification of antivirus countermeasures by European Institute for Computer Antivirus Research (EICAR) testing of the
capability to support verification functions shall include all those necessary to control system file system. Antivirus software should detect the EICAR test samples and appropriate incident handling
Security functionality ISA-62443-4-2:
x x x x FSA-CR 3.3 of the intended operation of support the security requirements specified in No 1, 2, 3, 4 procedures should be triggered.
verification CR 3.3
security functions according to the ISA-62443-4-2 standard. • Verification of the identification, authentication and use control countermeasures by attempting access with an
ISA‑62443‑3‑3 [11] SR3.3. Record one of: unauthorized account (for some functionality this could be automated).
a. Met • Verification of intrusion detection systems (IDSs) as a security control by including a rule in the IDS that triggers on
b. Not met irregular, but known non-malicious traffic. The test could then be performed by introducing traffic that triggers this rule
and the appropriate IDS monitoring and incident handling procedures.
• Confirmation that audit logging is occurring as required by security policies and procedures and has not been disabled
by an internal or external entity.

Components shall provide the Verify component provides methods to test

Security functionality capability to support verification security functions during normal operation.
ISA-62443-4-2:
x x x x FSA-CR 3.3 RE(1) verification during normal of the intended operation of Record one of: No 4
CR 3.3 RE(1)
operation security functions during normal a. Met
operations. b. Not met

Copyright © 2018 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 27 of 42
 CSA-311 FR 3
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 1.5
Software Application

Embedded Device

Network Device
Host Device Validation by
Capability
Independent Source of
Requirement ID Reference Name Requirement Description Validation Activity Security Rationale and Supplemental Guidance
Test Required Requirement
Level
(Yes/No)

Verify that user documentation describes

Components shall provide the
manual or automated integrity mechanisms
capability to perform or support
(such as cryptographic hashes) to verify the
integrity checks on software,
integrity of component software and Integrity verification methods are employed to detect, record, report and protect against software and information
configuration and other
configuration information as well as the tampering that may occur if other protection mechanisms (such as authorization enforcement) have been circumvented.
Software and information information as well as the ISA-62443-4-2:
x x x x FSA-CR 3.4 recording and reporting of the results of these No 1, 2, 3, 4 Components should employ formal or recommended integrity mechanisms (such as cryptographic hashes). For example,
integrity recording and reporting of the CR 3.4
checks, either directly or by integration into a such mechanisms could be used to monitor field devices for their latest configuration information to detect security
results of these checks or be
system. Record one of: breaches (including unauthorized changes).
integrated into a system that
a. Met by component
can perform or support integrity
b. Met by integration into system
checks.
c. Not met

Components shall provide the Verify that user documentation describes

capability to perform or support manual or automated authenticity mechanisms
authenticity checks on software, (such as digital signatures) to authenticate the
configuration and other origin of component software and configuration
Authenticity of software and information as well as the information as well as the recording and ISA-62443-4-2:
x x x x FSA-CR 3.4 RE(1) No 2, 3, 4
information recording and reporting of the reporting of the results of these checks. Record CR 3.4 RE(1)
results of these checks or be one of:
integrated into a system that a. Met by component
can perform or support b. Met by integration into system
authenticity checks. c. Not met

If component directly supports the capability

under FSA-CR 3.4, verify component provides
automated methods to verify software and
If the component is performing
configuration integrity and to provide automated
the integrity check, it shall be
notification to a configurable entity. Record one
capable of automatically
Automated notification of of: ISA-62443-4-2:
x x x x FSA-CR 3.4 RE(2) providing notification to a No 3, 4
integrity violations a. Met CR 3.4 RE(2)
configurable entity upon
b. Not met
discovery of an attempt to make
an unauthorized change.
If the component does not directly support the
capability under FSA-CR 3.4, record:
c. Not relevant

No validation activity for the FSA element of Rules for checking the valid syntax of input data such as set points should be in place to verify that this information has
Components shall validate the certification. not been tampered with and is compliant with the specification. Inputs passed to interpreters should be pre-screened to
syntax, length and content of prevent the content from being unintentionally interpreted as commands. Note that this is a security CR, thus it does not
any input data that is used as an This requirement is covered in the SDLPA address human error, for example supplying a legitimate integer number which is outside the expected range.
ISA-62443-4-2:
x x x x FSA-CR 3.5 Input validation industrial process control input element of certification, by the validations for No 1, 2, 3, 4 Generally accepted industry practices for input data validation include out-of-range values for a defined field type, invalid
CR 3.5
or input via external interfaces ISA-62443-4-1 requirements SVV-1 and SI-2, characters in data fields, missing or incomplete data and buffer overflow. Additional examples where invalid inputs lead
that directly impacts the action defined in the ISASecure document SDLA-312 to system security issues include SQL injection attacks, cross-site scripting or malformed packets (as commonly
of the component. as requirements SDLA-SVV-1C and SDLA-SI- generated by protocol fuzzers). Guidelines to be considered should include well-known guidelines such as the Open
2E. Web Application Security Project (OWASP) Code Review Guide [28].

Review user documentation and determine if

the component can physically or logically
connect to an automation process.
The deterministic behavior of control system outputs as a result of threat actions against the control system devices and
Components that physically or If the component can physically or logically
software is an important characteristic to ensure the integrity of normal operations. Ideally, the device continues to
logically connect to an connect to an automation process, review user
operate normally while under attack, but if the control system cannot maintain normal operation, then the control system
automation process shall documentation and verify that the component
outputs need to fail to a predetermined state. The appropriate predetermined state of control system outputs is device
provide the capability to set will set outputs of an automation process to a ISA-62443-4-2:
x x x x FSA-CR 3.6 Deterministic output No 1, 2, 3, 4 dependent and could be one of the following user configurable options:
outputs to a predetermined predetermined state if normal operation can not CR 3.6
• Unpowered – the outputs fail to the unpowered state;
state if normal operation as be maintained. Record one of:
• Hold – the outputs fail to the last-known good value; or
defined by the component a. Met
• Fixed – the outputs fail to a fixed value that is determined by the asset owner or an application; or
supplier cannot be maintained. b. Not met
• Dynamic – the outputs fail to one of the above options based on the current state.
If the component can not physically or logically
connect to an automation process, record:
c. Not relevant

Copyright © 2018 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 28 of 42
 CSA-311 FR 3
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 1.5
Software Application

Embedded Device

Network Device
Host Device Validation by
Capability
Independent Source of
Requirement ID Reference Name Requirement Description Validation Activity Security Rationale and Supplemental Guidance
Test Required Requirement
Level
(Yes/No)

Supplier provides a list of all error messages

returned to a non administrative user. Verify for The product supplier and/or system integrator should carefully consider the structure and content of error messages.
Components shall identify and samples from this list that component error Error messages generated by the component should provide timely and useful information without revealing potentially
handle error conditions in a messages do not reveal sensitive information harmful information that could be used by adversaries to exploit the IACS. Disclosure of this information should be
manner that does not provide that could be exploited to attack the component. ISA-62443-4-2: justified by the necessity for timely resolution of error conditions. Guidelines to be considered could include well-known
x x x x FSA-CR 3.7 Error handling No 1, 2, 3, 4
information that could be Verify that the supplier has performed a security CR 3.7 guidelines such as the OWASP Code Review Guide.
exploited by adversaries to expert review of all error messages for such NOTE: A good example of an error message that could help adversaries attack an IACS would be to provide details of
attack the IACS. exploitable information. Record one of: why authentication with the system failed. For example stating invalid user or invalid password in the feedback would
a. Met help an adversary attack the IACS and thus should not be provided.
b. Not met

Review user documentation and determine if

This control focuses on communications protection at the session, versus packet, level. The intent of this control is to
sessions are used.
establish grounds for confidence at each end of a communications session in the ongoing identity of the other party and
Components shall provide
in the validity of the information being transmitted. For example, this control addresses man-in-the-middle attacks
mechanisms to protect the If sessions are used, verify that design
including session hijacking, insertion of false information into a session or replay attacks. Use of session integrity
integrity of communications documentation confirms that user session
mechanisms can have a significant overhead and therefore their use should be considered in light of requirements for
Session integrity - invalidate sessions including the capability identifiers are invalidated upon user logout or ISA-62443-4-2:
x x x x FSA-CR 3.8A No 2, 3, 4 real-time communications.
session identifiers to invalidate session identifiers other session termination. Record one of: CR 3.8(a)
Session hijacking and other man-in-the-middle attacks or injections of false information often take advantage of easy-to-
upon user logout or other a. Met
guess session IDs (keys or other shared secrets) or use of session IDs that were not properly invalidated after session
session termination (including b. Not met
termination. Therefore the validity of a session authenticator should be tightly connected to the lifetime of a session.
browser sessions).
Employing randomness in the generation of unique session IDs helps to protect against brute-force attacks to determine
If sessions are not used, record:
future session IDs.
c. Not relevant

Review user documentation and determine if

sessions are used.
Components shall provide
If sessions are used, verify that design
mechanisms to protect the
documents indicate that the component can
integrity of communications
generate user session identifiers for each
Session integrity - generate sessions including the capability
session that are unique and that session IDs not ISA-62443-4-2:
x x x x FSA-CR 3.8B and recognize session to generate a unique session No 2, 3, 4 See FSA-CR 3.8A
generated by the system are rejected. Record CR 3.8(b)
identifiers identifier for each session and
one of:
recognize only session
a. Met
identifiers that are system-
b. Not met
generated.
If sessions are not used, record:
c. Not relevant

Review user documentation and determine if

sessions are used.
Components shall provide
mechanisms to protect the
If sessions are used, verify that user session
integrity of communications
identifiers are generated by the system with an
Session integrity - random sessions including the capability ISA-62443-4-2:
x x x x FSA-CR 3.8C accepted level of randomness. Record one of: No 2, 3, 4 See FSA-CR 3.8A
session identifiers to generate unique session CR 3.8(c)
a. Met
identifiers with commonly
b. Not met
accepted sources of
randomness.
If sessions are not used, record:
c. Not relevant

Review component documentation and verify

that audit information and audit tools (if present)
Components shall protect audit require authorization in order to access, modify
Audit information includes all information (for example, audit records, audit settings and audit reports) needed to
information, audit logs, and or delete, for any interface through which these
Protection of audit ISA-62443-4-2: successfully audit control system activity. The audit information is important for error correction, security breach
x x x x FSA-CR 3.9 audit tools (if present) from are accessible. Attempt to delete an audit log Yes 2, 3, 4
information CR 3.9 recovery, investigations and related efforts. Mechanisms for enhanced protection against modification and deletion
unauthorized access, as an unauthorized user and verify that access
include the storage of audit information to hardware-enforced write-once media.
modification and deletion. is denied. Record one of:
a. Met
b. Not met

Review component documentation and verify

Components shall provide the that the component has the capability to
Audit records on write-once capability to store audit records produce audit records on hardware-enforced ISA-62443-4-2:
x x x x FSA-CR 3.9 RE(1) No 4
media on hardware-enforced write- write-once media. Record one of: CR 3.9 RE(1)
once media. a. Met
b. Not met

Copyright © 2018 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 29 of 42
 CSA-311 FR 3
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 1.5
Software Application

Embedded Device

Network Device
Host Device Validation by
Capability
Independent Source of
Requirement ID Reference Name Requirement Description Validation Activity Security Rationale and Supplemental Guidance
Test Required Requirement
Level
(Yes/No)

Verify by examining design documentation and

user documentation, that elements of the
embedded device can be updated and Embedded devices over their installed lifetime may have the need for installation of updates and upgrades. There will
The embedded device shall upgraded. Typical elements are software and be cases where embedded devices are supporting or executing essential functions as well. When this is the case the
ISA-62443-4-2:
x FSA-EDR 3.10 Support for updates support the ability to be updated firmware. Update and upgrade are defined in No 1, 2, 3, 4 embedded device needs to have mechanisms in place to support patching and updating without impacting the essential
EDR 3.10
and upgraded. ISA-62443-4-2 sub clauses 3.1.48 and 3.1.49. functions of high availability systems (see 4.2 CCSC 1 Support of essential functions). One example for providing this
Record one of: capability would be to support redundancy within the embedded device.
a. Met
b. Not met

Verify that the component provides measures to

verify prior to installation, that software updates
and upgrades originate from the supplier.

Verify in design and user documention and by

testing that the component provides measures
The embedded device shall to detect changes to software that have
Update authenticity and validate the authenticity and occurred after creation by the supplier and prior ISA-62443-4-2:
x FSA-EDR 3.10 RE(1) Yes 2, 3, 4
integrity integrity of any software update to installation. EDR 3.10 RE(1)
or upgrade prior to installation.
One possible method to meet this requirement
is to validate digital signatures and
cryptographic hashes.
Record one of:
a. Met
b. Not met

Host devices over their installed lifetime may have the need for installation of updates and upgrades. There will be
Host devices shall support the cases where host devices are supporting or executing essential functions as well. When this is the case the host device
ISA-62443-4-2:
x FSA-HDR 3.10 Support for updates ability to be updated and Future entry Future entry 1, 2, 3, 4 should have mechanisms in place to support patching and updating without impacting the essential functions of high
HDR 3.10
upgraded. availability systems (see 4.2 CSSC 1 Support of essential functions). One example for providing this capability would be
to support redundancy within the host device.

Host devices shall validate the

Update authenticity and authenticity and integrity of any ISA-62443-4-2:
x FSA-HDR 3.10 RE(1) Future entry Future entry 2, 3, 4
integrity software update or upgrade HDR 3.10 RE(1)
prior to installation.

Network devices over their installed lifetime may require installation of updates and upgrades. There will be cases
Network devices shall support where network devices are supporting or executing essential functions as well. When this is the case the network device
ISA-62443-4-2:
x FSA-NDR 3.10 Support for updates the ability to be updated and Future entry Future entry 1, 2, 3, 4 should have mechanisms in place to support patching and updating without impacting the essential functions of high
NDR 3.10
upgraded. availability systems (see 4.2 CCSC 1 Support of essential functions). One example for providing this capability would be
to support redundancy within the network device.

Network devices shall validate

Update authenticity and the authenticity and integrity of ISA-62443-4-2:
x FSA-NDR 3.10 RE(1) Future entry Future entry 2, 3, 4
integrity any software update or upgrade NDR 3.10 RE(1)
prior to installation.

The purpose of tamper resistance mechanisms is to prevent an attempt by an attacker to execute an unauthorized
Examine the threat model for the component to
physical action against an IACS device. Secondary to prevention, detection and response are essential should a
verify that it enumerates possible integrity and
tampering event occur.
The embedded device shall confidentiality threats to the component due to
Tamper resistance mechanisms are most effectively used in combinations to prevent access to any critical components.
provide tamper resistance and physical access. Verify for each of these
Physical tamper resistance ISA-62443-4-2: Tamper resistance consists of using specialized materials to make tampering of a device or module difficult. This can
x FSA-EDR 3.11 detection mechanisms to threats, that either they are prevented with No 2, 3, 4
and detection EDR 3.11 include such features as hardened enclosures, locks, encapsulation, or security screws. Putting in place tight airflow
protect against unauthorized physical mechanisms,or that carrying out the
paths will increase the difficulty of probing the product internals.
physical access into the device. threat creates tamper evidence. Record one of:
The purpose of tamper evidence is to ensure that visible or electronic evidence remains when a tampering event occurs.
a. Met
Many simple evidence techniques are comprised of seals and tapes to make it obvious that there has been physical
b. Not met
tampering. More sophisticated techniques include switches.

Copyright © 2018 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 30 of 42
 CSA-311 FR 3
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 1.5
Software Application

Embedded Device

Network Device
Host Device Validation by
Capability
Independent Source of
Requirement ID Reference Name Requirement Description Validation Activity Security Rationale and Supplemental Guidance
Test Required Requirement
Level
(Yes/No)

Verify in the threat model that high risk events

The embedded device shall be
of unauthorized physical access are mitigated
capable of automatically
by automatic notification.
providing notification to a
configurable set of recipients
Verify that the component provides the
Notification of a tampering upon discovery of an attempt to ISA-62443-4-2:
x FSA-EDR 3.11 RE(1) capability to automatically provide notification to No 3, 4
attempt make an unauthorized physical EDR 3.11 RE(1)
a configurable set of recipients when such an
access. All notifications of
access is detected, and to create an audit
tampering shall be logged as
record for this notification. Record one of:
part of the overall audit logging
a. Met
function.
b. Not met

The purpose of tamper resistance mechanisms is to prevent an attempt by an attacker to execute an unauthorized
physical action against an IACS device. Secondary to prevention, detection and response are essential should a
Host devices shall provide the tampering event occur.
capability to support tamper Tamper resistance mechanisms are most effectively used in combinations to prevent access to any critical components.
Physical tamper resistance resistance and detection ISA-62443-4-2: Tamper resistance consists of using specialized materials to make tampering of a device or module difficult. This can
x FSA-HDR 3.11 Future entry Future entry 2, 3, 4
and detection mechanisms to protect against HDR 3.11 include such features as hardened enclosures, locks, encapsulation, or security screws. Putting in place tight airflow
unauthorized physical access paths will increase the difficulty of probing the product internals.
into the device The purpose of tamper evidence is to ensure that visible or electronic evidence remains when a tampering event occurs.
Many simple evidence techniques are comprised of seals and tapes to make it obvious that there has been physical
tampering. More sophisticated techniques include switches.

Host devices shall be capable of

automatically providing
notification to a configurable set
of recipients upon discovery of
Notification of a tampering ISA-62443-4-2:
x FSA-HDR 3.11 RE(1) an attempt to make an Future entry Future entry 3, 4
attempt HDR 3.11 RE(1)
unauthorized physical access.
All notifications of tampering
shall be logged as part of the
overall audit logging function.

The purpose of tamper resistance mechanisms is to prevent an attempt by an attacker to execute an unauthorized
physical action against an IACS device. Secondary to prevention, detection and response are essential should a
tampering event occur.
Network devices shall provide
Tamper resistance mechanisms are most effectively used in combinations to prevent access to any critical components.
tamper resistance and detection
Physical tamper resistance ISA-62443-4-2: Tamper resistance consists of using specialized materials to make tampering of a device or module difficult. This can
x FSA-NDR 3.11 mechanisms to protect against Future entry Future entry 2, 3, 4
and detection NDR 3.11 include such features as hardened enclosures, locks, encapsulation, or security screws. Putting in place tight airflow
unauthorized physical access
paths will increase the difficulty of probing the product internals.
into the device.
The purpose of tamper evidence is to ensure that visible or electronic evidence remains when a tampering event occurs.
Many simple evidence techniques are comprised of seals and tapes to make it obvious that there has been physical
tampering. More sophisticated techniques include switches.

Network devices shall be

capable of automatically
providing notification to a
configurable set of recipients
Notification of a tampering upon discovery of an attempt to ISA-62443-4-2:
x FSA-NDR 3.11 RE(1) Future entry Future entry 3, 4
attempt make an unauthorized physical NDR 3.11 RE(1)
access. All notifications of
tampering shall be logged as
part of the overall audit logging
function.

Copyright © 2018 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 31 of 42
 CSA-311 FR 3
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 1.5
Software Application

Embedded Device

Network Device
Host Device Validation by
Capability
Independent Source of
Requirement ID Reference Name Requirement Description Validation Activity Security Rationale and Supplemental Guidance
Test Required Requirement
Level
(Yes/No)

Examine supplier documentation of the

component design and manufacturing process
to verify that during the process for creating any
In order for a component to be able to validate the authenticity and integrity of the hardware, software, and data
roots of trust for the device, and thereafter, the
provided by the product supplier, it must possess a trusted source of data to perform the validation process. This trusted
product supplier keys and data to be used as
source of data is referred to as the “root of trust” for the system. This trusted source of data may be a set of
Embedded devices shall provide roots of trust, are handled within the device
cryptographic hashes of “known good” software, or it may be the public portion of an asymmetric cryptographic key pair
the capability to provision and such that they cannot be accessed in any
to be used in the validation of cryptographic signatures. This trusted data is often used to validate critical software,
protect the confidentiality, manner other than by the functions in the device
Provisioning product firmware, and data prior to booting the firmware or operating system of a component, in order to validate that the
integrity, and authenticity of that require the usage of this information. Verify ISA-62443-4-2:
x FSA-EDR 3.12 supplier roots of trust - No 2, 3, 4 component will boot into a “known good” state in which all security mechanisms are known to be operational and
product supplier keys and data that the threat model analyzes threats to the EDR 3.12
protection uncompromised. “Root of trust” data is often protected via hardware mechanisms, preventing any modification of the
to be used as one or more confidentiality, integrity and authenticity of the
data during normal operations of the component. Modification of product supplier root onique session IDs helps to
“roots of trust” at the time of roots of trust at the time of device manufacture
protect against brute-force attacks to determine future session IDs.ould then be performed by introducing traffic that
manufacture of the device. and as used thereafter, and that these threats
triggers this rule and the appropriate IDS monitoring and incident handling procedures.
have been mitigated. Use of a trusted store or a
• Confirmation that audit logging is occurring as required by security policies and procedures and has not been disabled
trusted zone are examples of methods to meet
by an internal or external entity. dity item r
this requirement. Record one of:
a. Met
b. Not met

In order for a component to be able to validate the authenticity and integrity of the hardware, software, and data
provided by the product supplier, it must possess a trusted source of data to perform the validation process. This trusted
source of data is referred to as the “root of trust” for the system. This trusted source of data may be a set of
Host devices shall provide the
cryptographic hashes of “known good” software, or it may be the public portion of an asymmetric cryptographic key pair
capability to provision and
to be used in the validation of cryptographic signatures. This trusted data is often used to validate critical software,
protect the confidentiality,
Provisioning product firmware, and data prior to booting the firmware or operating system of a component, in order to validate that the
integrity, and authenticity of ISA-62443-4-2:
x FSA-HDR 3.12 supplier roots of trust - Future entry Future entry 2, 3, 4 component will boot into a “known good” state in which all security mechanisms are known to be operational and
product supplier keys and data HDR 3.12
protection uncompromised. “Root of trust” data can be protected by software or hardware implemented mechanisms to prevent
to be used as one or more
any modification of the data during normal operations of the component. Modification of product supplier root of trust
“roots of trust” at the time of
data is typically limited to the product supplier’s provisioning process, where the product supplier has a trusted process
manufacture of the device.
to perform the provisioning of the data. Instead, information to be validated against the root of trust is submitted to the
validation process through a hardware or software API which performs the validation and returns the results without
exposing the protected data.

In order for a component to be able to validate the authenticity and integrity of the hardware, software, and data
provided by the product supplier, it must possess a trusted source of data to perform the validation process. This trusted
source of data is referred to as the “root of trust” for the system. This trusted source of data may be a set of
Network devices shall provide
cryptographic hashes of “known good” software, or it may be the public portion of an asymmetric cryptographic key pair
the capability to provision and
to be used in the validation of cryptographic signatures. This trusted data is often used to validate critical software,
protect the confidentiality,
firmware, and data prior to booting the firmware or operating system of a component, in order to validate that the
integrity, and authenticity of ISA-62443-4-2:
x FSA-NDR 3.12 Future entry Future entry 2, 3, 4 component will boot into a “known good” state in which all security mechanisms are known to be operational and
product supplier keys and data NDR 3.12
uncompromised. “Root of trust” data is often protected by software or hardware implemented mechanisms to prevent
to be used as one or more
any modification of the data during normal operations of the component. Modification of product supplier root of trust
“roots of trust” at the time of
data is typically limited to the product supplier’s provisioning process, where the product supplier has a trusted process
manufacture of the device.
to perform the provisioning of the data. Instead, information to be validated against the root of trust is submitted to the
validation process through a hardware or software API which performs the validation and returns the results without
exposing the protected data.

Product suppliers have established mechanisms to ensure that the software and firmware on their components is
Examine user documentation to verify that after authentic, and the integrity of that software and firmware has not been compromised. This allows the product supplier to
an asset owner has assumed responsibility for a provide the asset owner with a “known good” state from which to operate. However, many product suppliers also
device, a process exists for the asset owner to provide mechanisms for asset owners to extend the functionality of their devices through the use of mobile code, user
create and use roots of trust for the device. programs, or other such means. In order to protect the security of the component, it is important that these extensions to
Verify in design documentation that the asset the component’s functionality also be validated to ensure that they are authorized, and that the asset owner has
owner keys amd data to be used as roots of approved of their origins.
Embedded devices shall provide trust, are handled within the device such that In order to perform these validations the component must contain data that provides a way to differentiate between valid
the capability to provision and they cannot be accessed in any manner other and invalid origins. The list of valid and invalid origins will differ from asset owner to asset owner, and it is unlikely that a
Provisioning asset owner protect the confidentiality, than by the functions in the device that require ISA-62443-4-2: product supplier will have a complete list of every possible valid origin at time of manufacture. Therefore it is important
x FSA-EDR 3.13A No 2, 3, 4
roots of trust - protection integrity, and authenticity of the usage of this information. Verify that the EDR 3.13(a) that the product supplier provide a way for the asset owner to securely provision their own “roots of trust” which provide
asset owner keys and data to be threat model analyzes threats to the the ability to distinguish between origins allowed by the asset owner’s security policy, and those that are not. The
used as “roots of trust”. confidentiality, integrity, and authenticity of the authenticity and integrity of these “roots of trust” must be protected so that malicious actors cannot add additional roots
asset owner roots of trust and that these threats of trust that grant them the ability to operate on the component.
have been mitigated. Use of a trusted store or a A root of trust can also be used as a basis communications security, such as communications integrity required by CR
trusted zone are examples of methods to meet 3.1 – Communication integrity or communications confidentiality required by CR 4.1 – Information confidentiality.
this requirement. Record one of: Requirements such as EDR 2.4 – Mobile code require the component to complete authenticity checks on mobile code
a. Met prior to the execution of mobile code. The roots of trust provided by this requirement provide the data necessary to
b. Not met validate the origin and integrity of mobile code, allowing the component to independently determine if the code is
allowed to execute.

Copyright © 2018 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 32 of 42
 CSA-311 FR 3
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 1.5
Software Application

Embedded Device

Network Device
Host Device Validation by
Capability
Independent Source of
Requirement ID Reference Name Requirement Description Validation Activity Security Rationale and Supplemental Guidance
Test Required Requirement
Level
(Yes/No)

Examine user and design documents for

Embedded devices shall
evidence to verify that the component process
support the capability to
for provisioning asset owner roots of trust can
Provisioning asset owner provision without reliance on ISA-62443-4-2:
x FSA-EDR 3.13B be performed within the component's security No 2, 3, 4 See FSA-EDR 3.13A
roots of trust - inside zone components that may be EDR 3.13(b)
zone. Record one of:
outside of the device’s security
a. Met
zone.
b. Not met

Product suppliers have established mechanisms to ensure that the software and firmware on their components is
authentic, and the integrity of that software and firmware has not been compromised. This allows the product supplier to
provide the asset owner with a “known good” state from which to operate. However, many product suppliers also
provide mechanisms for asset owners to extend the functionality of their devices through the use of mobile code, user
programs, or other such means. In order to protect the security of the component, it is important that these extensions to
the component’s functionality also be validated to ensure that they are authorized, and that the asset owner has
approved of their origins.
Host devices shall provide the In order to perform these validations the component must contain data that provides a way to differentiate between valid
capability to provision and and invalid origins. The list of valid and invalid origins will differ from asset owner to asset owner, and it is unlikely that a
Provisioning asset owner protect the confidentiality, ISA-62443-4-2: product supplier will have a complete list of every possible valid origin at time of manufacture. Therefore it is important
x FSA-HDR 3.13A Future entry Future entry 2, 3, 4
roots of trust - protection integrity, and authenticity of HDR 3.13(a) that the product supplier provide a way for the asset owner to securely provision their own “roots of trust” which provide
asset owner keys and data to be the ability to distinguish between origins allowed by the asset owner’s security policy, and those that are not. The
used as “roots of trust”. authenticity and integrity of these “roots of trust” must be protected so that malicious actors cannot add additional roots
of trust that grant them the ability to operate on the component.
Requirements such as HDR 2.4 – Mobile code require the component to complete authenticity checks on mobile code
prior to the execution of mobile code. The roots of trust provided by this requirement provide the data necessary to
validate the origin and integrity of mobile code, allowing the component to independently determine if the code is
allowed to execute.
A root of trust can also be used as a basis communications security, such as communications integrity required by CR
3.1 – Communication integrity or communications confidentiality required by CR 4.1 – Information confidentiality.

Host devices shall support the

capability to provision without
Provisioning asset owner ISA-62443-4-2:
x FSA-HDR 3.13B reliance on components that Future entry Future entry 2, 3, 4 See FSA-HDR 3.13A
roots of trust - inside zone HDR 3.13(b)
may be outside of the device’s
security zone.

Product suppliers have established mechanisms to ensure that the software and firmware on their components is
authentic, and the integrity of that software and firmware has not been compromised. This allows the product supplier to
provide the asset owner with a “known good” state from which to operate. However, many product suppliers also
provide mechanisms for asset owners to extend the functionality of their devices through the use of mobile code, user
programs, or other such means. In order to protect the security of the component, it is important that these extensions to
the component’s functionality also be validated to ensure that they are authorized, and that the asset owner has
approved of their origins.
Network devices shall provide In order to perform these validations the component must contain data that provides a way to differentiate between valid
the capability to provision and and invalid origins. The list of valid and invalid origins will differ from asset owner to asset owner, and it is unlikely that a
Provisioning asset owner protect the confidentiality, ISA-62443-4-2: product supplier will have a complete list of every possible valid origin at time of manufacture. Therefore it is important
x FSA-NDR 3.13A Future entry Future entry 2, 3, 4
roots of trust - protection integrity, and authenticity of NDR 3.13(a) that the product supplier provide a way for the asset owner to securely provision their own “roots of trust” which provide
asset owner keys and data to be the ability to distinguish between origins allowed by the asset owner’s security policy, and those that are not. The
used as “roots of trust”. authenticity and integrity of these “roots of trust” must be protected so that malicious actors cannot add additional roots
of trust that grant them the ability to operate on the component.
Requirements such as NDR 2.4 – Mobile coderequire the component to complete authenticity checks on mobile code
prior to the execution of mobile code. The roots of trust provided by this requirement provide the data necessary to
validate the origin and integrity of mobile code, allowing the component to independently determine if the code is
allowed to execute.
A root of trust is used to provide communications security, such as communications integrity required by CR 3.1 –
Communication integrity or communications confidentiality required by CR 4.1 – Information confidentiality.

Network devices shall support

the capability to provision
Provisioning asset owner ISA-62443-4-2:
x FSA-NDR 3.13B without reliance on components Future entry Future entry 2, 3, 4 See FSA-NDR 3.13A
roots of trust - inside zone NDR 3.13(b)
that may be outside of the
device’s security zone.

Copyright © 2018 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 33 of 42
 CSA-311 FR 3
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 1.5
Software Application

Embedded Device

Network Device
Host Device Validation by
Capability
Independent Source of
Requirement ID Reference Name Requirement Description Validation Activity Security Rationale and Supplemental Guidance
Test Required Requirement
Level
(Yes/No)

Verify in design documentation, and by testing

that the component provides measures to verify
Embedded devices shall verify In order to make assurances to an asset owner that a component’s security functionality has not been compromised, it is
prior to the boot process that all firmware,
the integrity of the firmware, necessary to ensure that the component’s software and firmware has not been tampered with, and that the software and
software and configuration data needed for the
software, and configuration data ISA-62443-4-2: firmware is valid to execute on the component. Therefore the component must perform checks to validate the integrity
x FSA-EDR 3.14 Integrity of the boot process boot process have not been modified since a Yes 1, 2, 3, 4
needed for component’s boot EDR 3.14 of the component’s firmware and/or software prior to use during the boot process, to ensure that the component does
prior point in time when they were assumed
and runtime processes prior to not boot into an insecure or invalid operating state that could damage the component or provide a path for a malicious
trustworthy. Record one of:
use. actor to gain access to additional components, assets, or data.
a. Met
b. Not met

Verify in design and user documentation, and by

Embedded devices shall use the testing that the component uses supplier roots
component’s product supplier of trust to verify prior to the boot process that all
roots of trust to verify the firmware, software and configuration data
Authenticity of the boot authenticity of the firmware, needed for the boot process originate from the ISA-62443-4-2:
x FSA-EDR 3.14 RE(1) Yes 2, 3, 4
process software, and configuration data supplier. One possible method is validation of EDR 3.14 RE(1)
needed for the component’s digital signatures and cryptographic hashes.
boot process prior to it being Record one of:
used in the boot process. a. Met
b. Not met

Host devices shall verify the In order to make assurances to an asset owner that a component’s security functionality has not been compromised, it is
integrity of the firmware, necessary to ensure that the component’s software and firmware has not been tampered with, and that the software and
software, and configuration data ISA-62443-4-2: firmware is valid to execute on the component. Therefore the component must perform checks to validate the integrity
x FSA-HDR 3.14 Integrity of the boot process Future entry Future entry 1, 2, 3, 4
needed for component’s boot HDR 3.14 and authenticity of the component’s firmware and/or software prior to the boot process, to ensure that the component
process prior to it being used in does not boot into an insecure or invalid operating state that could damage the component or provide a path for a
the boot process. malicious actor to gain access to additional components, assets, or data.

Host devices shall use the

component’s product supplier
roots of trust to verify the
Authenticity of the boot authenticity of the firmware, ISA-62443-4-2:
x FSA-HDR 3.14 RE(1) Future entry Future entry 2, 3, 4
process software, and configuration data HDR 3.14 RE(1)
needed for component’s boot
process prior to it being used in
the boot process.

Network devices shall verify the In order to make assurances to an asset owner that a component’s security functionality has not been compromised, it is
integrity of the firmware, necessary to ensure that the component’s software and firmware has not been tampered with, and that the software and
software, and configuration data ISA-62443-4-2: firmware is valid to execute on the component. Therefore the component must perform checks to validate the integrity
x FSA-NDR 3.14 Integrity of the boot process Future entry Future entry 1, 2, 3, 4
needed for component’s boot NDR 3.14 and authenticity of the component’s firmware and/or software prior to the boot process, to ensure that the component
process prior to it being used in does not boot into an insecure or invalid operating state that could damage the component or provide a path for a
the boot process. malicious actor to gain access to additional components, assets, or data.

Network devices shall use the

component’s product supplier
roots of trust to verity the
Authenticity of the boot authenticity of the firmware, ISA-62443-4-2:
x FSA-NDR 3.14 RE(1) Future entry Future entry 2, 3, 4
process software, and configuration data NDR 3.14 RE(1)
needed for component’s boot
process prior to it being used in
the boot process.

Copyright © 2018 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 34 of 42
 CSA-311 FR 4
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 1.5
Software Application

Embedded Device

Network Device
Host Device Validation by
Capability
Independent Test Source of
Requirement ID Reference Name Requirement Description Validation Activity Security Rationale and Supplemental Guidance
Required Requirement
Level
(Yes/No)

The decision whether a given information should be protected or not

Identify all information at rest for which explicit read authorization is depends on the context and cannot be made at product design.
supported. Review design documentation and verify that all such However, the fact that an organization limits access to information by
information includes methods to protect the confidentiality such as configuring explicit read authorizations in the control system is an
encrypting the data or limiting user access to the location where the indicator that this information should be protected by the organization.
Components shall provide the capability
data is stored. If the user must configure or set up the component in Thus, all information for which the component supports the capability
Information confidentiality - at to protect the confidentiality of ISA-62443-4-2:
x x x x FSA-CR 4.1A a certain manner to meet this requirement, verify that this is clearly Yes 1, 2, 3, 4 to assign explicit read authorizations should be considered potentially
rest information at rest for which explicit read CR 4.1(a)
documented in a user manual. Attempt to access a sampling of sensitive and thus the component should also provide the capability to
authorization is supported.
confidential information to verify that it cannot be accessed by users protect its confidentiality.
without the proper authorization. Record one of: Confidentiality of information in transit requires system level
a. Met capabilities which the component should be able to support.
b. Not Met For confidentiality protection, 8.5 CR 4.3 – Use of cryptography
provides further requirements.

Identify all information in transit for which explicit read authorization is

supported. Review design documentation and verify that all such
information includes methods to protect the confidentiality such as
encrypting the data or limiting user access to the physical medium
data used for transmission. If the user must configure or set up the
Components shall support the protection component in a certain manner to meet this requirement, verify that
Information confidentiality - in of the confidentiality of information in this is clearly documented in a user manual. If a user can access a ISA-62443-4-2:
x x x x FSA-CR 4.1B Yes 1, 2, 3, 4 See FSA-CR 4.1A
transit transit as defined in ISA‑62443‑3‑3 [11] physical medium used for transmission, verify by test that no CR 4.1(b)
SR 4.1. confidential information can be seen over the wire by using an
eavesdropping tool such as Wireshark to view a sampling of
communications while the system is performing its normal
operations. Record one of:
a. Met
b. Not Met

Removal of a control system component from active service should

not provide the opportunity for unintentional release of information for
which explicit read authorization is supported. An example of such
information can include authentication information and network
Review component documentation and verify that the component
Components shall provide the capability configuration information stored in non-volatile storage or other
has the ability to purge all information for which explicit read
to erase all information, for which explicit cryptographic information that would facilitate unauthorized or
authorization is supported. Verify that the data is purged from the ISA-62443-4-2:
x x x x FSA-CR 4.2 Information persistence read authorization is supported, from No 2, 3, 4 malicious activity.
component such that it can not be recreated. Record one of: CR 4.2
components to be released from active Information produced by the actions of a user or role (or the actions of
a. Met
service and/or decommissioned. a software process acting on behalf of a user or role) should not be
b. Not Met
disclosed to a different user or role in an uncontrolled fashion. Control
of control system information or data persistence prevents information
stored on a shared resource from being unintentionally disclosed after
that resource has been released back to the control system.

Review component design documentation and verify that confidential

information is purged from RAM before that memory is released
Components shall provide the capability back to the component for use by a different user. Review
Erase of shared memory to protect against unauthorized and component design documentation and verify that confidential ISA-62443-4-2:
x x x x FSA-CR 4.2 RE(1) No 3, 4
resources unintended information transfer via information is not stored in memory that can be accessed by CR 4.2 RE(1)
volatile shared memory resources. unauthorized programs or users. Record one of:
a. Met
b. Not Met

Copyright © 2018 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 35 of 42
 CSA-311 FR 4
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 1.5
Software Application

Embedded Device

Network Device
Host Device Validation by
Capability
Independent Test Source of
Requirement ID Reference Name Requirement Description Validation Activity Security Rationale and Supplemental Guidance
Required Requirement
Level
(Yes/No)

Review the component documentation and verify that the component

has the cabability to verify that information has been purged from the
component as defined in the CR-4.2 base requirement. Carry out a
test to follow the recommended practice to purge information from
the component and perform the documented verification method to
Components shall provide the capability
verify that the information has been purged from the component. ISA-62443-4-2:
x x x x FSA-CR 4.2 RE(2) Erase verification to verify that the erasure of information Yes 3, 4
Carry out an addition test to perform the documented verification CR 4.2 RE(2)
occurred.
method on a system that has not had its information purged to
ensure that the method will detect a failure of the purge.
Record one of:
a. Met
b. Not Met

The selection of cryptographic protection should be based on a threat

and risk analysis which covers the value of the information being
protected, the consequences of the confidentiality and integrity of the
information being breached, the time period during which the
information is confidential and control system operating constraints.
This can involve either information at rest, in transit, or both. Note that
backups are an example of information at rest, and should be
considered as part of a data confidentiality and integrity assessment
process. The control system product supplier should document the
practices and procedures relating to cryptographic key establishment
Verify through design documentation that if the component uses and management. The control system should utilize established and
cryptography then algorithms, key sizes and mechanisms for key tested encryption and hash algorithms, such as the advanced
If cryptography is required, the
establishment are done according to commonly accepted industry encryption standard (AES) and the secure hash algorithm (SHA)
component shall use cryptographic
best practices and recommendations as defined in NIST SP 800-57 ISA-62443-4-2: series, and key sizes based on an assigned standard. Key generation
x x x x FSA-CR 4.3 Use of cryptography security mechanisms according to No 1, 2, 3, 4
or similar publication. CR 4.3 needs to be performed using an effective random number generator.
internationally recognized and proven
a. Met by the component The security policies and procedures for key management need to
security practices and recommendations.
b. Not Met address periodic key changes, key destruction, key distribution and
encryption key backup in accordance with defined standards.
Generally accepted practices and recommendations can be found in
documents such as NIST SP 800-57, Recommendation for Key
Management, Part 1: General [25]. Implementation requirements can
be found for example in FIPS 140-2, Security Requirements for
Cryptographic Modules [24] or ISO/IEC 19790, Information
technology – Security techniques – Security requirements for
cryptographic modules [17].
This CR, along with 5.10, CR 1.8 – Public key infrastructure
certificates may be applicable when meeting many other requirements
defined within this document.

Copyright © 2018 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 36 of 42
 CSA-311 FR 5
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 1.5
Software Application

Embedded Device

Network Device
Host Device Validation by
Capability
Independent Test Source of
Requirement ID Reference Name Requirement Description Validation Activity Security Rationale and Supplemental Guidance
Required Requirement
Level
(Yes/No)

Network segmentation is used by organizations for a variety of purposes, including

cyber security. The main reasons for segmenting networks are to reduce the
exposure, or ingress, of network traffic into a control system and reduce the spread, or
egress, of network traffic from a control system. This improves overall system
response and reliability as well as provides a measure of cyber security protection. It
also allows different network segments within the control system, including critical
control systems and safety-related systems, to be segmented from other systems for
an additional level of protection.
Access from the control system to the World Wide Web should be clearly justified
based on control system operational requirements.
Network segmentation and the level of protection it provides will vary greatly
depending on the overall network architecture used by an asset owner in their facility
Components shall support a segmented Verify that the device supports a networking technology that and even system integrators within their control systems. Logically segmenting
network to support zones and conduits, is capable of being segmented. Record one of: networks based on their functionality provides some measure of protection, but may
ISA-62443-4-2: CR
x x x x FSA-CR 5.1 Network segmentation as needed, to support the broader a. Met No 1, 2, 3, 4 still lead to single-points-of-failure if a network device is compromised. Physically
5.1
network architecture based on logical b. Not met segmenting networks provides another level of protection by removing that single-point-
segmentation and criticality. of-failure case, but will lead to a more complex and costly network design. These
trade-offs will need to be evaluated during the network design process (see ISA 62443
2-1).
In response to an incident, it may be necessary to break the connections between
different network segments. In that event, the services necessary to support essential
operations should be maintained in such a way that the devices can continue to
operate properly and/or shutdown in an orderly manner. This may require that some
servers may need to be duplicated on the control system network to support normal
network features, for example dynamic host configuration protocol (DHCP), domain
name service (DNS) or local CAs. It may also mean that some critical control systems
and safety-related systems be designed from the beginning to be completely isolated
from other networks.

Any connections to outside each security zone should occur through managed
A network device at a zone boundary
interfaces consisting of appropriate boundary protection devices (for example, proxies,
shall provide the capability to monitor and
gateways, routers, firewalls, unidirectional gateways, guards and encrypted tunnels)
control communications at zone ISA-62443-4-2:
x FSA-NDR 5.2 Zone boundary protection Future entry Future entry 1, 2, 3, 4 arranged in an effective architecture (for example, firewalls protecting application
boundaries to enforce the NDR 5.2
gateways residing in a DMZ). Control system boundary protections at any designated
compartmentalization defined in the risk-
alternate processing sites should provide the same levels of protection as that of the
based zones and conduits model.
primary site.

The network component shall provide the

capability to deny network traffic by
ISA-62443-4-2:
x FSA-NDR 5.2 RE(1) Deny all, permit by exception default and allow network traffic by Future entry Future entry 2, 3, 4
NDR 5.2 RE(1)
exception (also termed deny all, permit by
exception).

The network component shall provide the

capability to protect against any
ISA-62443-4-2:
x FSA-NDR 5.2 RE(2) Island mode communication through the control Future entry Future entry 3, 4
NDR 5.2 RE(2)
system boundary (also termed island
mode).

The network component shall provide the

capability to protect against any
communication through the control
ISA-62443-4-2:
x FSA-NDR 5.2 RE(3) Fail close system boundary when there is an Future entry Future entry 3, 4
NDR 5.2 RE(3)
operational failure of the boundary
protection mechanisms (also termed fail
close).

Copyright © 2018 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 37 of 42
 CSA-311 FR 5
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 1.5
Software Application

Embedded Device

Network Device
Host Device Validation by
Capability
Independent Test Source of
Requirement ID Reference Name Requirement Description Validation Activity Security Rationale and Supplemental Guidance
Required Requirement
Level
(Yes/No)

General purpose, person-to-person communications systems include but are not

limited to: email systems, forms of social media (Twitter, Facebook, picture galleries,
etc.) or any message systems that permit the transmission of any type of executable
file. These systems are usually utilized for private purposes that are not related to
A network device at a zone boundary control system operations, and therefore the risks imposed by these systems normally
shall provide the capability to protect outweigh any perceived benefit.
General purpose, person-to- against general purpose, person-to- ISA-62443-4-2: These types of general purpose communications systems are commonly used as
x FSA-NDR 5.3 Future entry Future entry 1, 2, 3, 4
person communication restrictions person messages from being received NDR 5.3 attack vectors to introduce malware to the control system, pass information for which
from users or systems external to the read authorization exists to locations external to the control system and introduce
control system. excessive network loading that can be used to create security problems or launch
attacks on the control system.
Network devices could realize such restrictions, for example, by blocking specific
communications based on port numbers and source and/or target address as well as
more in depth checks by application layer firewalls.

There is no component level requirement

ISA-62443-4-2: CR
FSA-CR 5.4 Application partitioning associated with ISA‑62443‑3‑3 SR 5.4. No validation activity
5.4

Copyright © 2018 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 38 of 42
 CSA-311 FR 6
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 1.5
Software Application

Embedded Device

Network Device
Host Device Validation by
Capability
Independent Source of
Requirement ID Reference Name Requirement Description Validation Activity Security Rationale and Supplemental Guidance
Test Required Requirement
Level
(Yes/No)

The applications and devices may generate audit records about events
occurring in that application or device (see 6.10). Access to these audit
logs is necessary to support filtering audit logs, identifying and removing
information that is redundant, reviewing and reporting activity during after-
Verify that the component provides a means for the-fact investigations of security incidents. In general, audit reduction
Components shall provide the
authorized humans and/or authorized external tools to and report generation should be performed on a separate information
capability for authorized humans ISA-62443-4-2:
x x x x FSA-CR 6.1 Audit log accessibility access audit logs on a read-only basis. Record one of: No 1, 2, 3, 4 system. Manual access to the audit records (such as, screen views or
and/or tools to access audit logs on a CR 6.1
a. Met printouts) is sufficient for meeting the base requirement, but is
read-only basis.
b. Not met insufficient for higher SLs. Programmatic access is commonly used to
provide the audit log information to analysis mechanisms such as
security information and event management (SIEM). See relevant SRs in
Clauses 5, 6 and 9 regarding the creation of, protection of and access to
audit logs.

Verify in user or design documentation that the

Components shall provide
component provides programmatic access to audit
programmatic access to audit records
records by either using an application programming
Programmatic access to by either using an application ISA-62443-4-2:
x x x x FSA-CR 6.1 RE(1) interface (API) or sending the audit records to a No 3, 4
audit logs programming interface (API) or CR 6.1 RE(1)
centralized system. Record one of:
sending the audit records to a
a. Met
centralized system
b. Not met

Control system monitoring capability can be achieved through a variety

Verify that the supplier chose an industry resource that
of tools and techniques (for example, IDS, intrusion prevention system
provides recommendations for events to be monitored to
(IPS), protection from malicious code mechanisms and network
identify security breaches for the component. Verify that
monitoring mechanisms). As attacks become more sophisticated, these
the component is capable of being monitored for those
monitoring tools and techniques will need to become more sophisticated
events. For example failed authorization and access
Components shall provide the as well, including for example behavior-based IDS/IPS.
control attempts, failed input validation, and high value
capability to be continuously Monitoring devices should be strategically deployed within the control
transactions are identified in the OWASP Top 10
monitored using commonly accepted system (for example, at selected perimeter locations and near server
resource. Verify that monitoring can be done in a ISA-62443-4-2:
x x x x FSA-CR 6.2 Continuous monitoring security industry practices and No 2, 3, 4 farms supporting critical applications) to collect essential information.
continuous manner, and that the component is capable of CR 6.2
recommendations to detect, Monitoring mechanisms may also be deployed at ad hoc locations within
reporting of events in a time frame to permit mitigation of
characterize and report security the control system to track specific transactions.
a possible associated security breach associated with the
breaches in a timely manner. Monitoring should include appropriate reporting mechanisms to allow for
event. Verify that events are reported with content and
a timely response to events. To keep the reporting focused and the
format usable by a centralized analysis solution. Record
amount of reported information to a level that can be processed by the
one of:
recipients, mechanisms such as SIEM are commonly applied to correlate
a. Met
individual events into aggregate reports that establish a larger context in
b. Not met
which the raw events occurred.

Copyright © 2018 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 39 of 42
 CSA-311 FR 7
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 1.5
Software Application

Embedded Device

Network Device
Host Device Validation by
Capability
Independent Source of
Requirement ID Reference Name Requirement Description Validation Activity Security Rationale and Supplemental Guidance
Test Required Requirement
Level
(Yes/No)

Verify that the threat model for the component identifies DoS
threats and their mitigations using a systematic analysis
Components shall provide the capability method. Verify that the supplier has test cases to show that the Components may be subjected to different forms of DoS situations.
to maintain essential functions when component maintains essential functions when subjected to ISA-62443-4-2: When these occur the component should be designed in such a
x x x x FSA-CR 7.1 Denial of service protection No 1, 2, 3, 4
operating in a degraded mode as the DoS attack. Verify that those tests have passed. Record one CR 7.1 manner that it maintains essential functions necessary for continued
result of a DoS event. of: safe operations while in a degraded mode.
a. Met
b. Not met

Verify that the threat model for the component identifies

information and/or message flooding types of DoS events.
Verify that the threat model indicates the capability to mitigate
the effects of these threats. Verify that the supplier has test
cases that have passed for these mitigations as required by
ISA-624432-4-1 requirement SVV-2. (This examination of test
cases can been done as part of validation activity in the
SDLPA element of certification, for requirement SDLA-SVV-2-
1.)
Components shall provide the capability
Manage communication load to mitigate the effects of information To address lower layer message flooding events, network Yes (as part of ISA-62443-4-2:
x x x x FSA-CR 7.1 RE(1) 2, 3, 4
from component and/or message flooding types of DoS traffic load testing is performed under the ERT (Embedded CRT) CR 7.1 RE(1)
events. Device Robustness Testing) element of certification, as part
of CRT (Communication Robustness Testing). High rate traffic
is directed at the component and the tester verifies upstream
services return to normal by end of test, and downstream
services are not adversely effected during the test. Verify that
the CRT load stress tests have passed in accordance with
EDSA-310 which describes details of this testing. Record one
of:
a. Met
b. Not met

Verify using design documentation that usage of security

functions provided by the component to meet the ISA-62443-4-
2 standard are limited in such a way that high usage of these
Resource management (for example, network segmentation or priority
functions does not interfere with other component functions.
schemes) prevents a lower-priority software process from delaying or
Components shall provide the capability Examples include but are not limited to: high rates of user
interfering with the control system servicing any higher-priority
to limit the use of resources by security authentication attempts (possibly failed attempts), high audit ISA-62443-4-2:
x x x x FSA-CR 7.2 Resource management No 1, 2, 3, 4 software process. For example, initiating network scans, patching
functions to protect against resource logging rates, high rates of incoming data requiring CR 7.2
and/or antivirus checks on an operating system can cause severe
exhaustion. authenticity checking or outgoing data requiring integrity
disruption to normal operations. Traffic rate limiting schemes should
protections, series of physical attacks triggering a series of
be considered as a mitigation technique.
automated notifications. Record one of:
a. Met
b. Not met

The availability of up-to-date backups is essential for recovery from a

control system failure and/or mis-configuration. Automating this
function ensures that all required files are captured, reducing operator
overhead.
When designing to support a backup capability, consideration should
Verify that the supplier has test cases to show that the be given to information that will be stored in backups. Some of this
Components shall provide the capability
component provides the capability to provide component user information may contain cryptographic keys and other information that
to participate in system level backup
and component state information as part of a system level is protected through security controls while part of the system. Once
operations in order to safeguard the
backup operation, with no effect on the normal component ISA-62443-4-2: the information is placed into a backup it most likely will not have the
x x x x FSA-CR 7.3 Control system backup component state (user- and system- No 1, 2, 3, 4
operations. Verify this capability in user documentation. CR 7.3 same controls in place to protect it. Thus the component backup
level information). The backup process
Record one of: ability needs to include the mechanisms to support the necessary
shall not affect the normal component
a. Met protection of the information that is contained in the backup. This may
operations.
b. Not met include encryption of the backup, encryption of the sensitive data as
part of the backup procedure or not including the sensitive information
as part of the backup. If the backup is encrypted it is important not to
include the cryptographic keys as part of the backup but to backup the
cryptographic keys as part of a separate more secure backup
procedure.

Copyright © 2018 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 40 of 42
 CSA-311 FR 7
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 1.5
Software Application

Embedded Device

Network Device
Host Device Validation by
Capability
Independent Source of
Requirement ID Reference Name Requirement Description Validation Activity Security Rationale and Supplemental Guidance
Test Required Requirement
Level
(Yes/No)

Verify in user documentation that the component provides the

capability to validate the integrity of backed up information
prior to the initiation of a restore of that information. Verify via
Components shall provide the capability
testing by both deleting and modifying the data in the backed
to validate the integrity of backed up ISA-62443-4-2:
x x x x FSA-CR 7.3 RE(1) Backup integrity verification up information associated with some event. Attempt to restore Yes 2, 3, 4
information prior to the initiation of a CR 7.3 RE(1)
and verify that a problem is reported to the user before the
restore of that information.
restore to the component is initiated. Record one of:
a. Met
b. Not met

Component recovery and reconstitution to a known secure state

Verify in user documentation that a process is described for
means that all system parameters (either default or configurable) are
restoring a failed or suspected defective component to a
Components shall provide the capability set to secure values, security-critical patches are reinstalled, security-
known secure state. Verify that the expected state is described
Control system recovery and to be recovered and reconstituted to a ISA-62443-4-2: related configuration settings are reestablished, system
x x x x FSA-CR 7.4 in the user documentation. Perform the process and verify that Yes 1, 2, 3, 4
reconstitution known secure state after a disruption or CR 7.4 documentation and operating procedures are available, components
it achieves the documented state. Record one of:
failure. are reinstalled and configured with established settings, information
a. Met
from the most recent, known secure backups is loaded and the
b. Not met
system is fully tested and functional.

There is no component level

ISA-62443-4-2:
FSA-CR 7.5 Emergency power requirement associated with No validation activity
CR 7.5
ISA‑62443‑3‑3 SR 7.5.

The SDLPA certification element under requirements SDLA-

SG-3A and SDLA-SG-3D in document SDLA-312, requires
guidelines for security hardening and security configuration,
respectively.

If the evaluation for SDLA-SG-3A has passed, verify by test

that the user may view currently deployed network
configuration settings through a component interface. Verify
that the component may be configured through a component
Components shall provide the capability
interface to modify these settings, and in particular to meet
to be configured according to These configuration settings are the adjustable parameters of the
any network configuration guidance found in the guidelines
recommended network and security control system components. By default the component should be
that have met SDLA-SG-3A.
configurations as described in configured to the recommended settings. In order for a component to
Network and security ISA-62443-4-2:
x x x x FSA-CR 7.6 guidelines provided by the control Yes 1, 2, 3, 4 detect and correct any deviations from the approved and/or
configuration settings If the evaluation for SDLA-SG-3D has passed, verify by test CR 7.6
system supplier. The component shall recommended configuration settings, the component needs to support
that the user may view the settings described in the guidelines
provide an interface to the currently monitoring and control of changes to the configuration settings in
that have met that requirement, though a component interface.
deployed network and security accordance with security policies and procedures.
Modify any settings that do not conform to the recommended
configuration settings.
settings. View and verify any changes in the resulting
configuration through the interface provided. Record one of:
a. Met
b. Not met

If evaluations for either of the requirements SDLA-SG-3A and

SDLA-SG-3D in the SDLPA element of certification have not
passed, Record:
b. Not met

Verify that a report can be generated listing the currently

Components shall provide the capability
deployed security settings in a machine-readable format, by
Machine-readable reporting of to generate a report listing the currently ISA-62443-4-2:
x x x x FSA-CR 7.6 RE(1) generating and reading this report. Record one of: Yes 3, 4
current security settings deployed security settings in a machine- CR 7.6 RE(1)
a. Met
readable format.
b. Not met

Copyright © 2018 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 41 of 42
 CSA-311 FR 7
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 1.5
Software Application

Embedded Device

Network Device
Host Device Validation by
Capability
Independent Source of
Requirement ID Reference Name Requirement Description Validation Activity Security Rationale and Supplemental Guidance
Test Required Requirement
Level
(Yes/No)

Components are capable of providing a wide variety of functions and

Verify the user documentation specifies required ports and services. Some of the functions and services provided may not be
Components shall provide the capability protocols, and provides guidance for how to prohibit and/or necessary to support IACS functionality. Therefore, by default,
to specifically restrict the use of restrict the use of unnecessary functions, ports, protocols ISA-62443-4-2: functions beyond a baseline configuration should be disabled.
x x x x FSA-CR 7.7 Least functionality No 1, 2, 3, 4
unnecessary functions, ports, protocols and/or other services. Record one of: CR 7.7 Additionally, it is sometimes convenient to provide multiple services
and/or services. a. Met from a single component of a control system, but doing so increases
b. Not met the risk compared to limiting the services provided by any one
component.

Verify that the component provides the capability to identify its

Components shall provide the capability Components may bring their own set of components into the overall
presence and its associated properties for a control sytem
Control system component to support a control system component ISA-62443-4-2: control system. When this is the case then those components need to
x x x x FSA-CR 7.8 component inventory. Record one of: No 2, 3, 4
inventory inventory according to ISA‑62443‑3‑3 CR 7.8 provide a mechanism to augment the overall component inventory
a. Met
[11] SR 7.8. which is compatible with ISA‑62443‑2‑4 [8] SP.06.02.
b. Not met

Copyright © 2018 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 42 of 42