ЭФФЕКТИВНОЕ ХРАНЕНИЕ ДАННЫХ РЕГИСТРАЦИИ С ПОДДЕРЖКОЙ ЗАПРОСА, СПОСОБСТВУЮЩЕЕ БЕЗОПАСНОСТИ КОМПЬЮТЕРНЫХ СЕТЕЙ Российский патент 2011 года по МПК G06F21/20 

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

Данная заявка испрашивает приоритет предварительной заявки США № 60/882289, поданной 28 декабря 2006 г., которая настоящим включена посредством ссылки в данный документ во всей своей полноте.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Раскрытие изобретения

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

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

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

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

1. Архитектура системы управления информацией/событиями безопасности (SIEM)

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

Типы источников 110 данных включают в себя системы обнаружения безопасности и прокси-системы, органы управления доступом и политикой, журналы регистрации базовых служб и консолидаторы журналов регистрации, сетевые аппаратные средства, устройства шифрования и физическую защиту. Примерные системы обнаружения безопасности и прокси-системы включают в себя IDS, IPS, многоцелевые приборы обеспечения безопасности, оценку и управление уязвимостью, антивирус, ловушки, технологию реагирования на угрозы и мониторинг сети. Примерные системы управления доступом и политикой включают в себя управление доступом и идентификацией, виртуальные частные сети (VPN), механизмы кэширования, брандмауэры и управление политикой безопасности. Примерные журналы базовых служб и консолидаторов журналов регистрации включают в себя журналы операционной системы, журналы ревизии базы данных, журналы приложений, консолидаторы журналов регистрации, журналы веб-сервера и консоли управления. Примерные сетевые аппаратные средства включают в себя маршрутизаторы и коммутаторы. Примерные устройства шифрования включают в себя безопасность и целостность данных. Примерные системы физической защиты включают в себя устройства считывания карточек-ключей, биометрические характеристики, сигнализацию о взломе и пожарную сигнализацию.

В изображенном варианте осуществления система 100 SIEM включает в себя один или несколько агентов 120, один или несколько менеджеров 130, одну или несколько баз 140 данных, один или несколько онлайновых архивов 150, один или несколько пользовательских интерфейсов 160 и одну или несколько систем 170 регистрации. В некоторых вариантах осуществления эти модули объединяются в одну платформу или распределяются по двум, трем или более платформам (таким как на фиг.1). Использование данной многоуровневой архитектуры поддерживает масштабируемость по мере роста компьютерной сети или системы. Система 100 SIEM дополнительно описана в заявке США № 10/308415, поданной 2 декабря 2002 г., которая настоящим включена по ссылке в данном документе во всей своей полноте.

Агент 120 обеспечивает интерфейс для источника 110 данных. Конкретно, агент 120 собирает данные («необработанные события») от источника 110 данных, обрабатывает данные и посылает обработанные данные («события») менеджеру 130. Агент 120 может работать в любом месте, например, на отдельном устройстве, устанавливающем связь по протоколу, такому как ловушки простого протокола управления сетью (SNMP), в консолидационной точке в сети, или на источнике 110 данных. Например, если источник 110 данных представляет собой приложение программного обеспечения, агент 120 может совместно хостироваться на устройстве, которое хостирует источник данных. В одном варианте осуществления агент 120 представляет собой продукт Connector компании ArcSight, Inc. из Купертино, Калифорния.

Обработка может включать в себя нормализацию, агрегирование и фильтрацию. Например, выполняется синтаксический анализ и нормализация индивидуальных необработанных событий посредством использования менеджера 130. Нормализация может включать в себя нормализацию значений (таких как важность, приоритет и часовой пояс) в общий формат и/или нормализацию структуры данных в общую схему. События могут категорироваться, используя общий, читаемый человеком формат. Этот формат позволяет пользователям лучше понимать события и позволяет им легче анализировать события, используя фильтры, правила, отчеты и мониторы данных. В одном варианте осуществления общим форматом является стандарт управления журналом регистрации общего формата событий (CEF) компании ArcSight, Inc. Нормализация дополнительно описывается в заявке США № 10/308941, поданной 2 декабря 2002 г., которая настоящим включена по ссылке в данном документе во всей своей полноте.

Агрегирование и фильтрация уменьшает объем событий, посылаемых менеджеру 130, который экономит пропускную способность сети и пространство хранения, повышает эффективность и точность менеджера и снижает время обработки событий. Агрегирование дополнительно описано в заявке США № 10/308584, поданной 2 декабря 2002 г., которая настоящим включена по ссылке в данном документе во всей своей полноте. Агент 120 посылает события менеджеру 130 группами, основываясь на истечении периода времени или основываясь на достигаемом пороговом количестве событий. Группирование событий для передачи менеджеру 130 дополнительно описано в патенте США № 7219239, выданном 15 мая 2007 г., который настоящим включен по ссылке в данном документе во всей своей полноте.

Агент 120 также может посылать команды на источник 110 данных и/или исполнять команды на локальном хосте, такие как инструктировать сканер на выполнение сканирования. Эти действия могут исполняться вручную или при помощи автоматизированных действий из правил и мониторов данных. Поддержка команд дополнительно описана в заявке США № 10/308417, поданной 2 декабря 2002 г., которая настоящим включена по ссылке в данном документе во всей своей полноте. Агент 120 также может добавлять информацию к данным, которые он собрал, например, посредством поиска адреса протокола Интернета (IP) и/или имя хоста, чтобы преобразовать поиск IP/имени хоста в менеджере 130.

Агент 120 конфигурируется при помощи связанного файла конфигурации (не показан). Агент 120 может включать в себя один или несколько программных модулей, включающих в себя компонент нормализации, компонент коррекции времени, компонент агрегирования, компонент группирования, компонент преобразователя, компонент транспортировки и/или дополнительные компоненты. Эти компоненты могут активизироваться и/или деактивизироваться посредством соответствующих команд в файле конфигурации. Во время конфигурирования агент 120 регистрируется на менеджере 130 и конфигурируется с характеристиками, основанными на его источнике 110 данных и требуемом режиме работы. Агент 120 является дополнительно конфигурируемым посредством как ручного, так и автоматизированного процессов. Например, менеджер 130 может посылать агенту 120 команду или обновление конфигурации. Компоненты агента дополнительно описываются в заявке США № 10/308548, поданной 2 декабря 2002 г., которая настоящим включена по ссылке в данном документе во всей своей полноте.

Менеджер 130 обеспечивает возможности анализа, возможности рабочего процесса управления делами и возможности служб. Связь между менеджером 130 и агентом 120 может быть двунаправленной (например, давая возможность менеджеру 130 передавать команду платформе, хостирующей агента 120) и шифрованной. В некоторых установках менеджер 130 может служить в качестве концентратора для многочисленных агентов 120 и может направлять информацию другим менеджерам 130 (например, менеджерам, развернутым в штаб-квартирах корпорации). Чтобы выполнять свои задачи, менеджер 130 использует многочисленные фильтры, правила, отчеты, мониторы данных, инструментальные панели и сетевые модели. В одном варианте осуществления менеджер 130 представляет собой основанный на Java сервер, такой как продукт Менеджер корпоративной безопасности (ESM) компании ArcSight, Inc.

Анализ может включать в себя обнаружение, корреляцию и эскалацию. Например, менеджер 130 взаимно коррелирует события, принятые от агентов 120, используя механизм правил (не показан), который оценивает каждое событие с сетевой моделью и информацией об уязвимости для разработки сводки угроз в реальном времени. Корреляция дополнительно описывается в заявке США № 10/308767, поданной 2 декабря 2002 г., которая настоящим включена по ссылке в данном документе во всей своей полноте. Что касается управления делами, менеджер 130 может поддерживать сообщения, касающиеся статуса инцидентов безопасности и их разрешения. Отчеты об инцидентах дополнительно описаны в заявке США № 10/713471, поданной 14 ноября 2003 г., которая настоящим включена по ссылке в данном документе во всей своей полноте. Службы могут включать в себя администрирование, уведомление и составление отчетов. Менеджер 130 также может обеспечивать доступ к базе знаний.

Когда события принимаются менеджером 130, они сохраняются в базе 140 данных. Сохранение событий позволяет использовать их позже для анализа и ссылки. В одном варианте осуществления база 140 данных представляет собой систему управления реляционной базой данных, такую как база данных компании Oracle Corporation в Редвуд Шорс, Калифорния.

В одном варианте осуществления база 140 данных хранит данные в разделах, которые представляют собой хронологические секции базы данных. Например, один новый раздел создается каждый день для хранения событий этого дня. Раздел может быть сжат и сохранен в онлайновом архиве 150 для последующего извлечения. Управление разделами дополнительно описано в заявке США № 10/839563, поданной 4 мая 2004 г., которая настоящим включена по ссылке в данном документе во всей своей полноте. В одном варианте осуществления управление разделами обеспечивается компонентом архивирования и извлечения SmartStorage продукта Управление информацией о жизненном цикле безопасности (SLIM) компании ArcSight, Inc.

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

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

Веб-интерфейс представляет собой независимый и удаленно устанавливаемый веб-сервер, который обеспечивает безопасный интерфейс с менеджером 130 для клиентов веб-браузера. Веб-интерфейс предназначен для использования в качестве усовершенствованного интерфейса для клиентов провайдеров управляемых служб защиты (MSSP), операторов SOC и пользователей, которым необходим доступ к менеджеру 130 извне защищенной сети. Так как веб-сервер может быть установлен в месте, удаленном от менеджера 130, веб-сервер может работать вне брандмауэра, который защищает менеджер 130. Веб-интерфейс обеспечивает мониторинг событий и возможности с повышенным уровнем детализации. В одном варианте осуществления в качестве функции обеспечения безопасности веб-интерфейс не разрешает разработку или административные функции. В одном варианте осуществления веб-интерфейсом является продукт ArcSight Web компании ArcSight, Inc.

В одном варианте осуществления система 170 регистрации представляет собой устройство хранения данных о событии, которое оптимизируется для очень высокой пропускной способности событий. Система 170 регистрации хранит события безопасности (иногда упоминаемые как «данные регистрации»). В одном варианте осуществления события безопасности хранятся в сжатом виде. Однако система 170 регистрации может извлекать эти события по требованию (немодифицированными) для данных судебного качества. Многочисленные системы 170 регистрации могут работать вместе для масштабирования для поддержки высоких обеспечиваемых скоростей ввода при сохранении событий. Запросы событий могут распределяться по одноранговой сети систем 170 регистрации. Пользователь может конфигурировать систему 170 регистрации при помощи пользовательского интерфейса (не показан). В одном варианте осуществления система 170 регистрации представляет собой продукт Logger компании ArcSight, Inc.

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

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

2. Данные регистрации

В данном документе описаны системы и способы для эффективного хранения данных регистрации, в то же время поддерживая запрос. «Данные регистрации», используемые в данном документе, могут генерироваться различными источниками, включая как устройства, так и приложения. Эти источники включают в себя, например, описанные выше источники 110 данных, а также сетевые системы, компьютеры, операционные системы, антивирусные системы, базы данных, физическую инфраструктуру, системы управления идентификацией, службы каталогов, информационные системы о состоянии системы, веб-трафик, унаследованные системы, частные системы, мэйнфреймы, приложения мэйнфреймов, системы обеспечения безопасности, физические устройства и источники SIEM (такие как агенты 120 и менеджеры 130).

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

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

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

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

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

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

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

3. Архитектура системы регистрации

Фиг.2 представляет собой высокоуровневую блок-схему компьютера 200, служащего в качестве системы 170 регистрации системы 100 управления информацией/событиями безопасности согласно одному варианту осуществления. Изображен по меньшей мере один процессор 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, действующем в качестве системы 170 регистрации, может отсутствовать клавиатура 210, указательное устройство 214, графический адаптер 212 и/или устройство 218 отображения. Кроме того, запоминающее устройство 208 может быть локальным и/или удаленным от компьютера 200 (таким как встроенное в сеть устройство хранения данных (SAN)).

Фиг.3 представляет собой блок-схему, иллюстрирующую систему 170 регистрации системы 100 управления информацией/событиями безопасности согласно одному варианту осуществления. В изображенном варианте осуществления система 170 регистрации включает в себя приемник 310 события, менеджер 320 хранения и механизм 330 связи. Хотя для ясности показан только один приемник 310 события, система 170 может поддерживать большое количество одновременных сеансов с многими приемниками 310 события. В одном варианте осуществления каждый приемник 310 события связан с уникальным идентификатором.

Приемник 310 события принимает данные 340 регистрации, обрабатывает данные 340 регистрации и выводит «порцию» 350 данных. Приемник 310 события включает в себя систему 355 управления, набор из одного или нескольких буферов 360 и структуру 365 метаданных. Система 355 управления соединена с возможностью установления связи с набором из одного или нескольких буферов 360 и структурой 365 метаданных.

Система 355 управления управляет работой приемника 310 события и более подробно описывается ниже с ссылкой на фиг.4.

Набор из одного или нескольких буферов 360 хранит одно или несколько событий. Набор буферов 360 также хранит, для каждого события, отметку времени/даты, которая отражает то, когда событие было принято приемником 310 события. Например, набор буферов 360 присоединяет к каждому событию это значение отметки времени/даты (тем самым присоединяя поле «ReceiptTime»).

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

Например, предположим, что событие включает в себя поле, называемое OccurrenceTime (время наступления), значение которого отражает момент времени, когда произошло событие. Если OccurrenceTime было бы представляющим интерес полем, то структура 365 метаданных включала бы минимальное значение для OccurrenceTime и максимальное значение для OccurrenceTime. Минимальным значением OccurrenceTime будет OccurrenceTime для события в наборе буферов 360, которое произошло первым. Максимальным значением OccurrenceTime будет OccurrenceTime для события в наборе буферов 360, которое произошло последним.

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

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

Менеджер 320 хранения принимает порции 350 данных и сохраняет их, так что они могут запрашиваться. Менеджер 320 хранения включает в себя систему 370 управления, таблицу 375 файлов данных, таблицу 380 порций и один или несколько файлов 385 данных. Система 370 управления соединена с возможностью установления связи с таблицей 375 файлов данных, таблицей 380 порций и одним или несколькими файлами 385 данных.

Система 370 управления управляет работой менеджера 320 хранения и дополнительно описывается ниже с ссылкой на фиг.4.

Таблица 375 файлов данных хранит информацию об одном или нескольких файлах 385 данных. В одном варианте осуществления каждый элемент в таблице 375 файлов данных представляет один файл 385 данных, для которого выделено пространство, и элемент включает в себя уникальный идентификатор, связанный с файлом данных, и расположение файла данных (например, файловая система, путь в ней и имя файла). Файл 385 данных, перечисленный в таблице 375 файлов данных, может содержать или может не содержать данные (например, порции 350). Таблица 375 файлов данных сохраняется, например, в базе данных (не показана). В одном варианте осуществления файлы 385 данных выделяются перед тем, как они потребуются. В данном варианте осуществления сохраняется список этих предварительно выделенных файлов 385 данных (называемый «списком свободных ресурсов»).

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

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

Механизм 330 связи соединяет с возможностью установления связи приемник 310 события и менеджер 320 хранения. В одном варианте осуществления механизм 330 связи включает в себя частично общедоступную или полностью общедоступную сеть, такую как Интернет. В других вариантах осуществления механизм 330 связи включает в себя частную сеть или одну или несколько отдельных или логических частных сетей (например, виртуальные частные сети или локальные сети). Линии связи на механизм 330 связи и от него могут быть проводными или беспроводными (например, наземные или спутниковые приемопередатчики). В одном варианте осуществления механизм 330 связи представляет собой сеть с коммутацией пакетов, такую как основанную на IP глобальную или городскую сеть, которая использует протокол Ethernet.

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

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

4. Первоначальное сохранение

Фиг.4 представляет собой блок-схему последовательности операций, иллюстрирующую способ сохранения данных регистрации согласно одному варианту осуществления изобретения. В одном варианте осуществления способ 400 по фиг.4 выполняется совместно приемником 310 события (например, его системой 355 управления) и менеджером 320 хранения (например, его системой 370 управления).

В одном варианте осуществления, перед тем как начнется способ 400, инициализируется набор буферов 360 и структура 365 метаданных. Например, система 355 управления сохраняет в структуре 365 метаданных уникальный идентификатор, связанный с приемником 310 события.

Способ 400 начинается, когда приемник 310 события принимает 410 данные 340 регистрации. В одном варианте осуществления данные 340 регистрации принимаются в виде потока.

Система 355 управления разделяет 420 данные регистрации на одно или несколько событий и определяет 420, когда каждое событие было принято приемником 310 события.

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

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

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

В другом варианте осуществления (также не показан) система 355 управления также генерирует свертку сообщения содержимого буфера 360. Например, система 355 управления применяет криптографическую хэш-функцию к строке, которая представляет содержимое буфера 360. Может использоваться любая криптографическая хэш-функция, такая как алгоритм Message-Digest 5 (свертка сообщения) (MD5) или алгоритм в семействе алгоритмов стойкого хэширования (например, SHA-256). В одном варианте осуществления значение свертки сохраняется в структуре 365 метаданных перед считыванием порции. Это значение затем может использоваться для определения, изменились ли или были ли подделаны данные буфера, которые хранятся в порции (в сжатом виде). Это способствует гарантии целостности хранимых событий, делая это заметным, когда события были изменены.

Буфер 360 и структура 365 метаданных затем повторно инициализируются 440, таким образом сбрасывая буфер 360. В одном варианте осуществления набор буферов 360 включает в себя многочисленные буферы. Данный вариант осуществления позволяет использовать один буфер для хранения поступающих событий, когда другой буфер заполнен или сбрасывается.

В одном варианте осуществления этап 440 выполняется тогда, когда буфер 360 заполнен. В другом варианте осуществления этап 440 выполняется тогда, когда истечет конкретный период времени («окно тайм-аута»), во время которого буфером 360 не были приняты события.

Система 355 управления посылает 450 порцию 350 данных менеджеру 320 хранения.

Менеджер 320 хранения принимает 460 порцию 350. Система 370 управления сохраняет 470 порцию в файле 385 данных (см. ниже). В одном варианте осуществления порция шифруется, перед тем как она будет сохранена, для целей безопасности. Система 370 управления также обновляет 470 таблицу 380 порций. Например, система 370 управления добавляет в таблицу информацию, касающуюся порции 350, которая только что была сохранена в файле 385 данных.

Система 370 управления записывает порции 350 в порядке «присоединения» внутри каждого файла 385 данных. Это иногда упоминается как «однократная запись с протоколированием». В одном варианте осуществления система управления поддерживает «указатель записи», который указывает расположение в файле данных, где порция может быть записана. После того как порция будет записана в файл данных, указатель записи модифицируется для указания расположения в этом же файле данных (конкретно, в конце порции, которая только что была записана). Если запись порции заполняет файл данных, указатель записи модифицируется для указания расположения в другом файле данных (конкретно, в начале), который может использоваться для хранения порций. В одном варианте осуществления (не показан) записи порций откладываются первоначальным кэшированием порций в памяти. Многочисленные непрерывные порции затем объединяются в одну операцию записи, чтобы оптимизировать записи с полным распределением по всем дискам в системах запоминающих устройств на дисках RAID 5. Посредством использования больших последовательных операций ввода, таких как записи, аппаратные средства приводятся в действие с высокой скоростью, пропускной способностью и параллелизмом.

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

Способ 400 имеет много желательных характеристик. Например, он является в высокой степени масштабируемым, так как он может поддерживать прием очень большого количества событий в секунду (EPS). Могут использоваться многочисленные приемники 310 события, и запись данных о событии является быстрой, так как она включает в себя только операции присоединения, а не операции поиска. Способ 400 также характеризуется высокой доступностью, так как он обеспечивает непрерывный доступ к данным. Удаление старых событий не фрагментирует носитель данных, что означает, что не требуется процесс дефрагментации, и, поэтому, также не требуется окно технического обслуживания. Не требуется неявное время простоя для задач очистки. Также, так как операции записи на диск являются эффективными, они исключают служебные данные, чтобы оставить место для обработки запросов.

5. Возвращение области хранения

В некоторый момент времени (описано ниже) область хранения, используемая одним или несколькими файлами 385 данных, возвращается для будущего использования. Фиг.5 представляет собой блок-схему последовательности операций, иллюстрирующую способ возвращения области хранения, согласно одному варианту осуществления. В одном варианте осуществления способ 500 по фиг.5 выполняется посредством менеджера 320 хранения (например, его системы 370 управления).

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

Информация, касающаяся всех порций 350, содержащихся в идентифицированном файле 385 данных, удаляется 520 из таблицы 380 порций.

Удаляется 530 элемент в таблице 375 файлов данных, который представляет идентифицированный файл 385 данных.

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

Вновь возвращенный файл 385 данных добавляется 550 к списку доступных предварительно выделенных файлов данных и готов для приема новых порций.

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

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

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

Если существуют многочисленные политики сохранности, система 170, показанная на фиг.3, незначительно модифицируется (не показано). Конкретно, приемник 310 события включает в себя один набор буферов 360 и одну структуру 365 метаданных для каждой политики сохранности. Перед тем как событие будет сохранено в наборе буферов и структура метаданных будет обновлена (этап 430), система 355 управления определяет, какая политика сохранности должна быть применена к событию. Это определение основывается, например, на статичном отображении или атрибуте конкретного события. Может использоваться любой атрибут, такой как приоритет или источник события. Основываясь на данном определении, система 355 управления сохраняет событие в соответствующем наборе буферов и обновляет соответствующую структуру метаданных. Таким образом, все события в конкретном наборе буферов будут связаны с одной и той же политикой сохранности.

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

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

6. Запрос/извлечение данных

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

В первой фазе идентифицируются поисковые термины в запросе, которые касаются информации, которая содержалась в структуре 365 метаданных (обратно, когда событие было сохранено в качестве события в буфере 360, а не как часть порции 350 данных в файле 385 данных). Данная информация метаданных включает в себя уникальный идентификатор связанного приемника события и для каждого представляющего интерес поля минимальное значение и максимальное значение, которые вместе отражают диапазон значений этого поля по многочисленным событиям (первоначально, события в этом же буфере, затем события в этой же порции данных). Вспомните, что информация метаданных была передана менеджеру 320 хранения как часть порции 150. Затем информация метаданных была сохранена в таблице 380 порций. Таким образом, чтобы найти события, основанные на этих метаданных, используются «поисковые термины метаданных» для поиска в таблице 380 порций. Результатом этого будет то, какие порции (если есть такие) могут содержать событие, которое удовлетворяет поисковым терминам метаданных. Таким образом, поиск может ограничиваться на основе конкретных значений (или диапазонов значений) для приемника события и/или представляющих интерес полей (так как эти значения хранятся в метаданных в таблице 380 порций).

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

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

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

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

Вышеупомянутый алгоритм выполняет поиск событий, которые хранятся в порциях 350. Однако система 170 регистрации может содержать дополнительные события в приемнике 310 события (например, в наборе буферов 360), которые еще не были сохранены в порции. Вышеупомянутый алгоритм не будет выполнять поиск этих событий. В одном варианте осуществления, перед тем как алгоритм будет выполнен, набор буферов 360 сбрасывается, так что события посылаются менеджеру 320 хранения и сохраняются в порции. Таким образом, когда исполняется алгоритм, также будет выполняться поиск событий, которые были прежде в наборе буферов. В другом варианте осуществления выполняется отдельный поиск на приемнике 310 события, используя содержимое структуры 365 метаданных и набор буферов 360, подобный описанному выше алгоритму. Таким образом, выполняется поиск всех событий, хранятся ли они в менеджере 320 хранения или в приемнике 310 события.

Фиг.6 представляет собой блок-схему последовательности операций, иллюстрирующую способ запроса согласно одному варианту осуществления. В одном варианте осуществления способ 600 по фиг.6 выполняется менеджером 320 хранения (например, его системой 370 управления). Перед началом способа 600 принимается запрос на поиск. Запрос на поиск включает в себя один или несколько поисковых терминов.

Идентифицируются 610 любые поисковые термины метаданных (в принятом запросе на поиск).

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

Каждая порция 350, метаданные которой удовлетворяют поисковым терминам метаданных, извлекается 630, используя расположение порции, которое хранилось в таблице 380 порций.

Извлеченные порции разбираются 640 на их составляющие события.

Каждое событие оценивается 650 в отношении запроса на поиск, чтобы определить, удовлетворяет ли событие запросу. Если событие удовлетворяет запросу, оно включается в результаты поиска.

7. Дополнительные варианты осуществления

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

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

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

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

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

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

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

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

6. Способ по п.5, в котором первое условие срабатывания основывается на пороге использования буфера или основывается на окне тайм-аута.

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

8. Способ по п.7, в котором второе условие срабатывания основывается на политике сохранности, связанной с порцией данных.

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

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

11. Способ по п.1, в котором этап, на котором сохраняют события в буфере, содержит присоединение события к содержимому буфера.

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

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

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

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

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

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

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