There are numerous bits of advice floating around on how to write and implement a security policy. This is another, by eminent security authors Cyrus Peikari and Seth Fogie. But Cyrus and Seth realize that there is a lot of information out there on policy making. In this short article, provided by
Security policies are part of any well-maintained information system. There are numerous guides and templates available that seem to provide you with a reference for creating the perfect security policy. However, to the dismay of many administrators and IT managers, a good security policy is not a simple plug-and-play component. For a policy to show any return on investment, it must become integrated into the processes and procedures of a business, along with the support of the people who are expected to follow it. Without this type of attention and support, a security policy will be worthless.
Security policy design often requires weeks of testing, meetings and data analysis. These next few pages will provide an overview of the obstacles that must be overcome in order to create the perfect security policy. Due to the enormous amount of information available, we have attempted to consolidate this subject into one brief section.
Defining the security policy
Over the years, there have been many attempts to define the term "security policy." There are numerous books, articles and Web sites that deal with nothing but security policies. As a result, there is a lot of data available to assist the policy maker, which unfortunately often has the effect of overwhelming them. For this reason, we will look at two popular variations of a security policy definition.
The first is provided by The SANS Institute, which starts by defining a policy as "a document that outlines specific requirements or rules that must be met...usually point-specific, covering a single area."
In other words, SANS describes a security policy as a modular method for defining and ultimately developing specific guidelines or rule sets that are used to control individual aspects of a computer system, such as acceptable use, password creation or instant messaging use. Depending on the level of security required, a company can create a few general policies that lump together multiple areas of security, or they can create very specific itemized policies that uniquely define each threat and then create a policy to handle that threat. The level should depend upon the value of the assets at risk and the required level of security needed to contain the threat.
The second definition uses a more global summary. This definition is taken from an article written by Ed Tittel in which he references SearchSecurity.com: "In business, a security policy is a document that states in writing how a company plans to protect the company's physical and information technology (IT) assets."
This definition highlights the purpose of the security policy verses the method of meeting this goal. However, if you merge the two definitions, a security policy can be defined as a set of documents that describes the security goals as required for the sole purpose of protecting the physical and information assets of a business.
Based on this, there are many subdefinitions that can be drawn from this overview of such a complex issue. The following will break down the security policy's purpose and how it can actually protect your company's assets.
The security policy will take the form of a document or a collection of documents depending on your intent. From the initial assessment to the final maintenance plan, each item, standard, guideline and procedure should be listed in a policy. This not only provides future policy creators with a guide to create standards and guidelines, but it also helps the IT administrators develop their personal and explicit instructions to help them meet the business goals of the policy. In addition, the policy can also become a point of reference in case a violation occurs that results in a dismissal or other penalty. You can expect this document to be rather long and extensive.
First, a policy itself includes no explicit procedures to meet its own goal. This is the job of IT administrators. However, it should be noted that the procedures should end up as part of the overall security policy document. Instead, the policy is a "...high-level [plan] that describe the goals of the procedures. Policies are not guidelines or standards, nor are they procedures or controls. Policies describe security in general terms, not specifics. They provide the blueprints for an overall security program just as a specification defines your next product." From this short excerpt of CISSP Security Management and Practices by Roberta Bragg, you can clearly see what the security policy should contain.
In addition to the general layout of a policy, there are some indirect goals that every security policy should meet. As TICSA Certification: Information Security Basics describes, "...any good security policy must address the following concerns:
- Prevent waste or inappropriate use of organization resources (especially computing resources).
- Limit or eliminate potential legal liability, be it from employees or third parties.
- Preserve and protect valuable, confidential or proprietary information from unauthorized access or disclosure."
The goals outlined in the security policy ultimately are to protect an asset. While it is important to determine what that asset is (discussed next), you also need to determine what you are protecting against. In other words, are you concerned about corporate espionage, theft of intellectual property, intrusion and destruction of files from external hackers or all of the above? Determining what you are protecting against is an important part of a security policy and needs to be determined early on in the creation.
On the flip side, protection also involves defining where and how consequences are to be administered in the case there is a violation. While the specifics of the rebuttals can be left to department heads, the basic security policy needs to define the methods by which protection can be enforced. Are authorities to be contacted? Will violations be handled in house? What are the levels of threat? These questions and more need to be answered.
While the other sections are important, the value of the security policy is ultimately related to the assets it is protecting. As a result, a company must perform an in-depth audit of their resources to determine what constitutes as an asset and more importantly, the value of that asset. This can be one of the most challenging parts of developing any security policy due to the fact that many items are hard to put a price tag on, and others are hard to define. For example, it is easy to put a price tag on a laptop, at least the physical value. However, how can you determine the value of the software, programs, e-mails and other pieces of information on the drive? Not only do they have an immediate value due to their contents, but there is also a hidden cost if another company were to discover or steal any sensitive information.
Summary of security policies
At this point you can see how complex a security policy can be. A good security policy cannot simply be haphazardly thrown together. In "Developing a Security Policy", written by Sun Microsystems, the characteristics of a good security policy are defined as:
- They must be implementable through system administration procedures, publishing of acceptable use guidelines or other appropriate methods.
- They must be enforceable with security tools, where appropriate, and with sanctions, where actual prevention is not technically feasible.
- They must clearly define the areas of responsibility for the users, administrators and management.
- They must be documented, distributed and communicated.
So, from this you can see that a policy must be more than a big document. If no one can understand it or use it, the time and effort put into it will be wasted. The following section will provide you with an example of a simple e-mail policy, along with a discussion explaining the reason for each point.
Click over to InformIT to read more of this article and to see the authors' example of an e-mail security policy.
This was first published in July 2003