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

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

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

Лукацкий А.В., НИП “Информзащита”, размещено в журнальчике BYTE #10/2003

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

Сканирование периметра сети
Подбор пароля на узлах, видимых из Веб
Атаки червяков Slammer и т.п.
Внедрение уязвимостей Web-сервера и т.п.

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

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

Многие спецы считают, что неверное обнаружение лучше, чем отсутствие сообщения об атаке. Но это как раз та ситуация, когда количество перебегает в качество. С течением времени это становится головной болью хоть какого админа, которому приходится решать, реагировать на показавшееся на консоли сообщение либо проигнорировать его. В итоге админ просто перестает реагировать не только лишь на неверные, да и на любые другие сообщения, в т.ч. и влекущие за собой томные последствия. К примеру, в Таблице 1 показан кусок журнальчика регистрации обширно известной в Рф системы обнаружения атак RealSecure Network 10/100, которая зафиксировала распространение червяка Slammer, нашумевшего сначала этого года. Таких записей за период в один денек в журнальчике может быть несколько 10-ов тыщ, ведь, как можно созидать, скорость распространения 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), которая позволяет все применяемые защитные средства соединить в единый управляемый комплекс. Такая система:

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

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

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

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

Консолидация (event consolidation).
Агрегирование (event aggregation).
Корреляция (event correlation).
Приоритезация (event prioritization).

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

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

Таблица 2. Консолидация событий на примере системы RealSecure SiteProtector с установленным модулем Third Party Module

Степень риска Событие Имя детектора Тип детектора Низкая fw-cisco~ids-packet-not-I>PSEC-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, антивирусные системы и т.д. фиксируют различные характеристики, связанные с несанкционированными действиями.

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

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

После консолидации событий начинается процесс их агрегирования, т.е. группирования однотипных событий совместно, что позволяет получить на дисплее заместо 10000 циклических строк “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 многие админы приходят в кошмар и лихорадочно начинают вспоминать, а пропатчили ли они свои узлы. А что если, даже самая суровая атака (к примеру, Slammer) не нанесет вам никакого вреда по той обычный причине, что у вас нет серверов на базе MS SQL? А если они у вас есть, но вы их издавна защитили? Подобная ситуация происходит и с другими атаками, которые отвлекают внимание админа и требуют вмешательства. А что, если на их вообщем не нужно реагировать (как ни феноминально это звучит)? Ведь не каждый взломщик знает всю подноготную вашей сети, и, часто, он наобум пробует штурмовать ваши ресурсы, что приводит к тому, что атака не только лишь не нанесет вам никакого вреда, да и в принципе не может быть применима к вашей сети. К примеру, относительно не так давно выпущенный SMBdie страшен только Windows-узлам, ну и то, только тем, на которых не был установлен соответственный Service Pack. Unix-машины к нему неуязвимы. Так для чего же реагировать на возникновение сообщения об атаке SMBdie? Отлично, если ваша сеть маленького размера и вы помните, что и где у вас установлено. А если нет? Куда лучше, если сообщения, не несущие никакой опасности, вообщем бы не показывались у вас на консоли и не отвлекали бы вас от более принципиальных дел. Механизм корреляции, т.е. поиск взаимосвязей меж разнородными данными, как раз и решает эту делему, снимая с администраторских плеч нагрузку проведения ручного анализа и сравнения разрозненных данных.

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

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

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

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

Таблица 4. Итог работы механизма корреляции на примере системы RealSecure SiteProtector с установленным модулем SecurityFusion Module

Степень риска Событие Число событий Статус Низкая NMap-Scan 139 Воздействие непонятно (корреляция не проводилась) Средняя SMTP-Sendmail-Relay 1 Возможно плохая атака (узел неуязвим) Высочайшая Backdoor-BO2k 1 Плохая атака (узел перекрыл атаку)

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

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

Таблица 5. Итог работы механизма корреляции на примере системы RealSecure SiteProtector с установленным модулем SecurityFusion Module

Степень риска Событие Число событий Источник Высочайшая Attack_From__Compromised_>Host 1567 139.92.229.160 Высочайшая Targeted_Break_In_Attempt 1 194.98.93.252 : : : :

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

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

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

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

Таблица 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 : : : :

Озвучте весь перечень, пжалуйста!

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

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.

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

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

Заключение

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

Об создателе

Алексей Викторович Лукацкий, управляющий отдела Internet-решений Научно-инженерного предприятия “Информзащита” (Москва). Создатель книжек “Обнаружение атак”, “Атака из Internet” и “Protect Your Information with Intrusion Detection”. Связаться с ним можно по тел. (095) 937-3385 либо e-mail: luka@infosec.ru.

Tags: атак, атака, обнаружения, системы, событий