Hi Brad,
In general agree with your response.
We have often described it as follows to our clients in terms of the 5 W's +
H;
Policy documents describe the - Why and the What, often giving the "mandate"
from the top exec or delegate
Procedures describe - who (does it), when (it is performed), and where (it
is performed) as well as the HOW (the doing steps of the task broken down in
single bite sized chunks and also how often),
We have conducted a number of consultancies for clients on writing policies
and procedures in terms, of coaching etc and its worked for our clients who
are the content experts (so they tell us). They just used to get tripped up
on policy and procedures and often confused and mixed the 2 up in many and
varied ways.
Regards
Rob Harmer
______________________________________________
PCProfile http://www.pcprofile.com
e-mail pcprofile@internode.on.net
Mobile Phone +61 (0) 418 817 955 (only after 6pm due to security
restrictions)
Fax+61 8 8265 1961
______________________________________________
-----Original Message-----
From: Brad Bemis [mailto:bradleyb@bradleyb.net]
Sent: Monday, 16 January 2006 4:46 AM
To: security-management@securityfocus.com
Subject: RE: How to organize a lot of policies?
Everyone has there own views on policies and how they should be put
forward. Here are just a few notes about how I've approach policies
in the past - and have worked well. I am now with a new company
(since December) and am neck deep in this process once more, so I am
happy to speak with anyone who wants more information.
I generally tend to take a layered approach to policy development:
- Security Principles: A high level set of basic bullet points that
describe the company's position on information security and can be
used in making decisions for which no guidance is available. The
GAISP pervasive principles offer a good starting point for this.
- Security Policies: High-level statements of the companies goals and
expectations in relation to a specific control area. For each control
just use a sentence or two that puts the expectation in plain simple
wording, and then maybe a short paragraph to provide some basic
explanation of the intent behind the policy statement. ISO 17799
provides an excellent basis for this kind of policy development.
Supplemented by things like Information Security Policies Made Easy,
COBIT, the FFIEC IT Examiners Handbook series, etc. just make sure
that you make them appropriate to the needs of your organization.
- Security Standards and Guidelines: These are where you more fully
explain the policy elements that require an additional level of
detail. Standards represent those things that must be done in order
to comply with policy, and guidelines represent those things that
aren't required, but should really be considered. This is where very
specific best practice materials like the CERT Guide to Network and
Security Best Practices or the Center for Internet Security's
hardening recommendations might come into play. It is also one of the
areas that people get confused about during policy development - keep
the policies high level and build the details into your security
standards and guidelines.
- Procedures: Actual step by step instructions on how to implement a
standard, guideline, policy, or whatever. A checklist formatted
procedure document for performing a project-based risk assessment for
a particular type of deliverable might be a good example, as would a
procedure for managers requesting access to a resource on behalf of
one of their employees - the list can get quite long, but over time
you can assemble a pretty good library of these.
The next part covers organization:
Organization is very important. In considering the approach that is
most appropriate to the needs of you organization, you should look at
how you plan to conduct your security awareness campaign. Those
materials that will be placed into regular use by the majority of your
user constituency should get the primary focus - Acceptable Use,
Information Asset Ownership and Classification, Event Reporting and
Incident Response, etc. I generally tend to make the Acceptable Use
policy the real cornerstone and use it as a way to summarize those
policies that are most relevant to the needs of a broad audience. It
is also the one policy that I require a signature on (using a web
based tool). Placing these up on a corporate website that is linked
in to the rest of your corporate policies from HR is another key
consideration - it helps lend credence to their applicability as
opposed to people just seeing them as IT requirements. The structure
that you use should keep the principles at the forefront, the policy
statements themselves should just be bullet points that can be clicked
on for additional details, links should be provided for going into the
standards, guidelines, and procedures. Everything needs to be fully
indexed and cross referenced - perhaps managed through the use of a
backend database. You should also consider adding a change page so
that when new materials are published, or existing ones are altered,
you have a way to focus people in on what has changed.
The next steps enter more deeply into your awareness campaign and
should include subsets of materials pulled together into handouts and
other quick reference tools that are targeted to meet the specific
needs of a group - perhaps a Computer Users Security Handbook and/or
an Information Security Handbook for Project Managers, etc. There are
many variations that can be delivered, and they can pull directly from
those principles, policies, standards, guidelines, and procedures that
address the specific needs of the target audience. You could also
offer on-line versions of these, create classes to walk people through
them and simulate their use in a day to day working environments -
whatever. Again, this gets into the broader discussion of security
awareness. They key takeaway here is that in order for any policy to
have validity, it must be effectively communicated to the people that
it impacts. Otherwise you cannot have a reasonable expectation for
compliance, which greatly limits your ability to hold people
accountable.
Ultimately, that is what your policy structure and guidance comes down
to - defining the rules, educating people on what they are, and
holding them accountable for their actions.
It is no small undertaking, so best of luck in your endeavors...
