PASS Pro Now Available

Welcome to the next evolution of PASS. Unlock exclusive training, discounts, and networking opportunities designed to accelerate your data career. Learn More >

The official PASS Blog is where you’ll find the latest blog posts from PASS community members and the PASS Board. Contributors share their thoughts and discuss a wide variety of topics spanning PASS and the data community.

Privacy, Security and Ethics for the Data-Driven Professional

It’s challenging to talk about Data Privacy without mentioning either Security or Ethics.

Potentially we should also be discussing process and governance – which can go a long way to ensuring that both privacy and security are as tight as possible.

The purpose of this short article is to generate thinking around these concepts and hopefully foster some thoughts into how we might make our industry more secure and less prone to the damaging articles we see everyday concerning data breaches and the misuse of data.

One common cause of data breaches is compromised passwords, and this can stem from either sharing them, writing them down or simply making them easy to guess.

At some point in my career I concluded that attempting to remember the multiple passwords that we have today was both unsustainable and futile. I started to use a password safe, initially hosting this on the corporate network. While this goes a long way to solving the issue of remembering them, it brings up another few challenges – namely the cultural change in getting the organisation using them, but also the issue of who looks after the safe, maintains and updates the processes around their use, storage, backups (and their storage) as well as any restores of them that may need to happen.

In the end, many corporates decide that this overhead is too much and opt for one of the many password safes on the market today such as LastPass or 1Password.

But, applications need to securely connect to resources – such as databases and email accounts – as well. And while authentication methods that don’t include passwords are preferred, such as Windows Authentication, Kerboros and certificates, there are still many applications that need to use passwords, and these applications need secure access to these password safes.

If you’re using Azure then there is always Azure Key Vault which may go some of the way to help solving some of the issues that were outlined in the last paragraph.

One of the other deep cultural changes that I feel our industry need to go though concerns attitudes towards monitoring and auditing.

Often these are looked at as tools to ‘find fault’ or ‘apportion blame’ – but this thinking needs to be put aside and we need to start thinking about the abundance of data that both auditing and monitoring can give us, that will directly lead to more secure and performant applications.

The logs can also be used in order to prove that the application is secure, is operating as expected and is accessing other resources, such as databases, in a secure manner.

This gives auditors, customers and prospective customers confidence that what you say is happening, is in-fact actually happening, and can act as a great source of positive marketing for any company.

One of the other big issues of our time concerns production data going into non-production environments.

Ideally, this is best avoided. However, if it absolutely must happen then a good strong process must exist around this, that includes a full de-identification process which is not reversible and includes removal of things like photographs, video and other non-text-based identification artefacts. Any metadata that contains identifiable attributes should also be irreversibly modified – or maybe even completely deleted.

This process should be strong and 100% enforceable so that it is not overwritten by somebody with seniority who feels that the need to place production data in a no-production environment outweighs the impact of exposing the personally identifiable information of the data subjects within the database.

You’ll likely want to remove data subjects that are easily identifiable because of some unique characteristic – such as extremely high balances or their relationships with other data subjects.

Tools do exist for doing this, such as data masker from Redgate. It is possible to write your own, but I’d caution against doing this as there is a large overhead in doing so and there is also a danger of making this too customised.

So, there’s a lot going on when it come to asking for production data to leave the production environment and so maybe it’s not a good idea to let this happen at all.

Maybe a better way would be to generate a totally fictitious – but very real looking – set of data purely for the purposes of development or testing. While this may seem like a big overhead, it may not be as costly as exposing the personally identifiable data of your customers. This cost may not solely be in any imposed fines, but also in reputation, lost customers, loss of potential customers and loss of commercial partners. This is something an enterprise may never recover from.

And, what about those pieces of legislation that were used to dish out the fines? If they are not aimed at your part of the world should you even be bothered taking notice of them? Well, I think so because sooner or later similar legislation will likely be drafted in your part of the world and then you’ll be playing catch up.

Martin Catherall
About the author

Martin is a data consultant in Melbourne, Australia, a Microsoft Data Platform MVP, and PASS Regional Mentor for the Asia Pacific (APAC) region.

Martin founded the Christchurch, New Zealand PASS Local Group and lead the group for a number of years before relocating to Melbourne.

He has been using SQL Server in various roles since 2000. In addition to anything data related, he enjoys playing the guitar and having fun with his family.

Please login or register to post comments.

Theme picker

Back to Top