À l’épisode précédent, tu as posé Rspamd devant ta boîte mail. Chaque message entrant est noté, l’hameçonnage lève une alerte, et le verdict remonte dans Wazuh. Trois briques debout, le serveur, le réseau, le mail. Ton SIEM voit, il bloque, il filtre.

Et il reste une porte. La dernière, celle qu’aucune des trois premières ne garde.

Un salarié télécharge un fichier. Une fausse mise à jour d’un logiciel qu’il connaît, un utilitaire trouvé sur un forum, une pièce jointe qui a franchi le filtre mail parce qu’elle était propre le jour où elle est passée. Il double-clique. Le binaire démarre. À cette seconde précise, ni CrowdSec ni Rspamd n’ont voix au chapitre, l’exécution se joue sur le Mac, en local, loin de tes serveurs.

C’est l’angle mort qui reste. Ton dispositif surveille tout ce qui entre, et laisse s’exécuter n’importe quoi une fois entré.

Aujourd’hui, on ferme cette porte. On installe Santa, un système de contrôle d’exécution pour macOS. Son principe est brutalement simple, tu établis la liste des applications qui ont le droit de tourner, et tout le reste est refusé. Puis on branche ses décisions sur Wazuh, pour que chaque binaire bloqué s’affiche dans ton tableau de bord, à côté de tes rejets mail et de tes blocages réseau.

Avant de commencer

Trois choses en tête avant la première commande.

Ce qu’il te faut. Un ou plusieurs Mac sous une version récente de macOS, un accès administrateur dessus, et l’agent Wazuh de l’épisode 3 déjà installé sur ces Mac, pour la partie intégration en fin de tuto. Santa est open source, maintenu par North Pole Security, la société fondée par ses créateurs d’origine, ceux qui l’ont écrit chez Google en 2014. Licence Apache 2.0, zéro version payante pour ce qu’on fait ici.

Ce que ça change. À la fin, un binaire inconnu ne s’exécute plus sur tes Mac. Pas « s’exécute et lève une alerte », ne s’exécute pas. Tu passes d’un poste qui lance tout ce qu’on lui présente à un poste qui ne lance que ce que tu as approuvé, et chaque tentative bloquée remonte dans ton SIEM.

Ce que ça ne change pas. Santa contrôle l’exécution de binaires. Il ne lit pas le contenu d’un script Python ou d’un shell, on y reviendra, c’est sa limite la plus importante et je ne vais pas te la cacher. Il ne remplace pas ton antivirus, il ne répare pas un compte dont le mot de passe a fuité. Et il ne se règle pas tout seul, la vraie dépense n’est pas la RAM, c’est la liste que tu vas devoir tenir à jour.

Santa n’interdit rien, il n’autorise que

Le renversement mental qui fait tout, et qui sépare Santa d’un antivirus.

Un antivirus travaille sur une liste noire. Il connaît des milliers de menaces, il les cherche, il les bloque, et il laisse passer tout ce qu’il ne reconnaît pas comme mauvais. Le problème est structurel, une menace qu’il ne connaît pas encore est une menace qu’il autorise. Il court après le mal, il a toujours un train de retard.

Santa fait l’inverse. Il travaille sur une liste blanche, une allowlist. Il ne se demande pas si un binaire est mauvais, il se demande s’il est autorisé. Ce qui n’est pas sur la liste ne tourne pas, qu’il soit malveillant, inconnu, ou parfaitement légitime mais oublié. Tu ne cours plus après les menaces, tu définis une fois ce qui a le droit d’exister sur tes machines.

Ce basculement se règle avec un seul paramètre, le mode client, et il a trois positions.

Monitor. Tout s’exécute, mais tout est journalisé. Santa regarde, note, et ne bloque rien. C’est le mode d’observation, celui par lequel on commence toujours.

Lockdown. Le verrou. Ce qui n’est pas explicitement autorisé est refusé. C’est la position cible, celle qui ferme la porte.

Standalone. Entre les deux. Un binaire inconnu déclenche une fenêtre qui demande à l’utilisateur d’autoriser lui-même, Touch ID à l’appui. Utile sur un poste isolé, mais il délègue la décision au salarié, exactement ce qu’une allowlist d’entreprise cherche à ne pas faire.

La progression est mécanique. On démarre en Monitor pour cartographier ce qui tourne réellement sur le parc, on construit l’allowlist à partir de ces observations, et on bascule en Lockdown une fois qu’on est sûr de ne bloquer personne d’utile. On ne verrouille jamais à l’aveugle.

Reste à savoir comment Santa reconnaît une application. Il dispose de cinq façons de l’identifier, de la plus précise à la plus large.

• Le CDHash, l’empreinte d’une version exacte d’un binaire. Change à la moindre mise à jour.
• Le hash SHA-256 du binaire lui-même. Aussi fragile, il casse à chaque update.
• Le SigningID, l’identifiant de signature d’une application précise d’un éditeur donné.
• Le certificat de signature, plus large, il couvre tout ce qu’un certificat signe.
• Le TeamID, l’identifiant de l’équipe Apple Developer. Le plus large côté éditeur, il autorise toutes les applications signées par ce développeur.

Santa les évalue dans cet ordre, du plus spécifique au plus général, et la première règle qui correspond l’emporte. Pour une PME, le bon niveau se situe presque toujours sur les deux derniers. Le TeamID dit « je fais confiance à cet éditeur », une règle unique qui survit à toutes ses mises à jour. Le SigningID affine quand tu veux autoriser une application précise d’un éditeur sans lui signer un chèque en blanc. Les hash, eux, tu les laisses aux cas particuliers, sinon tu passes ton temps à réécrire des règles que la prochaine mise à jour cassera.

Étape 1, installer Santa et démarrer en Monitor

Sur chaque Mac, tu récupères le paquet d’installation signé depuis les publications officielles de North Pole Security, et tu l’installes.

sudo installer -pkg santa-*.pkg -target /

Santa tourne comme une extension système, du type Endpoint Security, la même famille d’API que les outils de sécurité sérieux sur macOS. Concrètement, deux autorisations vont t’être réclamées à la première installation. macOS te demande d’approuver l’extension système, dans Réglages, Confidentialité et sécurité. Et il faut accorder à Santa l’accès disque complet, le Full Disk Access, pour qu’il voie tout ce qui s’exécute.

Tu reconnais ce Full Disk Access, c’est celui de l’agent Wazuh à l’épisode 3, la même contrainte TCC propre à macOS. Sur un parc géré en MDM, ces deux approbations se poussent par profil de configuration, une fois pour toutes, sur toutes les machines. Sans MDM, ça se coche à la main, poste par poste. C’est le premier endroit où l’absence de MDM se paie en manipulations manuelles, autant le savoir tout de suite.

Une fois installé, Santa démarre en Monitor par défaut. C’est exactement ce qu’on veut. Vérifie son état.

santactl status

Tu dois lire un mode Monitor et une extension active. À partir de maintenant, chaque exécution sur ce Mac est notée dans son journal, sans que rien ne soit bloqué. Laisse-le tourner. Une journée de travail normal, une semaine si tu peux, le temps que tes salariés lancent tout ce qu’ils lancent d’habitude. Tu n’installes pas un mur aujourd’hui, tu prends des photos de qui passe la porte.

Étape 2, cartographier ton parc et écrire ton allowlist

Santa écrit ses décisions dans /var/db/santa/santa.log, une ligne par exécution. Va les lire, c’est ta matière première.

tail -f /var/db/santa/santa.log

Chaque ligne te donne l’action, la décision, la raison, le chemin du binaire, son éditeur. En Monitor, tout est en decision=ALLOW, mais la raison t’apprend pourquoi Santa aurait laissé passer, ou aurait bloqué en Lockdown. Un reason=UNKNOWN, c’est un binaire que rien n’autorise, exactement ce qui tomberait le jour de la bascule.

Pour transformer une observation en règle, il te faut l’identité de l’application. Santa te la donne.

santactl fileinfo /Applications/UneApp.app

Il t’affiche la signature, le TeamID, le SigningID, les empreintes, et la règle qui s’appliquerait aujourd’hui. C’est là que tu décides du bon niveau. Un éditeur en qui tu as confiance sur tout son catalogue, tu l’autorises par son TeamID.

sudo santactl rule --allow --teamid --identifier <TEAMID> --comment "editeur maison"

Une application précise, tu la prends par son SigningID.

sudo santactl rule --allow --signingid --identifier <SIGNINGID>

Tu répètes pour chaque éditeur et chaque application légitimes que Monitor a vus passer. Ta liste se construit à partir du réel, pas d’un catalogue théorique. C’est le travail de fond de cet épisode, et il n’y a pas de raccourci, une bonne allowlist est celle qui colle à ton usage.

Pour un ou deux Mac, ces règles vivent en local sur chaque machine et ça suffit. Pour un parc, tu ne vas pas taper les mêmes commandes sur dix postes. Santa sait se synchroniser depuis un serveur central qui distribue les mêmes règles à toute la flotte. L’option souveraine, c’est Moroz, un petit serveur qui sert tes règles depuis de simples fichiers, que tu héberges toi-même. Tu le poses sur ton infrastructure et tu le gardes en Tailnet-only, la même doctrine que ton manager Wazuh depuis l’épisode 1, rien d’inutile sur l’internet ouvert. North Pole Security propose aussi son propre service de synchronisation clé en main, plus riche mais hébergé chez un tiers, à toi de trancher entre le confort et le tout-souverain.

Étape 3, verrouiller en Lockdown

Ton allowlist est prête, Monitor n’a plus rien de nouveau à t’apprendre. On ferme.

Et c’est ici que se cache le piège qui fait perdre une demi-heure à tout le monde. Tu ne peux pas basculer le mode avec defaults write. Tu peux l’écrire, defaults te dira que c’est fait, defaults read te le confirmera, et santad continuera tranquillement à tourner en Monitor. Reboot compris.

Ce n’est pas un bug. C’est une décision de sécurité. Santa ne lit son mode que depuis les préférences gérées, celles qu’un profil de configuration dépose, pas depuis les préférences ordinaires qu’un utilisateur pourrait modifier. La raison est limpide, si un simple defaults write suffisait à sortir du Lockdown, le premier logiciel malveillant venu s’en servirait pour se libérer. Le verrou ne s’ouvre qu’avec une clé que l’utilisateur courant n’a pas.

La clé, c’est un profil de configuration, un fichier .mobileconfig. Sur un parc géré, ton MDM le pousse sur toutes les machines. Sans MDM, tu écris le profil et tu l’installes à la main, via Réglages, Profils, Installer, mot de passe administrateur ou Touch ID à l’appui. Le profil contient le mode et la configuration de journalisation.

<key>PayloadType</key>
<string>com.northpolesec.santa</string>
<key>ClientMode</key>
<integer>2</integer>
<key>EventLogType</key>
<string>file</string>
<key>EventLogPath</key>
<string>/var/db/santa/santa.log</string>

Le ClientMode à 2, c’est le Lockdown. L’EventLogType à file et l’EventLogPath, c’est ce qui garantit que Santa continue d’écrire son journal à l’endroit que Wazuh ira lire à l’étape suivante. Une fois le profil installé, santad le prend en compte immédiatement.

santactl status

Le mode affiche désormais Lockdown. La porte est fermée. Teste-le sans attendre, télécharge un petit utilitaire quelconque, un binaire que tu n’as pas allowlisté, et lance-le.

./un-binaire-quelconque

macOS te répond que l’exécution a été bloquée par Santa. C’est le comportement attendu, et c’est la première fois que quelque chose s’oppose vraiment à un double-clic sur ton parc. Cette exécution refusée vient aussi d’atterrir dans /var/db/santa/santa.log, en decision=DENY. Il ne reste plus qu’à la faire remonter.

Étape 4, faire remonter Santa dans Wazuh

Santa bloque, sur chaque Mac, dans son coin. Ton SIEM ne le sait pas encore. On les branche, et la boucle de la série se referme sur le poste de travail.

Rien à activer côté Santa, il écrit déjà son journal. Le branchement se fait sur deux machines, et c’est le même partage des rôles qu’à l’épisode 5. L’agent Wazuh, sur chaque Mac, lit le fichier et expédie les lignes brutes. Le manager, sur ton VPS de l’épisode 2, décode et décide quoi en faire. Une machine ramasse, l’autre comprend.

Côté Mac, tu dis à l’agent de lire le journal de Santa. Et plutôt que d’éditer chaque poste un par un, tu réutilises les groupes de l’épisode 3. Le bloc va dans la configuration partagée du groupe macos, sur le manager, dans /var/ossec/etc/shared/macos/agent.conf, et le manager le pousse à tous tes Mac d’un coup.

<localfile>
  <location>/var/db/santa/santa.log</location>
  <log_format>syslog</log_format>
</localfile>

Tu reconnais le <localfile> de l’épisode 3, le mécanisme par lequel Wazuh avale n’importe quelle source de journaux. L’agent tourne en root, il lit /var/db/santa/ sans difficulté.

Côté manager, maintenant, et sur lui seul. Un décodeur extrait les champs utiles de la ligne, dans /var/ossec/etc/decoders/local_decoder.xml.

<decoder name="santa">
  <prematch>santad: action=EXEC</prematch>
</decoder>

<decoder name="santa-decision">
  <parent>santa</parent>
  <regex type="pcre2">decision=(\w+)\|reason=(\w+).*?\|path=(.+)$</regex>
  <order>santa_decision, santa_reason, santa_path</order>
</decoder>

Puis des règles qui transforment ces champs en alertes, dans /var/ossec/etc/rules/local_rules.xml, toujours sur le manager.

<group name="santa,">
  <rule id="100500" level="0">
    <decoded_as>santa</decoded_as>
    <description>Santa, décision d'exécution.</description>
  </rule>

  <rule id="100501" level="10">
    <if_sid>100500</if_sid>
    <field name="santa_decision" type="pcre2">^DENY$</field>
    <description>Santa, exécution bloquée, binaire $(santa_path).</description>
  </rule>

  <rule id="100502" level="3">
    <if_sid>100500</if_sid>
    <field name="santa_decision" type="pcre2">^ALLOW$</field>
    <description>Santa, exécution autorisée, binaire $(santa_path).</description>
  </rule>
</group>

La règle mère est en niveau 0, elle décode sans alerter. Le blocage passe en niveau 10, c’est lui qui t’intéresse, un binaire refusé sur un poste est un signal que tu veux voir. L’autorisation reste en niveau 3, une trace discrète, sans quoi ton tableau de bord se noierait sous les milliers d’exécutions légitimes de la journée, surtout tant que tu es en Monitor où tout est ALLOW. L’ancrage ^DENY$ et non DENY, même précaution qu’à l’épisode 5, pour ne coller qu’à la décision exacte.

Ne crois pas ce décodeur sur parole, teste-le. L’outil vit sur le manager, pas sur l’agent.

sudo /var/ossec/bin/wazuh-logtest

Tu colles une vraie ligne DENY de ton santa.log, et il te montre ce qu’il en a compris, phase par phase, décodeur reconnu, champs extraits, règle déclenchée. Si santa_decision et santa_path ne sortent pas, c’est le motif d’extraction qu’il faut ajuster, et tu le sauras en trente secondes. Un mot d’honnêteté sur ce point, les lignes de Santa commencent par un horodatage entre crochets qui n’a pas la forme d’un log syslog classique. Le pré-décodage et le motif peuvent demander un ajustement selon ta version de Wazuh et le format exact de tes lignes. C’est précisément ce que wazuh-logtest te confirme chez toi, avant que tu comptes sur l’alerte.

Une fois le test concluant, redémarre le manager pour qu’il charge ton décodeur et tes règles.

sudo systemctl restart wazuh-manager

Un salarié lance un binaire inconnu, Santa le refuse, l’écrit dans son journal, l’agent Wazuh le lit et l’expédie par le Tailnet, le manager le décode et lève une alerte de niveau 10, elle s’affiche dans ton tableau de bord à côté de tes blocages CrowdSec et de tes rejets Rspamd. La dernière porte est fermée, et tu la vois se fermer.

Si ça ne marche pas

Problème, Santa est installé mais ne journalise rien

Cause probable, l’extension système n’a pas été approuvée, ou le Full Disk Access manque. Sans eux, santad ne voit pas les exécutions.

Solution, dans Réglages, Confidentialité et sécurité, vérifie que l’extension Santa est autorisée et que l’accès disque complet lui est accordé. santactl status doit reporter l’extension active.

Problème, le mode reste sur Monitor malgré tout

Cause probable, presque à coup sûr, tu as tenté la bascule avec defaults write. Santa l’ignore, par conception.

Solution, passe par un profil de configuration .mobileconfig, poussé par MDM ou installé à la main dans Réglages, Profils. C’est le seul canal que Santa écoute pour son mode.

Problème, tu as ajouté des règles mais santactl status affiche Static Rules: 0

Cause probable, tu lis le mauvais compteur. santactl status sépare les règles par type, et Static Rules ne compte que celles d’un fichier de configuration statique, pas celles que tu ajoutes en ligne de commande.

Solution, une règle posée par TeamID compte dans TeamID Rules, une règle SigningID dans SigningID Rules. Regarde la ligne du type que tu as réellement posé, tes règles y sont.

Problème, rien ne remonte dans Wazuh

Cause probable, trois suspects, à départager avant de toucher à quoi que ce soit. Soit le fichier ne grossit pas côté Mac, soit l’agent ne le lit pas, soit le manager ne sait pas le décoder. Le grand classique, décodeur et règles édités sur le Mac au lieu du manager, où ils ne servent à rien.

Solution, le fichier grossit-il ? S’il grossit, va sur le manager, passe une ligne dans wazuh-logtest et regarde à quelle phase ça casse. Vérifie que local_decoder.xml et local_rules.xml sont bien sur cette machine-là, et que tu as redémarré wazuh-manager après les avoir écrits.

Ce que ça t’a coûté

La licence, rien. Santa est open source sous Apache 2.0, sans version payante, sans palier entreprise, sans quota de postes.

La machine, rien non plus. Santa tourne sur le Mac que tu as déjà. Le serveur de synchronisation, si tu en montes un, c’est un service léger de plus sur ton infrastructure existante.

Ton temps, un peu pour l’installation, beaucoup plus pour la calibration. Et c’est le seul vrai poste de dépense, celui qu’aucun SaaS ne t’épargnera.

Sois lucide sur ce que Santa ne fait pas, parce que ces angles morts sont réels et actionnables.

Il ne voit pas les scripts. Santa contrôle les binaires exécutés. Un script Python, un shell script, une macro, sont interprétés par un binaire, python3, bash, osascript, que tu as probablement autorisé. Le script passe alors sous le radar, c’est l’interpréteur qui est jugé, pas le code qu’il exécute. C’est la limite technique majeure, et elle ouvre tout un chantier connexe, le durcissement des interpréteurs eux-mêmes.

L’allowlist est vivante. Chaque nouvel outil légitime, chaque nouvel éditeur, c’est une règle à ajouter. Le TeamID limite la casse, une règle par éditeur qui survit à ses mises à jour, mais tu ne poses pas cette liste une fois pour la laisser dix ans.

Le jour de la bascule fait mal. Tout ce que tu as oublié d’allowlister est bloqué net, en pleine journée de travail. Le premier DENY d’un parc, c’est souvent un vieil agent de sauvegarde dormant ou un outil que personne ne savait plus installé. D’où le temps passé en Monitor, et une procédure de whitelist rapide sous la main pour les premiers jours.

Sans MDM, c’est plus manuel. Approbation de l’extension, accès disque complet, profil de mode, tout se fait poste par poste. Tenable à trois Mac, pénible à trente.

Aucune de ces limites n’est une raison de renoncer. C’est le prix d’un contrôle qui reste entièrement chez toi, aucune application soumise au cloud d’un tiers pour savoir si elle a le droit de tourner, aucun catalogue de confiance loué à un éditeur américain. Tu décides, la décision s’applique en local, et elle remonte dans ton SIEM.

Pour les pressés

Ce que fait cet article. On installe Santa sur les Mac, on démarre en mode Monitor pour cartographier ce qui s’exécute, on écrit une allowlist par TeamID et SigningID, on bascule en Lockdown via un profil de configuration, puis on fait remonter chaque décision dans Wazuh via un décodeur et des règles maison. Le poste de travail cesse d’être l’angle mort du SIEM.

Concrètement, les commandes.

1. Installer Santa sur chaque Mac : sudo installer -pkg santa-*.pkg -target /, puis approuver l’extension système et accorder le Full Disk Access.
2. Vérifier le mode par défaut : santactl status, tu dois lire Monitor.
3. Observer : tail -f /var/db/santa/santa.log, laisser tourner plusieurs jours.
4. Identifier une app : santactl fileinfo /Applications/UneApp.app.
5. Autoriser par éditeur : sudo santactl rule --allow --teamid --identifier <TEAMID>, ou par app : --signingid --identifier <SIGNINGID>.
6. Pour un parc, centraliser les règles avec un serveur de synchronisation auto-hébergé (Moroz), gardé en Tailnet-only.
7. Verrouiller : profil .mobileconfig avec ClientMode à 2, EventLogType à file, EventLogPath sur /var/db/santa/santa.log, poussé par MDM ou installé dans Réglages, Profils. defaults write est ignoré.
8. Intégrer à Wazuh, sur deux machines : <localfile> sur /var/db/santa/santa.log côté agent (via la config partagée du groupe macos), décodeur et règles côté manager (blocage en niveau 10), validation avec /var/ossec/bin/wazuh-logtest sur le manager, puis redémarrage de wazuh-manager.

En résumé

Tu es parti d’un dispositif qui voyait tes serveurs, bloquait ton réseau et filtrait ton mail, mais laissait s’exécuter n’importe quel binaire une fois qu’il avait atterri sur un Mac.

Tu as installé Santa sur tes postes, et compris qu’il ne travaille pas sur une liste de menaces mais sur une liste d’autorisés, tout ce qui n’est pas invité reste dehors. Tu as cartographié en Monitor ce qui tourne réellement, puis écrit ton allowlist par TeamID et SigningID, le bon niveau entre finesse et maintenabilité.

Tu as verrouillé en Lockdown par profil de configuration, seul canal que Santa écoute pour son mode. Et tu as branché tout ça sur Wazuh, décodeur et règles, pour qu’un binaire refusé lève une alerte de niveau 10 dans le même tableau de bord que le reste.

Le tout reste chez toi. Aucune application ne part se faire juger dans le cloud de quelqu’un d’autre, aucun tiers ne décide à ta place de ce qui a le droit de tourner sur tes machines.

Ton dispositif est complet. Quatre couches qui voient et qui bloquent, du serveur au poste de travail. Reste à le rendre vivable au quotidien. Un SIEM qui te réveille dix fois par nuit pour des broutilles, tu finis par l’ignorer, et un SIEM qu’on ignore ne sert à rien. À l’épisode 7, le dernier, on calibre l’alerting pour n’être dérangé que quand ça compte, et on fait les comptes, le coût total honnête de ce que tu viens de monter, face à la facture d’un SaaS équivalent.

Rappel de la série

Sept épisodes pour monter ta plomberie de sécurité souveraine, brique par brique.

• Épisode 0, le fondement de la série. Pourquoi une PME a besoin d’un SIEM souverain, NIS2, RGPD, et le coût du statu quo.
• Épisode 1, le socle. Le VPS durci hors CLOUD Act.
• Épisode 2, Wazuh en tout-en-un. Manager, indexeur et tableau de bord sur un seul nœud.
• Épisode 3, les agents partout. Déploiement sur tes serveurs, Mac et Windows.
• Épisode 4, la défense réseau communautaire. Bloquer les attaquants connus avant qu’ils n’arrivent.
• Épisode 5, le filtre mail. Anti-spam et anti-hameçonnage devant ton serveur de messagerie.
• Épisode 6, le contrôle d’exécution sur les Mac. Décider quelles applications ont le droit de démarrer. Tu viens de le lire.
• Épisode 7, alerting et coût total. Notifications calibrées et bilan financier honnête face au SaaS.

Des termes techniques ? Consulte le glossaire.