Тест за проникване или red team

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

За какво служи тестът за проникване

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

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

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

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

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

За какво служи red team

Red team ангажиментът е ограничен от цел, а не от обхват. Вместо „тествайте това приложение“, мандатът е нещо като: получете достъп до базата данни с клиенти; достигнете позиция, от която може да бъде одобрено плащане; демонстрирайте административен контрол над продукционната среда; извлечете маркиран набор от записи. Маршрутът е оставен открит — дали минава през слабост в приложение, фишинг имейл, данни за достъп, разкрити в публично хранилище за код, доставчик или физическо посещение на рецепцията, е проблем на red team да го реши.

Следват две неща. Първото е, че покритието се изоставя умишлено. Red team не изброява средата ви; той намира един път и го изминава. Отчетът може да съдържа много малко констатации и те може да изглеждат незначителни. Резултатът, който предаваме е разказ, не списък: ето какво направихме, по ред, с времеви печати, и ето къде свърши.

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

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

Едно до друго

Кое от двете всъщност ви трябва

Поводите са сравнително ясни, щом въпросът бъде поставен като „какво не знам?“, а не „кое звучи по-усъвършенствано?“.

Нужен ви е тест за проникване, ако: пускате нещо, което обработва пари, лични данни или регулирани решения; променили сте модел на удостоверяване или оторизация, или сте добавили принадлежност към клиентска организация или нива на права; клиент, застраховател или одитор иска независима увереност за назована система; никой извън екипа, който е изградил приложението, никога не го е оценявал; последният ви тест е на повече от година, а системата се е променила; или нямате текущ списък на това, което не е в ред. Всичко, което звучи като „безопасно ли е това за издаване?“, е тест.

Нужен ви е red team, ако: имате функция по операции по сигурността, чиято ефективност никога не е била измервана от друг освен от самата нея; инвестирали сте в инструменти за откриване и искате да знаете какво улавят, а не какво твърди продуктовият лист; затворили сте констатациите от скорошния си тест и оставащата несигурност е за реакцията, а не за конфигурацията; вашият борд или регулатор пита дали организацията би издържала целенасочена атака, а не дали някоя система има дефекти; или сте провеждали сценарийни упражнения и искате да знаете дали планът надживява срещата с действителността. Red teaming е правилната покупка, когато въпросът е за вашите хора и процеси под натиск и сте подготвени да чуете неудобен отговор.

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

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

Грешката, която купувачите правят

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

Това се случва по разбираеми причини: red teaming звучи като по-задълбочена версия на тестването, затова се чете като естествено придвижване напред и като по-лесна история за един борд. Резултатът е предвидим и скъп. Операторите намират път бързо, защото среда с неотстранени констатации предлага няколко. Нищо не ги открива, защото няма нищо, което да открива. Отчетът казва, че целта е била постигната за кратко време без вдигнати известия — което възложителят вече е подозирал и което не казва на никого какво да прави в понеделник. Платили сте надценка за отговор, до който сте могли да стигнете чрез разсъждение, и все още ви липсва списъкът с констатации, който ви е бил нужен.

По-лошо, ангажиментът е консумирал бюджета, който е трябвало да поправи проблема. Red team е измервателен инструмент: той ви казва колко добри са защитите ви. Насочен към защити, за които вече знаете, че са незрели, той не измерва нищо полезно. Всеки етап прави следващия осмислен — намерете и поправете това, което не е в ред, изградете наблюдението, проверете, че то улавя известните техники, и само тогава попитайте дали способен противник може да го подмине незабелязано.

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

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

Как двете работят заедно през една година

Проведени добре, те са етапи на една програма, а не алтернативи, и редът не е произволен.

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

Способността за откриване се изгражда паралелно и се проверява открито: покритие на известните техники, журналиране, което достига до мястото, където се генерират известията, известия, които достигат до човек, и човек с наръчник. Purple team работата принадлежи тук — евтина спрямо това, което поправя.

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

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

Накратко: тестът ви казва какво да поправите; red team ви казва дали поправянето е било достатъчно и дали бихте видели някой да опитва. Купувайте ги в този ред и се уверете, че и двата отчета завършват с работа, а не с папка в шкаф. Нашият отчет с констатации показва стандарта за доказателства, към който държим и двата вида ангажимент.