[WIP] update(rules): ehanced rules tagging for inventory / threat modeling

[incertum]

Signed-off-by: Melissa Kilby [email protected]

What type of PR is this?

Uncomment one (or more) /kind <> lines:

/kind bug

/kind cleanup

/kind design

/kind documentation

/kind failing-test

/kind feature

/kind release

If contributing rules or changes to rules, please make sure to also uncomment one of the following line:

/kind rule-update

/kind rule-create

Any specific area of the project related to this PR?

Uncomment one (or more) /area <> lines:

/area build

/area engine

/area rules

/area tests

/area proposals

/area CI

What this PR does / why we need it:

Proposing subtle changes in tagging rules for inventory and thread modeling purposes.

(1) Add Mitre TTP code(s) [1, 2] to rules under existing tags. Besides better inventory and threat modeling, this will allow us to quantify areas of improvements for Falco from a threat modeling perspective. Mitre TTP code(s) also provide end users less familiar with system level threats and exploitations with additional information.

(2) Adjust container and host tags usage.

container - The rule only works inside containers -> The rule works inside containers
host - The rule only works outside of containers -> The rule works outside of containers

Why not add host and/or container (either only one or both if applicable) to each rule? Could be more informative for inventory purposes when parsing and aggregating fields in the yaml to for example be able to know if certain threats are only addressed for container workloads or also on the underlying host etc.

(3) [Future Options]

While we do have the priority tag A case-insensitive representation of the severity of the event. sometimes wonder if additional tags around accuracy or scope of the rule could be useful for everyone in addition to existing tags.

"scope" - ["narrow", "medium", "broad", "unknown"] - Is this a more generic or extremely specific detection? For example does the rule only capture one way to elevate privileges or does the rule capture an entire class of vulnerabilities?
"accuracy" - ["low", "medium", "high", "unknown"] - While it depends on the actual workloads and environments, could some sort of FP ratio anticipation still be captured for the rules that are enabled by default? 

References:

[1] https://attack.mitre.org/tactics/enterprise/ [2] https://raw.githubusercontent.com/mitre/cti/master/enterprise-attack/enterprise-attack.json

Which issue(s) this PR fixes:

Fixes #

Special notes for your reviewer:

CC @leogr

Does this PR introduce a user-facing change?:

TBA

[poiana]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: incertum Once this PR has been reviewed and has the lgtm label, please assign mstemm for approval by writing /assign @mstemm in a comment. For more information see:The Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• rules/OWNERS

Approvers can indicate their approval by writing /approve in a comment Approvers can cancel approval by writing /approve cancel in a comment

[jasondellaluce]

/milestone 0.34.0

[darryk10]

Hi @incertum, I totally agre with tags container and host. In addition AFAIK you can also load rules based on tags so you may want to use the host ruleset and avoid the container rules. We might need to check and adjust the other rules but I find it really useful.

I do really like the "accuracy" tag idea. However it's hard to evaluate the FP ratio in advance and in reliable way since it's often based on "feeling" about the possible noise. However if we agree how to set this ratio, it would be a good way to split noisy rules from high confident security rules and enable them based on the use cases.

[incertum]

Hi @incertum, I totally agree with tags container and host. In addition AFAIK you can also load rules based on tags so you may want to use the host ruleset and avoid the container rules. We might need to check and adjust the other rules but I find it really useful.

Ok, for rules that work for both host and in a container, like this one https://github.com/falcosecurity/falco/pull/2167/files#diff-ea7e90b2fb13b5aa2c8e6799c1ea20612e8bd29a13c61dfb3653f03f0235436eR1738 confirming that it is ok to add both tags, host and container? That way yes you can filter for the host rules, including the ones that would also work in containers. I think that was the disconnect I brought up above that currently the tag host is only used for rules that work only on host, but not in a container which is not too intuitive to me. Also this way we can create nice summary aggregation tables showing number of rules for host and containers and more.

I do really like the "accuracy" tag idea. However it's hard to evaluate the FP ratio in advance and in reliable way since it's often based on "feeling" about the possible noise. However if we agree how to set this ratio, it would be a good way to split noisy rules from high confident security rules and enable them based on the use cases.

Agreed, if you have ideas on how to set these ratios, that would be cool. Even very imperfect ratios could help setting expectations for each rule.

[leogr]

cc @Kaizhe :hugs: