3 ms·

> In practice, attackers often find ways around those measures I really don't see this as a good explanation. You can say that about any security measure, but

> In practice, attackers often find ways around those measures I really don't see this as a good explanation. You can say that about any security measure, but we can't keep slapping more layers that check the previous layer. At some point that action itself will cause issues. > for example, through misconfigured deployments, command injection, supply chain attacks, or overly broad privileges. Those don't apply if the file owner is not the app runner or the filesystem is read-only. If you can change the file in that case, you can disable the check. Same for misconfiguration and command injection. > For example, PCI DSS Ah, BS processes. Just say it's about that up front.

chucky_z 1y ago
I've used FIM in the past to catch a CEO modifying files in real-time at a small business so I could ping him and ask him to kindly stop. It's not just about BS _processes_. :D
- viraptor 1y ago
  That means CEO has access to do the changes. It's technically easier to remove that, than to insert FIM into the deployment process. (And will stop other unauthorised employees too) I mean, you already need a working deployment pipeline for FIM anyway, so enforce that?
  - chucky_z 1y ago
    The CEO would've found it very easy to remove the blocker in that case (me). This is the life of small tech businesses. Also, they were modifying configuration files (php-fpm configurations iirc) and not code. FIM is very useful for catching things like folks mucking about with users/groups because you typically watch things like /etc/shadow and /etc/passwd, or new directories created under /home, or contents of /var/spool/mail to find out if you're suddenly spamming everyone.
    - catatsuy 1y ago
      That’s a great real-world story. Exactly the kind of unexpected modification FIM can help surface—not only security incidents, but also operational surprises.
catatsuy 1y ago
Compliance is definitely one use case, but not the only one. It’s also useful for catching unexpected local changes in real-world operations. The goal is to provide a lightweight FIM that can be added to existing apps without too much friction.

chucky_z 1y ago

I've used FIM in the past to catch a CEO modifying files in real-time at a small business so I could ping him and ask him to kindly stop. It's not just about BS _processes_. :D

viraptor 1y ago
That means CEO has access to do the changes. It's technically easier to remove that, than to insert FIM into the deployment process. (And will stop other unauthorised employees too) I mean, you already need a working deployment pipeline for FIM anyway, so enforce that?
- chucky_z 1y ago
  The CEO would've found it very easy to remove the blocker in that case (me). This is the life of small tech businesses. Also, they were modifying configuration files (php-fpm configurations iirc) and not code. FIM is very useful for catching things like folks mucking about with users/groups because you typically watch things like /etc/shadow and /etc/passwd, or new directories created under /home, or contents of /var/spool/mail to find out if you're suddenly spamming everyone.
  - catatsuy 1y ago
    That’s a great real-world story. Exactly the kind of unexpected modification FIM can help surface—not only security incidents, but also operational surprises.

catatsuy 1y ago

Compliance is definitely one use case, but not the only one. It’s also useful for catching unexpected local changes in real-world operations. The goal is to provide a lightweight FIM that can be added to existing apps without too much friction.