Хакер автопилот меняет правила игры. PT Dephaze. Бабин Ярослав Positive Technologies
Очень хочется. Замечательно. Господа, ваши аплодисменты Анне Олейниковой компании на стейдж. Итак, друзья, теперь поговорим немного о таких технологиях, как симуляция атак и применимость этого, в принципе, для стороны защиты. Первые системы для симуляции атак стали появляться более 10 лет назад, четкого разделения по функционалу и проблемам, которые они решают, нет.
В компании Postive Technologies проанализировали и попробовали десятки коммерческих open source продуктов, которые занимаются этими вопросами и для каждого из них нашли применение. Наш следующий спикер готов поделиться опытом в данном направлении. Встречайте, Ярослав Бабин, компания Postive Technologies, директор по продуктам для симуляции АТАК. Друзья, напоминаю про вопросы. Можете задавать их в Telegram-боте, для тех, кто онлайн, задавайте онлайн, подняв руку, и, соответственно, для онлайн-трансляции в специальном окошке. Спасибо. Ярослав, слово.
Всем привет. Да, как правильно сказали, мы смотрели в сторону решений, которые автоматически тестируют инфраструктуру, пытаются поломать, либо проводят какие-то отдельные атомарные атаки для того, чтобы посмотреть, как работают средства защиты. Меня зовут Ярослав Бабин, я директор по продуктам для симуляции атак. Вообще у меня в основном опыт именно со стороны оффенсив, со стороны наступательной кибербезопасности. Больше 15 лет я занимаюсь анализом защищенности веб-приложений, бизнес-приложение, то есть мы ломали различные банкоматы, онлайн-банкинги. Короче, так или иначе, системы, которые связаны с деньгами внутри них.
Также я занимался социальной инженерией, социотехническим тестированием, когда мы атакуем какую-то компанию и смотрим на то, как сотрудники реагируют, какое у них поведение вообще, если они сталкиваются с фишингом, вводят ли они там свои данные и так далее. Много баккантил, много зарабатывал на бакбаунти, потом, собственно, и делал это бакбаунти. Если знаете большой наш киберполигон Standoff, нашу платформу Standoff 365, вот ей какое-то время занимался я. Ну и выступал на многих международных конференциях в Корее, Японии, в Казахстане, в Армении и так далее.
К вопросу о том, что за системы для симуляции АТАК. Они уже известны, наверное, порядка 15 лет, системы для симуляции атак. И изначально эта система для проверки того, насколько хорошо и качественно, результативно работают ваши средства защиты. Поэтому изначально это просто система, которая просто симулирует атаки. Но из-за неразберихи, из-за того, что Гартнер как-то не выделял особое это решение, басами стали называть абсолютно всё. Системы для ЯСМА, те, которые смотрят на то, как вы видны с точки зрения злоумышленника, ваш внешний периметр. Системы для
vulnerability management тоже вроде как должны обладать функциональностью баса, однако нет. Системы для автопин-теста, которые вы запускаете, они начинают там что-то пытаются поломать, эксплуатируют уязвимости, проникают в инфраструктуру. Смотрят какие-то данные, показывают то, что злоумышленник мог бы гипотетически сделать.
Сюда же идут и комплайн-сканы, когда просто сканируется инфраструктура на предмет каких-то там мисконфигураций и так далее. И системы для моделирования атак, которые на практике по факту ничего не делают. Они лишь показывают потенциальные пути того, как злоумышленник мог бы перемещаться в вашей инфраструктуре, какие он бы мог использовать уязвимости и получается такой огроменный граф как потенциальный злоумышленник мог бы двигаться если бы у него были знания о том какие уязвимости в вашей инфраструктуре есть. Мы посмотрели на все это деление поняли то что это никаким образом не относится к реальной практической симуляции атак и поэтому для себя разделили на две основных категории.
Первое это автоматизация атак по неким созданным сценариям. Представьте то, что у вас есть некий набор кубиков. Каждый кубик это некая атака на инфраструктуру. Например, один кубик повышения привилегий. В этом кубике есть еще более мелкий набор кубиков, которые эксплуатируют какие-либо уязвимости, связанные с повышением привилегий. Есть отдельные кубики, которые делают какие-то вредоносные действия на целевом хосте. Например, не знаю, дампят lsas,
например, записываются в ветку в реестра в автозагрузку, или, не знаю, например, скачивают какой-нибудь бинарный файл из интернета. Вы смотрите на то, как работает ваше решение NTA, которое трафик анализирует, или какой-нибудь веб-прокси. Из этих кубиков вы, как специалист, готовите к некую инфраструктуру, который будет заранее уязвимо, в который вы знаете, какие уязвимости уже содержатся, и настраиваете прям сценарий полностью всей атаки.
Условно, перейди на такой-то хост, на этом узле загрузи такой-то бинарь, сначала загрузи этот бинарь в память, после этого, не знаю, сдам LSAS или повысь привилегия, после получи хэши пользователей, с этого хоста сделай там еще что-то. То есть вам нужно досконально описать все то, что будет происходить в вашей демо-инфраструктуре. Второй сценарий — это автоматический пентест. В этом случае у вас нет вот этого набора кубиков. Система сама принимает решение о том, в какое направление ей нужно двигаться, имея те данные, которые у нее на текущий момент есть.
Условно, у нее есть узел, порт, сервис и, например, версия сервиса. Если есть атака, которая к этому сервису подходит, она понимает, что да, у меня есть все условия для того, чтобы попробовать эту атаку выполнить. Или, например, она находится на узле, выполнила команду System.Info, понимает то, что версия винды такая-то, последние апдейты такие-то, поэтому я могу повысить привилегии с помощью такой-то уязвимости. И там может быть набор уязвимостей, она пойдет по первой, если она успешно не отработает, перейдет на вторую, третью, четвертую, пятую, пока не получит результат, которого она ожидает.
То есть повысит там привилегии. В этом случае у вас нет вот этого набора кубиков, и оно просто двигается в том направлении, в котором считает для себя самым лучшим, самым правильным. Вот представьте, что вы специалист ИБ в компании, и вот у вас есть система, которая позволяет автоматически по факту тестировать на проникновение вашей инфраструктуры, не обладая какими-то глубокими знаниями о том, как работает пентест, какие инструменты хакеры используют, и вот для себя, например, он говорят, слушай, Петь, вот у нас нужно поставить EDR, кажется. Все говорят, что это нужно, давайте EDR установим. Говорят, можешь выбрать нам какой-нибудь, который будет самый крутой. Вы пилотируете, например, несколько решений, и чтобы проверить, какой из них лучше ловит атаки, работает быстрее, эффективнее, там не загружает процессор на всю память, вы берете несколько стендов и запускаете там систему для симуляции атак, которая прогоняет по порядку различные атаки, которые EDR должен ловить. Скачивание там малварии, загрузка там выполнения в
памяти какого-то кода, создание учетных записей. И у вас условно есть наборы там из 100 тестов, которые выполняют какие-то нелегитимные действия и смотрите на то, как EDR их обрабатывает, и получается понятный результат. Один EDR заблокировал 90 таких событий, другой 80, третий 60. Понятно, что с точки зрения результативности первый показал себя лучше. Берем его.
Второй вариант. У вас огромная инфраструктура, вы думаете, что у вас заведены логи на всех системах, Все продукты настроены корректно, правила корреляции тоже все хорошо, точно работают. Можно запустить систему, которая пойдет, начнет проникать по всей инфраструктуре, расширяться максимально глубоко, пойдет в абсолютно любые сегменты вашей сети. И что может произойти? Вы видите то, что да, сейчас система находится вот здесь, она атакует такой-то хост, с этого хоста переместилась куда-то дальше. Потом раз в средствах защиты не отображается ничего, то есть вы там спустя какое-то время видите, как оно просто переключилось, например, уже начала атаковать DC. А все, что было до этого, скрыто по какой-то причине.
Не заведены логи, вообще отсутствует средство защиты. Это позволяет как раз таки понять, где у вас есть мертвые зоны, где нет никакой видимости и никакие инциденты по атакам абсолютно никак не приходят. Что вообще в целом происходит на пентестах? Ребята пентестят инфраструктуру. Есть какой-то киллчейн, который доходит до каких-то критичных систем. И часто бывает так, что получив доступ в некий сегмент, хакеры могут добраться сразу же до огромного количества критичных систем. Там до 1С с этого узла могут дойти до какого-нибудь, не знаю, сегмента с СУТП, с банкоматной сетью.
И это некий bottleneck, который открывает огромные возможности для атакующего. И исправив все уязвимости на этом узле, либо в этом сегменте, получится так, что хакер до него дойдет, постучится и дальше уже никуда пойти не сможет. Здесь это все произойдет автоматически.
Вы увидите то, что с этого хоста у нас огромное количество дальнейших атак на какие-то соседние узлы. И пойдете исправлять, сразу приоритизируете уязвимости в вашем ВИЭМе, закройте и все будет хорошо. Часто еще возникает проблема, что на пентесте вам показывают какой-то один вектор получения полных привилегий, в основном это атаки на DC и получение домен админа в инфраструктуре. Однако, всех вот этих цепочек, которые позволяют посмотреть вообще, а куда в целом хакер мог бы добраться, например, из пользовательского сегмента.
То есть, если какой-нибудь из пользователей загрузил малварь, запустил ее случайно, и вот из пользовательского сегмента, может ли он добраться до СУТПшки, может ли он добраться до компьютера генерального директора или какой-нибудь отчетности бухгалтерской, вот здесь можно будет получить абсолютно все вектора проникновения из какого-то определенного сегмента. Пользовательского, не знаю, где принтеры у вас расположены, где у вас переговорки какие-нибудь. Ну и последнее, это то, что можно качественно обучать первую линию SOC, который реагирует на все эти инциденты. Вы запускаете инструмент, смотрите, насколько быстро ребята реагируют и какой у вас тайм-то респонс. Естественно, чем больше вы запускаете, тем он должен быть меньше. Так как в этом решении зачастую
используются именно те хакерские инструменты, которые используют 99% хакеров, не какие-то супер крутые и мощные АПТшки, которые переписывают инструментарий, чтобы никаких детектов на их инструменты не было. Зачастую скрипткиди или новички, ребята, просто делают гид-клон инструментов с гидхаба и начинают использовать их. Естественно, средства защиты на эти инструменты должны реагировать правильно, потому что они нас от этого как раз защищают. Однако не всегда бывает так, правила корреляции отрабатывают по-разному, часто фолзят либо очень широко берут и это прям большая проблема. Все то что я описал подходит в целом и под тестирование на проникновение внутреннего периметра, но есть некие ограничения в том, что часто пентесты делают не еженедельно, не постоянно, не раз в квартал, а примерно раз в год пентест не показывает абсолютно всех векторов проникновения, то есть задача при пентесте получить максимальные привилегии в инфраструктуре, либо добраться до каких-то критически важных систем внутри этой инфры, ну или там, не знаю, подсетей каких-нибудь ССУТП.
Получается один вектор, который доходит до какого-то сегмента, и все, на этом пентест закончен, хакеры считают то, что они там все успешно выполнили. Третье это отсутствие возможности посмотреть, где у вас как раз-таки мертвые зоны всех средств защиты. Сегментов много, средства защиты установлены должны быть на всех из них, но хакеры идут по какой-то определенной цепочке, поэтому вы не покрываете абсолютно всю вашу инфраструктуру и не можете понять, где где еще потенциально могут быть проблемы, где у нас средства защиты неправильно настроены, например. Однако, после того, как этим инструментом вы воспользовались и устранили все то, какие проблемы есть на текущий момент, все равно нужно звать опытных пентестеров и проводить и ретимы, и пентесты, само собой, потому что ничто не заменяет хакерскую догадку, смекалку и весь тот опыт, который у них уже есть.
Часто, естественно, они будут работать намного лучше, чем машины. Когда мы смотрели на решение баз, которые есть на текущий момент, зачастую это как раз таки системы, которые позволяют из некого набора кубиков создать сценарий, то есть это некая заготовка, некая сценка, которая идет автоматически, просто по порядку, без всяких задержек проигрываются сценарии, выполняются команды, и вы смотрите в свои средства защиты на то, как они работают. Это отдельные атомарные атаки, например, как тестируется какая-нибудь песочница или решение по антиспаму. Берется набор сэмплов из 20 тысяч различных малварей, которые только были известны. И они просто пуляются в вашу почту. Неважно, работают они сейчас, подходят ли они под ваши системы.
Они проверяют именно средства защиты, то, какое у них покрытие вообще всех тех вредоносов, которые есть. Или вот с вафом, например. Берут обычное веб-приложение и отправляют туда какие-нибудь пейлоуды с RCE какими-нибудь уязвимостями, XSS, и так далее.
Неважно, есть ли там эта уязвимость в этом приложении, они просто смотрят на то, как работает и реагирует средство защиты. Условно отправили какой-нибудь пейлоуд с удаленным выполнением кода для какой-нибудь библиотеки. Если страничка 403 стала, вав заблокировал, значит все хорошо, вав нормально работает. И тут нету никакой отдельной пост-эксплуатации, она просто бинарная логика. Заблокировала хорошо, а не заблокировала плохо.
А дальше уже думайте, что с этими результатами делать. Эти решения в основном рассчитаны на проверки правил и средств защиты, насколько они хорошо работают. И все эти атаки как раз-таки часто интегрируются сиемом, чтобы можно было посмотреть, вот мы отправили такую-то атаку, а она в нашем CM вообще видна или нет. И вы по очереди просто прогоняете каждую атаку, смотрите в CM, смотрите, что не детектится, пишите новые правила корреляции и тем самым улучшаете работу своих средств защиты. Как я уже до этого говорил, у вас есть какой-то набор кубиков, которые вы совмещаете и прям составляете отдельный сценарий, который будет проигрываться. Но зачастую он ограничен тем, что это в основном атаки на хосты, то есть нет каких-то сетевых атак, нет латмувов, передвижений по инфраструктуре.
В основном это скачать какой-нибудь бинарный файл, попробовать запустить, повысить привилегии, сделать какую-нибудь вредоносную нагрузку в виде, например, зашифровать все данные на этом диске. И это очень сильно ограничивает, то есть фактически вы проверяете решение какого-нибудь EDR, NTA и антивируса. Однако это все кастомизируется, и если вы очень хорошо разбираетесь в том, как работают атаки, можете в целом сами заскриптовать и написать новую, найти на гитхабе какую-нибудь трендовую новую уязвимость, можете с легкостью дополнить зачастую поддержку абсолютно любых языков и дописать свою атаку.
И по результатам всех прогнанных атак вы получаете некий отчет, где видно, что, например, мы отправили 10 тысяч атак на почту. Из них ваша система смогла заблокировать 8 тысяч. Вот эти 2 тысячи она не заблокировала, поэтому идите и придумайте, что с этим делать. Часто все идут к вендору и спрашивают, а почему вы не блокируете эти атаки, давайте разбирайтесь сами.
Какие проблемы несет то, что вы тестируете это все на одном определенном хосте и нужно на этот хост что-то установить. То есть вы не тестируете абсолютно всю инфраструктуру и покрытие всех ваших средств защиты, а тестируете какой-то конкретный хост, который под политики похож на все остальные хосты рабочих мест, например, в вашей инфраструктуре. Требует детальной проработки и понимания того, как эти уязвимости работают. То есть в тот момент, когда вы хотите прогнать какой-то сценарий, вам нужна уязвимая машина, на которой вы будете знать, какие уязвимости там есть.
То есть вы сами вручную все это сначала проверифицируете, то, что там возможна эта эксплуатация, а уже потом напишется сценарий, который под эту эксплуатацию лежит. Нужно быть хорошим экспертом в атаках, понимать, как это все изнутри работает. Аналогично с пост-эксплуатацией, ее зачастую нет, то есть нет никаких перемещений внутри инфраструктуры.
Это сильно ограничивает покрытие того, какие атаки и какие средства защиты вы можете проверить. Та же проблема с перемещением в другие подсетки, все тестируется отдельно на локальном хосте каком-то. Дальше никуда это не ходит. И deface evasion зачастую нет. Если он есть, то он сильно устаревший, то есть аффустируется все каким-нибудь MSF-веномом, который в целом все средства защиты на текущий момент уже научились хорошо детектить.
Вот всяких новых трендовых атак, которые просто, например, средства защиту могут выключить, там, к сожалению, нет. Мы посмотрели на все эти ограничения и проблемы, которые есть в текущих решениях баз и попробовали подумать, как бы это могло работать у нас. Изначально таргетировались то, что не будет требовать установки какого-то агента, то есть система сама принимает решение о том, в какую сторону ей идти, что эксплуатировать, если там нужен агент на конечном хосте, чтобы выполнять какие-то команды или например повышать привилегии. Она просто устанавливает некий бинарь, который
после того, как вы атаку просимулировали, автоматически удаляет и удаляет все то, принес на этот хост. Сценарии никакие прописывать не нужно, не нужно обладать большими знаниями о том, как работают атаки. Вы просто запускаете, система сама принимает решение о том, в какую сторону пойдет. Используем все текущие и трендовые техники и тактики хакеров, которые успешно справляются с обходом средств защиты. Могут обойти антивирусы, выполняться в памяти, могут отключать средства защиты, если есть такая возможность. Короче, весь тот арсенал, который сейчас используют и наши пентестеры, и в целом хакеры по миру, он доступен уже из коробки. Естественно, есть постэксплуатация. В тот момент, когда мы
понимаем, что мы попали на хост, можем дальше повысить привилегии, мы можем проанализировать все файлы, которые лежат на рабочем столе. Часто пользователи, например, оставляют какой-нибудь файлик по роли txt или паролей docx, где прям хранят все пароли свои от сервисов, вообще неважно, забираем файлы, которые хранятся в браузерах, пароли, которые хранятся в браузерах и пытаемся все это заново применить относительно других систем, которые мы еще увидели в инфраструктуре. Ну и, например, если мы атакуем какой-нибудь сервер, у которого есть несколько интерфейсов, мы автоматически будем спрашивать, а можем ли мы пойти в другую подсетку, потому что мы видим то, что у нас доступ туда есть. Если вы разрешаете, то перемещаемся в эту подсеть и начинаем свою атаку. Все это происходит безопасно, потому что, например, если есть некие эксплойты, например, какой-нибудь Eternal Blue или эксплойта, не знаю, атака DCSync, которая делает дополнительную нагрузку на хост. Короче, все те атаки, которые так
или иначе связаны с каким-то негативным воздействием на инфраструктуру, не знаю, уронить хост, сделать какую-то дополнительную нагрузку, все такие атаки будут идти на согласование и вы можете контролировать каждое такое плохое действие и решать, делать эту атаку или нет. Например, если у вас демо-сегмент, то, ну, наверное, там можно пошуметь, все поломать и ничего плохого не произойдет. Если это прот, то, наверное, да, все-таки это делать не стоит. Можно сконфигурировать скоупы исключения, то есть вы прямо, не знаю, делаете выгрузку из какого-нибудь там, не знаю, VM из чего угодно по списку IP-шников, хостов, которые точно можно атаковать и знать, что ничего с ними плохого не произойдет. То же самое с исключениями. Прям написать систему или подсетки, в которые нам нельзя идти никаким образом.
Ну там, например, вас UTP-шный сегмент, наверное, решение, которое симулирует атаки, точно не стоит заходить. Если вы лучше разбираетесь, то можно преднастроить все атаки, которые будут в рамках симуляции запущены, исключить то, что потенциально может как-то нарушить логику вашей инфраструктуры и какого-то негативного воздействия. Логируем действия, которые, собственно, продукт делает.
В отношении какого хоста, сколько по длительности занимала атака, в какое время она началась. И все это можно увидеть, чтобы понять, если, например, некая атака что-то сделала плохое с инфраструктурой, например, заблокировала учетную запись пользователя, в следующий раз вы просто эту атаку отключаете, и количество негативного воздействия уменьшается. Так как мы целимся в том, что будем запускаться на продуктивной среде, то, естественно, что в момент, когда мы атакуем какую-то машину, но она должна не стать менее защищённее относительно того, как она была до нашего присутствия на ней.
Поэтому мы всё вычищаем за собой, чистим ветки реестра, файлы удаляем, приводим систему к изначальному виду. Ну и можно задать временные рамки работы продукта. Например, вы хотите оставить его только на ночь, или, например, хотите оставить его только в рабочее время. То есть 9 до 6 работой, потом ставь на паузу продолжая работу со следующего дня с 9 часов. Так как техники по эксплуатации
уязвимостей в целом довольно шумные и средства защиты хорошо с ними работают, то мы посмотрели на опыт наших пентестеров и в целом пентестеров во всем мире. Часто самая топовая техника связана как раз таки с переиспользованием паролей. Находим какой-то пароль, либо генерируем его вручную, с этим очень хорошо справляется LLM, ты просто даешь на вход то, что сейчас такая-то дата, я работаю, я запущен в компанию, которая называется так-то, парольная политика там от 8 до 16 символов генерирует мне пароли, которые будут подходить под эти критерии.
Вот и частые пароли, тут вот на картинке зима 2024 с восклицательным знаком, вот часто это какие-то, не знаю, пароли с раскладкой, с английской раскладкой, с русским либо из-за того, что пользователи заставляют менять пароли очень часто, они пытаются упростить себе генерацию запоминаний этих паролей, поэтому там зачастую дата, когда пароль поменяли, и какая-нибудь приписка в виде названия компании, в виде имени или сезона текущего зима, осень, весна, лето. Естественно, атаки не брутфорсим, потому что это потенциально может привести к блокировке учеток в основном атаки вида спреинга, когда у нас есть много учетных записей и какой-то единственный пароль, мы пытаемся все эти учетные записи прогнать и попробовать пробрутить, чтобы с этими учетками уже попробовать пойти на какой-нибудь домен-контроллер и позабирать оттуда информацию. Ну и вытаскиваем пароли из браузеров, потому что часто там хранится много информации о том, какие веб-сервисы доступны.
Пытаемся на эти веб-сервисы тоже зайти. Вот, у меня все. Спасибо. Тоже очень интересный доклад. Спасибо, Ярослав. Тогда такие вопросы тут, к сожалению, или к счастью, каверзного не придумал. Такие, наверное, все будут больше бытовые.
А может и покажется каверзным вопрос. Я когда еще в Позитиве работал, была такая история со СУТП. Вот я несколько раз упомянул, что, в принципе, в организациях, особенно в ОСУТП, люди очень часто как бы бдят, и иногда, может быть, даже перебдят, я, соответственно, потом наблюдал тенденцию, что все-таки какие-то сканирования там MaxPatrol, другие средства стали пускать, но даже не в ОСУТП, даже в офисном там сегменте, там коммерческом, часто слышу такую историю, что вот вы придете там с пин-тестом, что-то там сломаете, а если там говорить об автоматических средствах, наверное, это еще больше людей триггерит. Вот как ты считаешь, это обоснованные такие, скажем так, страхи, сомнения или это все-таки больше из серии того, что перебдят люди? Это хороший вопрос на самом деле, потому что мы когда с нашими ребятами-пентестерами общаемся, они часто рассказывают как раз таки тот же скепсис от заказчиков, что они могут что-то негативное сделать, поэтому мы как раз с ними очень много консультируемся и спрашиваем, условно, какие рейд-лимиты для инструментов выставлять так, чтобы они не сделали какую-то дополнительную нагрузку на сеть, ничего не уронили, отказались от эксплуатации бинарных эксплойтов, которые часто дают крутой результат, однако бинарная логика, работа с памятью с большой вероятностью может что-то негативное на системе сделать, поэтому будем тестировать у себя на позитивской инфраструктуре сначала, посмотрим как это будет отрабатывать, если у нас наше испытание пройдет там на наших лабораториях, на нашей инфре, то будем пилотироваться у заказчиков, в которых не будут так скептически к этому относиться.
Посмотрим. Господа, вопрос из зала, вопрос, пожалуйста, микрофончик. Да, спасибо за презентацию, интересно было, у меня несколько вопросов. Ну, наверное, продолжая вот предыдущий вопрос, если были уже какие-то там пилоты, да, или внедрения, то какие инфраструктуры, какие сегменты вами рекомендуются как первоначальные, которые нужно покрывать басом? Я скажу по опыту заказчиков, которые задавали нам вопросы, типа вот откуда начинать, но зачастую говорят, если про себя говорят, то нам интересно начинать с пользовательского сегмента, потому что зачастую первый вектор за счет которого проникает в организацию это фишинг. Фишинг это пользовательский сегмент, рассчитан на пользователей, поэтому самый такой критичный для них это пользовательский сегмент.
Второе, что часто спрашивают, это из-за того, что приходят люди из организаций, которые проверяют эти организации, например, кеишные, они подключаются в любые сетевые розетки, которые доступны каждому пользователю. Это в основном принтеры и переговорки. То есть первый пользовательский и второй по приоритету принтерный и переговорный. Понятно, спасибо. И второй вопрос. Так как система довольно критичная с точки зрения возможностей и доступов, которые нужно от нее открывать, какие технические меры вы принимаете, чтобы, собственно, саму систему BaaS не взломали у вас? На самом деле, мне кажется, любые средства защиты должны хорошо хранить и прятать все свои данные. Условно, если мы с помощью нашей системы получим доступ в какой-нибудь DLP, где хранится абсолютно все, Ну, это ужасно критично, считайте, что всё, мы завладели всей инфраструктурой.
Аналогично с любыми другими продуктами. Там некоторые продукты, например, для них специально нужно делать привилегированную учётную запись в домен-админе. Если получить к ней доступ, то у тебя фактически открывается, опять же, весь периметр, ты можешь устанавливаться на абсолютно любые системы. Поэтому все те же меры, которые относятся к любому средствам защиты, которые нами точно будут соблюдаться, типа авторизация, хранение всех данных, которые мы получаем от симуляции.
Это, само собой, хороший вопрос. Понятно, спасибо. Еще вопросы из зала? Вопрос, пожалуйста, микрофончик. Организаторы, уважаемые, можно микрофон, тут вопрос. Далеко ушли. Спасибо, Арислав, за доклад, очень интересно.
Если ваше решение запускать в функционирующей системе, как аналитик SOC может отделить вашу условную легитимную деятельность от реальной нелегитимной деятельности, которая при невысокой вероятности может происходить в этот же момент? Зависит на самом деле от задач, которые вы решаете. Если вы, как аналитик SOC, сами запускаете этот продукт, чтобы препин-тестить себя, то, наверное, вы знаете, как система работает. Вы можете посмотреть по логу событий, где она находится, какие уязвимости она сейчас атакует, потому что мы логируем абсолютно все действия, которые есть. Если же вы ставите задачу посмотреть, как ваша команда аналитиков SOC как раз таки реагирует на все эти решения... Так, нет, я повторяюсь. Если вы не знаете о том, что идёт сейчас запуск этой системы, мы думаем в сторону того, чтобы, словно, была галочка, где можно поставить, ну, показывать, словно все запросы будут содержать некий какой-то параметр, по которому можно будет осознать то, что это делает наша система, а не кто-то другой.
Понял, спасибо. Ещё вопросы из зала? Если нет, тогда онлайн вопрос от Влада Бостард. Добрый день, Ярослав. Почему, по вашему мнению, классические баз с агентским способом все еще актуальны, либо это не так, ваше мнение? Мне кажется, они до сих пор актуальны, потому что точно закрывают вопрос оценкой покрытия средств защиты, но кажется, что автоматический пентест в этом плане просто немного дальше пошел. Он не проверяет то, насколько баз покрывает все техники, он проверяет, может ли баз проэксплуатировать и пойти дальше, и подсветить намного больше проблем средств защиты, нежели там какие-то отдельные хостовые. Я думаю, полный ответ. Окей, тогда еще вопрос. Соответственно, то, о чем говорили, когда не система у нас, условно говоря, там какой-то реальный пентест,
А, условно говоря, инфраструктура, где заказчик, клиент готов полный, так сказать, там спектр инструментов применить, чтобы посмотреть, что происходит. Очень часто важен фактор времени. Вот выходит Zero-Day, к нему, допустим, RCE. Насколько быстро в такие инструменты, по вашему мнению, по вашей практике, можно внедрить, соответственно, RCE-шки, Zero-Day и прочее? Насколько оперативно это можно сделать? Свежачок, так сказать. Мне кажется, у нас есть такой негласный таргет добавления уязвимостей за 12 часов для эксплуатации, и это как бы основа наша продукта – уметь обходить средства защиты. Поэтому на все трендовые новые популярные уязвимости мы должны реагировать намного быстрее, чем средства защиты, чтобы показывать хороший результат. Поэтому будем таргетироваться в максимально короткое время.
Однако здесь есть второй еще вопрос, то, что потенциальные уязвимости, которые будут появляться, не факт, что мы успеем их хорошо оттестировать, и будет ли заказчик запускать это на своей инфраструктуре, понимая, что это еще экспериментальный эксплойт, он может гипотетически нарушить логику его инфраструктуры. Как минимум 100 какой-нибудь. Окей, еще тогда один, как мне кажется, вот интересный вопрос, его уже частично на самом деле здесь затронули, по поводу, соответственно, человеческого фактора фишингов и прочее прочее вот я человек от этой темы может быть сейчас немножко далекий как выглядит именно так сказать боевое применение и развертывание всех этих методик с учетом человеческого факта то есть позволяют ли эти средства и ваша практика учитывать скажем так ошибки ошибки пользователя конечного заказчика то есть автоматический фишинг присутствует может быть какие-то другие методы обмана которые в комбинации с техническими методами автопин-теста работают или они не требуются? Хороший вопрос, на самом деле. В эту сторону не думали, потому что зачастую это как раз-таки покрывается услугами социотехнического тестирования или социотехнического тестирования или Red Team в целом
2024-12-13 20:30
