Article

Analyst warns to keep tech talk out of security policies

Anne Saita

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

    Requires Free Membership to View

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 SearchSecurity.com. 


There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to: