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

Эта статья — про несколько вещей, которые выглядят совершенно по-разному в зависимости от того, с какой стороны экрана ты сидишь. Будет полезно и аналитикам, которые ругают «криворуких вендоров», и разработчикам, которые не понимают, почему их идеальное правило ненавидят в SOC.

«Почему нельзя просто убрать ложные срабатывания»

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

Когда я сам сел писать детекты, вопрос развернулся на 180 градусов. Проблема не в том, что нельзя убрать конкретный фолз — можно, за пять минут. Проблема в том, что почти любое сужение правила, которое гасит ложное срабатывание, одновременно открывает щель для настоящей атаки с похожим поведением. Ты не «чинишь баг», ты каждый раз заново проводишь границу между «нормально» и «подозрительно» — а она размытая по своей природе.

Легитимный админский скрипт и действие атакующего на живой системе отличаются не так сильно, как хочется. Оба запускают процессы, оба лезут в сеть, оба работают с чужими файлами. Разница — в контексте и намерении, а namerenie в телеметрию не пишется. Так что каждое исключение — это маленькая ставка: «вот здесь я готов рискнуть, потому что легитимный сценарий слишком частый, чтобы им завалить SOC». Иногда ставка проигрывает. Это не халтура, это природа задачи.

Почему алерт приходит «сырым»

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

Со стороны разработки видно, что «приложить детали» — это архитектурное решение с ценой. Момент срабатывания правила и момент, когда собран весь контекст, — разные моменты. Правило должно сработать быстро, пока событие свежее, иначе теряется смысл. А обогащение — репутация адресов, история хоста, связи с другими алертами — требует походов в другие системы, и если делать это синхронно в момент детекта, ты кладёшь производительность всего пайплайна. Поэтому обогащение обычно вынесено отдельно и по времени, и по коду.

Хороший продукт эту пропасть закрывает — но это отдельная большая работа, которую снаружи не видно, а изнутри она съедает заметную часть ресурсов команды. Когда я это понял, мои претензии из SOC переформулировались из «вендор поленился» в «это дорого, и вот почему».

Приоритет алерта — это не про вас

Ещё одно прозрение. В SOC кажется, что уровень critical/high/medium — объективная характеристика угрозы. На деле приоритет — это компромисс, зашитый в правило человеком вроде меня, который понятия не имеет про вашу конкретную инфраструктуру.

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

Что бы я сказал себе-аналитику

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

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

И наоборот, себе-разработчику: помни, что на том конце твоего красивого правила сидит живой человек, у которого таких «красивых» правил двести штук за смену. Детект, который технически верен, но генерирует шум, — это не сработавшая защита, это ослепший аналитик. А ослепший аналитик пропустит ровно то, ради чего всё это затевалось.

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