Security Policy Details
See the general document for the broad rules
that drive these specific requirements.
- All firewalls have a default deny stance
- All Internet connections have an appropriate firewall
- A firewall should be located at the boundary between any two networks
with significantly different security policies (i.e. development and
- In the event that one network needs to provide services to another
network which has a significantly different security policy (most
commonly at the Internet connection), the network architecture should
include a DMZ network for the systems which provide the services. No
inbound traffic should pass directly through from the untrusted network
to the trusted network. All inbound traffic must either terminate on
systems in the DMZ, or be proxied by those systems into the trusted
network. This sense of trusted or untrusted networks may well be
bi-directional (most commonly in network connections with partner
companies or organizations), resulting in each side building a DMZ to
provide services to the other.
- Intrusion detection systems should be located inside of firewalls
to reduce the false-positive rate and to accurately reflect when
real intrusions are happening. Someone "rattling the doorknobs"
by scanning ports from the Internet doesn't reflect a genuine security
risk on a properly secured network, and is much too common of an
occurrance to trigger an alarm when it happens.
- Intrusion detection devices should be located on networks with
requirements for high levels of security, or networks with high
levels of risk. IDS systems are too demanding of system administrator
resources to be deployed on all networks at this time.
- All software in use should be maintained by someone who will be
responsible for issuing patches in the event of a security problem.
I.e. software purchased from and maintained by a vendor (possibly
requiring an ongoing maintenance contract), OpenSource software that
is actively maintained by the author or the OSS community, etc.
In the event that an outside maintainer is not available (the vendor
goes out of business, the OSS software author disappears and no
community springs up to take over maintenance, etc.), an internal
maintainer who is capable of maintaining the software (i.e. is
familiar with the programming language the software is written in, etc.)
should be appointed to fix any security problems that are found.
This is likely to be difficult and this policy could be considered
to actively discourage internal maintenance of software in most
- Software should only be used in accordance with license, copyright
and other legal restrictions.
- Systems should only make available the necessary network services,
all other network services should be disabled.
- Insecure network services should be further restricted as possible,
possibly through the use of packet filtering software or TCP Wrapper.
- See separate patching policy
- Host-based intrusion detection software should be run on systems with
requirements for high levels of security, or systems with high
levels of risk. Tripwire is one example of host-based ID software.
ID software is too demanding of system administrator
resources to be deployed on all systems at this time.
- Organizations should develop a standard process, in consultation with
their legal counsel, about how to respond to suspected security
- System logging should be enabled in such a manner as to at least
log security related activity: failed and successful logins, failed
and successful attempts to use privilege granting software (see
description in Account section), etc.
- Systems with requirements for high levels of security, or systems
with high levels of risk should send their logs to a seperate
log collecting system (in addition to logging locally). This makes
it more difficult for an attacker to wipe out logs of his activity.
The log traffic contains sensitive information, and thus should be
sent over a secure channel.
- Logs should be automatically reviewed and system administrators
notified if inappropriate activity is noticed (consecutive failed
login attempts, etc.)
- In order to correlate logs from multiple systems, it is important
that the system clocks be synchronized. Clock synchronization is
also essential for many other computer operations: Kerberos,
source code compiling over network filesystems (think "File has a
modification date in the future" type messages from make), etc.
NTP is the suggested mechanism for clock synchronization. NTP's
methods for authentication using cryptographic keys should be
- Whenever possible, and in all cases where there are requirements for
high levels of security, authentication should be based on two factors.
The three common factors for authentication are: something you have,
something you know, and something you are. Examples of something you
have are smart cards, iButtons, mag-stripe cards, etc. Passwords and
PIN numbers are common things that you know. Biometrics is another
name for things that you are: fingerprints, palm scans, iris scans,
retina scans, etc.
- Most current authentication systems are based on passwords.
Passwords by themselves are a poor authentication system, worse than
many other single forms of authentication, because users can choose
poor passwords and likely would not know if their password has been
stolen (unlike a smart card or similar, which if stolen they are likely
to notice is missing). However, the expense (in tokens and/or readers)
and additional system administrator resources required for other forms
of authentication results in passwords being the authentication mechanism
used in most environments. Given that, some common rules about
passwords should be followed:
- Passwords should be screened by a tool to ensure that they meet
common guidelines (minimum length, mixture of letters, numbers and
punctuation, not in a dictionary, not related to the user's account
or real name, etc.)
- A password history should be maintained for each user, and the
user should be prevented from reusing passwords (within reason,
a history of 2-3 passwords is probably reasonable).
- New accounts should be configured with a random password, or a
password of the user's choice (properly screened of course). Accounts
must not be created with a well-known "new user password". If
accounts are created with a random password, or if someone other than
the user is involved in setting the password (i.e. the user supplies
the password over the phone to someone who types it in) then the
account must be set to expire the password in a short amount of time
(1-2 weeks is common). Even better, if possible, is for the account
to be "pre-expired", requiring the user to change their password at
the first login.
- Passwords should expire after some period of time, 3-6 months is
common, depending on security requirements. Accounts where the
password has expired should be disabled after some period
of time, 1 month is common. See the Accounts section for further
information on disabled accounts.
- Passwords must never be sent over the network in the clear.
- Passwords must never be stored in the clear. (On disk, on paper,
- Authentication failures should not result in the user being informed
for the reason for the failure (although the system should log the
failure and the reason). For example, an authentication failure should
be greeted with "Login failed" instead of "Unknown user" or "Invalid
password". This prevents attackers from finding out which accounts
- Repeated, consecutive authentication failures (5-10 consecutive
failures is the suggested limit) should result in the account being
- Users should be greeted with a message indicating that the system is for
use only by authorized users before they are given a chance to
authenticate. Where possible, this message should require positive
acknowledgement. It is recommended that organizations develop a
standard message for all systems in consultation with their legal
- Idle sessions should be automatically terminated or password-protected
after some period of time. An example of password-protecting the session
would be activating a password-protected screen saver on a graphical
session. 15 minutes is suggested if password protecting
the session is possible, 60 minutes is suggested if the session will
- Accounts should only be issued to users who have a demonstrated
need to access the system. This is commonly implemented by requiring
the consent (via a paper or digital signature) of a supervisor who
has authority to grant access to the system.
- Prospective users should be given, and should acknowledge, a set
of usage rules for the systems they are being given access to.
- Accounts should be regularly reviewed to ensure that all users still
have a need to access the system. The most thorough method, and
therefore the most bothersome and time-consuming, is to regularly (every
3-6 months) query the person who authorized access for each user to
see if they still wish to grant those users access. A less thorough,
but perhaps more feasible, method is to record some identifying
number (employee number, Social Security Number (although these have
their own issues), student number, etc.) for each user and then
query Human Resources (or similar) regularly to find out if those
users are still affiliated with the organization. This will catch
the users who have left the organization, but not those who are still
within the organization but have changed jobs or otherwise no
longer require access to a particular system. These two systems
could also be combined, for example checking with HR every 3 months
and with the authorizing supervisor once a year.
- Accounts that are inactive for a period of time (1-3 months is suggested)
should be automatically disabled.
- Disabled accounts (disabled due to password expiration, inactivity,
suspected illegal activity, etc.) should be automatically deleted after
a period of time (1 month is suggested).
- Privileged accounts (i.e. UID 0 on UNIX) should be limited to one
such account and access to the password for that account should be
tightly restricted. Normal system administration duties should be
performed via a tool which temporarily grants privileged access and
logs all such activity. sudo and PowerBroker are examples of such
tools for UNIX.
Viruses and other malware
- Systems vulnerable to malware (i.e. Windows) and common methods of malware
transmission (email) should be scanned.
- Virus scanners should be regularly and automatically updated with
the latest virus signatures.
- Users should be informed of common malware avoidance behavior
(not opening attachments they weren't expecting or from users they
don't know, etc.)
- Proprietary information must be marked according to its level of
sensitivity. Standard levels should be defined and distributed to
all users who handle such information.
- Rules for distributing proprietary information must be defined and
distributed. These rules should cover both electronic and paper
distribution. For example, the rules should define which levels
of information must be transmitted or stored in encrypted form.
- Default file permissions on systems should be such that access is
only granted to those who need it. For example, the suggested default
umask on UNIX systems is 027, which gives read access to anyone is
the user's group and no access to anyone else. Users can then adjust
permissions from there as necessary (by giving group write access as
needed, or removing group read access on sensitive documents, etc.)
Systems should be regularly scanned (every 1-2 months is suggested)
for world-writable files and other possible file permission problems
(set-uid and set-gid files on UNIX, for example).
- Organizations should develop a data retention policy in consultation
with their legal counsel.
- Backups and other copies of data should be stored in areas that are
at least as secure as the original data. I.e. if the original data is
on a machine in a locked server room, the backup tapes should not be
kept in an unlocked file cabinet.
UNIX specific checklist
- Install the minimum set of OS software necessary for the system's
operation. This reduced the number of potentially vulnerable programs,
particularly set-uid and set-gid executables, as well as reducing the
possible usefulness of the system to an attacker.
- Unnecessary network daemons disabled (i.e. init scripts removed)
- Unnecessary inetd services disabled, or inetd disabled altogether
- Mail aliases which run programs (i.e. uudecode) removed from
- All default accounts locked
- No . (dot) in default PATH, system directories before application
directories before user directories. This reduced the chances that
an attacker can introduce a trojan version of a common utility into
the user's path and have the user execute it accidentally.
jheiss at aput.net
$Id: details.shtml,v 1.2 2003/05/20 20:58:43 jheiss Exp $