Security Basics mailing list archives
Security Stance for Internal Systems ... comments?
From: John Brightwell <brightwell_151 () yahoo co uk>
Date: Mon, 17 Feb 2003 18:34:00 +0000 (GMT)
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
Current thread:
- Security Stance for Internal Systems ... comments? John Brightwell (Feb 18)