Repenser les logiciels dans la hiérarchie organisationnelle
Une version de cet article a été publiée dans Lecture sombre. Elle a été mise à jour et publiée ici.
À un moment ou à un autre de sa carrière, chacun a probablement vu l'un de ces organigrammes opérationnels ou hiérarchiques qui définissent qui rend compte à qui au sein d'une organisation. Parfois simplement appelé organigramme, il s'agit d'un outil utile pour faire savoir aux gens qui travaillent pour eux et qui sont leurs patrons. Par exemple, dans un organigramme classique, le chef d'un groupe de codage peut rendre compte au directeur du développement des produits, qui lui-même rend compte au vice-président chargé de l'innovation. Les lignes d'autorité se poursuivent en amont et en aval de la structure de l'entreprise. Qui n'a jamais regardé l'un de ces organigrammes pour essayer d'y trouver son petit bloc 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 survivre en tant qu'espèce pendant si longtemps, même dans les temps anciens où nous étions confrontés à un monde très dangereux. Nous n'avons jamais été les créatures les plus fortes ou les plus rapides, mais nous travaillions bien en équipe, chacun connaissant sa place et sa responsabilité dans le maintien de notre famille, de notre tribu ou de notre groupe, en vie et en plein essor. L'organigramme moderne est en fait un prolongement de cette époque et de cette réussite ancienne.
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. La plupart du temps, tous les éléments de ces organigrammes représentent des êtres humains ou des groupes d'êtres humains. Nous n'en sommes pas encore au point où les machines sont capables de superviser les humains, de sorte que pour l'instant, les organigrammes sont une affaire exclusivement humaine. Mais nos logiciels ont-ils également besoin d'une hiérarchie organisationnelle ?
Bien entendu, je ne suggère pas d'ajouter un logiciel aux organigrammes de nos entreprises. Personne n'a envie d'avoir une application pour patron. Comment pourriez-vous lui demander une augmentation ? Mais le paysage des menaces auxquelles nos applications et nos 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 bien longtemps. En aidant à définir les responsabilités de nos applications et logiciels au sein d'une hiérarchie étroite 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 dévastateur qui s'offre à eux.
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 travaillent pour eux, sont constamment à l'affût de la moindre faille dans les défenses à exploiter. Alors que le phishing et d'autres attaques contre les humains sont toujours lancés, les pirates les plus habiles ont déplacé la majorité de leurs efforts vers l'attaque des logiciels.
Si tous les logiciels sont visés, les attaques les plus réussies concernent les interfaces de programmation d'applications (API). Ces API discrètes sont de minuscules éléments de logiciel utilisés par les développeurs pour effectuer toute une série de tâches, petites mais importantes, pour leurs applications et leurs programmes. Elles sont souvent flexibles et uniques, et parfois même créées à la volée selon les besoins du processus de développement.
Les API sont certainement flexibles, mais elles sont aussi souvent sur-autorisées par rapport à leurs fonctions. Les développeurs ont tendance à leur accorder de nombreuses autorisations afin qu'elles puissent, par exemple, continuer à fonctionner même si le programme qu'elles aident à gérer continue à se développer et à changer. Mais cela signifie que si un attaquant les compromet, il obtient bien plus que les droits d'accès, par exemple, à un morceau d'une base de données spécifique. Il peut même obtenir des droits de quasi-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 sont aujourd'hui perpétrées contre des logiciels tels que les API. Akamai estime que ce chiffre représente 75 % du total, tandis que Gartner affirme également que les vulnérabilités impliquant les API sont devenues le vecteur d'attaque le plus fréquent. Le dernier rapport de Salt Labs montre que les attaques contre les API ont augmenté de près de 700 % par rapport à l'année dernière.
Création d'un organigramme pour les logiciels
L'un des moyens utilisés par les organisations pour lutter contre les menaces de vol d'informations d'identification consiste à appliquer le principe du moindre privilège, voire de la confiance zéro, au sein de leurs réseaux. Cela limite les utilisateurs à recevoir juste assez d'autorisations pour accomplir leur travail ou leurs tâches. Cet accès est souvent limité par des facteurs tels que l'heure et le lieu. De cette manière, même si une attaque par vol d'informations d'identification réussit, l'attaquant n'en tirera pas grand-chose puisqu'il n'aura la permission d'exécuter que des fonctions limitées pendant une brève période.
Le principe du moindre privilège est une bonne défense, mais il ne s'applique normalement qu'aux utilisateurs humains. Nous avons tendance à oublier que les API détiennent également des privilèges élevés et qu'elles ne sont souvent pas aussi réglementées. C'est l'une des raisons pour lesquelles un contrôle d'accès défaillant est désormais l'ennemi public numéro un selon l'Open Web Application Security Project (OWASP), qui suit les schémas de cyberattaque.
Il est facile de dire que la solution à ce problème critique consiste simplement à appliquer le principe du moindre privilège aux logiciels. Mais cette solution est beaucoup plus difficile à mettre en œuvre. Tout d'abord, les développeurs doivent être sensibilisés aux dangers. Ensuite, pour aller de l'avant, les API et autres logiciels doivent être officiellement placés, ou au moins envisagés, comme faisant partie d'un organigramme au sein du réseau informatique où ils résideront. Par exemple, si une API est censée saisir des 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 soit également capable de se connecter aux systèmes de paie ou de finance. Sur l'organigramme du logiciel, il n'y aurait pas de lignes directes ou même pointillées reliant ces systèmes.
Il est probablement irréaliste pour les développeurs de créer un organigramme montrant les milliers, voire les millions d'API fonctionnant dans leur entreprise. Mais le fait d'être conscient du danger qu'elles représentent et de limiter leurs autorisations au strict nécessaire pour faire leur travail contribuera grandement à mettre un terme aux attaques généralisées de vol d'informations d'identification auxquelles tout le monde est confronté ces jours-ci. Cela commence par une prise de conscience et se termine par le traitement des API et des logiciels avec la même attention que les utilisateurs humains.
Vous souhaitez renforcer votre équipe de développement ? Résolvez les problèmes de sécurité des API et bien d'autres choses encore grâce à notre approche agiles learning platform agiles et axés sur les développeurs.
En aidant à définir les responsabilités de nos applications et logiciels dans le cadre 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é les menaces qui pèsent sur eux.
Directeur général, président et cofondateur
Secure Code Warrior est là pour vous aider à sécuriser le code tout au long du cycle de vie du développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Réservez une démonstrationDirecteur général, président et cofondateur
Pieter Danhieux est un expert en sécurité mondialement reconnu, avec plus de 12 ans d'expérience en tant que consultant en sécurité et 8 ans en tant qu'instructeur principal pour SANS, enseignant des techniques offensives sur la façon de cibler et d'évaluer les organisations, les systèmes et les individus pour les faiblesses de sécurité. En 2016, il a été reconnu comme l'une des personnes les plus cool d'Australie dans le domaine de la technologie (Business Insider), a reçu le prix du professionnel de la cybersécurité de l'année (AISA - Australian Information Security Association) et détient les certifications GSE, CISSP, GCIH, GCFA, GSEC, GPEN, GWAPT, GCIA.
Une version de cet article a été publiée dans Lecture sombre. Elle a été mise à jour et publiée ici.
À un moment ou à un autre de sa carrière, chacun a probablement vu l'un de ces organigrammes opérationnels ou hiérarchiques qui définissent qui rend compte à qui au sein d'une organisation. Parfois simplement appelé organigramme, il s'agit d'un outil utile pour faire savoir aux gens qui travaillent pour eux et qui sont leurs patrons. Par exemple, dans un organigramme classique, le chef d'un groupe de codage peut rendre compte au directeur du développement des produits, qui lui-même rend compte au vice-président chargé de l'innovation. Les lignes d'autorité se poursuivent en amont et en aval de la structure de l'entreprise. Qui n'a jamais regardé l'un de ces organigrammes pour essayer d'y trouver son petit bloc 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 survivre en tant qu'espèce pendant si longtemps, même dans les temps anciens où nous étions confrontés à un monde très dangereux. Nous n'avons jamais été les créatures les plus fortes ou les plus rapides, mais nous travaillions bien en équipe, chacun connaissant sa place et sa responsabilité dans le maintien de notre famille, de notre tribu ou de notre groupe, en vie et en plein essor. L'organigramme moderne est en fait un prolongement de cette époque et de cette réussite ancienne.
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. La plupart du temps, tous les éléments de ces organigrammes représentent des êtres humains ou des groupes d'êtres humains. Nous n'en sommes pas encore au point où les machines sont capables de superviser les humains, de sorte que pour l'instant, les organigrammes sont une affaire exclusivement humaine. Mais nos logiciels ont-ils également besoin d'une hiérarchie organisationnelle ?
Bien entendu, je ne suggère pas d'ajouter un logiciel aux organigrammes de nos entreprises. Personne n'a envie d'avoir une application pour patron. Comment pourriez-vous lui demander une augmentation ? Mais le paysage des menaces auxquelles nos applications et nos 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 bien longtemps. En aidant à définir les responsabilités de nos applications et logiciels au sein d'une hiérarchie étroite 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 dévastateur qui s'offre à eux.
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 travaillent pour eux, sont constamment à l'affût de la moindre faille dans les défenses à exploiter. Alors que le phishing et d'autres attaques contre les humains sont toujours lancés, les pirates les plus habiles ont déplacé la majorité de leurs efforts vers l'attaque des logiciels.
Si tous les logiciels sont visés, les attaques les plus réussies concernent les interfaces de programmation d'applications (API). Ces API discrètes sont de minuscules éléments de logiciel utilisés par les développeurs pour effectuer toute une série de tâches, petites mais importantes, pour leurs applications et leurs programmes. Elles sont souvent flexibles et uniques, et parfois même créées à la volée selon les besoins du processus de développement.
Les API sont certainement flexibles, mais elles sont aussi souvent sur-autorisées par rapport à leurs fonctions. Les développeurs ont tendance à leur accorder de nombreuses autorisations afin qu'elles puissent, par exemple, continuer à fonctionner même si le programme qu'elles aident à gérer continue à se développer et à changer. Mais cela signifie que si un attaquant les compromet, il obtient bien plus que les droits d'accès, par exemple, à un morceau d'une base de données spécifique. Il peut même obtenir des droits de quasi-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 sont aujourd'hui perpétrées contre des logiciels tels que les API. Akamai estime que ce chiffre représente 75 % du total, tandis que Gartner affirme également que les vulnérabilités impliquant les API sont devenues le vecteur d'attaque le plus fréquent. Le dernier rapport de Salt Labs montre que les attaques contre les API ont augmenté de près de 700 % par rapport à l'année dernière.
Création d'un organigramme pour les logiciels
L'un des moyens utilisés par les organisations pour lutter contre les menaces de vol d'informations d'identification consiste à appliquer le principe du moindre privilège, voire de la confiance zéro, au sein de leurs réseaux. Cela limite les utilisateurs à recevoir juste assez d'autorisations pour accomplir leur travail ou leurs tâches. Cet accès est souvent limité par des facteurs tels que l'heure et le lieu. De cette manière, même si une attaque par vol d'informations d'identification réussit, l'attaquant n'en tirera pas grand-chose puisqu'il n'aura la permission d'exécuter que des fonctions limitées pendant une brève période.
Le principe du moindre privilège est une bonne défense, mais il ne s'applique normalement qu'aux utilisateurs humains. Nous avons tendance à oublier que les API détiennent également des privilèges élevés et qu'elles ne sont souvent pas aussi réglementées. C'est l'une des raisons pour lesquelles un contrôle d'accès défaillant est désormais l'ennemi public numéro un selon l'Open Web Application Security Project (OWASP), qui suit les schémas de cyberattaque.
Il est facile de dire que la solution à ce problème critique consiste simplement à appliquer le principe du moindre privilège aux logiciels. Mais cette solution est beaucoup plus difficile à mettre en œuvre. Tout d'abord, les développeurs doivent être sensibilisés aux dangers. Ensuite, pour aller de l'avant, les API et autres logiciels doivent être officiellement placés, ou au moins envisagés, comme faisant partie d'un organigramme au sein du réseau informatique où ils résideront. Par exemple, si une API est censée saisir des 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 soit également capable de se connecter aux systèmes de paie ou de finance. Sur l'organigramme du logiciel, il n'y aurait pas de lignes directes ou même pointillées reliant ces systèmes.
Il est probablement irréaliste pour les développeurs de créer un organigramme montrant les milliers, voire les millions d'API fonctionnant dans leur entreprise. Mais le fait d'être conscient du danger qu'elles représentent et de limiter leurs autorisations au strict nécessaire pour faire leur travail contribuera grandement à mettre un terme aux attaques généralisées de vol d'informations d'identification auxquelles tout le monde est confronté ces jours-ci. Cela commence par une prise de conscience et se termine par le traitement des API et des logiciels avec la même attention que les utilisateurs humains.
Vous souhaitez renforcer votre équipe de développement ? Résolvez les problèmes de sécurité des API et bien d'autres choses encore grâce à notre approche agiles learning platform agiles et axés sur les développeurs.
Une version de cet article a été publiée dans Lecture sombre. Elle a été mise à jour et publiée ici.
À un moment ou à un autre de sa carrière, chacun a probablement vu l'un de ces organigrammes opérationnels ou hiérarchiques qui définissent qui rend compte à qui au sein d'une organisation. Parfois simplement appelé organigramme, il s'agit d'un outil utile pour faire savoir aux gens qui travaillent pour eux et qui sont leurs patrons. Par exemple, dans un organigramme classique, le chef d'un groupe de codage peut rendre compte au directeur du développement des produits, qui lui-même rend compte au vice-président chargé de l'innovation. Les lignes d'autorité se poursuivent en amont et en aval de la structure de l'entreprise. Qui n'a jamais regardé l'un de ces organigrammes pour essayer d'y trouver son petit bloc 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 survivre en tant qu'espèce pendant si longtemps, même dans les temps anciens où nous étions confrontés à un monde très dangereux. Nous n'avons jamais été les créatures les plus fortes ou les plus rapides, mais nous travaillions bien en équipe, chacun connaissant sa place et sa responsabilité dans le maintien de notre famille, de notre tribu ou de notre groupe, en vie et en plein essor. L'organigramme moderne est en fait un prolongement de cette époque et de cette réussite ancienne.
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. La plupart du temps, tous les éléments de ces organigrammes représentent des êtres humains ou des groupes d'êtres humains. Nous n'en sommes pas encore au point où les machines sont capables de superviser les humains, de sorte que pour l'instant, les organigrammes sont une affaire exclusivement humaine. Mais nos logiciels ont-ils également besoin d'une hiérarchie organisationnelle ?
Bien entendu, je ne suggère pas d'ajouter un logiciel aux organigrammes de nos entreprises. Personne n'a envie d'avoir une application pour patron. Comment pourriez-vous lui demander une augmentation ? Mais le paysage des menaces auxquelles nos applications et nos 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 bien longtemps. En aidant à définir les responsabilités de nos applications et logiciels au sein d'une hiérarchie étroite 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 dévastateur qui s'offre à eux.
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 travaillent pour eux, sont constamment à l'affût de la moindre faille dans les défenses à exploiter. Alors que le phishing et d'autres attaques contre les humains sont toujours lancés, les pirates les plus habiles ont déplacé la majorité de leurs efforts vers l'attaque des logiciels.
Si tous les logiciels sont visés, les attaques les plus réussies concernent les interfaces de programmation d'applications (API). Ces API discrètes sont de minuscules éléments de logiciel utilisés par les développeurs pour effectuer toute une série de tâches, petites mais importantes, pour leurs applications et leurs programmes. Elles sont souvent flexibles et uniques, et parfois même créées à la volée selon les besoins du processus de développement.
Les API sont certainement flexibles, mais elles sont aussi souvent sur-autorisées par rapport à leurs fonctions. Les développeurs ont tendance à leur accorder de nombreuses autorisations afin qu'elles puissent, par exemple, continuer à fonctionner même si le programme qu'elles aident à gérer continue à se développer et à changer. Mais cela signifie que si un attaquant les compromet, il obtient bien plus que les droits d'accès, par exemple, à un morceau d'une base de données spécifique. Il peut même obtenir des droits de quasi-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 sont aujourd'hui perpétrées contre des logiciels tels que les API. Akamai estime que ce chiffre représente 75 % du total, tandis que Gartner affirme également que les vulnérabilités impliquant les API sont devenues le vecteur d'attaque le plus fréquent. Le dernier rapport de Salt Labs montre que les attaques contre les API ont augmenté de près de 700 % par rapport à l'année dernière.
Création d'un organigramme pour les logiciels
L'un des moyens utilisés par les organisations pour lutter contre les menaces de vol d'informations d'identification consiste à appliquer le principe du moindre privilège, voire de la confiance zéro, au sein de leurs réseaux. Cela limite les utilisateurs à recevoir juste assez d'autorisations pour accomplir leur travail ou leurs tâches. Cet accès est souvent limité par des facteurs tels que l'heure et le lieu. De cette manière, même si une attaque par vol d'informations d'identification réussit, l'attaquant n'en tirera pas grand-chose puisqu'il n'aura la permission d'exécuter que des fonctions limitées pendant une brève période.
Le principe du moindre privilège est une bonne défense, mais il ne s'applique normalement qu'aux utilisateurs humains. Nous avons tendance à oublier que les API détiennent également des privilèges élevés et qu'elles ne sont souvent pas aussi réglementées. C'est l'une des raisons pour lesquelles un contrôle d'accès défaillant est désormais l'ennemi public numéro un selon l'Open Web Application Security Project (OWASP), qui suit les schémas de cyberattaque.
Il est facile de dire que la solution à ce problème critique consiste simplement à appliquer le principe du moindre privilège aux logiciels. Mais cette solution est beaucoup plus difficile à mettre en œuvre. Tout d'abord, les développeurs doivent être sensibilisés aux dangers. Ensuite, pour aller de l'avant, les API et autres logiciels doivent être officiellement placés, ou au moins envisagés, comme faisant partie d'un organigramme au sein du réseau informatique où ils résideront. Par exemple, si une API est censée saisir des 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 soit également capable de se connecter aux systèmes de paie ou de finance. Sur l'organigramme du logiciel, il n'y aurait pas de lignes directes ou même pointillées reliant ces systèmes.
Il est probablement irréaliste pour les développeurs de créer un organigramme montrant les milliers, voire les millions d'API fonctionnant dans leur entreprise. Mais le fait d'être conscient du danger qu'elles représentent et de limiter leurs autorisations au strict nécessaire pour faire leur travail contribuera grandement à mettre un terme aux attaques généralisées de vol d'informations d'identification auxquelles tout le monde est confronté ces jours-ci. Cela commence par une prise de conscience et se termine par le traitement des API et des logiciels avec la même attention que les utilisateurs humains.
Vous souhaitez renforcer votre équipe de développement ? Résolvez les problèmes de sécurité des API et bien d'autres choses encore grâce à notre approche agiles learning platform agiles et axés sur les développeurs.
Cliquez sur le lien ci-dessous et téléchargez le PDF de cette ressource.
Secure Code Warrior est là pour vous aider à sécuriser le code tout au long du cycle de vie du développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Voir le rapportRéservez une démonstrationDirecteur général, président et cofondateur
Pieter Danhieux est un expert en sécurité mondialement reconnu, avec plus de 12 ans d'expérience en tant que consultant en sécurité et 8 ans en tant qu'instructeur principal pour SANS, enseignant des techniques offensives sur la façon de cibler et d'évaluer les organisations, les systèmes et les individus pour les faiblesses de sécurité. En 2016, il a été reconnu comme l'une des personnes les plus cool d'Australie dans le domaine de la technologie (Business Insider), a reçu le prix du professionnel de la cybersécurité de l'année (AISA - Australian Information Security Association) et détient les certifications GSE, CISSP, GCIH, GCFA, GSEC, GPEN, GWAPT, GCIA.
Une version de cet article a été publiée dans Lecture sombre. Elle a été mise à jour et publiée ici.
À un moment ou à un autre de sa carrière, chacun a probablement vu l'un de ces organigrammes opérationnels ou hiérarchiques qui définissent qui rend compte à qui au sein d'une organisation. Parfois simplement appelé organigramme, il s'agit d'un outil utile pour faire savoir aux gens qui travaillent pour eux et qui sont leurs patrons. Par exemple, dans un organigramme classique, le chef d'un groupe de codage peut rendre compte au directeur du développement des produits, qui lui-même rend compte au vice-président chargé de l'innovation. Les lignes d'autorité se poursuivent en amont et en aval de la structure de l'entreprise. Qui n'a jamais regardé l'un de ces organigrammes pour essayer d'y trouver son petit bloc 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 survivre en tant qu'espèce pendant si longtemps, même dans les temps anciens où nous étions confrontés à un monde très dangereux. Nous n'avons jamais été les créatures les plus fortes ou les plus rapides, mais nous travaillions bien en équipe, chacun connaissant sa place et sa responsabilité dans le maintien de notre famille, de notre tribu ou de notre groupe, en vie et en plein essor. L'organigramme moderne est en fait un prolongement de cette époque et de cette réussite ancienne.
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. La plupart du temps, tous les éléments de ces organigrammes représentent des êtres humains ou des groupes d'êtres humains. Nous n'en sommes pas encore au point où les machines sont capables de superviser les humains, de sorte que pour l'instant, les organigrammes sont une affaire exclusivement humaine. Mais nos logiciels ont-ils également besoin d'une hiérarchie organisationnelle ?
Bien entendu, je ne suggère pas d'ajouter un logiciel aux organigrammes de nos entreprises. Personne n'a envie d'avoir une application pour patron. Comment pourriez-vous lui demander une augmentation ? Mais le paysage des menaces auxquelles nos applications et nos 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 bien longtemps. En aidant à définir les responsabilités de nos applications et logiciels au sein d'une hiérarchie étroite 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 dévastateur qui s'offre à eux.
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 travaillent pour eux, sont constamment à l'affût de la moindre faille dans les défenses à exploiter. Alors que le phishing et d'autres attaques contre les humains sont toujours lancés, les pirates les plus habiles ont déplacé la majorité de leurs efforts vers l'attaque des logiciels.
Si tous les logiciels sont visés, les attaques les plus réussies concernent les interfaces de programmation d'applications (API). Ces API discrètes sont de minuscules éléments de logiciel utilisés par les développeurs pour effectuer toute une série de tâches, petites mais importantes, pour leurs applications et leurs programmes. Elles sont souvent flexibles et uniques, et parfois même créées à la volée selon les besoins du processus de développement.
Les API sont certainement flexibles, mais elles sont aussi souvent sur-autorisées par rapport à leurs fonctions. Les développeurs ont tendance à leur accorder de nombreuses autorisations afin qu'elles puissent, par exemple, continuer à fonctionner même si le programme qu'elles aident à gérer continue à se développer et à changer. Mais cela signifie que si un attaquant les compromet, il obtient bien plus que les droits d'accès, par exemple, à un morceau d'une base de données spécifique. Il peut même obtenir des droits de quasi-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 sont aujourd'hui perpétrées contre des logiciels tels que les API. Akamai estime que ce chiffre représente 75 % du total, tandis que Gartner affirme également que les vulnérabilités impliquant les API sont devenues le vecteur d'attaque le plus fréquent. Le dernier rapport de Salt Labs montre que les attaques contre les API ont augmenté de près de 700 % par rapport à l'année dernière.
Création d'un organigramme pour les logiciels
L'un des moyens utilisés par les organisations pour lutter contre les menaces de vol d'informations d'identification consiste à appliquer le principe du moindre privilège, voire de la confiance zéro, au sein de leurs réseaux. Cela limite les utilisateurs à recevoir juste assez d'autorisations pour accomplir leur travail ou leurs tâches. Cet accès est souvent limité par des facteurs tels que l'heure et le lieu. De cette manière, même si une attaque par vol d'informations d'identification réussit, l'attaquant n'en tirera pas grand-chose puisqu'il n'aura la permission d'exécuter que des fonctions limitées pendant une brève période.
Le principe du moindre privilège est une bonne défense, mais il ne s'applique normalement qu'aux utilisateurs humains. Nous avons tendance à oublier que les API détiennent également des privilèges élevés et qu'elles ne sont souvent pas aussi réglementées. C'est l'une des raisons pour lesquelles un contrôle d'accès défaillant est désormais l'ennemi public numéro un selon l'Open Web Application Security Project (OWASP), qui suit les schémas de cyberattaque.
Il est facile de dire que la solution à ce problème critique consiste simplement à appliquer le principe du moindre privilège aux logiciels. Mais cette solution est beaucoup plus difficile à mettre en œuvre. Tout d'abord, les développeurs doivent être sensibilisés aux dangers. Ensuite, pour aller de l'avant, les API et autres logiciels doivent être officiellement placés, ou au moins envisagés, comme faisant partie d'un organigramme au sein du réseau informatique où ils résideront. Par exemple, si une API est censée saisir des 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 soit également capable de se connecter aux systèmes de paie ou de finance. Sur l'organigramme du logiciel, il n'y aurait pas de lignes directes ou même pointillées reliant ces systèmes.
Il est probablement irréaliste pour les développeurs de créer un organigramme montrant les milliers, voire les millions d'API fonctionnant dans leur entreprise. Mais le fait d'être conscient du danger qu'elles représentent et de limiter leurs autorisations au strict nécessaire pour faire leur travail contribuera grandement à mettre un terme aux attaques généralisées de vol d'informations d'identification auxquelles tout le monde est confronté ces jours-ci. Cela commence par une prise de conscience et se termine par le traitement des API et des logiciels avec la même attention que les utilisateurs humains.
Vous souhaitez renforcer votre équipe de développement ? Résolvez les problèmes de sécurité des API et bien d'autres choses encore grâce à notre approche agiles learning platform agiles et axés sur les développeurs.
Table des matières
Directeur général, président et cofondateur
Secure Code Warrior est là pour vous aider à sécuriser le code tout au long du cycle de vie du développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Réservez une démonstrationTéléchargerRessources pour vous aider à démarrer
Évaluation comparative des compétences en matière de sécurité : Rationalisation de la conception sécurisée dans l'entreprise
Le mouvement "Secure-by-Design" (conception sécurisée) est l'avenir du développement de logiciels sécurisés. Découvrez les éléments clés que les entreprises doivent garder à l'esprit lorsqu'elles envisagent une initiative de conception sécurisée.
DigitalOcean réduit sa dette de sécurité avec Secure Code Warrior
L'utilisation par DigitalOcean de la formation Secure Code Warrior a considérablement réduit la dette de sécurité, permettant aux équipes de se concentrer davantage sur l'innovation et la productivité. L'amélioration de la sécurité a renforcé la qualité des produits et l'avantage concurrentiel de l'entreprise. À l'avenir, le score de confiance SCW les aidera à améliorer leurs pratiques de sécurité et à continuer à stimuler l'innovation.
Ressources pour vous aider à démarrer
Sécurité réactive contre sécurité préventive : La prévention est un meilleur remède
L'idée d'apporter une sécurité préventive aux codes et systèmes existants en même temps qu'aux applications plus récentes peut sembler décourageante, mais une approche "Secure-by-Design", mise en œuvre en améliorant les compétences des développeurs, permet d'appliquer les meilleures pratiques de sécurité à ces systèmes. C'est la meilleure chance qu'ont de nombreuses organisations d'améliorer leur sécurité.
Les avantages de l'évaluation des compétences des développeurs en matière de sécurité
L'importance croissante accordée au code sécurisé et aux principes de conception sécurisée exige que les développeurs soient formés à la cybersécurité dès le début du cycle de développement durable, et que des outils tels que le Trust Score de Secure Code Warriorles aident à mesurer et à améliorer leurs progrès.
Assurer le succès des initiatives de conception sécurisée de l'entreprise
Notre dernier document de recherche, Benchmarking Security Skills : Streamlining Secure-by-Design in the Enterprise est le résultat d'une analyse approfondie d'initiatives réelles de conception sécurisée au niveau de l'entreprise, et de l'élaboration d'approches de meilleures pratiques basées sur des conclusions fondées sur des données.
Plongée en profondeur : Naviguer dans la vulnérabilité critique de CUPS dans les systèmes GNU-Linux
Découvrez les derniers défis de sécurité auxquels sont confrontés les utilisateurs de Linux en explorant les récentes vulnérabilités de haute sévérité dans le système d'impression commun d'UNIX (CUPS). Apprenez comment ces problèmes peuvent conduire à une potentielle exécution de code à distance (RCE) et ce que vous pouvez faire pour protéger vos systèmes.