Do We Need Baseline Security for all SQL Data Stores?

Do We Need Baseline Security for all SQL Data Stores?

Nearly 7-in-10 SMBs Do Not Encrypt Their Data At-Rest

As we should all know, audit/compliance regimes have often failed to improve security practices. And so GDPR has come along to change things. At its core are: the focus on citizen’s rights for access and for the protection of their data; pseudo-anonymity; incident response; … and … encryption. For data we thus need to understand the different states that it may exist in: data-at-rest; data-in-transit; and data in-process.

For data in transit, we are fairly well covered, especially as we increase our usage of tunnels and VPNs, and few companies would be able to set up data infrastructures without actually implementing tunnelling between systems. For data in-process we still l have a major problem, and this can lead to memory leaks of data.

But data at rest is often the weakest part of any data infrastructure, and the data here should be encrypted, in order to stop intruders (or insiders) stealing the database and simply reading its contents. A single encryption key on the whole of the database can thus — at least — provide a barrier to an intruder. In the best case, multiple encryption keys would be used, and these would be managed by a key management system.

Some research

The Townsend Security Data Privacy Blog outlines research related to the usage of encryption within SQL databases [here], and conducted it within a recent SQL conference. Overall they classified the companies as: SMB (businesses with less than 1,000 employees), Enterprise (more than 1,000 employees) and Fortune 2000 (a company with the global Fortune 2000 list).

They found that around 76% of those companies surveyed did not know if they had active key management for their SQL data infrastructure. This statistic is worrying, especially as large companies are likely to have 10s of thousands of keys, and the leakage of just one of these keys can cause significant problems.

Along with this, companies often require to rotate keys and revoke them. Without a key management infrastructure, we often rely on humans actually generating, distributing, maintaining, storing and activating keys. This type of manual operation often leads to mistakes (and is also time-consuming).

The one result that sticks out is that over half (56%) still store their data within an on-premise only infrastructure and that just over half of the Global 2000 companies had a hybrid infrastructure:

It can be seen that the move to the cloud — for data — is perhaps not moving as fast as many would have predicted, especially with security and access concerns. But perhaps one of the most worrying results is that only 68% of SMBs do not encrypt their data at rest:

While the picture is better so Enterprise/Global 2000 companies, there is still a fairly large number who are not encrypting their data. For almost 1–in-5 Global 2000 companies not encrypting their data seems to identify that there are still many large companies who leave themselves wide open to a data breach.

Conclusion

In conclusion, Townsend outline the usage of a FIPS 140–2 compliant key manager and that can scale with the data infrastructure. For me, all I can say is “Yes!”. If your company runs on data, you MUST encrypt your SQL data at rest, otherwise, you are at risk from insiders, trusted external companies and external threat actors. As a minimum, apply encryption to your data infrastructure and protect your data.

While one can understand that many SMBs often do not have the resources to properly set up an encrypted data infrastructure, there are few excuses that can be defined for enterprise-level, and certainly none for Fortune 2000 companies. Our audit/compliance regimes have often failed to push the industry towards better security, and where it becomes a tick box exercise. Now, with GDPR, our data world changes, and companies must protect our data properly, otherwise, they shouldn’t be allowed to have it.

If you haven’t already done it, go and encrypt your SQL data at rest. A proper key management system, for many large companies, must be something that is at the top of their CEO’s shopping list.

We really cannot trust humans to generate, manage, maintain and revoke encryption keys for our data infrastructure, as we are often sloppy in our practices, we can become disgruntled, and are often prone to mistakes.