Gestion opérationnelle des incidents de Sécurité

Fiche Pratique
Juin
2013
Club des Responsables
d’Infrastructures et de Production
Sécurité
Gestion opérationnelle
des incidents de Sécurité
Problématiques
Les risques de sécurité qui pèsent sur les SI des entreprises
augmentent chaque année. En effet, une part croissante des
activités se digitalise, ce qui entraîne un accroissement de
la quantité de données confidentielles présentes dans le SI
(données à caractère personnel ou données sensibles pour
l’entreprise). De plus, pour atteindre plus facilement et plus
rapidement les clients et les partenaires, et rester en contact
avec les collaborateurs, l’exposition du SI à la toile augmente
sans cesse. Cet état de fait suscite un intérêt croissant des
pirates et criminels, comme en atteste la multiplication des
cyberattaques.
Parallèlement, le contexte réglementaire tend à imposer
de façon croissante aux entreprises une obligation de
notification des incidents critiques de sécurité qui les frappent.
Aujourd’hui, ces dispositions touchent principalement les
opérateurs de communications électroniques (transposition
dans le droit français du Paquet Telecom). Mais ce mouvement
risque de s’étendre à d’autres entreprises dès lors que les
projets européens (Data Protection Regulation / Network and
Information Security) aboutiront.
Notification d’incidents contexte réglementaire Européen
Pour faire face à ces évolutions, les entreprises doivent se
doter de dispositifs de détection et de traitement des incidents
de sécurité efficaces. Les équipes Sécurité se trouvent
bien évidemment au cœur de ces dispositifs, mais elles ne
peuvent pas détecter et traiter l’ensemble des incidents par
leurs seuls moyens. Les événements de sécurité pouvant
donner lieu à des incidents sont généralement remontés par
des outils techniques, gérés et exploités par des équipes
Sécurité, mais cela ne suffit pas. Comment dès lors étendre les
canaux de détection et d’alerte au-delà de ces seuls outils ?
Comment qualifier la gravité d’un incident de sécurité et
communiquer sur les risques associés ?
Une fois l’incident de sécurité remonté et qualifié, il est
parfois compliqué de mobiliser les équipes opérationnelles,
généralement plus enclines à résoudre des incidents de
production impactant uniquement la disponibilité des services
et applications vis-à-vis des utilisateurs/clients. Le risque de
voir leur implication diminuer au cours du temps si l’incident de
sécurité n’impacte que peu d’utilisateurs, voire aucun, est réel.
Par ailleurs, la nécessité de solliciter les équipes de Production
pour traiter de manière rapide et efficace un incident de
sécurité va souvent à l’encontre de la volonté de conserver la
confidentialité des incidents de sécurité que subit l’entreprise.
Analyse
Il paraît légitime d’adosser la gestion des incidents de sécurité
aux processus standards ITIL car ils sont généralement bien
ancrés dans les entreprises et ont depuis longtemps démontré
leur efficacité. Ce mode de fonctionnement permet de bénéficier
de dispositifs opérationnels et de schémas d’escalade déjà en
place, ainsi que des outils de ticketing existants. Problème :
ces derniers sont malheureusement accessibles à un grand
nombre d’acteurs de l’entreprise. Afin de préserver le niveau de
confidentialité approprié aux incidents de sécurité, il conviendra
d’en intégrer le détail dans un référentiel à accès restreint,
et seules les actions nécessaires au traitement de l’incident
apparaîtront dans l’outil de ticketing.
Certains types d’incidents de sécurité touchant à la fraude,
aux comportements de certains collaborateurs ainsi que les
incidents possédant un impact réglementaire garderont un
mode de traitement spécifique. Dans ce dernier cas de figure,
les dispositifs de communication vis-à-vis des instances de
réglementation devront être définis en amont. La gestion de
ces obligations de communication pourra passer par la mise
en place d’une cellule regroupant notamment les acteurs de
la sécurité, les responsables du Juridique, le correspondant
Informatique et Liberté (CIL), qui aura la charge d’instruire visà-vis de la CNIL les incidents portant atteinte aux données à
caractère personnel (détail de l’incident, nombre d’utilisateurs/
volumétrie des données impactées, etc.).
D’autres spécificités devront être prises en compte dans la
gestion des incidents de sécurité. Les équipes de Production
peuvent être amenées à isoler des périmètres d’infrastructure
pour limiter la propagation d’une attaque informatique, ce qui
est contradictoire avec leur objectif prioritaire de rétablissement
du service. Par ailleurs, la durée d’une crise de sécurité peut
être significativement plus importante que celle d’une crise de
production. La gestion dans le temps des ressources affectées
au traitement de la crise doit donc être prise en compte. On ne
peut pas mobiliser durant des semaines les mêmes personnes
sur des plages horaires étendues, au risque de perdre en
efficacité et lucidité.
Schéma de principe du process incident de sécurité
L’incident est clos dès lors que l’impact sécurité a été traité.
Les actions / chantiers de plus long terme visant à corriger la
source de l’incident (« root cause ») sont traités dans la gestion
des problèmes.
Pour permettre une plus large captation des incidents de
sécurité, il convient de définir un dispositif de pré-qualification des
incidents, sous la forme d’une fiche d’aide à la qualification.
Son principal objectif sera de permettre à des personnes n’ayant
pas de spécialisation en sécurité de qualifier un événement
observé en incident de sécurité potentiel. Il faudra diffuser cette
fiche par l’intranet et la faire connaître par des campagnes de
sensibilisation vers l’ensemble des acteurs de l’entreprise.
Un exemple : lorsque la consommation CPU habituellement
inférieure à 10 % d’un serveur augmente d’un coup pour
atteindre 100 %, les personnes en charge de son exploitation
doivent envisager que ce serveur puisse faire l’objet d’une
attaque par déni de service. La fiche d’aide à la qualification
décrit ce symptôme et sa cause possible, et fournit également les
points de contact et les premiers réflexes à avoir en cas d’incident
potentiel. Par exemple, elle précisera qu’il ne faut pas arrêter
brutalement un serveur éventuellement compromis.
La qualification précise de l’incident requiert la mise en œuvre
d’une matrice d’indice de gravité des incidents de sécurité
basée sur 3 axes :
Les catégories d’incidents :
Lorsque le traitement d’un incident de sécurité requiert des
échanges avec les équipes métier, l’utilisation de la matrice
d’indices de gravité des incidents de sécurité n’est pas toujours
adaptée. C’est pourquoi une matrice des impacts métier sera
privilégiée pour une meilleure communication sur l’incident en
cours auprès des équipes métier. Cette matrice est classiquement
basée sur une catégorie et un niveau d’impact métier :
• Perte financière,
• Atteinte à la réputation / image de marque,
• Réglementation / Juridique,
• Insatisfaction clients,
• Disponibilité des services.
L’ensemble des matrices de qualification de la gravité des
incidents de sécurité doit être élaboré avec les acteurs de
l’entreprise (directions métier, équipes opérationnelles) pour
une meilleure adhésion au dispositif, facteur clé de succès.
Les retours d’expérience sur les incidents de sécurité majeurs
doivent permettre de réévaluer régulièrement la pertinence de ces
matrices et sont l’occasion d’expliquer et de communiquer sur le
niveau de gravité de l’incident.
Par ailleurs, dans un souci d’amélioration continue, des exercices
de crise de sécurité peuvent être réalisés périodiquement en se
basant sur différents types de scénarios :
• le plus probable,
• Accès, modification, collecte non autorisés de données,
• celui qui présente le plus fort impact technique,
• Divulgation d’information,
• le plus transverse (impactant le plus de directions
techniques et métier),
• Intrusion / prise de contrôle,
• Comportements anormaux (usages frauduleux, usages
abusifs, comportements déviants,…),
• Présence de fichiers malveillants (malware),
• Dysfonctionnements (déni de service, par exemple :
indisponibilité de service non expliquée),
• Vulnérabilités critiques.
Le niveau de sensibilité des actifs impactés (services, applications ou données).
L’ampleur de l’incident (nombre d’actifs impactés, niveau de
contagion).
Notons que la détection de vulnérabilités critiques gagne à être
traitée dans le processus de gestion des incidents plutôt que dans
celui de gestion des problèmes pour bénéficier d’une meilleure
réactivité. Le traitement de l’incident consiste à corriger la faille
de sécurité et déterminer si elle a fait l’objet d’une exploitation.
Dans ce dernier cas de figure, un nouvel incident devra être créé.
Afin de permettre aux équipes en charge de l’évaluation de la
gravité d’un incident de bien assimiler la matrice Indices de
Gravité Sécurité, chaque ligne de la matrice devra être
accompagnée d’exemples d’incidents de sécurité déjà
rencontrés. Cette approche requiert la mise en place d’un
référentiel / historique des incidents de sécurité.
Pour bénéficier des dispositifs de mobilisation et d’escalade
déjà en place, l’échelle des indices de gravité des incidents de
sécurité doit être calquée sur celle des indices de gravité des
incidents de production et doit intégrer le principe d’escalade
dans la durée (plus l’incident dure sans résolution, plus son indice
de gravité augmente).
• celui qui est couplé avec un exercice de PRA (par exemple,
le scénario de déclenchement du PRA en réponse à une
attaque informatique massive de type déni de service).
Conclusion
La communication, la sensibilisation, l’accompagnement
au changement sont nécessaires pour contribuer à faire
de la sécurité l’affaire de tous. La bonne gestion du Run des
incidents de sécurité dépend donc largement de la phase de
construction des dispositifs (Build) qui la précède et la prépare.
Rédaction : Renaud Bonnet, CRiP - Création Fred.lameche - www.anousdejouer.fr
La gestion structurée des incidents de sécurité devient une
nécessité forte dans un contexte de menaces et d’obligations
qui se multiplient. Les professionnels de la sécurité ont
donc tout intérêt à se rapprocher des procédures déjà en
place dans la gestion des incidents de Production et des
pratiques ITIL, sans négliger pour autant les spécificités
réglementaires et de confidentialité propres à leur pratique.
Club des Responsables d’Infrastructures et de Production
24 rue Erlanger 75016 Paris - [email protected]
www.crip-asso.fr
En application de la loi du 11 mars 1957, il est interdit de reproduire ; sous forme de copie, photocopie, reproduction, traduction ou conversion, le
présent ouvrage que ce soit mécanique ou électronique, intégralement ou partiellement, sur quelque support que ce soit, sans autorisation du CRiP.