Repenser les logiciels dans la hiérarchie organisationnelle

Une version de cet article a été publiée dans Lecture sombre. Il a été mis à jour et diffusé ici.

‍

Tout le monde, à un moment ou à un autre de sa carrière, a probablement vu l'un de ces rapports opérationnels ou de ces organigrammes hiérarchiques qui définissent qui relève de qui dans une organisation. Parfois, on l'appelait simplement organigramme, c'est un outil utile qui permet aux gens de savoir qui travaille pour eux et qui sont leurs supérieurs. Par exemple, dans un organigramme classique, le responsable d'un groupe de codage peut rendre compte au directeur du développement des produits, qui relève à son tour du vice-président de l'innovation. Ensuite, les lignes hiérarchiques se poursuivent de haut en bas de la structure de l'entreprise. Qui n'a jamais jeté un coup d'œil à l'un de ces tableaux pour essayer de trouver son petit quartier personnel niché quelque part ?

Il n'est pas étonnant que les humains soient si fascinés par la hiérarchie et la structure. C'est ce qui nous a permis de vivre en tant qu'espèce pendant si longtemps, même dans les temps anciens, lorsque nous faisions face à un monde très dangereux. Nous n'avons jamais été les créatures les plus fortes ni les plus rapides, mais nous avons bien travaillé en équipe, chacun connaissant sa place et sa responsabilité dans le maintien de la vie et de la prospérité de notre famille, de notre tribu ou de notre groupe. L'organigramme moderne est en fait une extension de cette époque et de cet ancien succès.

Mais il y a une chose que presque tous les organigrammes ont en commun, quelle que soit la taille de l'entreprise ou d'autres facteurs. Dans la plupart des cas, tous les éléments constitutifs de ces graphiques représentent des humains ou des groupes d'humains. Nous n'en sommes pas encore au point où les machines sont capables de superviser les humains. Pour l'instant, les organigrammes sont une affaire exclusivement humaine. Mais notre logiciel a-t-il également besoin d'une hiérarchie organisationnelle ?

Bien entendu, je ne suggère pas que nous ajoutions un logiciel à l'organigramme de notre entreprise. Personne ne veut avoir une application pour un patron. Comment leur demanderiez-vous une augmentation ? Mais le paysage de menaces auquel nos applications et programmes sont confrontés aujourd'hui n'est pas sans rappeler l'environnement dangereux auquel nos anciens parents humains étaient confrontés il y a longtemps. En aidant à définir les responsabilités de nos applications et logiciels au sein d'une hiérarchie stricte, et en appliquant ces politiques avec le moins de privilèges possible, nous pouvons nous assurer que nos applications et logiciels survivent et prospèrent malgré le paysage de menaces extrêmement difficile qui les menace.

Les attaques contre les applications et les logiciels atteignent un niveau record

Pour comprendre la nécessité de créer de meilleures hiérarchies organisationnelles pour les logiciels, il est important de comprendre d'abord le paysage des menaces. De nos jours, les attaquants, ainsi que les robots et les logiciels automatisés qui fonctionnent pour eux, recherchent en permanence toute faille dans les défenses à exploiter. Et alors que le phishing et d'autres attaques contre des humains sont toujours en cours, les pirates informatiques les plus doués ont concentré la majeure partie de leurs efforts sur les attaques logicielles.

Et alors que tous les logiciels sont ciblés, les attaques les plus efficaces visent les interfaces de programmation d'applications, ou API. Ces API modestes sont de minuscules logiciels utilisés par les développeurs pour effectuer diverses tâches petites mais importantes pour leurs applications et programmes. Ils sont souvent flexibles et uniques, et parfois même créés à la volée selon les besoins du processus de développement.

Les API sont certes flexibles, mais elles le sont aussi souvent manière trop autorisée pour leurs fonctions. Les développeurs ont tendance à leur accorder de nombreuses autorisations afin qu'ils puissent, par exemple, continuer à fonctionner même si le programme qu'ils aident à gérer continue de se développer et de changer. Mais cela signifie que si un attaquant les compromet, il obtient bien plus que les droits d'accès, par exemple, à une partie d'une base de données spécifique. Ils peuvent même obtenir des droits proches de ceux d'administrateur sur l'ensemble d'un réseau.

Il n'est donc pas étonnant que plusieurs sociétés de recherche en sécurité affirment que l'écrasante majorité des attaques par vol d'informations d'identification visent aujourd'hui des logiciels tels que des API. Akamai estime ce chiffre à 75 % du total, tandis que Gartner affirme également que vulnérabilités impliquant des API sont devenus le vecteur d'attaque le plus fréquent. Et le dernier rapport de Salt Labs fait état d'attaques contre les API en hausse de près de 700 % par rapport à l'année dernière.

Création d'un organigramme pour un logiciel

L'un des moyens utilisés par les entreprises pour lutter contre les menaces liées au vol d'informations d'identification consiste à appliquer le principe du moindre privilège, voire la confiance zéro, au sein de leurs réseaux. Cela limite les utilisateurs à recevoir des autorisations à peine suffisantes pour accomplir leur travail ou leurs tâches. Cet accès est souvent encore plus restreint par des facteurs tels que l'heure et le lieu. Ainsi, même si une attaque visant à voler des informations d'identification est couronnée de succès, elle ne sera d'aucune utilité pour l'attaquant puisqu'il ne sera autorisé à exécuter que des fonctions limitées pendant une courte période.

Le moindre privilège est une bonne défense, mais il n'est normalement appliqué qu'aux utilisateurs humains. Nous avons tendance à oublier que les API possèdent également des privilèges élevés et ne sont souvent pas aussi réglementées. C'est l'une des raisons pour lesquelles contrôle d'accès cassé est désormais l'ennemi public numéro un selon l'Open Web Application Security Project (OWASP), qui suit les modèles de cyberattaques.

Il est facile de dire que la solution à ce problème critique consiste simplement à appliquer le moindre privilège aux logiciels. Mais c'est beaucoup plus difficile à mettre en œuvre. Tout d'abord, les développeurs doivent être sensibilisés aux dangers. Ensuite, à l'avenir, les API et autres logiciels devraient soit être officiellement placés, soit au moins envisagés, dans le cadre d'un organigramme au sein du réseau informatique où ils seront installés. Par exemple, si une API est censée récupérer les données de vol en temps réel dans le cadre d'une application de réservation, il n'y a aucune raison pour qu'elle puisse également se connecter aux systèmes de paie ou de finances. Sur l'organigramme du logiciel, il n'y aurait aucune ligne directe ou même pointillée reliant ces systèmes.

Il n'est probablement pas réaliste pour les développeurs de créer un organigramme montrant les milliers, voire les millions d'API qui fonctionnent dans leur organisation. Mais le fait d'être conscient du danger qu'ils représentent et de limiter leurs autorisations à ce dont ils ont besoin pour faire leur travail contribuera dans une large mesure à mettre fin aux attaques de vol d'informations d'identification endémiques auxquelles tout le monde est confronté ces derniers temps. Cela commence par la prise de conscience et se termine par le traitement des API et des logiciels avec la même attention que les utilisateurs humains.
‍

Voulez-vous améliorer votre équipe de développement ? Gérez les problèmes de sécurité des API et bien plus encore grâce à notre plateforme d'apprentissage agile et des outils de sécurité conçus pour les développeurs.