If you’re planning on writing a policy defining the rules of user authentication, here’s a short and sweet Authentication Policy from Auburn University that might be a helpful reference.

Here’s an excerpt:

I. PURPOSE
To ensure that only authorized users have access to Auburn University computers.

II. POLICY
Auburn University computers will be configured to require authentication at startup.  When possible, authentication will be done through official domain facilities, otherwise authentication will be established on each individual machine.

Auburn University computers will be configured to have a screen lock that engages after no more than 30 minutes of inactivity and which requires re-authentication. When possible, the screen lockout will be controlled through official domain.

There’s probably more that you should include but this is a good start.

There’s a helpful draft Information Security Classification Policy from Rutgers University here.

They define three classification levels. Here’s an excerpt:

Restricted Data

Restricted data is the most sensitive information and requires the highest level of protection. This information is usually described as “non-public information” about people and under the purview of a Data Custodian. Restricted data also includes data that Rutgers is required to protect under regulatory or legal requirements. Examples include student or employee identifiable information (i.e., Social Security Number, birth date, driver’s license number, etc.), financial records, medical records, legal records, student records, police records, and credit card information. Unauthorized disclosure of restricted information could result in adverse legal, financial or reputational impact upon the University.

Sensitive Data

Sensitive data is information that business units may decide to share with other units outside their administrative control for the purpose of collaboration. This information is not information that meets the requirements of “non-pubic” information. Examples include data created by the department, research data, and project data. Loss of this information could cause harm to the University’s image or reputation, but would not necessarily violate existing laws or regulations.

Public Data

Most Rutgers information falls into this classification under the “New Jersey Right to Know” law, is suitable for public dissemination and is accessible to anyone in the world. Examples include public web pages, course listings, press releases, marketing brochures, etc. While the requirements for protection of public data are less than that of Restricted and Sensitive, sufficient controls must be maintained to protect unauthorized modification of data.

Check it out!

I wrote a generic outsourcing policy for a presentation I’m giving on outsourcing security services.

Here’s the general outline:

• Purpose
• Scope/Applicability
• Policy Statement
  • Board and Management Responsibility
  • Risk Mitigation Strategies: Outsourcing Team
  • Business Case
  • Due Diligence
  • Business Continuity Management (BCM)
  • Contractual Agreements
  • Management and Control of the Outsourcing Relationship
  • Offshoring
  • Final Approval

Here’s an excerpt:

1.0 Purpose

The purpose of this policy is to establish the requirements for identifying, justifying, and implementing outsourcing arrangements for any Organization XYZ function.

2.0 Scope

This policy applies to all workforce members within Organization XYZ. It must be followed whenever Organization XYZ functions are outsourced.

3.0 Policy

To conduct operations as effectively and efficiently as possible, Organization XYZ may find it advantageous to outsource (use outside contractors for) certain functions. To ensure compliance with security objectives, these requirements must be followed:

You can download a copy of the policy here: Outsourcing Policy

I found a HUGE document of information security policies on the South African Government Information website: http://www.info.gov.za/

The policies document is almost 500 pages and includes the following chapters:

• Securing Hardware, Peripherals and Other Equipment
• Controlling Access to Information and Systems
• Processing Information and Documents
• Purchasing and Maintaining Commercial Software
• Developing and Maintaining In-House Software
• Combating Cyber Crime
• Complying With Legal and Policy Requirements
• Planning For Business Continuity
• Addressing Personnel Issues Relating To Security
• Controlling E-Commerce Information Security
• Delivering Training and Staff Awareness
• Dealing With Premises Related Considerations
• Detecting and Responding to IS Incidents
• Classifying Information and Data

I’ve included an archived copy of the document below. Check it out!

South African Information Security Policies

This blog entry from the Security Monkey at ITToolbox.com is shaping up to be a very handy list of security policy websites. Entitled, “Where Do You Get Your Security Policies From?”, the Security Monkey asks readers to respond with websites that they use for researching security policies.

Included in the suggestions are:

• http://www.sans.org/resources/policies/
• http://csrc.nist.gov/publications/nistpubs/index.html
• CoBIT (http://www.isaca.org/cobit)
• ISF Security Standard (http://www.isfsecuritystandard.com)
• ISO27XXX series (http://www.iso.ch)
• IT Baseline Protection Manual (http://www.bsi.de/english/gshb/index.htm)
• Plus many more

Definitely worth checking out!

If you’re in the medical field and you need to write your medical record retention policy, a good sample record retention policy can be found at the University of Texas Medical Branch at Galveston (UTMB) policy website here.

It’s interesting to see that they permanently retain their medical records.

Here’s an excerpt:

The University of Texas Medical Branch at Galveston (UTMB)
permanently retains medical records for patient care, education,
research and to meet legal requirements.

The Health Information Management Department (HIM) is
responsible for maintaining these records regardless of medium type.
This includes all microfilm/fiche, paper or electronic, computer-based
systems that may be retired because of improved systems operations,
upgrades, or a conversion to alternate application.

An archived copy of the policy is here: Medical Record Retention Policy

Check it out!

E-mail archiving company Fortiva has a nifty tool for building your own customized Electronic Communications Policy at their site here.

You have to register to use it, but I think the policy you get is worth it. The policy can be customized with your company or organization name and specific sections can be added or removed. When you’re ready you can convert it to a PDF complete with your corporate or organization logo.

Here’s an exerpt of the policy I created:

Email Record Retention

Default Retention Policy for Archived Email

[Company Name] treats electronic communications as a business record. Business records are subject to federal and state/provincial laws as well as [Company Name] records management policies. This section is not intended to replace existing record retention policies and procedures but to enable its enforcement using an automated archiving solution that matches the classification and retention schedule outlined in the [Company Name] Record Retention handbook.

As required by applicable regulation, [Company Name] maintains a system that makes a long-term record of emails received and sent through the [Company Name] network. Any email received or sent is subject to review by the regulatory authorities. These records are created as a matter of regulatory compliance and are not to be used for ordinary operational purposes and are not a substitute for ordinary daily management of email.

The Fortiva policy is designed to help organizations comply with new Federal Rules of Civil Procedure (FRCP).

Check it out!

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!

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