Rambler's Top100
Блоги Алексей ЛУКАЦКИЙ

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

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

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

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

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

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

Оставить свой комментарий:

Для комментирования необходимо авторизоваться!

Комментарии по материалу

Данный материал еще не комментировался.