system . A Trustworthiness Resilience Method most likely allows the execution of the system with limited capabilities even after the disrupted status is reached . But these “ minor ” levels follow the same graphical schema as shown in the TSSM .
It is important to understand that an initial threat which leads to an attack can also lead instantly to an additional accident . In this specific case , the Trustworthiness Security Method , which should protect the system from this threat , has a hazard ( which was probably hidden but suddenly visible after the incident caused by this threat happened the first time ). And due to this accident , a new threat could cause an even bigger attack . Which means , at the time of an incident , a cascade of hazards in the system could quickly convert a harmless attack into a more potent and dangerous attack .
After a system is designed and setup , the operator takes over the whole responsibility to run the system in a trustworthy way . During the design , all visible ( well-known ) perils should be specified and addressed by specific Trustworthiness Methods , and everything should be documented for the operator . The following details must be specified :
• Type of peril ( hazard or threat )
• Source of peril ( specific component , external location etc .)
• Likelihood of impact as incident
• Detailed description of the peril
• Prepared Trustworthiness Methods to reject this peril
• Describing the specific functionality of the Trustworthiness Methods for these peril
• Consequences if this Trustworthiness Method will fail : This will lead to other ( referenced ) perils , in many cases more severe .
Furthermore , the operator must practice what happens if such perils target the system as incidents . However , many of these incidents will lead to a disrupted system , so practicing the incident operations can only be done outside of the normal usage of the system , which is not always practical , especially not in systems running 24x7 . In this case , a simulation of the system , based on its Digital Twin , would help tremendously .
During such incident practices , new perils will most likely appear , because during the design phase , the impact of a specific peril was not completely visualized . In this case , the operational management must refine and expand the documentation around incidents .
Another reason to expand the list of perils is the detection of hidden hazards . They usually arise during a real incident . In such cases , the down time of a disrupted system is longer than usual because the selection of the correct trustworthiness method to stop this hazard is frequently not instantly apparent and sometimes a trial-and-error approach may be required . But after the
14 July 2022