Exchange 2003 Common Criteria certification and how we got there
Published Dec 12 2005 12:33 PM 1,029 Views

On November 15th, Exchange Server 2003 Service Pack 1 was awarded the Common Criteria Evaluation Assurance Level 4 (EAL 4+) certification (please see below for definition of different levels), the highest level awarded to a messaging product as defined by the Common Criteria for Information Technology Security Evaluation (CCITSE). The Common Criteria (CC) certification is a globally accepted standard for evaluating the security features and capabilities of information technology products and enables IT consumers to make informed decisions about the security capabilities of IT products.


Microsoft submitted Exchange Server 2003 SP1 to the CC certification evaluation process to ensure that customers would have an independent, standard validation of the security features in this product.  Achieving CC certification demonstrates a milestone toward Microsoft's commitment to provide global customers with a secure email infrastructure.


Microsoft and Common Criteria


Microsoft is a leader in certifying operating systems and applications. Windows Server 2000 is certified at EAL4+ under the Controlled Access Protection Profile. Windows Server 2003 SP1 and Windows XP SP2 are under currently under evaluation as well as Windows Certificate Server.


ISA Server 2000 was certified at EAL2 and ISA Server 2005 is certified at EAL4+.


Exchange Server 2003 is the latest to join the CC group.


Common Criteria Background


The United States federal government maintains a set of evaluation criteria for judging the security of computer systems. Many of its agencies, and many private-sector companies, will only buy systems that meet specified sets of these evaluation criteria. Dating from the 1970s, the well-known "C2" rating of the US Trusted Computer Systems Evaluation Criteria (TCSEC) was one such level. The European counterpart to the TCSEC, the Information Technology Security Evaluation Criteria (ITSEC), specified a comparable rating.


To reflect the increased sophistication of technologies and the growing need for more international standards for evaluation during the 1990s, a group of nations joined forces through the International Organization for Standardization (ISO) to design a new security evaluation process, known as the "Common Criteria for Information Technology Security Evaluation" (CCITSE). In this paper we'll abbreviate it to the "Common Criteria".


Under the Common Criteria, classes of products (such as operating systems) are evaluated against the security functional and assurance requirements of "Protection Profiles." Protection Profiles may be developed to apply to operating systems, firewalls, smart cards, or other products that can be expected to meet security requirements. For example, the Controlled Access Protection Profile applies to operating systems and replaces the old C2 evaluation requirements. The Common Criteria also specify a series of Evaluation Assurance Levels (EALs) for evaluated products. A higher EAL certification specifies a higher level of confidence that a product's security functions will be performed correctly and effectively.


As of November 2005, countries that recognize Common Criteria include Austria, Australia, Canada, the Czech Republic, Finland, France, Hungary, Germany, Greece, India, Israel, Italy, Japan, The Netherlands, New Zealand, Norway, the Republic of Singapore, Spain, Sweden, Turkey, the United Kingdom, and the United States of America.


What do all of these “EALs” mean?


The organizers of Common Criteria (“the Scheme”) categorize the level of a security evaluation from 1 to 7 with 7 being the highest level of evaluation.





Functionally Tested

It is intended to detect obvious

errors for a minimum outlay, but is unlikely to result in the detection of subtle security

weaknesses. It is applicable where the requirement is for a low level of independently assured security.


Structurally Tested

It is applicable where the  requirement is for a low to moderate level of independently

assured security, but the  complete [product]

development record is not readily available. This may arise when securing legacy systems, or where access to the developer

is limited.


Methodically Tested and Checked

This assurance level permits a conscientious developer to gain maximum assurance from

positive security engineering at the design stage, without substantial alteration of existing sound development practices. It is applicable where the requirement is for a moderate level of independently assured

security, with a thorough investigation of the TOE and its development without incurring

substantial re-engineering costs.


Methodically Designed, Tested, and Reviewed

This is the highest assurance level which it is likely to be economically feasible to retrofit to an existing product line. EAL4

permits a developer to gain maximum assurance from positive security engineering based on good commercial

development practices, which are rigorous but not overly specialized. It is applicable where the requirement is for a moderate to high level of independently assured security

in conventional commodity products, and there is willingness to incur some additional

security-specific engineering costs.


Semi-formally Verified Design and Tested

Such a [product] will be designed and developed with the intent of

meeting EAL5 requirements. EAL5 is applicable where the requirement is for a high level of independently assured security

in a planned development, with a rigorous development approach but without incurring unreasonable costs for specialized security engineering techniques.


Semi-formally Verified Design and Tested

EAL6 permits a developer to gain high assurance from application of specialized security engineering techniques in a

rigorous development environment, to produce a premium product for protecting

high value assets against significant risks. EAL6 is applicable to the development of

specialized security products, for application in high risk situations which justify the additional costs.


Formally Verified Design and Tested

EAL7 represents an achievable upper bound on evaluation assurance for practically useful products. It should only be

considered for experimental application to all but conceptually simple and well understood products. EAL7 is applicable to

the development of specialized security products, for application in extraordinarily high risk situations which justify the

extraordinary additional costs. Practical application of this level is currently limited to products with tightly focused security

functionality which is amenable to formal analysis.


Exchange 2003 certification


Exchange Server 2003 customers can use this certification as an independent confirmation of the security and engineering processes that went into the design, development, manufacturing, and servicing of Exchange 2003. In addition, the Exchange 2003 Common Criteria documentation can be used to deploy Exchange 2003 in the same configuration as used during the evaluation. The Common Criteria laboratory, operated by TÜV Informationstechnik GmbH (TUViT), is an independent, accredited evaluator for evaluation under the Common Criteria and validated by the German Federal Office for Information Security (Bundesamt für Sicherheit in der Informationstechnik, BSI).


The evaluation consisted of Exchange 2003 SP1 and security update MS05-021 running on Windows Server 2003 SP1 plus the available Windows critical security updates at the time of the evaluation testing. CC is centered on performing a detailed security analysis for a specific, fixed configuration. In the Exchange 2003 evaluation, we evaluated Exchange 2003 in it’s out of the box configuration.


Behind the scenes of a CC certification


A CC evaluation has two broad tracks: verifying the security claims made for the product and the engineering processes that went into developing, manufacturing, delivering, and installing the product.


A protection profile is a useful way to compare security claims for similar products such as operating systems, firewalls, and smart cards.  When there isn’t a relevant protection profile, the developer can choose the specific security claims for their product. In the Exchange 2003 certification, we chose the latter option. The evaluation lab at TUViT validated security claims on the following:


- Access control and permissions sharing for user mailboxes and public folders

- Send and receive limits for mailboxes and their equivalents for public folders

- Authentication and authorization restrictions for sending mail to distribution lists

- Preventing unsolicited commercial email (spam) by filtering based on connection, sender, recipient

- Validating administrator control over Exchange admin functionality (regular users can not admin the system)


The precise claims are described in the security target for Exchange 2003.


At an EAL4 evaluation, we had to demonstrate that Exchange was methodically designed, tested, and reviewed.  This meant beginning with the security target, the TUViT evaluators had to review the functional specs for Exchange 2003, then decompose the features in the spec to high-level and low-level design features, and ultimately to portions of the Exchange 2003 source code.


In addition to reviewing the Exchange 2003 design, TUViT also had to review the testing that went into Exchange 2003. The first step was to review the test cases for Exchange 2003 to check that the Exchange Team methodically tested the product in terms of the claims in the security target. After this (and this included reviewing test logs!), TUViT then re-ran a subset of the Exchange 2003 tests to check if their results matched the Exchange team’s. Fortunately, all of their tests passed. Next, TUViT ran several new test cases that the designed to check the products functionality. Finally, TUViT performed a vulnerability assessment of the security target features and then tried to break into Exchange using commonly used hacker tools. Again, Exchange 2003 emerged unscathed.


Once we passed the design and testing portions of the evaluation, we still had the process review.


Coming up… Part II … the security evaluators come to Redmond


- Mike Grimm

Version history
Last update:
‎Jul 01 2019 03:10 PM
Updated by: