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
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.
Évaluation comparative des compétences en matière de sécurité : Rationalisation de la conception sécurisée dans l'entreprise
Il est notoirement difficile de trouver des données significatives sur le succès des initiatives Secure-by-Design. Les RSSI sont souvent confrontés à des difficultés lorsqu'ils tentent de prouver le retour sur investissement (ROI) et la valeur commerciale des activités du programme de sécurité, tant au niveau des personnes que de l'entreprise. De plus, il est particulièrement difficile pour les entreprises d'obtenir des informations sur la façon dont leurs organisations sont comparées aux normes actuelles du secteur. La stratégie nationale de cybersécurité du président a mis les parties prenantes au défi d'"adopter la sécurité et la résilience dès la conception". Pour que les initiatives de conception sécurisée fonctionnent, il faut non seulement donner aux développeurs les compétences nécessaires pour assurer la sécurité du code, mais aussi garantir aux régulateurs que ces compétences sont en place. Dans cette présentation, nous partageons une myriade de données qualitatives et quantitatives, dérivées de sources primaires multiples, y compris des points de données internes collectés auprès de plus de 250 000 développeurs, des informations sur les clients basées sur des données, et des études publiques. En nous appuyant sur cette agrégation de points de données, nous visons à communiquer une vision de l'état actuel des initiatives Secure-by-Design dans de multiples secteurs verticaux. Le rapport explique en détail pourquoi cet espace est actuellement sous-utilisé, l'impact significatif qu'un programme de perfectionnement réussi peut avoir sur l'atténuation des risques de cybersécurité, et le potentiel d'élimination des catégories de vulnérabilités d'une base de code.
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.
Vibe Coding va-t-il transformer votre base de code en une fête de fraternité ?
Le codage vibratoire est comme une fête de fraternité universitaire, et l'IA est la pièce maîtresse de toutes les festivités, le tonneau. C'est très amusant de se laisser aller, d'être créatif et de voir où votre imagination peut vous mener, mais après quelques barils, boire (ou utiliser l'IA) avec modération est sans aucun doute la solution la plus sûre à long terme.
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.
