Security Stance for Internal Systems ... comments?

[John Brightwell <brightwell_151 () yahoo co uk>]

Dear All

I'm sure many people are familiar with how to harden
the OS by reducing the number of packages installed
and limiting the available services - there is
obviously a tradeoff with usability (as ever with
security) as well as cost of administration. For
exposed machines (DNS, webserver, mailserver) then IMO
you lock the system down as tight as a drum (similarly
for other secure systems such as authentication
servers)...note these are behind a firewall but at
least one service is exposed to an untrusted network 

But what is the received wisdom when it comes to
"Internal" machines - these machines don't reside in
the DMZ and are effectively isolated from external
networks (such as the Internet)?I feel that the
services (particularly the network services) should
still be minimised, but perhaps restricting the
installed packages is too great an administrative
burden ... what do you all think? - do you consider
the risk of installing one of the more fully featured
installations to be unreasonable ... e.g to keep
Oracle installations up to date it can be useful to
have apps such as 'make' available(which is included
in the developer packaged installation for
Solaris)...I would like to have a generic build for
internal systems(for consistency) so the build will
have to accommodate a variety of applications and
services The obvious answer is that the security
stance depends entirely upon the environment and the
associated risk - does anybody know of reference
material that quantifies this for different
industries?From my point of view I would say that we
are on the low side of average risk - vulnerability
would be largely be via physical access to the office
environment We aren't a particularly attractive target
for such activity - there is no obvious financial gain
to be achieved,our physical security is fairly ok and,
being in a large city, there are loads of more
attractive targets in our vicinity. As with any
company there is the risk of a disgruntled
employee...With all this in mind I'm inclined to allow
pretty much any level ofinstall.

But what about "r commands", do you allow rlogin, rsh
in your internal environments? And authentication ...
NIS and standard passwords?
I'm inclined to lock this down even for internal
systems (am I being paranoid?)

We can use ssh in place of telnet/rlogin and ssh to
encrypt (tunnel) Xsessions_or_ alternatively we can
leave the traffic unencrypted but use astronger
authentication mechanism (kerberos or secureID) - I'm
not particularly concerned with encrypting network
traffic internally butI want to protect the
authentication

Of the two options which do you think is the best for
internalsystems?

Is there any reference material which can guide me
when it comes to setting the security policy for build
on Internal systems. I want a secure environment but I
don't want to unnecessarily burden the sysadmins or
inconvenience the users.

thanks

Bright

__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com