News Stay informed about the latest enterprise technology news and product updates.

Analyst warns to keep tech talk out of security policies

It's easy to get carried away when developing or revamping a corporate security policy, but one expert at Information Security Decisions says it's actually much better to keep things short and simple.

NEW YORK -- Is your company working on its first security policy? Or an updated version of an existing one? One expert says aim low, keep it simple and keep it short.

"It's OK to put a wish list in the policy, but make it optional," said Phebe Waterfield, senior security analyst with Boston-based Yankee Group. Security policies, she told delegates Wednesday at the Information Security Decisions conference, should reflect current practices, not those the security department would like to see implemented.

One reason for lowering the bar, rather than raising it too high, is because people change more slowly than technologies. Waterfield said they need time to grasp and embrace company objectives, including those governing privacy and network and data security. Take baby steps toward enterprise-wide adoption. "People don't change as quickly as a firewall does," Waterfield added.

Though her conference session was titled "Perfecting the Security Policy," Waterfield warned perfection is an unachievable ideal when it comes to getting everyone working off the same page.

"There is no such thing as a 'perfect' policy," she said. "It's always a best effort." Waterfield also cautioned that polices should not be confused with standards and guidelines. Policies are for mandatory requirements and behavior, and apply to whole business units or departments; standards are more specific, and guidelines are optional.

To make that effort as best as possible, she offered the following tips:

  • Focus on what is unique about a policy and include scope and applicability; objectives; rules; enforcement and verification.
  • Don't waste time on recyclable elements, such as definitions, roles and responsibilities and violations reporting. Just cut and paste from other policies.
  • Be generous with your review cycle, and put a lot of effort in reviewing the policy. The means paying a lot of attention to the initial step, which is conducting a risk assessment.
  • Once you've written a policy, first have the security group review it.
  • Next, have IT specialists examine the document.
  • And, finally, senior management should weigh in.
  • Avoid server names, product names and network architecture specifics.
  • Avoid acronyms. "We're here to write policies that people can understand and read. Keep it simple and not technical," Waterfield said.
  • Turn to consultants, books, Web sites and other company's published policies for guidance. Standards, such as those offered by ISO 17799, COSO, Basel II and those established by NIST, also may be helpful.

Popular policies worth considering have some things in common. They're short and targeted to specific users or business units. For starters, they have reasonable and adequate controls and provide proof of compliance for both internal and external audits. They also cite management and monitoring and base decisions on risk assessments. It's also clear how violations are reported.

Information Security Decisions is produced by TechTarget, publisher of 

Dig Deeper on Basel II regulatory compliance and requirements

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.