ISACA Now Blog

Knowledge & Insights > ISACA Now > Posts > SQL Databases and Data Privacy

SQL Databases and Data Privacy

Robin Lyons, Technical Research Manager, ISACA
| Posted at 3:20 PM by ISACA News | Category: Privacy | Permalink | Email this Post | Comments (0)

Robin LyonsIf anyone had any doubts, data privacy is still kind of a big deal. Beyond being at the core of regulations ranging from the Health Insurance Portability and Accountability Act of 1996 (HIPAA) in the United States to the global, far-reaching General Data Protection Regulation (GDPR), data privacy has its own annual day of recognition – 28 January. As organizations design operational strategies and tactics around data privacy, opportunities to leverage applications with built-in functionality to safeguard sensitive and confidential data are valued. For those using Microsoft SQL Server 2016, there are a couple of areas where built-in functionality can assist with data privacy initiatives.

Where is the data?
Safeguarding of sensitive or confidential data generally begins with data classification. Once data has been identified and appropriately classified, the next effort is establishing internal controls commensurate with the sensitivity/confidentiality level of the data. Depending on the organization, designing and implementing internal controls may be a bit of a hurdle. In its 2017 State of Cybersecurity Metrics Annual Report, IT consulting firm Thycotic reported that 4 in 5 companies don’t know where their sensitive data is. Understandably, unknown data locations make it difficult to identify safeguards to protect the data. As in prior versions of SQL, using SQL Server Management Studio (SSMS) in SQL Server 2016 can provide a list of databases. Also, in addition to a variety of other data querying options, Transact-SQL (T-SQL) queries can be used to locate data and related tables.

Who has the data?
Having identified where the data resides, entities are faced with ensuring that access to the data is limited to those with the appropriate roles in their organizations. Once those access determinations are made (following the Principle of Least Privilege), organizations can then use Microsoft SQL Server 2016’s Dynamic Data Masking (DDM) feature to support its access strategy. With Dynamic Data Masking, sensitive/confidential data remains unchanged in the database while this data is hidden in designated database fields. Organizations can fully or partially mask the sensitive/confidential data depending on how they configure DDM.

Another option for limiting access to data is to use Always Encrypted. This feature allows encryption of sensitive data (at rest and in transit) within client applications. Since encryption and decryption happen outside of the SQL environment, it facilitates least privilege by limiting data access to those who own the data and need to view it.

As data privacy expectations become more permanent fixtures of entities’ operational landscapes, built-in features such as Dynamic Data Masking will become more commonplace. The newer DDM functionality, coupled with existing functionality through SQL Server Management Studio, can help entities achieve and maintain data privacy goals. Coupled with best practices in data management, this built-in functionality should provide an easier path to meeting the data privacy expectations of customers and compliance regulations.

Comments

There are no comments yet for this post.
You must be logged in and a member to post a comment to this blog.
Email