You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Propose Falco rule exceptions for false positive events.
Why is this needed:
As a user it is cumbersome to learn Falco rule syntax and to manually create exceptions based on false positive findings. As a rule of thumb, fewer, less sophisticated rules mean less false positives but also lower detection capabilities. On the other hand, more, and more sophisticated rules mean more false positives for which exceptions must be defined.
As an example, I used the vanilla ruleset from the active Falco project (https://github.com/falcosecurity/rules/tree/main/rules) for our workload. Detection capabilities were great: I could for example clearly follow debug sessions, however I spent a considerable amount of time defining exceptions for false positives. The resulting exception file grew to more than a thousand lines.
I would envision the following workflow, both on first deployment and continuously:
Deploy workload in cluster
Let the workload run for “some” time, possibly also including workload maintenance activities
Propose Falco exceptions for events
Review and apply exceptions
An administrator would review the exceptions and apply them to the system. As workloads-, and rulesets change, this needs to be a continuous process.
Care must be taken not to define exceptions for critical events or for events that indicate an actual attack. While one could argue that a system is not under attack during an initial deployment it may very well be at a later point in time.
The text was updated successfully, but these errors were encountered:
What would you like to be added:
Propose Falco rule exceptions for false positive events.
Why is this needed:
As a user it is cumbersome to learn Falco rule syntax and to manually create exceptions based on false positive findings. As a rule of thumb, fewer, less sophisticated rules mean less false positives but also lower detection capabilities. On the other hand, more, and more sophisticated rules mean more false positives for which exceptions must be defined.
As an example, I used the vanilla ruleset from the active Falco project (https://github.com/falcosecurity/rules/tree/main/rules) for our workload. Detection capabilities were great: I could for example clearly follow debug sessions, however I spent a considerable amount of time defining exceptions for false positives. The resulting exception file grew to more than a thousand lines.
I would envision the following workflow, both on first deployment and continuously:
An administrator would review the exceptions and apply them to the system. As workloads-, and rulesets change, this needs to be a continuous process.
Care must be taken not to define exceptions for critical events or for events that indicate an actual attack. While one could argue that a system is not under attack during an initial deployment it may very well be at a later point in time.
The text was updated successfully, but these errors were encountered: