Security Policies and Procedures

Posted on
Share on Google+Share on LinkedInShare on FacebookShare on RedditTweet about this on TwitterEmail this to someone

Security policies and procedures provide the “blueprint” of an organization’s information security program. The objective of an information security policy is to provide management direction and support for information security. The information security policy is a written policy document that must be available to all employees. The objective of developing security policies should include the development of information security and other security policy documents, documentation of security procedures, determination of contingency planning requirements and development of physical security plans.

 

Developing a Security Policy

 

At a minimum, an organization’s information security policy should include:

 

 

  • A definition of information security, its overall objectives and scope and the importance of security as an enabling mechanism for information sharing.
  • A statement of management intent, supporting the goals and principles of information security.
  • A brief explanation of the security policies, principles, standards and compliance requirements of particular importance to the organization (compliance with standards, legislation and other contractual requirements; security awareness requirements, prevention and detection of viruses and other malicious software; business continuity management; consequences of security policy violations).
  • A definition of general and specific responsibilities for information security management, including reporting security incidents.
  • References to documentation that may support the policy, e.g., more detailed security policies and procedures for specific information systems or security rules users should comply with.

 

This policy should be communicated throughout the organization to users in a form that is relevant, accessible and understandable to the intended reader.

 

Types of Security Policies

 

Security policies that an organization should seriously consider developing to address enterprise requirements include: information security policy, information classification policy, authentication policy, password policy, access control policy, incident response policy, workstation security policy, network security policy, Web security policy, e-mail security policy, security awareness policy and sanction policy.

 

A well-written security policy:

 

 

  • Should be technology-neutral.
  • Should be short, simple and written in a manner that is easily understood.
  • Requires infrequent change. (Some policies are more intimately linked to technology and technological change than others; consider the volatility of an information classification policy versus a VPN policy.)
  • Has formal approval and support from senior-level management.
  • Must be effectively communicated to all employees, agents and contractors within the enterprise on a regular basis.
  • Cannot be tested (but its application must).

 

Security Procedures

 

Next, the organization must create security procedures so that security practices are followed consistently. Procedures provide detailed instructions on how to implement specific policies. Examples of procedures that may be developed include: information system activity review procedure, security incident procedure, contingency operation procedures, physical access control and validation procedures, workstation use procedure, data backup and storage procedure, emergency access procedure, automatic logoff procedure and more.

 

Well-written procedures:

 

 

  • Should be technology-specific.
  • Should be detailed, documenting every step in a process from start to finish.
  • Should be able to walk a novice through the successful completion of a task (a good test of the procedure).
  • Should be updated whenever a step in the procedure changes.
  • Do not require formal approval from senior-level management.
  • Should only be communicated on a “need to know” basis to employees, agents and contractors.
  • Should be tested.

 

Contingency Plan

 

Every organization must plan to respond to an emergency or other occurrence (fire, vandalism, system failure or natural disaster) that damages systems. This activity will result in the development of a contingency plan. The objective of the contingency plan is to establish (and implement as needed) policies and procedures for responding to an emergency or other occurrence that damages systems that contain vital enterprise information. A contingency plan is the only way to provide for the availability and integrity of data during unexpected negative events. Data are often most exposed in these events, since the usual security measures may be disabled, ignored or not observed.

 

Key documents that relate to contingency planning include: data backup plan, disaster recovery plan, emergency mode operation plan, testing and revision, and applications and data criticality analysis.

 

Physical Security Plan

 

Physical security is about the application of physical barriers and control procedures as preventive measures and countermeasures against threats to resources and sensitive information. The organization must develop a physical security plan to secure enterprise sites and provide for the physical protection of critical server and other systems.

 

A physical security plan must address specific areas, such as: facility access controls (contingency operations, facility security plan, access control and validation procedures, and maintenance records); workstation security; and device and media controls (disposal, media reuse, accountability, and data backup and storage).
The objective of a facility security plan is to implement policies and procedures to safeguard the facility and the equipment therein from unauthorized physical access, tampering and theft.

 

Summary

 

A successful implementation of security policies and procedures will enable the organization to prevent improper use, inappropriate disclosure, improper destruction and unauthorized access of information. All members of the workforce must be aware of the organization’s security policies and procedures. My advice to all security practitioners is to make sure you communicate these policies to all members of your organization.

 

Water follows the path of least resistance. Similarly, guess the weakest link in security? Yes, that’s right—employees. Thus, security practitioners must lead the way to develop, maintain and communicate policies on a regular basis. That will enable your organization to better defend its vital enterprise assets and sensitive information.

 

Uday O. Ali Pabrai, Security+, CISSP, CHSS, chief executive of ecfirst.com, consults extensively in the areas of enterprise security and HIPAA. Pabrai, author of the best-selling “Getting Started with HIPAA,”is the co-creator of the Security Certified Program (www.securitycertified.net). E-mail him at pabrai@securitycertified.net.

 

Key Sections of a Policy Document

 

Each policy document must have specific sections in it. Consistently including these sections makes it easier to interpret and implement the guidelines established by the policies. The specific sections of the policy document that you may consider for your organization are:

 

 

  1. Title: identifies the name.
  2. Identifier: establishes a reference for tracking purposes.
  3. Version No.: clearly identifies the latest version.
  4. Approved By: establishes management support.
  5. Effective Date: the date the policy goes into effect.
  6. Purpose: defines the objective/motivation.
  7. Scope: identifies limits, assumptions or exclusions.
  8. Policy: describes the policy.
  9. Responsibilities: establishes duties for those associated or impacted by this
Share on Google+Share on LinkedInShare on FacebookShare on RedditTweet about this on TwitterEmail this to someone
cmadmin

ABOUT THE AUTHOR

Posted in Archive|

Comment:

Leave a comment

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>