A good example of an Email Acceptable Usage Policy can be found on page 6 of a document at the TechTarget website here.

Here’s an excerpt:

Introduction
This policy covers acceptable email usage when utilizing company information systems.
NOTE: You might want to include more information here such as the purpose and reasoning behind this policy.

Scope
All users of company information systems.

Policy Statement
Email is intended for business purposes only. All use is subject to monitoring, and there is no right to privacy when using company equipment. No user shall at any time send or store email that contains malware, a warning about malware, unsolicited commercial email, or that is considered pornographic or adult content in nature or would otherwise offend any other user of the system.

This document is part of a larger document called The Definitive Guide to Email Management and Security by Kevin Beaver.

Other sections in the document include:

• Email Policy Development and Management
  • User Awareness Training
• Storage Considerations
  • Backups
  • Fault Tolerance
• Email Retention
  • The Problem with Retrieval
  • Creating an Email Retention Policy
  • Enforcing Your Policy

Here’s an archived copy of the document: Email Acceptable Use Policy

Great info! Check it out!

The University of Connecticut has a great wireless security standards worksheet here.

It includes requirements for large deployments and small/individual deployments as well as requirements that are common for all deployments.

Here’s an excerpt:

Common Requirements

Please review the University Wireless Policy for policy related information.

Minimum Technical Requirements

• Locate APs on the interior of buildings instead of near exterior walls and windows as appropriate.
• Place APs in secured areas to prevent unauthorized physical access and user manipulation.
• Change the default service set Identifier (SSID).
• Ensure that AP channel selection utilizes the maximum amount of non overlapping channels for the given spectrum.
• Use WPA or greater encryption.
• APs shall not be plugged into network hubs.
• Ensure that all APs have strong administrative passwords.
• Use SNMPv3 and/or SSL/TLS for Web-based management of APs.
• Access points cannot interfere with any part of the central University wireless network
• When disposing of access points that will no longer be used, clear access point configuration to prevent disclosure of network configuration, keys, passwords, etc.

Here’s an archived copy of the standard: Wireless Security Standards

Great info! Check it out!

I’m a big proponent of creating a security policy hierarchy. It’s a great way to logically organize your policies and it helps you make sure you have all of your policy bases covered.

An excellent example of such a policy hierarchy can be found at the Lazarus Alliance site here.

The National Institute of Standards and Technology (NIST) has a document especially useful to anyone writing their vulnerability management policy. It’s Special Publication 800-40, Creating a Patch and Vulnerability Management Program. You can find it here.

Here’s an excerpt:

Organizations need to create a comprehensive, documented, and accountable process for identifying and addressing vulnerabilities, patches, and threats within an organization. One possible approach is to have a formal, centralized patch and vulnerability group that supports the security efforts of local system administrators.

Specific recommendations for organizations implementing a patch and vulnerability management program are as follows:

1. Create an inventory of all information technology assets.
2. Create a patch and vulnerability group.
3. Continuously monitor for vulnerabilities, remediations, and threats.
4. Prioritize patch application and use phased deployments as appropriate.
5. Test patches before deployment.
6. Deploy enterprise-wide automated patching solutions.
7. Create a remediation database (this is often included within enterprise patch management tools).
8. Use automatically updating applications as appropriate.
9. Verify that vulnerabilities have been remediated.
10. Train applicable staff on vulnerability monitoring and remediation techniques.

An archive copy of the document is here: Vulnerability Management Program

The American Institute of Certified Public Accountants (AICPA) and the Canadian Institute of Chartered Accountants (CICA) created an Incident Response Plan template which you can find here.

It contains a lot of useful info, including a good description of an Incident Response Team. Here’s an excerpt:

An Incident Response Team is established to provide a quick, effective and orderly response to computer related incidents such as virus infections, hacker attempts and break-ins, improper disclosure of confidential information to others, system service interruptions, breach of personal information, and other events with serious information security implications. The Incident Response Team’s mission is to prevent a serious loss of profits, public confidence or information assets by providing an immediate, effective and skillful response to any unexpected event involving computer information systems, networks or databases.

The Incident Response Team is authorized to take appropriate steps deemed necessary to contain, mitigate or resolve a computer security incident. The Team is responsible for investigating suspected intrusion attempts or other security incidents in a timely, cost-effective manner and reporting findings to management and the appropriate authorities as necessary. The Chief Information Security Officer will coordinate these investigations.

The Incident Response Team will subscribe to various security industry alert services to keep abreast of relevant threats, vulnerabilities or alerts from actual incidents.

It also suggests that the incident response team be composed of the following members:

• Information Security Office (ISO)
• Information Technology Operations Center (ITOC)
• Information Privacy Office (IPO)
• Network Architecture
• Operating System Architecture
• Business Applications
• Online Sales
• Internal Auditing

An archive of the template can be found here: Incident Response Plan Template

Great info! Check it out!

I wrote a generic e-mail filtering standard.

Here’s an excerpt:

3.1 Content Filtering

Employ a content filtering mechanism that scans all incoming e-mail messages and their attachments and manages the messages depending on the results of the scan.

3.1.1 Suspicious Content

Strip suspicious active content (ActiveX, JavaScript, etc.) from e-mail and forward to quarantine.

3.1.2 Prohibited Words

Quarantine e-mails that contain words or phrases that indicate the e-mail is “junk” or “spam”, words in the “Carlin List” and words that are racist, libelous, offensive or obscene.

3.1.3 Outbound Filtering

Protect the organization from possible litigation or loss of sensitive data by implementing outbound e-mail filtering.

3.1.3.1 Quarantine outbound e-mails that contain words or phrases viewed as inappropriate for use in organizational e-mail, including hoaxes and “spam”.
3.1.3.2 Quarantine outbound e-mails that contain words or phrases that indicate sensitive data is leaving the organization.

An archive of the standard is here: E-mail Filtering Standard

Let me know if you have any suggestions!

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

A very helpful part of this template is the classification labels section. Here’s an excerpt:

CLASSIFICATION LABELS

Public: This classification applies to information that is available to the general public and intended for distribution outside the organizations. This information may be freely disseminated without potential harm. Examples include product and service brochures, advertisements, job opening announcements, and press releases.

For Internal Use Only: This classification applies to all other information that does not clearly fit into the other classifications. The unauthorized disclosure, modification or destruction of this information is not expected to seriously or adversely impact the organization, its patients, its employees, or its business partners. Examples include the company telephone directory, new employee training materials, and internal policy manuals.

Confidential: This classification applies to information that is intended for use within the organization. Its unauthorized disclosure could adversely impact the organization, its patients, its employees and its business partners. Information that some people would consider private is included in this classification. Examples include medical information (except that which is restricted confidential), patient medical charts, appointment schedules, patient account records, department financial data, purchasing information, vendor contracts.

Restricted Confidential: This classification applies to the most sensitive medical and business information that is intended strictly for use within the organization. Its unauthorized disclosure could seriously and adversely impact the organization, its patients, its employees and its business partners. For example, statutorily protected medical information such as, mental health treatment, HIV testing, sexually transmitted diseases, abortion, and alcoholism or substance abuse treatment data. Other examples are merger and acquisition documents, corporate level strategic plans, and litigation strategy memos.

An archive of the template is here: Data Classification Policy Template

Check it out!

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!