Корреляция на службе безопасности
Алексей Лукацкий,
руководитель отдела Internet-решений НИП "Информзащита"
luka@infosec.ru
Многие специалисты считают, что ложное обнаружение атак лучше, чем отсутствие сообщений о них. Однако это как раз тот самый случай, когда количество переходит в качество — в плохое качество работы. Ведь со временем вал таких сообщений становится "головной болью" любого администратора, которому приходится решать, реагировать ли на очередное появившееся на консоли предупреждение или игнорировать его. Чаще всего он просто перестает обращать внимание на все такие сообщения, независимо от содержания, что рано или поздно приводит к самым тяжелым последствиям.
Системы обнаружения атак мертвы?
В потоке информации, постоянно поступающем на экран консоли администратора безопасности, есть множество предупреждений и сообщений от установленных в сети средств защиты. Это и диагностика от систем сканирования периметра сети, и обнаруженные попытки подбора пароля на узлах, видимых из Интернета, и выявленные атаки червей (Slammer и т. п.), и злонамеренное использование уязвимостей Web-сервера, и многое другое.
Подобные сообщения могут поступать от различных средств обеспечения безопасности, начиная от фильтрующего маршрутизатора и межсетевого экрана и заканчивая системами обнаружения атак и средствами контроля содержимого. Одна из первых задач администратора безопасности — отделить "зерна от плевел" и определить, какие атаки требуют немедленной реакции, какие подождут, а какие можно спокойно проигнорировать.
И эта задача не была бы столь сложна, если бы все сообщения, сгенерированные средствами защиты, соответствовали реальным атакам. Однако в действительности атак, которые могут нанести реальный ущерб ресурсам корпоративной сети, несоизмеримо меньше, чем событий, фиксируемых защитными механизмами.
Мнение о том, что ложное сообщение лучше, чем его отсутствие, далеко не всегда оправданно. Как тут не вспомнить сказку о пастушке, который так часто кричал: "…волки, волки", что все перестали обращать внимание на эти крики. И когда в действительности напали волки, никто не пришел на его зов о помощи, и волки спокойно задрали стадо.
Но вернемся к системам обнаружения атак. В табл. 1 приведен фрагмент журнала регистрации широко известной в России системы обнаружения атак RealSecure Network 10/100, которая зафиксировала распространение червя Slammer, причинившего немало бед в начале этого года. Подобных записей в журнале только за один день может накопиться не менее нескольких десятков тысяч, ведь скорость распространения Slammer составляет несколько узлов (не морских, а сетевых) в секунду. Конечно, проанализировать такое количество информации непросто, и аналогичные проблемы, возникающие у администраторов безопасности, дали повод некоторым специалистам утверждать, что системы обнаружения атак уже не справляются со своими задачами, а многие журналисты даже стали использовать в своих статьях громкие заголовки типа "системы обнаружения атак мертвы". Однако, как было справедливо замечено одним из экспертов в области выявления атак, "…это проблема не систем обнаружения атак, а систем представления данных и управления ими".
Таблица 1. Атака червя Slammer
| Дата | Время | Событие | Нарушитель | Цель | Прото-кол | Порт источ-ника | Порт назна-чения |
| 4/8/2003 | 23:14:53 | SQL_SSRP_StackBo | 194.98.93.252 | 139.92.229.160 | UDP | 1690 | 1434 |
| 4/8/2003 | 23:14:54 | SQL_SSRP_StackBo | 139.92.229.160 | 213.253.214.34 | UDP | 1080 | 1434 |
| 4/8/2003 | 23:14:54 | SQL_SSRP_StackBo | 139.92.229.160 | 213.253.214.35 | UDP | 1081 | 1434 |
| 4/8/2003 | 23:14:54 | SQL_SSRP_StackBo | 139.92.229.160 | 213.253.214.36 | UDP | 1082 | 1434 |
| 4/8/2003 | 23:14:55 | SQL_SSRP_StackBo | 139.92.229.160 | 213.253.214.37 | UDP | 1083 | 1434 |
| 4/9/2003 | 23:14:55 | SQL_SSRP_StackBo | 139.92.229.160 | 213.253.214.38 | UDP | 1084 | 1434 |
| 4/9/2003 | 23:14:55 | SQL_SSRP_StackBo | 139.92.229.160 | 213.253.214.39 | UDP | 1085 | 1434 |
| 4/9/2003 | 23:14:56 | SQL_SSRP_StackBo | 139.92.229.160 | 213.253.214.40 | UDP | 1086 | 1434 |
| 4/9/2003 | 23:14:56 | SQL_SSRP_StackBo | 139.92.229.160 | 213.253.214.41 | UDP | 1087 | 1434 |
| 4/9/2003 | 23:14:56 | SQL_SSRP_StackBo | 139.92.229.160 | 213.253.214.42 | UDP | 1088 | 1434 |
| 4/9/2003 | 23:14:56 | SQL_SSRP_StackBo | 139.92.229.160 | 213.253.214.43 | UDP | 1089 | 1434 |
| … | … | … | … | … | … | … | … |
Управление информационной безопасностью
Чтобы избежать описанных неприятностей, необходима эффективная система управления информационной безопасностью (Security Information Management System, SIMS), которая позволяет связать все используемые в сети защитные средства в единый управляемый комплекс. Такая система выполняет немало полезных функций. Прежде всего она унифицирует управление разнородными средствами в единых терминах политики безопасности и позволяет эффективно обновлять все управляемые средства защиты. SIMS умеет группировать защищаемые ресурсы по различным признакам, с тем чтобы фокусировать внимание на необходимых в данный момент узлах, и фильтровать фиксируемые события, устраняя тем самым "шумовые" данные и снижая нагрузку на администратора безопасности. Кроме того, она позволяет сопоставить данные от разнородных средств защиты, чтобы уменьшить количество ложных срабатываний и выделить из потока событий оповещения о реальных нарушениях политики безопасности. И наконец, эта система позволяет снизить затраты времени и средств на изучение разных консолей управления. Применение SIMS дает администратору возможность оперативно получить ответы на множество вопросов, таких, как:
- уязвим ли атакуемый узел к зафиксированной атаке;
- нанесла ли атака ущерб ресурсам сети;
- заблокировал ли установленный на атакуемом узле агент системы защиты зафиксированную атаку;
- какая система атакуется в данный момент;
- какие узлы сети являются источниками атак.
Эффективная система управления информационной безопасностью должна, помимо прочего, поддерживать четыре основных механизма управления событиями: консолидацию (event consolidation), агрегирование (event aggregation), корреляцию (event correlation) и приоритизацию (event prioritization).
Консолидация
Первый шаг в снижении нагрузки на администратора — объединение всех событий от разнородных средств защиты информации на одной консоли. Такая консолидация (несмотря на созвучие, последний термин не связан с консолью, а означает сбор информации) совершенно необходима в тех случаях, когда администратор просто "шалеет" от постоянно мелькающих на экране сообщений, которые невозможно не то что проанализировать, а даже успеть прочесть (см., например, табл. 2). Несколько сотен тысяч событий в день — это, увы, реальность наших дней. А в крупных сетях ежедневная порция информации, которая "сваливается" на администратора, может превысить миллион сообщений. Справиться с такими объемами информации не под силу ни одному человеку.
Таблица 2. Пример работы механизма консолидации событий системы RealSecure
SiteProtector с установленным модулем Third Party Module
| Степень риска | Событие | Имя сенсора | Тип сенсора |
| Низкая | fw-cisco~ids-packet-not-IPSEC-packet | cisco_fw_ras | Cisco PIX FW |
| Высокая | fw-checkpoint~SYN Attack | cp_fw_dmz | Check Point FW |
| Высокая | Backdoor-BO2k | network_sensor_1 | RealSecure Network |
| … | … | … | … |
Консолидация — не просто сбор и помещение данных в единое хранилище. Это и
нормализация данных, т. е. устранение избыточной информации. Другими словами,
в процессе нормализации SIMS удаляет повторяющиеся сообщения об атаках, полученные
из нескольких источников, например, от системы обнаружения атак и межсетевого
экрана, и исключает противоречивость при организации их хранения. В идеале одно
сообщение об атаке должно храниться только в одном месте.
На этом же этапе обработки информации обычно все данные приводятся к единому времени, что особенно важно, если управляемые средства защиты разбросаны по нескольким часовым поясам нашей необъятной страны.
Здесь следует заметить, что производители средств защиты до сих пор не пришли к унификации формата сообщений об атаках, поэтому каждый разработчик SIMS по-своему решает проблему приведения всех сообщений к единому виду. Надо сказать, что данная задача далеко не тривиальна, так как системы обнаружения атак, межсетевые экраны, средства VPN, антивирусное ПО и прочие элементы защиты фиксируют разные параметры, связанные с несанкционированными действиями.
Однако, собрав все данные в одном хранилище, мы не избавились от проблемы огромных объемов информации, отображаемых на консоли администратора безопасности. Ее призван устранить механизм агрегирования.
Агрегирование
После процедуры консолидации событий начинается процесс их агрегирования, т. е. группировки по типам. Агрегирование дает возможность получить на экране вместо 10 тыс. повторяющихся строк "UDP-Scan" или "SQL_SSRP_StackBo" (краткое название атаки Slammer в системе RealSecure Network 10/100) всего лишь одну строчку, которая дополнена новым параметром "число событий" (табл. 3). Иными словами, агрегирование облегчает отображение данных и их анализ. Но и этого недостаточно для решения всей проблемы.
Таблица 3. Снижение объема информации, отображаемой на консоли
| Степень риска | Событие | Число событий | Источник |
| Низкая | UDP-Scan | 11385 | 194.98.93.252 |
| Высокая | Backdoor-BO2k | 1 | 194.98.93.252 |
| Высокая | SQL_SSRP_StackBo | 1567 | 139.92.229.160 |
| … | … | … | … |
Агрегирование не спасает от появления сообщений о тех атаках, которые не несут
с собой никакой угрозы. Нужна более интеллектуальная обработка событий, которую
обеспечивает механизм корреляции.
Корреляция
Получив сообщение о том, что сеть атакована, например, червем Slammer, многие администраторы приходят в ужас и начинают лихорадочно вспоминать, а "пропатчили" ли они свои узлы. В пылу они часто способны забыть, что в сети, например, нет серверов на базе Microsoft SQL Server и потому даже самая серьезная атака (например, Slammer) не нанесет никакого вреда, либо, если такие серверы и имеются, то давно защищены. Похожие ситуации бывают и при других атаках.
А что, если на эти сообщения не надо реагировать вообще (как бы ни парадоксально это звучало)? Ведь не каждый хакер знает всю "подноготную" вашей сети. Зачастую он наугад пытается атаковать ресурсы, и его атака не только не нанесет сети никакого ущерба, но и в принципе неприменима к данной конфигурации. Например, появившийся относительно недавно червь SMBdie страшен только Windows-узлам, да и то только тем, на которых не установлен соответствующий Service Pack. Unix-машины для него неуязвимы. Так зачем же реагировать на появление сообщения об атаке SMBdie?
Однако такие успокаивающие рассуждения хороши, если ваша сеть небольшого размера и вы помните, что и где у вас установлено. А если нет? Куда лучше, если сообщения, не несущие никакой угрозы, вообще не появляются на консоли и не отвлекают администратора от более важных дел. Механизм корреляции, т. е. поиска взаимосвязей между разнородными данными, решает именно эту проблему, снимая с администраторских плеч нагрузку проведения анализа вручную и сопоставления разрозненных данных.
Модуль корреляции в SIMS автоматизирует не только процесс сопоставления разнородных данных, но и анализ воздействия атаки на данные сетевые ресурсы. Процедура корреляции для различных объектов и уровней защиты реализуется по-разному.
Локальная корреляция осуществляется непосредственно на защищаемом узле,
в ней задействована система обнаружения и предотвращения атак уровня узла (host-based
ID&PS), которая всегда оповещает администратора безопасности о своих действиях
и либо отражает атаку, либо нет. В последнем случае система должна не только
зафиксировать атаку, но и оценить ее воздействие на атакуемый узел, хотя процесс
расследования инцидентов по-прежнему инициируется человеком — специалистом по
безопасности.
Корреляция со сведениями об операционной системе. Если Windows-атака
направлена на Unix-узел, то ее можно игнорировать, и система сама принимает
данное решение. Если же атака применима к данной ОС, то в действие вступает
следующий вариант корреляции.
Корреляция атак и уязвимостей. Согласно определению атаки, она не может
быть успешна, если атакуемый узел или сегмент сети не содержит уязвимости. Таким
образом, сопоставляя данные об атаке и информацию об уязвимостях атакуемого
узла или сегмента, можно с уверенностью сказать, применима ли зафиксированная
атака к конкретной сети, и если да, то нанесет ли она какой-либо ущерб.
Результат работы механизма корреляции — это обычно одно результирующее сообщение
в строке статуса атаки с разъяснением причины такого вывода (см. врезку "Статусные
сообщения об атаке").
Статусные сообщения об атаке
|
Существуют и другие механизмы корреляции, облегчающие работу администратора.
Например, анализ шаблона атаки позволяет сделать вывод об использовании
того или иного средства реализации атаки и оценить квалификацию хакера, чтобы
в зависимости от этого предпринимать те или иные действия. Функция сопоставления
данных за заданный интервал времени обеспечивает объединение в едином сообщении
об атаке нескольких однотипных или разных событий: например, несколько неудачных
попыток входа в систему с одного из узлов сети за короткий интервал времени
могут указывать на попытку подбора пароля.
Приведем распространенные примеры, иллюстрирующие необходимость применения механизма корреляции. Так, сразу после обнаружения факта сканирования Web-сервера (что само по себе событие нередкое) фиксируется попытка использования уязвимости Unicode в сервере Microsoft Internet Information Server. Рассматриваемые по отдельности, эти события могут говорить как о реальной атаке, так и о ложном срабатывании. Совокупность же таких фактов, разделенных очень коротким интервалом времени, с весьма высокой вероятностью указывает на то, что происходит атака, направленная на взлом сайта.
Возможна другая, более сложная ситуация, когда один из узлов сети был успешно атакован и после этого сам стал базой для дальнейшего распространения атаки. Система корреляции, сопоставив различные данные, может обнаружить и уведомить администратора о данном факте. Это событие в журнале регистрации системы обнаружения атак может выглядеть как, например, выделенные цветом строки в табл. 1, а система корреляции представляет его несколько иным образом (см. первую строчку табл. 4).
Таблица 4. Пример работы механизма корреляции системы RealSecure SiteProtector
с установленным модулем SecurityFusion Module
| Степень риска | Событие | Число событий | Источник |
| Высокая | Attack_From__Compromised_Host | 1567 | 139.92.229.160 |
| Высокая | Targeted_Break_In_Attempt | 1 | 194.98.93.252 |
| … | … | … | … |
Кстати, следует обратить внимание на очень тонкий момент при выборе системы
управления информационной безопасности. Многие из производителей в своих рекламных
материалах упоминают о поддержке огромного количества разнородных средств защиты
(до нескольких десятков), перечисляя известнейшие брэнды. Но на деле под поддержкой
понимается только сбор данных от этих средств — и не более того.
Разработчик SIMS должен обновлять свое ПО столь же оперативно, как появляются патчи или новые версии поддерживаемых данным продуктом систем. Кроме того, при выходе обновления системы обнаружения атак или сканера необходимо пополнить базу знаний системы корреляции, добавив в нее информацию о новых уязвимостях и атаках. В противном случае нельзя рассчитывать на качественный и полный анализ событий, ведь среди потока могут оказаться и неизвестные "фигуранты". Об этом умалчивают многие производители средств выявления атак, считая достаточным указать в рекламных материалах лишь факт поддержки разнообразных средств анализа защищенности, межсетевых экранов, систем обнаружения атак, прокси-серверов и т. д. Поэтому максимум, на что можно надеяться, устанавливая подобный продукт, — это на сбор данных от разных источников, а о функциях агрегирования и корреляции событий следует забыть.
Однако есть и такие поставщики (к примеру, Internet Security Systems, Cisco и ряд других), которые не обещают "золотых гор", но зато гарантируют полную поддержку всех своих решений и, возможно, нескольких решений иных производителей.
Приоритизация
Одна и та же атака может иметь различные последствия для разных узлов корпоративной сети. Например, узел, работающий под управлением ОС Solaris 2.5.1, уязвим для атаки Ping of Death, а для узла с ОС Windows NT она не опасна. Другой пример — наличие модема в сети. Если он подключен к компьютеру с выполнением всех требований информационной безопасности, то такой ПК не требует пристального внимания администратора безопасности. Если же модем подключен в обход межсетевого экрана, то просто не имеет права на существование в сети и должен быть немедленно удален. Еще один пример — сервис Telnet необходим на маршрутизаторе, но не нужен на большинстве рабочих станций.
Система централизованного мониторинга атак должна предусматривать возможность задавать приоритеты для обнаруживаемых атак или уязвимостей, причем как статически (три приведенных выше примера), так и динамически.
Дело в том, что иногда для правильной интерпретации событий недостаточно статического метода задания приоритетов, нужно определить их динамическое изменение. Допустим, на компьютере существует учетная запись Guest, с помощью которой любой пользователь (в том числе и злоумышленник) сможет "творить" все, что ему заблагорассудится. В обычных условиях эта уязвимость имеет высокий приоритет. Однако на практике, в зависимости от того, разрешена (enable) ли эта учетная запись или запрещена (disable), данная уязвимость может иметь соответственно самый высокий или самый низкий приоритет. В такой ситуации приоритет может быть назначен только после корреляции событий, т. е. он должен задаваться динамически (ср. табл. 5 и 6).
Таблица 5. Пример работы механизма корреляции системы RealSecure SiteProtector
с установленным модулем SecurityFusion Module
| Степень риска | Событие | Число событий | Статус |
| Низкая | NMap-Scan | 139 | Воздействие неизвестно (корреляция не проводилась) |
| Средняя | SMTP-Sendmail-Relay | 1 | Вероятно, неудачная атака (узел неуязвим) |
| Высокая | Backdoor-BO2k | 1 | Неудачная атака (узел блокировал атаку) |
Таблица 6. Пример работы механизма динамической приоритизации системы RealSecure
SiteProtector с установленным модулем SecurityFusion Module
| Степень риска | Событие | Число событий | Источник |
| Высокая | UDP-Scan | 11385 | 194.98.93.252 |
| Низкая | Backdoor-BO2k | 1 | 194.98.93.252 |
| Низкая | SQL_SSRP_StackBo | 1567 | 139.92.229.160 |
| … | … | … | … |
Огласите список, пожалуйста!
Количество систем корреляции на рынке средств защиты постоянно растет, расширяется и перечень их разработчиков (см. врезку "Системы корреляции").
Однако, несмотря на рост интереса к таким продуктам на Западе, в России о них
известно пока мало, и это закономерно. У нас далеко не во всех сетях установлены
системы обнаружения атак и межсетевые экраны. Что уж говорить о средствах, расположенных
существенно выше на эволюционной лестнице защитных механизмов.
Системы корреляции
|
Тем не менее в России уже можно приобрести некоторые системы управления информационной
безопасностью, в частности, таких известных в мире защиты информации безопасности
компаний, как Internet Security Systems (ISS), Cisco Systems и Symantec.
Продукт ISS — бесплатный пакет ПО RealSecure SiteProtector (http://www.infosec.ru/-produkt/adapt/-siteprotector/sp.html),
система, в которой имеются описанные выше механизмы консолидации, агрегирования,
корреляции и визуализации событий. Источниками событий для нее служат не только
все решения ISS в области обнаружения атак и анализа защищенности (а их около
десятка), но и межсетевые экраны Check Point Firewall-1, Cisco PIX Firewall
и ряд других средств защиты. Из всех представленных на российском рынке это
самая "старая" система — ей уже около двух лет. Поскольку спектр "чужих" решений,
которые поддерживает эта система, не бесконечен, она не слишком требовательна
к системным ресурсам.
Выпущенная 30 июня 2003 г. система CiscoWorks Security Information Management
Solution компании Cisco (http://www.cisco.com/en/US/-products/sw/cscowork/-ps5209/index.html)
построена на базе широко известной на Западе системы управления информационной
безопасностью netForensics одноименной компании (http://www.netforensics.com).
Данная система весьма ресурсоемка (она требует наличия на сервере управления
как минимум 4 Гбайт оперативной памяти). CiscoWorks SIMS ориентирована в первую
очередь на собственную продукцию Cisco и "понимает" только сообщения, генерируемые
межсетевыми экранами Cisco PIX Firewall, системами обнаружения атак Cisco IDS,
VPN-концентраторами и маршрутизаторами, хотя в список поддерживаемых устройств
входят сетевые средства защиты и других производителей — Check Point, Arbor,
CyberGuard, Enterasys, NAI, ISS, NetScreen, NFR, Symantec и Tripwire. Стоимость
продукта с поддержкой 30 устройств составляет 40 тыс. долл. Дополнительный контроль
еще 20 средств защиты обойдется еще в 20 тыс. долл.
И наконец, компания Symantec предлагает систему Symantec Incident Manager (http://enterprisesecurity.-symantec.com/products/-products.cfm?productid=166&EID=0),
которая по своей идеологии и системным требованиям похожа на решения Cisco и
ISS. Однако данная система еще очень молода, и автору не удалось найти на сайте
Symantec ни списка поддерживаемых защитных устройств, ни цен на компоненты Incident
Manager. Можно предположить, что данный продукт будет поддерживать как минимум
большинство из собственных решений Symantec.
Что же касается выбора системы корреляции, то очевидная рекомендация такова: если компания в качестве стандарта сетевой защиты выбрала один из названных выше продуктов фирм ISS, Cisco или Symantec, то и система корреляции должна быть от того же производителя.
***
С точки зрения информационной безопасности уровень зрелости компании определяется не количеством установленных в ее сети межсетевых экранов и систем обнаружения атак, а умением управлять ими. Одно из средств, позволяющих это сделать, — системы управления защитой, которые с каждым годом становятся все более востребованными. По оценкам компании IDC, в мире в 2002 г. было приобретено SIMS на сумму 665 млн долл., а систем корреляции — на 100 млн долл. К 2005 г. IDC прогнозирует рост объема рынка таких систем до 1759 млн долл. (в том числе рынка систем корреляции — до 405 млн долл.). Однако, несмотря на большое желание (89% респондентов) применять такие средства управления в своей повседневной деятельности, только 5% компаний задействуют всю мощь этих решений (в России число компаний, которые задействовали в своих сетях системы управления безопасностью, измеряется сотыми долями процента). Остается надеяться, что в условиях растущей угрозы кибертерроризма отношение к таким системам изменится.