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!

When you write your wireless security standards, make sure you don’t fall into the trap of including wireless LAN security myths in them.

George Ou has written extensively about wireless LAN security and he’s published several articles on common wireless LAN security myths in ZDNet over the years. His latest article, “Wireless LAN security myths that won’t die” can be found on his ZDNet blog here.

He categorizes the myths he debunks as follows:

Waste of money, resources, time

• MAC filtering
• Disable DHCP and use Static IP addresses
• Signal suppression with expensive paint or antenna placement

Worse than no wireless security at all

• LEAP (adding EAP-FAST to the list)
• SSID Access Point beacon suppression (or “hiding”)

Has nothing to do with security mechanisms

• Just use 802.11a or Bluetooth

Even if you’re not writing your wireless security standard, read George’s article and make sure you aren’t spreading myths and making yourself look dumb in front of others who know better!

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!