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.
- 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.
- 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.