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 6 Compression, décompression et ingénierie inverse 7 Une stratégie par étapes pour assurer la supériorité de l'environnement sandbox 9 2 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 Détection de contenu exécutable injecté par l'échantillon Création de contenu exécutable dans le répertoire temporaire Administrateur 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é. Compromission d'une zone de la mémoire dans l'espace d'adressage virtuel d'un processus étranger Tentative de connexion à un fournisseur de services spécifique Création de contenu dans le répertoire système de Windows Manipulation à l'aide de contenu actif dans le répertoire temporaire Administrateur Obtention et utilisation de l'icône d'une application système légitime Création de contenu exécutable dans le répertoire Windows Exécution de contenu actif depuis le dossier système Windows Configuration d'une fonction de rappel afin de contrôler les événements matériels du système et de l'ordinateur Téléchargement de données depuis un serveur web 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 Détection de contenu exécutable injecté par l'échantillon Création de contenu exécutable dans le répertoire temporaire Administrateur 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é. Compromission d'une zone de la mémoire dans l'espace d'adressage virtuel d'un processus étranger Tentative de connexion à un fournisseur de services spécifique Création de contenu dans le répertoire système de Windows Manipulation à l'aide de contenu actif dans le répertoire temporaire Administrateur Obtention et utilisation de l'icône d'une application système légitime Création de contenu exécutable dans le répertoire Windows Exécution de contenu actif depuis le dossier système Windows Configuration d'une fonction de rappel afin de contrôler les événements matériels du système et de l'ordinateur Téléchargement de données depuis un serveur web 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