Proposal: Mitre Att&ck Checker library for Falco Rules

[IceManGreen]

Motivation

The rules must be both syntactically and grammatically correct and should evaluate to true during successful end-to-end tests. Furthermore, it needs to accurately detect the intended cyber threats, specifically the Tactics, Techniques, and Procedures (TTPs), against the Mitre ATT&CK framework. Both the community and the Falco experts will benefit from the falco mitre checker module to audit the default rules or custom rules against the STIX2 data from Mitre CTI.

Feature

Develop a library to check the compliance of the Falco rules against the Mitre ATT&CK Framework. This library will provide to Falco experts and Falco users a way to check default and custom rules for Mitre ATT&CK extra tags.
The library will use STIX from the OASIS standards. Structured Threat Information Expression (STIX™) is a language and serialization format used to exchange cyber threat intelligence (CTI) :

• STIX CTI documentation

Leveraging STIX, the library will fetch the ATT&CK® STIX Data from MITRE ATT&CK repositories using the python-stix2 library implemented by OASIS:

• ATT&CK STIX Data repository
• Python STIX2 repository

The choice of a library is motivated by the packaging of a python code to integrate it into wider Falco implementations. More precisely, the library can be used :

• by the rules_overview_generator.py script
• Falco users and experts to check their falco rules files
• Other falco components that need to check the validity of rules files

Design Choice

To benefit from python-stix2, the library will be developed in Python 3.11 according to the last stable version released on this date.
The library should take as inputs one or more Falco rules files and run a validity checker implementation on each file.
The library could be named mitre_checker and could be located in the build directory :

.
├── build
    ├── checker
    ├── mitre_checker
    └── registry

The implementation consists in :

• Fetching the enterprise-matrix STIX2 data from the Mitre CTI repository
• load the data in memory
• load the falco rules in memory
• look for the falco rules that contains extra tags that concerns mitre information. These tags should contain mitre_<mitre-phase-name> (backward compatible) and/or <technique id> (backward compatible).
• verify the validity of the relation between the technique and the mitre phase if a <technique id> is detected in the extra tags.

Expected Output

The library should provide an in-memory report, in form of a model, which gather information about errors in the falco rules files that concern Mitre ATT&CK extra tags.
The report can be dumped to be stored on disk (optional).

Packaging

The library can be packaged in a wheel file in the first place. In this way, it could be pushed in public pypi repositories. Otherwise, a developper can easily install it in any python environment or build it again from scratch.

Extra packaging like a binary file or a container can be considered for further integrations.

Alternatives

Mitre ATT&CK framework is growing as a 'de facto' standard for TTPs knowledge and studies. I do not know another framework to consider it as an alternative.

Mitre CTI sharing chose STIX2 standard to maintain its Mitre ATT&CK data. A known alternative is OpenCTI but it has to be considered as a set of tools based on STIX2 rather than an alternative to STIX.

Additional context

This initiative was discussed from the issue #84, in wip: #76 and during discussions on slack.

[incertum]

Thanks a bunch @IceManGreen!

Initial feedback:

Python is a good and appropriate choice here for several reasons: (1) It is well-suited for small-scale Data Science projects like this one due to its strong libraries, (2) Python facilitates broad adoption and reusability among many adopters, making it easier for others to use, and (3) since it is not crucial for deployment purposes, there is no need for critical optimizations.

STIX2 data from Mitre CTI seems suitable from my perspective. Thanks for outlining alternatives considered.

Great implementation details! The high-level outline for the new Python module looks great, and we can provide further guidance during the PR review process. As suggested, please refactor and integrate the existing rules overview Python script into the new module. I can assist with the refactoring process since we are currently working on the new rules maturity and adoption framework

re packaging: Let's consider adopting an approach similar to https://github.com/falcosecurity/kernel-crawler to ensure consistency within The Falco Project. Let me think more about the best directory outline, as this repository serves multiple purposes. However, I don't believe we should create yet another repository.

re goals

verify the validity of the relation between the technique and the mitre phase if a is detected in the extra tags.

Can we outline stronger benefits?

For example, since the Mitre tags are manually added by experts, errors can occur. This module serves as a cross-check to ensure that we have tagged a rule with the best available Mitre Attack TTPs. Furthermore, it provides additional educational material for adopters.

---

@falcosecurity/rules-maintainers kindly asking for additional feedback. Are we moving forward with the proposed plan?

[IceManGreen]

Hello @incertum !

Can we outline stronger benefits?
For example, since the Mitre tags are manually added by experts, errors can occur. This module serves as a cross-check to ensure that we have tagged a rule with the best available Mitre Attack TTPs. Furthermore, it provides additional educational material for adopters.

This a very interesting and complex question.
@hkonduri and I talked about it on Slack and we think, like you, that the discussion should go further between all of us. Like he suggested on Slack we could, for example, base some rules conditions on Mitre ATT&CK datasources.

But it raises other questions like :

• Are we able to bind syscalls with Mitre ATT&CK datasources using Falco ? For exemple, for the datasource DS0014 Pod creation, are we able to link the proper syscalls to a pod creation ? If yes, how to cross-check the syscalls to the datasource too ?
• For the following Mitre ATT&CK datasources defined for T1610 Deploy Container:

"x_mitre_data_sources": [
        "Pod: Pod Modification",
        "Container: Container Creation",
        "Pod: Pod Creation",
        "Application Log: Application Log Content",
        "Container: Container Start"
      ]

are we sure that if we detect all the syscalls for all these datasources, we can consider that it is surely a event for T1610 ? How can we cross-check this ?

• If we consider that all the syscalls above are featuring a pod creation, should we modify the Falco rules conditions (or maybe macros ?) to also include the detection of the datasources to add the proper Mitre ATT&CK extra tags ?

What is your opinion about it ?
If anyone has hints or suggestions, please comment !

[incertum]

@IceManGreen 🤯 these are all excellent questions and great thinking btw!

I hope we get to a solution that would help us more automagically craft rules and link them to Mitre. As a first step, perhaps we can keep the immediate benefits more scoped?

Here are some additional thoughts:

• Initially we should continue tagging the rules manually to the best of our ability
• The checker you are proposing helps avoid some human mistakes
• In addition, I see tremendous educational value in such a tool as we could enhance the rules overview document with additional links and resource that may inspire adopters and subsequently we can improve the robustness of rules and ensure we have the right rules to detect xyz.

---

@falcosecurity/rules-maintainers kind bump to give everyone the opportunity to share their feedback.

@IceManGreen let's give it another week to allow for feedback, after that I would make the judgement call to get started if no one objects. I am fully supportive of this proposal and will help with the review process the best I can.

[poiana]

Issues go stale after 90d of inactivity.

Mark the issue as fresh with /remove-lifecycle stale.

Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Provide feedback via https://github.com/falcosecurity/community.

/lifecycle stale

[leogr]

/remove-lifecycle stale

[poiana]

Issues go stale after 90d of inactivity.

Mark the issue as fresh with /remove-lifecycle stale.

Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Provide feedback via https://github.com/falcosecurity/community.

/lifecycle stale

[poiana]

Stale issues rot after 30d of inactivity.

Mark the issue as fresh with /remove-lifecycle rotten.

Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Provide feedback via https://github.com/falcosecurity/community.

/lifecycle rotten

[leogr]

/remove-lifecycle stale
/remove-lifecycle rotten

We still want this. I apologize this is taking so long. Since we still have a few ongoing license discussions with the CNCF, we just want to be prudent before proceeding. That being said, I am still fully supportive of this proposal.

[poiana]

Issues go stale after 90d of inactivity.

Mark the issue as fresh with /remove-lifecycle stale.

Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Provide feedback via https://github.com/falcosecurity/community.

/lifecycle stale

[leogr]

/remove-lifecycle stale

[IceManGreen]

Related to #181 (merged).

The next step should involve the integration of the former implementation in a CI/CD job in order to validate (at least) the stable rules. Maybe even the incubating and sandbox ones ?

This proposal can be closed, or maybe kept alive to discuss about the CI/CD job ?

[incertum]

We can close this and maybe open a new one for the CI integration.

FYI I am back to having more available and we can start working on it if you want. I'll also check how else we can leverage the new module. Thank you!

[poiana]

Issues go stale after 90d of inactivity.

Mark the issue as fresh with /remove-lifecycle stale.

Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Provide feedback via https://github.com/falcosecurity/community.

/lifecycle stale

[leogr]

We can close this and maybe open a new one for the CI integration.

👍

/close

[poiana]

@leogr: Closing this issue.

In response to this:

We can close this and maybe open a new one for the CI integration.

👍

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.