Penetration test, red team, purple team, симулиране на пробиви, нещо по средата или … всичко накуп?

Във всяко зло има и малко добро. Тази максима се оказа много вярна не само за начина на работа, който пандемията от COVID19 от преди няколко години успя да промени, но и за това до каква степен компаниите и институциите започнаха да гледат на киберсигурността. Освен увеличените инвестиции в системи за превенция на атаки, моето наблюдение е че започна да се обръща много по-сериозно внимание на оценката на риска, нуждата от адекватни процеси, свързани с киберсигурността, изграждането на специализирани екипи като SOC и други. Целият този комплекс от мерки изисква провеждане на внимателни проверки, защото сигурността е силна колкото е най-слабото звено, а при много, наистина много контроли, то може да се окаже трудно за откриване. Одити и тестове за проникване (ще използвам penetration тест, защото е по-познато като термин, а и ми звучи … по-технически) – дали само това е достатъчно за да оценим сигурността на една инфраструктура? В следващите редове ще се опитам да опиша моето виждане по този въпрос, като поне тук бих казал – „НЕ, нужни са повече подходи, като един е задължителен“.

Да приемем че в много случаи одитите по различни стандарти и нормативни изисквания, свързани с информационната сигурност, може да се приемат като задължителни и често се извършват от компании, имащи високо ниво на зрялост по отношение на защитата от киберзаплахи. До голяма степен те проверяват текущото състояние на контролите за сигурност и то на едно по-високо ниво, не казвам че няма технически доказателства, но оценката е холистична. За да видим какво се случва от гледна точка на системите и процесите се прилагат редица подходи като – сканирания за и управление на уязвимостите, penetration тестове, red team и purple team дейности, Attack Surface Management (ASM) и други. Дали само едно от тези неща е достатъчно или ако се инвестира във всички ще има по-добра оценка? Това е труден въпрос, отговорът на който следва да се определи за всяка конкретна инфраструктура, но винаги трябва да се вземе под внимание какви предимства и недостатъци има всяка една от тези проверки, какво точно анализират и какви резултати могат да ни дадат.

Сканиране за уязвимости (Vulnerability Scanning)

Уязвимостите могат да бъдат разнородни – от бъгове в кода, през “zero days”, до конфигурационни грешки. Използването на специализирани инструменти за тяхното откриване е базовo и по мое мнение задължително действие, което трябва да се извършва периодично, а оценката на резултатите да се прави от компетентни експерти. Разбира се, освен автоматизираните проверки понякога се налага да се премине и към ръчен анализ за конкретни слабости, но това е по-рядко срещано и се прави само в конкретни случаи, защото водещите производители на платформи за сканиране за уязвимости, сравнително бързо добавят нови индикатори, покриващи голям набор от операционни системи, устройства и приложения.

Важно е какво се случва след като имаме резултати от такава проверка. Необходимо е да се премине към процесът за управление на уязвимостите, който е свързан с оценка на техния риск и прилагане на мерки за неговото отстраняване (в случаите когато рискът не е приет). За съжаление, това с което се сблъсквам е че на много места този процес липсва, а администраторите прилагат обновления по един слабо контролиран начин (липсва управление на промените – “change management”).

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

Penetration тестoве

Съществува разбиране че penetration тестовете са най-добрият и универсален начин за проверка на информационната сигурност и респективно защитата на дадена инфраструктура. Това може да е било вярно преди десетилетия, но към момента мисля, че има нужда от допълнителни анализи и подходи, а за да се аргументирам за това нека да дефинираме какво точно е „тест за проникване“. Може да се обобщи, че penetration тестовете са проверка на открити уязвимости, дали и как те могат да бъдат използвани злонамерено и до какъв риск води това. Основата на анализът е резултат от сканиране за уязвимости, но е погрешно да се приеме че това е просто едно надграждане с допълнителни прости проверки.

Всеки penetration тест има ясно дефинирани метод (black-box, gray-box или white-box), обхват, времетраене, ограничения и конкретни цели. Това предполага че има известна или дори пълна яснота за проверяваната инфраструктура и/или системи. Сигурен съм, че тук си казвате – при “black-box” подход, penetration тестерите нямат знания за проверяваните системи и се опитват да направят максимално близка до реална ситуация проверка, но помислете от гледна точка на възложителя, който знае какво би очаквал при успешен анализ. Именно тук е и разликата с “red-team” дейностите, за които ще стане въпрос по-късно и при които не е ясно до къде може да стигне екипа (red team) от експерти.

По време на извършваните проверки при един penetration тест не се цели да се прикриват следите от използваните инструменти или да се реализират т.нар. „stealthy” активности, дори често пъти създадените логове и мрежови трафик допълнително се анализират от възложителите с цел верификация на защитни системи и допълване на конфигурации.

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

При поставени конкретни цели, екип от квалифицирани penetration тестери могат в сравнително кратък интервал от време да проверят и открият различни уязвимости и да опишат препоръки за тяхното отстраняване. От гледна точка на възложителя ще се получи изключително полезна информация, на база на която да се стартира процес за тяхното отстраняване, но след приключване на тези промени ще е необходима повторна проверка или казано по-друг начин нов penetration тест, с по-малко цели от предходния. Замислете се за следното – ако отстранените проблеми са довели до нови уязвимости, открити при повторния анализ, дали това няма да доведе до един затворен кръг от penetration тестове? Да, възможно е това да се случи и поради тази причина един по-нов подход е автоматизиран периодичен penetration тест, на което ще се спра по-долу.

Red team дейности

Да разгледаме следната ситуация - компания, която има сравнително високо ниво на зрялост по отношение на информационната си сигурност е въвела необходимите политики и процеси и е изградила SOC, иска да извърши цялостна проверка на наблюдението и дори на реакцията при инциденти. В този случай penetration тест няма да бъде най-доброто решение, защото този тип анализи нямат нужната гъвкавост, която се търси. Тук едно от подходящите решения е red team дейност (друго възможно е Breach and Attack Simulation), при която в проверяваната инфраструктура се включват експерти (red team members), които започват да извървят различни атаки с цел симулиране на максимално реална злонамерена дейност, целяща извършване на почти всички етапи от Cyber Kill Chain, прикривайки следите си и работейки дори дни наред.

Всъщност, каква е разликата между red team дейност и penetration тест? Може би едно от най-важните различия е че red team дейността цели да се провери до колко контролираните атаки могат да бъдат успешни (какви контроли за сигурност са приложени), открити (как се извършва наблюдението) и как ще се реагира при тях (ограничаване на „злонамерените“ системи и изолирането им). Вижда се че това е една задача, изискваща човешки фактор – от експертиза до изпълнение, защото въпреки че съществуват системи за автоматизиране на такива дейности, те не могат да реагират гъвкаво, да се напасват спрямо ситуацията и да вземат под внимание фактори като поведението на служителите и други.

За съжаление red team е скъпа дейност, която аналогично на penetration тестовете е препоръчително да се извършва от трета страна и изискваща предварително планиране, но получените резултати могат да дадат изключително полезни сведения за това как се справят съответните екипи в проверяваната компания или организация, дали политиките и процесите там имат пропуски, дали имплементираните контроли за сигурност са адекватни и други. Това не може да се получи от един penetration тест.

Purple team дейности

Под blue team се разбира екипа, който анализира, наблюдава и осигурява сигурността на инфраструктура и системи, свързана с киберзаплахи или ако се върнем на примера от описанието на red team, това ще е SOC.

Какво става когато смесим син и червен цвят?

Лилаво.

Ако обединим red и blue екипите (или част от blue изпълнява задачи за red) ще се получи една смесица от експерти, която може много задълбочено да провери контролите за сигурност. Най-често това се прави с вътрешен ресурс, но тук като недостатък може да се посочи, че има знания за тестваната инфраструктура.

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

Автоматизирани периодични penetration тестове

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

Появиха се специализирани решения, които предлагат непрекъснат, автоматизиран penetration test. Сигурен съм че това ви звучи като един страхотен вариант за имплементиране, но трябва да се вземат под внимание няколко фактора. На първо място инвестицията в подобна платформа е значителна, но определено се изплаща във времето. Не по-малко важно е да се отбележи и факта, че поне към момента този тип системи не могат изцяло да заменят човек експерт, който провежда тестовете. Според мен е разумен подход е да се извършва penetration тест на дадена инфраструктура веднъж или два пъти годишно, от трета страна и екип от експерти, а автоматизираните анализи да се използват за непрекъснати проверки, дали дадени коригирани уязвимости не са се появили отново (да – и това е напълно възможно), както и дали не е открито нещо ново. Тази комбинация от подходи не замества red team дейностите, но значително подобрява нивото на зашита и оценка на риска, чрез непрекъснатите проверки.

Attack Surface Management (ASM)

Гореописаните подходи винаги включват поглед върху анализираната инфраструктура и системи, както от гледна точка на ползвателите им, така и от „злонамерена“. До голяма степен те дават информация и видимост върху т.нар. „attack surface” (в превод – атакувана повърхност, но ще си позволя отново да използвам английския термин). Управлението на attack surface (ASM) се базира на непрекъснато търсене, анализ, отстраняване и проверка на уязвимости, както и наблюдение (свързано с процеса "threat intelligence") на потенциалните вектори за атака за дадена организация. Обърнете внимание, че тук отново се споменава – непрекъснато. Това е важно и е съществена разлика с някои от методите, изискващи експертни дейности.

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

ASM има редица предимства, ако бъде имплементиран. Чрез тази технология се наблюдават активите (assets), откриват се т.нар. “rogue” устройства, обхваща се “shadow IT” (сериозен проблем за много компании и организации), извършва се класифициране и оценка на рискове и заплахи, също така има възможност за извършване на действия за тяхното отстраняване. Не на последно място се подобрява наблюдението, свързано с киберсигурността.

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

Breach and Attack Simulation (BAS)

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

Основните разлики между BAS и автоматизираните penetration тестове са целите и употребата на агенти, а приликите са, че и двата подхода се базират на набор от различни инструменти с висока степен на автоматизация.  

Оптимален избор

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

Считам че е задължително всяка организация да извършва периодично (минимум ежемесечни) сканирания за уязвимости на свята инфраструктура, като проверките могат да се правят от ИТ екипа или трета страна, но трябва да включват всички услуги (вътрешни и публични). Важно е резултатите да бъдат използвани като входни данни за процеса за управление на уязвимости, а след всяко ново сканиране да се анализират и разликите с предходното (т.нар. делта доклад).

Решението какво да се използва след сканиране за уязвимости трябва да е мотивирано и може да се базира на отговори на въпроси като:

·       Ще се извършва ли оценка на контроли за сигурност или само ще се определи attack surface? При анализ на контроли за сигурност е подходящо да се изпълнят penetration тестове (включително автоматизирани такива), red team и purple team дейности, както и BAS. Определяне единствено на attack surface – може да се приложат сканиране за уязвимости (задължително) и при ресурс ASM.

·       Проверката ще бъде еднократна или няколко пъти в годината? Ако е необходимо да се извършват по-голям брой проверки, например penetration тестове, е целесъобразно да се помисли за автоматизирани периодични проверки. Ако се търси еднократно проверяване, но задълбочено може да се приложи red team дейност.

·       Колко бързо трябва отново да се провери за отстранени или нови уязвимости? Ако след приключване на анализ е необходимо да се повтори проверката в кратък срок, например няколко дни до седмица – автоматизиран penetration тест е добро решение.

·       С какъв финансов ресурс и с каква времева рамка разполагаме? От гледна точка на цена, най-достъпни проверки са penetration тест с ограничен обхват и BAS. Останалите от описаните методи изискват по-голяма инвестиция, но могат да дадат много по-точни резултати.

·       Какви са компетенциите на експертите по киберсигурност, с които разполагаме? Важно е ИТ екипът, поддържащ проверяваната инфраструктура да може пълноценно да се възползва от получените резултати. Докладите, получени след сканиране за уязвимости и penetration тестове обичайно съдържат препоръки за отстраняване на намерените слабости. По-трудно е да са оценят резултатите от red team или purple team дейностите, защото е необходимо да се направи задълбочен анализ на извършените „атаки“ и предприетите стъпки за защита, има силно влияещ човешки фактор и други.

·       Какви ще бъдат следващите стъпки, след получаване на резултатите от анализите? Силно се надявам, че проверките няма да са необходими „само на хартия“ за да отговорят на изискването на нормативен документ. Практиката показва, че е от съществено значение да се обърне внимание на резултатите от анализа на киберсигурността, дори те да съдържат само слабости с нисък приоритет, да няма успешно използвани уязвимости или red team дейността да е била неуспешна.

Може да се направи заключение, че изборът на начин за проверка на контролите за киберсигурност не е лесен, но те (проверките) са задължителни, а ако резултатите от тях не се използват пълноценно за подобряване на детекцията и превенцията от атаки, тогава те могат да бъдат една безсмислена инвестиция.

За да дам отговор на заглавието – „задължително сканиране за уязвимости, периодични penetration тестове, реализирани от трета независима страна, а при наличие на ресурс – дори може всичко накуп“.