falco rules mitre checker module

[IceManGreen]

What type of PR is this?

/kind feature

Any specific area of the project related to this PR?

/area rules

What this PR does / why we need it:

Provide a python module 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 module is motivated by the packaging of a python code to integrate it into wider Falco implementations. More precisely, the library can be used by :

• Falco users and experts to check their falco rules files
• Other falco components that need to check the validity of rules files

More details in proposal #88

[poiana]

Welcome @IceManGreen! It looks like this is your first PR to falcosecurity/rules 🎉

[incertum]

❤️ thank you @IceManGreen, please allow some time to allocate time for review as it's a complete new module that requires more thorough review and testing :) ETA maybe 1-2 weeks. Thank you again 🙏 !

[incertum]

re licensing

https://github.com/oasis-open/cti-python-stix2 -> BSD-3-Clause license is ok for CNCF projects
https://github.com/mitre-attack/attack-stix-data/blob/master/LICENSE.txt is a custom license.

CC @leogr what the implications are as cti-python-stix2 (ok license) is using the attack stix data (custom license).

[leogr]

CC @leogr what the implications are as cti-python-stix2 (ok license) is using the attack stix data (custom license).

Unfortunately, the custom license requires an explicit license exception approval by the CNCF. Is there no valid alternative?

[IceManGreen]

CC @leogr what the implications are as cti-python-stix2 (ok license) is using the attack stix data (custom license).

Unfortunately, the custom license requires an explicit license exception approval by the CNCF. Is there no valid alternative?

I am checking with the CNCF policies for potential licenses approvals.
The custom license seems quite permissive ("non-exclusive, royalty-free license to use ATT&CK® for research,
development, and commercial purposes"), so I do not think the that this terms could stop this PR on a legal basis.

Thanks a lot for highlighting this issue @incertum and @leogr, I am working on it.

EDIT: @leogr the repo under this license is actually used for the base knowledge, so it is used as data only in the mitre-checker module and not as a dependency. Do you know if it still has an incidence on the license approval for the PR ?

[leogr]

CC @leogr what the implications are as cti-python-stix2 (ok license) is using the attack stix data (custom license).

Unfortunately, the custom license requires an explicit license exception approval by the CNCF. Is there no valid alternative?

I am checking with the CNCF policies for potential licenses approvals. The custom license seems quite permissive ("non-exclusive, royalty-free license to use ATT&CK® for research, development, and commercial purposes"), so I do not think the that this terms could stop this PR on a legal basis.

Thanks a lot for highlighting this issue @incertum and @leogr, I am working on it.

EDIT: @leogr the repo under this license is actually used for the base knowledge, so it is used as data only in the mitre-checker module and not as a dependency. Do you know if it still has an incidence on the license approval for the PR ?

As per the common interpretation of the CNCF IP Policy, only those dependencies that are Apache 2.0 or in the Allowlist are automatically approved. All other licenses need an explicit license exception from the CNCF.

So, I guess, even if that dependency is data only, it might still be subject to this policy.

License issues have been a hot topic for the CNCF community in the last few months. We were license scanned multiple times and still, pending concerns, put the Falco Graduation on hold. We are working closely with the CNCF to overcome these issues. We are in an unfortunate situation, sorry.

So, even though I agree there's no legal restriction, on the other hand, the Falco project must adhere to CNCF Policies, so I think we have to wait a bit on this PR until we get more clarity on the whole situation. I really apologize for that, but it's something that we can't fully control. 😞

Anyway, I'll continuously monitor the situation and keep you posted. Also, once I find a bit of time, I will look deeper into this to see if there's any possible solution to unblock this shorty.

🙏

[IceManGreen]

I fully understand ! No worries.
I think that we are in the same boat for this PR, so I want to help.
In parallel, I asked for advice in a channel of the CNCF's slack, I'll keep you in touch.

[incertum]

Thanks @IceManGreen for proactively reaching out in the CNCF slack channel, please keep us in the loop. We will file a license exception after our currently pending kernel module request. Unfortunately, no ETA for the delay this will cause.

/hold

[IceManGreen]

Hello @incertum, @leogr,

I have some feedback from the CNCF Slack channel "maintainer-circle" about the license :

"Ultimately you're going to need to make a legal request for CNCF legal to take a look at this. [...] They're [Mitre ATT&CK] calling it Terms of Use, which means that you need to agree to it even if you're not copying the code. It's written as a copyright license, though, which is kind of weird. Copyright on data collections is a whole "fun" area of law. BTW, note that the terms of the license aren't actually problematic. It's just not an accredited OSS license, which means you'll be waiting for a while on a legal response.But you do need to talk to CNCF Legal about this."

So, it is like we expected :

• No problematic terms in the license
• We have to contact the CNCF Legal services to submit the licence

Do you have a contact with the CNCF Legal ? It should be faster than me contacting them in this case.

[incertum]

Hello @incertum, @leogr,

I have some feedback from the CNCF Slack channel "maintainer-circle" about the license :

"Ultimately you're going to need to make a legal request for CNCF legal to take a look at this. [...] They're [Mitre ATT&CK] calling it Terms of Use, which means that you need to agree to it even if you're not copying the code. It's written as a copyright license, though, which is kind of weird. Copyright on data collections is a whole "fun" area of law. BTW, note that the terms of the license aren't actually problematic. It's just not an accredited OSS license, which means you'll be waiting for a while on a legal response.But you do need to talk to CNCF Legal about this."

So, it is like we expected :

• No problematic terms in the license
• We have to contact the CNCF Legal services to submit the licence

Do you have a contact with the CNCF Legal ? It should be faster than me contacting them in this case.

Thanks @IceManGreen and here is our proposal:

Let's file the exception after we finish our current pending legal requests scheduled for the October 2023 CNCF legal meeting. We can start drafting it already.

[leogr]

Hello @incertum, @leogr,
I have some feedback from the CNCF Slack channel "maintainer-circle" about the license :
"Ultimately you're going to need to make a legal request for CNCF legal to take a look at this. [...] They're [Mitre ATT&CK] calling it Terms of Use, which means that you need to agree to it even if you're not copying the code. It's written as a copyright license, though, which is kind of weird. Copyright on data collections is a whole "fun" area of law. BTW, note that the terms of the license aren't actually problematic. It's just not an accredited OSS license, which means you'll be waiting for a while on a legal response.But you do need to talk to CNCF Legal about this."
So, it is like we expected :

• No problematic terms in the license
• We have to contact the CNCF Legal services to submit the licence

Do you have a contact with the CNCF Legal ? It should be faster than me contacting them in this case.

Thanks @IceManGreen and here is our proposal:

Let's file the exception after we finish our current pending legal requests scheduled for the October 2023 CNCF legal meeting. We can start drafting it already.

👍 and thank you!

Please make sure the request clearly states that we will only incorporate this into the project once we have the green light from the CNCF legal committee (and not before). This is important to avoid it becoming a blocker for the graduation process.

[incertum]

@IceManGreen just started reviewing a bit, overall it looks very carefully designed, amazing!

Our 2 pending legal requests are still open and we would like to continue holding this until they are approved in order to not block graduation. Thank you for your patience!

[IceManGreen]

Thanks @incertum !

In my turn, I recently had feedback from the Mitre ATT&CK stix-data maintainers :
mitre-attack/attack-stix-data#42
(@leogr FYI)

As they said, it is the first time they heard about the ATT&CK terms of use blocking a contribution to a CNCF project. But nothing seems to be really problematic for this PR.

I will probably push a minor modification to change the name of the module from falco_mitre_checker into falco_mitre_attack_checker. It will be more explicit and legit in the long term.

[leogr]

/assign

[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

[leogr]

Update:

The CNCF took so long to review and approve our pending license exceptions for us. But they are now all cleared, so we can proceed with this. Thank you for being so patient! 🙏

@IceManGreen

In my turn, I recently had feedback from the Mitre ATT&CK stix-data maintainers : mitre-attack/attack-stix-data#42 (@leogr FYI)

As they said, it is the first time they heard about the ATT&CK terms of use blocking a contribution to a CNCF project. But nothing seems to be really problematic for this PR.

Do we have evidence of other CNCF projects using miter-attack data? It would be relevant to submit the request.

Also, @IceManGreen and @incertum could you help me to list all 3rd-party deps in this PR that need a license exception?

[incertum]

yes @leogr we should get this kicked off now. I would really like to have clarity around the degree of dependencies, because the https://github.com/mitre-attack/attack-stix-data is a dependency of the dependency with ok license we aim to use, see my previous comment #181 (comment). @leogr what would you suggest we do to first to get clarity? Since the CNCF is now freezing for KubeCon, likely we won't be able to make progress until after KubeCon EU 24.

Great callout to check for other Mitre uses within CNCF projects 👀 .

[leogr]

I would really like to have clarity around the degree of dependencies, because the https://github.com/mitre-attack/attack-stix-data is a dependency of the dependency with ok license we aim to use, see my previous comment #181 (comment)

All dependencies used count, so basically, any license included here https://github.com/falcosecurity/rules/pull/181/files#diff-ebb0a6bba1b3e32ae5746afcca9406e4220f1a90d5d0cf0c107543188952efe7

@leogr what would you suggest we do to first to get clarity?
We have to ask the CNCF.

Based on our recent experience in this regard, I guess the main concern is if we distribute that not-allowed dependencies as part of our project. If I understood correctly, this will only run on the CI and will not be incorporated into our software distribution. If this is the case (please confirm), I think we may accept the risk of merging this and, in parallel, file an issue to the CNCF to clarify if our assumptions are valid. This way, we may save months.
Does it make sense?

[IceManGreen]

Hello @incertum and @leogr !

I agree with you, this experience with the Mitre ATT&CK license demonstrated that we should be careful with the 3rd-parties dependencies, at least about their licenses.

I confirm that this PR is dedicated to a CI/CD usage BUT I would suggest that we should still remain cautious.
My opinion is that we should consider using SBOM to bring the proof that the 3rd parties licenses are valid regarding the CNCF policy.

Do you know if one of the Falco repositories is using a framework to generate SPDX or CycloneDX SBOMs ?

[leogr]

Do you know if one of the Falco repositories is using a framework to generate SPDX or CycloneDX SBOMs ?

Not yet.
We have had just some discussions about that. cc @LucaGuerra

[IceManGreen]

Do you know if one of the Falco repositories is using a framework to generate SPDX or CycloneDX SBOMs ?

Not yet. We have had just some discussions about that. cc @LucaGuerra

I also add @Nicolas-Peiffer to the discussion.
He has a great experience with SBOMs.

[incertum]

Based on our recent experience in this regard, I guess the main concern is if we distribute that not-allowed dependencies as part of our project. If I understood correctly, this will only run on the CI and will not be incorporated into our software distribution. If this is the case (please confirm), I think we may accept the risk of merging this and, in parallel, file an issue to the CNCF to clarify if our assumptions are valid. This way, we may save months.
Does it make sense?

@leogr On board! @IceManGreen, re review: Overall it already looked pretty good to me, just need to test drive it once! Trying to do that by next week, it's a reminder on my calendar already.

[incertum]

@IceManGreen pulled the PR and ran it. All worked really nicely!

Just left a super minor comment and it could be nice to rebase anyways to see the current output with the current rules. I'll directly approve then!

In addition, I already created a ticket to track the subsequent CI integration #233 (likely after KubeCon EU 24).

Plus one more ticket to see how we can use this work to possibly augment the Rules Overview Doc #235.

[incertum]

/approve

Fantastic work @IceManGreen! @leogr I would propose to merge this first version, I don't see anything that would constitute a blocker for a v1. Once we start working on the CI integration and the other ticket I opened on possibly integrating this info with the information displayed in the Rules Overview doc we can expand the framework if needed. The README was clear, I could get it to work on the first try.

I'll leave it up to you @leogr to unhold, thanks!

[poiana]

LGTM label has been added.

Git tree hash: 7e8ef5627edc170a638d2939842fdad95e4ad399

[poiana]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: IceManGreen, incertum

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

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [incertum]

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

[leogr]

/approve

Fantastic work @IceManGreen! @leogr I would propose to merge this first version, I don't see anything that would constitute a blocker for a v1. Once we start working on the CI integration and the other ticket I opened on possibly integrating this info with the information displayed in the Rules Overview doc we can expand the framework if needed. The README was clear, I could get it to work on the first try.

I'll leave it up to you @leogr to unhold, thanks!

👍

/hold cancel