You're right that FIM assumes the possibility of compromise, but that's exactly the point - it's a detection control, not a prevention control. Prevention (read-only mounts, immutable bits, restrictive permissions, etc.) is necessary but not sufficient. In practice, attackers often find ways around those measures - for example, through misconfigured deployments, command injection, supply chain attacks, or overly broad privileges.
File Integrity Monitoring gives you a way to prove whether critical code or configuration has been changed after deployment. That’s valuable not only for security investigations but also for compliance.
For example, PCI DSS (Payment Card Industry Data Security Standard) explicitly requires this. Requirement 11.5.2 states:
"Deploy a change-detection mechanism (for example, file-integrity monitoring tools) to alert personnel to unauthorized modification of critical content files, configuration files, or system binaries."
Sure, a "sufficiently advanced" attacker could try to tamper with the monitoring tool, but (1) defense in depth is about making that harder, and (2) good implementations isolate the baseline and reports (e.g. write-only to S3, read-only on app servers), which raises the bar considerably.
I guess I can begrudgingly accept that this is an example of "defense in depth" but it doesn't seem like a very good one given how easily it can be bypassed. Like, you could equally well add "depth" by taking every password prompt and making it prompt for two different passwords, but of course that doesn't add any real security.
> for example, through misconfigured deployments, command injection, [...] or overly broad privileges.
Seems to me like it would be more useful to build something into your deployment process that verifies that permissions are set correctly.
I don't really buy that `mount -o ro` is inherently more prone to being misconfigured than `kekkai verify` or whatever.
> supply chain attacks
This wouldn't actually do anything to stop or detect supply chain attacks, right? Even if one of your dependencies is malicious, you're not going to be able to spot that by checking a hash against a deployment that was built with the same malicious code.
> good implementations isolate the baseline and reports (e.g. write-only to S3, read-only on app servers), which raises the bar considerably.
I don't see how that raises the bar at all. The weakness is that it's easy for an attacker to bypass the verifier on the app server itself. Making the hashes read-only in whatever place they're stored isn't a barrier to that.
> For example, PCI DSS (Payment Card Industry Data Security Standard) explicitly requires this.
This seems like the best actual reason for this software to exist. But if the point is just to check a compliance box, then I think it would make sense to point that out prominently in the README, so that people who actually have a need for it will know that it meets their needs. Similar to how FIPS-compliant crypto exists to check a box but everyone knows it isn't inherently any more secure.
You’re right that this doesn’t prevent compromise—it’s a detection control, not prevention. Things like read-only mounts or immutable bits are great, but in practice issues like command injection or misconfigured deployments still happen. FIM helps you know when files were changed and provides evidence for investigation or compliance.
> 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.
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
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?
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.
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.
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.
> Hospitals led by doctors outperform those run by non-medical managers. Universities, business schools and academic departments led by good scholars outperform those that are not. The best sports teams – using data from 15,000 basketball games and 60 years of Formula 1 racing – are led by great former players or run by racing specialists.
IMO, resumes, while ideally intended as experience summaries, often function as gatekeeper proxies, filtering candidates based on arbitrary criteria rather than actual potential. Unfortunately, I too can't think of a good alternative solution that can scale well.
Hiring on potential isn’t a great strategy though. It’s important to compare candidates on something objectively displayed during in the hiring process, rather than some “potential” that’s a figment of one’s imagination.
It's not exactly potential. The way I've heard it phrased is: hire for slope, not y-intercept. The trouble is that slope is even harder to judge than y-intercept.
IMO, Resumes attempt to solve a problem that precedes what some consider the actual hiring process: the need to quickly screen thousands of candidates.
Unfortunately, this approach has flaws. The person doing the initial screening may not have a deep understanding of the role and is often working with secondary information. This can sometimes lead to them becoming gatekeepers, filtering based on superficial criteria (like career gaps, job switches, etc)
Looks like your website has a bug - try entering a house number which is non integer (Like say B-123) Submission fails with error:
```
{"statusCode":400,"error":"Bad Request","message":"ValidationError","data":{"errors":{"houseNumber":["houseNumber must be a `number` type, but the final value was: `NaN` (cast from the value `\"B-123\"`)."]}}}
```
It's wrong to assume that a house number is always an integer. My address has an alphanumeric house number. I have been in apartments without a house number (Instead they may have an alphabetical name. Something like XYZ House)
Thanks for this comment. I had a similar problem with email verification assuming particular email formats. I really appreciate your pointing this out, I would not have found it on my own.
I removed the "house number" section in favour of on the "recipient address" section, and your comment makes me think it might be better to simply have text fields for Name / address / city / province / postal code rather than fields that are more complicated, because unless they are executed very well they might end up being barriers.
Agreed. Anyone who has not tried Ember should check out their getting started guide: https://guides.emberjs.com/release/getting-started/quick-sta....
Also, I highly recommend `ember-concurrency: An Ember Addon that makes it easy to write concise, robust, and beautiful asynchronous code.`
LinkedIn's Trust Engineering team is looking for Frontend developers who are eager to tackle the challenges of a rapidly growing web application with millions of daily visitors.
- 8+ years of hands on experience with semantic HTML, CSS and JavaScript.
- Ability and eagerness to program progressive, single-page applications (Ember / React / Angular / Backbone)
File Integrity Monitoring gives you a way to prove whether critical code or configuration has been changed after deployment. That’s valuable not only for security investigations but also for compliance.
For example, PCI DSS (Payment Card Industry Data Security Standard) explicitly requires this. Requirement 11.5.2 states:
"Deploy a change-detection mechanism (for example, file-integrity monitoring tools) to alert personnel to unauthorized modification of critical content files, configuration files, or system binaries."
Sure, a "sufficiently advanced" attacker could try to tamper with the monitoring tool, but (1) defense in depth is about making that harder, and (2) good implementations isolate the baseline and reports (e.g. write-only to S3, read-only on app servers), which raises the bar considerably.