ITIL structure vos services. Mais une politique de gestion des incidents parfaitement rédigée ne vaut rien face à un attaquant qui a déjà passé 20 jours dans votre réseau sans déclencher la moindre alerte.
ITIL : Information Technology Infrastructure Library, est aujourd'hui le référentiel de gestion des services informatiques le plus déployé au monde. Adopté par des milliers d'organisations dans plus de 150 pays, il structure la façon dont les équipes IT délivrent, maintiennent et améliorent leurs services.
Pourtant, dans la majorité des DSI qui appliquent ITIL, un angle mort persiste : la sécurité offensive. On gère les incidents. On documente les changements. On pilote les niveaux de service. Mais on ne teste jamais si ces processus résistent à un adversaire réel.
Cet article explore le référentiel ITIL sous un angle rarement abordé : comment ses pratiques de gestion des services s'articulent ou accrochent avec les exigences concrètes de la cybersécurité. Et pourquoi l'un sans l'autre reste une posture incomplète.
ITIL en 2025 : ce que le référentiel apporte vraiment
ITIL : Information Technology Infrastructure Library est né dans les années 1980 au sein de l'administration britannique (CCTA, devenu OGC) pour standardiser la gestion des services informatiques du gouvernement. À l'époque, le constat était simple : chaque département IT réinventait la roue, sans cohérence ni capitalisation entre organisations.
Depuis, le référentiel a connu quatre versions majeures. ITIL v2 (2000-2006) a popularisé les pratiques ITSM dans le secteur privé. ITIL v3 (2007) a introduit le cycle de vie des services. ITIL v4 (2019) représente la rupture la plus profonde : il abandonne le catalogue de processus rigides pour proposer un système de valeur de services (SVS) plus souple, intégrant les approches Agile, DevOps et Lean.
Aujourd'hui, plus de 5 millions de professionnels sont certifiés ITIL dans le monde. C'est le référentiel de gestion des services IT dominant, bien devant COBIT ou MOF. Sa force : il n'impose pas de technologie, il structure des pratiques universellement applicables.
Ses quatre dimensions fondamentales structurent toute délivrance de service :
- Organisations et personnes : gouvernance, rôles, culture, compétences
- Information et technologie : données, outils, plateformes, automatisation
- Partenaires et fournisseurs : écosystème tiers, SLA, gestion des dépendances
- Flux de valeur et processus : chaînes de valeur, pratiques, amélioration continue
Au cœur du système : la chaîne de valeur des services (SVC), qui orchestre six activités clés planifier, améliorer, engager, concevoir/transitionner, obtenir/construire, délivrer/supporter.
Ce qui distingue ITIL v4 de ses prédécesseurs, c'est son ancrage dans la réalité des organisations modernes : multi-cloud, DevOps, agilité à grande échelle. Les pratiques ne sont plus des processus séquentiels figés, elles sont des capacités modulaires que chaque organisation adapte à son contexte.
ITIL v4 intègre également 34 pratiques de gestion, regroupées en trois catégories : pratiques de gestion générale (14), pratiques de gestion des services (17), et pratiques de gestion technique (3). Parmi elles, plusieurs touchent directement à la sécurité de l'information. C'est ici que les choses deviennent intéressantes et parfois trompeuses.
Ce qu'ITIL dit de la sécurité (et ce qu'il ne dit pas)
ITIL v4 consacre une pratique entière à la gestion de la sécurité de l'information. Elle définit des objectifs clairs : protéger les informations de l'organisation, gérer les risques, assurer la disponibilité, l'intégrité et la confidentialité des données. Elle est alignée avec ISO 27001 et intègre les notions de politique de sécurité, de classification de l'information et de gestion des incidents de sécurité.
Les principes posés sont solides. Sur le papier.
Mais ITIL est un référentiel de gestion, pas un standard de sécurité technique. Il décrit quoi faire pas comment vérifier que ce qui est fait résiste à une attaque réelle.
Prenons un exemple concret. La pratique de gestion de la sécurité ITIL vous dira de maintenir une liste des actifs informationnels critiques et de définir des contrôles d'accès adaptés. Elle ne vous dira pas si ces contrôles d'accès sont effectivement contournables via une attaque de type Pass-the-Hash sur votre Active Directory, ni si un prestataire avec un accès VPN legacy constitue une porte d'entrée exploitable en moins d'une heure.
Elle vous dira de documenter vos procédures de gestion des incidents de sécurité. Elle ne vous dira pas si votre SOC détecte effectivement un mouvement latéral furtif dans votre Active Directory, ni en combien de temps.
C'est la différence fondamentale entre une posture de conformité et une posture de résilience. L'une documente. L'autre démontre.
| Ce qu'ITIL structure | Ce qu'ITIL ne teste pas |
|---|---|
| Procédures de gestion des incidents de sécurité | La détection réelle d'une intrusion furtive |
| Politique de gestion des changements (CAB) | L'impact d'une supply chain compromise |
| Catalogue de services et niveaux de service (SLA) | La résistance des accès prestataires à une attaque |
| Gestion des actifs et des configurations (CMDB) | L'exposition réelle de vos systèmes depuis Internet |
| Pratique de gestion des risques | La chaîne d'exploitation effective d'une vulnérabilité |
| Amélioration continue des services | La régression sécurité après chaque mise en production |
Les 5 pratiques ITIL qui ont un impact direct sur la sécurité offensive
Certaines pratiques ITIL, bien appliquées, créent des conditions favorables à une bonne posture de sécurité. D'autres, mal calibrées, deviennent des vecteurs d'exposition. Voici les cinq qui méritent une attention particulière.
1. Gestion des incidents (Incident Management)
ITIL définit un processus structuré de détection, qualification, escalade et résolution des incidents. En théorie, c'est exactement ce qu'une équipe SOC devrait suivre lors d'une intrusion : identifier l'événement, le qualifier, escalader vers le bon niveau, contenir, remédier, documenter.
En pratique : la majorité des processus incidents ITIL sont calibrés pour des pannes applicatives, pas pour des scénarios d'attaque. Les seuils d'alerte sont définis sur des métriques de disponibilité (uptime, temps de réponse), pas sur des indicateurs comportementaux (connexions inhabituelles, volume d'authentifications NTLM, accès à des partages réseau non fréquentés).
Les playbooks de réponse aux incidents de sécurité quand ils existent, ne sont que rarement testés face à un adversaire simulé. Un test d'intrusion interne révèle systématiquement si vos procédures ITIL de gestion des incidents tiennent réellement sous pression offensive et à quelle étape elles se grippent.
Donnée de terrain PIIRATES : sur les 10 dernières missions Redteam conduites dans des organisations avec processus ITIL formalisé, le délai médian de première détection d'une alerte SOC était de 22 jours. Dans 3 cas sur 10, aucune alerte n'a été générée sur toute la durée de la mission.
2. Gestion des changements (Change Management)
La pratique de gestion des changements et son comité CAB (Change Advisory Board) vise à maîtriser les modifications apportées aux systèmes de production. C'est l'un des meilleurs alliés de la sécurité quand il est bien appliqué : chaque changement est évalué, approuvé, documenté et réversible.
Mais voici le paradoxe : un processus de changement trop rigide retarde les correctifs de sécurité critiques. Un processus trop permissif laisse passer des modifications non contrôlées qui créent des vulnérabilités. L'équilibre est difficile et rarement évalué concrètement.
Cas typique : une vulnérabilité critique est publiée un vendredi soir. Le prochain CAB est le mardi. La fenêtre d'exploitation est ouverte pendant 4 jours. ITIL prévoit des procédures de changements d'urgence mais dans combien d'organisations sont-elles réellement utilisées pour les patches sécurité critiques, sans être court-circuitées ou retardées par des frictions organisationnelles ?
À l'inverse, les changements mal documentés sont une source fréquente de régression sécurité. Un nouveau serveur déployé hors du processus standard, une règle firewall ajoutée en urgence et jamais retirée, un accès prestataire ouvert pour un projet et jamais fermé à son terme autant de vecteurs qu'un test d'intrusion met systématiquement en lumière.
3. Gestion des actifs et des configurations (SACM)
La CMDB (Configuration Management Database) est censée recenser l'ensemble des actifs informatiques et leurs dépendances. C'est une base fondamentale pour comprendre votre surface d'attaque : si vous ne savez pas ce que vous avez, vous ne pouvez pas le protéger.
Réalité de terrain : dans plus de 80 % des organisations, la CMDB est incomplète, outdatée ou ne couvre pas les assets cloud et les SI shadow. Ce que vous ne voyez pas dans votre CMDB, un attaquant le trouvera via Shodan ou une reconnaissance OSINT en quelques heures.
Les angles morts les plus fréquents que PIIRATES identifie lors de la phase de reconnaissance OSINT : sous-domaines oubliés rattachés à d'anciennes filiales, buckets cloud publics contenant des credentials, interfaces d'administration exposées sur des ports non standards, certificats TLS révélant des hôtes internes non documentés, et dépôts Git publics avec des tokens d'API ou des fichiers .env.
La bonne nouvelle : un audit de surface d'attaque externe (EASM) peut alimenter et corriger votre CMDB de façon continue. C'est une pratique ITIL d'amélioration des actifs qui se nourrit directement de la perspective offensive.
4. Gestion des problèmes (Problem Management)
La gestion des problèmes ITIL cherche les causes racines des incidents récurrents pour les éliminer durablement. Appliquée à la sécurité, c'est exactement la logique d'une analyse post-incident ou d'un retour d'expérience après une compromission.
Les organisations qui intègrent leurs findings de tests d'intrusion dans leur processus de Problem Management ITIL sont celles qui progressent le plus vite en maturité sécurité. Chaque vulnérabilité trouvée lors d'un pentest devient un Problem Record : cause racine documentée, priorité définie selon l'impact business réel, correctif planifié avec un responsable désigné et un délai contractualisé, vérification post-remédiation lors du prochain test.
C'est aussi ce qui transforme un rapport de pentest souvent perçu comme une liste de problèmes en un plan d'action structuré avec des indicateurs de suivi. Le Problem Management ITIL est le processus naturel pour absorber et piloter les résultats d'un audit de sécurité.
5. Amélioration continue (Continual Improvement Practice)
C'est la pratique ITIL la plus proche de l'esprit d'une démarche de sécurité offensive mature. L'amélioration continue suppose de mesurer régulièrement l'écart entre l'état actuel et l'état souhaité et d'agir pour le réduire.
ITIL v4 propose le modèle en 7 étapes : Quelle est la vision ? Où en sommes-nous ? Où voulons-nous être ? Comment y arriver ? Agir. Avons-nous atteint l'objectif ? Comment maintenir l'élan ?
Or, comment améliorer ce qu'on ne mesure pas ? Un test d'intrusion annuel, intégré dans la boucle d'amélioration continue ITIL, est l'indicateur de progression le plus objectif qui soit. Il fournit des données concrètes là où les audits de conformité donnent des cases à cocher. Le taux de vulnérabilités critiques résiduelles, le délai médian de détection SOC, le pourcentage d'actifs correctement protégés : autant de métriques qui alimentent directement les rapports d'amélioration continue.
ITIL, NIS2 et les référentiels complémentaires : où se situe la sécurité offensive ?
ITIL ne vit pas seul. Dans la plupart des grandes organisations, il coexiste avec d'autres référentiels et réglementations : ISO 27001, COBIT, SOC 2, et désormais la directive NIS2 pour les entités essentielles et importantes.
La directive NIS2, entrée en application en octobre 2024, impose aux organisations concernées de mettre en place des mesures de gestion des risques de cybersécurité et de démontrer leur efficacité. Ce n'est plus seulement documenter : c'est prouver.
Ce que NIS2 impose que votre ITIL seul ne couvre pas :
- Évaluation régulière de l'efficacité des mesures de sécurité (et non juste leur existence)
- Gestion des risques liés à la chaîne d'approvisionnement et aux prestataires tiers
- Capacité de réponse aux incidents démontrée et non juste documentée
- Tests de continuité et de reprise après sinistre incluant des scénarios cyber
- Responsabilité des dirigeants sur la posture de sécurité (Article 20)
C'est précisément là que la sécurité offensive complète ITIL. Là où le référentiel structure vos processus, le test d'intrusion valide que ces processus résistent à un adversaire réel. L'un sans l'autre crée une illusion de contrôle.
Un RSSI qui suit ITIL rigoureusement mais ne fait jamais tester son SI sait ce qu'il devrait faire face à une attaque. Un RSSI qui couple ITIL et tests offensifs réguliers sait ce qu'il fait réellement face à une attaque. La nuance est de taille.
Les KPIs sécurité à intégrer dans vos tableaux de bord ITIL
L'un des apports les plus concrets de la sécurité offensive à une démarche ITIL, c'est la production d'indicateurs de performance réels — et non déclaratifs. Voici les métriques issues des tests offensifs qui s'intègrent naturellement dans les rapports ITIL d'amélioration continue.
| KPI sécurité offensive | Pratique ITIL associée | Ce qu'il mesure concrètement |
|---|---|---|
| Délai médian de détection (MTTD) | Gestion des incidents | Combien de jours avant que votre SOC détecte une intrusion active |
| Délai médian de réponse (MTTR) | Gestion des incidents | Combien de temps pour contenir une compromission une fois détectée |
| Taux de détection EDR/SIEM | Gestion des incidents | % des actions offensives effectivement détectées par vos outils |
| Taux de vulnérabilités critiques résiduelles | Amélioration continue | % de findings critiques non remédiés 90 jours après un pentest |
| Couverture CMDB vs surface réelle | Gestion des actifs | Écart entre les actifs recensés et les actifs trouvés par OSINT |
| Délai de patch post-CVE critique | Gestion des changements | Temps entre publication d'une CVE critique et application du correctif |
| % d'accès prestataires actifs non revus | Gestion des fournisseurs | Accès VPN/applicatifs ouverts sans revue depuis plus de 6 mois |
| Nombre de comptes à privilèges non nécessaires | Gestion des accès | Comptes avec droits élevés identifiés hors du référentiel attendu |
Ces indicateurs ont un avantage décisif sur les métriques ITIL classiques : ils sont difficilement contestables. Un taux de détection SOC à 18 % mesuré lors d'un Redteam, c'est un fait pas une estimation, pas un audit documentaire. C'est le type de donnée qui fait bouger les lignes en COMEX.
Recommandation PIIRATES : intégrez au minimum deux métriques issues de tests offensifs dans vos rapports ITIL d'amélioration continue trimestriels. C'est suffisant pour créer une dynamique de progression mesurable et pour ancrer la sécurité offensive dans la gouvernance IT ordinaire.
Comment intégrer les tests de sécurité dans votre cycle de vie ITIL
L'intégration de la sécurité offensive dans un framework ITIL existant ne nécessite pas de tout remettre à plat. La clé : ne pas traiter le pentest comme un événement ponctuel externe, mais comme une pratique récurrente intégrée au cycle de vie des services.
-
Cartographier votre surface d'attaque dans la CMDB. Avant tout test, assurez-vous que vos actifs critiques sont référencés et à jour. Mais ne vous arrêtez pas là : un audit de surface d'attaque externe (EASM) complète ce que votre CMDB ne voit pas sous-domaines oubliés, buckets cloud exposés, credentials leakés sur des forums. Ce delta entre ce que vous pensez avoir et ce qu'un attaquant trouve est souvent l'information la plus utile du processus.
-
Intégrer les pentests dans la gestion des changements. Tout changement d'infrastructure majeur migration cloud, refonte AD, nouveau partenaire avec accès VPN, déploiement d'une nouvelle application métier exposée devrait déclencher un test de sécurité ciblé. Inscrivez ce déclencheur comme critère de go/no-go dans votre processus CAB pour les changements à risque élevé.
-
Alimenter la gestion des problèmes avec les findings offensifs. Chaque vulnérabilité identifiée lors d'un pentest devient un Problem Record ITIL : cause racine documentée, priorité définie selon l'impact business réel (pas juste le score CVSS), correctif planifié avec responsable et échéance, et vérification post-remédiation systématique lors du prochain test. Ce cycle court-circuite le phénomène du rapport de pentest qui finit dans un tiroir.
-
Tester vos procédures d'incidents face à un scénario réel. Lors d'une mission Redteam, votre équipe de défense est activée sans savoir qu'elle est testée. Le résultat documente objectivement si vos processus ITIL de gestion des incidents fonctionnent sous pression et où ils se grippent. Quel niveau d'alerte a été atteint ? Le bon interlocuteur a-t-il été escaladé ? La procédure de confinement a-t-elle été activée ?
-
Mesurer la progression avec l'amélioration continue. Un test d'intrusion annuel (minimum), complété d'un Purple Team semestriel, crée des indicateurs de progression objectifs intégrables dans vos rapports ITIL d'amélioration continue. C'est le KPI sécurité le plus honnête qui soit parce qu'il est mesuré par quelqu'un qui essaie activement de vous compromettre, pas par quelqu'un qui valide vos propres déclarations.
Chaque organisation a ses propres enjeux IT et sécurité
Notre approche s'adapte à votre niveau de maturité !
ITIL structure vos services. La sécurité offensive valide qu'ils résistent. Couplées, ces deux démarches s'adaptent à tous les environnements — des ETI aux grands groupes, des SI on-premise aux infrastructures cloud hybrides.
Indépendance totale
Expertise offensive
Professionnalisme
Les 4 erreurs fréquentes à éviter
- ✕ Traiter le pentest comme un audit de conformité : Un test d'intrusion n'est pas une liste de cases à cocher. Son résultat n'est pas un score c'est une démonstration. Si votre prestataire vous livre 200 CVE sans scénario d'exploitation réel ni priorisation business, le livrable n'est pas exploitable par votre processus ITIL de Problem Management.
- ✕ Penser qu'une CMDB à jour remplace un audit de surface d'attaque : La CMDB référence ce que vous connaissez. La surface d'attaque réelle inclut ce que vous ignorez : comptes de service oubliés, APIs non documentées, domaines de filiales exposés. Un attaquant commence précisément là.
- ✕ Déclencher un pentest en dehors du cycle de changement : Tester une infrastructure qui va changer dans 3 semaines, c'est tester l'ancienne version. Intégrer le test de sécurité dans le processus ITIL de gestion des changements garantit que les findings sont actionnables et ne deviennent pas obsolètes avant d'être remédiés.
- ✕ Cloisonner les résultats au RSSI sans remontée au COMEX : ITIL positionne le management des services comme une responsabilité partagée entre IT et business. La sécurité aussi. Un rapport de pentest qui ne remonte pas au niveau du DSI ou du COMEX ne génère pas les décisions d'investissement nécessaires à la remédiation. NIS2 rend d'ailleurs les dirigeants personnellement responsables de cette remontée.
Un DSI « full ITIL » confronté à son premier Redteam
Organisation de services financiers 1 200 collaborateurs ITIL depuis 7 ans
Contexte : ISO 27001 certifiée depuis 2021, SOC externalisé avec un SIEM en place, service management office dédié. Déclencheur de la mission : obligation NIS2 et révision du contrat de cyberassurance, qui exige désormais la preuve d'un test d'intrusion récent.
Durée de la mission Redteam PIIRATES : 8 semaines. Périmètre : boîte grise, SI on-premise + Azure AD hybride. Objectif : démontrer si un attaquant externe peut atteindre le système de paiement ou les données clients sensibles.
- CMDB à 85 % de couverture sur le parc on-premise, avec historique des configurations sur 3 ans
- Processus de gestion des changements rigoureux avec validation CAB bi-hebdomadaire et traçabilité complète
- Procédures d'incidents de sécurité documentées, diffusées et connues de l'équipe IT et du SOC externalisé
- Revues trimestrielles de la posture de sécurité présentées au COMEX avec des métriques de disponibilité et de conformité
- Gestion des fournisseurs formalisée avec contrats SLA et revue annuelle des accès tiers
| Semaine | Phase | Découverte clé |
|---|---|---|
| S1-S2 | Reconnaissance OSINT | 3 sous-domaines actifs non référencés en CMDB dont un avec interface d'administration exposée. 2 dépôts GitHub publics avec des tokens d'API Azure encore valides. Un fichier de config révélant la structure interne du réseau. |
| S3 | Accès initial | Spearphishing ciblant un développeur identifié via LinkedIn. Email personnalisé imitant une notification Azure AD. Credential capturé en 18 minutes. Aucune alerte MFA, MFA non activé sur ce compte développeur. |
| S4 | Mouvement latéral initial | Depuis le compte développeur : accès à un dépôt GitLab interne contenant des scripts d'automatisation avec des mots de passe hardcodés pour 4 comptes de service Active Directory. |
| S5 | Élévation de privilèges | L'un des comptes de service dispose de droits d'administration locale sur 40 % du parc Windows. Via Pass-the-Hash : accès à un serveur d'administration. BloodHound révèle un chemin en 2 sauts vers le Domain Controller. |
| S6-S7 | Accès aux crown jewels | Compromission du Domain Controller via DCSync. Accès au serveur applicatif hébergeant le système de paiement. Exfiltration simulée de 500 Mo de données clients. Durée sans détection : 41 jours. |
| S8 | Rapport & debriefing | Présentation COMEX avec timeline complète, preuves de compromission et plan de remédiation priorisé par impact business. |
- La CMDB ne couvrait pas les assets cloud et les environnements de développement, angle mort classique dans les SI hybrides
- Le processus MFA de la gestion des accès avait des exceptions non documentées pour les comptes de développeurs
- Les scripts d'automatisation avec credentials hardcodés n'étaient pas couverts par la politique de gestion des secrets
- Le SOC externalisé n'a déclenché aucune alerte sur 41 jours, les règles SIEM étaient calibrées sur des seuils volumétriques, pas comportementaux
- Les procédures d'incidents de sécurité existaient, mais elles n'avaient jamais été testées sur un scénario d'attaque réel depuis la certification ISO 27001
- 2 tokens d'API Azure sur GitHub avaient expiré dans la CMDB des secrets mais étaient encore valides en production
- Intégration du pentest annuel obligatoire dans le calendrier ITIL des changements majeurs avec budget dédié
- Création d'un Problem Record pour chaque finding critique avec SLA de remédiation : P1 = 72h, P2 = 15 jours, P3 = 90 jours
- Extension de la CMDB aux environnements cloud et de développement avec processus de découverte automatisée trimestrielle
- Déploiement du MFA sur 100 % des comptes sans exception suppression des dérogations non documentées
- Mise à jour du processus d'amélioration continue : taux de détection SOC et MTTD deviennent des KPIs trimestriels contractuels avec le SOC externalisé
- Révision des règles SIEM vers une détection comportementale en s'appuyant sur le MITRE ATT&CK comme référentiel de couverture
- Premier Purple Team planifié 6 mois après la mission pour valider les corrections et entraîner le SOC externalisé
« On pensait qu'ITIL nous avait structurés pour faire face à tout. Le Redteam nous a montré que structurer et résister, ce n'est pas la même chose. Aujourd'hui, les deux se complètent — et nos métriques ITIL intègrent désormais des indicateurs issus des tests offensifs. » DSI de l'organisation, lors du debriefing COMEX
Pour aller plus loin avec PIIRATES
La sécurité offensive complète votre démarche ITIL sur plusieurs niveaux. Selon votre maturité et vos priorités :
- Pentest infrastructure & réseau interne : pour valider la résistance de votre SI face aux techniques d'escalade de privilèges et de mouvement latéral, et alimenter votre Problem Management ITIL avec des findings actionnables
- Audit de surface d'attaque externe (EASM) : pour cartographier ce que votre CMDB ne voit pas et corriger les angles morts avant qu'un attaquant ne les exploite
- Mission Redteam : pour simuler un adversaire réel sur plusieurs semaines et mesurer objectivement l'efficacité de vos processus ITIL de détection et de réponse
- Purple Team : pour entraîner votre Blue Team en conditions réelles et intégrer les résultats dans votre boucle d'amélioration continue ITIL
- Audit Active Directory via PingCastle : pour identifier les comptes à risque, les délégations dangereuses et les vulnérabilités de configuration qui échappent aux revues ITIL standard
ITIL structure, la sécurité offensive valide
ITIL est un cadre de valeur. Il apporte de la rigueur, de la lisibilité et une culture de l'amélioration continue qui manque à beaucoup d'organisations IT. Ce n'est pas son rôle de tester vos défenses, et c'est précisément pourquoi il a besoin d'un complément offensif.
La question n'est pas « ITIL ou sécurité offensive ? ». C'est « comment faire travailler les deux ensemble pour construire une organisation IT à la fois performante et résiliente ? »
Les organisations qui répondent le mieux aux crises cyber ne sont pas celles qui ont le plus de processus documentés. Ce sont celles qui ont testé leurs processus dans des conditions proches du réel et qui ont eu le courage d'en corriger les failles.
Faites tester vos défenses avant qu'un attaquant ne le fasse.
Demandez votre audit de surface d'attaque offert ou planifiez votre premier pentest avec PIIRATES. Échange confidentiel, périmètre défini avec vous, lettre de mission systématique.
Ce que nous ne faisons pas
(Liste non exhaustive)
Piratage de boite mail
Piratage comptes réseaux sociaux
Espionnage
Exfiltration de sms
Récupération de Cryptomonnaies
Prise en main à distance de véhicules
Suivi GPS de véhicule
Envoyez nous un ping
Oui. ITIL v4 intègre parmi ses 34 pratiques une pratique dédiée à la gestion de la sécurité de l'information. Elle couvre la politique de sécurité, la gestion des risques, la continuité et la gestion des incidents de sécurité. Cependant, elle reste à un niveau de cadrage et de gouvernance — elle ne prescrit pas de méthodes de test ou de validation technique de la résistance aux attaques. C'est précisément pour cela qu'elle se complète avec un test d'intrusion régulier.
Un pentest ne remplace aucun processus ITIL — il le valide. Il teste si vos procédures de gestion des incidents détectent réellement une intrusion, si votre CMDB reflète votre surface d'attaque réelle, si vos contrôles de changement empêchent les régressions de sécurité. Les résultats alimentent directement le Problem Management et l'amélioration continue, deux pratiques ITIL centrales. C'est un enrichissement, pas une remise en cause du référentiel.
Non. La directive NIS2 exige de démontrer l'efficacité des mesures de sécurité, pas seulement leur existence. Un référentiel de gestion comme ITIL structure vos pratiques. NIS2 exige que vous prouviez que ces pratiques fonctionnent face aux menaces réelles — ce qui passe par des tests techniques, des audits de sécurité et une capacité de réponse aux incidents éprouvée. La certification ISO 27001 aide, mais ne suffit pas non plus sans tests opérationnels. PIIRATES accompagne les organisations dans cette démonstration.
Non, absolument pas. Un test d'intrusion est utile à tout niveau de maturité — et souvent plus révélateur pour les organisations qui n'ont pas encore formalisé leurs processus. Dans ce cas, le rapport de pentest devient lui-même une feuille de route pour structurer les priorités, qu'elles soient ensuite intégrées dans ITIL ou non. La maturité ITIL n'est pas un prérequis à la sécurité offensive — c'est un accélérateur de l'exploitation des résultats.
Traduisez les résultats en indicateurs de service et de risque business. Un taux de détection SOC de 12 % sur une mission Redteam, c'est un SLA de sécurité qui n'est pas tenu. Un compte de service compromis avec droits Domain Admin, c'est un risque de continuité d'activité critique. Le langage ITIL — SLA, risque, impact service, amélioration continue — est précisément celui qui permet de faire remonter les enjeux offensifs au niveau décisionnel. PIIRATES structure ses livrables pour que l'executive summary soit directement exploitable en COMEX.
ITIL structure vos services IT, mais ne teste pas vos défenses. Découvrez comment intégrer pentest et sécurité offensive dans votre cycle ITIL. Expertise PIIRATES.
