Extensions needed for project TELEMETRY

[mike1813]

According to @panositi, the EU project TELEMETRY has a use case that requires some elaboration in the models of software processes and control of router functions. The requirements are:

1. A mechanism for relating a Process to Data assets that represent the software code executed by that process.
2. A mechanism for describing internal library dependencies within a Process, either by creating relationships between Data assets representing the code, or by allowing subprocesses representing called libraries to be modelled explicitly.
3. A way to model the relationship between routing functions of a Host (already modelled as Interface and LogicalSegment assets) and processes running on that Host.

These extensions will add complexity, so ideally they should be introduced as optional sub-models.

[mike1813]

Tackled item (3) first, because that's the most important in terms of modelling the TELEMETRY scenario. That requires a way to model routing function dependencies. The code as data and library dependency aspects are only a way to simplify the mapping between code vulnerabilities and other compromises and the processes (and their privileges) running on the router.

First step extended the range of the 'controls' relationship so a Process can control a routing function (an Interface or Logical Segment) on its Host. To complete the model, threats were added whereby if the Process is compromised, any security policy applying to the routing function will be overturned.

A change was also needed in a network connectivity construction patterns that add a a self-referential link to Logical Paths and Path Segments that follow a return path via a NAT router or equivalent. This link signifies that unsolicited connections cannot be made via the segment, due to the fact that the target address on the destination subnet has no meaning on the source subnet. If IPv6 is used, the target address would have meaning to the attacker, but most IPv6 routers would implement the same restriction as a default policy.

The self-referential link is then used to exclude the Segment (or Path through such a Segment) from threats involving unsolicited connections. However, if the Segment is controlled by a Process, the NAT (or equivalent policy) can itself be threatened by taking control of the Process. The construction pattern should therefore not be triggered if the Segment has a controlling Process, because if the self-referential link is generated, those threats could never apply. That being the case, the FWBlock control should apply to a DeNATSegment (the return path via a NAT router), as without the self-referential link it is assumed that unsolicited connections would be permitted by default.

This arrangement is slightly inefficient, because it leads to some threats being generated for return paths and segments even though there is no controlling process. It would be possible to fix this, but only by replacing most of package#NetworkConnectivity, so for now the inefficiency has been accepted for the sake of expediency.

[mike1813]

Another concern is that users will want to include processes like netfilter, dhcp or dns in their models to control routing functions. However, a router is assumed to be a specialised device, unable to run arbitrary application processes. Adding such a process to represent (say) netfilter leads to a spurious modelling error. The error is spurious in the sense that

• having a process running on a router for this purpose should not be considered an error, and
• the fact that the error is generated does not mean other threats are missed.

The model is in fact valid, but the modelling error claims it is not.

To get around this, a new 'system process' subclass is needed for these types of processes, which (unlike an application process) can run on any device. Arguably, such a process should only control other processes, networks or hosts, and should not process data except configuration data.

This leads to the idea that we also need a Process-configuredBy-Data, which could be a subcase of Process-reads-Data, but expressing the case where the data is configuration data that controls the behaviour of the process. We could then insert a modelling error to say a system process cannot process data unless it is configured by it (triggered if Process-processes-Data exists but Process-configuredBy-Data does not).

The Process-configuredBy-Data relationship would then signify that

• the Process reads the data (directly from its Host, via a DataFlow from some other Process, or from an interactive user)
• the Process becomes unreliable if the data is corrupt (has Loss of Integrity)
• the Process becomes unavailable if the data is not available (has Loss of Availability)
• the Process behaviour can be subverted if the data is forged by a malicious party (has Loss of Authenticity), even if the malicious data does not exploit a software vulnerability

Note that if a Process only 'reads' or 'receives' data, Loss of Authenticity only makes the Process unreliable (the same as Loss of Integrity which may signify accidental corruption). The malicious data can only subvert a process by exploiting a vulnerability if it is not configuration data.

[mike1813]

Added the new 'System Process' as a subclass of 'Simple Process', and the new 'configuredBy' relationship, plus threats whereby configuration data read by a process affects the behaviour of the process.

At this stage, no restrictions on them have been encoded in the form of modelling error threats. A system modeller user who gets a modelling error due to an 'Application Process' running on a simple host will now be able to fix the error by changing the Application Process to a System Process. This means it is now possible to insert kernel processes controlling interfaces and routing, plus a web interface and back-end processes to modify their configuration data, without getting modelling errors caused by application processes running on a specialised host.

Also cleaned up some of the package#NetworkConnectivity threats affecting Interfaces and Logical Segments. Some of their entry points were previously overlooked, and one of the original threats had not been generalised to include DeNATSegments as should have been the case.

[mike1813]

Consideration of the TELEMETRY application scenario indicates that we should try to find a way to distinguish between two control functions:

• controlling access to a subnet, which in an IPv4 subnet is normally handled by DHCPD, which may in turn use an authentication service
• enabling routing within a subnet, which is normally handled by DNS as well as by the router kernel

In the current TELEMETRY test case, these two processes (DHCPD and DNS) are not distinguished. It may make sense to introduce a second relationship something like 'controlsAddressing' to a subnet from its local DNS service. For a private subnet this would normally be a process running on a host directly connected to the subnet, because only it would know how to resolve hostnames on that subnet, although the DNS need not be running on the router itself.

This has not been added yet, because it may interact with the idea of using a loopback LogicalSegment to represent routing within a subnet, as discussed in #159. Further analysis is needed to determine whether it makes sense to pursue both these ideas, and whether either depends on the other.