Agile est un mot à la mode dans le domaine des technologies de l'information. D'un effort bien intentionné pour améliorer la qualité des logiciels et la rapidité de livraison, elle a été de plus en plus mal vendue au cours des deux dernières décennies comme une panacée pour guérir tous les maux de l'informatique. La méthodologie donne la priorité à l'autonomie, à la rapidité de livraison et à l'éthique "move fast, fail fast", ce qui suffit à faire grimacer n'importe quel RSSI.
Alors que le dogme Agile continue de se répandre, il est de notre devoir, en tant que responsables de la sécurité impartiaux, de le repousser.
Agent du changement ou agent du malheur ?
La méthode Agile a ses avantages. En tant qu'approche itérative du développement de logiciels, elle peut aider les équipes à accélérer la mise sur le marché et à éliminer les obstacles. Elle peut être particulièrement efficace pour les petites organisations et les petites équipes. Mais elle n'est pas très évolutive et n'aime pas les environnements hétérogènes complexes. Elle ne transformera certainement pas une équipe de livraison défaillante en une équipe efficace.
Pourtant, la méthode Agile est de plus en plus adoptée comme modèle d'exploitation à l'échelle de la technologie, afin de favoriser la transformation partout, des services d'assistance aux centres de données. Les DSI évangélistes sont encouragés par des entreprises qui n'en comprennent pas les nuances. On dit qu' environ la moitié des entreprises utilisent des pratiques agiles pour la transformation depuis au moins trois ans. Mais est-ce toujours approprié ?
Dites simplement non
Par le passé, j'ai travaillé avec de nombreuses équipes de DSI du FTSE 100 qui m'ont dit : "Nous passons à l'Agile". En réalité, ils veulent dire : "Nous sommes désormais autonomes : "Nous sommes désormais autonomes, nous n'avons donc plus besoin d'interagir avec la sécurité et nous nous retirons de la gouvernance d'entreprise".
Autre demande classique : "Pouvez-vous me donner une exception en matière d'acceptation des risques et de sécurité ?", ce qui pourrait être traduit plus précisément par "Pouvez-vous compromettre la sécurité pour m'aider à atteindre mes objectifs de livraison Agile ? "Pouvez-vous compromettre la sécurité pour m'aider à atteindre mes objectifs de livraison Agile ?"
Une réponse appropriée de la part du RSSI serait : "Bien sûr, à condition que vous soyez prêt à assumer l'entière responsabilité en cas de problème : "Bien sûr, tant que vous êtes prêt à assumer l'entière responsabilité en cas de problème".
La sécurité doit être acceptée comme une exigence fonctionnelle obligatoire de tout projet. Nous savons tous qu'il est moins coûteux, plus facile et plus sûr de l'intégrer dès le départ que de la moderniser. Pourtant, il est étonnant de constater que dans de nombreux projets Agile, l'"approbation de la sécurité" est la dernière tâche du sprint, ce qui entraîne inévitablement des retards.
La conformité réglementaire de base n'est pratiquement plus pertinente dans le paysage actuel des menaces. Au lieu de cela, nous devons tester avec des outils performants et, le cas échéant, des équipes rouges indépendantes. Les RSSI ont besoin d'outils capables de surveiller de près les environnements, les erreurs et les mauvaises configurations afin d'atténuer efficacement les risques. L'entreprise dans son ensemble doit comprendre qu'un produit n'est pas complet tant que toutes les exigences de sécurité n'ont pas été satisfaites.
En réalité, en tant que RSSI, nous sommes la conscience de l'organisation. Pour que les projets Agile réussissent, nous devons parfois ralentir un peu les choses et poser des questions difficiles. Parfois, nous devons remettre en question la foi dogmatique de nombreux DSI et de leurs équipes.
Il n'y a pas de mal à être le méchant. Dire non à l'Agile lorsqu'il existe de meilleures approches de bon sens.
https://www.theregister.com/2021/12/16/move_fast_break_security_why/