How to Integrate FIM with SOAR Platforms

File Integrity Monitoring (FIM) is a key intelligence and audit tool in an advanced security portfolio. While it is a logical component to integrate into your Security Orchestration, Automation, and Response (SOAR) tooling, it’s important to consider your approach to ensure you can gain the most benefits from it.

Classify First

The sensible starting place for your integration is to consider your FIM strategy. Working with clients to integrate FIM data sets for SOAR use cases, I’ll typically focus on ensuring FIM data is well classified:

• Categorize – Your FIM tool is likely already classifying changes so you can easily identify the difference between a business application from an operating system change or a Windows server configuration file versus a network device configuration setting change. Fortra’s Tripwire, fortunately, already provides classifications with our out-of-the-box rules that will help to break these down, though you may want to add additional business logic here, too – I’ll often add additional labels to highlight particularly critical internal business apps.
• Severities – Consider how you want to score some of the more important detected changes. This provides a useful flow control data point, letting you prioritize high severity changes for basic use cases and then expanding your workflows to cover more complex scenarios once you’re comfortable with the automation workflows.
• Coverage – If you’re focusing on specific use cases, consider whether you need additional rules for coverage for the automated responses you want to run. I’ll often take basic forensic audit rules for Active Directory user setting monitoring and extend it to provide detailed auditing of sensitive (such as Domain Admin or service) accounts to tie into SOAR workflows that aim to prevent tampering with high value domain accounts.

From Alerts to Playbooks

Once you’ve got your data classified well, consider the automation workflows that make sense for your data types. There are a wide range of possibilities, but the most common ones I tend to help clients put together for FIM responses include:

Automated restoration of files 

This is the most common one I see people asking for in relation to FIM, and it makes a lot of sense, though it needs care to be implemented effectively. Fully automatic recovery of files can be risky, and consideration should be given to “post-recovery” steps. For example, for IIS monitoring, I’ll often include automated recovery for global configuration values changed outside of an approved change window or even to handle website “defacing” attacks (internal or otherwise). Sometimes, however, an out-of-band change may be important and shouldn’t be automatically reverted. As a result, consider your high-sensitivity options for your automation workflows, along with notifications and rollback strategies.

Automatic validation of configuration changes

While file restorations are a common option, I actually see more value in reapplying security configurations via registry and or scripted responses. These can cover an even wider range of settings and can help enforce best practice hardening (and cut back on temporary changes made by system owners that can end up leaving a device insecure).

Automatic lockout of accounts

Another one we’re familiar with is account lockouts. We have all seen a password lockout after a set number of failed attempts, but adding a layer of sophistication with FIM monitoring means you can validate pre- and post-lockout information. This can drive a more sophisticated account management strategy for accounts that you might otherwise find application owners are apprehensive about having restrictions on.

Of course, there are many, many more possibilities (especially if you’re dealing with FIM data in tandem with other signals as your initial trigger point.) If you’re looking for further ideas around this, now might be a good time to consider speaking to a Fortra Professional Services consultant. We have experience with many scenarios that might tie into your goals, as well as using innovative approaches to suggest something new that will give you a new level of protection against risks detected by FIM.

Track Success

Finally, the key to your FIM-SOAR strategy is continuous testing. Part of that should be testing the use cases you’ve developed as well as edge cases that might not have immediately come to mind but remain important to handle. I often like to use this testing stage to incorporate other parts of the business to validate the playbooks that were developed, as they’ll offer a different point of view. It also serves as a good opportunity to show off the sophistication of your automation strategies to the wider organization.

That testing will also give you an important start to tracking your success – checking whether you’ve achieved your use case, identifying enhancements for future workflows, and giving you some benchmarks that you can use to track future automation responses against.

FIM–SOAR can be much more

While SOAR adoption has grown rapidly in recent years, FIM data is often restricted to SIEM and audit-only tooling – something I’d love to see change in a zero-trust security world where automation is key to keeping on top of the threat environment. If you’ve got FIM and SOAR tools already, now is the time to get a project to tie them together and make sure you’re not missing out on an important security signal for your workflows.