What is the new PP


Low assurance evaluations, mostly conformity testing;

No EAL claim or even mention;

Lowering the developer evidence production;

Evaluator actions defined and associated to each functional requirement.






So people likes to specify
the evaluator activities ...

  • Reduces subjectivity;
  • Increases understanding of the gained assurance;
  • Makes life easier to everyone.
  • But ...
  • Only applicable to low assurance
    • (good, consistent with new approach)
    • (insufficient when asking for more)
  • Real know-how and security sensible methodologies are not easy to share and be published.

Is this incompatible with the good old CC/CEM?

Existing PPs are making huge efforts not to use components from CC/CEM ...

... yet they claim they meet them so as to have the mutual recognition of the future certificates.

What is the only thing not really addressed by the CC/CEM?

The instantiation of TOE-specific evaluation activities.

From the generic framework we are moving to specific applications ...

... and we will back to moving them to the generic framework.


The association of assurance activities to functional requirements is not a product type thing, it is mechanism-based.

Think, for example, how to avoid buffer overruns. Is it OS-centric? Is it DBMS centric? What about physical protection?

How is this trend perceived by the community?

Alvaro Ortega: Attack Methods for HW Devices with Security Boxes (Epoche&Espri)

Trifon Gimenez: Side channels analysis under AVA.VAN.5: scoring the attack potential (Epoche&Espri)

Dirk-Jan Out: The Advantages of Using TOE Type Specific Assurance Methodology (Brightsight)

It it's easier to agree on details if we know exactly what we are talking about. Success recipe for technical communities?

And what about the rest of trending PP topics?

Welcome to chaos!

Content requirements without evaluator actions

Evaluator actions without content requirements

Messing ideas, concepts and requirements around, each PP taking it's own approach to the three times denial of the CC/CEM.


Achievable, Repeateble, Testable?

Because you do not want use CEM, you try to develop a comprehensive evaluation methodology in a day.

If it's already there, use it, please!

For the sake of consistency;

For the sake of completeness;

And to ease reaching the goals of the Vision Statement.

Fixing the CC

Testing the new structure

We have expanded the CC DTD, and named it CC V4;

We have taken the current OSPP draft, and nicely converted it into XML;

We have developed a small tool to publish it.

It works!

Three document types are
defined in cc4.dtd

  • The CC/CEM itself.
  • A supporting document
  • A protection profile

Checking the PP

We have provided two publication types for the PP:

  • Just the content of the PP
  • The content of the PP plus the applicable CC/CEM material as needed for the PP indicated assurance requirements.

Read them both and compare. The good old framework makes a lot of sense. Not every PP can/need to develop everything from scratch.

How to develop a PP?

SPD/Objectives/SFRs, you know how to do this.

Pick your assurance package/framework/level.

For each SFR, where needed, add your functional-specific stuff, as an instantiation of the alreay defined evaluator actions, or to fine-tune the developer evidence content requirements.

Where to find all this?

Here: http://www.epoche.es/PPwizard.html

Includes the PP documents, tool and XML stuff.

Open discussion


Miguel Bañón
Epoche and Espri