Re: Policy ? (was RE: Penetration Tests)

[Bennett Todd <bet () rahul net>]

On Fri, Sep 26, 1997 at 02:36:49PM -0500, Capt Jim Bailey - SSG/SINS - DSN 596-6106 wrote:
> I think everyone agrees that having a solid security policy is needed before
> implementing any feasible security architecture.  My question is what does
> this policy encompass?  My question is not directed at the technical details
> of how to get things done, but more towards the high level that has to be 
> sold to Joe and Jane user, the management, etc.  Are you looking at writing
> a document that states such general things like "don't use the network for
> unofficial business"? Or do you get more specific like "all web traffic
> will be proxied and only alowed to the following sites..."

Now _there's_ a provocative question!

I don't have the expertise to offer any kind of general answer; I doubt many
people have. The short answer is of course "Yes"; it might say "don't use
the network for unofficial business", it might say "all web traffic will be
proxied and ...". Exactly what it says will vary widely, and better closely
reflect the specific needs of the organization --- though use of proxies is
less likely to belong in the policy manual; that's just one way to implement a
policy.

It might even say "All users have access to email, which may be examined; some
users have access to http, and the list of ULRs they visit may be examined;
a few can be granted access to telnet and/or ftp and session data may be
scrutinized. Http traffic will have all references to active content stripped
out. Oh, and by the way, no machine may be connected to both the inside of our
security perimeter (the in-house net) and the outside (e.g. an ISP dialup)
except the company firewall." I'd say that's a fairly common shape to a
security policy for a financial institution.

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