Livre blanc
Pour un environnement sandbox
plus performant
Une stratégie efficace pour assurer une protection complète contre
les logiciels malveillants
Sommaire
La coévolution des logiciels malveillants et de l'analyse à des fins de détection 3
Analyse dynamique et statique
3
Les performances : un impératif 3
Niveau 1 — Détection des attaques connues
4
Niveau 2 — Défenses basées sur l'analyse en temps réel des comportements
4
Niveau 3 — Analyse dynamique
5
Environnement sandbox propre à la cible
5
L'importance de l'interaction 5
Interprétation des analyses dynamiques 5
Niveau 4 — Analyse statique du code
2
6
Compression, décompression et ingénierie inverse 7
Une stratégie par étapes pour assurer la supériorité de
l'environnement sandbox 9
Pour un environnement sandbox plus performant
La coévolution des logiciels malveillants et de l'analyse à des fins de détection
Les cybercriminels et les stratèges en sécurité informatique se livrent une véritable course aux armements. D'un côté, les logiciels
malveillants utilisés pour infiltrer les environnements informatiques se font toujours plus sophistiqués et difficiles à détecter.
De l'autre, de nouvelles technologies émergent sans cesse afin de les identifier, quelle que soit la qualité de leur camouflage.
La détection basée sur l'analyse dynamique, ou « sandboxing », est un domaine qui connaît une des évolutions les plus
prometteuses côté défense. Divers produits sont d'ores et déjà disponibles et d'autres en sont à différents stades de leur
commercialisation. Sans surprise aucune, les approches adoptées au niveau architectural par les principaux développeurs
présentent de grandes variations, tout comme la façon dont ces nouveaux produits s'intègrent dans des stratégies
de sécurité plus vastes. A l'heure actuelle, il est difficile de dresser une comparaison fiable des diverses technologies,
ou même d'être certain que la terminologie de base est utilisée de manière cohérente.
Ce livre blanc propose une stratégie de conception logique pour l'analyse dynamique des logiciels malveillants,
qui optimise à la fois l'efficacité et la rentabilité de la détection. Nous tenterons d'identifier les limites de la détection
dynamique et les méthodes complémentaires requises pour garantir une sécurité à toute épreuve. Nous terminerons
par quelques distinctions importantes, souvent rendues obscures par une terminologie imprécise.
Analyse dynamique et statique
La distinction entre analyse dynamique et analyse statique constitue sans doute le point départ le plus important de
toute discussion concernant les solutions d'isolement en sandbox des logiciels malveillants avancés. L'analyse dynamique
s'efforce d'identifier les fichiers exécutables malveillants en les chargeant dans un environnement d'exécution sécurisé,
généralement virtualisé, puis en observant leur comportement pendant une durée prédéterminée.
Pour bien distinguer cette tactique de l'analyse statique, il convient tout d'abord de rectifier une erreur courante
dans l'utilisation de ce dernier terme. La véritable analyse statique (parfois appelée analyse statique de code) prédit le
comportement probable d'un fichier exécutable sur la base d'une évaluation détaillée de son code. Le terme « analyse
statique » est souvent utilisé à tort pour qualifier des techniques plus simples et moins révélatrices (parfois appelées
analyse statique de fichiers), qui ne testent parfois qu'une partie de l'en-tête d'un fichier ou qui peuvent uniquement
accéder au contenu non dissimulé du fichier. Leur utilité en termes d'identification des logiciels malveillants avancés est
donc limitée, et toutes les références à l'analyse statique dans ce livre blanc se rapportent à des techniques capables
d'extraire, d'interpréter et d'analyser l'intégralité du code d'un fichier.
Les techniques d'analyse dynamique et d'analyse statique présentent toutes deux des points forts et des lacunes.
L'analyse dynamique permet d'identifier les logiciels malveillants avec un degré de certitude très élevé grâce à l'observation
directe de leur comportement. Elle constitue le moyen le plus fiable d'identifier avec précision des menaces dissimulées
dans des fichiers exécutables complexes. Divers stratagèmes permettent toutefois de tenir en échec ce type d'analyse.
Ainsi, un fichier peut attendre la fin de la période d'observation, en repoussant l'exécution de tout comportement
révélateur pendant un laps de temps prédéterminé pouvant être plus long qu'une inspection viable du point de vue
économique en environnement sandbox. Il est également possible de programmer un fichier pour qu'il reconnaisse
un environnement sécurisé d'après l'absence (ou la présence) de certaines ressources, et n'exécute qu'une série
limitée d'opérations ayant pour but de le faire paraître inoffensif.
L'inspection statique identifie le code malveillant avec un degré de certitude moindre que l'analyse dynamique dans la
mesure où elle repose sur la déduction plutôt que sur l'observation. Elle offre cependant une certaine visibilité sur la nature
du code latent (non exécuté), qui échappe totalement à l'analyse dynamique. Par exemple, l'analyse statique du code
identifie les similitudes structurelles entre le code latent et des échantillons de logiciels malveillants connus. Elle quantifie
le pourcentage de code qui s'exécute lors d'une évaluation en environnement sandbox, et cartographie les chemins
d'exécution logique d'un fichier complexe sans exécuter réellement le code.
Ce qui frappe ici, c'est le degré de complémentarité entre les lacunes et les points forts respectifs de l'analyse statique
et de l'analyse dynamique. Bien que les techniques généralement associées à un environnement sandbox d'exécution de
logiciels malveillants soient dynamiques, une détection fiable et précise est peu probable à moins de combiner analyses
dynamique et statique du code dans le cadre d'un processus parfaitement intégré. Pour être efficace, un environnement
sandbox se doit d'être à la fois dynamique et statique.
Les performances : un impératif
L'analyse dynamique et l'analyse statique ont en commun leurs exigences considérables en termes de puissance de calcul. A tel
point qu'elles ne peuvent être appliquées au trafic réseau en temps réel et qu'elles doivent être exécutées de manière sélective
pour éviter de dégrader les performances du réseau et des applications. Selon le produit et le fournisseur, ce type d'analyse
peut prendre plusieurs minutes, voire des heures. Une approche rationnelle consiste à exécuter préalablement des technologies
plus frugales en ressources, capables d'éliminer de façon rapide et économique les menaces facilement identifiables.
Nous pensons qu'il est possible de créer un environnement sandbox d'exécution des logiciels malveillants extrêmement
efficace et rentable en empilant de manière séquentielle plusieurs types de moteurs analytiques exigeant une puissance de
calcul croissante. Tous les fichiers inconnus interceptés par les sondes de sécurité du réseau pourraient être renvoyés vers
3
Pour un environnement sandbox plus performant
ce service pour évaluation. Chaque fichier passerait par les moteurs d'inspection en pile, en commençant par le moteur le
plus rapide et exigeant le moins de ressources. Les fichiers identifiés comme malveillants à chacun des niveaux de la pile
seraient immédiatement bloqués et retirés du flux d'inspection, ce qui permettrait de réduire la charge sur les analyses
plus exigeantes en ressources réalisées en aval.
Approche multiniveau complète offrant un équilibre entre performances et détection
Environnement sandbox avancé
Analyse statique de code
et analyse dynamique
Listes locales
Signatures de virus
Réputation mondiale
des fichiers
Moteur d'émulation
Figure 1 — Processus d'inspection multimoteur par étapes pour la détection des logiciels malveillants
Si la composition de la pile d'inspection doit se montrer extensible pour intégrer de nouvelles techniques de détection à mesure
qu'elles apparaissent, elle pourrait aujourd'hui prendre la forme d'une séquence débutant par la détection des attaques
connues (au moyen de signatures et de services de réputation), suivie de la détection des comportements en temps réel (analyse
heuristique et émulation), de l'analyse dynamique et, enfin, de l'analyse statique du code. Ce type de configuration est qualifié
d'« architecture d'inspection par étapes ». Examinons à présent les différents niveaux de cette séquence hiérarchisée de processus.
Niveau 1 — Détection des attaques connues
Le premier niveau d'inspection fait appel aux deux techniques de détection des logiciels malveillants les plus anciennes et
les plus répandues. Celles-ci figurent également parmi les techniques les moins gourmandes en ressources informatiques
et les plus en temps réel. Technologie de base de tout produit antivirus, l'inspection basée sur les signatures assure une
identification positive rapide basée sur la mise en correspondance de modèles avec une bibliothèque d'échantillons de
codes malveillants connus. Les services de réputation collectent des renseignements sur des sources connues d'attaques
antérieures, notamment les hachages des logiciels malveillants réels, les emplacements géographiques, les domaines, les
URL et les adresses IP, de façon à mettre en place les bases requises pour l'identification des attaques connues, inconnues
et de type « jour zéro » émanant de vecteurs malveillants connus.
Ces deux techniques sont rapides et peu exigeantes en capacité de calcul et assurent l'identification des menaces en
temps réel avec un taux élevé de certitude. Les principaux attributs sont (1) une bibliothèque complète de signatures et
de sources de menaces connues et (2) une infrastructure rapide et fiable pour l'acquisition de nouveaux renseignements
sur les menaces au niveau mondial et leur distribution aux sondes locales.
Dans la mesure où ces deux technologies — et, dans une moindre mesure, les technologies de niveau deux (ci-dessous) —
sont largement déployées dans les produits de sécurité existants, il est très utile de pouvoir disposer, dans nos fonctionnalités
de gestion des environnements sandbox, de la capacité à définir séparément les moteurs d'inspection en sandbox qui seront
appliqués aux fichiers transmis par chaque type de sonde. Ainsi, une inspection basée sur les signatures réalisée par un
service IPS, par exemple, ne sera pas répétée dans le sandbox.
Niveau 2 — Défenses basées sur l'analyse en temps réel des comportements
Deux types distincts de détection sont également appliqués au deuxième niveau d'inspection : l'analyse heuristique et
l'émulation. L'identification heuristique fait appel à des règles et à l'analyse de modèles de comportements pour créer des
constructions génériques et identifier les similitudes entre un fichier suspect et des groupes ou familles de menaces connues
liées. L'émulation simule l'exécution d'un fichier dans un environnement hôte simplifié et consigne les comportements
résultants. L'environnement d'émulation peut contenir un sous-ensemble des ressources processeur, mémoire et API du
système d'exploitation. L'émulation est parfois décrite comme une analyse dynamique partielle à complète, ou comme un
environnement sandbox léger, mais est suffisamment économe en ressources pour pouvoir fournir des résultats en temps réel.
L'analyse heuristique et l'émulation assurent l'identification en temps réel de menaces observées pour la toute première
fois et ne sont que légèrement moins fiables que les techniques basées sur les signatures. Elles impliquent certaines
opérations de décompilation et de décompression du code, mais comme il s'agit d'un processus en temps réel,
seules quelques fonctions sont déployées pour la décompression ou l'ingénierie inverse des fichiers dissimulés.
Il convient de noter que les différents types de contenu (fichiers exécutables, code shell, JavaScript, HTML et Java)
nécessitent des émulateurs différents, spécifiques pour chaque langage. La fiabilité et l'efficacité d'un moteur d'émulation
dépendent directement de l'exhaustivité de ses fonctionnalités.
4
Pour un environnement sandbox plus performant
Niveau 3 — Analyse dynamique
Le troisième niveau de notre modèle d'architecture sandbox marque la frontière entre les analyses effectivement exécutées en
temps réel et les techniques plus gourmandes en ressources, qui imposent inévitablement une latence légèrement plus grande.
A ce stade, les fichiers qui n'ont pas été identifiés de manière concluante comme malveillants lors des précédentes inspections
sont autorisés à s'exécuter dans un environnement virtuel dûment isolé. L'analyse dynamique véritable se distingue de
l'émulation dans le sens où elle instancie un environnement d'exécution parfaitement opérationnel, qui a été virtualisé et isolé
pour permettre l'exécution en toute sécurité de code potentiellement malveillant. L'analyse procède ensuite à la consignation
ou au classement de tous les comportements observés.
Environnement sandbox propre à la cible
Deux approches sont généralement utilisées pour configurer les environnements virtuels intégrés dans un environnement
sandbox d'exécution de logiciels malveillants. Les différences entre les deux sont importantes car la plupart des
environnements informatiques sont constitués d'une variété de plates-formes matérielles et logicielles, et la plupart des
échantillons de logiciels malveillants ciblent un environnement d'exploitation ou une application spécifique. La première
approche consiste à virtualiser un environnement générique unique et à l'utiliser pour toutes les analyses d'échantillons.
Une telle approche risque toutefois de passer à côté de comportements malveillants reposant sur des ensembles de
ressources ou des paramètres de configuration spécifiques qui ne sont pas toujours présents dans l'image générique.
Elle est par contre économe en ressources dans la mesure où elle n'exige qu'une seule analyse.
La deuxième approche consiste à virtualiser plusieurs environnements (diverses configurations et plates-formes serveur
Windows, par exemple, ainsi qu'une sélection d'images de plates-formes PC et mobiles). Les échantillons suspects sont
exécutés dans chacun de ces environnements. Cependant, une telle stratégie peut elle aussi passer à côté de l'environnement
cible réel et produire davantage de faux positifs. Elle exige en outre beaucoup plus de ressources informatiques.
L'exécution d'un fichier exécutable suspect dans un environnement virtuel reproduisant très précisément le système ciblé
par le fichier est une stratégie beaucoup plus efficace et rentable. Cette approche nécessite toutefois la disponibilité d'un
large éventail de configurations de systèmes d'exploitation, ou l'importation dans l'environnement d'images de référence
de l'ensemble des plates-formes des postes clients. L'environnement sandbox doit pouvoir identifier instantanément
l'environnement hôte cible et lancer rapidement la machine virtuelle correspondante — et bien qu'il ne s'agisse pas d'une
activité réseau, une intégration avec les systèmes des postes clients est requise. Lorsque ces différentes conditions sont
réunies, la probabilité est beaucoup plus grande de pouvoir déclencher et observer l'éventail complet de comportements
potentiels d'un fichier suspect, et de procéder à une évaluation précise de ses intentions.
L'importance de l'interaction
Pour permettre à l'inspection en sandbox d'évaluer avec précision les intentions d'un fichier exécutable, l'environnement
virtuel doit répondre de manière interactive au comportement de ce fichier, de la même façon que le ferait un système
hôte normal. L'environnement sandbox doit notamment émuler automatiquement la réponse normale de l'hôte aux
demandes de connexion réseau. L'absence de ces réponses attendues pourrait indiquer au logiciel malveillant qu'il fait
l'objet d'une analyse en environnement sandbox et lui permettre de mettre en œuvre des mesures de contournement.
Le sandbox doit également disposer de services de réputation, de façon à identifier immédiatement toute demande à haut
risque d'accès à des adresses IP, des URL et des fichiers malveillants connus en tant qu'indicateurs de menaces présentant
un degré élevé de probabilité.
Outre l'interactivité requise pour déclencher automatiquement des inspections en ligne de fichiers, les analystes en sécurité
ont également besoin d'un mode interactif complet pour les analyses manuelles hors ligne. Un tel mode doit permettre
à un analyste de lancer manuellement une machine virtuelle et de charger un échantillon de fichier exécutable avec une
prise en charge complète de KVM. Bien souvent, ce n'est qu'en lançant des sessions de navigateur et d'autres applications
d'entreprise normales qu'il est possible de déclencher et d'observer des comportements spécifiques associés à des menaces.
Interprétation des analyses dynamiques
Les deux premiers niveaux de notre pile d'inspection génèrent des résultats en temps réel simples. Un fichier inconnu
pourra rapidement être identifié en tant que menace connue par la mise en correspondance des signatures, ou encore
être jugé suffisamment malveillant dans des environnements d'émulation en temps réel. Dans les deux cas, une décision
binaire est prise rapidement et le fichier est bloqué ou autorisé.
En revanche, le résultat initial d'une analyse dynamique est un fichier journal qui n'a de sens que s'il est mis en corrélation.
Des comportements spécifiques doivent être identifiés et regroupés, et leur importance évaluée à la lumière d'autres
événements. Le résultat d'une analyse en environnement sandbox adapté à l'entreprise n'est ni un journal long et
complexe, ni une décision de blocage/autorisation trop simpliste. Pour être d'un quelconque intérêt pour l'entreprise,
l'outil de sandboxing doit fournir un rapport agrégé et structuré qui identifie et classe les comportements pertinents et leur
attribue un score général. Ce score peut tantôt être suffisant pour déclencher une décision de blocage, tantôt nécessiter
des données d'une analyse statique ultérieure à l'appui. Dans les deux cas, il fournit des informations exploitables
susceptibles d'être utilisées par les responsables de la sécurité.
5
Pour un environnement sandbox plus performant
Dissimulation du fichier par la modification
de ses attributs
Manipulation à l'aide de contenu actif
dans le répertoire temporaire Administrateur
Détection de contenu exécutable injecté
par l'échantillon
Obtention et utilisation de l'icône
d'une application système légitime
Création de contenu exécutable dans le répertoire
temporaire Administrateur
Création de contenu exécutable dans
le répertoire Windows
Dans Microsoft, CreateURLMoniker peut produire
des résultats différents de la saisie et son utilisation
peut créer des problèmes de sécurité.
Exécution de contenu actif depuis
le dossier système Windows
Compromission d'une zone de la mémoire dans
l'espace d'adressage virtuel d'un processus étranger
Configuration d'une fonction de rappel
afin de contrôler les événements
matériels du système et de l'ordinateur
Tentative de connexion à un fournisseur
de services spécifique
Téléchargement de données depuis
un serveur web
Création de contenu dans le répertoire système
de Windows
Enregistrement (annulation de
l'enregistrement) du nom du service
sur un serveur d'échange dynamique
de données (DDE)
Figure 2 — Rapport de classification et de synthèse des comportements produit par l'analyse dynamique
Niveau 4 — Analyse statique du code
La dernière étape de notre environnement sandbox multiniveau étendu est l'analyse statique du code, que nous pourrions
décrire comme une « analyse de codes/listes par désassemblage ». Lancé en même temps que l'analyse dynamique de
niveau trois, ce processus intègre certains résultats de l'inspection dynamique au fur et à mesure de leur disponibilité.
Nous avons expliqué un peu plus tôt que les techniques d'inspection de niveau deux proposées (analyse heuristique
et émulation) reposent sur l'accès au code source d'un fichier. Toutefois, cette analyse en temps réel offre peu de
fonctionnalités pour l'extraction du code dissimulé ou compilé. C'est précisément ce type d'investigation numérique
en profondeur qui est visé à l'étape quatre.
Figure 3 — L'analyse dynamique est incomplète à elle seule.
6
Pour un environnement sandbox plus performant
Compression, décompression et ingénierie inverse
Diverses raisons parfaitement légitimes peuvent conduire à la dissimulation ou au masquage du code exécutable compilé
d'un programme, la plus évidente étant la protection de la propriété intellectuelle. Les développeurs de logiciels veulent,
à juste titre, empêcher leurs concurrents de procéder à l'ingénierie inverse de leurs produits et de remonter jusqu'au code
source à partir du code d'assemblage distribué. Sans surprise, divers développeurs entreprenants ont créé un éventail
d'outils commerciaux afin de compliquer considérablement un tel processus. Appelés programmes de compression
(Themida et Armadillo, par exemple), ces outils permettent d'appliquer très facilement un éventail de techniques de
masquage et de randomisation au code compilé du programme. Il est ainsi extrêmement difficile de reconstruire le
code d'assemblage et, partant, de remonter jusqu'à la source. Les auteurs et développeurs de logiciels malveillants ont
simplement adopté les techniques du secteur des logiciels à leur avantage, de façon à rendre leurs attaques masquées
beaucoup plus difficiles à distinguer des fichiers légitimes.
Difficiles, certes, mais pas impossibles.
Figure 4 — Menu de masquage de Themida, un outil puissant de compression pour les applications Windows
Au quatrième niveau de notre environnement d'isolement des logiciels malveillants, les fichiers compressés et dissimulés
font l'objet d'une ingénierie inverse afin de récupérer des versions intactes du code d'assemblage compilé. Ils sont ensuite
analysés et soumis à une analyse statistique visant divers objectifs :
•
Evaluer la similitude avec des familles connues de logiciels malveillants
•
Mesurer le code latent qui ne s'est pas exécuté pendant l'analyse dynamique
•
Dresser une carte logique du ou des chemins d'exécution complets du fichier
Les menaces persistantes avancées modernes sont généralement des adaptations de code malveillant connu (et efficace).
Des modifications mineures suffisent à contourner l'inspection basée sur les signatures, qui exige une correspondance
exacte pour identifier des logiciels malveillants. Cependant, l'analyse du code complet par rapport à une bibliothèque de
références de familles connues de logiciels malveillants permet souvent de mettre au jour des logiciels malveillants furtifs.
Par exemple, un fichier suspect qui présente des signes mineurs de compromission, insuffisants pour entraîner son blocage,
mais qui affiche plus de 70 % de similitude avec une famille connue de logiciels malveillants (conficker ou voter_1,
par exemple) devrait normalement être bloqué. Sans l'analyse statique du code, ce logiciel malveillant aurait pourtant
réussi à infiltrer le réseau.
7
Pour un environnement sandbox plus performant
Figure 5 — La similitude avec une famille connue de logiciels malveillants constitue une preuve sérieuse du potentiel malveillant.
De manière similaire, les menaces persistantes avancées cherchent de plus en plus souvent à tenir compte de leur
environnement d'exécution ou exigent une séquence d'interactions spécifiques pour déclencher une action. Cela signifie
qu'une grande partie du code des logiciels malveillants furtifs demeure latent pendant l'analyse dynamique. Mais même
si le comportement de ce code latent ne peut être extrait, la latence d'une grande partie du code d'un fichier suspect doit
constituer un aspect essentiel de l'inspection réalisée par l'analyste en sécurité.
Prenez un fichier suspect qui ne manifeste aucun comportement malveillant. L'analyse dynamique seule conclura que
ce fichier est sûr. Mais imaginez que le fichier présente plus de 70 % de similitude avec une famille connue de logiciels
malveillants et que plus de 40 % de son code n'ait pas été actif ou analysé dans l'environnement sandbox. Ces deux
informations probantes indirectes sont suffisantes pour bloquer le fichier, à tout le moins jusqu'à ce qu'un responsable
de la sécurité puisse l'analyser.
Résumé des comportements (couverture du code de 57 %) :
Dissimulation du fichier par la modification
de ses attributs
Manipulation à l'aide de contenu actif
dans le répertoire temporaire Administrateur
Détection de contenu exécutable injecté
par l'échantillon
Obtention et utilisation de l'icône
d'une application système légitime
Création de contenu exécutable dans le répertoire
temporaire Administrateur
Création de contenu exécutable dans
le répertoire Windows
Dans Microsoft, CreateURLMoniker peut produire
des résultats différents de la saisie et son utilisation
peut créer des problèmes de sécurité.
Exécution de contenu actif depuis
le dossier système Windows
Compromission d'une zone de la mémoire dans
l'espace d'adressage virtuel d'un processus étranger
Configuration d'une fonction de rappel
afin de contrôler les événements
matériels du système et de l'ordinateur
Tentative de connexion à un fournisseur
de services spécifique
Téléchargement de données depuis
un serveur web
Création de contenu dans le répertoire système
de Windows
Enregistrement (annulation de
l'enregistrement) du nom du service
sur un serveur d'échange dynamique
de données (DDE)
Figure 6 — La présence d'importantes portions de code latent souligne les lacunes de l'analyse uniquement dynamique
Lorsqu'une intervention humaine est nécessaire, l'établissement d'un schéma des actions du fichier peut se révéler
extrêmement utile à des fins d'investigation numérique. Contrairement aux fichiers journaux ou aux observations du
comportement (analyse dynamique), un schéma aide les responsables de la sécurité à analyser les zones cachées et les
interactions du code. Une telle approche est souvent essentielle pour identifier le code latent, en particulier lorsqu'elle
est utilisée en combinaison avec un environnement sandbox autorisant des interactions manuelles avec le fichier suspect
sur la machine virtuelle.
8
Pour un environnement sandbox plus performant
Carte du code interactif exécuté
Lignes bleues : code exécuté de manière dynamique.
Lignes rouges : code exécuté de manière statique.
Figure 7 — La visualisation des processus au sein du fichier permet aux analystes en sécurité de stimuler le code latent.
Ces résultats sont ensuite combinés aux observations de l'analyse dynamique de niveau trois, pour obtenir un score global
indiquant avec quel degré de certitude le fichier échantillon ou exécutable est jugé malveillant.
Une stratégie par étapes pour assurer la supériorité de l'environnement sandbox
Un service de détection des logiciels malveillants avancés conçu et configuré selon la stratégie multiniveau par
étapes décrite ci-dessus offre une solution beaucoup plus sophistiquée, fiable et économique que les approches
actuellement disponibles sur le marché. Elle empêche la surcharge de l'environnement sandbox grâce à l'élimination
des menaces connues et facilement identifiables au moyen de services d'inspection par signatures et de renseignements
sur la réputation, peu gourmands en ressources et affichant un taux élevé de détection. Elle augmente en outre
considérablement l'efficacité et la précision de l'analyse dynamique grâce à la mise en place d'un environnement sandbox
d'exécution propre à la cible. Enfin, l'analyse statique du code fait tomber le masque de dissimulation pour révéler la
nature cachée du code latent et utilisant des techniques de contournement.
Fait exceptionnel dans l'histoire alambiquée de la coévolution des logiciels malveillants et de la sécurité, cette dernière est
sur le point de faire un bond proactif en avant.
Pour en savoir plus, visitez le site www.mcafee.com/fr/products/advanced-threat-defense.aspx.
McAfee S.A.S.
Tour Franklin, La Défense 8
92042 Paris La Défense Cedex
France
+33 1 47 62 56 00 (standard)
www.mcafee.com/fr
McAfee et le logo McAfee sont des marques commerciales ou des marques commerciales déposées de McAfee, Inc. ou de ses filiales aux
Etats-Unis et dans d'autres pays. Les autres noms et marques sont la propriété de leurs détenteurs respectifs. Les plans, les spécifications et les
descriptions des produits mentionnés dans le présent document sont donnés à titre indicatif uniquement. Ils peuvent être modifiés sans préavis
et sont fournis sans aucune garantie, implicite ou explicite. Copyright © 2014 McAfee, Inc.
60837wp_build-sandbox_0214_fnl_ETMG