INFOSEC policies: A primer

Tools are not a silver bullet. By themselves, they are not the panacea against all the information security ills that their marketing material purport them to be. They must be accurately placed in the network and tuned. Most importantly, they must be used in context.  This is my vote for INFOSEC policies.

Goals/Objectives

Too often I see tools being pushed and advocated for their own sake. What do you expect to accomplish? What controls are you trying to implement? Are you trying to comply with a regulation? Do you have the proper resources from a knowledge or full time equivalent standpoint?

These questions and more should be answered to get a good idea of the issue you are trying to fix or control.   The answers to these questions that flesh out the organizations goals and objectives will naturally create a framework to generate policy from.

Policy

Everyone’s favorite topic right? As dry as it can be to some, INFOSEC policies are a necessary evil. They can be as formal as a templated document which has a  creation process managed by various departments in your organization or a quick document that answers the following questions.

  • Who does this apply to?
  • Who is responsible for maintaining this policy?
  • What is the purpose?
  • What are important definitions or acronyms?
  • What are the parameters or standards of the policy topic? (the meat of the policy)
  • How often will this document be reviewed?
  • Are there related policies?
  • Does this policy map to controls or regulations?

Policy is all about WHAT is required to fulfill an objective or requirement. They are not a technical documents. For example, a password policy will explain who is required to have what type of passwords. It will not speak about how this will be implemented. That is detailed in other documents.

Depending on the policy topic and your organizational culture, policy documents can be written vaguely to cover a large area and allow for changes in the INFOSEC landscape or very specifically to target a niche area.

Procedures/Standards

These documents implement policy. They explain HOW a policy is implemented technically. How will a control be audited? How will a password requirement be implemented? What is the process to ensure that terminated employees are disabled in Active Directory?

There are a few different places that provide standards.

General OS Standards / Benchmarks

Center for Internet Security

DISA STIGS

NIST Special Publications

More and more application vendors are starting to provide information on how to properly secure their products. It’d be nice if they were secure by default but I’ll take having the information to harden it myself.

So what’s the point?

By figuring out the goals, objectives and requirements that drive your policy and procedures/standards, the organization is building out its information security protection framework. Policy provides the context that is so critical to implementation of tools, operating procedure and technology. These will guide decisions on what tools will fit into the organization. Furthermore, they’ll give guidance and some standardization to how information security is handled in the organization. Finally, it is a statement on what is important to the organization. Policy is (whether completely complied with or not) generally viewed as must do items.

Common Information Security Policies

The below policies are just a sampling of the most common policies that organizations create.

  • Acceptable Use Policy
  • Log Review Policy
  • Access Policy
  • Password Policy
  • Wireless Policy
  • Data Protection Policy
  • Vulnerability Management Policy
  • Network Security Policy

 

Where to find more information:

SANS Institute

INFOSEC Institute

 

How do you handle INFOSEC policies?

How do you decide what requires policy and what doesn’t?  How do you decide to flow from requirements through to repeatable operations?

Leave a Reply

%d bloggers like this: