Система автоматизации службы поддержки

Размещено на http://www.allbest.ru/

Содержание

Список сокращений

Введение

1. Теоретические основы менеджмента инцидентов информационной безопасности

1.1 Российские и международные документы, регламентирующие аспекты управления инцидентами информационной безопасности

1.2 Общие принципы в выявлении инцидентов ИБ

2. Сравнительный анализ современных подходов к выявлению инцидентов ИБ в организации

2.1 Технические средства и системы для выявления инцидентов ИБ

2.2 SIEM-системы

2.2.1 Принцип работы SIEM

2.2.2 Рынок SIEM

2.3 Сравнительный анализ SIEM-систем

2.3.1 Методика расчета

2.3.2 Сбор и обработка событий

2.3.3 Анализ данных

2.3.4 Настройки системы и внутренний аудит

2.3.5 Отказоустойчивость

2.3.6 Сертификаты регуляторов

2.3.7 Удобство использования

2.3.8 Итоговые результаты сравнительного анализа SIEM

3. Рекомендации по построению SOC

3.1 Цели и процессы SOC

3.2 Компетенции сотрудников

3.3 Подготовка и сведения инфраструктуры

Заключение

Список использованных источников

Приложение



Список сокращений

менеджмент информационный инцидент безопасность

БС РФ - банковская система Российской Федерации.

ДБО - дистанционное банковское обслуживание.

ИБ - информационная безопасность.

ИТ - информационные технологии.

Модель Деминга (цикл PDCA) - (англ. «Plan-Do-Check-Act» - планирование - действие - проверка - корректировка) циклически повторяющийся процесс принятия решения, используемый в управлении качеством.

ПО - программное обеспечение.

САСП - Система автоматизации службы поддержки.

СМИИБ - система менеджмента инцидентов информационной безопасности.

СУИБ - система управления информационной безопасность.

CISRT (Critical Incident Stress Response Team) - группы или подразделения, обеспечивающего сервис и поддержку предотвращения, обработку и реагирование на инциденты информационной безопасности.

CMMI (Capability Maturity Model Integration) - комплексная модель производительности и зрелости - набор моделей (методологий) совершенствования процессов в организациях разных размеров и видов деятельности. CMMI содержит набор рекомендаций в виде практик, реализация которых, по мнению разработчиков модели, позволяет реализовать цели, необходимые для полной реализации определенных областей деятельности.

DLP (Data Loss Prevention) - системы защиты от утечек конфиденциальной информации, предназначенные для отслеживания и блокирования попыток несанкционированной передачи данных за пределы корпоративной сети. Помимо предотвращения утечек информации DLP система может выполнять функции по отслеживанию действий пользователей, записи и анализу их коммуникаций через e-mail, социальные сети, чаты и т.д. Основная задача систем DLP - обеспечение выполнения принятой в организации политики конфиденциальности (защита информации от утечки)..

FTP (File Transfer Protocol) - протокол передачи файлов - стандартный протокол, предназначенный для передачи файлов по TCP-сетям (например, Интернет). FTP часто используется для загрузки сетевых страниц и других документов с частного устройства разработки на открытые сервера хостинга.

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

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

ITIL - (произносится как «айтимл», англ. IT Infrastructure Library -- библиотека инфраструктуры информационных технологий) -- библиотека, описывающая лучшие из применяемых на практике способов организации работы подразделений или компаний, занимающихся предоставлением услуг в области информационных технологий.

NetBIOS (Network Basic Input/Output System) - протокол для работы в локальных сетях на персональных ЭВМ типа IBM/PC, разработан в виде интерфейса, который не зависит от фирмы-производителя.

RPC (Remote Procedure Call) - удалённый вызов процедур - класс технологий, позволяющих компьютерным программам вызывать функции или процедуры в другом адресном пространстве (как правило, на удалённых компьютерах).

SEM (Security Event Management) - системы действуют в режиме приближённом к реальному времени. Для этого им требуется: автоматический мониторинг событий, их сбор, корреляция, генерация предупреждающих сообщений.

SIEM (Security Information and Event Management) - управление информацией и событиями в системе безопасности - общее название программных продуктов, ранее используемых по отдельности друг от друга, категории SIM (Security Information Management - управление информацией в системе безопасности) и SEM (Security Event Management - управление событиями в системе безопасности).

SIM (Security Information Management) - системы, в свою очередь, анализируют накопленную информацию со стороны статистики, различных отклонений от «нормального поведения» и т.д.

SOC (Security Operations Center) - центр мониторинга и обработки событий информационной безопасности.

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

TFTP (Trivial File Transfer Protocol) - простой протокол передачи файлов, используется главным образом для первоначальной загрузки бездисковых рабочих станций.



Введение

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

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

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

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

Целью работы является сравнительный анализ современных подходов к выявлению инцидентов ИБ. К современным подходам относятся организационные процессы и технические средства.

Организационные процессы строятся на ключевых международных и российских стандартах менеджмента информационной безопасности, менеджмента инцидентов ИБ и отраслевых стандартах, например - СТО БР ИББС-1.0-2014 Требования к организации обнаружения и реагирования на инциденты информационной безопасности. Для более глубокого анализа, многие аспекты будут представлены на примере компании, относящейся к финансовым некредитным организациям.

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

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



1. Теоретические основы менеджмента инцидентов информационной безопасности

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

Инцидент информационной безопасности (information security incident) - единичное или серия нежелательных или неожиданных событий ИБ, которые имеют значительную вероятность к нарушению бизнес-операций и угрожают информационной безопасности [1].

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

Таблица 1.1 - Стандарты менеджмента инцидентов ИБ

Группа стандартов	Перечень документов
Стандарты ISO	ISO/IEC 27001:2013 «Information security management system»
	ISO/IEC 27002:2013 «Information technology. Security techniques. Code of practice for information security controls»
	ISO/IEC 27035:2011 «Information technology. Security techniques. Information security incident management» И проекты дополнений к нему: CD 27035-1 Part 1: «Principles of incident management» CD 27035-2 Part 2: «Guidelines to plan and prepare for incident response» CD 27035-3 Part 3: «Guidelines for CSIRT operations»
	ISO/IEC 27037:2012 «Information technology. Security techniques. Guidelines for identification, collection, acquisition and preservation of digital evidence»
	ISO/IEC 27043:2015 «Information technology. Security techniques. Incident investigation principles and processes»
	ISO 22320:2011 «Societal security. Emergency management. Requirements for incident response»
Переводные ГОСТы	ГОСТ Р ИСО/МЭК 27001-2006 «Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности»
	ГОСТ Р ИСО/МЭК 27002-2012 «Информационная технология. Методы и средства обеспечения безопасности. Свод норм и правил менеджмента информационной безопасности»
	ГОСТ Р ИСО/МЭК ТО 18044-2007 «Информационная технология. Методы и средства обеспечения безопасности. Менеджмент инцидентов информационной безопасности»
	ГОСТ Р ИСО/МЭК 27037-2014 «Информационная технология. Методы и средства обеспечения безопасности. Руководства по идентификации, сбору, получению и хранению свидетельств, представленных в цифровой форме»
	СТО БР ИББС-1.0-2014 «Требования к организации обнаружения и реагирования на инциденты информационной безопасности»
СТО БР ИББС	РС БР ИББС-2.5-2014 «Менеджмент инцидентов ИБ»
NIST	NIST SP 800-61 Rev. 2 «Computer Security Incident Handling Guide»
	NIST SP 800-86 «Guide to Integrating Forensic Techniques into Incident Response»
	NIST SP 800-53 Rev. 4 Security and Privacy Controls for Federal Information Systems and Organizations (Security control: IR - Incident Response »
Материалы ENISA	"Good Practice Guide for Incident Management"
	"CSIRT Setting up Guide in Russian"
Процессы ITSM
Процессы COBIT5	DSS 02 Manage Service Requests and Incidents
	DSS 03 Manage Problems
Процессы ITIL	Event management (книга Service operation)
	Incident management (книга Service operation)
	Problem management (книга Service operation)
Процессы ISO 20000	Incident Management
	Problem management

1.1 Российские и международные документы, регламентирующие аспекты управления инцидентами информационной безопасности

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

ISO/IEC 27001:2013 «Information security management system» и ГОСТ Р ИСО/МЭК 27001-2006 «Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности»

Дополнительно стандарт предписывает следующие требования к процессу управления инцидентами ИБ, согласно разделу 4.2.3. «Мониторинг и анализ СУИБ» в организации должны быть выполнены следующие требования:

оказание необходимой помощи в выявлении событий безопасности для последующего предотвращения инцидентов безопасности путем использования индикаторов;

своевременная идентификация неудавшихся и успешных нарушений безопасности и инцидентов безопасности;

анализ эффективности действий, предпринятых для устранения нарушения безопасности;

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

В приложении А «Цели и меры управления» в разделе А.13 «Управление инцидентами ИБ» включен также определенный набор требований. Эти требования уже более конкретны и предъявляются к отдельным этапам работы процесса управления инцидентами ИБ [2].

Национальный стандарт Российской Федерации ГОСТ Р ИСО/МЭК 27001-2013 «Методы и средства обеспечения безопасности. Системы менеджмента ИБ» является аутентичным переводом на русский язык международного стандарта, рассмотренного выше, и предъявляет к процессу управления ИБ аналогичные требования.

ISO/IEC TR 18044:2004 «Information security incident management» и ГОСТ Р ИСО/МЭК ТО 18044-2007 «Менеджмент инцидентов информационной безопасности»

Международный стандарт ISO/IEC TR 18044 по управлению инцидентами ИБ определяет формальную модель процессов управления инцидентами ИБ. В данном стандарте описание процессов управления инцидентами ИБ, как и в стандарте ISO/IEC 27001, основано на использовании циклической модели Деминга (цикле PDCA). Документ подробно описывает стадии планирования и подготовки, эксплуатации, анализа и улучшения процесса реагирования на инциденты ИБ.

Основные цели данного документа говорят о следующем:

события и инциденты ИБ должны быть эффективно обработаны и определены относящиеся или не относящиеся к инцидентам ИБ;

идентифицированные инциденты ИБ в организации должны быть оценены, реагирование на них должно быть осуществлено наиболее подходящим и эффективным образом;

последствия инцидентов ИБ на организацию и бизнес-процессы должны быть минимизированы в процессе реагирования на инциденты, иногда с привлечением средств, обеспечивающих непрерывность бизнеса;

анализ инцидентов и событий ИБ производится в целях повышения вероятности предотвращения инцидентов в будущем, улучшения механизмов внедрения и использования защитных мер ИБ, улучшения общей системы менеджмента инцидентов ИБ [2].

Стандарт содержит все необходимые условия для разработки полноценного процесса управления инцидентами ИБ и поддерживающей его документации, а так же для создания процесса, полностью соответствующего требованиям ISO/IEC 27001.

NIST SP 800-61 «Computer security incident handling guide»

Настоящий документ «Руководство по реагированию на инциденты компьютерной безопасности» представляет собой сборник «лучших практик» по построению процессов управления инцидентами ИБ и реагирования на них. В стандарте разбираются вопросы реагирования на разные типы инцидентов, например, такие как атаки «отказ в обслуживании», распространение вредоносного программного обеспечения, несанкционированный доступ, нерегламентированное использование и распределенные (многокомпонентные) атаки. Процесс реагирования на инциденты компьютерной безопасности рассматривается, начиная с первоначальных приготовлений и заканчивая разбором инцидента после окончания процесса реагирования на него [3].

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

Процесс реагирования на инциденты по NIST SP 800-61 включает в себя следующие фазы: подготовка, обнаружение и анализ, сдерживание/устранение/восстановление, деятельность после инцидента.

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

Общие рекомендации, делающие процесс анализа инцидента проще и эффективнее:

Профилируйте сети и системы;

Создайте политику хранения журналов регистрации событий;

Выполняйте корреляцию событий;

Поддерживайте синхронизацию времени в системах;

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

Используйте для исследования поисковые системы в Интернет;

Используйте сниферы для сбора дополнительных данных;

Фильтруйте данные;

Обращайтесь за помощью к экспертам [4].

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

CMU/SEI-2004-TR-015 «Defining incident management processes for CSIRT»



СТО БР ИББС - 1.0 - 2014. «Обеспечение информационной безопасности организаций банковской системы РФ. Общие положения».



средств обработки (в том числе обнаружения) инцидентов информационной безопасности, по классификации инцидентов информационной безопасности [7].



1.2 Общие принципы в выявлении инцидентов ИБ

Для описания процедуры управления инцидентами безопасности используется классическая модель непрерывного улучшения процессов, получившая название от цикла Шухарта-Деминга -- модель PDCA (Plan - Do - Check - Act, т.е. "Планируй - Выполняй - Проверяй - Действуй"). Стандарт ISO 27001 описывает модель PDCA как основу функционирования всех процессов системы управления информационной безопасностью. Естественно, что и процедура управления инцидентами ИБ подчиняется модели PDCA, представленной на рисунке 1.1.

Рисунок 1.1 - Цикл Шухарта-Деминга -- модель PDCA

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

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

В качестве основных целей структурированного, хорошо спланированного метода менеджмента инцидентов ИБ ГОСТ 18044-2007 выделяет следующие:

обнаружение и эффективная обработка событий ИБ, выделение из их числа инцидентов ИБ ;

оценка и разрешение идентифицированных инцидентов ИБ наиболее оптимальным способом;

минимизация негативных воздействий инцидентов ИБ соответствующими защитными мерами;

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

После разработки и внедрения всех необходимых процедур и документации СМИИБ, в компании целесообразно осуществлять плановый и системный мониторинг событий ИБ, в целях оперативного выявления и реагирования на инциденты ИБ.

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

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

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

Рисунок 1.2 - Алгоритм выявления и реагирования на инциденты ИБ

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

наложение дисциплинарных взысканий на нарушителя;

создание негативного имиджа нарушителя;

проведение дополнительных инструктажей и обучения пользователей;

осуществление рассылок о необходимости соблюдения требований по ИБ;

внесение изменений в политику ИБ банка и т.п.

В целом, эффективность и оперативность процесса управления инцидентами ИБ зависит от следующих факторов:

координации и согласованности действий всех вовлеченных в него лиц;

имеющихся возможностей получения и анализа информации, связанной с инцидентом;

оперативности и корректности полученных результатов.

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

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

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

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



2. Сравнительный анализ современных подходов к выявлению инцидентов ИБ в организации

2.1 Технические средства и системы для выявления инцидентов ИБ

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

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

Основными задачами, решаемыми с помощью технических средств и систем выявления инцидентов ИБ, являются:

осуществление централизованного сбора, обработки и анализа событий из множества распределенных гетерогенных источников событий;

обнаружение в режиме реального времени атак, вторжений, нарушений политик безопасности;

контроль за портами и устройствами ввода/вывода информации;

мониторинг действий пользователей;

предоставление инструментария для проведения расследований инцидентов ИБ, формирования доказательной базы по инциденту ИБ.

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

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

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

2.2 SIEM-системы

SIEM-системы появились в результате эволюционного развития и последующего слияния систем SEM и SIM.

SEM (Security Event Management) - системы действуют в режиме приближённом к реальному времени. Для этого им требуется: автоматический мониторинг событий, их сбор, корреляция, генерация предупреждающих сообщений.

SIM (Security Information Management) - системы, в свою очередь, анализируют накопленную информацию со стороны статистики, различных отклонений от «нормального поведения» и т.д.

Когда же возможности SIM и SEM объединяются в рамках одного продукта, говорят о SIEM-системах. Исходя из этого, можно дать «литературный» перевод аббревиатуры SIEM - система сбора и корреляции событий. Важно понимать, что SIEM-системы в качестве самостоятельного (standalone) решения не предназначены и не способны предотвращать инциденты нарушения информационной безопасности. Их сущность заложена в их названии: анализ информации, поступающей из различных источников (DLP, IDS, антивирусы, межсетевые экраны и т.д.), и дальнейшее выявление отклонений от норм по заданным критериям. Тем не менее, «плюсов» вполне достаточно.

Перед системой SIEM ставятся следующие задачи:

Консолидация и хранение журналов событий от различных источников;

Предоставление инструментов для анализа событий и разбора инцидентов;

Корреляция и обработка событий по правилам;

Автоматическое оповещение и инцидент-менеджмент.

2.2.1 Принцип работы SIEM

В теории всё просто: система собирает информацию, анализирует «на лету» (и генерирует предупреждающее сообщение), складывает в базы данных, анализирует поведение на основании предыдущих наблюдений (и генерирует предупреждающее сообщение).

На практике схема, представленная на рис. 2.1, реализуется с помощью соответствующих компонентов:

Агенты (сбор данных из различных источников);

Серверы-коллекторы (аккумуляция информации, поступившей от агентов);

Сервер баз данных (хранение информации);

Сервер корреляции (анализ информации).



Рисунок 2.1 - Схема реализации SIEM

Входной информацией для SIEM-систем может служить практически любая информация. Как уже было сказано выше, сбор данных может осуществляться с помощью специальных агентов, которые представляют собой программу, которая локально собирает журналы событий и по возможности передает их на сервер. Для «вычитки» того или иного источника данных агент использует коллекторы - библиотеки для понимания конкретного журнала событий или системы. Коллекторы играют важную роль, так как разные источники могут именовать одно и то же событие по-своему. Например, Firewall одного производителя может записывать в отчёт deny, другого discard, третьего drop, хотя событие одно и тоже. Коллекторы помогают привести все эти события к общему знаменателю.

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

Также информацию можно собирать удалённо при помощи соединения по протоколам NetBIOS, RPC, TFTP, FTP. Однако в этом случае может возникнуть проблема с нагрузкой на сеть, так как часть систем позволяет передавать только журнал целиком, а не «свежие» записи.

SIEM-системы могут использовать следующие источники информации:

Access Control, Authentication. Применяются для мониторинга контроля доступа к информационным системам и использования привилегий.

DLP-системы. Сведения о попытках инсайдерских утечек, нарушении прав доступа.

IDS/IPS-системы. Несут данные о сетевых атаках, изменениях конфигурации и доступа к устройствам.

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

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

Межсетевые экраны. Сведения об атаках, вредоносном ПО и прочем.

Сетевое активное оборудование. Используется для контроля доступа, учета сетевого трафика.

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

Системы инвентаризации и asset-management. Поставляют данные для контроля активов в инфраструктуре и выявления новых.

Системы веб-фильтрации. Предоставляют данные о посещении сотрудниками подозрительных или запрещенных веб-сайтов.

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

SIEM-системы способны выявлять:

сетевые атаки во внутреннем и внешнем периметрах;

вирусные эпидемии или отдельные вирусные заражения;

попытки несанкционированного доступа к конфиденциальной информации; мошенничество;

ошибки и сбои в работе информационных систем;

уязвимости;

ошибки конфигураций в средствах защиты и информационных системах;

целевые атаки (APT).

2.2.2 Рынок SIEM

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

Основные лидеры SIEM-систем отображены в отчете международного аналитического агентства Gartner и представлены на рисунке 2.2 . Для анализа «способности реализации» аналитики Gartner принимают во внимание семь критериев, связанных с опытом клиента при использовании продукта или сервиса. Эта оценка включает простоту установки, использования, администрирования и масштабирования, стабильность работы и последующую сервисную поддержку. По шкале «полнота видения» оценивается способность организации понимать потребности клиента и воплощать это в своих продуктах и сервисах. Для сбора информации аналитики проводят интервью с потребителями услуг поставщиков, а также собирают отзывы клиентов Gartner, которые пользовались SIEM-системами.

Ввиду малой распространенности на рынке России и СНГ таких продуктов, как Splunk и LogRhythm, решено не рассматривать эти платформы в дальнейшем анализе. В тоже время, среди отечественных решений наиболее перспективной является платформа Positive Technologies, которая будет включена в конечный список.

Рисунок 2.2 - Магический квадрант Gartner по SIEM технологиям за 2015 год

Таким образом, в список сравниваемых решений попали:

HP ArcSight;

IBM QRadar Intel Security;

McAfee ESM;

RSA Security Analytics;

Positive Technologies MaxPatrol SIEM.



2.3 Сравнительный анализ SIEM-систем

2.3.1 Методика расчета

Рассматривается организация с численностью сотрудников ИБ до 10 человек. Специалисты выполняют широкий спектр задач, начиная с разработки нормативной документации и заканчивая обслуживанием СЗИ, т.е. не структурированы должностные обязанности. В организации существуют ИБ-политики и процессы, имеющие скорее формальное значение. При внедрении новых СЗИ нет необходимости интегрироваться в процессы ИТ и ИБ, или данная интеграция незначительна. Процесс согласования новых технических решений может быть как простым и быстрым, так и продолжительным и сложным из-за бюрократии. ИБ-подразделение выполняет прежде всего задачи соответствия требованиям регуляторов, текущие локальные задачи, реализация системной программы ИБ часто в расчет не берется. Для оценки функционала каждой из систем использован матричный метод расчета количества баллов, который отображен в приложении 1.

В целом, баллы выставлялись следующим образом.

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

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



Таблица 2.1 - Параметры для анализа SIEM-систем

Важность критерия (1-10)	Критерии	Параметры
8	Сбор событий	Количество поддерживаемых источников событий
		Качество парсинга событий
		Частота обновлений коннекторов\парсеров событий
		Нормализация (приведение всех обрабатываемых записей к единому виду)
		Агрегация
		Фильтрация событий по определенным условиям
		Контроль целостности данных
		Возможность автоматической приоритизации выявленного события
10	Анализ данных	Базовая корреляция
		Поведенческий анализ
		Расследование инцидентов
8	Настройки системы и внутренний аудит	Интеграция с LDAP, AD для обеспечения аутентификации
		Наличие системы управления инцидентами и Workflow
		Возможности по разграничению доступа
		Настройки парольной политики
		Защита канала при взаимодействии компонентов сисетмы
		Внутренний аудит системы
9	Отказоустойчивость	Непрерывность сбора событий
		Восстановление конфигурации после сбоев
		Автоматическое резервирование данных
8	Комплаенс - модуль	Соответствие требованиям международных стандартов
9	Наличие сертификатов российских регуляторов	ФСТЭК
7	Удобство использования	Простота масштабируемости и адаптации к сетям с различной топологией и определенной бизнес-направленностью
		Кастомизация графических панелей и интерфейса программы
		Возможности по оповещению о возникающих событиях
		Наличие предустановленного "базового" функционала по правилам корреляции и формам отчетов
		Возможность получения отчетов за большие промежутки времени



Далее рассматривается каждый критерий со своей совокупностью параметров.

2.3.2 Сбор и обработка событий

Результат анализа по первому критерию - Сбор событий - представлен на рисунке 2.3.

Рисунок 2.3 - Результат анализа критерия Сбор и обработка событий

IBM QRadar. Платформой поддерживается более 300 стандартных источников событий. Полноценная категоризация определена для большей части основных событий аудита, но довольно часто встречаются и события без категории. Качество парсинга обусловлено и используемой схемой хранения событий, включающей небольшое количество наиболее критичных полей. Обновления коннекторов/парсеров событий выпускаются вендором по мере выхода исправлений и дополнений. Присутствует автообновление парсеров событий. Для подключения нестандартных источников могут применяться часто используемые транспорты. Разработка собственных парсеров происходит по большей части в основном интерфейсе продукта, для описания событий используется regex.

HP ArcSight. Платформой поддерживается более 300 стандартных источников событий. Все события категоризированы, и их имена определены. Помимо этого, коннекторы многих систем включают в себя несколько вариантов парсеров, что позволяет выбрать наиболее подходящий под конкретные цели алгоритм обработки аудита. Обновления коннекторов/парсеров событий выпускаются вендором по мере выхода исправлений и дополнений - 2-3 раза в квартал. Возможность автообновления парсеров событий отсутствует. Вендор заверяет, что это сделано намеренно, поскольку автообновление в производственной среде может привести к изменению корреляционной логики. У многих заказчиков на корреляционную логику завязаны SLA, эскалации, документооборот - здесь важно, чтобы все изменения SIEM-системы проходили контролируемым образом. Кроме того, наличие подключения SIEM-системы к сети Интернет создает определенные риски. Для подключения нестандартных источников могут применяться часто используемые транспорты. Механизм разработки коннекторов, реализованный в ArcSight, является одним из самых мощных и гибких. Он позволяет не только разложить событие по определённым полям, но и с помощью множества встроенных функций изменять эти значения, а также реализовывать логические операции, основываясь на значениях определённых токенов. Коннектор представляет собой текстовый файл определённого формата, для описания событий используется regex. Для разработки также существует несколько графических утилит. Схема нормализации имеет более 200 полей. События хорошо нормализуются. Присутствует возможность гибкой настройки параметров агрегации. Поддерживается маскирование данных. Мониторинг NetFlow до 7-го уровня модели OSI осуществляется путем интеграции HP ArcSight и HP Tipping Point. Включение передачи событий из Tipping Point в ArcSight поддерживается решением по умолчанию и осуществляется одним действием в интерфейсе управления.

RSA Security Analytics. Поддерживается большое количество разнородных систем. Более 250 поддерживаемых стандартных источников событий. Для парсинга в платформу заложена многоуровневая модель обработки события. Есть проблемы с опознанием систем по событиям. При разборе событий возникают проблемы с кириллицей. Нет регулярности в выходе обновлений коннекторов/парсеров. Обновления выходят в зависимости от популярности подключаемого нестандартного источника. Поддерживается автообновление парсеров событий. Для разработки коннекторов используется модуль прошлого SIEM от RSA - enVision. Парсер представляет собой текстовый файл XML-формата. Как приемник RSA enVision, RSA SA использует многие его парсеры. Платформой поддерживаются следующие виды транспортов: AWS, Checkpoint, File Collection, Netflow Collection, ODBC, SDEE, SNMP, VMware, Windows, Legacy Windows и NetApp. Присутствует автообнаружение источников событий. Поддерживаются нормализация, агрегация и фильтрация событий. Для контроля целостности данных требуется использование дополнительного модуля Archiver. Работа по raw-событиям гораздо медленнее по сравнению с конкурентами. Возможность хранения данных в течение разного периода времени, их разделения на физическом и логическом уровне также требует использования дополнительного модуля Archiver. Отсутствует маскирование данных. Мониторинг сетевого трафика вплоть до 7-го уровня модели OSI осуществляется с помощью модуля Packet Decoder.

McAfee ESM. Решение поддерживает большое количество разнородных источников событий (более 400 систем: WMI, Syslog, SCP, FTP, HTTP(S), ODBC/MSSQL, OPsec, CEF, MEF). Обработка событий выполняется корректно. Но отсутствует механизм траблшутинга парсинга событий. Например, для аудита СУБД очень сложно разобраться, почему может не осуществляться парсинг событий. Обновления коннекторов выходят регулярно и доступны сразу для всего модельного ряда. Поддерживается автообнаружение источников событий. Поддерживается создание собственных парсеров событий. Разработка происходит в основном интерфейсе продукта, для описания событий используется regex. Процесс нормализации приводит все события в формат MEF (McAfee Event Format). Осуществляется категоризация событий. Агрегация присутствует. Есть ограничения по агрегации - максимум 3 значения, по которым можно ее выполнить. Параметры агрегации можно переопределить. Разбор сетевого трафика на уровне приложений осуществляется путем интеграции с решением IPS от McAfee.

PT MaxPatrol SIEM. Количество поддерживаемых источников постоянно растет. Известные поддерживаемые источники - Syslog, Windows Event Log, Windows File log, Windows WMI log, NetFlow, ODBC Log, Checkpoint LEA, SNMP Traps, SSH File Log, Telnet File Log. Max Patrol SIEM - новый продукт на рынке SIEM, он не дотягивает до гигантов индустрии по количеству поддерживаемых систем, но очень динамично развивается. Российские корни вендора могут дать продукту поддержку отечественных источников событий, отсутствующих во всех его западных конкурентах. Для разработки правил нормализации используется SDK, собственный язык программирования позволяет гибко нормализовать практически любое событие. Автообнаружение источников событий в системе присутствует, база источников периодически пополняется. Присутствуют механизмы нормализации, агрегации и фильтрации событий. Нормализация производится только для определённых типов событий. Поддерживается возможность сбора, хранения и работы по raw-событиям. Отсутствует маскирование данных при сборе/отображении в консоли. Платформой поддерживается мониторинг сетевого трафика вплоть до 7-го уровня модели OSI при помощи дополнительного модуля MaxPatrol X Network Traffic.

2.3.3 Анализ данных

Результат анализа по критерию - Анализ данных - представлен на рисунке 2.4.

Рисунок 2.4 - Результат анализа критерия Анализ данных

IBM QRadar. Реализованы механизмы real-time корреляции событий, есть возможность провести поведенческий анализ, осуществляется обогащение данных из других систем, поддерживается корреляция исторических данных.

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

RSA Security Analytics. В ядре системы заложен достаточно слабый корреляционный функционал, для полноценной корреляции возможно использование дополнительного модуля ESA. Функционал исторической корреляции в платформе отсутствует.

McAfee ESM. Реализованы механизмы real-time корреляции событий. При проведении поведенческого анализа есть возможность просмотреть два наложенных графика - статистику по событиям за предыдущий период и текущую статистику (онлайн). Для работы с историческими данными необходимо использовать компонент McAfee Advanced Correlation Engine (ACE). Этот модуль может выполнять и историческую корреляцию, но в один момент времени он может работать только в одном из режимов (real-time или исторической корреляции).

PT MaxPatrol SIEM. Реализованы механизмы real-time корреляции событий. Отсутствуют механизмы для проведения поведенческого анализа. Поддерживается обогащение данных в пределах платформы MaxPatrol X. Проведение корреляции исторических данных планируется реализовать в следующих релизах.

2.3.4 Настройки системы и внутренний аудит

Результат анализа по критерию - Настройки системы и внутренний аудит - представлен на рисунке 2.5.

Рисунок 2.5 - Результат анализа критерия Настройки системы и внутренний аудит

IBM QRadar. Поддерживается аутентификация пользователей в различных LDAP. Существует встроенный функционал Workflow. Поддерживается интеграция со сторонними Workflow-системами (ограниченная по поддерживаемым операциям). Встроено большое количество предустановленных корреляционных ресурсов, отчётов и графических панелей.

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

RSA Security Analytics. Поддерживается аутентификация пользователей в различных LDAP. Существует встроенный функционал Workflow, поддерживается интеграция со сторонними системами. Встроено большое количество предустановленных корреляционных ресурсов, отчётов и графических панелей.

McAfee ESM. Поддерживается аутентификация пользователей в различных LDAP. Осуществляется интеграция с Remedy на уровне подключения по API; любая внешняя система уровня Service Desk интегрируется на уровне шаблонных сообщений SMTP для автоматического заведения инцидентов. Встроено большое количество предустановленных корреляционных ресурсов, отчётов и графических панелей.

PT MaxPatrol SIEM. Отсутствует интеграция с LDAP и AD для обеспечения аутентификации, но данный функционал вендор обещает реализовать в 12-м релизе своей платформы. Для разграничения доступа между пользователями доступна ролевая модель. Присутствуют встроенные корреляционные правила, графические панели и отчёты. Реализован базовый функционал управления инцидентами.

2.3.5 Отказоустойчивость

Результат анализа по критерию - Отказоустойчивость - представлен на рисунке 2.6.

Рисунок 2.6 - Результат анализа критерия Отказоустойчивость

IBM QRadar. Ограничением по количеству обрабатываемых событий в секунду является порог в 1 200 000 (максимальная инсталляция, по информации от вендора). Есть возможность реализации конфигурации High Availability. Осуществляется резервирование всех компонентов системы, вплоть до ядра. Сжатие данных при хранении происходит в соотношении 1 к 10. Для хранения событий используются Ariel.

HP ArcSight. Ограничением по количеству обрабатываемых событий в секунду является порог в 1 500 000 (максимальная инсталляция, по информации от вендора). Есть возможность реализации конфигурации High Availability. Осуществляется резервирование всех компонентов системы, вплоть до ядра. Сжатие данных при хранении происходит в соотношении 1 к 10. Для хранения событий используются CORR-Engine.

RSA Security Analytics. Ограничением по количеству обрабатываемых событий в секунду является порог в 20 000 (максимальная инсталляция, по информации от вендора). Есть возможность реализации конфигурации High Availability. Осуществляется резервирование всех компонентов системы, вплоть до ядра. Сжатие данных при хранении происходит в соотношении 1 к 10. Для хранения событий используется RAW/Meta и в случае с Warehouse - Hadoop.

McAfee ESM. Ограничением по количеству обрабатываемых событий в секунду является порог в 300 000 (максимальная инсталляция, по информации от вендора). Возможность увеличения мощности ядра и компонентов системы доступна для виртуальных комплексов. В случае ПАК требуется приобретение новой платформы. Есть возможность реализации конфигурации High Availability. Осуществляется резервирование всех компонентов системы, вплоть до ядра. Для хранения событий используется собственная внутренняя база данных.

PT MaxPatrol SIEM. Ограничением по количеству обрабатываемых событий в секунду является порог в 30 000 (максимальная инсталляция, по информации от вендора). Отсутствует возможность резервирования компонентов системы и реализации отказоустойчивой конфигурации. Хранение событий осуществляется в исходном и нормализованном виде. Осуществляется сжатие данных до 30%. Для хранения событий используется MongoDB. Существует возможность интеграции с внешними массивами для хранения архивных данных.

2.3.6 Сертификаты регуляторов

Все рассматриваемые SIEM-системы на текущий момент имеют Сертификат ФСТЭК России по защите конфиденциальной информации, включая ИСПДн.

2.3.7 Удобство использования

Результат анализа по критерию - Удобство использования - представлен на рисунке 2.7.



Рисунок 2.7 - Результат анализа критерия Удобство использования

IBM QRadar. По умолчанию доступны 9 типов графического представления. Существуют некоторые ограничения в кастомизации графических панелей. Интерфейс русифицирован. Отчеты могут быть экспортированы в файлы следующих форматов: MS Excel, RTF, PDF, XML, HTML.

HP ArcSight. Доступны более 20 типов графического представления. В качестве полей графического представления используются Data Monitor, Dashboard, Query Viewer. Русифицированный интерфейс решения доступен с февраля 2015 года. Отчеты могут быть экспортированы в следующие форматы: MS Excel, RTF, PDF, CSV, HTML.

RSA Security Analytics. Доступны более 5 типов графического представления. В качестве полей графического представления используются Dashboard, System Stats. Русский интерфейс отсутствует. Отчеты могут быть экспортированы в следующие форматы: MS Excel, RTF, PDF, CSV, HTML.

McAfee ESM. Доступны следующие типы графического представления: табличное, pie chart, bar chart, графики, граф коммуникаций на основе анализа NetFlow. Русский интерфейс отсутствует. Отчеты могут быть экспортированы в следующие форматы: PDF, CSV, HTML. Присутствует возможность запуска отчетов за большие промежутки времени.

PT MaxPatrol SIEM. Доступны гистограммы и графики, а также таблицы и отчеты. Интерфейс русифицирован. Есть встроенные отчеты, формат, поля, промежутки времени, но для их кастомизации необходимо использовать SDK.