Votre organisation est-elle vraiment prête pour le DevSec ? Mets-le à l'épreuve.

Nous sommes à peine à la moitié de l'année 2020, et pourtant nous sommes déjà sur la bonne voie pour établir un sombre record en matière de violations de données, constatant une augmentation de 273 % des données volées par rapport au premier semestre 2019. De nos jours, il est plus précis de demander quelle quantité de données n'a pas Ils ont déjà été volés. En raison d'événements mondiaux tels que la pandémie de COVID-19, la fréquence et la puissance de ces attaques n'ont fait qu'augmenter, les cibles étant de plus en plus vulnérables.

Nous le savons tous depuis longtemps : la sécurité n'est plus une option et nous devons nous concentrer sur une attaque préventive. Pour que cela soit efficace, toutes les personnes dans le SDLC doivent être sensibles à la sécurité, en particulier les développeurs. Il s'agit de la partie « DevSec » de DevSecOps, une méthodologie de développement logiciel idéale pour le climat, mais de nombreuses organisations ne sont pas totalement préparées à l'exécuter efficacement.

En tenant compte de votre organisation, réfléchissez à ces questions dans le contexte de votre rôle. Comment s'en sortirait-il une fois soumis au test DevSec ?

Auto-évaluation DevSec : votre jardin SDLC est-il prêt à accueillir des ingénieurs soucieux de la sécurité ?

1. La sécurité occupe-t-elle une place de premier plan dans le processus de développement interne ?
   Un certain nombre de facteurs de risque liés à la cybersécurité peuvent empêcher le CISO moyen de rester éveillé la nuit, mais la réalité est préoccupante : alors que de nombreuses entreprises font de la sécurité une priorité, leur approche interne n'est peut-être pas suffisamment robuste pour atténuer les catastrophes potentielles (ou, du moins, les maux de tête considérables pour l'équipe AppSec et les retards dans la livraison des logiciels).
   DevSecOps est peut-être le nirvana actuel en matière de sécurité, mais peu d'entreprises utilisent cette méthodologie. Si vous utilisez toujours Agile, voire Waterfall, la sécurité est souvent considérée comme le domaine de spécialistes, très éloignés du processus et activés tardivement dans le SDLC, pour gâcher la journée des développeurs en leur proposant des correctifs pour leur code. Dans un tel environnement, il sera difficile de développer une culture DevSec : les développeurs adorent la création de fonctionnalités et y accordent la priorité, et ils n'auront tout simplement pas suffisamment d'expérience pratique en matière de sécurité pour y voir une voie de montée en compétence souhaitable. En fait, leurs points de contact avec elle peuvent être empreints de frustration et de négativité. Il faut y remédier rapidement pour donner une approche prioritaire à toutes les personnes impliquées dans le processus de développement logiciel.
   ‍
2. Votre organisation est-elle encore en train de rattraper son retard en matière de modélisation des menaces ?
   C'est une statistique qui donne à réfléchir 60 % des PME font faillite dans les six mois suivant la réussite d'une cyberattaque, et comme pour les autres catastrophes, l'impact est bien plus important sans une planification adéquate.
   La modélisation des menaces est un élément essentiel des meilleures pratiques de sécurité, car elle permet aux professionnels de la sécurité des applications d'évaluer 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 très tôt dans le 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 diffusion continue font tous partie du processus, et les équipes de développement disposent des ressources et de la visibilité nécessaires pour être les principaux composants du moteur qui crachent du code hermétique.
   ‍
3. Les responsables du développement donnent-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 pour des raisons de culture et d'ambiance, comme le fait de porter des tongs au bureau ou de savoir comment ils « se débrouillent ». Leurs priorités professionnelles 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 si elle n'est pas prévue en termes de formation et de support, les ingénieurs qui les sous-tendent seront absents et l'entreprise sera plus menacée qu'elle ne devrait l'être.
   ‍
4. Les développeurs ont-ils une raison de se soucier 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 ne correspond pas à son approche actuelle, sans lui dire pourquoi.
   
   Le fait de se faire dire de « 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, facilitera les choses et les rendra plus efficaces par la suite. Pour vraiment intégrer le mouvement DevSec, les développeurs doivent avoir une raison de se préoccuper de la sécurité en premier lieu. Après tout, dans la plupart des organisations, c'est toujours « le problème de quelqu'un d'autre » (c'est-à-dire les assistants AppSec enfermés dans une autre pièce, très, 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 outils, de l'assistance et de la formation appropriés pour faire leur part... et cela demande du temps pour le déployer et le perfectionner 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 qu'ils n'ont aucune aide pour les gérer sans se rendre fous. Il s'agit d'un changement culturel, qui ne se fait pas du jour au lendemain.
   ‍
5. Comptez-vous sur une poignée de licornes de sécurité magiques pour assumer la tâche de plusieurs ?
   Les professionnels de la sécurité sont là offre très limitée, et nous avons besoin de bien plus que ce qui est actuellement disponible. Cela va de soi, mais de plus en plus de développeurs se tournent vers des rôles plus axés sur la sécurité. En général, ils peuvent porter des titres tels que « ingénieur en sécurité » ou « ingénieur DevOps » (lentement, nous verrons ce titre se transformer en Ingénieur DevSecOps, avec un peu de chance !). Un ingénieur DevOps est capable de développer des fonctionnalités pour pratiquement toutes les applications, tout en déployant à l'aide d'un véritable pipeline CI/CD. Ils font tout de bout en bout et sont généralement accompagnés d'une bonne dose de sensibilisation à la sécurité. En ce sens, ils sont un peu magiques et, par conséquent, rares.
   
   Cependant, certaines entreprises commettent l'erreur d'embaucher ces ingénieurs spécialisés, de les intégrer à une équipe et de s'attendre à ce qu'ils soient confrontés à tous les problèmes de sécurité, à chaque étape du processus de développement, et cela seul constitue la panacée. Surchargez vos magiciens DevSecOps et vous vous retrouverez là où vous avez commencé : envoyer du code non sécurisé sans la précision des freins, contrepoids et sécurité pour lesquels ils ont été recrutés à l'origine. Il est de la plus haute importance que l'équipe de développement en général soit renforcée et soutenue 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 apparaître dans votre organisation.

Si vous mettez en œuvre une formation approfondie dans le cadre de votre programme de sécurité, vous découvrirez des trésors cachés dans votre cohorte de développement. Il s'agit de personnes qui, malgré les expériences négatives qu'elles ont pu vivre dans leur travail quotidien, sont passionnées par le codage sécurisé et les meilleures pratiques en matière de sécurité. Ces personnes sont des candidats de choix pour les champions de la sécurité au sein de l'équipe ; un point de contact entre la sécurité et l'ingénierie qui donne le bon exemple aux autres, assure une sensibilisation élevée 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é.

Le « qu'est-ce que cela m'apporte ? » la conversation est un pas en avant positif.

Même les humains les plus nobles ont besoin d'une sorte de « carotte » pour se plonger dans un territoire inconnu, ou d'une activité qui n'offre peut-être pas les courbes d'apprentissage les plus agréables.
Passer du statut de « développeur » à celui de « DevSec » est un formidable coup de pouce pour la carrière d'un développeur. Les développeurs soucieux de la sécurité ont travaillé d'arrache-pied pour comprendre la sécurité, en assumer la responsabilité dans les domaines qu'ils peuvent contrôler et fonctionner en sachant que le seul code de qualité est un code sécurisé. En général, les développeurs souhaitent s'améliorer, résoudre de nouveaux problèmes et créer des fonctionnalités enviables qui les aident à se démarquer de leurs pairs. Donnez-leur la voie pour atteindre un niveau supérieur de développement logiciel, et c'est 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, dirigez une équipe de sensibilisation à la sécurité des applications ou si vous êtes l'un des nombreux cerveaux qui travaillent d'arrache-pied à l'élaboration de stratégies de programmes de sécurité, le moment est venu de faire mieux que de « basculer » vers la gauche. Avec la formation, les outils et l'environnement appropriés, vous pouvez créer un incubateur de sécurité pour les développeurs qui rapportera de gros dividendes à toutes les parties. Si cette liste de contrôle a mis en évidence certains domaines à améliorer, vous avez une excellente occasion de préparer votre organisation à un département d'ingénierie dirigé par DevSec capable de réduire les risques dès le début du SDLC.