Эльман Бейбутов, руководитель направления безопасности БД и SOC Центра информационной безопасности, компания «Инфосистемы Джет»
Говорят: создать SOC сложно. Однако давайте разберемся, какие проблемы возникают при построении SOC и какие пути их решения существуют. Любая крупная компания, внедряющая по две-три актуальных системы ИБ ежегодно, сталкивается с необходимостью автоматизированного разбора сотен миллионов событий в день. Наиболее крупные из них уже сейчас строят и масштабируют свои SIEM, выделяют специалистов, разрабатывают регулирующие документы. И у них, как у настоящих оптимистов, стакан SOC’а наполовину полон.
Основа SOC: технологии, люди, процессы
Три кита, на которых держится SOC, − SIEM (технологическая платформа), персонал и процессы. Выбор SIEM − зачастую самый простой и достижимый результат. На нашем рынке представлены пять производителей, чьи системы можно взять на тестирование, разобраться в тонкостях интерфейсов, отличиях подходов к разработке правил корреляции и управления инцидентами. При этом стоит учесть понимание каждым производителем концепции Next Generation SIEM – лакмусовой бумажки, отображающей зрелость идей и технологий. По подходу к управлению инцидентами решения условно можно разделить на три группы:
- готовые реализовать любую прикладную задачу ИБ и имеющие для этого продуманный интерфейс, оптимизированные алгоритмы и логику;
- базирующиеся на собственном высокопроизводительном оборудовании и «перемалывающие» огромные потоки событий в секунду. Это упрощает задачу фильтрации данных, но может «замусорить» систему и «замылить» взгляд безопасника. Таким решениям свойственны простота интерфейса и меньшая гибкость функционала по разработке правил корреляции при закрытии 80% повседневных задач с 20%-ным усилием;
- предлагающие наборы продуктов (например, сам SIEM, сканер уязвимостей, компоненты для анализа трафика до седьмого уровня OSI и расследования инцидентов), объединенные одной веб-консолью, существенно расширяющие понятие SIEM и позволяющие сэкономить на совокупной стоимости владения ими.
Второй «кит» – люди. SIEM – инструмент в руках аналитика, позволяющий анализировать поступающие события ИБ, составлять корреляционные правила и разбирать критичные инциденты. Система не заменит опыта экспертной команды и не выдаст сообщение в формате: «инцидент Y был обнаружен по связке событий N, что привело к реализации рисков R компании. Во всем виновата группа лиц G, находящаяся по адресу B». И если набрать грамотных специалистов, обучить их работе с SIEM-системой возможно, то удержать и мотивировать их на развитие SOC – по силам далеко не каждой организации. Именно по этой причине ряд компаний, выбрав аутсорсинговую модель развития собственных SOC, уже подключились к Jet Security Operations Center (JSOC), запущенному компанией «Инфосистемы Джет» полтора года назад. При этом не играет роли наличие или отсутствие собственного SIEM – подключение к JSOC возможно в любом случае.
Третье звено SOC − ключевые процессы управления инцидентами, с которыми сталкиваются все компании, строящие SOC, – выбор источников событий и создание правил корреляции. Устоялись два подхода к выбору источников: «снизу вверх» и «сверху вниз». Например, компания А решила подключить все источники к системе мониторинга, дабы не упустить ни одного инцидента и иметь максимальную доказательную базу при их расследовании. Подход «снизу вверх» при этом позволит охватить всю ИТ-инфраструктуру и настроить детектирование практически всех возможных инцидентов. Однако для компании с 25 тыс. рабочих станций, 1,5 тыс. единиц серверного и 1 тыс. сетевого оборудования бюджет проекта может превысить 80 млн руб. Добавьте к этому ежегодные затраты на сопровождение, и станет ясно, что такой проект по силам очень небольшому числу компаний.
Представим себе компанию Б, цель которой − соответствие требованиям PCI DSS. Здесь границы проекта существенно ỳже (100 рабочих станций, 35 серверов и 30 единиц сетевого оборудования), и компания потратит на управление инцидентами гораздо меньшую сумму, сэкономив на SIEM и его внедрении. Но при подходе «сверху вниз» многие системы безопасности, не участвующие непосредственно в защите процессинга, могут оказаться вне границ проекта. Равно как и большая часть серверной и сетевой инфраструктуры, не обрабатывающая данные платежных карт. Но без этих компонентов далеко не все угрозы можно будет обнаружить и своевременно о них уведомить специалистов ИБ.
Выходит, что ни один из распространенных подходов не гарантирует создания качественного SOC. И компания, потратив на SIEM и персонал от шести и более миллионов рублей, может не ощутить развития темы управления инцидентами ИБ.
В международной практике есть модель пятибалльной оценки уровня зрелости SOC по четырем параметрам: бизнес, персонал, процессы и технологии. Уровень зрелости 5 (экстремальный) говорит о слишком бюрократизированном и документированном подходе к управлению, поэтому компании могут придерживаться уровней 3 и 4. Основанный на этой модели аналитический отчет HP Security Intelligence and Operations Consulting (по данным 69 компаний 13 стран) демонстрирует низкий уровень зрелости SOC. Максимальные оценки − 1,83 и 2,02 − получили компании финансового и потребительского секторов экономики соответственно. Таким образом, 24% проанализированных SOC в мире не дотягивают до уровня 1 и только 30% − соответствуют базовому (2) уровню. Собственная статистика компании «Инфосистемы Джет» показывает, что на российском рынке по зрелости SOC лидируют телеком-операторы (2,2 балла) и финансовые организации (2,0 балла). Почти в каждом проанализированном случае эксперты отметили недостаточную проработанность процессов управления инцидентами ИБ, что подтверждает мнение о том, что передовые технологии и люди еще не являются залогом успеха создания SOC.
«Мой бар» для полезного SOC
Решая проблему выбора источников событий ИБ и создания правил корреляции, эксперты компании «Инфосистемы Джет» сформировали и апробировали в проектах собственный подход. Возьмем, к примеру, типовую инфраструктуру банка, включающую межсетевые экраны, антивирусные средства, системы обнаружения вторжений, VPN-шлюзы, а также полный набор ИТ-сервисов (службу каталогов, почту, среду виртуализации и др.). ИБ-специалисты банка знают о ряде сценариев проникновения и доступа к корпоративным ресурсам, которые бы хотелось отслеживать и регистрировать. Понятно, что сценарии атак можно обнаружить по определенным типам событий, инициатор которых − злоумышленник, преодолевающий очередной рубеж защиты. Это напоминает приложение «Мой бар», где программа предлагает отметить имеющиеся ингредиенты и на их основе выдает список коктейлей с рецептами. Или, наоборот, можно выбрать «коктейль», а программа сообщит, каких «ингредиентов» не хватает.
Во-первых, такой подход позволяет понять, какие «коктейли» можно смешать при наличии таких «ингредиентов», как межсетевой экран, антивирус, служба каталогов и файловый сервер. Во-вторых, какие «ингредиенты» нужно собрать для «коктейля» по отслеживанию доступа к внутренним ресурсам из Интернета. Однако остается задача актуализации базы сценариев атак («книги рецептов»). Мало кто из специалистов ИБ по памяти назовет десяток «рецептов» детектирования конкретных сценариев реализации угроз. При этом их небольшое количество не удовлетворит всех потребностей службы ИБ, а слишком сложные «коктейли» могут так никогда и не проявиться. Для поддержания своей «книги рецептов» в актуальном состоянии мы в первую очередь учитываем опыт реализованных проектов, в которых решались задачи по детектированию конкретных атак, и обогащаем его лучшими практиками производителей SIEM-решений (в их базовых правилах встречаются интересные примеры). Также нельзя забывать о требованиях международных стандартов. И дополняют этот набор сценарии взлома систем, которые генерируют наши собственные эксперты при проведении тестов на проникновение. В результате компания «Инфосистемы Джет» имеет сформированный каталог сценариев, структурированный по типам атак: НСД, взлом учетной записи пользователя, вирусное заражение, сетевые аномалии и т. д. Каждый раздел уже содержит десятки «рецептов», характеризующихся необходимыми типами событий ИБ и примерами источников.
Выбор актуальных сценариев атак и подключение соответствующих источников событий ИБ – ключевая задача при построении эффективного SOC, путь к оптимизации соотношения цена/качество всего проекта. При этом настройка правил корреляции под дополнительные сценарии может потребовать внедрения новых систем ИБ, а управление выявленными инцидентами − наборов регламентов и инструкций. Создание SOC – это процесс, описанный подход − его отправная точка. Не стоит забывать, что на каждом этапе можно принять решение о подключении к облачному сервису − JSOC − и доверить управление инцидентами опытной команде.
