Почти 70 % компаний уже внедрили SOC, но половина таких центров остаются неэффективными. Все дело в непонимании бизнес-целей, недостатке кадров, неподготовленной инфраструктуре и нереалистичном бюджетировании. В материале обсудили ключевые риски запуска и практические выводы от отраслевых экспертов.
- 1. Введение
- 2. Риск №1. ИТ-проект вместо бизнес-проекта
- 3. Риск №2. Кадровый вакуум
- 4. Риск №3. Неготовность инфраструктуры
- 5. Риск №4. Бюджетные ограничения
- 6. Выводы
Введение
К 2026 году собственный SOC (Security Operations Center, Центр мониторинга информационной безопасности) или доступ к нему имеют около 70 % компаний крупного и среднего бизнеса. Однако почти у половины из них он попросту неэффективен. Проблема не в инструментах, а в самом фундаменте.
В эфире АМ-Live ведущие специалисты поделились взглядами на то, как эффективно построить SOC и не выйти за рамки бюджета.
Риск №1. ИТ-проект вместо бизнес-проекта
Стартовая ошибка большинства SOC-проектов — подмена бизнес-логики технологической. Выбирается SIEM (Security information and Event Management, система управления событиями безопасности), обсуждается EDR (Endpoint Detection and Response, обнаружение и нейтрализация атак на конечные точки), рассчитывается объём EPS (Events Per Second, количество событий в секунду) и архитектура хранения логов. Но не формулируется главный вопрос — «какой конкретный бизнес-риск должен снижать SOC?».
По словам заместителя директора экспертного центра безопасности Positive Technologies Владимира Дмитриева, начинать нужно не с задачи и не с инструментов, а с разговора с бизнесом: «для чего нам вообще SOC, что мы хотим от него получить?». Например, для ретейла это непрерывность работы склада и торговых точек, для ИТ-компании — сохранность пайплайна (последовательности этапов) разработки и отсутствие компрометации сервисов. SOC надо встроить в модель непрерывности бизнеса, а не в модель ИТ-мониторинга.
Без этой логики SOC начинает жить по так называемой noise-driven модели, то есть его деятельность направляют не бизнес-задачи, а всевозможные «шумы». ИТ-отделы настраивают десятки правил корреляции, генерируется поток уведомлений. Но между ними и стратегическими рисками компании нет прямой связи.
Рисунок 1. Уровни эффективности SOC. Источник: Softenger
С этой проблемой сталкиваются не только в России. По данным исследования HP Enterprise, только около 25 % организаций смогли создать эффективную работу своих SOC, остальные же не могут преодолеть организационные, процессные и управленческие барьеры. Эксперты по измерению эффективности подчёркивают, что многие организации до сих пор не работают с метриками, которые переводят деятельность SOC на бизнес-язык. Компании просто не знают, какие финансовые результаты вообще приносит система.
Как отметил Старший эксперт по сервисам безопасности «Лаборатории Касперского» Андрей Тамойкин, необходимо продемонстрировать ценность SOC для руководства и доказать конкретный бизнес-эффект от внедрения.
Риск №2. Кадровый вакуум
Следующий риск — недостаток подходящих кадров. Андрей Тамойкин прямо указал, что именно это становится основной проблемой, причём не только в России:
«Технологии можно запланировать, как и процессы, а вот кадры — это та вещь, которую адекватно прогнозировать сложно».
По его словам, средний срок найма аналитика SOC составляет 2–6 месяцев. Для полноценного круглосуточного мониторинга требуется минимум 5 аналитиков первой линии. То есть даже при благоприятном рынке труда на формирование базовой сменной команды может уйти год.
Как дополнил Руководитель группы пресейл-менеджеров, пресейл-архитектор в Security Vision Александр Падурин, к срокам найма нужно добавлять и время на онбординг. Аналитика нужно обучить, дать «разогреться». А если учесть жёсткий рынок труда, конкуренцию компаний и региональные ограничения, на подготовку команды уйдёт до полутора лет.
Отдельную проблему составляет поиск аналитиков третьей линии, которых, по словам Андрея Тамойкина, можно искать несколько лет. Эти специалисты:
- проводят сложные расследования;
- занимаются поиском угроз;
- валидируют новые сценарии обнаружения;
- работают с нетривиальными атаками.
Без аналитиков такого уровня SOC превращается в центр однотипных алертов. Он может обрабатывать фишинг и стандартные вредоносные программы, но при столкновении со сложной атакой оказывается ограниченным.
Как главную проблему недостаток квалифицированных кадров отметили и зрители, проголосовавшие в опросе. Причём эта проблема характерна и для зарубежных рынков. Аналитики называют недостаток навыков и знаний у персонала одним из важнейших вызовов при внедрении SOC. Если аналитику не хватает экспертизы, он тратит время, чтобы разобраться в инструментарии, найти нужные функции мониторинга и управления, корректно диагностировать инцидент. Кроме того, он может неверно реагировать или выполнить неполный набор действий для остановки атаки.
Как указывают эксперты, даже опытные специалисты, отлично владеющие инструментами, могут допускать ошибки, если плохо понимают защищаемую среду. Недостаточное знание архитектуры, бизнес-процессов и критичных активов приводит к росту ложноположительных срабатываний, и наоборот — увеличению ложноотрицательных инцидентов, когда реальная атака не распознаётся как угроза. В итоге команда тратит ресурсы на несуществующие проблемы и одновременно пропускает реальные атаки.
В качестве возможного решения эксперты рекомендуют использовать аутсорсинг. Руководитель отдела развития технологий и перспективных услуг SOC в ГК «Солар» Максим Жевнерёв говорит, что на старте следует взять коммерческий внешний сервис и вместе с ним выстраивать внутреннюю инфраструктуру и процессы реагирования.
Андрей подчеркнул, что необходимо стандартизировать процессы и обучать внутренних специалистов, чтобы не стать зависимым от одного «звёздного» эксперта, при уходе которого вся система может развалиться. А аналитиков первой линии можно сформировать из студентов и стажёров, которые со временем смогут получить больше компетенций.
Максим Жевнерёв также предложил нестандартное решение: поменять местами людей на разных ролях. Например, автора правил посадить на L1, а L1 временно включить в разработку детектов. По его словам, это даст ценные инсайты и повысит качество процессов.
Риск №3. Неготовность инфраструктуры
Даже при корректной постановке бизнес-задач и подходящей модели работы с кадрами запуск SOC может сорваться из-за неподготовленной инфраструктуры. Александр Падурин прямо назвал именно эту проблему одной из самых частых причин сдвигов сроков:
«Самая частая проблема, из-за чего прямо с самого начала всё уходит на полгода вперёд, — это задержка с поставками оборудования. Бывает, что нам должны поставить сервера через полгода. Они только через год приезжают».
SOC-проект почти всегда зависит от готовности серверной инфраструктуры, доступа к сетевым сегментам, участия ИТ-подразделения. Если ИТ не синхронизировано с ИБ, запуск центра мониторинга может затянуться надолго.
Проблема усугубляется масштабами данных. По оценкам, у заметной доли компаний поток логов уже измеряется терабайтами в сутки. 22 % организаций генерируют 1 ТБ логов в день или больше, и это даже не бигтехи, а вполне обычные предприятия среднего бизнеса. Если система будет не готова к такой нагрузке, толку от неё будет немного. Для этого архитектуру SOC стоит спроектировать как дата-платформу с управлением жизненным циклом данных, нормализацией и фильтрацией на входе.
Отдельный слой инфраструктурного риска — слепые зоны, которые растут по мере шифрования, и облака. Доля организаций, которые вообще не используют TLS-инспекцию для просмотра зашифрованного трафика, выросла до 34 % против 25 % годом ранее. Эксперты связывают это с тем, что SOC теряет видимость исходящего трафика и всё сильнее вынужден полагаться на телеметрию конечных точек.
Участники дискуссии упомянули, что выбор технологий должен идти от необходимой функциональности. Иначе SOC начнёт генерировать поток алертов, которые не привязаны к реальному риску. Кроме того, необходимо провести качественную инвентаризацию. Иначе система не сможет приоритизировать алерты и оценивать реальный уровень риска, из-за чего менее заметные сегменты останутся вне зоны контроля.
Рисунок 2. Схема непрерывного улучшения в SOC. Источник: SecureList
Это подтверждает и зарубежный опыт. Инструментальный зоопарк и разрыв рабочих процессов становятся одной из причин провалов внедрения SOC. Команды в среднем управляют 17 разными облачными инструментами, а 30 % компаний тратят более суток на закрытие инцидентов, в то время, как атаки в облачных средах могут развернуться за считанные минуты.
Так, одним из самых ярких случаев стал взлом системы здравоохранения Сингапура SingHealth в 2018 году. Атака привела к компрометации личных данных 1,5 млн пациентов и записей о назначениях лекарств 160 тысячам человек. Расследование выявило, что серверы с уязвимостями не получали обновлений более года, а антивирусное ПО значительно устарело, что стало результатом системных проблем с поддержкой и управлением инфраструктурой.
Более того, атака начиналась с заражения одной рабочей станции и затем распространилась по сети, что стало возможным из-за архитектурных слабостей в системе. Повлиял и недостаточный опыт персонала, который не сумел интерпретировать поступающие алерты вовремя. Этот кейс стал одним из классических примеров неготовности как команды, так и самой системы к реальной атаке.
Компаниям стоит учесть 3 основных контура при подготовке инфраструктуры. Первый — управляемый контур логирования, который отвечает за сбор и хранение информации. Второй — контур видимости, который закрывает слепые зоны. Третий — контур контекста, то есть инвентаризация, нормализация идентичностей и сервисов.
Риск №4. Бюджетные ограничения
Вопрос бюджета остаётся одним из самых чувствительных на старте SOC. Здесь у компаний может сформироваться 2 иллюзии: или попытка запустить всё по минимальной цене, или, наоборот, желание успеть всё и сразу, что ещё сильнее раздует бюджеты.
Во время дискуссии начальник Центра реагирования Подразделения ИБ «Московского метрополитена» Елизавета Шатунова напрямую спросила, какой нужен бюджет для запуска SOC в базовом варианте и как сделать так, чтобы затраты не выросли вдвое во время внедрения? Максим Жевнерёв оценил минимальную планку в 2,5 млн рублей. Он указал, что речь идёт о сервисной модели для «не очень большой инфраструктуры». А Евгений Гуляев указал, что без предпроектного обследования и без понимания того, какой именно комплект продуктов нужен заказчику, давать какие-либо оценки бесполезно.
Иллюзия дешёвого старта возникает, потому что на раннем этапе SOC действительно могут воспринимать как набор минимальных инструментов. Достаточно купить лицензию на SIEM, набор серверов и нанять несколько аналитиков. Однако многие забывают про необходимую интеграцию с инфраструктурой, настройку правил, развитие плейбуков, что может привести к резкому росту бюджетов. А на формирование полноценного SOC-проекта может уйти до 3 лет.
Иллюзия дешёвого старта опасна тем, что она формирует завышенные ожидания. Руководство ожидает полноценный центр мониторинга за минимальные деньги и в короткие сроки. Когда же выясняется, что необходимы дополнительные инвестиции, доверие к проекту снижается.
Другой ошибкой может стать, наоборот, попытка раздуть проект и подвести его под каждый возможный сценарий. Андрей Тамойкин отметил, что на старте фирме не нужно 50 плейбуков, то есть формализованный сценарий действий аналитика при обработке конкретного типа инцидента. Для начала будет достаточно нескольких сценариев. Так же считали и опрошенные зрители трансляции.
Кроме того, чрезмерное расширение функционала на старте обостряет кадровую проблему. Если даже базовую L1-команду сложно сформировать в течение 2–6 месяцев, то запуск сложных сценариев без зрелой команды может привести к операционному коллапсу.
Согласно одному из отраслевых исследований, 67 % центров мониторинга испытывают критические операционные сбои в первые 2 года работы из-за ошибок планирования и распределения ресурсов, что повышает задержки обнаружения угроз почти в 2 раза и увеличивает стоимость реагирования в 1,5 раза по сравнению с отлаженными SOC. Из-за этого в первые 6–18 месяцев большинство SOC попросту закрываются.
Попытка реализовать идеальный SOC в первые месяцы лишь отсрочит эффективную работу и снизит эффективность. Сперва лучше отработать ограниченный набор сценариев, а уже затем масштабироваться.
Выводы
SOC принимают всё больше компаний, но до сих пор немногие могут использовать его эффективно. Главным фактором успеха становится способность выстроить управляемую модель обнаружения и реагирования, привязанную к конкретным бизнес-рискам.
Практика показывает наличие 4 главных рисков: подмена бизнес-целей ИТ-интеграцией, недооценка кадрового горизонта, инфраструктурная неподготовленность и искажённое бюджетное планирование.
Как отметили участники эфира, устойчивость центра формируется в первые 6 месяцев через ограниченный набор сценариев, стандартизированные плейбуки, измеримые операционные метрики и чёткую модель реагирования. Именно дисциплина первых 6 месяцев определит, станет ли SOC малополезным набором инструментов или превратится в полноценное и эффективное подразделение бизнеса.
