Security Policy Details

See the general document for the broad rules that drive these specific requirements.

Network Security

Firewalls

• 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 production).
• 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

• 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.

Host Security

Software

• 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 cases.
• 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

Intrusion Detection

• 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 incidents.

Logging

• 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 utilized.

Authentication

• 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, etc.)
• 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 are valid.
• Repeated, consecutive authentication failures (5-10 consecutive failures is the suggested limit) should result in the account being disabled.

System Usage

• 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 counsel.
• 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 be terminated.

Accounts

• 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.)

Information

• 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 /etc/mail/aliases
• 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.