Система корреляции событий безопасности в рамках концепции soc: роль и место, практические рекомендации при реализации проектов Текст научной статьи по специальности «Электротехника, электронная техника, информационные технологии»

Система корреляции событий безопасности в рамках концепции SOC:

роль и место, практические рекомендации при реализации проектов

Андрей Бедрань,

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

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

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

Адекватным ответом на современные угрозы безопасности корпоративных информационных систем является построение центра мониторинга и управления информационной безопасностью — Security Operation Center (SOC).

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

• мониторинг и корреляцию событий безопасности;

• контроль защищенности;

• контроль изменений;

• управление обновлениями;

• визуализацию данных;

• предоставление отчетности;

• управление;

• контроль соответствия нормам регулирования;

• хранение данных.

Как показала практика реализации проектов по построению Центров управления безопасностью, основная функциональная нагрузка приходится на системы мониторинга и корреляции инцидентов безопасности в информационной системе заказчика. Причины данного обстоятельства объяснить довольно просто — комплекс мониторинга и корреляции инцидентов безопасности является некой сенсорной системой SOC. Данный класс решений призван в режиме реального времени собрать и обработать журналы аудита с механизмов безопасности критичных узлов ИС, а также с источников данных инфраструктурных и прикладных сетевых систем, способных "прояснить" ситуацию с конкретным инцидентом безопасности.

На рис.1 представлена общая схема организации центров управления безопасностью — Security Operation Center (SOC).

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

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

Отметим основные задачи, которые решают заказчики, по мере внедрения данного класса систем:

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

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

• принятие решений по противодействию обнаруженным угрозам и их величине возможных рисков;

• архивирование анализируемой информации с возможностью полнотекстового поиска по архиву;

• проверка корпоративной сети на соответствие требованиям стандартов и политики безопасности;

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

Основной функционал современных систем мониторинга и корреляции инцидентов безопасности:

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

• осуществление корреляции собранных данных;

• реализация отчетности и оповещения об инцидентах безопасности;

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

• осуществление ретроспективного анализа инцидентов безопасности;

• интеграция с системами класса Help Desk.

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

• Compliance management: контроль степени соответствия положениям отечественных и международных стандартов;

• предотвращение распространения атаки: модули класса Threat Response;

• предотвращение действий инсайдеров: модули класса Insider Threat Package;

• защита от мошенничества: модули класса Fraud Management.

Проблема выбора конкретного решения

Этап выбора продукта для последующей реализации проекта у каждого заказ-

Рис. 1. Общая архитектура систем класса БОС

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

• количество успешных внедрений подобных решений в РФ;

• наличие компетенции по данному решению как у исполнителя, так и у представителя производителя в РФ;

• стоимость внедрения системы и ее последующего сопровождения;

• сроки реализации проекта;

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

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

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

кающих на этапе реализации данных проектов далее и пойдет речь.

Задачи пилотного проекта

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

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

• работоспособности решения в части требуемого заявленного функционала;

• возможности функциональных компонент решения;

• количественных характеристик на базе работоспособной системы;

• степени удобства использования данного решения в части выполнения производственных задач;

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

• степени адекватности и приемлемости лицензионной политики решения;

• возможности подключения требуемого количества разнородных источников данных;

• методики категоризации источников данных по степени критичности;

• сравнительного анализа протестированных решений.

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

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

который в настоящий момент применяется в компании.

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

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

• объем нормализованной базы данных, собранных журналов аудита;

• общий объем ненормализованной, т.е. содержащий лог-данные в исходном виде, базы данных журналов аудита;

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

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

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

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

На практике, использование системы

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

• источникам событий/атаки;

• типам атаки;

• типам журналов аудита;

• типам объектов, согласно принятой оргструктуре организации (например, делать запрос событий высокой степени критичности в конкретном филиале);

• результатам деятельности той или иной роли;

• конкретному временному интервалу;

• работе конкретной точки агрегации трафика.

Возможности графического интерфейса приведены на рис. 2. В данном случае в качестве примера выступает централизованная система управления решения ArcSight.

Оценка возможности и необходимости интеграции решения с другими прикладными системами, как правило, производится в отношении систем класса Help Desk. Дан-

Рис. 2. Возможности графического интерфейса системы ArcSight

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

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

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

Стадии реализации успешного пилотного проекта

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

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

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

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

• определение исполнителей (партнеры, рабочая группа);

• подбор аппаратной платформы для формирования стенда. Если решение поставляется только в аппаратном виде (например, решения компаний Cisco Systems и RSA/EMS enVision), то нужно запросить у исполнителя на тестирование конкретные модели функциональных компонент;

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

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

• определение сроков и составление календарного плана работ. Практика показала, что на реализацию пилота требуется не меньше месяца;

• поставка программно-аппаратных средств стенда. Как правило, это серверное оборудование и ПО решения;

• тестирование решения. На данном этапе рекомендуется активно привлекать к выполнению намеченных задач Исполнителя, а в ряде случаев и производителя решения;

• разработка отчета по результатам тестирования;

• доклад о результатах тестирования руководству профильных подразделений.

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

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

• выбор продуктов для тестирования. При выборе продуктов следует ориентироваться на производителей лидирующих решений мирового и отечественного рынка систем корреляции — ArcSight, Symantec, Cisco Systems;

• выбор исполнителя для тестирования. Исполнитель обязан обладать успешным опытом внедрения подобных проектов, ресурсом для оказания помощи в реализации пилота, а также необходимыми компетенциями;

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

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

• формирование списка тестируемых модулей. Не стоит ставить задачу тестирования всех модулей. Как правило, тестированию подвергаются модули корреляции данных и Compliance-модуль (например, на соответствие требованиям стандарта Payment Card Industry Data Security Standard (PCI DSS));

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

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

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

Опыт реализации проекта у одного из крупнейших банков РФ доказал вышеизложенное. При расчете теоретической мощности заказчик планировал внедрять систему производительностью 40 000 событий в секунду. После реализации пилота расчетная мощность была снижена до 28 500 событий в секунду при количестве источников данных — 500 ед. Данное обстоятельство существенно отразилось на конечной стоимости решения.