Levels Of Maturity In The Security Policy Development Process

Litmus Test: One high-tech company that this author was working with recently was considering the acquisition of another high-tech company. In order to gauge the sophistication of the information security effort at the target company, top management at the acquiring company requested a copy of the information security policy. The policy document in that moment became the litmus test, the single method to quickly measure the sophistication of the target organization’s efforts. Top management at the acquiring firm was surprised at how backwards and old-fashioned the target was. They got to thinking about the extent to which the target firm would be able to safeguard their valuable intellectual property, and it did not look encouraging. For the time being, the merger is off. It was simply too scary for the acquiring managers to proceed.

This sequence of events reveals one role that information security is increasingly playing in a stressed and financially uncertain economy: assurance of “mission integrity.” By mission integrity, this author means helping to guarantee that the organizational mission will be fulfilled. In other words, information security is a critical supporting effort, a critical supporting infrastructure and business function, without which the organization’s mission could not be successfully achieved. In the example just cited, the target organization’s mission was impaired because information security was not, or more specifically the information security policy was not, up to snuff.

Different Uses: The example cited here shows how information security policies are increasingly coming to be recognized as calling cards indicating just where an organization stands when it comes to information security. While a policy document is the most prominent and best-known information security document, the same can be said these days about the collection of information security documents found within an organization. The collective status of these documents reveals what has gotten attention and what has not, in addition to in what areas the organization is leading, and in what areas it is lagging.

Some time ago (Note #1), this author defined an information security sophistication curve. This hypothetical curve has discrete data points indicating the existence of, and level of refinement of, internal information security documents, which collectively indicate where a particular organization stands. For example, if no Information Security Officer has been designated within the organization, if no job description for such a person has been developed, then the organization is most likely way down on the curve, in other words its information security effort is still embryonic. But if an employee has been assigned this role, and their job description reflects that, and if there is a budget line item for information security, then the organization is getting a lot more sophisticated when it comes to information security. And taking the analogy one step further, if an organization has a refined process for managing information security risks, perhaps even with a formal documented risk management process that would be eligible for ISO 27001 certification — a process that names an information security management committee and other responsible managers — then the firm is very far along when it comes to the sophistication curve.

Levels Of A Policy: If we narrow our discussion, and apply this same notion of a sophistication curve to an information security policy document only, then three distinct hypothetical sophistication levels can be defined. Mind you, this author has no empirical evidence to back these assertions up. They are based only on his 30+ years of working in the field, and what he has observed when doing consulting work for 110+ organizations around the world. His viewpoint is also likely to be skewed because he has been working primarily in certain industries (notably finance and high-tech). But the reader can hopefully take the basic idea discussed here, and use it in a conversation with, or presentation delivered to management. Mentioning this notion of sophistication levels to management could get managers to seriously think about whether they have allocated sufficient resources to information security, and whether the organization is in fact doing all that is expected of an organization in a similar position.

So let’s define three data points on the sophistication curve. At an organization that was low down on the sophistication curve, a policy document — assuming that they had published a policy document — would typically be primarily an Internet Acceptable Use Policy. This document would most likely cover downloading porn, playing computer games while at work, using the systems for personal purposes, and related topics. The document may include words about reporting problems, specifically what needs to be reported, and to whom the reports should be directed. Typically a rudimentary access control policy based on the need-to-know will also be included in this short policy document. In many cases these policies were adopted because an auditor or business partner said it was necessary. Management’s begrudging attitude toward information security is also often evident in the policy document because whole clauses have been copied wholesale from other firm’s policy documents (or perhaps copied directly from this author’s policies book). Unfortunately, these clauses are often written in different styles, and/or make reference to terms that don’t occur elsewhere in the document.

As a second data point, consider an organization that has been doing some significant work, that is closer to average in terms of sophistication. In their information security policy, we would expect to see a data classification policy, including how to mark paper documents with different classification levels. Such an organization would also have developed a rudimentary information security architecture, which would be referenced in a policy document, and which would be designated as the authoritative source of guidance in terms of building information systems. As a more specific example, the technical components to be used in all in-house desktop computers would be defined in such an architecture. Likewise, the policy document would make reference to a systems development process, and how information security is considered in this process (for example in the requirements definition phase). An organization like this would also most likely have developed several teams, for example for incident handling, and separately for electronic discovery orders. A policy of this nature would additionally be expected to include a documented process for getting management approval to access different application systems, servers, networks, and the like.

As a third data point, a highly sophisticated organization would be expected to have a document management system into which versions of policies would be logged, and in which reviewers and approvers would be noted. This document control system would be part of a formal quality control process. The QA process would likewise show up in the testing routines used for in-house software. Such a firm may even have adopted ISO 9000 style documentation management procedures and applied them to the information security function. In such a sophisticated organization, the policy would reflect a high level of granularity in privileges for different types of workers, such as outsourcing firm personnel, business partner staff, contractors, consultants, and temporaries. This policy would also make reference to sophisticated automated controls such as encryption, digital certificates, and digital signatures. The policy would also show that the fixed password based access controls of yesteryear have given over to more sophisticated extended user authentication, such as hand-held tokens that have passwords that change once a minute. This policy would also make reference to separate extensively developed documents for both business continuity and disaster recovery. There would be more, but the reader hopefully gets the gist of what would be included.

How To Use These Levels: After reviewing these three levels of sophistication for an information security policy document, the reader might pause to discern into which category their organization is likely to fall. The important question to ask within that firm: “Does our information security policy reflect the work that has been done, and is it suitably sophisticated for our organization?” If not, perhaps it’s time for you to request some money to update the information security policy.

Of course, these three levels of sophistication are just snapshots. Many other considerations could have been mentioned. And the exact nature of the policy document’s contents will be fluid, and vary from organization to organization. These contents will change based on organizational size, home country, industry, size of the firm, technology employed, management’s attitude toward risk, and other factors.

In a more general sense, this author urges the reader to initiate an information security document audit at their organization. Such an audit can be used to determine what information security documents exist, and what documents need to exist in order to fully support current information security activities. Typically such an audit reveals the need for more awareness and training material, among many other things. An audit of this nature can also show management that it is unreasonable to expect certain results when the supporting documentation has not been prepared. For example, why would management expect systems administrators to consistently and securely configure their systems if the organization had not yet issued any explicit written guidance on how to do this?

Updates Required: The preparation of information security documents has been erroneously viewed by many to be a one-time activity. Instead, organizations need to realize that the preparation and periodic revision of policy documents is an on-going activity essential to information security success. In recognition of the many changes taking place in both the business and technical environments, information security documents need to be periodically reviewed to determine whether they are relevant, accurate, and responsive to an organization’s needs. A document audit can help organizations achieve these aims.

Note #1: See “An Overview Of Information Security Documents,” by Charles Cresson Wood and Juhani Saari, published in the Auerbach journal Information Systems Security, Summer 1992.

—————————————————————————————————————————-

Charles Cresson Wood, MBA, MSE, CISA, CISM, CISSP, is an independent technology risk management consultant with InfoSecurity Infrastructure, Inc., in Mendocino, California. In the field since 1979, he is the author of a collection of ready-to-go information security policies entitled Information Security Policies Made Easy. He can be reached via www.infosecurityinfrastructure.com.