Как выращивать SOC на корпоративной ферме
Леди и джентльмены!
Эта история о том, как группа из пяти инженеров-универсалов в течение года преобразовалась и выросла в полномасштабный Security Operations Center из трёх специализированных линий.
Когда-то мы и правда считали, что можем в 4–5 пар глаз отслеживать состояние всех критически важных сервисов и ситуативно автоматизировать самую унылую рутину, хорошо хоть вовремя опомнились.
А поведаю об этом я — инженер (по информационной безопасности, разумеется), умеренный любитель кардиганов худи и классической шотландской клетки и адепт консистентности. Меня зовут Максим, и в Ozon Tech я уже два года занимаюсь прикладными задачами SOC, без лишнего фанатизма формализую процессы команды и выращиваю эксплуатационную документацию.
Пора закупать парашюты
К моменту начала преобразования нашей группе не хватало собственного кодекса чести структурированности и чёткого разграничения сфер ответственности.
Обработка пользовательских обращений и автоматических уведомлений была размазана по сотрудникам всех внутренних групп, недостаточно формализована, идентичные запросы обрабатывались дежурными по-разному в зависимости от личного восприятия.
Распределение проектных задач происходило по принципу «каждый занимается тем, что интересно ему здесь и сейчас».
Дежурные борются за общий результат
Успех формирования подразделения определяется наличием у руководства стратегии развития, а в случае с SOC-ом нет права на ошибку, ведь эта команда образует первый рубеж и формирует восприятие всей структуры ИБ.
Классическая модель SOC подразумевает наличие трёх функционально разграниченных линий:
1 линия — оперативное реагирование по хорошо известным событиям;
2 линия — разбор сложных кейсов, глубокий анализ, приведение событий к состоянию, доступному для разбора 1-й линией;
3 линия — проактивный поиск и анализ угроз (threat hunting, threat intelligence), форензика.
В силу обстоятельств мы выбрали для себя немного иной путь, но обо всём по порядку.
С первым уровнем ничего выдумывать не пришлось, это очевидная идея — набрать команду, исходно заточенную под обработку входящего потока обращений и реагирование на автоматизированные мониторинги.
Схему организации я смоделировал по просьбе руководителя минут за 20 «на коленке», и она позволила нашему маленькому предприятию начать работу в тестовом режиме, а некоторые базовые подходы к организации работы группы используются до сих пор.
Разумеется, оставлять обслуживание первой линии на плечах действующих сотрудников никто не собирался. Всего через два месяца поисков мы сформировали команду из стажёров, позднее ставших штатными сотрудниками, а возглавить новое подразделение пригласили опытную сотрудницу одной из служб поддержки посредством внутренней ротации.
Ребята полностью оправдали наши ожидания, забрали всю нагрузку по обработке неформализованных обращений и изменили опыт взаимодействия с департаментом — нам больше не приходится самим гоняться за мелкими нарушителями правил ИБ по неблагополучным районам инфраструктуры компании, а также с частью команд была утверждена схема прямой маршрутизации алертов — мы избавились от диспетчерской функции перекладывания сработок между исполнителями.
Помимо этого они помогли серьёзно переработать внутренние инструменты контроля задач и метрики эффективности — всё то, что раньше могло остаться без должного внимания, теперь контролируется сразу на нескольких уровнях, как автоматизированно, так и методом пристального взгляда дежурного специалиста поддержки.
Группа обрабатывает не только устоявшийся пул задач, но и регулярно принимает на поддержку стандартизированные процессы смежных команд департамента для снятия нагрузки с более высококвалифицированных кадров.
Я понял, как делается колбаса, расскажите мне про мясные лавки
Самое время вернуться к сотрудникам, силами которых проводился пилотный запуск. Избавившись от необходимости лавировать между пользовательскими чатами и рутинной маршрутизацией задач в трекере, они наконец смогли заняться чем-то более творческим.
Более творческие задачи группы аналитики
Так появилась аналитическая группа, зоной ответственности которой стали:
оптимизация и развитие средств мониторинга — просто перевести весь поток событий на другую группу было бы издевательством, поэтому ребята начали исследовать имеющиеся правила и преобразовывать их в комплексные цепочки — мы начали получать уведомления о ценных с точки зрения мониторинга событиях, а не только о косвенных процессах (по итогу примерно на 25% сократилось как количество однотипных правил, требующих поддержки, так и число ложных срабатываний на неоднозначные индикаторы);
регулярный аудит и рефакторинг существующих правил — когда основную часть рабочего времени занимали разбор и классификация сработок, об улучшении кода правил оставалось только мечтать, теперь появилось и время, и свежий взгляд — пересмотр логики и технической реализации теперь является частью операционной деятельности (в рамках последней активности мы проштудировали более 200 правил, избавились от неактуальных — <4%, обнаружили и исправили ошибки в ~10% правил);
взаимодействие с бизнес-заказчиками по вопросам мониторинга отдельных сервисов — наконец-то появилось достаточно времени на подробное обсуждение задач и планов, пусть даже иногда и случается, что от активно прорабатываемых сервисов в итоге отказываются;
углублённый анализ данных при расследованиях — наши самые близкие коллеги (да не обидятся на меня все остальные), разумеется, команда расследования инцидентов — теперь мы можем уделять им должное внимание, помогать оптимизировать запросы к SIEM и оперативно создавать исчерпывающие выгрузки данных.
Дополнительно группа была усилена ещё двумя специалистами, один из которых в скором времени взял на себя роль руководителя подразделения (при этом не прекращая участвовать в операционных задачах), второй же является главным разработчиком собственных внутренних решений, как независимых, например сервис мониторинга утечек данных или платформа Threat Intelligence, так и различных модулей, расширяющих функциональность инструментов.
Команда сформировалась из действующих сотрудников, и мы смогли позволить себе дополнительный наём — усилили группу аналитиком, выросшим на поле интеграторов. Неофит оказался инициативным и притащил в наш монастырь SIEM целый выводок собственных правил (корреляции, конечно).
В итоге наша аналитическая группа объединяет в себе большинство аспектов 2-й и 3-й линий классической модели.
Я — друг, союзник, Санта, который всегда с тобой
Чем же занимается ещё одна группа, если команда аналитики покрывает привычный набор практик классической модели?
Так уж вышло, что изначально SOC берет своё начало из инициативы одного инженера — по совместительству главного архитектора и администратора нашей SIEM (он обычно так и представляется).
Он же взял на себя роль руководителя команды, именуемой «группой развития и поддержки технических инструментов», и теперь может позволить себе сосредоточиться не столько на поддержании стабильности всех систем, сколько на возможностях масштабирования и внедрения новых модулей и дополнительных функций (а ещё он создаёт лучшие презентации своей группы).
Долго искать желающих примкнуть к этой неклассической линии не пришлось — первым подопечным стал действующий сотрудник отдела, обладающий богатым опытом как раз в области технической поддержки (это я). Мне удалось заполучить в качестве нового пула задач изучение каждого компонента SIEM, детальное исследование тонкостей интеграции в инфраструктуру и описание в таком виде, чтобы остальным не приходилось ставить рекорды по прыжкам на подводных граблях. В процентах снижение уровня непонимания наших систем я привести не могу, но хочется верить, что оно «значительное».
Практически одновременно со мной в группе появилась K8s-инженер, которая занялась адаптацией имеющегося зоопарка разнородных элементов для развёртывания их во внутренней K8s-платформе, и уже успела преобразовать как минимум 20% наиболее важных модулей. Также её силами была создана standalone-платформа, имитирующая нашу SIEM, для быстрых тестов, проверки новых библиотек и иных небезопасных для продуктовой среды манипуляций — это помогло нивелировать 99% всех проблем при тестировании из-за разницы архитектур, зависимостей и т.п.
А совсем недавно появился хоть и не выпускник Лиги Плюща, но настоящий потомственный разработчик, чья основная задача — изменение устоявшегося (и далеко не факт, что правильного) представления о процессах разработки.
Мы стараемся пользоваться передовым инструментарием, оптимизировать свои разработки, проводить рефакторинг, но иногда всё ещё велик соблазн оставить заведомо работающий костыль как есть, просто чтобы ничего не сломать.
Дальнейшие наши планы — развитие и оптимизация имеющихся решений, разработка новых модулей и общее повышение стандартов ведения процессов.
Высокие технологии на страже ИБ
Интересный факт — весь линейный состав группы развития и поддержки технических инструментов оказался в компании благодаря системе рекомендаций (как извне, так и посредством внутренней ротации).
Если у вас в компании есть система рекомендаций, а также допустима внутренняя ротация сотрудников между командами, это может стать серьёзным подспорьем в поиске кадров.
Молодость успешнее старости
Прошло около года с момента преобразования идей линейного SOC-а в практические реализации.
За это время полностью сформировались 3 независимые, но тесно взаимодействующие команды, которыми намного проще управлять иерархически.
Каждая наша команда, более не отвлекаясь на сторонние операции, успела откалибровать основной массив всех задач, выявить свои сильные и слабые стороны, а в момент выхода этой статьи мы уже составили план развития на ближайшее полугодие.
Очередным нововведением станет внедрение полноценной круглосуточной смены мониторинга. Растущий объем обращений и непрерывное развитие SIEM и наполнение её новыми событиями и правилами привели нас именно к такому логичному варианту.
Так сколько же линий?
В результате мы модифицируем классическую схему SOC одновременно и качественно, и количественно, ну и стараемся сделать это сбалансированно.
Если вашей организации подходит эталонная модель SOC, пользуйтесь ей, но не бойтесь менять отдельные её части или придумывать свои варианты распределения функций — так вы сможете выработать оптимальную структуру, подходящую именно вашей команде.
Чтобы стать царём зверей, мало вести себя по-царски, надо быть царём.
