This pull request came about due to a bug where payloadInspection on a ConnectionRule would only propagate the restrictions to the attacker's actions to the Applications directly associated with it and not across other Networking assets.
The inspection discussed here refers to payload inspection of the traffic and not host/port-based filtering which is accounted for by the Restricted defence, instead.
The changes subsumed here separate all network connectivity in coreLang into two separate components:
Uninspected communications which do not impose any limitations on the attacker's activities.
Inspected communications which carry some limitations. Such as, preventing the attacker from exploiting SoftwareVulnerabilities, and limiting ReverseReach(which in turn is needed to maximise the impact of UnsafeUserActivity and prevent Extract on Data).
It is important that whenever the attacker is able to gain Uninspected networking reach to an asset that they are also flagged as having Inspected reach as well, otherwise some odd results might be produced.
This pull request came about due to a bug where
payloadInspectionon aConnectionRulewould only propagate the restrictions to the attacker's actions to theApplicationsdirectly associated with it and not across otherNetworkingassets.The inspection discussed here refers to payload inspection of the traffic and not host/port-based filtering which is accounted for by the
Restricteddefence, instead.The changes subsumed here separate all network connectivity in coreLang into two separate components:
SoftwareVulnerabilities, and limitingReverseReach(which in turn is needed to maximise the impact ofUnsafeUserActivityand preventExtractonData).It is important that whenever the attacker is able to gain Uninspected networking reach to an asset that they are also flagged as having Inspected reach as well, otherwise some odd results might be produced.