A process using locally stored data as input or for display to a user is assumed to read the stored data unless it gets the data via a data service. That is deduced by construction pattern Pr-cDSH-S-Hu-DA+DI, and encoded as a DataCopy-fulfils-DataInput relationship.
The problem is that the process may be getting the data from another data producing process, just not from a data service. In practice, it is even possible that the process may receive new data and save the data to its host, if there is no other process serving the stored copy. In that case, if the data is created but not appended by another process, the receiving process would not need to read the stored data once written to its host. This is significant because extra threats are then created to the process whose effects would not otherwise arise.
Pattern Pr-cDSH-S-Hu-DA+DI does not know whether the process will receive the data from another process, because that is inferred by the subsequent data flow inference sequence, so it assumes a process using stored data as input will be reading from the stored copy. It should only do this if either (a) updates from a source process are not obtained via a data flow, or (b) updates do not overwrite previous data but are appended to it.
The best way to solve this problem would be to delay creation of the DataCopy-fulfils-DataInput relationship until after data flows have been inferred. New construction patterns could then add the relationship if and only if conditions (a) or (b) are satisfied. This may or may not be possible, depending whether the DataCopy-fulfils-DataInput is needed as a precondition for correctly deducing the data flows in situations where conditions (a) and (b) are not satisfied.
Note that there is a similar problem with write access by a process that creates updates for locally stored data not accessed via a data service. In such cases, it is possible that the process sends updates via some other process (not a data service), which forwards those updates to a service that writes to the stored copy. However, this is not such a problem as the read access scenario because threats to data integrity arising from the potentially incorrect direct access to the stored copy cause the same effects as the threats to the flow of data from the process.
A process using locally stored data as input or for display to a user is assumed to read the stored data unless it gets the data via a data service. That is deduced by construction pattern Pr-cDSH-S-Hu-DA+DI, and encoded as a DataCopy-fulfils-DataInput relationship.
The problem is that the process may be getting the data from another data producing process, just not from a data service. In practice, it is even possible that the process may receive new data and save the data to its host, if there is no other process serving the stored copy. In that case, if the data is created but not appended by another process, the receiving process would not need to read the stored data once written to its host. This is significant because extra threats are then created to the process whose effects would not otherwise arise.
Pattern Pr-cDSH-S-Hu-DA+DI does not know whether the process will receive the data from another process, because that is inferred by the subsequent data flow inference sequence, so it assumes a process using stored data as input will be reading from the stored copy. It should only do this if either (a) updates from a source process are not obtained via a data flow, or (b) updates do not overwrite previous data but are appended to it.
The best way to solve this problem would be to delay creation of the DataCopy-fulfils-DataInput relationship until after data flows have been inferred. New construction patterns could then add the relationship if and only if conditions (a) or (b) are satisfied. This may or may not be possible, depending whether the DataCopy-fulfils-DataInput is needed as a precondition for correctly deducing the data flows in situations where conditions (a) and (b) are not satisfied.
Note that there is a similar problem with write access by a process that creates updates for locally stored data not accessed via a data service. In such cases, it is possible that the process sends updates via some other process (not a data service), which forwards those updates to a service that writes to the stored copy. However, this is not such a problem as the read access scenario because threats to data integrity arising from the potentially incorrect direct access to the stored copy cause the same effects as the threats to the flow of data from the process.