Recently in Policy writing Category

I have just started to consolidate several best practices and operational procedures for handling confidential information. I am using the results of this effort to set a confidential information handling policy. It seems that the policy itself may turn out to be very simple:

1. Confidential information may only be collected, stored and processed if a need to do so exists, and if that need cannot be satisfied in any other way.
2. Confidential information must be destroyed when it is no longer needed.
3. Confidential information must be handled with due care.
4. When loss of or unauthorized access to information has been detected, or if it is suspected, the Information Security Officer must be notified and an information security incident will be declared.

Is there anything I need to address at the policy-level? Obviously, at the level of the supporting standard, the requirements for due care must be established in more detail, but this seems to mostly cover it.

A 0day with an automatic discovery and dissemination tool shouldn't be a surprise to anyone. The fact that it's hit hundreds of thousands of sites in less than a couple of weeks is slightly surprising, though it mainly means that the bad guys are moving fast. Is this just the next step in Internet security, where we have new 0day vulnerabilities sweeping through web servers on a regular basis?
Source: Network Security Blog

Observations like this once more seem to reconfirm that the bad guys are increasingly focusing on OSI layer 7 and above. While not to be ignored, simply putting up a firewall to keep unwanted traffic out, and an IDS to make sure the firewall is working well (or an IPS, if you prefer) is not sufficient.

One of the responsibilities assigned to me in my current position is the development and implementation of a comprehensive information security policy. In line with the premise that what you do not know about, you cannot protect, I started with drafting an information classification policy.

In researching that policy at other organizations, most of the examples that I found focused on the well-known categories: public, sensitive, and confidential, or variations on that theme.

A Haiku:

The Security Catalyst Community is a group of information security practicioners, designed to support those responsible for protecting information by providing a professional, supportive environment to ask for help, foster a culture that welcomes ideas; share your experiences and insights regardless of your experience, and share your passion and blend your energy with others.

A recent topic (registration required) that sparked my interest is Eliminating Bad Passwords. I think that topic should have been: Eliminating Passwords.

Recently, I have been thinking about what the roles and responsibilities of an information security manager should be. These thoughts partially originated from an academic desire to form a complete picture of what information security management at mid-tactical to strategic level could entail, and partially from a direct need to establish my own responsibilities.

Information Security people often come from a highly technical background. As they move up through the ranks, and achieve management level, one of the hardest things turns out to be how to write a good policy. When I was confronted with this problem, I decided to take a step back and worry about developing a framework and a policy life cycle, before any real policies would be written.

One of the most fundamental steps in an information security program is to have a sound policy. It sounds boring, but it is absolutely required, as having a policy that is shared, supported and approved by the highest level of management gives direction, and mandate. It gives the information security officer the ammunition he needs: "because the president says so" is always more convincing than "because I say so"

While working on a draft policy for remote access company systems, an article hit my inbox. The title by Joel Dubin is titled Partner access: Balancing security and availability.

In reality, secure partner access is just an extension of existing access management for mobile and remote employees -- but with a few twists. Employees are already enrolled in the organization's directory service, whether Active Directory, LDAP or some other system. They're company insiders who are already part of the network, not outsiders from another network with a different IT security set up.

I have been working on documenting how information securities should be written and implemented. The gist of it is:

Only write a policy when there is a real need to do so. When a policy is written, keep it as short as possible. Make sure that any requirements identified in the policy can be monitored and enforce compliance. Always make sure that implementing a policy does not prevent necessary work from getting done, or incur unreasonably high costs. For this reason, all policies should identify if deviation of the policy is permissible and if so, which role may authorized these deviations.

When I sent out the full document for review, one of my coworkers come up with the following gem:

"As XXX can attest, the sysadmins have been looking forward to the time when some policies might be implemented, though I would say that we envisioned policies that applied to the user community, rather than ourselves " I thought that was pretty funny :-)

And on a totally unrelated note: SANS just published their new SANS Top-20 2007 Security Risks (2007 Annual Update) report. I am sure that many other bloggers will comment on it, so I will refrain from doing so. For example, terminal23 blog was the first one that I read.

In a post on the Security Catalyst forums (register for full access), I found a link to a post by Prof. Eugene Spafford of Purdue's Center for Education and Research in Information Assurance and Security on the CERIAS Weblog. The title of the post is Security Myths and Passwords, and it contains some very insightful observations.