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. |
AttemptNetworkConnectViaResponse | NetworkConnect is, in contrast to LocalConnect, making contact with this application via a connected Network or ConnectionRule object. |
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. |
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. |
SypplyChainAuditing | Blocks a supply chain attack by stating that applications/updates/libraries are reviewed before being deployed. |
Updated 4 months ago