Paper War

A little less could be more

If you wish to build the IT Security measures of a company on solid ground there is no way around defining these measures in documents containing IT Security policies and guidelines. However, even the best security measures become obsolete sooner or later and thus dysfunctional. The same is true for security policies and guidelines. In practice, the problem frequently arises that it is not recognised at management level that neither the security measures nor the underlying policies and guidelines represent the state of the art and best practices any longer and that part of the security mantel consists of false security. Consequently, it is recommended that security measures are evaluated with regard to their actuality and effectiveness at regular intervals. Regular IT security audits is a good framework for this purpose.

At the same time it is a good idea to scrutinise existing internal policies and guidelines for validity and actuality. Only with the definition provided in a company-wide security standard and the accompanying guidelines specifying how the policies should be converted to practical measures, is it possible to introduce and maintain security measures that are sensible and targeted.

When it comes to the company guidelines, however, they can often result in a full-scale paper-war. Even in smaller enterprises you often see policy documents the size of an EU directive. E. g. I know a company that has published no less than 384 new corporate IT security guidelines over a nine year period! Some guidelines complement others, some guidelines cancel older guidelines and a lot of the guidelines are grossly contradictory. Small wonder, then, that few employees know what the current guidelines stipulate, let alone abide by them.

I can't be able to say whether this regulatory pain is something that can be labeled as specifically German. lt is my impression, however, that the errors made within the realm of corporate policies in General and IT security pohcies in particular are similar across Europe. If so, it is in general possible to limit the river of policy statements drastically by following a few rules.

Recommendations
By and large it cannot be recommended to replace existing guidelines with expanded or revised versions. Because of the familiarity among company staff with existing guidelines it makes sense to retain guideline numbers and/or titles and include new details as addenda to existing guidelines instead. This procedure serves to ensure that users always connect a certain guideline number and name with a particular content. In practice this leads to a kind of unmistakable policy statement identity.

Furthermore, it is highly recommended to make it possible for users to find all guidelines covering a particular, or related, theme(s) under a relevant and well-known general title or buzzword. E.g. it is recommended within the area of IT security to institute throughout the organisation, one general IT security policy under the key IT Security, together with an index of all subordinate guidelines. Insofar as it is possible these should be combined into one single guideline statement. On the internal web they should be locatable by searching for IT Security as well as the individual guideline numbers and subtitles. In most cases the only good reason for splitting a guideline up into several would be because one set of guidelines were required for end users and a different technically and organisationally oriented set, for system administrators and management.

Standards for documents and classification of information
It is a conspicuous fact that in many companies no standard exists for classification and naming of documents. One consequence is that it is impossible for the users to know to which (if any) extent the circulation of a particular document is restricted. The recommendation here is for companies to introduce a company-wide guideline specifying the classification of document contents and a corresponding document or distribution code. It must be possible to tell from the document code (and each and every document must have one), who the author of the document is (name/job title), to which department the author belongs, the date of publication and which group of users are allowed access to the document. Optionally a version number may be used to tell how often the document has been revised or changed after its original publication.

It is also possible to specify a particular corporate date formal in this guideline. The author of a document is responsible for its classification. [Last time your humble editor invented and implemented such a document classification system an automatic expiration date was included, indefinite not among the options. Did wonders with regard to some of the document revision problems listed above. -ed].

Through this type of measures it is possible to introduce information classification inexpensively and in a reasonable span of time thus introducing information transparency throughout the organisation without introducing security problems for parts of the organisation. Without such a procedure in place you cannot implement meaningful access restrictions for information of importance to the organisation. As part of this exercise it is necessary to find out where sensitive information is created, where it is stored and who should be allowed to access the sensitive information. This done, it becomes easy to implement useful guidelines and enforcing these for information on paper as well as on other media.

As evidenced by these recommendations it does not have to be particularly complicated or difficult to reduce the paper-war to a bare minimum. You do need to make the effort, though...