Преминете към съдържанието

МЕУ организира кампания за пентестове в държавната администрация

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

Добре дошли в Хакинг.БГ! 

Всеки един от нас стои на раменете на гигантите, споделили знанията и опита си с нас.

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

Стремим се да предоставим платформа, където членовете могат да развиват своите умения, като се дава приоритет на етиката, сигурността и поверителността!

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


Препоръчан пост


  • Група:  [Администратор]
  • Последователи:  7
  • Брой мнения:  50
  • Репутация:   42
  • Спечелени дни:  21
  • Регистриран на:  10.04.2023
  • Статус:  Оффлайн
  • Система/OS::  Windows

zx952y526_4270323.jpg?v=1635323831

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

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

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

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

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

 

 

Силни страни

Основна проверка, показваща потенциални слабости и уязвимости. Резултатите се използват като база при penetration тестове, оценка на риска, red team дейности и други.

Слаби страни

Резултатите зависят от наличните проверки в използвания инструмент. Възможно е да има голям брой недействителни открития (false-positive), не винаги има лесна възможност да се провери, дали дадена уязвимост може да се използва при реална атака или - не. В оценката на риска липсва експертното мнение.

Човешки фактор

Не.

Ограничение във времето

Да. Сравнително бързи проверки.

Необходим ресурс

Инвестиция в система за сканиране за уязвимости (налични са и безплатни) и при нужда добавяне на софтуерен модул за сканиране в рамките на проверяваната инфраструктура.

Резултати

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

Проверка само на текущо състояние

Възможно е да се стартират периодични последователни сканирания.

Цена

Ниска.

Vulnerability-Scanning-1.png

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 тест, на което ще се спра по-долу.

Силни страни

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

Слаби страни

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

Човешки фактор

Да.

Ограничение във времето

Да. Планира се във времето с ограничения за извършвани проверки.

Необходим ресурс

Екип от експерти. Препоръчително е да се използва услуга на трета, независима страна.

Резултати

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

Проверка само на текущо състояние

Да. Възможно е стартиране на последователни penetration тестове, но е необходимо време за тяхното планиране и изпълнение.

Цена

Средна.

 

Penetration-Test-1.png

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 тест.

Силни страни

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

Слаби страни

Изисква се значителен експертен опит, внимателно планиране и задълбочена оценка на получените резултати.

Човешки фактор

Да, като се използва трета независима страна.

Ограничение във времето

Да, детайлно планиране и изпълнение в рамките на дни след началото на дейностите.

Необходим ресурс

Необходими са експертни знания за този тип анализи (откриване на уязвимости и тяхното използване, прикриване на следи, прилагане на тактики за да не бъдат открити и други.

Резултати

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

Проверка само на текущо състояние

Не. Проверка на текущите контроли за сигурност, знанията и уменията на екипа.

Цена

Висока до много висока.

 

Red-Teaming-1.png

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

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

Лилаво.

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

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

Силни страни

На база на опита на експертите се проверяват контролите за сигурност, знанията и уменията на ИТ екипа, поддържащ анализираната инфраструктура, процесите и реакцията при инциденти. Включването на изцяло вътрешен ресурс от специалисти за red team и blue team дейностите значително подобрява знанията, уменията и показва, дали има пропуски в процесите, свързани с информационната сигурност.

Слаби страни

Изисква се значителен експертен опит, внимателно планиране и задълбочена оценка на получените резултати. Включването на голям брой специалисти от една организация изисква внимателно разпределение във времето. Възможно е да се използват „вътрешни“ знания за red team действията.

Човешки фактор

Да.

Ограничение във времето

Да, детайлно планиране и изпълнение в рамките на дни след началото на дейностите.

Необходим ресурс

Необходими са експертни знания за този тип анализи (откриване на уязвимости и тяхното използване, прикриване на следи, прилагане на тактики за да не бъдат открити и други. Включването на blue team ролята изисква още повече вътрешен ресурс.

Резултати

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

Проверка само на текущо състояние

Не. Проверка на текущите контроли за сигурност, знанията и уменията на екипа.

Цена

Висока.

 

Purple-Team-1.png

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

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

Силни страни

Автоматизирани и „непрекъснати“ проверки, които дават възможност за бързо откриване на нови слабости и уязвимости.

Слаби страни

Висока цена на платформите за автоматизиран penetration тест, а резултатите силно завист от възможностите на софтуерното решение.

Човешки фактор

Не.

Ограничение във времето

Не, възможно е да се правят непрекъснати проверки.

Необходим ресурс

Специализирана платформа за непрекъснати и автоматизирани penetration тестове.

Резултати

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

Проверка само на текущо състояние

Не. Бързите и периодични проверки могат бързо да открият нови пропуски в сигурността.

Цена

Средна до висока (зависи от избраната специализирана платформа).

 

Automated-Penetration-Testing-1.png

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

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

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

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

Силни страни

Разширена видимост и по-точна оценка на риска.

Слаби страни

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

Човешки фактор

Да, но само при конфигурацията и оценката на резултатите.

Ограничение във времето

Не, възможно е да се извършват автоматизирани и последователни проверки.

Необходим ресурс

Препоръчително е използването на специализирано решение.

Резултати

Възможно е да има наличие на недействителни открития. Получава се по-добра видимост върху attack surface.

Проверка само на текущо състояние

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

Цена

Средна до висока (в зависимост от платформата).

 

Attack-Surface-Management-1.png

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

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

Силни страни

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

Слаби страни

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

Човешки фактор

Не.

Ограничение във времето

Не, възможно е автоматизирано стартиране на анализи.

Необходим ресурс

Препоръчително е да се използва специализирана софтуерна система.

Резултати

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

Проверка само на текущо състояние

При използване на специализирана платформа е възможно да се стартират последователни проверки.

Цена

Ниска до средна (зависи от избраното софтуерно решение).

 

image_2024-03-08_203253737.png

 

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

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

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

·      

Quote

Ще се извършва ли оценка на контроли за сигурност или само ще се определи attack surface?

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

·      

Quote

Проверката ще бъде еднократна или няколко пъти в годината?

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

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

Quote

·       С какъв финансов ресурс и с каква времева рамка разполагаме?

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

Quote

·       Какви са компетенциите на експертите по киберсигурност, с които разполагаме?

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

Quote

·       Какви ще бъдат следващите стъпки, след получаване на резултатите от анализите?

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

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

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

Линк към статията и блога на Александър Цокев

Hacking-Banner.png

Link to comment
Сподели другаде

Join the conversation

Можете да публикувате сега и да се регистрирате по-късно. If you have an account, sign in now to post with your account.

Гост
Отговори на тази тема

×   Поставено като форматиран текст.   Вместо това поставете като обикновен текст

  Разрешени са само 75 емотикони.

×   Вашата връзка е вградена автоматично.   Вместо това се показва като връзка

×   Вашето предишно съдържание е възстановено.   Изчистване на редактора

×   Не можете да качите директно снимка. Качете или добавете изображението от линк (URL)

  • Регистрирайте се

    Регистрирайте се за да използвате пълната функционалност на форума 🙂

HACKING.BG Партньори

Asset3.png.df693f7661f6e8a7a3ec208659eda80b.pngtransparent1.png.c15979e1dc997cdd3a9941e342368a9b.png2.png.3e2592eadc660ecc831f1fdd569e8eb4.png600_489534840.png.72981fb02b90f1986dd7ade4d561e6d0.pngcyberclub-logo-text.png.6e9d11752e2eade43d40337d83365e48.png

×
×
  • Създай ново...

Важна информация!

Политика за сигурност и условия на ползване Privacy Policy