Управление журналами регистрации событий безопасности (NIST SP 800-92)

Руководство по управлению журналами регистрации событий компьютерной безопасности.

(Ключевые моменты)

 NIST Special Publication 800-92. Guide to Computer Security Log Management.

 

1. Введение.

2. Введение в управление журналами регистрации событий компьютерной безопасности.

2.1. Основы журналирования событий безопасности.

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

  • журналы специального ПО (СЗИ), обеспечивающего безопасность (раздел 2.1.1).
  • журналы операционных систем (раздел 2.1.2) и приложений (раздел 2.1.3).

 

2.1.1. Системы защиты информации (СЗИ).

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

  • Системы защиты от вредоносного ПО. Наиболее распространенной формой является антивирусное ПО, которое, как правило, записывает все события связанные с обнаружением вредоносных программ, попыток «дезинфекции» файлов и систем, передачи файлов на карантин. Антивирусное ПО может также регистрировать события, связанные с проведением сканирование на наличие вредоносных программ, обновлением сигнатур.
  • Системы обнаружения и предотвращения вторжений. Журналы событий систем обнаружения и предотвращения вторжений содержат подробную информацию о подозрительном поведении и обнаруженных атаках, а также о действиях, предпринятых, чтобы остановить вредоносную активность. Некоторые задачи системы обнаружения вторжений, такие как проверка целостности файлов и ПО могут запускаться на периодической основе, создавая отдельные пакеты записей в журнале.
  • ПО для создания безопасного удаленного доступа. Удаленный доступ часто предоставляется и защищается с использованием виртуальных частных сетей (VPN). Системы VPN обычно предоставляют возможность регистрировать успешные и неудачные попытки входа, а также дату и время подключения и отключения пользователей, объем данных, переданных и принятых в каждой сессии пользователя. Системы VPN, которые поддерживают гибкий контроль доступа, такие как Secure Sockets Layer (SSL) VPN, могут также регистрировать подробную информацию об использовании ресурсов.
  • Прокси-сервер. Прокси-сервер являются промежуточным звеном (посредником) между пользователем и интернет сайтом. Прокси делает запросы веб-страниц от имени пользователей, кэширует копии полученных веб-страниц, чтобы сделать последующий доступ к этим страницам более эффективным. Прокси также может быть использован для ограничения доступа в Интернет и создания дополнительного слоя защиты между веб-клиентами и веб-сервером. Веб-прокси регистрирует информацию о посещаемых ресурсах Интернет (кто, когда и что посещал).
  • Системы управления уязвимостями. Системы управления уязвимостями, обычно регистрируют историю обнаружения и устранения уязвимостей (установки патчей) каждого хоста. Также такие системы могут записывать дополнительную информацию о конфигурации хостов. Как правило, сканирование с использованием таких систем запускается на периодической, а не постоянной основе.
  • Серверы аутентификации. Серверы аутентификации, как правило, регистрируют каждую попытку аутентификации, в том числе ее происхождение, имя пользователя, успех или неудача, а также дату и время.
  • Маршрутизаторы. Маршрутизаторы могут быть сконфигурированы, чтобы разрешить или блокировать определенные типы сетевого трафика на основе созданных политик. Маршрутизаторы, которые блокируют трафик, как правило, настроены на регистрацию только самых базовых характеристик заблокированной деятельности.
  • Межсетевые экраны. Как и маршрутизаторы, межсетевые экраны разрешают или блокируют трафик, на основании сконфигурированных политик. Однако, межсетевые экраны используют намного более сложные методы исследования трафика, они могут отслеживать состояние соединений и выполнять контентный анализ. Межсетевые экраны, как правило, имеют более сложные политики и генерируют более подробные журналы.
  • Серверы карантина. Некоторые организации проверяют уровень безопасности каждого удаленного хоста, прежде чем разрешить ему присоединиться к сети. Часто это делается через установку агентов на каждом хосте и с использованием сервера карантина. Хосты, которые не отвечают на проверки сервера или которые проходят проверку будут помещены на карантин в отдельную виртуальную сеть (VLAN). Серверы карантина регистрируют информацию о состоянии проверок, в том числе, какие хосты были помещены в карантин, и по каким причинам.

На рисунке ниже представлены примеры журналов регистрации событий СЗИ.

1

2.1.2. Операционные системы.

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

  • Системные события. Системные события — операционные действия, выполняемые компонентами ОС, такие как выключение системы или запуск сервиса. По умолчанию регистрируются события завершенные неудачей, а также наиболее значимые успешные события, но, как правило, многие ОС позволяют администраторам определять, какие типы событий будут регистрироваться. Детали, регистрируемые для каждого события, также отличаются друг от друга; каждое событие, как правило, датировано, и содержит вспомогательную информацию, такую как, коды ошибок; имя службы, имя системной или пользовательской учетной записи, связанной с событием.
  • Записи аудита. Записи аудита содержат информацию о событиях безопасности, такую как удачные и неудачные попытки аутентификации, доступ к файлам, изменения в политике безопасности, изменения учетных записей (например, создание и удаление учетных записей, назначение привилегий), использование привилегий. ОС обычно позволяют системным администраторам указать, какие типы событий следует регистрировать.

Пример журнала регистрации событий ОС представлен на рисунке ниже:

2

2.1.3. Приложения

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

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

На рисунке ниже, представлен пример журнала событий веб-сервера.

3

2.3. Проблемы в управления журналами событий.

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

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

 

2.3.1. Генерация и хранение журналов.

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

  • Большое количество источников журналов. При этом каждый источник может также регистрировать большое количество различных типов событий.
  • Противоречивое содержание журналов. Каждый источник записывает определенную информацию в свои журналы (например, адрес хоста и имя пользователя). Для эффективности, источники журналов часто записывать только те части информации, которые они считают наиболее важными. Это может затруднить задачу связи (корреляции) событий, записанных различными источниками журналов (например, источник 1 записывает IP-адрес хоста, но не имя пользователя, и источник 2 записывает имя пользователя, но не IP-адрес хоста). Каждый тип источника журнала также может представлять значения отличающемся от других формате; эти различия могут быть небольшими (например, одна дата, в формате ММДДГГГГ а другая в формате ДД-ММ-ГГГГ), или более сложными (например, использование протокола передачи файлов (FTP) в одном журнале выявляются по имени («FTP») а в другом журнале по номеру порта (21)). Все это еще больше усложняет процесс связывания событий, записанных различными источниками журнала.
  • Непоследовательные метки времени. Каждый хост, который создает журналы, обычно ссылается свои внутренние часы при установке метки для каждой записи журнала. Если на хосте установлено не точное время, временные метки в журналах также будут неточными. Это может усложнить анализ журналов, особенно когда анализируются журналы из нескольких источников. Например, временные метки могут показывать, что событие А произошло за 45 секунд до события В, когда на самом деле событие А произошло на две минуты позже события B.
  • Противоречивый формат журналов. Многие из типов источников журнала используют различные форматы для своих журналов, таких как, разделенные запятыми или др символами текстовые файлы, бинарные файлы, syslog, Simple Network Management Protocol (SNMP), Extensible Markup Language (XML). Некоторые форматы журналов предназначены для чтения человеком, в то время как другие должны проходить предварительную обработку. Некоторые журналы используют стандартные форматы, в то время как другие используют собственные форматы. Некоторые журналы создаются для передачи в другие системы, а не для локального хранения в файле. Некоторые форматы, в частности, текстовые файлы, отличаются последовательностью значений в каждой записи журнала и разделителями между значениями (например, значения, разделенных запятыми, пробелами, XML).

 

2.3.2. Обеспечение безопасности журналов.

  • В связи с тем, что журналы содержат записи систем безопасности, они должны быть защищены от нарушения их конфиденциальности и целостности. Например, в журналах может намеренно или случайно регистрироваться конфиденциальная информация, такая как, пароли пользователей и содержание электронной почты. Журналы, также могут быть подвержены преднамеренному и непреднамеренному изменению и уничтожению. Это может привести к тому, что вредоносная деятельность останется незамеченной и недоказуемой. Например, многие руткиты изменяют журналы для удаления каких-либо доказательств своей установки или функционирования.
  • Организации также должны защитить доступность своих журналов. Многие журналы имеют пороговые значения для их хранения (например, хранение 10000 последних событий, или хранение 100 мегабайт данных журнала). При достижении предельного размера, журнал может переписать старые данные — новыми, или прекратить регистрацию событий. Для удовлетворения требований к хранению данных, организации может потребоваться хранить копии файлов журналов в течение более длительного периода времени, чем поддерживают источники журналов, что требует внедрение процесса архивирования журналов. Ввиду большого объема, было бы целесообразно в некоторых случаях, отфильтровывать записи журнала, которые не должны быть попадать в архив, для уменьшения объема. Конфиденциальность и целостность архивных журналов также должны быть обеспечены.

 

2.3.3. Анализ журналов.

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

 

2.3. Решение проблем управления журналами.

Несмотря на многие проблемы, с которыми сталкиваются организации, есть несколько ключевых практик, следование которым поможет решить рассмотренные выше проблемы, и даже предотвратить их появление:

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

 

3. Инфраструктура управления журналами.

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

  • Системы централизованного сбора и хранения журналов, основанные на протоколе syslog.
  • Системы управления событиями информационной безопасности.

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

 

3.1. Архитектура.

Инфраструктура управления журналами обычно включает в себя следующие три уровня:

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

 

3.2. Функции.

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

Общие:

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

Хранение:

  • Ротация журналов – закрытие одного и открытие нового файла журналов, когда первый файл считается полным. Ротация обычно выполняется в соответствии с графиком (например, ежечасно, ежедневно, еженедельно), или когда файл журнала достигает определенного размера. Основные преимущества ротации журналов — сохранение записей журналов, сохраняя при этом управляемым размер файлов журнала.
  • Архивирование журналов — сохранение журналов в течение длительного периода времени, как правило, на съемных носителях, в сети хранения данных (SAN), или специализированном устройстве или сервере. Журналы часто нуждаются в хранении для удовлетворения юридических или нормативных требований. Есть два типа хранения журналов: сохранение и консервация. Сохранение (Log retention) — выполняет архивирование журналов на регулярной основе в рамках стандартных операционных мероприятий. Консервация (Log preservation) — архивация журналов, содержащих интересующие организацию записи, которые в обычных условиях отбрасываются системой фильтрации. Консервация обычно выполняется в интересах проведения дальнейших расследований инцидентов.
  • Сжатие журналов — хранение файлов журналов таким образом, чтобы уменьшить место, необходимое для хранения файла, не изменяя смысл содержания журнала. Сжатие часто выполняется, при ротации и архивировании журналов.
  • Сокращение журналов — удаляет ненужные записи из журнала, чтобы создать новый журнал меньшего объема. Сокращение часто выполняются в сочетании с архивированием, чтобы на длительное хранение помещались только записи журналов, представляющие интерес для организации.
  • Преобразование журналов – обработка журнала в одном формате и хранение в другом. Например, преобразование может импортировать данные из журнала в базе данных и сохранять его в XML-формате в текстовом файле. Многие генераторы журнала могут конвертировать свои собственные журналы в другой формат. Доступны также сторонние утилиты для преобразования.
  • Нормализация журналов, каждое поле данных журнала преобразуется в частный формат представления. Наиболее распространенный пример нормализации — хранение дат и времени в едином формате. Нормализация может быть очень ресурсоемкой, особенно для сложных записей журнала (например, журналы систем обнаружения вторжений).
  • Проверка целостности журналов – вычисление контрольной суммы каждого файла журналов и надежное хранение значений контрольных сумм сообщения, чтобы  гарантировать, что изменения архивных журналов будут обнаружены.

Анализ:

  • Корреляция событий находит связи между двумя или более записями. Наиболее распространенной формой корреляции событий является основанная на правилах корреляция, которая сопоставляет несколько записей журнала из одного или нескольких источников на основе зарегистрированных значений, например отметки времени, IP-адреса и типа событий. Корреляция событий также может быть выполнена другими способами, например, с использованием статистических методов или средств визуализации. Если корреляция выполняется с помощью автоматизированных методов, как правило, результат успешной корреляции — новая запись, которая объединяет фрагменты информации. В зависимости от характера коррелированной информации, система может также генерировать сигнал тревоги, указывающий, что определенное событие требует дальнейшего расследования.
  • Просмотр журнала — отображение записей журнала в удобном для восприятия формате. Большинство генераторов журналов предоставляют некоторые возможности просмотра журналов. Также для этого можно использовать различные сторонние утилиты. Некоторые средства просмотра журналов обеспечивают возможность фильтрации и агрегации.
  • Формирование отчетов отображает результаты анализа журналов.

Утилизация:

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

 

3.3. Системы централизованного сбора и хранения журналов, основанные на протоколе syslog.

В инфраструктурах на основе протокола syslog, каждый генератор журнала использует одинаковый формат для своих журналов и базовой механизм передачи своих записей журнала на сервер, запущенный на другом хосте. Syslog предоставляет основу для генерации, хранения и передачи записей журналов, которые могут использоваться различными ОС, СЗИ, или приложениями, поддерживающими данный формат. Подробнее о протоколе Syslog можно почитать здесь: http://ru.wikipedia.org/wiki/Syslog.

 

3.3.1. Формат Syslog.

Syslog назначает приоритет каждому сообщению на основе важности следующих двух атрибутов:

  • Тип сообщения, известный как facility. Примеры включают сообщения ядра, сообщения системы электронной почты, сообщения авторизации, сообщения принтера и сообщения аудита.
  • Серьезность. Каждому сообщению журнала присваивается уровень серьезности, от 0 (чрезвычайный) до 7 (отладка).

Пример сообщения Syslog представлен на рисунке ниже:

4

3.3.2. Безопасность Syslog.

Syslog разрабатывался в то время, когда безопасность журналов не была основной целью.

В настоящее время в протоколе syslog уделяется больше внимания безопасности журналов. Реализация протокола на основе RFC 3195 может поддерживать конфиденциальность, целостность и доступность журналов.

 

3.4. Системы управления событиями информационной безопасности (SIEM -системы).

SIEM системы имеют один или несколько серверов журналов, которые выполняют анализ журналов, и один или несколько серверов баз данных, в которых хранятся журналы. Большинство продуктов SIEM поддерживает два способа сбора журналов:

  • Без агента. Сервер SIEM получает данные от хоста-источника, без необходимости установки на этом хосте специального программного обеспечения. Затем сервер выполняет фильтрацию событий и агрегацию, нормализацию и анализ собранных журналов.
  • С использованием агента. На хост-источник устанавливается специальная программа-агент, которая выполняет фильтрацию событий, агрегацию, нормализации журналов, и затем передает данные нормированных журналов на сервер SIEM, как правило, в режиме реального или близком к реальному масштабе времени для дальнейшего анализа и хранения.

 

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

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

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

 

3.5. Дополнительные типы ПО управления журналами событий.

Другие типы программного обеспечения, которые также могут быть полезны в управлении журналами:

  • Системы обнаружения вторжений уровня хоста (Нost-based IDS). Хост-IDS контролирует (в поисках подозрительной активности) характеристики и события в пределах одного хоста. Многие IDS уровня хоста могут контролировать журналы ОС и приложений, для обеспечения безопасности.
  • Инструменты визуализации. Инструмент визуализации представляет данные о событиях безопасности в графическом формате. Например, инструмент может отображать данные, сгруппированные или упорядоченные по значениям различных характеристик событий (например, таких как адрес источника). Многие SIEM решения имеют встроенные средства визуализации.
  • Утилиты для ротации журналов. Администраторы могут использовать специализированные утилиты сторонних производителей для ротации журналов. Это может быть полезно для улучшения управления журналами при отсутствии встроенных возможностей ротации журналов.
  • Утилиты тля преобразования журналов. Многие производители программного обеспечения предлагают утилиты, которые можно использовать, чтобы преобразовать журналы в стандартные форматы. Эти утилиты являются полезными, например, когда SIEM решение не поддерживает определенный формат журнала.

 

4. Планирование управления журналами.

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

 

4.1. Определение ролей и сфер ответственности.

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

  • Системные и сетевые администраторы, как правило, отвечают за настройку ведения журналов отдельных систем и сетевых устройств, периодический анализ этих журналов, отчетность о результатах деятельности по управлению журналами, а также регулярное обслуживание журналов и ПО управления журналами.
  • Администраторы безопасности, как правило, отвечают за управление и мониторинг инфраструктуры управления журналами, настройку ведения журналов на устройствах безопасности (например, межсетевые экраны, сетевые системы обнаружения вторжений, антивирусные серверы), отчетность о результатах деятельности по управлению журналами, и помощь другим сотрудникам с настройкой журналов регистрации событий.
  • Команда реагирования на инциденты компьютерной безопасности, использует данные журнала при обработке некоторых инцидентов.
  • Разработчики приложений, могут понадобиться для разработки или настройки приложений таким образом, чтобы приложения выполняли регистрацию событий в соответствии с определенными требованиями и рекомендациями.
  • Руководитель подразделения информационной безопасности (CISO) может осуществлять надзор за инфраструктурой управления журналами.
  • Руководитель ИТ-службы (CIO), отвечает за ИТ-ресурсы, которые генерируют, передают и хранят журналы.
  • Аудиторы, могут использовать данные журналов при выполнении проверок.
  • Лица, участвующие в закупке программного обеспечения, которое должно или может генерировать данные журналов компьютерной безопасности.

 

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

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

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

 

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

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

 

4.2. Определение и внедрение политик журналирования.

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

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

Генерация журналов:

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

Передача журналов:

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

Хранение и удаление журналов:

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

Анализ журналов:

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

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

5

4.3. Убедитесь в выполнимости политик.

Создание требований и рекомендаций по регистрации событий должно проводиться в сочетании с анализом

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

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

 

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

 

Организации при разработке политики необходимо также рассмотреть среду в которой функционируют системы,. NIST SP 800-70, Security Configuration Checklists Program for IT Products—Guidance for Checklists Users and Developers, определяетнесколькообщихтиповсредыфункционирования. Ниже приведено описание этих сред с пояснениями, как характеристики каждой среды могут повлиять на политики протоколирования. Организации могут рассмотреть отдельные положения политик управления журналами для систем в каждой среде.

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

o   Системы с ограниченной (в целях безопасности) функциональностью (Specialized Security-Limited Functionality) содержат системы и сети с высоким риском нападения или раскрытия данных, в которых безопасность имеет приоритет перед функциональностью. Предполагается, что системы имеют ограниченную или специализированную функциональность, из-за функционирования в среде с высоким риском (например, внешний межсетевой экран или доступный из внешней сети веб-сервер). Такие системы могут иметь ограниченную способность участвовать в инфраструктуре управления журналами из-за потенциальных рисков нарушения безопасности (например, запуск дополнительных сетевых сервисов, передача незащищенной конфиденциальной информации по сетям общего пользования). Для таких компонентов может потребоваться доставка журналов через другие каналы (например, вручную с использованием переносных носителей информации).

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

 

4.4. Разработка инфраструктуры управления журналами.

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

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

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

 

5. Операционные аспекты управления журналами.

Администраторы ИТ — инфраструктуры должны следовать стандартным процессам управления журналами, за выполнение которых они несут ответственность. В этом разделе описываются основные операционные виды деятельности процесса управления журналами:

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

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

 

5.1. Настройка источников журналов:

5.1.1. Генерация журналов.

5.1.2. Хранение и удаление журналов.

Опции, связанные с хранением журналов могут включать:

  • Отсутствие необходимости хранения.
  • Хранение только на локальном уровне (уровне хоста).
  • Хранение только на уровне инфраструктуры управления журналами.
  • Хранение, как на уровне хоста, так и на уровне инфраструктуры.

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

  • Остановить регистрацию событий.
  • Перезаписать старые данные журналов.
  • Остановить генерацию журналов.

5.1.3. Безопасность журналов.

Администраторы должны обеспечивать целостность и доступность данных журналов, а также часто и их конфиденциальность. Раздел 5.1.2 описывает практики хранения и архивирования журналов, которые поддерживают доступность. Необходимо также учитывать дополнительные соображения безопасности при хранении и передаче журналов:

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

 

5.2. Анализ данных журналов:

5.2.1. Понимание информации содержащейся в журналах.

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

  • Необходимость учета контекста.
  • Неясность сообщений.

5.2.2. Приоритезация данных журналов.

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

  • Тип записи (например, код сообщения 103, класс сообщения критический).
  • Новизна (то есть, появлялся ли такой тип данных в журналах раньше?).
  • Источник журнала.
  • IP-адрес источника или назначения (например, адрес источника из черного списка, адрес назначения — критическая система)/
  • Время суток или день недели (например, запись может быть приемлемой или неприемлемой в определенное время)
  • Частота событий (например, N раз за Mсекунд).

5.2.3. Сравнительный анализ на уровне хоста/системы.

 

5.3. Реагирование на идентифицированные события.

5.4. Управление долгосрочным хранением данных журналов.

  • Выберите формат журналов для проведения архивирования.
  • Архивируйте данные журналов.
  • Проверяйте целостность передаваемых журналов.
  • Обеспечивайте безопасность мест/средств хранения журналов.

 

5.5. Обеспечение дополнительной операционной поддержки.

Необходимо регулярно выполнять следующие виды работ:

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

 

5.6. Выполнение тестирования и валидации.

Наиболее распространенные методы проверки и валидации системы управления журналами:

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

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

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