Rechercher
Contactez-nous Suivez-nous sur Twitter En francais English Language
 











Abonnez-vous gratuitement à notre NEWSLETTER

Newsletter FR

Newsletter EN

Vulnérabilités

Se désabonner

La gestion des incidents de sécurité doit faire l’objet d’une démarche spécifique

octobre 2014 par Emmanuelle Lamandé

Exploiter l’information remontée par le SI s’avère une tâche complexe et fastidieuse. En effet, rien ne sert de collecter des tonnes de données si l’on n’en extrait pas une information pertinente et exploitable pour les équipes sécurité. L’objectif est également aujourd’hui d’atteindre un délai optimum entre la détection de tout incident et la réaction appropriée. Pour ce faire, l’entreprise doit disposer d’une démarche spécifique de gestion des incidents de sécurité. Elle pourra également compter sur quelques alliés précieux, tels que le SOC, la cartographie ou les nouveaux standards de l’ISG ISI. Le CLUSIF revient sur les bonnes pratiques en la matière à l’occasion d’une conférence dédiée.

En matière de cyberdéfense et de SIEM, avant la vision était uniquement technologique avec la volonté de détecter tout incident, constate Gérard Gaudin, Président du Club R2GS. Le problème était alors de devoir trier des masses gigantesques de données. Cette période a conduit au développement de systèmes complexes, coûteux avec des résultats décevants. Les fournisseurs de solutions ont aussi leur part de responsabilité dans cet échec, quant aux prétentions de ce qu’étaient capables de faire les solutions de SIEM à l’origine. Aujourd’hui, du chemin a été fait. La vision s’est élargie en allant au-delà des aspects purement technologiques.

Pour lui, plusieurs besoins ressortent à l’heure actuelle : notamment atteindre un délai optimum entre la détection, l’action et la réaction, mais aussi pouvoir s’appuyer sur de nouveaux standards. Nous devons passer d’une culture qualitative à une culture quantitative en matière de cybersécurité. Les taux de détection restent très faibles aujourd’hui (entre 10 à 20%). La nécessaire gestion des vulnérabilités reste, quant à elle, sous-estimée et l’hygiène informatique encore peu appliquée.

Actuellement les frustrations restent perceptibles, mais tout n’a pas été fait. Deux axes majeurs sont à privilégier :
 L’évaluation statistique des incidents et vulnérabilités : il nous faut des chiffres, ainsi qu’un état de l’art ;
 Les spécialistes IT et sécurité ne peuvent pas tout faire tout seul. C’est pourquoi il est nécessaire de mettre l’humain au cœur de la cybersécurité. Le RSSI doit mobiliser le management et trouver les moyens de mieux communiquer avec le COMEX. Il est essentiel de se porter sur les vrais leviers de motivation.

Nous avons également besoin d’un nouveau standard en matière de cyberdéfense. L’ETSI a créé, en ce sens, l’ISG ISI (Industry Specification Group for Information Security Indicators), dont l’objectif est de couvrir l’ensemble du spectre de la détection des événements de sécurité (indicateurs, modèle de classification d’événements, maturité, test…) au travers de 5 nouveaux standards : ISI-001 ; ISI-002 ; ISI-003 ; ISI-004 et ISI-005. Cette démarche devrait à la fois faciliter l’approche quantitative, permettre d’accélérer les progrès en cybersécurité à travers une approche solide alignée sur les préoccupations du management, et stimuler les échanges au sein de la profession.

SOC et cartographie : deux alliés indispensables

En vu d’améliorer le temps de détection et de réaction aux incidents de sécurité (IS), de plus en plus d’entreprises disposent désormais d’un SOC (Security Operation Center), observent Jean Olive & Thibault Chevillotte, CGI Business Consulting. L’objectif est, en effet, d’être en mesure d’analyser et de traiter tous les événements de sécurité dans un délai optimal. Il faut être capable de détecter les anomalies à partir des événements, puis de qualifier celles-ci en événements de sécurité. Ensuite, l’entreprise, au travers de son SOC, doit pouvoir réagir à ces incidents le plus rapidement possible et surtout éviter qu’ils ne se reproduisent.

Pour ce faire, le SOC doit cependant disposer d’une cartographie de l’entreprise et de son SI. La cartographie permet d’essayer de contextualiser les indicateurs, de savoir où l’incident se passe, quelles incidences cela aura sur le réseau, d’être capable de réagir, via des moyens de protection cohérents pour l’entreprise. Dans cette démarche, l’approche technique (inventaire technique, liste des logiciels…) ne doit pas être dissociée de l’approche fonctionnelle (métiers, processus, services…), les deux étant liées.

Le responsable du SOC a besoin d’avoir une vue logique : réseaux interne et externe de l’entreprise, équipements de filtrage, de sécurité, sondes, serveurs de services… C’est le minimum à avoir sur le SI. A partir de cela, on va pouvoir positionner les sondes de logs, chercher les points d’accès et éventuelles traces d’attaques, mais aussi déterminer où l’on va pouvoir agir. C’est un processus continu qui s’effectue dans la durée. En effet, les mesures de sécurité doivent sans cesse être ajustées en fonctions des incidents de sécurité, attaques…

Cependant, cette vision, seule, ne suffit pas. Il a également besoin d’avoir une vision des domaines AD, c’est-à-dire d’administration. Par exemple, si un compte est compromis, il est essentiel de pouvoir voir comment l’attaque risque de se propager en fonction des droits d’administration.

La cartographie doit donc se focaliser sur les annuaires, les biens critiques et les endroits où ils sont, les points d’accès externes, les droits d’administration… Elle doit permettre de positionner les sources de logs, de qualifier un incident et de savoir comment réagir, de faire apparaître les indicateurs dans leur contexte… Pour être efficiente, les responsables sécurité doivent, de plus, se rapprocher des architectes urbanistes. Ces derniers sont souvent en charge de la conception de la cartographie, alors qu’ils n’ont pas forcément une bonne vision de la sensibilité des informations. C’est donc un travail qui doit se faire de concert.

Cette démarche doit, en outre, être progressive. Plusieurs niveaux de maturité existent, en effet, en la matière. L’entreprise peut, par exemple, commencer par lister dans un premier temps les contacts à avertir en cas de problème, puis ultérieurement les applications, les points d’accès externes, les domaines d’administration… Ca ne sert à rien de voir trop grand, mieux vaut y aller étape par étape. Afin d’accompagner les entreprises dans la mise en place de ce type de cartographie, l’ANSSI va d’ailleurs prochainement publier un guide dédié.

La procédure doit précéder les acteurs et les outils

En matière d’incidents de sécurité, il est primordial avant toute chose de disposer d’une procédure, explique Frédéric Malmartel, ACOSS. L’objectif d’une démarche spécifique de gestion des incidents de sécurité est de faire en sorte que les incidents de sécurité restent sous contrôle, de prévenir le risque inadmissible, de participer à une amélioration constante, mais aussi de préparer une conformité ISO-27001. Il s’agit donc avant tout qu’un incident de sécurité n’en entraîne pas un autre et ne se généralise pas à toute l’entreprise.

La gestion des incidents de sécurité doit venir s’inscrire dans la gestion globale de l’entreprise. Pour qu’elle fonctionne, la procédure se doit, de plus, d’être simple. La confidentialité et la communication représentent également, selon lui, deux points clés de la démarche. En effet, la gestion d’un IS dépend du degré de confidentialité des informations victimes de l’information. Cette gestion doit toutefois être évolutive dans le temps, car une information confidentielle à un instant T ne le sera pas forcément dans la durée. La communication qui sera faite de tel ou tel incident dépendra également de ce niveau de confidentialité.

Pour conclure, il est essentiel de commencer par les processus et les acteurs ; viendront ensuite les outils. C’est, en effet, le process qui fera que la gestion des incidents sera pertinente ou non. Et quoi qu’il en soit, elle se doit d’être pratico-pratique pour être efficiente et opérationnelle. Elle nécessite enfin un peu de recul et d’anticipation.


Voir les articles précédents

    

Voir les articles suivants