Современный SOC приходит к осознанной и эффективной эксплуатации. В 2026 году успех центра мониторинга определяет не столько набор инструментов, сколько отлаженные процессы работы с ними. Как выстроить этот баланс и превратить технологии в реально работающий механизм защиты?
- 1. Введение
- 2. С чего начать построение SOC?
- 3. Какую выбрать архитектуру для SOC в 2026 году?
- 4. Блиц: самый недооценённый продукт в SOC
- 5. Какие функции в SOC может выполнять ML?
- 6. Три первых шага для тех, кто строит SOC
- 7. Выводы
Введение
В последние годы подход к построению центров мониторинга информационной безопасности (SOC) прошёл значительный путь развития. Если раньше основное внимание уделялось первоначальному выбору технологической платформы, то сегодня на первый план выходит непрерывный процесс её настройки и адаптации.
Рынок инструментов защиты стал более зрелым, однако сам по себе набор продуктов не гарантирует защищённости инфраструктуры. Эффективность SOC всё больше зависит от того, насколько грамотно выстроены процессы эксплуатации, анализа событий и реагирования на инциденты.
Эксперты обсудили, как смещается фокус с этапа выбора технологий на их повседневное применение, и какие факторы определяют успешную работу SOC в современных условиях.
Рисунок 1. Эксперты в студии AM Live
Участники эфира:
- Владимир Дмитриев, заместитель директора экспертного центра безопасности (PT ESC), Positive Technologies.
- Евгений Гуляев, руководитель отдела реализации проектов, R-Vision.
- Андрей Шаляпин, руководитель BI.ZONE TDR, BI.ZONE.
- Максим Жевнерёв, руководитель отдела развития технологий и перспективных услуг SOC, ГК «Солар».
- Александр Падурин, руководитель группы пресейл-менеджеров, Security Vision.
- Андрей Тамойкин, старший эксперт по сервисам безопасности, «Лаборатория Касперского».
Ведущий и модератор эфира — Елизавета Шатунова, начальник Центра реагирования Подразделения ИБ, ГУП «Московский метрополитен».
С чего начать построение SOC?
Елизавета Шатунова отметила, что у 70 % компаний крупного и среднего бизнеса есть свой SOC или доступ к нему. Но парадокс заключается в том, что почти у половины из этих компаний SOC неэффективен, и причина даже не в инструментах, которые они используют, а в фундаменте. Поэтому для построения SOC нужно разобраться в фундаментальных вопросах, связанных с проектированием, архитектурой, технологиями и эффективностью.
Елизавета Шатунова, начальник Центра реагирования Подразделения ИБ, ГУП «Московский метрополитен»
Андрей Шаляпин считает, что сегодня SOC — это не только мониторинг и реагирование, а нечто большее. По его мнению, центр мониторинга становится центром операционной безопасности компании в принципе. Помимо управления уязвимостями, в SOC могут реализовываться и другие функции: управление безопасными конфигурациями, Threat Intelligence, задачи Red Team.
Начинать построение SOC нужно с понимания того, какой набор функций мы хотим видеть в перспективе 3–5 лет. Важно определить, какие ресурсы, в первую очередь компетенции, доступны уже сейчас, а какие можно взрастить в течение небольшого времени.
Владимир Дмитриев считает, что начинать построение SOC нужно с бизнес-целей. Он объясняет: для большинства заказчиков основная задача центра мониторинга — остановить атаку до того, как пострадает бизнес. Поэтому важно определить реальные цели и разобрать задачи на конкретные векторы и инфраструктуру. Поскольку ресурсы всегда ограничены, при строительстве необходимо соблюдать баланс. Далее следует провести инвентаризацию и понять объект защиты.
Эксперт предупреждает: не стоит пытаться делать всё и сразу. Нужно определить команду, которая будет этим заниматься, и уже под людей подбирать процессы и технологии. Дмитриев рекомендует взять что-то на пилот, посмотреть, как это применимо к конкретной компании и её инфраструктуре. Уже на этапе пилота можно проводить тестирования и эмулировать действия атакующего.
Владимир Дмитриев, заместитель директора экспертного центра безопасности (PT ESC), Positive Technologies
Евгений Гуляев обращает внимание на важность подготовительной работы, которую можно провести бесплатно. Прежде всего нужно навести порядок в инфраструктуре, разобраться, насколько хорошо компания понимает свой ИТ-ландшафт и готово ли к этому ИТ-подразделение. Кроме того, необходимо договориться о распределении ролей (кто за что будет отвечать), а также разработать и написать регламент реагирования.
Александр Падурин считает, что после определения объектов защиты и страхов компании необходимо исходя из модели угроз сформировать перечень приоритетных источников для постановки на мониторинг. Далее нужно понять, какие именно события из этих источников следует подключать в SIEM. Если этого не сделать, постановка активов на мониторинг будет крайне сложной.
Ошибки при построении SOC
Андрей Шаляпин отмечает, что построение SOC часто начинают с очевидных шагов: например, с приобретения SIEM-системы как наиболее ассоциируемого с центром мониторинга решения. При этом отсутствует предварительное проектирование и понимание того, какие функции мы хотим получить.
Ещё одна распространённая ошибка — стремление сделать всё быстро. Компании осознают, что создание SOC — длительный проект, но пытаются максимально быстро набрать команду. Однако без чёткого понимания желаемого результата просто набранная команда не приведёт к нужному эффекту.
Андрей Шаляпин, руководитель BI.ZONE TDR, BI.ZONE
Максим Жевнерёв обращает внимание на специфику построения SOC: оно сопровождается большим объёмом операционной деятельности, множеством разнородных задач, которые нужно выполнять постоянно, что может быть скучно. Когда центр мониторинга создаётся с нуля, многие команды не справляются с этим валом операционных задач на начальном этапе.
Главную ошибку эксперт видит в попытке сделать всё одновременно или двигаться сразу в нескольких направлениях, не учитывая, что каждое из них тянет за собой много дополнительных проблем и задач. Поэтому, когда SOC только запускается внутри компании, важно сосредоточиться на одной-трёх приоритетных задачах. Всё остальное можно отдать внешним провайдерам или временно игнорировать, двигаясь фокусно и постепенно переходя от одной задачи к другой.
Евгений Гуляев обращает внимание на распространённое заблуждение: многие компании полагают, что достаточно приобрести SIEM-систему — и SOC появится сам собой. Такой подход встречается повсеместно, но неизбежно приводит к разочарованию, поскольку технологии без выстроенных процессов и компетенций не работают.
В первом опросе зрители поделились, что они считают базовым минимумом для SOC в 2026 (мультивыбор):
- Мониторинг и анализ событий — 93 %.
- Разбор и приоритизация инцидентов — 79 %.
- Реагирование на инциденты — 70 %.
- Автоматизация повторяющихся задач — 36 %.
- Выполнение требований регуляторов — 25 %.
- Контроль и отчётность для руководства — 23 %.
Рисунок 2. Что вы считаете базовым минимумом для SOC в 2026? (мультивыбор)
Что мешает построить SOC с нуля?
Евгений Гуляев выделил 3 главных препятствия при создании SOC с нуля: неготовность ИТ-инфраструктуры, отсутствие понимания собственных активов и ресурсно-сервисной модели, а также отсутствие вовлечённого руководителя проекта со стороны заказчика.
Андрей Тамойкин считает, что основная проблема при построении SOC — это кадры. Технические вопросы решаемы, процессы давно известны, а вот с прогнозированием доступности специалистов ситуация сложнее: опираться можно только на статистику.
Средний срок найма аналитика для SOC составляет от 2 до 6 месяцев, но это не гарантирует, что по истечении данного срока специалист будет найден. Только для первой линии требуется 5 человек. Эксперт уверен: эту проблему необходимо учитывать, закладывать в планы и учиться с ней справляться.
Андрей Тамойкин, старший эксперт по сервисам безопасности, «Лаборатория Касперского»
Александр Падурин называет 2 наиболее частые проблемы при построении SOC — задержки с поставками оборудования и необходимость длительного согласования с ИТ-подразделением доступа к инфраструктуре. Решение этих вопросов может затянуть проект ещё на полгода или вовсе привести к его провалу.
Какую выбрать архитектуру для SOC в 2026 году?
Владимир Дмитриев считает, что начинать построение мониторинга необходимо с логов аутентификации. Он поясняет: все точки аутентификации — Active Directory, MFA, точки входа в различные системы — критически важны, поскольку 80 % атак подразумевают манипуляции с учётными данными.
Практика показывает: имея логи аутентификации, можно эффективно мониторить, обнаруживать атаки и реагировать на них даже без хорошего хостового покрытия. Без этих логов, предупреждает эксперт, задача существенно усложняется. Кроме того, эксперт отмечает важность сетевых потоков: если добавить к ним данные с сетевых сенсоров, становятся видны попытки эксплуатации уязвимостей и сканирование, что в совокупности даёт высокий процент видимости происходящего в инфраструктуре.
Максим Жевнерёв предлагает на старте обратиться к коммерческому внешнему SOC и параллельно с провайдером выстраивать собственную внутреннюю инфраструктуру и процессы реагирования. Базой должны стать Patch Management и Asset Management — если этих процессов нет, их необходимо развивать либо передать внешнему провайдеру.
Знание инфраструктуры обеспечивает 80–90 % успеха во всех дальнейших работах. Первый вопрос, возникающий при любом алерте, — «где это произошло и к кому нужно идти», а ответить на него можно только при чётком понимании собственной инфраструктуры.
Максим Жевнерёв, руководитель отдела развития технологий и перспективных услуг SOC, ГК «Солар»
Андрей Тамойкин систематизирует подход к выбору источников, разделяя их на 2 категории. К первой он относит источники телеметрии, где ключевой критерий — распространённость в инфраструктуре: в первую очередь это операционные системы, средства защиты информации и сетевые потоки.
Вторая категория — источники контекста для обогащения событий. Эксперт уверен, что здесь нужно ориентироваться на фундаментальные системы: Asset Management, CMDB, каталоги пользователей и базы индикаторов компрометации.
Во втором опросе выяснилось, что, по мнению зрителей, мешает SOC быть более эффективным (мультивыбор):
- Нехватка квалифицированного персонала — 56 %.
- Недостаток бюджета — 47 %.
- Недостаточно знаний о защищаемых активах — 43 %.
- Отсутствие автоматизации — 40 %.
- Нет понимания бизнес-контекста — 30 %.
- Нет поддержки руководства — 23 %.
- Слишком большое количество алертов — 17 %.
Рисунок 3. Что мешает вашему SOC быть более эффективным?
Блиц: самый недооценённый продукт в SOC
Владимир Дмитриев: «Asset Management — продукт, который обязательно должен присутствовать в SOC, но на сегодняшний день он остаётся самым недооценённым. Все говорят о его важности, но мало кто действительно использует. При этом задача SOC — формировать Asset Management самостоятельно, изучая инфраструктуру с помощью всех доступных сенсоров и других техник».
Евгений Гуляев: «Deception — технология создания цифровых имитаций объектов ИТ-инфраструктуры для выявления злоумышленников, уже проникших в корпоративную сеть. Её главное преимущество в том, что при правильном внедрении она спустя некоторое время даёт очень низкий уровень шума в SOC, что крайне ценно».
Андрей Шаляпин: «EDR (Endpoint Detection and Response) до сих пор недооценён. До сих пор встречается мнение, что начинать нужно с базовых вещей — подключать источники в SIEM, а EDR откладывать на второй этап развития. Хотя на самом деле его роль стоило бы пересмотреть».
Максим Жевнерёв: «Система контроля качества работы детектирующего контента. Важно понимать, что все созданные вами механизмы действительно работают».
Александр Падурин: «Vulnerability Management — управление уязвимостями. Наша практика, особенно за последний год, показывает, что многие SOC приходят с запросом на выстраивание полноценного процесса управления уязвимостями. Это даёт аналитикам важный и полезный контекст по инфраструктуре».
Андрей Тамойкин: «Многие SOC недооценивают инструменты систематизации. База знаний позволяет не только организовать командную работу, но и на базовом уровне заменять собой ряд систем. В ней можно вести собственный Threat Intelligence, хранить библиотеки юзкейсов и правил детектирования, а также плейбуки. Возможно, не на зрелом уровне, но на начальном этапе база знаний вполне справляется с этими задачами».
Какие функции в SOC может выполнять ML?
Александр Падурин поделился опытом своей компании в применении машинного обучения и перечислил задачи, которые уже можно поручить ML. По его словам, это триаж событий, определение ложноположительных срабатываний, оценка критичности инцидента на основе большой базы событий, формирование рекомендаций, а также подбор перечня похожих инцидентов из общей базы — чем эта база больше, тем лучше работает алгоритм.
Александр Падурин, руководитель группы пресейл-менеджеров, Security Vision
Александр Падурин также отметил, что за последний год хорошо зарекомендовала себя ML, позволяющая быстро имитировать отчёты экспертных команд по всему миру. Такие решения способны распарсить отчёты, вычленить индикаторы компрометации, тактики и техники, а затем использовать их на этапе классификации.
Эксперт рассказал о Copilot — большой аналитической модели, которая в рамках SOAR-решения позволяет заменять GPT и задавать вопросы по типам событий, техникам, тактикам и возможным рекомендациям. Ещё одно направление, которое пока находится на этапе тестирования, — ML для расчёта достижимости потенциально скомпрометированных стратегических активов. Он подчеркнул, что для получения точной информации на вход необходимо подавать очень большой объём данных.
Евгений Гуляев напомнил, что все продукты класса UEBA уже давно работают на базе машинного обучения, проверяя статистические отклонения от корректного поведения пользователей. ML работает со статистикой, и с его помощью можно решать задачи, однако обычные формализованные формулы в некоторых случаях показывают себя не хуже. Нужно взвешивать, тот ли эффект мы получаем, который действительно нужен.
Отдельно эксперт остановился на применении AI и LLM для суммаризации инцидентов. Ответственность всегда лежит на аналитике, принимающем решение, поскольку ИИ своими заключениями сильно подталкивает к конкретному выводу, но он может оказаться ошибочным.
Евгений Гуляев, руководитель отдела реализации проектов, R-Vision
Владимир Дмитриев обозначил границы доверия к искусственному интеллекту в SOC. ИИ можно доверять все те задачи, которые сокращают время и трудозатраты аналитика. При этом нельзя делегировать ИИ принятие решений — особенно тех, которые влияют на инфраструктуру и процесс реагирования.
В третьем опросе зрители ответили, как они относятся к использованию ML/AI в SOC:
- Планируют использовать, понимают, какие задачи можно решить с ML/AI — 31 %.
- Не верят в эффективность ML/AI в SOC — 31 %.
- Затруднились ответить — 21 %.
- Уже используют — 9 %.
- Не любят самодеятельность, оставят это вендорам — 8 %.
Рисунок 4. Как вы относитесь к использованию ML/AI в SOC?
Три первых шага для тех, кто строит SOC
Андрей Тамойкин: «Прежде всего необходимо чётко определить, что вы хотите получить от SOC, и спланировать поэтапное развёртывание центра мониторинга либо подключение к MSSP-провайдеру. При этом важно помнить, что помимо технологий существуют процессы — им нужно уделять не меньше внимания».
Александр Падурин: «Отправная точка — понимание критичных для бизнеса процессов. Исходя из этого, мы определяем источники, которые ставим на мониторинг, и выбираем уровень логирования. Для быстрого старта можно использовать EDR-решения».
Максим Жевнерёв: «Нужно понять главное: зачем вы это делаете, кто будет этим заниматься и как вы будете контролировать и измерять эффективность».
Андрей Шаляпин: «Полезно обратиться к коллегам, у которых SOC уже работает, собрать их мнения и на этой основе принимать решения. Эксперты охотно делятся и достижениями, и проблемами — это ценный материал, который не стоит игнорировать на этапе проектирования».
Евгений Гуляев: «В основе любого проекта лежит устав, где собрана вся ключевая информация: какой SOC мы строим, от каких угроз защищаемся, кто ключевые стейкхолдеры. К созданию SOC нужно подходить как к полноценному проекту — если вести его по правильной методологии, ответы на все вопросы появятся сами».
Владимир Дмитриев: «Пробуйте, проверяйте на себе, не пытайтесь сделать сразу всё. Возьмите какую-то часть, на которой сможете проверить гипотезы в реальной работе».
Четвёртый опрос показал, каково мнение зрителей относительно строительства корпоративного SOC после эфира:
- Будут усиливать построенный SOC — 53 %.
- Заинтересовались и будут строить SOC — 19 %.
- Считают интересным, но пока избыточным для себя — 17 %.
- Видят, что придётся многое перестраивать — 7 %.
- SOC не нужен — 2 %.
- Ничего не поняли, о чём сегодня говорили — 2 %.
Рисунок 5. Каково ваше мнение относительно строительства корпоративного SOC после эфира?
Выводы
Построение SOC в 2026 году — это уже не столько технологический вызов, сколько управленческий и организационный. Рынок перешёл от фазы активного внедрения инструментов к фазе их осмысленной эксплуатации, где ключевую роль играют не столько возможности вендорских решений, сколько зрелость процессов и компетенции команды.
Участники эфира сошлись во мнении, что фундамент эффективного SOC закладывается задолго до покупки первой SIEM-системы. Он начинается с инвентаризации активов, наведения порядка в ИТ-инфраструктуре и честного ответа на вопрос, какие бизнес-цели должен закрывать центр мониторинга. Попытка объять необъятное и запустить все процессы одновременно почти гарантированно приводит к провалу — гораздо продуктивнее двигаться фокусно, от одной приоритетной задачи к другой, постепенно наращивая зрелость.
Отдельного внимания заслуживает кадровый вопрос, который остаётся одной из самых острых проблем отрасли. Дефицит аналитиков заставляет искать баланс между автоматизацией, аутсорсингом и развитием собственных специалистов.
При этом искусственный интеллект и машинное обучение, какими бы перспективными они ни казались, сегодня выполняют преимущественно вспомогательную роль, снимая рутину, но не заменяя экспертного принятия решений.
Успех SOC определяет системный подход. Технологии, процессы и люди должны существовать не изолированно, а как единый слаженный механизм, способный адаптироваться к изменениям. Даже имея ограниченные ресурсы, можно выстроить эффективную защиту, если опираться на практический опыт коллег, не бояться пилотировать решения и последовательно двигаться к поставленным целям.
Телепроект AM Live еженедельно приглашает экспертов отрасли в студию, чтобы обсудить актуальные темы российского рынка ИБ и ИТ. Будьте в курсе трендов и важных событий. Для этого подпишитесь на наш YouTube-канал. До новых встреч!
