Vous n'avez pas besoin d'un SIEM pour enquêter sur un incident. Il vous faut les bons journaux activés, conservés au moins six mois, protégés contre toute altération et consultables sans avoir à ouvrir une session sur chaque machine.
Les six catégories ci-dessous constituent notre propre regroupement et non un standard. Elles réorganisent les trois tableaux de l'introduction à la journalisation à des fins de sécurité du NCSC, y ajoutent la journalisation applicative issue des recommandations de l'OWASP, ainsi que des précisions sur Microsoft 365 tirées de la documentation de Microsoft.
Partir des questions
Choisissez vos sources de journaux en fonction des questions qui vous seront posées dans les premières heures d'un incident. Le NCSC les formule de façon large : que s'est-il passé, quel est l'impact, que devons-nous faire ensuite, la remédiation a-t-elle fonctionné, et nos mesures de sécurité fonctionnent-elles. Ses tableaux les déclinent en questions concrètes, par exemple qui s'est connecté à distance en dehors des heures de bureau, ou si quelqu'un a cliqué sur un lien donné. Si vous ne savez pas dire à quelle question répond un journal, il passe après les autres.
Le jeu minimal
| Source | Question à laquelle elle répond | Origine |
|---|---|---|
| Identité et accès à distance | Qui s'est connecté, depuis où, à quelle heure ? Y a-t-il eu des tentatives échouées sur les services exposés à Internet ? | Journaux Active Directory, LDAP, ADFS, VPN, bureau à distance et VDI |
| Messagerie | Qui a reçu un message comme celui-ci, et qui a cliqué sur le lien ? | Serveurs SMTP, MS Exchange, appliances d'analyse du courrier, API des fournisseurs cloud |
| Postes et serveurs | Ce binaire a-t-il été exécuté, ce fichier existe-t-il, s'est-il passé quelque chose d'anormal sur un hôte ? | Windows EVTX, Syslog, Microsoft Sysmon, agents sur les hôtes |
| Pare-feu, DNS et proxy | Un système communique-t-il avec une IP ou un domaine suspect ? | Journaux de pare-feu ou netflow, journaux DNS, journaux du proxy web |
| Serveur web et application | Qu'a fait l'utilisateur et quel en a été le résultat ? | Code applicatif, serveur web |
| Actifs et changements | Quel équipement avait cette IP, qu'est-ce qui a changé, à qui appartient ce serveur ? | Journaux DHCP, routeurs, pare-feu et commutateurs, une CMDB |
Certains détails modifient ce que vous collectez. Sur le pare-feu, le NCSC indique que les journaux capturés doivent tenir compte de la traduction d'adresses réseau (NAT), afin d'enregistrer à la fois l'IP interne et l'IP externe. Les journaux DNS montrent le domaine sur lequel un utilisateur a cliqué, mais pas l'URL complète : considérez-les comme un substitut plus faible lorsque vous n'avez pas de proxy web.
Les agents sur les hôtes, y compris Microsoft Sysmon qui est gratuit, peuvent produire des informations sur les processus, des événements de résolution DNS, des modifications du système de fichiers et des empreintes de fichiers. Ils ne couvrent que les machines sur lesquelles quelqu'un les a installés et configurés : le shadow IT, les équipements réseau, les systèmes d'exploitation non pris en charge et les hôtes où un malware a désactivé l'agent restent donc dans l'ombre.
Les journaux du serveur web ne remplacent pas la journalisation applicative. L'application connaît l'identité de l'utilisateur, ses rôles et le résultat d'une action, ce que les équipements d'infrastructure ignorent souvent.
Microsoft 365
Si vous utilisez Microsoft 365, consultez Microsoft Purview avant d'acheter quoi que ce soit. Audit (Standard) est activé par défaut pour les organisations disposant de l'abonnement approprié. Il vous reste à attribuer les permissions de recherche, dans le portail Purview ou avec la cmdlet Search-UnifiedAuditLog dans Exchange Online PowerShell.
L'édition Standard conserve les enregistrements pendant 180 jours. Ceux générés avant le 17 octobre 2023 n'étaient conservés que 90 jours. Audit (Premium) conserve par défaut pendant un an les enregistrements de Microsoft Entra ID, Exchange, OneDrive et SharePoint.
Premium fournit aussi la propriété SensitivityLabel sur l'activité MailItemsAccessed dans Exchange Online. Les utilisateurs ont besoin d'une licence Premium pour que le système génère ces événements : réglez donc la question des licences avant un incident.
Conservation et protection
Le NCSC recommande un minimum de 6 mois pour les journaux qui répondent à vos questions d'incident. Il ajoute que M-Trends 2018 situait le délai moyen de détection à 101 jours, et qu'il faut donc conserver plus longtemps si le budget le permet.
Les journaux locaux peuvent rester en deçà de cet objectif sans que personne ne s'en aperçoive. Ouvrez chacun d'eux et relevez la date de l'entrée la plus ancienne. Si elle date de moins de six mois, le journal est peut-être trop petit ou trop sollicité pour atteindre votre objectif : vérifiez aussi la taille configurée ou le paramètre de rétention.
Quiconque s'introduit dans un système a intérêt à altérer les journaux. Apportez donc au service de journalisation les mêmes soins qu'à n'importe quelle interface d'administration. Demandez-vous qui peut lire les journaux, qui peut y écrire, et si vous verriez une modification. L'OWASP donne des mesures concrètes pour les journaux applicatifs :
- Placer les journaux sous forme de fichiers sur une partition distincte de celle du système d'exploitation et du contenu généré par les utilisateurs, avec des permissions strictes sur les répertoires et les fichiers.
- Garder les journaux hors des emplacements accessibles depuis le web. Si c'est inévitable, restreindre l'accès et les servir en texte brut plutôt qu'en HTML.
- Lors d'une journalisation en base de données, utiliser un compte dédié uniquement à l'écriture des journaux, avec des permissions très restrictives.
- Utiliser un format d'événement standard sur un transport sécurisé, par exemple le format de message syslog sur TLS.
Centraliser seulement quand c'est rentable
Le NCSC considère la journalisation centralisée et décentralisée comme un véritable choix. Un stockage central vous évite de passer sur chaque machine pendant une investigation, et il devient plus utile à chaque source ajoutée. Laisser les journaux sur place fonctionne lorsqu'ils sont déjà consultables et conservés assez longtemps. Les services de messagerie cloud sont l'exemple du NCSC : l'extraction y justifie rarement son coût.
Pour une petite équipe, un partage raisonnable consiste à centraliser les journaux des postes, des serveurs, des pare-feu et du VPN, et à laisser en place les services cloud bien dotés. Sous Windows, Windows Event Forwarding envoie de façon sécurisée les journaux des clients vers un stockage central.
Le NCSC avertit aussi qu'un modèle décentralisé peut se dégrader peu à peu. Confiez à quelqu'un la tâche récurrente de vérifier que chaque source produit toujours des journaux, et notez qui en est responsable.
Par où commencer
- Reprenez les questions concrètes des tableaux du NCSC, par exemple qui s'est connecté à distance en dehors des heures de bureau, ou si quelqu'un a cliqué sur ce lien. Pour chacune, nommez le système qui y répondrait.
- Pour chaque source, consignez où elle est stockée, combien de temps elle est conservée et qui peut la lire ou la modifier. Signalez tout ce qui est en dessous de six mois.
- Vérifiez les paramètres par défaut. Si une source journalise peu de détails, modifiez la configuration pour en capturer davantage. Dans Microsoft 365, confirmez qu'Audit est activé et attribuez les permissions de recherche.
- Transférez les journaux des postes, des serveurs, des pare-feu et du VPN vers un stockage unique à accès en écriture restreint, avec Windows Event Forwarding ou syslog sur TLS.
- Faites un exercice : choisissez une adresse IP suspecte et un objet d'e-mail de phishing, puis essayez de répondre aux questions à partir des seuls journaux. Corrigez d'abord la source sur laquelle vous avez buté.
- Si vous ne pouvez pas mener cet exercice en interne, demandez de l'aide à une équipe de réponse à incident ou à un prestataire de sécurité managée.
