Марсель Айсин
Руководитель BI.ZONE SOC Consulting
Окончил Московский государственный индустриальный университет (факультет экономики, менеджмента и информационных технологий).
В сфере кибербезопасности — с 2010 года. Начинал инженером в ИТ-интеграторе, а с 2017 года специализируется на сервисах коммерческих центров мониторинга и реагирования на инциденты кибербезопасности (SOC).
В BI.ZONE развивает направление BI.ZONE SOC Consulting, где отвечает за создание и оценку зрелости центров мониторинга с использованием лучших практик и экспертного опыта. Участвует в проектах федерального масштаба по созданию SOC для российских предприятий, а также в зарубежных проектах.
Последние несколько лет стали периодом развития центров мониторинга и реагирования (SOC) и сопутствующих технологий. О роли SOC в обеспечении киберустойчивости бизнеса, трендах развития центров мониторинга и реагирования, способах обоснования расходов на эти подразделения и пользе аудита SOC мы обсудили с руководителем BI.ZONE TDR Андреем Шаляпиным и руководителем BI.ZONE SOC Consulting Марселем Айсиным.
Как бы вы охарактеризовали текущий уровень зрелости рынка SOC в России и СНГ? Изменилось ли восприятие этой функции внутри компаний за последние годы?
А.Ш.: Безусловно. Рынок SOC становится все более зрелым. Мифы и опасения, которые были актуальны еще 5–7 лет назад, постепенно уходят в прошлое. Сегодня все больше компаний понимают, что SOC — это не просто модный элемент инфраструктуры, а важнейшая составляющая бизнеса, без которой риск ущерба, утечки данных или даже потери бизнеса растет с каждым годом. Многие организации дозрели до осознания, что SOC — это не затратная статья, а инструмент, который защищает саму основу бизнеса.
Но такое осознание пока приходит неравномерно. С одной стороны, мы видим зрелых заказчиков с четким пониманием, а с другой — растущий разрыв между объективной необходимостью SOC и реальными действиями бизнеса. Этот разрыв только усиливается на фоне стремительного усложнения ИТ-ландшафта, дефицита кадров, роста геополитических рисков и тотальной цифровизации, когда безопасность становится синонимом устойчивости бизнеса.
Многие компании, когда речь заходит о внедрении SOC, говорят, что они еще недостаточно зрелы, недостаточно интересны злоумышленникам для того, чтобы инвестировать в это подразделение. Как понять, что необходим внутренний SOC?
М.А.: Это очень актуальный вопрос. Часто можно услышать: «Мы недостаточно большие или известные, поэтому до SOC еще не доросли». На самом деле это не вопрос размера или известности компании, а вопрос рисков, комплаенса и готовности управлять безопасностью осознанно.
Во-первых, важно понять, что SOC — это не точка старта, а логичное продолжение развития кибербезопасности. Если на базовом уровне она уже выстроена, SOC — естественный следующий шаг. Во-вторых, нужно решить, какие риски вы планируете снизить с помощью SOC. Например, можно однозначно сказать, что SOC становится необходимостью, если:
- Ваш бизнес сильно зависит от инфраструктуры, и потери или простой недопустимы.
- У вас есть критические данные (персональные данные, коммерческая тайна, интеллектуальная собственность и т. д.).
- Вы уже сталкивались с инцидентами, но реагирование выглядело как набор хаотичных действий, и ущерба можно было избежать.
- Вы регулярно расширяете ИТ-инфраструктуру (новые облака, новые филиалы, новые приложения и т. д.), и нет понимания, что действительно в ней происходит.
Что касается тезиса «недостаточно интересны злоумышленникам», не стоит забывать, что интересы злоумышленников бывают разные. Основной мотивацией остаётся финансовая выгода, но постоянно растет количество атак, цель которых шпионаж и хактивизм. И мы видим, что последствия атак приобретают другой масштаб для компании: речь идет о простое (до нескольких недель), колоссальных затратах на восстановление, рисках для контрагентов и даже падении стоимости акций на бирже.
В продолжение предыдущего вопроса: размер инвестиций в SOC составляет достаточно большую сумму. Бизнес не очень любит обоснование затрат через непонятную для него метрику предотвращенных инцидентов. Атаки на коллег и конкурентов из отрасли тоже редко работают. Что еще можно привести как обоснование затрат?
М.А.: Позволю не согласиться: атаки на коллег, конкурентов, поставщиков очень отрезвляют. Информация о серьезных киберинцидентах часто попадает в публичное пространство. И это заставляет задуматься тех, кто раньше считал, что «мы-то хакерам совсем неинтересны». Для многих компаний, в том числе наших клиентов, атака на одного из игроков отрасли становится звоночком, что пора серьезно вкладываться в кибербезопасность. У нас есть услуга BI.ZONE Compromise Assessment: мы детально проверяем инфраструктуру клиента на компрометацию и наличие следов злоумышленников. Как правило, выявленные инциденты и мисконфигурации дают почву для размышлений о необходимости SOC — собственного или в виде услуги.
Для бизнеса метрика предотвращения атак действительно бывает непонятной, и аргумент «мы отразили более 100 атак за месяц» мало что скажет. Но если говорить на языке бизнеса с позиции, что SOC — инструмент для управления рисками, что он защищает операционную деятельность (клиентские сервисы, производство и т. д.) от простоев, штрафов и репутационных потерь, то восприятие руководства компании меняется.
Центр мониторинга и реагирования — это в первую очередь актив, а не просто статья расходов. Киберриски — материальная угроза, а потенциальный ущерб от простоя или утечки можно просчитать в деньгах. И SOC — это механизм, который напрямую снижает вероятность и размер этого ущерба. Таким образом, его работа напрямую влияет на сохранность капитала компании. А значит, это инвестиция в бизнес-устойчивость. Как и любой актив, SOC требует грамотного управления и оценки эффективности.
Есть ли интересные кейсы, когда SOC, построенный по всем стандартам, не «взлетал»? Что к этому привело и можно ли было этого избежать?
А.Ш.: Есть много нюансов, без понимания которых не получится грамотно оценить требуемые ресурсы, инвестиции, компетенции при создании SOC. Одна из частых причин: центр мониторинга воспринимается как набор коробочных решений, который можно купить по красивой презентации, с четырьмя блоками: SIEM, EDR, SOAR и немного Threat Intelligence.
Многие мыслят абстрактными маркетинговыми схемами: на них изображены 3–4 ключевых компонента технологического стека, и это представлено как инфраструктура SOC. На деле же подводная часть айсберга — это десятки невидимых, но критически важных компонентов и процессов. Про них, как правило, не говорят на уровне идеи. Это всевозможные шины данных, системы контейнеризации, сложные технические обвязки вокруг SIEM, системы мониторинга ИТ-инфраструктуры и т. д.
Тот же принцип касается команды: чтобы SOC действительно работал, а не просто красиво выглядел на схеме, нужно не 1–2 универсальных инженера, как думают в 90% случаев, а целое подразделение технических специалистов разных профилей. Это не просто «аналитики трех уровней», а специалисты по Threat Hunting, форензике, реверс-инжинирингу, контент-разработчики для SIEM, специалисты по Threat Intelligence, архитекторы процессов, специалисты по автоматизации и другие. И у каждого своя зона ответственности, свои процессы, свои KPI.
Когда пошел тренд на строительство SOC, многие компании рассуждали следующим образом: купим SIEM, доработаем правила из коробки, посадим пару аналитиков, и это нас спасет от атак хакеров. Спустя несколько лет мы видим, что SOC — это не только подключение источников и настройка правил. Насколько четко заказчики сейчас понимают и осознают это? Или многие до сих пор живут парадигмой прошлого?
М.А.: Не могу подтвердить, что рынок живет парадигмой прошлого. Действительно, мы прошли многолетний путь от SIEM к SOC: компании уже поняли, что специализированные технологии — это лишь часть SOC, для эффективной защиты необходимо собирать команду и выстраивать операционную деятельность.
Сейчас рынок на следующей стадии принятия: многие воспринимают SOC как еще одну команду исполнителей, группу операторов, которые получают заявки, обрабатывают их и успешно закрывают. Такой подход часто становится ловушкой для топ-менеджмента. Когда бизнес смотрит на SOC только как на команду операторов, обрабатывающих заявки, он вкладывается лишь в реакцию на угрозы, а не в предупреждение. Но реальная ценность центра мониторинга в том, чтобы предупреждать атаки, оптимизировать затраты и защищать репутацию компании.
Сегодня SOC — это уже мозг кибербезопасности компании, а не просто ее руки. Речь идет не только о «тушении», а об анализе причин «возгорания», укреплении систем «сигнализации и пожаротушения», обучении персонала, чтобы такие ситуации не повторялись. То есть SOC должен работать не только в моменте. Он обеспечивает долгосрочную устойчивость, помогает компании развиваться безопасно, а не просто выживать.
На профильных конференциях отмечается, что одна из самых горящих проблем SOC — кадры. При этом речь даже не о поиске новых людей, а о выгорании существующих. Для внутреннего SOC эта проблема еще критичнее. Если у MSSP заказчик может попросить заменить неэффективного аналитика, то внутри так не получится. Плюс требуется время на поиск нового человека. Есть ли успешные практики по борьбе с выгоранием людей? Поможет ли ротация персонала внутри управления кибербезопасности или геймификация процесса?
А.Ш.: Если вы просто нанимаете все больше аналитиков, чтобы вручную разбирать больше алертов, вы не строите SOC — вы строите самую дорогую фабрику по перекладыванию ложных срабатываний в мире. В любом SOC жизненно необходимо постоянно искать точки оптимизации и сокращения рутины за счет внедрения механизмов автоматизации. Не стоит рассматривать ее как инструмент замены конкретных ролей. В первую очередь автоматизация помогает сделать процессы более качественными, быстрыми, эффективными, сместив фокус с рутины на более интеллектуальные задачи.
Если мы посмотрим на этапы обработки событий (событие, алерт, инцидент), то увидим, что практически на каждом этапе есть очень много точек оптимизации, где хорошо сочетаются как классические подходы к автоматизации, так и с применением ИИ. Например, мы можем существенно сократить количество алертов, обрабатываемых вручную. С одной стороны, это сценарии, которые автоматически преобразуют алерты в инцидент; с другой — использование ИИ для закрытия ложноположительных срабатываний.
Аналогично можно оптимизировать анализ и обработку тикетов (инциденты, которые возвращаются обратно на операционные линии), автоматизацию проверки качества карточек (описание инцидентов), пояснение различных аспектов в контексте сработавшего правила корреляции (пояснение командных строк) и т. д.
Когда мы системно ищем точки автоматизации процессов с большим количеством рутинных задач, мы в том числе решаем проблему выгорания специалистов, повышаем эффективность их работы.
Андрей Шаляпин
Руководитель BI.ZONE TDR
Окончил Сибирский государственный аэрокосмический университет им. М. Ф. Решетнёва (ныне Сибирский государственный университет науки и технологий) по специальности «комплексное обеспечение информационной безопасности автоматизированных систем».
Начал карьеру в сфере кибербезопасности в 2014 году, став инженером на одной из крупнейших гидроэлектростанций России и мира — Красноярской ГЭС. Спустя несколько лет перешёл на позицию CISO.
Более 6 лет специализировался на управлении кибербезопасностью, выстраивании процессов, а также проведении комплексных технических аудитов корпоративных и технологических сетей.
Параллельно преподавал на кафедре «компьютерная безопасность» в Сибирском федеральном университете (СФУ).
В BI.ZONE пришёл руководителем внутренних проектов BI.ZONE TDR, а теперь возглавляет сам сервис.
Чем должен заниматься SOC, чтобы он не только помогал «тушить пожары» в моменте, но и обеспечивал долгосрочную киберустойчивость бизнеса?
А.Ш.: В зрелом SOC около 30 процессов. Непрерывное обнаружение, анализ и реагирование — это ядро центра мониторинга, но лишь часть экосистемы. Эффективный SOC невозможен без таких процессов, как:
- регулярный анализ покрытия инфраструктуры мониторингом;
- разработка и улучшение детектирующей логики;
- применение данных об угрозах (threat intelligence) для их обнаружения и разработки детектирующей логики.
Также важную роль играют проактивный поиск угроз (threat hunting), поддержание и оптимизация SOC-технологий, наличие инструментов и отработанный алгоритм реагирования на конечных устройствах и в инфраструктурных системах. Не менее значимо взаимодействие с red team, обучение и онбординг аналитиков, готовность к масштабным инцидентам, документирование и управление знаниями.
Все эти элементы формируют замкнутый цикл — от обнаружения угроз до постоянного улучшения защиты, превращая SOC из просто операционного центра в ключевой элемент киберустойчивости организации.
Как компании понять, что ее SOC развивается в правильном направлении? Какие есть инструменты для этого — чек-листы, аудиты?
А.Ш.: Лучший инструмент — аудит SOC. Он показывает, что действительно выявляется, а что остается в слепой зоне, будут ли плейбуки и процессы эффективно работать в кризисной ситуации, хватает ли автоматизации, где происходит перерасход бюджета без роста эффективности и т. д. С точки зрения бизнеса аудит позволяет показать топ-менеджменту, что SOC — это не просто «дорогая игрушка», а высокотехнологичный актив, эффективность которого можно измерить. Это помогает аргументировать инвестиции, сравнивать показатели с отраслевыми стандартами, понимать ROI от безопасности.
С точки зрения самого SOC аудит — это инструмент саморазвития. Он помогает увидеть узкие места, то есть дает понимание, где центр мониторинга теряет эффективность и куда стоит развиваться дальше. Я бы сказал, что грамотный аудит превращается в зеркало для SOC: он помогает увидеть, что работает, а что — нет.
Если воспринимать аудит как формальность, пользы не будет. Но если рассматривать его как инструмент управления, то он становится драйвером развития. SOC — дорогой, сложный, технологически насыщенный механизм. Без периодического аудита он теряет эффективность, а вместе с этим и доверие бизнеса. Аудит позволяет говорить с руководством на одном языке: не «нам нужно больше ресурсов», а «инвестиции вот в это принесут наибольшую отдачу». Это качественно другой разговор.
Как именно устроен аудит? Что проверяют аудиторы, как смотрят на процессы и чем руководствуются?
М.А.: Приведу конкретный пример, как один из ключевых процессов в SOC оценивается нами при аудите. Речь об управлении правилами обнаружения угроз. При аудите этого направления нужно оценить целую систему процессов:
- разработка и тестирование правил обнаружения;
- управление наборами (репозиториями) правил;
- ведение бэклога предложений по созданию новых правил;
- анализ и поддержка окружения для их разработки;
- работа с сигнатурами, сетевыми и YARA-правилами, другими артефактами детектирования.
Важно, что анализ проводят эксперты, которые сами ежедневно занимаются в SOC от BI.ZONE разработкой правил обнаружения угроз и управлением ими. Это позволяет нам не только оценить, как устроен процесс по формальному признаку, но и увидеть, как он выглядит в действии: смотрим архитектуру самих правил, реализацию процесса в системах и т. д.
Кроме того, мы оцениваем процессы как комплексно, так и по отдельности. Идем примерно по следующему чек-листу:
- Кто на самом деле задействован и отвечает за контент-инжиниринг, рецензирование, утверждение и эксплуатацию.
- Есть ли регламенты, пайплайны, инструменты контроля версий и тестирования, насколько их описание соответствует реальности.
- Как устроен жизненный цикл правил: от идеи или гипотезы до вывода из эксплуатации.
- Есть ли установленные сроки (SLA), предусмотрена ли процедура экстренного внедрения новых детектов в обход стандартного цикла при появлении критических угроз.
- Ведётся ли описание логики правил, условий срабатывания, зависимостей, источников данных.
- Насколько полно зафиксированы все необходимые логи, поля и настройки аудита.
- Ведётся ли обогащение правил метаданными: указание критичности, категории, владельца, мэппинга MITRE ATT&CK и других классификаторов.
- Соблюдается ли версионность: используются ли системы контроля версий и принципы change management при изменении правил.
- Как происходит вывод правил из эксплуатации: предусмотрен ли процесс ревизии и снятия устаревших детектов.
Кто эти самые аудиторы? И как понять, что им можно доверить свою инфраструктуру и процессы?
М.А.: Далеко не все аудиторы SOC способны оценить его эффективность. При выборе важно смотреть не только на знание стандартов и методик, но и на практический опыт построения и эксплуатации SOC. Хороший аудитор должен понимать, как процессы работают на практике, а не на бумаге — от мониторинга и детектирования до реагирования, автоматизации и анализа угроз.
Проверка должна проводиться с опорой на реальные сценарии работы, а не только чек-листы. Важно, чтобы аудитор мог не просто указать на несоответствия в конкретном направлении, а посмотреть на работу SOC комплексно, при этом предложить конкретные рекомендации по улучшению. Идеальный аудитор — это партнер, который помогает не пройти аудит, а сделать SOC более сильным и зрелым с точки зрения процессов, технологий и людей.
Марсель, Андрей, благодарю за интересную и познавательную беседу. Удачи и развития вашей компании!









