Open nozmore opened 3 years ago
A process is a server when it has incoming dataflows. What annotations currently suggest that it's always listening?
Maybe but not currently. Command line arguments or shell/ui interface could be an incoming Dataflow, this does not make it a Server.
I actually thought of this as a 3rd option but got busy and forgot to add it but you could detect this in policy or in the apply_defaults area and set a bit to indicate such. This would address the Primary goal but not the secondary, well technically it could be exposed in reporting but doesn't aid in model creation.
Still, this is defined by the dataflow, if it has a port/protocol defined or not.
That's a good point. At higher levels (Ln) of dfd's we could see a Process "listening" to incoming data via CLI, GUI, IPC, pipes, etc. and that would be reflected in there being dataflows, but not in being a Server per se.
I think this is a semantic thing, not a technical more/less-attributes one.
I updated the option list above with with the one I left out and @nineinchnick referenced.
I would like to have better support for client/non-listening processes. Today Process contain annotations (also inherited from Asset) which applies to Listening/Server Processes or Actor could be used but you miss out on applicable annotations. There are a few ways to address this so thought we could chat about it.
The primary goal is to include the concept of a listening vs non-listening Process in threat evaluation. A secondary goal is to restrict to applicable annotations during model creation and reporting.
Possible options:
1 and 2 can address the Primary goal but don't directly address the secondary goal, they could be included in reporting with 2 having to replicate existing logic. 3 would address both cases and IMO the threat eval and reporting would be cleaner.
I have a local branch I was starting to do this but before I get too far along I wanted to get some thoughts.