Joel Weise and Charles R. Martin from Sun wrote an excellent Data Security Policy guide which you can download here.

This is a great reference to follow when developing any data security policy.

Here’s an excerpt:

The purpose of this document is to define the Data Security Policy. Data is considered a primary asset and as such must be protected in a manner commensurate to its value. Data security is necessary in today’s environment because data processing represents a concentration of valuable assets in the form of information, equipment, and personnel. Dependence on information systems creates a unique vulnerability for our organization.

Security and privacy must focus on controlling unauthorized access to data. Security compromises or privacy violations could jeopardize our ability to provide service; lose revenue through fraud or destruction of proprietary or confidential data; violate business contracts, trade secrets, and customer privacy; or reduce credibility and reputation with its customers, shareholders and partners. This policy therefore discusses:

• Data content
• Data classification
• Data ownership
• Data security

The main objective of this policy is to ensure that data is protected in all of its forms, on all media, during all phases of its life cycle, from unauthorized or inappropriate access, use, modification, disclosure, or destruction. This policy applies to all of our and all customer data assets that exist, in any of our processing environments. The processing environment is considered to be, collectively, all applications, systems, and networks that we own or operate or that are operated by our agents.

Very helpful! Check it out!

Walter Kobus at TESS (http://www.tess-llc.com/) has made available his Identification and Authentication Policy here.

His policy covers the key elements required in any Authentication Policy. Here’s an excerpt:

Policy
Access to the [ORGANIZATION]’s information assets will be granted on different levels, based on the business rules established by data owner’s of that information, for an authorized user or entity to create, read, update, delete or transmit that information. Users will be provided access based on the concept of “least privilege.” Access will be managed and controlled  through discretionary access controls, identification and authentication, and audit trails.

Use of the [ORGANIZATION]’s information assets shall be restricted and shall be allowed only as necessary to support authorized business activities. The business rules currently in effect in conjunction with the [ORGANIZATION]’s user-based access controls shall be reviewed for
adequate security level access and protection, and may serve as the foundation for establishing compliance with this policy.

Any effort to circumvent the [ORGANIZATION]’s information security mechanisms to gain access or to exploit any known or unknown vulnerabilities shall be perceived as a security incident, and shall be handled in accordance with established incident reporting guidelines and/or
appropriate human resources policies and procedures.

All of the [ORGANIZATION] information is considered an asset and is protected, in all of its forms, from accidental or intentional but unauthorized, disclosure (confidentiality), modification or destruction (integrity), or the inability to process that information (availability).

Walter requires a $5 fee for using or adapting his copyrighted policy. That’s a bargain in my opinion.

Check it out!

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!

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!