Changing Policies (was Re: Policy ? )

[John Lines <John.Lines () aeat co uk>]

Bennett Todd said (among many other good points about security policy)


> Your security policy needs to state what your security admin is charged with
> accomplishing; the list of what's permitted and what's prohibited needs to
> cover everything anyone cares about; the policy statement is the security
> admin's authority. Management needs to have decided (with advice and guidance
> from security experts) what the organization needs -vs- what it can't afford.
> What's more, since it gets so very detailed, it needs to be a flexible,
> easily-changed document; needs and risks change over time. When your security
> policy is really a strong, living document, users feel good about it; when
> conflicts come up between their needs or wishes and the policy, they either
> get a clear explanation of the risk to the firm that's being defended against,
> or else they get the policy revised ao allow what they want. That sort of
> interaction gives you a strongly supportive user community, and that's another
> absolutely mandatory part of good working security. You can try to erect
> strong barriers to prevent ``inside jobs''. I doubt you'll succeed.
>
> -Bennett

It helps to have a change mechanism built into your security policy. In
our case all policy changes need to be agreed by a security review group.
This consists of the Internet Manager (me), my boss, the security manager,
and representatives from our user community.

The user representatives are all senior enough to speak for their areas of
the organisation, but technical enough to understand the implications of
a proposed change.

I present the review group with a business case (usually from someone 
internally),
and a proposed way of implementing the change in a secure manner, together
with an analysis of the risks, costs etc.

If I cant convince them to pass the change then we dont do it.

I find it is a very useful discipline to have to explain, to an audience who
are all very intelligent, but not nescessarily computer specialists, exactly
how a change is going to be made.

It is suprising how many requirements for, e.g. RealAudio through the firewall,
go away when I ask for the business case so I can present it to the review
group.

In our case it is particularly important to have the support of the user
community as we have a lot of bright scientists and engineers, who might
feel justified in working out a way to bypass our firewall if they thought
it was just an obstruction imposed on them. Having a reasonable change process
reduces the risk of 'inside jobs'

                John Lines