Why businesses need to look internally to protect their data

(Image credit: Image source: Shutterstock/Wright Studio)

Organisations have understood for a long time the importance of data security and protecting customer information from hacking and misuse. The introduction of the GDPR and the tightening of other legislation has now raised the game and further reinforced the need to better protect personal data.

Interestingly, however, research demonstrates that businesses need to change their data security approach from looking for external threats to those from internal sources. The latest statistics from the Identify Theft Resource Centre found that, in 2018, breaches caused by hacking actually fell, but those due to unauthorised access from staff, contractors and other third parties trebled from 11 per cent to 30 per cent. While overall breach numbers went down, the number of exposed records also more than doubled from 197.6 million in 2017 to 446.5 million.

These breaches clearly leave companies open to regulatory fines as well as significant reputational damage, so how can they change their approach? Given that the need has moved to better securing data within the business, there is a requirement to focus on four areas.

Understand your data

Data is often scattered across organisations, so the first step is to identify where it is – where are all the databases, and who has access to them?

Following this, you need to categorise what type of information is being held. Is it standard personal data like names and addresses, for example, or is it more sensitive like a person’s racial or ethnic origin, or details about health or sexual orientation? If you then use a taxonomy to differentiate between personal and sensitive data, columns can be tagged to identify the kind of data they contain and what needs to be protected.

This then leads onto identifying where the risk lies. With all of the data found and categorised, it should be relatively straightforward. Are there copies of the production database in use in development and testing, for example? What access permissions are in place to restrict who can view the database? Where are backups kept, and are they encrypted?

Protect your data

Once you’ve identified the risks, you can put measures in place to protect your data. For many businesses this involves a change of mindset. With the threat growing from internal rather than external breaches, that means moving away from the open sharing of data to a ‘least access’ methodology.

You can reduce the attack surface area immediately by consolidating the storage of data to as few locations as possible and giving access only to individuals who have permission to view, modify or delete personal data that is relevant to their job role. You should also think about distributing data so that more sensitive information is in one place, less sensitive information is another, and only the necessary data gets transmitted across.

Where personal data is still exposed, consider using a technique like data masking to protect it. Many developers like to have a copy of the production database, for example, to create and test new code against, but these invariably contain personal data of the kind that needs to be protected and, therefore, restricted. Adopting data masking measures like pseudonymisation, encryption, anonymisation and aggregation protects sensitive data by replacing it with fictitious, but still accurate data. This balances protection and compliance with usability, and developers can still be confident the data they’re using is truly representative and their code won’t cause issues when deployed to production.

Bring DevOps to your data

  • DevOps: Common mistakes and how to avoid them

DevOps is becoming standard practice in application development and at first glance it may appear difficult to include database development in DevOps as well. Fortunately, the first step has already been taken with the rise of full-stack developers. The 2019 State of Database DevOps Survey from Redgate showed that 77 per cent of application developers are also now responsible for database development and building database deployment scripts.

So rather than changing the way developers work, it’s more about standardising the way everyone works. By, for example, writing database code in the same way, with a team style applied so that the code base remains the same however many developers have contributed to it, and is therefore easier to work with. There are tools available that can help with this, and the same tools often perform static code analysis as code is written, so that errors are flagged up early, rather than later down the pipeline.

Just as version control is used in application development, so it can also be applied to the database, preferably with a solution that plugs into and integrates with the same version control system already in place. By checking database code into a common repository during the development process, one source of truth is maintained, and there is a record of who changed what, when, and why.

Finally, automation can be introduced. Every time a change is committed to version control, for example, a continuous integration process can be triggered to test the change and flag up any errors in the code. The errors can be fixed immediately and tested again, before the change is then passed along to a release management tool where it can be reviewed before being deployed to production. This not only speeds up development but also provides a full audit trail for compliance.

Monitor your data

The increased focus on data privacy and protection has brought an additional requirement to how databases are monitored. Monitoring for performance issues like queries having an unexpected impact, memory utilisation and blocking processes is normal practice, but the safety of the data being held is now just as important. Organisations are now required to monitor and manage access, ensure data is available and identifiable, and report when a breach occurs, including how the breach has been addressed.

You need to know your servers are online, for example, and what kind of changes are occurring inside databases across all environments. Are people adding or dropping tables without your knowledge? Are modifications occurring to columns? Are access permissions changing?

You need a way to track changes to the data, alterations to the structures, and modifications to the environment that you are working within such that you know your systems are available, that the data being retrieved is the correct data and only going to the right people, and that you are able to ensure that the data is available online. 

Summary

Driven by increasing demands to protect personal data – and demonstrate that it is being protected – many organisations have succeeded in markedly reducing the threat from external players like hackers. The focus should now be shifted to ensure internal processes and practices are also updated so that the attack surface area within organisations is just as robust.

Matt Hilbert, technology writer, Redgate Software