UTILISING TRANSPARENT DATABASE ENCRYPTION (GDPR)
If you currently work within the IT industry/department, then I would be very surprised on what you are actually doing if you have not yet come across GDPR or you should be already in the process of assessing what your organisation/Business needs to do to prepare for GDPR. In short, GDPR takes over existing data protection legislation within EU countries on May 25th 2018 (for the UK, this will be the Data Protection Act 1998). GDPR brings data protection guidelines firmly into the 21st century and provides a framework for organisations to apply the appropriate steps to protect individuals data. Whilst there is much within the updated guidelines that remain unchanged, there is additional emphasis towards organisations implementing the appropriate levels of security (both physical and technical), applying regular auditing processes and documentation of processes to protect against a possible data breach. For any IT professional, one of the overriding questions you should be starting to ask yourself right away while reading this is “What can you do to make the systems you support/implement strongly compatible with GDPR?”
Dynamics CRM/Dynamics 365 for Enterprise (CRM/D365) is one system that is likely to be in place within businesses/organisations across the EU, and one that is arguably best placed to help meet the challenges that GDPR brings to the table. The wide berth of functionality within the application can be picked up and adapted to suit the following requirements:
Provide backend database encryption, to protect your key customer data in the event of a data breach.
Ensure that highly sensitive data categories are only accessed by relevant personnel within your organisation.
Enables you to implement a clear and comprehensive security model within your system, that can then clearly documented.
Helps you to implement a data retention policy that is line with contractual and statutory requirements.
Allow you to quickly and effectively respond to subject access requests, via the use of easy to generate document templates.
All of the above can be achieved using out of the box functionality within the Dynamics CRM application and, in some cases, can be more straightforwardly than you may assume.
I will take a look at each of the bullet points above, step by step in different series of my posts. The aim of this is to highlight the specific elements within GDPR that each potential situation covers, how to go about implementing a solution within CRM/D365 to address each one and to provide other thoughts/considerations to better prepare yourself for GDPR. By doing so, I hope to make you aware of functionality within the application that hitherto you may never have looked at before and to explore specific use cases that provide a wider business relevance.
All posts I write on GDPR will make frequent references to the text contained within Regulation (EU) 2016/679 to make it universal for anyone who is looking or carrying out considerations in their Business, available online as part of the Official Journal of the European Union – a particularly onerous and long-winded document. If you are based in the UK, you may find comfort in reading through the ICO’s instead rather high level Overview of the General Data Protection Regulation (GDPR) pages, where further clarification on key aspects of the regulation can be garnered.
Understanding and effectively utilising Transparent Database Encryption within your CRM/D365 deployment.
One area within GDPR that has changed significantly is data breaches and penalties for organisations that have demonstrated a clear dereliction of their responsibilities. When assessing whether a fine is issued by your countries appropriate authority, which could number in the millions of £’s or more, a determination is made whether the company has implemented sufficient technical controls to mitigate the potential impact of a data breach. Article 32 sets this out in broad terms:
Taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing as well as the risk of varying likelihood and severity for the rights and freedoms of natural persons, the [Data] controller and the [Data] processor shall implement appropriate technical and organisational measures/policies to ensure a level of security appropriate to the risk, including inter alia as appropriate:
(a) the procedure and encryption of personal data;
(b) the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services;
(c) the ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident;
(d) a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing.
It is worth noting that an assessment will be made of your businesses size, turnover etc. when a judgement is made on what “appropriate” steps your organisation has taken to mitigate their risk in this regard. Smaller businesses can, therefore, breathe a sigh of relief in not having to implement large scale and costly technical solutions within their businesses. Speaking more generally though, the importance of encryption within your organisation’s database and application systems becomes a primary concern in demonstrating GDPR compliance. It could also help you when it comes to determining whether you need to report a Data Breach, as an encrypted piece of hardware does not necessarily expose personal data; arguably meaning that no data breach has occurred.
Dynamics CRM/D365 gives us the option to utilise a well-established tried and tested feature within SQL Server to implement encryption for our data – Transparent Database Encryption.The good news for you all is that this function is already enabled by default. That being said, it is paramount for you to take a copy of the default encryption key or change it entirely if you haven’t done so already and ensure its stored securely.
Doing either of the above is relatively straightforward. Navigate to Settings -> Data Management within Dynamics CRM/D365 application and then click on the Data Encryption icon:
The Data Encryption pop-up window will appear, as indicated below:
From here you have two options at your disposal:
Use the Show Encryption Key to allow you to copy and paste the key to your location of choice. Note that as outlined by Microsoft, the key may contain Unicode characters, leading to a potential a loss of data when using applications such as Notepad.
Generate a new key that meets the requirements set out above and then click on Change.
In both cases, ensure that the encryption key is stored securely and segregated as far away as possible from your CRM/D365 deployment. Keep in mind as well that there are specific privileges that control if a user can access the above or even modify the encryption key in the first place. These privileges can be found on the Core Records tab within a Security Role page:
It may be tempting, knowing that encryption is enabled by default, to put your feet up and not worry much about it can be costly in complying with the GDPR regulations. Here’s why it’s critical to securely hold/segregate your database encryption key and also to think carefully about which users in your organisation/Business have full Administrative privileges on the application best practice will be to have minimal users with Adminstative role:
Let’s take the the following scenario as an example: your on-premise CRM 2016 organisation has database encryption enabled and SQL Server is installed on the same machine, along with all database files. The database encryption key is saved within a .txt file on the same computer.
An employee like a child in a candy shop has full Administrative privileges on CRM or an attacker manages to gain access to this server, in the process taking your CRM organisations .mdf database file (Backup File). They also manage to either take a copy of the .txt file containing the encryption key or the currently configured encryption key by accessing your CRM instance. This person now has the ability to both mount and access the database file without issue. Under GDPR, this would constitute a data breach, requiring your business to do the following as immediate steps:
Notify the supervisory body within your country within 72 hours of the breach occurring (Article 33)
Notify every person whose personal data was stored in the database that a breach has occurred (Article 34)
Record the nature of the breach, the actual effect caused by it and all remedial steps taken to prevent the occurrence of a breach again in the future. All of this may be required by the supervisory body at any time (Article 35) Remember the damage all the consquences of a the above three can have on your organisation or Business/Organisation, (EXPECT LOSSES ,POTENTIALLY COST YOU YOUR JOB, BE VIGILANT)
The fun does not stop there: depending on what processes/procedures your Business/Organisation have in place and, given the specific nature of the scenario, a fine of 4% of your anunnal Business/Organisation revenue may be more than likely. This is due to the clear steps that could have been taken to prevent the database from being so easily accessible. Having to explain this in front of senior executives/directors within your business is not a prospect any of us would particularly look forward to as this could have been avoided had the following steps below which could have been implemented:
The employee like a child in a Candy shop had been given a much more restrictive security role, that did not grant the Manage Data Encryption key – Read privilege.
The SQL Server instance had been installed on a different server.
The database encryption key had been saved on a different server
The database encryption key had been saved in a password protected/encrypted file.
This list is by no means exhaustive, and there is ultimately no silver bullet when it comes to situations like this; however, you can manage your risk much more effectively and demonstrate to authorities like the ICO that you have taken reasonable steps by taking some of the appropriate steps to comply with the regulations.
Always remember to carefully look at your considerations and make reasonable efforts.
Dynamics CRM/Dynamics 365 for Enterprise (CRM/D365) is one system that is likely to be in place within businesses/organisations across the EU, and one that is arguably best placed to help meet the challenges that GDPR brings to the table. The wide berth of functionality within the application can be picked up and adapted to suit the following requirements:
Provide backend database encryption, to protect your key customer data in the event of a data breach.
Ensure that highly sensitive data categories are only accessed by relevant personnel within your organisation.
Enables you to implement a clear and comprehensive security model within your system, that can then clearly documented.
Helps you to implement a data retention policy that is line with contractual and statutory requirements.
Allow you to quickly and effectively respond to subject access requests, via the use of easy to generate document templates.
All of the above can be achieved using out of the box functionality within the Dynamics CRM application and, in some cases, can be more straightforwardly than you may assume.
I will take a look at each of the bullet points above, step by step in different series of my posts. The aim of this is to highlight the specific elements within GDPR that each potential situation covers, how to go about implementing a solution within CRM/D365 to address each one and to provide other thoughts/considerations to better prepare yourself for GDPR. By doing so, I hope to make you aware of functionality within the application that hitherto you may never have looked at before and to explore specific use cases that provide a wider business relevance.
All posts I write on GDPR will make frequent references to the text contained within Regulation (EU) 2016/679 to make it universal for anyone who is looking or carrying out considerations in their Business, available online as part of the Official Journal of the European Union – a particularly onerous and long-winded document. If you are based in the UK, you may find comfort in reading through the ICO’s instead rather high level Overview of the General Data Protection Regulation (GDPR) pages, where further clarification on key aspects of the regulation can be garnered.
Understanding and effectively utilising Transparent Database Encryption within your CRM/D365 deployment.
One area within GDPR that has changed significantly is data breaches and penalties for organisations that have demonstrated a clear dereliction of their responsibilities. When assessing whether a fine is issued by your countries appropriate authority, which could number in the millions of £’s or more, a determination is made whether the company has implemented sufficient technical controls to mitigate the potential impact of a data breach. Article 32 sets this out in broad terms:
Taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing as well as the risk of varying likelihood and severity for the rights and freedoms of natural persons, the [Data] controller and the [Data] processor shall implement appropriate technical and organisational measures/policies to ensure a level of security appropriate to the risk, including inter alia as appropriate:
(a) the procedure and encryption of personal data;
(b) the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services;
(c) the ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident;
(d) a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing.
It is worth noting that an assessment will be made of your businesses size, turnover etc. when a judgement is made on what “appropriate” steps your organisation has taken to mitigate their risk in this regard. Smaller businesses can, therefore, breathe a sigh of relief in not having to implement large scale and costly technical solutions within their businesses. Speaking more generally though, the importance of encryption within your organisation’s database and application systems becomes a primary concern in demonstrating GDPR compliance. It could also help you when it comes to determining whether you need to report a Data Breach, as an encrypted piece of hardware does not necessarily expose personal data; arguably meaning that no data breach has occurred.
Dynamics CRM/D365 gives us the option to utilise a well-established tried and tested feature within SQL Server to implement encryption for our data – Transparent Database Encryption.The good news for you all is that this function is already enabled by default. That being said, it is paramount for you to take a copy of the default encryption key or change it entirely if you haven’t done so already and ensure its stored securely.
Doing either of the above is relatively straightforward. Navigate to Settings -> Data Management within Dynamics CRM/D365 application and then click on the Data Encryption icon:
The Data Encryption pop-up window will appear, as indicated below:
From here you have two options at your disposal:
Use the Show Encryption Key to allow you to copy and paste the key to your location of choice. Note that as outlined by Microsoft, the key may contain Unicode characters, leading to a potential a loss of data when using applications such as Notepad.
Generate a new key that meets the requirements set out above and then click on Change.
In both cases, ensure that the encryption key is stored securely and segregated as far away as possible from your CRM/D365 deployment. Keep in mind as well that there are specific privileges that control if a user can access the above or even modify the encryption key in the first place. These privileges can be found on the Core Records tab within a Security Role page:
It may be tempting, knowing that encryption is enabled by default, to put your feet up and not worry much about it can be costly in complying with the GDPR regulations. Here’s why it’s critical to securely hold/segregate your database encryption key and also to think carefully about which users in your organisation/Business have full Administrative privileges on the application best practice will be to have minimal users with Adminstative role:
Let’s take the the following scenario as an example: your on-premise CRM 2016 organisation has database encryption enabled and SQL Server is installed on the same machine, along with all database files. The database encryption key is saved within a .txt file on the same computer.
An employee like a child in a candy shop has full Administrative privileges on CRM or an attacker manages to gain access to this server, in the process taking your CRM organisations .mdf database file (Backup File). They also manage to either take a copy of the .txt file containing the encryption key or the currently configured encryption key by accessing your CRM instance. This person now has the ability to both mount and access the database file without issue. Under GDPR, this would constitute a data breach, requiring your business to do the following as immediate steps:
Notify the supervisory body within your country within 72 hours of the breach occurring (Article 33)
Notify every person whose personal data was stored in the database that a breach has occurred (Article 34)
Record the nature of the breach, the actual effect caused by it and all remedial steps taken to prevent the occurrence of a breach again in the future. All of this may be required by the supervisory body at any time (Article 35) Remember the damage all the consquences of a the above three can have on your organisation or Business/Organisation, (EXPECT LOSSES ,POTENTIALLY COST YOU YOUR JOB, BE VIGILANT)
The fun does not stop there: depending on what processes/procedures your Business/Organisation have in place and, given the specific nature of the scenario, a fine of 4% of your anunnal Business/Organisation revenue may be more than likely. This is due to the clear steps that could have been taken to prevent the database from being so easily accessible. Having to explain this in front of senior executives/directors within your business is not a prospect any of us would particularly look forward to as this could have been avoided had the following steps below which could have been implemented:
The employee like a child in a Candy shop had been given a much more restrictive security role, that did not grant the Manage Data Encryption key – Read privilege.
The SQL Server instance had been installed on a different server.
The database encryption key had been saved on a different server
The database encryption key had been saved in a password protected/encrypted file.
This list is by no means exhaustive, and there is ultimately no silver bullet when it comes to situations like this; however, you can manage your risk much more effectively and demonstrate to authorities like the ICO that you have taken reasonable steps by taking some of the appropriate steps to comply with the regulations.
Always remember to carefully look at your considerations and make reasonable efforts.
Comments
Post a Comment