The "maintaining compliance" issue

There’s an interesting discussion over on PCI Compliance Demystified about maintaining compliance after you have initially achieved the “tick in the box”. The discussion is primarily about PCI DSS compliance but could be had about any compliance requirement.

To paraphrase, the question was raised: “how is compliance maintained?” which has developed into a “what’s being done about maintaining compliance?” question.

I find this interesting because when we first started looking at PCI DSS Compliance at my company I made more emphasis of the “maintaining compliance” requirement than the “achieving compliance” requirement. It was a hard sell, and not fully accepted as yet.

PCI DSS requires that you achieve compliance and continue to remain compliant from then on. If your company suffers a security breach and the investigators are sent in by the card schemes, they will not just assess your compliance when they turn up. What they will do is investigate the state of compliance for as long as the security breach occurred and even prior to that to identify whether a failure in maintaining compliance contributed to the breach. If it did, big money fines are on their way.

Take the TJX situation for example. Initially TJX reported that the security breach happened “over a period of a few months at the end of 2006”. After the investigators went in they found that the hack had been on going for a period of a couple of years. This being the case, the investigators will be assessing whether TJX was compliant for the whole of that time. From reports it appears they were not.

My company has accepted the “maintaining compliance” requirement to the extent where they have agreed to completely redesign the payment processing platform from the old legacy system (which was difficult to support and maintain) to a nice shiny new compliant and maintainable platform. Good news. However, the question of compliance management thereafter is still being discussed.

Without the compliance management process existing, the initial achievement of compliance is fairly pointless. 2 days after you tick the box, a new member of staff joins and unwittingly blows your achievements away by introducing a new business practice that ignores some fundamental PCI DSS requirement. Worse still are the creeping changes which in isolation are perfectly fine and compliant. However, over time, one thing leads to another and bang, a vulnerability slides in which “no one could possibly have foreseen….”

Compliance management is a functional process and requires not only resources but also an agreed corporate approach. Perhaps this is the issue, no one wants the responsibility monkey on their back.

Data ownership

I read Rob Newby's post about "data classification" with interest as the implementation of such a process has been on my "to do" list for a while. To paraphase my comment to him, "I think Data Classification is one of the fundamental first steps in a good InfoSec programme". The point is, until you know how important the data is, how long it needs protecting for and who should have access to it it is impossible to get the data security environment set up correctly.

And therefore, protect your data adequately.

So, on to my particular issue. I have discussed data classification schemes in the past within The Company and not had much interest. Despite using the obvious scare mongering tactics and some pretty internally high profile snafus, no one really gave a preverbial.

So, how do I make people take notice?

Well, a while ago, I found out that our directory access control settings were all over the place. People had access to stuff they didn't need and in some cases, didn't even know about. After investigation, it appears that to be given access permissions to a certain directory, you just had to "fill in a form". The process of authorisation didn't really exist.

Although strictly speaking this isn't "data classification", it is linked.

It sparked a debate where I suggested that the IT department should review the process of assiging access permissions and improve it. They misunderstood and said it was not their responsibility to decide who has access to what. Of course it isn't, but they have a responsibility to ensure that the requests are properly authorised and that the environment is maintained correctly.

So, where are we now? Well, The Service Delivery Manager is involved and we have agreed to raise it at the next IT User Group Meeting with a view to getting buy-in from the business.

Here lies the core issue. In previous discussions, it's been a case of "it's not my responsibility" from both IT and the business units. The process of breaking that down is one of enlightenment. Once both "sides" understand where they fit into the whole picture, they "should" agree to take ownership a lot easier.

Now to the link between "data classification" and "access control". Once the business units have accepted responsibility for specifying who can access what directories / folders, it should be a far easier "sell" to get them to accept responsibility for determining who should see what specific data. That being true, the subject of "data classification" springs up, as if by magic!!!!