ConnectionRule

Purpose

The ConnectionRule object is representing connectivity or reachability. It can be used to define that applications and/or networks are allowed to communicate with each other. It is not required to detail by what means this communication is possible since, from an attacker's perspective, this might not be obvious once the connectivity is discovered. Also, from an architect's perspective, during the design phase, the only known fact might be that a certain application will require comminucation with an other application or network.

Below is a list of artifacts that a ConnectionRule can represent;

• Firewall policies (firewall configuration used as input).
• Confirmed communication (traffic meta-data like tcpdump and similar).
• Required communication/dataflows defined in system architecture maps.
• Speculative connectivity (scenarios like "What if this network has external connectivity?").
• Air-gap resilience (scenarios like "This area of the architecture is air-gapped but what if someone brings a maintenance laptop every 6 months?")

Connections

Directionality

When connecting ConnectionRule object, the directionality is essential. This is decided by selecting between "In" and "Out" type of connections between two objects. The concept In/Out shall be seen from the Application's or the Network's perspective. Therefore, an InApplicationConnection or an InNetworkConnection states that the ConnectionRule is allowing incoming communication to that Application or Network, and vice versa.

The In/Out are only refering to the initiation of the allowed communication. Once the communication is established, it is considered bidirectional.

Application

Connecting a ConenctionRule object to an Application object is defining allowed communication related to it. In other words, defining specific reacability. Available options are InApplicationConnection for allowing incoming requests, OutApplicationConnection for allowing outgoing requests and ApplicationConnection for defining both incoming and outgoing requests as allowed to the very same application.

Using an InApplicationConnection will make an application act as a service and using an OutApplicationConnection will make it act as a client application.

The "in" and "out" labels only refer to the reachability and the initiation of the requests. Once an incoming request has been made, the connection is considered bidirectional.

IDPS

Since the IDPS object is inheriting from the Application (IDPS is an application object with additional features), it can also be connected to a Connection rule in the same way as an Application object can. This is however not relating to the protection of a dataflow by an IDPS, but rather which applications and networks can communicate with the IDPS application's admin interface.

Network

Connecting a ConnectionRule object to a Network object is defining that the Network or Application in "the other end" of the ConnectionRule is allowed to communicate from and/or to any Application connected with NetworkExposure to the Network.
####Network to Network

Application to Network

ConnectionRules can also be used to define communication between specific applications and Networks. The following is an example of how to, in the simplest form, model a VPN connection.

N.B: Often, it is desirable to model VPN functionality in a more granular way. The example above is representing an already present/connected/static VPN connection which means that if you compromise the "NW Clients on AdminMachine", you also have access to anything that is reachable via the ConnectionRule. In order to also model the security aspects of the VPN solution itself (authentication, update status, from where can you connect to it and so on), it should be represented by an Application with NetworkExposure to the networks where connecting to the VPN is allowed. However, those attack scenarios are slightly different; one is about making use of the connectivity the VPN brings and the other is about abusing the VPN implementation itself.

It is not required to detail (or know) technically how one network can make contact with an other application or network. It is, from a threat modeling perspective, enough to state that it is possible.

Data Diode

A data diode is a relatively rare piece of equipment that is network-wise only allowing packets to travel in one direction. No ACK packers are allowed to reach back to the originating network. (This is sometimes implemented using fiber equipment where the the receive channel in the fiber pair is just terminated.) I.e. responses (and thus response attacks) are electronically not possible.

Data diodes can be configured to only allow packets to go in to or out from a protected network depending on if confidentiality or integrity is most important.

RoutingFirewall

In a coreLang threat model, a RoutingFirewall object is not representing a device that forwards or drop actual communication. Instead, it is an object that ties firewall rules (ConnectionRules) together with the administration of them.

In the example below, the three rules at the top are managed by the RoutingFirewall while the lower ConnectionRule defines from where you need to connect in order to connect to the firewall itself, to do administration.

If the RoutingFirewall, as such, is compromised, any ConnectionRule connected to it will also be possible to compromise/edit.

In order to compromise the firewall, it is necessary to connect to (the administration interface of) it which can only be done over a ConenctionRule connected with InApplicationConnection.

In the example above, the actual Applications and Networks that rules 4711-4713 allow communication between are not shown.

Traffic Filtering

The aspect of traffic filtering is represented as a defense property of a ConnectionRule. It is described under defenses below, but it is worth highlighting here.

When a map, architecture or configuration is set up to do traffic inspection of a dataflow or communication path, this is reflected in the PayloadInspection defense of the ConnectionRule. This means that trivial or off-the-shelf payloads are expected to be discovered and will not be successful on the target Application.

The use of a Web Application Firewall, is a functionality that would render setting the PayloadInspection defense to on.

It is also possible to set this defense to a probability in order to represent the expected efficiency of the traffic filtering.

Properties

AttackSteps

Defenses