Корреляция предупреждений IDS и данных о вирусной активности

по материалам securityfocus

Небеса рушаться, небеса рушаться!  Ладно, ничего на самом деле не рушится, но не такое ли чувство возникало у нас, когда мы впервые установили NIDS и включили её? Перед нашими глазами пролетали предупреждения быстрее чем мы могли увидеть о чем они. Если бы нам повезло, то мы смогли бы заметить только какого цвета были предупреждения. К сожалению, этот недостаток присущ большинству продуктов индустрии обнаружения вторжений. Некоторые люди, установившие  NIDS, зачастую даже не смотрят на то, что система выводит на экран, и счастливо сообщают проверяющим: «А как же, конечно мы используем систему обнаружения вторжений. Мы используем <вставьте здесь известное название>».

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

При создании сигнатуры, ей назначается уровень важности по умолчанию, основываясь на опасности эксплойта. Если у вас включены все HTTP сигнатуры, и вы используете только Apache, должны ли предупреждения о Code Red восприниматься как высоко опасные? А что если у вас работает магазин на IIS и все сервера обновлены? Должны ли в таком случае предупреждения о Code Red  считаться опасными?

В начале.

Когда впервые появились IDS, все они по большому счету делали одно и тоже: сравнивали текущий пакет с набором известных эксплойтов. Потом Dug Song написал fragroute. Это был первый широко известный инструмент для обхода IDS. Thomas Ptacek и Timothy Newsham годом раньше написали об обходе защиты IDS, и fragrouter воплотил их идеи в реальность. Теперь любой, имеющий *NIX систему мог обойти защиту NIDS. Идея была довольно проста, и заключалась в использовании фрагментированных IP пакетов для разбиения кода эксплойта на несколько пакетов. Большинство NIDS не выполняли никакой сборки пакетов [1], поэтому, когда IDS пыталась сравнить сигнатуру с лишь частью атаки, она пропускала атаку. Лишь несколько поставщиков IDS в то время могли справиться с таким типом атаки. Все поставщики, чьи системы были неподготовлены к технике обмана fragroute, в срочном порядке начали работу над обновлением своих систем.

Прошло три года, после того, как Dug выпустил fragroute. Утилита уже вышла за пределы статьи Ptacek и Newsham. Теперь простой сборки IP пакетов было недостаточно. NIDS было необходимо анализировать каждый поток и собирать пакеты на четвертом уровне. На первый взгляд это легко сделать, не так ли? На самом деле все не так просто. RFC являются только руководящими документами о том, как должен быть реализован протокол. RFC не написаны на камне, и каждый, кто пишет протокол, основанный на RFC, может иметь свои небольшие ньюансы в его реализации. Представьте себе, что NIDS видит TCP пакет, которые по какой-либо причине был передан повторно. Как он должен быть воспринят? Какой пакет должна выбрать IDS: старый или новый? При нормальных условиях данные в обоих пакетах должны быть одинаковыми, но здесь мы имеем дело с обходом защиты NIDS, поэтому данные в этих пакетах могут быть разными. В связи с этим становится очень важным правильно собрать пакеты. Но что значит правильно собрать пакеты TCP потока? Это зависит от реализации TCP/IP. На данный момент есть еще одна проблема с NIDS. Так как NIDS находится перед защищаемым хостом, она не может знать, как конечная система будет обрабатывать пакеты. Если система обработает пакеты не так, то вполне возможно, что она сгенерирует ложную тревогу или, что еще хуже, пропустит атаку.

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

Отличное сочетание

Системы, специфичные для информационной безопасности обычно являются точечными системами. Этим я подразумеваю то, что каждая из них защищает информацию компании, не зная, что есть другие системы и информация, которую они предоставляют. В то время как большинство поставщиков предлагают специфичные технологии или продукты  (например IDS, firewall, защиту от вирусов), взаимодействие между собой у этих продуктов в большинстве случаев отсутствует [2]. SIMS (Security Information Management Systems) казалось бы являются долгожданным решением, но они не обеспечивают должного уровня надежности. Системы должны коррелировать информацию между несколькими продуктами, предоставляя пользователю информацию, полученную из отдельных систем.

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

Сейчас существует несколько поставщиков [3], продукты которых могут коррелировать информацию почти в реальном времени. Кроме того, что информация от систем поиска уязвимостей и  IDS коррелируется, сообщения сортируются по категориям и представляются в более удобном виде. Раньше консоли IDS были основаны на доставке каждого сообщения почти в реальном времени. Это хорошо работало пару лет назад, когда атаки не были такими частыми и черви не были так распространены. Сейчас червей гораздо больше. Они ищут уязвимые машины и когда машина найдена, запускается атака и в течении нескольких секунд червь зажжет ваш консоль таким количеством сообщений, которое вы не сможете расшифровать. С использованием корреляции событий, выводимые данные менее избыточны и имеют больше смысла.

Вы спросите: не является ли такая технология урезанной версией SIMS? Это не совсем так. SIMS основана на корреляции данных большого количества разных систем (IDS, firewall, маршрутизаторов и т.д.), что занимает длительное время для выявления атаки из-за большого объема всех журналов. Системы управления предупреждениями анализируют только  предупреждения IDS, смотрят, является ли атакуемая машина уязвимой для данной атаки и устанавливают приоритеты предупреждений на основе результатов корреляции. Ложные срабатывания все равно останутся, но система управления предупреждениями поможет установить приоритеты предупреждений таким образом, что ложные срабатывания будут показываться после остальных.

Управление предупреждениями

Нравится нам это или нет, концепция информационной безопасности заключается в учете рисков, а не в установке максимально возможного уровня безопасности. Если бы мы были пуристами безопасности, то мы бы оказались бы в такой же ситуации, как CIA [4]. Наша работа состоит в том, чтобы свести риски к уровню, приемлемому для компании. Корреляция данных анализа уязвимостей с данными IDS тем не менее может быть хорошей основой для системы управления предупреждениями.

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

Первым шагом в работе червя является сканирование порта, на котором обычно находится уязвимое программное обеспечение. В случае Code Red и Nimda это 80 порт TCP.

1. Обычная консоль IDS. Количество выводимых данных будет зависеть от следующих факторов:

• Число используемых IDS. Если атаку обнаружат сразу несколько IDS, тогда один единственный пакет вызовет множественные предупреждения.
• Число публично доступных защищаемых адресов. Одна и та же атака, в случае сканирования адресов класса B может вызвать много предупреждений.

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

Вторым шагом в работе червя, является попытка эксплойта хоста, который он нашел на первом шаге.

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

2. Система управления предупреждениями. Все предупреждения об атаке группируются в одно. Единственное что изменяется - это счетчик атак. Корреляционная система поставит в соответствие сканирование и саму атаку. Уровень опасности предупреждения может меняться и устанавливается в зависимости от информации в базе уязвимостей.

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

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

2. Система управления предупреждениями. Система установит наивысший приоритет предупреждениям и среагирует на эти предупреждения так, как она сконфигурирована. Все три события коррелируются между собой. Вместо того, чтобы показывать все события, аналитику предоставляется минимальный объем информации. Счетчик событий исключает необходимость каждый раз показывать сами события. Реальная угроза была обнаружена и данные об этом были представлены аналитику в доступной форме. Ниже приведены скриншоты двух разных продуктов: ISS Site Ptotector 2.0 с Fusion 2.0 и Tenable Network Security’s Lightning Console.

На рисунке 1, все схожие атаки организованы в виде единого события, которое и видит аналитик. Изменяются только такие поля события как источник, цель и счетчик. Модуль Fusion 2.0 коррелирует информацию NIDS (RealSecure) с информацией системы обнаружения уязвимостей (Internet Scanner) и обновляет колонку “Status”. После этого аналитик может исследовать предупреждения, основываясь на информации об успешности атаки. Событие “HTTP_Code_Red_II” из-за корреляции было классифицировано как событие с низким приоритетом,  хотя по умолчанию это событие имеет высокий приоритет.

В следующем примере, на рисунке 2, показано как предупреждения от всех IDS (Dragon, Snort, ISS, Bro) коррелируются с информацией системы поиска уязвимостей (Nessus). Любая атака, которая может завершиться успешно, помечается, и аналитик имеет возможность должным образом среагировать на опасность.

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

На рисунке 4 показан другой тип диаграммы, показывающей количество опасных атак.

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

Заключение.

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

Ссылки

[1] http://archives.neohapsis.com/archives/ids/1999-q4/0189.html

[2] Поставщики вроде CheckPoint предоставляют интеграцию со своими продуктами при помощи API.

[3] На данный момент автору известны лишь два поставщика, с продуктами, учитывающими специфичные данные о системе и генерирующие события почти в реальном времени: Tenable Network Security и ISS.

[4] Report: Too Much Cyber Security at the CIA http://www.securityfocus.com/news/5201