Open tailsec opened 1 year ago
hi @tailsec
What about this command line option:
-a APPLICABLE_TO, --applicable-to APPLICABLE_TO
specify which data source objects to include by filtering on applicable to value(s) (used to define the type of system). You can provide multiple
applicable to values with extra '-a/--applicable-to' arguments
This option is available in the CLI datasource mode. If you want to use a filter op applicable_to in detection/visibility mode, you can use EQL queries: https://github.com/rabobank-cdc/DeTTECT/wiki/EQL#filter-on-applicable_to
Thanks for the suggestion, I'll give the EQL a try!
I've been able to filter on those fields for the Detection, Visibility, and Data Source modes, so thanks for sharing those tips!
When it comes to Group layers, however, I'm not able to do the same as the Applicable_to field isn't a configurable option for this layer.
I know this isn't something that vendors will populate, but it would be useful where an organisation has multiple defined "Systems" and a threat group/campaign would impact a number of them. We could manually note which techniques would impact which system, which could then be used to filter visualisations to see which are most affected, etc.
Would it be possible to add the Applicable_to field to Group layers?
@tailsec
Indeed, group yaml files doesn't have the applicable_to field. applicable_to is designed for detections and visibility (and data sources) to indicate to which type of systems the detection/visibility score or data source it relates. This doesn't apply to attackers behaviour. An attacker can execute his behaviour on any type of system...
I think combining/overlaying the group yaml file to your detection coverage for example (or visibility) will address your need. Check-out the -o option in group mode.
I am using the Applicable_to field to delineate detection/visibility by system, e.g. DMZ, Workstations, etc., and while I understand what you mean by saying an attacker can execute their behaviour on any type of system - this isn't always the case.
For example an actor could use T1112: Modify Registry, but this won't work on Linux hosts because they don't have a registry to modify, and the same could be said for Cloud workloads and containers. In this case I could still mark it as applicable_to my DMZ Windows Servers and Corporate SOE systems, but not the others.
Another example where this could be useful is if you have specific hardening measures in place on certain systems that make specific techniques infeasible, but not on others.
Being able to filter Data Sources by the Applicable_to field is an essential feature for our use case, and while you can use the -p argument on the Visibility, Detection, and Group layers, it doesn't provide the same functionality as the Applicable_to field.
The Applicable_to field seems to be the only way I could possibly filter the layers, for example if I wanted to see Detections applicable to our Windows Workstations or TTPs used by a Group to target ESXi servers. There doesn't seem to be a commandline option to generate output using this, though. Please let me know if I've missed something here.