Anastasiya Kazakova, Senior Public Affairs Manager, Kaspersky
Igor Kumagin, Cybersecurity expert, Kaspersky
Vladimir Radunović, Director, E-diplomacy and Cybersecurity Programmes, DiploFoundation
Poorly designed and secured software products can pose a security risk to users. Vulnerability in software can be exploited by threat actors, leading to theft of users’ personal data or financial information. Vulnerabilities in consumer software usually remain unknown for a long time unless they become evident in a particular context or usage case. This makes it difficult for consumers to timely identify and properly manage vulnerabilities. “While consumers can test the brakes on a bike before going for a ride, vulnerabilities in products and the consequences of their exploitation […] are more difficult to perceive”. End-users rarely know what’s sold to them in a software “black box”: its source code or code components cannot be checked since most consumers don’t have the technical expertise.
So, how can consumers distinguish a more secure product from a less secure one?
Labels are one option to address this information asymmetry on the market. Often, those who sell software have disproportionately more information about the security and reliability of software than consumers. This situation bears risks for both sides – those who produce and sell software and those who purchase it – since poorly secured software in supply chains can impact many users, even leading to safety risks that boomerang back to suppliers.
Introducing voluntary labelling of products’ security is one of the regulatory practices these days aimed at helping consumers make informed purchasing decisions and, thus, driving demand for secure products. Labels can help put security into products’ features; this has been discussed in the Geneva Dialogue by governments, industry and standardization bodies. Labels are also being discussed by the OECD as an option to increase transparency and consumer awareness, and have already been implemented in some countries for consumer IoT products. In the U.S., we may see similar trends where a President’s Executive Order has already prescribed steps on IoT consumer product labeling programs.
While there are certain traps of labelling schemes, overall, labels will likely continue to develop and address risks in consumer IoT or smart devices. But can labels potentially be just as effective for consumer software products? Unfortunately, the answer to this is ‘not so simply’.
Why ‘not so simply’?
Consumers often make their purchasing choices based on reviews. So, to ensure that a label serves as a useful tool and indeed helps raise consumer awareness, it needs to rely on product ratings based on universally-applied industry criteria. For instance, in the cybersecurity industry, independent testing organizations such as AV-TEST or AV-Comparatives conduct regular security evaluations and publicly provide the results to help consumers make informed choices before purchasing cybersecurity solutions. These organizations also apply a common methodology in security evaluations, so all products are compared using a single approach.
Testing results: An example from AV-Comparatives ‘Advanced Threat Protection Test 2021’ test of consumer security software https://www.av-comparatives.org/tests/advanced-threat-protection-test-2021-consumer/.
Imagine: AV-Comparatives.
Example evaluation: AV-Test's evaluation of mobile security products for Android, November 2021 https://www.av-test.org/en/antivirus/mobile-devices/android/november-2021/.
Image: AV-Test.
Furthermore, unlike consumer IoT devices, modern software products rely more on multiple components – including those of third parties and open-source libraries. Such a complex architecture of consumer software products represents an increased attack surface for threat actors and, making them potentially more vulnerable. That’s why software manufacturers should continuously implement cyber-risk monitoring, including third-party risk monitoring.
This multi-component nature of modern consumer software products poses a challenge to traditional labeling schemes – labels can hardly be expected to keep up with the pace of software’s lifecycle. The solution could be a properly developed set of baseline criteria so that, first and foremost, viable and critical characteristics build the foundation for security assessments for ensuring if software products are sufficiently secure or not.
In sum, could labels potentially be equally effective for consumer software products as consumer IoT or smart devices? We’d probably answer ‘yes’ when labels rely on software products’ ratings which are (i) publicly available to consumers, (ii) based on security evaluations of third-party independent organizations, and (iii) based on a universally applied set of baseline security criteria.
What could baseline security criteria include?
The U.S. NIST has proposed draft baseline criteria for consumer software cybersecurity labeling and developed four categories of attestations under which consumers can have more information about secure software development, data protection practices and more. Last December NIST opened a call for submissions and published those received from Google, Kaspersky, Microsoft, and others. We recommend leaders and decision-makers check these criteria and follow the upcoming updates from NIST, as the criteria provides a constructive, risk-based approach. At the same time, some improvements could be considered.
First, ‘level and speed’: to be feasible and realistic, as well as serve the intended security purposes, labels need to rely on criteria of the same nature, level and with similar updating speed. Practically speaking, the criterion ‘free from known vulnerabilities’ should be updated regularly, while a criterion indicating that ‘a secure development process’ has been implemented can be updated less often and does not require the same frequency of security attestations. Otherwise, software manufacturers would be forced to update labels too often and bear additional costs.
Second, static criteria for dynamic consumer software products would hardly work, and thus would unlikely be helpful to consumers themselves. For instance, the attestation of software that is ‘free of known vulnerabilities’ might become obsolete the day after the label is issued. New information about known significant vulnerabilities appears every day, and this means that every day there is a risk of new vulnerabilities that may be significant or may affect a particular software product. Instead, a label’s focus on whether a software manufacturer implements appropriate, relevant security controls and processes would be more pragmatic and realistic.
A way forward?
Overall, labels or labeling schemes for consumer software could be a working solution to increase security in purchasing software products. And it is great to see the NIST follows some industry feedback in the finalized ‘Recommended Criteria for Cybersecurity Labeling of Consumer Software’[1] (February 2022), and particularly replaces the above-discussed criterion with: ‘Practices Secure Design and Vulnerability Remediation’ and ‘Practices Responsible Vulnerability Reporting Disclosure’.
We hope to see further developments in the industry and regulatory practices to agree on baseline criteria and mutually recognized labels to also equally ensure that software manufacturers remain incentivized to pass additional security attestations.
For now, within the Geneva Dialogue, industry partners continue to discuss necessary steps to ensure the security of digital products and reduce vulnerabilities in them. Their efforts will achieve the ultimate goal of greater security and safety for users.
[1] Quite interesting as well that the NIST adds an additional descriptive claim on ‘Secure Update Method’ and re-phrases a former one ‘Software End of Support Date’ to ‘Minimum Durations of Security Update Support’.
