Ajouter un commentaire

Par :
Hicham Bouali

jeu, 26/08/2021 - 13:48

La plupart des professionnels de la sécurité estiment que leurs délais de réponse pourraient être beaucoup plus courts s’ils disposaient de logs adéquats, ce qui n’est généralement pas le cas.

Lorsqu’un incident survient, les équipes d’intervention sont régulièrement confrontées au même obstacle : le manque de logs exploitables. Entre pénurie de journaux et mauvaise configuration, il faut souvent attendre qu’une cyberattaque se produise pour que les entreprises comprennent à quel point elles sont aveugles.

Les logs sont des fichiers qui contiennent les actions associées à des événements survenus dans une application ou un système informatique. Malgré leur simplicité, les journaux d’événements constituent la principale source d’informations pour les analystes chargés de déterminer la cause, la nature et l’impact d’un incident de cybersécurité. Or, ces fichiers sont souvent insuffisants, si ce n’est inexistants.

Le plus surprenant est que les administrateurs système ne réalisent le manque cruel de logs qu’après un incident. Résultat : l’analyse des causes premières nécessite dans bien des cas une analyse forensique a posteriori à défaut d’une action immédiate. De plus, il faut souvent énormément de temps aux analystes forensiques pour déterminer l’ampleur d’une attaque. Il est même parfois impossible d’effectuer une analyse complète parce que les bonnes informations n’ont pas été collectées, et encore moins conservées, pendant une durée suffisante, et ont été écrasées.

Comment en sommes-nous arrivés là ? Pourquoi tant d’entreprises disposent d’une stratégie de journalisation défaillante et comment elles peuvent y remédier avant qu’un incident cyber ne se produise ?

Les paramètres par défaut mènent à l’échec

Très peu d’entreprises mettent en œuvre une véritable stratégie de journalisation. Elles se contentent bien souvent des configurations par défaut qui génèrent un journal de base et écrasent les données afin d’économiser de l’espace. L’objectif est de ne conserver ensuite que les informations les plus utiles. Ces pratiques générales ne répondent pourtant pas toujours aux besoins spécifiques des entreprises en matière de cybersécurité.

Comme certains produits génèrent leurs logs dans leur propre emplacement, souvent inconnu de l’administrateur, l’absence de centralisation complique encore plus l’identification des cyberattaques. Lorsqu’un incident survient, le département informatique est rarement préparé à répondre aux demandes de l’équipe d’intervention. Incapables de savoir à quelle machine ou à quel utilisateur correspond l’adresse IP touchée, les entreprises peinent à déterminer comment l’incident s’est produit et l’ampleur de son impact sur le réseau.

Même si l’administrateur a recours à un service de journalisation centralisé, cela ne suffit pas. Les logs doivent non seulement tous être collectés, mais ils doivent aussi s’accompagner d’informations détaillées et pouvoir faire l’objet d’audits. Deux paramètres souvent ignorés. Plutôt que des données réelles, les entreprises stockent des événements génériques de lancement et d’arrêt indiquant qu’un logiciel a été ouvert, puis fermé, sans plus de détails. Aucun événement de compromission détaillé, comme « l’utilisateur malveillant X a lancé le programme Y » ou « l’utilisateur malveillant X a copié des fichiers sur le partage Z », n’est collecté.

Comme si l’absence de logs et le défaut d’informations n’étaient pas suffisamment handicapants, la compromission de comptes à privilèges aggrave encore la situation. Sans une stratégie de journalisation appropriée, les comptes en question ne manqueront pas de supprimer ou de manipuler les journaux disponibles. Un cybercriminel pourra ainsi effacer les informations les plus utiles d’un log pour compliquer les investigations, voire les rendre impossibles.

Stratégie de journalisation efficace : élément clé de la réponse à incidents

Cette stratégie peut varier en fonction de l’entreprise et de la sensibilité de son système d’information. De plus, les logs eux-mêmes doivent être protégés. Le problème est que les entreprises ont besoin de collecter les données de tous les systèmes (Cloud, sur site, hybrides et applications), puis d’être en mesure de les agréger et de les consulter depuis un même emplacement. Ces données doivent également être sécurisées. Il ne faut pas oublier que les pires fuites de données de ces dix dernières années concernaient des logs non sécurisés.

Une fois en possession des journaux, les entreprises doivent les auditer et définir les événements à consigner pour tenter d’identifier une activité à l’aide des logs. Les équipes s’apercevront ainsi que l’exécution de requêtes sur l’ensemble des logs depuis une même interface accroît l’efficacité et réduit les délais d’intervention de plusieurs jours.

Il est en outre important de mettre en place une surveillance particulière des comptes à privilèges pour veiller à la journalisation des événements à privilèges. L’objectif est de disposer d’un nombre suffisant d’événements pour retracer une session complète et déterminer aisément les actions effectuées par un administrateur ou un compte à privilèges. Des centaines d’événements critiques sont souvent ignorés ou supprimés. Grâce à des solutions dédiées qui conservent les logs de différents systèmes pendant plus d’un an, au lieu de 90 jours, les équipes informatiques ont l’assurance de disposer des ressources nécessaires pour analyser correctement un incident.

Les stratégies de journalisation rigoureuses ne sont pas un concept nouveau. Cependant, en négligeant les logs, les entreprises courent droit à l’échec en cas de cyberattaque. La mise en œuvre d’une stratégie de journalisation solide leur permet non seulement de réagir de manière rapide et efficace en période de crise, mais accélère aussi la résolution et l’analyse des causes premières.

A propos de l'auteur

Hicham Bouali
Directeur Avant-Ventes EMEA de One Identity

Filtered HTML

Plain text

CAPTCHA
Cette question permet de vérifier que vous n'êtes pas un robot spammeur :-)
 L     X   X  W     W  K  K  III 
L X X W W K K I
L X W W W KK I
L X X W W W K K I
LLLL X X W W K K III