Modern security product certification best practices
IT security product manufacturers are required to achieve government mandated, standards-based certifications to get their product in market. One of the most common, aptly called Common Criteria (CC), was introduced more than two decades ago to help standardize the evaluation criteria used to validate a product’s conformance against a variety of functional security requirements.
Its goal is to ensure that a certified product meets the rigorous level of conformance required by the internationally adopted CC standard – thereby providing end users with assurance about the product’s security posture prior to deployment.
Achieving certifications against standards like Common Criteria, or its related cryptographic validation standard FIPS 140-2, are industry and government procurement table stakes. A product’s CC and/or FIPS 140-2 validation certificate helps to demonstrate assurance, trust and denotes conformance to a rigorous evaluation process. Without these independent, third-party certifications, product vendors are limited in their ability to sell into government agencies or other regulated industries.
When it comes to cybersecurity product development, the industry is agile by design, but security product certification methods haven’t kept pace with modern development methods and release cycles. As many developers or product managers will attest, trying to integrate legacy certification processes on top of modern development on your own is complex, expensive and often frustrating.
To complicate matters, standards-based certification programs are expanding in scope and prevalence. This means the DevOps toolchain has drastically changed the speed at which teams can bring product to market thanks to process automation. But nothing will slow a fully automated pipeline down faster than legacy, manual product certification. Why are these processes so out of sync?
At best, the intricate testing and evaluation process usually takes months to achieve certification with a product that is ready to certify. At worst, it can lead a product back to the drawing board for fixes if problems are identified through the evaluation – thereby delaying time to market. The process is time consuming and costly for development teams implementing fixes against the prescriptive requirements. This is also one of the few remaining non-automated test processes within the development environment and whether you’re managing it internally or outsourcing to a lab, the entire process is typically managed in a very manual way.
For years, security was often a last consideration in product development, but today manufacturers and regulators recognize the importance of security at design – and that security by design must include preparing for certification during design and development. Standards-based testing will benefit by a modern approach; new automation capabilities and certification process innovation means continuous iterative testing will help teams certify at the speed of development.
Here are five steps product managers and developers can take to manage the security product certification process a little more smoothly.
1. Fully vet an accredited lab partner to help you manage the test process
Ask your lab before contracting if you (as the vendor), need to develop any test harnesses or use your own resources do any of the testing and show the results. With few exceptions, your lab should be able to do close to 100% of the Protection Profile testing with their processes and tools. Set expectations in advance on your team’s required level of involvement to avoid surprises.
2. Confirm how much pricing contingency the lab is building into their model for testing
Historically, labs did not know how many rounds of testing they would need to do, because the testing was done at the end of an evaluation project with little advance insight into possible issues. This resulted in labs building in a significant risk premium. If you, as a vendor, undertake an automated Functional Gap Assessment approach to ensure product readiness before formal testing, you can confidently enter into a contract with a lab that only includes one full pass of testing. Don’t pay for unnecessary testing cycles.
3. Ask your lab how they do their gap analysis
If it’s a paper-based exercise or checklist, be aware that the process will likely miss granular details that may end up costing re-development cycles and slow your time to market. A lab that relies solely on a paper-based gap analysis may only uncover additional problems during the official testing phase, at which point you are forced to remediate the problem. The best way to determine gaps is to execute actual test cases using customized tools against the target early and often to dramatically reduce re-development risk.
4. Confirm with your lab how long the entire process takes before signing the contract
Be wary of broad or loose time frames. Armed with the results of a Functional Gap Assessment, the lab should be able to confidently commit to testing and finalization duration. There are some caveats around specific CC-scheme policies, such as the US scheme requiring last minute technical interpretations or requirements to be applicable right up until submission. A standard NDcPP formal evaluation can be completed in 60 days or less if the lab has the FGA results as inputs and is able to be “one and done” with formal testing. Don’t agree to an extended multi-month process without understanding why it will take so long and slow your time to market.
5. Check with your lab on the ownership of the project deliverables
Be wary of labs that don’t provide the consulting or documentation deliverables as works for hire. You have paid for the work and should have ownership of the documents for future use with that lab or another of your choosing.
At the end of the day, product managers and developers are equally responsible for driving better security assurance outcomes and the move to a modernized approach will yield greater results. Common Criteria can and should be a key tool in the toolbox to get us there.