Towards "controlled and guaranteed origin" software. Will they be enough to make us safer?


President Biden orders the safety labeling of the software and the communication to the consumer of the list of ingredients of which it is composed. The aim is to certify the origin, genuineness and safety of the product. The executive order "Improving the Nation's Cybersecurity" was issued last May and in recent weeks the first technical-organizational responses from federal agencies and the academic and industrial world have begun to arrive.

Finally, it seems. 

Too many security holes, too many malevolent actors who have had an easy time over the years. In fact, from now on, it will be necessary to set up proven tracing procedures to demonstrate that the software has been created in a safe environment, according to good development and testing practices; and the origin of the source codes will have to be accounted for, confirming them with standardized artefacts. And finally, the user will no longer have to acknowledge the conditions of use, but add a safety labeling and an SBOM (Software Bill Of Materials): the bill of materials that lists the components and their origin.

In short, going to buy software will end up being very similar to when we have to buy the new washing machine, be careful to check the energy labeling to check electricity consumption or noise pollution; or similarly to when we wander through the aisles of supermarkets, intent on checking the table of the ingredients of the biscuits in search of the healthiest, most genuine, zero kilometer ones, with fewer calories and without allergens. Or again when at the restaurant we are looking for the quality bottle of wine, requesting the DOC one rather than the one marked with one Denomination of Controlled and Guaranteed Origin.

But let's go in order and try to understand what is happening. And especially if it will be really enough.

In recent months, two structural initiatives have been launched by the American government: the first, aimed at securing the software supply chain; the second, that aimed at bringing the technological environment of industrial control systems to a level of cybersecurity at least equal to that which has been achieved today in IT systems.

The software supply chain is now very developed and widely distributed, so much so that it can now be said that “anyone who makes software”. And in the concept of "anyone" there is that - related - of "indeterminate", which today constitutes the main vulnerability at the basis of most computer incidents: not only do we not know who exactly is the authorship of the software we use, to which civil, criminal and administrative liability can be traced for damage caused or for the actual exposure to dangers; but we do not even know if this someone, even when he has acted in good faith, has equipped himself with the resources, structures and operating techniques to safely develop and test the product, as well as adequate controls that prevent tampering.

And all this, if it is generally valid for all software, assumes a decisive value for the category of so-called critical software, i.e. those that perform guarantee and security functions, such as those necessary to manage and verify the privileges of system administrators. or that allow direct access to machine or network resources.

The strategy that is being put in place will therefore try to guarantee, with repeatable and verifiable processes, these three dimensions: authorship, safety and genuineness. Let's see how.

Software will begin to be expected to be created in development environments that are compartmentalized with respect to those in which they will be subsequently tested, as well as those in which they will be - when fully operational - used; and the information to the consumer must give evidence of the safety procedures used to ensure this environmental segregation. Then, it will be necessary to employ automatisms that allow both the verification of the origin and integrity of the source codes used to develop the software, and a constant search for vulnerabilities and related remedies. And this too must be acknowledged in the information to users, not failing to indicate a brief description of the risks assessed and mitigated.

It will also be necessary to keep a timely inventory of the data relating to the origin of the source codes or software components not developed in house, as well as the controls implemented and audits performed on software components, services and development tools, both internal and third parties. set off. To the extent possible, it will be mandatory to certify the integrity and provenance of open source software used within any portion of a product. Finally, it will be necessary to demonstrate that an internal control system is in place that is able to disclose in time the vulnerabilities detected in the software products.

Upon completion or completion of the actions indicated above, it will be necessary to create safety labels and bills of materials for consumers.

It is to be expected that all this will significantly improve the tracking of the origin, integrity and security of the software, but will also lead to a significant increase in implementation costs and therefore in prices to the public.

But the common man, with the digital divide that characterizes the current mass culture, accustomed as he is to downloading "cracked" software at no cost from the web, will he be willing to spend significantly different amounts to buy this kind of secure software? We need to act in parallel so that, hand in hand with the security of the software supply chain, we act to create new awareness of digital hygiene among those who will feel the need for those software.

Orazio Danilo Russo, Carlo Mauceli

To learn more: