Стратегия 6. Часть 4. Мониторинг и защита узлов

8.3 Мониторинг и защита узлов

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

Данные, предполагающие, подтверждающие и уточняющие присутствие и проникновение злоумышленника, лучше всего обнаруживаются посредством мониторинга и анализа контента конечных хостов. Более того, реагирование на инциденты часто включает в себя непосредственную работу на конечных узлах и этот процесс может занимать часы, дни, недели или даже больше. Рассмотрим организацию с хорошо оборудованными компьютерами и серверами, которые не только сообщают о признаках и предоставляют исчерпывающий контекст вторжения, но и обеспечивают автоматические ответные действия. Многим SOC приходится уделять столько же внимания вопросу оснащения конечных узлов, как сетям.

В этом разделе рассматривается вопрос оснащения узлов набором сенсоров, которые будут использованы SOC для обнаружения, анализа, понимания, мониторинга и предотвращения инцидентов безопасности на конечном хосте. Эти инструменты могут быть представлены в виде программного агента, установленного на хосте, который наблюдает за локальной активностью. Подобно сетевой системе обнаружения вторжений (NIDS), инструменты на узле контролируются центральной системой управления. Развернутая сетевая система обнаружения/предотвращения вторжений может включать десятки или сотни сенсоров, при этом SOC может поставить узловую систему обнаружения/предотвращения вторжений на каждом конечном узле. В случае крупной организации это могут быть сотни тысяч датчиков. При таком большом количестве данных и разнородной структуре ИТ-предприятия обеспечить масштабируемость сложно.

Есть ряд возможностей, которые можно использовать на уровне узла. И хотя есть специализированные продукты, которые нацелены на качественное выполнение какой-то одной функции, чаще один продукт сочетает в себе несколько функций:

  • Антивирус/Антишпионское ПО;
  • Обнаружение и предотвращение вторжений;
  • Черные и белые списки приложений;
  • Отслеживание конфигурации;
  • Контроль доступа к сети;
  • Персональный межсетевой экран;
  • Предотвращение потери IP;
  • Мониторинг активности пользователей;
  • Удаленная поддержка и расследование инцидентов.

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

Почти все инструменты используют набор наблюдений, которые содержатся в системной памяти, процессоре, на диске, периферийных хранилищах или их комбинации. Различия между инструментами заключаются в их ключевых функциях и методах (тот самый «секретный ингредиент»), которые задействуют эти наблюдения для реализации своих функций. Поэтому начнем с подробного рассмотрения этих «наблюдений», затем обсудим, каким образом они задействуются для каждой ключевой функции, реализованной в системе мониторинга узла, а завершим некоторым заключениями об использовании этих инструментов на практике.

8.3.1 Наблюдение и обзор

При наличии доступа к конечному узлу появляется масса возможностей узнать, какие действия на нем совершались. Эти наблюдения можно собирать либо постоянно, либо по запросу и по-разному синтезировать. Рассмотрим основные блоки:

Из встроенных файловых систем и любого другого хранилища:

  • Версия ОС, установленные пакеты обновлений и уровень патчей.
  • Установленные приложения.
  • Резидентные файлы, время их модификации, владельцы, права доступа, содержимое и сводные данные, такие как размер и значение хеша.
  • «Свободное пространство» файловой системы, содержащее удаленные файлы и содержимое корзины.
  • Содержимое всего физического диска, например, полный образ.
  • Журналы ОС и приложений.
  • Данные конфигурации ОС и приложений, такие как содержимое ветвей реестра Windows.
  • История браузера, кэш, куки и настройки.

Из системной памяти и процессора (ов):

  • Идентификационный номер процесса приложения (PID), время создания, путь к исполняемому файлу, синтаксис выполнения с аргументами, имя, пользователь, с правами которого он запускается (контекст пользователя), используемое время процессора и приоритет.
  • Действия запущенных процессов и потоков, например поведение при запуске и системные вызовы.
  • Содержимое ОЗУ и карт памяти
  • Содержимое буфера обмена
  • Содержание и расположение регистров процессора и кэша.
  • Зарегистрированные пользователи или приложения с правами удаленного пользователя, например, с базой данных или пользовательским приложением.

Из подключенных устройств и системы ввода-вывода:

  • Данные о потоке сети (иногда называемом «потоком хоста»), по возможности включая обогащения, связывающие имя процесса с портами и открытыми соединениями.
  • Данные из сетевого трафика.
  • Нажатия клавиш пользователя.
  • Действия от других устройств ввода, таких как мыши, сенсорные панели или сенсорные экраны.
  • Скриншоты.
  • Подключенные устройства, включая такие данные как тип устройства, информация о драйвере, серийный номер/ID, системные ресурсы, адресуемое хранилище или память (если применимо) и события подключения/отключения.

Чтобы представить полную картину того, что происходит на узле, обычно необходимо изучить все три блока (данные на диске, в памяти и подключенном устройстве ввода-вывода). Например, если сосредоточиться только на локальной файловой системе, аналитик увидит вредоносные программы, работающие исключительно в памяти. Пакет мониторинга хоста должен осуществлять сбор данных, не требуя значительных ресурсов системы, особенно ЦП и ОЗУ.

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

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

Некоторые инструменты мониторинга на узле могут работать полностью в памяти, практически не занимая места на диске. Этот метод обеспечивает инсталляцию или внедрение кода в ОС во время загрузки или вскоре после нее. С одной стороны, это закрывает некоторые возможности, которыми могут воспользоваться вредоносные программы для препятствия мониторингу хоста, с другой – создает дополнительную сложность с точки зрения управления и распространения.

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

Когда пакет мониторинга должен располагаться на контролируемом узле, он обычно находится в «нулевом кольце защиты», где ОС работает с привилегиями системного уровня. К сожалению, это ставит его в один ряд с вредоносными программами, которые получают те же привилегии системного уровня. В результате создается ситуация гонки вооружений между авторами вредоносных программ и поставщиками средств безопасности с целью обойти друг друга на хосте. Кроме того, вредоносное ПО, которое располагается в прошивке, BIOS или оборудовании, имеет преимущество в том, что оно обходит эти пакеты мониторинга, по крайней мере частично.

Некоторые более эзотерические подходы к мониторингу узлов используют постоянное хранилище или доверенный источник на аппаратном уровне. Например, обнаружение руткитов может осуществляться с помощью специализированных инструментов мониторинга, реализованных в виде платы, связывающей периферийные компоненты в системе, но это довольно дорого. Существуют также варианты использования доверенного платформенного модуля (TPM) в современных системах архитектуры Intel в качестве доверенного источника, гарантирующего, что ОС и другие компоненты не будут скомпрометированы. Однако на момент написания этой книги такой подход находился в основном в стадии исследования и небольших пилотных проектов.

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

8.3.2 Антивирус и антишпионское ПО

Тема антивирусных инструментов должна быть знакома читателям. Если кратко, то это программа, которая проверяет содержимое файловой системы и памяти, используя большой пул сигнатур и эвристику для поиска известных вредоносных программ или известных методов вредоносных программ. Как и в случае сигнатурных IDS, их можно обойти. Они не обеспечивают полную защиту, но могут быть актуальными в контексте Windows-систем, на которые нацелено подавляющее большинство существующих вирусов. Учитывая их ограничения, антивирусные инструменты обычно критикуют за использование ими системных ресурсов, объема оперативной памяти и регулярное сканирование дисков, что перевешивает их небольшие преимущества.

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

Тот факт, что антивирусные инструменты обнаруживают лишь небольшой процент всех вредоносных программ, а найденные ими образцы представляют собой преимущественно вредоносное ПО, работающее на базе Windows/Intel платформ, привлекает внимание. Mandiant, признанный поставщик хостовых средств реагирования на инциденты, оценивает  обнаружение антивирусных инструментов на уровне 24%, если рассматривать вредоносное ПО класса APT. В других источниках фигурируют значения от 15 до 40 процентов. В защиту антивирусов можно сказать, что 15-40% лучше, чем ничего и, по крайней мере, антивирус может указать, что узел заражен. Но следует помнить, что даже если антивирус сообщил об устранении вируса и о чистоте системы, на деле он обнаружил лишь часть заражения, оставив другие инструменты противника действовать в системе.

Обязательное использование антивирусов в корпоративной и государственной среде все еще широко распространено. С практической точки зрения их применение в настольной версии Windows считается целесообразным, хотя и несущественным. Некоторые специалисты по сетевой безопасности полагают, что антивирус на платформах, отличных от Windows, таких как Apple, Linux и UNIX, не нужен, несмотря на применение политики “обязательного антивируса” для каждого настольного компьютера и сервера на предприятии, которая наблюдается во многих организациях. Почти каждое крупное предприятие имеет обязательный инструмент мониторинга на уровне узла, и в этом отношении антивирус считается необходимым минимумом. Как упоминалось выше, если SOC развертывает какие-либо инструменты помимо антивируса, они могут распознавать друг друга как вредоносное ПО и, в самых крайних случаях, приводить к отказу своего хоста из-за конфликтов. SOC должны уделять пристальное внимание вопросам интеграции перед развертыванием.

8.3.3 Система обнаружения/предотвращения вторжений на хостах

В разделах 2.7 и 8.2 рассматривались системы обнаружения вторжений IDS, которые позволяют оценить возможности обнаружения и предотвращения вредоносной активности на узлах. Действительно, хостовые инструменты обнаружения/предотвращения вторжений обычно используют методы обнаружения как на основе сигнатур, так и на основе поведения. Тогда как для антивируса краеугольным камнем является библиотека сигнатур миллионов штаммов вредоносного ПО, инструменты обнаружения/предотвращения вторжений на хосте базируются на выявлении отклонений от того, что считается нормальным поведением ОС и приложений.

Инструменты HIDS/HIPS обычно полагаются на набор поведенческих характеристик для всего ПО, что выполняется на узле. Эти профили поведения могут быть построены путем периодического или постоянного «обучения» поведению, которое считается нормальным. Когда хосты отклоняются от этого нормального поведения, срабатывает предупреждение и HIPS фактически блокирует активность, если включен режим предотвращения. Представьте, например, что Microsoft Word внезапно начал записывать различные разделы реестра Windows или открыл связь с удаленным сервером по нестандартному сетевому протоколу. Пакет HIPS должен заметить и заблокировать это.

Проводя еще одну параллель с сетевыми IDS, передовые образцы вредоносных программ могут обойти HIDS. Одна из классических тактик атаки на платформе Windows привела к смене практики поставщиков по проверке ключевых компонент системы. Например, HIDS будет отслеживать любые изменения файлов в c:\windows\system, осуществляя мониторинг обработчиков файловой системы Windows. Хакеры обошли ее, переименовав этот каталог произвольным именем или выполнив прямой ввод-вывод для файлов, содержащихся в его каталогах, что позволило избежать обнаружения. Хотя эта конкретная атака была распознана много лет назад передовыми поставщиками, она иллюстрирует ту самую игру в кошки-мышки, которая мешает большинству инструментов HIDS и HIPS по сей день.

HIDS/HIPS часто рассматриваются как наиболее сложные компоненты пакета мониторинга на узлах по двум причинам. Во-первых, они глубоко интегрированы с операционной системой хоста. На крупных предприятиях с различными базовыми показателями системы пакеты HIDS/HIPS часто могут вызывать нетривиальные конфликты с другими работающими компонентами, поэтому всегда требуется обслуживание и отладка перед полным развертыванием. Во-вторых, всегда рекомендуется развертывать HIPS на большой части узлов, по возможности, на всех серверах и в некоторых случаях на всех настольных компьютерах. Это может быть непростой задачей, поскольку любые ошибки настройке сигнатур или профиля HIDS/HIPS могут легко привести к массовым перебоям в обслуживании и наплыву обращений в службу поддержки. Хотя эти проблемы могут возникать при использовании любого инструмента мониторинга на основе хоста, чаще всего они характерны для HIPS.

8.3.4 Помещение приложений в черный или белый список

Одним из следствий работы систем обнаружения/предотвращения вторжений и антивирусов является возможность контролировать работу приложений на конечном хосте. Составление черного списка приложений — это метод, при котором модуль ОС или агент защиты блокирует нежелательные процессы, выполняющиеся на конечном узле. Это достигается путем мониторинга процессов, которые соответствуют определенному набору критериев, таких как имена процессов, MD5 хэш кода или подписание кода доверенным корневым центром сертификации. Внесение в черный список похоже на политику «разрешения по умолчанию», при которой запрещен запуск только определенных приложений.

Белый список приложений аналогичен черному списку приложений, но вместо политики «разрешить по умолчанию» используется подход запрета по умолчанию. Системные администраторы должны определить, какие программы разрешено запускать в каких системах; все остальные блокируются для запуска на уровне операционной системы или клиента, поддерживающего черный/белый список.

Белый и черный списки приложений могут быть встроены в некоторые операционные системы (например, AppLocker в Windows 7 и Windows Server 2008). Они также часто является частью пакета HIDS/HIPS (например, Белый список приложений Bit9 и Контроль приложений McAfee). Как в случае с антивирусными и HIDS/HIPS пакетами, некоторые реализации черного и белого списков приложений корпоративного уровня можно обойти с помощью ряда методов, но тем не менее они повышают стоимость успешной эксплуатации. Вендора приложили усилия, чтобы закрыть дыры в своих схемах защиты, но как и в любой схеме защиты на основе сигнатур, существует «гонка вооружений» между защитниками и злоумышленниками.

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

8.3.5 Отслеживание конфигурации, аттестация и контроль

Управление конфигурацией считается ключевым фактором, способствующим усилению защищенности предприятия. Управление конфигурацией связано с мониторингом конфигурации на рабочем столе и на сервере.

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

Можно сделать логический вывод о том, что инструменты для отслеживания конфигурации можно объединить с автоматизацией на уровне сетевой инфраструктуры для формирования услуг, предоставляемых системам (в зависимости от статуса соответствия конфигурации). Это ключевая особенность сетевых систем контроля доступа (NAC), продаваемых несколькими компаниями, включая PacketFence, McAfee, Juniper и Microsoft.

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

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

Независимо от используемых инструментов или методов, опытные злоумышленники крайне заинтересованы в том, чтобы аналитики сетевой безопасности не узнали о каких-либо изменениях, вызванных их присутствием на узлах организации. С этой целью они пойдут на все, используя такие инструменты, как руткиты, чтобы скрыть изменения в ключевых системных файлах, которые могут вызвать срабатывание Tripwire или NAC. В некоторых случаях эти инструменты могут быть атакованы напрямую и настроены на предоставление ложной информации вышестоящим серверам управления. Это относится к любому инструменту мониторинга на узле, но наиболее остро это касается отслеживания конфигурации и комплектов системы предотвращения вторжений хоста.

И хотя все инструменты мониторинга хоста кроме самых простых используют различные внутренние проверки для защиты от компрометации, ни один из них не защищен на 100%, если вредоносное ПО стоит на одном уровне (нулевое кольцо) с пакетами мониторинга. Для этого модуль доверенной платформы может использоваться в качестве доверенного источника для аттестации конфигурации хоста.

8.3.6 Межсетевой экран

Межсетевые экраны (МСЭ) наиболее известны как устройства, фильтрующие трафик между двумя или более сетями, однако возможности по фильтрации сетевого трафика на уровне узла есть практически во всех популярных разновидностях UNIX и Linux и входят в большинство пакетов хостовых систем обнаружения/предотвращения вторжений. В средах UNIX и Linux такие МСЭ используются главным образом для ограничения доступа внешних систем (и пользователей) к чувствительным службам, таким как инструменты удаленного управления (например, SSH). Существует множество пакетов хостовых МСЭ, которые различаются версиями UNIX, включая таблицы IP и пакетные фильтры (PF).

Персональные МСЭ, как их обычно называют, применяются для расширения правил, уже действующих в сетевых МСЭ и шлюзах. Их можно использовать для дальнейшего сдерживания распространения сетевых вредоносных программ, особенно в случае критической или повышенной угрозы. Стоит отметить, что многие средства защиты от вторжений используют легитимные порты и протоколы, что ограничивает возможности более простых настольных МСЭ в противодействии тому же вредоносному ПО. Персональные межсетевые экраны естественно не заменяют МСЭ корпоративного уровня, которые располагаются у сетевых шлюзов, и почти всегда служат их дополнением, а не заменой. Symantec, CheckPoint и McAfee включают хостовые МСЭ в пакеты хостовых систем предотвращения вторжений.

8.3.7 Предотвращение утечек интеллектуальной собственности

С ростом распространенности зашифрованных сетевых протоколов и съемных носителей большой емкости, таких как флэш-накопители USB, возникает серьезная озабоченность по поводу утечки конфиденциальных данных организации. К ней можно отнести все, что угодно, от отправки конфиденциальных документов по личной электронной почте до загрузки данных HR на флэшку. Хост часто является единственным местом, где можно отследить эту активность (например, через сетевой трафик и наблюдаемые системные вызовы). Многие из пакетов мониторинга на уровне узла, упомянутые в этом разделе, включают функции по сканированию и оповещению о данных, переданных на локальные съемные носители, а также о размещении информации на веб-сайте и по электронной почте (они известны как средства предотвращения утечки интеллектуальной собственности или данных [DLP]). Некоторые пакеты для предотвращения утечки интеллектуальной собственности также могут использоваться для блокировки или ограничения доступа пользователей к съемным носителям, расширяя функциональность, уже присутствующую в объектах групповой политики Windows.

8.3.8 Мониторинг активности пользователей

В некоторых организациях с подозрением относятся к действиям значительной части сотрудников. Многие организации придерживаются политики «доверяй, но проверяй», согласно которой пользователям предоставляется свобода действий для выполнения их рабочих функций, но их действия тщательно контролируются. Обычно это организации, обрабатывающие большие объемы конфиденциальных или ценных данных, например, в области защиты, разведки, финансах и некоторых отраслях промышленности. В таких случаях отдел безопасности, контрразведки и предотвращения утечки интеллектуальной собственности может потребовать полный контроль над активностью пользователей. Обычно он подразумевает полное отслеживание активности пользователей на персональных компьютерах до такой степени, что действия пользователей можно увидеть в режиме реального времени или воспроизводить с помощью снимков экрана и нажатий клавиш. Эффективность и правовые вопросы, связанные с использованием такого программного обеспечения, выходят за рамки этой книги.

Как видно из рассмотренных ранее наблюдений, узел хорошо подходит для осуществления такого мониторинга. Обычно такой функционал входит в вышеупомянутые выше инструменты DLP. Коммерческие примеры пакетов мониторинга внутренних угроз включают Raytheon SureView и ObserveIT.

8.3.9 Поддержка и расследование инцидентов

До сих пор подавляющее большинство наших дискуссий о мониторинге хостов было сосредоточено на левой половине жизненного цикла кибератак, а нас интересует весь жизненный цикл атаки. Когда один ящик взломан, SOC должен ответить на вопросы, в том числе: были ли взломаны другие? Насколько можно быть уверенным, если мы никогда не получали оповещения систем предотвращения вторжений или антивирусов от других хостов? Что, если компрометация была обнаружена с помощью анализа NetFlow или пользователя, звонящего с неизвестного номера? Кроме того, что делать, учитывая, что наш SOC находится в Аризоне, а взломанная система находится в Марокко?

Во второй половине 2000-х годов несколько поставщиков выпустили на рынок серию продуктов, призванных помочь SOC в быстрой оценке воздействия и распространения компрометаций в организации заказчика. Эти продукты включают в себя Mandiant для интеллектуального реагирования, AccessData CIRT, HBGary Responder Pro и Guidance EnCase Enterprise. Эти инструменты, в первую очередь, предназначены для использования всего спектра наблюдений, описанных в начале Раздела 8.3, иногда называемого в этом контексте «хост-телеметрией», для поддержки специального анализа вторжений. Кроме того, многие из этих инструментов могут создавать целые образы ОЗУ или диска для удаленного анализа.

К примеру, представьте себе, что аналитик SOC работает с компрометированной системой. Быстрый анализ памяти и диска выявил ряд программ, которые кажутся подозрительными. Вышеупомянутые инструменты позволят аналитику просканировать другие системы организации на предмет наличия тех же файлов, например, путем анализа карты памяти или сканирования хеш-файлов на диске. Некоторые инструменты, в частности EnCase Enterprise, фактически удаленно извлекают частичный или полный образ содержимого системы для анализа.

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

Хотя использование этих инструментов, безусловно, влияет на масштабируемость, производительность и пропускную способность, они позволяют обеспечить различные варианты реагирования на инциденты, которые иначе были бы недоступны. Можно сократить сроки анализа инцидентов с недель и месяцев до минут и часов. SOC, которые сталкиваются с многочисленными системными компромиссами каждую неделю, особенно в удаленных локациях, вынуждены использовать инструменты удаленного реагирования на инциденты как часть архитектуры мониторинга и реагирования. Такие инструменты, возможно, в большей степени, чем любые другие, позволяют SOC оставаться в цикле принятия решений противника даже в случае крупной географически распределенной организации.

Поделиться записью: