Due to the large variety of attacks present today, Defense-In-Depth is necessary to properly secure systems. Some of the elements of Defense-In-Depth include:
An unauthorized individual should not be given physical access to systems. Many security measures can be overcome via access at the console or the machine or components could be stolen.
1. Use a BIOS password if the machine must reside in a semi-public (or worse) space. This will prevent an unauthorized user from booting a system.
2. Use chassis locks to prevent unauthorized individuals from gaining access to core system components such as removing a hard drive and connecting it to a system under their control.
3. Use cabinet locks when the potential exists for unauthorized users to gain access to the physical machine and removable media including USB, CD/DVD, or floppy.
1. Disable user accounts immediately after a user leaves the organization.
2. Disable user accounts and groups that are not required. Some accounts are never used for interactive login.
3. Make sure every active account has a strong password, at least 8 characters long with uppercase, lowercase, numbers, and symbols. Change any administrative access password frequently, at least once per year.
4. Periodically review and monitor user lists and groups for unauthorized changes.
5. Ensure that a user’s rights are adjusted when they change departments or responsibilities.
Baseline and Auditing
This protects the system by taking a snapshot of the system before it goes live and periodically comparing the running state to the baseline. Implement a controlled change management program so changes are documented and the baseline gets updated. Perform control audits to protect against unauthorized changes.
1. Use a firewall – This protects the system by only allowing access to those protocols/services for which we have legitimate applications. Deny all other access.
2. Disable services that are not actively being used. The number and type of services that should be listening for connections from the network depends on the type of system and its mission. The most secure stance is to only enable services that are required for the system to fulfill its mission.
3. Always use the secure versions of protocols where applicable. Choose ssh over telnet, https over http (although an automatic redirection from http to https version of a website is acceptable), sftp over ftp, etc.
4. Verify permissions for any file shares, web site directories. Choose the least-privilege necessary that still allows proper operation or access. The owner of any non-interactive process (i.e. non-user) should never have write permissions to any file or directory that are accessible by that process.
5. Restrict access to appropriate clients. Linux/Unix has a built in mechanism to restrict access from ip address ranges by creating entries in /etc/hosts.allow and /etc/hosts.deny. Similar functionality is available in the Windows firewall. Please contact IT support for help in determining what appropriate ip address ranges are for your application.
1. Install host based intrusion detection software. This protects the system by watching for and alerting on known vulnerabilities.
2. Install host based file integrity software. This protects the system by monitoring changes to critical files.
3. Log everything. This protects the system by recording critical events. Configure log rotation and keep logs as long as feasible.
4. Review logs frequently. Nothing replaces due diligence and frequent log scouring. So what do you look for? Anything out of the ordinary. How do you know what is ordinary? By checking your logs frequently.
5. Patching is a necessary evil. It is highly recommended to configure the system to automatically check for new patches. Apply patches manually using the following guidelines.
a). Review patch relevance and do not apply patches for services that you are not running.
b). Read the release notes to understand how to apply the patch and what it is going to do.
c). Always apply patches in a test environment first.
d). Re-audit the system for unexpected changes by comparing the runtime state to the baseline.
1. Secure backup tapes away from the system, if possible. These should be locked away and only available to authorized personnel.
2. Document your backup/restore plan to ensure the backups are performed consistently and that someone in your absence can continue the backup rotation (and restoration, if necessary).
3. Clearly label everything.
4. Verify backup tapes periodically.
5. Test restore procedures periodically.