The Laptop Security Blog over at www.absolute.com has an interesting post about how the Auditor General of Canada says government agencies aren’t upholding the Government Security Policy (GSP).

In particular, the Auditor General said that the security policy doesn’t include a disaster recovery plan.

Even if you work in a company you can expect that auditors are going to look for a disaster recovery policy and disaster recovery plan in your corporate security policy.

Here’s a fun security training video that could be useful to explain the value of security policies and security concepts like defense in depth:

I like how it incorporates Second Life as a training tool. 

The educause.edu site has a chapter from the book Computer and Network Security in Higher Education here.

It does a good job of describing how university security policies should be written.

Here’s an excerpt:

If the goal of institutional policies is to direct individual behavior and guide institutional decisions, then the effectiveness of formal policy statements will depend on their readability and usefulness. Many colleges and universities suffer from the lack of a common and consistent approach or format for writing organizational policies. Policy development is often confused and sometimes derailed because of the misunderstanding and misuse of terms with important meanings to a professional policy administrator, legal counsel, and others.

You can download an archive copy of the chapter here.

This is a great site to find a ton of actual security policies and procedures used by universities.

Here’s a sample of some of the university policies available:

• Data Handling and Storage Policy (Adams State College)
• Secure Handling of Social Security Numbers (Northwestern University)
• Data Access, Security, Classification and Handling (Purdue University)
• The Payment Card Industry (PCI) Data Security Standard (Duke University)
• Information Access & Protection Standard (Rochester Institute of Tecnology)
• Data Classification Security Policy (George Washington University)

Lots of helpful security policy templates for you to use. Check it out!

The IT Security group at the California Department of Techonology Services (DTS) have a security incident response presentation here that describes their incident response plan.

This presentation includes a couple of scenarios where they demonstrate how to implement the Security Incident Lifecycle:

• Security Incident Identification
• Security Incident Triage
• Security Incident Response & Resolution
• Security Incident Communication (concurrent)
• Post Security Incident Documentation

Great info!

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