DF1 threat assumes source and sink are remote systems
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 1.2k
- Forks
- 229
- PR merge metrics
- No merged PRs in 30d
Description
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?
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the DF1 threat logic and the Dataflow and DataStore properties described in the issue. Compare the Protocol and isLocalFile approaches, and resolve the intended behavior for local file stores versus remote systems with maintainers. Done means DF1 is not reported for the intended local-file case and the agreed behavior is covered by tests.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- security
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100