Rethinking stored document encryption: Part 5
Continuing our series on content level encryption we are finally in a position where we can encrypt something. How does the user go about this?
If we want the user to actually use encryption on a regular basis, the answer is going to have to be that the user will have to do as little as is possible, ideally nothing whatsoever.
Ideally we would want the security policy to be inferred automatically from the user's normal workflow. If the user starts a new document using the 'Company Confidential' template this should automatically cause the appropriate security policy to be set for that document, including causing the document to be saved in encrypted form by default.
DRM schemes typically take the view that in order to talk about security policy it is necessary to have a language to express the security policy that is understood by every potential policy enforcement point. This then segues into a highly proprietary policy descruiption language and an equally proprietary mechanism for distribution of the same.
But CLE is not DRM and since the type of control we wish to provide involves distributing confidential documents to typically tens, rarely hundreds and very exceptionally thousands of recipients we do not need to make every potential document reader a policy enforcement point. Accordingly we have no requirement to standardize the policy description langauge or to distribute it amongst the policy enforcement points.
We do however have a requirement to be able to reference the security policy description so as to allow statements of the form 'this content is to be controlled under the X security policy',
Fortunately this is where the World Wide Web comes to the rescue. A security policy is just a resource like any other and is thus described by means of a URI.
For example, BizyBank might have the following security policies defined:
- http://secpolicy.bizybank.com/confidential
- Company confidential, document may only be circulated inside the company or with outside partners under a specified NDA
- http://secpolicy.bizybank.com/unrestricted
- The document may be shared without restriction
- http://secpolicy.bizybank.com/executive
- The document may only be read by the author and the executive team
- http://secpolicy.bizybank.com/customer
- The document an only be read by the author and the specified customer
In each case the summary descriptions of the security policies omit a great deal of detail that becomes essential in a real-world situation. In practice, every document is in the final analysis property of the company rather the individual and there will be a need for exceptions and for processes to manage the exceptions.
There would also be a need for security policy to be considered as an aspect of the overall document process model. In most cases 'public' is a property that a document will only achieve at the end of its development lifecylce, if ever. In the typical case a document intended for publication will begin life as a confidential document, undergo a process of editing and internal review. If management of the security policy is to be transparent it must be driven by the processes that support the review cycle.
From this we may deduce that in the enterprise a document should be encrypted by default and that it is the conversion to enclair that should require affirmative intervention.
But this conclusion is not the same as saying that by default a document should be considered company confidential. On the contrary, if we are to take company confidential status seriously we must accept that this entails considerations of process.
When Alice creates a new document in Word or OpenOffice the default should be that the document file created be encrypted with decryption blocks for Alice and the key management system and giving Alice complete control over who is granted read access.
A stricter security is only required if Alice is in a position of specific responsibility that requires greater control or explicitly selects a particular security policy (e.g. by selecting a specific document template). Contrawise, if Alice wishes to save the document without encryption she must make an explicit decision to do so.
By default the files are protected against the primary negligence risks identified at the start of this series. The files saved to disk can be safely exchanged via email or USB thumdrive without concern.
Protected content may be flagged to advise applications that they should not allow the user to change the security policy under which they are controlled but we do not insist on the implementation of an infrastructure to ensure compliance. As with paper documents, an authorized reader may defect but this requires an intentional act such as disabling the malware scanner on the machine or loading a deliberately compromised application.
What we have not done so far is to allow Alice to share the file with anyone other than herself. That is the next step.
