SCW アイコン
ヒーロー背景(区切りなし)
ブログ

Repenser les logiciels dans la hiérarchie organisationnelle

ピーテル・ダンヒユー
2023年06月01日 掲載
最終更新日: 2026年3月8日

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

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

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

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

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

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

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

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

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

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

Création d'un organigramme pour un logiciel

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

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

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

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


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

リソースを表示する
リソースを表示する

En aidant à définir les responsabilités de nos applications et logiciels au sein d'une hiérarchie stricte, et en appliquant ces politiques avec le moins de privilèges possible, nous pouvons nous assurer que nos applications et logiciels survivent et prospèrent malgré le paysage de menaces auquel ils sont confrontés.

さらに詳しく知りたいですか?

最高経営責任者(CEO)、会長、および共同設立者

もっと詳しく

Secure Code Warrior ソフトウェア開発ライフサイクル全体を通じてコードのセキュリティを確保し、サイバーセキュリティを最優先事項とする文化を構築するために、組織をSecure Code Warrior 。アプリケーションセキュリティ担当者、開発者、情報セキュリティ責任者、その他セキュリティに関わるあらゆる方々のために、当社は組織が非セキュアなコードに関連するリスクを軽減するお手伝いをいたします。

デモを予約する
共有する:
リンクトインのブランドソーシャルx ロゴ
作者
ピーテル・ダンヒユー
2023年06月01日掲載

最高経営責任者(CEO)、会長、および共同設立者

Pieter Danhieuxは、セキュリティコンサルタントとして12年以上の経験を持ち、SANSの主席講師として8年間、組織、システム、個人をターゲットにしてセキュリティの弱点を評価する方法に関する攻撃的なテクニックを教えている、世界的に有名なセキュリティエキスパートです。2016年には、オーストラリアで最もクールな技術者の一人として認められ(Business Insider)、Cyber Security Professional of the Yearを受賞(AISA - Australian Information Security Association)、GSE、CISSP、GCIH、GCFA、GSEC、GPEN、GWAPT、GCIA認定を保有している。

共有する:
リンクトインのブランドソーシャルx ロゴ

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

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

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

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

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

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

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

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

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

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

Création d'un organigramme pour un logiciel

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

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

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

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


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

リソースを表示する
リソースを表示する

以下のフォームに記入してレポートをダウンロードしてください

当社製品および/またはセキュアコーディング関連の情報をお送りするにあたり、ご承諾を頂戴できれば幸いです。お客様の個人情報は常に細心の注意をもって取り扱い、マーケティング目的で他社に販売することは一切ございません。

提出する
SCW成功アイコン
SCWエラーアイコン
フォームを送信するには、Analyticsクッキーを有効にしてください。完了後は再度無効化しても構いません。

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

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

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

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

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

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

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

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

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

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

Création d'un organigramme pour un logiciel

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

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

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

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


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

ウェビナーを表示する
始めましょう
もっと詳しく

以下のリンクをクリックして、このリソースのPDFをダウンロードしてください。

Secure Code Warrior ソフトウェア開発ライフサイクル全体を通じてコードのセキュリティを確保し、サイバーセキュリティを最優先事項とする文化を構築するために、組織をSecure Code Warrior 。アプリケーションセキュリティ担当者、開発者、情報セキュリティ責任者、その他セキュリティに関わるあらゆる方々のために、当社は組織が非セキュアなコードに関連するリスクを軽減するお手伝いをいたします。

レポートを表示するデモを予約する
PDFをダウンロード
リソースを表示する
共有する:
リンクトインのブランドソーシャルx ロゴ
さらに詳しく知りたいですか?

共有する:
リンクトインのブランドソーシャルx ロゴ
作者
ピーテル・ダンヒユー
2023年06月01日掲載

最高経営責任者(CEO)、会長、および共同設立者

Pieter Danhieuxは、セキュリティコンサルタントとして12年以上の経験を持ち、SANSの主席講師として8年間、組織、システム、個人をターゲットにしてセキュリティの弱点を評価する方法に関する攻撃的なテクニックを教えている、世界的に有名なセキュリティエキスパートです。2016年には、オーストラリアで最もクールな技術者の一人として認められ(Business Insider)、Cyber Security Professional of the Yearを受賞(AISA - Australian Information Security Association)、GSE、CISSP、GCIH、GCFA、GSEC、GPEN、GWAPT、GCIA認定を保有している。

共有する:
リンクトインのブランドソーシャルx ロゴ

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

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

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

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

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

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

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

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

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

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

Création d'un organigramme pour un logiciel

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

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

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

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


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

目次

PDFをダウンロード
リソースを表示する
さらに詳しく知りたいですか?

最高経営責任者(CEO)、会長、および共同設立者

もっと詳しく

Secure Code Warrior ソフトウェア開発ライフサイクル全体を通じてコードのセキュリティを確保し、サイバーセキュリティを最優先事項とする文化を構築するために、組織をSecure Code Warrior 。アプリケーションセキュリティ担当者、開発者、情報セキュリティ責任者、その他セキュリティに関わるあらゆる方々のために、当社は組織が非セキュアなコードに関連するリスクを軽減するお手伝いをいたします。

デモを予約するダウンロード
共有する:
リンクトインのブランドソーシャルx ロゴ
リソースセンター

はじめの一歩を踏み出すためのリソース

投稿はありません
リソースセンター

はじめの一歩を踏み出すためのリソース

投稿はありません