Compliance Importance

Service delivery includes the protection and the integrity of content created. Like security, compliance is cross platform, cross industry. It does not matter whether you are simply using SharePoint, or using multiple platforms to service content into SharePoint.

Compliance concerns:

• Monitoring, isolation, automated operations, secure network and encrypted data.
  
• Security best practice, and the customer controls.
  
• DPL, audit and retention, eDiscovery and Data spillage.
  
• Standards such as ISO 27001, FISMA, HIPAA BAA, EU Model Clauses, and the CSA.
  

Note – this article is geared to looking at SharePoint on-premise. Office 365 is pretty much covered on encryption technologies. There is a wealth of information concerning this and more the Microsoft Office 365 article on this link: Data Encryption Technologies in Office 365. Also, there is also a huge amount of information available in its Trust Centre. There is a specific section concerning compliance on this link: Continuous Compliance in Office 365

Encryption is a solution against Data Breaches

Data Breaches are not simply relegated to external infringement of data by those who should not have access. This is an ongoing problem, and regulators are ramping up audits and confirming standards to ensure companies are taking heed. Some data breaches can occur for any of the following reasons:

• Data copied and taken off premises
  
• Downloading information then emailing the data unprotected to external parties
  
• Saving content to a folder which is publicly available online
  
• Provisioning of production data in test or development systems
  

Protecting against data breaches therefore must consider the data at the location where it is saved. Encryption of the data is without doubt the highest level of protection the data can get to prevent that data being subject to a data breach. However, the human culture of how they handle security matters is also extremely important.

SharePoint Data Security

When data ends up in SharePoint, the content is stored in SQL (at rest), except in the case of RBS (Remote Blob Storage). The data in SQL is ‘unstructured’, meaning, that it is not ‘easy’ to simply dive in and set security on specific bits of data. The data is also ‘unknown’, meaning that it is not also ‘easy’ to identify what data relates to what area and in what context – and even if you could, securing that would be a difficult in the extreme.

SharePoint, ‘Out-Of-The-Box’, provides access controls only to protect the data based on the role of the user. These access controls include:

• Permissions access to the data
  
• Auditing controls, stamping of data, lock down.
  

However, there are data encryption components provided ‘Out of the Box’ for SharePoint. Data could be read in a number of ways (described below). And again, confusion reigns from people trying to get to grips with the options. Some people even confuse authentication with encryption. I have even heard a client state that surely provisioning SSL will provide encryption. That client had to be informed that SSL only secures the network connection to the link where the data can be accessed (that is, Data in Transit, NOT Data at Rest). It does not protect the data from being ‘read’ at its source. Anyone unsure of this should check out this article Do you need SSL?

Compounded is the challenge humans the culture they apply to security – it is not simply a ‘one hat fits all’. From people I have spoken to and worked with on this topic, it is generally stated that users are simply not taking enough security measures to protect the data. Yes, one could very easily apply role permissions to ensure that individuals cannot read, write, or even upload. Provision of auditing tools to alert individuals of unwanted access is possible. Locking down of data so that the data cannot be modified or downloaded is possible. However, those solutions is not on the same plain as the protection (encryption) of the data where it is stored. For example, if a disk holding data was subject to attack / access from those who should not be able to read the data at source, then surely that is an out of compliance and classed as security risk. Indeed, taking a SQL SharePoint content database off a disk, and then applying that content database into another web application in another farm is relatively easy. Even if that operation takes place unless under strict and controlled circumstances (note that in some cases a challenge to implement, especially when working with multiple technical teams like a separated team for SQL, Windows, SharePoint, etc.) the mere fact that the data is in a read-able form when transmitted could be still construed as a data compliance issue.

The solution is looking at the data within SQL; that requires ‘security hardening’ and encryption solve these challenges.

Implementing encryption for Data at Rest starring SQL

As pointed out, SharePoint data resides in SQL. That is the point where encryption should be brought into play. Microsoft recognised this way back with the implementation of SQL 2008 and provided two technologies to protect ‘data at rest’ meeting various compliance standards. Thankfully, the architecture is in place to provide, since SQL provides the ability to have the data encrypted, using the following technologies:

• EKM – Extensible Key Management
  
• TDE – Transparent Data Encryption
  

Details of these technologies are available here:

Understanding Transparent Data Encryption (TDE)

Switching on encryption is not just a ‘fire and forget’ action. A number of tasks must be completed beforehand in order to deliver the service:

1. The environment must be modelled first; for example, identifying the number of users, size of documents, underlying infrastructure, specific technical roles and skill set.
   
2. Disaster Recovery environment and enabled technologies. Check the infrastructure applied to the SharePoint farm concerning DR. Check whether RBS is in use which will impact on how encryption is to be applied – note that TDE does not apply to content in a file stream because that content is not encrypted in SQL so additional encryption methods would have to be applied.
   
3. Key management – who is responsible for managing the key – is it the SharePoint team? The SQL team? The Security team?
   
4. Advise your corporate security team including any stakeholders of the impact of encryption. There is a technical as well as business impact. The technical side is a degradation of overall performance. From investigations I’ve been advised this could be up to 2% overall. On the business side is an impact on support, particularly from SQL and Security, since they have an extra accountability to the management of the encryption. Note also, that you should test this thoroughly in a isolated test environment and against DR and run DR tests.
   
5. Apply Encryption at Rest for SQL, and for this, TDE must be implemented. Remember, TDE is used to prevent the restoration or attachment of databases into another SQL instance. This means that a master key needs setup, the database requires configuration, and the encryption password (stored in the certificate) must be backed up. Then, all must be tested (i.e. backup, restore – which should fail – then restore again along with the key – which should work).
   
6. Ensure connections to SQL are encrypted. This means protection from those attempting to use tools to get at the data. This means forcing encryption settings to enabled for the SQL server and applying the certificate.
   
7. Prevent other machines accessing the SQL instance (i.e. attempting to connect a different farm, or a machine outside of the ‘allowed server authentication list’ to a SQL instance being protected), you would setup isolation rules by configuring the firewall on the relevant servers themselves.
   

Note – doing this by yourself in a company with multiple teams looking after the infrastructure is unwise. You should seek aid from your SQL teams, as well as advice from Server teams.

To get detailed information on how to technically deliver encryption for SQL as well as isolation, step by step, check out the excellent article on this link:

Securing SharePoint: Harden SQL Server in SharePoint Environments

Conclusion

A key aspect of Data Compliance is the protection of data. Companies use data compliance to protect data, provide policies, processes and systems, and this stretches to governments and individuals. This is cross platform, and cross technology.

In Sharepoint, in order to meet data compliancy challenges and provide solutions through service delivery, there must be understanding that there is encryption tools available to data where that data resides. Encryption is the keyword here, since through this article I have explained how data can be securely stored and protected from unwarranted access.

SQL provides encryption and key management tools so that the data becomes unreadable to anyone except those who should have access to that data, using key management to automatically convert data back to its original, readable form. There are additional opportunities available to harden the SQL platform so that there is isolation and authenticated access.

The implementation of encryption though, whilst relatively easy from a technical viewpoint, provides many challenges to overcome in implementation. Security awareness, and identifying shortfalls in the surrounding infrastructure is vital, along with the marrying up of the roadmap of SharePoint. Implementing future technologies down the line will have an impact on encryption, so ensuring that you continually review encryption usage and change management is necessary.