Writing policies that demonstrate compliance

An expert offers advice for writing security policies that ensure managment that staff and systems are in compliance.

A serious problem associated with many information security policies is that management often has no idea if staff and systems are in compliance with these policies. This disconnect between the policy's intention and the policy's implementation is in large measure a reflection of the compliance auditing technology being used to support information security.

When practitioners write information security policies, they should push management to consider the implications of using different compliance auditing technologies, such as the up-front costs for initial deployment, the on-going costs of operation and maintenance, and the costs of demonstrating compliance. Before going into these matters, to determine the extent to which compliance exists, it is first important to distinguish three different types of control environments.


Control environments

  • The first type of control environment is built so there is no need for periodically gathered compliance data. In these situations, controls often permit only the previously approved uses of certain types of information. For example, a digital rights management (DRM) system can be used to prevent anybody except those using specific desktop computer systems from displaying a readable version of certain sensitive information. Whatever the control environment, there will always be ways that security systems such as this can be broken, but the need in this type of control environment is for good problem-reporting systems, not compliance checking. In this case, problem-reporting systems would be able to deal with matters such as secondary dissemination, where an authorized person passed information to an unauthorized person. There is no need to have a compliance checking system to see whether the encryption routines in the DRM system were operating correctly.
  • The second type of control environment provides indicators that can definitively show whether security policies are being observed. For example, a systems administrator should be following established policies and procedures when configuring operating systems, including installing patches and upgrades. Whether this has been done can be readily observed with vulnerability identification software. Another example involves fixed passwords chosen by end-users. Software can readily determine whether the users have followed a strong password policy. If passwords are easy-to-guess, the users are automatically notified that they need to change their passwords. Reports reflecting compliance in both of these examples are relatively inexpensive to automatically generate.
  • The third type of control environment has few definitive types of evidence that can be examined to demonstrate compliance. For example, a data classification policy can define what types of information should be strictly kept within the organization. In the absence of a serious problem, such as a competitor using an internal trade secret for their own product, management will never know whether workers are observing this policy. While management could instruct auditors to interview workers about their knowledge and compliance with a policy like this, respondents would be unlikely to realistically and candidly respond.

Dictate through policy
Bringing the three types of control environments together shows how the type of control environment we face in a particular situation is a function of the technology used to secure information. Therefore, whenever possible, practitioners should dictate through policy the use of controls that don't require compliance checking. In the absence of cost-effective control solutions of this nature, practitioners should seek to dictate controls for which compliance can be readily measured, ideally with automated tools.

Promote TCO
Without question, the control environments that don't require periodic compliance checking are the most expensive to initially deploy. Naturally, the environments involving the most difficult-to-perform and most-expensive compliance checking are the least expensive to initially deploy. When making decisions about policies that require the use of certain controls, management is often not aware of this important trade-off or of the total cost of adopting a particular control. Often, management is presented with the purchase cost, such as the license fee for a security software package, but not any credible estimate of the costs to maintain and operate this software, let alone the costs to perform compliance checks to ensure that it is operating correctly. Therefore, when practitioners write policies, they need to foster more of a total-cost-of-ownership (TCO) approach to controls, so management can clearly see the big picture.

This big picture in turn should provide management with an understanding that they often face a "pay me now, or pay me later" situation. In other words, if they skimp on the initial costs for security, they will pay later because compliance checking will be difficult and relatively expensive. However, if they pay a significant amount for security up-front, they will enjoy on-going operational and compliance checking costs that are significantly reduced.

About the author:
Charles Cresson Wood, CISSP, CISA, CISM, is an independent information security consultant based in Sausalito, Calif.. He specializes in the development of information security documents including policies, standards, procedures and job descriptions. He is also the author of the book and CD-ROM entitled Information Security Policies Made Easy.

This was last published in February 2005

Dig Deeper on Information security policies, procedures and guidelines

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.