Skip to content ↓ | Skip to navigation ↓

Networkworld recently posted a piece by Ron Lepofsky titled “On Being Secure”.

In itself it was interesting, but the subtitle really grabbed me:  “Phase II: Why have I not yet implemented File Integrity Management”.  Now THIS is required reading!

The piece covered how FIM works and where to search for vendors that provide related tools.  What it didn’t do was connect the dots between FIM and PCI.   As my colleague Ed Rarick points out, “The term File Integrity Monitoring—or FIM for short—originated in the VISA CISP (Cardholder Information Security Program) in June, 2001.  In September, 2006, the CISP specification was folded into PCI DSS 1.0 and the FIM requirements remained the same—word for word.  Tripwire was referenced by name in the early versions of the security standard as a way to help define the intended purpose of FIM.

I recently spent a fair amount of time immersing myself in the 2.0 version of PCI DSS.  It occurred to me that this iteration deserved some scrutiny, partly because as a Tripwire product marketing manager it is in my purview to know what policy changes have occurred, and what market factors have driven them.  But on a deeper level, I was curious as to why the industry’s regulating body felt the need to update the wording, and its subsequent interpretation by the folks I talk with every day.

What I found was like what fighter pilots describe as their missions:  “…hours of boredom, punctuated by moments of stark terror”.  Lets skip to the terrifying moments, specifically section 11.5.

In this version, the Data Security Council introduced a testing procedure to the 11.5 file integrity monitoring requirement.  The new 11.5.b testing procedure reads: “Verify the tools are configured to alert personnel to unauthorized modification of critical files…”.  Hmmm…interesting addition – I wonder what drove this level of granularity and clarification?

In ruminating on this and speaking with colleagues, the consensus was that the purpose is to alert when unauthorized changes to critical files are detected so they can be remediated before any harm comes to cardholder data.  The requirement is not about collecting change data, it is about finding harmful change so that action can be prioritized.

Imagine a modern day dogfight where one fighter jock has a radar screen showing all air traffic in his range, and his opponent has a radar screen filtering out all but his target (eliminating “friendlies”, civilian aircraft, flocks of birds, the Goodyear Blimp…).  Which pilot is better equipped to win the battle?

Fortunately for system administrators and the people who depend on those systems, FIM solutions exist to help separate the intended target for remediation from the countless flocks of birds and Goodyear blimps that may light up their daily radar scopes.

Which brings me to another aviation quote, particularly relevant in light of the recent midnight unaided landings at Reagan International:  “If you’re ever faced with a forced landing at night, turn on the landing lights to see the landing area.  If you don’t like what you see, turn ’em back off”.