DMARC доказателства за ISO 27001, NIS2, DORA и GDPR

Всичко започва с финансов директор, който препраща имейл до директора по информационна сигурност (CISO) в 07:42.

„Ние ли изпратихме това?“

Съобщението изглежда безупречно. Същото лого, същият футър, същият тон като на екипа по фактуриране. Твърди се, че банковите данни са променени. Показваното име на изпращача е правилно. Домейнът не е правописна имитация. Нападателят подправя реалния домейн.

Към 08:15 екипът по сигурността потвърждава неудобната истина: SPF съществува, но е твърде широк; DKIM е активиран само за основната платформа за електронна поща; няколко маркетингови инструмента изпращат неподписана поща; DMARC все още е в режим на мониторинг; и никой не може да открие последния преглед на MTA-STS политиката на домейна. Организацията има „сигурност на електронната поща“ в презентации, но доказателствата са разпръснати между DNS екранни снимки, портали на доставчици, стари тикети в Jira и електронна таблица, притежавана от човек, който е напуснал миналата година.

Към 10:30 правният отдел пита дали може да са засегнати лични данни на клиенти. Екипът по съответствие пита дали това е релевантно за докладване по NIS2. Клиент от сектора на финансовите услуги пита дали дружеството може да докаже контроли за ИКТ риск, съгласувани с DORA. Вътрешният одит пита как това се съпоставя с ISO/IEC 27001:2022. Управителният съвет задава по-прост въпрос: „Защо някой може да се представя за нас?“

Именно този въпрос е причината автентикацията на електронната поща през 2026 г. вече да не е тясна DNS тема. DMARC, SPF, DKIM, MTA-STS и TLS-RPT са контроли, които генерират доказателства. Те намаляват риска от фишинг и подправяне на домейни, но също така създават артефактите, които одиторите очакват: решения по политики, собственост, технически базови конфигурации, отчетност на доставчиците, журнали, записи от мониторинг, изключения, одобрения на промени и тригери за реагиране при инциденти.

Проблемът на съответствието не е „Имаме ли DMARC?“. Проблемът е „Можем ли да докажем, че автентикацията на електронната поща се управлява, наблюдава, преглежда и е свързана с риска?“

Пропускът в доказателствата, който одиторите постоянно откриват

Втори сценарий е също толкова често срещан. Външният одит е в ход в бързо растяща финтех компания. Одиторът преминава от непрекъснатост на дейността към управление на инциденти и пита CISO за компрометиране на служебна електронна поща.

CISO обяснява, че компанията има антифишинг филтри и тримесечно обучение за повишаване на осведомеността по информационна сигурност.

Одиторът кимва и след това пита за нещо по-конкретно: „Покажете ми управлението около DMARC, SPF и DKIM. Трябва да видя собственост, записи за промени, оценка на риска, доказателства от мониторинг и как това се свързва с киберхигиената по NIS2 и рамката за управление на ИКТ риска по DORA.“

В стаята настъпва тишина.

Техническият екип е внедрил DMARC преди месеци, но СУИС няма препратка към политика, няма централен пакет с доказателства, няма връзка с регистъра на рисковете и няма одобрена пътна карта за прилагане. Контролът може да съществува технически, но е невидим за управлението.

Това е пропускът в доказателствата.

Зряла програма за автентикация на електронната поща отговаря на шест одитни въпроса:

1. Кои домейни и поддомейни са в обхвата?
2. Кой притежава всеки домейн, DNS зона, пощенски поток и услуга за изпращане?
3. Кои системи имат право да изпращат от името на организацията?
4. Кои механизми за автентикация се прилагат, наблюдават и преглеждат?
5. Как се одобряват изключенията, приема се рискът и се закриват изключенията?
6. Какви доказателства удостоверяват, че контролът е функционирал във времето?

ISO/IEC 27001:2022 превръща това във въпрос на система за управление. Клаузи 4.1 до 4.4 изискват организацията да разбира контекста, изискванията на заинтересованите страни, границите на обхвата, интерфейсите и зависимостите. Автентикацията на електронната поща засяга всички тях. Регистраторът на домейни може да е доставчик. DNS може да е хостван в облачна инфраструктура. Вашите CRM, платформа за заплати, инструмент за фактуриране, доставчик на маркетингова автоматизация и система за клиентска поддръжка могат всички да изпращат електронна поща, използвайки вашия бранд.

Клаузи 5.1 до 5.3 превръщат това във въпрос на лидерство. Висшето ръководство трябва да възложи отговорности и да интегрира информационната сигурност в бизнес процесите. Решение за DMARC от p=none към p=quarantine или p=reject може да засегне комуникации с клиенти, финансови уведомления, въвеждане на служители от ЧР, кампании по продажби и външни доставчици.

Клаузи 6.1.1 до 6.1.3 изискват оценка на риска, третиране на риска, избор на контроли и Декларация за приложимост. Подправянето на домейн трябва да се третира като рисков сценарий, като SPF, DKIM, DMARC, MTA-STS и TLS-RPT се избират като част от третирането, когато е приложимо. След това клауза 8.1 изисква оперативно планиране и контрол, включително контрол върху процеси, продукти и услуги, предоставяни отвън и релевантни за СУИС.

Какво доказва всеки контрол за автентикация на електронната поща

SPF, DKIM, DMARC, MTA-STS и TLS-RPT работят заедно, но доказват различни неща.

SPF и DKIM са сигнали за идентичност и цялостност. DMARC е слоят на политиката, който превръща тези сигнали в действие от страна на получателя. MTA-STS и TLS-RPT подпомагат сигурния транспорт на електронна поща, като помагат за предотвратяване на рискове от downgrade атаки и неправилна конфигурация.

За одиторите по-дълбоката стойност е повторяемото доказателство. Агрегираните DMARC отчети показват кой изпраща като вашия домейн. TLS отчетите показват дали криптираната доставка се проваля. Заявките за промяна показват дали съществува управление. Записите за доставчици показват дали зависимостите във веригата на доставки са известни.

Първо включете домейните в регистъра на активите

Автентикацията на електронната поща не може да се управлява, ако домейните не се третират като активи.

SME Asset Management Policy-sme Политика за управление на активите - SME изрично включва домейни и идентичности, свързани с електронна поща, в обхвата:

„Цифрови удостоверителни данни и услуги: имена на домейни, цифрови сертификати, API ключове, имейл акаунти, облачни регистрации“

От раздел „Обхват“, клауза 2.2.4 на политиката.

За по-големи организации корпоративната Asset Management Policy Политика за управление на активите прилага същата логика:

„Логически активи: имена на домейни, лицензи, потребителски акаунти, базови конфигурации“

От раздел „Обхват“, клауза 2.2.5 на политиката.

Ако домейните са активи, те могат да имат собственици, оценки на критичност, цикли на преглед, зависимости от доставчици, контрол на промените и местоположения на доказателства. Ако са просто DNS записи, обикновено остават неуправлявани, докато нещо не се повреди.

Готовият за одит регистър на домейните и изпращането на електронна поща трябва да включва:

Този регистър подпомага ISO/IEC 27001:2022 Приложение A контрол A.5.9 Инвентар на информацията и други свързани активи, A.8.9 управление на конфигурацията, A.5.19 информационна сигурност във взаимоотношенията с доставчици и A.5.23 информационна сигурност при използване на облачни услуги. Той също така подпомага резултатите от инвентаризацията по NIST CSF 2.0 за активи, услуги, доставчици и критичност.

Използвайте управление на промените за решения по DNS и пощенски потоци

Автентикацията на електронната поща се нарушава, когато управлението на промените е слабо. Екип по продажби добавя платформа за изходящи кампании. ЧР приема инструмент за проследяване на кандидати. Финанси сменя софтуера за фактуриране. Маркетингът преминава към нов доставчик на имейл услуги. Всяко бизнес решение създава нов изпращач.

Корпоративната Change Management Policy Политика за управление на промените прави изискването за доказателства изрично:

„Всички заявки за промяна, прегледи, одобрения и подкрепящи доказателства трябва да бъдат записани в централизираната система за управление на промените.“

От раздел „Изисквания за внедряване на политиката“, клауза 6.1.1 на политиката.

Силната заявка за промяна при автентикация на електронна поща трябва да включва:

• Бизнес обосновка за новия изпращач.
• Засегнат домейн или поддомейн.
• Въздействие върху SPF include или IP адрес за изпращане.
• DKIM селектор и собственост върху ключа.
• Резултат от тест за DMARC подравняване.
• Въздействие върху MTA-STS или MX, ако има такова.
• Класификация на данните в изпращаните съобщения.
• Референция към прегледа на сигурността на доставчика.
• План за връщане към предходно състояние.
• Одобрение от собственика на домейна и екипа по сигурност.
• Доказателства от тестване след внедряване.
• Дата на преглед или срок на изтичане за временни настройки.

Това е разликата между „DNS администратор промени запис“ и „СУИС контролира промяна, релевантна за риска“.

Практичен 30-дневен план за доказателства за DMARC, SPF, DKIM и MTA-STS

CISO не се нуждае от шестмесечен трансформационен проект, за да подобри зрелостта на доказателствата. Фокусиран 30-дневен спринт може да създаде защитима базова конфигурация.

Седмица 1: Откриване на домейни, изпращачи и собственост

Експортирайте всички домейни от регистратора и DNS доставчика. Извлечете данни за пощенския поток от пощенския шлюз, CRM, системата за обслужване, маркетинговата платформа, системата за фактуриране и облачните услуги за уведомяване. Изградете регистъра на домейните и изпращачите.

Включете и паркирани домейни и защитни регистрации. Паркираните домейни често се игнорират, но все още могат да бъдат злоупотребени, ако DMARC липсва или е слаб.

Седмица 2: Коригиране на SPF и DKIM подравняването

Прегледайте SPF за прекомерно разрешителни механизми, остарели include записи, дублиращи се доставчици и рискове от лимити за справки. За DKIM идентифицирайте всеки изпращач, който не подписва поща или подписва с домейн, който няма да се подравни с DMARC.

Не одобрявайте SaaS изпращач само защото пощата работи. Одобрете го, защото:

• Доставчикът е вписан в регистъра на изпращачите.
• SPF и DKIM конфигурацията са документирани.
• DKIM селекторите са инвентаризирани.
• Собствеността върху ключовете и очакванията за преглед са ясни.
• Документацията по сигурността на доставчика подкрепя сигурното обработване на поща.
• Бизнес собственикът приема всяко временно изключение.

Тук NIS2 и DORA стават практически приложими. NIS2 Article 21 изисква подходящи и пропорционални технически, оперативни и организационни мерки, включително анализ на риска, обработване на инциденти, непрекъснатост на дейността, сигурност на веригата на доставки, сигурно придобиване и поддръжка, оценка на ефективността, киберхигиена, криптография, контрол на достъпа и сигурни комуникации. DORA Article 28 изисква финансовите субекти да управляват ИКТ риска от трети страни като част от рамката за управление на ИКТ риска, включително надлежна проверка, договорни очаквания, мониторинг и планиране при изход.

Ако маркетингов доставчик изпраща неавтентикирана електронна поща чрез вашия домейн, това не е само маркетингов проблем. Това е риск, свързан с доставчици, риск от имитация на бранда и потенциална вреда за клиентите.

Седмица 3: Преминаване на DMARC към прилагане

Режимът на мониторинг е полезен, но постоянен p=none без одобрена пътна карта е слабо доказателство.

Защитимият план за прилагане на DMARC трябва да включва:

• Преглед на базовите агрегирани отчети.
• Идентифициране на легитимни и нелегитимни източници.
• Отстраняване на проблемите при легитимни източници с неуспешна проверка.
• Бизнес валидиране на критични пощенски потоци.
• Постепенно увеличаване на политиката до pct=25, pct=50, pct=100.
• Преход от p=none към p=quarantine.
• Преход към p=reject, когато рискът и готовността на бизнеса позволяват.
• Отделна обработка за поддомейни чрез sp=.
• Регистър на изключенията с дати на изтичане.
• Одобрение от ръководството за остатъчния риск.

Това подпомага ISO/IEC 27001:2022 клауза 6.1.3 за третиране на риска и клауза 8.1 за оперативно планиране и контрол. Също така предоставя на вътрешния одит ясна следа: решение, внедряване, мониторинг, изключение, одобрение и преглед.

Седмица 4: Валидиране на MTA-STS, TLS-RPT и мониторинга

MTA-STS често се пропуска, защото не спира изходящото подправяне на бранда по същия начин като DMARC. Но той е много релевантен за сигурните комуникации и защитата на информацията при пренос. Той указва на съвместимите изпращащи сървъри, че пощата до вашия домейн трябва да се доставя през TLS, и валидира MX идентичността.

Корпоративната Cryptographic Controls Policy Политика за криптографски контроли задава ясна базова линия за сигурност на транспорта:

„Сигурност на транспорта: TLS 1.2 или по-висока версия (за предпочитане TLS 1.3)“

От раздел „Изисквания за внедряване на политиката“, клауза 6.1.1.5 на политиката.

За SME Cryptographic Controls Policy-sme Политика за криптографски контроли - SME изрично включва предаването по електронна поща:

„Данни, предавани чрез електронна поща, корпоративни VPN и уеб портали“

От раздел „Изисквания за внедряване на политиката“, клауза 6.1.1.4 на политиката.

Тестването трябва да включва MX TLS валидиране, наличност на файла с MTA-STS политиката, техническо състояние на HTTPS сертификата, преглед на TLS-RPT отчети и записи от триаж за откази.

Съпоставяне на автентикацията на електронната поща с ISO/IEC 27001:2022 Приложение A

Zenith Controls: The Cross-Compliance Guide на Clarysec Zenith Controls помага за свързване на техническите доказателства с одитните очаквания в различни рамки. Това не е отделен набор от контроли. Това е ръководство за съпоставяне и одит за контролите по ISO/IEC 27001:2022 и свързаните стандарти.

За ISO/IEC 27001:2022 Приложение A контрол A.5.14 Пренос на информация, Zenith Controls обяснява връзката с криптографията:

„Сигурният пренос на информация разчита на криптографски контроли, както е подробно описано в 8.24.“

Това е връзката между служебната електронна поща, DKIM, MTA-STS и TLS. Електронната поща е канал за пренос на информация. DKIM подпомага автентичността и целостта на съобщението. MTA-STS и TLS подпомагат защитата при пренос.

За Приложение A контрол A.8.24 Използване на криптография, Zenith Controls свързва криптографията с преноса на информация, поверителността, защитата на лично идентифицираща информация (PII), класификацията и управлението на уязвимостите. За Приложение A контроли A.8.15 Регистриране и A.8.16 Дейности по мониторинг ръководството свързва журналите и мониторинга с управлението на събития, събирането на доказателства, прегледа, анализа и възможността за одитиране.

SME Logging and Monitoring Policy-sme Политика за регистриране и мониторинг - SME посочва:

„Регистрирането трябва да бъде активирано и конфигурирано, когато е налично“

От раздел „Изисквания за управление“, клауза 5.5.1.1 на политиката.

Корпоративната Logging and Monitoring Policy Политика за регистриране и мониторинг включва:

„Външни комуникации и тригери от правила на защитната стена“

От раздел „Изисквания за внедряване на политиката“, клауза 6.1.1.6 на политиката.

За автентикацията на електронната поща външните комуникации трябва да включват събития от пощенския шлюз, обработване на агрегирани DMARC отчети, тенденции при DKIM откази, подозрителна инфраструктура на източника, TLS-RPT откази и опити за подправяне, които задействат триаж на инциденти.

Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint поставя това в практическо валидиране на контролите. Във фазата „Контроли в действие“, стъпка 20, той указва на екипите да валидират сигурността на мрежовите услуги:

„Избройте всички вътрешни и външни мрежови услуги (DNS, VPN, SMTP, DHCP, API шлюзове и др.).

✓ За всяка потвърдете, че използва сигурни протоколи (напр. DNSSEC, TLS 1.2+, SSH вместо Telnet).
✓ Прегледайте как се контролира достъпът до всяка услуга (напр. списъци с разрешени IP адреси, автентикация, сертификати).
✓ Ако се управлява от трети страни (напр. DNS, SD-WAN, хостван VPN), прегледайте клаузите за сигурност в SLA или договора с доставчика. Актуализирайте вашия регистър на услугите и отбележете къде се намират отговорностите по сигурността — вътрешни или външни.“

Приложено към електронната поща, това се превръща в работен план за DNS, SMTP, TLS, хоствани пощенски шлюзове, изпращачи доставчици и граници на отговорност.

Съпоставяне за множество режими на съответствие: един пакет с доказателства, много задължения

Същият пакет с доказателства може да подпомага ISO/IEC 27001:2022, NIS2, DORA, GDPR и NIST CSF 2.0, ако е структуриран правилно.

NIS2 е особено релевантна за съществени и важни субекти, както и за определени категории цифрова инфраструктура и цифрови доставчици. Article 20 превръща управлението на киберсигурността в отговорност на органа на управление, докато Article 21 установява базовия набор за управление на риска. Доказателствата за автентикация на електронната поща помагат да се покаже, че сигурните комуникации, взаимоотношенията с доставчици, обработването на инциденти, оценката на ефективността и киберхигиената са оперативни, а не теоретични.

За финансовите субекти DORA се прилага от 17 януари 2025 г. Articles 5 и 6 изискват отчетност на органа на управление и документирана рамка за управление на ИКТ риска. Article 17 изисква процеси за откриване, управление, записване, класифициране, ескалиране и отстраняване на инциденти, свързани с ИКТ. Article 28 превръща управлението на ИКТ риска от трети страни във формална отговорност. Доставчиците на електронна поща, маркетинговите платформи, системите за платежни уведомления и инструментите за комуникация с клиенти могат всички да станат част от тази верига на ИКТ зависимости.

За GDPR ключовият въпрос е дали електронната поща се използва за обработване на лични данни. Article 5 включва цялостност, поверителност и отчетност. Article 32 изисква подходящи технически и организационни мерки. Ако фактури, ЧР съобщения, уведомления за акаунти, билети за поддръжка или имейли при въвеждане съдържат лични данни, автентикацията на електронната поща и сигурността на транспорта стават част от доказателствата за сигурност на обработването.

Реагиране при инциденти: когато отчетите се превръщат в ранно предупреждение

Агрегираните DMARC отчети не са само доказателства за съответствие. Те са данни за ранно предупреждение. Рязък ръст на неуспешна автентикация от непозната инфраструктура може да показва активно подправяне, неразрешени ИТ услуги, неправилна конфигурация при доставчик или компрометиран изпращач.

Съгласно NIS2 Article 23 съществените и важните субекти трябва да уведомяват за значителни инциденти без неоправдано забавяне, като използват поетапно докладване, включващо ранно предупреждение, уведомление за инцидент и окончателен доклад. Не всеки опит за подправяне подлежи на докладване, но организацията трябва да може да оцени степента на сериозност, оперативното прекъсване, финансовата загуба, трансграничното въздействие и вредата за получателите.

Съгласно DORA Article 17 финансовите субекти трябва да дефинират и внедрят процес за управление на инциденти, свързани с ИКТ, да записват инциденти и значителни киберзаплахи, да идентифицират първопричини, да използват индикатори за ранно предупреждение, да класифицират по степен на сериозност и критичност на услугата, да възлагат роли, да дефинират комуникации и да ескалират значими инциденти. DORA Article 19 разглежда докладването на значими инциденти, свързани с ИКТ.

За GDPR въпросът е дали събитието е причинило случайно или незаконосъобразно унищожаване, загуба, промяна, неоторизирано разкриване на или достъп до лични данни. Подправен имейл, който подвежда клиенти да подадат лични данни на нападател, може да задейства оценка за нарушение на сигурността на личните данни, дори ако вътрешните системи не са компрометирани.

Корпоративната Audit and Compliance Monitoring Policy Политика за одит и мониторинг на съответствието обяснява защо дисциплинираните доказателства имат значение:

„Да се генерират защитими доказателства и одитна следа в подкрепа на регулаторни запитвания, съдебни производства или искания от клиенти за потвърждение на контролите.“

От раздел „Цели“, клауза 3.4 на политиката.

SME Audit and Compliance Monitoring Policy-sme Политика за одит и мониторинг на съответствието - SME добавя изискване за качество на доказателствата:

„Метаданните (напр. кой ги е събрал, кога и от коя система) трябва да бъдат документирани.“

От раздел „Изисквания за внедряване на политиката“, клауза 6.2.3 на политиката.

Следователно разследващият файл за DMARC трябва да документира източника на отчета, времето на събиране, анализатора, засегнатите домейни, предполагаемите IP адреси на изпращача, резултатите от автентикацията, оценката на въздействието върху бизнеса, взетите решения и одобрението за приключване.

Какво ще поискат одиторите

Различните одитори използват различен език, но доказателствата се припокриват.

Очаквайте практически въпроси:

• Покажете DMARC отчетите за последното тримесечие.
• Покажете как са били прегледани.
• Покажете изключението за този изпращач с неуспешна проверка.
• Покажете кой е одобрил тази SPF промяна.
• Покажете дали DKIM селекторите са инвентаризирани и преглеждани.
• Покажете как MTA-STS се тества след промени в пощенския шлюз.
• Покажете как събитията за подправяне влизат в триаж на инциденти.
• Покажете как изпращачи доставчици се премахват при прекратяване на договор.

Кратък контролен списък за вътрешен одит през 2026 г.

Използвайте този контролен списък като отправна точка за вътрешен одит, тестване на контролите или преглед на доказателствата за автентикация на електронната поща.

• Всички домейни и поддомейни са вписани в регистъра на активите.
• Паркираните и защитните домейни имат DMARC покритие.
• Всеки оторизиран изпращач има бизнес собственик и технически собственик.
• SPF записите се преглеждат за остарели include записи и прекомерен обхват.
• DKIM е активиран за легитимни изпращачи, когато се поддържа.
• DKIM селекторите са инвентаризирани и преглеждани.
• DMARC е внедрен за основните домейни и релевантните поддомейни.
• DMARC има пътна карта за прилагане, а не неопределен мониторинг.
• Агрегираните DMARC отчети се преглеждат по определена периодичност.
• MTA-STS е конфигуриран за домейни за входяща поща, когато е приложимо.
• TLS-RPT отчетите се събират и подлагат на триаж.
• Промените по автентикацията на електронната поща следват процеса за управление на промените.
• Въвеждането на доставчици включва изисквания за изпращане на електронна поща.
• Освобождаването на доставчици премахва SPF include записи, DKIM селектори и разрешения за изпращане.
• Изключенията имат собственици на риска, дати на изтичане и компенсиращи контроли.
• Пиковете на подправяне и неуспешната автентикация захранват реагирането при инциденти.
• Доказателствата включват метаданни, източник, дата, събиращо лице и система.
• Ръководството получава периодични показатели и актуализации за риска.

Zenith Blueprint, фаза „Управление на риска“, стъпка 14, препоръчва създаване на регулаторни таблици за съпоставяне за приложимите задължения:

„За всяка регулация, ако е приложимо, можете да създадете проста таблица за съпоставяне (може да бъде приложение към доклад), която изброява ключовите изисквания за сигурност на регулацията и съответните контроли/политики във вашата СУИС. Това не е задължително в ISO 27001, но е полезно вътрешно упражнение, за да се гарантира, че нищо не е пропуснато. То също прави добро впечатление на одитори/оценители, че не управлявате сигурността във вакуум, а сте наясно с правния контекст.“

За автентикацията на електронната поща тази таблица се превръща в мост между техническата DNS реалност и увереността на ниво управителен съвет.

Превърнете автентикацията на електронната поща в готови за одит доказателства

Вашите клиенти може никога да не попитат дали вашият SPF запис има перфектен синтаксис. Те ще попитат дали можете да защитите бранда си, да намалите риска от фишинг, да осигурите сигурни комуникации, да управлявате доставчици и да докажете, че контролите ви работят.

Clarysec помага на организациите да превърнат автентикацията на електронната поща от крехки технически настройки в готова за одит система от контроли. Практическата следваща стъпка е фокусиран преглед на доказателствата за автентикация на електронната поща:

1. Изградете регистъра на домейните и изпращачите.
2. Съпоставете статуса на SPF, DKIM, DMARC, MTA-STS и TLS-RPT.
3. Идентифицирайте доставчици, неразрешени изпращачи и изключения.
4. Създайте пътна карта за прилагане на DMARC.
5. Валидирайте доказателствата за управление на промените, регистриране и реагиране при инциденти.
6. Свържете доказателствата с ISO/IEC 27001:2022, NIS2, DORA, GDPR и NIST CSF 2.0.
7. Подгответе пакет с доказателства, готов за одитор, като използвате Zenith Blueprint, Zenith Controls и релевантните политики на Clarysec.

Ако вашата организация се подготвя за сертификация по ISO/IEC 27001:2022, готовност за NIS2, увереност по DORA, прегледи на отчетността по GDPR или клиентски въпросници за сигурност, започнете с контролите, които нападателите злоупотребяват най-видимо: вашите домейни, вашите изпращачи и вашата верига на доверие в електронната поща.

Изтеглете Zenith Blueprint, използвайте Zenith Controls за съпоставяне на изискванията за съответствие и проведете 30-дневен преглед на доказателствата за автентикация на електронната поща, преди следващият инцидент с подправяне или одитно искане да наложи този разговор.