Verification methods of selected IEC 62443-4-2 requirements
This section provides some methods how to check that the security mechanisms of the node and of the Management System are properly configured and active.
Some tests are described in the tables below for manual execution.
Alternatively, TTTech provides a Docker container performing some of these tests automatically. The instructions on how to use the Docker container are provided together with the container.
Mapping of tests cases to requirements
FR 1 – Identification and authentication control (IAC)
| Requirement |
Description |
Verification MS |
Verification Node |
| CR1.1 |
Human user identification and authentication |
Auth-1 |
Auth-2 |
| CR1.1. RE(1) |
Unique identification and authentication |
Auth-1 |
Auth-2 |
| CR1.2 |
Software process and device identification and authentication |
Auth-3 |
Auth-3 |
| CR1.3 |
Account management |
Auth-4 |
Auth-4 |
| CR1.4 |
Identifier management |
See note 1 |
Delegated to the MS |
| CR1.5 |
Authenticator management |
Auth-5 |
Auth-5 |
| CR1.7 |
Strength of password-based authentication |
Auth-6 |
Delegated to the MS |
| CR1.10 |
Authenticator feedback |
Auth-1 |
Auth-2 |
| CR1.11 |
Unsuccessful login attempts |
Auth-7 |
Auth-8 |
| CR1.12 |
System use notification |
If needed, refer to Notifications |
Not implemented |
| CR1.13 |
Access via untrusted networks |
NA |
NA |
Note
Each user is identified through his email address, which guarantees the unicity.
FR2 – Use control (UC)
| Requirement |
Description |
Verification MS |
Verification Node |
| CR2.1 |
Authorization enforcement |
|
|
| CR2.1 RE(1) |
Authorization enforcement for all users |
|
|
| CR2.1 RE(2) |
Permission mapping to roles |
See Roles |
Not implemented |
| CR2.4, SAR, EDR, HDR |
Mobile code |
UC-1 |
|
| CR2.4 RE(1) SAR, EDR, HDR |
Mobile code authenticity |
UC-1 |
|
| CR2.5 |
Session lock |
UC-3 |
UC-4 |
| CR2.6 |
Remote session termination |
Only relevant for the node |
UC-5 |
| CR2.8 |
Auditable events |
|
|
| CR2.9 |
Audit storage capacity |
Part of hosting |
|
| CR2.10 |
Response to audit processing failures |
Part of hosting |
|
| CR2.11 |
Timestamps |
Used in Auth-1 |
Used in Auth-2 |
| CR2.11 RE(1) |
Time synchronization |
Tested in Auth-1 |
Tested in Auth-2 |
| CR2.12 |
Non-repudiation |
|
|
| CR2.13 EDR |
Use of physical diagnostic and test interfaces |
NA |
Non-destructive method not available. |
FR3 – System integrity (SI)
| Requirement |
Description |
Verification MS |
Verification Node |
| CR3.1 |
Communication integrity |
SI-1 |
SI-2 |
| CR3.1 RE(1) |
Communication authentication |
SI-1 |
|
| CR3.2 EDR, HDR |
Protection from malicious code |
Part of hosting |
Pending |
| CR3.3 |
Security functionality verification |
This document |
This document |
| CR3.4 |
Software and information integrity |
Part of hosting |
Done as part of the certified development process. |
| CR3.4 RE(1) |
Authenticity of software and information |
Part of hosting |
Done as part of the certified development process. |
| CR3.5 |
Input validation |
Done as part of the certified development process. |
Done as part of the certified development process. |
| CR3.7 |
Error handling |
Done as part of the certified development process. |
Done as part of the certified development process. |
| CR3.8 |
Session integrity |
SI-3 |
SI-4 |
| CR3.9 |
Protection of audit information |
Part of hosting |
Pending |
| CR3.10 EDR, HDR |
Support for updates |
NA |
Regular updates are published, no verification needed. |
| CR3.10 RE(1) EDR, HDR |
Update authenticity and integrity |
NA |
The checks are performed at different levels, preventing tests in a productive environment. |
| CR3.11 EDR.HDR |
Physical tamper resistance and detection |
NA |
Non-destructive method not available. |
| CR3.12 EDR, HDR |
Provisioning product supplier roots of trust |
NA |
Non-destructive method not available. |
| CR3.14 |
EDR, HDR Integrity of the boot process |
NA |
Non-destructive method not available. |
| CR3.14 (1) EDR, HDR |
Authenticity of the boot process |
NA |
Non-destructive method not available. |
All requirements applicable only to EDR and HDR devices are not relevant for the management system.
FR 4 – Data confidentiality (DC)
| Requirement |
Description |
Verification MS |
Verification Node |
| CR4.1 |
Information confidentiality |
Part of hosting,SI-1 |
Pending |
| CR4.2 |
Information persistence |
Part of hosting |
Non-destructive method not available. |
| CR4.3 |
Use of cryptography |
Done as part of the certified development process. |
Done as part of the certified development process. |
FR 5 – Restricted data flow (RDF)
| Requirement |
Description |
Verification MS |
Verification Node |
| FR 5.1 |
Network segmentation |
NA |
No practical test available |
FR 6 – Timely response to events (TRE)
FR 7 – Resource availability (RA)
| Requirement |
Description |
Verification MS |
Verification Node |
| CR7.1 |
Denial of service protection |
Pending |
Pending |
| CR7.1 RE(1) |
Manage communication load from component |
Pending |
Pending |
| CR7.2 |
Resource management |
Pending |
Pending |
| CR7.3 |
Control system backup |
Part of hosting |
Pending |
| CR7.3 RE(1) |
Backup integrity verification |
Part of hosting |
Pending |
| CR7.4 |
Control system recovery and reconstitution |
Part of hosting |
Pending |
| CR7.6 |
Network and security configuration settings |
NA |
See Network |
| CR7.7 |
Least functionality |
Part of hosting |
Done as part of the certified development process. |
| CR7.8 |
Control system component inventory |
RA-10 |
RA-11 |
Verification procedures
Authentication
| Id |
Test steps |
Expected results |
| Auth-1 |
Try to login on the MS with a non-existing |
- The login fails with the message "Invalid credentials".
- The audit logs of the MS contain a corresponding entry
- The timestamp of the audit log entry is within 10 s of the time the action occurred.
|
| Auth-2 |
- Try to login on a Node with a non-existing user.
|
- The login fails with the message "Invalid credentials".
- The audit logs of the MS and of the node contain a corresponding entry.
|
| Auth-3 |
- On the MS, save the secure ID of an existing node.
- Enter a new secure ID.
|
- On the MS, the node should be seen as offline.
- The audit logs.
|
| Auth-4 |
- On the MS, create a new user and give him viewer rights on the nodes.
- Delete the newly created user.
|
- On the node it is possible to login with the new user credentials.
- It is not possible to login on the node with the new user credentials.
|
| Auth-5 |
- On the MS change the password of a user with at least "Node viewer" role.
- Logout.
|
- It is possible to log in on the MS with the new credentials.
- It is possible to log in on a node with the new credentials
|
| Auth-6 |
On the MS, try to change the password of the current user, using a password against the configured policy. Refer to Note 3 below the table. |
The password is not accepted, a message is displayed explaining the policy. |
| Auth-7 |
- On the MS create a new user.
- Try lo login with a wrong password.
- Repeat the failed login attempts until a message appears indicating that the user is blocked.
- Wait for 30 min.
|
- The user is blocked after 5 failed attempts.
- The user can login again after 30 minutes. Refer to Note 2 below the table.
|
| Auth-8 |
- Create another user on the MS.
- Try to login on the node with wrong credentials.
- Repeat the failed login attempts until a message appears indicating that the user is blocked.
- Wait for 30 min.
|
- The user is blocked after 10 failed attempts.
- The user can login again. Refer to Note 3 below the table.
|
Note 1: Currently the password policy is not configurable. The password must be at least 8 characters long, contain at least one number and a mix of lower and upper case characters.
Note 2: The test uses the default configuration. If a change has been requested to the TTTech Support team, the number of failed attempts and the duration of the waiting period must be adjusted.
Note 3: The number of failed attempts and the duration of the waiting period are currently not configurable on the node.
Authorization
| Id |
Test steps |
Expected results |
| UC-1 |
Go to the Management System login page |
- SRI is used
- CORS are set to prevent access to other URL
- CSP limit the permissions
|
| UC-3 |
- Login to the Management System
- Copy the SessionID from the browser local storage
- Wait for 1 hour
- Make an API call to
/nerve/update/cloud/current-version using the previously retrieved sessionID
|
- The Login page of the Management System is displayed
- The API call is rejected with status 401
|
| UC-4 |
- Login to the Local UI
- Copy the JWT token from the browser local storage
- Wait for 1 hour
- Make an API call to /api/setup/node/info using the previously retrieved token
|
- The login page of the Local UI is displayed
- The API call fails with status code 401
|
| UC-5 |
- Create a remote tunnel according to remote-tunnel
- Leave the remote tunnel inactive for 30 min
|
- After 30 min of inactivities, the remote tunnel is not visible in the Management System and in the Local UI
|
Note
Some tests may be faster if the default configuration is changed to reduce to time out.
Integrity
| Id |
Test steps |
Expected results |
| SI-1 |
Scan the URL of the MS with an online SSL check tool or use TTTech verification tool. |
- HTTP call is redirected to HTTPS.
- Only TLS1.2 and TLS1.3 are accepted.
- Only
ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384 cipher suites are accepted. - The certificate is issued by Letsencrypt and is valid.
|
| SI-3 |
- Login to the Management System
- Save the sessionID
- Logout
- Perform an API call to
nerve/update/cloud/current-version - Login again
- Repeat login operation 50 times
|
- After logout the sessionID is invalid.
- The new sessionID is different from the first one.
- The sessionID strength is >128 bits.
|
| SI-4 |
- Login to the node and save the authorization cookie
- Logout
- Try to access
/api/version - Login again
- Inspect the token
|
- After logout the token is invalid
- After login the token is different.
- The token is valid for 1 hour or less.
|
Availability
| Id |
Test steps |
Expected results |
| RA-10 |
- Login to the Management System
- Copy the SessionID from the browser local storage
- Perform an API call to
nerve/update/cloud/current-version
|
The response includes the current version, the build date and the hash of the git commit. |
| RA-11 |
- Login to the Local UI
- Copy the JWT token from the browser local storage
- Make an API call to
/api/setup/node/info and to /api/version/ using the previously retrieved token
|
The response to the first call contains the name of the device, the hardware model and the IP address of the node.
The second response includes the version name, the build date and the git commit. |