NOD-010b — Authorize Node Fault Injection

Go to NOD-010 — Inject Node Faults

The Authorizing Authority SHALL authorize each Fault Injection before the DIDO-TE introduces the specified Fault.

• NOD-010 — Inject Node Faults
• NOD-010a — Specify a Node Fault
• [DTE5] DIDO-TE Requirements Register, source requirement identifier and obligation to be assigned
• [DTE6] Structured Information Processing Reference Architecture (SIP-RA)
• [DTE7] Federated Data Interpretation Systems Reference Architecture (FDIS-RA)

Fault Injection deliberately introduces a condition intended to change Node behaviour. Authorization confirms that an identified authority has accepted the specified purpose, target, scope, risks, controls, termination conditions, recovery conditions, and potential effects before introduction of the Fault.

The authorization identifies the Fault, target Node, governing Test Definition, governing Test Procedure, permitted scope, authorization period, responsible participants, constraints, and conditions that invalidate or revoke the authorization.

Authorization of the Test Definition does not necessarily authorize execution of every Fault Injection described by that Test Definition. NOD-010b requires an authorization that explicitly covers the Fault Injection performed by the DIDO-TE.

Changes to the target, Fault, injection point, timing, duration, intensity, scope, prohibited effects, termination conditions, or recovery conditions require reassessment of the authorization.

Unauthorized or incorrectly authorized Fault Injection may affect unrelated Nodes, Test Resources, Test Environments, Test Executions, protected information, or operational services.

• Authorizing Authority
• DIDO-TE
• Fault
• Fault Injection
• Node
• Node Configuration
• Node Binding
• Dependency
• Test Definition
• Test Procedure
• Test Environment
• Test Execution
• Test Resource
• Evidence
• Traceability

Verification confirms that:

1. Each Fault Injection has an identified Authorizing Authority.
2. The Authorizing Authority has authority over the target Node, Test Environment, and affected resources.
3. The authorization uniquely identifies the Fault Injection.
4. The authorization identifies the specified Fault and target Node.
5. The authorization identifies the governing Test Definition and Test Procedure.
6. The authorization identifies the injection point, timing, duration, intensity, and permitted scope.
7. The authorization identifies the expected effects and prohibited effects.
8. The authorization identifies the controls governing containment, suspension, termination, and recovery.
9. The authorization identifies the authorization period and conditions that invalidate or revoke authorization.
10. The authorization identifies the participants permitted to initiate, control, terminate, and recover from the Fault Injection.
11. The authorization exists before preparation proceeds beyond the point that could introduce the Fault.
12. The authorization exists before the DIDO-TE introduces the Fault.
13. The DIDO-TE verifies the authorization before permitting Fault Injection.
14. The DIDO-TE prevents Fault Injection when authorization is missing, expired, revoked, ambiguous, incomplete, or inconsistent with the governing Test Definition.
15. The DIDO-TE prevents Fault Injection when the target, Fault, injection point, timing, duration, intensity, or scope differs from the authorization.
16. A change to an authorized Fault Injection receives authorization before the changed Fault Injection proceeds.
17. The DIDO-TE preserves the authorization and each authorization revision.
18. The DIDO-TE maintains Traceability among the Authorizing Authority, authorization, Fault, Fault Injection, target Node, governing Test Definition, governing Test Procedure, Test Environment, Test Execution, and resulting Evidence.
19. Missing, expired, revoked, incomplete, unauthorized, incorrectly scoped, or untraceable authorization constitutes nonconformance with this requirement.

The following pages reference this requirement:

Assign the delivery phase.

Assign the implementation status.

The proposed derived requirement requires review and acceptance.

Assign the source requirement identifier and obligation from the DIDO-TE Requirements Register.

{{section>dido:03-dido-te:99-annexes:annex-c-requirements:03-node-requirements:nod-010-inject-node-faults:nod-010b-authorize-node-fault-injection#Statement&noheader&nofooter&noeditbtn}}