Одговор на фишинг са QR кодом: Шта да радите након скенирања

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

Овај ток рада се примењује без обзира да ли се сумњиви код појавио у имејлу, документу, пошиљци, на постеру, у сали за састанке, у простору за посетиоце или у пословној поруци. Такође даје купцима конкретан стандард за процену платформи за подизање свести о "кушинг-превари": алат треба да подржава извештавање, тријажу, безбедно повратне информације и мерљиво опоравак — а не само да броји скенирања.

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

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

Прекините интеракцију. Затворите одредиште и не уносите лозинку, податке о плаћању, аутентификациони код или друге осетљиве информације. Не одобравајте пријаву или не инсталирајте ништа што страница затражи.
Пријавите преко поузданог канала. Користите познато дугме за пријављивање компаније, безбедносни мејл-поштанско сандуче, службу за кориснике, телефонску линију или радни ток за пријављивање преко мобилног телефона. Не користите контакт информације приказане на сумњивој страници.
Пријавите шта се догодило. Наведите где се код појавио, када је скениран, шта је телефон приказао и да ли су унети неки подаци, да ли је дат одобрење или је отворена датотека.

Омогућите пут за пријављивање и ван корпоративног лаптопа. Скенирање QR кода често преусмерава запосленог на телефон, па формулар доступан само на интранету или додатак за е-пошту на рачунару можда неће бити доступан у тренутку када је потребан. Лак за памћење кратак адреса, број службе за кориснике или формулар доступан преко мобилног уређаја смањују кашњење.

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

Упозорење ФБИ-ја о злонамерним QR кодовима наводи да и дигитални и физички кодови могу бити измењени или искоришћени за преусмеравање људи на преварантске дестинације. Зато прво пријављивање треба да укључи оригинални контекст, а не само одредиште које се отворило.

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

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

Користите једноставан модел тријаже заснован на томе шта се десило следеће:

Код примећен, али није скениран: сачувајте оригинални контекст, уклоните или изолујте код где је то прикладно и проверите да ли би се други могли сусрести са њим.
Код скениран; без даљег деловања: прегледајте одредиште и релевантни уређај или безбедносну телеметрију путем одобрених алата. Дајте запосленом јасан закључак или следећи корак.
Унешене информације: идентификовати врсту података и поступити у складу са одговарајућим процедурама за идентитет, приватност, превару или изложеност података.
Одобрена аутентификација: одмах започети унутрашњи ток рада организације за заштиту налога и преглед сесије.
Отворен фајл или инсталирана апликација: пређите на поступак за инциденте на крајњој тачки или мобилном уређају.
Покренуто плаћање или размењени финансијски подаци: без одлагања обавестите овлашћеног власника за финансије или одговорног за реаговање на преваре.

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

Израдите СОК тријажну листу за извештаје о квашинг нападама

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

пријављивача и контакт-особu;
време открића и време скенирања;
где се појавио QR код;
да ли је био физички или дигитални;
тип уређаја и да ли је под управљањем компаније;
шта се појавило након скенирања;
да ли су унети подаци, одобрен захтев или отворен фајл;
снимци екрана или фотографије када је безбедно и дозвољено;
повезана порука, документ, тикет или идентификатор локације;
друге особе или локације које су можда примиле исти код; и
хитне радње које су већ предузете.

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

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

Сачувајте извор као и налог

Квишинг може да пређе дигиталне и физичке границе. Стога, власник одговора мора да гледа даље од телефона.

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

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

Јасно власништво је од суштинског значаја. Безбедност може да процени претњу, тимови за идентитет могу да заштите налоге, ИТ може да пружи подршку за уређаје, објекти могу да се позабаве физичким материјалом, финансије могу да зауставе спорне уплате, а тимови за приватност или правни тимови могу да воде у доношењу одлука о регулисаним подацима. План за реаговање на "квишинг" треба да дефинише ове преносе надлежности пре настанка инцидента.

Упутство ЦИСА-е за препознавање и пријављивање фишинга наглашава вредност пријављивања сумњивих активности уместо даље интеракције. За пословни програм, претворите тај савет у унутрашњу руту са особљем, дефинисаним временима одговора и правилима ескалације.

Комуницирајте без окривљавања пријављивача

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

Користите неутралан језик:

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

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

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

Тестирајте ток одговора безбедним симулацијама

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

Вежба би требало да тестира питања као што су:

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

Користите водич за куповину симулатора кушингa да процените контроле дестинације, мобилну телеметрију, приватност и безбедност платформе. Водич за кушинг у хибридном раду (https://autophish.io/blog/quishing-awareness-training-for-hybrid-workplaces) обухвата физичке и дигиталне површине поверења које би требало да буду заступљене у програму.

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

Мерење извештавања и опоравка, а не само скенирања

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

Корисне мере програма укључују:

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

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

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

Замолите добављача платформе да демонстрира цео ток рада након скенирања:

Може ли платформа да разликује скенирање, каснију акцију, извештај и аутоматизовану безбедносну проверу?
Може ли да спречи прикупљање лозинки, кодова за аутентификацију, података о плаћању и других тајних података?
Могу ли запослени да извештавају са управљаних и личних телефона путем одобрених рута?
Може ли извештај да сачува оригиналну поруку, документ или контекст физичке локације?
Може ли да се интегрише са постојећим сервисним деском, безбедносном поштом, SIEM-ом или процесом управљања случајевима?
Могу ли администратори да дефинишу непосредне повратне информације и упутства за одговор без откривања детаља о кампањи?
Може ли програм да подржи физичке и дигиталне QR вежбе са истим контролама управљања?
Да ли су подешавања за приступ, задржавање, брисање, извоз и регионално складиштење конфигурисана?
Могу ли одговорни да паузирају вежбу и разликују је од стварног инцидента?
Да ли запис о ревизији бележи овлашћење, покретање, измене, извештаје, акције одговора и закључење?
Може ли извештавање да прикаже брзину одговора и исходе отклањања проблема, а не само стопе скенирања?
Може ли добављач да подржи ограничен пилот-пројекат без широког приступа продукцијским системима за идентификацију или размењивање порука?

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

Покрените ограничено пилотирање спремности за одговор

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

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

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

Често постављана питања

Шта запослени треба да уради након скенирања сумњивог QR кода?

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

Да ли скенирање фишинг QR кода значи да је телефон компромитован?

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

Да ли запослени треба одмах да ресетује лозинку?

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

Шта би симулација "кушинг" преваре требало да мери?

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

Може ли одговор на фишинг са QR кодовима да обухвати личне телефоне?

Да, ако организација дефинише руту поштовања приватности која не захтева инвазиван приступ личном уређају. Запослени могу да опишу шта се догодило и поделе одобрене доказе; одговорни сарадници треба да прикупе само оно што случај захтева и да понуде алтернативе када је приступ уређају непримерен.

Нека брзо извештавање буде најбезбеднија подразумевана опција

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

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