COMMON CRITERIA
What is Common Criteria?
The Common Criteria (CC) is an international standard for evaluating the security functions of IT products. It defines a framework for the oversight of evaluations, syntax for specifying the security requirements to be met and a methodology for evaluating those requirements. CC evaluations are intended to provide consumers with a defined level of independent assurance in the secure operation of a certified product.
Because of procurement policies around the world that require products to be CC certified (such as CNSSP11) vendors are incentivized through sales to achieve compliance. Before the CC, each country had its own evaluation criteria whereas now vendors can be evaluated once and recognized world-wide.
The CC defines seven Evaluation Assurance Levels (EAL) which provide a sliding scale of assurance from EAL1 (lowest) to EAL7 (highest). The Common Criteria Recognition Arrangement (CCRA) caps mutual recognition at EAL2 unless an internationally recognized Collaborative Protection Profile (cPP) is used in which case recognition may extend to EAL4. The CC standard documents can be obtained from www.commoncriteriaportal.org
Frequently Asked Questions
HOW MUCH DOES COMMON CRITERIA CERTIFICATION COST?
It depends. There are many factors to consider within a CC evaluation which impact the cost. Costs include:
- Internal costs (including development and project management time)
- Consulting fees (which reduces internal costs)
- Lab fees
- Certification fees (some certification schemes charge a cost recovery fee)
You can request a quote by completing a quick and easy form.
HOW LONG DOES COMMON CRITERIA CERTIFICATION TAKE?
We find that certification projects typically take about 9 – 12 months to complete, including the development time required to remediate gaps. The first step is to for us to perform a test run to identify these using our Functional Gap Assessment process.
Uniquely, Lightship leverages our automation platform to dramatically reduce the testing time for our clients to days instead of weeks or months.
WHAT GETS EVALUATED UNDER COMMON CRITERIA?
This depends on the Protection Profile and/or EAL that you are claiming. Protection Profile based evaluations are more heavily geared towards functional testing. EAL evaluations include the following:
Security Target evaluation. Evaluation of the Security Target (ST) – a claims document that specifies the functions under evaluation and the assurance requirements being met.
Design evaluation. Evaluation of design documents – at the most basic level this will simply be an interface specification. Depending on the assurance requirements this can include multiple layers of very detailed design specs and source code review (this is becoming less common).
Guidance evaluation. Evaluation of all the guidance documents that are shipped with the product and a CC specific addendum or ‘Secure Installation Guide’ for achieving the evaluated configuration.
Life-cycle evaluation. Evaluation of configuration management practices, delivery procedures and security bug tracking (flaw remediation). Can also include development practices and site security audits.
Functional testing. The evaluators repeat a sample of the developer’s functional tests and come up with some independent tests to confirm the operation of the security functions as specified.
Penetration testing. The evaluators don their white hats and try to break the security policy enforced by the security functions.
Whether a particular evaluation activity gets performed is dependent on the assurance requirements that are specified in the Security Target. EAL levels are simply pre-canned packages of assurance requirements.
WHAT IS A SECURITY TARGET?
A Security Target is the document that defines the Target of Evaluation (TOE), that is, the product configuration and version, and scope of security functionality being evaluated. The CC allows the TOE to be all or part of a product or system. The Security Target is put together using CC constructs. As with a Protection Profile (see below), the Security Target defines both functional requirements as well as assurance requirements. A Security Target may conform to a Protection Profile but is not required to. A Security Target (written by vendor) goes beyond a Protection Profile (written by consumer) by including a description of how the product achieves the defined requirements. There are plenty of Security Target examples at the Common Criteria Portal
WHAT IS A PROTECTION PROFILE?
A Protection Profile is a requirements statement put together using CC constructs. They are generally published by governments for a specific technology type, like Firewalls for example, as part of procurement policy. A Protection Profile specifies both functional requirements as well as assurance requirements. EALs specify the assurance part. So a Protection Profile will may reference an EAL but will also specify a set of functional requirements to be met. By far the most commonly used Protection Profiles are those published by the United States National Information Assurance Partnership (NIAP). In addition to these, work on internationally agreed Protection Profiles is published at the Common Criteria Portal.
COMMON CRITERIA
What is Common Criteria?
The Common Criteria (CC) is an international standard for evaluating the security functions of IT products. It defines a framework for the oversight of evaluations, syntax for specifying the security requirements to be met and a methodology for evaluating those requirements. CC evaluations are intended to provide consumers with a defined level of independent assurance in the secure operation of a certified product.
The “Common” in Common Criteria is there because it’s a mash-up of multiple countries’ criteria. The genesis and sustaining reason for the CC’s existence is policy – government agency procurement policies around the world that require products to be CC certified (such as CNSSP11). Vendors are incentivized through sales to achieve compliance. Before the CC, each country had its own evaluation criteria whereas now vendors can be evaluated once and recognized world-wide.
The CC defines seven Evaluation Assurance Levels (EAL) which provide a sliding scale of assurance from EAL1 (lowest) to EAL7 (highest). The Common Criteria Recognition Arrangement (CCRA) caps mutual recognition at EAL2 unless an internationally recognized Collaborative Protection Profile (cPP) is used in which case recognition may extend to EAL4. The CC standard documents can be obtained from www.commoncriteriaportal.org
Frequently Asked Questions
HOW MUCH DOES COMMON CRITERIA CERTIFICATION COST?
There are many factors to consider within a CC evaluation which impact the cost. Costs include:
- Internal costs (including development and project management time)
- Consulting fees (which reduces internal costs)
- Lab fees
- Certification fees (some certification schemes charge a cost recovery fee)
HOW LONG DOES COMMON CRITERIA CERTIFICATION TAKE?
The general rule of thumb is that the CC certification process takes about one year to complete. This can be longer or shorter depending on the conformance claims and product readiness.
Uniquely, Lightship leverages our automation platform to dramatically reduce the testing time for our clients to days instead of weeks or months.
WHAT GETS EVALUATED UNDER COMMON CRITERIA?
A large amount of documentation is evaluated, followed by some testing at the end. With good intent the CC authors try to codify the information that an evaluator needs by using very specific requirements for input documentation. Evaluators spend a lot of time verifying that the required information is present and consistent. A rough map of an evaluation looks like this:
Security Target evaluation. Evaluation of the Security Target (ST) – a claims document that specifies the functions under evaluation and the assurance requirements being met.
Design evaluation. Evaluation of design documents – at the most basic level this will simply be an interface specification. Depending on the assurance requirements this can include multiple layers of very detailed design specs and source code review (this is becoming less common).
Guidance evaluation. Evaluation of all the guidance documents that are shipped with the product and a CC specific addendum or ‘Secure Installation Guide’ for achieving the evaluated configuration.
Life-cycle evaluation. Evaluation of configuration management practices, delivery procedures and security bug tracking (flaw remediation). Can also include development practices and site security audits.
Functional testing. The evaluators repeat a sample of the developer’s functional tests and come up with some independent tests to confirm the operation of the security functions as specified.
Penetration testing. The evaluators don their white hats and try to break the security policy enforced by the security functions.
Whether a particular evaluation activity gets performed is dependent on the assurance requirements that are specified in the Security Target. EAL levels are simply pre-canned packages of assurance requirements.
WHAT IS A SECURITY TARGET?
A Security Target is the document that defines the Target of Evaluation (TOE), that is, the product configuration and version, and scope of security functionality being evaluated. The CC allows the TOE to be all or part of a product or system. The Security Target is put together using CC constructs. As with a Protection Profile (see below), the Security Target defines both functional requirements as well as assurance requirements. A Security Target may conform to a Protection Profile but is not required to. A Security Target (written by vendor) goes beyond a Protection Profile (written by consumer) by including a description of how the product achieves the defined requirements. There are plenty of Security Target examples at the CC Portal
WHAT IS A PROTECTION PROFILE?
A Protection Profile is a requirements statement put together using CC constructs. They are generally published by governments for a specific technology type, like Firewalls for example, as part of procurement policy. A Protection Profile specifies both functional requirements as well as assurance requirements. EALs specify the assurance part. So a Protection Profile will may reference an EAL but will also specify a set of functional requirements to be met. By far the most commonly used Protection Profiles are those published by the United States National Information Assurance Partnership (NIAP). In addition to these, work on internationally agreed Protection Profiles is published at the Common Criteria Portal.