DF1 threat assumes source and sink are remote systems
I was mocking up a sample DFD with a Process and some local files datastores and I am getting a DF1 threat (Dataflow not authn'd) which isn't the beast threat here.
I would like to add logic so this threat doesn't apply to local file data stores and maybe introduce a threat about permissions or something.
I've mocked up two places where I can do this.
-Use the Protocol property on the Dataflow.
"target.authenticatedWith is False and target.protocol is not 'FileSystem'"
-Add an isLocalFile to DataStore
"target.authenticatedWith is False and ( (type(target.source) is Datastore and target.source.isLocalFile is False) or (type(target.sink) is Datastore and target.sink.isLocalFile is False) )"
Thoughts?
My logic isn't right on the second example but you get the idea.... its late ; )
Personally I like having 'Datastore.isLocalFile' for other threats but this does add complexity to Threat conditions, as you can see above. And would need to be more complicated as Server or Process wouldn't get caught with that example.
Why not Datastore.type = (Local, Database, Registry, ...) ?
Even better.
Having that is good and it should get added since it could be useful for other Threats/Mitigations. We could also have a dataflow type, IPC, Network, File/Local. This would simplify the threat condition so I wouldn't need to detect if its datastore being calling the datastore method.
I'm not sure if I understood the issue correctly but what do you think about checking threats only against dataflows crossing threat boundaries? Flows can be still added inside a boundary to make the model a bit clearer, if needed, but getting the right threat boundaries is important.
Implementing this is kinda simple, most threats that apply to Dataflows only need to have target.crosses(Boundary) added.
DF1 threat no longer exists, which threat does this issue relate to now?