Vulnerabilities, the Achilles heel of digital transformation

Although several IT teams around the world were involved, the disclosure of the Apache Log4j vulnerability a few days ago remained widely unnoticed by managers and the public. This vulnerability comes from a security flaw in a software component that is commonly used by developers. The criticality of this vulnerability lies in the wide use of this component as well as in the easiness of its exploitation to execute cyber-attacks. It has resulted in the preventative shutdown of applications, the urgent deployment of additional protection measures and patch implementation.

Beyond this specific case, the year 2021 has witnessed the official publication of more than 18,000 vulnerabilities, which to put into context is three times more than five years ago, and even ten times more than twenty years ago. This figure is also largely underestimated because it only considers "industrialized" software, i.e., about half of the world's software inventory, the rest being made up of specific "customized" software that is less carefully examined by vulnerability researchers.

Even as we entrust more and more of our lives to the digital sphere, vulnerabilities, and the resulting stream of cyber-attacks, have become the Achilles heel of this digital transformation. A strong response from the digital ecosystem is required or else the trust placed in it will be compromised and its future jeopardized.

How did we get here, how can we explain this prevalent weakness?

Firstly, it is the general quality of production, especially of software, that is responsible. Further, the complexity of applications, most often made up of different components, some of which are free (open source) coupled with the competitive pressure to quickly release them on the market as well as the lack of training for developers and absence of development processes and controls are a prime cause. All too often development agility has been built at the expense of quality and therefore security. This crisis also demonstrates that open-source software, although stemming from a transparent approach, is not free of security flaws.

Moreover, the shared responsibility between the publisher and the end-user is too unbalanced to improve the situation. In fact, although the publication of the patch is the responsibility of the publisher, the damage caused by the attacks exploiting this vulnerability and the temporary additional protection measures, as well as the patch implementation work, which can be complex because it can cause regressions and failures, remains the responsibility of the customer.

Finally, this situation is fuelled by the growth of a business, official or more obscure, of vulnerability research. Some companies or groups have specialized in the discovery and reselling of vulnerabilities, either to the software publisher to strengthen its security, which is good, or to private or governmental attacker groups. A new critical vulnerability can be sold for up to several million dollars.This situation is not sustainable in the long-term, especially in view of the vast utilization of connected devices that are interfering with our lives.

While the complete remediation of vulnerabilities is desirable but remains unrealistic in the mid-term, it is crucial to work on reducing their volume and criticality.

Four gradual and complementary measures should contribute to this.

First, reinforcing security training for developers by inciting them to use more robust techniques and effective control tools.

It would also be necessary, as it is done in many other sectors, to increase the value of the most secure solutions and to obtain the agreement of companies and administrations to pay for them, by involving the top management in these choices. The major economic and governmental players have a responsibility to be exemplary in this matter.

Finally, as a last resort, the regulatory enforcement of a software development certification and standardization process should be considered, especially for the future European NIS2 directive. Even if this type of approach is difficult and has certain limits (cost, time, version tracking, etc.), it should be able to generate a positive trend to build a consistent security chain: providing commitments and demanding guarantees.

These measures cannot be initiated and carried out exclusively by the private sector, nor can they be limited to a single country, otherwise they could become the target of a competitive bias. With the RGPD, Europe has opened the path, a similar approach about vulnerabilities would certainly find its place in the agenda of the future French presidency of the EU.

The article was published on EurAsia Prospective.

Read the original article

Incident Response Hotline

Facing cyber incidents right now?

Contact our 24/7/365 world wide service incident response hotline.