mike1813
commented
3 days ago The best approach to addressing this issue is to first clarify what it means when a cellular network asset is included in a system model.
A cellular network asset can be used as an abstraction representing a complex set of implementing routers and subnets. These cellular network infrastructure assets are inferred to exist if not asserted. In a private cellular network, the backbone router must be asserted so the external connections are specified (even if there are none), but the backbone network, base stations and radio access networks can still be inferred. In a public cellular network, the entire infrastructure can be inferred, and is assumed to have an external connection to the Internet.
For a public cellular network, any inferred infrastructure is assumed provided by someone outside the modelled system, who is responsible for its physical security. To achieve this, some threats must be suppressed. This is done by appropriate classification of inferred assets and/or leaving out some of their relationships. However, asserted public cellular network infrastructure assets, and any private cellular network infrastructure assets (even if inferred) are assumed to be part of the modelled system. Physical security for those assets must be modelled by using controls.
For network security, the default assumption is that the provider of a public cellular network does not trust its users. Anybody may subscribe and access the network, so the provider imposes connection routing restrictions that limit their opportunity to attack either the network or its other users. However, for a private cellular network the default assumption is that the provider does trust the users, so connection routing restrictions must be modelled by using controls.
In most situations it is not possible to run a service on a device connected to a cellular network. This is because such devices have private IP addresses within the cellular network, which have no meaning outside the cellular network.
Given this, logical segments for routes through a gateway into and out of the cellular network, and between the backhaul network and cells in the cellular network are created using subclasses that embody restrictions on what connections can be made. This ensures that system modeller users don't need to go in and add a lot of controls representing firewall policies on these routes for threats that can't happen.
However, the assumption is that the base stations and backhaul router devices do not allow connection forwarding rules to be set up. Such rules can be used to provide a proxy on a gateway for a service on a LAN inside the gateway, allowing such a service to be accessed from outside the gateway.
It is reasonable (at least at the present time) to assume that a public cellular network operator will not provide connection forwarding as part of their service. To do so may create security problems and would impose operational constraints, so they just don't do this. Indeed, the assumption used is that one cannot connect to mobile devices from outside the cell they are in, let alone outside the cellular network.
It is not so reasonable to assume that connection forwarding rules could not be set up within a private cellular network. This assumption is currently used (the same construction patterns are used for all cellular networks), but may need to be changed.
See also issue #151, which describes a different bug in the cellular network construction pattern sequence. It may make sense to address both these issues in a single set of changes.