22.1.19

Почему хостовые средства защиты не так хороши, как их описывает Сергей Солдатов :-)

Возвращаюсь к давно забытому формату, когда блогер не согласен с блогером и начинает с ним заочно спорить (правило двух блогеров от Сергея Борисова). Вот и я сегодня хочу поспорить с Сергеем Солдатовым, который позавчера написал заметку, в которой зачем-то противопоставил сетевые и хостовые средства защиты и стал доказывать, что хостовые лучше/эффективнее сетевых. В качестве одного из доводов Сергей ссылался на матрицу MITRE ATT&CK, которая описывает поведенческие индикаторы и в которой хостовых индикаторов в пять раз больше, чем сетевых. Не ставя под сомнение арифметику Сергея и с уважением относясь к MITRE ATT&CK хочу только отметить, что матрица техник, тактик и процедур для Windows, то есть для хоста, по определению будет содержать больше хостовых индикаторов, чем любых иных :-)

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

Я как раз сторонник интеграции двух типов решений - сетевых и хостовых, которые только в альянсе способны повысить эффективность системы защиты информации на предприятии. Возьмем к примеру задачу отслеживания точки отсчета для атаки, которая была зафиксирована на рабочей станции Windows. Как это сделать без интеграции двух типов решений и реализации механизма ретроспективной безопасности? Ответ прост - никак. При этом важно, чтобы хостовые данные коррелировались с сетевыми автоматически, а не требовали ручной работы, которую не все могут сделать и не все любят. И, по статистике Forrester, и не делают.


Или еще один кейс. Вы зафиксировали на МСЭ прохождение файла, с неизвестным изначально вердиктом. Потом файл прошел попал на оконечное устройство и именно там, по поведению, выяснилось, что файл вредоносный. В "чисто" хостовой истории агенты системы защиты могут  (в идеальной ситуации) обмениваться соответствующими индикаторами/сигнатурами и оперативно блокировать угрозу, если она вдруг попадет в сеть вторично. Но только на тех хостах, которые обеспечены защитным агентом. А если по каким-то причинам такого агента нет или он не работает? Идеальным было бы сообщить о соответствующем индикаторе/сигнатуре МСЭ и все промежуточные сетевые средства, которые в следующий раз смогут блокировать угрозу, не давая ей даже приблизиться к хостам. В идеале индикаторы могут быть переданы также и на средства защиты электронной почты - тогда мы сможем блокировать угрозу еще и на этом рубеже.

Третий пример. Вы внедрили у себя средство мониторинга DNS-трафика, которое позволяет вам не только обнаруживать существующие, но и предсказывать будущие DGA-домены, с которых могут быть осуществлены атаки против вашей инфраструктуры. Данное средство не только идентифицирует опасные домены и командные сервера, но и связанные с ними вредоносные семплы. Вам нужно проверить, не встречались ли в вашей инфраструктуре данные семплы? И сделать это можно только путем интеграции сетевой и хостовой безопасности (защитный агент должен в этом случае обладать функцией threat hunting). Одно хостовое решение будет долго ждать, когда до них будет доведена эта информация в ручном режиме.

Если идти еще дальше, то интеграция должна касаться всех средств кибербезопасности. Например, ваша IPS зафиксировала соединение с командным сервером. Полученный IP-адрес был "прокачан" через облачную TI-платформу, которая вернула (конечно же в автоматическом режиме) вам список семплов, ассоциированных с этим командным сервером, которые были загружены на хостовую систему защиты, которая смогла проинспектировать защищаемые рабочие станции и сервера и найти вредоносный код на ПК. Данный же вредонос был обнаружен в почтовых ящиках пользователей, присланных с e-mail контрагента, который, как позже выяснилось, был заражен и послужил причиной целенаправленной атаки на вас. И все это должно осуществляться автоматически, за счет интеграции различных типов средств защиты, а не в ручном режиме, как сейчас.


ЗЫ. Отчет Forrester с приведенной выше статистикой о важности автоматизации и интеграции средств защиты можно скачать тут.

6 коммент.:

Sergey Soldatov комментирует...

Алексей Викторович! Большое спасибо вам за внимание к моим публикациям, мне очень приятно.

Приведу несколько цитат из заметки, прокомментированной вами.
1. "Сразу хочется оговориться, что являюсь сторонником многоуровневого подхода, что не раз отмечал."

2. "Не будет лишним повторить, что я ни коим образом не пытаюсь снизить значимость NGFW/IPS для корпоративной ИБ, дело в том, что телеметрии только с них крайне недостаточно"

3. "для демонстрационных целей я привожу данные для Windows, но, поскольку все скрипты свободно доступны, читателям ничего не стоит оценить картину для других платформ"

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

5. Превентивную функцию у фаервола никто не отнимал: "...за сетевыми СЗИ сохраняется их изначальная функция - предотвращения...", - это как раз второй сценарий использования, указанный вами.

Еще раз благодарю за ваши комментарии.

Алексей Лукацкий комментирует...

Ты, безусловно, эти цитаты приводил, но по тексту доказываешь все-таки обратное :-) Поэтому я тебе и возразил :-)

По п.3. Возьми любую другую матрицу ATT&CK - они тоже все хостовые - Linux, Mobile...

По п.4. Есть технологии, которые позволяют видеть в трафике инициировавший его процесс.

По п.5. А про функцию предотвращения я вообще не говорил - это даже и не обсуждается. Я только вопрос телеметрии и расследования смотрел.

Anton Chuvakin комментирует...

Но ведь твоя логика скорее направлена на то что оба лучше чем одно? Есть ли у тебя аргументы, например, почему лучше первым делать сетевые средства?

Алексей Лукацкий комментирует...

Ну да, так есть. Нужна комбинация. Одним типом задачу не решить

Anton Chuvakin комментирует...

А какой первым, по твоему? Я до тебя докапываюсь так как у меня на вебинаре это спросят во вторник :-(

Алексей Лукацкий комментирует...

Ну универсального ответа не будет, все зависит. Например, от того, какие решения у заказчика уже установлены. Например, если у него есть антивирус c хотя бы зачаточными функциями EPP/NGAV/EDR, то приоритет я бы отдал сетевой составляющей. Если у заказчика есть NGFW/NGIPS, то приоритет отдал бы EDR/EPP. Если есть оба, посмотрел бы в сторону NTA/NTF. Ну и про моделирование угроз бы уточнил. Если мы исходим из того, что в компании нет Wi-Fi, нельзя подключать сторонние устройства (аудиторов или личные), пользователи обучены не поднимать флешки, то фокус на сетевую ИБ. Если активно реализуется концепция доступа с любого устройства из любого места, то я бы фокусировался на защите ПК.

У нас в Cisco концепция Trusted Device реализуется, так как мы часто вне корпоративной сети работаем и поэтому вся надежда в таких случаях только на защиту ПК.