Зашто имејлови за симулацију фишинга завршавају у спаму (и како то поправити без умањивања безбедности)

Ако ваше имејлове за симулацију фишинга заврше у спаму или карантину, тешко је веровати вашим резултатима.

Стопа кликања од 2% може да значи да су ваши корисници побољшали своје вештине. Или може да значи да велики део компаније заправо никада није видео поруку. То није само проблем извештавања. То је проблем у дизајну програма. Овај водич је намењен безбедносним инжењерима, ИТ администраторима, ЦИСО-има и руководиоцима за усаглашеност којима је потребна поуздана достава симулација без прављења опасних рупа у безбедности поште.

Безбедносна напомена: Овај чланак се бави одбрамбеним симулацијама и мерењем свести. Не садржи упутства за праву фишинг кампању, крађу акредитива или заобилажење безбедносних контрола у злонамерне сврхе.

Кратка верзија

Ако е-поруке за симулацију фишинга завршавају у спаму, решење обично није "опустите филтере док све не заврши у пријемном сандучету."

Безбеднији приступ је:

• користите посвећено доменско име за симулацију или поддомен
• намерно ускладите SPF, DKIM и DMARC
• одржавајте садржај и ланце преусмеравања чистим
• разликујте телеметрију испоруке од телеметрије понашања корисника
• и, где је потребно, користите селективну дозволу уместо широког заобилажења

Та последња тачка је важна. Широко дозвољавање је ризично. Али уски, добро документовани правили који су везани за посвећену IP адресу за слање и познате идентитете пошиљалаца могу бити сасвим разумна дугорочна контрола.

Зашто испоручивост у симулацији фишинга не функционише

Неуспеси у испоручивости су ретко случајни. Они су обично предвидив резултат начина на који је програм подешен.

1) SPF, DKIM или DMARC нису усклађени са видљивим пошиљаоцем

Ово је најчешћи узрок.

Ако домен који корисници виде у пољу From не одговара домену који је овлашћен помоћу SPF-а или потписан помоћу DKIM-а, мејл системи имају добар разлог да буду сумњичави. И Microsoft и Google третирају SPF, DKIM и DMARC као основне сигнале поверења у пошиљаоца, и оба наглашавају усклађеност са доменом видљивог пошиљаоца.

Уобичајени обрасци неуспеха:

• видљиви домен From није домен којим сте се заправо аутентификовали
• недостаје DKIM потпис или је прикључен на погрешан домен
• DMARC постоји, али усклађеност са видљивим доменом пошиљаоца никада није правилно тестирана
• извршене су измене у DNS-у, али се нису у потпуности прошириле или потврдиле пре покретања кампање

2) Симулација користи главни корпоративни домен

Коришћење примарног домена компаније може изгледати реалистично, али често ствара непотребне сукобе.

На крају тестирате против истих контрола за спречавање превара, прерушавања и злоупотребе које постоје да би заштитиле тај домен у продукцији. То може бити прикладно у неким зрелим програмима, али је ретко најбоље полазиште.

За већину тимова, посебни поддомен за симулацију је безбеднија подразумевана опција.

3) Коришћен је погрешан тип беле листе

Допуштање може постати безбедносни проблем, посебно када тимови раде ствари као што су:

• глобално заобилажење заштите од фишинга
• допуштање огромних IP опсега облачних провајдера
• изузимање целог пошиљалачког инфраструктурног система којим не управљају
• прескокање скенирања за широке категорије поште

Али то није једини модел.

Постоји велика разлика између широких заобилазака и хируршких правила за доставу. Ако ваш провајдер шаље са посвећене ИП адресе и малог, познатог скупа адреса или домена пошиљалаца, дозвољавање уском опсегу може бити прихватљиво и чак може остати део стандардне конфигурације. Сопствени документи са упутствима за подешавање компаније AutoPhish управо тај модел: кампање се шаљу са наменског SMTP сервера/IP адресе и дефинисаног скупа адреса пошиљалаца, што омогућава прецизно филтрирање изузетака без прибегавања врсти прекомерних заобилазних решења која стварају стварну изложеност.

4) Садржај и линкови покрећу исте контроле којима очекујете да ће корисници веровати

Имитациони имејлови често садрже:

• линкове за праћење
• преусмеравања
• језик хитности
• формулације у стилу бренда
• позиве на акцију у стилу пријаве

То аутоматски није погрешно. Али то значи да ће имејл бити проверен као сумњив имејл. Ако симулација зависи од тога да изгледа довољно сумњиво да заобиђе ваше сопствене контроле, ви заправо више не тестирате кориснике. Ви тестирате да ли ваш безбедносни слој открива очигледно ризичан садржај.

5) Подаци о испоруци и подаци о понашању су помешани

Ако не можете јасно да одвојите:

• послато
• испоручено
• отворено
• кликнуто
• пријављено

онда ће вас ваше извештавање збунити. Слаба метрика кампање може да одражава проблем са корисником. Или проблем са рутирањем. Или политику карантина. Или проблем са филтрирањем специфичан за провајдера поштанског сандучета. То су веома различити путеви за отклањање проблема.

Безбеднији начин за побољшање испоруке фишинг симулације

Корак 1: Одвојите слање симулације од уобичајене пословне е-поште

За већину организација, најбоља полазна основа је:

• наменски домен или поддомен за симулацију
• наменски рекорди за аутентификацију
• чист пут слања који је лако објаснити и проверити
• без представљања као стварни унутрашњи корисници, осим ако не постоји јасан, проверен разлог

Ово смањује опсег експлозије, смањује конфузију и чини решавање проблема много лакшим.

Корак 2: Проверите аутентификацију пре прве кампање

Пре него што закључите да "Microsoft нас блокира" или да је "Google превише агресиван", проверите основе:

• да SPF обухвата само инфраструктуру која треба да шаље симулационе имејлове
• да је DKIM омогућен и да потписује поуздано
• да је DMARC објављен и усклађен са видљивим доменом пошиљаоца
• да ли тест поруке заправо показују резултате аутентификације које сте очекивали

За неутрално освежавање знања, преглед Microsoft-а о аутентификацији е-поште је корисна основа, а Google-ове смернице за пошиљаоце износи исту основну поенту: поуздана достава почиње чистом аутентификацијом и усклађеношћу домена.

Ако користите AutoPhish, чланак о помоћи за испоруку имејлова кампање и проверу DNS-а су добра полазна места током подешавања.

Корак 3: Користите прецизну дозволу (allowlisting) када је потребно, а не опште заобилажење

Ово је део који је многим тимовима заправо потребан.

Добар изузетак је:

• специфичан
• документован
• предмет прегледа
• лако се објашњава ревизорима
• везан за познат идентитет пошиљаоца или посвећену IP адресу за слање
• довољно узак да случајно не дозволи неповезани саобраћај

Лош изузетак је "све од овог провајдера је у реду". Боља изузетац је "поруке за симулацију са ове посвећене IP адресе и овог дефинисаног скупа пошиљалаца треба да се достави доследно за овај програм подизања свести." Та разлика је важна.

У пракси, најодбрањивији став је често:

• задржати уобичајено скенирање где је то могуће
• избегавати глобална правила за "прескок филтрирања"
• давати предност уским правилима заснованим на пошиљаоцу/IP адреси у односу на поверење у целу инфраструктуру
• прецизно документовати зашто правило постоји и шта обухвата
• периодично га прегледати, али не претпостављати да мора бити привремено ако остаје строго ограничен и даље одговара вашем моделу контроле

Са AutoPhish-ом, тај модел је остварив јер се кампање шаљу са наменске IP адресе и познатог отиска пошиљаоца, а не из огромног заједничког пула поште.

Корак 4: Дизајнирајте симулације да бисте учили препознавање, а не да бисте се борили против пролаза

Најбоље симулације фишинга не морају да "победе" сваку безбедносну контролу.

Оне треба да вам помогну да измерите да ли људи:

• примећују сумњиве знаке
• избегавају ризичне радње
• брзо пријављују сумњиве поруке
• временом напредују

То је здравији циљ дизајна од покушаја да се сваки имејл на слоју филтрирања учини нераздвојним од правог напада.

Корак 5: Изградите извештавање које може да разликује проблеме са поштом од проблема са људима

Зрео програм треба да може да одговори на следећа питања:

• Колико је порука заправо испоручено?
• Који провајдер или политика их је филтрирао?
• Која одељења су имала нижу видљивост?
• Да ли су корисници пријавили поруку?
• Да ли су исти корисници временом побољшали своје резултате?

То је оно што симулације претвара из "гомиле лажних имејлова" у нешто оперативно корисно.

Ако желите такву структуру, извештавање је подједнако важно као и садржај. Погледајте: Извештавање о симулацијама фишинга: 12 функција које би тимови за безбедност требало да упореде.

Како изгледа "добра" листа дозвољених пошиљалаца

Добро правило треба да буде довољно прецизно да ваш тим за безбедност може да се придржава њега, а ваши ревизори да га разумеју.

То обично значи:

• ограничено је на инфраструктуру за слање симулација
• везано је за познате домене, идентитете пошиљалаца или посвећену IP адресу
• не верује неповезаној пошти од истог ширег провајдера
• не ствара општу услов "увек испоручуј, никада не скенирај" осим ако не постоји веома јак разлог
• прати се као део дизајна програма подизања свести, а не као скривено заобилазно решење

Овде је такође важна архитектура провајдера. Ако платформа шаље са заједничког пула који користе многи клијенти, дугорочно додавање на дозвољену листу постаје теже оправдати. Ако шаље са наменске IP адресе са малим, документованим бројем пошиљалаца, уско додавање на дозвољену листу постаје много лакше оправдати.

Кратки контролни списак када имејлови за симулацију фишинга заврше у спаму

Користите овај контролни списак када ваши резултати изгледају сумњиво.

Аутентификација и идентитет пошиљалаца

• Да ли је видљиво поље "From" оно које сте намеравали да користите?
• Да ли су SPF, DKIM и DMARC усклађени са тим доменом?
• Да ли се недавно нешто променило у DNS-у или конфигурацији слања?
• Да ли тест заглавља показују резултате које сте очекивали?

Архитектура слања

• Да ли користите посебан поддомен за симулацију?
• Да ли је инфраструктура за слање изолована од продукцијске поште?
• Да ли је историја репутације пошиљаоца стабилна?
• Да ли се ослањате на заједнички пул пошиљалаца или на посебну IP адресу?

Правила и изузеци

• Да ли је неко направио широко заобилазно правило да би "једноставно функционисало"?
• Може ли се правило сузити на тачне идентитете пошиљалаца или на одређену IP адресу?
• Да ли је изузетак документован и може ли се прегледати?
• Да ли и даље скенирате где год је то практично?

Садржај и мерење

• Да ли су URL адресе чисте и предвидиве?
• Да ли постоје непотребни ланци преусмеравања?
• Да ли мерите доставу одвојено од ангажовања?
• Да ли пратите стопу извештаја и време до извештаја, а не само кликове?

ЧПП

Да ли треба да ставимо на белу листу имејлове за симулацију фишинга?

Понекад да.

Оно што желите да избегнете је широко поверење. Оно што је често прихватљиво је тесно поверење: посвећена IP адреса за слање, познати идентитети пошиљалаца, јасно документован циљ и без прекомерног заобилажења које слаби остатак ваше безбедности имејлова.

Да ли та правила треба да буду привремена?

Не нужно.

Широке изузетке у ванредним ситуацијама треба да буду привремене. Али прецизна, добро дефинисана правила могу остати на снази ако су део одобреног оперативног модела, и даље прикладно уска, и периодично се прегледају.

Можемо ли да покрећемо симулације са нашег главног корпоративног домена?

Можете, али је то обично захтевније и ризичније.

Посебни поддомен за симулацију је лакши за аутентификацију, лакши за објашњење и мање је вероватно да ће доћи у сукоб са вашим производним контролама против преваре и прерушавања.

Да ли боља испорученост смањује реализам?

Не.

Добре симулације мере понашање препознавања и извештавања. Оне не морају да имају нередну инфраструктуру или небезбедне заобилазне путеве да би биле корисне.

Како докажемо да су резултати поуздани?

Документујте обе стране система:

1. шта је требало да буде испоручено
2. шта су корисници заправо урадили након испоруке

То је далеко одбрањивије него показивање графикона стопе клика без контекста испоруке.

Јесте ли спремни да покренете симулације које мере отпорност уместо случајних догађаја у протоку поште?

AutoPhish је направљен за тимове који желе безбедне симулације, извештавање које штити приватност и доказе погодне за ревизију без великог оперативног оптерећења.

Ако вам је потребан прецизан водич за подешавање, погледајте наш чланак о томе како да се уверите да су е-поруке кампање добро примљене.

Пријавите се

Заслуге за слику: Фотографија аутора Крсто Јевтић на Unsplash.