Lorsque l'on travaille dans le domaine de la cybersécurité et plus particulièrement de la détection des incidents (exemple dans un SOC), il y a souvent une confusion entre les événements de sécurité et les incidents de sécurité notamment chez les clients.

Peut-être avez-vous entendu ?

Ces logs sont truffés d'incidents ?
Alerte, on vient de recevoir un événement de sécurité ?
Mais au fait, combien faut-il d'événements pour faire un incident ?

On a donc le droit à une jolie terminologie mixte, à l'instar de crypter/chiffrer. La distinction peut paraitre anodine, mais en réalité la différence est importante et permet de réagir différemment selon les faits rencontrés.

Voyons la manière dont nous pouvons définir ces termes en prenant en compte les définitions du NIST (800-61 du NIST) et l'ETSI (ETSI GS ISI 002 V1.2.1 (2015-11)) :

Un événement

De manière générale, un événement un élément observable dans l'infrastructure informatique. Il peut-être aussi bien bénin que malin. Par exemple : la mise à jour du pare-feu est un événement.

Ensuite, plus précisément, les événements de sécurité sont des éléments qui peuvent altérer spécifiquement la sécurité de l'entité avec l'apparition d'un risque pour celle-ci. Exemple : la réception d'un courriel avec un virus en pièce jointe.

Une alerte est une notification de l'occurrence d'un événement particulier (ou d'une série d'événements). Par exemple, le SOC reçoit une alerte lorsqu'un utilisateur essaie de s'authentifier plus de 5 fois sans succès.

Selon l'ETSI, un événement de sécurité est forcément soit l'occurrence ou la détection d'une vulnérabilité, soit un incident de sécurité. 500 événements de sécurité ont été inventoriés dans l’industrie et sont regroupés en 9 catégories principales, les 3 premières correspondant à des incidents et les 4 dernières à des vulnérabilités :

  • attaques et intrusions externes ;
  • défaillances ;
  • comportements déviants internes ;
  • vulnérabilités comportementales ;
  • vulnérabilités logicielles ;
  • vulnérabilités de configuration ;
  • vulnérabilités de sécurité générale (techniques ou organisationnelles).

Un incident de sécurité

Tous les événements ne sont pas des incidents, mais tous les incidents sont des événements. Un incident est donc un événement qui affecte négativement les systèmes d'information. Il s'agit donc d'une interruption imprévue de la disponibilité, de l'intégrité ou de la confidentialité des SI.

Le NIST et le CERT définissent les incidents comme des violations de la politique de sécurité des systèmes d'information, qu'elle soit implicite ou explicite. Cette définition est vue comme trop restrictive par l'ETSI par exemple comme le montre le schéma. L'organisme européen évoque également l'exploitation d'une vulnérabilité connue et acceptée ou d'une vulnérabilité inconnue.

Par exemple, une attaque en déni de service distribuée (DDoS) qui altère la disponibilité d'un site Internet et utilise une vulnérabilité connue et identifiée de la plupart des hébergeurs.

On peut noter que les événements ne sont pas toujours négatifs, les incidents le sont.
Un incident nécessite une réponse rapide et adaptée. C'est d'ailleurs tout le sens d'un SOC qui permet d'agir rapidement lors de l'irruption d'un incident de sécurité, en lien étroit avec le bénéficiaire de nos services.

Enfin, une série d'incidents peut se transformer en crise.

Il est important que les entreprises définissent leur propre seuil pour définir un incident ou une crise. Cela permet d'améliorer la collaboration entre l'IT, la sécurité, la conformité, les services juridiques et la direction. Sans l'établissement de règles au préalable, les entreprises perdent un temps précieux pour décider d'agir ou escalader en gestion de crise si nécessaire.

Définir les notions permet de guider vos réponses aux incidents et améliore la protection contre les risques réglementaire et en matière de réputation.