It is important to have formal standards and procedures defined. These should not only include usage and behaviour policies, but should also define rules to ensure monitoring and policy enforcement occur.

Automated monitoring mechanisms exists, watching for anything from the following list, and reporting in an appropriate means.

• port scans
• repeated login failures
• changes to password or group files
• logins from unexpected hosts
• logins at unexpected times
• logins on dormant accounts
• normal system processes not running
• unexpected system processes running
• unexpected mounted file systems
• all SetUID and SetGID files
• programs in common areas
• successful and unsuccessful use of su/sudo
• (un)expected reboots/shutdowns
• system utilization and capacity
• Network sockets and servers
• all commands as the system user are logged
• Check for .rhosts, .shosts and .netrc in user's directories. Verify acceptability if they exist
• Check user shell initialization files .login or .profile for acceptable umask
• Permissions on user work areas and home directories are monitored for acceptability

• There is only one system account and system group
• Access to privileged groups is monitored and restricted to authorized accounts only
• System account login is disallowed everywhere but on the console, and limited to su or sudo
• Access lists are built around su and/or sudo (if the systems does not have a mechanism for this--such as limiting to accounts in the System group, use sudo).
• Privileged accounts do not have the "current directory" (.) in their PATH
• A sufficient file umask exists for all privileged accounts (022 is acceptable)

• An acceptable default file umask exists for all users
• No guest accounts exist
• No multi-user accounts exist
• Account home directories are proprietary to each user
• Default GID for user is exclusive to each user (each user has its own group)
• User home directories and files are properly protected
• Access to a command prompt for end-users should be limited wherever possible
• All user accounts have adequate information to identify users
• All users are required to logout of the system when idle
• Idle timeout mechanisms exist, to logout idle users

• A verified requisition form is required for new accounts
• Form must be submitted by supervisor (not user)
• New accounts are assigned UID's outside system ranges. No UID is less than 10, preferrably less than 100

• Accounts for terminated employees are disabled within a defined period of time after the employee leaves
• Directories and files associated with terminated employee accounts are reviewed soon after employee's termination, to be allocated to others or deleted
• UIDs of terminated accounts are removed from password and group files, and any other access files, along with a comprehensive system search for additional files owned by the terminated account
• Dormant accounts are monitored, and disabled after a specified period of inactivity

• Password file is shadowed
• All accounts with login access have passwords
• Passwords expire on a regular schedule for all accounts
• Privileged accounts have a regular unannounced password change (at least every 60 days)
• All vendor supplied account passwords (or lack thereof) should be changed immediately upon installation or upgrade
• A password checking program is run on a regular basis (such as every 30 days), to verify that users do not have easilly guessable passwords--or a mechanism exists to disallow these passwords to be set
• Passwords are all complex, unique and not easilly guessed
• Passwords are not stored in command files or shell scripts

• Only the System Account has write access to system configuration files and directories.
• Only the System Account has write access in any system wide (default) command area, including: /bin, /usr/bin, /sbin, /usr/sbin, /opt/bin and /usr/local/bin (more as appropriate).
• System Devices are secure. By default, ownership of system devices are by root, with the appropriate privileged group.
• job scheduling directories (at and cron) are secure.
• All common area programs are not writable, and SetUID/GID programs only readable by privileged users.

• Network access is only available via an encrypted shell session (ssh/secure shell or ssl telnet)
• Network access is available via ssh and telnet
• Network access is limited to known hosts--public access is through a blackbox proxy server
• Full shell access is available via a modem
• Restricted shell access is available via modem
• Modem phone numbers are confidential and only distributed to a limited group of people
• Additional measures exist to secure modem access (such as key cards or dial-back service)

• TCP Wrappers are installed to limit access to services
• IP Services use standard IETF defined ports
• non-privileged port services (greater than 1023) are approved
• RPC services have been reviewed and limited to necessary set
• all internet services which are not needed are discontinued, specifically: echo, discard, daytime, chargen, finger.
• Less secure services are disabled, including: shell (remsh), login (rsh), tftp
• Additional service configurations have been reviewed for potential security issues, specifically: ftp, imap, pop
• ftp access is limited to authorized users, if not all user login being denied--allowing only anonymous access.
• anonymous ftp access is limited to file creation only (no directory creation, nor delete of any type).
• Disallow download of password and group files from ftp.

• VRFY and EXPN commands are disabled
• Relaying is limited to local approved hosts only
• MAIL FROM must be a valid DNS address

• Only valid, authorized and known hosts are listed in the NIS hosts file
• Only hosts on the local network are be listed within the NIS hosts file
• The root user is not included in the NIS password file
• Users listed in the NIS password database are limited to those who require domain wide access
• All user identification codes defined in the NIS password file have a password (following same password rules set above)

• All exported mount points specify the nosuid option (effectively removing suid bits from any suid programs, and disallowing creation of them)
• Read-only NFS is used for any filesystem where write access is not a requirement, specifically including any filesystems where system information is, such as shared libraries and configuration files (i.e. /usr).
• The root filesystem is never exported