Using Security Policies As Catalysts For Internal Change

Security Quality Control: There is much to recommend about the ISO 9000 quality control approach as it is applies to the discipline of information security. In fact the ISO 27001 standard, entitled Information Security Management System (ISMS), in large measure reflects that same methodology. In other words, ISO 27001 suggests a continuous improvement approach to information security, where processes are documented and standardized, where adherence to these processes is regularly measured, and where improvements are made over time to the processes themselves. The standard makes reference to the “plan, do, check, act” approach, alias PDCA, which is another way to describe this same continuous improvement quality control approach.

If you’re approaching information security in this manner at your organization, your organization’s information security function is in a relatively evolved state. In contrast, many organizations are still trying to get the budget to occasionally perform credible risk assessments. Likewise, many organizations are still desperately seeking more management attention, trying to get enough budget to adequately accomplish the basics, like user awareness and training — in many cases things that should have been completed ages ago.

So how can these information security staff seeking to up the security level at their organizations accelerate the evolution of security? How can they catalyze the change process? One highly recommended way is to start putting things much more seriously down on paper. To start this process, they can write a variety of information security policies.

Importance Of Security Policies: But before you run off and start writing a bunch of policies, or better yet, tailoring a template of already written policies, there are some important initial steps. You or an independent third party should have performed a recent risk assessment, and this report should make it clear that substantial improvement is still needed in the information security area. Thus top management will need to be legally put on notice that they need to do something in the information security area.

With top management, you should also talk about the importance of policies in the information security area. Tell them how policies are like the backbone on which many other documents are built, and from which general direction for an information security effort will come. Talk about how policies are one of the most basic pieces of evidence that auditors look for when they determine the sophistication of an organization’s information security effort. Make reference to the group of laws and regulations (relevant to the your organization, of course) that all require the existence of an information security policy document. For example, if your organization works with medical information, the Health Insurance Portability & Accountability Act (HIPAA) requires a privacy policy. Thus management will come to appreciate the centrality and importance of putting things in writing, specifically in the form of policy documents.

If it doesn’t already exist within your organization, (and it’s best to piggyback on an existing process if you can), then you should create a formal documented risk management process. Implementing the PDCA approach mentioned above, this procedural approach provides a mechanism to hold people’s feet to the fire, to get them to act, and to regularly report back to management if and when they don’t act. This same risk management process checks to see if people are in compliance with policies and other internal requirements. Policies are of very little use if they are never enforced. In fact, they could do more harm that good if everybody knows that policies are simply a smokescreen obscuring the fact that top management doesn’t care about information security.

Provocation Begins: The beneficial provocation, which catalyzes the evolutionary process, can for example take place when there is a budget showdown, where management must decide between an information-security project and a non-information-security project. If you’ve documented an information security requirement in the form of a policy, gotten top management’s written approval, and you’ve sent it out to the whole organization, maybe even distributed it to customers and business partners, you should stress that management must now follow through. Emphasize how they must establish supporting infrastructure, and consistently maintain a system that supports this requirement.

This is a great time to talk about compliance and how important it is to get consistent compliance, from all people, from all systems all the time. This is also potentially an important teaching moment with top management. They may not like the fact that they are required to spend money on information security. But if you’ve done your job well, specifically if you’ve documented everything and tied it all back to legitimate and authoritative sources, then you’re standing on firm ground. Of course, management can always decide to take a risk, and not to fund the information security project implementing this policy’s requirement, but if they do, at least you’ve got it in writing that the onus of responsibility is on their shoulders.

Another great provocation approach, an approach that prods management to take more action, is to spend some time with your internal legal counsel. Speak to your attorney about what it means for top management to have a fiduciary duty to protect assets, and how top management is legally bound to protect assets (which of course include both information and information systems). Talk to them about negligence, professional duty, due diligence, and related legal concepts that squarely place the ultimate responsibility for information security on top management’s shoulders. If you can, reference specific laws and regulations, and/or case law (although the latter is hard to come by because information security is still such a new field). For example, if you work in the US government, could make reference to FISMA, the Federal Information Security Management Act, which requires every Federal agency to develop and document an information security effort.

Building A Security Pyramid: So what we’re doing here is collecting a bunch of authoritative sources that say that you must document, document, and then document some more the requirements that go into your information security program. Then we’re showing those sources to management, and impressing them with the fact that it in their best interests to document, document, document the information security function. For example, top management can demonstrate that they have exercised due diligence in the information security area if the organization has adopted authoritative new information security policy documents. So in the process, we’re building a pyramid of documents, a hierarchy of documents with policies at the top.

Some readers may think this strategy seems manipulative. But I suggest that’s an unnecessarily negative spin. Think of it instead as the establishment of action-forcing mechanisms. I’m not asking you to do anything that isn’t absolutely tied-in with fundamental business needs. What’s new, and perhaps at least in the beginning a bit hard for some readers to follow, is understanding how very successful a documentation-oriented approach can be, when it comes to forcing management to do what they have all along been required to do. So tie all this documentation in well with business requirements [who knows sometimes management justifies this important kind of work for the wrong reasons — for example as a way to get a new customer to sign-up for their service — but don’t complaint, just go with whatever works]. At any rate, this hierarchy of documents will define what needs to be done, and the risk management process mentioned above (aka PDCA) then will start to illuminate the fact that actual conditions are a significant distance away from the documented requirements. This gap needs to be closed, and that means that we need to go back to management to ask for more budget dollars.

In these tough financial times, going back to management and asking for more money can admittedly be hard to do. But it’s important, so do it anyway. You should feel good about the fact that all we’re doing here is getting management to do what they are legally, ethically, and prudently required to do. What’s different about this documentation-based approach is that it’s codifying the information security function; it’s establishing the information security function as an on-going organizational function like accounting and marketing. What’s different about this approach is that we’re moving information security out of the project-to-project mode, and we’re creating on-going business processes that top management must engage with periodically. For example, as part of the documentation approach, this author recommends the establishment of an Information Security Management Committee, which meets quarterly to supervise and oversee information security activities.

Nobody’s Irreplaceable: One of the great parts about this documentation-oriented approach is that it help address the information-security related complexity management problem. If we don’t extensively use documentation, then we can’t really understand what’s happening in the information security area. If we don’t understand what’s happening, then we can’t successfully manage information security.

As one example of this point, consider how this documentation approach creates enough documentation in the pyramid (standards, guidelines, procedures, contingency plans, etc.), so that no one individual can unexpectedly leave an organization, and thereby interfere with the continuation of the work as it should be performed. Along with a host of other objectives, as a design objective, the system of documentation and related organizational structure should be created so that it is not dependent on any one individual. That is both good information security practice and good human resource management practice.

A highly publicized example of what can go wrong when this good practice isn’t pursued was recently revealed by a court case involving Terry Childs and the City of San Francisco. Childs was a systems administrator who had extensive privileges over one of the City’s internal networks. He changed the password and locked people out of the network, and then refused to divulge the password. Later convicted of a type of denial of service attack under California law, Childs had no peer at the City who knew the password, nor was there a work-around that could be employed, so he could effectively hold the City hostage. Although this author doesn’t know about the status of documentation at the City, it appears that if excellent documentation was in fact prepared and used, this excessive reliance upon a single individual would have stuck out like a sore thumb, and it would have been promptly remedied.

You should talk about cases like this with management, and help them to understand how having good checks and balances, that are in turn well documented, will in fact help to prevent problems such as this. And of course, as you prepare this documentation, you will also be building the documentation pyramid mentioned above, and coming that much closer to having information security be recognized as a legitimate on-going organizational function, just like accounting and marketing.

—————————————————————————————————————————

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.