Зачем нам это знание... и почему нельзя без него обойтись
При расследовании инцидентов есть несколько ключевых моментов этого процесса для аналитиков, на которые в данной статье мы обратим внимание – это корректность самого расследования, верная категоризация произошедшего, а также приоритет. Грамотно расставленные приоритеты, а именно, правильно рассчитанная критичность инцидента, в значительной степени влияет на скорость принятия решений аналитиком и на эффективность его работы в целом.
SOC представляет собой набор людей и процессов, который, подобно живому существу, постоянно развивается и эволюционирует. Без этого сложно представить себе команду расследования. И понятная категоризация, в данном случае – понятная система метрик и понятий – помогает выстроить еще и те процессы, которые начинаются тогда, когда расследование завершено. Речь пойдет о подготовке к процессу lessons learned, или о пост-инциденте: в правках и тюнинге могут нуждаться плейбук, регламент, а зачастую и автоматизация – к примеру, может потребоваться донастройка источника или SIEM. И как раз чтобы знать, куда смотреть, на что обращать внимание, аналитик, проводящий подобную работу, руководствуется результатами предыдущих этапов – категоризацией инцидента в разрезе было или не было, выявлено правильно или неправильно.
От флага, полученного на этапе реагирования и расследования, может зависеть многое – как время аналитика, так и область поиска ошибки с дальнейшим ее исправлением.
Понимание, в какой области находится проблема, как с ней разбираться и как к ней подступиться, даже то, в какой системе эта проблема находится – ко всему этому можно прийти, разбирая случаи подтвержденных/не подтвержденных инцидентов и false positive сработок.
Откуда берутся false positives?
Начнем разматывать клубок с того, что вообще в природе инфраструктуре может породить ложноположительный инцидент. Оттолкнемся от того, что предстоит чинить на этапе пост-инцидента:
Проблемы настроек. Здесь речь может идти как об источнике данных, так и о SIEM или любой другой системе, генерирующей инциденты (TIP, UEBA и проч.).
Источник. Зачастую неправильная настройка источника порождает поток некорректных данных или данных правильных, но переданных с ошибкой – к примеру, дубли логов, приходящие несколько раз на коррелятор.
СЗИ. Бывает и так, что алерт, который нашелся у антивируса, DLP или WAF, на самом деле стал результатом сбоя или неправильной интерпретации входных данных.
SIEM. Наверное, самый частый случай – «фолзящие» правила корреляции: тут не тот временной диапазон, там не та частота событий – и у нас в SOAR или IRP целый набор инцидентов, которым предстоит уйти в папку false positive.
Отсутствие угрозы как таковой. Тут есть несколько вариантов:
Расследование привело к тому, что субъектом действия выступал легитимный пользователь – инцидент, по сути, не подтвердился. Действия пользователя были правомерными, но паттерн этих действий непреднамеренно совпал с поведением злоумышленника. Такое бывает и с лучшими из нас, когда после отпуска сам собой забывается пароль.
Действие было легитимно, но одновременно с этим отсутствовало какое-либо уведомление со стороны субъекта (например, когда речь идет о сканировании, инициированном коллегами из ИТ), и своевременно не был наполнен список исключений для правил.
Произошедший инцидент был вызван учениями, тестированием нового правила.
Во всех этих случаях алгоритм проверки примерно одинаков, а вот способы устранения проблемы могут сильно разниться.
Как находят и как трактуют false?
Существуют и best practice, и целые методики работы с FP, но можно сказать и проще: в первую очередь стоит поискать доказательства сработки – проверить логи источника, парсинг их для коррелятора, даже задать пользователю прямой вопрос. Нередко в SOC выделяют отдельный процесс и ресурсы под отработку и тестирование правил, написание use case – правила проходят тщательную проверку на тестовых данных, прежде чем отправиться в боевую систему.
С трактовкой же все не так однозначно.
Что в документах?
На бумаге все очевидно, прозрачно и просто: существуют настоящие угрозы или их отсутствие. Первое представляет собой true positive – подтвержденный инцидент, второе же – не существующий трафик, результат ошибок настроек, некий дополнительный шум, вызванный некорректными пороговыми значениями, если речь идет об адаптивной системе. В нескольких словах, false – это то событие, которого на самом деле не было. Здесь и начинаются приключения.
А как предлагают трактовать false positive из коробки вендоры SOAR/IRP?
Несколько вариантов на выбор:
Дублирование флага от SIEM – а этот флаг проставляется вручную.
Конструктор из различных свойств карточки инцидента, иногда добавляется шаг подтверждения и дополнительный флаг, отличный от FP.
Иная метрика опасности угрозы, основанная на скоринге или критичности.
Отдельный флаг для ошибки в правилах корреляции – и отдельный коробочный сценарий.
Нередко SOC или конкретным заказчикам не хватает таких метрик и трактовок, и они просят добавлять свои.
Что настроит интегратор?
Интегратор может приходить как со своей экспертизой, так и на конкретное ТЗ для уже существующих процессов и регламентов. Экспертиза будет включать в себя и рекомендации регуляторов, и богатый проектный опыт, и некое собственное видение проблемы. Вероятнее всего флага будет два – FP и подтверждение, оно же легитимность – на это и будут опираться сценарии.
Как у заказчиков?
Со временем (или даже сразу) количество понятий перерастает в целый «зоопарк». Какие мы встречали флаги в карточках, как они могли быть выявлены и какое предлагалось реагирование:
Не угроза. Произошедшее произошло, но никаких рисков для заказчика это событие не несет – им можно пренебречь и закрыть инцидент с этим флагом, а время и ресурсы бросить на что-то более существенное. Как ставится этот флаг:
По скорингу активов. Произошедшее могло не быть критичным, могло быть, но место возникновения инцидента настолько не критично для организации или не влияет на процессы и общую безопасность, что инцидент и сам теряет свою значимость.
Иные скоринги, к примеру, результат проверки вредоносного ПО: если score такого ПО меньше единицы (или любого другого порога), то происшествие считается незначительным и не заслуживает внимания. По аналогии эту логику можно экстраполировать и на WAF (некритичный сегмент, некритичная уязвимость) и на иные СЗИ.
Дубликаты. Множественные оповещения об одной и той же сработке иногда помечаются «в лоб» - вердиктом «дубликат», а иногда закрываются с меткой false positive. В целом, аргументы есть для обоих понятий: более прозрачный вердикт поможет в дальнейшем при сборе статистики и построении отчетности, так как даст понимание о доле таких инцидентов от общего числа, а ошибка генерации инцидентов говорит о сбое и о том, что на самом деле в указанное время на точке сбора событие на источнике не произошло.
Нелегитимность/легитимность. Такая отметка дает оценку действию пользователя, а не самому инциденту, и вполне уживается на карточке с флагом FP. По сути, и правило корреляции может быть настроено верно, и события пришли такие, как ожидали, но сработал человеческий фактор, и используемые в правилах корреляции списки исключений не заполнились (например, запланированная смена привилегий для пользователя отобразилась как инцидент, т.к. не было связанной с мероприятием служебной записки) или субъект предполагаемой атаки просто делал свою работу. Оценка характера действия субъекта в рамках процесса пост-инцидента позволяет более четко и качественно описать сценарии тестирования правил в дальнейшем.
Разнообразные ошибки. Очень редко они появляются в виде каких-либо флагов, но вот в виде развилки дерева принятия решений – наверняка будут. Ведь в зависимости от контекста и характера ошибок определяются действия по их устранению, и опять же, это полезно для статистики:
Ошибка корреляционного правила. Самая популярная проблема, требующая отдельного внимания. Важно определять именно эту ошибку не столько для статистики, сколько для сценария.
Ошибка источника. Призрачные логи, неправильное время и сбои при передаче – все это здесь.
Ошибка парсинга. Неправильный маппинг полей, некорректное заполнение карточки – и вот даже протестированное и надежное правило корреляции начнет ошибаться на неверных вводных данных.
Учения и тесты. Ошибочно попавшие в общий зачет события и инциденты, которые, с одной стороны, по всем параметрам – опасная сработка, а с другой – эмуляция реальных угроз. В таком контексте заказчики нередко переигрывают FP в обратную сторону, от чего может возникать путаница – нам встречались инциденты-симуляции, отмеченные как FP только потому, что результат не совпал с предполагаемым в use case.
аким образом, перед SOC в процессе расследования стоит непростая задача по поиску странного существа, по сути кадавра от мира ИБ – true false positive, настоящего ненастоящего инцидента, который может принимать любые облики и трактовки. На этапе реагирования критически важно правильно установить этот флаг, так как в дальнейшем это влияет на выбор пути для процесса lessons learned: что чинить в первую очередь, с кем работать дальше и как преобразовать связанные процессы.
А можно отдать выявление false positive инцидентов на откуп AI?
Можно попробовать, но задачка непростая.
Как в целом можно предлагать искусственному интеллекту предсказывать, произошел или нет инцидент, полученный от источника или коррелятора? Существует такой вариант, как выявление false через частоту и всплески событий в трафике: хаотичные false positive, или события, которых не было, идут в противовес забагованному правилу корреляции, которое генерирует массу таких событий с флагом, одно за другим. Но от какой модели отталкиваться?
В такой ситуации наиболее логичным кажется построение модели поведения источников событий, определение характера трафика и поиск или установление аномалий: к примеру, был такой случай – у одного из заказчиков контроллер домена выходил из строя строго в обеденное время на час, после чего какое-то время отправлял накопленные логи с неправильными метками времени, да еще и в двойном-тройном объеме. Случаи таких аномалий редки, но есть вероятность, что искусственный интеллект сможет каким-либо образом научиться отличать настоящий поток событий от ошибочного.
На практике есть риск потери важных данных и по-настоящему критичных инцидентов. Лучше уж ставить отметки о том, что угроза отсутствует, при виде логов, которые взялись из ниоткуда.
Итоги
Как же все-таки быть с таким большим разбросом терминов и подходов? Вернемся к самому началу – к цели цикличного обновления процессов – и разделим проблему на два вектора по типу решения:
Некорректна автоматизация – требуется перенастроить инструмент, который по какой-то причине выдает фактический результат отличным от ожидаемого. В таком случае приемлемо как построение отдельного плейбука под одну общую задачу, так и набора таких сценариев под каждый тип ошибки. Правила можно обкатать, настройки перепроверить – и далее в оркестратор будет приходить все меньше и меньше FP.
Автоматизация в порядке, но сыграл человеческий фактор – требуется провести внеочередную сессию awareness для пользователей и всех причастных. Еще раз оговорить существующие процессы, протестировать теорию на практике. Если СЗИ и источники настроены хорошо, дополнительный процесс для них не нужен, а решить проблему такого фактора можно в рабочем порядке расследования/реагирования. Правильно выставленная метка позволит сократить использование аналитического ресурса хотя бы здесь.
Решение разделить флаги на два блока – подтверждения и false positive – позволит сразу подсветить для аналитика конкретные проблемы и не даст спрятать в числе общих ошибок те, которые можно исправить.
