2018 will be remembered as the year the world stood up and took note of how slack some organizations were being with their data. The EU enacted the GDPR – the most far reaching data protection law so far – which seemed to lead to a snowball effect. Japan, Australia, India, and US states strengthened, tore up, and rewrote their laws too. Yet for all this enthusiasm, reports of data breaches keep on rising.
It begs the question: are we actually seeing an increase in non-compliance, or just an increase in reporting? High profile cases, such as the Facebook-Cambridge Analytica scandal, coupled with the promotion of updated and new regulations, is certainly making it a hot topic.
Unfortunately, it appears that data negligence has been going on for years. When Marriot announced in November 2018 that the records of 500 million customers had been involved in a data breach, the most shocking revelation was that an attacker had been able to access their network for four years!
What causes a data breach, of course, varies, but all too often it stems from internal sources. The infamous Equifax data breach of 2017, concerning the records of 146 million individuals, was down to mistakes in the software development process. And at the time of writing this, we’re hearing how a coding error at UW Medicine led to a misconfigured database and the exposure of patient data for 974,000 individuals in December 2018.
Regulations such as HIPAA, SOX, and the GDPR are designed to protect sensitive data – personal data for HIPAA and the GDPR, and financial data for SOX – with the intention that only authorized people can access it. But they rely on organizations having a good handle on their internal processes for protecting this information.
For many reasons, customer data gets spread around organizations’ IT systems, and the more places it lives, the greater the risk of non-compliance. Sensitive information is often copied down from production as part of a dataset so that real data can be used within development to improve testing. The temptation to do this is understandable. Production is constantly being kept up to date with new data so we can’t always be sure that the changes we’re making will affect production in the expected way. Development cycles are also getting shorter, so data needs refreshing more often to keep pace.
If you copy down production data, albeit for good reason – to improve the quality of your software – you are, however, taking an unnecessary risk. That’s because in most cases supplying realistic data can be achieved with masking. Actual data is rarely needed, it’s the size, shape and demographic distribution that’s important and this can usually be achieved through a masking model.
Solutions like SQL Provision from Redgate exist to make this easy, and should be at top of every IT team’s procurement list. When compared to the consequences of non-compliance – fines as well as the negative impact on a company’s brand, reputation and finances – the investment comes cheap.
SQL Provision helps organizations to mitigate against the risk of malicious behavior or employee negligence by enforcing a restriction on where sensitive information is stored – in most cases it should never live outside production. Wherever sensitive data exists, even for just a short while, there’s the risk that it will be exposed. Therefore, whenever a new development or test environment is created, or needs fresh data, it should be done so with the data already masked. This way, the period when sensitive data lives outside of production is reduced to zero.
Organizations such as KEPRO, a US healthcare provider, and PASS, the global community association for SQL Server, have already implemented SQL Provision to ensure compliance with data privacy legislation. What’s more, because it now takes just seconds to create sanitized local databases, with each one using a tiny 40MB of disk space, they’ve also been able to shorten their development cycles and save on disk space too. Further reasons then, why SQL Provision should be at the top of your procurement list.
To learn more, visit the SQL Provision product page.
Was this article helpful?