Принципите на Zero Trust (нула доверие) вече са нещо обичайно в корпоративната инфраструктура; организациите прекараха години в инвестиции в мерки, които защитават самоличностите и системите от сложни атаки.

Въпреки това, човешката грешка все още е лесно използваем път към дори най-защитените организации, особено когато доверието се установява ръчно. Процесите по въвеждане на нови служители (onboarding) и центровете за техническа поддръжка (service desk) са естествена точка на натиск, където операторите може да се наложи да вземат решения с голямо въздействие върху достъпа при ограничен контекст, докато за атакуващите е необходимо само да убедят един човек, че са тези, за които се представят.

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

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

Проблемът с фалшивата самоличност

ФБР неколкократно предупреди, че севернокорейски ИТ работници използват откраднати или фалшиви самоличности, за да си осигурят дистанционна работа и да получат достъп до корпоративни мрежи. В някои случаи работниците са използвали фалшиви документи за самоличност, прокси инфраструктура и посредници, базирани в САЩ, за да изглеждат като легитимни кандидати.

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

Схемите с фалшиви работници от Северна Корея са постоянни заплахи и ФБР вече препоръчва потвърждаване на самоличността по време на процеса по наемане и през целия период на работа на дистанционните служители. По-широкият извод е, че организациите трябва да прилагат същото ниво на проверка при създаването на самоличност, каквото прилагат и при удостоверяването на вече съществуваща такава.

Силната многофакторна автентификация (MFA) има слабо място: регистрирането

След като новият служител премине през процеса по въвеждане, центърът за поддръжка често участва активно в неговата настройка. Операторите могат да помогнат за активиране на акаунта, издаване на първоначални идентификационни данни, регистриране на MFA, регистриране на passkey или ключ за сигурност и конфигуриране на корпоративно устройство.

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

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

Ден първи се нуждае от собствен слой за потвърждаване на самоличността

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

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

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

Силните форми на потвърждаване на самоличността, като валидиране на издаден от държавата документ за самоличност и комбинирането му с биометрични проверки за наличие на жив човек (liveness checks), могат да осигурят увереност при липсата на съществуващи фактори за автентификация. Това помага да се установи доверие в даденото лице, преди организацията да започне да му предоставя такова.

Направете потвърждаването на самоличността част от работния процес

Решения като Specops Secure Onboarding прилагат този принцип, като правят потвърждаването на самоличността задължителна стъпка в процеса по въвеждане, вместо нещо, което се оставя на преценката на оператора от поддръжката за всеки отделен случай.

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

За нови служители Specops Secure Onboarding комбинира сканиране и валидиране на издадени от държавата документи с биометрично откриване на жив човек. Това дава на организациите по-високо ниво на увереност, че лицето, което се въвежда, е това, за което се представя, преди да бъдат издадени идентификационни данни, MFA методи, устройства или достъп до приложения.

Същият принцип продължава и след въвеждането. Когато този служител по-късно се свърже с центъра за поддръжка за помощ, Specops Secure Onboarding изисква от него да потвърди самоличността си с помощта на доверени фактори за автентификация, преди операторът да може да продължи.

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

Zero Trust трябва да започва преди първия вход в системата

Организациите са станали много по-добри в проверката на потребителите, след като те вече са вътре в средата. Следващата стъпка е прилагането на същото мислене към момента, в който тези самоличности се създават.

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