Comme vu lors de nos précédents billets, le pentest tel que pratiqué aujourd’hui, est substantiellement limité, ponctuel, onéreux.

Comment alors conjuguer cela avec l’agilité nécessaire aujourd’hui à la transformation des organisations ?

🚀L’agilité pour réduire le Time To Market assurer la pertinence des produits numériques 

Pour rappel, les techniques de développement agiles ont été introduites afin d’accélérer le TTM (Time To Market) des produits numériques ainsi que leur pertinence vis-à-vis des évolutions toujours plus fréquentes des marchés. Nous ne pouvions plus nous permettre d’attendre 12, 18 ou 24 mois pour mettre sur le marché un produit et un service qui, de facto, ne reflétait pas/plus les besoins actuels du métier.

L’agilité vise donc à pallier cela en réduisant les cycles de feedbacks entre le développement, la production et le marché (ou le “métier”), en introduisant des notions de tests itératifs (prototypes, MVP, versions),  afin de refléter le plus fidèlement possible les besoins actuels des métiers et de clarifier au fil de l’eau les incertitudes entourant les projets. MAIS, eh oui parce qu’il y a un grand MAIS !

👨‍💻La cybersécurité, un frein à l’agilité ?

Il arrive souvent que le RSSI (Référent ou Responsable de la Sécurité des Systèmes d’Information) ou la personne qui endosse ce rôle de manière informelle fasse écrouler ce château de cartes en donnant un coup de grâce au TTM. Le trait est grossi, nous l’avouons, mais ce qui se produit souvent est que le RSSI n’ayant pas pris part au cycle agile, et étant un passage obligé avant toute mise en production d’un objet connecté ou d’un service, notamment à l’issue du tout dernier sprint, il freine des quatre fers parce qu’il constate un certain nombre de manquements à l’hygiène numérique et/ou à la PSSI (Politique de Sécurité du Système d’Information) et/ou à telle ou telle norme ou tel ou tel standard ou telle ou telle obligation contractuelle… Il empêche ainsi la mise en production jusqu’à ce que les objections effectuées soient levées … et c’est ainsi que le TTM s’envole et tous les bénéfices de l’agilité s’évaporent. Ceci est d’autant plus criant que les projets de remédiation de vulnérabilités ne sont peut être pas gérés de manière “agile” mais plutôt selon des cycles en V qui plongent de surcroît l’organisation dans une cohabitation de méthodes assez divergentes.

Comment faire alors pour inclure le RSSI dès la conception, dès les phases amont des projets ? Comment faire pour injecter le Sec entre le Dev et le Ops et aboutir à une sécurité agile en DevSecOps ? Nous verrons cela en détail lors d’un prochain billet. 😉

➰Et comment mettre à contribution les pentests dans une démarche agile ?

Prenons l’exemple du framework Scrum, le plus utilisé à ce jour. Une Scrum team est une petite équipe pluridisciplinaire (métier, développement front, back, test & intégration)  qui s’organise et s’engage autours de trois artefacts :

• Le sprint : un incrément de temps fixe (souvent 2 à 3 semaines) qui va cadencer les cycles de développement et de prise de feedback utilisateur et client.
• La backlog produit : le découpage de l’ensemble du périmètre du produit (ou projet) en petits éléments développables en un sprint, communément appelés User Stories (“En tant que [utilisateur] je souhaite [fonctionnalité] afin de [bénéfice]”) ou Technical Stories.
• L’incrément produit (ou l’objectif de sprint) : la somme des User Stories et Technical Stories développées lors d’un sprint, qui doit être testable et démontrable à un client.

Classiquement la notion de test couvre les tests fonctionnels et techniques (code review, tests unitaire, QA…), c’est pourquoi les compétences de test sont internalisées dans l’équipe Scrum (développeur, testeur) et sont impliquées dès les phases de conception et de planification.

Idéalement, de la même manière, il faudrait impliquer l’expertise cyber :

• Dès le début pour définir un cadre sain de développement (architecture, bonnes pratiques de développement, tests automatiques)
• Au fil des développements au travers d’audits cyber réguliers (effectuer des tests d’intrusion (pentest) à chaque montée de version par exemple), afin de certifier les systèmes et d’identifier les pistes de sécurisation à intégrer dans le Backlog Produit.
• Lors des planifications de sprint (sprint planning) pour prioriser ces pistes de sécurisation et les intégrer dans les objectifs de sprint.

Mais pour effectuer ces pentests réguliers, encore faut-il pouvoir solliciter l’intervention de pentesters internes ou externes, qu’ils soient disponibles et que leur coût soit compris dans le budget du projet. Par ailleurs, il faudrait anticiper les durées d’audit ou de pentest nécessitant par exemple de figer la production.

Une autre difficulté réside dans le choix du type de pentests à conduire : boîte noire / grise / blanche… Cela revient à décider des typologies d’utilisateurs et de “use cases” à évaluer, et nécessite de bien connaître son environnement cyber, et d’avoir une stratégie cyber claire et partagée.

Des solutions “intellectuelles” existent bien pour ne pas perdre tous les bénéfices de l’agilité mais elles se heurtent à un nombre substantiel de limites organisationnelles, budgétaires et de compétences. 

Et vous, comment faites-vous pour rassurer votre RSSI avant la mise en production d’un produit ou d’un service ? Et, est-ce que vos échanges souvent houleux le/la poussent à déjeuner seul.e à la cantine ? 😉

Comme toujours, nous sommes preneurs de vos commentaires et retours d’expérience !

Hadi & Arthur pour Knock Knock