AppendixA.Security Certifications

Appendix A. Security Certifications

Although often not necessary, selecting a network operating system that has earned a security rating can be advantageous. For instance, if your company has a security-conscious Chief Technology Officer, a network operating system that has an internationally recognized security rating would be an easier sell than one that doesn't. Furthermore, some companies you do business with may require it.

A number of different organizations, including the U.S. government, have defined a set of security requirements that must be met in order for the operating system to be used within those organizations. At the very least, the classifications can be used to help people (primarily the U.S. government and its contractors) in their purchasing decision. Therefore, if your company does business with the U.S. government or its contractors or simply requires the same level of network security, it would be a good idea if your company deployed network operating systems that meet the minimum of these security ratings.

In 1983, the National Computer Security Center (NCSC) assigned a range of security ratings, shown in Table A.1, based on the United States Department of Defense's Trusted Computer System Evaluation Criteria (TCSEC). These ratings, often referred to as the Orange Book after the color of the document's cover, measure the degree of protection offered by operating systems, network components, and applications.

Table A.1. Orange Book Security Ratings

RATING CODE	RATING NAME
A1	Verified Design
B3	Security Domains
B2	Structured Protection
B1	Labeled Security Protection
C2	Controlled Access Protection
C1	Discretionary Access Protection (this rating is obsolete)
D	Minimal Protection

NOTE

When a software product, such as a database, is granted a security rating, it is often referred to as a trusted application.

The TCSEC standard consists of levels of trust ratings, in which higher levels of security build on lower levels, adding more rigorous protection requirements. Although a few network components (such as Boeing MILS LAN Version 2.1) have been evaluated A1, no operating system has earned the A1 rating. A number of operating systems such as Hewlett-Packard's HP/UX, Digital's Ultrix, and Silicon Graphics' IRIX have earned B1, B2, and B3 ratings. A number of general-purpose network operating systems, such as Windows NT4 and NetWare 4.11, have earned the C2 rating.

NOTE

You can find a complete list of products evaluated by the NCSC using the Orange Book criteria at www.radium.ncsc.mil/tpep/epl/historical.html.

A similar set of European security criteria, Information Technology Security Evaluation Criteria (ITSEC), was developed in the mid-1990s. Recognizing that an internationally accepted standard is required so that all countries can use one evaluation system, the United States, United Kingdom, Germany, France, Canada, and the Netherlands released a jointly developed evaluation standard for a multinational marketplace in January 1996. This standard is known as the Common Criteria for Information Technology Security Evaluation (CCITSE), usually referred to simply as the Common Criteria (CC).

The CCITSE has a structure closer to the ITSEC than the TCSEC and includes Protection Profiles to collect requirements into easily specified and compared sets and a Security Target.

A Protection Profile (PP) is a document created by a group of users (for example, a consumer group or large organization) that identifies the desired security properties of a product. Basically, a PP is a list of user security requirements, described in a very specific way defined by the CC. A Security Target (ST) is a document that identifies what a product (known as the Target of Evaluation, or TOE) actually does, or a subset of it, which is security-relevant; it is the basis for agreement between all parties as to what security the TOE offers.

NOTE

For more definitions and explanations of terms used in computer security evaluations, visit www.radium.ncsc.mil/tpep/process/faq.html.

It is often difficult to identify a reasonable set of assurance requirements. The Common Criteria offer a set of predefined assurance requirements, called Evaluation Assurance Levels (EALs). EALs provide a uniformly increasing scale that balances the level of assurance obtained with the cost and feasibility of acquiring that degree of assurance. There are seven hierarchically ordered EALs, as shown in Table A.2. The higher levels build on lower levels, so the higher the EAL rating, the greater the degree of assurance.

Table A.2. Evaluation Assurance Levels in Common Criteria

EVALUATION ASSURANCE LEVELS	COMMENTS
EAL1 (Functionally Tested)	The EAL1 rating indicates that the TOE was independently tested to verify its security functions, the TOE functions in a manner consistent with its documentation, and the TOE provides useful protection against identified threats.
	EAL1-rated products are best for situations in which some confidence in correct operation is required, but the threats to security are not considered as serious.
EAL2 (Structurally Tested)	In addition to the EAL1 rating, an EAL2 rating requires that evidence of developer testing and selective results be independently confirmed. The developer must conduct a vulnerability analysis and provide evidence that security functions claimed to operate at certain strength levels meet or exceed those levels. For instance, if the TOE supports 128-bit encryption, the developer must provide evidence to substantiate that feature.
	EAL2 is therefore applicable in those circumstances that require a low to moderate level of independently assured security in the absence of ready availability of the complete development record.
EAL3 (Methodically Tested and Checked)	In addition to the EAL2 rating, an EAL3 rating requires the developer to document the security controls and procedures (including Change Management) employed to protect the TOE during developmentfor example, how the source code was protected from tampering. Furthermore, the TOE's documentation would be examined to ensure there is no conflicting or misleading information, that it identifies all possible modes of operation, and that it lists all assumptions about the operating environment and requirements for external security measures.
	EAL3 is applicable in those circumstances that require a moderate level of independently assured security and require a thorough investigation of the TOE and its development record.
EAL4 (Methodically Designed, Tested, andReviewed)	In addition to the EAL3 rating, an EAL4 rating requires validation that the TOE is resistant to vulnerability attacks of "low penetration potentials." In addition to evidence of partial automation of Change Management and problem tracking practices, and implementation of TOE according to strict design documentation, the developer is also required to provide documentation regarding life-cycle support.
	EAL4 is therefore applicable in those circumstances that require a moderate to high level of independently assured security in "off-the-shelf" TOEs.
EAL5 (Semiformally Designed and Tested)	In addition to the EAL4 rating, an EAL5 rating requires validation that the TOE is resistant to vulnerability attacks of "moderate penetration potentials." The developer must supply an architectural description of the TOE security functions that demonstrate a modular design and that there is minimal interaction among the modules (so that the failure of one security function module will not adversely impact the performance of others).
	EAL5 is therefore applicable in those circumstances that require a high level of independently assured security in a planned development and require a rigorous development approach. An EAL5-rated TOE is generally designed and developed with the intent of achieving EAL5 assurance, where no retrofitting of security modules is required (if retrofitting is required, the components may not integrate nicely).
	EAL6 (Semiformally Verified Design and Tested) In addition to the EAL5 rating, an EAL6 rating requires validation that the TOE is resistant to vulnerability attacks of "high penetration potentials." In addition to evidence of complete automation of the Change Management process, the developer must supply an architectural description of the TOE security functions that demonstrate a layered as well as modular design. An analysis of the documentation is performed to ensure it contains sufficient information for users to detect an insecure TOE.
	EAL6 is therefore applicable to TOEs used in high-risk situations in which the value of the protected assets justifies the additional costs.
EAL7 (Formally Verified Design and Tested)	In addition to the EAL6 rating, an EAL7 rating requires the evaluator to repeat and verify all testing performed by the developer and that a procedure is in place to guarantee that the TOE is not tampered with while en route from the developer to the user.
	EAL7 is applicable to the development of security TOEs for use in extremely high-risk situations and/or where the high value of the assets justifies the higher costs.

NOTE

For more information about Common Criteria for Information Technology Security Evaluation (CCITSE), visit csrc.nist.gov/cc.

Today, the Common Criteria standard has replaced TCSEC and ITSEC, and all current network operating system product evaluations are taking place at these new EALs, not at the older levels (such as C2 and so on). In February 2005, SLES 9 running on IBM eServers was granted the EAL4+ rating by astec information security (www.astec.com), one of the few laboratories worldwide officially accredited and licensed to perform evaluations based on the Common Criteria standard. Additional evaluations using a range of IBM and HP hardware platforms are being conducted at the time of this writing.

NOTE

The document titled "SUSE LINUX Enterprise Server (SLES) V9 Security Target for CAPP Compliance," located at www.ibm.com/developerworks/opensource/library/os-ltc-security, contains the security feature specifications of SLES 9 as evaluated for the EAL4+ rating.

NOTE

While EALx is simply a standard shorthand for the set of assurance requirements defined for EALx, products can be evaluated with additional assurance measures. For example, a product (such as SLES) might choose to be evaluated at EAL4 plus some additional assurance measures, but not sufficient to be EAL5. Such a combination would be called EAL4+.

You need to be aware that a security rating is different from a security certification. Operating systems, hardware, and application programs earn ratings, but individual installations must be certified. This distinction is significant. What it means is that you may be running an EAL4-rated operating system, but your site is not automatically EAL4-certified. You need to install and configure your system using the same operating system version, patches, and settings as well as the same or equivalent hardware used in the evaluation. Then your system must be inspected and granted that certification by an accredited third party. Furthermore, any changes made, no matter how minor, to an already-certified installation require the whole configuration to be reevaluated to retain the certification.

You will find the system hardening information presented in Chapter 13, "System Security," is complementary to the configuration procedures used for SLES 9's EAL4+ evaluation. The following summary describes how you should apply computer security certifications toward your network's security needs:

• If you need to run a secure network, select a network operating system that has an EAL rating; you should also consider running EAL-rated workstation operating systems.

• Using an EAL-rated operating system does not automatically give you all the necessary protection. You need to apply the recommended settings as per its security guides. For example, to configure your SLES server to match its EAL4+ settings, follow the procedures outlined in "Common Criteria EAL4+ Evaluated Configuration Guide for SUSE LINUX Enterprise Server (SLES) on IBM Hardware," found at www.ibm.com/developerworks/opensource/library/os-ltc-security. This guide explains how the evaluated configuration was set up and provides information to administrators and users to ensure secure operation of the system.

• EAL4+ settings may be much more than what your environment requires. If that is the case, the configuration guide's recommended settings serve as a starting point to customize your own security requirements.

• Other than using rated operating systems, you may also want to deploy other networking components (such as firewalls) that are EAL-rated. You can find a detailed list at niap.nist.gov/cc-scheme/vpl/vpl_type.html.

You can find an RPM package containing the configuration script and data needed to set up the Common Criteria EAL4 system configuration certified on IBM hardware at http://portal.suse.com/psdb/22e06ee39e67b7064ea5c31de972460c.html. You will need a current SUSE maintenance contract to access this page. Even if you are not using IBM hardware, the script can provide you with insights into the necessary settings to be applied to your server.