Access Policy

An access policy does the following.

Defines the type of rules allowed, ingress or egress.
Defines the network(s) on one side of the test
- ingress-network defines the destination addresses.
- egress-network defines the source addresses.
Provides organizational metadata such as names, comments, and owners.

Rules evaluations happen independently, so overlapping policies and rules are allowed.

Access policy

A policy is a group of related rules that target the same ‘ingress’ or ‘egress’ network. You must place Invariant rules inside an access policy.

Example

access-policy:
  - comment: Access to the datacenter is controlled by this policy
    ingress-network: DATACENTER
    name: datacenter-security-policy
    owner: [email protected]
    rules:
      - comment: VLAN30 must not be able to reach DATACENTER through SSH
        destination-port: SSH
        protocol: tcp
        source-address: VLAN30
        type: ingress-deny

Schema

Field	Type	Required?	Description
`access-policy[].comment`	string	Optional	Free form comment describing the policy.
`access-policy[].owner`	string	Optional	String to record owner of the policy. e.g., `[email protected]` or `security team`
`access-policy[].enforce`	boolean	Optional	Boolean indicating the policy enforcement, resulting in a violation. Defaults to true.
`access-policy`	list of objects	Required	List of access policies.
`access-policy[].name`	string	Required	Name of the policy. No whitespace is allowed. e.g. `my-access-policy` or `my_access_policy`. Only characters -, _, A-Z, a-z, 0-9 are allowed.
`access-policy[].rules`	list of objects	Required	A list of rule objects.
`access-policy[].ingress-network`	list of strings or Network	Yes (mutually exclusive to egress-network)	Network definitions of the destination networks or an `ingress-network` object. Mutually exclusive with `egress-network`.
`access-policy[].egress-network`	list of strings or Network	Yes (mutually exclusive to ingress-network)	Network definitions of the egress networks or a `egress-network` object. Mutually exclusive with `ingress-network`.

Policy best practices

Use comments to help describe the policy's intention and refer to external resources such as service tickets.
Use teams rather than individuals in the owner's field as people move teams or companies.
Set enforce to false during the development of new policies or when you want to track your progression towards adhering to policy.

Network schema

A policy must have an ‘ingress-network’ or ‘egress-network’ and never both.

All rules in this policy must match the direction of the policy. A policy with ‘ingress-network’ defined may only contain ‘ingress’ rules. A policy with ‘egress-network’ defined may only contain ‘egress’ rules.

Field	Type	Required?	Description
`destination-address`	list of strings	Required (at least one)	Network definitions of the destination networks.
`destination-exclude`	list of strings	Required (at least one)	Network definitions that are subtracted from `destination-address`.

Field	Type	Required?	Description
`source-address`	list of strings	Required (at least one)	Network definitions of the source networks.
`source-exclude`	list of strings	Required (at least one)	Network definitions that are subtracted from `source-address`.
`source-interface`	list of strings	Optional	Consider traffic entering on these interfaces. Disables automatic interface selection.
`enter-interface`	list of strings	Optional	Consider traffic originating from these interfaces. Disables automatic interface selection.

Rule types

Invariant supports the following types of rules.

Rule type	Direction	Description
ingress-critical-flow	ingress	This traffic should always be successfully delivered.
egress-critical-flow	egress	This traffic should always be successfully delivered.
ingress-deny	ingress	This traffic should never be successfully delivered.
egress-deny	egress	This traffic should never be successfully delivered.
ingress-deny-others	ingress	Within a scope (e.g., TCP traffic), traffic should never be successfully delivered except where permitted.
egress-deny-others	egress	Within a scope (e.g., TCP traffic), traffic should never be successfully delivered except where permitted.

Rules schema

Field	Type	Required?	Description
`type`	string	Required	The type of rule, can be `ingress-critical-flow`, `egress-critical-flow`, `ingress-deny`, `egress-deny`, `ingress-deny-others`, `egress-deny-others`.
`comment`	string	Optional	Free form text describing the rule.
`source-address`	list of strings	Optional	Network definitions of the source networks.
`source-exclude`	list of strings	Optional	Network definitions that are subtracted from `source-address`.
`source-port`	list of strings	Optional	Service definitions used as the source ports.
`source-interface`	list of strings	Optional	Interface identifiers where traffic should be sourced from.
`enter-interface`	list of strings	Optional	Interface identifiers where traffic should enter.
`destination-address`	list of strings	Optional	Network definitions of the destination networks.
`destination-exclude`	list of strings	Optional	Network definitions that will be subtracted from `destination-address`.
`destination-port`	list of strings	Optional	Service definitions used as the destination ports.
`protocol`	list of strings	Optional	Protocol such as `tcp`, `udp` or `icmp` the rule covers.
`icmp-type`	list of integers	Optional	ICMP type numbers, used with the protocol being `icmp`. See IANA documentation for list of types
`icmp-code`	list of integers	Optional	ICMP code numbers, used with the protocol being `icmp`, must fall within the valid codes for the type. See IANA documentation for list of codes
`within`	list of Flows	Optional	Used when type is `ingress-deny-others` or `egress-deny-others`. Scopes deny-other search space.
`deny-all-except.flows`	list of Flows	Required with `deny-others` type	Flows that are exempt from violation for `ingress-deny-others` or `egress-deny-others`

Rules best practices

Use comments to describe the intent behind the rule.
If you want to ensure flows in deny-all-except.flows are allowed, use a critical flow in tandem.

Flow schema

Field	Type	Required?	Description
`comment`	string	Optional	Free form text describing the rule.
`source-address`	string	Optional	Network definitions of the source networks.
`source-exclude`	string	Optional	Network definitions that will be subtracted from `source-address`.
`source-port`	string	Optional	Service definitions used as the source ports.
`source-interface`	string	Optional	Interface identifiers where traffic should be sourced.
`enter-interface`	string	Optional	Interface identifiers where traffic should enter.
`destination-address`	string	Optional	Network definitions of the destination networks.
`destination-exclude`	string	Optional	Network definitions that will be subtracted from `destination-address`.
`destination-port`	string	Optional	Service definitions used as the destination ports.
`protocol`	string	Optional	Protocol such as `tcp`, `udp` or `icmp` the flow covers.
`icmp-type`	string	Optional	ICMP type numbers, used with the protocol being `icmp`. See IANA documentation for list of types
`icmp-code`	string	Optional	ICMP code numbers, used with the protocol being `icmp`, must fall within the valid codes for the type. See IANA documentation for list of codes

Examples

ingress-critical-flow

This rule asserts that a traffic flow will always be delivered. Specifically, it looks for any possible way a packet could be rejected, dropped, or failed to route within this traffic class.

access-policy:
   - name: dmz-ingress
     comment: |
        This policy asserts that the DMZ network makes some services available to the internet.
     owner: [email protected]
     ingress-network: DMZ
     rules:
        - type: ingress-critical-flow
          comment: Ensure public HTTP/HTTPS access to DMZ resources
          protocol: tcp udp
          destination-port: HTTP HTTPS

egress-critical-flow

Identical to ingress-critical-flow. Asserts that traffic flows between the egress-network and the destination-address are always delivered. Specifically this rule looks for any possible way a packet could be rejected, dropped, or fail to route within this traffic class.

access-policy:
   - name: basic-internet-access
     comment: |
        This policy asserts that some basic internet access (egress) is expected for the target networks.
     owner: [email protected]
     egress-network:
        - DMZ
        - VLAN30
        - CLIENT_VLANS
     rules:
        - type: egress-critical-flow
          comment: Ensure access to 1.1.1.1, 8.8.8.8 etc
          protocol: tcp udp
          destination-address: GOOGLE_DNS CLOUDFLARE_DNS LEVEL3_DNS
          destination-port: DNS
   - name: dmz-access-needed
     comment: |
        This policy encodes critical dependencies for the DMZ network
     owner: [email protected]
     egress-network: DMZ
     rules:
        - type: egress-critical-flow
          comment: Ensure DMZ servers can send telemetry into the protected SEC_LOGS network
          protocol: tcp udp
          destination-address: SEC_LOGS
          destination-port: HTTPS

ingress-deny

It asserts that a traffic flow can never be successfully delivered. Specifically, this rule looks for any possible way a packet could be successfully delivered within this class of traffic.

access-policy:
   - name: ingress-no-ssh
     comment: |
        This blanket policy asserts SSH access is denied for any traffic entering from the internet.
     owner: [email protected]
     ingress-network: RFC1918 DMZ
     rules:
        - type: ingress-deny
          comment: Ensure public SSH access is denied
          protocol: tcp udp
          enter-interface: EDGE_FROM_INTERNET
          destination-port: SSH

egress-deny

Identical to ingress-deny. Asserts that traffic flows from MALICIOUS_PUBLIC_IPS to RFC1918 can never be successfully delivered. Specifically, this rule looks for any possible way a packet could be successfully delivered within this class of traffic.

access-policy:
   - name: egress-malicious-nets
     comment: |
        This blanket policy asserts outbound access is denied to certain malicious networks.
     owner: [email protected]
     egress-network: RFC1918
     rules:
        - type: egress-deny
          comment: Ensure outbound access to malicious networks is not allowed
          protocol: tcp udp
          destination-address: MALICIOUS_PUBLIC_IPS

ingress-deny-others

This rule asserts that traffic can never be successfully delivered to the target network except for specific permitted flows. It looks for how a forbidden packet could be successfully delivered.

The optional ‘within’ field restricts the scope of the rule. Although the field is optional, almost all deny-others rules will need to be restricted by protocol. There are two reasons for this:

Not all IP protocols support ports. Rules that use destination-port or source-port must use ‘within’ to restrict the rule scope to IP protocols supporting ports (e.g., TCP, UDP). Many users are focused on TCP and UDP access policies and are not prepared to establish policies for other IP protocols. When reasoning about deny-others rules, it can be helpful to treat the rule as a boolean expression:

IF traffic matches the network section

AND traffic matches the ‘within’ section

AND traffic is NOT in the ‘deny-all-except’ list

THEN the traffic violates the rule.

access-policy:
   - name: dmz-ingress
     comment: example
     owner: [email protected]
     ingress-network: DMZ
     rules:
        - type: ingress-deny-others
          comment: Limit SSH access to only from bastion network
          within:
             - protocol: tcp
               destination-port: SSH
          deny-all-except:
             flows:
                - comment: Internal SSH access
                  source-address: BASTION
                  destination-port: SSH
                  protocol: tcp

egress-deny-others

Identical to ingress-deny-others. Asserts that traffic flows between egress-network and destination-address can never be successfully delivered to the target network except for specific permitted flows. This rule looks for how a forbidden packet could be successfully delivered.

See ingress-deny-others for more information.

access-policy:
  - name: client-egress
    comment: |
     This policy asserts that traffic entering the CLIENT_BORDER interfaces can reach
     only necessary resources on the network. It targets the CLIENT_BORDER interfaces
     directly to ensure the policy applies even to spoofed source addresses.
    owner: [email protected]
    egress-network:
      enter-interface: CLIENT_BORDER
    rules:
      - type: ingress-deny-others
        comment: Limit TCP/UDP access to DMZ network, external only
        within:
          - protocol: tcp udp
        deny-all-except:
          flows:
            - comment: Client - DMZ
              destination-address: DMZ
              destination-port: HTTP HTTPS SSH
            - comment: Client - NTP
              destination-address: NTP
              destination-port: NTP
            - comment: Client - DNS
              destination-address: DNS
              destination-port: DNS
            - comment: Client - External
              destination-exclude: RFC1918 DMZ

Access policy​

Example​

Schema​

Policy best practices​

Network schema​

Rule types​

Rules schema​

Rules best practices​

Flow schema​

Examples​

ingress-critical-flow​

egress-critical-flow​

ingress-deny​

egress-deny​

ingress-deny-others​

egress-deny-others​