Ръководство за откриване на измамни имейли с използване на AI агенти: пълен анализ на избор и разполагане за предприятия през 2026 г.
От SPF/DKIM/DMARC до анализ на семантиката с използване на големи модели, дълбок анализ на това как се落ява AI базираните двигатели за борба с измамата в реална заплаха
Daniel Nikulshyn
Editor
Панорама на заплахите
Защо фишингът все още е номер едно атакуващ вектор през 2026 г.
Въпреки че индустрията за сигурност на електронната поща е развита повече от двадесет години, фишингът все още е основния вход за изтичане на данни в предприятията. Согласно годишните издания на Verizon на „Изследване на изтичането на данни“ (DBIR), социалното инженерство и кражбата на данни заемат постоянно висока позиция в списъка с изтичания, а електронната поща е най-честият канал за доставяне на такива атаки. Уикипедия дава определение на фишингът, като посочва, че сърцевината му е атакуването на доверени лица, което кара жертвата да предаде данни, да преведе пари или да инсталира зловреден софтуер. От 2022 г. насам разпространението на генеративен AI е съществено намалило разходите за създаване на фишинг съдържание. Предишните правила за фишинг писма, основани на правописни грешки и примитивна граматика, губят своето значение – големите езикови модели могат да генерират текст със съвършена граматика и тънък език, съответстващ на културата на компаниите, и дори могат да прилагат съдържание в зависимост от публично достъпните социални профили на целта, което се нарича фишинг тип „списък“ (spear phishing) и 商业ен електронен компромис (BEC, Business Email Compromise). BEC е особено тревожен. ФБР-центърът за жалби за интернет-prestiж (IC3) години наред включва този тип атаки в годишните си отчети като един от най-големите онлайн престъпления, причиняващи икономически щети, и тези атаки често не съдържат нито един зловреден линк или препратка, а просто полагат sociale инженерство, за да манипулират финансови служители и да преведат пари, което прави традиционните средства за откриване, базирани на подписи и черни списъци с URL, напълно неефективни. Точно този „безопасен“ тип атака насърчава агентите за откриване, базирани на изкуствен интелект за семантично разбиране, да заемат място напред. Те вече не гледат само линкове и препратки, а анализират интент, аномалии в отношенията и езикови модели, което представлява технологичния ядро на този наръчник.
- Phishing - Уикипедия — Уикипедия за дефиниция, видове и история на фишинг атаките
- Годишен отчет на ФБР IC3 — Годишни отчети на ФБР-центъра за жалби за интернет-prestiж за статистика на щетите от BEC
Техническа основа
Сертификатите за протоколи са основа, но далеч не са краят
Всяка сериозна схема за откриване на измамни електронни писма се основава на три основни протокола за сертификация на електронна поща: SPF, DKIM и DMARC. SPF (Sender Policy Framework) посочва чрез DNS записите, кои сървъри имат право да представляват дадено име на домейн при изпращане на електронна поща; DKIM (DomainKeys Identified Mail) използва криптографски подписи за да потвърди, че електронната поща не е била изменяна по време на предаването; DMARC (Domain-based Message Authentication, Reporting and Conformance) регулира стратегията при провал на аутентикация (none/quarantine/reject) и предоставя агрегирани отчети. Статията в Уикипедия за DMARC обяснява, че неговото основно принос е "съвпадение" (alignment) – гарантиране, че имената на домейн, които се използват за проверка на SPF/DKIM, съвпадат с тези, които потребителят вижда в заглавието "От", за да се предотвратят измамни действия с имена на домейни. Google и Yahoo започнаха да изискват DMARC от големи изпращачи през 2024 г., което значително ограничи пространството за пряко измамно използване на имена на домейни. Въпреки това, тези протоколи могат да решат само въпроса "Кой има право да изпраща електронна поща от това име на домейн?". Те са некомпетентни при две категории високорискови атаки: първо, когато нападателят регистрира име на домейн, което е много близко до целевото (например, използва "rn", за да се престори на "m"), което позволява на електронната поща да мине през DMARC аутентикация; второ, когато нападателят взема контрол над легитимен имейл на партньор и стартира атаката, при което всички проверки преминават успешно. Това е точката, на която се включват агентите за откриване чрез изкуствен интелект. Те използват резултатите от аутентикацията като един от многото характеристики, а не като единствено основание за решение, и добавят още профили на изпращачите, анализ на семантичните намерения и графични отношения, за да покрият слепите точки на протоколите за аутентикация. Разбирането на това разделение е предпосылка за оценка на доставчици без да бъдат подвеждани от фрази като "Ние поддържаме DMARC".
- DMARC - Уикипедия — Работата на протокола DMARC, механизмът на съвпадение и типовете стратегии
- DKIM - Уикипедия — Технически детайли за криптографските подписи за проверка на DKIM
Вътрешен двигател
Разбор на основните технологии за детектиране на измамни електронни писма с помощта на ИИ
Современите ИИ агенти за детектиране на измамни електронни писма обикновено се състоят от четири слоя способности. Първият слой е традиционното детектиране с определени свойства: база данни за репутацията на URL, песочница за атаки с приложения, сравняване на хешови стойности - тази част от технологията е вече узряла и се използва основно за блокиране на известни заплахи. Вторият слой е статистическите и машинните обучения с извличане на стотици сигнали, като например продължителността на регистрацията на домейна на изпращача, първите сигнали за комуникация, несъответствия между адреса на изпращача и адреса на отговора, скрити юникод знаци с еднакъв вид и т.н. Третият слой е ключовото нововъведение през последните години: обработка на естествен език и анализ на семантичните намерения, задвижвани от големи езикови модели. Двигателът вече не само задава въпроса 'Дали този линк е безопасен?', а задава въпроса 'Какво това електронно писмо се опитва да направи?'. Той може да разпознае принудителните действия ('моля, изпълнете превода в рамките на 30 минути'), фалшивите идентичности (представяне като главен изпълнителен директор), както и аномалиите в структурата на речта. API интерфейсите на големите модели на OpenAI, Anthropic и други доставчици значително повишават точността на семантичните анализи, но също така довеждат до нови компромиси по отношение на разходи, забавяния и поверителност. Четвъртият слой е графичните бази данни и базовите линии на поведението. Агентът, чрез анализиране на историческата комуникация в рамките на организацията и извън нея, създава 'нормален профил на поведението' за всеки електронен адрес на изпращач: обикновено по което време изпраща съобщения, какво устройство използва, с кого общува и използвания език. Когато едно електронно писмо се отклонява от тази базова линия (например, главният финансов директор внезапно изисква спешен превод от неизвестен IP адрес през нощта), системата дава висок риск оценка. Този метод, базиран на откриване на аномалии, е особено ефективен срещу атаки от тип BEC, тъй като не зависи от известни подписи. При оценката доставчиците трябва да задават въпроси: дали семантичният анализ е правилна схема или истинско моделиране? колко дълъг е периодът на обучение за базовите линии на поведението? как се отчитат грешните сигнали и се включват в модела? Отговорите на тези въпроси разкриват истинския потенциал на продукта много по-добре, отколкото просто фразата 'ние използваме ИИ'.
- Документация на платформата OpenAI — Официална документация за големите моделни API използвани за анализ на семантични намерения
- Anti-phishing software - Wikipedia — Техническа класификация и обзор на методите за детектиране на измамни електронни писма
Архитектурно решение
Гейтово ниво срещу ниво API: двата варианта при деплойMENT на архитектури
При избора на решения фундаменталното архитектурно разделение се отнася до мястото, където се намира точката на детекция. Традиционната сигурна електронна поща (SEG, Secure Email Gateway) е депозирана в началото на потока от електронна поща и чрез промяна на записите MX пренасочва цялата входяща поща към службата за детекция, преди тя да бъде доставена до пощенската кутия. Този подход е напълно ефективен и не зависи от платформените API на пощенските кутии, но недостатъкът му е, че не позволява да се видят последващи промени в вече доставената поща (като закъсняли активирани линкове) и е трудно да се направи анализ на вътрешните фишингови атаки. В последните години е популярно деплойMENT на ниво API (обикновено наричано ICES, Integrated Cloud Email Security). Той директно чете съдържанието на пощенската кутия чрез Microsoft Graph или Google Workspace API и след това прави_inline или последващ сканиране. Предимството му е, че деплойMENT отнема само няколко минути, не е нужно да се променят записите MX и позволява да се види вътрешния поток на електронната поща и да се поддържа автоматичното оттегляне (Claw-Back) на доставената поща. Defender for Office 365 на Microsoft и родната сигурност на Google Workspace също следват тази идея. Двата архитектурни варианта не се изключват взаимно. Многобройни организации използват 'гейтово ниво за предварителна проверка + ниво API за детайлна проверка' във vertikalen модел на отбраната. Специалистите по сигурност трябва да вземат предвид следното: схемите на ниво гейтово ниво са по-добре контролирани в случаите, чувствителни към забавяне, но поддържането им е по-тежко; схемите на ниво API са лесни за деплойMENT, имат по-голяма видимост, но са ограничени от скоростта и разрешенията на платформените API и следващото оттегляне на пощата означава, че злонамерената поща е била кратковременно в пощенска кутия на потребителя. Често пренебрегваният момент при оценката е връзка с данните и конфиденциалността. Схемите на ниво API изискват разрешение за чтение на пълното съдържание на електронната поща от страна на трети лица, което за предприятията, които се подчиняват на изискванията на GDPR или индустриалния регламент, е важно решение. Служителят по сигурност трябва да потвърди местоположението, където се обработват данните, сроковете за съхранение и дали съдържанието на електронната поща се използва за обучение на общите модели.
- Microsoft Defender for Office 365 — Официална документация на Microsoft за защита срещу заплахи чрез електронна поща
- Email filtering - Wikipedia — Технически фон на филтрирането на електронна поща и сигурността на електронната поща
Методология за селекция
Оценъчен каркас: Какво трябва да се тества и как
Практически всяка една доставчик на пазара декларира '99% и повече детекция', но този процент е безсмислен без тестови набори. Предлагам на сигурностните отбори да създават оценъчен каркас, съставен от четири квадранта: детекция, рискови разходи, опит на експлоатация и общ разходи. В размера на детекция не е wicht ключовият момент общата точност, а разделното поведение по видове: детекция на фишинг със зловредни линкове, детекция на зловреден софтуер в приложения, детекция на BEC с чист текст и детекция на вътрешен фишинг. Най-ценната практика е да се използват реални примери от историята (анонимизирани), а не демонстрационни примери, предоставени от доставчика. Освен това, е необходимо да се поискат минимум 30 дни на паралелен тест (режим на сянка), за да се оцени новия двигател, без да се повлияе производството, и след това да се сравнят реалните резултати. Рискът от грешна детекция е лесно подценен. Двигател с детекция от 0,1% изглежда добър, но при обработка на милиони имейли във фирмата това означава, че всеки ден стотици нормални имейли са грешно изолирани, което директно повлиява SOC и подрива доверието на потребителите към системата. По време на оценката трябва да се отбележат часовете за обработка на всяка грешна детекция и да се тества колко бързо се активизира обратната връзка на доставчика. Размерите на експлоатация и разходи включват: детайли на конфигурацията и четимост, интеграция с SIEM/SOAR, използваемост на интерфейса за разследване на инциденти и ценоваmodel (по имейл, по количество имейли или по позиции). Скритите разходи често се появяват при profesIONALни услуги, периоди на настройка и необходимост от допълнителни заплащания за информация за заплахи. Ако се включат всички тези показатели в процеса на решяване, можем да избегнем ситуацията, в която действителните TCO се оказват по-високи от разходите.
- Precision and recall - Wikipedia — Понятие за детекция и припомняне в детекционните системи
Игра на нападение и отбрана
Противник реалност: Когато атакуващите използват и AI
Детекцията на фишингови имейли е постоянна игра на нападение и отбрана. Атакуващите вече започват да използват методи за избягване на AI детекторите: влагане на скрити 'подсказки' (prompt injection) в имейлите, манипулиране на базирани на LLM аналитични двигатели; използване на изображения за превоз на текст, за да се избегне текстов сканиране; или използване на законни споделени линкове (Google Docs, SharePoint) като скокове, които да правят зловредното съдържание видимо едва след няколко скока. Статията в Уикипедия за противникова машинна ученост (adversarial machine learning) посочва, че всяка система за детекция, базирана на модели, е изложена на риск от измама от страна на умислени противникови примери. Това означава, че ако доставчикът се разчита единствено на един голем модел, той рискува да бъде атакуван. Стабилният подход трябва да включва множество двигатели, като нито един сигнал не може да бъде достатъчен за окончателна оценка. Друга реалност, която често се пренебрегва, е 'умората от детекция'. Когато системата често показва рискови уведомления, потребителите започват да ги игнорират. Затова отличните продукти правят рискови нива – само за имейли с високо ниво на риска се предлагат по-силни мерки, а за нисък риск – леки подсказки, които да концентрират вниманието на потребителите върху най-важните неща. Това е проблем на продуктовия дизайн, а не纯 технически проблем, но директно влияе на реалния ефект от защитата. Накрая, технологията не poate заменят човешката подготовка. Даже най-новите AI агенти трябва да се използват в комбинация с редовни фишингови симулации и обучения за осведоменост на служителите. Да се очаква от AI агентите да 'снизят броя на зловредните имейли, които достигат човешки очи, и да предоставят контекстни помощни средства', а не да 'елиминират всички фишинг', е реалистично очакване.
- Adversarial machine learning - Wikipedia — Противникова машинна ученост и нейният ефект върху детекционните системи
- Anthropic безопасностни изследвания — Изследвания за 'подсказки' и сигурност на моделите
Ръководство за внедряване
План за внедряване: 90-дневен план
На база на многократен опит от внедряване, препоръчвах да се раздели внедряването на AI агента за откривање на измамни електронни писма на три етапа от по 30 дни. Първите 30 дни са за базови линии и паралелен тестов режим: без промяна на съществуващите потоци от електронна поща, в режим на сянка се включва новия двигател, събира се оценката му на истинските електронни писма, и се сравнява със съществуващото състояние, правейки количествена оценка на новите открития и грешните сигнали. Едновременно се извършва проверка на SPF/DKIM/DMARC, за да се гарантира, че основата за удостоверяване е стабилна — много организации именно на този етап откриват, че DMARC все още е в състояние на p=none. Следващите 30 дни са за постепенно преминаване и оптимизиране на стратегията. Избира се един отдел с контролируем риск (обикновено финансовия или екипа на помощниците на висшето ръководство са групите с високо рисково поведение при бизнес електронна поща) и първи се включва задължителна блокада, наблюдавайки внимателно грешните сигнали и създавайки бързи канали за разрешаване. В този етап основният резултат е набор от стратегии и процедури за действие (playbook), които съответстват на реалността на организацията, и които уточняват на кои нива на сигнали системата трябва да предприема автоматично мерки, и кои изискват ръчно оценяване от SOC. Третите 30 дни са за пълно внедряване и оперативна консолидация. Детектори за откривање на измамни електронни писма се интегрират със SIEM/SOAR, за да се осигури автоматично връщане, автоматично изолиране и събитийни тикети; създава се нормален процес за обратна връзка при грешни сигнали, за да се гарантира, че всяко грешно блокирано електронно писмо бързо kunne да бъде върнато в модела; същевременно стартира първата симулация на измамни електронни писма, за да се провери реалният ефект от защита чрез взаимодействието между човек и машина. Не забравяйте да запазите план за възстановяване. Всички системи, които разчитат на трети страни API и модели, могат да бъдат повлияни от провала на доставчика, актуализация на модела или ограничения на скоростта и да се обезвредят за кратко, а предварително уговорен план за намаляване на риска (например автоматично връщане към консервативни определени правила) може да предотврати повреждането на цялата организация поради провала на доставчика, запишете тези неща в договорните клаузи за SLA, които са последната линия на защита за специалисти.
- Управление на сигурността на информацията и събития - Уикипедия — Фонов информации за интеграцията на SIEM/SOAR с системи за откривање на електронна поща
Ресурси
- Phishing - Уикипедия
Дефиниция, типове и история на развитие на измамните атаки
- DMARC - Уикипедия
Протокол за автентикация и предотвратяване на измамни имейли
- Microsoft Defender for Office 365 документация
Официална документация на продукта за защита на имейлите срещу заплахи от Microsoft
- OpenAI платформа документация
Официална информация за използване на големите модели API за анализ на семантичните намерения
- Anthropic изследователска страница
Често задавани въпроси
Можат ли AI агентите за откриване на измамни имейли да изместят напълно традиционните сигурни имейл портали?
Обикновено не могат да ги изместят напълно, а да ги допълват. API нивото на AI откриване се проявява по-добре в BEC и вътрешните хоризонтални измамни атаки, но порталите все още имат стойност при входящите груби филтри и контрол на забавяне. Основните зрелища прилагат дълбока защита, като използват и двата вида.
Какви са риските от съгласието при разполагане на решението на ниво API?
Основно се отнася до местоположението на данните, сроковете за съхранение и дали се използват за обучение на модели. Предприятията, които подлежат на GDPR или индустриални изисквания, трябва да потвърдят местоположението на обработка на данните от доставчика, да подпишат споразумение за защита на данните и да уточнят, че съдържанието на имейлите няма да се използва за обучение на общи модели.
Защо имаме измамни атаки, въпреки наличието на DMARC?
DMARC може само да предотврати измамата с използване на фалшиви имена на домейни, но не може да предотврати използването на подобни имена на домейни (използване от нападателя на легитимни имена на домейни) и атаки с използване на откраднати имена на домейни на партньори, които са били атакувани. Това са типове атаки, които могат да бъдат предотвратени с използване на сертификати. Това е основната причина да се използва анализ на семантиката и поведение с използване на AI.
Можем ли да доверим на 99% ефективност за откриване, заявена от доставчика?
Процентът за откриване, извън тествения набор от данни, няма голямо значение. Трябва да се изискват типови данни за възстановяване и да се тества с истински изгубени примери от миналото, както и да се провежда паралелен тест за валидации в течение на поне 30 дни.
Колко голямо бреме по операции носят грешните сигнализации?
Те са много лесно подценени. Даже при 0,1% грешни сигнализации, при имейли в размер на милиони, това означава хиляди нормални имейли, които са били филтрирани в течение на един ден, което ще парализира SOC и ще увреди доверието на потребителите. При оценка е необходимо да се измери времето за коригиране на грешни сигнализации и скоростта на обучение.
След като нападателите използват AI за генериране на измамни имейли, е ли все още ефикасно откриването?
Традиционните методи за откриване на измамни имейли чрез използване на граматика и правопис са вече неэффективни, но методите за откриване на измамни имейли, базирани на поведенческите базови линии и графите на отношенията, все още са ефективни, защото не зависят от качеството на текста. Проектът трябва да включва множество двигатели и да избягва целенасочените атаки.
Имат ли малки и средни предприятия нужда от закупуване на специални AI агенти за откриване на измамни имейли?
Ако вече използват Microsoft 365 или Google Workspace, трябва да първо активира своите вградени способности за сигурност и да настроят DMARC на „изпълнение“. Когато се справят с високорискови атаки или изисквания за съответствие, трябва да оценят специализираните решения ICES, като продукти с малко таксуване на база на брой имейл акаунти вече са налични и имат намалени прагове за достъп.
Колко време обикновено отнема за разполагане на тези системи?
Техническият достъп до системата на ниво API може да отнеме от няколко минути до няколко дни, но за пълна реализация се препоръчва 90-дневен план в три етапа: 30 дни паралелен тест, 30 дни настройка в сив режим и 30 дни пълна промоция и оперативна фиксация, за да се контролират грешните сигнализации и рисковете при преминаването.
