By Adam Vero
…or rather, don’t use poor methods to secure documents (or anything else – this is bordering on Security Theatre). Also, don’t spend valuable IT resources securing things for users on a case-by-case basis by creating a tangled web of folders with arcane permissions on them. You need to provide the tools for your business to enable people to store things securely themselves, and educate them in how to achieve this.
This week I was asked by the IT support guy who works for one of my clients about how a user could put a password on a document. Since I am both their external consultant and their MS Office trainer, I was the right person to call.
To me this question is always a red flag as it implies that the user does not understand the places which already exist for them to save documents in such a way as to give access to the correct group of colleagues (or just themselves). My answer was therefore “I’ll show you how to do it for the sake of argument, but you should tell the user that they should not do this”.
The issue with users putting passwords on documents is that this usually leads to a problem when they leave the business, go on holiday or just plain forget what it was. I have had to use a password cracking tool a few times – once so that an HR manager could access an employment contract they had forgotten the password for, since the person was leaving and no-one was quite sure what terms applied to them. (Quite what had happened to the paper copy is anyone’s guess). This simply should not have to happen.
If one employee is off sick and their colleague phones and asks them for a password for document A, what is the betting that this is also the password for even-more-important-document B? How about their hotmail? Or online banking? People frequently make poor password choices, either in the sense that they are cryptographically weak (usually too short), or that they are shared across inappropriate environments. When making “good” choices which are unique for every document there is always the possibility of the dreaded Excel list of passwords being kept in their home directory or worse yet, printed and kept in a desk drawer.
I have a strong view that IT as a department should be an “enabler” – provide other staff the tools they need to do their jobs. This does not conflict with my other opinion that people around the business should stick to their specialism and should therefore come to IT with a requirement in their business terms, not try to guess what the IT solution should be and ask for that. Of course, this sometimes means a bit more dialogue with people to find out what they are really trying to achieve. Some business people make out they are too busy to spare the time, while many technical people may be uncomfortable with this whole idea of “dialogue” (How do you spot an extrovert IT support tech? He stares at your shoes).
There can also be perceived “power” issues when a senior business manager asks a lowly IT tech to provide or change something specific and technical – should the response be to challenge the proposed IT solution and dig for the underlying reason for wanting it? Some managers I have worked with find this effrontery unacceptable and move into foot-stamping mode; others have welcomed this approach and realise they can use my experience and knowledge of my field to deliver something which is even better at meeting their needs (which they understand better than I will).
In the case at hand, IT needed to provide a means of someone making a document secure, that was the “business need”. Office passwords would have been (in my view) a poor way to fulfil that need in this case. Not because of any inherent insecurity in the MS Office encryption but mainly because of the issues introduced by the human factor (although the user in question was on Office 2000 so there are known weaknesses, especially when using poor short passwords). Also there is a second need which is usually implied in a work context that there must be some kind of access to business data in the event of changes in or absences of personnel, which is not well addressed by individually-protected documents.
A simple, tried and tested method would be file shares with well-managed folder permissions. Great – this client has a sound documented model and set of properly-nested AD groups to implement this. Then educate the users about them – the lack of knowledge was really the underlying problem in this case and showed up a weakness in how new staff were provided with information as part of their induction process. A step further might be to introduce EFS, which requires a bit more knowledge and planning, such as ensuring that all the requisite key backups are available (especially with the requirements of RIPA in the UK). Clearly this could also be an opportunity to look into more substantial and flexible solutions such as SharePoint or a full-blown document management system (DMS). Maybe also incorporate digital rights management (DRM) for good measure.
I support the idea of the author having control over the security and use of their documents, but like any IT tool this has to be provided in a way which makes sense to the people actually using the system. While working in IT management for a law firm I went through two company mergers and was responsible for integrating the parent company’s DMS into the new sites both times. Each project involved migrating existing documents and trying to import as much metadata as possible which was implicit in the folder structure and file naming conventions in use. While this was a very challenging task from a technical point of view (700,000+ documents in the second project), the more demanding part was to understand and address the concerns of the users as to how they would benefit from this new system.
The most obvious benefit of any DMS is the metadata which goes along with the document itself to assist in finding it based on knowing a subset of its properties – maybe the author, the client it relates to, and one or more words of the title. Other reasons to use DMS are full auditing of the documents’ history (who did what when) and ability to manage multiple versions (possibly with comments about these to indicate why each exists). However, users had managed for years with highly structured folder trees and were not really going to appreciate these benefits until they had been using the system for several months.
The big change the end-users could immediately see, feel, and appreciate was the fact that we were now going to give them control over the security of their documents. That is to say that they could determine who could find, read or edit anything they created. Of course, for most documents these had defaults based on who created them, which was fine and generally did not need to be changed. For example, any document created in HR was secured down to that department’s staff by default – but they could easily add other people if necessary.
For any person who needed to, it was now almost trivial to say that a document such as a completed appraisal form was private, then allow their manager to read but not change it. Flagging a document as a read-only ‘final version’ was simple. Checking who on a circulation list had actually bothered to open and read a document was also straightforward.
Immediately after the rollout users had direct granular control of security and feedback about who had accessed or changed a document. IT had fewer calls from people needing to access documents which had been saved with inappropriate security (either in the wrong place or with password protection). Providing people with the right tools made them actually embrace security and take ownership of it rather than it remaining “an IT problem”. So don’t let users put passwords on their documents, but do give them the means to store them in a secure place, even if that is just a share with suitable agreed NTFS permissions.