Voici le plan de la série d’articles prévus sur ce sujet :
- Déploiements possibles sur un S.I.. ;
- Cas d’usage « réels » : différence et complémentarité avec EDR ;
- Intérêt et puissance du scan « hors ligne ».
- Bonnes pratiques de configuration.
Non, l’antivirus n’est pas mort, et n’a pas été « remplacé » par l’EDR ! Dans cette série d’articles, nous allons revenir sur l’utilité encore réelle de l’antivirus, ses cas d’usage (y compris comparativement à l’EDR), ses scénarios de déploiement, et les bonnes pratiques d’administration.
D’ailleurs, en amont des textes qui vont suivre, nous souhaitons sensibiliser nos lecteurs sur le fait qu’un antivirus, cela reste une technologie relativement complexe, qui nécessite intégration et maintien en conditions opérationnelles (avec administration spécifique).
Partie 1 : Déploiements possibles (et recommandés) sur un système d’information
Tout d’abord, il convient de rappeler que l’antivirus a différents positionnements techniques possibles, sur un système d’information, dont voici une liste (non exhaustive, mais tirée du RETEX métier) :
- Postes ;
- Serveurs ;
- Baies réseau de stockage ;
- Service d’accès à Internet sécurité (SWG alias « proxy ») ;
- Service de messagerie (SEG, couches MDA et MTA) ;
- Service de transfert de fichiers vers/depuis l’extérieur de l’organisation ;
- Mobiles.
Les postes
Le premier emplacement, les postes, semble tomber sous le sens. En effet, le poste est l’un des actifs les plus exposés du S.I. lorsque l’on regarde les vecteurs techniques d’infection principaux, que sont la messagerie, la navigation, et les supports amovibles. Pourtant le RETEX de réponse à incident montre qu’il y a encore trop de postes non protégés (ou avec un antivirus obsolète, voire mal installé) ; et les postes sous MacOSX sont trop souvent oubliés, alors qu’ils ne sont aucunement immuns à la menace virale (d’ailleurs, des tests indépendants prennent cela en compte spécifiquement).
N’oublions cependant pas les postes obsolètes : certains éditeurs ont des versions de leurs produits qui s’installent encore sur Windows 7 et 8, c’est toujours une couche de sécurité bonne à prendre (ou garder), le temps que ces environnements obsolètes ne soient migrés ! Le minimum, à défaut, pourrait être de régulièrement télécharger et réaliser un scan avec l’outil Safety Scanner (gratuit !) de Microsoft ; cela peut s’automatiser. Pour XP, en revanche, cela devient vraiment compliqué…
Les serveurs
Le deuxième emplacement, les serveurs, pourrait tomber lui-aussi sous le sens, pourtant le RETEX de réponse à incident semble montrer le contraire : nombre de serveurs ne sont pas protégés en production. Certes, une configuration antivirus pour serveur est spécifique aux rôles du serveur. Diverses exclusions sont à mettre en place, y compris par rapport aux composants applicatifs hébergés (nous reviendrons sur ces exclusions dans la partie « bonnes pratiques de configuration »).
Malgré tout, un serveur, même Linux, qui héberge des partages réseau (en SBM, par ex), doit bien être protégé niveau antivirus en local, et non pas « tirer parti » de la protection antivirus des clients qui se connectent à ses partages. La problématique est identique à celle des baies réseau, explicitée ci-après.
Les baies réseau
Le fait de positionner spécifiquement un antivirus adapté sur elles est encore trop peu commun en production. Cependant, la légende urbaine qui consiste à compter sur les postes de travail pour protéger niveau antiviral les baies de stockage réseau, ne tient pas sur le plan technique.
En effet, typiquement lors d’un accès à un fichier stocké sur un partage réseau de la baie, avec le protocole SMB, ce dernier offre une couche d’abstraction au client (Windows Explorer, par ex), du système de fichiers de la baie réseau. Toutefois, cette couche d’abstraction ne permet pas un contrôle total réel du système de fichier exposé : ainsi, un accès distant en SMB ne peut être aussi profond et fiable, qu’un accès local par le système hébergeant le partage réseau. Il convient donc de positionner un antivirus sur la baie réseau elle-même, pour être sûr de pouvoir parcourir toutes les arborescences partagées, et nettoyer de manière fiable tous les fichiers détectés.
En outre, le RETEX de réponse à incident montre des cas où des fichiers infectés stockés sur baie réseau, normalement détectés par l’antivirus sur le poste, n’ont pas été détectés car le transfert du fichier en SMB a permis un début d’exécution du fichier en local sur le poste, avant que le fichier soit déclaré « pleinement téléchargé » au niveau système et que l’antivirus ne le scanne…
Le service d’accès à Internet
il convient de rappeler la nécessité de disposer d’interception SSL. En effet, la grande majorité (80-90%) du trafic Internet en entreprise est à présent chiffré par défaut, donc comment la passerelle peut-elle « intercepter » les fichiers à analyser au niveau antivirus, si le flux n’est pas déchiffré puis rechiffré à son niveau ?
Certains évoqueront l’évolution aujourd’hui avec des passerelles en mode service (« Proxy-as-a-Service », type NetSkope ou Zscaler), et soit un paramétrage du navigateur (fichier PAC) pour passer par cet équipement de sécurité, soit un agent à déployer sur les postes et qui intercepte les flux. Le RETEX SOC/CERT, notamment pour des cas des flux malveillants de type C&C qui ne « lisent pas » la configuration du navigateur, et qui sortent sur Internet « en direct », nous fait recommander de privilégier l’agent, afin d’intercepter tous les flux sortants des machines de manière fiable.
Le service de messagerie
la nécessité de protection antivirale semble évidente pour tout ce qui est pièce jointe voire contenu actif (script) dans les emails. D’ailleurs, en complémentarité directe avec la protection antivirale pure, une série d’extensions de fichiers dites « à risque » est normalement implémentée en blocage (ex pour MS365 et Outlook), ce qui bloque les fichiers même si l’antivirus ne les détecte pas ; cela contribue néanmoins au filtrage des fichiers.
En fait, la recommandation pour le filtrage antiviral de la messagerie est de fonctionner en multi-niveaux :
- le MTA : filtrage périmétrique et le plus quantitatif, les fréquences de moteur antivirus positionnés ici sont fréquemment de moins de 15 min ;
- le MDA : filtrage interne à l’organisation, au niveau stockage dans les BAL, transparent pour les utilisateurs. Cela permet d’être complémentaire avec celui du MTA, mais aussi de « rattraper » un email malveillant qui aurait échappé au filtrage, et de le supprimer en BAL avant (espérons) que l’utilisateur ne le récupère et l’ouvre ;
- le MUA : mis à part quelques règles « statiques » plutôt en rapport avec de l’antispam, c’est en fait l’antivirus de la machine où le client de messagerie est installé, qui assumera le rôle de barrière antivirale ultime.
D’aucuns diront qu’avec des solutions de messagerie « en service », telles qu’Exchange Online, la notion de MTA et MDA est un peu moins visible par le client final. Certes, mais le principe de filtrage en couches demeure pourtant une recommandation valable.
Le service de transfert de fichiers vers/depuis l’extérieur de l’organisation
Cela va dépendre de comment un tel service est implémenté par une organisation. S’il s’agit d’un serveur relai en DMZ, installé et maintenu par l’organisation, il convient alors de sécuriser ledit serveur comme il se doit, et d’y installer un antivirus en veillant à ce que tout fichier entrant et sortant soit scanné (avec une notification envoyée à l’émetteur du fichier).
S’il s’agit par contre d’une solution achetée sur étagère (ex : Kiteworks), c’est un point à voir avec chaque éditeur.
D’ailleurs, les jusqu’au-boutistes envisageront d’implémenter une diode de données, garantissant un échange à sens unique des fichiers, avant et après contrôle. Cela peut être extrêmement efficace, notamment pour des services RH recevant beaucoup de CV, ou des services de comptabilité traitant beaucoup de factures et devis.
Les mobiles
Enfin, concernant les mobiles, la problématique est évidemment de détecter des applications malveillantes qui seraient installées sur les ordiphones (« smartphones »).
Pour cela, une solution d’inventaire et gestion du parc, type MDM (ex : Intune ou MobileIron), est nécessaire en amont ; puis une solution de sécurité mobile spécifique, type MTP (ex : WithSecure EMP ou Tehtris MTD) sera nécessaire pour la détection d’attaques et d’applications malveillantes elles-mêmes.
Conclusion
Voilà, c’est la fin de cet article, premier de la série sur les antivirus. En espérant qu’il vous intéresse et vous soit utile ! A bientôt pour les suivants.
NB : certains puristes pourraient vouloir rajouter les stations blanches comme point de positionnement recommandé d’un antivirus au sein d’un S.I.. Et ils ont tout à fait raison dans le principe ! Cependant, le MSSP Metsys regrette de ne voir que trop peu de stations blanches dans ses périmètres d’intervention, donc nous ne l’avons pas listée. Pour autant, la protection contre les clefs USB infectées par station blanche, demeure une vraie recommandation.
