-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
IMHO...an additional policy would include something to the effect:
"...the security manager shall escrow with the (pick one
here..President, Technology manager, Operations manager...) office
all passwords, access controls, keys and other such mechanisms to
which the Security Officer normally has the only access. This
information shall be placed in a sealed envelope, proctected by a
security seal or other tamperproof mechanism, and locked in a secure
cabinet, safe or desk to which only the escrow officer has access.
This information shall be updated and re-sealed upon any change
within the same business day such changes are made"....
If the S.O. **DOES** get hit by a bus, at least SOMEONE can get
access to the FW, routers and other things should it become
necessary.
Comments welcome...Flames Ignored!
At 04:59 PM 11/5/97 +0000, Craig I. Hagan wrote:
>> Craig,
>> please tell me your opinion on this statement of mine (many people
have
>> been burned alive for much less than that).
>>
>> A firewall is something that must not be tampered with, so the
fewer people
>> know something about it (in the organization it is there to
protect) the
>> better. Thus, a UNIX O.S. is a good thing in an environment where
many
>> people know NT, i.e. almost everywhere.
>
>many takes.
>
>the short one is that if the above were true, and the firewall
person
>left, was hit by a bus, etc, then the company is *FUCKED*.
Additionally,
>you may need to change the firewall to reflect changes in security
policy
>-- after all, the firewall merely enacts policy, it doesn't create
it.
>
>A better method, imho, of saying it (perhaps what you meant) would
be:
>
>"
>Firewalls exist to enact corporate security policy. Since this
policy
>changes infrequently, access controls to the firewall should be both
>severely restricted, and logged in such a way as to make any and all
>actions obvious to an experienced administrator. Additionally, all
changes
>made to the firewall must go through authorized change control
procedures
>so that they can accurately reflect the security policy, and the
coding
>can be properly reviewed to make sure that policy is correctly
enacted.
>"
>
>IMHO, knowledge is a good thing: if everyone knew about the
firewall, how
>it worked, and WHY it did what it did, and even the source code of
the
>firewall, it shouldn't matter if the firewall properly enacts your
>policies (and they demand stringent access control). In fact, if the
>people in the company were knowledgeable, then they would likely
know the
>policy and WHY it was in effect.
>
>As for the OS choice of the firewall, unix/NT/OS2/mac/DOS/whatever,
>security through obscurity is the worst case scenario in that you
are
>banking on people not knowing something rather than proper access
controls
>and channels to facilitate this.
>
>A better question might be: if you are using
unix/NT/OS2/mac/DOS/whatever
>for a firewall, how could people (both internal and external) gain
>unauthorized access to the firewall? If your policy states that this
>should not be, then you should take every action to prevent it. For
an NT
>machine, it may mean not participating in a domain, blocking all of
the
>RPC/auth/whatever ports,disabling a rack of services,etc. for unix
it may
>mean not participating in a YP/NIS domain, not running
RPC/portmapper and
>a myriad of other daemons, etc. same ideas, different OS. But, all
comes
>down to policy and properly enacting it.
>
>
>-- craig
>
>---------------------------------------------------------------------
- ----------
>Craig I. Hagan "It's a small world, but I wouldn't want to back
it up"
>hagan(at)cih.com "True hackers don't die, their ttl expires"
> "It takes a village to raise an idiot, but an idiot can raze a
village"
>
> Stop the spread of spam, use a sendmail condom!
> http://www.cih.com/~hagan/smtpd-hacks
>
>
>
-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
Charset: noconv
iQA/AwUBNGIYqtIk6V3CiVjTEQJeHACfQtXcFobqsoxx/XChihqRGBHU/okAoJst
1l+5ojo5GOdwxN6PTpFaxbkZ
=6bY+
-----END PGP SIGNATURE-----
*****************************************************
* Steve Kruse Milkyway Networks *
* Network Systems Engineer 1342 E. Vine St. #224 *
* 407-847-8977 Voice Kissimmee, FL 34744 *
* 407-847-7203 Fax http://www.milkyway.com *
*****************************************************
References:
|
|
