Purpose

The Network object is representing network connectivity, like a VLAN. It is, strictly speaking, defining which applications are able to communicate with each other with no restrictions. It is not concerned about if the applications are on different network equipment or in different locations.

Connections

Application

An Application can be connected to a Network via NetworkExposure or ClientAccess.
Please see the Application section for more information.

RoutingFirewall

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.

Connecting a RoutingFirewall to a Network does not represent a router that is routing traffic to/from the Network. Such aspects are defined by the ConnectionRule objects connected to the Network.

Please see the ConnectionRule section for more information.

IDPS

An IDPS can be connected to a Network via NetworkExposure or ClientAccess like with RoutingFirewall as described above.

Connecting an IDPS to a Network does not represent NIDS functionality but instead administrative access to the IDPS solution.

Please see the paragraph "Network and NIDS functionality" under the IDPS section for more information.

ConnectionRule

A ConnectionRule can be connected to a Network using InNetworkConnection, OutNetworkConnection, NetworkConnection and DiodeNetworkConnection.

Please see the ConnectionRule section for more information.

Data

Connecting a Data object to a Network object (using DataInTransit) defines that the Data is traveling over the Network. For a traditional style unswitched network, like a hub, the Data is accessible if the attacker has access to the Network.

This is however dependent on if the Network object's defense property of EavesdropDefense is enabled or not or set to a probability.

868

For an unswitched Network, set the defense property EavesdropDefense of the Network to zero.

An other example of a Network where EavesdropDefense should not be enabled is wireless networks. In this case, all communication is possible to tap but the integrity is instead dependent on the quality (defense properties) of the Credentials object connected to the Data object representing the communication.

918

For WiFi communication, set the defense property EavesdropDefense of the Network to false and connect a Credential object to the Data object (representing the communication). The integrity of the communication is dependent on the defense properties of the Credential object.

Properties

AttackSteps

Attack step nameAttack step purpose
AccessBeing able to connect, and respond, to Applications connected via NetworkExposure and ClientAccess, respectively.
AccessNetworkDataBeing able to access Data objects connected via DataInTransit. Prerequisite to Eavesdrop.
BypassAccessControlIf access control is enabled for the network, i.e. login required, this attack step is for bypassing that obstacle.
BypassEavesdropProtectionIf EavesdropProtection, i.e. switching, is enabled, this attack step is for bypassing that.
BypassMitMProtectionIf EavesdropProtection, i.e. IpSec/StaticArpTables/DNSSec, is enabled, this attack step is for bypassing such functionality.
DenialOfServiceDenying the Network.
EavesdropListen to network traffic.
ManInTheMiddleRedirecting communication between two endpoints without them noticing, giving the possibility to alter the communication content.
NetworkForwardingBeing able to access the Network via ConnectionRules.
PhysicalAccessGaining physical access to a location where the Network is present and connectable.

Defenses

Defense nameDefense purpose
EavesdropDefenseThe network is configured to use Point-to-point communication. E.g. switching. For traditional non-switched hubs, WiFi and similar networks, set this defense to off.
ManInTheMiddleDefenseFor instance; static ARP tables, IPSec, DNSSec.
NetworkAccessControlAuthentication (network login) is required to access the network.