305 lines
10 KiB
HTML
305 lines
10 KiB
HTML
<HTML
|
|
><HEAD
|
|
><TITLE
|
|
>Common Criteria Introduction</TITLE
|
|
><META
|
|
NAME="GENERATOR"
|
|
CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
|
|
REL="HOME"
|
|
TITLE="Secure Programming for Linux and Unix HOWTO"
|
|
HREF="index.html"><LINK
|
|
REL="UP"
|
|
TITLE="Security Requirements"
|
|
HREF="requirements.html"><LINK
|
|
REL="PREVIOUS"
|
|
TITLE="Security Requirements"
|
|
HREF="requirements.html"><LINK
|
|
REL="NEXT"
|
|
TITLE="Security Environment and Objectives"
|
|
HREF="x608.html"></HEAD
|
|
><BODY
|
|
CLASS="SECT1"
|
|
BGCOLOR="#FFFFFF"
|
|
TEXT="#000000"
|
|
LINK="#0000FF"
|
|
VLINK="#840084"
|
|
ALINK="#0000FF"
|
|
><DIV
|
|
CLASS="NAVHEADER"
|
|
><TABLE
|
|
SUMMARY="Header navigation table"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
CELLPADDING="0"
|
|
CELLSPACING="0"
|
|
><TR
|
|
><TH
|
|
COLSPAN="3"
|
|
ALIGN="center"
|
|
>Secure Programming for Linux and Unix HOWTO</TH
|
|
></TR
|
|
><TR
|
|
><TD
|
|
WIDTH="10%"
|
|
ALIGN="left"
|
|
VALIGN="bottom"
|
|
><A
|
|
HREF="requirements.html"
|
|
ACCESSKEY="P"
|
|
>Prev</A
|
|
></TD
|
|
><TD
|
|
WIDTH="80%"
|
|
ALIGN="center"
|
|
VALIGN="bottom"
|
|
>Chapter 4. Security Requirements</TD
|
|
><TD
|
|
WIDTH="10%"
|
|
ALIGN="right"
|
|
VALIGN="bottom"
|
|
><A
|
|
HREF="x608.html"
|
|
ACCESSKEY="N"
|
|
>Next</A
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><HR
|
|
ALIGN="LEFT"
|
|
WIDTH="100%"></DIV
|
|
><DIV
|
|
CLASS="SECT1"
|
|
><H1
|
|
CLASS="SECT1"
|
|
><A
|
|
NAME="AEN595"
|
|
></A
|
|
>4.1. Common Criteria Introduction</H1
|
|
><P
|
|
>First, some general information about the CC will help understand
|
|
how to apply its concepts.
|
|
The CC's official name is
|
|
"The Common Criteria for Information Technology Security Evaluation",
|
|
though it's normally just called the Common Criteria.
|
|
The CC document has three parts:
|
|
the introduction (that describes the CC overall),
|
|
security functional requirements (that lists various kinds of security
|
|
functions that products might want to include),
|
|
and security assurance requirements (that lists various methods of
|
|
assuring that a product is secure).
|
|
There is also a related document, the
|
|
"Common Evaluation Methodology" (CEM),
|
|
that guides evaluators how to apply the CC when doing formal evaluations
|
|
(in particular, it amplifies what the CC means in certain cases).</P
|
|
><P
|
|
>Although the CC is International Standard ISO/IEC 15408:1999,
|
|
it is outrageously expensive to order the CC from ISO.
|
|
Hopefully someday ISO will follow the lead of other standards
|
|
organizations such as the IETF and the W3C, which freely redistribute
|
|
standards.
|
|
Not surprisingly, IETF and W3C standards are followed more often than
|
|
many ISO standards, in part because ISO's fees for standards simply
|
|
make them inaccessible to most developers.
|
|
(I don't mind authors being paid for their work, but ISO doesn't
|
|
fund most of the standards development work - indeed, many of the developers
|
|
of ISO documents are volunteers - so ISO's indefensible fees only line their
|
|
own pockets and don't actually aid the authors or users at all.)
|
|
Thankfully, the CC developers anticipated this problem and have made sure
|
|
that the CC's technical content is freely available to all;
|
|
you can download the CC's technical content from
|
|
<A
|
|
HREF="http://csrc.nist.gov/cc/ccv20/ccv2list.htm"
|
|
TARGET="_top"
|
|
>http://csrc.nist.gov/cc/ccv20/ccv2list.htm</A
|
|
>
|
|
Even those doing formal evaluation processes usually
|
|
use these editions of the CC, and not the ISO versions;
|
|
there's simply no good reason to pay ISO for them.</P
|
|
><P
|
|
>Although it can be used in other ways, the CC is typically
|
|
used to create two kinds of documents, a
|
|
``Protection Profile'' (PP) or a ``Security Target'' (ST).
|
|
A ``protection profile'' (PP) is a document created by group of users
|
|
(for example, a consumer group or large organization)
|
|
that identifies the desired security properties of a product.
|
|
Basically, a PP is a list of user security requirements,
|
|
described in a very specific way defined by the CC.
|
|
If you're building a product similar to other existing products, it's
|
|
quite possible that there are one or more PPs that define what some
|
|
users believe are necessary for that kind of product
|
|
(e.g., an operating system or firewall).
|
|
A ``security target'' (ST) is a document that identifies what a product
|
|
actually does, or a subset of it, that is security-relevant.
|
|
An ST doesn't need to meet the requirements of
|
|
any particular PP, but an ST could meet the requirements of one or more PPs.</P
|
|
><P
|
|
>Both PPs and STs can go through a formal evaluation.
|
|
An evaluation of a PP simply ensures that the PP meets various documentation
|
|
rules and sanity checks.
|
|
An ST evaluation involves not just examining the ST document,
|
|
but more importantly it involves evaluating an actual system
|
|
(called the ``target of evaluation'', or TOE).
|
|
The purpose of an ST evaluation is to ensure that, to the level of
|
|
the assurance requirements specified by the ST,
|
|
the actual product (the TOE) meets the ST's security functional requirements.
|
|
Customers can then compare evaluated STs to
|
|
PPs describing what they want.
|
|
Through this comparison, consumers can determine if the
|
|
products meet their requirements - and if not, where the limitations are.</P
|
|
><P
|
|
>To create a PP or ST, you go through a process of identifying the
|
|
security environment, namely, your
|
|
assumptions, threats, and relevant organizational
|
|
security policies (if any).
|
|
From the security environment, you derive
|
|
the security objectives for the product or product type.
|
|
Finally, the security requirements are selected so that
|
|
they meet the objectives.
|
|
There are two kinds of security requirements: functional requirements
|
|
(what a product has to be able to do), and assurance requirements
|
|
(measures to inspire confidence that the objectives have been met).
|
|
Actually creating a PP or ST is often not a simple straight line as
|
|
outlined here, but the final result needs to show a clear relationship so
|
|
that no critical point is easily overlooked.
|
|
Even if you don't plan to write an ST or PP,
|
|
the ideas in the CC can still be helpful;
|
|
the process of identifying the security environment, objectives, and
|
|
requirements is still helpful in identifying what's really important.</P
|
|
><P
|
|
>The vast majority of the CC's text is used to define standardized
|
|
functional requirements and assurance requirements.
|
|
In essence, the majority of the CC is a ``chinese menu'' of possible
|
|
security requirements that someone might want.
|
|
PP authors pick from the various options to describe what they want, and
|
|
ST authors pick from the options to describe what they provide.</P
|
|
><P
|
|
>Since many people might have difficulty identifying a reasonable set
|
|
of assurance requirements, so pre-created sets of assurance requirements
|
|
called ``evaluation assurance levels'' (EALs) have been defined, ranging
|
|
from 1 to 7.
|
|
EAL 2 is simply a standard shorthand for the set of assurance requirements
|
|
defined for EAL 2.
|
|
Products can add additional assurance measures, for example, they might
|
|
choose EAL 2 plus some additional assurance measures (if the combination
|
|
isn't enough to achieve a higher EAL level, such a combination would be
|
|
called "EAL 2 plus").
|
|
There are mutual recognition agreements signed between many of the
|
|
world's nations that will accept an evaluation done by
|
|
an accredited laboratory in the other countries as long as all of the
|
|
assurance measures taken were at the EAL 4 level or less.</P
|
|
><P
|
|
>If you want to actually write an ST or PP, there's an
|
|
open source software program that can help you, called the
|
|
``CC Toolbox''.
|
|
It can make sure that dependencies between requirements
|
|
are met, suggest common requirements, and help you quickly
|
|
develop a document, but it obviously can't do your thinking for you.
|
|
The specification of exactly what information
|
|
must be in a PP or ST are in CC part 1, annexes B and C respectively.</P
|
|
><P
|
|
>If you do decide to have your product (or PP) evaluated by
|
|
an accredited laboratory, be prepared to spend money, spend time,
|
|
and work throughout the process.
|
|
In particular, evaluations require paying an
|
|
accredited lab to do the evaluation, and higher levels of assurance
|
|
become rapidly more expensive.
|
|
Simply believing your product is secure isn't good enough; evaluators
|
|
will require evidence to justify any claims made.
|
|
Thus, evaluations require documentation, and usually the available
|
|
documentation has to be improved or developed
|
|
to meet CC requirements (especially at the higher assurance levels).
|
|
Every claim has to be justified to some level of confidence, so the more
|
|
claims made, the stronger the claims, and the
|
|
more complicated the design, the more expensive an evaluation is.
|
|
Obviously, when flaws are found, they will usually need to be fixed.
|
|
Note that a laboratory is paid to evaluate a product and determine the truth.
|
|
If the product doesn't meet its claims, then you basically have two
|
|
choices: fix the product, or change (reduce) the claims.</P
|
|
><P
|
|
>It's important to discuss with customers what's desired before beginning
|
|
a formal ST evaluation;
|
|
an ST that includes functional or assurance requirements
|
|
not truly needed by customers will
|
|
be unnecessarily expensive to evaluate, and an ST that omits
|
|
necessary requirements may not be acceptable to the customers
|
|
(because that necessary piece won't have been evaluated).
|
|
PPs identify such requirements, but make sure that the PP
|
|
accurately reflects the customer's real requirements (perhaps the customer
|
|
only wants a part of the functionality or assurance in the PP,
|
|
or has a different environment in mind, or wants something else instead
|
|
for the situations where your product will be used).
|
|
Note that an ST need not include every security feature in a product;
|
|
an ST only states what will be (or has been) evaluated.
|
|
A product that has a higher EAL rating is not necessarily more secure than a
|
|
similar product with a lower rating or no rating;
|
|
the environment might be different, the evaluation may have saved money and
|
|
time by not evaluating the other product at a higher level,
|
|
or perhaps the evaluation missed something important.
|
|
Evaluations are not proofs; they simply impose a defined minimum bar to
|
|
gain confidence in the requirements or product.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="NAVFOOTER"
|
|
><HR
|
|
ALIGN="LEFT"
|
|
WIDTH="100%"><TABLE
|
|
SUMMARY="Footer navigation table"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
CELLPADDING="0"
|
|
CELLSPACING="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="left"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="requirements.html"
|
|
ACCESSKEY="P"
|
|
>Prev</A
|
|
></TD
|
|
><TD
|
|
WIDTH="34%"
|
|
ALIGN="center"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="index.html"
|
|
ACCESSKEY="H"
|
|
>Home</A
|
|
></TD
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="right"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="x608.html"
|
|
ACCESSKEY="N"
|
|
>Next</A
|
|
></TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="left"
|
|
VALIGN="top"
|
|
>Security Requirements</TD
|
|
><TD
|
|
WIDTH="34%"
|
|
ALIGN="center"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="requirements.html"
|
|
ACCESSKEY="U"
|
|
>Up</A
|
|
></TD
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="right"
|
|
VALIGN="top"
|
|
>Security Environment and Objectives</TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></BODY
|
|
></HTML
|
|
> |