A major problem in the commercial world is getting people to look after their data. Too often, a staff member will save sensitive data in a document without adequate protection, bypassing all logical controls set up by the system administrator.
How do we solve this? Ask everyone to apply strong Access Control Lists to all data that they save? This would cause problems:
-A lot of wasted effort if the data is not sensitive
-For the sensitive data, how should one apply the ACLs? Which people should be allowed to access it?
A common solution has been to use the concepts of security classification from the defence world.
You’ll recall all those documents in James Bond movies marked ‘Top Secret’ and ‘For Your Eyes Only’. Well, this can be applied to the different types of data in an organisation. You can make up your own labels, but I’ll use these four:
| Top Secret | -Could harm organisation if made public -Secret keys -Take over plans |
-Store encrypted -Backup encrypted -Transmit encrypted |
| Secret | -Board meeting minutes -High value contracts |
-Transmit encrypted -Backup encrypted |
| Restricted | -Low value contracts | -Transmit encrypted |
| Public | -All other material | -Unprotected |
Now we have this, we can decide what type of data falls into each classification:
| Top Secret | -Could harm organisation if made public -Secret keys -Take over plans |
-Store encrypted -Backup encrypted -Transmit encrypted |
| Secret | -Board meeting minutes -High value contracts |
-Transmit encrypted -Backup encrypted |
| Restricted | -Low value contracts | -Transmit encrypted |
| Public | -All other material | -Unprotected |
This enables staff to know how to categorise data.
Now we add details of how the data is to be protected:
| Top Secret | -Could harm organisation if made public -Secret keys -Take over plans |
-Store encrypted -Backup encrypted -Transmit encrypted |
| Secret | -Board meeting minutes -High value contracts |
-Transmit encrypted -Backup encrypted |
| Restricted | -Low value contracts | -Transmit encrypted |
| Public | -All other material | -Unprotected |
So now staff can see how to handle each type of data. The table above would probably be a lot larger for most organisations, but you get the point. Staff can now identify the type of data, and from that they are able to use the correct safeguards.
Encryption of sensitive data at rest and in backups is very common for major institutions. This can be a very computationally intensive and difficult to implement control.
SQL Server 2008 introduces a new tool called Transparent Data Encryption. This encrypts data at the page level of the database, but decrypts it as it is read into memory. And it doesn’t increase the size of the database!
The encryption is performed by a database encryption key (DEK). This is a symmetric key, which is then encrypted by a certificate stored in the master database of the server. This is then protected using the DPAPI.
The following slide from MSDN makes things a little clearer.
.gif)
This is great news for those of us who work in compliance related positions, such as security consultancy. A lot of effort has previously gone into development of solutions or selection of third party tools that provide this protection. Now SQL database administrators can provide this with minimal financial cost to the organisation.
