Windows and Common Criteria

Microsoft heavily touted its Common Criteria certification for Windows 2000. But what does that mean?

• By Roberta Bragg
• March 01, 2003

In October 2002, Microsoft announced that Windows 2000 had received an Evaluation Assurance Level 4 (EAL4) Common Criteria certification.

I’m listening, but I’m not hearing the chuckles. Oh, I can find criticism of Common Criteria (CC). There are numerous comments and even a couple of articles that attack CC, the evaluation process and the people involved. There are many of the usual slams (Microsoft is bad and so on) but there are some refreshing opinions, as well.

Be careful, though: CC validation doesn’t mean that Win2K is a secure operating system. Rather, it means that it’s a securable operating system. Just as an MCSE certification doesn’t guarantee that the holder is competent to administer Windows enterprise networks, the CC certification doesn’t guarantee that any implementation of Win2K is secure. Like previous government product-specific security standards—E3/F and C2—CC certification certifies that the product, when configured as it is in the evaluation, meets some security profile. It says, in effect, that Win2K can be secure if properly patched and configured to specific criteria.

So let’s say you’d like to configure it that way—or, if you’re a Windows-hater, you want to argue that this certification proves nothing and that Windows is still insecure. Before you do either, you should first understand what CC is all about, as well as the specifics of the Win2K evaluation.

Your Seal of a Quality OS!
Think of CC certification as a Better Business Bureau stamp or the Good Housekeeping Seal of Approval. That’s rather simplistic, but it should put you in the right frame of mind. CC, and those government-sponsored evaluation systems that went before it, don’t pretend to tell you that a particular product will meet your security needs. Instead, it says, in essence, that a specific product does have the security features it touts and can be configured to meet a specific Protection Profile (more on those later). The sole purpose here is to let purchasers determine if a product has the features they need and that the features work as advertised, without doing their own exhaustive tests. It doesn’t guarantee that the product is free from vulnerability, nor that the purchaser’s staff will correctly secure the system.

I think most anyone can see the benefits of allowing a third party to test agreed-upon security standards. It saves a lot of time and creates the confidence that comes when someone other than the manufacturer backs a product’s security features. However, it doesn’t absolve you from matching security requirements with product capability and then using the specification to implement proper security.

Body Parts
You can download a complete copy of the current standard from http://commoncriteria.org/cc/cc.html. Different language versions are available from international sites.

The main body of CC is divided into three parts, but a number of additional documents may be necessary to fully understand a particular certification. Read the documentation to get a general understanding of the process, as well as the additional documents to clarify the results of a certification. The main body parts are:

• Part 1: Introduction and General Model. This includes principles of security evaluation and a high-level specification. This is good background and an even better reference for most consumers. If your study time is limited, read this.
• Part 2: Security Functional Requirements. This part describes common function requirements and is a good guide for formulating security requirements.
• Part 3: Security Assurance. Specific requirements for Targets of Evaluation (TOE), including the evaluation criteria for specific Protection Profiles and Security Targets.

Newer modules (areas not covered in the initial evaluation) are continually being developed (think of these the same way you do service packs). The Win2K Security Response process has been evaluated and certified against one of the approved modules, the ALC FLR 3 (Systemic Flaw Remediation). As I understand it, this means it won’t be necessary to reevaluate Win2K each time an additional security hotfix is advised.

First, Define the Possibilities
A large part of the Part 1 documentation defines critical elements of an evaluation, such as the Protection Profile and Security Target. The Protection Profile is a description of security requirements and defines the problem a specific product can solve. A Protection Profile must be evaluated and certified before a product can use it in an evaluation.

A Protection Profile can be quite detailed and involved. One example would be a set of requirements that allows an election to take place on the Internet. Or, it can be as simple as a company-specific security requirement for its business-to-business Web site or describing product criteria for a firewall. Many Protection Profiles have been certified, and a list is available at the Protection Profile registry, http://niap.nist.gov/cc-scheme/PPRegistry.html. The Security Target is a document that addresses the Protection Profile and states how the system to be evaluated (the TOE) will meet it.

If you wish to use CC certifications to determine if a product is suitable for a specific environment, you must first review the Protection Profile to see if it meets your needs, find a product that meets this Protection Profile, and determine if the Security Target fits your operation. In other words, can and will your people maintain the TOE as specified in the Security Target? Does this configuration allow your applications and functions to work? Remember, it’s well and good to have a certification—but if the specifications that bring the product to the evaluated level aren’t followed, the certification’s worthless.

Reading the CC documentation can be a challenge. It’ll certainly put you to sleep if you attempt to read it like you do a Stephen King novel. However, there’s a great deal to learn from spending some time with the CC. There’s a wealth of good, basic security information you can apply to products and services that aren’t yet evaluated. Specifically, Part 2 lays out the 11 functional security classes and their broader families. These classes cover Audit, Cryptographic Support, Communications, User Data Protection, Identification and Authentication, Security Management, Privacy, Protection of the TOE Trusted Security Functions data (integrity, recovery, replay detection, time stamps and so on), Resource Utilization, TOE Access and Trusted Path (communication channels between users and the trusted system functions).

The purpose of all this information is to provide functional requirements for the TOE. Keep in mind that CC doesn’t specify one security standard—or even one approach. If you take these security classes and study them, you can create a Security Target that meets your own Protection Profile. It won’t mean your systems meet any CC evaluation, but it does provide you with a logical evaluation process. Granted, it’s not a simple process; but if you’re charged with this level of security design, it’s worth your while.

Assurance, Assurance, Assurance
Like the oft-heard claim for commercial success—location, location, location—the success of a security schemata can also be judged by one word—assurance. Part 3 of CC answers the question: Are the proposed measures sufficient to fulfill your organization’s security policy and meet clearly articulated threats? In this document, several classes are defined, which are meant to assure that the Protection Profile and Security Target are appropriate and that the evaluation process is up to snuff. Combined, they ask for answers to questions such as:

• Is the Protection Profile and the Security Target complete, consistent and technically sound?
• Is security protection compromised during delivery, installation or operations?
• Are guidance documents available for administrators and users that detail the secure operation of the TOE?
• What tests are used to prove the TOE meets the criteria of the Security Target?
• What is the mapping of security function requirements to the Protection Profile?
• What vulnerabilities are there if the TOE is misused, improperly configured or operated in an insecure manner?
• Can the TOE be used over time and continue to meet the security target?

Level Setting
Evaluation Assurance Levels are the certification ratings assigned after a product has completed the certification process. While levels range from EAL1 to EAL7, broad acceptance by approving nations is limited, for the most part, to levels EAL1 to EAL4. Levels above EAL4 are considered by many to be outside the commercial product space, and they’re certainly currently beyond the ability of commercial testing facilities to certify. The seven levels are:

• EAL1: Functionality tested and found to be correct.
• EAL2: Structurally tested. Design information is provided to the tester and test results are consistent. Suitable for low- to moderate-level security.
• EAL3: Methodically tested and checked. Security engineering exists at the design level. Search for obvious vulnerabilities made.
• EAL4: Methodically designed, tested and reviewed. Positive security engineering exists, commercial development practices are sound and rigorous. Developers don’t have to possess specific secure development knowledge. Independent search is made for vulnerabilities.
• EAL5: Semi-formally designed and tested using specialized security engineering techniques. Rigorous commercial development practices. Independently assured security.
• EAL6: Semi-formally verified, designed and tested. Protection of high-value assets against significant risks. Modular, layered approach to design. Independent search for vulnerability, which ensures resistance to penetration, and includes a rigorous, systematic search for covert channels, proper development environment and configuration management controls.
• EAL7: Formally verified, de- signed and tested.

What’s useful to most of us is the relative level of security each evaluation level defines. Without formal training in security design, we can’t hope to really judge the merit of their characteristics.

Stupidity, Human Nature Not Addressed
The CC guidelines are comprehensive, but incomplete. For instance, they don’t address secure usage; nothing is mandated about administrators; and there’s no evaluation of controls, whether organizational, political, personnel-related, physical or procedural. In other words, it gets very specific about what should be, but can’t adequately manage what will be. If governments and businesses think the certification process will provide them with secure systems, they have some additional work to do. Insisting on a successful CC evaluation for IT products can only be one part of any intended information systems security program. It’s a part, however, than can reduce the work in building secure information systems.

Evaluation Criteria
On Oct. 25, 2002 the EAL4 CC certification was awarded to Win2K Professional, Server and Advanced Server. The evaluation was tested in several schemes and on several computer systems.

All OSs had Service Pack 3 and TechNet Security Bulletin MS02-042 hotfix, “Flaw in Network Connection Manager Can Cause Rights Elevation.”

The computers included:

• Compaq Proliant ML570, ML330
• Compaq Professional Workstation AP550
• Dell Optiplex GX 400
• Dell PE 2500, 6450, 2550, 1550
• The hardware consisted of the following:
• Motherboard with up to four CPUs for Server and up to eight for Advanced Server
• Monitor
• Keyboard
• Mouse
• Floppy drive
• CD-ROM drive
• Fixed disk drives
• Printer
• Audio adapter
• Network adapter

The TOE doesn’t include other network hardware or devices, but assumes they’ll be, in turn, properly protected.

Interestingly, instead of specifying a single Win2K computer, the TOE can either apply to one Win2K computer or to an entire network of Win2K systems. If an entire network is the TOE, then each Win2K system can provide a subset of the TOE security functions. Therefore, Active Directory, Group Policy, Kerberos and domain-specific functionality were evaluated but aren’t required to have a system that meets the evaluated criteria. This doesn’t mean, however, that all Win2K functionality was evaluated. Certification Authority, e-mail services, Web-based applications, firewall functionality and Terminal Services weren’t evaluated.

This certification only confirms that a specific Win2K system meets EAL4 guidelines: It must be installed on one of the approved hardware systems, in the manner specified in the Security Target and patched and configured to that specification. If you modify one of the criteria, you can’t say the system meets the criteria level. You should also remember that setting up a system to meet EAL4 criteria doesn’t mean that the system is a certified EAL4 system or that it presents the ultimate security configuration for your use of Win2K. Conversely, don’t assume that some variation on the setup is less secure.

However, in order to install and configure a Win2K system to meet the criteria, you should read and follow the Security Target, a document that defines how Win2K meets the Protection Profile and lists the required and recommended configuration changes. To administer the system, download, read and follow the Win2K Evaluated Administrators Guide. Users of Win2K systems should be schooled in the procedures and processes outlined in the Win2K Evaluated Configuration Users Guide. These documents were submitted during the evaluation process.

The Security Target
The 121-page Win2K Security Target document describes both what should be done to Win2K in order to meet its selected Protection Profile [Controlled Access Protection Profile 1.d. (CAProtection Profile) National Security Agency, Oct. 8, 1999] and how the Security Target differs from the CA Protection Profile. In general, the Security Target goes beyond the Protection Profile—with a number of additions, refinements and upgrades to the CA Protection Profile to reach EAL4 from its originally approved EAL3 rating.

Included in the Security Target are:

• The hardware systems on which the operating system will be installed for evaluation.
• The TOE (versions of Win2K, hardware and administration modules including descriptions of what Win2K can do: Group Policy, directory services, single sign-on, virtual private network, desktop and network management).
• The Evaluation Assurance Level sought (in this case, EAL4).
• The Protection Profile, and how the Security Target meets it.
• Threat examples.
• Security objectives satisfied by the TOE.
• Security function and assurance requirements met by the TOE.

Statements within the document clearly specify the environment in which the system operates. For example, statements identify the evaluated system as being part of a network, but assume that the entire network it’s connected to is under the same administration control. This potentially limits the effectiveness of the security you might gain by configuring your systems to this certification level. Remember, however, that you’re supposed to be considering other security measures to assist with network protection. This certification addresses Win2K, not the entire computing world. In fact, the document clearly states that it assumes communication paths and other network components will also be protected .

Security Isn’t Done in a Vacuum
Also of interest are specifications to protect the TOE from physical attack; that access credentials are protected; that those responsible for the TOE ensure its delivery, installation and administration; and that operations meet security objectives. In other words, it’s not up to Win2K to be secure in a vacuum. Also applicable: “Ten Immutable Laws of Security,” http://microsoft.com/technet/treeview/default.asp?url=/technet/
columns/security/essays/10imlaws.asp and, “Ten Immutable Laws of Security Administration,” http://microsoft.com/technet/treeview/
default.asp?url=/technet/columns/security/essays/ 10salaws.asp.

Other items are specific to the evaluation: Audit records must be able to be generated for specific events, cryptoprotect algorithms will use DES or 3DES with 56- or 168-bit key size, and standards will meet Federal Information Processing Standards (FIPS) 140-1 Level 1.

Also included are statements about the OS subsystems, including their design, fulfillment of security objectives and their interfaces; development practices and development security documentation; and flaw remediation procedures.

The Security Target describes, in detail, the Win2K Security Functions (audit, data protection, identification and authentication, security management, resource utilization and TOE access) and how they map to the functional requirements.

Guiding Lights
While you could deduce from the Security Target some of what might be necessary for operating systems to conform to this standard, three helpful documents—the configuration guide, administrator’s guide and user’s guide—are much more illuminating. That’s why their submission is required for the product to be certified. Here’s the breakdown:

Security Configuration Guide
Three chapters identify hardware and software, installation, and configuration. A fourth provides CC security templates. No downloadable .inf files are present,+ so you’ll have to copy the embedded file information to make your own file. Appendices list the default security policy on Win2K, audit events that correspond to those required by the Security Target, changes necessary to user rights, default user and group accounts, and security configuration checklists.

Administrator’s Guide
This guide is meant to support the knowledgeable administrator in the secure operation of Win2K as specified by the Win2K CC Security Target. The guide assumes a familiarity with the security features in Win2K and the Win2K Resource Kit, but it also explains them and gives step-by-step instructions on how to use them. Think of this as a good introductory read on Win2K security. There’s also some good information if you or your administrators haven’t concentrated on the security perspective, but know how to implement the features. Pay attention to the specifics of the evaluated configuration.

An important and necessary understanding you should gain from this document is how the Protection Profile is reflected in Win2K. Each Protection Profile policy and assumption is listed and explained. This will help you understand the configuration settings that are considered required and the reason that others, though discussed or listed as recommended, aren’t required for the Evaluated Configuration. Many specifications of the Security Target state the system must be able to perform some security function, but stop short of requiring that that function be accomplished in a specific way, or at all.

User’s Guide
In addition to defining the Evaluated Configuration, the user’s guide explains security features that may affect users or over which they may have control. Included are instructions for password reset, creating strong passwords, dealing with account lockout, logon, logoff, shutdown, setting up password-protected screen locks, setting permissions on files and using EFS. Also described are disk quotas; access controls; file permission settings, including inheritance; and the affect of copying and moving files on permissions.

Although I’m a strong believer in providing users with security information, I wouldn’t distribute this guide without alteration. I’d review it and modify it according to my organization’s security policy. You may find that the document, as is, provides instructions on features you don’t want users to perform. In addition, if your company’s security policy doesn’t address EFS, I’d definitely bolster the information in this document by adding warnings and instructions on key archival.

Let the Implementer Beware
Whether or not to configure your Win2K systems to the EAL4 Evaluated Configuration isn’t a decision I can make for you. Some government offices will require that purchased products have CC certification; others may not require it, but implement the appropriate settings anyway. Even if you don’t work for the government, you may decide to adopt the standards. Before doing so, you’ll need to understand your organization’s security policy and the Win2K Security Target to determine if implementation of the Evaluated Configuration is appropriate—or even possible. Even if you decide against it, you can add important information to your security education by studying the documents and, perhaps, utilizing some of the requirements and recommendations without attempting to incorporate them all.

Securable—NOT Secure!
Finally, to reiterate: Win2K EAL4+ certification doesn’t mean Win2K is a secure operating system. It means it’s a securable operating system. You can’t merely install the product; you must pay attention to the installation, update and configuration specifications clearly detailed in the CC guides produced by Microsoft. And, yes, part of that means keeping the system patched, and using your head about what you do with the system after you get it there. Win2K EAL4+ certifies the OS in a particular configuration—not the OS as installed by default, the hundreds of thousands of applications you run on it, the other network equipment and systems you expose it to, nor the situations to which you may subject it.