Votre organisation est-elle vraiment prête pour le DevSec ? Mettez-la à l'épreuve.
Nous sommes à peine à la moitié de l'année 2020, et pourtant nous sommes déjà en passe d'établir un sinistre record en matière de violation de données, avec une augmentation de 273 % des données volées par rapport au premier semestre 2019. De nos jours, il est plus juste de se demander combien de données n 'ont pas encore été volées. Avec des événements mondiaux comme la pandémie de COVID-19, ces attaques n'ont fait qu'augmenter en fréquence et en puissance, avec des cibles de plus en plus vulnérables.
Nous le savons tous depuis un certain temps : la sécurité n'est plus facultative et nous devons nous concentrer sur une attaque préventive. Pour que cela soit efficace, tous les acteurs du cycle de développement logiciel doivent être sensibilisés à la sécurité, en particulier les développeurs. C'est la partie "DevSec" de DevSecOps, une méthodologie de développement logiciel idéale pour le climat, mais de nombreuses organisations ne sont pas entièrement préparées pour l'exécuter efficacement.
En gardant votre organisation à l'esprit, réfléchissez à ces questions dans le contexte de votre rôle. Comment se comporterait-il lorsqu'il est soumis au test DevSec ?
DevSec Self-Assessment: Votre jardin SDLC est-il prêt à accueillir des ingénieurs sensibilisés à la sécurité ?
- La sécurité est-elle au cœur du processus de développement interne ?
Une série de facteurs de risque de cybersécurité peut empêcher le RSSI moyen de dormir, mais la réalité préoccupante est que, bien que de nombreuses entreprises fassent de la sécurité une priorité, leur approche interne n'est peut-être pas assez solide pour atténuer un désastre potentiel (ou, du moins, des maux de tête massifs pour l'équipe AppSec et des retards dans la livraison des logiciels).
DevSecOps est peut-être l'état actuel du nirvana de la sécurité, mais peu d'entreprises travaillent avec cette méthodologie. Si vous êtes encore en mode Agile - ou même en mode Waterfall - la sécurité est souvent considérée comme le domaine de spécialistes éloignés du processus et activés tardivement dans le SDLC, surgissant pour gâcher la journée d'un développeur avec des correctifs pour son code. Dans un tel environnement, il sera difficile d'instaurer une culture DevSec : les développeurs aiment et donnent la priorité à la création de fonctionnalités, et n'auront tout simplement pas eu assez d'expérience pratique de la sécurité pour la considérer comme une voie de perfectionnement souhaitable. En fait, leurs contacts avec la sécurité peuvent être empreints de frustration et de négativité. Il faut y remédier rapidement afin d'instiller une approche de premier plan pour toutes les personnes impliquées dans le processus de développement de logiciels.
- Votre organisation est-elle encore en train de rattraper son retard en matière de modélisation des menaces ?
Les statistiques sont inquiétantes : 60 % des PME cessent leurs activités dans les six mois qui suivent une cyberattaque réussie et, comme pour d'autres catastrophes, l'impact est bien plus important sans une planification adéquate.
La modélisation des menaces est un élément crucial des meilleures pratiques de sécurité, qui permet aux professionnels de l'AppSec d'évaluer toute l'étendue de la surface d'attaque et de structurer les défenses, les contre-mesures et la planification appropriées. Dans les entreprises qui ont pleinement adopté DevSecOps, la sécurité est activée dès le début du pipeline CI/CD, de manière à ne pas ralentir la production autant que par le passé. La sécurité, le codage sécurisé et la livraison continue font tous partie du processus, et les équipes de développement reçoivent les ressources et l'exposition nécessaires pour être des composants majeurs du moteur qui crache un code étanche.
- Les responsables du développement accordent-ils la priorité aux meilleures pratiques en matière de sécurité ?
Qu'ils le veuillent ou non, les responsables du développement sont des modèles pour leur équipe. Et ce n'est pas seulement une question de culture et d'ambiance, comme le fait de porter des tongs au bureau ou la façon dont ils "gèrent vers le haut". Leurs priorités de travail seront inévitablement absorbées par les membres de leur équipe, et si la sécurité ne fait pas partie des objectifs clés, ou n'est pas planifiée en termes de formation et de soutien, alors les ingénieurs en dessous d'eux manqueront à l'appel, et l'entreprise sera plus en danger qu'elle ne devrait l'être.
- Les développeurs ont-ils une raison de se préoccuper de la sécurité ?
D'après mon expérience, le moyen le plus rapide de mettre quelqu'un hors-jeu est de lui dire qu'il doit faire quelque chose qui n'a rien à voir avec son approche actuelle, sans lui dire pourquoi.
Le fait de devoir "changer" implique que l'approche précédente était erronée, alors que dans de nombreux cas, il s'agit simplement d'une amélioration qui, espérons-le, rendra les choses plus faciles et plus efficaces par la suite. Pour adopter véritablement le mouvement DevSec, il faut donner aux développeurs une raison de se préoccuper de la sécurité en premier lieu - après tout, dans la plupart des organisations, c'est encore le "problème de quelqu'un d'autre" (c'est-à-dire les magiciens de l'AppSec enfermés dans une autre pièce, loin, très loin, très loin).
DevSecOps ne fonctionne tout simplement pas si la sécurité n'est pas une responsabilité partagée. Les développeurs ont besoin des bons outils, du support et de la formation pour faire leur part... et cela demande du temps pour être déployé et perfectionné dans le cadre d'un programme de sécurité global. La pire approche est celle qui submerge et aliène, ce qui peut être le cas lorsque les développeurs ont trop de priorités concurrentes et aucune aide pour les gérer sans se rendre fous. Il s'agit d'un changement culturel qui ne se fera pas du jour au lendemain.
- Comptez-vous sur une poignée de licornes magiques de la sécurité pour prendre en charge la tâche d'un grand nombre de personnes ?
Les professionnels de la sécurité sont très rares, et nous en avons besoin de beaucoup plus que ce qui est actuellement disponible. C'est une évidence, mais un nombre croissant de développeurs s'orientent vers des fonctions plus axées sur la sécurité. En règle générale, ils portent des titres tels que "ingénieur en sécurité" ou "ingénieur DevOps" (avec un peu de chance, nous verrons ce titre se transformer en ingénieur DevSecOps). Un ingénieur DevOps est capable de développer des fonctionnalités pour pratiquement n'importe quelle application, tout en la déployant à l'aide d'un véritable pipeline CI/CD. Il s'occupe de tout de bout en bout et est généralement doté d'une bonne dose de sensibilisation à la sécurité. En ce sens, ils sont un peu magiques, et donc rares.
Cependant, certaines entreprises font l'erreur d'embaucher ces ingénieurs spécialisés, de les intégrer dans une équipe et de s'attendre à ce qu'ils s'occupent de tous les problèmes de sécurité, à chaque étape du processus de développement, et qu'ils soient la panacée. Surchargez vos magiciens DevSecOps et vous vous retrouverez au même point qu'au début : vous livrerez un code non sécurisé sans les contrôles, les équilibres et la précision de sécurité pour lesquels ils ont été embauchés. Il est de la plus haute importance que l'équipe de développement en général soit perfectionnée et nourrie dans un environnement de sécurité positif afin qu'elle soit équipée pour partager la charge de manière significative.
Trouvez le changement que vous souhaitez voir s'opérer dans votre organisation.
Si vous mettez en place une formation solide dans le cadre de votre programme de sécurité, vous découvrirez quelques joyaux cachés dans votre cohorte de développement. Il s'agit des personnes qui, malgré les expériences négatives qu'elles ont pu avoir dans leur travail quotidien, ont une certaine passion pour le codage sécurisé et les meilleures pratiques en matière de sécurité. Ces personnes sont des candidats de choix pour devenir des champions de la sécurité au sein de l'équipe ; un point de contact entre la sécurité et l'ingénierie qui montre l'exemple aux autres, maintient la sensibilisation à un niveau élevé et contribue aux initiatives d'engagement. Leurs compétences interpersonnelles sont également très importantes pour diffuser largement la joie de la sécurité et défendre les besoins des développeurs auprès de la direction et de l'équipe de sécurité.
La conversation "qu'est-ce que j'y gagne ?" est un pas en avant positif.
Même les êtres humains les plus nobles ont besoin d'une "carotte" pour s'aventurer en terrain inconnu ou dans une activité dont la courbe d'apprentissage n'est pas des plus agréables.
Faire le saut de "dev" à "DevSec" est un formidable coup de pouce pour la carrière d'un développeur. Les développeurs sensibilisés à la sécurité ont travaillé dur pour comprendre la sécurité, en assumer la responsabilité dans les domaines qu'ils peuvent contrôler et travailler en sachant que le seul code de qualité est un code sécurisé. En général, les développeurs veulent s'améliorer, s'attaquer à de nouveaux problèmes et créer des fonctionnalités enviables qui les aident à se démarquer de leurs pairs. Donnez-leur la possibilité d'atteindre un niveau plus élevé de développement logiciel, et vous obtiendrez une situation gagnant-gagnant.
Il n'est jamais trop tard pour constituer votre équipe de rêve DevSec.
Si vous gérez des développeurs, si vous dirigez une équipe de sensibilisation à l'AppSec ou si vous êtes l'un des nombreux cerveaux qui travaillent à l'élaboration de stratégies de programmes de sécurité, le moment est venu de faire mieux que de "passer" à gauche. Avec la formation, les outils et l'environnement adéquats, vous pouvez créer un incubateur de sécurité pour les développeurs qui rapportera beaucoup à toutes les parties. Si cette liste de contrôle a mis en évidence certains points à améliorer, vous avez une excellente occasion de préparer votre organisation à un service d'ingénierie dirigé par DevSec et capable de réduire les risques dès le début du cycle de développement durable (SDLC).
En gardant votre organisation à l'esprit, réfléchissez à ces questions dans le contexte de votre rôle. Comment se comporterait-il lorsqu'il est soumis au test DevSec ?
Matias Madou est expert en sécurité, chercheur, directeur technique et cofondateur de Secure Code Warrior. Matias a obtenu son doctorat en sécurité des applications à l'université de Gand, en se concentrant sur les solutions d'analyse statique. Il a ensuite rejoint Fortify aux États-Unis, où il s'est rendu compte qu'il ne suffisait pas de détecter les problèmes de code sans aider les développeurs à écrire du code sécurisé. C'est ce qui l'a incité à développer des produits qui aident les développeurs, allègent le fardeau de la sécurité et dépassent les attentes des clients. Lorsqu'il n'est pas à son bureau en tant que membre de l'équipe Awesome, il aime être sur scène pour présenter des conférences, notamment RSA Conference, BlackHat et DefCon.
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émonstrationMatias Madou est expert en sécurité, chercheur, directeur technique et cofondateur de Secure Code Warrior. Matias a obtenu son doctorat en sécurité des applications à l'université de Gand, en se concentrant sur les solutions d'analyse statique. Il a ensuite rejoint Fortify aux États-Unis, où il s'est rendu compte qu'il ne suffisait pas de détecter les problèmes de code sans aider les développeurs à écrire du code sécurisé. C'est ce qui l'a incité à développer des produits qui aident les développeurs, allègent le fardeau de la sécurité et dépassent les attentes des clients. Lorsqu'il n'est pas à son bureau en tant que membre de l'équipe Awesome, il aime être sur scène pour présenter des conférences, notamment RSA Conference, BlackHat et DefCon.
Matias est un chercheur et un développeur qui possède plus de 15 ans d'expérience pratique dans le domaine de la sécurité des logiciels. Il a développé des solutions pour des entreprises telles que Fortify Software et sa propre entreprise Sensei Security. Au cours de sa carrière, Matias a dirigé de nombreux projets de recherche sur la sécurité des applications qui ont débouché sur des produits commerciaux et peut se targuer d'avoir déposé plus de 10 brevets. Lorsqu'il n'est pas à son bureau, Matias a été instructeur pour des formations avancées en matière de sécurité des applications ( courses ) et intervient régulièrement lors de conférences mondiales telles que RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec et BruCon.
Matias est titulaire d'un doctorat en ingénierie informatique de l'Université de Gand, où il a étudié la sécurité des applications par le biais de l'obscurcissement des programmes afin de dissimuler le fonctionnement interne d'une application.
Nous sommes à peine à la moitié de l'année 2020, et pourtant nous sommes déjà en passe d'établir un sinistre record en matière de violation de données, avec une augmentation de 273 % des données volées par rapport au premier semestre 2019. De nos jours, il est plus juste de se demander combien de données n 'ont pas encore été volées. Avec des événements mondiaux comme la pandémie de COVID-19, ces attaques n'ont fait qu'augmenter en fréquence et en puissance, avec des cibles de plus en plus vulnérables.
Nous le savons tous depuis un certain temps : la sécurité n'est plus facultative et nous devons nous concentrer sur une attaque préventive. Pour que cela soit efficace, tous les acteurs du cycle de développement logiciel doivent être sensibilisés à la sécurité, en particulier les développeurs. C'est la partie "DevSec" de DevSecOps, une méthodologie de développement logiciel idéale pour le climat, mais de nombreuses organisations ne sont pas entièrement préparées pour l'exécuter efficacement.
En gardant votre organisation à l'esprit, réfléchissez à ces questions dans le contexte de votre rôle. Comment se comporterait-il lorsqu'il est soumis au test DevSec ?
DevSec Self-Assessment: Votre jardin SDLC est-il prêt à accueillir des ingénieurs sensibilisés à la sécurité ?
- La sécurité est-elle au cœur du processus de développement interne ?
Une série de facteurs de risque de cybersécurité peut empêcher le RSSI moyen de dormir, mais la réalité préoccupante est que, bien que de nombreuses entreprises fassent de la sécurité une priorité, leur approche interne n'est peut-être pas assez solide pour atténuer un désastre potentiel (ou, du moins, des maux de tête massifs pour l'équipe AppSec et des retards dans la livraison des logiciels).
DevSecOps est peut-être l'état actuel du nirvana de la sécurité, mais peu d'entreprises travaillent avec cette méthodologie. Si vous êtes encore en mode Agile - ou même en mode Waterfall - la sécurité est souvent considérée comme le domaine de spécialistes éloignés du processus et activés tardivement dans le SDLC, surgissant pour gâcher la journée d'un développeur avec des correctifs pour son code. Dans un tel environnement, il sera difficile d'instaurer une culture DevSec : les développeurs aiment et donnent la priorité à la création de fonctionnalités, et n'auront tout simplement pas eu assez d'expérience pratique de la sécurité pour la considérer comme une voie de perfectionnement souhaitable. En fait, leurs contacts avec la sécurité peuvent être empreints de frustration et de négativité. Il faut y remédier rapidement afin d'instiller une approche de premier plan pour toutes les personnes impliquées dans le processus de développement de logiciels.
- Votre organisation est-elle encore en train de rattraper son retard en matière de modélisation des menaces ?
Les statistiques sont inquiétantes : 60 % des PME cessent leurs activités dans les six mois qui suivent une cyberattaque réussie et, comme pour d'autres catastrophes, l'impact est bien plus important sans une planification adéquate.
La modélisation des menaces est un élément crucial des meilleures pratiques de sécurité, qui permet aux professionnels de l'AppSec d'évaluer toute l'étendue de la surface d'attaque et de structurer les défenses, les contre-mesures et la planification appropriées. Dans les entreprises qui ont pleinement adopté DevSecOps, la sécurité est activée dès le début du pipeline CI/CD, de manière à ne pas ralentir la production autant que par le passé. La sécurité, le codage sécurisé et la livraison continue font tous partie du processus, et les équipes de développement reçoivent les ressources et l'exposition nécessaires pour être des composants majeurs du moteur qui crache un code étanche.
- Les responsables du développement accordent-ils la priorité aux meilleures pratiques en matière de sécurité ?
Qu'ils le veuillent ou non, les responsables du développement sont des modèles pour leur équipe. Et ce n'est pas seulement une question de culture et d'ambiance, comme le fait de porter des tongs au bureau ou la façon dont ils "gèrent vers le haut". Leurs priorités de travail seront inévitablement absorbées par les membres de leur équipe, et si la sécurité ne fait pas partie des objectifs clés, ou n'est pas planifiée en termes de formation et de soutien, alors les ingénieurs en dessous d'eux manqueront à l'appel, et l'entreprise sera plus en danger qu'elle ne devrait l'être.
- Les développeurs ont-ils une raison de se préoccuper de la sécurité ?
D'après mon expérience, le moyen le plus rapide de mettre quelqu'un hors-jeu est de lui dire qu'il doit faire quelque chose qui n'a rien à voir avec son approche actuelle, sans lui dire pourquoi.
Le fait de devoir "changer" implique que l'approche précédente était erronée, alors que dans de nombreux cas, il s'agit simplement d'une amélioration qui, espérons-le, rendra les choses plus faciles et plus efficaces par la suite. Pour adopter véritablement le mouvement DevSec, il faut donner aux développeurs une raison de se préoccuper de la sécurité en premier lieu - après tout, dans la plupart des organisations, c'est encore le "problème de quelqu'un d'autre" (c'est-à-dire les magiciens de l'AppSec enfermés dans une autre pièce, loin, très loin, très loin).
DevSecOps ne fonctionne tout simplement pas si la sécurité n'est pas une responsabilité partagée. Les développeurs ont besoin des bons outils, du support et de la formation pour faire leur part... et cela demande du temps pour être déployé et perfectionné dans le cadre d'un programme de sécurité global. La pire approche est celle qui submerge et aliène, ce qui peut être le cas lorsque les développeurs ont trop de priorités concurrentes et aucune aide pour les gérer sans se rendre fous. Il s'agit d'un changement culturel qui ne se fera pas du jour au lendemain.
- Comptez-vous sur une poignée de licornes magiques de la sécurité pour prendre en charge la tâche d'un grand nombre de personnes ?
Les professionnels de la sécurité sont très rares, et nous en avons besoin de beaucoup plus que ce qui est actuellement disponible. C'est une évidence, mais un nombre croissant de développeurs s'orientent vers des fonctions plus axées sur la sécurité. En règle générale, ils portent des titres tels que "ingénieur en sécurité" ou "ingénieur DevOps" (avec un peu de chance, nous verrons ce titre se transformer en ingénieur DevSecOps). Un ingénieur DevOps est capable de développer des fonctionnalités pour pratiquement n'importe quelle application, tout en la déployant à l'aide d'un véritable pipeline CI/CD. Il s'occupe de tout de bout en bout et est généralement doté d'une bonne dose de sensibilisation à la sécurité. En ce sens, ils sont un peu magiques, et donc rares.
Cependant, certaines entreprises font l'erreur d'embaucher ces ingénieurs spécialisés, de les intégrer dans une équipe et de s'attendre à ce qu'ils s'occupent de tous les problèmes de sécurité, à chaque étape du processus de développement, et qu'ils soient la panacée. Surchargez vos magiciens DevSecOps et vous vous retrouverez au même point qu'au début : vous livrerez un code non sécurisé sans les contrôles, les équilibres et la précision de sécurité pour lesquels ils ont été embauchés. Il est de la plus haute importance que l'équipe de développement en général soit perfectionnée et nourrie dans un environnement de sécurité positif afin qu'elle soit équipée pour partager la charge de manière significative.
Trouvez le changement que vous souhaitez voir s'opérer dans votre organisation.
Si vous mettez en place une formation solide dans le cadre de votre programme de sécurité, vous découvrirez quelques joyaux cachés dans votre cohorte de développement. Il s'agit des personnes qui, malgré les expériences négatives qu'elles ont pu avoir dans leur travail quotidien, ont une certaine passion pour le codage sécurisé et les meilleures pratiques en matière de sécurité. Ces personnes sont des candidats de choix pour devenir des champions de la sécurité au sein de l'équipe ; un point de contact entre la sécurité et l'ingénierie qui montre l'exemple aux autres, maintient la sensibilisation à un niveau élevé et contribue aux initiatives d'engagement. Leurs compétences interpersonnelles sont également très importantes pour diffuser largement la joie de la sécurité et défendre les besoins des développeurs auprès de la direction et de l'équipe de sécurité.
La conversation "qu'est-ce que j'y gagne ?" est un pas en avant positif.
Même les êtres humains les plus nobles ont besoin d'une "carotte" pour s'aventurer en terrain inconnu ou dans une activité dont la courbe d'apprentissage n'est pas des plus agréables.
Faire le saut de "dev" à "DevSec" est un formidable coup de pouce pour la carrière d'un développeur. Les développeurs sensibilisés à la sécurité ont travaillé dur pour comprendre la sécurité, en assumer la responsabilité dans les domaines qu'ils peuvent contrôler et travailler en sachant que le seul code de qualité est un code sécurisé. En général, les développeurs veulent s'améliorer, s'attaquer à de nouveaux problèmes et créer des fonctionnalités enviables qui les aident à se démarquer de leurs pairs. Donnez-leur la possibilité d'atteindre un niveau plus élevé de développement logiciel, et vous obtiendrez une situation gagnant-gagnant.
Il n'est jamais trop tard pour constituer votre équipe de rêve DevSec.
Si vous gérez des développeurs, si vous dirigez une équipe de sensibilisation à l'AppSec ou si vous êtes l'un des nombreux cerveaux qui travaillent à l'élaboration de stratégies de programmes de sécurité, le moment est venu de faire mieux que de "passer" à gauche. Avec la formation, les outils et l'environnement adéquats, vous pouvez créer un incubateur de sécurité pour les développeurs qui rapportera beaucoup à toutes les parties. Si cette liste de contrôle a mis en évidence certains points à améliorer, vous avez une excellente occasion de préparer votre organisation à un service d'ingénierie dirigé par DevSec et capable de réduire les risques dès le début du cycle de développement durable (SDLC).
Nous sommes à peine à la moitié de l'année 2020, et pourtant nous sommes déjà en passe d'établir un sinistre record en matière de violation de données, avec une augmentation de 273 % des données volées par rapport au premier semestre 2019. De nos jours, il est plus juste de se demander combien de données n 'ont pas encore été volées. Avec des événements mondiaux comme la pandémie de COVID-19, ces attaques n'ont fait qu'augmenter en fréquence et en puissance, avec des cibles de plus en plus vulnérables.
Nous le savons tous depuis un certain temps : la sécurité n'est plus facultative et nous devons nous concentrer sur une attaque préventive. Pour que cela soit efficace, tous les acteurs du cycle de développement logiciel doivent être sensibilisés à la sécurité, en particulier les développeurs. C'est la partie "DevSec" de DevSecOps, une méthodologie de développement logiciel idéale pour le climat, mais de nombreuses organisations ne sont pas entièrement préparées pour l'exécuter efficacement.
En gardant votre organisation à l'esprit, réfléchissez à ces questions dans le contexte de votre rôle. Comment se comporterait-il lorsqu'il est soumis au test DevSec ?
DevSec Self-Assessment: Votre jardin SDLC est-il prêt à accueillir des ingénieurs sensibilisés à la sécurité ?
- La sécurité est-elle au cœur du processus de développement interne ?
Une série de facteurs de risque de cybersécurité peut empêcher le RSSI moyen de dormir, mais la réalité préoccupante est que, bien que de nombreuses entreprises fassent de la sécurité une priorité, leur approche interne n'est peut-être pas assez solide pour atténuer un désastre potentiel (ou, du moins, des maux de tête massifs pour l'équipe AppSec et des retards dans la livraison des logiciels).
DevSecOps est peut-être l'état actuel du nirvana de la sécurité, mais peu d'entreprises travaillent avec cette méthodologie. Si vous êtes encore en mode Agile - ou même en mode Waterfall - la sécurité est souvent considérée comme le domaine de spécialistes éloignés du processus et activés tardivement dans le SDLC, surgissant pour gâcher la journée d'un développeur avec des correctifs pour son code. Dans un tel environnement, il sera difficile d'instaurer une culture DevSec : les développeurs aiment et donnent la priorité à la création de fonctionnalités, et n'auront tout simplement pas eu assez d'expérience pratique de la sécurité pour la considérer comme une voie de perfectionnement souhaitable. En fait, leurs contacts avec la sécurité peuvent être empreints de frustration et de négativité. Il faut y remédier rapidement afin d'instiller une approche de premier plan pour toutes les personnes impliquées dans le processus de développement de logiciels.
- Votre organisation est-elle encore en train de rattraper son retard en matière de modélisation des menaces ?
Les statistiques sont inquiétantes : 60 % des PME cessent leurs activités dans les six mois qui suivent une cyberattaque réussie et, comme pour d'autres catastrophes, l'impact est bien plus important sans une planification adéquate.
La modélisation des menaces est un élément crucial des meilleures pratiques de sécurité, qui permet aux professionnels de l'AppSec d'évaluer toute l'étendue de la surface d'attaque et de structurer les défenses, les contre-mesures et la planification appropriées. Dans les entreprises qui ont pleinement adopté DevSecOps, la sécurité est activée dès le début du pipeline CI/CD, de manière à ne pas ralentir la production autant que par le passé. La sécurité, le codage sécurisé et la livraison continue font tous partie du processus, et les équipes de développement reçoivent les ressources et l'exposition nécessaires pour être des composants majeurs du moteur qui crache un code étanche.
- Les responsables du développement accordent-ils la priorité aux meilleures pratiques en matière de sécurité ?
Qu'ils le veuillent ou non, les responsables du développement sont des modèles pour leur équipe. Et ce n'est pas seulement une question de culture et d'ambiance, comme le fait de porter des tongs au bureau ou la façon dont ils "gèrent vers le haut". Leurs priorités de travail seront inévitablement absorbées par les membres de leur équipe, et si la sécurité ne fait pas partie des objectifs clés, ou n'est pas planifiée en termes de formation et de soutien, alors les ingénieurs en dessous d'eux manqueront à l'appel, et l'entreprise sera plus en danger qu'elle ne devrait l'être.
- Les développeurs ont-ils une raison de se préoccuper de la sécurité ?
D'après mon expérience, le moyen le plus rapide de mettre quelqu'un hors-jeu est de lui dire qu'il doit faire quelque chose qui n'a rien à voir avec son approche actuelle, sans lui dire pourquoi.
Le fait de devoir "changer" implique que l'approche précédente était erronée, alors que dans de nombreux cas, il s'agit simplement d'une amélioration qui, espérons-le, rendra les choses plus faciles et plus efficaces par la suite. Pour adopter véritablement le mouvement DevSec, il faut donner aux développeurs une raison de se préoccuper de la sécurité en premier lieu - après tout, dans la plupart des organisations, c'est encore le "problème de quelqu'un d'autre" (c'est-à-dire les magiciens de l'AppSec enfermés dans une autre pièce, loin, très loin, très loin).
DevSecOps ne fonctionne tout simplement pas si la sécurité n'est pas une responsabilité partagée. Les développeurs ont besoin des bons outils, du support et de la formation pour faire leur part... et cela demande du temps pour être déployé et perfectionné dans le cadre d'un programme de sécurité global. La pire approche est celle qui submerge et aliène, ce qui peut être le cas lorsque les développeurs ont trop de priorités concurrentes et aucune aide pour les gérer sans se rendre fous. Il s'agit d'un changement culturel qui ne se fera pas du jour au lendemain.
- Comptez-vous sur une poignée de licornes magiques de la sécurité pour prendre en charge la tâche d'un grand nombre de personnes ?
Les professionnels de la sécurité sont très rares, et nous en avons besoin de beaucoup plus que ce qui est actuellement disponible. C'est une évidence, mais un nombre croissant de développeurs s'orientent vers des fonctions plus axées sur la sécurité. En règle générale, ils portent des titres tels que "ingénieur en sécurité" ou "ingénieur DevOps" (avec un peu de chance, nous verrons ce titre se transformer en ingénieur DevSecOps). Un ingénieur DevOps est capable de développer des fonctionnalités pour pratiquement n'importe quelle application, tout en la déployant à l'aide d'un véritable pipeline CI/CD. Il s'occupe de tout de bout en bout et est généralement doté d'une bonne dose de sensibilisation à la sécurité. En ce sens, ils sont un peu magiques, et donc rares.
Cependant, certaines entreprises font l'erreur d'embaucher ces ingénieurs spécialisés, de les intégrer dans une équipe et de s'attendre à ce qu'ils s'occupent de tous les problèmes de sécurité, à chaque étape du processus de développement, et qu'ils soient la panacée. Surchargez vos magiciens DevSecOps et vous vous retrouverez au même point qu'au début : vous livrerez un code non sécurisé sans les contrôles, les équilibres et la précision de sécurité pour lesquels ils ont été embauchés. Il est de la plus haute importance que l'équipe de développement en général soit perfectionnée et nourrie dans un environnement de sécurité positif afin qu'elle soit équipée pour partager la charge de manière significative.
Trouvez le changement que vous souhaitez voir s'opérer dans votre organisation.
Si vous mettez en place une formation solide dans le cadre de votre programme de sécurité, vous découvrirez quelques joyaux cachés dans votre cohorte de développement. Il s'agit des personnes qui, malgré les expériences négatives qu'elles ont pu avoir dans leur travail quotidien, ont une certaine passion pour le codage sécurisé et les meilleures pratiques en matière de sécurité. Ces personnes sont des candidats de choix pour devenir des champions de la sécurité au sein de l'équipe ; un point de contact entre la sécurité et l'ingénierie qui montre l'exemple aux autres, maintient la sensibilisation à un niveau élevé et contribue aux initiatives d'engagement. Leurs compétences interpersonnelles sont également très importantes pour diffuser largement la joie de la sécurité et défendre les besoins des développeurs auprès de la direction et de l'équipe de sécurité.
La conversation "qu'est-ce que j'y gagne ?" est un pas en avant positif.
Même les êtres humains les plus nobles ont besoin d'une "carotte" pour s'aventurer en terrain inconnu ou dans une activité dont la courbe d'apprentissage n'est pas des plus agréables.
Faire le saut de "dev" à "DevSec" est un formidable coup de pouce pour la carrière d'un développeur. Les développeurs sensibilisés à la sécurité ont travaillé dur pour comprendre la sécurité, en assumer la responsabilité dans les domaines qu'ils peuvent contrôler et travailler en sachant que le seul code de qualité est un code sécurisé. En général, les développeurs veulent s'améliorer, s'attaquer à de nouveaux problèmes et créer des fonctionnalités enviables qui les aident à se démarquer de leurs pairs. Donnez-leur la possibilité d'atteindre un niveau plus élevé de développement logiciel, et vous obtiendrez une situation gagnant-gagnant.
Il n'est jamais trop tard pour constituer votre équipe de rêve DevSec.
Si vous gérez des développeurs, si vous dirigez une équipe de sensibilisation à l'AppSec ou si vous êtes l'un des nombreux cerveaux qui travaillent à l'élaboration de stratégies de programmes de sécurité, le moment est venu de faire mieux que de "passer" à gauche. Avec la formation, les outils et l'environnement adéquats, vous pouvez créer un incubateur de sécurité pour les développeurs qui rapportera beaucoup à toutes les parties. Si cette liste de contrôle a mis en évidence certains points à améliorer, vous avez une excellente occasion de préparer votre organisation à un service d'ingénierie dirigé par DevSec et capable de réduire les risques dès le début du cycle de développement durable (SDLC).
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émonstrationMatias Madou est expert en sécurité, chercheur, directeur technique et cofondateur de Secure Code Warrior. Matias a obtenu son doctorat en sécurité des applications à l'université de Gand, en se concentrant sur les solutions d'analyse statique. Il a ensuite rejoint Fortify aux États-Unis, où il s'est rendu compte qu'il ne suffisait pas de détecter les problèmes de code sans aider les développeurs à écrire du code sécurisé. C'est ce qui l'a incité à développer des produits qui aident les développeurs, allègent le fardeau de la sécurité et dépassent les attentes des clients. Lorsqu'il n'est pas à son bureau en tant que membre de l'équipe Awesome, il aime être sur scène pour présenter des conférences, notamment RSA Conference, BlackHat et DefCon.
Matias est un chercheur et un développeur qui possède plus de 15 ans d'expérience pratique dans le domaine de la sécurité des logiciels. Il a développé des solutions pour des entreprises telles que Fortify Software et sa propre entreprise Sensei Security. Au cours de sa carrière, Matias a dirigé de nombreux projets de recherche sur la sécurité des applications qui ont débouché sur des produits commerciaux et peut se targuer d'avoir déposé plus de 10 brevets. Lorsqu'il n'est pas à son bureau, Matias a été instructeur pour des formations avancées en matière de sécurité des applications ( courses ) et intervient régulièrement lors de conférences mondiales telles que RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec et BruCon.
Matias est titulaire d'un doctorat en ingénierie informatique de l'Université de Gand, où il a étudié la sécurité des applications par le biais de l'obscurcissement des programmes afin de dissimuler le fonctionnement interne d'une application.
Nous sommes à peine à la moitié de l'année 2020, et pourtant nous sommes déjà en passe d'établir un sinistre record en matière de violation de données, avec une augmentation de 273 % des données volées par rapport au premier semestre 2019. De nos jours, il est plus juste de se demander combien de données n 'ont pas encore été volées. Avec des événements mondiaux comme la pandémie de COVID-19, ces attaques n'ont fait qu'augmenter en fréquence et en puissance, avec des cibles de plus en plus vulnérables.
Nous le savons tous depuis un certain temps : la sécurité n'est plus facultative et nous devons nous concentrer sur une attaque préventive. Pour que cela soit efficace, tous les acteurs du cycle de développement logiciel doivent être sensibilisés à la sécurité, en particulier les développeurs. C'est la partie "DevSec" de DevSecOps, une méthodologie de développement logiciel idéale pour le climat, mais de nombreuses organisations ne sont pas entièrement préparées pour l'exécuter efficacement.
En gardant votre organisation à l'esprit, réfléchissez à ces questions dans le contexte de votre rôle. Comment se comporterait-il lorsqu'il est soumis au test DevSec ?
DevSec Self-Assessment: Votre jardin SDLC est-il prêt à accueillir des ingénieurs sensibilisés à la sécurité ?
- La sécurité est-elle au cœur du processus de développement interne ?
Une série de facteurs de risque de cybersécurité peut empêcher le RSSI moyen de dormir, mais la réalité préoccupante est que, bien que de nombreuses entreprises fassent de la sécurité une priorité, leur approche interne n'est peut-être pas assez solide pour atténuer un désastre potentiel (ou, du moins, des maux de tête massifs pour l'équipe AppSec et des retards dans la livraison des logiciels).
DevSecOps est peut-être l'état actuel du nirvana de la sécurité, mais peu d'entreprises travaillent avec cette méthodologie. Si vous êtes encore en mode Agile - ou même en mode Waterfall - la sécurité est souvent considérée comme le domaine de spécialistes éloignés du processus et activés tardivement dans le SDLC, surgissant pour gâcher la journée d'un développeur avec des correctifs pour son code. Dans un tel environnement, il sera difficile d'instaurer une culture DevSec : les développeurs aiment et donnent la priorité à la création de fonctionnalités, et n'auront tout simplement pas eu assez d'expérience pratique de la sécurité pour la considérer comme une voie de perfectionnement souhaitable. En fait, leurs contacts avec la sécurité peuvent être empreints de frustration et de négativité. Il faut y remédier rapidement afin d'instiller une approche de premier plan pour toutes les personnes impliquées dans le processus de développement de logiciels.
- Votre organisation est-elle encore en train de rattraper son retard en matière de modélisation des menaces ?
Les statistiques sont inquiétantes : 60 % des PME cessent leurs activités dans les six mois qui suivent une cyberattaque réussie et, comme pour d'autres catastrophes, l'impact est bien plus important sans une planification adéquate.
La modélisation des menaces est un élément crucial des meilleures pratiques de sécurité, qui permet aux professionnels de l'AppSec d'évaluer toute l'étendue de la surface d'attaque et de structurer les défenses, les contre-mesures et la planification appropriées. Dans les entreprises qui ont pleinement adopté DevSecOps, la sécurité est activée dès le début du pipeline CI/CD, de manière à ne pas ralentir la production autant que par le passé. La sécurité, le codage sécurisé et la livraison continue font tous partie du processus, et les équipes de développement reçoivent les ressources et l'exposition nécessaires pour être des composants majeurs du moteur qui crache un code étanche.
- Les responsables du développement accordent-ils la priorité aux meilleures pratiques en matière de sécurité ?
Qu'ils le veuillent ou non, les responsables du développement sont des modèles pour leur équipe. Et ce n'est pas seulement une question de culture et d'ambiance, comme le fait de porter des tongs au bureau ou la façon dont ils "gèrent vers le haut". Leurs priorités de travail seront inévitablement absorbées par les membres de leur équipe, et si la sécurité ne fait pas partie des objectifs clés, ou n'est pas planifiée en termes de formation et de soutien, alors les ingénieurs en dessous d'eux manqueront à l'appel, et l'entreprise sera plus en danger qu'elle ne devrait l'être.
- Les développeurs ont-ils une raison de se préoccuper de la sécurité ?
D'après mon expérience, le moyen le plus rapide de mettre quelqu'un hors-jeu est de lui dire qu'il doit faire quelque chose qui n'a rien à voir avec son approche actuelle, sans lui dire pourquoi.
Le fait de devoir "changer" implique que l'approche précédente était erronée, alors que dans de nombreux cas, il s'agit simplement d'une amélioration qui, espérons-le, rendra les choses plus faciles et plus efficaces par la suite. Pour adopter véritablement le mouvement DevSec, il faut donner aux développeurs une raison de se préoccuper de la sécurité en premier lieu - après tout, dans la plupart des organisations, c'est encore le "problème de quelqu'un d'autre" (c'est-à-dire les magiciens de l'AppSec enfermés dans une autre pièce, loin, très loin, très loin).
DevSecOps ne fonctionne tout simplement pas si la sécurité n'est pas une responsabilité partagée. Les développeurs ont besoin des bons outils, du support et de la formation pour faire leur part... et cela demande du temps pour être déployé et perfectionné dans le cadre d'un programme de sécurité global. La pire approche est celle qui submerge et aliène, ce qui peut être le cas lorsque les développeurs ont trop de priorités concurrentes et aucune aide pour les gérer sans se rendre fous. Il s'agit d'un changement culturel qui ne se fera pas du jour au lendemain.
- Comptez-vous sur une poignée de licornes magiques de la sécurité pour prendre en charge la tâche d'un grand nombre de personnes ?
Les professionnels de la sécurité sont très rares, et nous en avons besoin de beaucoup plus que ce qui est actuellement disponible. C'est une évidence, mais un nombre croissant de développeurs s'orientent vers des fonctions plus axées sur la sécurité. En règle générale, ils portent des titres tels que "ingénieur en sécurité" ou "ingénieur DevOps" (avec un peu de chance, nous verrons ce titre se transformer en ingénieur DevSecOps). Un ingénieur DevOps est capable de développer des fonctionnalités pour pratiquement n'importe quelle application, tout en la déployant à l'aide d'un véritable pipeline CI/CD. Il s'occupe de tout de bout en bout et est généralement doté d'une bonne dose de sensibilisation à la sécurité. En ce sens, ils sont un peu magiques, et donc rares.
Cependant, certaines entreprises font l'erreur d'embaucher ces ingénieurs spécialisés, de les intégrer dans une équipe et de s'attendre à ce qu'ils s'occupent de tous les problèmes de sécurité, à chaque étape du processus de développement, et qu'ils soient la panacée. Surchargez vos magiciens DevSecOps et vous vous retrouverez au même point qu'au début : vous livrerez un code non sécurisé sans les contrôles, les équilibres et la précision de sécurité pour lesquels ils ont été embauchés. Il est de la plus haute importance que l'équipe de développement en général soit perfectionnée et nourrie dans un environnement de sécurité positif afin qu'elle soit équipée pour partager la charge de manière significative.
Trouvez le changement que vous souhaitez voir s'opérer dans votre organisation.
Si vous mettez en place une formation solide dans le cadre de votre programme de sécurité, vous découvrirez quelques joyaux cachés dans votre cohorte de développement. Il s'agit des personnes qui, malgré les expériences négatives qu'elles ont pu avoir dans leur travail quotidien, ont une certaine passion pour le codage sécurisé et les meilleures pratiques en matière de sécurité. Ces personnes sont des candidats de choix pour devenir des champions de la sécurité au sein de l'équipe ; un point de contact entre la sécurité et l'ingénierie qui montre l'exemple aux autres, maintient la sensibilisation à un niveau élevé et contribue aux initiatives d'engagement. Leurs compétences interpersonnelles sont également très importantes pour diffuser largement la joie de la sécurité et défendre les besoins des développeurs auprès de la direction et de l'équipe de sécurité.
La conversation "qu'est-ce que j'y gagne ?" est un pas en avant positif.
Même les êtres humains les plus nobles ont besoin d'une "carotte" pour s'aventurer en terrain inconnu ou dans une activité dont la courbe d'apprentissage n'est pas des plus agréables.
Faire le saut de "dev" à "DevSec" est un formidable coup de pouce pour la carrière d'un développeur. Les développeurs sensibilisés à la sécurité ont travaillé dur pour comprendre la sécurité, en assumer la responsabilité dans les domaines qu'ils peuvent contrôler et travailler en sachant que le seul code de qualité est un code sécurisé. En général, les développeurs veulent s'améliorer, s'attaquer à de nouveaux problèmes et créer des fonctionnalités enviables qui les aident à se démarquer de leurs pairs. Donnez-leur la possibilité d'atteindre un niveau plus élevé de développement logiciel, et vous obtiendrez une situation gagnant-gagnant.
Il n'est jamais trop tard pour constituer votre équipe de rêve DevSec.
Si vous gérez des développeurs, si vous dirigez une équipe de sensibilisation à l'AppSec ou si vous êtes l'un des nombreux cerveaux qui travaillent à l'élaboration de stratégies de programmes de sécurité, le moment est venu de faire mieux que de "passer" à gauche. Avec la formation, les outils et l'environnement adéquats, vous pouvez créer un incubateur de sécurité pour les développeurs qui rapportera beaucoup à toutes les parties. Si cette liste de contrôle a mis en évidence certains points à améliorer, vous avez une excellente occasion de préparer votre organisation à un service d'ingénierie dirigé par DevSec et capable de réduire les risques dès le début du cycle de développement durable (SDLC).
Table des matières
Matias Madou est expert en sécurité, chercheur, directeur technique et cofondateur de Secure Code Warrior. Matias a obtenu son doctorat en sécurité des applications à l'université de Gand, en se concentrant sur les solutions d'analyse statique. Il a ensuite rejoint Fortify aux États-Unis, où il s'est rendu compte qu'il ne suffisait pas de détecter les problèmes de code sans aider les développeurs à écrire du code sécurisé. C'est ce qui l'a incité à développer des produits qui aident les développeurs, allègent le fardeau de la sécurité et dépassent les attentes des clients. Lorsqu'il n'est pas à son bureau en tant que membre de l'équipe Awesome, il aime être sur scène pour présenter des conférences, notamment RSA Conference, BlackHat et DefCon.
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.