Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

If you’ve been in information security for a while, you’ve likely had some experience with file integrity monitoring (FIM). It’s a capability with a long history, going back to the original open-source Tripwire tool for monitoring file hashes. And FIM has staying power. It’s still around, and there are still new deployments. There aren’t a lot of security controls that continue to be valuable over such a long time frame.

In a previous article, I noted that organizations are witnessing a surge in integrity-based attacks targeting their networks. Enterprises can defend themselves against these types of threats by turning to the National Institute of Standards and Technology (NIST) Cybersecurity Framework. They can then pair the risk-based approach with NIST SP 800-53 and other security control catalogs that enable integrity management.

Windows supports a code-signing feature called Authenticode, which allows a software publisher to digitally sign executable files (e.g. .exe, .msi, …) so that users can verify their autenticity. The digital signature of a file can be viewed in the file properties in Windows explorer on the “Digital Signature” tab.

In part one I provided a high level overview of PowerShell and the potential risk it poses to networks. Of course we can only mitigate some PowerShell attacks if we have a trace, so going forward I am assuming that you followed part 1 of this series and enabled: Module Logging, Script Block Logging, Security Process Tracking (4688/4689)