Improved support for client/non-listening processes

[nozmore]

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. Add a type on Process to indicate if it creates a listening socket. With Threat Evaluation Improvements: Simplify conditions and first step toward detecting mitigations #152 it could be a target condition.
2. Change nothing and use existing annotations, inbound dataflow with port assigned, etc.
3. Introduce a new class for ClientProcess with specific annotations. This way using an IDE only applicable annotations will be exposed. This would involve wider changes impacting the entire inheritance model so we should discuss this more. i.e moving some annotations out of Asset and creating a "ListeningAsset" (name tbd).. port, protocol, definesConnectionTimeout, etc.

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.

[nineinchnick]

A process is a server when it has incoming dataflows. What annotations currently suggest that it's always listening?

[nozmore]

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.

[nineinchnick]

Still, this is defined by the dataflow, if it has a port/protocol defined or not.

[izar]

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.

[nozmore]

I updated the option list above with with the one I left out and @nineinchnick referenced.