Most of our work is project based. We agree a set of requirements with a customer and then work these into a clear statement of work with well-defined deliverables, timescales and responsibilities. In order to allow our customers maximum control over their spending, we usually work to a fixed price.
The bulk of our work is taken up with Common Criteria and FIPS 140-2 evaluations.
Common Criteria |
Common Criteria projects are usually phased to fit in with the stages of a Common Criteria evaluation.
Initially we will work together to write a Security Target, either to a relevant Protection Profile or using a set of Security Functional Requirements applicable to the Target of Evaluation (your product).
Once this Security Target is accepted as a basis for evaluation, we can produce the other evidence to allow the test laboratory to evaluate the product.
Historically, we have concentrated on the higher levels of evaluation, usually EAL4 or EAL4+, but most schemes worldwide are now concentrating on EAL2 evaluation against Security Targets based on public Protection Profiles. This has the advantages that evaluations are quicker and cheaper to perform and also make it easier for potential purchasers to make like for like comparisons between different products.
FIPS 140 |
We usually work in five distinct phases to most efficiently mesh with the evaluation process and to mitigate cost and risk.
We normally begin with a two-day workshop. This usually occurs on your site or at a location that is convenient for your staff.
The purpose of the workshop is threefold: It provides training in the concepts of FIPS 140-2 and the evaluation process; Presents the module functionality to the delegates; Defines the module boundary and lists the algorithms, keys and services of the module.
We can usually be on site to give the workshop within two weeks of receiving an order.
Following on from the workshop visit, we will have most of the information that we need to perform an initial compliance audit. The purpose of this is to assess your product against the FIPS 140 criteria.
The audit report will highlight any non-compliances and provide advice on how to address any non-compliances.
This approach allows you to correct any problems prior to evaluation to your own timescales rather than potentially disrupt an evaluation and potentially generate adverse publicity by encountering problems during evaluation.
We will usually produce a report within a week of the workshop site visit.
The compliance audit identifies areas that need to be addressed prior to evaluation. This phase provides developers with the support that they need to implement the FIPS 140 requirements.
This can be quite difficult for developers going through the FIPS 140 process for the first time and the support process shortens the timescale needed to address the FIPS 140 requirements.
In order to be accepted into evaluation by a test lab, you need to submit to the lab a complete set of documentation that details how your product meets each and every relevant requirement of the FIPS 140 criteria.
We start by producing the Cryptographic Module Security Policy, the key document that is posted on the CMVP website on successful completion of the evaluation. This is a public document and tells prospective customers how your product provides its FIPS 140 security functionality.
We also produce a "Vendor Evidence" pack, that explicitly addresses each derived test requirement (DTR) assertion and provides the lab with easy to follow and verifiable evidence of compliance.
A Finite State Model document is also a requirement and we tend to provide this as a separately controlled component within the Vendor Evidence.
At higher levels extra evidence is necessary. At level 2, for instance, a Functional Specification must also be provided.
Once the documentation is delivered to the test lab, the evaluation can begin. The lab evaluation falls into five phases: documentation review, algorithm validation, source code review, physical testing and report writing and submission. We provide technical support to the lab, providing their technical point of contact and shielding our customers from interruptions. We will also handle the algorithm validation and host the source code review and support and witness the physical testing where appropriate.