Goal Summary:

A comprehensive File Integrity Monitoring (FIM) solution that allows security administrators to detect and alert on unauthorized file modifications across both containerized deployments and host nodes. By providing granular filtering via file paths, operation types, and process initiators, FIM ensures real-time visibility into potential tampering while maintaining system performance through optimized daemonset configurations.

Goals and expected user outcomes:

• A customer shall be able to define a policy to identify if file activity has been initiated by a process inside a container (Deployment type File Activity Policy). The following are options for the customer that has to configure such policy:
  • ‘File Operation’ if they want to monitor specific file operations: write, create, change permissions.
  • (New)‘Process initiator’ if they want to filter out by the process name which performed the modification.
• User can choose either Actual path or Effective file path to identify the file they are interested in monitoring.
  In addition to the Actual path or Effective file path, the user can further filter out events using the following criteria: process and file operations

• A customer shall be able to define a policy to identify if file activity has been initiated by a process on the host  (Node type File Activity Policy). The following are options for the customer that has to configure such policy:
  • ‘File Operation’ if they want to monitor specific file operations: write, create, change permissions.
  • (New) ‘Process initiator’ if they want to filter out by the process name which performed the modification.
  • (New) User can choose either Actual path or Effective file path to identify the file they are interested in monitoring.
  • In addition the following are options for the customer that has to configure such policy:
    • ‘File Operation’ if they want to monitor specific file operations: write, create, change permissions.
    • (New)‘Process initiator’ if they want to filter out by the process name which performed the modification.
• Both policy types will be configurable via Policy Wizard in ACS UI, API or CR
• (New) User can use wildcards but it will be subject to limitations defined by us (after doing bechmark)
• File system policies for deployments will abide by exclusions, to minimise alert noise.
• (New) The Fact DaemonSet will be configured only to the set of paths and attributes of the available policies.
• (New) Violations dashboard will show both Deployment and Node violations. All the alerts referring to the same deployment will be grouped under the same ‘Deployment’ type violation and same will happen for ‘Node violations’
• (New) When in the UI a Node Violation is opened, you will have a Tab to describe Node information: 
  • Cluster name
  • Cluster ID
  • Node name
  • Node ID
• (New)UI change for File Operation: Delete --> Delete (unlink)
• (New) Upgrade FACT to Ubi9 (again) and build it as part of ACS Konflux build
• FIM will be limited to x86 

Out of scope:

• Notifications via Splunk TA are pushed to 5.0
• Feature enablement won't be done by runtime configuration
• ARM, power and Z support

Test we must performed:

• Automated testing for all the main file operations customers will test with and know how our system behaves in such cases.
  • Examples: 
  • Open (writable)
    • open with a text editor: nano, vi, vim, emacs
    • open via shell redirection: exec 3> maria.txt
  • Create : 
    • create an empty file: touch
    • create and write content: echo "Hello World" > maria.txt
    • Create using text editor: nano maria.txt (file doesn't exist before hand)
  • Detele (unlink)
    • Remove a file: rm
    • Force delete: rm -f
  • Permission change:
    • chmod u+x maria.txt
    • chmod 666 maria.txt
  • Ownership change:
    • sudo chown alice maria.txt
    • sudo chown alice:developers maria.txt
    • change group only: sudo chgrp developers maria.txt{}
• Enable deployment and node type policy for the 4 files we keep track in 4.10. (/etc/shadow, /etc/passwd, /etc/ssh/sshd_config, /etc/sudoers.
  Now perform an OpenShift upgrade and see all the violations that are triggered by the upgrade itself on those 4 files.
  Modify the policies to filter all those 'legitimate violations' as noise. You can do this by using the same tools the customer has: using exclusions and scoping, filtering by process name. 
  Then, perform a new upgrade to a different version and see if you got rid of all those violations. If not, this is what the customer is expecting and we need yet different criteria to be added to filter it. 

Acceptance Criteria:

• Sufficient testing to provide customers a benchmark of how far our FIM stretches.
• User must be able to filter out all of the legitimate file activity events triggered by an OpenShift upgrade
• Users must be able to create a policy that combines at least three conditions (Path + Operation + Process Initiator) 
• Wildcard patterns (e.g., /etc/*.conf) must resolve correctly without exceeding a CPU threshold of [X]% on the collector.
• The Violations Dashboard must aggregate multiple file events on the same node/deployment into a single logical violation entry to prevent "alert fatigue."
• For Node-type violations, the UI must display all four required fields: Cluster Name, Cluster ID, Node Name, and Node ID, in addition to the other relevant FIM fields.

Success Criteria or KPIs measured:

• Resource Overhead: The FIM agent must not consume more than 5% CPU and 200MB RAM on a standard node under a "heavy" load (e.g., 100 file operations per second).