Адаптация

Ну раз Нассиму Николасу Талебу можно одну из глав книги "Антихрупкость" позже расписать на целую книгу "Рискуя собственной шкурой...", не говоря уж о том, что во всех трех книгах, от Лебедя до Шкуры, он многократно повторяется, я решил, что мне тоже не зазорно развить более подробно тему необходимости постоянной адаптации детекторов, затронутую в предыдущей заметке.

Теоретически понимаемо и подтверждаемо практикой, что исправление Контекстных ложных срабатываний отнимает несравненно больше времени, чем первоначальное создание правила обнаружения (детектора). Причинами здесь могут быть:

• инфраструктурные изменения, например, появляется новый сервер или новый софт, особенно этого много в компаниях с множеством самописного ПО, а с учетом высокого уровня виртуализации серверных мощностей (тоже уже давно повсеместная практика), появление сервера совсем не проблема;
• изменение поведения пользователя - даже самые, казалось бы статичные роли, с минимальной креативностью, с достаточной постоянностью генерят аномалии, и часто надо поломать голову как правильно сделать фильтр, и есть ли такая возможность вообще (привет, UEBA!)
• периодические действия, которые лучше не фильтровать вообще, но тогда придется постоянно переспрашивать пользователя о легитимности - сюда часто попадают действия администраторов или разного рода специалистов по безопасности. К счастью, этот сценарий часто может быть неплохо автоматизирован: алерт летит не в SOC, а непосредственно пользователю, и он подтверждает легитимность кнопкой из почты или на каком-то портале (что по реализации одно и то же)

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

Ничто не вечно! Если мы с вами - поставщик услуги, как правило, мы не участвуем в процессе управления изменениями заказчика, тем более, нам неведомы кадровые изменения. Поэтому наши клиентские фильтры под инфраструктуру или под учетные записи пользователей могут (и будут!) устаревать. В лучшем случае, эти, уже ненужные фильтры, будут ничего не делать, но есть риск что они начнут фильтровать инциденты.

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

Все сценарии предусмотреть не удастся точно, да и "висяки" не нужны, поэтому фильтры надо пересматривать. Периодичность пересмотра зависит от потенциальной частоты изменения параметров, используемых в фильтре. На практике разные фильтры могут иметь разное TTL. При истечении TTL ответственному Detection Engineer-у прилетает задача на пересмотр и он как-то принимает решение, что фильтр все еще актуален.

Хорошим подспорьем для Detection Engineer-а будет инверсия фильтра - условие, обратное фильтру. Инверсию можно обернуть в самостоятельный запрос к телеметрии и периодически запускать - найденные данные представляют собой то, что фильтрует наш фильтр. Эти данные должны совпадать с первоначальной контекстной фолсой, о которой мы говорили в начале. Если пойманные инверсией данные не повторяют первоначальное контекстное ложное срабатывание - это серьезный повод пересмотреть фильтр. Если инверсия ничего не находит, очевидно, фильтр можно отключить.

Надеюсь, что в этой заметке мне удалось показать, что:

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