Сигнатурные и Контекстные ложные срабатывания

Все в этом мире относительно. Именно поэтому для результативности безопасности нам важен контекст, поскольку технологические сигнатуры (не важно на что: на конкретный файл или на последовательность действий) производителем СЗИ выпускаются на среднестатистическую ситуацию, которая может быть сильно различна от инфраструктуры к инфраструктуре. В качестве иллюстрации можно привести сигнатуры на отстуки по C2 ботнетов - это безусловно нехороший знак для рабочих станций рядовых сотрудников HR или бухгалтерии, однако, это вполне может быть ОК для сотрудников подразделений RnD, исследующих ботсети, и для них фиксируемые алерты в контексте конкретной ситуации вполне могут быть ложными срабатываниями. Важным моментом здесь является то, что технологически сигнатура отработала корректно и мячик находится уже на стороне адаптации решения к конкретной среде. Перевод СЗИ из дефолтной конфигурации в адаптированную для конкретной инфраструктуры - очевидная вещь о которой много написано, и сегодня не про это (хотя, в моей практике были комичные случаи, когда я так и не смог убедить в необходимости конфигурирования СЗИ из коробки :) - поэтому, если в необходимости адаптации под свою сеть есть сомнения - этому можно посветить отдельный пост).

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

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

IoNA: Сетевой трафик winlogon

Рассуждая о безопасности мы часто упоминаем индикаторы компрометации - все те же сигнатуры, все то же перечисление зла. Однако, для понимания происходящего, тем более для хантинга, надо не просто находить по индикаторам, а отличать "нормальное" от "подозрительного"/"не нормального" - для чего надо неплохо разбираться в том, что может быть нормальным. Имея знания о "нормальности" подход будет примитивным и, вместе с тем, вполне себе эффективным: из общего количества активностей убрали все, что "нормальны"/известны, а с оставшимися - явно ненормальными или неизвестными - разбираемся. По результатам разбора можно пополнить свой багаж знаний о "нормальности" поведения - т.е. копить не только IoC-и, но и IoNA - индикаторы нормальной активности :)

Оказывается, процесс winlogon тоже генерит сетевой трафик. Причем эта его активность не вызвана никакими инъекция зловредов в него - это его нормальная активность в случае, если у пользователя смонтированы папки WebDAV. Более того, если у вас используется WPAD, то winlogon пойдет сначала на сервер wpad, получит настройки прокси, а затем с ними устремится подключать шары. Если посмотреть dll-ки, подгруженные в winlogon, демонстрирующий такое поведение, то там можно будет обнаружить компоненты Internet Explorer: %SYSTEMROOT%\system32\urlmon.dll, %SYSTEMROOT%\system32\iertutil.dll, %SYSTEMROOT%\system32\WININET.dll, %SYSTEMROOT%\system32\jsproxy.dll. Сетевой трафик от winlogon можно наблюдать в момент входа пользователя в Windows (== момент подключения сетевых папок WebDAV).

Таким образом, наш IoNA выглядит так:
1. Сетевой трафик (WPAD - если есть, HTTP - на сервер с папкой WebDAV) от легитимного процесса winlogon.exe.
2. Подгруженные в winlogon библиотеки IE.
3. У пользователя подключена сетевая папка WebDAV.

В заключение хочется отметить, что это нормальное поведение может являться неплохим вектором атаки на winlogon, - уже как на клиента Интернет... - время покажет.

Два сценария мониторинга

Несомненно, заслуживает уважения стремление Человечества все автоматизировать. Однако, концептуально непреодолимая проблема в том, что машина не может догадываться (некоторая продвинутость в вопросах машинного обучения заставляет в этом сомневаться , но на практике я не видел полностью автоматических систем безопасности, полагаю, сначала появятся пентестеры-автоматы, и это будет предвестником безопасников-автоматов :) ), а рейтинговые системы порой дают результаты, оспаривающие здравый смысл, что может служить почвой для анекдотов и прочего народного творчества. Поэтому, приходится нехотя соглашаться, что автоматикой мы способны задетектить то, с чем аналитик когда-то разбирался и придумал некоторый алгоритм, как это обнаруживать. Но, очевидная правда в том, что безопасность - бесконечная игра в кошки-мышки, где защищающие постоянно отстают от нападающих и вынуждены уже постфактумно, получив какие-либо артефакты, разгадывать неведанные, тайные и запутанные замыслы атакующих. Поскольку от детских проблем прекрасно спасает автоматика, а кибератака - эффективный инструмент влияния, получающий всю большую популярность одновременно с повышением своей эффективности, мы имеем, что для обеспечения этого эффективного влияния атакующий должен использовать недетские TTP, способные обходить автоматические средства защиты, бить в те места, где автоматика бессильна, обнажая пробельные места в защите.
Вот, как раз, эти-то пробельные места и компенсируются трудом аналитика, проводящего расследования компьютерных атак (== инцидентов ИБ). Широко смотря на проблему разделение задач такое: робот - детектит все то, что известно, а все что не известно - детектит аналитик и учит этому робота, создавая корреляционные правила/сигнатуры и т.п.. Так обеспечивается замкнутый цикл мониторинга, реализованный через симбиоз человека и робота - основа построения комплексной услуги и системного подхода.

На практике это выглядит как два сценария мониторинга. Первый назовем "Alerting" (или "Alerts"). Его суть заключается в том, что под известные TTP, выраженные в цепочках событий\нотификаций систем безопасности (да и любых других систем, способных генерить логи вообще) создаются алерты, свидетельствующие о том, что данная цепочка была обнаружена, а следовательно - обнаружена соответствующая ей атака. Достоверность (% ложных срабатываний) такого алерта будет полностью зависеть от качества цепочки (корреляционного правила, сигнатуры). Здесь задача службы мониторинга - а) понять что алерт - не фолса, б) инициировать процесс реагирования на инцидент и отработки последствий. Этот случай - классический, все, кого я спрашивал о том, что он думает о мониторинге и SOC, - отвечали примерно это.
Второй сценарий, назовем его "Hunting", менее очевидный, но все понимают его необходимость при попытке ответить на вопрос: "Откуда берутся корреляционные правила". Да, сценарий, когда аналитик почитал новости и сделал новую детектирующую цепочку все равно относится к Первому сценарию, поскольку аналитик автоматизировал уже известную атаку. А вот если хочется защищаться от неизвестных атак, обеспечивая комплексную услугу, - аналитику надо самому находить атаки, анализируя неочевидные индикаторы и признаки, совокупность которых создаст подозрения, расследование которых приведет к выявлению новых, ранее не встречаемых ITW атак. Вот это - Второй сценарий, позволяющий создавать эти корреляционные правила, и далее - учить автомат самостоятельно, насколько это возможно, это детектировать и обезвреживать.

Указанные два подхода к мониторингу принципиально отличаются и, вместе с тем, прекрасно дополняют друг друга до единого целого, необходимого, в конечном счете, потребителю. Для Первого можно придумать SLA со временем реакции и временем решения, для второго - нет. Для первого важна реалтаймовая корреляция, что обычно возникает в сознании при слове "SIEM", для второго - важна возможность разнопланового анализа, структурирование в момент поиска, позволяющее одни и те же события в разное время увидеть и интерпретировать по-разному. Первый сценарий - больше operations, оперативная готовность, тогда как Второй - research, планирование и развитие. Оба сценария важны, невозможно добиться желаемого результата реализовать лишь какой-то из них, однако, Второй, как любые исследования, достаточно дорог (нужны люди, инструменты, время), а поэтому может эффективно выполняться, скорее, специализированным компаниям, уже проводящим такие исследования в рамках своей основной деятельности, и поэтому - обречен на аутсорсинг, что, на мой взгляд, - нормально.
Очевидно, что Hunting, применяемый к угрозам ITW, а полученные сигнатуры - к угрозам на данном конкретном предприятии, дает значительно меньший эффект, чем сценарий, когда весь исследовательский потенциал специализированного аутсорсера направлен на Hunting в рамках данной конкретной инфраструктуры, в результате которого созданные корреляционные правила/сигнатуры для данной конкретной инфраструктуры, - именно поэтому он интересен для понимающего заказчика. Hunting атак ITW, сопряженный с Alerting-ом в конкретном предприятии можно сравнить со стрельбой вслепую - если везет, то по направлению предполагаемого противника, тогда как Hunting по данной конкретной инфраструктуре в совокупности с Alerting-ом по ней же, аналогичен прицельному снайперскому огню, эффективность которого, безусловно, выше.