Skip to main content

Invariant

Invariant is a network analysis platform which can validate network configurations against user-provided rules within a fast, highly scalable, cross-vendor digital twin. Its primary function is to identify network and access control issues - connectivity loss and unwanted security gaps - preventing issues with a wide variety of root causes. It can also receive scheduled scans of the live network and generate incident alerts with attached virtual traceroutes and virtual route table diffs demonstrating the issue. As a secondary function, ad-hoc rules can be tested against the digital twin, allowing Invariant to function as a powerful security research tool, or permitting instant yes/no connectivity tests and virtual traceroutes. It also supports AWS.

info

Try it now - follow the Get Started guide and tutorial to try Invariant against an example enterprise network.

How It Works​

Invariant does not need direct access to your network of routers and switches. The digital twin operates entirely on the network configuration files, building up simulated devices, protocol sessions, route tables, protocol-based routing and ACLs. Because it functions on configuration files only, you can use Invariant to explore detailed "what-if" scenarios through direct configuration file modification. Any passwords or secrets present in your network configuration files are deleted before Invariant can view them.

Invariant provides a rich web-based user interface showing automatically laid out network maps for all current and archived network snapshots. The UI can display virtual traceroutes and is especially useful in visually understanding failures and investigating issue root causes. Individual accounts, SSO, domain-level restrictions, and other advanced security settings are available for controlling access to the UI.

Invariant is designed to be easy to automate and easy to integrate in existing network change management workflows. It does not presuppose any specific release workflow. In the very simplest arrangement, you can directly collect and evaluate your network configs directly using the Python client. In more advanced configurations, you can integrate it with continuous pre-flight evaluation through Jenkins or Github Actions, automatically fetch configs using LibreNMS / Netmiko, import network names from Aerleon, Capirca, or IPAM, and send events to SIEM.

Invariant also maintains searchable archives of network snapshots. You can scan these archived snapshots to determine when configuration changes were made, when incidents were introduced and resolved, and so on. Because ad-hoc rules can be tested against archived snapshot, you can perform retroactive validation to determine the behavior of the network in the past, or assess past compliance with new rules.

Big Picture​

The Invariant vision is to transform network management into a more predictable, reliable, and secure process. By enabling both the primary network team and internal stakeholders to understand the full impact of changes and prevent problems through a command-line validation tool, UI, and automated validation, Invariant aims to free up network teams from firefighting, allowing them to focus on strategic initiatives and innovation. Whether you are an engineer simply opening access in an AWS Security Group or an experienced network professional performing BGP or ACL changes, Invariant can help.

Overview Drawing

A mature integration of Invariant might look something like this:

  • Your process for making a change to the network always includes an Invariant evaluation of the planned changes. You use some kind of automation tool, like the provided Jenkins task, to automatically evaluate planned changes in Invariant.
    • If you support self-service network security changes, Invariant can be part of the approval process.
    • Virtual route table diffs are automatically generated for all network devices and all VRFs.
  • The Invariant Sync Agent (running in your network) regularly runs ‘SHOW RUNNING CONFIG’ or similar on network devices, removes secrets, and submits the configs for analysis.
    • Alerts are generated if any incident is detected. Alerts have pre-computed traceroutes attached which can be viewed in the UI.
    • The up-to-date network snapshot in the UI can be used by incident response, internal stakeholders investigating a service incident, compliance stakeholders, and security researchers.
    • Virtual network data is available as a service to internal stakeholders as a service.
  • Labor-intensive network security tasks, such as PCI compliance audit, ACL audit and cleanup, and incident root cause analysis can be assisted by Invariant.
  • Any users who use LLM tools to understand how a network config or ACL would behave can include virtual route tables and other computed information from Invariant in the LLM context to improve the accuracy and performance of the tool. You can also connect the authenticated try-rule API as a resource which LLM tools can invoke to get accurate answers to specific connectivity or security questions.

Core Functions​

Invariant's capabilities are centered around its digital twin technology, rule-based validation, pre-flight checking, and detailed virtual traceroutes.

Network Model​

Invariant creates a highly scalable digital twin from your network configuration files. This digital model serves as the foundation for all subsequent validation and analysis processes. The model can be hibernated in a fraction of a second, so the model consumes no standing compute resources. The model is highly effective in representing complex routing scenarios, including BGP and OSPF, as well as Network Address Translation (NAT), policy-based routing (PBR), Virtual Private Networks (VPNs), and Access Control Lists (ACLs). It is designed to scale to networks comprising thousands of devices.

Invariant has been tested against real, complex production networks. We maintain a repository of example network snapshots here.

Learn more about the model here.

Validation Rules​

Validation rules come in two basic flavors: connectivity requirements for traffic that must always be deliverable, and security requirements for traffic that should never be deliverable. You can write them as YAML files or edit them visually in the UI.

Example: Connectivity Requirements​

To write a basic rule, start by describing the kind of traffic in question: DNS connectivity to well-known public DNS providers.

protocol: TCP UDP
destination-address: GOOGLE_DNS CLOUDFLARE_DNS LEVEL3_DNS
destination-port: DNS

Note: if you have used Aerleon or Capirca to create cross-vendor ACLs, this is the same format! You can generally copy between Aerleon ACL terms and Invariant rules. You can load your Aerleon or Capirca network and service definitions into Invariant as well.

Now turn that into an Invariant rule by wrapping it in this structure. We have set the rule type to “egress-critical-flow” which tells Invariant to confirm that key internal networks (“DMZ”, “CLIENT_VLANS”) can reach those providers (or more specifically, exit our network towards the internet in the direction of those providers).

access-policy:
  - name: basic-dns-egress
    egress-network: DMZ CLIENT_VLANS
    rules:
      - type: egress-critical-flow
        protocol: TCP UDP
        destination-address: GOOGLE_DNS CLOUDFLARE_DNS LEVEL3_DNS
        destination-port: DNS

Above we used names to specify IP address ranges. IP addresses and CIDRs are also acceptable.

# Alternatively, IP addresses can be used directly
destination-address: 8.8.8.8 8.8.4.4 1.1.1.1 1.0.0.1 209.244.0.3 209.244.0.4

# CIDR
egress-network: 195.1.1.160/27 195.1.1.192/26 192.172.0.0/14

Notice that we did not explicitly tell Invariant where these virtual packets should originate in our rule. Invariant performs logical start location inference to locate interfaces and devices which would realistically be able to originate the traffic based on source address. You can always directly control the start location for a rule directly, which leads to the next example: verifying the security configuration for a key VLAN.

Example: Security Requirements​

In the next example we want to create a security rule which asserts that the DMZ is fully locked down to ingress traffic except what’s specified here. Invariant will search the network for counter-examples. Start with the allowed traffic:

# Traffic entering from the internet should be able to reach HTTPS services in the DMZ
- start-location: EDGE_TO_INTERNET
  destination-port: HTTPS
  protocol: TCP UDP

# Our internal BASTION network needs SSH, HTTP, HTTPS, and POSTGRESQL access
- source-address: BASTION
  destination-port: SSH
  protocol: TCP
- source-address: BASTION
  destination-port: HTTP HTTPS POSTGRESQL
  protocol: TCP UDP

Now turn that into an Invariant rule by wrapping it in this structure. We have set the rule type to “ingress-deny-others” which tells Invariant to search for any counter-examples to the rule, unwanted traffic which can reach the DMZ hosts.

invariant/policy/dmz-spec.yaml
  - name: dmz-ingress-spec
    ingress-network:
      destination-address: DMZ
      destination-exclude: DMZ_GATEWAY
    rules:
      - type: ingress-deny-others
        within:
          - protocol: TCP UDP
        deny-all-except:
            flows:
                - source-address: BASTION
                  destination-port: SSH
                  protocol: TCP
                - start-location: EDGE_TO_INTERNET
                  destination-port: HTTPS
                  protocol: TCP UDP

Note that we did something a little advanced in the ingress-network section: instead of just setting the ingress-network to DMZ, we excluded the DMZ_GATEWAY interface, with the objective of avoiding false positives for traffic deliverable directly to the gateway, because some of the enforcement is performed on the southbound outbound ACLs on the DMZ gateway.

Example: Vulnerability Discovery​

This example is from the article Discovering Network Vulnerabilities with Invariant.

Suppose we are aware of a recently announced exploit related to IPP traffic over UDP. The exploit specifically applies to printers. Suppose we have deployed an ACL change to reject IPP/udp going forward. Let’s use a scan to verify that our enforcement is effective.

    ingress-network: PRINT_SERVER
    rules:
      - type: ingress-deny
        comment: Check that CVE-2024-47176 is denied to our print server.
        destination-port: IPP
        protocol: udp

Invariant evaluates user rules in the context of the digital twin model. A key aspect of Invariant rule evaluation is its exhaustive nature; rules are designed to search comprehensively within potentially large ranges of network packets and origination points. This exhaustive validation provides a significantly higher degree of assurance compared to manual testing or random sampling, which are error-prone and cannot cover all possible traffic permutations.

Deployment Model​

Invariant uses a client-server architecture. The client runs on your local machine or automation server (a convenience automation agent is also available for Docker or Kubernetes). If you do use the client to collect network configs, any credentials used remain on your machine and are never shared with the Invariant server. The Invariant client automatically removes all passwords or secrets present in your network configuration files before sending them to the server.

Invariant runs cloud-hosted analysis servers and the UI portal at https://invariant.tech. This is where the digital twin network is created and analyzed quickly. The cloud service uses state of the art encryption and environment isolation techniques to keep your data private and secure. Invariant staff cannot view your data except through special disaster recovery accounts secured with physical tokens. If fully on-premise data retention is a requirement, please get in touch through slack or email. In any case, the analysis servers never have any access to your network and it is not possible to store network credentials there.

Basic accounts can use Invariant for free with effectively no usage limits. Higher tier accounts are available which unlock SSO, access to the highest possible device count (up to hundreds or thousands of devices), and early access to upcoming preview features.