-
Notifications
You must be signed in to change notification settings - Fork 219
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clarify some threat model assumption when Falco is deployed in a K8s cluster #832
Comments
Issues go stale after 90d of inactivity. Mark the issue as fresh with Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with Provide feedback via https://github.com/falcosecurity/community. /lifecycle stale |
/remove-lifecycle stale |
I agree that improving the documentation on "users" and privileges in the cloud ecosystem is crucial. It is important to provide a clear distinction between Linux and audit users, including elaborating on the concept of sometimes users representing individuals with interactive access. Furthermore, yes it would be beneficial to clarify the meaning of "root" in the context of effective Linux capabilities and privileges, emphasizing the potential damage that could occur if such a user were compromised. Lastly, while the quoted statement may hold true statistically, it does not necessarily encompass a generic threat model or reflect what each organization truly values. Ultimately, the focus should be on identifying and protecting the specific "crown jewels" of your organization, which can vary greatly from one organization to another.
Kindly asking to clarify this? Disabling Falco may not be as simple as one might think, depending on the deployment configuration. In fact, I believe it is easier for logging to be circumvented through obfuscation techniques or resource exhaustion tricks. Consequently, the community would greatly appreciate documentation that dives into this topic, providing insights into the challenges associated with disabling Falco and more importantly offering guidance on effective measures to mitigate the risks of logging evasion.
Linux security monitoring is unique in every organization because of factors such as the organization's environment, system architecture, risk profile, security objectives, compliance requirements, the evolving threat landscape, and available resources. These factors influence the specific security monitoring needs and approaches of each organization. Therefore, an alternative approach is to educate the adopter on effectively using Falco and customizing it to align with their organization's requirements and threat model. This approach aims to set realistic expectations and provide additional educational resources beyond Falco's scope. It recognizes that Linux security monitoring encompasses various technologies that span multiple domains, and empowering the adopter with knowledge in these areas can lead to better utilization of Falco and overall security monitoring practices. Technologies and domains Falco touches: Linux kernel and eBPF, Offensive security, Cyber defense, Incident response, Production deployment and operationalization, Performance optimization and stability, Data pipelines and scale, Big Data and Data Science. |
Issues go stale after 90d of inactivity. Mark the issue as fresh with Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with 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 Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with Provide feedback via https://github.com/falcosecurity/community. /lifecycle stale |
/remove-lifecycle stale |
/assign |
Issues go stale after 90d of inactivity. Mark the issue as fresh with Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with Provide feedback via https://github.com/falcosecurity/community. /lifecycle stale |
/help |
@leogr: Please ensure the request meets the requirements listed here. If this request no longer meets these requirements, the label can be removed In response to this:
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/test-infra repository. |
Issues go stale after 90d of inactivity. Mark the issue as fresh with Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with Provide feedback via https://github.com/falcosecurity/community. /lifecycle stale |
Stale issues rot after 30d of inactivity. Mark the issue as fresh with Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with Provide feedback via https://github.com/falcosecurity/community. /lifecycle rotten |
Rotten issues close after 30d of inactivity. Reopen the issue with Mark the issue as fresh with Provide feedback via https://github.com/falcosecurity/community. |
@poiana: Closing this issue. In response to this:
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/test-infra repository. |
/area documentation
What would you like to be added:
Quoting the last security audit report of Jan 2023 (section 5.1 A note on threat actors , page 8):
Update the Falco documentation to make the assumption "that most users will be non-trusted unprivileged users, or diminished root users in containers" explicit when Falco is deployed in a K8s cluster. In case that assumption wasn't valid for the adopter use case, the documentation should clearly state that, without additional strategies, a malicious actor may disable Falco, thus voiding its security value.
Why is this needed:
The current documentation might confuse our users and expose them to potential security issues. Making them fully aware of the intended threat model would mitigate such risk.
The text was updated successfully, but these errors were encountered: