If you’ve ever spent any amount of time delving into the world of Common Criteria (CC), you’ve no doubt come across the veritable Roman/biblical hierarchy of relationships between the various components. At times, it would make even Cersei Lannister blush. In support of the CC automation we are doing at Lightship Security, I took on the daunting task of modelling this complex family tree in software. Here’s what I learned about who begat whom in the family tree of CC requirements.
At the highest level, we have the class. The class contains some contextual information about the assertion goal and contains a set of families which achieve that goal. Classes are usually named as a three letter acronym (TLA), ie. FIA (covering identification and authentication).
Similarly, a family is also denoted with a TLA as a suffix to the class in belongs to, ie. FIA_UAU. Families house a set of components which each share a similar goal but differ in emphasis and testing rigour.
While the previous groupings act in large part as containers, the component is the smallest selectable item of requirements. The component will be made up of 1 or more elements. An element is an indivisible statement of security need. It is a Target of Evaluations (TOE) requirement.
Initially, the relationship doesn’t seem all that complicated.
A collaborative protection profile (cPP) can be thought of as a tree of the aforementioned structures detailing the statements a TOE must affirm as requirements. A cPP will have named classes, families, components, extended components (usually denoted by a _EXT suffix) and elements. Within the protection profile, some of the constructs might be mandatory and the requirements listed in the elements must be satisfied. A hierarchy might also be optionally claimed. Lastly, a hierarchy might fall under a selectable claim. Depending on the nature of the mandatory or optional claims, these selectable elements might come into play. This complicates the diagram slightly.
Along with the collaborative protection profile is the supporting document (SD). If the cPP can be thought of as the list of requirements, the SD contains the same objects but lists the actions an evaluator must make to validate the statements made in the cPP. The cPP is what the TOE will do. The SD is how the evaluator will prove it.
The SD introduces assurance activities (AAs). AAs can take many forms. In the case of the NDcPP, the TOE summary specification (TSS), guidance documentation, and tests are documented within the SD. Each of these sections (or other types depending on the PP) may or may not exist within a component or element. Each of these sections will contain one or more actionable statements to be carried out by the evaluator.
As you can see, our once simple family tree of class, family, component, element has now blossomed into a complex, dynamic gaggle that even Robert Graves could write about. This post scrapes the surface of the intricate nuances that need to be considered when trying to understand what needs to be done, what is in scope and what needs to be tested when automating our testing. Our mission at Lightship Security is to simplify the complex relationships found in CC through expertise and automation and to allow our clients to “certify at the speed of development”.
About the Author
Alex is the lead developer of Greenlight – the test automation system that Lightship uses to automate CC Protection Profile based testing. Alex enjoys using mechanical keyboards, believes in spaces over tabs and is a fan of anything involving dragons.
Alex Thurston
Alex Thurston is Lightship’s lead developer. While relatively new to the certifications space, he has been involved in software development for over 10+ years. He loves all aspects of software development, loves to find modern approaches through code, and hates doing the same thing more than once.