CP Dependencies and Data Sovereignty

[mike1813]

Data Sovereignty analysis is needed by a dependent project (DS2), so a new package#DS2DataSovereignty is being added to handle that, see #246.

Data Sovereignty imposes requirements on both usage control and usage auditability. In both cases, the requirement may be met indirectly. For example,

• if a usage policy controls a service, it also controls data flows to and from that service, or
• one can audit access to a stored file if a logger records information about every process that accesses the file.

Consequently, package#DS2DataSovereignty uses many construction patterns. These create inferred logs or policy clauses associated with Logger or Policy assets, and relationships denoting which data lifecycle assets are logged or auditable using a logger, or regulated by a policy.

Some of these create patterns must go in the existing CP sequence for data storage inference. Unfortunately, this sequence is a bit of a mess, due to the presence of existing unresolved sequencing dependencies. See #220 and #221.

To complete the model of Data Sovereignty, we now need to fix the existing sequence by addressing both these issues, then make the sequence more extensible by rationalising its structure.

[mike1813]

There are similar sequencing issues related to Host operation, which currently involves four sets of patterns:

• A general sequence in package#Network that finds Hosts with no operator and assigns this role to the Host manager or their employer.
• A fall back pattern for Fixed (physical) Hosts at the end of that sequence in package#Network, assigning the role to the operator of the Space in which the Host is located.
• A sequence in package#Privacy that finds Hosts with no operator that are relatedTo a Human data subject, and assigns the role to them.
• A one-pattern sequence in package#Virtualisation that finds Virtual Hosts with no operator and assigns the role to the operator of the Host on which they are provisioned

Each sequence is bracketed by marker patterns with dependencies that leave the last two sequences running in parallel, despite the fact that there is a dependency. Assignment of an operator to a Virtual Host in the last pattern does not conflict with the personal device operator CP, because that must pertain to a physical host. However, the Host on which a Virtual Host is provisioned may be physical, so the last sequence does depend on the previous sequence.

This is one of those areas in the domain model where the construction patterns are meant to help users by filling in details they may overlook or just not have time for. The gaps must be filled or threats won't work correctly. However, the sequencing imposes a priority order on which assumptions are used to fill in the gaps. Generally speaking, this is not a safe approach because the assumptions are just that - we assume we know what the system modeller user would have done, had they been able and willing to assert everything themselves.

The simplest solution in this specific case is to force the package#Virtualisation pattern to follow all the others. Because package#Virtualisation is not supposed to depend on package#Privacy, we can't just make the start marker in package#Virtualisation sequence follow the end marker in package#Privacy. Instead, the package#Network sequence will need more markers allowing the other two sequences to be bracketed within the package#Network markers, dividing the package#Network sequence into

• managed host operation inference, including hosts in a space with an operator
• unmanaged physical host operation inference

[mike1813]

Now addressed in branch 242, so this issue should be closed when that is merged by pull request #277.