The (Not So) Common Criteria Certification


It seems like every day now we see news about new cyber attacks, security breaches of high profile companies, and steadily rising growth of awareness of security concerns. It only makes sense then that customers of IT solution vendors should demand more in terms of security assurances around the software and products they use. We see these requirements come up on RFI/RFP type documents, but often they are not fully vetted or audited until post-deployment. We have seen more requirements creeping up as well around standards such as FedRAMP, ISO 27001, etc., but often these are focused solely on cloud-based and shared service type deployments, and are only post-deployment type certifications, which can be adhered to with bolted-on security after issue discovery. There is an inherit flaw in this type of post-deployment adherence type logic. Products should not just be customize-able to hit security targets and should not only be focused on being vulnerability-free. Products should be designed to protect against security threats, and prospecting consumers should be demanding proof of assurances before making decisions.

From the perspective of the Axway US Federal Technical Manager, as well as the current Product Owner/Manager for US Federal Vertical Solutions, I see these type of requirements come up quite often and am tasked with ensuring we can provide these assurances in a way that benefits not just the US Federal vertical, but also the rest of the company. This brings us to the Common Criteria (CC) Certification. If you aren't familiar with this certification, it is an international standard that focuses on evaluation of security attributes of Information Technology solutions. CC certification is based on a set of Protection Profiles (PP), or specifications of security requirements for a class of device or technology to which a vendor can claim their solution, or Target of Evaluation (TOE) adheres. To become certified against a PP, a TOE much undergo a rigorous evaluation and quality assurance process executed by a certified national lab to validate the claim of conformance to the PP. What makes the CC certification special or different from some of the other certifications out there? Why should a technology solution prospect care about this certification?

The CC Certification is Global.

The CC certification originated from several different standards from the UK, Canada, and US DoD. While these standards all sought similar to achieve similar goals in product assurance, the siloed approach made it difficult for IT vendors to provide a level of assurance against all of the standards. As a result, the several governments came together to develop the CC evaluation. The Common Criteria Recognition Arrangement (CCRA) was put into place, where countries around the world have joined as members (http://www.commoncriteriaportal.org/ccra/members/) who recognize the value of the standard, and work together to authorize and consume the certifications. This means that CC standards are highly vetted, and can be relyed upon to be conducted in a through, rigorous, and standardized manner, with the results providing a high level of assurance of vendor security functional and assurance requirement complaince claims.

Many Stakeholders.

27 countries have signed the CCRA, which translates into many communities of interest with investment into this certification for interntional commerce of IT products. However, Federal and Government entities are not the only ones who find value in the CC certification. Anywhere you find critical infrastructure and highly regulated industries you will find requirements to meet the security standards CC PPs push vendors to achieve. Industries and verticals such as IoT, Healthcare, Financial Services, etc. all have a stake and goals around the CC certification. As a result, the CC standard does not sit static and stagnant. As recently as 2012, a new vision statement was brough forward, with new goals being implemented in a new CCRA in 2014. An active user community identifies the security requirement profiles needed to meet assurances around shifiting paradigms to which vendors much adhere.

The CC Certification Demonstrates Commitment to Product Security.

The CC certification has an important differentiator against earlier mentioned certifications. The CC certification occurs before a product is deployed. A product cannot simply be vulnerability free and customized to pass an audit; the CC certification demands a solution be designed with built in security in mind. The certification evaluation is no small matter. The fact is that the process of specification, implementation, and evaluation of solutions can be lengthy, resource intensive, and expensive, which has caused critisim of the certification in the past. Highly variable solutions, such as many open source products, that are very dynamic with frequent changes can cause challenges with requiring recertifications against PPs as well. The value of the certification comes at a cost to vendors, in the form of resource cycles, financial budget, and requirement to balance a stoic solution that is focused on continuous dedication to reliable services, rather than constant changes to chase market trends. Achieving and maintaining CC certification of a product against one or several PPs challenges vendors to choose dedication to their consumer base, to provide them with the high level of assurances they need pre-deployment on critical and sensitive systems.

In an interconnected world, consumers must make demands around security assurances of the IT solutions they choose and use to ensure they can protect the data of their customers and themselves. The Common Criteria Certifications is a great way to ensure a product can provide these assurances. From the global community that matches enterprise/agencies international commerce and operational missions, the the insight from diverse industries with many different regulations to which they must adhere, the CC certification aligns with consumer goals and needs.

In line with my role at Axway, I want to share that the organization has made the dedication to our customers to show commitment in this space. Our API Management Suite has achieved this certification (https://www.axway.com/en/pressrelease/2017/axway-api-management-enhances-security-credentials-common-criteria-certification), as well as several other solutions in the past, with efforts under way to renew certification against updated PPs already under way.

Comments

Popular posts from this blog

Firewall, IDS, IDP, WAF, API Gateway: Choose Your Shield

API Security - The Next Generation with Elastic Beam

REST API Best Practices: HTTP Status Codes and You, Part 2(xx) - Status 200; Success!