Bugs in Data Flow threat patterns

[mike1813]

There are several threats involving a data flow, all of which use variants of the pattern PDF. The root pattern for this comprises a Data Flow, the Data flowing in it, and the Source and Destination processes. The matching pattern adds the manager of the destination process at an optional node with role Process Manager.

These threats are variously blocked or triggered by control strategies, some of which involve manual suspension of the data flow. This includes one control (typically some form of security or governance training) at the optional Process Manager role. The idea is that if the incoming data is found to be compromised, the Process Manager can suspend the data flow, preventing unauthentic, corrupt or infected data affecting the destination process, which may then enable further attacks or produce secondary effects. However, this strategy only works if there is a Process Manager.

Triggered threats then deal with the side effects of suspending the data flow. These lead to Loss of Availability in the data flow, with a likelihood equal to that of the compromise that would cause suspension. This didn't quite work due to Spyderisk/system-modeller#290, but that has now been fixed, so that the side effect threats can only be triggered if the optional Process Manager role is filled.

However, now this system-modeller bug has been fixed, there is still a problem. One of the control strategies is CSG-SuspendSensitiveDataFlow, which is supposed to protect sensitive data being sent if the destination or the communication path to it has been compromised. The problem is that in this situation, it is the manager of the source process that would intervene, not the destination process manager. At present, the control strategy blocking the potential harm and triggering side effects is incorrect, because the intervention control is in the wrong place. This would give the wrong results if the role is filled and the intervention control enabled at one end but not the other.

What we need to do is to create two versions of each matching pattern, one having the Process Manager associated with the destination process, and one where the Process Manager role manages the source process. Each threat can then be assigned to the right matching pattern, so fixing the issue.

[mike1813]

Note that this issue does not affect data flow threats that cause loss of authenticity or confidentiality. The problems are in threats that lead to loss of availability, or to 'normal operational effects' related to the encryption status of the data flow.

[mike1813]

The threats affected by this issue all cause loss of availability in a data flow as a side effect of security measures:

• DF.A.PDF.6.2: is a future risk calculation threat, triggered by CSG-AutoSuspendCorruptDataFlow and CSG-SuspendCorruptDataFlow, which models rejection of the data flow to exclude forged data.
• DF.A.PDF.6.3: is a future risk calculation threat, triggered by CSG-AutoSuspendCorruptDataFlow and CSG-SuspendCorruptDataFlow, which models rejection of the data flow to exclude any type of corrupt data.
• DF.A.PDF.6.4: is a future risk calculation threat, triggered by CSG-AutoSuspendCorruptDataFlow and CSG-SuspendCorruptDataFlow, which models rejection of the data flow to exclude malware.

These are future risk threats modelling the consequences of using data flow suspension as a response to threats. Their causes include the effects of the threats these contingency plans are meant to contain. Thus DF.A.PDF.6.4 is caused by a lack of Health (absence of malware) in the data flow - so if there is a low likelihood of malware infection, there will be a low likelihood of loss of availability due this threat. The CSGs represent rejection of the data by the destination process, so the automated version must have a cloud management control at this process, while the manual version has a control representing intervention by the manager of this process.

The situation where a data flow is already disabled is covered by DF.A.PDF.6.1. This threat applies in both future and current risk calculations, and has multiple triggers some of which only apply in current risk calculations:

• CSG-DisableDataFlow, which represents disablement of a data flow 'by design', used mostly when construction rules infer the presence of a data flow that does not or should not exist within the modelled system.
• CSG-AutoSuspendCorruptDataFlow-Impl-RT and CSG-SuspendCorruptDataFlow-Impl-RT are current risk versions of the contingency plan CSGs from DF.A.PDF.6.2, DF.A.PDF.6.3 and DF.A.PDF.6.4 to conditionally reject the data flow at the destination process.
• CSG-AutoSuspendSensitiveDataFlow-Impl-RT and CSG-SuspendSensitiveDataFlow-Impl-RT, are current risk versions of contingency plan CSGs to conditionally suspend the sending of data flows by the source process.

There are two problems with this arrangement that should be fixed:

• The last pair of CSGs require intervention by the manager of the source process, but the Process Manager role in pattern PDF is at the destination process, and
• There are no future risk threats modelling the side effects of an intention to suspend the data flow at the source process.

As an added complication, the CSG recommendation algorithm in system modeller depends on having the same CSG blocking a threat and triggering side effects of the CSG. This constrains how side effects are handled in domain models.

To solve the two problematic cases, the following steps can be used:

• Remove the Process Manager role from the original pattern PDF.
• Remove the contingency plan activation CSGs as triggers for DF.A.PDF.6.1, so this now only represents the consequences of data flow disablement 'by design', so it can use pattern PDF which now has no Process Manager role.
• Make a copy of pattern PDF called PDF+DM, with an optional Process Manager role representing the destination process manager.
• Replace DF.A.PDF.6.2 by DF.A.PDF+DM.6.2, based on pattern PDF+DM, and similarly for DF.A.PDF.6.3 and DF.A.PDF.6.4.
• Make a copy of pattern PDF called PDF+SM, with an optional Process Manager role representing the source process manager.
• Add threat DF.A.PDF+DM.6.1, triggered by CSG-AutoSuspendCorruptDataFlow-Impl-RT and CSG-SuspendCorruptDataFlow-Impl-RT, representing the situation where the data flow has been suspended by the destination process.
• Add threat DF.A.PDF+SM.6.1, triggered by CSG-AutoSuspendSensitiveDataFlow-Impl-RT and CSG-SuspendSensitiveDataFlow-Impl-RT, representing the situation where the data flow has been suspended by the destination process
• Introduce a new threat DF.A.PDF+SM.6.5, representing side effects for suspension of the data flow by the sending process, whose causes include lack of Confidentiality in the data flow, triggered by CSG-AutoSuspendSensitiveDataFlow or CSG-SuspendSensitiveDataFlow

The first two steps address the issue that the current version of DF.A.PDF.6.1 has inconsistent roles between triggering CSGs. The remaining steps address the cases that are then no longer covered by DF.A.PDF.6.1, and fill the gap in future risk side effect modelling for contingency plans to suspend data flows to prevent sensitive data leaks. The renaming of existing threats just makes it clear from the threat name which version of pattern PDF it is based on, and hence which process manager is included (if any).

There are also three threats that create causes for other threats that together model side effects of encryption:

• DF.X.PDFV.6: models the data flow being encrypted using a key managed by a key vault service, so the data is not available in unencrypted form. Modelled as a threat because being encrypted may cause other threats to data availability if a consumer needs unencrypted data.
• DF.X.PDF-V.6: is the same threat, but encryption is done with a pre-installed (shared) key represented by a control strategy.
• DF.Y.PDF-V.8: is the opposite case, where the data is not encrypted, which may cause threats to availability if a consumer needs encrypted data.

These threats present no concerns because they use control strategies representing design-time choices to use end-to-end encryption, which does not require intervention by the process manager. The Process Manager role should be removed from patterns PDFV and PDF-V so their names show the absence of this role, consistent with the rest.

[mike1813]

In addition, threats DF.A.AC-iDFSC.6.3 and DF.A.AC-iDFCS.6.3 can be removed from package#ProcessTrust. They also cover cover side effects of suspension of the data flow by the sender, but their causes are not effects of other threats on the data flow itself. As a result, they overlap with DF.A.PDF.6.2 and threats modelling side effects of suspending client access.

[mike1813]

Correction.

The proposed threat DF.A.PDF+SM.6.5 does not work properly because it is caused by a lack of data flow confidentiality. Suspending the data flow to prevent leakage would mean this cause is also negated. Suspending the data flow after the data has leaked does not make sense.

The cause of this threat should be the trustworthiness of the destination process, in a context where the data can flow to it. The threat pattern should still involve a Process Manager role related to the source process, but it should also include contexts related to the destination process. Something like DF.A.PDFAC+SM.

[mike1813]

Now addressed in branch 242. Can be closed when that branch is merged.