Solar JSOC – опыт построения коммерческого SOC

    Эта статья открывает цикл публикаций, посвященных функционированию центра по мониторингу и реагированию на инциденты информационной безопасности – Security Operations Center (SOC). В них мы будем рассказывать о том, что надо учитывать при создании SOC, о процессе подготовки инженеров мониторинга, регистрации инцидентов и практических кейсах, с которыми сталкивается Solar JSOC.

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

    Зачем нужен SOC


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

    В качестве вводной информации стоит упомянуть статистику по данным исследований, проведенных ФРИИ, а также компаниями Group-IB и Microsoft:

    • Потери экономики РФ от киберпреступности за 2015 год оцениваются в 123,5 млрд рублей.
    • 60% российских компаний отметили рост числа киберинцидентов на 75%, а размера ущерба — в два раза.

    Также хотелось бы упомянуть статистику по нашим клиентам, которая отражается в ежеквартальных отчетах JSOC Security Flash Report:

    • Двукратный рост количества инцидентов информационной безопасности в первом квартале 2016 года по отношению к аналогичному периоду 2015 года.
    • Значительный рост инцидентов, связанных с утечками конфиденциальной информации.
    • Увеличение критичных инцидентов с 26% до 32% по отношению к общему скоупу.
    • Рост числа различных кибергруппировок, работающих по известным схемам мошенничества.


    Если же вспомнить последние публичные инциденты – «Металлинвестбанк», «Русский международный банк», вывод денег через уязвимости SWIFT и атака на энергоотрасль Украины, абсолютно логичной и понятной становится идея о том, что за безопасностью необходимо следить, а инциденты ИБ − выявлять и анализировать.

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

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

    Немного методологии


    Согласно модели, предложенной HP SIOC, существует несколько уровней зрелости SOC − SOMM (Security Operations Maturity Model):


    Рис. 1. Уровни SOMM

    К сожалению, большинство компаний как в России, так и в мире, сделав первый шаг на пути к построению собственного Security Operations Center, на нем и останавливается. По оценкам HP, 24% SOC в мире не дотягивают до 1 уровня, и только 30% SOC соответствуют базовому (2) уровню. Статистика распределения уровней SOMM в зависимости от сферы бизнеса компаний, собранная в 13 странах мира (включая Канаду, США, Китай, Великобританию, Германию, ЮАР и др.) такова:


    Рис. 2. Распределение уровней SOMM по сферам бизнеса

    Проблематика собственного SOC


    Наиболее проторенный в России путь – приобрести SIEM-систему для мониторинга инцидентов. По этому пути прошли практически все крупные российские компании. При этом говорить об успешном запуске центра мониторинга и реагирования инцидентов возможно, в лучшем случае, в 5-10%. Что же мешает? Основные сложности при построении собственного SOC наблюдаются в трех направлениях:

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

    • Невозможность построения эффективного процесса мониторинга с внутренними SLA. Помимо необходимости выделения персонала, запуск SOC подразумевает создание в подразделении IT-security полноценной дежурной смены, работающей в режиме 12/5 или 24/7, а это от 2 до 5 новых штатных единиц. При этом выделение персонала напрямую связано с необходимостью постоянного контроля кадровой текучки (крайне редко ИБ-специалисты готовы работать в ночной смене), выстраивания процессов и внутреннего контроля качества выполняемых работ.

    • Развитие SOC должно осуществляться на постоянной основе: разработка новых сценариев под векторы угроз, подключение новых источников информации, агрегация и использование репутационных баз. Статический SOC совершенно неэффективен, а для динамического развития нужен аналитик. Наличие в штате человека, являющегося архитектором SOC в режиме full time, – большая роскошь даже для крупной компании.

    Оценка существующей на рынке потребности в создании SOC'ов вкупе с описанными выше нюансами привели нас сначала к идее, а потом и к фактическому построению собственного коммерческого SOC.

    Выбор платформы


    Одним из главных вопросов на этапе строительства Security Operations Center для нас был выбор SIEM-системы. Мы сформировали ряд требований к ней:

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

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

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

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

    • SIEM-система должна позволять кастомизировать внутренние ресурсы под меняющиеся задачи SOC. В частности, создание внутреннего профиля мониторинга источников (System Health), использование на различных этапах работы с фиксируемыми инцидентами внешних скриптов, ведение и кастомизация своего инцидент-менеджмента и т. д.

    Свой выбор мы остановили на одном из лидеров в классе SIEM – HP ArcSight и, несмотря на различные сложности в жизни системы, о своем решении ни разу не пожалели.

    Компоненты SOC


    Вслед за сервисом по мониторингу инцидентов Solar JSOC дополнялся новыми сервисами:

    • WAF as a service;
    • Anti-DDoS;
    • Vulnerability Assessment, где в качестве основного решения мы выбрали Qualys за счет богатого функционала и удобного интерфейса, в том числе для написания сигнатур;
    • Сканер программного кода на наличие уязвимостей и НДВ Solar inCode.

    Технологически Solar JSOC − уже давно не только HP ArcSight. SIEM'овское ядро постепенно обрастало различными полезными аддонами и фичами. Были добавлены средство мониторинга трафика и решение класса Security Intelligence Solar inView, которое является:

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

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

    Важным инструментом в рамках задач по мониторингу и выявлению инцидентов являются репутационные базы различных отечественных и зарубежных вендоров и CERT. Базы могут содержать как сетевые, так и хостовые индикаторы компрометации (IOC) различных вредоносов, либо описывать схему работы злоумышленников. В зависимости от поставляемых данных, мы используем различные инструменты выявления индикаторов: сетевые заносятся в ArcSight для ретроспективного поиска и контроля в будущем, хостовые превращаются в индикаторы сканеров защищенности. Самыми значимыми партнерами в этой области являются FinCERT и Kaspersky Lab.

    Интеграция с репутационными базами Kaspersky Threat Intelligence осуществляется через API, разработанный совместно с Kaspersky Lab. Благодаря этому мы получаем наиболее актуальную информацию – база «фидов» обновляется раз в несколько часов, что сопоставимо со скоростью получения новых антивирусных сигнатур (иногда быстрее). Это позволяет оперативно выявлять zero-day вирусы, попадающие в инфраструктуру заказчиков за счет их callback'ов.

    Интересным форматом предоставляемой информации являются APT Reports, в которых вендором или CERT'ом описывается хронология атаки, инструментарий, сопутствующее использование уязвимостей и, конечно, цель злоумышленников. Данный формат позволяет нам по-новому взглянуть на точки контроля и детектирования инцидентов, подкрутить существующие или создать новые корреляционные правила.

    Используя указанный выше инструментарий, мы сформировали следующие направления оказания сервисов ИБ:

    • Защита внешних веб-ресурсов компании – здесь в первую очередь мы предоставляем сервис по проактивной эксплуатации WAF и Anti-DDoS решений;
    • Комплексное обеспечение безопасности бизнес-приложений – мониторинг инцидентов + анализ исходного кода;
    • Инфраструктурный мониторинг инцидентов ИБ;
    • Комплектный контроль защищенности и compliance control;
    • Выявление направленных атак и zero-day вредоносов – комплектный подход, включающий в себя регулярные сканирования инфраструктуры с помощью сканера защищенности + мониторинг инцидентов + использование целевых фидов + разбор и анализ экземпляров вредоносного ПО;
    • Эксплуатация интеллектуальных СЗИ – DAM, Sandbox, NGFW, анализаторы трафика.

    Архитектура



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

    При этом принципиальным оставался вопрос географии: collocation возможен только в границах РФ, что исключало возможность использования популярных западных провайдеров. Сюда же наложились естественные вопросы обеспечения ИБ инфраструктуры на всех уровнях доступа. Поэтому было решено обратиться к нашему партнеру Jet Infosystems, и в рамках большого колокейшена для JSOC было выделено несколько стоек в физически изолированном от других серверов фрагменте, где мы смогли развернуть свою архитектуру, одновременно ужесточив уже существующие в рамках ВЦОД профили безопасности. ИТ-инфраструктура развернута в Tier 3 дата-центре, и ее показатели доступности составляют 99,8%. В результате мы смогли выйти на целевые показатели доступности нашего сервиса и получили существенную свободу действий в работе и адаптации системы под себя.

    Команда


    На начальном этапе команда JSOC состояла из 3 человек: двух инженеров мониторинга, закрывающих временной интервал с 8 до 22 часов, и одного аналитика/администратора, который занимался развитием правил. SLA по услуге, обозначенный клиентам, тоже был достаточно мягким: время реакции на обнаруженный инцидент – до 30 минут, время на разбор, подготовку аналитической справки и информирование клиента – до 2 часов. Но, по прошествии первых месяцев работы, мы сделали несколько очень существенных выводов:

    • Смена мониторинга должна обязательно работать в режиме 24*7. Несмотря на то, что объем инцидентов в вечерние и ночные часы снижается, самые важные и критичные события (старт DDoS-атак, завершающие фазы медленных атак на проникновение через внешний периметр, злонамеренные действия контрагентов и т. п.) происходят именно в ночное время, и к моменту старта утренней смены уже теряют свою актуальность.

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

    • Для обеспечения требуемого времени разбора под каждый инцидент должен быть подготовлен полноценный инструментарий для расследования внутри ArcSight: active channels с отфильтрованными целевыми событиями для разбора, trends, dashboards, демонстрирующие статистические изменения в подозрительных активностях, и целевые аналитические отчеты, позволяющие быстро анализировать активности и принимать оперативные решения, active/session lists для оперативного доступа к информации о хостах, пользователях и пр.

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

    Эти выводы существенно повлияли на структуру департамента JSOC в компании Solar Security и помогли сформировать трехуровневую модель реагирования на инциденты. Сейчас подразделение насчитывает уже более 40 человек, имеет сформировавшуюся структуру (см. рис. 4) и включает в себя:

    • Две дежурные смены, которые работают 24*7: одна занимается мониторингом и разбором инцидентов, другая – администрированием системы.
    • Персональных аналитиков и сервис-менеджеров под клиентов JSOC. По опыту, один аналитик способен вести 3-4 компании.
    • Выделенную команду развития, которая позволяет нам сохранять актуальность услуги и профиля мониторинга угроз.


    Рис. 4 – Организационная структура JSOC

    Такая организационная структура позволила нам выйти на целевые показатели SLA:


    Итоги


    За последние 4 года развития наш Security Operations Center прошел следующие важные этапы:

    2012 год

    • зарождение идеи облачного SOC.

    2013 год

    • формирование команды JSOC, состоящей из 2 инженеров мониторинга в режиме 12/5, одного аналитика и руководителя направления;
    • 1 заказчик и 3 пилотных проекта;
    • SLA: реакция на инцидент – 30 минут, анализ – 2 часа.

    2014 год

    • формирование двух площадок: Москва и Нижний Новгород;
    • первая линия мониторинга и эксплуатации 24/7;
    • выполнение SLA – 98,5%;
    • 10 заказчиков.

    2015 год

    • штат сотрудников достиг 30 человек;
    • значительный рост числа заказчиков – 20+, 4 публичных проекта
    • выполнение SLA – 99,2%

    На этом первая, вводная статья из серии подошла к концу. В ближайших планах – материалы о технических аспектах работы Solar JSOC:

    • Доступность SOC: показатели, измерение.
    • Solar JSOC: Регистрация инцидентов. Как и почему стоит жить во внешней тикет-системе.
    • Solar JSOC: ПРАВИЛьная кухня и др.
    • и др.

    Оставайтесь с нами!
    Ростелеком-Solar 166,06
    Безопасность по имени Солнце
    Поделиться публикацией
    Похожие публикации
    Комментарии 11
      0
      На сколько я понял из картинки, вы собираете логи с помощью Zabbix? Каким образом потом логи передаются на ArcSight?
        0
        Добрый день. Zabbix используется для мониторинга доступности самой инфраструктуры JSOC: серверов, прикладного ПО, сетевого оборудования и т.д. Сбор событий безопасности с систем клиентов и выявление инцидентов делается посредством HPE ArcSight.
        0
        WAF as a service

        Вы сотрудничаете с другими поставщиками таких услуг или сами устанавливаете и управляете WAFами? Если не секрет, что за WAF предпочитаете?

        Комплектный контроль защищенности

        Сканируете только периметр или еще и сканируете внутреннюю сеть организации? Если второе — то проводите выездные проверки, размещаете агент сканера, организуете разовый удаленный доступ или постоянно имеете удаленный доступ к сети организации?
          0
          WAF as a service

          Вы сотрудничаете с другими поставщиками таких услуг или сами устанавливаете и управляете WAFами? Если не секрет, что за WAF предпочитаете?

          Добрый день, собственного WAF`а у нас нет. В рамках оказания сервиса мы сотрудничаем как с некоторыми отечественными решениями (SolidWall, PT WAF), так и лидерами зарубежного рынка – Imperva, F5.
          Наша основная функция — проактивная эксплуатация. Мы берем на себя функции по управлению, профилированию, тюнингу политик, мониторингу и реагированию на атаки, и, конечно, контролируем работу самого WAF с точки зрения доступности и работоспособности.
          Благодаря партнерским соглашениям с вендорами у нас также есть возможность предоставлять WAF в аренду заказчику совместно с нашим сервисом.
          Комплектный контроль защищенности

          Сканируете только периметр или еще и сканируете внутреннюю сеть организации? Если второе — то проводите выездные проверки, размещаете агент сканера, организуете разовый удаленный доступ или постоянно имеете удаленный доступ к сети организации?

          В рамках сервиса мы осуществляем сканирование как периметра, так и внутренней инфраструктуры компании. В рамках сканирований, помимо стандартного vulnerability management и инвентаризации, мы проверяем конфигурации хостов с целью выявления индикаторов компрометации различными вредоносами (поиск IoC на хостах).
          С точки зрения доступа существует несколько вариантов:
          1. Если используется Qualys, управление virtual appliance осуществляется из облака самого Qualys. Заказчик может разделить функции по сканированию и дальнейшему анализу отчетов по нескольким учетных записям, поэтому инженер подключается для сканирования, а анализирует отчет аналитик.
          2. Если используется MaxPatrol, то, в зависимости от «закрытости» сегмента, есть возможность выезда инженера на площадку или подключения по VPN — одноразово или на постоянной основе в рамках site-to-site с нашим ЦОДом. Второй вариант используется при комплексном сервисе совместно с мониторингом инцидентов, когда необходимо оперативно подгружать информацию из сканера защищенности в SIEM-систему и запускать сканирования по факту срабатывания сетевых кусков репутационных баз наших партнеров (обращения к потенциально опасным хостам).
          В любом случае, при сканированиях всегда запускается процесс согласования с заказчиком (RFC), выбирается время, скоуп и тип сканирования в соответствии с критичностью сканируемой системы.
          0
          Пардон, оговорился:
          мы проверяем конфигурации хостов с целью выявления индикаторов компрометации различными вредоносами

          Конечно, имелась в виду проверка с целью выявления индикаторов компрометации различных вредоносов, а не различными вредоносами).
            0
            Спасибо за развернутый ответ.

            А как налаживаете процесс работы с администраторами организаций — теми, кто проверяет, что атака была успешной/неуспешной? Как вы учитываете время их реакции — оно каким-то образом связано с вашими показателями SLA? Как уменьшаете количество ложных срабатываний в подобных ситуациях:

            К примеру, нет WAF, фиксируется попытка заливки веб-шелла (СОВ), потом обращение к веб-шеллу для проверки успеха атаки (логи веб-сервера) и пусть код ответа 404. Но что, если скрипт шелла сам возвращает не 200-й код, а 404-й к каждому обращению к нему. Если реагировать только по логам и не проверять сервер на наличие шелла, то можно пропустить атаку. А уведомление об атаке = время на проверку.
              0
              Добрый день.

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

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

              Ложные срабатывания уменьшаются тем быстрее, чем лучше клиент знает свою инфраструктуру. Процесс, опять же, разнообразный:
              — По сильно флудящим инцидентам мы можем предоставлять сводную ежедневную (еженедельную) информацию, если у нас нет возможности фильтрации FP и заказчик не может предоставить критерии
              — По ситуациям, которую Вы описали — всегда включаем максимальный режим паранойи, тренируем первую линию с помощью case review, либо внезапными проверками по часто повторяющимся инцидентам

              В любом случае работа по инцидентам всегда совместная с заказчиком и, зачастую, именно он определяет, как и когда проверять, мы лишь можем посоветовать.
              0
              И еще вопрос: по заказчикам услуг. Кто они (госы, банки, больницы...)? И откуда они? Все из Москвы/Нижнего Новгорода? Или есть ли кто-то из регионов?
                0
                Заказчиков много, примерно 60% банки, остальные — совершенно различные сферы:
                Ритейл
                ТЭК
                Транспортные компании
                Медиа-компании

                Регионов представлено много и постоянный прирост. Из публичных заказчиков — СТС Медиа, S7 Airlines, Яндекс.Деньги, Почта Банк, МТС Банк, Уральский банк реконструкции и развития
                  0
                  1) Расскажите еще, пожалуйста, про то, как взаимодействуете с заказчиками: в плане какие действия/запросы/изменения/требования обязательно и жестко фиксируете на бумаге, а какие ведете в электронном виде. К примеру, согласование профилей легальной активности (http://www.securitylab.ru/analytics/473903.php), согласование способов информирования об атаках (те же перечни телефонов, почт), согласование ответственных лиц, возможно категории инцидентов, тот же перечень контролируемых хостов/сервисов на них.

                  Ограничиваетесь базовым договором, а все остальное — в электронной форме (через тикеты)?

                  2) А также вопрос: как понять параметр SLA «Время обнаружения инцидента (мин)». Когда начинается отсчет времени и каким событием он заканчивается?
                    0
                    Добрый день.

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

                    2) Обнаружение инцидента — это время в течение которого специалист первой линии обязан взять кейс в работу. В арксайте есть параметр manager receipt time — это время фактического прихода события в систему. Время прихода события в систему (либо время прихода последнего события в цепочке, в случае, например, брутфорсов) совпадает с временем генерации правила (если в явном виде не задана задержка), на основании которого и заводится инцидент. В ArcSight есть так же время Start и End time которые говорят о фактическом времени начала и конца события. При штатной работе системы разница между End Time и manager receipt time составляет 10 секунд — 2 минуты. А нештатные ситуации контролируются правилами.

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

                    Самое читаемое