CIOs, Your Top 10 Compliance Headaches

I deal with compliance in 2 positions – directly, for our own compliance, and indirectly for our customers’ compliance.  In both cases, though, I find very similar issues, and most of them stem from the fact that auditors don’t base their assessments on a unique company’s case-by-case situation but, instead, go down a predetermined checklist that someone else has written for them and which, more often than not, they follow like Gospel.

These checklists are written in a very generic and high level tone, and are meant as guidance, as a general direction of what the auditor should be looking for and should assess.  Instead, many auditors frankly don’t have the technical expertise to interpret those lists properly and apply them with the due exceptions in every case.  Instead, they resort to going down the list without critical thinking, and often, this causes issues.

I could provide hundreds of examples, but I shall only mention one ~ many auditors do what they call ‘pen test’.

This is an abbreviation for penetration test, but what they’re really doing is a vulnerability scanning.  No, not a vulnerability assessment, but simply a scanning with a standard engine, reporting on standard tests.  The issue with doing this is that a scanning is only the very first baby step in determining the actual security posture of a company.

Once you have the results, you need to assess whether there are false positives, whether some of them are correct but don’t really matter, or don’t really have any chance of being exploited, and which remain as true issues which necessitate further investigation.

Thereafter, it would be a good idea to test those issues further, to see if they are truly exploitable (possibly without taking the customer network down!) but this is an extra step which can be avoided.  When you get to this step, it makes sense to fix the remaining issues anyway.

The problem with all this is that most times, all the auditor does is present you with an initial laundry list of results, and you find yourself staring at issues that bear no consequence whatsoever on your security posture, and, consequently, very likely wasting a lot of time fixing issues that aren’t pertinent, just to ensure the audit scan comes out clean.

Here’s something which happened to me about a month ago while assisting a customer.

You see, our device runs firewall and 2 IPSs inline.  The auditors weren’t able to even find the device, let alone scan it.  Frustrated by the excessive protection the device was displaying, they asked us to set their source IP addresses as “friendly” so that the IPSs wouldn’t block them.  Grudgingly we complied.  They ran their scan, and came back telling us that supposedly we had a problem.  My jaw dropped – I mean, first you ask me to let you in uncontrolled, then you accuse me of having let you in uncontrolled?

What auditing methodology is that?  And to top the cake, the ‘supposed’ issue wasn’t even an issue because it was a false positive.

In conclusion, all ranting aside, my worst headache about compliance isn’t the rules or what I need to do to get there.  Quite frankly, my worst nightmare is those auditors who apply checklists without any critical thinking.

What’s yours?