PCI DSS 11.5 requires merchants to “…alert on unauthorized modification of critical system, content or configuration files…”. That should be good news, right? Alerting on unauthorized change requires more from a FIM than simply detecting change. It requires the ability to analyze each detected change to determine if it is expected or unexpected. Tripwire FIM can do that and others cannot; they don’t have the intelligence to make that determination nor the architecture to manage large amounts of change data over time.
Auditors do not require merchants to prove they know which changes are unauthorized so they seldom try. They simply store change data in bulk for compliance requirements and that is about it. It has given True FIM and a tarnished reputation: FIM is all noise.
True FIM—Tripwire FIM—can help merchants automatically determine if detected change is authorized or even most likely authorized. But more importantly, Tripwire FIM helps to automatically determine if change is suspect and should immediately be investigated or if it is expected and can be considered low-risk or no-risk. There is a huge difference between unauthorized and suspect change.
Defining a change as unauthorized presumes it is a “bad” change but that is not necessarily true. While the change may not have followed defined change process policy, it may actually resolve a critical problem. Defining a change as authorized presumes it is a “good” change but that is also not necessarily true. Many authorized changes cause problems and have to be rolled back or modified—sometimes using an unauthorized process.
The use of the term unauthorized in the PCI DSS specification is a misnomer. For the purpose of increasing the security of cardholder data it would be better to alert on undesired or suspect change. While Tripwire FIM can correlate detected changes to RFC tickets, this process is not foolproof because the tickets do not contain the information required to make it foolproof.
Many merchants do not have automated ticketing systems or, even if they do, they do not put 100% of their approved changes through the system. And virtually no RFC ticket includes a list of every file that is authorized to be changed. The result is that detected changes cannot be reconciled file-by-file to RFC tickets. If not, what is the benefit of trying to reconcile change to authorization?
Whether a detected change can be reconciled to some form of authorization or not does not address the issue of a “bad” change that exposes a device or application to increased risk of compromise. Finding bad changes is the issue that must be addressed by FIM. Doing so is the true intent of the PCI DSS 11.5 requirement. Tripwire FIM is designed to help find bad change at the speed of change.