Lever le voile sur les cyber-vulnérabilités dans la chaîne d'approvisionnement du gouvernement
Une version de cet article a été publiée dans TechCrunch. Elle a été mise à jour et publiée ici.
Comme si nous n'avions pas eu assez de perturbations au cours de l'année qui ne peut être nommée, 2021 a commencé par un coup de tonnerre assourdissant pour le gouvernement américain, sous la forme de l'une des pires violations de données jamais enregistrées. L'incident SolarWinds est une attaque dévastatrice et sophistiquée d'un État-nation qui a semé la panique dans plusieurs ministères et grandes organisations, qui se sont empressés de sécuriser leurs points d'extrémité. Pratiquement tous les utilisateurs finaux du logiciel SolarWinds ont été compromis, et l'incident a montré très clairement que la cybersécurité et la défense des chaînes d'approvisionnement en logiciels sont essentielles.
Il est évident que la cybersécurité est importante, mais que signifie-t-elle réellement dans le contexte des chaînes d'approvisionnement ?
L'état de la cybersécurité dans l'équipe de développement moyenne
Une quantité énorme de logiciels est produite chaque jour, ce qui représente des milliards de lignes de code chaque année, et cela ne fait qu'augmenter avec la demande créée par nos modes de vie de plus en plus numériques. La population mondiale des développeurs devrait atteindre près de 29 millions de personnes d'ici à 2024, et il n'existe actuellement aucune certification officielle permettant d'évaluer et de certifier leur capacité à coder en toute sécurité. Cela ne veut pas dire que chaque développeur produit ou réutilise un code non sécurisé, mais il existe indubitablement un risque durable que des faiblesses de sécurité de base soient introduites dans les logiciels auxquels nous confions nos données.
Les développeurs sont évalués sur leur capacité à créer des fonctionnalités et à livrer le code le plus rapidement possible. La sécurité n'a pas été un critère de réussite dans la plupart des organisations, mais ce sentiment commence à changer car de plus en plus d'entreprises réalisent le potentiel qu'elles détiennent en matière de prévention des bogues de sécurité courants dès les premières étapes de la création de logiciels. Cependant, la prise de conscience et la mise en œuvre sont deux choses différentes, et comme la plupart des développements tertiaires courses ne contiennent aucun contexte sur les pratiques de codage sécurisé, c'est souvent au lieu de travail d'un développeur de combler les lacunes. Si le développement des compétences et le partage des connaissances sont peu fréquents ou non pertinents, ils seront probablement inefficaces. Ainsi, le cycle des vulnérabilités récurrentes dues au manque de développement des compétences reste ininterrompu.
Naturellement, il n'incombe pas au développeur de logiciels moyen de résoudre les problèmes de cybersécurité dans le monde ; après tout, ce n'est pas pour rien que les organisations embauchent des professionnels de la sécurité qui coûtent très cher. Les gourous de la sécurité se font rares, cependant, et les développeurs peuvent certainement jouer un rôle en réduisant la pression.
Mais où cela nous mène-t-il - ainsi que les fournisseurs qui créent des logiciels pour les infrastructures critiques et les organisations sensibles - en termes de prévention d'une cyberattaque dévastatrice ? Il faudra à tout le moins modifier le statu quo en matière d'achat de logiciels.
Les pièges qui entravent la sécurité de la chaîne d'approvisionnement en logiciels
L'adage selon lequel une chaîne est aussi solide que son maillon le plus faible est malheureusement tout aussi vrai lorsqu'il s'agit de l'approvisionnement en logiciels. Peu importe que votre entreprise ait renforcé ses meilleures pratiques en matière de sécurité, qu'elle ait investi dans la formation continue des développeurs et qu'elle ait évolué vers un environnement DevSecOps fonctionnel (c'est-à-dire que tout le monde partage la responsabilité de créer des logiciels aussi sûrs que possible) ; si vous utilisez des logiciels d'un fournisseur qui a des problèmes de sécurité, vous en hériterez dans votre écosystème et vous en subirez les conséquences.
Bien sûr, l'équipe de sécurité devrait aider à évaluer la sécurité des ajouts de tiers à la pile technologique, mais les décisions peuvent être prises sur la base d'un besoin commercial avec peu de choix parmi les solutions. À ce stade, il peut s'agir d'un exercice de confiance. Le fournisseur se préoccupe-t-il de la sécurité autant que votre entreprise ? Et peut-il réellement évaluer les risques comme vous seul pouvez les comprendre, ainsi que les actifs que vous devez protéger ?
La transparence est un facteur très important dans l'évaluation de la viabilité de la sécurité des ajouts logiciels des fournisseurs. Sont-ils francs quant à leurs propres pratiques en matière de sécurité? Ils doivent être fiers de leur approche en matière de sécurité des données et en faire une priorité absolue. Si les pratiques de sécurité ne sont publiées nulle part, ou si aucune information n'est disponible, il y a de fortes chances que la sécurité ne soit pas une priorité. Le fournisseur doit être en mesure de répondre aux questions techniques, et des certifications indépendantes telles que ISO27001 et SOC2 ne seraient pas de trop. Par ailleurs, si vous ne pouvez pas "regarder sous le capot" et rechercher les vulnérabilités dans le cadre de vos propres pratiques internes de diligence et de sécurité, laissez tomber.
La demande entraînant une mise en œuvre aussi rapide des besoins logiciels, en particulier si le code du fournisseur est intégré dans des systèmes existants pour effectuer des actions dans un nouveau contexte, le fournisseur et l'acheteur doivent tous deux être au sommet de leur art, et leurs développeurs doivent être sur le terrain pour détecter les bogues et les failles de sécurité les plus courants avant l'expédition. Des centaines - voire des milliers - de dépendances peuvent être compromises si un nouvel élément vient s'ajouter à la toile d'araignée des solutions technologiques existantes, et une petite défaillance peut conduire à une défaite catastrophique.
Quelle est donc la solution ? Tout coder en interne, à partir de zéro ? Si nous étions en 1998, cela pourrait avoir du sens. Cependant, de même que nous ne demandons plus à Jeeves où se trouve la station de lavage la plus proche, nous devons mettre en œuvre des mesures de protection réalistes qui fonctionnent dans le contexte d'aujourd'hui.
Il n'y a pas encore de solution miracle, mais il existe des solutions
Pour les acheteurs, la sécurité assessment des logiciels et des pratiques de développement des fournisseurs doit être une priorité du programme de sécurité global et du plan d'atténuation des risques. Posez des questions sur les certifications, les pratiques et la réputation de sécurité de leurs développeurs.
Les fournisseurs (et en fait toutes les entreprises qui créent des logiciels) doivent être prêts à démontrer que la sécurité est au centre de leurs préoccupations et doivent se concentrer sur la formation continue. Les développeurs compétents en matière de sécurité sont très demandés et, avec les outils et le soutien adéquats, ils peuvent être formés à partir de votre équipe existante et être habilités à se défendre contre les attaques résultant des vulnérabilités courantes. Mais ne leur donnez pas n'importe quelle formation. Donnez-leur le temps de s'épanouir avec des outils de sécurité qui complètent leurs flux de travail existants. Rendez les choses aussi simples que possible et observez les bogues gênants commencer à disparaître du code qui alimente l'entreprise.
En définitive, les risques liés aux logiciels sont immédiatement exacerbés s'ils font partie de la chaîne d'approvisionnement, affectant tous les utilisateurs et tous les systèmes où des composants vulnérables ont été utilisés. Si les fournisseurs ne sont pas aussi sérieux en matière de sécurité que les entreprises qui mettent en œuvre leurs logiciels - ou si le fournisseur et l'organisation présentent tous deux des lacunes dans leur programme de sécurité - des attaques de la chaîne d'approvisionnement plus dévastatrices et de plus grande portée comme celle de SolarWinds deviendront inévitablement la norme - et il s'agit là d'un problème critique pour tout le monde.
Il est évident que la cybersécurité est importante, mais que signifie-t-elle réellement dans le contexte des chaînes d'approvisionnement ?
Directeur général, président et cofondateur
Secure Code Warrior est là pour vous aider à sécuriser le code tout au long du cycle de vie du développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Réservez une démonstrationDirecteur général, président et cofondateur
Pieter Danhieux est un expert en sécurité mondialement reconnu, avec plus de 12 ans d'expérience en tant que consultant en sécurité et 8 ans en tant qu'instructeur principal pour SANS, enseignant des techniques offensives sur la façon de cibler et d'évaluer les organisations, les systèmes et les individus pour les faiblesses de sécurité. En 2016, il a été reconnu comme l'une des personnes les plus cool d'Australie dans le domaine de la technologie (Business Insider), a reçu le prix du professionnel de la cybersécurité de l'année (AISA - Australian Information Security Association) et détient les certifications GSE, CISSP, GCIH, GCFA, GSEC, GPEN, GWAPT, GCIA.
Une version de cet article a été publiée dans TechCrunch. Elle a été mise à jour et publiée ici.
Comme si nous n'avions pas eu assez de perturbations au cours de l'année qui ne peut être nommée, 2021 a commencé par un coup de tonnerre assourdissant pour le gouvernement américain, sous la forme de l'une des pires violations de données jamais enregistrées. L'incident SolarWinds est une attaque dévastatrice et sophistiquée d'un État-nation qui a semé la panique dans plusieurs ministères et grandes organisations, qui se sont empressés de sécuriser leurs points d'extrémité. Pratiquement tous les utilisateurs finaux du logiciel SolarWinds ont été compromis, et l'incident a montré très clairement que la cybersécurité et la défense des chaînes d'approvisionnement en logiciels sont essentielles.
Il est évident que la cybersécurité est importante, mais que signifie-t-elle réellement dans le contexte des chaînes d'approvisionnement ?
L'état de la cybersécurité dans l'équipe de développement moyenne
Une quantité énorme de logiciels est produite chaque jour, ce qui représente des milliards de lignes de code chaque année, et cela ne fait qu'augmenter avec la demande créée par nos modes de vie de plus en plus numériques. La population mondiale des développeurs devrait atteindre près de 29 millions de personnes d'ici à 2024, et il n'existe actuellement aucune certification officielle permettant d'évaluer et de certifier leur capacité à coder en toute sécurité. Cela ne veut pas dire que chaque développeur produit ou réutilise un code non sécurisé, mais il existe indubitablement un risque durable que des faiblesses de sécurité de base soient introduites dans les logiciels auxquels nous confions nos données.
Les développeurs sont évalués sur leur capacité à créer des fonctionnalités et à livrer le code le plus rapidement possible. La sécurité n'a pas été un critère de réussite dans la plupart des organisations, mais ce sentiment commence à changer car de plus en plus d'entreprises réalisent le potentiel qu'elles détiennent en matière de prévention des bogues de sécurité courants dès les premières étapes de la création de logiciels. Cependant, la prise de conscience et la mise en œuvre sont deux choses différentes, et comme la plupart des développements tertiaires courses ne contiennent aucun contexte sur les pratiques de codage sécurisé, c'est souvent au lieu de travail d'un développeur de combler les lacunes. Si le développement des compétences et le partage des connaissances sont peu fréquents ou non pertinents, ils seront probablement inefficaces. Ainsi, le cycle des vulnérabilités récurrentes dues au manque de développement des compétences reste ininterrompu.
Naturellement, il n'incombe pas au développeur de logiciels moyen de résoudre les problèmes de cybersécurité dans le monde ; après tout, ce n'est pas pour rien que les organisations embauchent des professionnels de la sécurité qui coûtent très cher. Les gourous de la sécurité se font rares, cependant, et les développeurs peuvent certainement jouer un rôle en réduisant la pression.
Mais où cela nous mène-t-il - ainsi que les fournisseurs qui créent des logiciels pour les infrastructures critiques et les organisations sensibles - en termes de prévention d'une cyberattaque dévastatrice ? Il faudra à tout le moins modifier le statu quo en matière d'achat de logiciels.
Les pièges qui entravent la sécurité de la chaîne d'approvisionnement en logiciels
L'adage selon lequel une chaîne est aussi solide que son maillon le plus faible est malheureusement tout aussi vrai lorsqu'il s'agit de l'approvisionnement en logiciels. Peu importe que votre entreprise ait renforcé ses meilleures pratiques en matière de sécurité, qu'elle ait investi dans la formation continue des développeurs et qu'elle ait évolué vers un environnement DevSecOps fonctionnel (c'est-à-dire que tout le monde partage la responsabilité de créer des logiciels aussi sûrs que possible) ; si vous utilisez des logiciels d'un fournisseur qui a des problèmes de sécurité, vous en hériterez dans votre écosystème et vous en subirez les conséquences.
Bien sûr, l'équipe de sécurité devrait aider à évaluer la sécurité des ajouts de tiers à la pile technologique, mais les décisions peuvent être prises sur la base d'un besoin commercial avec peu de choix parmi les solutions. À ce stade, il peut s'agir d'un exercice de confiance. Le fournisseur se préoccupe-t-il de la sécurité autant que votre entreprise ? Et peut-il réellement évaluer les risques comme vous seul pouvez les comprendre, ainsi que les actifs que vous devez protéger ?
La transparence est un facteur très important dans l'évaluation de la viabilité de la sécurité des ajouts logiciels des fournisseurs. Sont-ils francs quant à leurs propres pratiques en matière de sécurité? Ils doivent être fiers de leur approche en matière de sécurité des données et en faire une priorité absolue. Si les pratiques de sécurité ne sont publiées nulle part, ou si aucune information n'est disponible, il y a de fortes chances que la sécurité ne soit pas une priorité. Le fournisseur doit être en mesure de répondre aux questions techniques, et des certifications indépendantes telles que ISO27001 et SOC2 ne seraient pas de trop. Par ailleurs, si vous ne pouvez pas "regarder sous le capot" et rechercher les vulnérabilités dans le cadre de vos propres pratiques internes de diligence et de sécurité, laissez tomber.
La demande entraînant une mise en œuvre aussi rapide des besoins logiciels, en particulier si le code du fournisseur est intégré dans des systèmes existants pour effectuer des actions dans un nouveau contexte, le fournisseur et l'acheteur doivent tous deux être au sommet de leur art, et leurs développeurs doivent être sur le terrain pour détecter les bogues et les failles de sécurité les plus courants avant l'expédition. Des centaines - voire des milliers - de dépendances peuvent être compromises si un nouvel élément vient s'ajouter à la toile d'araignée des solutions technologiques existantes, et une petite défaillance peut conduire à une défaite catastrophique.
Quelle est donc la solution ? Tout coder en interne, à partir de zéro ? Si nous étions en 1998, cela pourrait avoir du sens. Cependant, de même que nous ne demandons plus à Jeeves où se trouve la station de lavage la plus proche, nous devons mettre en œuvre des mesures de protection réalistes qui fonctionnent dans le contexte d'aujourd'hui.
Il n'y a pas encore de solution miracle, mais il existe des solutions
Pour les acheteurs, la sécurité assessment des logiciels et des pratiques de développement des fournisseurs doit être une priorité du programme de sécurité global et du plan d'atténuation des risques. Posez des questions sur les certifications, les pratiques et la réputation de sécurité de leurs développeurs.
Les fournisseurs (et en fait toutes les entreprises qui créent des logiciels) doivent être prêts à démontrer que la sécurité est au centre de leurs préoccupations et doivent se concentrer sur la formation continue. Les développeurs compétents en matière de sécurité sont très demandés et, avec les outils et le soutien adéquats, ils peuvent être formés à partir de votre équipe existante et être habilités à se défendre contre les attaques résultant des vulnérabilités courantes. Mais ne leur donnez pas n'importe quelle formation. Donnez-leur le temps de s'épanouir avec des outils de sécurité qui complètent leurs flux de travail existants. Rendez les choses aussi simples que possible et observez les bogues gênants commencer à disparaître du code qui alimente l'entreprise.
En définitive, les risques liés aux logiciels sont immédiatement exacerbés s'ils font partie de la chaîne d'approvisionnement, affectant tous les utilisateurs et tous les systèmes où des composants vulnérables ont été utilisés. Si les fournisseurs ne sont pas aussi sérieux en matière de sécurité que les entreprises qui mettent en œuvre leurs logiciels - ou si le fournisseur et l'organisation présentent tous deux des lacunes dans leur programme de sécurité - des attaques de la chaîne d'approvisionnement plus dévastatrices et de plus grande portée comme celle de SolarWinds deviendront inévitablement la norme - et il s'agit là d'un problème critique pour tout le monde.
Une version de cet article a été publiée dans TechCrunch. Elle a été mise à jour et publiée ici.
Comme si nous n'avions pas eu assez de perturbations au cours de l'année qui ne peut être nommée, 2021 a commencé par un coup de tonnerre assourdissant pour le gouvernement américain, sous la forme de l'une des pires violations de données jamais enregistrées. L'incident SolarWinds est une attaque dévastatrice et sophistiquée d'un État-nation qui a semé la panique dans plusieurs ministères et grandes organisations, qui se sont empressés de sécuriser leurs points d'extrémité. Pratiquement tous les utilisateurs finaux du logiciel SolarWinds ont été compromis, et l'incident a montré très clairement que la cybersécurité et la défense des chaînes d'approvisionnement en logiciels sont essentielles.
Il est évident que la cybersécurité est importante, mais que signifie-t-elle réellement dans le contexte des chaînes d'approvisionnement ?
L'état de la cybersécurité dans l'équipe de développement moyenne
Une quantité énorme de logiciels est produite chaque jour, ce qui représente des milliards de lignes de code chaque année, et cela ne fait qu'augmenter avec la demande créée par nos modes de vie de plus en plus numériques. La population mondiale des développeurs devrait atteindre près de 29 millions de personnes d'ici à 2024, et il n'existe actuellement aucune certification officielle permettant d'évaluer et de certifier leur capacité à coder en toute sécurité. Cela ne veut pas dire que chaque développeur produit ou réutilise un code non sécurisé, mais il existe indubitablement un risque durable que des faiblesses de sécurité de base soient introduites dans les logiciels auxquels nous confions nos données.
Les développeurs sont évalués sur leur capacité à créer des fonctionnalités et à livrer le code le plus rapidement possible. La sécurité n'a pas été un critère de réussite dans la plupart des organisations, mais ce sentiment commence à changer car de plus en plus d'entreprises réalisent le potentiel qu'elles détiennent en matière de prévention des bogues de sécurité courants dès les premières étapes de la création de logiciels. Cependant, la prise de conscience et la mise en œuvre sont deux choses différentes, et comme la plupart des développements tertiaires courses ne contiennent aucun contexte sur les pratiques de codage sécurisé, c'est souvent au lieu de travail d'un développeur de combler les lacunes. Si le développement des compétences et le partage des connaissances sont peu fréquents ou non pertinents, ils seront probablement inefficaces. Ainsi, le cycle des vulnérabilités récurrentes dues au manque de développement des compétences reste ininterrompu.
Naturellement, il n'incombe pas au développeur de logiciels moyen de résoudre les problèmes de cybersécurité dans le monde ; après tout, ce n'est pas pour rien que les organisations embauchent des professionnels de la sécurité qui coûtent très cher. Les gourous de la sécurité se font rares, cependant, et les développeurs peuvent certainement jouer un rôle en réduisant la pression.
Mais où cela nous mène-t-il - ainsi que les fournisseurs qui créent des logiciels pour les infrastructures critiques et les organisations sensibles - en termes de prévention d'une cyberattaque dévastatrice ? Il faudra à tout le moins modifier le statu quo en matière d'achat de logiciels.
Les pièges qui entravent la sécurité de la chaîne d'approvisionnement en logiciels
L'adage selon lequel une chaîne est aussi solide que son maillon le plus faible est malheureusement tout aussi vrai lorsqu'il s'agit de l'approvisionnement en logiciels. Peu importe que votre entreprise ait renforcé ses meilleures pratiques en matière de sécurité, qu'elle ait investi dans la formation continue des développeurs et qu'elle ait évolué vers un environnement DevSecOps fonctionnel (c'est-à-dire que tout le monde partage la responsabilité de créer des logiciels aussi sûrs que possible) ; si vous utilisez des logiciels d'un fournisseur qui a des problèmes de sécurité, vous en hériterez dans votre écosystème et vous en subirez les conséquences.
Bien sûr, l'équipe de sécurité devrait aider à évaluer la sécurité des ajouts de tiers à la pile technologique, mais les décisions peuvent être prises sur la base d'un besoin commercial avec peu de choix parmi les solutions. À ce stade, il peut s'agir d'un exercice de confiance. Le fournisseur se préoccupe-t-il de la sécurité autant que votre entreprise ? Et peut-il réellement évaluer les risques comme vous seul pouvez les comprendre, ainsi que les actifs que vous devez protéger ?
La transparence est un facteur très important dans l'évaluation de la viabilité de la sécurité des ajouts logiciels des fournisseurs. Sont-ils francs quant à leurs propres pratiques en matière de sécurité? Ils doivent être fiers de leur approche en matière de sécurité des données et en faire une priorité absolue. Si les pratiques de sécurité ne sont publiées nulle part, ou si aucune information n'est disponible, il y a de fortes chances que la sécurité ne soit pas une priorité. Le fournisseur doit être en mesure de répondre aux questions techniques, et des certifications indépendantes telles que ISO27001 et SOC2 ne seraient pas de trop. Par ailleurs, si vous ne pouvez pas "regarder sous le capot" et rechercher les vulnérabilités dans le cadre de vos propres pratiques internes de diligence et de sécurité, laissez tomber.
La demande entraînant une mise en œuvre aussi rapide des besoins logiciels, en particulier si le code du fournisseur est intégré dans des systèmes existants pour effectuer des actions dans un nouveau contexte, le fournisseur et l'acheteur doivent tous deux être au sommet de leur art, et leurs développeurs doivent être sur le terrain pour détecter les bogues et les failles de sécurité les plus courants avant l'expédition. Des centaines - voire des milliers - de dépendances peuvent être compromises si un nouvel élément vient s'ajouter à la toile d'araignée des solutions technologiques existantes, et une petite défaillance peut conduire à une défaite catastrophique.
Quelle est donc la solution ? Tout coder en interne, à partir de zéro ? Si nous étions en 1998, cela pourrait avoir du sens. Cependant, de même que nous ne demandons plus à Jeeves où se trouve la station de lavage la plus proche, nous devons mettre en œuvre des mesures de protection réalistes qui fonctionnent dans le contexte d'aujourd'hui.
Il n'y a pas encore de solution miracle, mais il existe des solutions
Pour les acheteurs, la sécurité assessment des logiciels et des pratiques de développement des fournisseurs doit être une priorité du programme de sécurité global et du plan d'atténuation des risques. Posez des questions sur les certifications, les pratiques et la réputation de sécurité de leurs développeurs.
Les fournisseurs (et en fait toutes les entreprises qui créent des logiciels) doivent être prêts à démontrer que la sécurité est au centre de leurs préoccupations et doivent se concentrer sur la formation continue. Les développeurs compétents en matière de sécurité sont très demandés et, avec les outils et le soutien adéquats, ils peuvent être formés à partir de votre équipe existante et être habilités à se défendre contre les attaques résultant des vulnérabilités courantes. Mais ne leur donnez pas n'importe quelle formation. Donnez-leur le temps de s'épanouir avec des outils de sécurité qui complètent leurs flux de travail existants. Rendez les choses aussi simples que possible et observez les bogues gênants commencer à disparaître du code qui alimente l'entreprise.
En définitive, les risques liés aux logiciels sont immédiatement exacerbés s'ils font partie de la chaîne d'approvisionnement, affectant tous les utilisateurs et tous les systèmes où des composants vulnérables ont été utilisés. Si les fournisseurs ne sont pas aussi sérieux en matière de sécurité que les entreprises qui mettent en œuvre leurs logiciels - ou si le fournisseur et l'organisation présentent tous deux des lacunes dans leur programme de sécurité - des attaques de la chaîne d'approvisionnement plus dévastatrices et de plus grande portée comme celle de SolarWinds deviendront inévitablement la norme - et il s'agit là d'un problème critique pour tout le monde.
Cliquez sur le lien ci-dessous et téléchargez le PDF de cette ressource.
Secure Code Warrior est là pour vous aider à sécuriser le code tout au long du cycle de vie du développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Voir le rapportRéservez une démonstrationDirecteur général, président et cofondateur
Pieter Danhieux est un expert en sécurité mondialement reconnu, avec plus de 12 ans d'expérience en tant que consultant en sécurité et 8 ans en tant qu'instructeur principal pour SANS, enseignant des techniques offensives sur la façon de cibler et d'évaluer les organisations, les systèmes et les individus pour les faiblesses de sécurité. En 2016, il a été reconnu comme l'une des personnes les plus cool d'Australie dans le domaine de la technologie (Business Insider), a reçu le prix du professionnel de la cybersécurité de l'année (AISA - Australian Information Security Association) et détient les certifications GSE, CISSP, GCIH, GCFA, GSEC, GPEN, GWAPT, GCIA.
Une version de cet article a été publiée dans TechCrunch. Elle a été mise à jour et publiée ici.
Comme si nous n'avions pas eu assez de perturbations au cours de l'année qui ne peut être nommée, 2021 a commencé par un coup de tonnerre assourdissant pour le gouvernement américain, sous la forme de l'une des pires violations de données jamais enregistrées. L'incident SolarWinds est une attaque dévastatrice et sophistiquée d'un État-nation qui a semé la panique dans plusieurs ministères et grandes organisations, qui se sont empressés de sécuriser leurs points d'extrémité. Pratiquement tous les utilisateurs finaux du logiciel SolarWinds ont été compromis, et l'incident a montré très clairement que la cybersécurité et la défense des chaînes d'approvisionnement en logiciels sont essentielles.
Il est évident que la cybersécurité est importante, mais que signifie-t-elle réellement dans le contexte des chaînes d'approvisionnement ?
L'état de la cybersécurité dans l'équipe de développement moyenne
Une quantité énorme de logiciels est produite chaque jour, ce qui représente des milliards de lignes de code chaque année, et cela ne fait qu'augmenter avec la demande créée par nos modes de vie de plus en plus numériques. La population mondiale des développeurs devrait atteindre près de 29 millions de personnes d'ici à 2024, et il n'existe actuellement aucune certification officielle permettant d'évaluer et de certifier leur capacité à coder en toute sécurité. Cela ne veut pas dire que chaque développeur produit ou réutilise un code non sécurisé, mais il existe indubitablement un risque durable que des faiblesses de sécurité de base soient introduites dans les logiciels auxquels nous confions nos données.
Les développeurs sont évalués sur leur capacité à créer des fonctionnalités et à livrer le code le plus rapidement possible. La sécurité n'a pas été un critère de réussite dans la plupart des organisations, mais ce sentiment commence à changer car de plus en plus d'entreprises réalisent le potentiel qu'elles détiennent en matière de prévention des bogues de sécurité courants dès les premières étapes de la création de logiciels. Cependant, la prise de conscience et la mise en œuvre sont deux choses différentes, et comme la plupart des développements tertiaires courses ne contiennent aucun contexte sur les pratiques de codage sécurisé, c'est souvent au lieu de travail d'un développeur de combler les lacunes. Si le développement des compétences et le partage des connaissances sont peu fréquents ou non pertinents, ils seront probablement inefficaces. Ainsi, le cycle des vulnérabilités récurrentes dues au manque de développement des compétences reste ininterrompu.
Naturellement, il n'incombe pas au développeur de logiciels moyen de résoudre les problèmes de cybersécurité dans le monde ; après tout, ce n'est pas pour rien que les organisations embauchent des professionnels de la sécurité qui coûtent très cher. Les gourous de la sécurité se font rares, cependant, et les développeurs peuvent certainement jouer un rôle en réduisant la pression.
Mais où cela nous mène-t-il - ainsi que les fournisseurs qui créent des logiciels pour les infrastructures critiques et les organisations sensibles - en termes de prévention d'une cyberattaque dévastatrice ? Il faudra à tout le moins modifier le statu quo en matière d'achat de logiciels.
Les pièges qui entravent la sécurité de la chaîne d'approvisionnement en logiciels
L'adage selon lequel une chaîne est aussi solide que son maillon le plus faible est malheureusement tout aussi vrai lorsqu'il s'agit de l'approvisionnement en logiciels. Peu importe que votre entreprise ait renforcé ses meilleures pratiques en matière de sécurité, qu'elle ait investi dans la formation continue des développeurs et qu'elle ait évolué vers un environnement DevSecOps fonctionnel (c'est-à-dire que tout le monde partage la responsabilité de créer des logiciels aussi sûrs que possible) ; si vous utilisez des logiciels d'un fournisseur qui a des problèmes de sécurité, vous en hériterez dans votre écosystème et vous en subirez les conséquences.
Bien sûr, l'équipe de sécurité devrait aider à évaluer la sécurité des ajouts de tiers à la pile technologique, mais les décisions peuvent être prises sur la base d'un besoin commercial avec peu de choix parmi les solutions. À ce stade, il peut s'agir d'un exercice de confiance. Le fournisseur se préoccupe-t-il de la sécurité autant que votre entreprise ? Et peut-il réellement évaluer les risques comme vous seul pouvez les comprendre, ainsi que les actifs que vous devez protéger ?
La transparence est un facteur très important dans l'évaluation de la viabilité de la sécurité des ajouts logiciels des fournisseurs. Sont-ils francs quant à leurs propres pratiques en matière de sécurité? Ils doivent être fiers de leur approche en matière de sécurité des données et en faire une priorité absolue. Si les pratiques de sécurité ne sont publiées nulle part, ou si aucune information n'est disponible, il y a de fortes chances que la sécurité ne soit pas une priorité. Le fournisseur doit être en mesure de répondre aux questions techniques, et des certifications indépendantes telles que ISO27001 et SOC2 ne seraient pas de trop. Par ailleurs, si vous ne pouvez pas "regarder sous le capot" et rechercher les vulnérabilités dans le cadre de vos propres pratiques internes de diligence et de sécurité, laissez tomber.
La demande entraînant une mise en œuvre aussi rapide des besoins logiciels, en particulier si le code du fournisseur est intégré dans des systèmes existants pour effectuer des actions dans un nouveau contexte, le fournisseur et l'acheteur doivent tous deux être au sommet de leur art, et leurs développeurs doivent être sur le terrain pour détecter les bogues et les failles de sécurité les plus courants avant l'expédition. Des centaines - voire des milliers - de dépendances peuvent être compromises si un nouvel élément vient s'ajouter à la toile d'araignée des solutions technologiques existantes, et une petite défaillance peut conduire à une défaite catastrophique.
Quelle est donc la solution ? Tout coder en interne, à partir de zéro ? Si nous étions en 1998, cela pourrait avoir du sens. Cependant, de même que nous ne demandons plus à Jeeves où se trouve la station de lavage la plus proche, nous devons mettre en œuvre des mesures de protection réalistes qui fonctionnent dans le contexte d'aujourd'hui.
Il n'y a pas encore de solution miracle, mais il existe des solutions
Pour les acheteurs, la sécurité assessment des logiciels et des pratiques de développement des fournisseurs doit être une priorité du programme de sécurité global et du plan d'atténuation des risques. Posez des questions sur les certifications, les pratiques et la réputation de sécurité de leurs développeurs.
Les fournisseurs (et en fait toutes les entreprises qui créent des logiciels) doivent être prêts à démontrer que la sécurité est au centre de leurs préoccupations et doivent se concentrer sur la formation continue. Les développeurs compétents en matière de sécurité sont très demandés et, avec les outils et le soutien adéquats, ils peuvent être formés à partir de votre équipe existante et être habilités à se défendre contre les attaques résultant des vulnérabilités courantes. Mais ne leur donnez pas n'importe quelle formation. Donnez-leur le temps de s'épanouir avec des outils de sécurité qui complètent leurs flux de travail existants. Rendez les choses aussi simples que possible et observez les bogues gênants commencer à disparaître du code qui alimente l'entreprise.
En définitive, les risques liés aux logiciels sont immédiatement exacerbés s'ils font partie de la chaîne d'approvisionnement, affectant tous les utilisateurs et tous les systèmes où des composants vulnérables ont été utilisés. Si les fournisseurs ne sont pas aussi sérieux en matière de sécurité que les entreprises qui mettent en œuvre leurs logiciels - ou si le fournisseur et l'organisation présentent tous deux des lacunes dans leur programme de sécurité - des attaques de la chaîne d'approvisionnement plus dévastatrices et de plus grande portée comme celle de SolarWinds deviendront inévitablement la norme - et il s'agit là d'un problème critique pour tout le monde.
Table des matières
Directeur général, président et cofondateur
Secure Code Warrior est là pour vous aider à sécuriser le code tout au long du cycle de vie du développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Réservez une démonstrationTéléchargerRessources pour vous aider à démarrer
Évaluation comparative des compétences en matière de sécurité : Rationalisation de la conception sécurisée dans l'entreprise
Le mouvement "Secure-by-Design" (conception sécurisée) est l'avenir du développement de logiciels sécurisés. Découvrez les éléments clés que les entreprises doivent garder à l'esprit lorsqu'elles envisagent une initiative de conception sécurisée.
DigitalOcean réduit sa dette de sécurité avec Secure Code Warrior
L'utilisation par DigitalOcean de la formation Secure Code Warrior a considérablement réduit la dette de sécurité, permettant aux équipes de se concentrer davantage sur l'innovation et la productivité. L'amélioration de la sécurité a renforcé la qualité des produits et l'avantage concurrentiel de l'entreprise. À l'avenir, le score de confiance SCW les aidera à améliorer leurs pratiques de sécurité et à continuer à stimuler l'innovation.
Ressources pour vous aider à démarrer
La note de confiance révèle la valeur des initiatives d'amélioration de la sécurité par la conception
Nos recherches ont montré que la formation au code sécurisé fonctionne. Le Trust Score, qui utilise un algorithme s'appuyant sur plus de 20 millions de points de données d'apprentissage issus du travail de plus de 250 000 apprenants dans plus de 600 organisations, révèle son efficacité à réduire les vulnérabilités et la manière de rendre l'initiative encore plus efficace.
Sécurité réactive contre sécurité préventive : La prévention est un meilleur remède
L'idée d'apporter une sécurité préventive aux codes et systèmes existants en même temps qu'aux applications plus récentes peut sembler décourageante, mais une approche "Secure-by-Design", mise en œuvre en améliorant les compétences des développeurs, permet d'appliquer les meilleures pratiques de sécurité à ces systèmes. C'est la meilleure chance qu'ont de nombreuses organisations d'améliorer leur sécurité.
Les avantages de l'évaluation des compétences des développeurs en matière de sécurité
L'importance croissante accordée au code sécurisé et aux principes de conception sécurisée exige que les développeurs soient formés à la cybersécurité dès le début du cycle de développement durable, et que des outils tels que le Trust Score de Secure Code Warriorles aident à mesurer et à améliorer leurs progrès.
Assurer le succès des initiatives de conception sécurisée de l'entreprise
Notre dernier document de recherche, Benchmarking Security Skills : Streamlining Secure-by-Design in the Enterprise est le résultat d'une analyse approfondie d'initiatives réelles de conception sécurisée au niveau de l'entreprise, et de l'élaboration d'approches de meilleures pratiques basées sur des conclusions fondées sur des données.