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.
Before starting the tests, prepare the node as follows:
- If the node is not delivered by TTTech, the SSH password must be changed.
- Ensure that the node DNA is in the applied state.
- Deploy workloads through a signed DNA file, and verify that the DNA is in the applied state.
- The production mode is enabled.
As the test intend to check some security measures, several errors will be reported in the audit logs.
Performing such tests may require to inform the security teams in charge of analysing the logs.
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 |
Not possible |
Not possible |
| CR1.3 |
Account management |
Auth-4 |
Auth-4 |
| CR1.4 |
Identifier management |
See note below. |
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 |
Node DNA |
| CR1.13 |
Access via untrusted networks |
NA |
NA |
Note
Each user is identified through their email address, which guarantees uniqueness.
FR2 – Use control (UC)
| Requirement |
Description |
Verification MS |
Verification Node |
| CR2.1 |
Authorization enforcement |
UC-8 |
UC-9 |
| CR2.1 RE(1) |
Authorization enforcement for all users |
UC-10 |
NA |
| CR2.1 RE(2) |
Permission mapping to roles |
Roles |
UC-9 |
| CR2.4, SAR, EDR, HDR |
Mobile code |
UC-1 |
UC-2 |
| CR2.4 RE(1) SAR, EDR, HDR |
Mobile code authenticity |
UC-1 |
UC-2 |
| CR2.5 |
Session lock |
UC-3 |
UC-4 |
| CR2.6 |
Remote session termination |
Only relevant for the node |
UC-5 |
| CR2.8 |
Auditable events |
See other tests |
See other tests |
| CR2.9 |
Audit storage capacity |
Part of hosting |
See Dashboard |
| CR2.10 |
Response to audit processing failures |
Part of hosting |
Node system monitoring |
| 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 |
Covered whenever audit logs are checked. |
Covered whenever audit logs are checked. |
| CR2.13 EDR |
Use of physical diagnostic and test interfaces |
NA |
Perform a visual inspection of the device. |
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 |
Access is only possible over physical port or SSH tunnel. |
| CR3.2 EDR, HDR |
Protection from malicious code |
Part of hosting |
RA-11 |
| CR3.3 |
Security functionality verification |
This page |
This page |
| 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,UC-7 |
| 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 |
Perform visual inspection, check if anti-tampering screws are in place and all the stickers are intact. |
| CR3.12 EDR, HDR |
Provisioning product supplier roots of trust |
NA |
Done as a part of the installation process. |
| CR3.14 |
EDR, HDR Integrity of the boot process |
NA |
RA-11 |
| CR3.14 (1) EDR, HDR |
Authenticity of the boot process |
NA |
RA-11 |
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 |
RA-11 |
| CR4.2 |
Information persistence |
Part of hosting |
RA-11 |
| 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 |
Review network configuration |
FR 6 – Timely response to events (TRE)
FR 7 – Resource availability (RA)
| Requirement |
Description |
Verification MS |
Verification Node |
| CR7.1 |
Denial of service protection |
RA-1 |
RA-2 |
| CR7.1 RE(1) |
Manage communication load from component |
Part of hosting |
Node system monitoring |
| CR7.2 |
Resource management |
Part of hosting |
Node system monitoring |
| CR7.3 |
Control system backup |
Part of hosting |
Verification is not possible during operation. |
| CR7.3 RE(1) |
Backup integrity verification |
Part of hosting |
Verification is not possible during operation. |
| CR7.4 |
Control system recovery and reconstitution |
Part of hosting |
Verification is not possible during operation. |
| CR7.6 |
Network and security configuration settings |
NA |
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 with the name of the invalid user.
|
| 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 login to the MS with the new credentials.
- It is possible to login to a node with the new credentials
- An audit log entry indicates which user logged in
|
| Auth-6 |
On the MS, try to change the password of the current user, using a password against the configured policy: too short, too long, only lower case, only upper case, no special character. |
- Each password that violates the policy is rejected.
- An audit log entry indicates which users attempted to change their password.
|
| Auth-7 |
- Try lo login on the MS with a wrong password (non-critical user).
- Repeat the failed login attempts until a message appears indicating that the user is blocked.
- Wait for the configured blocking time, by default 30 min.
|
- The user is blocked after the configured number of failed attempts, default 5.
- The user can login again after the configured blocking time.
- The audit log contains an entry stating that the user was blocked.
|
| Auth-8 |
- 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 the configured time, by default 10 min.
|
- The user is blocked after the configured number of failed attempts.
- The user can login again.
|
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 limits the permissions.
|
| UC-2 |
Go to the Local UI login page |
- SRI is used
- CSP limits 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 406.
|
| 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.
|
| UC-6 |
- On the MS create concurrent sessions for the same user.
|
- The configured number of concurrent sessions can be created.
- Additional sessions are rejected.
- Each session identifier is unique.
- An audit log indicates that the user has reached the maximum number of concurrent sessions.
|
| UC-7 |
- On the node create concurrent sessions for the same user.
|
- The configured number of concurrent sessions can be created.
- Additional sessions are rejected.
- Each session identifier is unique.
- An audit log indicates that the user has reached the maximum number of concurrent sessions.
|
| UC-9 |
- Login to a node as a user and retrieve the permissions
- Read the OpenAPI specification and try to perform each operation for which no permission is given
|
- Each request fails with 401 or 403.
|
| UC-10 |
- Try to add logs by performing a POST request on logs//_bulk
|
- The POST request with user credential is rejected with 401.
- The POST request with invalid node credentials is rejected with 401.
|
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.
- A token signed with a different key is rejected.
|
Availability
| Id |
Test steps |
Expected results |
| RA-1 |
- Create more than 700 request per second on the login page of the MS.
|
- Some requests are rejected with code 429.
|
| RA-2 |
- Create more than 75 request per second or burst of request on the login page of the Local UI.
|
- Some requests are rejected with code 429.
|
| 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./li>
- 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, the IP address of the node, the status of secure boot and of the production mode.
The second response includes the version name, the build date, the git commit and the list of security relevant packages with their version. |
Note
The status of secure boot and disk encryption is combined. If the Secure Boot status is true, it means both secure boot and disk encryption are active.