Une partie importante du décret émis par l'administration Biden sur la cybersécurité exige que le National Institute of Standards and Technology (NIST) définisse ce qui constitue un « logiciel critique ». Cette mission centrale s’inscrit dans un effort plus large de sécurisation de la supply chain en logiciels. La semaine dernière, le NIST a publié une liste préliminaire de catégories de logiciels entrant dans le cadre de cette définition.

Le texte présidentiel indique que la définition du NIST « doit refléter le niveau de privilège ou d'accès requis pour fonctionner, l'intégration et les dépendances avec d'autres logiciels, l'accès direct aux ressources de réseau et de calcul, l'exécution d'une fonction critique pour la confiance et le potentiel de préjudice en cas de compromission ». L'objectif de cette définition est de guider plusieurs autres actions requises par le décret et de changer la manière dont le gouvernement fédéral achète et gère les logiciels critiques qu’il déploie. En fixant une cadre réglementaire, l’Etat fédéral met dans la balance son poids financier comme levier d’influence sur le secteur privé, car la plupart des grands fournisseurs de logiciels vendent à la fois aux secteurs public et privé et trouveraient plus efficace de créer un seul produit sécurisé pour les deux secteurs.

Caractéristiques des logiciels critiques

Après avoir consulté d'autres agences gouvernementales, sollicité des documents de synthèse de la communauté logicielle et organisé un atelier virtuel pour élaborer la définition, le NIST a établi « qu’un logiciel critique conforme à l’ordonnance présidentielle est défini comme tout logiciel qui a, ou qui a des dépendances logicielles directes, avec un ou plusieurs composants ayant au moins l'une des caractéristiques suivantes :

- Il est conçu pour fonctionner avec des privilèges élevés ou pour gérer des privilèges.

- Il dispose d'un accès direct ou privilégié aux ressources réseau ou informatiques.

- Il est conçu pour contrôler l'accès aux données ou aux technologies opérationnelles.

- Il exécute une fonction critique pour la confiance.

- Il fonctionne en dehors des limites normales de confiance avec un accès privilégié.

 

Le National Institute of Standards and Technology a déclaré que la définition s'applique à toutes les formes de logiciels, « y compris les logiciels autonomes, les logiciels intégrés de dispositifs spécifiques ou de composants matériels, et les logiciels basés sur le cloud achetés ou déployés dans des systèmes de production et utilisés à des fins opérationnelles ».

Les phases ultérieures de la mise en œuvre du texte réglementaire peuvent également inclure d'autres catégories de logiciels, notamment :

- Les logiciels qui contrôlent l'accès aux données.

- Les logiciels basés sur le cloud et les logiciels hybrides.

- Les outils de développement logiciel comme les systèmes de dépôt de code, les outils de développement, les logiciels de test, d'intégration et de déploiement.

- Les composants logiciels des microprogrammes de démarrage.

- Les composants logiciels des systèmes industriels (OT).

Catégories de logiciels critiques

Le NIST a produit un tableau qui précise les catégories spécifiques de logiciels utilisés pour les fonctions de sécurité, comme celles qui concernent le contrôle du réseau, la sécurité des points d'accès et la protection du réseau. Les catégories préliminaires de logiciels critiques figurant dans le tableau sont les suivantes :

- Gestion des identités, des justificatifs et des accès (Identity, Credential, and Access Management, ICAM).

- Systèmes d'exploitation, hyperviseurs, environnements de conteneurs.

- Navigateurs web.

- Sécurité des points d'extrémité.

- Contrôle du réseau.

- Protection des réseaux.

- Surveillance et configuration des réseaux.

- Surveillance et analyse opérationnelles.

- Analyse à distance.

- Accès à distance et gestion de la configuration.

- Sauvegarde/récupération et stockage à distance.

« Il n'y a absolument rien de nouveau dans tout cela », a déclaré Chris Wysopal, vétéran de la sécurité logicielle, cofondateur et directeur technique de Veracode, une entreprise de sécurité des applications basée à Burlington, Massachusetts. « Cela fait des décennies que certains parlent de ce genre de concept », a-t-il ajouté. Ce dernier reconnait néanmoins, « que cette définition crée une ligne de démarcation claire » et il trouve formidable que l’on exige des caractéristiques spécifiques « pour ces logiciels critiques afin de s'assurer qu'ils ne présentent pas de risques excessifs pour la sécurité nationale ». Comme le précise le NIST lui-même, c’est le piratage du logiciel de gestion de réseau SolarWinds par les services de renseignement russes qui a motivé l'élaboration de cette base de sécurité pour les logiciels critiques, affirmant que les incidents récents démontrent la nécessité pour le gouvernement fédéral d'améliorer sa défense contre les cyberactions malveillantes. Le NIST insiste également sur le fait que « les acteurs de la menace exploitent l’utilisation omniprésente des logiciels et la complexité du code sous-jacent et des pratiques de développement et de distribution des logiciels ».

Un point de départ solide

« Nous ne pouvons tout simplement pas continuer à laisser faire », a déclaré Chris Wysopal. « Nous ne pouvons pas nous contenter d'attendre que le prochain SolarWinds se produise, même si c’est dans six mois, un an ou plus ». Il pense que le NIST a fait un excellent travail en définissant les bases nécessaires pour établir les paramètres préliminaires auxquels devront répondre les logiciels critiques. « Si l’on regarde les différents logiciels proposés par le NIST, tous jouent, à l’instar de Solarwinds, un rôle privilégié dans le réseau et l'identité, sauf qu’il s'agit d'une catégorie de logiciels tout à fait différents », a-t-il ajouté. « Je pense qu'ils l'ont suffisamment élargi ».

Malgré la nature exhaustive de sa définition, le NIST n'a pas inclus certains logiciels qui peuvent servir de vecteur d'attaque. « On pourrait dire que, même le logiciel le moins privilégié du réseau pourrait éventuellement finir par compromettre les données les plus sensibles si l’on prend en compte les mouvements latéraux et d'escalade de privilèges et l'enchaînement des vulnérabilités », a encore déclaré M. Wysopal. Mais il ajoute qu'il faut bien commencer quelque part et qu'avec le temps, « le NIST devrait inclure aussi les logiciels à moindre risque ». Ce n'est que lorsque le gouvernement et l'industrie de la sécurité parviendront à gérer les logiciels critiques à haut risque que les définitions des logiciels pourront être élargies. « C'est une manière de commencer, et j’espère que l’on ne s’en tiendra pas là. Il faudra plusieurs années pour que cela fonctionne avant d’envisager une quelconque expansion », a encore déclaré M. Wysopal.

Prochaines étapes

Le NIST a déclaré que la Cybersecurity and Infrastructure Security Agency (CISA) et l'Office of Management and Budget (OMB) « surveilleront la mise en œuvre du programme dans la phase initiale et décideront à quel moment il faudra inclure d’autres catégories de logiciels ».

Dans l'intervalle, les directives à court terme du décret suivantes découleront de la définition préliminaire des logiciels critiques du NIST :

- Vers le 12 juillet, l'OMB et la CISA publieront des directives décrivant les mesures de sécurité pour les logiciels critiques.

- Vers le 25 juillet, le département américain de la Sécurité intérieure (DHS), par le biais de la CISA, « identifiera et mettra à la disposition des agences une liste de catégories de logiciels et de produits logiciels utilisés ou en cours d'acquisition répondant à la définition de logiciel critique ».

- Vers le 24 août, le directeur de l'OMB, agissant par l'intermédiaire de l'administrateur de l'Office of Electronic Government au sein de l'OMB, prendra les mesures appropriées pour exiger que les agences se conforment aux orientations décrivant les mesures de sécurité des logiciels critiques.

À long terme, les mesures prévues par le décret sur la sécurité des logiciels devraient rendre les attaques supply chain « beaucoup, beaucoup, beaucoup plus difficiles parce qu'à l'heure actuelle, rien n’empêche ces attaques de se produire », a déclaré Chris Wysopal. « Le gouvernement n'examine aucun de ses logiciels critiques sous cet angle ». En outre, le renforcement de la sécurité des logiciels critiques par le biais du processus d'acquisition fédéral pourrait renforcer la sécurité des logiciels en réduisant la nécessité de corriger les produits logiciels aussi fréquemment. « L'application d'exigences sur ce type de logiciel obligera le fournisseur à effectuer davantage de tests de sécurité, et l’on peut supposer qu’un plus grand nombre de vulnérabilités seront débusquées au cours du processus de développement et non pas découvertes après coup », a ajouté M. Wysopal. « Cette attention supplémentaire au processus de développement aura un impact sur la qualité du code et le logiciel sera effectivement plus sûr ».