Windows and Common Criteria
Microsoft heavily touted its Common Criteria certification for Windows 2000. But what does that mean?
What if someone said the words “Windows” and “security” in the same breath,
and no one laughed? Would you think you were suspended in some time warp
vortex where aliens who’d never used these products lurked?
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.
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
- 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
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
- 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
- What is the mapping of security function requirements to the Protection
- 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?
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
- 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
- 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.
|Table 1. Common
Criteria Status of Other Operating Systems
|Apple Mac OS X
|Mac OS X Server
||Plans are underway to submit
Linux for EAL2 certification
||Trusted Solaris v. 8
||EAL4, June 2002
- V. 8 with Admin Suite
- V. 3.01
|EAL4, November 2000
||V. 6.5.13, with patches 4354,
||EAL3, April 2002
||V. 6.5.13, with patches 4354,
4451, 4452, 4373, 4473
||EAL3, May 2002
||EAL4+, November 1999
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
- Floppy drive
- CD-ROM drive
- Fixed disk drives
- 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
Included in the Security Target are:
- The hardware systems on which the operating system will be installed
- 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
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
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
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.
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.
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
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.