Blog

In a previous post, I discussed the importance of security policies and how the likely impact of not having a well-defined corporate security policy. Today, I want to get a little deeper and layout what a security policy should contain as well as describe some of the accompanying documentation that supports that policy. In order to fully understand how a security policy applies to your organization, we need to define a few terms.

First, security - what does it mean in reality? According to Merriam-Webster, security is defined as "the state of being protect or safe from harm." International Information Systems Security Certification Consortium (ISC)2 does not define security as single defined entity or state. Instead, they break security down into addressable components and refer to a variety of acceptable security control frameworks that can be used to help organizations manage the complexities of  developing and implementing a corporate security policy.

Next, we need to understand what is at risk in our environment. Risk is defined as the probability of a threat agent exploiting a vulnerability and the impact associated with that exploitation. A threat is the danger of a threat agent exploiting a vulnerability. A threat agent is any entity that can exploit a vulnerability. A vulnerability is defined as weakness or the lack of a countermeasure. Risk can mean the loss or harm to data, physical assets, reputation or people. The exploitation of a risk from an outside threat results in an incident with harm to data, physical assets or people resulting in a breach.

Remember, a security policy is defined as a strategic tool used to dictate how sensitive information and resources are to be managed and protected. These definitions are found in the Official (ISC)2 Guide to the CISSP CBK, Fourth Edition.

In practical terms, a corporate security policy defines that scope of security needed by an organization, lists in general terms the assets that require protection and degree that security should be applied to those assets. A written security policy is an actual physical document, albeit one that should be in constant flux, changing to reflect the changing needs of an organization's security posture.

Security policies assign responsibilities, define organizational roles, layout audit requirements, describe enforcement processes, list compliance requirements and define acceptable risk levels. This document is used as proof that senior management is exercising due care in protecting itself. Security policies are compulsory, meaning everyone in the organization is required to abide by them and they are often subdivided into and advisory policy, and informative policy and a regulatory policy.

Most security policies are further subdivided into role or function specific policies that have a very narrow scope. These policies are all under the umbrella of the corporate security policy. Security polices are by nature very general and do not delve into specific implementations. They typically refer to more specific documents. Those documents each refer to standards, baselines,  guidelines and procedures.

Standards are exactly what you might imagine - they define the standards accepted by the organization and accounts for any regulatory or contract-based requirements but does not spell out how the standard are implemented. Baselines define the minimum level of acceptable security and are typically based upon industry standards such as TCSEC or the ISO Common Criteria. An organization does not need to have a regulatory need for adapting these baselines. Guidelines are recommendations as to how things should be done but stop short of defining the actual specific steps to be followed in implementing the guideline recommendations. Procedures define the actual process for accomplishing the security goals defined in the preceding documents. These are details and technology specific. These documents will change frequently to reflect changes in technology.

Wow! Security policies seem complicated and appear to be a ton of work. So where does one start? You have heard the saying "how do you eat an elephant?" One bite at a time.

First and foremost, you must have buy-in from your C-level management. Without their understanding and support, you will end up spinning your wheels. It is helpful to remind your management team members that they are ultimately responsible for doing their due diligence and implementing due care. Security starts with management. You can help management understand the need for a comprehensive security policy by first educating them on the overall risk to their organization in terms they understand - dollars. Follow that up with helping them understand the costs involved in reducing corporate exposure.

Next, you must understand the risks faced by your organization. In order to do that, you must first understand your organization's structure, the roles within that structure and the assets (along with their corresponding values) that you need to secure. With that information is in hand, you can undertake a risk analysis. The goal of a risk analysis is to categorize, quantify and prioritize security initiatives. Ultimately, security controls are driven by the results of solid cost benefit analysis.

You can then begin to develop your global security policy and add more needed sub-policies based upon those areas that pose the greatest risk to your organization. Work your way through the process of developing standards, baselines, guidelines and procedures. Repeat the process for the next highest priority risk area. Over time, you will develop a comprehensive set of security policies and supporting documentation. In the end, your organization will better understand its risk level and likely have a much better handle on the underlying processes used to implement security.

All of the documents discussed in this post are available as templates from a multitude of online resources including:

Sans Information Security Policy Templates IT Business Edge CSO Online

These resources should get you well on your way to a more secure organization. Keep in mind that security and risk reduction encompasses much more than just your IT infrastructure. You must address security holistically with the security and safety of your people always having the highest priority.