Goal Summary

Expand File Activity Monitoring to provide user defined  paths specification, optionally with wildcards, violations on file rename operations, and ability to combine existing process criteria with file access criteria for deployment and node policies. 

Goals and expected user outcomes

• Users must be able to define their own paths to monitor including the use of wildcards. 
• RHACS must be able to react if the chosen criteria of file activity by the customer threatens the stability of the system.
• Users must be able to filter file activity based on:
• Process name
• Process ancestor
• Process arguments
• Process UID

• Users should be able to create policies and see violations for file rename operations. 
• Users need a unified and intuitive interface that allows them to define security policies for file paths they are interested in by simply naming the file they want to protect, without having to understand exactly where this file is located. 
• We will do this by using a single criteria, File path, that will substitute Effective Path and Actual Path fields in deployment and node type policies to enhance the user experience of customers during policy generation and reduce cognitive load.  
• Violations will contain both fields: Effective Path and Actual Path, and will be triggered when any of those paths match File path. 
• Important: There is no feature gap, just a much better user experience.

• Users must be able to see Node violation from the UI dashboard. Node violations should contain: Cluster name, Cluster ID, Node name, Node ID
• Change for File Operation: Delete --> Delete (unlink) to provide clarity to users connecting the terminology of the policy and violation.
• Add a new default policy category: “File Activity Monitoring” 
• Test File Activity Monitoring with HCP and describe if there are any limitations. 

Limitations:

• File Activity Deployment type Violations of files on the overlayFS of the container won’t contain Actual path filled out. Effective path provides the main value for the customer rather than knowing exactly where on the host this is stored.

Example:
Customer intention is to monitor critical application file /app/config/production.yaml

• File policy deployment type: File path: /app/config/production.yaml
• Deployment type Violation:
• Effective Path:  /app/config/production.yaml
• Actual Path: (empty,even though actual path /var/lib/docker/overlay2/./app/config/production.yaml)

Out of scope

• File access notifications via Splunk TA [targeted to 5.0]

• 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).