Earlier this month, journalist and researcher Keith Ng blogged about a massive security hole in the New Zealand Ministry of Social Development’s (MSD) network.

According to Ng, he was able to simply walk up to a public kiosk in the NZ Work and Income office and — without having to resort to cracking a password or planting a trojan — immediately gained access to thousands upon thousands of sensitive files.

According to the news reports from the Southern Hemisphere, the researcher was able to browse, read, and modify a variety of files containing invoices and a variety of other financial data, as well as call system logs and files linking children to medical prescriptions, plus the identities of children in special needs programmes.

Accessing financial records without permission is one thing, but files involving children – and children with special needs – are an entirely different data protection ballgames.

The $64,000 question, of course, is how did this happen – and arguably more important from a governance perspective, is the problem a repeatable occurrence?

Our observations are that there are two leading possibilities: either the kiosks were logged in to a local or remote server using an administrative account (e.g. Domain Admin) with full access to all data on the network; or that the kiosks were logged in with a `normal’ privilege account, but with the file shares incorrectly `permissioned,’ thus allowing global access.

Most security professionals will find it difficult to believe that the kiosks were logged in with administrator permissions, but this possibility cannot be ruled out.

The latter possibility, meanwhile – that of broken/excessive permissions – is actually a very common governance problem that our clients experience, and turn to us for professional solutions that not only work, but also will pass muster for relevant governance best practice and regulatory reasons.

And with version 3.0 of the PCI DSS rules – which mandate a number of rules on organisations that process credit and debit card transactions – this issue is an important one.

This leads us rather neatly into the next question, namely – what could have been done to prevent this data security disaster from happening?

Unplugging the kiosks, of course, is only the first step. Truth be told, the kiosks are not the problem. There are many much larger information governance problems at stake here – and at the heart of the data leak headache.

We decided to approach the issue by offering a few governance tips for any interested parties, as there are some clear lessons that can be learned:

1) Locate any exposed, sensitive data

Exposed data can exist in many different forms, not least because IT systems tend to auto-archive and replicate a variety of information, whether it exists in a structured or unstructured format.

From this step, IT professionals should use a data classification framework to scan their file servers and so determine where their organisation’s most sensitive content resides – and where it is exposed to more people than it should be exposed to.

Once you have located your organisation’s sensitive data files, you need to ensure that only the right people have access, and then monitor access activity against that sensitive data to ensure that authorised users are not abusing their access.

If you are CSO/CISO, you will be looking for a solution that is capable of advising monitoring staff – at all times – where all their sensitive data is located, whether – and where – it is over-exposed, and who is accessing that data.

The bottom line here is that, if someone creates a file with a social security number – or patient ID – and places it into a folder that offers public share access for a kiosk to access, you will want a security platform that alerts key personnel immediately.

 

2) Identify and remove global access groups from ACLs

As an IT professional, you should be analysing where `everyone’ or `authenticated users’ appear on ACLs – Access Control Lists – and remove them from the system.

This step can be a toughie, for the non-trivial reason that it is a major task to trawl through every ACL on every file server or NAS device looking for `everyone’ and you will almost certainly have to pull the global access group without cutting off the people who really need access to the data.

3) Log and monitor your super users

This step in the governance process involves setting up alerts for whenever anyone is granted super user and/or administrator privileges.

This process also involves periodically reviewing the list of people who have privileged access on the platform in question.

Seasoned governance professionals should also review their IT audit trail to observe – and track – what the super users are doing with their elevated rights.

Even if the kiosks were mistakenly set up to run under a super user account, if the audit logging function were enabled, then it would almost certainly have noticed an inordinate amount of super user activity from the public kiosks’ IP addresses.

4) Assign and involve data owners

This fourth step involves getting what IT professionals call stakeholder buy-in – in the case of access to children’s medical records, for instance, this access should be granted and reviewed not by the IT function, but by the business unit that is responsible for managing the patients – i.e. the medical director.

By transferring this responsibility to the people who are most equipped to make access control decisions (i.e. data owners), not only do you – as an IT security and governance specialist – end up with better decisions, but you also relieve some of the burden on IT.

 

Many of the comments on Ng’s posts were along the lines of `Rookie mistake’ or `Security 101′ but the stark reality is that the process of information governance is much harder than people think, especially in an age where data is somewhat of a contagion and is being created – and replicated – at such a staggering pace.

In response to the industry commentators such as Ng, I would like ask the rhetorical question: without an automated solution, how would the audit software function know which folders were mistakenly placed with open access to everyone?

Our observations here at Varonis Systems suggest that it only takes one frustrated person around half a minute to add `everyone’ to an ACL – but it could take several years to discover and correct the access control failure.

Perhaps worse, once the records are found, how does the IT function know whether the over-exposed data was stolen by someone who isn’t as harmless as Keith Ng?

That’s the even larger governance question that New Zealand’s government is facing right now.