mike1813
commented
8 months ago There is a similar issue regarding cryptographic protection of copies of data stored on hosts. That case is less problematic, because access is by one process at a time, and possibly only one process ever.
Selection of an Encryption control at a Data Flow asset is meant to signify end-to-end (i.e., not transport level) encryption. This protects the data when the data flow goes between source and destination processes via one or more intermediaries, by making it impossible for the intermediaries to access the data.
For this to work, the source and destination processes must have a shared key. There were two options:
The first option is cheaper to implement, and (given a suitably secure negotiation protocol), would protect the data from attacks by or via the intermediaries. However, it does not prevent injection by an imposter source or interception by an imposter destination, unless further measures are used to enable mutual source-destination authentication. The second option does protect against impersonation attacks, as imposters would not have access to the pre-shared key. For this reason, until now the domain model assumed the second option is used.
We now have a third alternative, using a key stored in a key vault to which both source and destination processes have access. New keys could then be used for each exchange, and would not need to be stored by the source and destination, so protecting against some extra threat paths. This arrangement is denoted by asserting a relationship from the key vault to the data flow
Should we now change our assumptions about the meaning of the Encryption control? For example, we could assume that a pre-shared key would be shared via a key vault. This would mean the Encryption control now signifies end-to-end encryption using a key negotiated over the data channel (and hence not proof against all the same attacks as hitherto).