search

Spyderisk / domain-network

Network domain model
Apache License 2.0
1 stars 0 forks source link

Inferred gateway routes need updating #6

Closed mike1813 closed 1 year ago

mike1813 commented 1 year ago

There are some serious defects in the network routing inference the current (v6a1-2) version:

Note that in a tethering connection (L1rGcL3), the gateway is a USB/Bluetooth device (e.g. phone), whose IP address on the L3 network becomes bound to an interface on the USB/Bluetooth host (e.g. a PC). This is not a NAT connection. The reverse path created by L3cGrL1 is not a ReverseTetheringSegment because that is created when the gateway is a USB/Bluetooth host, but it is not a TetheringSegment either. These types of gateway routes arise in different connections - they are not two directions of the same connection.

mike1813 commented 1 year ago

Related threats to logical segments (Sg.DA.. and Sg.TA..) and some Sg.A.. side effect threats also needed updating.

mike1813 commented 1 year ago

Getting this right involves a lot of moving parts, and needs checking using a threat path visualiser.

In addition to the points listed above, we need to decide which threats should apply to each type of gateway route. Then we must make sure the gateway route asset inheritance hierarchy is consistent with the threat patterns, so the right threats are generated in each case. Then (as noted above) we need to decide which controls apply to each type of gateway route and ensure that we have a control strategy for each threat affected by the controls (given the new hierarchy).

On the first point, it is unclear to me whether a tethered link would automatically provide some firewall protection (meaning that the FWBlock control should not apply, and neither should the threats addressed by this control).

With reverse tethering it looks like this is the case. The gateway retains its own IP address on the IP subnet, so messages sent to it are not automatically forwarded to the reverse tethered Bluetooth/USB link. The gateway acts like a NAT device. Its manager will need to set up a means to forward anything, e.g. by mapping the reverse tethered device to a port on the external IP interface.

With tethering it is less obvious. The gateway is something like a phone with a Bluetooth/USB link to (say) a notebook PC. Once tethered, the gateway device acts like a network interface on the PC, with an address on the IP subnet. Messages sent to the IP address would automatically be forwarded to the PC, making it possible to launch attacks on the PC. This is not a port-mapped service.

These attacks are repelled by placing a FWBlock control on the return path via the Bluetooth/USB gateway. But the gateway is acting as a network interface, so strictly it should leave traffic control to the host whose interface it is. It is at best unclear if the gateway would always automatically insert a FWBlock control so that only outbound connections were permitted by default.

For that reason, using the principle that we should overestimate not underestimate the risks, at least for now we should assume the route is 'open', the SPYDERISK system-modeller user to add the firewall control in their system model, if desired.

mike1813 commented 1 year ago

One other point about tethering. Suppose a device like a smart phone is tethered via Bluetooth/USB to a PC, and the phone is connected to a cellular network and a WiFi LAN. In this situation, messages could flow between the PC and the cellular network.

If the phone is also providing the WiFi (as a hotspot) it would act as a NAT gateway between the WiFi and the cellular network. However, if it is not providing the WiFi, it would not normally route messages between the WiFi and the cellular network. This restriction should be captured in the inference rules because without it, unrealistic threats (and threat paths) would be created.

mike1813 commented 1 year ago

Now addressed in branch 6-inferred-gateway-routes-need-updating.

However, tests suggest that now gateway routes are being generated correctly, there is no need for threats in which an attacker with control over a gateway can re-enabled routes that have been blocked by firewall policy controls. This is because the attacker can simply access the networks on either side of the gateway, and has no need to route through the gateway.

A further change should therefore be considered in which these threats are removed. Tests will then be needed to ensure that no type of route becomes immune from attack where this should not be the case.

mike1813 commented 1 year ago

The original issue is now addressed:

There remains the possibility that we could remove some threats involving attacker override. That requires some investigation of potential threat paths to ensure that only redundant paths would be eliminated, which should be covered separately.

Unfortunately, refactoring the threats related to tethering involved combining threats relating to host connections and client-service connections. The new threats created a circular dependency between the process communication and local connectivity submodels. The reason this happened is because the new threat URIs are encoded as network connectivity threats (though with local connectivity assets). The 'obvious' package assignment was to the local connectivity submodel making that depend also on process comms. However, the alternative assignment to the process comms submodel doesn't work either because that would become dependent on local connectivity, which is not what we want.

To get around this, some revision of the package assignments and interdependencies will be needed before the original issue can be closed.

mike1813 commented 1 year ago

The question of whether we can now delete some threats involving an attacker overriding a FW policy has been moved to a new issue #11. The rest of this issue having been addressed on branch https://github.com/SPYDERISK/domain-network/tree/6-inferred-gateway-routes-need-updating, it can now be closed.