Comment traiter les journaux ?
La façon de traiter les journaux varie beaucoup selon la complexité du SI et les
appétences techniques des équipes qui les gèrent. Certaines adoptent une approche très
empirique alors que d’autres tendent vers des solutions de niveau industriel. Nous allons
passer en revue quatre de ces approches.
La méthode artisanale
La première approche pour traiter les journaux peut être appelée la « méthode
artisanale ». La tentation est grande de développer soi-même des scripts pour traiter les
journaux afin de repérer les événements ciblés évoqués précédemment. Les scripts shell,
awk ou autres programmes perl ont une flexibilité infinie. Les équipes de sécurité ayant
une appétence technique développeront sans difficulté de tels scripts. Cette approche
présente deux avantages.
Maîtrise en profondeur : l’approche artisanale est en principe la meilleure, puisque
l’équipe de sécurité maîtrise de bout en bout le processus d’analyse des journaux et de
détection des incidents. En effet, elle sait très précisément ce qu’elle veut détecter et
comment le faire.
Coût : comme les développements sont souvent réalisés en interne et presque
exclusivement à base d’outils open source, le coût strictement financier de cette
solution est imbattable, surtout si on ne tient pas compte du temps passé (et donc du
salaire versé) à développer les outils. Il n’est donc pas nécessaire d’avoir un budget
pour analyser les scripts, pour peu qu’on ait du temps à y consacrer.
Malheureusement, cet avantage est tempéré par les trois inconvénients suivants.
Temps : l’inconvénient majeur de cette approche est que les temps de développement
et d’affinement des scripts explosent très rapidement, occupant les équipes à
développer et tester, au détriment d’autres tâches tout aussi importantes, si ce n’est
plus.
Évolutivité difficile : comme les scripts sont développés sur mesure, il est nécessaire
de les retester dès qu’une modification survient dans la structure des journaux. De
plus, l’intégration de nouveaux journaux oblige à développer de nouveaux scripts.
Cette situation n’est pas tenable à long terme.
Horaires : enfin, une fois les scripts en production, les équipes de sécurité ont
tendance à ne pas surveiller systématiquement les journaux. D’ailleurs, les horaires de
surveillance se limitent souvent aux heures ouvrables. Qu’en est-il des incidents
repérés en dehors de ces plages horaires ?
Nous pouvons conclure que cette démarche artisanale est appropriée lorsque les journaux
à analyser sont peu nombreux. En revanche, lorsque ceux-ci se multiplient, une autre
approche s’avère nécessaire.
Les SIEM
La façon de traiter les journaux varie beaucoup selon la complexité du SI et les
appétences techniques des équipes qui les gèrent. Certaines adoptent une approche très
empirique alors que d’autres tendent vers des solutions de niveau industriel. Nous allons
passer en revue quatre de ces approches.
La méthode artisanale
La première approche pour traiter les journaux peut être appelée la « méthode
artisanale ». La tentation est grande de développer soi-même des scripts pour traiter les
journaux afin de repérer les événements ciblés évoqués précédemment. Les scripts shell,
awk ou autres programmes perl ont une flexibilité infinie. Les équipes de sécurité ayant
une appétence technique développeront sans difficulté de tels scripts. Cette approche
présente deux avantages.
Maîtrise en profondeur : l’approche artisanale est en principe la meilleure, puisque
l’équipe de sécurité maîtrise de bout en bout le processus d’analyse des journaux et de
détection des incidents. En effet, elle sait très précisément ce qu’elle veut détecter et
comment le faire.
Coût : comme les développements sont souvent réalisés en interne et presque
exclusivement à base d’outils open source, le coût strictement financier de cette
solution est imbattable, surtout si on ne tient pas compte du temps passé (et donc du
salaire versé) à développer les outils. Il n’est donc pas nécessaire d’avoir un budget
pour analyser les scripts, pour peu qu’on ait du temps à y consacrer.
Malheureusement, cet avantage est tempéré par les trois inconvénients suivants.
Temps : l’inconvénient majeur de cette approche est que les temps de développement
et d’affinement des scripts explosent très rapidement, occupant les équipes à
développer et tester, au détriment d’autres tâches tout aussi importantes, si ce n’est
plus.
Évolutivité difficile : comme les scripts sont développés sur mesure, il est nécessaire
de les retester dès qu’une modification survient dans la structure des journaux. De
plus, l’intégration de nouveaux journaux oblige à développer de nouveaux scripts.
Cette situation n’est pas tenable à long terme.
Horaires : enfin, une fois les scripts en production, les équipes de sécurité ont
tendance à ne pas surveiller systématiquement les journaux. D’ailleurs, les horaires de
surveillance se limitent souvent aux heures ouvrables. Qu’en est-il des incidents
repérés en dehors de ces plages horaires ?
Nous pouvons conclure que cette démarche artisanale est appropriée lorsque les journaux
à analyser sont peu nombreux. En revanche, lorsque ceux-ci se multiplient, une autre
approche s’avère nécessaire.
Les SIEM