Идентификация в реальном времени модели ресурса и категоризация ресурса для содействия в защите компьютерной сети

Идентификация в реальном времени модели ресурса и категоризация ресурса для содействия в защите компьютерной сети

Иллюстрации

Показать все

Реферат

Предшествующий уровень техники

1. Перекрестная ссылка на родственную заявку

По настоящей заявке на патент испрашивается приоритет по дате подачи предварительной заявки США № 60/862930, поданной 25 октября 2006 г., и заявки США № 11/923513 на полезную модель, поданной 24 октября 2007 г., которые полностью включены в этот документ по ссылке.

2. Область техники, к которой относится изобретение

Это изобретение, в общем, относится к управлению событием/информацией, относящимся к безопасности, (SIM или SIEM) и, в частности, к осуществлению доступа к модели узла сети (например, узла, на который нацелено событие) так, чтобы данные модели могли быть использованы вместе с событиями/информацией, относящимися к безопасности.

3. Описание предшествующего уровня техники

Область управления событием/информацией, относящимися к безопасности, (SIM или SIEM), в общем, имеет отношение к 1) сбору данных из сетей и сетевых устройств, которые отражают сетевую активность и/или работу устройств, и к 2) анализу упомянутых данных для увеличения безопасности. Например, данные могут анализироваться для идентификации атаки на сеть или сетевое устройство и определения, какой пользователь или машина являются ответственными. Если атака продолжается, то может быть принята ответная мера, чтобы помешать атаке или уменьшить вызываемый ею ущерб. Данные, которые собираются, обычно исходят от сообщения (например, события, предупреждения или сигнала тревоги) или записи в журнале регистрации, которые формируются сетевым устройством.

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

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

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

Для того чтобы анализ безопасности осуществлялся в реальном времени (или почти в реальном времени), доступ к модели ресурса должен осуществляться в реальном времени (или почти в реальном времени). Это очень трудно осуществить, так как в минуту формируются тысячи событий, и в каждом событии указывается один или более узлов. Например, скорость события 5 000 событий/секунда и 4 узла/событие в результате приводят к 20 000 узлов/секунда. Для каждого узла идентифицируется его модель ресурса и к ней осуществляется доступ.

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

Сущность изобретения

Менеджер принимает одно или более событий и анализирует их для обнаружения атак. Событие описывает действие, затрагивающее устройство компьютерной сети, называемое "узлом сети". Событие включает в себя ссылку, называемую "ссылкой на узел", на один или более узлов (например, на узел, на который было направлено действие ("целевой узел") и/или узел, из которого исходило действие ("узел-источник")). Ссылка на узел включает в себя множество полей, например, адрес Интернет-протокола (IP), зону сети, имя хоста, адрес протокола управления доступом к среде (MAC) и идентификатор ресурса (assetID).

Поле assetID предназначено для сохранения уникального идентификатора (ID), который назначен узлу сети. Когда менеджер впервые принимает событие, поле assetID ссылки на узел является пустым. Позже, идентификатор, соответствующий "модели ресурса" узла, сохраняется в поле assetID. ID используется для получения модели ресурса, соответствующей узлу сети, связанному с ID, и определения, является ли узел сети членом конкретной категории. Менеджер осуществляет доступ к модели ресурса узла сети для выполнения анализа безопасности.

Модель ресурса является набором информации об узле сети. Эта информация может включать в себя, например, IP-адрес узла, имя хоста узла, сеть, к которой принадлежит узел, роль узла в пределах предприятия, открытый порт в узле, программные средства, установленные в узле (например, операционную систему и приложения) и список известных уязвимостей или слабых сторон узла (называемых "незащищенными уязвимостями").

Менеджер включает в себя модуль идентификатора и модуль категории. Модуль идентификатора обеспечивает выполняемые функции, относящиеся к уникальному ID, который назначен узлу сети, и включает в себя модуль поиска и модуль управления. Модуль поиска определяет ID узла сети на основе различных характеристик узла сети, например, IP-адреса, имени хоста, зоны сети и/или адреса протокола управления доступом к среде (MAC). Эти порции информации используются как ключи в одной или нескольких поисковых структурах данных (например, поисковых таблицах). Если поиск является успешным (например, найдено значение, которое связано с ключом), то это значение (которое является ID модели ресурса узла) возвращается. Модуль управления отслеживает, какие ID были назначены узлам сети, и какие ID нет.

Модуль категории обеспечивает выполняемые функции, относящиеся к категориям, и включают в себя модуль поиска и модуль управления. Модуль поиска определяет, является ли конкретный узел сети (ресурс) членом (то есть, находится в пределах) конкретной категории. Для того, чтобы определить это, модуль категории использует данные категории. Данные категории используют транзитивное замыкание (TC) для моделирования иерархического и динамического пространства категоризации (свойств), которые могут быть присоединены к модели ресурса. TC хранится в памяти как набор битовых карт, где битовая карта соответствует конкретной группе или категории ресурса. Бит 0/1 в битовой карте представляет, существует ли связь между конкретной категорией/группой ресурса и ресурсом. Уникальный ID ресурса служит индексом в битовой карте транзитивного замыкания. Модуль управления по мере необходимости обновляет данные категории.

Краткое описание чертежей

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

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

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

Фиг.4 - блок-схема, представляющая способ определения идентификатора, связанного с узлом сети, согласно одному варианту осуществления.

На фиг.5 представлены иллюстративные структуры данных для поисковой таблицы с IP-адресами.

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

На фиг.7 представлена иллюстративная структура данных для поисковой таблицы с MAC-адресами.

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

Подробное описание вариантов осуществления

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

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

Некоторые последующие части подробного описания представлены в терминах алгоритмов и символических представлений операций над данными в машинной памяти. Эти алгоритмические описания и представления являются средствами, используемыми специалистами в области вычислительной техники для наиболее эффективной передачи сущности их работы другим специалистам в данной области техники. В данной работе, и, как правило, алгоритм представляют согласующейся последовательностью этапов, приводящих к требуемому результату. Упомянутые этапы являются этапами, требующими физических манипуляций физическими величинами. Обычно, хотя не обязательно, эти величины принимают форму электрических или магнитных сигналов, которые можно сохранять, передавать, объединять, сравнивать и которыми можно манипулировать каким-либо иным образом. Иногда оказывалось удобным, преимущественно по причине общепринятого использования, называть эти сигналы битами, значениями, элементами, символами, знаками, термами, числами и т.п. Однако следует принять во внимание, что все эти и подобные термины должны быть связаны с соответствующими физическими величинами и являются просто удобными обозначениями, относящимися к этим величинам. Если специально не обусловлено иное, будет понято, что на протяжении всего описания настоящего изобретения использование таких терминов, как "обработка", "вычисление", "расчет", "определение", "вывод на экран" и т.п., относится к действию и процессам компьютерной системы или аналогичного электронного вычислительного устройства, которое манипулирует данными, представленными как физические (электронные) величины в блоках памяти и регистрах компьютерной системы, и преобразует их в другие данные, также представленные как физические величины в регистрах или блоках памяти компьютерной системы или других таких устройствах отображения, передачи или хранения информации.

Как указано выше, один вариант осуществления настоящего изобретения реализован в программном обеспечении, то есть в компьютерно-читаемых командах, которые при исполнении одним или несколькими компьютерными процессорами/системами, дают указания процессорам/системам выполнить указанные действия. Такое программное обеспечение может находиться на одном или нескольких компьютерно-читаемых носителях информации, например, жестких дисках, дисках CD-ROM, дисках DVD-ROM, постоянном запоминающем устройстве, стираемом запоминающем устройстве и так далее. Такое программное обеспечение может быть распределено в одном или нескольких этих носителях информации или может быть сделано доступным для загрузки в одной или нескольких компьютерных сетях (например, Интернет). Независимо от формата, способы компьютерного программирования, визуализации и обработки, обсуждаемые в этом документе, являются просто примерами типов программирования, визуализации и обработки, которые могут использоваться для реализации аспектов настоящего изобретения. Эти примеры никоим образом не ограничивают настоящее изобретение, которое лучше всего можно понять из формулы изобретения, которая следует за этим описанием.

Архитектура системы

Фиг.1 является схемой высокого уровня, иллюстрирующей среду, содержащую систему 10 управления событием/информацией, относящимися к безопасности, согласно одному варианту осуществления. Система 10 включает в себя агентов 12, один или более менеджеров 14 и одну или более систем управления 16 (которые могут включать в себя их версии на основе браузера). В некоторых вариантах осуществления, агенты, менеджеры и/или системы управления могут быть объединены на одной платформе или распределены на двух, трех или большем количестве платформ (таких, как в иллюстрированном примере). Использование этой многоуровневой архитектуры поддерживает масштабируемость по мере роста компьютерной сети или системы.

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

Агенты 12 конфигурируются посредством и автоматизированных и не автоматизированных процессов и через связанные файлы конфигурации. Каждый агент 12 может включать в себя один или более программных модулей, в том числе компонент стандартизации, компонент поправки времени, компонент агрегирования, компонент группирования, компонент преобразователя адресов, транспортный компонент и/или дополнительные компоненты. Эти компоненты могут быть активизированы и/или отключены посредством соответствующих команд в файле конфигурации.

Менеджеры 14 являются серверными компонентами, которые дополнительно объединяют, фильтруют и осуществляют взаимную корреляцию событий, принятых из агентов, с использованием механизма 18 правил и централизованной базы 20 данных событий. Одной ролью менеджера 14 является перехват и хранение всех данных о прошлых событиях и в реальном времени для создания (посредством менеджера 22 базы данных) полной картины на уровне предприятия активности средств безопасности. Менеджер 14 также обеспечивает централизованное администрирование, оповещение (посредством одного или нескольких устройств 24 оповещения) и представление отчета, а также базу 28 знаний и последовательность выполняемых действий по управлению случаем. Менеджер 14 может быть развернут на любой компьютерной аппаратной платформе, и один вариант осуществления использует систему управления реляционными базами данных, например, базу данных Oracle^TM для реализации компонента хранилища данных событий. Связь между менеджером 14 и агентами 12 может быть двунаправленной (например, обеспечивать возможность менеджеру 14 передавать команды в платформы, размещающие агентов 12) и зашифрованной. В некоторых инсталляциях менеджеры 14 могут действовать как концентраторы для множества агентов 12 и могут пересылать информацию другим менеджерам (например, развернутым в штаб-квартире корпорации).

Менеджер 14 включает в себя одного или более менеджеров 26 агентов, которые ответственны за прием сообщений данных события, передаваемых агентами 12. Там, где реализована двусторонняя связь с агентами 12, эти менеджеры 26 агентов могут быть использованы для передачи сообщений агентам 12. Если используется шифрование для связи агент-менеджер (которое является необязательным), менеджер 26 агентов отвечает за расшифровку сообщений, принимаемых от агентов 12, и шифровку любых сообщений, передаваемых агентам 12.

Системы управления 16 являются приложениями на основе компьютера (например, рабочей станции), которые обеспечивают возможность специалистам в области безопасности выполнять повседневные задачи административного управления и эксплуатации, например, текущий мониторинг событий, авторскую разработку правил, исследование инцидентов и представление отчетов. Списки контроля доступа обеспечивают возможность множеству специалистов в области безопасности использовать идентичные систему и базу данных событий, причем каждый имеет свои собственные вид, правила корреляции, предупреждения, отчеты и базу знаний, соответствующие их ответственности. Один менеджер 14 может поддерживать множество систем управления 16.

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

Посредством вышеописанной архитектуры система может поддерживать централизованную или децентрализованную среду. Это полезно, потому что организации может потребоваться реализация одного экземпляра системы 10 и использование списка контроля доступа для разделения пользователей. В качестве альтернативы, организация может выбрать развертывание отдельных систем 10 для каждой из нескольких групп и объединение результатов на "ведущем" уровне. Подобным развертыванием можно также осуществить размещение "вслед за солнцем", где географически рассредоточенные равноправные группы сотрудничают друг с другом посредством передачи основной ответственности за контроль группе, работающей в настоящее время в обычные часы работы. Системы 10 могут также быть развернуты в корпоративной иерархии, где отделы компании работают отдельно и поддерживают накопление в централизованной функции управления.

Система 10 управления событием/информацией, относящимся к безопасности, также описана в заявке США № 10/308415, поданной 2 декабря 2002 г., которая полностью включена в этот документ по ссылке.

Введение в модели ресурса

Менеджер 14 принимает одно или более событий и анализирует их для обнаружения атак. Событие описывает действие, затрагивающее устройство компьютерной сети, называемое "узлом сети". Иллюстративные узлы сети включают в себя портативные или настольные компьютеры, серверы (например, серверы электронной почты, серверы управления доступом и серверы доменной системы имен (DNS)), брандмауэры, маршрутизаторы, системы обнаружения несанкционированного вторжения, системы виртуальной частной сети (VPN) и принтеры.

В одном варианте осуществления, событие указывает один или более узлов (например, узел, на который было направлено действие ("целевой узел") и/или узел, из которого исходило действие ("узел источника")). В этом варианте осуществления событие включает в себя ссылку на каждый узел (называемую "ссылкой на узел"). Ссылка на узел включает в себя множество полей, например, адрес Интернет-протокола (IP), зону сети, имя хоста, адрес протокола управления доступом к среде (MAC) и идентификатор ресурса (assetID). (Зона сети является сегментом сети. Метка идентифицирует зону сети и используется, чтобы отличать частные адресные пространства друг от друга). К узлу сети обращаются с использованием IP-адреса. К некоторым устройствам, например, серверам, подключенным к множеству физических линий данных, можно обращаться посредством любого из множества IP-адресов. В этой ситуации каждый IP-адрес обрабатывается как отдельный узел сети. Соответственно, одно устройство может "содержать" множество узлов сети.

Поле assetID предназначено для сохранения уникального идентификатора (ID), который назначен узлу сети. Когда менеджер впервые принимает событие, поле assetID ссылки на узел является пустым. Позже, идентификатор, соответствующий "модели ресурса" узла, сохраняется в поле assetID. В одном варианте осуществления, ID используется для получения модели ресурса, соответствующей узлу сети, связанному с ID. В другом варианте осуществления, ID используется для определения, является ли узел сети членом конкретной категории (описано ниже). Модель ресурса является набором информации об узле сети. Эта информация может включать в себя, например, IP-адрес узла, имя хоста узла, сеть, к которой принадлежит узел, роль узла в пределах предприятия, открытый порт в узле и программные средства, установленные в узле (например, операционную систему и приложения). В одном варианте осуществления, модель ресурса включает в себя список известных уязвимостей или слабых сторон узла, называемых "незащищенными уязвимостями". Уязвимость в общем определяется как конфигурация или состояние узла, которые могут быть использованы для оказания воздействия, отличного от того, которое подразумевалось изготовителем узла.

Менеджер 14 осуществляет доступ к модели ресурса узла сети для выполнения анализа безопасности. Например, событие может описывать попытку использования одной или нескольких известных уязвимостей, называемых "используемыми уязвимостями". Менеджер 14 может определять незащищенные уязвимости целевого узла (посредством осуществления доступа к модели ресурса узла) и затем сравнивать их с используемыми уязвимостями. Угроза обнаруживается, если уязвимость появляется и как незащищенная уязвимость и как используемая уязвимость. Обнаружение угрозы также описано в патенте США № 7260844, выданном 21 августа 2007 г., который полностью включен в этот документ по ссылке.

В качестве другого примера, рассмотрим стандарт в рамках федеральных стандартов обработки информации (FIPS), который требует категоризации узла согласно его допуску для конфиденциальности. Событие может описывать действие, которое может аннулировать конфиденциальность на конкретном узле. Менеджер 14 может заметить это событие и определить, насколько важна конфиденциальность для этого узла (посредством осуществления доступа к модели ресурса узла). Если конфиденциальность важна, то может быть создан аварийный мандат для отслеживания нарушения.

Может быть определена категория узла сети (ресурса) для описания его свойств. Категория реализуется как "группа". Например, для спецификации того, что конкретный узел работает под управлением операционной системы Windows 2003 Server, ресурс узла помещается в группу "/AllCategories/OperatingSystems/Microsoft/Windows/2003Server". Категории могут быть иерархическими. Например, "2003Server" является дочерним элементом категории "Windows", которая является дочерним элементом категории "Microsoft" и т.д. Другим примером иерархических категорий являются географические классификации (например, континент/страна/штат/округ/...).

С учетом ссылки на узел и категорию, менеджер 14 может определять, является ли узел членом (то есть, находится в пределах) этой категории. Может также быть определена категория группы ресурса, как и зоны сети и группы зоны сети.

Анализ безопасности, соответственно, включает в себя идентификацию модели ресурса и осуществление к ней доступа и проверку членства в категории. Для того чтобы анализ безопасности выполнялся в реальном времени (или почти в реальном времени), идентификация модели ресурса и доступ к ней и проверки категории должны также выполняться в реальном времени (или почти в реальном времени). Это очень трудно осуществить, так как в минуту формируются тысячи событий, и в каждом событии указывается одна или более ссылок на узлы. Например, скорость события 5 000 событий/секунда и 4 ссылки на узлы/событие в результате приводят к 20 000 ссылок на узлы/секунда. Для каждой ссылки на узел, идентифицируется ее модель ресурса и осуществляется к ней доступ, и выполняется несколько проверок членства в категории.

Архитектура Менеджера

Фиг.2 является блок-схемой высокого уровня компьютера 200, действующего как менеджер 14 системы 10 управления событием/информацией, относящимся к безопасности, согласно одному варианту осуществления. Изображен, по меньшей мере, один процессор 202, подключенный к шине 204. Также к шине 204 подключены память 206, устройство 208 хранения, клавиатура 210, графический адаптер 212, указательное устройство 214 и сетевой адаптер 216. В одном варианте осуществления выполняемые функции шины 204 обеспечены соединительным набором микросхем. Дисплей 218 соединен с графическим адаптером 212.

Устройство 208 хранения является любым устройством, которое может хранить данные, например, жестким диском, постоянным запоминающим устройством на компакт-диске (CD-ROM), DVD или твердотельным запоминающим устройством. Память 206 содержит команды и данные, используемые процессором 202. Указательное устройство 214 может быть мышью, трекболом или другим типом указательного устройства и используется в комбинации с клавиатурой 210 для ввода данных в компьютер 200. Графический адаптер 212 выводит на экран дисплея 218 изображения и другую информацию. Сетевой адаптер 216 подключает компьютер 200 к локальной или глобальной сети.

Как известно в данной области техники, компьютер 200 может иметь отличные и/или другие компоненты, чем те, которые изображены на фиг.2. Кроме того, в компьютере 200 могут отсутствовать некоторые изображенные компоненты. Например, в компьютере 200, действующем как менеджер 14, могут отсутствовать клавиатура 210, указательное устройство 214, графический адаптер 212 и/или дисплей 218. Кроме того, устройство 208 хранения может быть локальным и/или удаленным от компьютера 200 (таким как реализованное в сети хранения данных (SAN)).

Программный агент 12 (например, SmartConnector от ArcSight, Inc., Cupertino, CA (Калифорния)) принимает, от датчика, сообщение относительно узла сети. После этого агент 12 обрабатывает сообщение для создания события. В одном варианте осуществления, событие представляет структуру данных, которая включает в себя одно или более полей, где каждое поле может содержать значение. Значение поля определяется на основе сообщения, принятого от датчика. Агент отправляет событие в менеджер 14 (например, Enterprise Security Manager от ArcSight, Inc.) для хранения и анализа.

Менеджер 14 включает в себя модуль, называемый распознавателем ресурса события (EAR) (не изображен). Напомним, что событие может включать в себя ссылку на узел. Модуль EAR связывает эту ссылку на узел с ее соответствующей моделью ресурса и помечает ссылку на узел уникальным идентификатором (ID). Например, модуль EAR модифицирует событие посредством сохранения ID в поле assetID ссылки на узел, которое ранее было пустым. В одном варианте осуществления, событие включает в себя ссылки на четыре узла: источник сетевого трафика, адрес назначения сетевого трафика, хост агента и хост датчика, который сообщил о событии. Для каждой ссылки на узел, модуль EAR связывает ссылку на узел с ее соответствующей моделью ресурса и помечает ссылку на узел уникальным ID.

Фиг.3 является блок-схемой высокого уровня, иллюстрирующей модули, находящиеся в менеджере 14 системы 10 управления событием/информацией, относящимся к безопасности, согласно одному варианту осуществления. Как изображено на фиг.3, вариант осуществления менеджера 14 включает в себя модуль 300 идентификатора и модуль 310 категории. В других вариантах осуществления могут быть другие и/или дополнительные модули, по сравнению с теми, которые изображены на чертеже. Например, менеджер 14 может содержать модули, изображенные на фиг.1, хотя для ясности эти модули не включены в фиг.3. Кроме того, функции могут быть распределены среди модулей способом, отличным от способа, описанного в данной работе.

Модуль 300 идентификатора обеспечивает выполняемые функции, относящиеся к уникальному идентификатору (ID), который назначен узлу сети. В одном варианте осуществления, ID является целым числом (например, значением, выраженным в простом типе данных "int"). В одном варианте осуществления, ID является "локально" уникальным. Например, он уникален в пределах конкретного менеджера 14, но не обязательно уникален во всем множестве менеджеров. В другом варианте осуществления, ID является универсальным уникальным идентификатором (UUID) или глобально уникальным идентификатором (GUID). В этом варианте осуществления, ID является "глобально" уникальным. Например, он уникален во всем множестве менеджеров. Объем памяти, требуемый для хранения UUID или GUID, составляет, по меньшей мере, 16 байтов. Для хранения целочисленного значения требуется меньше памяти. Так как может потребоваться хранить в памяти более одного миллиона ID одновременно, то это различие в памяти является существенным.

В одном варианте осуществления, ID используется для получения модели ресурса, соответствующей узлу сети, связанному с ID. Например, модуль управления ресурсом (не изображен) поддерживает информацию модели ресурса и при запросе возвращает модель ресурса с использованием ID. Модель ресурса представляется, например, структурой данных объекта (например, в языке объектно-ориентированного программирования, таком как Java). В другом варианте осуществления, ID используется для определения, является ли узел сети членом конкретной категории.

В иллюстративном варианте осуществления, модуль 300 идентификатора включает в себя модуль 320 поиска, модуль 330 управления, таблицу 340 интервала и одну или более поисковых таблиц 350. Модуль 320 поиска определяет ID узла сети на основе различных характеристик узла сети. Эти характеристики присутствуют в ссылке на узел в событии, как описано выше. ID конкретного узла сети определяется на основе IP-адреса узла, имени хоста, зоны сети и/или адреса протокола управления доступом к среде (MAC). В одном варианте осуществления, эти порции информации используются как ключи в одной или нескольких структурах данных поиска (поисковых таблицах 350, описанных ниже). Если поиск является успешным (например, найдено значение, которое связано с ключом), то это значение (которое является ID модели ресурса узла) возвращается.

Фиг.4 является блок-схемой, представляющей способ определения идентификатора, связанного с узлом сети, согласно одному варианту осуществления. До начала способа 400 принимается информация об узле сети. Эта информация включает в себя одно или большее количество из следующего: IP-адреса узла, зоны сети, имени хоста и MAC-адреса.

Предпринимается 410 поиск с использованием MAC-адреса узла. Если в результате этого успешно найдено соответствие, то возвращается 420 ID. Если в результате MAC-поиска соответствие успешно не найдено, то предпринимается 430 поиск с использованием зоны сети и IP-адреса узла. Если в результате этого успешно найдено соответствие, то возвращается 420 ID. Если в результате IP-поиска соответствие успешно не найдено, то предпринимается 440 поиск с использованием зоны сети и имени хоста узла. Если в результате этого успешно найдено соответствие, то возвращается 420 ID. Если в результате поиска по имени хоста соответствие успешно не найдено, то предпринимается 450 поиск с использованием диапазона для ресурса, который охватывает IP-адрес узла в пределах зоны сети узла. Если в результате этого успешно найдено соответствие, то возвращается 420 ID. В одном варианте осуществления, порядок, в котором предпринимается каждый поиск (MAC-поиск, IP-поиск, поиск по имени хоста и поиск по диапазону для ресурса), является конфигурируемым.

Поисковые таблицы 350 используются модулем 320 поиска для определения ID узла сети на основе различных характеристик узла сети. В одном варианте осуществления существует четыре типа поисковых таблиц 350: поисковые таблицы IP-адрес/зона сети, поисковые таблицы имя хоста/зона сети, поисковые таблицы с MAC-адресами и поисковые таблицы с диапазонами для ресурсов. Каждая из этих поисковых таблиц заполняется модулем управления ресурсом (описанным выше).

Поиск по IP-адресу/зоне сети

В одном варианте осуществления, поисковая таблица с IP-адресами использует ключи и значения простого типа данных "int" (integer (целое число)). Ключ, который используется для выполнения поиска, является 32-разрядным целым числом, которое представляет IP-адрес. Значение, которое возвращается поиском, является целочисленным ID соответствующей модели ресурса. Так как IP-адреса уникальны только в пределах зоны сети, то в каждой зоне сети существует своя собственная поисковая IP-таблица.

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

На фиг.5 представлены иллюстративные структуры данных для поисковой таблицы с IP-адресами. Иллюстративные структуры данных включают в себя хэш-карту 500 с открытой адресацией и массив 510 с прямым доступом. В общепринятых реализациях хэш-карт с открытой адресацией используются три массива: один для хранения ключей, один для хранения значений и один для указания, допустимы ли пары ключ-значение. Здесь ключи (IP-адреса) и значения (ID) хранятся вместе в одном целочисленном массиве 500. В иллюстративном варианте осуществления, ключ и связанное с ним значение размещены вблизи друг от друга (например, рядом друг с другом) в массиве для лучшей локализации кэша. Другими словами, хэш-карта с открытой адресацией реализована с использованием одного массива посредством чередования значений массива ключей и массива значений. Реализация хэш-карты с открытой адресацией с использованием одного массива известна специалистам в данной области техники и описана в Data Structures/Hash Tables (Структуры данных/хеш-таблицы) Wikibook (Викикнига) по адресу http://en.wikibooks.org/wiki/Data_Structures/Hash_Tables.

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

В качестве альтернативы, может использоваться массив 510 с прямым доступом, где каждое значение (здесь ID) сохраняется как один элемент массива. Индекс этого элемента в массиве определяется на основе ключа (здесь IP-адреса). В одном варианте осуществления, индекс равен смещению IP-адреса в пределах конкретного диапазона адресов. Например, рассмотрим зону сети, которая включает в себя IP-адреса, которые изменяются в пределах от 192.168.0.100 до 192.168.0.200. У IP-адреса 192.168.0.150 индекс был бы равным 50, так как его смещение от нижней границы диапазона равно 50. Соответственно, его ID был бы сохранен в array[50], где array является именем массива, и 50 является индексом в массиве. Следовательно, нет необходимости сохранять ключ. Вместо этого он преобразован в индекс, который далее используется для доступа к конкретному элементу массива.

Рассмотрим другую зону сети и диапазон ее IP-адресов (например, 192.168.0.0 по 192.168.0.255). Если IP-адреса