Le 13 septembre 2018

« Est-ce que je me lève aujourd'hui ? », « Est-ce que je vais acheter des sushis dans une station-service le long de l'autoroute ? » ou bien « Pouvez-vous tenir mon verre pendant un moment ? » : tout ce que nous faisons comporte un certain risque. Cela vaut également pour le secteur informatique. Christopher Robinson, Product Security Program Manager chez Red Hat, explique comment faire face aux risques informatiques et comment prendre des décisions éclairées basées sur les données.
Dans le monde de la sécurité des informations, certains outils peuvent nous aider à prendre des décisions éclairées. Lorsque nous examinons les risques potentiels, nous réfléchissons aux problèmes qui pourraient survenir et auraient donc un impact sur nos activités professionnelles. Avant toute chose, nous devons comprendre ce qui peut arriver en examinant les conséquences d'un danger potentiel. Par exemple, si je n'ai pas de glaçons par une chaude journée d'été, ma boisson ne restera pas fraîche. Mais le manque de glaçons n'est pas le seul risque en plein soleil. Ai-je de la crème solaire ou un chapeau ? Et s'il pleut ? Il est bon de consigner (registre des risques) ces problèmes (risques) et leurs conséquences négatives potentielles (impact).

Une fois que tous les risques possibles ont été identifiés, vous remarquez que certains sont pires que d'autres. Par exemple, un coup de soleil est plus nocif qu'un manque de glaçons. Certains problèmes sont mesurables (quantifiables), tandis que d'autres sont davantage liés à votre perception (qualifiables). Chacune des approches est valable, selon les données et les décisions que vous voulez prendre. Mais il faut s'assurer que le même référentiel soit utilisé pour que l'analyse soit cohérente.
Si vous voulez savoir à quel point certaines choses sont graves, abordez-les dans les trois dimensions suivantes :

- Confidentiel : ce problème permet-il à quelqu'un de voir quelque chose qui ne devrait pas être vu ?
- Disponibilité : ce problème signifie-t-il que les données ne sont pas accessibles à ceux qui devraient pouvoir y accéder ?
- Intégrité : ce problème entraîne-t-il une modification des données d'une manière qui ne devrait pas l'être ?

Un autre facteur à considérer est la probabilité que le problème survienne réellement. Par exemple, la probabilité que vous rencontriez un requin en nageant dans la mer du Nord est assez faible. Ces questions peuvent également être consignées dans le registre des risques.

Un registre des risques complété, avec la probabilité et l'impact d'avoir ou non des glaçons, d'avoir un coup de soleil et de rencontrer un requin.
Je prends un autre animal pour mieux illustrer le danger et la vulnérabilité, ainsi que leur impact. Supposons qu'un ours brun trouve votre terrain de camping (danger) et mange votre sandwich (risque) après avoir fait un trou dans la clôture autour de votre tente (vulnérabilité).
Risque = danger x vulnérabilité

Nous en arrivons maintenant au point où la science et les mathématiques vous aident à décider, notamment en ce qui concerne l’espérance de perte unique (SLE – single loss expectancy) : quel est le coût si cela ne se produit qu’une fois ?

Retour à notre ours affamé. Nous avons un sandwich de moins, ce qui n’est pas fort grave. Mais quid si ça arrive tous les jours ? Ensuite, vous examinez le risque en termes de « taux d'occurrence annuel » (ARO – annualized rate of occurrence). Quotidiennement, la probabilité est élevée (100 %). Avec ces deux données, nous pouvons calculer l'espérance de perte annuelle (ALE – annual loss expectancy).

ALE = SLE x ARO

Dans notre exemple, il s'agit d'un sandwich (éventuellement complété par une bombe lacrymogène contre les ours et une nouvelle clôture) multiplié par 365 jours. On se retrouve aussitôt avec une montagne de sandwichs à préparer.

Il est donc préférable d'investir dans des moyens de dissuasion : une bombe lacrymogène, une clôture solide et des huches à pain pour y ranger les sandwichs. Cela vous coûte, à vue de nez, plusieurs dizaines d'euros par an. Il est alors temps de faire une évaluation, pour que nous investissions le bon montant par rapport au rendement.
COÛT_des_mesures = ALE_DÉPART – ALE_ACTUEL

Idéalement, vous ne devriez pas dépenser plus d'argent qu’il n’est nécessaire selon vous (la sécurité et la conformité sont bien sûr hors de prix). Il est donc possible qu'il soit moins coûteux d'arrêter votre activité (risquée).

Il existe différentes techniques pour consigner tous les risques potentiels et quatre stratégies sont possibles :

1. Vous pouvez essayer de résoudre le problème, mais cela peut être coûteux (une clôture électrique que les ours ne peuvent pas passer).
2. Vous pouvez minimiser le problème (réparer le trou dans la clôture pour que l'ours doive faire plus d'efforts pour passer).
3. Vous pouvez refiler le problème à quelqu'un d'autre (échange d’emplacement sur le terrain de camping).
4. Vous pouvez accepter le problème et apprendre à vivre avec le risque (devenez ami avec l’ours).

Il est impossible d'éliminer tous les risques. Même si vous essayez, il peut y avoir d'autres facteurs que vous ne connaissez pas encore. Ou bien vous n'avez pas assez de budget/temps pour résoudre complètement le problème.

En pratique

Des ours et des glaçons, tout cela semble simple. Mais qu’en est-il de votre entreprise ? Avec Red Hat Product Security, vous disposez de données claires et factuelles. De cette façon, vous connaissez la taille des ours, la vitesse de nage des requins et la température extérieure. Vous savez de quelle quantité de glaçons vous avez besoin pour que votre boisson reste fraîche, par exemple. Red Hat vous aide à identifier les vulnérabilités et vous donne des options pour y remédier. Mais à la fin, c'est vous qui savez quel type de sandwich vous plaît. Votre voisin le préfèrera peut-être avec plus de mayonnaise, tandis que vous optez pour la variante light.
Dès que tous les embargos auront été levés, Red Hat rendra publiques ses données et statistiques de sécurité. Chaque vulnérabilité est clairement identifiée grâce à des outils et mesures standardisés, tels que Common Vulnerabilities and Exposures (CVE), Common Weakness Enumeration (CWE) et Common Vulnerability Scoring System (CVSS). Nous publierons ces données dans des formats lisibles par l'homme comme par la machine : Open Vulnerability and Assesment Language (OVAL) et Common Vulnerability Reporting Framework (CVRF).

Nous d̩crivons un probl̬me et ̩valuons sa gravit̩ en ajoutant un score d'impact suppl̩mentaire Рpar exemple un score CVSS. Chaque erreur est consid̩r̩e du point de vue de nos produits sur base des composants et de la fa̤on dont ces packages sont utilis̩s et configur̩s. Nous savons quand une erreur est minime, mais aussi quand elle prend des formes gigantesques et g̢che votre journ̩e. En outre, le programme interne Customer Security Awareness fournit des donn̩es, un contexte et des outils suppl̩mentaires permettant aux entreprises de prendre des d̩cisions et de r̩agir rapidement. Si l'ours revient ou si vous n'avez plus de gla̤ons, vous saurez que faire.
Christopher Robinson est Product Security Program Manager chez Red Hat, le premier fournisseur mondial de solutions logicielles open source.