«Давайте быстро развернем SOC» — подобные запросы от руководства компаний учащаются после каждой громкой кибератаки. Возникает иллюзия, что центр мониторинга безопасности можно легко создать за пару недель. Но так ли это? Или дело не в SOC, а в том, кто именно его запускает?
На связи Денис Иванов, руководитель по развитию центра мониторинга информационной безопасности в Бастионе. На практике я часто сталкиваюсь с подобными заблуждениями насчет SOC: заказчики путают его с SIEM, не понимают, когда нужен собственный центр мониторинга, а когда — готовая услуга.
В статье разберу, почему сформировалось такое искаженное представление о SOC, с какими типичными ошибками сталкиваются компании при его создании и какие подходы действительно работают.
Кому и зачем нужен SOC
Security Operations Center (SOC) — живая экосистема из технологий, процессов и людей, которая обеспечивает круглосуточный мониторинг и управление безопасностью. За последнее десятилетие SOC эволюционировал от ручного анализа логов до продвинутого арсенала средств защиты информации (СЗИ), позволяющих пресекать атаки на инфраструктуру.
Эта комплексность SOC и порождает главный миф, с которым мы сталкиваемся постоянно: «SOC — это просто ПО. Купил, установил — и защита готова». На практике без грамотной команды и отлаженных процессов такое ПО превращается в дорогой и бесполезный архив логов. Реальный SOC — это живой организм, который нужно выращивать и поддерживать: адаптировать под меняющиеся угрозы, обучать сотрудников и отлаживать каждую связку между технологиями и людьми.
Но какие именно задачи SOC закрывает в компании? Их набор может различаться в зависимости от модели развертывания и специфики бизнеса. Среди ключевых — круглосуточный мониторинг, раннее обнаружение киберугроз, централизованное управление инцидентами и обеспечение требований регуляторов.
Выбор модели SOC напрямую зависит от нескольких факторов:
Масштаб и специфика бизнеса. Крупные корпорации (B2E) чаще стремятся к созданию инхаус-SOC для полного контроля над безопасностью. B2B-компаниям в большинстве случаев интересны облачные SOC-решения, не требующие поддержки собственных серверов и SIEM-систем. В B2G обычно выбирают гибридные решения или строят собственный SOC из-за жестких нормативных требований.
Уровень зрелости и экспертизы. Компаниям без собственных специалистов по ИБ лучше подойдет облачный SOC; организациям с уникальной инфраструктурой — собственный или гибридный. Порой даже IT-компании, обладающие экспертизой, передают мониторинг MSSP-провайдерам, чтобы сфокусироваться на основном бизнесе.
Критичность данных и процессов. SOC особенно необходим компаниям, работающим с высокочувствительными данными (например, финансы, персональные данные или гостайна) и тем, чьи бизнес-процессы напрямую зависят от бесперебойной работы инфраструктуры. Здесь часто выбирают инхаус-модель или управляемый сервис с повышенными требованиями к безопасности.
Какой бы путь — инхаус, облачный SOC или гибрид — вы ни рассматривали, ключевым барьером всегда становится один и тот же фактор: кадры. Именно с ними связаны самые большие заблуждения о построении SOC.
Всё решают кадры
Многим кажется, что достаточно купить и интегрировать в свою инфраструктуру SIEM-систему, посадить пару специалистов — и центр мониторинга готов. В реальности даже самая продвинутая система бесполезна без грамотной команды, собранной и обученной под ваши задачи.
И эта команда должна работать круглосуточно, без выходных и праздников — именно в нерабочее время бизнес наиболее уязвим для атак. Для круглосуточного покрытия вам понадобятся минимум 12–15 человек: три смены аналитиков L1 и L2, инженеры-администраторы систем, руководители смен и координаторы, команда по реагированию. И каждый из них — дефицитный специалист, за которого конкурируют сразу несколько работодателей.
SOC должен работать 24 на 7, потому что SOC 5/2 — это не SOC. Хакеры, к сожалению, не уходят на обеденный перерыв или поспать.
Содержание такой команды — это не просто фонд оплаты труда. Бюджет проекта по созданию SOC часто оказывается на порядок выше первоначальных оценок. Помимо очевидных статей расходов вроде зарплаты и ПО, компания сталкивается с менее предсказуемыми, но весомыми затратами:
потери на текучке кадров (в среднем 20–30% команды в год);
затраты на постоянное обучение и сертификацию сотрудников;
расходы на поддержку и модернизацию инфраструктуры;
дополнительные издержки на интеграцию SOC с бизнес-процессами компании на начальном этапе.
Все эти статьи расходов — прямое следствие четырех системных проблем, с которыми сталкивается любая компания при построении SOC:
1. Жесткий дефицит квалифицированных кадров. Пока вы месяц ищете и два месяца онбордите старшего специалиста, конкуренты уже пробуют переманить его более выгодным оффером. Найти даже одного опытного SOC-аналитика за месяц — это уже большая удача; порой создается впечатление, что надежнее растить экспертизу внутри. На практике лучше всего работает гибридный подход: привлекать готовых экспертов и параллельно растить собственных. Без этого непрерывного обучения даже сильная команда быстро теряет эффективность, потому что угрозы эволюционируют ежедневно.
2. Высокие зарплатные ожидания. Хороший специалист по кибербезопасности стоит дорого. Для крупной организации содержание штата SOC означает ежегодные расходы на зарплаты, исчисляемые десятками миллионов рублей. Когда мы смотрим на ситуацию в компаниях, которые пытались построить SOC самостоятельно, часто видим одну и ту же картину: бюджет на оплату труда регулярно повышается, но проблема удержания кадров никуда не уходит.
3. Долгое обучение. Адаптация нового аналитика занимает от 3 до 6 месяцев — и всё это время вы платите зарплату без полной отдачи. Но проблема глубже: инхаус-специалист ограничен одной инфраструктурой и типовыми сценариями, что для амбициозного инженера — карьерный тупик. По-настоящему богатый опыт дают только сервис-провайдеры, где за год видят больше инцидентов, чем специалист в инхаусе за всю свою карьеру.
4. Проблема часовых поясов/рабочего графика. Некоторые руководители ошибочно полагают, что для организации круглосуточного мониторинга достаточно «нанять по одному человеку в каждом регионе», и всё заработает само. Но реальность сложнее: нужно не просто физическое присутствие специалиста, а полноценная команда в каждой смене. Обязательно появятся периоды, когда дневные и вечерние смены не покроют все временные зоны, что создаст «слепое» окно. На практике это приводит к необходимости вводить нестандартные графики работы или создавать распределенные команды в разных регионах.
Для коммерческих SOC-провайдеров проблема часовых поясов не существенна. Они просто набирают сотрудников, готовых работать в нестандартные смены, и распределяют нагрузку между ними. Однако для среднего бизнеса — это вызов. Представьте HR-хаос набора и управления командой, распределенной по всей стране, от Калининграда до Владивостока. Это дополнительные организационные усилия и затраты, которые могут быть неподъемными для средних и небольших организаций.
Поэтому когда кто-то говорит «давайте быстро развернем SOC», я всегда спрашиваю: а где вы возьмете людей? Российский рынок кибербезопасности и так испытывает острый дефицит кадров. Может быть, проще начать с гибридного решения, а команду растить постепенно? Есть исследования о том, что стоимость найма нового сотрудника (учитывая поиск, адаптацию и возможные ошибки) может в разы превышать затраты на внутреннее обучение. Для SOC-аналитиков это супер-актуально, потому что тут нужны специфические знания о внутренней инфраструктуре компаний. Но это уже тема для другой статьи.
SOC ≠ SIEM, или сколько стоит ваша инфраструктура
На втором месте после недооценки человеческого фактора стоит другое распространенное заблуждение — отождествление SOC с SIEM. Логика «купим SIEM — и у нас будет SOC» часто приводит к разочарованию. Это как купить машину и считать, что вы уже умеете водить.
Реальный SOC требует дорогостоящих лицензий на ПО и капитальных вложений в инфраструктуру:
Во-первых, потребуются мощные серверы для обработки и хранения событий. SIEM-системы чувствительны к производительности и отказоустойчивости — экономить здесь не получится.
Во-вторых, понадобится отдельная сетевая инфраструктура с достаточной пропускной способностью, чтобы собирать и анализировать трафик со всей организации.
В-третьих, каждому сотруднику SOC нужно рабочее место с нормальным железом и необходимым ПО.
Вишенкой на торте станут затраты на обслуживание всего этого зоопарка.
Почему облачная модель выгоднее
Главное преимущество облачных SOC — отсутствие простоев. В MSSP одна команда мониторинга работает сразу с несколькими заказчиками, а не сидит внутри одной организации в режиме «ждём инцидента». Это типичная сервисная модель: вы платите за объем мониторинга, а не за содержание всей инфраструктуры.
Вместо того чтобы каждый раз выстраивать процессы с нуля, сервис-провайдеры используют уже отработанные схемы, проверенные на десятках проектов. Стандартизированные процедуры ускоряют реагирование и снижают операционные издержки. Вдобавок лицензии на ПО для MSSP-провайдеров часто на 30–50% дешевле, чем для корпоративных клиентов, а оборудование закупается крупными партиями.
Как итог, управляемый сервис дешевле не потому, что там хуже специалисты или слабее технологии. Экономия возникает благодаря налаженным процессам и оптимизации ресурсов. Не случайно многие вендоры сейчас активно развивают партнерские программы для MSSP — они понимают, что будущее за сервисными моделями.
Однако даже при всех этих преимуществах MSSP эффективный мониторинг остается нетривиальной задачей. Любая корпоративная среда уникальна, а современные атакующие редко действуют грубо. Чаще они начинают с аккуратной разведки, применяя инструменты, которые антивирусы считают безопасными.
Поэтому наличие технологий само по себе ничего не решает — важно ещё уметь с ними работать. Команда SOC должна постоянно адаптировать правила детектирования под специфику бизнеса, понимать, какие действия в конкретной среде допустимы, а какие — нет. Без этого даже самая дорогая платформа будет работать как лог-архив, а не как инструмент обнаружения атак.
Настройка процессов — долго, дорого, сложно
Когда говорят о «настройке процессов SOC», на практике имеют в виду вполне конкретные вещи: какие события будут считаться инцидентом, каким из них отдавать приоритет, что делать при срабатывании.
Базовый уровень — коробочные правила мониторинга от сервис-провайдера или вендора SIEM. Это минимальный набор сценариев, направленных на обнаружение очевидных угроз — например, брутфорса, подозрительных действий в Active Directory или использования популярных вредоносов. Такой мониторинг дает быстрый результат, но охватывает лишь поверхностные риски.
Следующий этап — кастомизация правил под конкретную среду. Здесь уже потребуются:
перечень администраторов и их типичных действий;
список разрешенного ПО и легитимных активностей;
лимиты по критическим операциям (например, массовое удаление файлов).
На эту работу уходит вся жизнь от 3 до 6 месяцев, особенно если учитывать согласования с другими подразделениями, тестирование и доработку сценариев. В результате система начинает детектировать не только шаблонные атаки, но и более сложные угрозы, такие как перемещение внутри сети или использование легальных инструментов в злонамеренных целях.
Продвинутый уровень, или полноценное погружение в специфику компании — это уже игра вдолгую. Речь идет о детектировании аномалий, связанных с уникальными бизнес-процессами, настройке правил для кастомных приложений и legacy-систем, постоянном обновлении логики мониторинга под новые методы атак. Даже спустя годы работы могут оставаться «слепые зоны», которые будут требовать корректировок.
На любом из этих уровней у вас должен быть четко регламентирован процесс мониторинга. Команда должна точно понимать, как осуществляется наблюдение за инфраструктурой, какие инструменты используются, какие события считаются значимыми и как коммуницировать с другими отделами в случ��е инцидента. Без таких регламентов работа превращается в хаос, где решения принимаются ситуативно, что неизбежно ведет к ошибкам.
Регламенты нужно постоянно актуализировать: инфраструктура меняется, техники атак — тоже. Хорошей практикой является обновление после значимых изменений в инфраструктуре серьезных инцидентов, когда становятся видны слабые места существующих процедур. Слишком жесткие регламенты так же опасны, как и их полное отсутствие, ведь они лишают команду возможности адаптироваться к меняющимся условиям.
Особые случаи, когда внутренний SOC имеет смысл
Встречаются и ситуации, когда бизнес действительно может позволить себе поэтапное построение внутреннего SOC без существенных рисков. Яркий пример — одна крупная компания, чья инфраструктура была практически полностью изолирована от внешнего мира. У них было минимальное присутствие в интернете в виде сайта-визитки, а основная инфраструктура на момент кейса насчитывала тысячи серверов и рабочих станций, тщательно сегментированных внутри сети.
Руководитель компании обоснованно считал, что даже в случае инцидента в пользовательском сегменте вероятность его распространения на критические системы крайне мала. Это позволило компании относительно спокойно развивать собственный SOC, опираясь на уже внедренные EDR-решения и поэтапно наращивать компетенции команды. Но такой подход возможен только при изначально грамотной архитектуре безопасности с жесткой изоляцией сегментов.
В моей практике чаще встречались обратные примеры, особенно в сегменте B2G, когда компании после попытки построить внутренний SOC возвращались к коммерческим решениям. Типичная ситуация: организация инвестирует в создание SOC, сталкивается с серьезным инцидентом, и оказывается, что их команда либо недоукомплектована, либо недостаточно квалифицирована для эффективного противодействия.
После таких случаев многие принимают решение временно перейти на коммерческий SOC, продолжая параллельно дорабатывать собственное решение. Но значительная часть в итоге полностью отказывается от идеи внутреннего SOC, осознав масштаб требуемых постоянных инвестиций.
Проверка эффективности SOC и команд
Независимо от того, выбрали ли вы внутренний или коммерческий SOC, его работоспособность нужно регулярно проверять. В этом плане наиболее показательны киберучения, моделирующие реальные атаки. Только анализируя, как быстро и точно срабатывают механизмы обнаружения и реагирования, можно по-настоящему оценить эффективность SOC.
При этом важно понимать, что Red Team — не универсальный индикатор качества работы SOC. На практике бывали ситуации, когда SOC в ходе киберучений корректно обнаруживал атаку и выдавал рекомендации, но они не выполнялись вовремя ИТ-службой. В результате атака развивалась дальше, а выводы делались ошибочные — как будто проблема была в SOC. На самом деле такие кейсы показывают слабые места во взаимодействии команд и процессах принятия решений, а не плохую работу мониторинга.
Особняком стоит контроль качества работы распределенных команд. В коммерческих SOC эта проблема решается с помощью систем мониторинга производительности. Например, в Бастионе время реакции на инциденты четко фиксируется в SLA, а скорость обработки кейсов отслеживается с помощью автоматизированных инструментов. Если инциденты начинают подологу «застревать» на отдельных стадиях, это сразу становится заметно.
На практике эффективность SOC особенно заметна в пиковые периоды — например, в новогодние праздники. За годы работы мы предотвратили достаточно инцидентов, чтобы понимать, какие сценарии чаще всего всплывают в такие моменты и где возникают реальные риски. На основе этого опыта разработаны регламенты, определяющие порядок дежурств и приоритеты мониторинга в праздничные дни. Для компаний с ограниченными ресурсами такой подход особенно важен: даже базовый контроль ключевых систем в «опасные» периоды заметно повышает вероятность предотвращения атак.
Другой важный маркер эффективной команды — разграничение полномочий SOC. В разных организациях это может выглядеть совершенно по-разному: где-то команда безопасности имеет право самостоятельно принимать решения о блокировках и изменениях, а где-то — только давать рекомендации, оставляя окончательное слово за владельцами систем. Этот момент критически важен, так как определяет реальные возможности SOC влиять на безопасность организации. Неправильное распределение ответственности может свести на нет все усилия по мониторингу: SOC увидит угрозу, но не сможет оперативно её отработать из-за бюрократических барьеров.
Процесс оценки эффективности сам по себе включает множество сопутствующих процедур. Проверяется, как настроено взаимодействие между первой и второй линией реагирования, как выглядит эскалация инцидентов, каков порядок отключения систем в экстренных случаях, настроены ли правила генерации алертов.
Эти процессы не обязательно детализировать до мелочей, но общие принципы и порядок действий должны быть четко зафиксированы, включая выстраивание метрик эффективности. Измерение таких показателей, как скорость обнаружения, время реагирования, качество анализа требует накопления статистики. Невозможно адекватно оценить эффективность SOC, который работает всего несколько недель.
Влияет ли работа с разными заказчиками на качество мониторинга?
На самом деле, вопрос не в качестве, а в трудозатратах. Возьмем два типа клиентов:
У типового заказчика стандартная инфраструктура: несколько серверов, парк рабочих станций на Windows, минимум кастомных решений. Подключить такого клиента к базовому мониторингу относительно просто — настройка занимает минимум времени, алерты предсказуемы, процессы отработаны.
У заказчика со сложной уникальной инфраструктурой всё иначе: унаследованные системы, самописные решения, критические бизнес-процессы на «легаси»-коде, который никто толком не документировал.
Такого клиента подключить не просто сложнее — это принципиально другая работа. Ресурсы команды расходуются не на анализ угроз, а на изучение самой инфраструктуры: нужно разбираться в кастомных системах, которые писали под себя 10 лет назад, погружаться в бизнес-процессы и разбираться, что действительно важно мониторить.
Работа с этими двумя категориями заказчиков требует принципиально разного подхода. В условиях ограниченных ресурсов (временных, финансовых, человеческих) придется выбирать между скоростью подключения и глубиной охвата.
Для типовых инфраструктур можно быстро выйти на высокий уровень мониторинга с минимальными трудозатратами. Здесь основная задача SOC — обеспечить стабильность и предсказуемость работы.
Для сложных инфраструктур качественный мониторинг возможен только после глубокого анализа и адаптации под специфику заказчика. Это долгий и ресурсоемкий процесс, который нельзя ускорить без потери эффективности.
Что делать? Если у вас нет уникальных требований — коммерческий SOC оптимален. Если же инфраструктура сложная и критичная для бизнеса — стоит задуматься о гибридной модели или постепенном переходе к in-house. Попытки искусственно ускорить этот процесс неизбежно приведут к опасным пробелам в системе безопасности:
Ложному чувству защищенности, когда организация считает, что защищена, в то время как SOC не способен обнаружить и отработать реальные угрозы из-за недостаточно отлаженных процессов.
Финансовым и репутационным потерям, когда инцидент, пропущенный неопытным аналитиком или несовершенной системой, приведет к миллионным убыткам и потере доверия.
Вместо вывода
Создание полноценного SOC — это процесс, измеряемый годами, а не месяцами. Даже при наличии консалтинговой поддержки минимальный срок для развертывания работоспособного центра мониторинга составляет 1,5–2 года. И это при условии бесперебойного финансирования и доступности квалифицированных кадров.
Именно поэтому начинать стоит с главного вопроса: действительно ли вам нужен собственный SOC? Если нет уникальных требований, жестких нормативов или долгосрочных планов — возможно, коммерческое решение уже покрывает 90% потребностей.
PURP — Telegram-канал, где кибербезопасность раскрывается с обеих сторон баррикад
t.me/purp_sec — инсайды и инсайты из мира этичного хакинга и бизнес-ориентированной защиты от специалистов Бастиона
