Новость · 3 декабря 2025

6 ноября прошел вебинар «Промышленный SOC. Инструкция по применению», на котором эксперты УЦСБ SOC рассмотрели недопустимые события на производстве, рассказали о выстраивании мониторинга ИБ на промышленных предприятиях, а также поделились примерами атак.

Участники вебинара активно задавали спикерам вопросы, на самые интересные из них отвечаем в этом FAQ.

1) Как монетизировать репутационные потери для руководства?

Репутационные потери можно монетизировать через сценарный и количественный подходы, которые выражаются в потере части клиентов или снижении объемов производства и поставок. Чтобы перевести репутационные потери в конкретные финансовые показатели, проанализируйте среднемесячные, квартальные или годовые показатели производства совместно с производственными и коммерческими подразделениями.

При этом важно учитывать не только прямые убытки, но и косвенные последствия. Например, ухудшение отношений с ключевыми контрагентами, партнерами, заказчиками или даже с вышестоящими структурами и регуляторами. Такие сценарии часто оказываются более значимыми, чем потеря выручки, поскольку они влияют на стратегическую устойчивость компании.

Таким образом, обоснование должно быть комплексным. С одной стороны, расчет конкретных финансовых потерь, с другой — качественный анализ того, как репутационные риски могут сказаться на взаимодействии с ключевыми стейкхолдерами и управленческими структурами.

2) Какие ключевые компоненты должны входить в современную инфраструктуру SOC?

Ключевые компоненты современной инфраструктуры SOC зависят от конкретных задач по мониторингу, но базовый набор элементов остается неизменным.

Основой является SIEM-система — инструмент, который собирает, нормализует и анализирует события безопасности из различных источников: сетевого оборудования , рабочих станций, серверов, а также внутренних программных решений компании. Главное требование — способность систем и сервисов формировать журналы событий, которые SIEM может обрабатывать для выявления инцидентов.

Следующий важный компонент — SOAR/IRP-платформа, объединяющая функции автоматизации реагирования и управления инцидентами. Она обеспечивает обработку инцидентов на всех этапах их жизненного цикла — от поступления алерта и подтверждения инцидента до его расследования и закрытия. Такой системный подход позволяет снизить влияние человеческого фактора, сократить время реакции и минимизировать потенциальный ущерб.

Кроме того, в инфраструктуру SOC могут входить IDS/IPS-системы, EDR-решения, а также различные дополнительные источники информации. Например, средства для выявления мошеннических активностей или внешние Threat Intelligence-сервисы.

Важно помнить, что проектирование архитектуры SOC — сложная и ресурсозатратная задача. Оптимальный подход предполагает консультации с профильными экспертами, чтобы избежать избыточных закупок неиспользуемых инструментов и обеспечить наличие действительно необходимых компонентов, которые будут эффективно задействованы в инфраструктуре.

3) Как обеспечить соответствие SOC требованиям нормативных актов и стандартов безопасности?

Для обеспечения соответствия требованиям нормативных актов и стандартов безопасности необходимо руководствоваться действующими регламентами и выстраивать взаимодействие с уполномоченными государственными органами.

Основным документом для технологических сегментов является Федеральный закон № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации». В соответствии с ним, SOC должен иметь соглашение о взаимодействии с регулятором. Например, с Национальным координационным центром по компьютерным инцидентам. Наличие такого соглашения подтверждает, что регулятор доверяет SOC функцию выявления и реагирования на компьютерные инциденты и атаки.

Кроме того, при построении и эксплуатации SOC следует оринетироваться на стандарты, ГОСТы и лучшие практики. Например, ГОСТ Р 59547, который устанавливает основные правила и процедуры мониторинга информационной безопасности.

4) Кому подходит модель аутсорса SOC, и когда становится выгоднее строить его внутри компании?

Аутсорсинговый SOC оптимален для компаний, которые только начинают выстраивать процессы мониторинга информационной безопасности и не имеют в этом опыта. Создание собственного центра — сложный и ресурсоемкий процесс, который требует глубокой экспертизы, выстроенных регламентов и квалифицированного персонала. Поэтому на начальном этапе целесообразно воспользоваться полным аутсорсингом SOC, получая готовый сервис по выявлению и уведомлению об инцидентах и атаках.

По мере роста зрелости компании и накопления внутренней компетенции можно переходить к гибридной модели. При таком формате часть функций SOC выполняется своими силами, а остальное остается у внешнего поставщика.

Построение внутреннего SOC становится оправданным, когда компания достигает достаточного уровня зрелости, обладает ресурсами, устойчивыми процессами, а содержание собственной команды экономически целесообразно.

Следует отметить, что даже крупные организации с развитой инфраструктурой нередко выбирают гибридный формат. Квалифицированных специалистов по кибербезопасности не хватает, а высокая нагрузка и выгорание персонала делают полный инсорсинг менее устойчивым. Зачастую форензика, разработка правил коррелляции и киберразведка отдаются исполнителю.

5) Приведите реальный кейс, когда субъект был привлечен в административной ответственности за неуведомление о киберициденте либо нарушении срока уведомления?

УЦСБ не допускал подобных ситуаций. В открытом доступе нет подтвержденных случаев привлечения к ответственности по данным основаниям. Однако это не исключает, что такие прецеденты могли быть. Практика по киберинцидентам, особенно в контексте КИИ, не афишируется и крайне редко попадает в публичные источники.

6) Кто должен взаимодействовать с внешним SOC со строны Заказчика?

Возможны разные варианты взаимодействия. Однако оптимальна модель с назначением единого координационного лица со стороны Заказчика, чаще всего специалиста по информационной безопасности.

Технически регламент реагирования предусматривает обращение к администраторам ИТ-систем. Первая линия внешнего SOC получает контакты ответственных лиц, перечень обслуживаемых активов, режимы работы и т.д. В этом случае SOC взаимодействует с конкретными специалистами по каждому инциденту, направляя им уведомления и запросы через личный кабинет или другие каналы связи.

Как показывает практика, важно, чтобы ответственный со стороны Заказчика координировал все действия. Атаки часто затрагивают несколько информационных систем, требуя согласованных шагов по реагированию.

За каждой информационной системой важно закрепить ответвтенного за администрирование и владелеца, принимающего решения о критических действиях. Например, об остановке сервера или отключении хоста. Такое разграничение необходимо, чтобы избежать самостоятельных решений ИТ-персонала, способных привести к остановке бизнес-процессов и дополнительным убыткам.

Поэтому взаимодействие с аутсорсинговым SOC целесообразно возложить на специалиста по информационной безопасности и подключать ИТ-службы для технической реализации мер реагирования.

7) Какие основные вызовы стоят перед SOC при обнаружении и реагировании на сложные кибератаки?

При обнаружении и реагировании на сложные кибератаки современный SOC сталкивается с вызовами, связанными с масштабом и сложностью инфраструктуры, объемом данных и сокращением времени на реакцию.

Одной из ключевых проблем является большое количество информационных систем и недостаток информации о них. Из-за постоянных изменений в инфраструктуре, процессов импортозамещения и появления новых решений у аналитиков SOC не всегда есть полная картина происходящего. В таких случаях требуется оперативное стендирование и тестирование — моделирование атак, анализ возникающих событий и быстрый выпуск правил детектирования, чтобы сократить время реагирования.

Еще один серьезный вызов — огромный объем данных для анализа. Обрабатывать все вручную уже невозможно, поэтому для выполнения рутинных задач важно использовать средства автоматизации, включая искусственный интеллект и нейросети. При этом принятие ключевых решений должно оставаться за экспертами, а автоматизация должна высвобождать их время для анализа действительно критичных инцидентов.

Кроме того, с каждым годом сокращается время реализации атак — злоумышленники действуют все быстрее. SOC остается все меньше времени для предотвращения или локализации угрозы. Все большее значение приобретают проактивные методы защиты, позволяющие выявлять угрозы еще на стадиях разведки и подготовки к атаке, до того, как начнется воздействие на инфраструктуру.

Таким образом, современные SOC сталкиваются с комплексом вызовов — от нехватки информации и высокой нагрузки до необходимости опережать противника во времени. Решением становится сочетание автоматизации, постоянного анализа инфраструктуры и проактивного мониторинга.

8) Какие метрики и показатели эффективности наиболее важны для оценки работы SOC?

Оценка эффективности работы SOC основывается на системе метрик, которые позволяют контролировать качество мониторинга, своевременность реагирования и общую результативность процессов.

Существует набор базовых показателей, которые применяются во всех центрах мониторинга. К ним относятся:

• соблюдение SLA — время обнаружения и обработки инцидентов;
• общее время простоя сервисов;
• объем ложноположительных сабатываний;
• количество поступающих событий и инцидентов за определенный период;
• уровень покрытия инфраструктуры мониторингом.

Эти метрики являются универсальными и описаны во многих профессиональных публикациях и отраслевых стандартах. На их основе можно получить базовую оценку эффективности SOC.

Далее подключаются специфические метрики, которые зависят от особенностей конкретного предприятия и его бизнес-процессов. Для производственных компаний это может быть время простоя производства, для финансовых организаций — ошибки транзакций, для IT-инфраструктуры — доступность ключевых сервисов. Такие показатели настраиваются индивидуально в процессе эксплуатации SOC, исходя из того, какие параметры наиболее значимы для Заказчика.

При этом важно не ограничиваться подсчетом количественных показателей. Необходимо также контролировать, чтобы инциденты, выявленные SOC, действительно обрабатывались и доводились до завершения. Довольно часто уведомления об угрозах формируются корректно, но долго остаются без реакции ответственных групп реагирования. Это напрямую влияет на реальную эффективность противодействия кибератакам.

Таким образом, эффективная система метрик SOC должна сочетать универсальные показатели SLA и качества мониторинга с индивидуальными метриками, отражающими специфику бизнеса, и сопровождаться контролем полноты и скорости обработки инцидентов.

9) Какие процессы необходимо выстроить до подключения к SOC?

Мониторинг необходим в любой инфраструктуре, даже если в компании уже выстроены все остальные процессы информационной безопасности. Абсолютно защищённых систем не существует. Со временем настройки теряют актуальность, появляются новые уязвимости и атаки нулевого дня. Злоумышленники постоянно совершенствуют свои методы, поэтому даже идеально настроенная система защиты нуждается в постоянном мониторинге, который позволяет своевременно выявлять новые угрозы и реагировать на них.

Отсутствие формализованных процессов управления активами, правами доступа или патч-менеджмента усложняет работу SOC, но не делает ее бессмысленной. Напротив, подключение к SOC часто становится стимулом для наведения порядка в инфраструктуре. На этапе постановки систем на мониторинг проводится инвентаризация, выявляются неиспользуемые или дублирующиеся ресурсы, теневое ИТ, сегментируется сеть, устанавливаются зоны ответственности.

В процессе совместной работы с SOC постепенно формируются необходимые организационные механизмы — назначаются ответственные за инциденты, уточняются владельцы активов, закрепляются внутренние регламенты реагирования. Таким образом, даже если изначально процессы управления не выстроены идеально, мониторинг помогает выявить проблемные зоны и создать базовый уровень управляемости и прозрачности.

SOC не только обеспечивает обнаружение атак, но и способствует формированию зрелой системы управления безопасностью, упорядочивая внутренние процессы и распределение ответственности.

10) Каким образом SOC проводит обучение персонала (теоретическое обучение или прямо имитация инцидента)?

SOC проводит комплексное обучение сотрудников. В систему обучения входят следующие теоретические и практические мероприятия:

• обязательное теоретическое обучение — ежегодные курсы для всего персонала;
• обязательное изучение плейбуков и регламентов для новых сотрудников;
• внутренние вебинары и лекции от наиболее опытных сотрудников уровня L3;
• использование плейграундов для имитации атак и разработки правил в учебных целях;
• практические занятия с разными ролями — Blue Team и Red Team;
• наставничество для сопровождения новых аналитиков на всех этапах обучения;
• обучение аналитиков первой линии на тестовых стендах до выхода в продуктивную среду.

11) Как повысить уровень обнаружения и предотвращения угроз? Почему большинство SOC не способны обнаружить и остановить современные сложные кибератаки, и что нужно изменить в их концепции?

Чтобы повысить уровень обнаружения угроз необходимо обеспечить контроль и развитие следующих показателей:

• покрытие инфраструктуры мониторингом ИБ;
• обогащение мониторинга актуальными идентификаторами компрометации;
• разработка правил детектирования актуальных атак.

Предотвращение угроз подразумевает формирование целей обеспечения кибербезопасности и реализацию этих целей. Например, с помощью харденинга, применения средств защиты информации или организационных мер. У современных SOC есть все чтобы обнаруживать сложные кибератаки. Например, с помощью команды киберразведки УЦСБ SOC способен обнаружить коммуникацию злоумышленников в даркнете еще на стадии подготовки к атаке или обнаружить слитые учтены записи до использования в атаке. Важно помнить, что любая атака — это многосоставной вектор. SOC не обязательно видеть абсолютно все шаги атаки, но желательно видеть первые.

12) Какие ограничения принимались в кейсах для СОВ?

В случае применения систем предотвращения вторжений (IPS) необходимо писать правила по автоматическому блокированию, обходя ключевые коммуникации, которые напрямую влияют на критические функции. Для критичного функционала должен быть пассивный мониторинг, посредством которого аналитики проводят анализ алертов и в рамках SLA приходят с решением к группам реагирования. Таким образом, можно избежать остановки бизнес-процессов из-за ложных сработок.

13) Есть ли кейсы по выстраиванию реагирования через SIEM-системы для источников SCADA, PLC?

УЦСБ SOC имеет опыт как мониторинга, так и внедрения SIEM в технологическом сегменте в различных отраслях промышленности. В частности, с помощью SIEM анализируются события со SCADA и PLC на предприятиях нефтегазовой отрасли, в генерации электроэнергии, а также на предприятиях черной металлургии среди крупнейших производителей РФ.

14) Какие меры принимать в отношении персонала, который успешно или неуспешно прошел обучение?

Обучение персонала — обязательная часть стратегии кибербезопасности предприятия. Для технического персонала, связанного с ИТ и ИБ, обучение проводится регулярно и включает как теоретическую, так и практическую части, с обязательной планеркой для закрепления навыков.
Для сотрудников, успешно прошедших обучение, возможны регулярные обновляющие курсы и участие в более сложных практических сценариях. Для тех, кто не справился с обучением, применяются программы Security Awareness и дополнительные занятия для повышения уровня знаний и навыков. Такой подход позволяет поддерживать необходимый уровень компетенций и формировать культуру безопасности в компании. Мы можем правильно организовать реагирование, если у нас есть информация о реакции сотрудника на фишинг. Например, присваивать инцидентам разные уровни критичности в соответствии с уровнем киберосознанности сотрудников.

15) Как автоматизация и искусственный интеллект меняют работу SOC и повышают его
эффективность?

В УЦСБ SOC реализуется стратегический план автоматизации всех этапов работы аналитиков и инженеров.
Базовый этап включает внедрение современных платформ IRP/SOAR, что позволяет автоматизировать до 90% первичной обработки инцидентов по сравнению с предыдущими поколениями ПО.
Кроме того, используется цифровой ассистент на базе больших языковых моделей, который обеспечивает автоматизацию рутинных действий аналитиков, таких как:

• парсинг больших данных;
• написание правил корреляции для detection-инженеров;
• консультативное сопровождение младшего персонала;
• подготовка аналитических отчетов.

ИИ помогает снижать количество ложноположительных срабатываний, выявлять аномалии и формировать предварительный вердикт по инцидентам.
Внедрение цифрового ассистента позволяет ускорить обработку запросов аналитиков, повысить точность детекции и улучшить адаптацию младшего персонала. При этом критически важна правильная первоначальная настройка ИИ для обеспечения его эффективной работы.

16) Почему обнаружение атаки на ранней стадии важнее, чем работы по предотвращению атак?

Есть мнение, что предотвращение атак должно быть приоритетом. Однако в современной кибербезопасности фокус смещен. Современный подход строится на предположении, что взломы неизбежны, и организация должна быть к ним готова.
Обнаружение атак на ранней стадии не заменяет предотвращение — они являются частью единой стратегии. Тем не менее, сделать ставку только на предотвращение технически невозможно и стратегически ошибочно. Раннее обнаружение выполняет роль страховочной сетки и системы оповещения, компенсируя неизбежные пробелы в предотвращении атак.

17) Почему большинство SOC не справляются с масштабом и скоростью современных
угроз, и как это исправить? Какие кардинальные изменения нужны в культуре и
организации SOC для борьбы с эволюционирующими киберугрозами?

На первый взгляд, архитектура SOC выглядит простой — технологии, процессы, люди. Однако каждая из этих частей включает множество инструментов, решений и требований к квалификации команды.
Скорость изменения технологий часто не успевает за появлением остро актуальных угроз. Регулярно ведется деятельность по детектированию и проактивному реагированию. Но текущий ландшафт угроз настолько обширен, что полностью покрыть его невозможно.
Внедрение автоматизации значительно расширяет возможности SOC, но и этого не всегда достаточно. Применение ИИ, который выполняет целые блоки процессов SOC, позволяет эффективно выстраивать проактивную работу по оценке и приоритизации угроз.
Кардинальных изменений в культуре SOC в ближайшее время не предвидится, так как многие процессы пока не поддаются полной автоматизации и требуют участия высококвалифицированных специалистов. Тем не менее, проактивное сканирование и приоритезация угроз в зависимости от изменения ландшафта угроз уже реализуются и позволяют повысить эффективность Центров мониторинга инцидентов ИБ.

18) Почему в примерах нет ситуации с Аэрофлот?

Невозможно рассмотреть все возможные кейсы, для вебинара мы подобрали различные примеры. Кроме того, из уважения к коллегам из различных отраслей российской промышленности и транспорта мы не выносим на публичное обсуждение конкретные ситуации, с которыми может столкнуться каждая компания.

19) Как бороться с уязвимостями, которые активно используются хакерами, если нет возможности обновить ОС из-за несовместимостью новых версий ПО с промышленным оборудованием?

Отсутствие возможности обновлений — распространенная, но опасная ситуация. Если уязвимость не может быть устранена в источнике, задача — создать максимальное количество барьеров между ней и злоумышленником.

Стандартное решение — применение компенсирующих мер, обычно через наложенные средства защиты информации. Примеры таких мер:

1. Полная сетевая сегментация и установка промышленного фаервола — без этого остальные меры будут малоэффективны.
2. Многофакторная аутентификация для всех точек входа и регулярное изолированное резервное копирование.
3. Усиление защиты ОС и внедрение систем мониторинга OT/ICS для обнаружения атак.
4. Обучение персонала, четкие регламенты и регулярный аудит безопасности.

Важно понимать, что эти меры не делают систему полностью безопасной. Они лишь существенно повышают сложность для злоумышленника и снижают вероятность успешной атаки.

20) Как оценивать эффективность работы SOC, какие метрики вы используете?

Оценка эффективности SOC — сложная задача. Со стратегической и технической точек зрения — это внутренняя эффективность процессов SOC.С точки зрения Заказчика — ценность услуги, управление рисками и финансовая прозрачность. Метрики должны быть понятны бизнесу, а не только технологам.

В большинстве SOC используются типовые метрики.

1.SLA Compliance Rate (Соблюдение Соглашений об Уровне Сервиса)
Что измеряем: процент инцидентов и задач, выполненных в соответствии с SLA.
Зачем: выполнение SLA гарантирует заказчику предсказуемость и стабильность сервиса, низкий показатель сигнализирует о проблемах в качестве сервиса или планировании ресурсов.
2.Coverage Rate (Коэффициент покрытия телеметрией)
Что измеряем: процент критических активов и событий безопасности, от которых поступают логи и телеметрия в необходимом объёме и качестве.
Зачем: оценивает зрелость архитектуры сбора данных и наличие «слепых зон», где могут действовать злоумышленники. Важно учитывать не только факт подключения, но и полноту данных, отсутствие ошибок парсинга и релевантность источников для модели угроз.
3.MTTD / MTTR / Dwell Time
Что измеряем: среднее время между началом атаки и её обнаружением/оповещением аналитиком или SIEM.
Зачем: оценивает эффективность детектирующих правил, корреляционных сценариев в SIEM и SOAR.

Также в УЦСБ SOC используется широкий набор дополнительных показателей, позволяющих оценивать эффективность сложных внутренних процессов и соответствовать требованиям Заказчиков с учетом специфики и отрасли.

21) Какие скрытые уязвимости и слабости в текущих моделях SOC позволяют злоумышленникам обходить защиту?

Современный SOC часто ориентируется на реакцию на уже известные тактики и правила корреляции. К основным скрытым уязвимостям и слабостям относят:

1. Ограничения телеметрии — неполное покрытие источников данных, слабый аудит или недостаточный контроль за их доступностью.
2. Тактики обхода детектирования — злоумышленники маскируют действия под легитимный трафик или используют новые комбинации техник, которые не охватываются текущими правилами.
3. Недостатки корреляции и контекста — разрозненные данные затрудняют выявление сложных многоэтапных атак.
4. Операционные сложности — усталость аналитиков и перегрузка событиями снижают эффективность обнаружения.
5. Недооценка Threat Hunting — многие SOC пренебрегают проактивным поиском угроз, ограничиваясь реактивной работой по срабатыванию правил.

В результате современные сложные атаки часто обнаружены постфактум, когда срабатывают известные корреляционные правила, а не в момент их начала.

Способы повышения эффективности SOC:

• внедрение проактивного Threat Hunting и активного поиска угроз для выявления неизвестных тактик и техник;
• обогащение телеметрии и контекста из дополнительных источников данных;
• использование вендорской экспертизы и готовых правил для обнаружения сложных атак;
• совмещение реактивного мониторинга с проактивной аналитикой, моделированием сценариев атак и тренировкой аналитиков на сложные кейсы.

Современный SOC способен не только реагировать, но и проактивно обнаруживать и предотвращать сложные кибератаки, если сочетать мониторинг, Threat Hunting и экспертные инструменты.

22) Сколько раз атаковали именно вас? Были ли последствия для ваших заказчиков?

УЦСБ SOC, как и инфраструктура наших Заказчиков, регулярно сталкивается с попытками несанкционированного доступа и кибератак. Подробности таких инцидентов и их последствия не раскрываются в публичном поле из соображений безопасности и конфиденциальности.

23) Какие стратегии используются для быстрого реагирования на инциденты и минимизации ущерба? Почему большинство SOC сосредоточены на реагировании, а не на предвидении и предотвращении атак?

Для быстрого реагирования на инциденты SOC использует несколько ключевых стратегий:

• проработанные сценарии реагирования — все шаги при кибератаке чётко прописаны и понятны участникам;
• распределение ролей и назначение ответственных — каждый знает, какие действия он выполняет по сценарию;
• доступность и изучение сценариев — ответственные должны иметь возможность оперативно использовать инструкции при инциденте;
• отслеживание SLA по выявлению и реагированию на инциденты — своевременное информирование всех участников о ситуации и плане действий.

Такая организация позволяет действовать максимально оперативно, так как каждая минута увеличивает риск продвижения злоумышленника и накопления ущерба.
SOC также занимается предвидением атак через киберразведку (TI). Однако корректно определить атаки на этапе разведки не всегда возможно из-за «шума» в киберпространстве. Команда TI выявляет новые типы атак и группировки, а ИБ-команда Заказчика получает обнаруженные признаки компрометации и методики атак для оптимизации защиты и предотвращения инцидентов.

24) Надо ли как-то закреплять полномочия специалиста, который реагирует на мониторинг? Насколько широкими должны быть его полномочия?

Безусловно, важно закреплять не только полномочия, но и обязанности специалистов. В компании могут быть несколько групп реагирования, разделённых по информационным системам.

В группе реагирования рекомендуется разделять роли:

1. Владелец ресурса отвечает за функции компании, которые реализует информационная система.
2. Ответственный за реагирование — администратор системы знает нюансы ее функционирования и конфигурации и способен быстро и корректно выполнять шаги сценария реагирования.

Однако администратор не всегда может принимать решения о реакции в критические моменты. Например, если атаке подвержен ресурс, обеспечивающий ключевые обязательства компании перед клиентами, его остановка может повлечь серьёзные последствия. В таких случаях решение принимает владелец информационной системы, который оценивает риски для бизнеса. Например, коммерческий директор.
Такой подход позволяет быстро реагировать на инциденты, не создавая дополнительных рисков для критически важных процессов.

25) Почему администратор SCADA и администратор антивируса управляются одной учетной записью?

Это некорректное разграничение полномочий. На практике иногда возникают ситуации, когда для работы со SCADA необходимо временно отключать ПО, мешающее ее функционированию, например, антивирус. Если администратор SCADA не может оперативно подключиться, оператору могут временно выдавать права администратора.
Такой подход не является безопасным, и УЦСБ SOC его не одобряет. В кейсах это лишь один из примеров существующих недостатков в организации ИБ.

26) Как бороться с «тенью» угроз, которые остаются незамеченными даже в самых продвинутых SOC?

В этом случае речь может идти о теневом ИТ или о сложно детектируемых, скрытых этапах атак.
При постановке инфраструктуры на мониторинг значительная часть теневого ИТ становится видимой. Появляются неучтенные сервисы, администраторские протоколы, нестандартные точки доступа — то, что раньше не фиксировалось.

Если речь идет именно о «теневых» действиях злоумышленника, то важно помнить, что любая современная атака — это многоэтапный вектор. Как правило, злоумышленник выполняет следующие действия:

1. эксплуатирует уязвимость или слабость периметра;
2. ищет точку закрепления внутри инфраструктуры;
3. повышает привилегии и подготавливает инструменты;
4. переходит к целевым действиям — краже данных, шифрованию, нарушению технологического процесса.

Если какой‑то редкий или нестандартный шаг останется незамеченным, SOC может выявить другие следы движения злоумышленника внутри инфраструктуры. Поэтому задача центра мониторинга — выявлять максимально ранние стадии атаки, чтобы начать реагирование до того, как злоумышленник перейдет к критическим действиям.

27) Какие инновационные технологии и подходы могут радикально изменить роль SOC в будущем информационной безопасности?

На первый взгляд, ответ очевиден — машинное обучение и большие языковые модели. Однако в ближайшей перспективе ключевым станет эффективное освоение уже существующих технологий и подходов.

Например:

• активное реагирование через EDR и SOAR — далеко не все организации реализовали эти возможности в полном объеме;
• ADR (Application Detection and Response) — на отечественном рынке пока отсутствуют продукты этого класса, но внедрение подобных решений может значительно изменить подход к мониторингу и реагированию на угрозы на уровне приложений.

Таким образом, эволюция SOC в ближайшие годы будет зависеть не столько от появления новых технологий, сколько от эффективного применения существующих инструментов и подходов к автоматизации, корреляции и проактивному реагированию.

28) Как создать полностью автоматизированный SOC, способный реагировать на угрозы без человеческого вмешательства? Возможно ли это вообще и на сколько актуально?

На текущем уровне развития технологий невозможно создать полностью автоматизированный SOC, способный самостоятельно принимать критические решения и адаптироваться к изменениям киберпространства. Ошибки могут быть слишком дорогостоящими, а ИИ пока не способен полностью заменить экспертов.

Однако современные технологии позволяют значительно облегчить работу SOC, автоматизируя рутинные и повторяющиеся задачи. Так эксперты могут сосредоточиться на сложных и критически важных действиях. Например, detection-инженер может не заниматься трудоемким парсингом и написанием правил на Sigma, а концентрироваться на логике детектирования и анализе кибератак.

29) Как встроить SOC в инфраструктуру? Отдельный SOC для корпоративной сети и отдельный для технологической? Или общий для обеих сетей? Если технологическая сеть физически изолирована от КСПД и интернета?

Единственно правильного решения здесь нет. Оптимальная схема зависит от масштаба компании, внутренних политик, требований регуляторов и особенностей бизнес-процессов. В зависимости от этого могут применяться оба подхода — отдельные SOC для разных контуров или единый центр мониторинга.

Техническая реализация также будет отличаться, поскольку даже в одинаковых отраслях инфраструктуры предприятий уникальны. Важно понимать, что SOC — это не самоцель, а элемент общей системы обеспечения ИБ. Поэтому выбор внутреннего или внешнего SOC, используемых инструментов и способа интеграции в ИТ-ландшафт определяется на этапе проектирования.

30) Как встроить SOC в инфраструктуру? Отдельный SOC для корпоративной сети и отдельный для технологической? Или общий для обеих сетей? Если технологическая сеть физически изолирована от КСПД и интернета?

Достичь высокого уровня прозрачности и контроля в работе SOC можно за счет систематизации процессов и поддержания высокого уровня квалификации сотрудников.

В качестве практических мер применяются стандартные методы контроля бизнес-процессов:

• разделение полномочий;
• аудит действий сотрудников;
• регулярный контроль выполнения процедур.

Эти подходы позволяют минимизировать риски внутренних угроз и злоупотреблений при работе SOC.

31) Почему большинство компаний недооценивают важность SOC, и как это сказывается на их кибербезопасности в критические моменты?

Во многих организациях недооценка роли SOC связана с ограничениями по бюджету и нехваткой квалифицированных внутренних ресурсов, которые могли бы полноценно обрабатывать результаты работы центра мониторинга.

Это напрямую влияет на уровень кибербезопасности — отсутствие своевременного мониторинга и реагирования увеличивает вероятность успешных атак и серьезных последствий. Данный эффект хорошо отражен в ежегодной статистике киберинцидентов в государственном сегменте, где наблюдается устойчивый рост числа инцидентов и их критичности.

32) Действительно ли нужен мониторинг 24/7? А если со стороны заказчика нет дежурной смены специалистов?

Круглосуточный мониторинг — единственно правильный и эффективный подход. Формат 5/8 создаёт лишь иллюзию защищенности — большинство критичных инцидентов происходят вне рабочего времени. Без постоянного контроля риски значительно возрастают.

Если у Заказчика нет дежурной смены ИБ или ИТ, проблема должна решаться организационно и технически. Возможны следующие варианты:

• передача части полномочий по активному реагированию коммерческому SOC;
• использование аутстаффинга специалистов ИБ;
• внедрение процессов, позволяющих оперативно принимать меры при критичных инцидентах даже без внутренних дежурных команд.

Такие меры позволяют обеспечить полноценную реакцию на инциденты и нивелировать риски, связанные с отсутствием круглосуточной внутренней поддержки.

33) Есть ли примеры реакции регуляторов на несвоевременное реагирование на инциденты ИБ? И как своевременно отреагировать, если нет SOC 24/7, а время на оповещение ГосСОПКИ/НКЦКИ всего 3 часа с момента обнаружения инцидента?

Конкретные примеры реакции регуляторов не публикуются, поскольку такая информация конфиденциальна.

Практически невозможно своевременно отреагировать и уложиться в регламентные сроки уведомления без выстроенного процесса мониторинга ИБ и процедуры взаимодействия с регуляторами.

34) Есть ли у SOC свой SOC?

Да. Инфраструктура УЦСБ SOC находится под собственным круглосуточным мониторингом инцидентов ИБ.

Если у вас есть вопросы — оставьте заявку, и мы поможем вам выстроить мониторинг в полном соответствии с требованиями регулятора.