TGViewer
Channel Public Channel
НеДобрый SOC

НеДобрый SOC

@nedobrysoc

Практическая информационная безопасность глазами SOC-аналитика и пентестера. Расследования, мониторинг, атаки, защита, процессы и опыт из реальной практики.
Канал авторский и мнение автора не равно мнению компании, где работает автор.
Subscribers
50
Photos
14
Videos
0
Links
1
Recent Posts 20 shown
Post #28 22
АТАКУЮЩЕМУ БОЛЬШЕ НЕ НУЖЕН ВРЕДОНОСНЫЙ ФАЙЛ

Мы привыкли представлять атаку примерно одинаково.

Пользователь открывает вложение. На хосте появляется неизвестный файл. Антивирус замечает вредоносный код. EDR блокирует процесс. SOC получает алерт и начинает расследование.

В этой модели у атаки есть понятный объект.

Файл. Хеш. Сигнатура. Процесс, которого раньше не было.

Но что произойдёт, если атакующий ничего не принесёт с собой?
Post #27 26
КАК ПОЯВЛЯЕТСЯ СЛЕПАЯ ЗОНА

Обычно всё начинается вполне логично.
Сервисная учётная запись регулярно запускает PowerShell-скрипт. SIEM создаёт однотипные алерты, аналитики тратят время, администраторы жалуются на постоянные уточнения.
Команда решает убрать шум и добавляет учётную запись в белый список.

Срабатывания прекращаются. Очередь становится чище. Проблема выглядит решённой.

А потом проходит время.

Скрипт переносят на другие серверы. Права учётной записи расширяют. Меняется владелец системы. Первоначальная причина исключения остаётся где-то в старой заявке, которую уже никто не помнит.

Но само исключение продолжает работать.

Если учётные данные будут скомпрометированы, атакующий получит не только их привилегии. Он унаследует доверие, которое когда-то выдал SOC.
Теперь PowerShell запускает уже не администратор. Поведение изменилось, контекст изменился, риск изменился.
А SIEM продолжает молчать.

Он не сломан. Он точно выполняет просьбу команды не смотреть в эту сторону.

КОГДА ИСКЛЮЧЕНИЕ СТАНОВИТСЯ ОПАСНЫМ

Исключение не означает, что активность безопасна.
Оно означает, что мы решили её не анализировать.

Сами по себе исключения необходимы. Без них аналитики действительно могут утонуть в повторяющихся срабатываниях и перестать замечать важные сигналы.

Опасность начинается тогда, когда временное решение становится бессрочным.

У исключения нет владельца. Срок пересмотра не указан. Условие сформулировано слишком широко. Никто не проверяет, соответствует ли оно текущей инфраструктуре.

Так белый список постепенно превращается в архив старого доверия.

В нём остаются сервисные учётные записи, которые давно используются иначе. IP-адреса переходят другим системам. Каталоги меняют назначение. Административные инструменты обновляются, а исключения продолжают действовать так, словно вокруг ничего не произошло.

ДОВЕРИЕ К ОДНОМУ ПРИЗНАКУ

Особенно опасно строить исключение вокруг одного признака.
Имя пользователя не доказывает легитимность действий. Разрешённый процесс может использоваться не по назначению. Привычный путь ещё не означает, что файл внутри него безопасен.

Представьте два похожих исключения.

В первом случае SOC подавляет алерт для конкретного подписанного скрипта, который запускается определённой учётной записью на известном сервере в рамках ожидаемого задания.

Во втором — игнорирует любой запуск PowerShell от имени этой учётной записи.

Оба варианта уменьшают шум.
Но первый описывает нормальное поведение. Второй создаёт территорию, на которой почти любое поведение заранее считается нормальным.

Чем шире исключение, тем удобнее в нём спрятаться.

БЕЛЫЙ СПИСОК — ЭТО ИЗМЕНЕНИЕ ЗАЩИТЫ

Относиться к исключению нужно не как к технической настройке, а как к изменению логики обнаружения.

Команда должна понимать, какую активность она перестаёт видеть и почему считает это допустимым. У такого решения должен быть владелец, способный подтвердить его необходимость.

Должна существовать дата, после которой доверие будет пересмотрено, а не продолжено автоматически.

Важно сохранить и альтернативный способ наблюдения.
Если ожидаемый административный скрипт не должен создавать алерт, SOC всё равно может контролировать изменение самого файла, его запуск на необычном хосте или появление нетипичных дочерних процессов.

Убрать конкретный шум — нормально.

Отказаться от видимости поведения целиком — уже нет.

С ЧЕГО НАЧАТЬ ПРОВЕРКУ

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

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

Если никто не помнит причину, владельца невозможно найти, а срок действия нигде не указан — перед вами не управляемое исключение.

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

Иногда результат оказывается неприятным.
EDR ничего не блокирует. SIEM не создаёт алерт. Аналитик не видит активности.

Атакующий мог бы продолжать работу в зоне, которую команда сама сделала невидимой.

БЕЛЫЙ СПИСОК ТОЖЕ НУЖНО КОНТРОЛИРОВАТЬ

Каждое исключение — это обмен.
Мы уменьшаем шум, но принимаем риск что-то пропустить.
Этот обмен должен быть осознанным, ограниченным и обратимым.

Если у исключения нет владельца, срока действия и регулярной проверки, оно перестаёт быть способом настройки детекта.
Оно становится постоянным разрешением действовать там, куда SOC однажды решил не смотреть.

НеДобрый SOC

Когда заканчивается борьба с шумом — начинается управление слепыми зонами.

#SOC #SIEM #EDR #DetectionEngineering #BlueTeam #Кибербезопасность
Post #26 30
БЕЛЫЙ СПИСОК, В КОТОРОМ СПРЯТАЛСЯ АТАКУЮЩИЙ

Иногда детект не срабатывает не потому, что правило написано плохо.

Телеметрия поступает. Парсер работает. Агент на месте. Условия корреляции совпадают.
Но алерта нет.
Потому что несколько месяцев назад кто-то добавил исключение.
Post #24 39
Детект есть. Защиты нет. Почему правила SIEM нужно проверять атаками.

В матрице покрытия всё выглядит убедительно.

PowerShell — покрыт.
Credential Dumping — покрыт.
Создание службы — покрыто.
Подозрительная аутентификация — тоже покрыта.

Напротив каждой техники стоит зелёная отметка, а в SIEM действительно существует правило с подходящим названием.

Но сработает ли оно во время настоящей атаки?
Post #22 32
CMDB не спасёт SOC, если никто не знает, что он защищает

Представьте два одинаковых алерта.

На двух хостах обнаружен подозрительный запуск PowerShell с обфусцированной командой.

Одинаковая техника.
Одинаковая критичность детекта.

Одинаковый пользовательский контекст.
Только первый хост — тестовый стенд, который через неделю выведут из эксплуатации.

А второй — сервер, через который проходят платежи компании.

Для SIEM эти события могут выглядеть одинаково.

Для бизнеса — нет.
Post #21 47

This post (sticker, poll or similar) has no web preview. Open in Telegram

  • ❤ 1
  • 👍 1
  • 🔥 1
Post #20 53
SOC не может работать в вакууме. Зачем ему CTI

Можно построить SOC, подключить SIEM, EDR, NDR, настроить корреляции и собрать команду аналитиков.

На дашбордах будут алерты.
В очереди — инциденты.
В отчётах — показатели SLA.

Но откуда SOC узнаёт, что именно сегодня делают злоумышленники?

Какие техники они используют для первоначального доступа? Как закрепляются в инфраструктуре? Какими легитимными инструментами маскируют активность? Какие уязвимости эксплуатируют? Какие TTP характерны для группировок, атакующих именно вашу отрасль?

Если на эти вопросы некому отвечать, SOC начинает работать в вакууме.

Он хорошо обнаруживает то, что уже умеет обнаруживать. Но почти не понимает, насколько его возможности соответствуют реальной угрозе.

И вот здесь CTI становится не дополнительной функцией, а частью операционной модели SOC.
  • ❤ 1
  • 👍 1
  • 🔥 1
Post #19 41

Forwarded from АйТи Новация: Ваша безопасность - наша забота

🚀 ATN CSF 2026: регистрация открыта!

Кибербезопасность меняется быстрее, чем мы успеваем обновлять пароли. А значит, пора говорить о будущем — уже сейчас.
18 сентября в Краснодаре пройдет III Ежегодный фестиваль ATN CSF — событие для тех, кто строит цифровую защиту бизнеса, государства и критической инфраструктуры.

В этом году мы предлагаем вместе разобраться в одном из самых острых вопросов кибербезопасности: «Человек vs машина: кто защищает лучше?»

На фестивале обсудим:

❤️применение ИИ в кибербезопасности;
❤️защиту критической инфраструктуры и персональных данных;
❤️развитие российских технологий и импортонезависимых решений;
❤️изменения в законодательстве и требования регуляторов;
❤️реальные кейсы, живые дискуссии и практический опыт ведущих экспертов отрасли.

Уже этой осенью попробуем ответить на главный вопрос, сможет ли ИИ полностью заменить человека, или лучшая защита — это их совместная работа?

📅 18 сентября 2026
📍 Краснодар
👉
Стать участником ATN CSF 3
Post #18 44

This post (sticker, poll or similar) has no web preview. Open in Telegram

  • ❤ 1
  • 👍 1
  • 🔥 1
Post #17 49
29 минут до lateral movement: почему скорость SOC стала частью защиты

Представьте обычную ночную смену.

На рабочей станции срабатывает детект. Алерт попадает в SIEM, ждёт корреляции, затем оказывается в очереди аналитика. Аналитик открывает карточку, проверяет пользователя, собирает контекст, пишет старшему смены. Старший смены ищет владельца системы и согласовывает блокировку.

Процесс работает. Все роли определены. Все действия описаны в регламенте.

Есть только одна проблема: атакующий уже ушёл с первого хоста.

По данным CrowdStrike, среднее время от первоначального компрометации до начала горизонтального перемещения — breakout time — сократилось до 29 минут. Самый быстрый зафиксированный случай занял 27 секунд.

Это не значит, что каждая атака через полминуты охватит всю инфраструктуру. Но это хорошо показывает разрыв между скоростью атакующего и скоростью принятия решений внутри SOC.

Пока защитники создают тикет, злоумышленник проверяет доступные учётные данные.

Пока идёт эскалация, он изучает домен.

Пока владелец системы решает, можно ли изолировать хост, атакующий уже использует полученный доступ на другом узле.

И вот здесь заканчивается красивый процесс на бумаге и начинается реальная проверка зрелости SOC.
  • ❤ 1
  • 👍 1
  • 🔥 1
Post #16 45
Хватит ждать алертов

Давайте начну с неприятного факта. Медианное время нахождения атакующего в сети до обнаружения (dwell time) по данным разных отчётов по-прежнему измеряется неделями, а в ряде отраслей — месяцами. И это среднее по индустрии, а не «у отстающих». Это в компаниях, где стоят EDR, SIEM, антивирусы, есть SOC-команды.

Как так получается?

Очень просто. Профессиональный атакующий не будет запускать mimikatz «в лоб» и генерировать красный алерт. Он будет использовать штатные утилиты — PowerShell, WMI, PsExec, планировщик. Будет двигаться медленно. Будет закрепляться там, где вы не смотрите — в задачах планировщика на файловом сервере, в WMI Event Subscription, в теневых копиях. Будет ждать окно для эксфильтрации в момент плановой активности, чтобы утонуть в фоновом трафике.

Ваш EDR его не поймает. Он на это не рассчитан.

EDR прекрасно ловит известное. Прекрасно ловит наглое. Прекрасно ловит быстрое. Но именно медленную, тихую, использующую вашу же инфраструктуру активность он часто пропускает — потому что для его моделей поведения это выглядит как обычная работа администратора.

Именно на этом стыке появляется Threat Hunting.

Что такое Threat Hunting на самом деле

Начну с того, чем он не является.

Threat Hunting — это не «регулярно смотреть в SIEM».

Не «запустить готовое правило и посмотреть, что выпадет».

Не «проверить логи после инцидента».

Threat Hunting — это проактивный поиск следов компрометации, которых ещё нет ни в одном сработавшем правиле. Хантер работает от гипотезы: «Я исхожу из того, что нас уже взломали. Если это так — где бы я закрепился на месте атакующего? И как бы это выглядело в моих логах?».

Ключевое слово — гипотеза. Хантер не ищет «что-нибудь плохое в целом» (это бесконечное и бесполезное занятие). Хантер формулирует конкретное предположение и проверяет его на своих данных.

Как это выглядит на практике

Одна охота обычно строится по трём шагам.

Шаг первый: гипотеза. Не «поищу подозрительное», а конкретно: «в моей инфраструктуре могут использовать DLL side-loading через легитимные подписанные приложения для закрепления». Гипотезу удобно брать из MITRE ATT&CK — там уже разложены техники по фазам атаки и по группировкам. Выбираете технику, которая релевантна для вашего профиля риска, и строите вокруг неё гипотезу.

Шаг второй: сбор улик. Идёте в свои логи и ищете паттерны, которые указывают на эту технику. Для DLL side-loading — это, например, загрузка библиотек из нетипичных путей (C:\Users\Public\, %TEMP%\), необычные родительские процессы легитимных бинарников, подписанные утилиты, стартующие из пользовательских директорий. Sysmon с нормальной конфигурацией здесь незаменим — он видит то, что штатный лог Windows просто не пишет.

Шаг третий: раскрутка. Вы находите тысячу легитимных срабатываний паттерна и один-два странных. Начинаете разматывать: кто запустил, откуда, что за процесс, куда он потом ходил в сеть, какие ещё процессы породил, какие файлы читал. На этом шаге охота либо превращается в инцидент, либо в новое знание о своей инфраструктуре («ага, вот это оказывается наш штатный installer, который так себя ведёт, надо запомнить»).

Оба исхода — успех. Инцидент — это очевидно. Но и «пустая» охота — тоже успех, потому что она даёт нормальность, от которой в следующий раз будет проще отталкиваться.

Почему это важно для SOC — три причины помимо очевидной

Первая — понятная: хантер находит то, что не видят автоматические правила. Это его прямая задача.

Вторая — менее очевидная: каждый успешный hunt должен заканчиваться новым правилом детекта. Хантер, нашедший закрепление через WMI Event Subscription в первый раз, пишет правило, которое поймает следующий раз автоматически. Threat Hunting — это R&D для вашего SOC. Он производит новые детекты быстрее, чем любой внешний вендор правил корреляции. Причём эти детекты будут заточены именно под вашу инфраструктуру и вашу нормальность.

Третья — самая недооценённая: хантинг вычищает мозги аналитику. Ничто так не заставляет по-настоящему понять свою сеть, как пара часов ручного копания в логах. Аналитик, который два месяца поохотился, начинает видеть свою инфраструктуру не как набор источников в SIEM, а как живой ландшафт с зонами риска, привычками, узкими местами. Такой человек начинает лучше обрабатывать и обычные алерты — потому что у него есть контекст.

«У нас нет людей на охоту»

Это самая частая отговорка. И самая опасная.
Правда в том, что вам не нужен выделенный threat hunter с зарплатой senior-инженера. Нужны четыре часа в неделю у одного человека из существующей команды.

Начните с малого. Возьмите одного аналитика с достаточным опытом. Дайте ему один спокойный слот в неделю — например, четверг с 10 до 14. И одну задачу: «эта неделя — гипотеза про кражу токенов доступа через LSASS memory dumping». Всё. Не «пять техник», не «полный обход инфраструктуры». Одна гипотеза, четыре часа.

Что вы получите в первые несколько недель:

— скорее всего, ни одного настоящего инцидента (это нормально)

— несколько новых правил детекта под вашу инфраструктуру

— карту слепых зон, где логов не хватает даже чтобы построить гипотезу

— аналитика, который начал думать про инфраструктуру шире

Если через полгода вы всё-таки поймаете реальную компрометацию — она окупит весь этот эксперимент. Если нет — вы получили улучшенный SOC и человека, который перестал выгорать на монотонных алертах.

Что не работает

Пару раз я видел, как threat hunting внедряли неправильно. Пусть эти истории послужат вам предостережением.

Первая ловушка — «охота на всё сразу». Команда садится и решает «а давайте прогоним весь MITRE». Через три недели все выгорают, найдено 0.5 инцидента, программу закрывают. MITRE — это карта, а не список задач. Из него надо выбрать релевантное, а не идти подряд.

Вторая ловушка — охота без документации. Хантер что-то нашёл, разобрал у себя в голове, закрыл, пошёл дальше. Через два месяца никто не помнит, что именно проверяли, какие гипотезы были отброшены, какие правила были рождены. Threat Hunting без журналирования — это дорогая любительская активность, а не процесс.

Третья ловушка — охота ради KPI. Как только вы поставите «10 гипотез в квартал» в мотивацию, вы получите десять формально закрытых пустышек. Threat Hunting — это качество, а не количество.

Финал

Тот факт, что у вас стоит EDR, ещё не означает, что вас нельзя взломать медленно. Скорее наоборот — чем дороже EDR, тем сильнее иллюзия защищённости и тем меньше желания копать самому.

Threat Hunting — это не роскошь топ-tier SOC. Это гигиена. Как чистка зубов. Не гарантирует, что не будет проблем, но резко снижает вероятность запущенных случаев.
Начните с четырёх часов в четверг.
 
НеДобрый SOC
Когда заканчиваются красивые отчёты — начинается настоящая работа.

#SOC #SIEM #DetectionEngineering #BlueTeam #Кибербезопасность #Threat_Hunting
  • ❤ 1
  • 🔥 1
Post #15 45
Threat Hunting — не роскошь, а гигиена

Большинство современных SOC устроены как «залы ожидания».
Мы сидим и ждём, пока SIEM или EDR загорится красным.
Проблема в том, что серьёзные атакующие давно научились обходить эти красные лампочки.
  • ❤ 1
  • 👍 1
  • 🔥 1
Post #14 52
Телеметрия против логов. Почему большинство SOC тонет не в атаках, а в собственных данных

Коллеги, иногда мне кажется, что главная задача SIEM-вендоров — убедить нас хранить как можно больше бесполезных логов.

И знаете что?

Мы сами с удовольствием за это платим.

Сегодня большинство SOC живет по очень простой логике:

«Подключите еще один источник.»
«Давайте соберем вообще всё.»
«А вдруг пригодится.»

В какой-то момент SIEM превращается в цифровую свалку, куда летит всё подряд: события Windows, логи файрволов, прокси, почты, VPN, антивирусов... Если устройство умеет что-то писать — значит, это обязательно должно попасть в SIEM.

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

Звучит впечатляюще.

Только вот во время расследования очередного инцидента выясняется знакомая картина:

«Да, событие было... Просто мы его не заметили.»

И проблема здесь не в SIEM.

Проблема в том, что многие до сих пор путают логи и телеметрию.

Лог — это просто запись о событии.

Телеметрия — это данные, которые помогают обнаружить атаку.

На первый взгляд разница небольшая. На практике именно она определяет, будет ваш SOC расследовать инциденты или бесконечно листать миллионы событий.

Я регулярно вижу одну и ту же картину.

В SIEM лежат миллиарды событий об успешных входах пользователей. Они занимают место, стоят денег и практически никогда никому не нужны.

Зато информации о том, какой процесс запустил PowerShell, кто породил подозрительное сетевое соединение или почему пользователь внезапно получил административные права, — нет.

Мы прекрасно видим движение пакетов по сети, но совершенно не понимаем, что происходит на конечной станции.

Именно так появляются слепые зоны.

Самое интересное, что многие компании искренне считают огромное количество логов признаком зрелого SOC.

На мой взгляд — всё наоборот.

Зрелый SOC умеет говорить «нет».

Нет бесполезным данным.

Нет событиям, которые никогда не участвуют в детектах.

Нет принципу «соберем всё, потом разберемся».

Перед тем как подключить очередной источник, я всегда задаю простой вопрос:

Какую технику злоумышленника мы сможем обнаружить благодаря этим данным?

Если ответа нет — зачем мы вообще их собираем?

Есть еще одна вещь, которую многие недооценивают.

Контекст.

Сам по себе IP-адрес почти ничего не говорит аналитику.

Но если вместе с событием сразу приходит информация, что это контроллер домена, пользователь из финансового отдела, а IP уже замечен в Threat Intelligence, расследование начинается не с поиска информации, а сразу с принятия решений.

Вот это уже телеметрия.

И чем дальше, тем сильнее я убеждаюсь в одной мысли.

Через несколько лет мы перестанем мериться количеством собранных логов.
Главной ценностью станет качество данных.

Победит не тот SOC, который собирает больше всех.

Победит тот, который собирает только то, что действительно помогает поймать злоумышленника.

И напоследок вопрос, который я бы задал каждому руководителю SOC.

Какой процент данных, которые вы храните в SIEM, реально используется хотя бы в одном правиле детекта?

Есть ощущение, что ответ многих неприятно удивит.

НеДобрый SOC
Когда заканчиваются красивые отчеты — начинается настоящая работа.
 
#SOC #SIEM #DetectionEngineering #BlueTeam #Кибербезопасность
  • 👍 2
  • ❤ 1
  • 🔥 1
Post #13 50
Мы привыкли считать, что чем больше логов собирает SOC, тем лучше он защищен.
Но что, если именно эта логика делает нас слепыми?
Мы тратим миллионы на хранение данных, подключаем всё новые источники, расширяем SIEM... а потом не можем заметить атаку, которая была прямо перед глазами.
В следующем посте хочу поговорить о вещи, которую, на мой взгляд, многие недооценивают.
Почему будущее SOC — не в логах, а в телеметрии.
Post #12 67
Смерть сигнатуры и эра поведенческих моделей
Много лет мы строили SOC вокруг довольно простой идеи: любую атаку можно описать. Если злоумышленник сделает действие X, SIEM сгенерирует алерт Y. Мы писали правила корреляции, обновляли базы сигнатур и постепенно убеждали себя, что именно так и должна работать защита.

В 2026 году эта модель окончательно перестала быть основной.

Не потому, что сигнатуры стали плохими. Они по-прежнему прекрасно находят известные угрозы. Просто современные атаки всё реже выглядят как что-то заранее известное.

Посмотрите на то, как сегодня работают злоумышленники. Зачем приносить собственный вредоносный инструмент, если в инфраструктуре уже есть PowerShell, WMI, Bash и десятки штатных утилит? Концепция Living off the Land давно стала повседневностью. Для операционной системы всё выглядит так, будто системный администратор просто выполняет свою работу.

Добавьте к этому полиморфизм и генеративный ИИ. Современный вредоносный код способен менять структуру буквально при каждом запуске, а инструменты на базе LLM позволяют быстро адаптировать эксплойты под конкретную цель. Пытаться описывать подобные вещи сигнатурами — примерно как составлять фоторобот человека, который меняет лицо каждые несколько секунд.

И даже если новая техника всё-таки будет обнаружена исследователями, времени почти не остается. Сегодня между публикацией новой уязвимости и её массовой эксплуатацией проходят не дни, а часы. Пока вендор выпустит новую сигнатуру, SOC вполне может уже заниматься расследованием последствий компрометации.

Поэтому главный вопрос сегодня уже не в том, что делает атакующий. Гораздо важнее понять, как ведет себя пользователь, процесс или сервер.

Именно здесь начинается поведенческий анализ.


Любой зрелый SOC должен понимать, что является нормой для инфраструктуры. Если сервер базы данных годами общался исключительно с сервером приложений, а однажды ночью неожиданно начинает устанавливать соединения с IP-адресом в другой стране, причина для расследования возникает не потому, что кто-то заранее написал соответствующее правило. Причина в том, что подобное поведение никогда раньше не встречалось.

Точно так же перестают иметь смысл отдельные события. Один подозрительный процесс редко означает компрометацию. Но если пользователь входит в систему в непривычное время, затем скачивает неизвестный файл, после этого запускает процесс с повышенными привилегиями и почти сразу начинает устанавливать сетевые соединения наружу, перед нами уже не набор случайных алертов, а вполне осмысленная история атаки. Именно способность связывать отдельные события в единый сценарий отличает современный детектинг от классического набора сигнатур.

Не менее полезным становится и скоринг сущностей. Вместо того чтобы разбирать тысячи независимых уведомлений, аналитик начинает видеть общий уровень риска для пользователя или хоста. Когда рейтинг активности администратора за короткое время взлетает практически до максимума, становится очевидно, куда нужно смотреть в первую очередь.

В этот момент многие обычно говорят: «Все это красиво, но у нас нет денег на UEBA».

Именно здесь маркетинг начинает побеждать здравый смысл.

Нас годами убеждали, что поведенческий анализ невозможен без дорогой платформы с искусственным интеллектом и машинным обучением. На практике UEBA — это прежде всего методология. Хороший продукт способен существенно облегчить работу, но сама идея поиска аномалий прекрасно реализуется и на обычном SIEM.

Начать можно буквально завтра.

Самый простой путь — постепенно формировать представление о нормальном поведении критичных систем. Практически любой SIEM умеет работать со справочниками и lookup-таблицами. Если сервис резервного копирования всегда запускает один и тот же набор процессов, то появление любого нового процесса под этой учетной записью уже становится хорошим поводом для проверки. То же самое касается административных доступов. Если администратор годами подключается только с нескольких рабочих станций, неожиданная авторизация с обычного пользовательского ноутбука — это уже поведенческая аномалия.

Не менее полезно отказаться от поиска конкретных событий и начать анализировать статистику. Сервер базы данных может ежедневно передавать около гигабайта данных, и это совершенно нормально. Но если в какой-то день объем исходящего трафика увеличивается в десятки раз, SIEM вполне способен заметить подобное обычным агрегирующим запросом. Для обнаружения возможной эксфильтрации вовсе не обязательно использовать сложные алгоритмы машинного обучения.

Еще один мощный инструмент — анализ последовательностей событий. По отдельности создание нового пользователя, добавление его в группу Domain Admins или очистка журналов могут оказаться абсолютно легитимными действиями. Но если всё это происходит в течение нескольких минут сразу после нетипичного входа администратора, вероятность настоящего инцидента становится крайне высокой.

И, конечно, нельзя не вспомнить Sysmon. За годы работы он так и остался одним из самых полезных бесплатных инструментов для построения качественной телеметрии. Именно благодаря ему становится видно не просто запуск cmd.exe, а весь контекст процесса: кто его породил, какие команды выполнялись, какие сетевые соединения появились после запуска. Именно такой уровень детализации и превращает обычные журналы событий в основу для поведенческого анализа.

Если только начинаете двигаться в эту сторону, не пытайтесь сразу профилировать всю компанию. Намного разумнее сосредоточиться на привилегированных пользователях. Именно они чаще всего становятся целью атакующих и именно для них проще всего описать нормальную модель поведения: привычные рабочие часы, типовые инструменты, постоянные хосты и характерные административные действия. Уже этого достаточно, чтобы резко повысить качество обнаружения компрометаций.

Смерть сигнатур — это вовсе не трагедия. Это естественная эволюция нашей профессии.

Сигнатуры никуда не исчезнут. Они останутся важным элементом защиты, но перестанут быть ее фундаментом. Побеждать будет тот SOC, который научится понимать поведение своей инфраструктуры, а не просто искать совпадения с заранее написанными правилами.

И, пожалуй, именно это сегодня становится главным навыком современного инженера по детектированию.

НеДобрый SOC
Когда заканчиваются красивые отчеты — начинается настоящая работа.
  • ❤ 1
  • 👍 1
  • 🔥 1
Post #11 55
Смерть сигнатуры и эра поведенческих моделей

SOC-детектинг не работает без модели поведения: почему сигнатуры окончательно умерли в 2026 году
  • ❤ 1
  • 👍 1
  • 🔥 1
Post #10 64
Управление инцидентами — почему это не про тикеты, а про выживание

В одном из прошлых постов я высказал мысль, что без процессов SOC — это просто дорогой телевизор, который показывает шум. Сегодня начинаем глубокое погружение. И первый на очереди — Процесс управления инцидентами (Incident Management).

Казалось бы, что тут обсуждать? У всех есть тикет-система, все умеют нажимать кнопку «Create Incident». Но вот парадокс: у 80% команд, которые я видел, «управление инцидентами» заканчивается там, где начинается реальная работа. Они управляют тикетами, но не инцидентами.

В чем разница?
Управление тикетами — это про заполнение полей, соблюдение SLA на «первый ответ» и красивую статистику для руководства. Это бюрократия в чистом виде.
Управление инцидентами — это про то, как ваша система безопасности реагирует на угрозу, локализует её и извлекает уроки. Это кровеносная система SOC. Если она забита тромбами из ненужных согласований или, наоборот, дырявая как решето — ваш SOC умрет при первой же серьезной атаке.

Анатомия провального процесса:
1. «Инцидент ради инцидента». Аналитик создает тикет на каждый чих SIEM, потому что «так положено». В итоге в системе 500 открытых инцидентов, из которых 499 — ложноположительные сработки (False Positive). Реальная атака просто тонет в этом мусоре.
2. Отсутствие жизненного цикла. Инцидент создается, а дальше... тишина. Никто не знает, в каком он статусе, кто над ним работает и что было сделано. Это не процесс, это черная дыра.
3. Формализм вместо контекста. Тикет содержит заголовок «Suspicious Activity» и ссылку на лог. Всё. Аналитик следующей смены тратит час, чтобы просто понять, о чем вообще шла речь.

Как выглядит здоровый Incident Management в 2026 году?

Процесс должен отвечать на три главных вопроса: Что происходит? Что мы с этим делаем прямо сейчас? И как сделать так, чтобы это не повторилось завтра?

Классификация и Приоритизация (Triage)

Ваш процесс должен четко определять: что мы считаем инцидентом, а что — событием ИБ. Не каждый алерт — инцидент. Инцидент — это когда подтверждено нарушение политики или есть реальная угроза.

Практический совет: Внедрите «Матрицу критичности». Приоритизация должна опираться на два фактора: Критичность актива (Asset Criticality) и Уровень угрозы (Severity). Взлом ноутбука курьера (Low Asset) и взлом сервера БД (High Asset) — это разные инциденты по приоритету, даже если техника атаки (например, Mimikatz) одна и та же.

Четкие фазы жизненного цикла (NIST/SANS style)
• Detection & Analysis: подтверждаем, что это не фантомные боли SIEM. Здесь аналитик должен собрать «доказательную базу»: хэши, IP, логи процессов.
• Containment (Локализация): Это самая важная фаза. Ваша цель — остановить «кровотечение».
◦ Совет: Имейте заранее согласованные «аварийные кнопки». Например: «SOC имеет право блокировать учетную запись без согласования, если подтвержден Brute Force». Если аналитик должен ждать три часа одобрения от начальника ИТ, чтобы изолировать зараженный хост — у вас нет процесса реагирования.
• Eradication & Recovery: вычищаем следы и возвращаем бизнес в строй. Здесь мы удаляем веб-шеллы, меняем пароли, восстанавливаем данные из бэкапов.
• Post-Incident Activity: закрываем тикет только после того, как проведен разбор полетов.

«Золотой стандарт» карточки инцидента

Чтобы ваш процесс не превратился в свалку, каждый инцидент должен содержать:
• Executive Summary: кратко для людей (что случилось и каков риск).
• Timeline: хронология событий (когда началось, когда обнаружили, когда локализовали).
• Evidence: ссылки на конкретные события в SIEM/EDR.
• Actions Taken: что именно сделал аналитик. «Посмотрел логи» — это не действие. «Заблокировал IP на FW, изолировал хост через EDR» — это действие.

Практический чек-лист: Здоров ли ваш процесс?
Попробуйте честно ответить на эти вопросы:
1. Знает ли аналитик L1, что ему делать, если он увидел шифровальщик в 3 часа ночи в субботу? (Без звонка начальнику).
2. Можете ли вы за 1 минуту выгрузить список всех инцидентов, связанных с конкретным пользователем за последний месяц?
3. Есть ли у вас статус «Resolved», который отличается от «Closed»? (Разница в том, что угроза устранена, но разбор еще не закончен).
4. Связаны ли ваши инциденты с техниками MITRE ATT&CK?

Главный совет: Начните не с покупки дорогой IRP/SOAR системы, а с рисования схемы на доске. Если вы не можете объяснить процесс управления инцидентом новому аналитику за 10 минут без использования названий кнопок в софте — у вас нет процесса.

Управление инцидентами — это дисциплина. Это умение всей команды действовать как единый механизм в условиях стресса. Если ваш процесс — это просто «создать тикет в Jira», то вы не SOC, вы — секретарь хакера, который старательно записывает его успехи.


НеДобрый SOC
Когда заканчиваются красивые отчеты — начинается настоящая работа.
  • 🔥 2
  • ❤ 1
  • 👍 1
Older posts →

About this channel

How can I read @nedobrysoc without a Telegram account?
TGViewer shows the public web preview Telegram publishes for НеДобрый SOC: recent posts, photos, videos and the subscriber count, with no app, login or account.
How many subscribers does НеДобрый SOC have?
НеДобрый SOC (@nedobrysoc) has 50 subscribers on Telegram, refreshed roughly every 30 minutes.
Does НеДобрый SOC know I viewed it here?
No. Public channel previews carry no viewer identity, and TGViewer has no accounts or tracking of what you look up.
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →