How should perspective policy be defined?

[claudijd]

We have used a similar pattern as this to define external policy in the DC's and Offices, so there is a precedent here, but sharing some rough ideas on how we can expand on this policy expectation definition to support more complex, but still relatively simple policy expectations to help define scan visibility as an effective unit-test framework, but still keep it human readable/writeable.

# WARNING: this is a mock up draft, not really our policy, just sort of getting an idea if this is palatable

PerspectiveID: 6ee44136-21d8-49dd-9eae-875a9cc18c70
  Description: Mozilla's from Internet to Mozilla Data Center Policy
  Expectations:
    PortWhiteList:
      - 80
      - 443
      - 500
    SocketWhiteList:
      - 192.168.1.1:25 # Bug 123456 (This is our inbound SMTP agent)

PerspectiveID: 2d5b504e-9d90-429e-b751-c07779d6f576
  Description: Mozilla's Guest to Guest Policy
  Expectations:
    PortBlackList:
      - 22
      - 2222
      - 5900
      - 389
    SocketWhiteList:
      - 192.168.1.1:389 # Bug 123456 (This is our LDAP endpoint, it's required for guest's to auth)   

PerspectiveID: eaa1141f-89ac-469b-9439-8fc00d8cec4d
  Description: Mozilla AWS Account XYZ Inside VPC => Inside VPC visibility
  Expectations:
    PortBlackList:
      - *

[arcrose]

While the whitelist/blacklist language is fairly natural to me, it does make me question some expectations. For example, it's not obvious whether specifying a blacklist of ports would mean that any ports found to be open and not in the blacklist would be considered okay. I'd like to propose a couple of things here:

1. Replace PortWhiteList with OpenPorts, PortBlackList with ClosedPorts, SocketWhiteList with AllowedConnections and (hypothetically) SocketBlackList with ForbiddenConnections.
2. Require both Open and Closed sections.

My argument for 1 is that the wording makes the intention a bit clearer. I personally have to do a mental translation from "whitelist" to "allowed" and "blacklist" to "disallowed," so I prefer to skip that step if possible.

As for 2, I think that requiring both sections will make it absolutely clear what the expectations are. It was initially unclear to me whether I should expect ports determined to be open and not on the blacklist to be acceptable. When a blacklist and whitelist are both present, it seems a bit more natural to assume that

• ports open on the blacklist => error
• ports not open on the whitelist => error
• ports open on neither the blacklist nor the whitelist => error
• everything else => okay

It's a tiny bit frustrating to have to think in terms of set theory. I might even suggest doing away with these two lists and advocate for something like this:

Expectations:
  - 22: open
  - 80: open
  - 443: open
  - 5900: closed
  - *: closed

In this case, it's easier to require that an "open / closed" policy be made explicit for every possible port. It feels less ambiguous and more straightforward to me.

[arcrose]

Another thing you'll probably want to support are port ranges and maybe even port lists for expressiveness.

Expectations:
  - 22, 2222: closed    # SSH
  - 80, 443: open       # HTTP(S)
  - "40000-60000": open # FTP?

[andrewkrug]

Is this supposed to be described as .yml

[claudijd]

@andrewkrug ultimately, probably JSON, I feel like that's a small detail relative to what it should contain.

[ajvb]

1. What is and why is it called PerspectiveID?
2. What are the defaults or is a configuration section required before you can scan any range?
3. What matches a rule set to an IP range or multiple IP ranges?

[claudijd]

@jjvb...

1.) A PerspectiveID is a unique identifier for a perspective. A perspective is basically a unique source and target(s) pairing. Example: A target may look different from the internet than from say a trusted IP range and the perspective and associated policy that we might run on that perspective's scan result data may be different.

2.) I'm assuming you mean policy defaults, as of yet, I have not defined any defaults. In fact, I have just this proposal of format and no code to interpret written yet. We could easily have defaults, though I'm not sure what a sane default would look like as the policy seems opinionated based on view.

3.) There is not concept of a rule set, but if you are talking perspective to target mapping, that would be the perpective ID. The agent would emit output that contains the results and the perspective that result is for. We'd then have post processing that overlays our policy expectations per perspective and determines if we have an out of policy situation and escalates.

[caggle]

@claudijd I liked your initial suggestion. One thing I'd say is, do we need to specify which protocol a particular port corresponds to (tcp or udp)? Looking at the example I see port 500, which is likely a IKE protocol for VPN connections and is UDP, but the policy does not specify this (Does it have to?)

I also like @zsck's suggestion of below, it feels easier to read and understand:

Expectations:

• 22: open
• 80: open
  • 443: open
  • 5900: closed
  • *: closed

We could also represent an allowed socket connection in that format, e.g. 192.168.1.1:25: open (we could use another delimiter for port status to avoid confusion).

[ajvb]

1.) A PerspectiveID is a unique identifier for a perspective. A perspective is basically a unique source and target(s) pairing. Example: A target may look different from the internet than from say a trusted IP range and the perspective and associated policy that we might run on that perspective's scan result data may be different. 3.) There is not concept of a rule set, but if you are talking perspective to target mapping, that would be the perpective ID. The agent would emit output that contains the results and the perspective that result is for. We'd then have post processing that overlays our policy expectations per perspective and determines if we have an out of policy situation and escalates.

Ok, yeah that makes perfect sense but the PerspectiveID as a UUID seems like it may be a convoluted way to accomplish this. I wonder if you can have PerspectiveName with a more human friendly value, as these will be distinct scanners that will be treated as pet servers, right?

As well, I wonder if you can completely remove the idea of a PerspectiveID by having configuration files that are scanner specific that match IP ranges with rules? Or will scanners potentially support multiple perspectives?

Lastly, I don't think my above opinions are blockers by any means. Just thoughts on how to structure the configuration to make it easier to understand.

2.) I'm assuming you mean policy defaults, as of yet, I have not defined any defaults. In fact, I have just this proposal of format and no code to interpret written yet. We could easily have defaults, though I'm not sure what a sane default would look like as the policy seems opinionated based on view.

Ok sounds good, just wanted to check. In my humble opinion, I would not have defaults and require a configuration to be written OR have the default be "no ports are open".

@caggle @claudijd

One thing I'd say is, do we need to specify which protocol a particular port corresponds to (tcp or udp)? Looking at the example I see port 500, which is likely a IKE protocol for VPN connections and is UDP, but the policy does not specify this (Does it have to?)

What would be the behavior if no protocol is listed? It means both TCP and UDP? There is some mapping within nmap-agent that says "X port maps to X protocol"?