Tout produit qui se présente comme de la « détection avancée des menaces » pour Mac repose sur un petit nombre de mécanismes, presque tous documentés par Apple. Savoir sur quel mécanisme s’appuie une fonction donnée vous dit ce qu’elle peut réellement voir, et ce qui lui échappe. Cet article passe ces couches en revue une par une : ce qu’est une signature, ce que vérifie la notarisation, ce que le framework Endpoint Security d’Apple expose aux logiciels de sécurité, ce que veut dire l’analyse comportementale en pratique, et ce qu’un modèle qui surveille les connexions réseau peut ou ne peut pas juger.
En résumé : aucune couche ne voit tout. Un scanner de fichiers ne voit jamais une connexion. Un moniteur réseau ne voit jamais un fichier. Les produits honnêtes sur cette frontière sont plus utiles que ceux qui la brouillent.
Première couche : les signatures (XProtect)
La technique de détection la plus ancienne est la signature : un motif qui correspond à un programme malveillant connu. Sur Mac, ce travail revient à XProtect. Le guide de sécurité des plateformes Apple, dans la page Protection contre les logiciels malveillants, décrit XProtect comme un moteur fondé sur des signatures et précise qu’il intervient à trois moments : au premier lancement d’une app, quand une app a été modifiée sur le disque, et quand les signatures de XProtect sont mises à jour.
Apple est franche sur la portée de cette approche. La même page indique que les règles de XProtect sont « plus génériques qu’un simple hachage de fichier », ce qui lui permet de repérer des variantes qu’Apple n’a jamais vues, et décrit un moteur de remédiation qui supprime les infections après coup. Ce qu’une signature ne peut pas faire, par construction, c’est reconnaître ce pour quoi personne n’a encore écrit de règle. C’est précisément cet écart que toutes les autres couches cherchent à réduire.
Deuxième couche : la notarisation et Gatekeeper
La deuxième couche agit avant la première ouverture d’une app. La page d’Apple sur Gatekeeper et la protection à l’exécution explique que Gatekeeper vérifie qu’une app téléchargée provient d’un développeur identifié, qu’elle a été notarisée par Apple et qu’elle n’a pas été altérée, puis qu’il demande l’accord de l’utilisateur avant d’ouvrir un logiciel téléchargé. La notarisation elle-même est une analyse qu’Apple effectue sur les logiciels signés avec un Developer ID avant leur diffusion ; le guide ajoute qu’Apple peut émettre plus tard un ticket de révocation pour un logiciel reconnu malveillant, même s’il avait été approuvé auparavant.
Cette couche est un contrôle à la porte. Elle répond à la question « sait-on qui a construit ceci, et Apple y a-t-elle trouvé quelque chose de manifestement anormal ? ». Elle ne suit pas l’app une fois entrée. Une app qui franchit la porte puis se comporte mal, ou dont le comportement change après une mise à jour, sort du champ de vision de Gatekeeper à partir de ce moment.
Troisième couche : le framework Endpoint Security
Les produits de détection tiers sur Mac, la catégorie qu’on appelle généralement EDR (endpoint detection and response), sont pour l’essentiel construits sur une seule API d’Apple : le framework Endpoint Security. Apple l’a introduit dans macOS 10.15 pour que les logiciels de sécurité reçoivent un flux d’événements système depuis l’espace utilisateur (un processus qui se lance, un fichier ouvert ou écrit, une tâche créée) au lieu de charger une extension de noyau, un mécanisme qu’Apple retire progressivement.
C’est la couche qui voit les arbres de processus : quel processus en a lancé quel autre, avec quels arguments, en touchant quels fichiers. C’est aussi là que vit habituellement l’« analyse comportementale ». La détection comportementale consiste à comparer ce que fait un processus aux techniques connues des attaquants, plutôt qu’à un fichier connu. La référence publique de ces techniques est la matrice MITRE ATT&CK pour macOS, qui recense les tactiques depuis l’accès initial et la persistance jusqu’au commandement et contrôle et à l’exfiltration, chacune découpée en techniques précises et observables.
L’analyse comportementale a un coût réel : une app qui écrit légitimement des agents de lancement, lit le trousseau ou lance des commandes shell ressemble beaucoup, vue depuis le seul flux d’événements, à une app qui le fait pour de mauvaises raisons. Chaque éditeur d’EDR règle ce compromis à sa façon, et aucun ne publie assez de détails pour qu’un observateur extérieur puisse comparer. Ce qu’on peut affirmer avec certitude, c’est que cette couche exige soit un produit payant, soit une bonne dose d’expertise. Pour les particuliers, la fondation à but non lucratif Objective-See publie des outils gratuits et open source bâtis sur les mêmes frameworks Apple, comme TaskExplorer pour inspecter les processus en cours et KnockKnock pour lister ce qui est configuré pour se lancer automatiquement.
Quatrième couche : la mémoire et le contenu des fichiers
Deux types d’analyse se situent encore sous la couche Endpoint Security : l’inspection approfondie du contenu d’un fichier (l’analyse statique, ce que fait un antivirus) et l’inspection de la mémoire d’un processus en cours d’exécution. Ce sont les seules façons de savoir ce qu’un programme contient réellement, et c’est le domaine des antivirus et des outils forensiques. Il faut le dire clairement, parce que les textes marketing laissent souvent entendre le contraire : un pare-feu, FireAI compris, ne fait rien de tout cela. FireAI n’analyse pas les fichiers, ne lit pas la mémoire des processus et n’est pas un antivirus.
Cinquième couche : le réseau
La dernière couche est celle que les autres ne peuvent pas atteindre. Presque tout ce qu’un attaquant veut faire après avoir placé du code sur un Mac passe par le réseau : récupérer une deuxième charge, se signaler à un serveur de contrôle, faire sortir les données volées. Dans la matrice ATT&CK, ces étapes ont leurs propres colonnes, commandement et contrôle puis exfiltration, justement parce qu’elles forment une phase distincte et observable.
Une couche réseau voit un ensemble de faits différent de celui des couches précédentes. Pour chaque nouvelle connexion sortante, elle connaît le binaire signé qui l’a ouverte, l’hôte, l’IP et le port de destination, le protocole, le caractère chiffré ou non de la connexion, et le moment. C’est assez pour qu’un examinateur, humain ou modèle, porte plusieurs jugements utiles :
- La réputation de la destination : l’hôte ou l’IP figure-t-il sur une liste publique comme abuse.ch, Spamhaus, Phishing Army ou OpenPhish, ou s’agit-il d’un nœud de sortie Tor ? Les flux de renseignement sur les menaces sont une consultation de liste, pas une supposition, et ils peuvent être appliqués en local sans envoyer le trafic nulle part.
- Un binaire vu pour la première fois : est-ce la première fois que cette signature de code ouvre une connexion sur ce Mac ? Un outil non signé, fraîchement installé, qui se connecte aussitôt à une IP inconnue ne présente pas le même risque que Safari qui joint un CDN.
- Des bizarreries de port ou de protocole : un éditeur de texte qui parle sur le port 4444, une app qui utilise des adresses IP brutes plutôt que des noms d’hôte, ou une connexion vers un pays où l’app n’a rien à faire.
- Des identifiants en HTTP clair : si une connexion n’est pas chiffrée, son contenu est lisible sur le Mac avant de partir, et un numéro de carte, un mot de passe ou une clé d’API qui circule en clair peut être arrêté à ce moment précis.
C’est ce que fait la revue par IA privée de FireAI. Un petit modèle embarqué (un téléchargement facultatif de 1,5 Go) examine chaque connexion venant d’une app inconnue, à partir exactement des faits listés ci-dessus, puis la bloque, la signale ou la laisse passer avec une explication en langage clair que vous pouvez lire et annuler. Le jugement est rendu sur le Mac ; le trafic n’est jamais envoyé à HisnLabs ni à qui que ce soit pour analyse.
Les limites sont tout aussi concrètes. Un examinateur réseau ne voit pas le contenu des fichiers, il ne peut donc pas vous dire qu’un téléchargement est hostile avant qu’il ne s’exécute. Il ne voit pas la mémoire, il ne peut donc pas détecter une charge injectée dans un processus de confiance, et si du code hostile se cache derrière une app signée et autorisée, son trafic hérite des permissions de cette app. Il ne déchiffre pas TLS : pour une connexion chiffrée, il juge la destination et le schéma, pas le contenu. Et un flux de réputation ne connaît que les destinations que quelqu’un a déjà signalées.
Assembler les couches
Lue comme une pile, l’image est cohérente. La notarisation et Gatekeeper décident si le code entre. XProtect supprime ce qui est déjà connu comme nuisible. Les outils fondés sur Endpoint Security observent ce que font les processus. Les antivirus et la forensique lisent le contenu des fichiers et la mémoire. La couche réseau surveille ce qui sort. Chacune répond à une question que les autres ne peuvent pas traiter, et le test utile pour n’importe quelle promesse de « détection avancée » est simple : de quelle couche s’agit-il, et que voit cette couche ?
Pour la plupart des propriétaires de Mac, la combinaison pratique, ce sont les couches intégrées d’Apple, tenues à jour, plus une visibilité sur la seule phase qu’Apple ne vous montre pas : quelles apps se connectent, et où. C’est une promesse plus étroite que « arrête chaque menace », et c’est celle qui peut réellement être tenue.
Le rôle de FireAI et de HisnLabs
FireAI est la couche réseau de cette pile, et rien de plus : il n’analyse pas les fichiers et ne lit pas la mémoire, mais il est le seul endroit par lequel chaque connexion sortante d’une app doit passer, examinée sur votre Mac par un modèle qui explique ce qu’il a vu.
FireAI est le produit de HisnLabs : un pare-feu IA embarqué pour Mac. Il montre en langage clair chaque connexion faite par vos applications et vous laisse décider ce qui sort de votre Mac — son IA fonctionne en local, votre trafic ne nous est jamais envoyé, ni à personne d’autre. L’équipe de recherche en sécurité de HisnLabs est celle qui garde ces décisions fiables : elle recense les domaines de simple télémétrie face à ceux d’un vrai service, suit le pays et le réseau derrière une connexion, et entraîne le modèle embarqué (la fonction Autopilot) sur du trafic réel, sans que rien ne quitte votre Mac.
Vous pouvez lire les choix techniques qui s’y trouvent, ou essayer FireAI pendant 17 jours, sur FireAI, par HisnLabs.