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

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

Иллюстрации

Показать все

Реферат

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 соедине