Cette méthode a bouleversé les façons de travailler des équipes produits et des équipes SSI, mais il ne va pas s’agir de « juste » adapter l’homologation RGS du cycle en V à l’Agile, mais bien de proposer une solution adéquate pour répondre à l’objectif de l’homologation : « trouver un équilibre entre le risque acceptable et les coûts de sécurisation, puis faire arbitrer cet équilibre, de manière formelle, par un responsable qui a autorité pour le faire[3] ».

Une solution : l’homologation provisoire et l’homologation ferme

Comme l’a déclaré un célèbre expert Sécurité Agile de Wavestone : « l’Agile et les homologations, c’est pas sorcier ». Sans nier les débats d’experts et les difficultés, l’approche reste assez simple à expliquer. Face à des équipes qui doivent livrer plus vite et mettre en production en continu, il faut que les niveaux de risques et donc l’homologation suivent le rythme.

Que doit prendre en compte l’homologation ?

Comme toute homologation traditionnelle, il s’agit de présenter le niveau de risque à une Autorité d’homologation, qui acte le fait que ce niveau est acceptable au regard des critères SSI de l’organisation (nombre d’EUS présentes sur le projet par exemple, pourcentage des règles de base de la PSSI ou règles d’hygiène appliqué pour un périmètre donné, etc.) et prend la responsabilité des éventuels risques résiduels.

Par exemple, un projet à ses débuts, qui souhaite mettre à disposition quelques fonctionnalités à peu d’utilisateur, présentera un niveau de risques moindre, dû à sa faible exposition, malgré un périmètre peut-être encore peu sécurisé. Une homologation provisoire (d’une durée de quelques mois par exemple) peut être prononcée pour permettre l’expérimentation, à renouveler lorsque certains critères de renouvellement (définis à l’avance) sont atteints.

Figure 1 – Exposition au risque résiduel d’un produit
Tiré du Guide ANSSI : Agilité et Sécurité Numériques, octobre 2018 (lien vers le guide)

Pour un projet en rythme de croisière, accessible à son public cible avec toutes les fonctionnalités attendues, une homologation ferme (3 ans par exemple) est prononcée. Les critères de renouvellement, menant à la prononciation d’une nouvelle homologation sont également définis à l’avance.

Quand renouveler une homologation ?

Bien que les critères de renouvellement soient très contextuels, voici des pistes de réflexion (en volume et degré d’exploitation du projet).

Pour l’homologation temporaire, elle est valide jusqu’à ce que des critères de renouvellement soient identifiés :

• De nouvelles fonctionnalités critiques sont ajoutées (à définir par le projet),
• Un nouveau palier de nombre d’utilisateurs est franchi (défini à l’avance, en fonction des risques associés),
• De nouvelles données à caractères personnel doivent être intégrées et traitées par le projet,
• De nouvelles fonctionnalités liées à des paiements doivent être implémentées,
• Un nouveau palier de volume de transaction est dépassé,
• Et bien sûr quand la date limite de l’homologation est atteinte.

Pour l’homologation ferme, la validité de l’homologation est plus longue, sur hypothèse que moins de changement seront apportés au projet. Cependant, et toujours dans une optique d’amélioration continue, la vérification des niveaux de sécurité sera réitérée à intervalles réguliers (tous les 3 ans par exemple).

Quels éléments de preuve doivent apporter les squads ?

Les squads doivent normalement être en mesure de présenter différents éléments de preuve à l’Autorité d’homologation/responsable de l’homologation. Les Evil User Stories (EUS) font office de risques, avec leur priorisation qui donne un élément de compréhension sur leur gravité. Nous avions détaillé dans un article précédent la manière de mener à bien ces ateliers d’analyse des risques en Agile. Un extrait du backlog peut apporter la preuve que les EUS principales ont bien été traitées et que les EUS résiduelles sont connues (et par extension, doivent être acceptées par l’Autorité d’homologation).

Le Passeport Sécurité (détaillé dans notre article sur la transformation Agile) est également un moyen pertinent de suivre les niveaux de sécurité d’un projet.

Les rapports des outils de revue de code et de scan de vulnérabilité peuvent également être utilisés (pour les squad ayant intégré le DevSecOps et possédant également les outils adéquats).

Si l’équipe X-team existe (voir notre article sur les nouveaux rôles SSI dans l’Agile et l’organisation associée) ou si une équipe d’audit externe a pu les réaliser, les rapports de test d’intrusion sont également présentés.

Tout autre document existant et nécessaire peut également être présenté (document d’architecture par exemple, réglementation applicable…).

Pour l’homologation temporaire, ces éléments de preuve ne doivent pas forcément faire l’objet d’un « dossier » hors-sol ; il faut surtout s’assurer qu’ils existent bien et sont accessibles aux acteurs de l’homologation (Autorité d’homologation ou son délégué, équipe SSI…).

Qui sont les acteurs du processus ?

Pendant tout le développement du produit, le Security Champion (cf. la définition dans cet article) est garant de la bonne mise en œuvre de l’évaluation des risques via les ateliers d’identification des Evil User Stories et des Security Stories associés. De manière assez naturelle, l’équipe SSI est actrice du processus d’homologation, via l’expertise apportée aux équipes, notamment lors de ces ateliers.

Le Product Owner est responsable de la bonne création et mise à jour des éléments de preuve nécessaire à l’homologation. Il s’assure également que l’équipe SSI est bien tenue informée du bon déroulement de l’homologation et qu’elle est sollicitée si besoin.

L’Autorité d’homologation est, comme toujours, un responsable métier (par exemple le Business Owner) capable d’accepter les risques résiduels et de valider les niveaux de sécurité des produits. Cependant, et toujours dans une optique d’amélioration des temps de traitement, la signature d’une homologation temporaire pourra être déléguée au Product Owner, en tant qu’émanation du métier, pour peu que les critères nécessaires à la validité de l’homologation soient bien respectés. Dans les cas où le projet ferait porter un risque à d’autres métiers ou à d’autres systèmes, la responsabilité de l’homologation devra être portée en transverse, par un N+1 commun. Si aucun compromis n’est trouvé, c’est le Directeur des Systèmes d’Information (DSI), dans son rôle de garant du maintien en conditions opérationnelles des SI, qui assumera la responsabilité.

Ainsi, l’homologation conserve toute son importance, et notamment dans le cadre de la méthodologie Agile qui fait évoluer la manière de travailler des équipes produit. Les équipes SSI doivent profiter de ces évolutions pour se (re)projeter dans ces équipes (à travers le Security Champion et à travers la formation des équipes à la sécurité) et ainsi œuvrer à la réduction incrémentale du risque.

Plus d’articles à venir sur la Sécurité dans l’Agile, restez à l’écoute !

[1] Guide ANSSI : Agilité et Sécurité Numériques, octobre 2018 (lien vers le guide)

[2] Pour les administrations : décret n°2010-112 du 2 février 2010, modalités du Référentiel général de sécurité (RGS). Pour tout produit traitant d’informations relevant du secret de la Défense nationale : l’Instruction générale interministérielle 1300. Pour les opérateurs d’importance vitale : volet cyber de la LPM (loi n° 2013-1168 du 18 décembre 2013 – article 22), pour le renforcement de la sécurité des sys­tèmes d’information critiques qu’ils exploitent, mené dans le cadre d’une démarche d’homologation.

[3] Guide ANSSI : L’homologation de sécurité en neuf étapes simples, août 2014 (lien vers le guide)

Cet article Homologation Sécurité et Agilité Numérique : c’est possible ! est apparu en premier sur RiskInsight.

Les méthodologies Agiles se généralisent au sein des organisations et les équipes de sécurité doivent désormais s’adapter pour s’intégrer au nouveau modèle opérationnel.   

Mais lors de la mise à l’échelle de la sécurité, passant de quelques projets Agile à accompagner à une centaine, la rareté de l’expertise en sécurité devient un frein majeur (il est estimé qu’il manquera 350 000 experts en cybersécurité d’ici 2022). La conséquence ? Les équipes sécurité, surchargées, et ne pouvant accompagner toutes les Feature Teams, doivent donc parfois se résoudre à mettre en production de nouvelles fonctionnalités en fin de sprint, sans revue de sécurité.  

Ainsi, pour accompagner cette transformation, les équipes du RSSI doivent revoir en profondeur leur modèle de fonctionnement pour être présentes et garantir un bon niveau de sécurité. Cela implique de revoir leur organisation, leur processus et leurs outils.  

Comment réaliser concrètement cette transition ?

Définir les nouveaux rôles SSI pour une transition vers un nouveau modèle opérationnel

Il faut d’abord comprendre les différents rôles que la sécurité doit jouer dans le nouveau modèle opérationnel, pour soutenir ce passage à l’échelle : 

• La Guilde sécurité : afin d’assurer la diffusion du savoir entre les équipes, il est important de construire une communauté de personnes qui ont une appétence sécurité pour les aider à partager les bonnes pratiques. Cette communauté de Security Champions, dont la description est au paragraphe suivant (et de toutes personnes intéressées par les sujets de sécurité), doit également permettre d’enrichir un cadre de référence commun sur les méthodologies (KM sécurité, Evil User Stories, Security Baseline, contrôle de niveau 1, explicités dans notre article précédent).

• Le Security Champion : c’est l’ambassadeur sécurité au sein des Feature Teams. Il fait partie intégrante de la Feature Team et est présent à chaque sprint planning. Son rôle est de s’assurer que la sécurité est bien prise en compte à chaque sprint dans le développement des User Stories. Le Security Champion peut être issu du monde des développements, et monter en compétence sur les sujet sécurité, avec l’aide de la Guilde et de l’Enabler Squad.

• L’Enabler Squad : dans le modèle de Spotify c’est le moteur des Guildes ; un groupe de personnes issus de l’équipe du RSSI qui va accompagner la Guilde Sécurité tout en bâtissant des méthodes, des processus, des produits, des services et des standards de développements qui vont permettre aux Security Champions de gagner en autonomie. Lors du démarrage de l’appropriation du modèle, ils peuvent incarner le rôle de Security Champion, avant de pouvoir les former. Ils fournissent aussi de l’expertise sécurité sur les périmètres les plus critiques et/ou les équipes les moins matures.

• La X-Team (« cross team ») : si le rôle de l’Enabler Squad est d’assister les Feature Teams dans l’intégration de la sécurité, le rôle de la X-Team est de contrôler le niveau de sécurité et de garantir la couverture des risques. Elle réalise des tests techniques (tests d’intrusion, revues de code, etc.) ciblés. Evidemment, réaliser un test d’intrusion dans chaque Feature Team et pour chaque sprint n’est pas possible pour des raisons de charge. Ainsi, les tests seront réalisés soit par échantillonnage et aléatoirement (jouant ainsi le rôle de « Chaos Monkey » dans l’organisation), soit en se concentrant dans un premier temps sur les périmètres les plus sensibles et/ou les moins matures. En effet, dès lors que suffisamment de KPI sécurité seront remontés depuis les Feature Teams, la X-Team pourra aller contrôler de manière plus renforcée les équipes dont le niveau de sécurité dérive de la cible.

• Concernant le RSSI : le rôle évolue pour permettre d’opposer un veto si le niveau de sécurité du delivery de la Feature Team est jugé insatisfaisant (selon la X-Team ou selon un niveau « score sécurité » au niveau applicatif ou de l’infrastructure développé par l’équipe SSI). Il ne peut bien entendu être présent durant toutes les cérémonies Agile, et doit se reposer sur la Guilde Sécurité pour lui remonter les sujets d’arbitrage, où une décision stratégique doit être prise. Il peut néanmoins participer aux PI Planning et cérémonies peu fréquentes pour disposer d’une vision d’ensemble et pressentir les sujets et besoins qui nécessiteront un accompagnement renforcé. Des comités dédiés peuvent également être mis en place, permettant aux projets de s’inscrire pour faire arbitrer les sujets, avec appel au RSSI en cas de besoin d’arbitrage final. 

Comme dans toute conduite du changement, l’efficacité de l’acculturation réside davantage dans la pratique que dans la théorie. Il faut commencer petit pour initier une prise en main progressive du nouveau modèle opérationnel par l’équipe SSI. Il sera ensuite plus simple d’étendre son périmètre à toute l’entreprise. 

Faire : mobiliser des experts sécurité pour amorcer la transition dans 2 ou 3 Feature Teams

La prise en compte de la sécurité se veut continue. L’objectif est que les Feature Teams soient suffisamment matures et compétentes en matière de cybersécurité pour être autonomes dans leur gestion des risques. Mais dans une période intermédiaire, la présence d’experts sécurité dans une posture de service et d’accompagnement est un facteur de réussite pour faciliter la prise en compte de la sécurité dans les projets, en attendant que des Security Champions émergent dans toutes les Feature Teams. Ces experts sécurité doivent donc se répartir les périmètres prioritaires (projets critiques, Feature Team en difficulté au niveau sécurité…) et ne pourront pas accompagner tous les projets.  

L’objectif est d’amorcer la transition, d’utiliser les experts en sécurité de l’équipe SSI pour “faire” avec les équipes, apprendre en pratiquant et utiliser leurs connaissances pour constituer les premières briques des méthodes sécurité requis par les équipes Agiles. 

C’est à ce moment-là que les premiers outils et méthodologies nécessaires doivent être construits, utilisés et améliorés :  

• Le passeport sécurité : il suit le projet tout au long de sa vie (et au-delà). Il est initié dès le début d’un projet (au moment du PI Planning) pour en identifier la criticité, mettre en place et suivre les mesures de sécurité appropriées.

• La Security Baseline : c’est l’ensemble des règles et standards de sécurité de base, traduits de façon conversationnelle pour être intégrés facilement aux backlogs des Feature Teams, afin d’être traitées lors des sprints. Elles se présentent sous forme de Security Stories : 

Pour atteindre un niveau minimum de sécurité, les projets (standards ou peu sensibles) doivent au moins respecter cette Security Baseline. 

• Les formations à destination des futurs Security Champion  
  • Présentation de la fiche de poste, les rôles et responsabilités,  
  • Formation sur les EUS, Security Stories, grâce à la gamification chère à l’Agile. C’est ici que les Security Champions peuvent se familiariser avec le jeu de carte produit par Wavestone (nous vous invitons à aller lire cet article pour retrouver toutes les informations sur le Jeu de Carte Agile de Wavestone), 
  • Formation à la bonne utilisation du KM (partager les informations, faire vivre la communauté, connaître les référents…).

• La sécurisation des productions des équipes 
  • Mise sous contrôle les développements : formation au développement sécurisé, sécurisation du pipeline CI/CD, mise en place de contrôle sur le code produit, etc. 
  • Définition des règles de séparation des rôles et responsabilités en DevOps : mise en production, édition des tests, changement en production, etc. 

Un article plus complet sera dédié à cette dernière partie. 

Et ensuite ? Comment passer à l’échelle ?

Cette période intermédiaire, où les experts SSI ont été projetés dans quelques Feature Teams est clé, pour la construction des rôles, des outils et des processus.  

Une fois le modèle bien maîtrisé par les équipes SSI, il s’agit d’étendre la méthodologie à tout le périmètre agilisé.  

Communiquer

La célébration des succès des 2 ou 3 Feature Teams pilotes peut favoriser l’adoption par le reste du périmètre.  

Une fois que les premiers projets auront démontré l’intérêt de la démarche et que les outils et les méthodes seront développés, il s’agira alors d’étendre ces bonnes pratiques à l’échelle de l’entreprise. 

Former

Les experts sécurité pourront servir de coachs pour diffuser les pratiques au sein des Feature Teams qui se formeront au fur et à mesure.  

Une bonne solution est d’utiliser la moitié des experts en sécurité pour partager les outils et former les équipes. Cette moitié constitue naturellement la Security Enabler Squad. 

L’autre moitié peut ainsi rester concentrée sur la réduction des risques au niveau des périmètres critiques ou moins avancé, en tendant vers une montée en maturité suffisante des Security Champions des autres Feature Teams. 

Il faut aussi toujours assurer la communication autour de la transformation et l’animation de la communauté sécurité pour favoriser le passage à l’échelle.  

Contrôler et piloter la maturité des Security Champion

Enfin, une fois les Feature Teams formées à utiliser les outils et méthodes sécurité, les experts sécurité de l’équipe SSI peuvent concentrer leurs efforts sur le contrôle des versions importantes et le pilotage de la Guilde Sécurité. Il s’agit de faire vivre cet espace d’échange, de capitalisation et de partage, pour continuer la montée en maturité de toute la Guilde, et donc des Feature Teams. 

Combien de temps pour parvenir à agiliser complètement la sécurité ?

Les premiers retours d’expérience font état d’une transition de 3 ans, pour passer du début de l’état intermédiaire où l’équipe sécurité se projette dans les Feature Teams, jusqu’à une complète autonomie des Security Champions. Cela peut sembler long, mais le passage à l’Agile est bien plus qu’un simple changement de méthodologie, c’est un véritable changement de paradigme qui nécessite une conduite du changement, à la fois révolutionnaire et faite pour durer dans le temps. 

Dans les prochains articles, nous répondrons aux questions suivantes : 

• Comment assurer les contrôles de sécurité en Agile ? 
• Au-delà du support sur les projets, comment l’organisation et les processus majeurs SSI doivent-ils évoluer pour fonctionner dans le nouveau modèle opérationnel Agile de l’entreprise ? 

Cet article Comment structurer les équipes SSI pour assurer la prise en compte de la sécurité dans l’Agile à l’échelle ?  est apparu en premier sur RiskInsight.

L’atelier EUS & Security Stories : Qui, quand, où ?

Tout d’abord, nous ne pouvons que vous conseiller d’impliquer dans cet atelier les habituels acteurs des cérémonies agiles :

• Le Product Owner (PO) en sa qualité de représentant des besoins métiers
• Le Coach Agile en sa qualité de garant du respect de la méthode
• Les référents techniques du projet (architecte, développeurs, testeurs…)

Pour apporter un œil cybersécurité, il est important de compter sur la présence du Security Champion de l’équipe projet. Si aucun n’est disponible, un membre de l’équipe du RSSI peut le remplacer et aura « l’état d’esprit » Cybersécurité pour vous aiguiller et mener l’atelier à bien.

Ensuite, on se demande souvent à quel moment ces ateliers doivent être conduits… Pour tout vous avouer, il n’y a pas de règle à ce sujet, car cela dépendra des exigences sécurité de chaque release ! Toutefois, notre premier conseil à ce sujet est de synchroniser leur fréquence avec celle de revue du backlog produit. Ainsi, il vous suffit de prolonger les ateliers où vous travaillez sur les User Stories d’environ 50% pour vous consacrer à cette étude sécurité avec déjà tous les bons acteurs présents et mobilisés.

Enfin, où réaliser l’atelier ? Idéalement dans la continuité de votre atelier précédent, dans une salle avec un tableau ou un projecteur permettant de partager un écran et la possibilité d’annoter les schémas assez facilement (post-its, feutres pour tableau blanc…). Néanmoins, il est également tout à fait envisageable de le faire en ligne ! Chez Wavestone, nous utilisons régulièrement des solutions comme Mural ou Stormboard à cet usage. Faites-vous la main sur une solution de ce genre et vous verrez si c’est jouable !

Déroulement de l’atelier

Tout d’abord, il est souvent nécessaire que le Security Champion mène la barque dans les premiers ateliers. Mais l’idée est de se coordonner avec le Coach Agile et travailler de concert pour que les référents techniques puissent petit à petit prendre en main la méthodologie et se l’approprier.

Quand nous formons nos clients sur le sujet, nous prenons souvent un cas d’usage, fictif mais concret et réaliste ! WaveCare est une application médicale avec de nombreuses fonctionnalités innovantes telles que :

• Consultation des disponibilités de praticiens près de chez vous
• Transmission en temps réel de vos données de santé grâce à votre montre connectée
• Réalisation de consultations à distance en Visio (conférence Skype)
• Réception de l’ordonnance après le RDV en format dématérialisé

Pour cette démonstration, intéressons-nous à deux composants en particulier : le schéma descriptif de la fonctionnalité permettant à un patient de rechercher et réserver un créneau dans l’agenda de son médecin et le schéma d’architecture générale.

–

Etape 1 : Construire les scénarios de risque

Les premières questions à se poser sont « Où-suis-je vulnérable ? », « Comment et par où peut-on m’attaquer ? ». Le référent sécurité (Security Champion) et les développeurs vont devoir essayer de répondre à ces questions ! Ici, c’est donc un mélange de connaissances en sécurité applicative et en développement qui va permettre d’identifier les vulnérabilités exploitables. Nous pouvons déjà noter un aspect intéressant de l’approche : elle fonctionne aussi bien sur l’aspect infrastructure qu’applicatif !

Un conseil que nous pouvons déjà vous donner : encouragez les développeurs à s’approprier l’approche et à être force de proposition, c’est un excellent levier pour les sensibiliser à la sécurité ! Pour le référent sécurité, son rôle doit majoritairement être de modérer l’échange et challenger les propositions des développeurs. Cette posture peut en plus vous permettre d’identifier des potentiels Security Champions, ne lésinez pas à la conserver !

Appliquons donc ce que nous venons de nous dire à notre exemple, dans les figures ci-dessous.

–

Et voilà, on peut finalement identifier assez rapidement quelques points d’attention ! Si nous voulons détailler le scénario « Injection de code » du schéma d’architecture globale, nous pouvons par exemple le reformuler comme cela : « En tant qu’attaquant, je veux injecter du code malveillant dans les champs de saisie non sécurisés de l’application ». Vous voyez, cette terminaison est très proche de celle d’une User Story classique, mais l’angle est bien celui de l’attaquant !

Etape 2 : Evaluer les impacts métiers des scénarios

La seconde phase va être clef pour s’assurer d’utiliser l’énergie de l’équipe au bon endroit. C’est à ce moment que le Product Owner entre en jeu ! Avec le Security Champion, il va mener les débats pour qualifier l’impact que peut avoir chaque vulnérabilité.

Pourquoi le PO est-il décisif sur cette étape ? Toute simplement car c’est lui qui connaît le mieux à la fois la réalité métier du projet et l’importance de chaque fonctionnalité. Il s’agira de bien l’orienter, avec des questions comme « Est-ce grave si les données envoyées à ce moment par le patient sont volées ? », « Quelle est la gravité du vol du compte de l’utilisateur ? », etc.

Ensuite, il vous faudra donner une note pour prioriser chaque scénario. Deux choix s’offrent alors à vous. Le premier est d’utiliser une vue risque cyber classique, avec un niveau de probabilité et d’impact. Personnellement, je vous recommande plutôt d’utiliser un système de point ou la suite de Fibonacci, comme pour une US classique, c’est franchement plus simple et instinctif !

Etape 3 : Définir et prioriser les Security Stories

La prochaine étape consistera à construire des Security Stories basées sur chacun des scénarios.

Au tour du Security Champion et des développeurs de remonter sur scène ! Pour continuer sur l’exemple précédent, voici une Security Story que nous pouvons rédiger : « En tant que développeur, je veux m’assurer que les attaques par injection de code sont évitées ». Concrètement, elle nous fera ajouter au backlog du produit des actions comme l’échappement des caractères spéciaux, le filtrage des entrées utilisateurs ou encore l’usage de l’attribut HttpOnly pour éviter le vol des cookies de session.

Evidemment, pour chacune des Security Stories, il peut s’avérer que les mesures de sécurité à mettre en œuvre le sont déjà. Dans le cas contraire, le Security Champion se charge de prioriser les mesures de sécurité techniques, au regard de la couverture des risques induits, à l’échelle de l’entreprise et pas uniquement du métier. Pour les mesures de sécurité n’étant pas uniquement techniques, c’est au Product Owner de les prioriser, au regard des risques business et des moyens de l’équipe.

Et voilà, vous pouvez maintenant démarrer votre sprint plus sereinement !

Et pour vous aider, préparez et adaptez le matériel à votre contexte !

Pour rendre les ateliers plus simples et ludiques, nous avons conçus un jeu de cartes génériques, constitué de cartes ayant chacune deux faces :

• Recto : les Evil User Stories, elles décrivent de façon très pédagogique ce qui peut mal se passer, en utilisant quelles vulnérabilités (ex : élévation de privilèges sur un serveur Web, attaque par force brute, XSS, …)
• Verso : les Security Stories décrivent les mesures de sécurité à implémenter pour s’assurer que l’Evil User Story ne se produit pas (ex : utilisation d’un algorithme de chiffrement robuste AES 256/512, …).

Ces cartes sont vraiment utiles pour vous lancer ! Pour de meilleurs résultats, vous pouvez même choisir de les adapter à votre contexte d’entreprise. Utilisez vos politiques de sécurité et intégrez vos exigences sur le chiffrement, la complexité des mots de passe, etc. Suivant les besoins de sécurité du projet, vous pouvez aussi calquer de exigences liées à des certifications (HDS) ou des directives (LPM, NIS).

Retrouvez le jeu de carte disponible gratuitement ici (et en anglais ici)et n’hésitez pas nous faire vos retours pour que nous continuions à l’améliorer !

Également, un atelier qui se déroule avec fluidité est toujours plus productif ! N’oubliez pas de préparer les supports en amont : schémas d’architecture du projet (flux et classification des données), listing et détail des prochaines User Stories à développer…

Cet article Comment conduire un atelier Cybersécurité agile ? est apparu en premier sur RiskInsight.

A travers cette série d’articles, nous présenterons nos convictions pour permettre aux équipes SSI de mener cette transformation en profondeur.

La transformation numérique implique l’usage d’une nouvelle méthode de delivery IT

A l’heure des transformations numériques, les organisations doivent faire face à 3 principaux défis :

• Innover plus rapidement pour faire face à la compétition.
• S’adapter rapidement au changement avec plus de flexibilité afin de mieux gérer l’incertitude et la complexité.
• Mieux combiner les compétences IT et métier pour maximiser la valeur produit.

Dans ce contexte, les méthodes agiles représentent par leur approche de développement itératif, incrémental et adaptatif, la promesse d’une organisation plus fluide en permettant de :

• Réduire les délais entre l’expression de besoin métier et l’ouverture du service idoine (« Time to Value ») : les fonctionnalités développées à chaque étape (sprint) sont opérationnelles et potentiellement utilisables.
• Maitriser les risques et le niveau de qualité: l’approche itérative et incrémentale de l’agile permet de récolter un maximum d’apprentissage (« test and learn ») en un minimum d’effort.
• Augmenter la productivité et la collaboration entre les différentes équipes en donnant du sens à leur travail : en cassant les silos organisationnels, les interactions entre l’IT et les métiers s’intensifient et améliorent l’engagement autour du projet et les boucles d’amélioration continue.
• S’adapter rapidement aux changements: avec la possibilité de changer à tout moment en cas d’évolution des besoins ou de mauvais feedbacks.

Parce que les méthodes agiles bouleversent les façons de prendre des décisions et l’organisation, de nouvelles questions se posent autour de l’articulation de la sécurité dans des organisations agiles :

• Comment réinventer l’intégration de la sécurité dans les projets pour s’adapter à une livraison itérative ?
• Comment soutenir le passage à l’échelle ? Comment structurer les équipes de sécurité pour assurer la sécurité dans l’agile à l’échelle ?
• Au-delà du support sur les projets, comment l’organisation et les processus majeurs SSI évoluent-ils pour fonctionner dans le nouveau modèle opérationnel agile de l’entreprise ?

L’adoption des méthodes agiles impose une refonte du processus d’intégration de la sécurité dans les projets

L’adoption des méthodes agiles représente une véritable rupture dans l’organisation du travail. Le cycle itératif de développement et la fréquence de livraison exigent que toutes les équipes qui gravitent autour du produit soient alignées et impose donc au RSSI de trouver l’articulation idéale entre agilité et sécurité.

Dans les méthodes de gestion de projets traditionnelles, la sécurité est implémentée de manière monolithique à travers 3 piliers :

• Evaluation des risques : évaluation des besoins sécurité et du niveau d’accompagnement SSI consenti pour gérer les risques identifiés.
• Accompagnement : accompagnement des équipes de développement et d’infrastructure dans la conception et l’implémentation des mesures de sécurité.
• Contrôle : réalisation de recette sécurité pour valider la résorption des risques de sécurité et valider la mise en production.

L’intégration de la sécurité dans les processus agiles doit pouvoir s’appuyer sur ces 3 piliers mais il est nécessaire que les équipes SSI revoient leur approche pour s’adapter aux nouvelles méthodes de delivery.

Vous trouverez dans cet article, 4 facteurs clés de succès pour réussir à transposer le processus d’ISP dans une démarche agile.

1. Evaluer le niveau d’accompagnement SSI tout au long du cycle de développement agile

L’appréciation de la sensibilité d’un projet est une première étape incontournable pour prioriser et optimiser les efforts des équipes SSI. Dans une démarche agile, cette évaluation ne doit plus uniquement être réalisée en amont du projet, mais bien tout au long du cycle de développement. Chaque produit doit donc posséder un passeport sécurité, qui sera mis à jour sur une base régulière (ex : tous les 3-6 mois) et lors de développement de fonctionnalités induisant de nouveaux besoins en sécurité.

Le niveau d’accompagnement des équipes SSI sera déterminé en tenant compte de la sensibilité SSI des fonctionnalités développées lors des prochains sprints et du niveau de maturité de la Squad en matière de cybersécurité.

2. Adopter une approche Security by Design

Pour faciliter l’approche Security by Design, les exigences SSI devront être intégrées le plus tôt possible dans la conception du produit.

Pour y parvenir, les équipes SSI vont devoir traduire les mesures de sécurité (référencées dans des politiques et des standards SSI souvent méconnus des équipes de développement) en « security baseline », c’est à dire en un socle de bonnes pratiques applicables de façon systématique et conférant un niveau de protection minimum.

Cela se traduit par une liste de « security user stories », facilement manipulable par les développeurs, qui sera intégrée dans tous les backlogs produit.

3. Traduire les scénarios de risques en Evil User Stories

De la même façon que le Product Owner rédige des User Stories pour décrire de façon conversationnelle une attente exprimée par un utilisateur, les équipes sécurité vont devoir s’adapter aux méthodes agiles en exprimant les risques de façon conversationnelle à travers des Evil User Stories (EUS).

Les Evil User Stories permettent à la sécurité d’exprimer les intentions d’un utilisateur malveillant.

Une Evil User Story décrit la réalisation d’un scénario de risque à travers l’identification d’une source de risque (attaquant externe / collaborateur malveillant), exploitant une vulnérabilité, occasionnant un impact sur la valeur métier.

Pour chaque EUS, des mesures de sécurité (Security User Stories) permettant de mitiger les risques sont identifiées et intégrées au backlog.

Les Security User Stories peuvent être définies à plusieurs étapes du cycle :

• Lors de l’évaluation initiale des risques au lancement du produit.
• Au fil des itérations : dès lors qu’une user story métier induisant des risques SSI est identifiée.
• Lors des phases de contrôle : dès qu’une vulnérabilité est détectée.

Par rapport à une analyse des risques en cycle en V, les Evil User Stories apportent des avantages clés en termes de sécurité :

• Les risques sont facilement compréhensibles, car ils sont énoncés de manière conversationnelle : aujourd’hui lorsqu’on réalise une analyse de risques, les risques que l’on formalise ne vont pas forcément parler à un métier ou à un développeur. De cette façon, les risques sont compréhensibles par tous les acteurs du projet et sont intégrés dans leur quotidien.
• Les risques sont régulièrement mis à jour chaque fois que le produit évolue : la prise en compte des enjeux sécurité doit être à la fois continue et pragmatique et permettre ainsi une démarche de réduction incrémentale du risque. Les Security User Stories sont priorisées en fonction du risque réel et le risque résiduel reste acceptable tant que le produit est exposé à une poignée d’utilisateurs.
• Le processus de remédiation est facilement contrôlable en examinant le backlog : la liste des Security User Stories est embarquée dans le backlog et tracée dans un outil (ex : Jira). C’est un vrai gain par rapport aux méthodes traditionnelles qui ne permettaient pas toujours de suivre la bonne application des mesures de sécurité.

4. Intégrer la sécurité dans les critères d’acceptation des User Stories

Dans un monde idéal, où la sécurité serait systématiquement embarquée, les équipes sécurité n’auraient pas forcément besoin d’intégrer des Security User Stories au backlog produit.

En effet, dans les méthodes agiles, des critères d’acceptation accompagnent chaque user story. Ils représentent un ensemble de conditions (utilisabilité, performance, etc…) que la story doit satisfaire pour être considérée comme complète et terminée. Ils sont rédigés par le Product Owner, en collaboration avec l’équipe de développement.

Ainsi l’équipe sécurité pourrait profiter de ces conditions de satisfaction pour ajouter la liste des mesures de sécurité à intégrer pour assurer la sécurité de chaque fonctionnalité développée.

Dans la réalité, ce n’est jamais réalisé de cette façon (trop contraignant pour la Squad), d’où la nécessité de rédiger et intégrer des Security User Story au backlog produit.

5. Fournir des outils ludiques pour favoriser la prise en compte des enjeux SSI

Parce que les membres au sein des Squad qui vont devoir identifier les Evil User Stories, n’ont pas forcément toutes les compétences pour le faire, nous avons développé un jeu de cartes qui permet de rendre l’exercice d’analyse de risques plus concret et ludique.

Le jeu est composé de cartes, chacune ayant 2 faces :

• Recto : les Evil User Stories décrivent de façon très pédagogique ce qui peut mal se passer, en utilisant quelles vulnérabilités (ex : élévation de privilèges sur un serveur Web, attaque par force brute, XSS, …)
• Verso : les Security User Stories décrivent les mesures de sécurité à implémenter pour s’assurer que l’Evil User Story ne se produise pas (ex : utilisation d’un algorithme de chiffrement robuste AES 256/512, …).

Comment jouer :

• Il faut rassembler à minima les membres de la Squad ayant une connaissance fonctionnelle de la solution (Product Owner) et une connaissance technique et des risques (référents sécurité, développeurs, architectes).
• Les architectes dessinent l’architecture applicative sur une grande affiche A3 sur une table en faisant apparaitre les flux de données et la classification des données et le Product Owner liste les prochaines User Stories qui devront être développées.
• Le référent sécurité (Security Champion) et les développeurs répartissent les vulnérabilités exploitables sur le schéma d’architecture.
• Le Product Owner et le Security Champion qualifient l’impact que peut avoir chaque vulnérabilité.
• Le Security Champion et les développeurs vérifient si les mesures de sécurité permettant de contrer les vulnérabilités identifiées sont déjà implémentées.
• Si des mesures de sécurité ne sont pas encore en production : Le Security Champion priorise les mesures techniques à implémenter permettant de couvrir les risques induits (risque pour l’entreprise, pas seulement au niveau business).
• Le Product Owner priorise les autres mesures de sécurité au regard des risques business / et des moyens de l’équipe.

Ce type de jeu permet de mobiliser l’ensemble des parties prenantes dans l’analyse des risques et d’identifier les mesures de sécurité à injecter dans le backlog.

A travers cet article, nous avons identifié 4 premiers leviers pour intégrer la cybersécurité dans une démarche agile :

1. Le Passeport Sécurité pour évaluer le niveau d’accompagnement SSI tout au long du cycle de développement agile
2. La traduction opérationnelle de la Security Baseline pour assurer un niveau de protection minimum
3. Les Evil User Stories pour exprimer de façon simple et compréhensible les scénarios de risques
4. Des outils ludiques pour favoriser la prise en compte des enjeux SSI

Dans les prochains articles, nous répondrons aux questions suivantes :

• Comment soutenir le passage à l’échelle ? Comment réorganiser l’équipe SSI ?
• Comment assurer un bon niveau de contrôle sécurité ?
• Au-delà du support sur les projets, comment l’organisation et les processus majeurs SSI doivent-ils évoluer pour fonctionner dans le nouveau modèle opérationnel agile de l’entreprise ?

Cet article Transformations agiles des organisations: vers un changement structurel d’approche pour la cybersécurité est apparu en premier sur RiskInsight.

1)     Analyse des opérations

L’analyse dynamique permet la surveillance de nombreuses informations : les registres, le système de fichiers et les processus. Cette étape est au début assez fastidieuse étant donné que de nombreuses informations sont accessibles. Il existe différents outils permettant d’accéder à ces informations. ProcessMonitor est l’un de ces outils qui a l’avantage de permettre à l’analyste de filtrer ses recherches sur un exécutable, ce qui est très pratique pour l’analyse de malwares.

Figure 1 : Résultat d’une analyse de ProcessMonitor sur un malware appelé mm32.exe

Figure 2 : Résultat de Process Explorer sur un exécutable

Dans ce résultat, le premier constat est la création d’un mécanisme de persistance HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run par le programme ckr.exe, le deuxième est la modification de la valeur de la seed pour le générateur de nombre aléatoire, ce qui représente un bruit habituel.

2)     Analyse réseau

Figure 4 : Interception des requêtes DNS et simulation des réponses par ApateDNS en utilisant l’IP 192.168.120.1

Figure 5 : Résultat renvoyé par Netcat lors de l’exécution de RShell en redirigeant les requêtes vers l’hôte grâce à ApateDNS

Figure 6 : Capture d’écran d’une analyse Wireshark

Figure 7 : Fonctionnalité Follow TCP Stream de Wireshark

3)     Analyse via débogueur

• Les software breakpoints : ces points d’arrêt sont utilisés pour faire en sorte que le programme s’arrête lorsque l’instruction sur laquelle ils sont placés est appelée. Pour réaliser cela, le débogueur remplace le premier octet de l’instruction par 0xCC, l’instruction pour INT3.

Cet article Reverse Engineering – focus sur l’analyse dynamique de malware est apparu en premier sur RiskInsight.