Appendix A Site Security Policy

Each Trusted Solaris site is unique and must determine its own security policy. Perform the following tasks when creating and managing a security policy.

• Establish a security team. The security team should have representation from toplevel management, personnel management, computer system management and administrators, and facilities management. The team should review Trusted Solaris administrators' policies and procedures, and recommend general security policies that apply to all system users.

• Educate management and administration personnel about the site security policy All personnel involved in the management and administration of the site should be educated about the security policy. Security policies should not be made available to ordinary users since this policy information has direct bearing on the security of the computer systems.

• Educate users about Trusted Solaris and the policy. All users must be familiar with the Trusted Solaris User's Guide. Because the users are usually the first to know when a system is not functioning normally, the user should become acquainted with the system and report any problems to a system administrator. A secure environment needs the users to notify the system administrators immediately if they notice:

  • A discrepancy in the last login time that is reported at the beginning of each session

  • An unusual change to file data

  • A lost or stolen human-readable printout

  • The inability to operate a user function

• Enforce the security policy. If the security policy is not followed and enforced, the data contained in Trusted Solaris will not be secure. Procedures should be established to record any problems and the measures that were taken to resolve the incidents.

• Review the security policy. The security team should perform a periodic review of the security policy and all incidents that occurred since the last review. Adjustments to the policy can then lead to increased security.

Site Security Policy and the Distributed System

The security administrator should design the distributed system based on the site's security policy. The security policy dictates configuration decisions regarding such things as:

• How much auditing will be done for all users in the system and for which classes of events

• How much auditing will be done for users in roles and for which classes of events

• How audit data will be managed, archived, and reviewed

• Which labels will be used in the system and whether the ADMIN_LOW and ADMIN_HIGH labels will viewable by ordinary users

• Which user clearances will be assigned to individuals

• Which devices (if any) will be allocatable by which normal users

• Which label ranges are defined for machines, printers, and other devices

• Whether the Trusted Solaris system will be used in an evaluated configuration or in an extended configuration.

Computer Security Recommendations

The following list of guidelines provides some things to consider when developing a security policy for your site.

• The maximum label of the Trusted Solaris distributed system (the highest label in the user accreditation range) should not be greater than the maximum security level of work being done at the site.

• System reboots, power failures, and shutdowns should all be recorded manually in a site log.

• File-system damage should be documented and all affected files should be analyzed for potential security-policy violations.

• Operating manuals and administrator documentation should be restricted to individuals with a valid need for access to that information.

• Unusual or unexpected behavior of any Trusted Solaris software should be reported and documented, and the cause should be determined.

• If possible, at least two individuals should administer Trusted Solaris. One should be assigned security administrator authorization for security-related decisions, and the other should be assigned the system administrator authorization for computer management tasks.

• A regular backup routine should be established.

• Authorizations should be assigned only to users who need them and who can be trusted to use them properly.

• Privileges should be assigned to programs only when the program needs the privileges to do its work, and only when the programs have been scrutinized and proven to be trustworthy in their use of privilege. Review the privileges on existing Trusted Solaris programs for a guide to setting privileges on new programs.

• Audit information should be reviewed and analyzed regularly. Any irregular events should be noted and investigated to determine the cause of the event.

• The number of administration IDs should be minimized. The install user account should be disabled after an authorized security administrator user is established.

• The number of set user ID and set group ID programs should be minimized. Setuid/setgid programs should be employed only in protected subsystems.

• An administrator should regularly verify that normal users have a valid login shell.

• An administrator should regularly verify that normal users have valid user ID values and not system administration ID values.

• Consider TEMPEST shielded equipment and fiber-optic network cables to reduce electronic radiation emitted from computer equipment.

• Only certified technicians should open and close TEMPEST equipment to ensure its ability to shield electromagnetic radiation.

Physical Security Recommendations

• Restrict access to the Trusted Solaris system. The most secure locations are generally interior rooms that are not on the ground floor.

• Monitor and document access to Trusted Solaris.

• Secure computer equipment to large objects such as tables and desks to prevent theft. When equipment is secured to a wooden item, increase the strength of the item by adding metal plates.

• Consider removable storage media for sensitive information. Lock up all removable media when not in use.

• Store system backups and archives in a secure location separate from the location of the Trusted Solaris system.

• Restrict physical access to the backup and archival media in the same manner as access to the Trusted Solaris system.

• Install a high-temperature alarm in the computer facility to indicate when the temperature is outside of the range of the manufacturer's specifications. A suggested range is 10oC to 32oC (50oF to 90oF).

• Install a water alarm in the computer facility to indicate water on the floor, in the subfloor cavity, and in the ceiling.

• Install a smoke alarm to indicate fire.

• Install a fire-suppression system.

• Install a humidity alarm to indicate too much or too little humidity.

• Consider TEMPEST shielding if machines do not have it. TEMPEST shielding may be appropriate for facility walls, floors, and ceilings.

• Check for physical gaps that allow entrance to the facility or the rooms containing computer equipment. Look for openings under raised floors, in suspended ceilings, in roof ventilation equipment, and in adjoining walls between original and secondary additions.

• Prohibit eating, drinking, and smoking in computer facilities or near computer equipment. Establish areas where these activities can occur without threat to the computer equipment.

• Protect architectural drawings and diagrams of the computer facility.

• Restrict the use of building diagrams, floor maps, and photographs of the computer facility.

Personnel Security Recommendations

• Inspect packages, documents, and storage media entering and leaving a secure site.

• Require identification badges on all personnel and visitors at all times.

• Use identification badges that are difficult to copy or counterfeit.

• Establish areas that are prohibited for visitors and clearly mark the areas.

• Escort visitors at all times.

Common Security Violations

Because no computer is 100% secure, a computer facility is only as secure as the people who use it. The limitations of an administrator are directly related to the actions of all individuals involved with the use of computer equipment and its facilities. Although most actions that violate security are easily resolved by careful users or additional equipment, the following list gives examples of problems that can occur:

• Users give passwords to other individuals who should not have access to the computer system.

• Users write down passwords and lose or leave the passwords in nonsecure locations.

• Users set their passwords to easily guessed words or names.

• Users learn passwords by watching other users when they enter a password.

• Unauthorized users remove, replace, or physically tamper with hardware.

• Users leave their workstations or terminals unattended without locking the screen.

• Users change the permissions on a file to allow other users to read the file.

• Users change the labels on a file to allow other users to read the file.

• Users discard sensitive hardcopy documents without shredding them or leave sensitive hardcopy documents in insecure locations.

• Users leave access doors unlocked.

• Users lose their keys.

• Users do not lock up removable storage media.

• Computer screens are visible through exterior windows.

• Network cables are tapped.

• Electronic eavesdropping captures signals emitted from computer equipment.

• Power outages, surges, and spikes destroy data.

• Earthquakes, floods, tornadoes, hurricanes, and lightning destroy data.

• External electromagnetic radiation interference such as sun-spot activity scrambles files.

Additional Security References

As a trusted administrator, you should become familiar with the standards established by various government agencies. Government publications describe in detail the standards, policies, methods, and terminology associated with computer security.

Other publications listed here are guides for system administrators of UNIX systems and are useful in gaining a thorough understanding of UNIX security problems and solutions. Some publications listed here describe successful attempts to penetrate computer systems around the world and illustrate real threats to computer security. These publications emphasize the importance of computer systems managed by knowledgeable and capable administrators.

U.S. Government Publications

Computer Security Requirements, Guidance for Applying the Department of Defense Trusted Computer System Evaluation Criteria in Specific Environments, DoD, CSC-STD-003-85, 1985.

Department of Defense Password Management Guideline, DoD, CSC-STD-002-85, 1985.

Department of Defense Trusted Computer System Evaluation Criteria (TCSEC) National Computer Security Center, DoD 520.28-STD, 1985.

Graubart, Richard D., J.L. Berger, and John P.L. Woodward, Compartmented Mode Workstations Evaluation Criteria, Version 1, DIA DDS-2600-6243-91, Mitre, Bedford, Massachusetts, March 1991.

Personal Computer Security Considerations, National Computer Security Center, NCSC-WA-002-85, 1985.

Technical Rationale behind CSC-STD-003-85 Computer Security Requirements, Guidance for Applying the Department of Defense Trusted Computer System Evaluation Criteria in Specific Environments, DoD, CSC-STD-004-85, 1985.

Trusted Network Interpretation of the Trusted Computer System Evaluation Criteria, National Computer Security Center, NCSC-TG-005 Version 1, 1987.

Woodward, John P.L., Security Requirements for System High and Compartmented Mode Workstations, DIA DDS-2600-5502-87, Mitre, Bedford, Massachusetts, November 1987.

UNIX Security Publications

Farrow, Rik, UNIX System Security, Addison-Wesley, Reading, MA, 1991.

Garfinkel, Simson, and Gene Spafford, Practical UNIX Security, O'Reilly & Associates, Inc., Sebastopol, CA, 1991.

Gregory, Peter, Solaris Security, Sun Microsystems Press, September 1999.

Hayes, Frank, "Is Your System Safe?" UNIXWORLD, June 1990.

Wood, Patrick H., and Stephen Kochan, UNIX System Security, Hayden Books, Indianapolis, IN, 1986.

General Computer Security Publications

Denning, Peter J., Computers under Attack: Intruders, Worms and Viruses, ACM Press, Addison-Wesley, Reading, MA, 1990.

Farrow, Rik, "Inside the Internet Worm," UNIXWORLD, June 1990.

Hafner, Katie, and John Markroff, Cyberpunk: Outlaws and Hackers on the Computer Frontier, Simon & Schuster, New York, NY, 1991.

Levy, Steven, Hackers: Heroes of the Computer Revolution, Dell Books, New York, NY, 1984.

McAffe, John, and C. Haynes, Computer Viruses, Worms, Data Diddlers, Killer Programs, and Other Threats to Your System, St. Martin's Press, New York, NY, 1989.

Page, Bob, "A Report on the Internet Worm," University of Lowell, Computer Science Department, November 1988.

Russell, Deborah, and G.T. Gangemi, Sr., Computer Security Basics, O'Reilly & Associates, Inc., Sebastopol, CA, 1990.

"Special Report: Computer Security and the Internet", Scientific American, October 1998. pp 95-117. Contains articles on hackers, firewalls, encryption, digital signatures, and Java, with extensive bibliographies.

Seeley, Donn, "A Tour of the Worm," University of Utah Department of Computer Science, Technical Report, November 1988.

Spafford, Eugene H., "The Internet Worm: Crisis and Aftermath," Communications of the ACM, June 1989.

Stoll, Cliff, The Cuckoo's Egg, Doubleday, Garden City, NY, 1989.

Thompson, Ken, "Reflections on Trusting Trust," 1983 ACM Turing Award Lecture, Communications of the ACM, August 1984.

General UNIX Publications

Bach, Maurice J., The Design of the UNIX Operating System, Prentice Hall, Englewood Cliffs, NJ, 1986.

Kobert, Jeannie Johnstone, Guide To High Availability: Configuring boot/root/swap, Sun Microsystems Press, September 1999.

Nemeth, Evi, Garth Snyder, and Scott Seebas, UNIX System Administration Handbook, Prentice Hall, Englewood Cliffs, NJ, 1989.

Winsor, Janice, Solaris 7 Reference, Sun Microsystems Press, September 1999.