Bonjour, mon nom est Tyler Welton. Je suis ingénieur en sécurité à Planview AgilePlace et j'adore ça. Je passe une grande partie de mon temps à remplir des fonctions de sécurité défensive et offensive pour notre application web, notre infrastructure et notre culture de sécurité.
La sécurité de l'information est difficile. Assurer une bonne sécurité est encore plus difficile. La méthodologie de développement agile et la pratique de principes Lean ont permis aux leaders de l'industrie de produire et de déployer des logiciels plus rapidement et plus fréquemment qu'au cours des décennies précédentes. Naturellement, notre diligence à protéger ces logiciels, et nos moyens de le faire, doivent aussi évoluer.
La sécurité a toujours suivi l'innovation technologique, à juste titre d'ailleurs, puisque sans la technologie, il n'y aurait rien à protéger. Je pense qu'il est probablement assez évident, à la simple observation des événements actuels, que la protection des données des clients et la fortification du code contre les attaques sont des éléments qui doivent être au premier plan du développement moderne des logiciels.
Malheureusement, dans la profession de la sécurité, il semble toujours y avoir un retard entre l'évolution du développement des logiciels et l'évolution de la sécurisation de ces logiciels. Les problèmes se glissent lorsqu'on essaie d'améliorer le flux de travail de développement, et de fournir une valeur visible tant au consommateur du logiciel qu'à l'organisation de développement.
La sécurité à l'ancienne ajoute certainement de la valeur aux opérations à l'ancienne, mais les versions logicielles fréquentes et itératives ne peuvent être protégées par des systèmes et des méthodes conçus pour garder le monolithe. La sécurité doit rattraper son retard.
Old School : Hors de la boucle
Tout d'abord, abordons les étouffoirs que les méthodes archaïques font peser sur le flux. Il y a des stéréotypes que vous entendrez dans le monde de l'informatique et de DevOps, qui incluent, mais sans s'y limiter, les pénibles réunions du comité consultatif sur le changement (CAB) et les hiérarchies comiquement bureaucratiques d'approbation des changements technologiques.
Bien que ces processus soient initialement nés d'un véritable souci de sécurité, ils ont à bien des égards été à la hauteur de leurs stéréotypes. Ils ont rendu difficile l'application rapide de correctifs, l'analyse fréquente des vulnérabilités et la sécurité intégrée, et à long terme, ils peuvent affecter négativement la posture de sécurité d'une organisation.
Ces limitations n'existent pas seulement dans l'infrastructure, mais aussi dans le cycle de vie du développement logiciel. Dans la sécurité informatique à l'ancienne, les développeurs peuvent travailler sur un logiciel pendant des mois avant sa sortie. Souvent, la sécurité est le dernier arrêt sur les rails. Lorsque la sécurité découvre ensuite un problème avec le code, le logiciel peut devoir subir une réécriture approfondie. Dans ces cas, la sécurité n'est pas impliquée, est détachée et n'est pas aussi efficace qu'elle pourrait l'être.
La valeur est une autre idée Lean qui s'oppose à la sécurité traditionnelle et colossale. Une meilleure façon de dire cela pourrait être la "valeur perçue". Une sécurité réussie est difficile à quantifier, car sa mise en œuvre correcte ne devrait pas avoir beaucoup de résultats (brèches, incidents, etc.).
Ce qui est encore pire, c'est que les très mauvaises pratiques de sécurité semblent avoir les mêmes résultats quantifiables, en raison d'un manque de compréhension du paysage des menaces. Cela laisse les ingénieurs en sécurité, les spécialistes de la sécurité des applications et les pirates dans une position difficile où ils doivent trouver un moyen d'exprimer le risque qui a été atténué par les systèmes qu'ils ont mis en place.
Nouvelle école : Le déploiement continu comme élément de sécurité
J'ai assisté à une conférence de Zane Lackey, anciennement d'Etsy, qui a affirmé que le déploiement continu était leur fonctionnalité de sécurité numéro un. Cela s'est également avéré vrai à Planview AgilePlace, de plusieurs manières.
Premièrement, les itérations fréquentes, tant dans les déploiements de logiciels que dans les changements d'infrastructure, permettent une analyse plus approfondie de la sécurité et des vulnérabilités. Si le changement poussé est suffisamment petit, l'analyse de sécurité peut être extrêmement ciblée. Davantage de pistes d'exploitation peuvent être examinées lorsque la lumière n'est braquée que sur quelques changements, et que tout se passe dans le flux existant du SDLC.
Deuxièmement, le déploiement continu oblige la sécurité à entretenir une relation plus intime avec le développement. Lorsque cela se produit, la sécurité a la possibilité de mettre en œuvre un aperçu de la sécurité au niveau du code. Ces mesures peuvent ensuite être prises, et un véritable paysage des menaces peut commencer à être révélé. Cela permet de présenter la valeur de la sécurité d'une manière quantifiable. Au lieu d'une dynamique de "famille dysfonctionnelle", le développement et la sécurité peuvent s'engager sur la voie d'une relation plus symbiotique.
Premiers pas avec la méthodologie Lean
Les pratiques Lean se prêtent bien à la sécurité progressive de l'information, mais par où commencer sur cette voie ? Une formation de développeur doit-elle être mise en place ? Les politiques doivent-elles être formées et mises en place avant que le changement puisse se produire ?
Je n'ai pas de réponses précises à ces questions car les solutions diffèrent selon les organisations. Mais je peux dire que cela aide d'avoir des ressources disponibles pour les développeurs et les membres de l'équipe des opérations informatiques. Les employés du secteur technologique, pour la plupart, ont l'habitude d'apprendre et d'absorber de nouveaux concepts, mais ils passent la majorité de leur temps ailleurs. Si un simple catalogue de ressources peut être mis à la disposition des consommateurs, il peut fortement contribuer à un changement culturel.
Nous ne sommes pas parfaits ici à Planview AgilePlace, mais j'ai eu la chance de travailler avec des personnes très soucieuses de la sécurité. Mais même s'il y a un manque de sensibilisation à la sécurité au sein d'une entreprise, un pool de ressources pertinentes peut faire beaucoup. Nous sommes une équipe, après tout.
Il existe un potentiel impressionnant pour améliorer la valeur qu'offre la sécurité, tout en maintenant et même en améliorant le flux de travail moderne. Tout cela ne veut pas dire qu'il n'y a pas de problèmes avec les méthodes modernes - mais les équipes Agile qui valorisent les principes Lean ont au moins le cadre nécessaire pour évoluer rapidement afin de résoudre ces problèmes.
Final Thoughts
Bruce Schneier a déclaré : "Si vous pensez que la technologie peut résoudre vos problèmes de sécurité, alors vous ne comprenez pas les problèmes et vous ne comprenez pas la technologie." C'est le processus de sécurisation qui importe plus que les solutions mises en place. La sécurité est la capacité de réagir et de s'adapter afin de maintenir l'intégrité des données et des ressources qu'elle protège. La sécurité, pour le meilleur ou pour le pire, dépend des personnes. Et ce sont les personnes qui doivent créer le changement.
![Un plan de gestion du travail collaboratif mondial [Vidéo] (en anglais)](https://blog.planview.com/wp-content/uploads/2019/07/A-Global-Collaborative-Work-management-blueprint.png)
