It’s never too early

(Or: Why engaging your test lab early pays off.)

When we addressed industry criticism about the length of Common Criteria (CC) projects, we pointed out that atsec information security regularly starts CC evaluations while the product is still being developed. This approach reduces the overall time and cost of evaluation, shortens the time between product release and certification, and can enable the sponsor to be first on the market with a CC-certified product. The same optimized approach works for FIPS 140-2 projects.

Although they are well aware that cryptographic modules require standards-based verification before they can be sold in the Federal marketplace, many vendors wait until their product is complete or well-along in development before engaging a lab to begin the required testing. Although a sequential approach like this might seem to make sense, pursuing development and verification in parallel can save both time and money.

Here’s how an optimized approach can succeed. The vendor contacts the lab very early in the development cycle. The lab reviews the product designs for protocols, algorithms, security packaging and other relevant items before any development begins. If design choices have been made that would create issues with respect to the standard, they can be corrected before the vendor’s heavy investment in development starts. In addition, the test lab can prepare for and usually begin testing in parallel during product development. In many cases, testing can be completed almost as soon as the final product is ready. Achieving certification soon after product release maximizes the return on the vendor’s investment in testing.

Developing an on-going relationship with a test lab is advantageous and cost-effective. Most products that are tested for standards compliance also require repeat testing as the product changes and adds features over time. Repeat testing with the same lab is faster and less expensive for several reasons. First, if the changes to the product are small, the lab might only need to test the changes, not re-test the entire product. Even if the changed product needs full testing, the lab’s familiarity with the vendor’s development methods and personnel will help to optimize the validation process. Most significantly, the test team will already have a working knowledge of the product, including any special knowledge needed to finish the tests quickly. If re-testing is a regular event – often the case for major products with long lives – the lab and the vendor can work together to optimize the whole process, potentially resulting in a vastly-reduced (potentially greater than half) validation effort for each product iteration.

We would welcome a chance to talk to you about your IT security projects and discuss how we can help you streamline the validation process.