Стратегия 6. Часть 3. Анализ трафика, данные и метаданные.

8.2.3 Данные NetFlow

IDS просматривает весь контент сетевого трафика, однако нужна возможность просуммировать весь сетевой трафик, не оказывая большого воздействия на производительность. Дополнением к оповещениям IDS служат записи NetFlow (часто упоминаются как потоки). В отличие от записи или анализа всего содержимого соединений, запись потока содержит краткий обзор каждого сетевого соединения. Исходно стандарт NetFlow был разработан компанией Cisco, но теперь используется в различных сетевых устройствах и ПО и является стандартом Internet Engineering Task Force.

Устройство, генерирующее данные NetFlow, можно сравнить с регистратором телефонных звонков. Регистратор — это устройство, которое фиксирует все входящие и исходящие телефонные звонки по определенной линии, включая время, продолжительность, номера телефонов абонентов. Регистратор телефонных звонков только записывает информацию о совершенных звонках, но не сохраняет содержание звонка – что было сказано при разговоре. NetFlow в этом смысле похож на регистратор TCP/IP соединений. NetFlow не дает информации о том, что было сказано, а дает понять, что разговор состоялся.

Существуют различные инструменты генерации и управления NetFlow, каждая запись обычно содержит следующую информацию:

  • Время начала
  • Время окончания (или продолжительность с момента начала)
  • IP источника и назначения
  • Порт источник и назначения
  • Протокол уровня 4 – TCP, UDP или ICMP
  • Сколько отправлено и получено байт
  • Установленные флаги TCP (если это поток TCP).

Содержимое сетевого подключения может составлять несколько гигабайт (ГБ), а одна запись потока – меньше нескольких килобайт (КБ). Поэтому сила NetFlow в его простоте. Сбор и анализ записей NetFlow считается эффективным способом определения происходящей деятельности в сети любой конфигурации и размера. Важно понимать, что записи NetFlow обычно не содержат содержимого сетевого трафика выше Уровня OSI 4. И это плюс, поскольку (1) для их генерации требуется небольшая вычислительная мощность, (2) они занимают мало места при хранении или передаче, (3) они не зависят от большинства форм шифрования, таких как SSL/TLS, и (4) всего несколько записей потока могут заменить гигабайты или терабайты сетевого трафика. Минус в том, что они ничего не сообщают о полезной нагрузке этого трафика. IDS требует значительных вычислительных мощностей для оповещения лишь о подозрительном трафике, а инструменты генерации NetFlow потребляют очень небольшую вычислительную мощность для агрегации всего трафика.

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

Записи потока может генерировать ряд устройств, включая:

  • Роутеры и коммутаторы; официальный формат записей NetFlow был разработан в Cisco;
  • Некоторые сетевые IDS/IPS в дополнение к их обычному потоку предупреждений;
  • Некоторые хостовые IDS/IPS, которые могут связать поток с процессом ОС, передающим через интересующий порт;
  • Пакеты программ, специально предназначенные для генерации, сбора и анализа потоков, такие как SiLK [67], Argus [66] и S / GUIL [141].

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

Инструменты NetFlow делятся на две части по аналогии со стандартной архитектурой развертывания IDS:

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

Некоторые инструменты для работы с NetFlow могут принимать записи потоков, созданные в сторонних системах, например, с помощью маршрутизаторов или коммутаторов. Argus, например, может собирать потоки в форматах Cisco NetFlow версий 5 и 9.

NetFlow имеет несколько ограничений. Среди них:

  • Как и любой другой инструмент сетевого мониторинга, сенсор NetFlow не может генерировать записи по трафику, который проходит мимо. Поэтому важно аккуратно размещать датчики NetFlow в инфраструктуре заказчика.
  • Классические записи NetFlow не записывают данные о содержимом сетевого трафика выше уровня 4 TCP/IP. Даже если поток находится на порте 80, это необязательно означает, что его содержимое является легитимным веб-трафиком.
  • При больших нагрузках датчик NetFlow может собирать только часть сетевого трафика. В этом случае сгенерированные записи будут содержать неверное количество пакетов и байт, тем самым искажая полученную статистику и потенциально засоряя последующие сценарии использования.
  • Как и другие возможности мониторинга сети, анализ NetFlow может быть частично ограничен при излишнем использовании технологий NAT и прокси в сети. По этой причине полезно собирать потоки по обе стороны прокси и/или логи самих прокси.
  • NetFlow иногда используется для анализа зашифрованных соединений, поскольку углубляться в сетевой стек не имеет смысла. Тем не менее, характер протокола должен быть тщательно проанализирован, поскольку при некоторых комбинациях туннелирования и шифрования анализ NetFlow может оказаться практически бесполезным.
  • Поскольку запись генерируется для каждого сеанса сетевого трафика, записи NetFlow могут превосходить большинство других потоков данных, собранных SOC, особенно если потоки собираются с конечных хостов.

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

8.2.4 Метаданные трафика

Как мы обсудим в Разделе 8.4 и Разделе 9.2, существует ряд источников логов, которые могут быть использованы SIEM для обнаружения потенциальных вторжений. Три самых популярные: (1) МСЭ, (2) почтовый прокси и (3) журналы веб-прокси. Они дают чрезвычайно полезную информацию – заголовки писем (отправитель, получатель, тема) и заголовки HTTP (запрошенный URL, user agent и referrer) для всего проходящего трафика. Однако во многих ситуациях эти логи недоступны, трудно анализируются или ненадежны.

К счастью, у нас есть альтернативы, которые продвигают NetFlow на один шаг дальше по стеку TCP/IP, предоставляя аналитикам те же метаданные трафика или «суперпотоки», которые они могли бы получить из других источников логов. Метаданные по объему сопоставимы с NetFlow с точки зрения количества записей, сгенерированных при загруженном сетевом соединении, однако могут служить расширенным источником данных о потенциальной угрозе вторжения. Рассмотрим определенный набор сайтов, на которых размещено вредоносное ПО. Этот список вредоносных URL-адресов можно сопоставить с метаданными входящего трафика для поиска потенциально опасных инфекций. Мы также можем собрать метаданные по DNS-запросам и ответам, которые могут использоваться для обнаружения вредоносных маяков и скрытого управления и контроля вредоносов. На самом деле, сбор метаданных с нужных точек сети позволяет нам быть более избирательными в отношении того, что собирать. Это позволяет снизить нагрузку на производительность как системы SOC по сбору данных, так и на сетевые сервисы, такие как DNS-серверы или почтовые шлюзы.

8.2.5 Полный захват и анализ сессии

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

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

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

Самая большая проблема с захватом полной сессии очевидна – это объем. Рассмотрим организацию с десятком тысяч хостов, которые проходят через одно подключение к Интернету – к примеру, OC-48, которое достигает максимальной скорости более двух гигабит. Давайте посмотрим, сколько данных мы сможем собрать в течение 24 часов при использовании на 50%:

2400 Мбит/с * 60с * 60мин * 24часа *0,5 загрузка / 8 бит на байт = 12,96 ТБ

На первый взгляд, это не выглядит непреодолимой проблемой. Один средний по цене NAS может хранить гораздо больше. Как мы обсудим в Разделе 9.2, аналитикам 2 Линии обычно требуется не менее 30 дней онлайн PCAP для целей анализа и реагирования, а лучше за 60 дней и более. Это означает, что у нас 30*12,96 ТБ = 388,8 ТБ. Это очень значительный объем данных, даже если рассматривать умеренное соединение и ограниченное хранение.

Несмотря на то, что сбор и хранение полных сессий не является тривиальной задачей, существует несколько довольно простых способов это осуществить. Популярные утилиты с открытым исходным кодом типа tcpdump, тщательная оптимизация ОС и драйверов и применение скриптов можно комбинировать со стандартным серверным оборудованием для загрузки PCAP на скоростях, превышающих один Гб в секунду. В большинстве случаев проще всего подключить стандартный сервер с большим объемом встроенного хранилища к серии недорогих устройств хранения данных с прямым подключением (DASD), каждое на десятки ТБ. Если внимательно отнестись к фильтрации лишнего трафика и сжатию архивных данных, хранение данных за месяц и более в режиме онлайн не будет проблемой для большинства архитектур. Одна из самых больших сложностей при захвате PCAP – потеря пакетов, что является одной из главных причин для покупки специальных платформ для поддержки захвата пакетов со скоростью 10 Гбит/с и более. Это может быть оптимальным выбором для SOC, у которых нет ресурсов для создания и настройки системы сбора данных с высокой пропускной способностью.

8.2.6. Сценарии для применения открытых решений и виртуализации

Рассмотрим сетевые IDS/IPS корпоративного уровня, которые могут стоить от 5000 долларов США за скромное аппаратное устройство до более 100 000 долларов США за устройство, рассчитанное на множество 10 гигабайтных соединений. В Таблице 10 рассмотрены преимущества и недостатки различных вариантов платформ с учетом ценовых различий.

ПлатформаПреимуществаНедостатки
Программно-аппаратный комплекс (специализированный).

Интегральные схемы специального назначения (ASIC) или основанные на программируемых пользователем вентильных матрицах (FPGA) аппаратные средства, оптимизированные для приложений NIDS/NIPS.

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

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

Простое управление устройством.

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

Некоторые представляют собой нишевые решения и могут не обеспечивать всестороннего покрытия.

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

Разработка специализированного дизайна занимает больше времени, что означает более длительный цикл обновления продукта.

Программно-аппаратный комплекс (стандартный).

Вендоры размещают оригинальное программное обеспечение IDS на обычных ОС и оборудовании (как правило Linux х86).

Большинство NIDS/NIPS представляют собой именно такую форму.

Развертывание «под ключ» и простое управление устройством.

Хорошая производительность из коробки при условии правильной настройки.

Одно устройство высокого класса может контролировать несколько высокоскоростных сетевых подключений.

Подобный функционал можно реализовать и с помощью программной IDS на стандартных аппаратных средствах.

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

Развертывание на множестве точек ограничено в силу стоимости устройств.

Программное обеспечение.

Разработчик поставляет продукт в виде программного пакета, который инсталлируется и настраивается клиентом самостоятельно.

Низкая стоимость без учета оборудования.

Возможность развертывания на недорогом стандартном оборудовании.

Некоторая ограниченность в доступе пользователей к устройству компонентов системы с риском слететь с вендорской поддержки.

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

Сочетание программного обеспечения IDS, различных аппаратных средств и платформ ОС могут усложнить процесс внедрения и устранения проблем.

При недостаточно тщательном подборе оборудования и настройке может возникнуть проблема потери пакетов.

Могут возникать сложности в обеспечении отказоустойчивости и надежности NIPS.

Немногие поставщики поставляют NIDS в виде ПО.

Виртуальное устройство.

Вендор поставляет разработанное NIDS/NIPS в виде виртуального контейнера с ограниченным доступом пользователей “под капот”.

По простоте в развертывании и управлении схожи с аппаратными средствами.

По гибкости в выборе оборудования и развертывании схожи с программными NIDS/NIPS.

Легко поддерживать мониторинг в виртуальных средах.

Сравнительно новый функционал.

По стоимости приближаются к аппаратным устройствам.

Аналогично программным NIPS, развертывание виртуальных NIPS может оказаться сложным с точки зрения обеспечения пропускной способности и отказоустойчивости.

Таблица 10. Характеристики коммерческих сетевых IDS/IPS.

Вспомним, что мы обсуждали в начале раздела 8.2. Нам требуется обеспечить  мониторинг с помощью сетевой IDS, сбор NetFlow и полный захват PCAP. Эти задачи легко выполняются с помощью открытых и свободных инструментов, таких как Snort, Argus (или ряда других, таких как SiLK) и tcpdump и небольшого количества скриптов, чтобы их интегрировать. На самом деле, дисковый ввод/вывод (I/O), а не память или процессор, может стать ограничивающим фактором для сбора PCAP. Более того, с появлением сетевых интерфейсных плат (NIC), специально созданных для высокоскоростных приложений IDS, мы можем реализовать те сценарии использования, которые ранее были невозможны из-за высокой стоимости интегральных схем специального назначения (ASIC) и платформ на основе FPGA.

В Таблице 11 приведены основные различия между передовыми открытыми и коммерческими сетевыми платформами IDS/IPS.

ХарактеристикиКоммерческие
(Commercial off-the-shelf)
Открытые
(Free & Open-Source Software)
КодЗакрытыйОткрытый
СигнатурыЗакрытые. Это может мешать в случае, когда аналитик хочет понять, почему событие сработало; количество и надежность пользовательских сигнатур временами очень ограничены.Открытые. Возможность оценить и создавать собственные сигнатуры на том же качественном уровне, что и поставляемые по умолчанию в продукте – ключевая особенность; при необходимости можно создавать тысячи пользовательских сигнатур.
Точность механизма определения протоколаОбычно очень хорошая. Это ноу-хау вендора и одна из отличительных особенностей.Также может быть очень хорошей, но зависит от того, может ли сообщество поспевать за развитием угроз и протоколов.
Предрасположенность к ложным срабатываниямСильно варьируется в зависимости от индивидуальных сигнатур и механизма обнаружения.Сильно варьируется в зависимости от индивидуальных сигнатур и механизма обнаружения.
Доступность сигнатур для новых критичных уязвимостейВ течение нескольких дней.В течение нескольких часов.
ПроизводительностьСпособны обрабатывать несколько гигабитных линий; более дорогие продукты поддерживают 10 гигабитные.Большинство решений могут без проблем обеспечивать гигабитный мониторинг на недорогом оборудовании; масштабирование до 10 гигабит и более обычно требует аппаратной и программной оптимизации.
Сложность в управленииУправление с помощью кликов мышкой, поэтому обучение новых сотрудников очень простое, но некоторые системы могут быть весьма трудными в управлении из-за нескольких уровней сложности; некоторые коммерческие решения становятся сложными в управлении при большом количестве датчиков.Для новичка это может быть непростой задачей; опытный администратор Linux/UNIX может автоматизировать управление большим парком датчиков без особого труда, используя привычные для среды UNIX инструменты.
Пригодность использования NIPS для блокировкиЗависит от инсталляции продукта; обычно от очень хорошего до превосходного уровня.Настройка вручную стандартного аппаратного обеспечения и операционных систем может осложнить этот вопрос, если в системе изначально не заложена отказоустойчивость.
Совокупная стоимость оборудования и ПО при реализации решенияОт умеренной до очень высокой, в зависимости от требований к пропускной способности; учитывайте ежегодные расходы на обслуживание на уровне 20-25% от первоначальной стоимости.При наличии нескольких талантливых администраторов Linux/UNIX систем, могут быть очень дешевыми, особенно при развертывании более 50 датчиков; единственные расходы в течение года – это поддержка оборудования.

Таблица 11. Сравнение коммерческих и открытых платформ сетевого мониторинга.

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

8.2.7 Детонация и анализ вредоносных программ

Если бы существовало killer app для NIDS/NIPS, оно скорее всего обнаруживало бы и блокировало прямые сетевые атаки, такие как переполнение буфера. Эти атаки прекратились в конце 2000-х. Вендоры улучшили защиту от атак на код, который исполняется на серверах и приложениях, напрямую подключенных к Интернету. В результате злоумышленники перефокусировались на использование слабых мест жертв с помощью фишинга и фарминга. В ходе таких атак пользователей вынуждают загружать вредоносный контент с веб-сайтов или электронной почты. Такая тактика работает по двум причинам: (1) большое количество уязвимостей все еще имеется в программах, работающих на конечных хостах, и (2) злоумышленники могут легко нацелиться на эти уязвимости, разместив вредоносный контент на веб-сайтах или отправив их по электронной почте потенциальным жертвам.

И хотя NIDS/NIPS могут в какой-то мере помочь, этот набор атак обычно за пределами возможностей системы обнаружения вторжений. При передаче PDF или документа Word по сети IDS видит поток закодированной двоичной информации. У сетевой СОВ обычно нет времени, чтобы собрать файл и оценить, что произойдет, если его запустить.

Появилось новое поколение «детонационных» продуктов для вредоносов или «песочниц», таких как FireEye AX, Norman Shark и ThreatTrack TreatAnalyzer, которые анализируют файлы, извлеченные из сетевого трафика или с конечных систем. Эти продукты иногда называют «антивирусами следующего поколения», что размывает позиционирование продуктов. Их главная задача – принимать потенциально вредоносные файлы, «детонировать» их в искусственной среде и наблюдать за поведением файлов в процессе исполнения.

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

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

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

На момент написания этой книги такие устройства были очень популярны. Тем не менее, есть некоторые ограничения и предостережения относительно устройств детонации контента, которые следует учитывать:

  • Многие авторы вредоносов заранее предполагают, что для их вредоноса будет применяться реверс-инжиниринг и детонация контента в виртуальной среде. Поэтому закладывают невозможность запустить его исполнение на виртуальной машине, что будет приводить к ложно-отрицательным результатам в детонационных камерах в виртуальных средах.
  • Некоторое вредоносное ПО требует взаимодействия с пользователем, прежде чем оно запустится. В детонационной камере не предусмотрен пользователь, который будет нажимать кнопки в диалоговом окне для запуска вредоносного ПО, поэтому возникнет ложноотрицательный результат. Может быть проблематичным создать и настроить такую систему детонации контента, которая обойдет эту проблему.
  • Некоторые эксплойты, такие как heap spraying, требуют весьма специфического размещения компонент ОС в памяти. Поскольку системы детонации контента стараются охватить как можно больше вариантов виртуальных машин на весьма скромной платформе, для полной эмуляции того, что будет происходить при запуске на реальном конечном хосте, может просто не хватить памяти. ВМ может иметь только один ГБ выделенной памяти, тогда как heap spraying может потребовать как минимум четырех ГБ. При таких условиях ожидаем ложноотрицательный результат.
  • Многие вредоносные программы далеко не идеальны и могут не всякий раз срабатывать при запуске. Скорее всего у устройства детонации контента будет только одна попытка запустить файл, который является потенциально вредоносным. Поэтому есть риск не отловить зловред с первого раза, что приведет к ложноотрицательному результату.
  • Некоторые вредоносные программы могут выжидать определенное время перед исполнением. Устройство детонации контента по истечении определенного количества циклов CPU или секунд будет отключаться. Некоторые авторы вредоносных программ специально предусматривают задержки в исполнении, чтобы избежать обнаружения антивирусами или устройствами детонации контента.
  • Устройства детонации контента запускают файлы внутри какой-то виртуальной машины или песочницы, которая должна соответствовать стандартным корпоративным конфигурациям. Однако они могут значительно отличаться от того, что на самом деле используется заказчиками. Важно убедиться, что ОС, браузер, плагины, версии приложений, пакеты обновлений песочницы совпадают с реально используемыми. Невыполнение этого требования может привести к ложноположительным или ложноотрицательным срабатываниям.
  • При использовании в разрыв в режиме блокировки устройство детонации контента может служить дополнительной точка отказа при доставке электронной почты или веб-контента. Если заказчик использует резервные почтовые или веб-шлюзы, SOC может также рассмотреть вопрос о выделении устройств детонации контента для каждого шлюза, тем самым сохраняя необходимый уровень резервирования, но это удорожает развертывание. В случае сбоя детонационное устройство должно оставаться «открытым», позволяя пропускать трафик.
  • Устройство детонации контента может исполнять только определенное количество файлов в заданный промежуток времени. Использование на высокоскоростных соединениях может оказаться проблематичным, поскольку некоторые файлы могут никогда не исполниться или может возникнуть проблема с ограничением в пропускной способности. SOC следует консультироваться с поставщиками для правильного подбора размера и использовать методы балансировки нагрузки при необходимости.
  • Скорее всего устройства детонации контента обнаружат вредоносное ПО, которое NIDS, HIDS, AV и средства фильтрации контента никогда не детектировали, что потенциально может вызвать тревогу отдельных сотрудников. Поэтому отчеты о вредоносных программах должны быть интерпретированы только тем, кто имеет опыт работы с вредоносными программами.
  • Осведомленность, которую дают устройства детонации контента, очень четко показывает, сколько вредоносных программ в день или неделю доходят до заказчика. Без дополнительной информации о том, удалось ли их избежать или заблокировать, может возникнуть серьезная тревога, хотя нет гарантий, что она обоснована.

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

8.2.8 Ханипоты

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

8.2.9 Будущее систем обнаружения вторжений

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

В 2003 году компания Gartner предрекала смерть сетевых IDS. Они утверждали, что из-за огромного количества ложных срабатываний, СОВ приносят больше проблем, чем пользы. К такому же заключению могли прийти и некоторые аналитики SOC. В конце концов, системы обнаружения вторжений не осуществляют ничего, кроме сбора большого числа данных, а некоторые аналитики считают это сомнительной ценностью. Из этого следует, что нам правильнее сосредоточить внимание на системах предотвращения вторжений, которые фактически блокируют атаки. В конце концов, NIPS основаны на тех же концепциях, что и NIDS, а их разработчики более тщательно контролируют ложные срабатывания и, предположительно, используют более надежные механизмы обнаружения и более качественные сигнатуры.

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

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

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

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