Стратегия 6. Часть 1: Максимизировать пользу от закупленных технологий

Первые SOC, появившиеся в 1990-х, работали с относительно небольшим количеством не очень сложных инструментов, в основном это были сетевые и хостовые IDS. Со временем рынок средств защиты сильно расширился так же, как и тактика, техника и процедуры (TTP) противника, его ресурсы и мотивация. Сегодня SOC должен использовать широкий спектр возможностей для выполнения своей миссии, что делает защиту сети гораздо более дорогостоящей, чем ранее. Нет ни одного инструмента, который делал бы все. Каждый имеет свои ограничения, и при этом должен взаимодействовать с другими инструментами в сложной архитектуре, поддерживающей комплексный мониторинг и расширенную аналитику.

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

  • Сканеры уязвимостей и системы отображения сетей, которые помогают SOC понять масштаб, характер и статус уязвимостей организации.
  • Сетевые системы обнаружения/предотвращения вторжений (NIDS/NIPS), которые реагируют на определенные шаблоны поведения пользователей, систем или сетей.
  • Дополнения к NIDS/ NIPS, включая NetFlow (записывает сводку сетевой активности), захват полного сеанса сети, а также устройства детонации контента (которые проверяют документы и веб-страницы на наличие вредоносного содержимого).
  • Аналогичные средства для хостов сети (HIDS/HIPS), которые во многих случаях также включают различные усовершенствования и дополнительные модули, такие как антивирусы и мониторинг конфигураций.
  • Средства сбора, нормализации, корреляции, хранения и представления событий из различных источников, такие как SIEM-системы и их аналоги или устройства управления файлами журналов.

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

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

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

  • Постоянно быть в курсе актуальной ситуации и релевантных для заказчика проблем — наиболее опасных и вероятных угроз.
  • Рассматривать совокупную ценность каждого инструмента с точки зрения обозримости, охвата жизненного цикла кибератаки и его срока службы.
  • Сосредоточиться на наборе отдельных инструментов, которые обеспечивают максимальную ценность без дублирования функций, если только это не требуется в целях резервирования.
  • Придерживаться жесткого подхода, основанного на требованиях и обратной связи от операторов.
  • Тщательно управлять ожиданиями IT-руководителей относительно достоинств и ограничений рассматриваемых инструментов — панацеи нет.
  • Убедиться, что SOC обладает достаточным опытом, чтобы использовать все возможности выбранных инструментов.
  • Совершенствовать инструменты на протяжении всего срока их службы, выделяя ресурсы на настройку и аналитику, а также на создание пользовательских сценариев и контента.
  • Убедиться, что выбранные инструменты вписываются в тщательно разработанную архитектуру мониторинга, анализа и реагирования.

8.1 Знание заказчика

Чтобы защитить предприятие, необходимо сначала его изучить. Львиная доля внимания аналитиков SOC приходится на инструменты мониторинга сетей и хостов. Однако необходимым условием для использования этих средств является наличие некоторого “локального контекста” для узлов и сетей, которые они отслеживают.

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

В этом разделе обсуждаются инструменты и методы, которые помогают SOC достичь следующих целей:

  1. Понимание состояния конечных хостов и устройств: что на них установлено и насколько они уязвимы для атак.
  2. Понимание топологии сети, связей между хостами и анклавами.
  3. Установление ключевых связей между IT-активами и реализуемыми ими бизнес-задачами.

8.1.1 Информация об активах

Организации любого размера должны следить за инвентаризацией своей инфраструктуры – из чего она состоит, где находится, кому принадлежит, что и когда было приобретено и так далее. Кроме того, крайне желательно использовать централизованное средство для развертывания обновлений и исправлений программного обеспечения, такое как Microsoft System Center Configuration Manager. А некоторые инструменты, такие как Radia или Symantec Management Agent (Altiris), действительно смогут обращаться к конечным узлам и запрашивать системные настройки и файлы на жестком диске, чтобы определить статус исправлений системы.

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

В идеале эти системы смогут предоставлять очень ценные данные по активу для аналитика:

  • Имя хоста
  • MAC-адрес
  • IP-адрес
  • ОС и её версия
  • Пакет обновлений и патчи
  • Установленное и запущенное программное обеспечение
  • Детали и конфигурация оборудования
  • Системные настройки
  • Дата покупки
  • Владелец, если применимо
  • Отношение к организации или проекту в некоторых случаях.

Рассмотрим распространенную ситуацию, когда аналитик исследует атаку, которая затронула несколько сотен систем всей инфраструктуры клиента. Аналитик может знать только IP-адреса жертв. Где физически расположены эти системы? Что на них запущено? Могут ли они быть потенциально уязвимы, исходя из версии пакета обновления? Ответить на эти вопросы помогут данные из надежной системы управления активами.

Сканеры уязвимостей могут предоставлять аналогичные данные; однако, скорее всего, IT-отдел уже имеет свою базу данных для контроля и управления активами. И хотя SOC может развернуть свой собственный инструмент для сбора этих данных, использование уже существующего инструмента позволит избежать дополнительных расходов. Многие SOC наполняют свои системы мониторинга выгрузками данных по активам в целом или же создают рабочие инструменты, позволяющие аналитикам отправлять в систему управления активами запросы о конкретных событиях . Подобные подходы могут быть реализованы с помощью SIEM-системы.

8.1.2 Топология сети

Чтобы понять топологию IT-инфраструктуры организации, SOC обычно обращается к картам сети. Разные карты сети могут отображать организацию в различных представлениях. Некоторые из них сосредоточены на небольших подсетях, некоторые на сетях региональных или анклавах. Обычно на таких картах даны подробные сведения о пограничных устройствах, таких как коммутаторы и серверы — за исключением внешнего периметра и DMZ, которые бывают необходимы только при реагировании на конкретный инцидент. Другие карты сетей представляют организацию на гораздо более высоком уровне, отображая топологию WAN, основные маршрутизаторы и оборудование оператора связи (PoPs) без учета конечных хостов. Они помогают аналитикам понимать, что они контролируют. Обычно SOC не являются ответственными за карты сетей, чем осложняется их поддержка в актуальном состоянии, поэтому SOC стоит опираться на личные связи с владельцами систем и сетевыми инженерами.

Обычно карты сетей генерируются автоматически – программой мониторинга сети, средством сетевого сканирования или создаются вручную с помощью Microsoft Visio.
Отрисовка карты сети вручную – довольно трудная и кропотливая задача, которую выполняют системные администраторы и администраторы сетей, понимающие, насколько важно точно изобразить активы, которыми они управляют. Если у аналитиков есть доступ к актуальным картам сетей, это уже достаточно большой прогресс в понимании инфраструктуры клиента при нулевой стоимости для SOC. На самом деле, некоторые SOC могут играть существенную роль в формировании набора карт сетей или в обновлении сводных высокоуровневых диаграмм.

Для дополнения созданных вручную карт сетей некоторые организации используют автоматизированные системы сканирования сетей, такие как Lumeta IPSonar. Несмотря на то, что у каждого инструмента такого рода есть определенные достоинства и недостатки, все они довольно похожи с точки зрения архитектуры. Как видно на рисунке 17, сканирующие узлы размещаются в ключевых точках по всей сети. Каждый узел будет искать подключенные к сети устройства и конфигурационные данные в рамках заданного пользователем диапазона IP. Эти данные будут передаваться на центральный коллектор, где пользователь может управлять системой и взаимодействовать с собранными данными. Анализируя результата сканирования, такие как трассировка маршрутов, система может просчитать топологию сети между ней и просканированными активами.

Рис.17. Базовая архитектура обнаружения сети

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

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

В таблице 8 приведены плюсы и минусы различных методик составления карт сетей.

ХарактеристикаАвтоматическиВручную
Стоимость внедренияУмеренная, в зависимости от размера организации-заказчика: инструменты для крупных организаций более дорогостоящи и потребуют дополнительных расходов на внедрение.Нулевая или минимальная: в пределах стоимости нескольких лицензий MS Visio или схожего инструмента.
Стоимость выполнения и поддержкиОт небольшой до умеренной, в зависимости от частоты сканирования и сложности используемого средства.От небольшой до умеренной при условии регулярного обновления. Создание и консолидация карт считается неотъемлемой задачей управления конфигурацией сетей – необходимо осознанно выделять для этого ресурсы.

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

Что включаетОбъединенные в сеть хосты и межсетевое взаимодействие, некоторые конфигурации маршрутизаторов/коммутаторов, не зависимо от того, описаны и документированы хосты или нет.Известные сетевые устройства (коммутаторы, маршрутизаторы, межсетевые экраны, серверы), соединения, периметры, сети – все, что покажется важным составителю карты, даже если уровни представления будут пересекаться.
Что упускаетКонтекст, важный для анализа карты в рамках миссии SOC; системы, не видимые с позиции сканера из-за сетевых экранов, NAT-преобразования сетевых адресов, VPN, виртуализация сетей или туннелирование; конфигурационные данные для активов, к которым нет доступа или привилегий.Все, о чем автор карты не знал: недокументированные активы, изменения в сети, при отсутствии дополнительной автоматизации или плагинов сканирования – подробные конфигурационные данные для большого числа активов, поскольку для сбора этих данных потребуется слишком много времени.
УстареваниеРазвертывание и использование сканеров должно синхронизироваться с изменениями сетей или анклавов заказчика, иначе результаты будут неактуальными.Карты сетей устаревают сразу же после отрисовки. Их правильности и полноте способствует внимательность. Изображение может быть помечено как свежее, однако часть данных может быть уже устаревшей. Полная чистка сетевых карт может быть крайне трудоемкой.
Ограничения в масштабируемостиПозволяет охватить большие объемы данных по активам в крупных сетях, чего невозможно добиться ручными методами. Если не используется многоуровневое отображение сети с возможностью провалиться на более подробный уровень, могут возникнуть сложности в восприятии карты.Составление каждой карты отнимает время, поэтому авторам приходится включать в нее только то, что действительно важно. Изображение тысячи отдельных узлов на одной карте обычно не целесообразно на практике.
Воздействие на системы и сетиОператоры должны спроектировать и выполнять сканирование так, чтобы оно не создало избыточную нагрузку на ресурсы.  В случае некорректного выполнения весьма вероятен самостоятельно спровоцированный отказ в обслуживании.Небольшое или отсутствует вовсе. Может отсутствовать воздействие на системы.

Таблица 8. Сравнение автоматического и ручного методов составления карты сети.

Важно отметить, что есть также третий, менее распространенный метод создания карт сетей. Ранее говорилось, что карты сетей, составленные вручную или автоматически, могут содержать прямые ссылки на конфигурационные данные по активу, привязанные к символам на карте. Можно составить карту, целиком полагаясь на анализ конфигурации различных активов – маршрутизаторов, коммутаторов, МСЭ. По крайней мере, компания RedSeal предлагает свой продукт для создания карт сетей, в котором заложена именно такая стратегия. Этот подход дает те же преимущества, что и автоматические методы сканирования, обсуждавшиеся ранее – он отражает то, что реально внедрено и работает. Однако одним из его недостатков будут пробелы на карте сети в тех местах, где для опроса оборудования на предмет конфигурации не хватит прав. У классических средств автоматического сканирования такой проблемы может не быть.

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

8.1.3 Сканеры уязвимостей

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

С точки зрения архитектуры принцип работы сканеров уязвимостей во многом похож на рассмотренные ранее средства составления карт сетей. Пользователь взаимодействует с системой через центральную консоль, управляя одним или несколькими сканерами. Каждый клиент сканера размещается в логической или физической близости от целевых узлов. Используя домен Windows, протокол LDAP или локальные учетные данные, они опрашивают объединенные в сеть системы на предмет подробной системной конфигурации, которая свидетельствует о статусе их обновлений, и другой информации, относящейся к безопасности. Затем управляющий сервер собирает результаты, которые размещаются в базе данных и выдаются пользователю по запросу. Пользователь может детально настроить глубину и ширину сканирования, позволяя, к примеру, выполнить сканирование только на предмет конкретной уязвимости.

Сканеры уязвимостей стоят особняком от систем для составления карт сетей, поскольку они взаимодействуют с конечными хостами только на предмет конфигурационных данных и не дают никакой информации о топологии сети. Сканеры могут собрать некоторую информацию, если её предоставит сенсор на хосте, однако их настройки по умолчанию составляются исходя из вероятного отсутствия нужного ПО на конечном устройстве. На рынке представлено несколько таких инструментов, например, Rapid7, Nexpose, Tenable Nessus и eEye Retina Network Scanner.

Сканеры уязвимостей также можно настроить для выполнения быстрого поверхностного обнаружения хостов или простого сканирования открытых портов. Оно не даст таких же полных результатов в отношении запущенных или уязвимых приложений как полноценное сканирование, однако займет гораздо меньше времени. Если у SOC нет полноценного инструмента для сканирования уязвимостей, можно использовать средство сканирования портов, самое популярное среди них – Nmap.

Как ранее обсуждалось в Главе 2.4, SOC часто приходится выполнять сканирование уязвимостей на некоторой части сетей заказчика. Осуществляя э задачу, SOC действует как информатор, давая независимую оценку действиям IT-подразделения по своевременному обновлению систем. В глазах IT-отдела SOC может восприниматься как негативный персонаж, однако это балансируется тем фактом, что у SOC есть понимание о реальной степени уязвимости заказчика и именно он является той самой «надеждой и опорой», которая сообщает различным заинтересованным сторонам сведения о реальном положении дел.

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

Наконец, SOC важно получить соответствующие подтверждения (например, от CIO) и разослать уведомления, прежде чем проводить сканирование уязвимостей, портов или сетей. Подобные сканирования могут оказывать негативное воздействие на устаревшие системы, которые могут дать неоднозначную реакцию в ответ на нестандартный сетевой трафик, особенно при выполнении сканирования цифровых отпечатков операционных систем и приложений. При необходимости нужно аккуратно исключать такие системы. У SOC должна быть установленная договоренность между IT руководителями и руководителями подразделения по безопасности в отношении характера, частоты и источников сканирования. Перед опасными для инфраструктуры сканированиями необходимо рассылать предупредительные письма соответствующим системным администраторам и администраторам сети.

8.1.4 Пассивный сбор цифровых отпечатков

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

Свободно распространяемые средства, такие как P0f, XProbe2 и менее популярный коммерческий инструмент Sourcefire Real-time Network Awareness, используют пассивный подход к идентификации устройств с сети. Размещая их рядом или там же, где размещены распределённые по инфраструктуре организации сенсоры, SOC может улучшить обозримость сети с минимальными дополнительными затратами. Обычно в них используется библиотека захвата пакетов (libcap), тем самым формируя знакомую операционную среду. На практике некоторые коммерческие сетевые системы обнаружения вторжений (NIDS) можно настроить так, чтобы получать результаты пассивного сбора цифровых отпечатков операционных систем и приложений в формате предупреждений, также как при совпадении сигнатур.

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

Более подробную информацию по пассивному сбору цифровых отпечатков можно найти в [134].

8.1.5 Миссия и пользователи

Мы уже рассмотрели набор технологий и методик, которые SOC может использовать для понимания технических параметров заказчика. Вспоминая наши рассуждения о фундаментальных составляющих ситуационной осведомленности из главы 2.5, ситуационная осведомленность будет неполной, если картина не будет содержать действующих лиц (пользователей) и контекст миссии. Понимание топологии сети и конфигурации хоста – сравнительно более понятная и простая задача.

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

Вот несколько методик, которые помогут справиться с этими сложностями:

  • Отправляйте новый персонал SOC на вводный курс по бизнес-задачам заказчика. Если такого нет, попробуйте добавить его в программу обучения для SOC.
  • Аналитики Линии 2 могут постепенно накапливать знания о взаимосвязях IT-активов и бизнес-задач; попробуйте ввести на регулярной основе обмен знаниями между членами команды.
  • Карты сетей, особенно те, что составлены владельцами систем и инженерами проекта, зачастую содержат дополнительную информацию о предназначении систем; полезно задать несколько уточняющих вопросов администратору сети или инженеру, тщательно изучив карту сети.
  • Базы данных HR подразделения и системы управления идентификацией пользователя часто содержат пометки относительно положения в организации и бизнес-задачи каждого пользователя. Высококлассные SIEM системы и инструменты отслеживания внутренних нарушителей могут также собирать эти данные и осуществлять более продвинутую корреляцию в контексте пользовательских ролей.[1]
  • Некоторые заказчики собирают информацию обо всех своих департаментах и подразделениях в формате структурированной базы данных или вебсайта, к которым могут обращаться сотрудники или другие системы по запросу.


[1] – Как и при сборе любых данных, позволяющих идентифицировать личность, SOC необходимо тщательно соблюдать законодательство, которое может применяться ко сбору и хранению данных из систем и хранилищ, относящихся к управлению персоналом.

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