VMware vSphere has started its journey to Common Criteria certification.
So what is Common Criteria and why should we be bothered, to answer this a little background is in order. The Common Criteria for Information Technology Security Evaluation (abbreviated as Common Criteria or CC) is an international standard (ISO/IEC 15408) for computer security certification. Its current incarnation is version 3.1.
Originally IT security standards were different across the globe, what was considered secure under the Orange book might not have been accepted as such by Europe or Canada, Therefore CC was formed out of the following three standards:
- ITSEC – The European standard, developed in the early 1990s by France, Germany, the Netherlands and the UK, which was a unification of earlier work, including the two UK approaches (the CESG UK Evaluation Scheme which was aimed at the Defence/Intelligence market and the DTI Green Book positioned for commercial use), this standard was adopted by some other countries, for example. Australia.
- CTCPEC – The Canadian standard followed from the US DoD standard, but avoided several problems and was used jointly by evaluators from both the U.S. and Canada. The CTCPEC standard was first published in May 1993.
- TCSEC – The United States Department of Defense DoD 5200.28 Std, called the Orange Book and parts of the Rainbow Series. The Orange Book originated from Computer Security work including the Ware Report, done by the National Security Agency and the National Bureau of Standards (the NBS eventually became NIST) in the late 1970s and early 1980s. The central thesis of the Orange Book follows from the work done by Dave Bell and Len Lapadula for a set of protection mechanisms.
Ostensibly the CC was produced to simplify certification by unifying these standards; however the real reason was costs, prior to CC, companies selling computer products to the government market (mainly for Defence or Intelligence use) would have to be evaluated under each of the national standards, this was not only costly but very time consuming, often a product would be certified as compliant in the US, only to fail CESG. Now under CC a manufacture would only need to have their product evaluated against one set of standards in a CC member country. However, due to the esoteric nature of the standard, the costs did not significantly fall. A certification process under common criteria can sink hundreds of thousands of Dollars, with no guarantee of gaining the desired EAL () level. For example all testing laboratories must comply with ISO 17025, and certification bodies will normally be approved against either ISO/IEC Guide 65 or BS EN 45011. Even compliance with the standard is typically demonstrated to a national approval authority.
One of the most important parts of the CC standard is the sub-treaty level Common Criteria MRA (Mutual Recognition Arrangement), under this sub section each party agrees to recognize any evaluation against the Common Criteria standard done by other parties. The Treaty originally signed in 1998 by Canada, France, Germany, the United Kingdom and the United States, was further expanded by the joining of Australia and New Zealand in 1999 and again in 2000 by the joining of Finland, Greece, Israel, Italy, the Netherlands, Norway and Spain.
The MRA was renamed Common Criteria Recognition Arrangement (CCRA) and membership continues to expand. Within the CCRA only evaluations up to EAL 4 are mutually recognized (Including augmentation with flaw remediation). The European countries within the former ITSEC agreement will typically recognize higher EALs as well. Evaluations at EAL5 and above tend to involve the security requirements of the host nation’s government.
So what are the issues?
Well all this sounds hunky dory and everything is rosy in the garden. Well not quite, the CC has a lot of flaws:
Requirements
The Common Criteria requirements are very generic; there are no directly available a list of product security requirements or features for specific (classes of) products: this follows the approach that was taken by ITSEC, but has been a source of debate to those used to the more prescriptive approach of other earlier standards such as TCSEC (Orange Book) and FIPS 140-2.
Value of Certification
This particular issue is both CC main strength and major weakness. If a product is CC certified, it does not necessarily follow that it is completely secure. Various Microsoft Windows versions, including Windows Server 2003 and Windows XP, have been certified at EAL4+, but regular security patches for security vulnerabilities are still published by Microsoft for these Windows systems. This is possible because the process of obtaining a Common Criteria certification allows a vendor to restrict the analysis to certain security features and to make certain assumptions about the operating environment and the strength of threats
The certified Microsoft Windows versions remain at EAL4+ without including the application of any Microsoft security vulnerability patches in their evaluated configuration. This shows both the limitation and strength of an evaluated configuration, as a System is still considered compliant even if it is no longer secure due to new vulnerabilities appearing.
Criticisms
In Mid 2007, Government Computing News (GCN) columnist William Jackson critically examined Common Criteria methodology and its US implementation by the Common Criteria Evaluation and Validation Scheme (CCEVS). In the column executives from the security industry, researchers, and representatives from the National Information Assurance Partnership (NIAP) were interviewed. Some of the objections outlined in the article include:
- That Evaluation is a costly process (often measured in hundreds of thousands of US dollars) — and the vendor’s return on that investment is not necessarily a more secure product
- Evaluation focuses primarily on assessing the evaluation documentation, not on the actual security, technical correctness or merits of the product itself. For U.S. evaluations, only at EAL5 and higher do experts from the National Security Agency participate in the analysis; and only at EAL7 is code analysis required.
- The effort and time necessary to prepare evaluation evidence and other evaluation-related documentation is so cumbersome that by the time the work is completed, the product in evaluation is generally obsolete
- Industry input, including that from organizations such as the Common Criteria Vendor’s Forum, generally has little impact on the process as a whole
Earlier in 2006 a research paper by computer specialist David A. Wheeler suggested that the Common Criteria process discriminated against Free and Open Source Software (FOSS)-centric organizations and development models. This is because Common Criteria assurance requirements tend to be conducted following the traditional waterfall software development methodology. FOSS software however is produced using modern agile paradigms. Some have argued that both paradigms do not align well, others have attempted to reconcile both paradigms, Personally I fall into the camp of FOSS as a model is worrying in a “Truly Secure Environment”
Alternative approaches
Even throughout the lifetime of CC, it has not been fully adopted even by the creator nations, with, for example, cryptographic approvals being handled separately, such as by the Canadian / US implementation of FIPS-140, and the CESG Assisted Products Scheme (CAPS) in the UK.
Further we in the UK have also produced a number of alternative schemes when the timescales, costs and overheads of mutual recognition have been found to be impeding the operation of the market:
- The CESG System Evaluation (SYSn) and Fast Track Approach (FTA) schemes for assurance of government systems rather than generic products and services, which have now been merged into the CESG Tailored Assurance Service (CTAS) [7]
- The CESG Claims Tested Mark (CCT Mark), which is aimed at handling less exhaustive assurance requirements for products and services in a cost and time efficient manner
Summary
So as you can see the hullaballoo about vSphere entering Common Criteria testing in reality mean next to nothing, if you are a consultant working in the Government sector, it means that on completion you will have a better chance of getting accreditation for your design if utilizing vSphere. A Certified product does not mean a certified solution. You will still have to present your SYOPS to your accreditation authority, and still have to mitigate your deviances from GAP.
Comments are closed.