This month we celebrate 20 years of Riscure, and, as it happens, device security evaluation and certification emerged during that period. Whereas regulation is still limited to the most sensitive products, we also see a trend towards more semi-formal and voluntary certification for more products. At Riscure, we played along and evaluated numerous products, making sure they met the expected security criteria. More importantly, we are working together with the market to ensure the security norms continue evolving together with the latest technology developments and growing security needs of the final product users.
Security certification aims to provide assurance (trust), where requirements define a clear threshold. The benefit of a well-functioning security certification scheme is that the actual attack resistance of a product becomes predictable. With many businesses and consumers being generally unable to judge security threats themselves, it is a relief to have a trusted system in place. Large-scale enforcement reduces incidents and protects society. Payment cards show a great example, where the migration from strip to chip under a rigid certification scheme resulted in a sharp drop in fraud.
However, there are also various pitfalls where certification may lose some value or even provide a false sense of security. The five tips below are based on our certification experience. They could as well apply to any development where security is prioritized:
1. Balance security priorities
Certification criteria set a threshold, drawing attention to the hardest aspects of security. Any script kiddy can tell you that it is the low-hanging fruit that counts. Why gear up a sophisticated exploitation chain if guessing a simple password is all it takes? It happens that labs have successfully verified mitigation of complex attacks, while basic implementation flaws left the door wide open to entry-level attackers. Evaluators should be encouraged to prioritize simple attacks in line with the evolving threat surface and work towards the more complex ones.
2. Take into account the impact
Evaluation labs, or the certification standards, may not fully understand or capture the application or a business case. Some certification schemes are even asset agnostic, forcing evaluators to only judge the difficulty of an attack. As a result, the impact of an attack is often ignored. This is problematic since actual attackers would almost exclusively follow attack paths that lead to an economic advantage. Certification gets more value when it does weigh impact, thus preventing real-life fraud.
3. Take into account attack evolution
Product certificates are valid for a period after passing a successful evaluation. The products themselves and the attack landscape have a tendency to evolve in the meantime. Sometimes, highly complex attacks become mundane after someone takes the effort of automating or open-sourcing the recipe. Best-practice evaluators follow the progress in the scientific and hacking communities, perform their own research, and predict attack evolution for the duration of a certificate. Moreover, security-minded vendors ensure that product development is closely coupled with the security evaluation efforts to ensure product updates do not have a negative impact on the overall product security.
4. Avoid a race to the bottom
From a (shortsighted) financial perspective, there is a benefit for both the product developer and the evaluation lab to minimize evaluation work and reduce certification to rubber-stamping. The evaluator would get paid for minimal effort, while the developer would not be bothered with unwelcome security findings. Eventually, this leads to the value of a certification scheme being undermined and gradually lose value until it is abandoned. In the short term, this approach is significantly hampering the scaling of the products certification outreach most developers are aiming for. It also often proves to be detrimental to the product developer as it brings expensive recalls or significant loss of reputation. Mature certification schemes use unambiguous requirements and a well-controlled quality system, ensuring the quality level of the certificates.
5. Foster an environment of collaboration and trust
It is in the nature of certification schemes to position product developers and evaluators as opponents. The developers are happy if the product passes, whereas the evaluators pride themselves when they find vulnerabilities. However, zooming out, it is in the interest of all that new products reach the market with the best possible security. Successful evaluators collaborate with a developer to detect issues early and provide advice on mitigation direction. Successful developers work with an evaluator, following up creatively to implement solutions that pass certification.
Over time we came across all these issues and developed our strengths in dealing with them. We learned that the considerate application of certification drives security forward. We continuously witness that Riscure evaluators’ feedback leads to immediate improvements in the product’s security and/or accompanying documentation. More importantly, it serves as a direct input in the subsequent product development activities, eventually reducing certification and mitigation pain significantly for everyone involved.
Long-term proactive collaborations, in which security evaluations are closely connected with early stages of the product development, lead to surges of security improvements for the final product users and more optimal product certificates outreach at a much lower overall cost for the developers.
Contributed by Marc Witteman, Geert van Kuyck, Mafalda Monteiro Oliveira Cortez, Anna Kolesnichenko, and Nikola Medic, Team Riscure. If you have any questions, contact us at inforequest@riscure.com.