Nmap Security Scanner
*Intro
*Ref Guide
*Install Guide
*Download
*Changelog
*Book
*Docs
Security Lists
*Nmap Hackers
*Nmap Dev
*Bugtraq
*Full Disclosure
*Pen Test
*Basics
*More
Security Tools
*Pass crackers
*Sniffers
*Vuln Scanners
*Web scanners
*Wireless
*Exploitation
*Packet crafters
*More
Site News
Site Search:
Exploit World
Advertising
About/Contact
Credits
Sponsors:




firewall-wizards logo Firewall Wizards mailing list archives

Security Policy (was Re: how to do intrusion detection right)
From: Bennett Todd <bet () rahul net>
Date: Wed, 15 Apr 1998 04:03:54 -0700

Here I'm not using "policy" in the usual computer security sense,
of an unyielding set of rules; perhaps it's more an intent of
what should and shouldn't be going on.

I've worked in one shop where the Data Security Department suffered
from the delusion that a security policy can or should be an unyielding
set of rules. That was maybe 8 years ago, all the major staff of that
department are blessedly gone, and as far as I know the damage hasn't
been undone yet; if any security work is accomplished in that firm
it's not done by the Data Security department, as the people in that
department gave it a reputation for being utterly useless, and mildly
destructive if not ignored.

I've since had some wonderful good fortune. I came to work at a shop
that had intelligent and wise management, and then saw another example
of the same at a truly superb ISP. In the _good_ places I've had a
chance to see a Policy as a kind of a cache: decision-making is _hard_,
so whenever you work through a meaty one, make a note of the
circumstances that seemed to guide the decision and the conclusion you
came to, and lean on precedent in future decision-making.

When you view it that way it becomes obvious that a Policy is a living
document. This has enormous value.

The most tricky and delicate part of security administration is getting
the users to support the policy. The first part of dealing with this
comes as you're formulating the policy, but the ongoing work comes in
selling it. Typically a user comes and says they want to do something,
and they can't, please fix it. What they want to do (e.g. view a web
page with applets) is prohibited by the policy. So you explain to them
why the policy is as it is, what the cost to the organization would be
of relaxing the policy. You try to find an alternative way to meet their
needs. And you pitch your explanation of why they can't do what they
asked in such a fashion that they know who they'll have to approach, and
what argument they'll have to overcome, to get the policy changed to
suit them.

Do this right and the user community comes to really actively support
the security policy; then you can start doing your job _right_.

-Bennett



  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]