« Back to DataSecurityPolicies.com

Archive for September, 2007



Incident Response Policy from Yale

Here’s the incident response policy used at Yale.

Parts of the policy include:

  • Identification of Incidents
  • Establishment of an IT Security Incident Response Team
  • Risk Assessment Classification Matrix
  • Documentation and Communication of Incidents
  • Subordinate Procedures
  • Role of Yale Personnel, Training
  • Incident Prevention

This is an exerpt from the Risk Assessment section:

The ISO will establish an internal risk assessment classification matrix to focus the response to each Incident, and to establish the appropriate team participants to respond. This classification matrix will correspond to an “escalation” of contacts across the University, and will indicate which authorities at Yale to involve and which procedure would be applicable for each class of incident.

An archived copy of the policy is here.

September 27th, 2007 | Posted in Incident Response Policy, Security Policies | No Comments

Best Practices for Security Incident Response

Here’s a helpful white paper by Kerry Thompson that describes best practices that you should follow when responding to a security incident.

I like the part about the incident team. Here’s an exerpt:

An incident team for a small to medium enterprise is almost always two people. One will be the technical lead who will perform the bulk of the remedial work, and the other will be a backup person reporting to management and recording the actions taken. Further people may be involved depending on the size of the organisation, usually in the reporting chain rather than in direct involvement. These may include:

  • the IT manager
  • the CEO/CIO/CTO
  • Media relations
  • Legal
  • Law enforcement

Always get help if you feel the situation is getting out of hand. For example, in one case an incident involving malware infection dragged on for two weeks before someone was called in to diagnose the problem and resolve it within an hour. Get equipment and software tools if required.

Other areas covered include:

  • Forming a plan for resolution
  • Return to operation
  • Preventing reoccurance
  • Review the causes
  • Review resolution
  • Create a final report

Check it out!

September 25th, 2007 | Posted in Incident Response Policy, Security Policies | No Comments

Example Incident Report

Your Data Security Incident Response Policy should include a reference to your Incident Response Plan or Procedure which should require that an Incident Report be completed for each security incident. An incident report example can be found at the California Department of Finance page here.

This is a very thorough report that requires you to fill in information on topics like:

  • Date and Time Incident Occurred
  • Description of Incident
  • Estimated Cost of Incident
  • Corrective Actions Taken to Prevent Future Occurances
  • Estimated Costs of Corrective Actions
  • Have Those Responsible for the Incident Been Identified?
  • If So, How Many Individuals Were Involved?
  • Will Criminal Charges Be Filed?

Check it out here.

September 23rd, 2007 | Posted in Incident Response Policy, Security Policies | No Comments

Acceptable Use Policy

I found a good example of an Acceptable Use Policy at the Asian School of Cyber Laws site here.

I like the section on Unacceptable Use. Here’s an excerpt:

The following activities are, in general, prohibited. Employees may be exempted from these restrictions during the course of their legitimate job responsibilities (e.g., systems administration staff may have a need to disable the network access of a host if that host is disrupting production services).

Under no circumstances is an employee of ASCL authorized to engage in any activity that is illegal under local, state, central or international law while utilizing ASCL-owned resources.

The lists below are by no means exhaustive, but attempt to provide a framework for activities, which fall into the category of unacceptable use.

Check it out!

September 22nd, 2007 | Posted in Acceptable Use Policy, Security Policies | No Comments

Incident Response Policy

John Cristiansen is an information security compliance and risk management lawyer in Seattle, WA. He has an excellent example of a generic Security Incident Reponse Policy on his blog here. The policy is focused on complying on HIPAA requirements but it can be customized to meet the needs of any organization.

Here’s an exerpt:

1. Objectives of this Policy

The objectives of this Policy are to help assure:

  • The confidentiality, integrity and availability of Protected Information held by ORGANIZATION, including but not limited to protected health information as defined by Health Insurance Portability and Accountability Act of 1996 and its implementing regulations (”HIPAA”); and
  • The operational integrity of ORGANIZATION’s Information Systems.

2. Scope of Policy

This Policy is intended to help accomplish its objectives by providing guidance to ORGANIZATION Workforce and Contractors, so that they will be able to:

  • Recognize events or circumstances which may indicate that a Security Incident is occurring or has occurred;
  • Know who is responsible for and authorized to respond to possible Security Incidents; and
  • Know the procedures which should be followed in responding to possible Security Incidents.

Check it out!

September 20th, 2007 | Posted in Incident Response Policy, Security Policies | No Comments

Data Classification Policy

There’s a useful example of a Data Classification Policy from George Washington University here.

They only have three categories of information and responsibility for implementing the policy is delegated to the departments of the University. Here’s an exerpt:

Data owned, used, created or maintained by the University is classified into the following three categories:

  • Public
  • Official Use Only
  • Confidential

Departments should carefully evaluate the appropriate data classification category for their information.

When provided in this policy, examples are illustrative only, and serve as identification of implementation practices rather than specific requirements. Nothing in this policy is intended to identify a restriction on the right of departments to require policies and/or procedures in addition to the ones identified in this document.

An archived copy of the policy is here.

September 17th, 2007 | Posted in Data Classification Policy, Security Policies | No Comments

Business Continuity Presentation

When you’re developing your Business Continuity Security Policy you may want to deliver a presentation to your company explaining what business continuity is all about. Here’s a Business Continuity Presentation I gave to educate a company about the need for business continuity. Feel free to use it as you like.

Topics covered in the presentation include:

  • Definitions
  • Why Have a Plan?
  • Statistics
  • Getting Your BCP Plan Started & Sold
  • Getting the BCP Approved
  • Building the BCP
  • Business Impact Analysis
  • Risk Assessment
  • Risk Management
  • Risk Monitoring
  • Insurance Integration
  • What Are the Cost Issues?

Enjoy!

September 16th, 2007 | Posted in Business Continuity Policy, Security Policies | No Comments