andrewbwm
commented
2 years ago Maybe instead of making the assumption that a user can expose itself to an attacker somehow if they are careless maybe we should create a reverse reach concept. This would start from the attacker and go through all the networking/application assets to see from where the attacker could be reached by the user.
This has been implemented in 190d525fd35cc61983f2a269032176a63def376e.
The old filtered defence on the ConnectionRule made use of the automatic vulnerabilities which no longer exist.
This new version makes it so that vulnerabilities are not triggered and their network access requirements are not fulfilled when the attacker gains access to a filtered ConnectionRule.
The issue is that filtered defence is described as preventing malicious payloads on the connection in general. These deleterious data can also come via the unsafe actions of the user, the current implementation does not account for that. If we wish to remediate this issue we will need to have the unsafe action follow the ConnectionRules to see if any of them are filtered. This solution also comes with its own sets of problematic assumptions as we do not know which ConnectionRules lead to the potential attackers.
This conversation is also somewhat related to the potential viability of an Intrusion Detection and Prevention System(IDPS) asset #47.