23.07.2003. Корреляция на службе безопасности

Системы обнаружения атак мертвы?

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

• сканирование периметра сети;
• подбор пароля на узлах, видимых из Интернет;
• атаки червей Slammer и т. п.;
• использование уязвимостей Web-сервера и т. п.

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

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

Многие специалисты считают, что ложное обнаружение лучше, чем отсутствие сообщения об атаке. Однако это как раз та ситуация, когда количество переходит в качество. Со временем это становится головной болью любого администратора, которому приходится решать, реагировать на появившееся на консоли сообщение или проигно­рировать его. В результате администратор просто перестает реагировать не только на ложные, но и на любые другие сообщения, в том числе и влекущие за собой тяжелые последствия. Например, в Таблице 1 показан фрагмент журнала регистрации широко известной в России системы обнаружения атак RealSecure Network 10/100, которая зафиксировала распространение червя Slammer, нашумевшего в начале этого года. Таких записей за период в один день в журнале может быть несколько десятков тысяч, ведь, как можно видеть, скорость распространения Slammer составляет несколько узлов в секунду.

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

Системы управления информационной безопасностью

Для того чтобы избежать описанных проблем, необходима эффективная система управления информационной безопасности (Security Information Management System, SIMS), которая позволяет все используемые защитные средства объединить в единый управляемый комплекс. Такая система:

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

Использование таких систем позволяет ответить на множество вопросов, постоянно возникающих в процессе обеспечения информационной безопасности, например:

• Уязвим ли атакуемый узел к зафиксированной атаке?
• Нанесла ли атака ущерб ресурсам моей сети?
• Заблокировал ли установленный на атакуемом узле агент системы защиты зафиксированную атаку?
• Какая система атакуется в данный момент?
• Какие узлы моей сети являются источниками атак?

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

• консолидация (event consolidation);
• агрегирование (event aggregation)
• корреляция (event correlation)
• приоритезация (event prioritization).

Консолидация событий

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

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

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

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

Агрегирование

После консолидации событий начинается процесс их агрегирования, то есть группирования однотипных событий вместе, что позволяет получить на экране вместо 10'000 повторяющихся строк « Scan» или «SQL_SSRP_StackBo» (краткое название атаки Slammer в системе RealSecure Network 10/100) всего лишь одну строчку, которая дополнена новым параметром «число событий» (см. Таблицу 3).

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

Корреляция

Получив сообщение о том, что, например, ваша сеть атакована червем Slammer многие администраторы приходят в ужас и лихорадочно начинают вспоминать, а пропатчили ли они свои узлы. А что если, даже самая серьезная атака (например, Slammer) не нанесет вам никакого вреда по той простой причине, что у вас нет серверов на базе MS SQL? А если они у вас есть, но вы их давно защитили? Аналогичная ситуация происходит и с другими атаками, которые отвлекают внимание администратора и требуют вмешательства. А что, если на них вообще не надо реагировать (как ни парадок­сально это звучит)? Ведь не каждый хакер знает всю подноготную вашей сети, и, зачастую, он наугад пытается атаковать ваши ресурсы, что приводит к тому, что атака не только не нанесет вам никакого ущерба, но и в принципе не может быть применима к вашей сети. Например, относительно недавно выпущенный SMBdie страшен только Windows-узлам, да и то, только тем, на которых не был установлен соответствующий Service Pack. Unix-машины к нему неуязвимы. Так зачем же реагировать на появление сообщения об атаке SMBdie? Хорошо, если ваша сеть небольшого размера и вы помните, что и где у вас установлено. А если нет? Куда лучше, если сообщения, не несущие никакой угрозы, вообще бы не показывались у вас на консоли и не отвле­кали бы вас от более важных дел. Механизм корреляции, то есть поиск взаимосвязей между разнородными данными, как раз и решает эту проблему, снимая с администра­торских плеч нагрузку проведения ручного анализа и сопоставления разрозненных данных.

Модуль корреляции в SIMS не только автоматизирует процесс сопоставления разнородных данных, но и сам проводит анализ воздействия атаки на ваши ресурсы. Это может происходить по-разному:

• Локальная корреляция, осуществляемая непосредственно на защищаемом узле. В этом процессе участвует система обнаружения и предотвращения атак уровня узла (host-based IDPS), которая либо отражает атаку, о чем оповещает администратора безопасности, либо нет. В последнем случае требуется вмешательство специалистов, которые инициируют процесс расследования инцидентов. В данном случае, система обнаружения и предотвращения атак должна не только зафиксировать атаку, но и оценить ее воздействие на атакуемый узел.
• Корреляция со сведениями об операционной системе. Если Windows-атака направлена на Unix-узел, то ее можно игнорировать и не забивать себе голову проблемой реагирования на такие нарушения. Если же атака «применима» к данной ОС, то в действие вступает следующий вариант корреляции.
• Корреляция атак и уязвимостей. Следуя определению атаки, она не может быть успешна, если атакуемый узел или сегмент сети не содержит уязвимости. Таким образом, сопоставляя данные об атаке с информацией об уязвимостях атакуемого узла или сегмента, можно с уверенностью будет сказать, применима ли зафиксированная атака к вашей сети и, если да, то нанесет ли она вам какой-либо ущерб.

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

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

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

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

Кстати, здесь есть очень тонкий момент, на который необходимо обращать внимание при выборе системы управления информационной безопасности. Многие из них в своих рекламных материалах упоминают про поддержку огромного количества разнородных средств защиты (до нескольких десятков) и перечисляют известнейшие имена. Но на самом деле под поддержкой понимается только сбор данных от этих средств, не более того. Производитель SIMS должен обновлять свое решение также часто, как и все из поддержи­ваемых ими систем. Более того, с выходом обновления для системы обнаружения атак или сканера система корреляции также должна пополнить свою базу знаниями о новых уязвимостях и атаках. В противном случае она не сможет анализировать неизвестные ей события. Об этом умалчивают многие производители таких средств, считая, что достаточно указать в рекламных материалах факт поддержки разнообразных средств анализа защищенности, межсетевых экранов, систем обнаружения атак, proxy-серверов и т. д. Поэтому максимум, на что вы можете надеяться, устанавливая такой продукт, — это на сбор данных из разных источников без функции агрегирования и корреляции. Честнее поступают такие производители как Internet Security Systems, Cisco и т. п. Они не обещают золотых гор, но зато гарантируют полную поддержку всех своих решений и, возможно, парочки решений от других производителей.

Приоритезация

Одна и та же атака может иметь различные последствия для разных узлов корпоративной сети. Например, узел, работающий под управлением ОС Solaris 2.5.1, уязвим для атаки Ping of Death, а узел, работающий под ОС Windows NT, не подвержен данной атаке. Можно привести и другой пример — наличие модема. Если модем подключен к компьютеру с выполнением всех требований по обеспечению информационной безопасности, то это нормальная ситуация, не требующая пристального внимания администратора безопасности. Напротив, модем, подключенный в обход межсетевого экрана, должен быть немедленно удален. Или сервис Telnet. На маршрутизаторе он нужен, а на большинстве рабочих станций — нет. Именно поэтому система централизованного мониторинга атак должна предусматривать возможность задания приоритетов для обнаруживаемых атак или уязвимостей. При этом задание приоритетов может быть как статическим (что было продемонстри­ровано выше на трех примерах), так и динамическим.

Зачем нужно динамическое задание приоритетов, и почему недостаточно статического метода? Допустим, на компьютере существует учетная запись Guest, с помощью которой любой злоумышленник сможет делать на компьютере всё, что ему заблагорассудится. В обычных условиях эта уязвимость имеет высокий приоритет. Однако на практике, в зависимости от того, разрешена ли (enable) эта учетная запись или запрещена (disable), данная уязвимость может иметь самый высокий или самый низкий приоритет, соответственно. В такой ситуации приоритет может быть назначен только после корреляции событий, то есть он должен задаваться динамически (сравните колонку «Степень риска» в Таблице 3 и Таблице 6).

Огласите весь список, пожалуйста!

Число систем корреляции постоянно растет, и к ним, например, можно отнести:

• Forensics одноименной компании;
• Private I компании Open Systems;
• Security Manager компании Intellitactics;
• SPECTRUM Security Manager компании Aprisma Management Technologies;
• SystemWatch компании OpenService;
• ArcSight одноименной компании;
• neuSECURE компании GuardedNet.

Несмотря на рост интереса к этим системам на Западе, в России о таких решениях говорят пока мало и это закономерно. У нас далеко не все используют системы обнаружения атак и межсетевые экраны, не говоря уже о средствах, стоящих существенно выше на эволюционной шкале защитных механизмов. Однако, несмотря на это, в России уже можно найти системы управления информационной безопасностью таких известных в мире безопасности компаний, как Internet Security Systems, Cisco Systems и Symantec.

Первая из них предлагает бесплатную систему RealSecure SiteProtector, которая обладает описанными выше механизмами консолидации, агрегирования и корреляции событий, получаемых не только от всех своих решений в области обнаружения атак и анализа защищенности, но и от межсетевых экранов CheckPoint Firewall-1 и Cisco PIX Firewall. Также эта система поддерживает и другие средства защиты.

Компания Cisco предлагает систему CiscoWorks Security Information Management Solution, которое построено на базе широко известной на Западе системы управления информационной безопасности netForensics одноименной компании.

Компания Symantec предлагает систему Symantec Incident Manager и семейство DeepSight, вошедшее в пакет предложений Symantec после покупки последней компании SecurityFocus.

Заключение

Уровень зрелости компании в области информационной безопасности определяется не количеством установленных в сети межсетевых экранов и систем обнаружения атак, а умением управлять ими. Одним из таких средств являются системы управления информационной безопасностью, которые получают всё большее распространение в мире. По оценкам компании IDC к 2005 году объем рынка таких систем составит 1759 миллионов долларов (в том числе объем рынка систем корреляции — 405 миллионов долларов). Однако, несмотря на желание применять такие системы в своей повседневной деятельности (такое желание высказывают 89 % респондентов), только 5 % компаний задействуют всю мощь этих решений (в России число таких компаний измеряется сотыми долями процента). Остается надеяться, что в условиях растущей угрозы кибертерроризма отношение к таким системам изменится.

Статьи по данной теме

• Централизованный мониторинг атак — не всё так просто. А. Лукацкий. «ВКСС. Connect!», № 6/2002
• Централизованный мониторинг атак в корпоративной сети. А. Лукацкий. Документальная электросвязь, № 10/2002
• Обнаружение атак. А. Лукацкий. СПб.: БХВ-Петербург, 2003

А. Лукацкий — заместитель директора по маркетингу НИП «Информзащита»
23.07.2003