Total Enterprise Security Solutions has a great data classification matrix here.

This matrix would make a good appendix to your Data Classification Policy.

It categorizes data into non-sensitive (non-controlled and controlled) and sensitive (critical information and restricted information). It also has examples and criteria for each category plus ten handling standards:

• Release to Third Parties Standards
• Transmission by Post, Fax and E-mail Standards
• Transmission by Spoken Word Standards
• Print, Film, Fiche, Video Standards
• Copying Standards
• Storage Standards
• Destruction Standards
• Physical Security Standards
• Access Control Standards
• Audit Standards

An archive of the data classification matrix is here: Data Classification Matrix

Very useful info–check it out!

The Hawaii Health Information Corporation has a sample data classification policy here.

Here’s an excerpt:

A. [COMPANY]’s data classification system has been designed to support the “need to know” principle so that information may be protected from unauthorized disclosure, use, modification, and deletion. Consistent use of this data classification system will facilitate business activities and help keep the costs for information security to a minimum. Without the consistent use of this data classification system, [COMPANY] unduly risks loss of customer relationships, loss of public confidence, internal operational disruption, excessive costs, and competitive disadvantage.

B. This data classification policy is applicable to all information in the [COMPANY]’s possession. Example information such as medical records on patients, confidential information from suppliers, business partners and others are protected under this data classification policy. No distinctions between the word “data”, “information”, “knowledge,” and “wisdom” are made for purposes of this policy.

An archive of the file can be found here: Sample Data Classification Policy

Very useful sample–check it out!

An excellent template for an Incident Response Policy can be found in RFC 2350 here. While this is a template for a computer security incident response team (CSIRT), it has a lot of the same structure you would need for an Incident Response Policy.

It even has a filled out example of the template. Here’s an excerpt:

5.1.2 Incident Coordination

• Determining the initial cause of the incident (vulnerability exploited).
• Facilitating contact with other sites which may be involved.
• Facilitating contact with XYZ University Security and/or appropriate law enforcement officials, if necessary.
• Making reports to other CSIRTs.
• Composing announcements to users, if applicable.

5.1.3 Incident Resolution

• Removing the vulnerability.
• Securing the system from the effects of the incident.
• Evaluating whether certain actions are likely to reap results in proportion to their cost and risk, in particular those actions aimed at an eventual prosecution or disciplinary action: collection of evidence after the fact, observation of an incident in progress, setting traps for intruders, etc.
• Collecting evidence where criminal prosecution, or University disciplinary action, is contemplated.

In addition, XYZ-CERT will collect statistics concerning incidents which occur within or involve the XYZ University community, and will notify the community as necessary to assist it in protecting against known attacks.

Check it out!

The University of Toronto has a great example of a Network Security Policy here.

Here’s an excerpt:

Computing & Networking Services will:

• monitor in real-time, backbone network traffic, as necessary and appropriate, for the detection of unauthorized activity, intrusion attempts and compromised equipment.
• carry out and review the results of automated network-based vulnerability, compromise assessment and guideline compliance scans of the systems and devices on University networks in order to detect known vulnerabilities, compromised hosts, and guideline compliance failures,
• test campus wireless network access to ensure compliance to published guidelines.
• prepare summary reports of its network security activities for the Technical Operations Committee on a quarterly basis

Also includes the appendix Guidelines for the Implementation of Wireless and Wired Docking Infrastructure.

Check it out!

I wrote a generic Personnel Security Policy which is attached below.

Sections of this policy include:

• Requirement to Protect Corporate Assets
• Information Security Responsibilities in Employee Handbook & Contracts
• Information Security Training
• Background Checks
• Bonding
• Conflict of Interest
• Non-Disclosure Agreements
• Security Incidents

Here’s an excerpt:

Include information security responsibilities in company rules and worker’s contracts.

• Information security responsibilities to be followed by all employees must be incorporated into Organization XYZ’s employee handbook.
• All employees must acknowledge in writing (electronic acknowledgement is acceptable) that they have read and understood Organization XYZ’s employee handbook.
• Specific information security responsibilities must be incorporated into all contracts with contractors (including consultants or any non-employee who performs work for hire) who have access to restricted, customer or otherwise sensitive information.

You can download a copy of the policy here: Personnel Security Policy

Let me know if you have any suggestions!

The Ruskwig site has a great example of an Acceptable Use Policy here.

Here’s an excerpt:

DO NOT
9. Do not download text or images which contain material of a pornographic, racist or extreme political nature, or which incites violence, hatred or any illegal activity.
10. Do not download content from Internet sites unless it is work related.
11. Do not download software from the Internet and install it upon the Organisation’s computer equipment.
12. Do not use the Organisation’s computers to make unauthorised entry into any other computer or network.
13. Do not disrupt or interfere with other computers or network users, services, or equipment. Intentional disruption of the operation of computer systems and networks is a crime under the Computer Misuse Act 1990.
14. Do not represent yourself as another person.
15. Do not use Internet access to transmit confidential, political, obscene, threatening, or harassing materials.

Definitely worth checking out if you’re developing your own Acceptable Use Policy.

Here’s a great article by Mich Kabay that describes tips for defining email retention policies.

Here’s an excerpt:

• Define, enforce and update formal retention policies that stipulate how long to keep archives of which types of data. Ensure that your legal counsel is deeply involved in setting these policies.
• Access to archived records should be completed within, at most, 48 hours to avoid possible fines.
• Deleting e-mail and other records that show evidence of wrongdoing may lead to worse legal and public-relations consequences than coming clean.
• Unscheduled deletion of e-mail may destroy exculpatory evidence or lead to a tacit presumption of guilt.

Great info for anyone developing their own e-mail retention policy. Check it out!

eMag has a great overview of how to develop your document retention policy here.

Here’s an excerpt:

EVERY company should have a formal document retention policy, and this policy must be actively enforced. When a company or business is on notice of pending litigation, it is required to implement a “Litigation Hold” to retain any information or documents that the organization reasonably believes are discoverable in the anticipated litigation. Failure to properly implement such a hold can result in large damage claims for the opposing part, as evidenced by the landmark spoliation ruling in Zubulake (Zubulake v. UBS Warburg (”Zubulake V”), 2004 U.S. Dist. LEXIS 13574 (July 20, 2004). Morgan Stanley faced a $1.4 billion award in compensatory and punitive damages stemming from its lack of knowledge about the location of its discoverable information ( Coleman (Parent) Holdings v. Morgan Stanley, 2005 Extra LEXIS 94 (Fla Cir. Ct. Mar. 23, 2005) . Likewise, a company may have email or other electronic records that were excluded by an under-inclusive preservation order, thus opening up the entire catalog of archived electronic records to scrutiny by the courts. Sanctions may be imposed where a party has not only acted in bad faith or gross negligence, but also through ordinary negligence (Residential Funding Corp. v. DeGeorge Fin. Corp. 306 F.3d 99).

This is very useful information for justifying the need to write, implement and enforce your own document retention policy.

The SANS Security Policy Project site has a good acceptable use policy sample here.

2.0 Purpose

The purpose of this policy is to outline the acceptable use of computer equipment at <Company Name>. These rules are in place to protect the employee and <Company Name>. Inappropriate use exposes <Company Name> to risks including virus attacks, compromise of network systems and services, and legal issues.

…

4.3. Unacceptable Use

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 <Company Name> authorized to engage in any activity that is illegal under local, state, federal or international law while utilizing <Company Name>-owned resources.

This is a great resource for anyone developing their own Acceptable Use Policy. Check it out!

There are a ton of great sample security policies available at the SAN Institute Security Policy Project here.

Included in the policies you can download in either Word or PDF format are:

Acceptable Encryption Policy
Defines requirements for encryption algorithms used within the organization.

Acceptable Use Policy
Defines acceptable use of equipment and computing services, and the appropriate employee security measures to protect the organization’s corporate resources and proprietary information.

Analog/ISDN Line Policy
Defines standards for use of analog/ISDN lines for Fax sending and receiving, and for connection to computers.

Anti-Virus Process
Defines guidelines for effectively reducing the threat of computer viruses on the organization’s network.

Application Service Provider Policy
Defines minimum security criteria that an ASP must execute in order to be considered for use on a project by the organization.

Application Service Provider Standards
Outlines the minimum security standards for the ASP. This policy is referenced in the ASP Policy above.

Acquisition Assessment Policy
Defines responsibilities regarding corporate acquisitions, and defines the minimum requirements of an acquisition assessment to be completed by the information security group.

Audit Vulnerability Scanning Policy
Defines the requirements and provides the authority for the information security team to conduct audits and risk assessments to ensure integrity of information/resources, to investigate incidents, to ensure conformance to security policies, or to monitor user/system activity where appropriate.

Automatically Forwarded Email Policy
Documents the requirement that no email will be automatically forwarded to an external destination without prior approval from the appropriate manager or director.

Database Credentials Coding Policy
Defines requirements for securely storing and retrieving database usernames and passwords.

Dial-in Access Policy
Defines appropriate dial-in access and its use by authorized personnel.

DMZ Lab Security Policy
Defines standards for all networks and equipment deployed in labs located in the “Demilitarized Zone” or external network segments.

E-mail Policy
Defines standards to prevent tarnishing the public image of the organization.

E-mail Retention
The Email Retention Policy is intended to help employees determine what information sent or received by email should be retained and for how long.

Ethics Policy
Defines the means to establish a culture of openness, trust and integrity in business practices.

Extranet Policy
Defines the requirement that third party organizations requiring access to the organization’s networks must sign a third-party connection agreement.

Information Sensitivity Policy
Defines the requirements for classifying and securing the organization’s information in a manner appropriate to its sensitivity level.

Internal Lab Security Policy
Defines requirements for internal labs to ensure that confidential information and technologies are not compromised, and that production services and interests of the organization are protected from lab activities.

Internet DMZ Equipment Policy
Defines the standards to be met by all equipment owned and/or operated by the organization that is located outside the organization’s Internet firewalls (the demilitarized zone or DMZ)).

Lab Anti-Virus Policy
Defines requirements which must be met by all computers connected to the organization’s lab networks to ensure effective virus detection and prevention.

Password Protection Policy
Defines standards for creating, protecting, and changing strong passwords.

Personal Communication Device
Describes Information Security’s requirements for Personal Communication Devices and Voicemail.

Remote Access Policy
Defines standards for connecting to the organization’s network from any host or network external to the organization.

Remote Access - Mobile Computing and Storage Devices
To establish an authorized method for controlling mobile computing and storage devices that contain or access information resources.

Risk Assessment Policy
Defines the requirements and provides the authority for the information security team to identify, assess, and remediate risks to the organization’s information infrastructure associated with conducting business.

Router Security Policy
Defines standards for minimal security configuration for routers and switches inside a production network, or used in a production capacity.

Server Security Policy
Defines standards for minimal security configuration for servers inside the organization’s production network, or used in a production capacity.

Server Malware Protection Policy
Outlines which server systems are required to have anti-virus and/or anti-spyware applications.

The Third Party Network Connection Agreement
Defines the standards and requirements, including legal requirements, needed in order to interconnect a third party organization’s network to the production network. This agreement must be signed by both parties.

VPN Security Policy
Defines the requirements for Remote Access IPSec or L2TP Virtual Private Network (VPN) connections to the organization’s network.

Wireless Communication Policy
Defines standards for wireless systems used to connect to the organization’s networks.

Lots of great info. Check it out!