Open IceManGreen opened 1 year ago
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?
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 :
"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 ?
What is your opinion about it ? If anyone has hints or suggestions, please comment !
@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:
@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.
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
/remove-lifecycle stale
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
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
/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.
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
/remove-lifecycle stale
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 ?
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!
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) :
Leveraging STIX, the library will fetch the ATT&CK® STIX Data from MITRE ATT&CK repositories using the
python-stix2
library implemented by OASIS: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 :
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 namedmitre_checker
and could be located in thebuild
directory :The implementation consists in :
enterprise-matrix
STIX2 data from the Mitre CTI repositorymitre_<mitre-phase-name>
(backward compatible) and/or<technique id>
(backward compatible).<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.