Information assurance and encryption

Alison Gibney spoke to the June meeting of the IRMS London Group about the relationship between the disciplines of information assurance and records management.

Alison differentiated  information assurance from information security.  Information security covers any type of information an organisation wants to protect, whereas information assurance is focused on protecting personal data.    There is no US equivalent term, partly because the US legislation on personal data is less strict than that of the UK.

Alison said that in the UK public sector over the last five years records management has gone down a peg or two (thanks to budget cuts) , whilst  ‘information assurance’ has gone up a few pegs.  The rise of information assurance is thanks to the various high profile central government data leaks in 2007 and 2008; the Hannigan report which compelled UK government bodies to adopt a strong information assurance regime in response to those leaks; and the fines meted out by the Information Commissioner for non-compliance with the Data Protection Act.

Alison showed a list of the fines meted out by the Information Commissioner over the past few years.  She pointed out that a significant proportion of the fines had gone to local authorities.  This was not necessarily because local authorities are worse at managing personal data than, say, a private sector retail company.  It is more likely to be because local authority have literally hundreds of different functions that necessitate the collection, storing and sharing of personal data, whereas a retail operation may only have three or four such functions.  It is very hard for a local authority to ensure that all these many different functions are fully compliant with data protection legislation.

Alison also pointed out that most of the fines could be ascribed to two generic types of breaches:

  • communications being sent to the wrong person
  • loss or theft of removable media

These two types of generic breaches both occurred across a range of formats, digital and hard copy.   Communication misdirections included misdirected e-mail, letters and faxes.  Loss and thefts of removable media included losses of laptops, key drives and hard copy files.

When to encrypt and when not to encrypt

Alison said that encryption offered a solution to the problem of protecting personal data in certain circumstances.
Alison recommended encrypting:

  • personal data in transit (for example data being e-mailed to a third party) because of the risk of interception or misdirection
  • personal data on removable media (optical disks, laptops, mobile phones etc) because of the risks of loss or  theft

Alison did not recommend encrypting ‘data at the rest’ in the organisation’s databases/document management systems.   But she raised a question mark over data in the cloud.  Technically it is data at rest.  But it is data held by another organisation, possibly within a different legal jurisdiction, and the organisation may wish to encrypt because of that.

It is worth taking a closer look at the issues around the encryption of the different types of data that Alison mentioned.

Encrypting data in transit – e-mail

There are various ways of encrypting e-mail.   A typical work e-mail travels from a device, through an e-mail server within the organisation, to an e-mail server in the recipient’s organsiation, to the device of the recipient.  There are security vulnerables at any of those points.  Devices bring in a particular vulnerability particularly since the rise in usage of smartphones and of trends such as ‘bring your own device’.

The most secure option is for the message to be encrypted all along the chain.   However the further along the chain the e-mail is encrypted the more complex, expensive and intrusive the encryption software and the procedures for applying it become.   Chapter 4 of this pdf hosted by Symantec gives a neat summary of the different options for e-mail encryption.

If you decide to encrypt messages from the moment they leave the sender’s device  all the way to the recipient’s device (endpoint to endpoint) then both the sender and the recipient will need encryption software installed on their device.  This is intrusive for both parties.  It may be reasonable to expect organisations that you regularly exchange sensitive data with to have such software installed.  It would not  be reasonable for a local authority corresponding with a citizen for the first time to expect the citizen to install such software.

A less intrusive option  is ‘gateway to gateway’ encryption.  The  message goes in plaintext from the sender’s device to a gateway server inside their organisation. The gateway server encrypts it.  When it reaches the recipient organisation it is decrypted by a gateway server which sends it on in plaintext to the recipient.  Note that this model requires the recipient organisation to have the same encryption software installed on their gateway server as is used by the sending organisation.

A lighter approach to encryption is the gateway-to-web approach where a standard plaintext e-mail is sent to a recipient giving them a link to a web address where they can go to retrieve the message which is protected by some kind of transport layer encryption such as SSL (Secure sockets layer – as used to  protect credit card transactions on the web).  The web site will ask the user for authentication.  Assuming that the authentication details have been sent to the user by a different channel other than e-mail, this will provide some protection against an e-mail being sent to the wrong recipient.  In her talk Alison had informed us that 17 London boroughs had chosen encryption software from one particular vendor (Egress) – that uses this gateway- to-web model.  Although this is a lower level of security than endpoint to endpoint encryption, it has the crucial advantage that the recipient does not need to install encryption software.

Encrypting data on removable media

Encrypting personal data on removable devices is the most straightforward of the cases that Alison mentioned.  The individual who owns the device it with their (public) encryption key.  Only they have the (private) encryption key necessary to decrypt it.  If the device gets lost or stolen the data is safe so long as the person who gets it does not get the decryption key.

Encryption and data-at-rest

Bruce Schneier points out in his post Data at Rest vs Data in Motion ( that cryptography was developed to protect data-in-motion (military communications), not data-at-rest.   If an organisation encrypts the data it holds on its on-premise systems then it faces the challenge of maintaining through time the encryption keys necessary to decrypt the data. Schneier puts it succintly:  ‘Any encryption keys must exist as long as the encrypted data exists. And storing those keys becomes as important as storing the unencrypted data was’ .  If you are encrypting the data to guard against an unauthorised person overcoming the system’s security model and gaining access to the data, then logically you cannot store the decryption keys within the system itself (if you did you would not have guarded against that risk!).

Encryption and data in the cloud

Most organisations have regarded data at rest within their on-premise information systems as being significantly less at risk than data on removable devices and data in transit, and therefore do not encrypt it.

But what about data in the cloud? There are certain features of cloud storage that may lead your organisation to wish to encrypt its data.  You may be concerned that a change of ownership or a change of management at your cloud provider might adversely impact on security.  You might be worried that the government of a territory in which the information is held may attempt to view the data.  You may be concerned about the employees of the cloud provider seeing the data.  However fundamentally speaking, data in the cloud is data-at-rest.  It is data that is being stored not communicated.  .  If you encrypt your cloud data you have the same problem as you would have if you encrypted data on your on-premise systems – how do you ensure that you maintain the encryption keys over time, and where do you store them?  If your reason for encrypting is a lack of trust of the cloud provider then storing the decryption keys with the cloud provider would defeat the object.

The challenge of encryption key management

Key management is crucial to any encryption model. In theory you want the organisation to give every individual a private/public encryption key pair. That means that not only can individuals encrypt information (with their public key) that they wish to keep secret.  But you also can provide a digital signature capability because they can encrypt with their private key a signature that anyone can read with that individual’s public key.  This offers proof that the individual alone must have signed it because it could only have been encrypted with the individual’s private key.  Thus the signature is in theory non-repudiatable (the indivdual could not deny that it was they that sent it).

There are a couple of interesting issues around key management.  Do you make it so that only the individual knows their private key? – in which case the digital signature is genuinely non-repudiatable.  But if the individual loses their private key then they lose access to their signature and to information that they have encrypted.  The alternative is that the organisation provides a way for the individual to recover their private key, for example through an administrator.  But this means that the digital signature is in theory now repudiatable because the administrator could have used it to sign a message.

I am currently reading a wonderful book that explains why even two decades into the digital age there is still no widely accepted digital signature capability – the vast majority of organisations do not use digital signatures (and hence still have a need to keep some paper records of traditional blue ink signatures) The book is called burdens of proof and is written by Jean-Francois Blanchette.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s