At present, Data Flows are considered in service if any client channel they flow along is in service. They suffer a loss of availability if any client channel they flow along has no connectivity.
However, this isn't 100% correct. It is possible for a data flow to go via more than one process-to-process communication path. This is ignored by the current In Service and Loss of Availability threats. By assuming that we need every client channel (i.e. process-to-process communication step) to be up and running, we're in effect assuming they are all on a single path along which data flows.
Possible paths are found in the data flow construction sequence, where they are represented as DataPath and DataChannel assets. However, these are constructed iteratively following all possible process-process connections from opposite ends. Where a data path meets a data channel, a communication path is inferred to exist. Links are then created from the DataFlow to the process-process relationships (ClientChannel assets).
This leaves a lot of DataPath and DataChannel assets leading from the sender or recipient of a DataFlow, many of which don't meet in the middle and are never used. It is unclear how these assets could be used in threats without creating dependencies on 'unused' paths and channels. Because of this, they are not used in threats, and are flagged for removal at the end of the construction sequence.
Because of that, the obvious cause-and-effect chain might not be workable, e.g. if a Data Flow uses a Data Channel but it depends on other Data Channels some of which are not used. That could lead to a situation where Data Flows can never be brought into service or never blocked. An audit will need to be conducted to verify that Data Channel dependencies are consistent with Data Flow dependencies.
At present, Data Flows are considered in service if any client channel they flow along is in service. They suffer a loss of availability if any client channel they flow along has no connectivity.
However, this isn't 100% correct. It is possible for a data flow to go via more than one process-to-process communication path. This is ignored by the current In Service and Loss of Availability threats. By assuming that we need every client channel (i.e. process-to-process communication step) to be up and running, we're in effect assuming they are all on a single path along which data flows.
Possible paths are found in the data flow construction sequence, where they are represented as DataPath and DataChannel assets. However, these are constructed iteratively following all possible process-process connections from opposite ends. Where a data path meets a data channel, a communication path is inferred to exist. Links are then created from the DataFlow to the process-process relationships (ClientChannel assets).
This leaves a lot of DataPath and DataChannel assets leading from the sender or recipient of a DataFlow, many of which don't meet in the middle and are never used. It is unclear how these assets could be used in threats without creating dependencies on 'unused' paths and channels. Because of this, they are not used in threats, and are flagged for removal at the end of the construction sequence.
Because of that, the obvious cause-and-effect chain might not be workable, e.g. if a Data Flow uses a Data Channel but it depends on other Data Channels some of which are not used. That could lead to a situation where Data Flows can never be brought into service or never blocked. An audit will need to be conducted to verify that Data Channel dependencies are consistent with Data Flow dependencies.