This Annex provides a mapping of ISA/IEC 62443 to OPC UA. The first 5 columns (yellow color) in each table are from the IEC 62443 specification and are included here for clarity. Some topics in ISA/IEC 62443 do not apply to OPC UA and are marked as “N”. ISA/IEC 62443 topics that do apply are marked as “Y”. ISA/IEC 62443 topics that are partially covered are marked as “P”, For each topic that does apply the table lists the relevant OPC UA Parts and the Profiles/ ConformanceUnits that covers the listed functionality. For each OPC UA Part that is listed (other than OPC 10000-7) the text in the “Keyword text or comment” column is the text that should be searched for. The section that are found related to the keyword will describe the OPC UA related functionality. For the row labelled OPC 10000-7, the keyword column contains the actual Profile or ConformanceUnits that apply. For more detail on the ConformanceUnit or Profile, please use the on-line Profile Application available at https://profiles.opcfoundation.org.
Columns 2 through 4 in each of the tables could include a checkmark. The check marks when present indicate that the specific 62443 requirement applies to the listed security level (SL). This information is provided by the IEC 62443 specification and is reproduced here as a convenience.
The tables are broken into seven separate tables, one for each of the foundational requirements;
- Identification and authentication control (Table A.)
- Use control (Table A.)
- System integrity (Table A.)
- Data confidentiality (Table A.)
- Restricted data flow (Table A.)
- Timely response to events (Table A.)
- Resource availability (Table A.)
Table A.1 – ISA/IEC 62443 Mapping FR 1 Identification and authentication control
|
ISA-62443-4-2 CRs and Res |
Related to |
Applies to OPC UA |
OPC UA Part # |
Keyword text or comment |
SL1 |
SL2 |
SL3 |
SL4 |
|
CR 1.1: Human user identification and authentication |
√ |
√ |
√ |
√ |
Y |
IssuedIdentityToken |
JSON Web Token (JWT), JWT UserTokenPolicy |
Security User JWT IssuedToken, Security User JWT Token Policy, OPC UA Authority Profile |
|
CR 1.1 RE (1): Unique identification and Authentication |
|
√ |
√ |
√ |
Y |
IssuedIdentityToken |
JSON Web Token (JWT), JWT UserTokenPolicy |
Security User JWT IssuedToken, Security User JWT Token Policy, OPC UA Authority Profile User Token JWT Server Facet, User Token JWT Client Facet |
|
CR1.1 RE(2) Multifactor authentication for all interfaces` |
|
|
√ |
√ |
P |
|
OPC UA does not define any alternate schemes for two factor authentication, but if Issued tokens are used for user Authentication, the issued token provider can implement multifactor authentication. OPC UA authenticates the application as well as the user. |
IssuedIdentityToken |
JSON Web Token (JWT), JWT UserTokenPolicy |
Security User JWT IssuedToken, Security User JWT Token Policy, OPC UA Authority Profile User Token JWT Server Facet, User Token JWT Client Facet |
|
CR 1.2: Software process and device identification and authentication |
|
√ |
√ |
√ |
Y |
ApplicationAuthentication, X.509 v3 Security Certificates |
ApplicationInstance Security Certificate |
EndpointDescription, EndpointUrl, Hostname (Device) |
Security Default ApplicationInstance Security Certificate, Global Security Certificate Management Server Facet |
|
CR 1.2 RE (1) Unique identification and authentication |
|
|
√ |
√ |
Y |
ApplicationAuthentication, X.509 v3 Security Certificates |
ApplicationInstance Security Certificate |
EndpointDescription, EndpointUrl, Hostname (Device) |
Security Default ApplicationInstance Security Certificate, Global Security Certificate Management Server Facet |
|
CR 1.3: Account management |
√ |
√ |
√ |
√ |
P |
|
OPC UA does not directly provide account management, but if an AuthorizationService is used for user Authentication, it could support account management |
IssuedIdentityToken |
JSON Web Token (JWT), JWT UserTokenPolicy |
Security User JWT IssuedToken, Security User JWT Token Policy, OPC UA Authority Profile User Token JWT Server Facet, User Token JWT Client Facet |
|
CR 1.4: Identifier management |
√ |
√ |
√ |
√ |
Y |
UserIdentityToken, UserTokenPolicy |
Security User JWT IssuedToken, Security User JWT Token Policy, OPC UA Authority Profile |
User Token JWT Server Facet, User Token JWT Client Facet |
|
CR 1.5: Authenticator management |
√ |
√ |
√ |
√ |
Y |
UserIdentityToken, UserTokenPolicy |
Security User JWT IssuedToken, Security User JWT Token Policy, OPC UA Authority Profile |
User Token JWT Server Facet, User Token JWT Client Facet |
|
CR 1. 5 RE (1) Hardware security for authenticators |
|
|
√ |
√ |
N |
|
Secure elements are recommended in 9.1 and also discussed in OPC 10000-12 and OPC 10000-21, but not defined in OPC. |
|
NDR 1.6 – Wireless access management |
√ |
√ |
√ |
√ |
N |
|
OPC UA does specify physical characteristics of a network including wireless. |
|
NDR 1.6 RE (1) Unique identification and authentication |
|
√ |
√ |
√ |
N |
|
Same as above |
|
CR 1.7: Strength of password based authentication |
√ |
√ |
√ |
√ |
N |
|
OPC UA provides the mechanism for exchanging passwords information, but it does not define the implementation of the password – this is vendor specific. If an AuthorizationService is used, it can provide password strength enforcement |
|
CR 1.7 RE (1) Password generation and lifetime restrictions for human users |
|
|
√ |
√ |
N |
|
Same as CR 1.7 above |
|
CR 1.7 RE (2) Password lifetime restrictions for all users (human, software process, or device) |
|
|
|
√ |
N |
|
Same as CR 1.7 above |
|
CR 1.8: Security certificates |
|
√ |
√ |
√ |
Y |
Security Certificates, TrustLists (CertificateStore), OPC UA Security Services |
Obtaining, validating, and installing Security Certificate services |
Security Certificates |
Security Administration, Global Security Certificate Management |
Security Certificate Management Overview |
|
CR 1.9: Strength of public key-based authentication |
|
√ |
√ |
√ |
Y |
Cryptographic Keys |
Trusted Security Certificates |
Security Profiles: Basic256_Limits, SecurityPolicy [B] – Basic256Sha256 |
|
CR 1.9 RE (1) Hardware security for public key-based authentication |
|
|
√ |
√ |
N |
|
Secure elements are recommended in 9.1 and also discussed in OPC 10000-12 and OPC 10000-21, but not defined in OPC. |
|
CR 1.10: Authenticator feedback |
√ |
√ |
√ |
√ |
Y |
ApplicationAuthentication, X.509 v3 Security Certificates |
ApplicationInstance Security Certificate |
EndpointDescription, EndpointUrl, Hostname (Device) |
Security Default ApplicationInstance Security Certificate, Global Security Certificate Management Server Facet |
|
CR 1.11: Unsuccessful login attempts |
√ |
√ |
√ |
√ |
N |
|
OPC does not provide temporary lock out for user access failure, but an AuthenticationService could. OPC does monitor SecureChannel connection and could block secure channel connection for repeated failure. |
|
CR 1.12: System use notification |
√ |
√ |
√ |
√ |
N |
|
OPC does not define the how a client prompts for username/password. |
|
NDR 1.13 – Access via untrusted networks |
√ |
√ |
√ |
√ |
N |
|
OPC does not define network hardware requirements. It can restrict communication to be between uniquely identified applications. (see CR 1.2) |
|
NDR 1.13 RE (1) Explicit access request approval |
|
|
√ |
√ |
N |
|
Same as NDR 1.13 above |
|
CR 1.14: Strength of symmetric key-based authentication |
|
√ |
√ |
√ |
Y |
Symmetric Encryption |
SymmetricEncryptionAlgorithm |
Global Service Key Credential Pull/Push Facets, KeyCredential Service Server Facet, KeyCredential Service Client Facet |
Part 14 |
SecuritKeyService (SKS), SymmetricEncryptionAlgorithm |
|
CR 1.14 RE (1) Hardware security for symmetric key-based authentication |
|
|
√ |
√ |
N |
|
The OPC UA specification does not provide hardware requirements and does not utilize long lived symmetric keys |
Table A.2 – ISA/IEC 62443 mapping FR 2 Use control
|
ISA-62443-4-2 CRs and Res |
Related to |
Applies to OPC UA |
OPC UA Part # |
Keyword text or comment |
SL1 |
SL2 |
SL3 |
SL4 |
|
CR 2.1: Authorization enforcement |
√ |
√ |
√ |
√ |
Y |
UserAuthorization |
Authorization Services, IssuedIdentityToken |
AuthorizationService, JSON Web Token (JWT) |
User Token – JWT Server Facet, User Token – JWT Client Facet |
|
RE (1): Authorization enforcement for all users (humans, software processes, and devices) |
|
√ |
√ |
√ |
Y |
UserAuthorization |
Authorization Services, IssuedIdentityToken |
AuthorizationService, JSON Web Token (JWT) |
User Token – JWT Server Facet, User Token – JWT Client Facet |
|
RE (2): Permission mapping to roles |
|
√ |
√ |
√ |
Y |
Roles, JWT, and User Roles |
User Authorization, Role Type |
RolePermissions |
User Role Management Server/Client Facets |
|
CR 2.1 RE (3) Supervisor override |
|
|
√ |
√ |
P |
|
OPC provides the ability to switch user context, but it does not provide an automatic timeout for a switch |
Authorization Services |
|
CR 2.1 RE (4) Dual approval |
|
|
|
√ |
N |
|
OPC does not define the logic for applications and thus does not define dual approval |
|
CR 2.2: Wireless use control |
√ |
√ |
√ |
√ |
N |
|
OPC is hardware agnostic. |
|
CR 2.3 – Use control for portable and mobile devices |
NA |
NA |
NA |
NA |
N |
|
No component level requirements defined in 62443 |
|
SAR 2.4: Mobile code |
√ |
√ |
√ |
√ |
N |
|
OPC does not define Mobile code technologies |
|
SAR 2.4 RE (1): Mobile code authenticity check |
|
√ |
√ |
√ |
N |
|
OPC does not define Mobile code technologies |
|
EDR 2.4: Mobile code |
√ |
√ |
√ |
√ |
N |
|
OPC does not define Mobile code technologies |
|
EDR 2RE (1): Mobile code authenticity check |
|
√ |
√ |
√ |
N |
|
OPC does not define Mobile code technologies |
|
HDR 2.4: Mobile code |
√ |
√ |
√ |
√ |
N |
|
OPC does not define Mobile code technologies |
|
HDR 2.4RE (1): Mobile code authenticity check |
|
√ |
√ |
√ |
N |
|
OPC does not define Mobile code technologies |
|
NDR 2.4 – Mobile code |
√ |
√ |
√ |
√ |
N |
|
OPC does not define Mobile code technologies |
|
NDR 2.4 – Mobile code |
|
√ |
√ |
√ |
N |
|
OPC does not define Mobile code technologies |
|
CR 2.5: Session lock |
√ |
√ |
√ |
√ |
N |
|
OPC UA does not define human user interface |
|
CR 2.6: Remote session termination |
|
√ |
√ |
√ |
P |
|
OPC allows identification of remote session via ApplicationAuthentication, remote restrictions are application specific, but the infrastructure is provided. |
IssuedIdentityToken |
JSON Web Token (JWT), JWT UserTokenPolicy |
Security User JWT IssuedToken, Security User JWT Token Policy, OPC UA Authority Profile |
|
CR 2.7 – Concurrent session control |
|
|
√ |
√ |
N |
|
OPC provides limits on sessions, subscription and other functionality and defines behaviour if these limits are exceeded, but it does not provide limits per user. |
|
CR 2.8: Auditable events |
√ |
√ |
√ |
√ |
Y |
Auditability, Auditing, Audit Event Management |
Auditing |
AuditSecurityEventType |
Auditing Server Facet, Auditing Client Facet, Best Practice – Audit Events |
|
CR 2.9: Audit storage capacity |
√ |
√ |
√ |
√ |
N |
|
OPC does not define Audit storage. |
|
CR 2.9 RE (1) Warn when audit record storage capacity threshold reached. |
|
|
√ |
√ |
N |
|
OPC does not define Audit storage. |
|
CR 2.10: Response to audit processing failures |
√ |
√ |
√ |
√ |
N |
|
OPC does not provide Audit storage |
|
CR 2.11: Timestamps |
√ |
√ |
√ |
√ |
Y |
Message replay, Timestamps, SecureChannelId |
TimestampsToReturn |
AuditEventType |
Auditing Server Facet |
|
CR 2.11 RE (1): Time synchronization |
|
√ |
√ |
√ |
Y |
Cryptographic Keys (time validity of security profile) |
SourceTimestamp, VersionTime, Redundant Server Set Requirements |
Time Synchronization |
Security Time Synchronization |
|
CR 2.11 RE (2) Protection of time source integrity |
|
|
|
√ |
N |
|
OPC does not define a unique time synchronization scheme, but utilize other industry standard. |
|
CR 2.12: Non-repudiation |
√ |
√ |
√ |
√ |
Y |
Message alteration, Server Profiling, System Hijacking, Repudiation, Audit Event Management |
Signing, GetEndpoints, SecureChannel, Auditing, Proof of Possession, |
User Token – JWT Server/Client Facets, Auditing Server Facet, Auditing Client Facet, Best Practice – Audit Events |
|
CR 2.12 RE (1) Non-repudiation for all users |
|
|
|
√ |
Y |
Message alteration, Server Profiling, System Hijacking, Repudiation, Audit Event Management |
Signing, GetEndpoints, SecureChannel, Auditing, Proof of Possession, |
User Token – JWT Server/Client Facets, Auditing Server Facet, Auditing Client Facet, Best Practice – Audit Events |
|
EDR 2.13: Use of physical diagnostic and test interfaces |
|
√ |
√ |
√ |
N |
|
OPC is hardware agnostic. |
|
EDR 2.13 RE (1) Active monitoring |
|
|
√ |
√ |
N |
|
OPC is hardware agnostic |
|
HDR 2.13: Use of physical diagnostic and test interfaces |
|
√ |
√ |
√ |
N |
|
OPC is hardware agnostic |
|
HDR 2.13 RE (1) Active monitoring |
|
|
√ |
√ |
N |
|
OPC is hardware agnostic |
|
NDR 2.13: Use of physical diagnostic and test interfaces |
|
√ |
√ |
√ |
N |
|
OPC is hardware agnostic |
|
NDR 2.13 RE (1) Active monitoring |
|
|
√ |
√ |
N |
|
OPC is hardware agnostic |
Table A.3 – ISA/IEC 62443 Mapping FR 3 System integrity
|
ISA-62443-4-2 CRs and Res |
Related to |
Applies to OPC UA |
OPC UA Part # |
Keyword text or comment |
SL1 |
SL2 |
SL3 |
SL4 |
|
CR 3.1: Communication integrity |
√ |
√ |
√ |
√ |
Y |
SecureChannel – OpenSecureChannel |
SecureChannel Service Set |
SecureChannel, SecurityProtocol |
Security Policy Required, Security Policy [A] & [B] |
|
CR 3.1 RE (1): Communication authentication |
|
√ |
√ |
√ |
Y |
SecureChannel – OpenSecureChannel |
SecureChannel Service Set |
Security Policy Required, Security |
|
SAR 3.2: Protection from malicious code |
√ |
√ |
√ |
√ |
N |
|
OPC does not define requirement related to malicious code protection (for example. virus checkers) |
|
EDR 3.2: Protection from malicious code |
√ |
√ |
√ |
√ |
N |
|
OPC does not define requirement related to installation or execution of software |
|
HDR 3.2: Protection from malicious code |
√ |
√ |
√ |
√ |
N |
|
OPC does not define requirement related to malicious code protection (for example. virus checkers) |
|
HDR 3.2 RE (1): Report version of code protection |
|
√ |
√ |
√ |
N |
|
OPC does not define requirement related to malicious code protection (for example. virus checkers) |
|
NDR 3.2 – Protection from malicious code |
√ |
√ |
√ |
√ |
N |
|
OPC does not define requirement related to malicious code protection (for example. virus checkers) |
|
CR 3.3: Security functionality verification |
√ |
√ |
√ |
√ |
Y |
Identity Provider, SecurityKeyService, SecureChannel, TLS |
OpenSecureChannel, CreateSession, Write |
OPC UA Secure Conversation (UASC), Verifying Message Security, Token Policy, Bad_SecureChannel |
User Token – JWT Server/Client facets, Security Policy [A] & [B] |
|
CR 3.3 RE (1) Security functionality verification during normal operation |
|
|
|
√ |
N |
|
OPC does not define security function verification |
|
CR 3.4: Software and information integrity |
√ |
√ |
√ |
√ |
P |
ApplicationInstance Security Certificate |
SoftwareCertificates |
ApplicationInstance Security Certificate, X.509 v3 |
Security ApplicationInstance Security Certificate, Global Security Certificate Management Server/Client Profiles |
|
CR 3.4 RE (1): Authenticity of software and information |
|
√ |
√ |
√ |
P |
ApplicationInstance Security Certificate |
SoftwareCertificates |
ApplicationInstance Security Certificate, X.509 v3 |
Security ApplicationInstance Security Certificate, Global Security Certificate Management Server/Client Profiles |
|
CR 3.4 RE (2) Automated notification of integrity violations |
|
|
√ |
√ |
P |
ApplicationInstance Security Certificate |
SoftwareCertificates |
ApplicationInstance Security Certificate, X.509 v3 |
Security ApplicationInstance Security Certificate, Global Security Certificate Management Server/Client Profiles |
|
CR 3.5: Input validation |
√ |
√ |
√ |
√ |
N |
|
OPC does not define HMI requirements, but does ensure that input data (method parameter or for write) is of the correct datatype |
|
CR 3.6: Deterministic output |
√ |
√ |
√ |
√ |
N |
|
OPC does not define application behaviour, but does define information models that include substituted values and other behaviours for failed states. |
|
CR 3.7: Error handling |
√ |
√ |
√ |
√ |
Y |
Request/Response Service |
SessionDiagnosticsObjectType |
MessageChunks, Error Handling, Error Message, CloseSecureChannel |
Security Policy Required, Security Policy [A] & [B] |
|
CR 3.8: Session integrity |
|
√ |
√ |
√ |
Y |
SecureChannel, Session ID |
Session Service Set, Creating a Session, Auditing Session Service, SessionAuthenticationToken |
Session Services Facets, Standard UA Client 2017 Profile, Base Server Behavior Facet |
|
CR 3.9: Protection of audit information |
|
√ |
√ |
√ |
P |
|
OPC provides security related to Audit event generation, but does not define Audit Logging requirements or tools for analysing audit records |
SecureChannel, Session ID |
Session Service Set, Creating a Session, Auditing Session Service, SessionAuthenticationToken |
Session Services Facets, Standard UA Client 2017 Profile, Base Server Behavior Facet |
|
CR 3.9 RE (1) Audit records on write-once media |
|
|
|
√ |
N |
|
OPC does not define hardware requirements |
|
EDR 3.10: Support for updates |
√ |
√ |
√ |
√ |
N |
|
Some companion specification can define additional functionality that would apply, such as OPC 10000-100 |
|
EDR 3.10: RE (1): Update authenticity and integrity |
|
√ |
√ |
√ |
N |
|
|
|
HDR 3.10: Support for updates |
√ |
√ |
√ |
√ |
N |
|
|
|
HDR 3.10 RE (1): Update authenticity and integrity |
|
√ |
√ |
√ |
N |
|
|
|
NDR 3.10 – Support for updates |
√ |
√ |
√ |
√ |
N |
|
|
|
NDR 3.10 RE (1) Update authenticity and integrity |
|
√ |
√ |
√ |
N |
|
|
|
EDR 3.11: Physical tamper resistance and detection |
|
√ |
√ |
√ |
N |
|
|
|
EDR 3.11 RE (1) Notification of a tampering attempt |
|
|
√ |
√ |
N |
|
|
|
HDR 3.11: Physical tamper resistance and detection |
|
√ |
√ |
√ |
N |
|
|
|
HDR 3.11 RE (1) Notification of a tampering attempt |
|
|
√ |
√ |
N |
|
|
|
NDR 3.11 – Physical tamper resistance and detection |
|
√ |
√ |
√ |
N |
|
|
|
NDR 3.11 RE (1) Notification of a tampering attempt |
|
|
√ |
√ |
N |
|
|
|
EDR 3.12: Provisioning product supplier roots of trust |
|
√ |
√ |
√ |
N |
|
|
|
HDR 3.12: Provisioning product supplier roots of trust |
|
√ |
√ |
√ |
N |
|
|
|
NDR 3.12 – Provisioning product supplier roots of trust |
|
√ |
√ |
√ |
N |
|
|
|
EDR 3.13: Provisioning asset owner roots of trust |
|
√ |
√ |
√ |
N |
|
|
|
HDR 3.13: Provisioning asset owner roots of trust |
|
√ |
√ |
√ |
N |
|
|
|
NDR 3.13 – Provisioning asset owner roots of trust |
|
√ |
√ |
√ |
N |
|
|
|
EDR 3.14: Integrity of the boot process |
√ |
√ |
√ |
√ |
N |
|
|
|
EDR 3.14 RE (1): Authenticity of the boot process |
|
√ |
√ |
√ |
N |
|
|
|
HDR 3.14: Integrity of the boot process |
√ |
√ |
√ |
√ |
N |
|
|
|
HDR 3.4 RE (1): Authenticity of the boot process |
|
√ |
√ |
√ |
N |
|
|
|
NDR 3.14 – Integrity of the boot process |
√ |
√ |
√ |
√ |
N |
|
|
|
NDR 3.14 RE (1) Authenticity of the boot process |
|
√ |
√ |
√ |
N |
|
|
Table A.4 – ISA/IEC 62443 Mapping FR 4 Data confidentiality
|
ISA-62443-4-2 CRs and Res |
Related to |
Applies to OPC UA |
OPC UA Part # |
Keyword text or comment |
SL1 |
SL2 |
SL3 |
SL4 |
|
CR 4.1: Information confidentiality |
√ |
√ |
√ |
√ |
Y |
Confidentiality, Confidentiality, Eavesdropping, Client/Server, PubSub, Confidentiality |
SecureChannel Service Set |
OPC UA HTTPS, WebSockets (Security) |
Security Policy Required, Security Policy [A] & [B] |
|
CR 4.2: Information persistence |
|
√ |
√ |
√ |
N |
|
OPC does not describe hardware |
|
CR 4.2 RE (1) Erase of shared memory resources |
|
|
√ |
√ |
N |
|
OPC does not describe hardware |
|
CR 4.2 RE (2) Erase verification |
|
|
√ |
√ |
N |
|
OPC does not describe hardware |
|
CR 4.3: Use of cryptography |
√ |
√ |
√ |
√ |
Y |
Asymmetric Cryptography, Cryptography, Symmetric Cryptography, SecurityPolicies, Random Number Generation, Security Certificate Management |
GetEndpoints, OpenSecureChannel |
Security Handshake, Security Certificates, AccessTokens, Security Header, Deriving Keys (Table 49) |
AccessToken Request Client Facet, Security User Access Control Base Profile, Best Practice – Random Numbers, Global Discovery and Security Certificate Management 2017 Server, Global Security Certificate Management Client 2017 Profile |
Certificate Management Overview, KeyCredential Management |
Table A.5 – ISA/IEC 62443 Mapping FR 5 Restricted data flow
|
ISA-62443-4-2 CRs and Res |
Related to |
Applies to OPC UA |
OPC UA Part # |
Keyword text or comment |
SL1 |
SL2 |
SL3 |
SL4 |
|
CR 5.1: Network segmentation |
√ |
√ |
√ |
√ |
Y |
Network Segmentation, OpenSecureChannel |
Standard UA Client 2017 Profile, Base Server Behavior Facet |
|
NDR 5.2 – Zone boundary protection |
√ |
√ |
√ |
√ |
N |
|
OPC does not define network hardware. |
|
NDR 5.2 RE (1) Deny all, permit by exception |
|
√ |
√ |
√ |
N |
|
OPC does not define network hardware. |
|
NDR 5.2 RE (2) Island mode |
|
|
√ |
√ |
N |
|
OPC does not define network hardware. |
|
NDR 5.2 RE (3) Fail close |
|
|
√ |
√ |
N |
|
OPC does not define network hardware. |
|
NDR 5.3 – General purpose, person-to-person communication restrictions |
√ |
√ |
√ |
√ |
N |
|
OPC does not define network hardware. |
|
CR 5.4 – Application partitioning |
NA |
NA |
NA |
NA |
NA |
|
Nothing defined in IEC62443 |
Table A.6 – ISA/IEC 62443 Mapping FR 6 Timely response to events
|
ISA-62443-4-2 CRs and Res |
Related to |
Applies to OPC UA |
OPC UA Part # |
Keyword text or comment |
SL1 |
SL2 |
SL3 |
SL4 |
|
CR 6.1: Audit log accessibility |
√ |
√ |
√ |
√ |
N |
|
OPC does not define an Audit log. OPC defines standard Audit records and also defined historical storage of events. It provides access restriction for all data. |
|
CR 6.1 RE (1) Programmatic access to audit logs |
|
|
√ |
√ |
N |
|
OPC Does not define an Audit log. OPC defines standard Audit records and also defined historical storage of events. It provides access restriction for all data, standard methods for programmatical access are defined. |
|
CR 6.2: Continuous monitoring |
|
√ |
√ |
√ |
Y |
Monitor Items, GetMonitoredItems Method, SetMonitoringMode. Subscription Server Facet, Standard UA Client 2017 Profile, Standard DataChange Subscription 2017 Server Facet |
|
Table A.7 – ISA/IEC 62443 Mapping FR 7 Resource availability
|
ISA-62443-4-2 CRs and REs |
Related to |
Applies to OPC UA |
OPC UA Part # |
Keyword text or comment |
SL1 |
SL2 |
SL3 |
SL4 |
|
CR 7.1: Denial of service protection |
√ |
√ |
√ |
√ |
Y |
Application Crashes, Fuzz Testing, Certification |
CreateSession, OpenSecureChannel, AuthenticationToken |
Session Services Facets, Standard UA Client 2017 Profile, Base Server Behavior Facet |
|
CR 7.1 RE (1): Manage communication load from component |
|
√ |
√ |
√ |
Y |
Message flooding, GetEndpoints, OpenSecureChannel |
CreateSession, OpenSecureChannel, AuthenticationToken |
Session Services Facets, Standard UA Client 2017 Profile, Base Server Behavior Facet |
|
CR 7.2: Resource management |
√ |
√ |
√ |
√ |
Y |
Resource exhaustion, ClientAuthentication, ServerAuditing, OpenSecureChannel |
CreateSession, OpenSecureChannel, AuthenticationToken |
Session Services Facets, Standard UA Client 2017 Profile, Base Server Behavior Facet |
|
CR 7.3: Control system backup |
√ |
√ |
√ |
√ |
N |
|
OPC does not define system level backup requirements. |
|
CR 7.3 RE (1): Backup integrity verification |
|
√ |
√ |
√ |
N |
|
OPC does not define verification of backup requirements. |
|
CR 7.4: Control system recovery and reconstitution |
|
|
|
|
N |
|
OPC UA does not define backup and restore requirements (to a specific state). |
|
CR 7.5 - Emergency Power |
NA |
NA |
NA |
NA |
NA |
|
(no requirements for this) |
|
CR 7.6: Network and security configuration settings |
√ |
√ |
√ |
√ |
P |
|
OPC UA requires that application can be configured for network and security setting, but it does not define how this is accomplished. |
ClientAuthentication, OpenSecureChannel |
CreateSession, OpenSecureChannel, Discovery |
Session Services Facets, Standard UA Client 2017 Profile, B |
|
CR 7.6 RE (1) Machine-readable reporting of current security settings |
|
|
√ |
√ |
P |
|
This is not defined in an OPA UA specification, but OPC UA does define a machine readable XML format that an application could be used to export the security setting. |
ClientAuthentication, OpenSecureChannel |
CreateSession, OpenSecureChannel, Discovery |
Session Services Facets, Standard UA Client 2017 Profile |
|
CR 7.7: Least functionality |
√ |
√ |
√ |
√ |
N |
The OPC UA specification does describe that least functionality is recommended with regard to OPC UA access, but this requirement applies to all service/ports protocols, etc. which is beyond the scope of OPC UA Specifications. |
|
|
CR 7.8: Control system component inventory |
|
√ |
√ |
√ |
N |
|
This scope is beyond what is defined in core OPC UA specifications. Some companion specification can define additional details about the overall environment in which OPC UA is executing, which could be able to cover this requirement. |
The Open Group has given the OPC Foundation permission to incorporate the above table(s) from their copyrighted documentation: O-PAS™ Standard, Version 2.1, Copyright© 2021 The Open Group. The table has been edited in this version for content, format and structure.