Les pratiques recommandées guident pour l'Anti-mystification

Au sujet de ce document

Ce document est pour les clients de Cisco, les partenaires de distribution de Cisco et les ingénieurs de Cisco qui déploieront la sécurité du courrier électronique de Cisco. Ce document couvre :

• Quelle est mystification d'email ?
• Processus de la défense de mystification d'email
• Ce qui plus que vous pouvez faire avec la prévention de mystification ?

Quelle est mystification d'email ?

La mystification d'email est contrefaçon d'en-tête d'email où le message semble avoir provenu de quelqu'un ou quelque part autre que la source réelle. La mystification d'email est une tactique utilisée dans le phishing et des campagnes de Spam parce que les gens sont pour ouvrir un email quand ils le pensent a été envoyées par une source légitime et digne de confiance. Pour plus d'informations sur la mystification, référez-vous s'il vous plaît à http://blogs.cisco.com/security/what-is-email-spoofing-and-how-to-detect-it

La mystification d'email se range dans les catégories suivantes :

Catégorie	Description	Cible principale
Mystification directe de domaine	Personnifiez un domaine identique dans la « enveloppe de » comme domaine du destinataire.	Employés
Duperie de nom d'affichage	«  » De l'en-tête affiche un expéditeur légitime avec un nom exécutif d'une organisation. Également connu en tant que compromission d'email d'affaires (BEC).	Employés
Personnification de marque	«  » De l'en-tête affiche un expéditeur légitime avec la marque d'une organisation réputée.	Clients/Partenaires
Attaque basée par URL de Phish	Un email avec un URL qui tente de dérober des données sensibles et/ou l'information de connexion de la victime. Un faux email d'une banque te demandant de cliquer sur un lien et de vérifier vos détails de compte est un exemple d'attaque basée par URL de phishing.	Employés/Partenaires
Cousin ou attaque identique de domaine	La « enveloppe » ou «  » de la valeur d'en-tête affiche qu'une adresse semblable d'expéditeur qui personnifie vrai, sautait des inspections SPF, DKIM et DMARC.	Employés/Partenaires
La reprise de compte/a compromis le compte	Gagnez l'accès non autorisé à un vrai compte de messagerie qui appartient à quelqu'un et puis envoie des emails à d'autres victimes en tant que propriétaire légitime de compte de messagerie.	Chacun

La première catégorie associe aux abus du nom de domaine du propriétaire dans la « enveloppe » de la valeur dans l'en-tête d'Internet d'un email. La sécurité du courrier électronique de Cisco peut remediate cette attaque à l'aide de la vérification de DN d'expéditeur permettre seulement les expéditeurs légitimes et le même résultat peut être réalisé globalement à l'aide de la vérification DMARC, DKIM et SPF.

Cependant, les autres catégories ne violent pas entièrement la partie de domaine de l'adresse e-mail de l'expéditeur, par conséquent il n'est pas facile d'être découragé à l'aide des DN textotent des enregistrements ou la vérification d'expéditeur seulement. Dans le meilleur des cas, il serait le meilleur de combiner quelques caractéristiques de sécurité du courrier électronique de Cisco avec la protection de phishing avancée par Cisco basée parcase (APP) pour lutter contre de telles menaces avancées. Veuillez noter que l'application des caractéristiques de sécurité du courrier électronique de Cisco peut varier d'une organisation à l'autre et l'application inexacte peut mener à une incidence élevée des faux positifs, par conséquent il est important de comprendre les besoins des affaires de l'organisation et de travailler les caractéristiques en conséquence.

Processus de la défense de mystification d'email

Les fonctionnalités de sécurité qui adressent les pratiques recommandées pour surveiller, avertissent et imposent contre des attaques de détournement de trafic sont affichées dans le diagramme ci-dessous (le schéma 1). Les détails de chaque caractéristique seront fournis dans ce document. La pratique recommandée est une approche en profondeur de la défense pour détecter la mystification d'email. Maintenez toujours dans l'esprit que les attaquants changeront leurs méthodes contre une organisation au fil du temps, ainsi il est très important que un administrateur de surveiller toutes les modifications de occurrence et continue avec des avertissements et l'application appropriés.

La sécurité du courrier électronique de Cisco du schéma 1. charrient le pipeline de la défense

Couche 1 : Contrôle de validité sur le domaine de l'expéditeur

La vérification d'expéditeur est une manière plus simple d'empêcher l'email envoyé d'un domaine factice d'email, tel que la mystification de domaine de cousin (par exemple 'c1sc0.com est l'imposter de « cisco.com "). La sécurité du courrier électronique de Cisco fait une requête de MX Record pour le domaine de l'adresse e-mail de l'expéditeur et exécute une consultation d'enregistrement A sur le MX Record pendant la conversation de SMTP. Si la requête DNS renvoie NXDOMAIN, elle traitera le domaine comme non-existence. C'est une technique commune pour que les attaquants modifient les informations d'expéditeur d'enveloppe ainsi l'email d'un expéditeur invérifié est reçu et traité plus loin. Utilisant cette caractéristique, tous les messages entrant qui échouent le contrôle de vérification seront rejetés par sécurité du courrier électronique de Cisco à moins que le domaine ou l'adresse IP de l'expéditeur pré-soit ajouté dans le « Tableau d'exception ».

Pratique recommandée : Configurez la sécurité du courrier électronique de Cisco pour rejeter la conversation de SMTP si le domaine d'email du gisement d'expéditeur d'enveloppe est non valide et pour permettre seulement les expéditeurs légitimes en configurant la stratégie de flux de courrier, la vérification d'expéditeur et la table d'exception (facultatives). Le pour en savoir plus, visitent s'il vous plaît : https://www.cisco.com/c/en/us/support/docs/security/email-security-appliance/200057-Spoof-Protection-using-Sender-Verificati.html

Section de vérification d'expéditeur du schéma 2. dans la stratégie par défaut de flux de courrier.

Couche 2 : Vérifiez «  » de l'en-tête utilisant DMARC

La vérification DMARC est beaucoup de fonctionnalité puissante à lutter contre « mystification directe de domaine » et inclut également « nom d'affichage » et attaques « de personnification de marque ». Liens DMARC dans les informations authentifiées avec la SPF ou le DKIM (envoyant la source de domaine, ou la signature) avec ce qui est présenté au fin-destinataire dans «  » de l'en-tête et établit que des identifiants SPF et/ou DKIM sont alignés avec de l'identifiant d'en-tête.

Pour passer la vérification DMARC, un email entrant doit passer au moins un de ces mécanismes d'authentification. La sécurité du courrier électronique de Cisco permet également à l'administrateur pour définir un profil de vérification DMARC pour ignorer les stratégies DMARC du propriétaire de domaine et envoyer l'agrégat (RUA) et la panne/légal (RUF) fait rapport aux propriétaires de domaine qui aide à renforcer leurs déploiements d'authentification en échange.

Pratique recommandée : Éditez le profil du par défaut DMARC qui est conforme aux actions de stratégie DMARC qui sont informées par l'expéditeur. Supplémentaire, les paramètres généraux de la vérification DMARC doivent être édités pour activer la génération du rapport correcte. Une fois que le profil est configuré convenablement, le service de vérification DMARC doit être activé dans la stratégie par défaut des stratégies de flux de courrier.

Profil de vérification du schéma 3. DMARC

Remarque: DMARC doit être mis en application par le propriétaire du domaine de envoi en même temps qu'un outil de surveillance de domaine, tel que la protection de domaine de Cisco. Une fois mise en application convenablement, l'application DMARC dans des aides de sécurité du courrier électronique de Cisco se protègent contre l'email de phishing envoyé aux employés des expéditeurs ou des domaines non autorisés. Pour plus d'informations sur la protection de domaine de Cisco, visitez s'il vous plaît ce lien : https://www.cisco.com/c/dam/en/us/products/collateral/security/cloud-email-security/at-a-glance-c45-740937.pdf

Couche 3 : Empêchez les spammers d'envoyer les emails charriés

Les attaques de détournement de trafic peuvent être une autre forme commune d'une campagne de Spam, par conséquent l'activation de la protection d'anti-Spam est encore essentielle pour identifier efficacement les emails frauduleux qui contiennent des éléments de Spam/phishing et les bloquent franchement. L'utilisation de l'engine de courrier indésirable, une fois ajoutée à d'autres actions de pratique recommandée, complètement décrites dans ce document, fournissent les meilleurs résultats sans perte d'emails légitimes.

Pratique recommandée : La lecture d'anti-Spam d'enable dans la stratégie par défaut de messagerie et le positionnement mettent en quarantaine l'action aux configurations franchement identifiées de Spam. Augmentez la taille minimum de lecture pour le message spam au moins à 2M dans le paramètre général.

Configuration d'anti-Spam du schéma 4. dans la stratégie par défaut de messagerie

Le seuil de Spam peut être ajusté pour que le positif et le Spam suspecté augmente ou pour diminue la sensibilité (le schéma 5) ; cependant, Cisco décourage l'administrateur pour faire ainsi, et utilise seulement les seuils par défaut comme spécification de base, à moins qu'étant indiqué autrement par Cisco.

Schéma 5. seuils d'anti-Spam plaçant dans la stratégie par défaut de messagerie

Comme note marginal, la sécurité du courrier électronique de Cisco offre l'engine intelligente ajoutée du Multi-balayage (IMS) qui fournit la combinaison différente de l'engine d'anti-Spam en faveur d'augmenter les taux de capture de Spam (la plupart de crochet-débit agressif).

Couche 4 : Déterminez les expéditeurs malveillants par l'intermédiaire du domaine d'email

Utilisant l'IP basé la détection de réputation (SBRS) à lutter contre des attaques de détournement de trafic n'est plus due suffisant à plusieurs raisons en particulier avec le fait que la même source des adresses IP peut être utilisée pour héberger le multiple envoyant des domaines, dans ce cas, la nature de chaque domaine peut être différente, par conséquent rendant SBRS moins efficace d'empêcher les messages infectés malveillants et charriant des campagnes. La réputation de domaine d'expéditeur (SDR) est livré dans pratique d'aborder de tels soucis.

Avec la conservation de la réputation IP filtrant à la couche de connexion de SMTP, le verdict de réputation basé sur l'information de domaines de envoi présentée dans la conversation de SMTP et les en-têtes de message sera pris en compte pour déterminer si on permet l'email par la stratégie de messagerie entrante ou pas. Le SDR est au dessus en termes d'empêcher efficacement charriant des campagnes des sources malveillantes ou d'un domaine qui a été récemment enregistré, moins qu'une semaine, par exemple, dans une tentative claire de se montrer plus malin que la caractéristique de lecture de réputation.

Pratique recommandée : Créez un filtre satisfait entrant qui capture le domaine de envoi dans lequel le verdict de réputation de SDR tombe sous ou terrible/pauvre/corrompue ou l'âge de domaine est moins qu'ou égale à 5 jours. L'action recommandée est de mettre en quarantaine le message et d'envoyer une notification à l'administrateur de sécurité du courrier électronique et au destinataire d'origine. Pour plus d'informations sur la façon configurer le SDR, visualisez s'il vous plaît le vidéo de Cisco chez https://www.youtube.com/watch?v=IBLRQMT3SHU

Le filtre satisfait du schéma 6. pour la réputation de SDR et le domaine vieillissent avec informent et mettent en quarantaine des actions.

Couche 5 : Réduisez les faux positifs avec des résultats de vérification SPF ou DKIM

Il est impératif d'imposer la vérification SPF ou DKIM (chacun des deux ou l'un ou l'autre une) quant aux multi-couches de construction de charrient la détection d'email pour la plupart des types d'attaque. Au lieu de prendre une mesure finale (telle que la baisse ou la quarantaine), Cisco recommande ajouter une nouvelle en-tête comme [X-SPF-DKIM] sur le message qui échoue vérification SPF ou DKIM et coopère les résultats avec la configuration modifiée de détection d'email (ALIMENTÉE) que nous couvrirons plus tard, en faveur d'un taux de capture amélioré de mystification envoie.

Pratique recommandée : Créez un filtre satisfait qui les résultats examine SPF ou DKIM vérification de chaque message entrant qui ont traversé des inspections précédentes. Ajoutez une nouvelle X-en-tête (par exemple X-SPF-DKIM=Fail) sur le message qui échoue la vérification SPF ou DKIM et livre à la prochaine couche de lecture – détection modifiée d'email (ALIMENTÉE).

Filtre satisfait du schéma 7. qui examine des messages avec des résultats défectueux SPF ou DKIM

Couche 6 : Détectez les messages avec le nom probablement modifié d'expéditeur

Complétant avec des vérifications SPF, DKIM et DMARC, la détection modifiée d'email (ALIMENTÉE) est une autre importante ligne de défense contre la mystification d'email. FED est idéale aux attaques de détournement de trafic de remediate qui maltraitent «  » de la valeur au corps du message. Étant donné que vous connaissez déjà les noms exécutifs dans l'organisation, vous pouvez créer un dictionnaire de ces noms et puis mettre en référence ce dictionnaire avec l'état ALIMENTÉ dans des filtres satisfaits. Indépendamment des noms exécutifs, vous pouvez également créer un dictionnaire des domaines de cousin ou des domaines identiques, basé sur votre propre domaine à l'aide de DNSTWIST (https://github.com/elceef/dnstwist) à apparier contre la mystification identique de domaine.

Pratique recommandée : Identifiez les utilisateurs dans votre organisation dont les messages sont susceptibles d'être modifiés. Créez un dictionnaire fait sur commande qui explique des cadres. Pour chaque nom exécutif, le dictionnaire doit inclure le nom d'utilisateur et tous noms d'utilisateur possibles comme termes (le schéma 8). Quand le dictionnaire est complet, l'utilisation a modifié la détection d'email (ALIMENTÉE) dans le filtre satisfait pour apparier sur «  » de la valeur des messages entrant avec le ce des entrées dictionnaire.

Répertoire fait sur commande du schéma 8. pour la détection modifiée d'email

C'est une action facultative d'ajouter une condition d'exception pour votre domaine d'email dans le « expéditeur d'enveloppe » pour sauter l'inspection ALIMENTÉE. Alternativement, une « liste d'adresses » faite sur commande peut être créée pour sauter l'inspection ALIMENTÉE à une liste d'adresses e-mail qui sont affichées dans «  » de l'en-tête (le schéma 9).

Le schéma 9. créent la liste d'adresses pour sauter l'inspection ALIMENTÉE

Appliquez l'action de propriété industrielle modifiée de détection d'email (ALIMENTÉE) d'éliminer «  » de la valeur et de passer en revue l'adresse e-mail réelle d'expéditeur d'enveloppe dans la boîte de réception de message. Plutôt qu'en appliquant une mesure finale, ajoutez une nouvelle X-en-tête (exemple : X-FED=Match) sur le message qui a apparié la condition et continue de fournir le message à la prochaine couche d'inspection (le schéma 10).

Paramètre de filtre satisfait recommandé du schéma 10. pour ALIMENTÉ

Couche 7 : Email franchement identifié de mystification

Il est plus efficace d'identifier une vraie campagne de mystification en mettant en référence d'autres verdicts de diverses fonctionnalités de sécurité dans le pipeline, tel que les informations de X-en-tête qui sont produites par la « application SPF DKIM » et « ALIMENTÉES ». Les administrateurs peuvent créer un filtre satisfait pour identifier des messages ajoutés avec des résultats de vérification défectueuse due SPF/DKIM de les deux nouvelles X-en-têtes (X-SPF-DKIM=Fail) et que «  » de l'en-tête apparie les entrées dictionnaire ALIMENTÉES (X-FED=Match).

L'action recommandée peut être, mettre en quarantaine le message et informer le destinataire ou continuer de fournir le message d'origine mais d'ajouter [POSSIBLE MODIFIÉ] des mots au début « pour soumettre » la ligne comme avertissement au destinataire comme représenté ci-dessous (figure 11).

Cartel du schéma 11. toutes les X-en-têtes dans une règle simple (de finale)

Couche 8 : Protection contre le phishing URLs

La protection contre des liens URL de phishing sont incorporées à l'URL et à l'épidémie filtrant dans la sécurité du courrier électronique de Cisco. Les menaces mélangées combinent des messages de mystification et de phishing afin d'essayer de regarder plus légitimes à la cible, par conséquent l'activation du filtrage d'épidémie est essentielle d'aider à détecter, analyser et lever de telles menaces sur une base en temps réel. Il vaut de savoir que la réputation URL est évaluée à l'intérieur de l'engine d'anti-Spam et sera utilisée en tant qu'élément de la décision pour la détection de Spam. Si l'engine d'anti-Spam n'arrête pas le message avec l'URL comme Spam, elle sera évaluée par l'URL et l'épidémie filtrant dans la dernière pièce du pipeline de Sécurité.

Recommandation : Créez une règle de filtrage satisfaite qui bloque l'URL avec un score « malveillant » de réputation et réoriente l'URL avec un score « neutre » de réputation au proxy de sécurité Cisco (figure 12). Activez les filtres d'épidémie de menace en activant la modification de message. L'url rewrite tient compte pour que les URL méfiants soient analysés par proxy de sécurité Cisco (figure 13). Le pour en savoir plus, visitent s'il vous plaît : https://www.cisco.com/c/en/us/support/docs/security/email-security-appliance/118775-technote-esa-00.html

Figure 12. Filtre satisfait pour des réputations URL

Figure 13. Url rewrite d'enable dans le filtrage d'épidémie

Couche 9 : Augmentez la capacité de détection de mystification avec Cisco a avancé la protection de phishing (l'APP)

Cisco offre la protection avancée de phishing (APP) qui intègre l'apprentissage automatique, combinant l'identité locale et les relations modelant avec l'analytics de comportement, pour se protéger mieux contre des menaces basées sur duperie d'identité. L'APP permet également à l'administrateur pour enlever les emails malveillants des boîtes de réception des utilisateurs pour empêcher la fraude de fil ou d'autres attaques avancées ; et fournit la visibilité détaillée dans l'activité d'attaque d'email, y compris les messages totaux sécurisés et les attaques empêchées. Pour plus de détails, visitez s'il vous plaît les liens suivants : https://www.cisco.com/c/dam/en/us/products/collateral/security/cloud-email-security/at-a-glance-c45-740894.pdf

Recommandation : L'APP de Cisco est une solution de sortie de la boîte dans le nuage. Les administrateurs exécutent l'email inscrivant sur le serveur de mail tel que l'échange et le bureau 365 afin de retenir les informations d'en-tête de tous les messages entrant dans l'APP de Cisco pour l'analyse approfondie sans n'importe quelle intervention de programmation humaine. Les administrateurs passent en revue les classes d'attaque que l'APP de Cisco a identifiées (figure 14) et configurent les stratégies qui incluent la capacité d'alerter l'administrateur, supprimer le message ou mettre en quarantaine le message à un dossier alternatif basé sur l'attaque tape (figure 15).

Figure 14. L'APP de Cisco remplissent automatiquement classes d'attaque sur le tableau de bord principal

Figure 15. Le paramètre de la stratégie dans l'APP de Cisco qui automatise l'action if le message apparie le type sélectionné d'attaque.

Ce qui plus que vous pouvez faire avec la prévention de mystification ?

Beaucoup charrie peuvent remediated en exerçant quelques précautions simples, y compris notamment :

• Limitez l'utilisation des domaines whitelisted dans le Tableau d'accès au hôte (CHAPEAU) à l'très peu de principaux partenaires commerciaux
• Membres toujours de piste et de mise à jour dans le groupe d'expéditeur SPOOF_ALLOW, si vous avez créé un en suivant les instructions données dans le lien de pratiques recommandées.
• Activez la détection de graymail et placez-les dans la quarantaine de Spam aussi bien

Mais le plus important de tous, de la SPF d'enable, du DKIM, et du DMARC et implémentez-les convenablement. Cependant, les conseils de la façon éditer des enregistrements SPF, DKIM et DMARC sont hors de portée de ce document. Pour cela, référez-vous s'il vous plaît au livre blanc suivant : https://www.cisco.com/c/dam/en/us/products/collateral/security/esa-spf-dkim-dmarc.pdf

Nous comprenons également le défi des attaques remediating d'email telles que les campagnes de mystification discutées ici. Si vous avez des questions au sujet de mettre en application ces pratiques recommandées, entrez en contact avec s'il vous plaît le support technique de Cisco en ouvrant un cas. Atteignez alternativement, s'il vous plaît à votre équipe de compte Cisco pour une solution et des conseils de conception. Pour plus d'informations sur la sécurité du courrier électronique de Cisco, allez s'il vous plaît à http://www.cisco.com/c/en/us/products/security/emailsecurity/index.html