Отслеживание данных изменения состояния для того, чтобы содействовать безопасности вычислительной сети

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

 

Уровень техники

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

Данная заявка притязает на приоритет предварительной заявки (США) номер 60/862932, поданной 25 октября 2006 года, и заявки на патент на изобретение (США) 11/923502, поданной 24 октября 2007 года, которые настоящим полностью содержатся в данном документе.

Область техники

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

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

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

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

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

К сожалению, непросто определить состояние сети в любой момент времени. Это происходит из-за того, что состояние не является постоянным - оно изменяется со временем. В частности, состояние каждого устройства изменяется со временем. Например, IP-адрес, назначаемый устройству, может измениться со временем из-за различных периодов аренды адреса протоколов динамического конфигурирования хоста (DHCP), использования различных виртуальных частных сетей (VPN) или трансляции сетевых адресов (NAT). В качестве еще одного примера, пользователи, вошедшие в систему на устройстве, могут изменяться со временем, поскольку различные люди входят в систему и выходят из системы. Таким образом, полезно знать не только текущее состояние сети, но также и предшествующее состояние(я) сети. Поскольку атрибуты конкретного устройства могут измениться, знание корректных атрибутов в любой данный момент времени полезно для того, чтобы коррелировать события, включающие одну и ту же машину или пользователя.

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

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

Обратите внимание, что изменение IP-адресов также может приводить к ложным оповещениям. В соответствии с примером выше, рассмотрим четыре завершившихся ошибкой входа в систему из одного исходного устройства и шесть завершившихся ошибкой входов в систему из другого исходного устройства, каждый из которых происходит в пределах пятиминутного отрезка времени и направлен на одну и ту же машину. Хотя исходные устройства являются различными, и они никогда не имели один и тот же IP-адрес одновременно, каждое устройство имело один и тот же IP-адрес в то время, когда устройство вызвало завершившийся ошибкой вход в систему. Поскольку этот один и тот же IP-адрес присутствовал во всех десяти сообщениях завершившихся ошибкой входов в систему, это событие должно быть помечено для анализа. Это называется ложным утверждением.

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

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

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

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

Для каждого типа сеанса поддерживается сеансовая таблица. Сеансовая таблица включает в себя одну или более записей, где каждая запись представляет сеанс. Информация о записи сеанса хранится в различных полях. Вместе эти поля содержат схему для информации о сеансе. Каждая схема включает в себя три типа полей: поля ключей, поля значений и поля временных меток. Информация о сеансе описывается как ключи и значения, чтобы поддержать операции запроса/поиска.

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

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

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

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

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

Чертеж иллюстрирует примерные схемы для различных типов информации о сеансе.

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

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

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

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

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

Введение в сеансы

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

Рассмотрим устройство, которое приняло IP-адрес через аренду адреса протокола динамического конфигурирования хоста (DHCP). Один или более фрагментов данных могут включать в себя a) IP-адрес (и, если IP-адрес не глобально уникален, сетевую зону, которая содержит IP-адрес) и b) индикатор устройства, которому назначен IP-адрес (к примеру, имя хоста устройства и/или адрес управления доступом к среде (MAC)). (Сетевая зона - это сегмент сети. Метка идентифицирует сетевую зону и используется для того, чтобы отличать закрытые адресные пространства друг от друга). Аналогично, рассмотрим устройство, которое приняло IP-адрес через регистрацию в виртуальной частной сети (VPN). В дополнение к (a) и (b) выше, один или более фрагментов данных может включать в себя имя пользователя, которое использовалось, чтобы инициализировать вход в систему по VPN. В качестве еще одного примера рассмотрим устройство, которое охарактеризовано IP-адресом через трансляцию сетевых адресов (NAT). Здесь, один или более фрагментов данных могут включать в себя a) IP-адрес (и, если IP-адрес не глобально уникален, сетевую зону, которая содержит IP-адрес) и b) индикатор устройства, которому назначен IP-адрес через трансляцию (к примеру, имя хоста устройства и/или фактический IP-адрес и исходный порт).

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

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

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

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

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

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

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

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

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

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

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

Инфраструктура для хранения данных сеанса

Для каждого типа сеанса поддерживается сеансовая таблица. Например, одна сеансовая таблица сохраняет информацию о сеансе, связанную с устройствами и IP-адресами, тогда как другая сеансовая таблица содержит информацию о сеансе, связанную с людьми и активами. Сеансовая таблица включает в себя одну или более записей, где каждая запись представляет сеанс. Например, сеанс устройства/IP-адреса должен описывать период времени, на который конкретному устройству назначен конкретный IP-адрес. Эта запись должна быть сохранена в сеансовой таблице устройства/IP-адреса. В одном варианте осуществления сеансовая таблица аналогична списку сеансов, который является признаком ArcSight™ Enterprise Security Manager (ESM) 4.0 (предлагаемый компанией ArcSight, Inc Cupertino, Калифорния).

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

Информация о записи сеанса хранится в различных полях. Вместе эти поля составляют схему для информации о сеансе. Различные типы информации о сеансе могут иметь различные схемы. Чертеж иллюстрирует примерные схемы для различных типов информации о сеансе. Проиллюстрированные схемы - это DHCP, VPN, NAT, вход в систему и монопольное использование актива. На чертеже каждый прямоугольник представляет поле.

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

Поля временной метки, которые включают в себя поле Start Time, поле End Time и поле Creation Time, содержат временную метку, как описано выше (если только сеанс не закончился, в этом случае End Time должно быть пустым). Значение поля Start Time и значение поля End Time используются для того, чтобы идентифицировать допустимый сеанс для данного ключа в любой данный момент времени. Например, с учетом ключа и конкретной временной метки, если этот ключ соответствует нескольким наборам полей значений, соответствующий набор полей значений является набором, для которого Start Time и End Time окружают временную метку.

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

Таким образом, сеансовая таблица выступает в качестве сопоставления ключей и значений, которое сопоставляет или привязывает ключи к значениям. Например, запрос сеанса должен содержать один или более ключей ("ключей запроса"), а результат запроса должен содержать одно или более значений, которые привязаны к одному или более ключей. Поскольку сеанс можно рассматривать как ассоциативную связь между двумя объектами, один объект представляется посредством ключа, а другой объект представляется посредством значения.

Информация, содержащаяся в некоторых полях, может быть идентичной среди различных сеансов (и, следовательно, среди различных записей). Например, если устройству назначен первый IP-адрес в один день и второй IP-адрес в другой день, то каждая запись сеанса должна содержать идентичную информацию относительно устройства (к примеру, MAC-адрес или имя хоста устройства). Аналогично, если IP-адрес назначен первому устройству в один день и второму устройству в другой день, то каждая запись сеанса должна содержать идентичную информацию относительно IP-адреса. Если две записи содержат идентичную информацию в полях, и эта информация в полях определяет ключ, то этот один ключ должен соответствовать двум различным наборам информации (один набор для каждого сеанса). Эта функциональность может быть реализована, например, посредством помещения наборов информации о сеансе в список и задания значения ключа в качестве этого списка. Значение поля Start Time и значение поля End Time используются для того, чтобы идентифицировать то, какой набор информации о сеансе является допустимым в данный момент времени, как описано выше. В одном варианте осуществления наборы информации о сеансе сортируются в пределах списка согласно начальному времени каждого сеанса. Это уменьшает время, необходимое для того, чтобы выполнить поиск.

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

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

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

Память, требуемая для того, чтобы хранить сеансовую таблицу, пропорциональна числу записей в таблице. Другими словами, требуемый объем и конфигурация памяти возрастает в O(n), где n - это число записей, загруженных в памяти для сеансовой таблицы. Что касается времени поиска, если m - это число уникальных ключей (на основе кортежа поля ключей) в сеансовой таблице, а p - это среднее число записей на уникальный ключ, то время, требуемое для того, чтобы выполнить поиск, равно O(log p). Здесь, m*p=O(n).

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

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

Зависимые переменные могут быть объединены в цепочку, чтобы осуществлять доступ к информации о сеансе из различных источников. Пользователь может указать не только несколько источников данных, в которых следует искать информацию, но также и порядок, в котором должны использоваться эти источники данных. Например, пользователь может указать, что, если информация DHCP и информация VPN доступны, MAC-адрес может быть извлечен от любой из них и затем комбинирован с информацией неодинаковых источников, чтобы использоваться в корреляции.

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

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

Сеансовая таблица может быть заполнена данными различными способами. Один способ состоит в том, чтобы импортировать данные из файла, такого как архив. Файл, который может находиться на любом сетевом устройстве, может содержать любой тип информации в любом формате (к примеру, в формате разделенных запятыми значений (CSV)). Например, файл, возможно, выведен посредством хранилища данных, которое содержит информацию, которая должна быть коррелирована с информацией/событиями безопасности. Рассмотрим базу данных, которая содержит информацию по персоналу (HR), такую как служащие и их бизнес-роли в организации. Экспорт этих HR-данных из базы данных в файл и последующий импорт файла в сеансовую таблицу делает данные доступными в реальном времени для корреляции и т.д. Эти данные могут быть использованы, например, для того, чтобы активировать политику доступа к сети на основе бизнес-роли пользователя, а не на основе устройства или IP-адреса.

Другой способ заполнить сеансовую таблицу состоит в том, чтобы использовать службы каталогов для того, чтобы извлекать данные из хранилищ данных. К этим службам каталогов можно осуществлять доступ через различные протоколы, такие как упрощенный протокол доступа к каталогам (LDAP) или X.500.

Еще один способ состоит в том, чтобы использовать один или более программных агентов (например, SmartConnectors от ArcSight, Inc), чтобы отправлять требуемые данные в форме событий. Затем одно или более правил могут быть использованы для того, чтобы обработать события. В частности, правила могут извлекать данные сеанса из событий и использовать эти данные для того, чтобы заполнить сеансовые таблицы.

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

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

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

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

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

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

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

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

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

Пример неявного завершения сеанса

Согласно записи в сеансовой таблице, IP-адрес в данной сетевой зоне (ключ) назначается конкретному имени хоста и MAC-адресу (192.168.0.1, внутренняя зона 1) => (hostname1, 11:11:11:11:11:11) 12 октября 2007 года в 22:00. 12 октября 2007 года в 23:00 наступает событие начала сеанса, который сопоставляет тот же IP-адрес в той же зоне (ключ) с другим устройством (192.168.0.1, внутренняя зона 1) => (hostname2, 22:22:22:22:22:22). Событие начала сеанса приводит к тому, что первый сеанс заканчивается (с конечным временем от 12 октября 2007 года в 23:00), а второй сеанс создается и запускается (с начальным временем от 12 октября 2007 года в 23:00).

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

Пример неявного разделения сеанса (первая форма) - Согласно записи в сеансовой таблице, сеанс закончился 12 октября 2007 года в 23:00. Событие завершения сеанса наступает, что соответствует этой записи сеанса и указывает время завершения 12 октября 2007 года в 22:30. Конечное время в записи сеанса изменяется с 12 октября 2007 года в 23:00 на 12 октября 2007 в 22:30.

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

Пример неявного разделения сеанса (вторая форма) - Согласно сеансовой таблице, сеанс S1 начинается 1 января 2008 года в 13:00 и завершается 1 января 2008 года в 22:00, а сеанс S2 начинается 1 января 2008 года в 23:00 и является активным. Событие наступает, что указывает существование сеанса S3, начинающегося 1 января 2008 года в 18:00. Сеанс S1 разделяется так, чтобы он начался 1 января 2008 года в 13:00 и закончился 1 января 2008 года в 18:00. Сеанс S3 создается так, чтобы он начался 1 января 2008 года в 18:00 и закончился 1 января 2008 года в 23:00. Сеанс S2 остается как активный сеанс, который начинается 1 января 2008 года в 23:00.

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

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

Подробности реализации

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

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

В одном варианте осуществления сеансовая таблица секционируется на основе начального времени сеанса. Напомним, что каждая запись в сеансовой таблице включает в себя временную метку начального времени. Значение этой временной метки определяет то, в каком разделе сохраняется запись. В одном варианте осуществления каждый раздел представляет 24-часовой период. Например, первый раздел представляет с 1 января 2007 года в 0:00 по 1 января 2007 года в 23:59, а второй раздел представляет со 2 января 2007 года в 0:00 по 2 января 2007 года в 23:59. В этом варианте осуществления период данных сеанса за один год должен быть сохранен в 365 разделах, а не в одной огромной сеансовой таблице.

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

В режиме реального времени, когда информация/события безопасности принимаются, они коррелируются с информацией о сеансе в реальном времени или практически в реальном времени. Чтобы эта корреляция осуществлялась в реальном времени, данные сеанса должны храниться в реальном времени и должны также поддерживать выполнения запросов в реальном времени. Этого очень трудно добиться, поскольку в минуту тысячи событий формируются, и каждое событие может включать в себя одну или более ссылок на информацию о сеансе (к примеру, один или более IP-адресов, которые должны быть использованы для того, чтобы определять MAC-адреса, которым эти IP-адреса назначены, или одно или более имен хоста, которые должны быть использованы для того, чтобы определять пользователей, которые входят в систему на этом хосте). Например, частоты событий в 5000 событий/секунда и 2 ссылки на сеанс/событие имеет результатом 10000 ссылок на сеанс/секунда.

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

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

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

После свертки сеанса предыдущие разделы должны содержать только законченные сеансы (т.е. сеансы, записи которых содержат временные метки конечного времени). Поскольку предыдущие разделы не содержат оперативные данные сеанса, проще удалять или архивировать эти разделы.

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

Например, рассмотрим первый раздел, который представляет с 1 января 2007 года в 0:00 по 1 января 2007 года в 23:59, и второй раздел, который представляет со 2 января 2007 года в 0:00 по 2 января 2007 года в 23:59. Сеанс начинается 1 января 2007 в 23:00 и заканчивается 2 января 2007 в 1:00. Свертка сеанса разделяет сеанс на два сеанса: a) с 1 января 2007 года в 23:00 по 1 января 2007 года в 23:59 и b) со 2 января 2007 года в 0:00 до 2 января 2007 года в 1:00. Сеанс (a) сохраняется в первом разделе как законченный сеанс, и сеанс (b) сохраняется во втором разделе (также как законченный сеанс). Если сеанс относится к информации DHCP, то данный IP-адрес и сетевая зона совпадают с одним именем хоста и MAC-адресом для всех событий, которые имеют временные метки между 1 января 2007 года в 23:00 и 2 января 2007 года в 1:00, независимо от разделения сеанса.

В качестве еще одного примера, рассмотрим сеанс, который начинается 1 октября 2007 года в 14:00 и является выполняющимся в данный момент 5 октября 2007 года. Выполнение свертки сеанса 5 октября 2007 года разделяет сеанс на пять сеансов (один для 1 октября, один для 2 октября, один для 3 октября, один для 4 октября и один для 5 октября). Первые четыре сеанса сохраняются в соответствующих разделах как законченные, и пятый сеанс (5 октября) сохраняется в активном разделе как выполняющийся в данный момент.

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

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

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

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

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

2. Способ по п.1, в котором запись сеанса включает в себя информацию, извлеченную из сообщения или записи журнала регистрации, связанного с событием безопасности.

3. Способ по п.1, в котором одно или более полей ключей содержат адрес Интернет-протокола (IP).

4. Способ по п.1, в котором одно или более полей значений содержат одно из имени хоста и адреса управления доступом к среде (MAC).

5. Способ по п.1, в котором сетевое устройство содержит одно из брандмауэра, системы обнаружения проникновения и сервера.

6. Способ по п.1, в котором ключ запроса содержит хэш-код.

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

8. Способ по п.7, в котором конечное время неявно определяется на основе события начала сеанса.

9. Способ по п.7, в котором начальное время неявно определяется на основе события завершения сеанса.

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

11. Способ по п.1, в котором выполнение запроса к сеансовой таблице с помощью временной метки и ключа запроса содержит этап, на котором тестируют ключ запроса в сравнении с фильтром, ассоциативно связанным с сеансовой таблицей.

12. Способ по п.1, в котором выполнение запроса к сеансовой таблице с помощью временной метки и ключа запроса содержит этап, на котором ожидают минимальный интервал времени.

13. Способ по п.1, в котором выполнение запроса к сеансовой таблице с помощью временной метки и ключа запроса содержит этап, на котором ожидают максимальный интервал времени.

14. Способ по п.1, в котором запись сеанса содержит поле временной метки, указывающее время создания записи сеанса.

15. Способ по п.1, в котором сеансовая таблица разделяется.

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

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

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

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

20. Способ по п.1, в котором сеансовая таблица разделяется посредством начального времени сеанса, и в котором выполнение запроса к сеансовой таблице с помощью временной метки и ключа запроса содержит этапы, на которых:
- определяют раздел сеансовой таблицы на основе временной метки; и
- выполняют запрос к определенному разделу с помощью временной метки и ключа запроса.

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

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