RoutingFirewall

Purpose

The RoutingFirewall object is representing the routing firewall itself rather than the packet forwarding and filtering functionality it provides. In other words, it is representing the management, access and vulnerability aspects of a firewall.

Therefore, connecting a Network to a RoutingFirewall does not represent traffic forwarding. This is instead defined by connecting ConnectionRule objects between Network objects that are allowed to communicate. For more information on this, please see the ConnectionRule section.

Connections

Application

Technically, a RoutingFirewall is regarded as an Application with packet forwarding capabilities. Therefore, the RoutingFirewall object inherits all properties of the Applciation type of modeling object.

An Application can be connected to a RoutingFirewall in the same way as an Application can be connected to an other Application, i.e. in a parent or child relationship.

Please see the Application section for more information.

Network

A RoutingFirewall can be connected to Network via NetworkExposure or ClientAccess since it is a derivative of Application. This is representing the possibility to connect to the RoutingFirewall itself (for administration purposes) from the Network.

Please see the Network section for more information.

IDPS

When connecting an IDPS to a RoutingFirewall object using a parent/child type of connection, it represents that the RoutingFirewall is also hosting an application or plugin/module with IDPS functionality. It can also be connected using the ManagedBy or AppProtection which represents that the RoutingFirewall is managing the IDPS functionality or that the IDPS is protecting the RoutingFirewall by filtering incoming connections to the RoutingFirewall's management interface, looking for well known malicious signatures/payloads.

Please see the IDPS section for more information.

ConnectionRule

A ConnectionRule can be connected to a RoutingFirewall InApplicationConnection, OutApplicationConnection, ApplicationConnection and ConnectionRule. The application-related connections is defining connectivity to the RoutingFirewall itself (administrative access) and the ConnectionRule connection defines which connection rules are managed by this particular RoutingFirewall.

In other words, if the RoutingFirewall gets compromised, all ConnectionRule objects (connected via the ConnectyionRule link) are also compromised.

Please see the ConnectionRule section for more information.

Data

Please see the Application section.

Identity

Please see the Application section.

SoftwareProduct

Please see the Application section.

SoftwareVulnerability

Please see the Application section.

System

A connection to a System object defines which hardware the RoutingFirewall is running on. N.b; RoutingFirewalls can also be routing functionality entirely in software. In such cases, the RoutingFirewall should be connected as a child application to the Application (operating system) hosting it.

Properties

AttackSteps

Attack step name	Attack step purpose
AccessNetworkAndConnections	Once access is gained to an Application, you will also have access to any Network or ConnectionRule object it is connected to.
AttemptLocalConnectViaResponse	LocalConnect is, in contrast to NetworkConnect, making contact with this application from a connected/local child or parent application. "ViaResponse" means that this application does not respond to connections, i.e. it is behaving like a client and the attacker need to wait for a session. "Attempt" means that this attack step is before the LocalConnectViaResponse (successful) attack step.
AttemptNetworkConnectViaResponse	NetworkConnect is, in contrast to LocalConnect, making contact with this application via a connected Network or ConnectionRule object. "ViaResponse" means that this application does not respond to connections, i.e. it is behaving like a client and the attacker need to wait for a session. "Attempt" means that this attack step is before the NetworkConnectViaResponse (successful) attack step.
AttemptReverseReach	ReverseReach ispresenting the probability of successfully achieveing a "call home" situation where the Application makes a call back to the Attacker, i.e. the Attacker's starting point in the model. "Attempt" means that this attack step is a prerequisite to the (hidden) ReverseReach attack step which in turn lead to SpecificAccess or FullAccess.
AttemptUseVulnerability	AttemptUseVulnerability is a prerequisite to succeeding with SpecificAccess or FullAcces via a vulnerability.
Authenticate	Gaining SpecificAccess or FullAccess via known, stolen or guessed Credentials.
DenialOfService	Denial of Service with respect to the RoutingFirewall Application itself and its related ConnectionRule objects.
Deny	Denial of Service with respect to the RoutingFirewall Application itself.
FullAccess	Succeeding with superuser access.
LocalConnect	LocalConnect is, in contrast to NetworkConnect, making contact with this application from a connected/local child or parent application.
Modify	Altering the Application. Depending on the vulnerability, or if a SoftwareProduct origin has been compromised, the Application might be possible to alter. E.g. adding your own payloads and change application behavior.
NetworkConnect	Making a connection to the application via network. (Via connected Netowrk or ConnectionRule objects allowing connectivity.)
NetworkConnectViaResponse	Making a connection to the application via network. (Via connected Netowrk or ConnectionRule objects allowing connectivity.) However, this case is for when the Application acts as as a client application and the attacker has to rely on user interaction or callback sessions being initiated.
Read	Reading the application code and data.
SpecificAccess	Gaining limited access to the application by using credentials.
SpecificAccessAuthenticate	Succeeding with convincing a user to help with a connection back to the attacker. Some vulnerabilities require user interaction.
UnsafeActivityByUser	Succeeding with convincing a user to help with a connection back to the attacker. Some vulnerabilities require user interaction.

Defenses

Defense name	Defense purpose
Disabled	Defines whether the Application exists or not. This is useful from a threat modeling perspective when information about application presence is not known. It can also be used to state that for instance "20% of the servers represented by this application has RDP enabled". It can also be used to represent services that are temporarily enabled, or enabled on schedule.
SypplyChainAuditing	Blocks a supply chain attack by stating that applications/updates/libraries are reviewed before being deployed.