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 Plateforme D'apprentissage 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émonstration
Directeur 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 Plateforme D'apprentissage 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 Plateforme D'apprentissage 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émonstration
Directeur 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 Plateforme D'apprentissage 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
AI Coding Assistants : Un guide de navigation sécurisée pour la prochaine génération de développeurs
Les grands modèles linguistiques offrent des avantages irrésistibles en termes de rapidité et de productivité, mais ils présentent également des risques indéniables pour l'entreprise. Les garde-fous traditionnels ne suffisent pas à contrôler le déluge. Les développeurs ont besoin de compétences précises et vérifiées en matière de sécurité pour identifier et prévenir les failles de sécurité dès le début du cycle de développement du logiciel.
Sécurité dès la conception : Définir les meilleures pratiques, permettre aux développeurs et évaluer les résultats de la sécurité préventive
Dans ce document de recherche, les cofondateurs de Secure Code Warrior , Pieter Danhieux et Matias Madou, Ph.D., ainsi que des contributeurs experts, Chris Inglis, ancien directeur national américain de la cybernétique (aujourd'hui conseiller stratégique du Paladin Capital Group), et Devin Lynch, directeur principal du Paladin Global Institute, révèleront les principales conclusions de plus de vingt entretiens approfondis avec des responsables de la sécurité des entreprises, y compris des RSSI, un vice-président de la sécurité des applications et des professionnels de la sécurité des logiciels.
Ressources pour vous aider à démarrer
Définir la norme : SCW publie des règles de sécurité gratuites pour le codage de l'IA sur GitHub
Le développement assisté par IA n'est plus un horizon : il est bel et bien là, et il transforme rapidement la manière dont les logiciels sont écrits. Des outils comme GitHub Copilot, Cline, Roo, Cursor, Aider et Windsurf transforment les développeurs en copilotes, permettant des itérations plus rapides et accélérant tout, du prototypage aux projets de refactorisation majeurs.
Bouclez la boucle des vulnérabilités avec Secure Code Warrior + HackerOne
Secure Code Warrior est heureux d'annoncer sa nouvelle intégration avec HackerOne, un leader dans les solutions de sécurité offensive. Ensemble, nous construisons un écosystème puissant et intégré. HackerOne met le doigt sur les vulnérabilités dans les environnements réels, en exposant le "quoi" et le "où" des problèmes de sécurité.
Révélation : Comment l'industrie du cyberespace définit la notion de "Secure by Design" (sécurité dès la conception)
Dans notre dernier livre blanc, nos cofondateurs, Pieter Danhieux et Matias Madou, Ph.D., ont rencontré plus de vingt responsables de la sécurité d'entreprise, notamment des RSSI, des responsables AppSec et des professionnels de la sécurité, afin d'identifier les principales pièces de ce puzzle et de découvrir la réalité qui se cache derrière le mouvement Secure by Design. Il s'agit d'une ambition partagée par les équipes de sécurité, mais il n'y a pas de manuel de jeu commun.
Codage axé sur le développeur.
En toute sécurité.
Contactez-nous dès aujourd'hui et faites de la sécurité des logiciels une partie intrinsèque de votre processus de développement.
