On Jun 4, 2006, at 4:59 AM, <tom.psrc (at) hushmail (dot) com [email concealed]> wrote:
> I think most information security policies are written for security
> departments themselves and not for the business.
Not in my experience - when they are written to fulfill an external
mandate they may be, but policies have to be approved by the CEO and
board and become legally binding in the sense that they induce
liability.
> They generally
> don't explain to people what they can and so are just seen as
> another set of silly rules to ignore.
If poorly implemented this is true. But in a proper environment,
policies can be very helpful in guiding decisions, processes, and
actions.
> Information security people
> are generally (and yes broad generalization) not established
> writers.
This is true - but some of us have enough experience writing to be
capable of putting pen to paper (light to laser?) when we have to.
> You only have to look at the Sans policy examples or even
> Charles Cresson Woods policy templates for examples of dull
> lifeless content that is sure to be ignored!
Yes they are - but on the other hand, I am currently writing a
complete ISO-17799:2005 based policy for a large enterprise (it takes
about 3 months of collaboration and costs about $125K) and along the
way we are implementing many of the provisions within it (not
included in the $125K of course). They are seeing a measurable
improvement in protection along the way and fulfilling other legal
and regulatory obligations without incurring large costs of
implementation because they have made reasonable policy decisions.
> I must confess to having taken a long vacation and not updating the
> PSRC
> Wiki as I wanted to. The list seems a bit slow so I thought I would
> stimulate some discussion.
>
> Why do most information security policies fail?
Because the CISO is poorly positioned, inadequately empowered and
knowledgeable, the organization doesn't really want an effective
protection program, and top management is not enlightened as to the
need.
> Is it because they are written in the negative context (you can't
> do this or
> you can't do that)?
This is a poorly written policy. A good policy consists largely of
"you must" and not "you may not".
> Is it because companies can't (or don't) track who has read them
> and how
> much they understand them?
A proper policy includes the training and awareness requirements,
process definitions to mandate that key decisions makers interact
with risk management on a regular basis to make decisions, and so
forth. They are not designed to be read by everyone but rather to
guide the development of processes and standards that are then
actively applied.
> Is it because they are usually not supported by material to help
> people
> implement them?
A set of control standards to go along with policies costs on the
order of $250K-$500K and the procedures which really have to be
internally implemented take even more time and effort.
> Is it because they are not kept current?
A properly defined and written policy set for a large enterprise
should not have to be changed more than once every few years and then
it tends to be a relatively small change to reflect external events.
Control standards get developed over time to meet emerging needs, but
existing ones only change every few years (perhaps 3) to reflect
changes in technology and business approaches. Procedures change
whenever the operating environments or business structures change
The problems you identify are the result of a poorly written policy
that is not a policy really but rather a mishmosh of rules and
statements make by people who had to do it tactically after a bad
thing happened because they were not permitted or did not realize
they should do it strategically.
Plenty of folks have this situation, but it is curable.
-- This communication is confidential to the parties it is intended
to serve --
Security Posture securityposture.com tel/fax
University of New Haven unhca.com 925-454-0171
Fred Cohen & Associates all.net 572 Leona Drive
ASP Press asp-press.com Livermore, CA 94550
> I think most information security policies are written for security
> departments themselves and not for the business.
Not in my experience - when they are written to fulfill an external
mandate they may be, but policies have to be approved by the CEO and
board and become legally binding in the sense that they induce
liability.
> They generally
> don't explain to people what they can and so are just seen as
> another set of silly rules to ignore.
If poorly implemented this is true. But in a proper environment,
policies can be very helpful in guiding decisions, processes, and
actions.
> Information security people
> are generally (and yes broad generalization) not established
> writers.
This is true - but some of us have enough experience writing to be
capable of putting pen to paper (light to laser?) when we have to.
> You only have to look at the Sans policy examples or even
> Charles Cresson Woods policy templates for examples of dull
> lifeless content that is sure to be ignored!
Yes they are - but on the other hand, I am currently writing a
complete ISO-17799:2005 based policy for a large enterprise (it takes
about 3 months of collaboration and costs about $125K) and along the
way we are implementing many of the provisions within it (not
included in the $125K of course). They are seeing a measurable
improvement in protection along the way and fulfilling other legal
and regulatory obligations without incurring large costs of
implementation because they have made reasonable policy decisions.
> I must confess to having taken a long vacation and not updating the
> PSRC
> Wiki as I wanted to. The list seems a bit slow so I thought I would
> stimulate some discussion.
>
> Why do most information security policies fail?
Because the CISO is poorly positioned, inadequately empowered and
knowledgeable, the organization doesn't really want an effective
protection program, and top management is not enlightened as to the
need.
> Is it because they are written in the negative context (you can't
> do this or
> you can't do that)?
This is a poorly written policy. A good policy consists largely of
"you must" and not "you may not".
> Is it because companies can't (or don't) track who has read them
> and how
> much they understand them?
A proper policy includes the training and awareness requirements,
process definitions to mandate that key decisions makers interact
with risk management on a regular basis to make decisions, and so
forth. They are not designed to be read by everyone but rather to
guide the development of processes and standards that are then
actively applied.
> Is it because they are usually not supported by material to help
> people
> implement them?
A set of control standards to go along with policies costs on the
order of $250K-$500K and the procedures which really have to be
internally implemented take even more time and effort.
> Is it because they are not kept current?
A properly defined and written policy set for a large enterprise
should not have to be changed more than once every few years and then
it tends to be a relatively small change to reflect external events.
Control standards get developed over time to meet emerging needs, but
existing ones only change every few years (perhaps 3) to reflect
changes in technology and business approaches. Procedures change
whenever the operating environments or business structures change
The problems you identify are the result of a poorly written policy
that is not a policy really but rather a mishmosh of rules and
statements make by people who had to do it tactically after a bad
thing happened because they were not permitted or did not realize
they should do it strategically.
Plenty of folks have this situation, but it is curable.
-- This communication is confidential to the parties it is intended
to serve --
Security Posture securityposture.com tel/fax
University of New Haven unhca.com 925-454-0171
Fred Cohen & Associates all.net 572 Leona Drive
ASP Press asp-press.com Livermore, CA 94550
[ reply ]