Jim Laurent's Weblog

I have it on good authority (from Sun Federal COO Bill Vass) that Solaris 10 03/05  has completed its Common Criteria evaluation.  It will take us a while to issue a formal press release, but the evaluation is complete.  This evaluation was at EAL 4+ using the Controlled Access Protection Profile (CAPP) and the Role Based Access Control PP.  The process has taken over a year and cost a significant bundle of cash.  Solaris 10 with Solaris Trusted Extensions (found in the 11/06 update) is current under evaluation with the addition of the Labeled Security PP and should complete next year.

Congratulations and thanks to Sun's evaluation team including Jane Medefesser, Vanessa Kong, and Linda Gallops.

A little history.....

A long, long time ago (back in the 1980s) the NSA created a program known as the Trusted Computer System Evaluation Criteria (TCSEC). As an employee of Gould Computer Systems (RIP!) at that time, I know that Gould's UTX-32 OS was the first commercial Unix to receive a TCSEC C2 evaluation by the NSA.  Gould sold about 5 copies of that OS after spending millions of dollars to complete the process.  The UK had an equivalent program known as ITSEC. The TCSEC labeled OSes using a letter/number scheme still referred to by some today:

• C2 is roughly equivalent to today's CAPP
• B1 is roughly equivalent to today's LSPP
  

There were two major problems with the NSA system.

1. The process took so long and cost so much that an evaluated product was no longer competitive and didn't run on the latest hardware.
2. An evaluation completed by the NSA meant nothing to the UK, Germany, or other countries who had their own evaluation schemes.
   

As a result, the Common Criteria process was established and a number of countries agreed to abide by it.

What is a CC Evaluation?

 The Common Criteria is an international set of standards for evaluating software products against a set of  requirements.  There are two parts to a CC designation; Evaluation Assurance Level and Protection Profile (more info)

 Evaluation Assurance Level

The EAL designates the level of rigor that was applied to an evaluation.  Levels range from 1-7 and are defined as:

• EAL1 - functionally tested
• EAL2 - structurally tested
• EAL3 - methodically tested and checked
• EAL4 - methodically designed, tested and reviewed
• EAL5 - semiformally designed and tested
• EAL6 - semiformally verified design and tested
• EAL7 - formally verified design and tested
  

At this time, EAL4 is the highest level that can be transferred from one country to another. 

Protection Profile

A protection profile defines the technical functions required to be evaluated.  For example, the Controlled Accesss Protection Profile includes requirements for (among others):

• User authentication  (you have to login)
• Access control (Unix-style permissions)
• Auditing (know what has happend on the system)
• Prevention of object re-use (clear memory and disk before giving it to another user) 

There are a variety of protection profiles for product classes including OS, Database, Firewall, Encryption etc.  It is also possible to get a CC Evaluation without a protection profile although the usefulness of such a thing is debatable.

Other protection profiles that apply to Solaris include:

• RBAC Role Based Access Control
  
• LSPP - Labeled Security PP for multi-level data 

Who cares about Common Criteria.

The US Federal Goverment and Department of Defense have a variety of policies (FISMA and DoD Directive 8500.2) dictating that CC evaluated products should be use where they exist and are preferred over non-evaluated products.  As a result, nearly all purchases by the US government require that an OS be evaluated or at least in the evaluation process.  Sun has a long history of evaluated Solaris OS versions over the last 10 years.

As an engineer at Sun with many years of DoD customer experience, I'm frequently asked a number of questions about the interpretation of the CC requirements in the DoD (see the questions in the comments section):

Can I use a Solaris update that's different than the certified version?

Strickly speaking, any change that you make to the certified baseline (platform, version, patches) means you are running an "uncertified configuration."  This doesn't make you less secure.  Strict conformance to this policy would seriously prevent you from running the latest Solaris version or taking advantage of the latest hardware.

What is the US DoD policy on using later Solaris updates?

While I can't speak for the government, I can relate my direct conversations with officials at the Defense Information Systems Agency (DISA) who create and enforce these policies.  I have been told that a CC evaluation is a "Checkbox" activity that is NOT the most important item in a security accreditation.  The fact that a more recent update of Solaris has not been certified directly should not prevent you from using it.  However, if the update has a new security feature that has not been evaluated and you are planning to use that feature, it may be more difficult to get your system accredited.  DoD customers should work directly with DISA in this area.  There is a help desk available at the DISA Field Security Office

What about commercial customers?

Each customer has their own policy.  Some simply require that a product be "in evaluation."  Others require that some version of the product has been certified.  Work with your customer's security office to determine their policy.

What does DoD Directive 8500.2 say about CC?

Feel free to read it, however, to paraphrase section E3.2.5:  If there is a certified product, you must use it.  If there is no product that's certified, it should be "in evaluation."  If there is no product in evaluation, a commitment from the vendor to evaluate should be made before you buy.  If there is no defined protection profile for a product class (eg. VMware), the vendor should create a security target and have it evaluated.

If the process was not designed to actually detect software bugs or vulnerabilities in an OS, then what does it check?

This question emphasizes the current disappointment that DoD officials have with the process.  They are paying extra money for evaluated products but not necessarily getting better products because of the evaluation process.  The process is designed to ensure that a product behaves as documented but it is NOT a source code scrub for buffer overflows, coding errors or other issues (The fact that MS Windows products are evaluated at EAL4 should make this point painfully obvious!).

Does every product need to be CC  evaluated?

The DoD directive refers only to "IA products, and IA-enabled IT products."  They define IA-enabled product as "Product or technology whose primary role is not security, but which provides security services as an associated feature of its intended operating capabilities. Examples include such products as security-enabled web browsers, screening routers, trusted operating systems, and security-enabled messaging systems."  By this definition a product like StarOffice is NOT IA-enabled, however, a web portal or identity management systems is IA-enabled in my opinion.  Some would say, "If it asks for a username and password, it's IA-enabled."

What is NIAP and who does the evaluations?

NIAP is the National Information Assurance Partnership between NIST and NSA.  They control the CC program in the U.S.  An evaluation is done by an independent commercial laboratory known as a commercial licensed evaluation facility or CLEF.  Sun's evaluation was done by a Canadian CLEF.

What's wrong with the current Common Criteria process?

Although the current process is somewhat better than the old NSA process, it still leaves something to be desired.  I have heard it stated in public forums by DoD employees that the CC process does not meet all Government's goals.   Current problems include:

• It still take a long time (about 1 1/2 years) resulting in delays in purchasing state of the art products.
• The process is not designed to actually detect software bugs or vulnerabilities in an OS
• The rules for adoption of the OS are interpreted in a wide variety of ways across organizations.
• It is not flexible in handling OS updates and patches
  

What is the difference between a CC evaluation and a site accreditation?

Products are CC evaluated, sites and solutions are accredited.  For example, a particular site may take a number of CC evaluated products, install them on computers, connect to different classifications of network and put the whole solution in a particular building.  An accreditation ensures that all these steps were followed with security in mind and that the products, policies, people and procedures meet the security requirements of  the mission.  An accounting system has different requirements than a warfighting or intelligence gathering system and the accreditations will vary for each even if they use the same products.

Why should you  care?

CC evaluations provide an assurance that a product has been documented properly and behaves in accordance with its documentation.  It is an external, third party audit of a product that provides a higher level of assurance on the capabilities of the delivered product. Sun takes our responsibility for security very seriously and our goal is to ensure that Solaris is the preferred platform for Federal mission critical systems.

Sun has a long history of evaluated versions of Solaris including 2.5.1, 2.6, 8, 9, 10 and various Trusted Solaris versions.

CC evaluated products are preferred by most US Federal and DoD procurements.