Метка: UDV Group

UDV Group: телеком становится главной мишенью для кибератак

Опубликовано

По данным RED Security, 2025-й стал для хакеров «годом телекоммуникаций». Именно российская отрасль связи перехватила «лидерство» у промышленного сектора по количеству попыток кибератак на IT-инфраструктуру компаний — 40% от общего числа нападений против 9% годом ранее. Это резкий стратегический сдвиг в целях злоумышленников, указывают аналитики, и в текущем году компании сфер IT и телекоммуникаций останутся в фокусе их внимания, поскольку одна успешная атака на такие организации способна затронуть большое количество их клиентов.

Смена лидера

В 2025 году отрасль связи отразила 40% от всех зафиксированных попыток компрометации, что кратно превышает показатель 2024 года (9%), следует из данных исследования центра мониторинга и реагирования на кибератаки RED Security SOC (входит в МТС), с которыми ознакомился Forbes. Телеком-операторы столкнулись не только с ростом количества атак, но и с их исключительной опасностью, констатируют ИБ-специалисты: почти половина (49%) попыток кибератак в этом секторе были классифицированы как высококритичные. Для сравнения: совокупная доля таких инцидентов по всем отраслям сохранилась на среднем уровне последних трех лет — около 20%.

В то время как объем массовых атак на телеком резко вырос, доля инцидентов в промышленном секторе сократилась с 31% в 2024 до 8% в 2025-м. По мнению аналитиков RED Security SOC, это свидетельствует как о перераспределении интересов, так и об изменении тактики атакующих. «Простые и массовые атаки в прошлом году уступили место целенаправленным: пытаясь взломать промышленные организации, хакеры прибегали к тщательно подготовленным инструментам, адаптированным под конкретную организацию, — говорится в отчете. — Так, в 2025 году эксперты RED Security SOC фиксировали несколько волн атак на промышленность, которые были атрибутированы к известным антироссийским хакерским группировкам, ранее бравшим на себя ответственность за масштабные инциденты информационной безопасности в крупнейших российских организациях».

Среди других отраслей, компании которых подверглись атакам, выделяются IT — 21%, финансы — 12%, медицина — 5%. Доли ретейла, HoReCa, транспорта, девелопмента и медиа составили меньше 5%. Всего за 2025 год аналитики RED Security SOC зафиксировали и помогли отразить почти 142 000 кибератак, это на 9% больше, чем годом ранее.

«Рост общего числа атак — это тренд, который мы наблюдаем последние годы. Однако ключевой вывод 2025 года — не в цифрах, а в изменении приоритетов атакующих, — настаивает технический директор центра мониторинга и реагирования на кибератаки RED Security SOC Владимир Зуев. — Финансовый сектор и IT-компании, традиционно находящиеся в топе, теперь делят лидерство с телекомом. Телекоммуникационная инфраструктура — это кровеносная система цифровой экономики и национальной безопасности. Ее компрометация могла бы дать злоумышленникам беспрецедентный уровень контроля над данными и коммуникациями, что объясняет высокий интерес к этому сектору».

«Эффект масштаба»

Эксперты называют сложившуюся картину «логичной». Телекоммуникации действительно стали одной из самых привлекательных целей, подтверждает проджект-менеджер MD Audit (входит в ГК Softline) Кирилл Левкин. «Это высоконагруженная, распределенная инфраструктура с большим количеством внешних точек доступа и высокой ценностью доступности сервисов. При этом рост доли высококритичных инцидентов говорит не просто о количестве атак, а о повышении их качества и глубины, — рассуждает он. — Ключевой фактор — эффект масштаба. Успешная атака на телеком или IT-провайдера позволяет затронуть сразу множество организаций и пользователей, включая бизнес-клиентов. Это делает такие цели более выгодными с точки зрения отдачи при сопоставимых затратах на атаку».

Телеком-инфраструктура часто используется как опорная среда для других сервисов, что повышает ценность доступа к ней, продолжает Левкин. Сама специфика телеком-бизнеса предполагает наличие большого количества точек воздействия и невозможность просто отрезать внешний канал для изоляции от атак, поясняет CEO ИБ-компании UDV Group Виктор Колюжняк. В промышленности же уровень базовой защищенности за последние годы, по словам Левкина, заметно вырос, и для атак теперь требуется больше разведки, кастомных инструментов и времени, что снижает массовость, но повышает сложность операций. «Такой сдвиг от «шума» к точечным операциям — общий тренд зрелости киберпреступности», — резюмирует он.

Данные RED Security точно отражают ключевое изменение в стратегии современных злоумышленников: переход от широкомасштабного сканирования и массовых атак к прицельному выбору объектов, дающих максимальный стратегический и разрушительный эффект, размышляет инженер по информационной безопасности Linx Cloud Станислав Савкин. «Цели явно сместились в сторону критической инфраструктуры, удар по которой вызывает каскадный эффект для экономики и общества», — делится он наблюдениями.

«Постоянный объект атак»

«Логично, что телеком является постоянным объектом атак как отрасль, критически важная для бизнеса, государства и граждан, — заявили Forbes в Т2. — Мы согласны с тем, что в 2025 году число атак выросло в пределах 9% год к году. По итогам прошлого года число автоматизированных атак на публичные ресурсы компании увеличилось в несколько раз, при этом DDoS-атак — вдвое. Мы отмечаем рост сложности атак и уровня атакующих». В МТС, «Мегафоне», «Вымпелкоме» не стали комментировать данные исследования.

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

При этом, согласно результатам отчета «Солара» о целевых атаках профессиональных хакерских группировок за десять месяцев прошлого года, доля атак с целью шпионажа достигла 60%, с целью шантажа и вымогательства денежных средств — 17%. «Хакеры все меньше заинтересованы в громких кейсах взломов, и все чаще — в атаках с целью разрушения инфраструктуры крупнейших организаций и оказания негативного влияния на экономику страны», — поясняют в ГК «Солар».

Вместе с этим одним из главных трендов киберугроз 2025 года специалисты называют атаки через подрядчика — за десять месяцев 2025 года доля подобных атак почти достигла трети (27%) от других видов проникновений в инфраструктуру российских компаний. «Нередко атакованным подрядчиком становится небольшая IT-компания или телеком-провайдер, — подтверждают в ГК «Солар». — Этот тренд на атаки через подрядчиков и усложнение техник и тактик продолжится и в 2026 году».

Источник: https://www.forbes.ru/tekhnologii/553547-hakery-seli-na-telefon-telekom-stanovitsa-glavnoj-misen-u-dla-kiberatak

UDV Group: как выстраивать подготовку ИБ-инженеров внутри компании

Опубликовано

Вырастить ИБ-инженера внутри компании — лишь половина задачи. Гораздо сложнее удержать его, дать понятные перспективы роста и встроить обучение в систему, которая работает не разово, а воспроизводится из года в год. Зарплата здесь важна, но решающую роль играют возможности развития, понятный карьерный трек и участие в реальной инженерной работе. О том, как превратить внутреннее обучение в полноценную школу ИБ — с преемственностью, методологией,снижением зависимости от рынка и формированием устойчивого кадрового ядра — рассказывает Ольга Луценко, эксперт UDV Group.

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

Причины такого сдвига выходят далеко за рамки кадрового дефицита. Ключевые из них — скорость, стоимость и управляемость рисков. Даже сильный специалист с рынка тратит значительное время на погружение в инфраструктуру, процессы и внутренний контекст компании. Фактически бизнес оплачивает период его адаптации — деньгами и упущенным временем. При внутреннем выращивании этот этап сокращается в разы: инженер из смежной IT-роли уже знает систему, остается включенным в рабочие процессы и параллельно осваивает функции информационной безопасности.

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

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

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

Именно поэтому внутренняя подготовка позволяет закрывать сразу несколько задач: сокращать время адаптации, формировать бизнес-ориентированное мышление и быстрее выводить инженеров на работу с реальными, а не абстрактными рисками.

От инженерного фундамента к целевым ИБ-ролям внутри компании

Подготовку ИБ-инженера внутри компании имеет смысл начинать не с инструментов и регламентов, а с формирования правильного инженерного и бизнес-мировоззрения. На первом этапе важно, чтобы специалист понял, что такое информационная безопасность именно в контексте конкретного бизнеса, а не в отрыве от него. Сначала инженер погружается в бизнес-риски и операционные процессы: какие из них критичны, какие нельзя останавливать и как текущая система защиты встроена в их поддержку. Далее следует разбор архитектуры и потоков данных — чтобы безопасность воспринималась как часть реальных бизнес-процессов, а не как отдельный слой «над системой». Параллельно закладываются базовые инженерные принципы информационной безопасности: отказоустойчивость, эшелонированная защита, принцип наименьших привилегий и другие фундаментальные подходы, которые должны применяться уже на этапе проектирования. И только после этого имеет смысл переходить к предметному обучению — работе с конкретными средствами защиты, используемыми в компании, и к погружению в нормативные требования, если ранее такого опыта не было.

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

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

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

Обучение ИБ через бизнес-контекст, последствия решений и наставничество

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

При этом критически важно управлять рисками, связанными с допуском стажеров к реальным системам. Стратегия минимизации включает: строгий контроль доступа (принцип наименьших привилегий, временные права), работу в изолированных sandbox-средах, максимальное использование копий данных и логирование всех действий обучаемого для последующего разбора. Это защищает бизнес от случайных ошибок и формирует у инженера культуру ответственности с первых дней.

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

Ключевую роль в этом процессе играет наставник. Именно он передает тот контекст, которого нет в документации: знание архитектуры, «тонких мест», исторических ограничений и причин принятых решений. Наставник показывает, как действовать в условиях неполной информации, делится опытом прохождения риск-комитетов и разбора инцидентов, а также помогает выстраивать коммуникацию с бизнесом и смежными подразделениями. Однако эффективное наставничество — это значительная нагрузка на опытных специалистов. Чтобы система работала, роль наставника должна быть формализована: включена в KPI и должностные обязанности, выделено специальное время (например, 15-20% рабочей недели), а его вклад — материально и карьерно мотивирован. В противном случае высок риск выгорания наставников и формального отношения к обучению.

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

Типовые ошибки и баланс обучения в ИБ-командах

Одна из самых распространенных ошибок внутреннего обучения ИБ-специалистов — подмена практики теорией. Когда обучение сводится к просмотру лекций и вебинаров без доступа к тестовым стендам и «живым» системам, специалист формально обучается, но оказывается не готов к реальной работе. Усиливает проблему изоляция от боевых задач: обучаемого держат в учебных проектах, не показывают реальные инциденты и не вовлекают в текущие процессы, из-за чего не формируется понимание того, как информационная безопасность работает на практике.

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

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

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

Отдельный риск внутренней школы — «узкая специализация», когда инженер становится экспертом только в специфике своей компании, теряя связь с отраслевыми трендами. Профилактика этого — обязательное включение во внутренний учебный план внешних активностей: отраслевые конференции (для обмена опытом), специализированные курсы и актуальные сертификации (для проверки знаний), участие в хакатонах и CTF-соревнованиях (для развития прикладных навыков в незнакомой среде). Это инвестиция в поддержание высокой экспертизы команды.

Прогресс ИБ-инженера при этом важно оценивать путем сочетания объективных показателей (метрик) и субъективной оценки развития компетенций инженера. В качестве объективных метрик могут рассматриваться: время на закрытие смоделированного инцидента; количество и критичность выявленных уязвимостей в тестовой среде; результаты регулярных аудитов защищенности сегмента, за который отвечает стажер; и, наконец, структурированная обратная связь (оценка 360°) от наставников, коллег из смежных команд и внутренних «заказчиков».

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

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

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

Как удерживать выращенных ИБ-специалистов и не терять их после обучения

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

Заключение

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

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

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

Источник: https://ict-online.ru/it_class/Kak-vystraivat-podgotovku-IB-inzhenerov-vnutri-kompanii-321470

UDV Group: за 2025 год рост рынка ИБ-аудита превысил 25%

Опубликовано

Ольга Луценко, ведущий эксперт по ИБ компании UDV Group, дала комментарий, в котором оценила исследование рынка ИБ-аудита

Согласны ли вы с тем, что за 2025 год рост рынка ИБ-аудита превысил 25% и достиг 25 млрд руб., ? Есть ли у вас собственные цифры?

С такой оценкой рынка можно согласиться. Мы действительно видим устойчивый, планомерный рост сегмента ИБ-аудита из года в год. Собственных агрегированных цифр по рынку в абсолютных значениях мы не ведем, однако по динамике спроса со стороны заказчиков темпы роста в 25% не противоречат нашим наблюдениям.

Как вы оцениваете динамику? Компании просто идут на поводу у регулятора и выполняют некоторые минимальные требования или же речь идет о реальном повышении зрелости?

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

Роль ИБ-аудита в этих условиях заметно эволюционирует. Если ранее аудит во многих случаях воспринимался исключительно как формальное выполнение регуляторных требований, то сегодня он все чаще используется как прикладной инструмент управления рисками. Компании прибегают к внешней оценке не только для подтверждения соответствия, но и для выявления уязвимых мест в системе обеспечения ИБ — в том числе в рамках подготовки к проверкам или государственному контролю. Дополнительным фактором спроса становится высокая динамика изменений законодательства: аудит позволяет зафиксировать текущий уровень соответствия и понять, какие требования уже закрыты, а какие меры требуют доработки или внедрения.

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

Какие сегменты все чаще идут за ИБ-аудитом?

С точки зрения отраслевой структуры спроса, сегодня основными заказчиками ИБ-аудита остаются субъекты критической информационной инфраструктуры — прежде всего в контексте изменений и практики применения 187-ФЗ. Одновременно мы видим рост интереса со стороны государственных организаций и органов местного самоуправления, что связано с реформированием подзаконной базы в области обеспечения ИБ госсектора, включая требования приказа ФСТЭК № 117 и планируемые изменения в перечнях мер. Именно эти сегменты в ближайшие годы, по нашему мнению, будут формировать основной спрос и поддерживать дальнейший рост рынка ИБ-аудита.

UDV Group: как правильно организовать цикл обнаружения и реагирования на инциденты ИБ

Опубликовано

Автор: Николай Нагдасев, ведущий специалист UDV Group

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

Введение

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

Линейный цикл реагирования vs реальная инфраструктура

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

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

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

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

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

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

Проблема №1: обнаружение построено без связи с критичностью активов

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

Проблема №2: анализ инцидентов не стандартизирован и зависит от конкретного инженера

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

Поэтому здесь необходим инженерный подход: стандарты, чек-листы и закрепленные сценарии для разных типов инцидентов. Это снимает зависимость от личного опыта и позволяет выполнять базовый набор действий одинаково — будь то фишинг, внедрение вредоносного ПО или атаки на учетные записи. Далее важна единая классификация и общий язык описания техник, например, на базе MITRE ATT&CK или внутреннего справочника классификаторов инцидентов компании: это упрощает коммуникацию между командами и делает результаты анализа сопоставимыми. В такой модели выводы и решения становятся предсказуемыми и объективными, а сам процесс начинает опираться на стандарты, а не на интуицию отдельных специалистов. И именно здесь проявляется следующая проблема — как обеспечить одинаковую глубину анализа и качество реагирования для всех типов инцидентов, а не только там, где работает сильный инженер.

Проблема №3: реагирование не синхронизировано между ИТ, ИБ и технологами

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

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

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

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

Поддержать этот процесс помогают в том числе и средства автоматизации — системы класса IRP/SOAR или тикет-система, где фиксируются статус, принятые меры и дальнейшие шаги.

Проблема №4: локализация основана на ручных действиях, а не инженерных процедурах

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

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

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

Проблема №5: мониторинг не обеспечивает полноту данных для реагирования

Мониторинг действительно генерирует большой поток информации, однако при работе с конкретным инцидентом контекста часто не хватает. Это нормальная ситуация: специалисты SOC обычно используют несколько систем одновременно, потому что единое окно доступа к данным есть далеко не везде. SIEM выполняет свою задачу — собирает сырые события, коррелирует их и выдает ключевую информацию по факту срабатывания. Но для полноценного анализа этого недостаточно. Например, по доменному имени и IP-адресу пораженного хоста невозможно понять, к какой системе относится актив. Эти данные хранятся уже в других источниках — CMDB или системах учета инфраструктуры. Аналогично и с учетными записями: имя пользователя само по себе мало что говорит, и аналитик вынужден искать информацию вручную — в адресных книгах, справочниках, внутренних базах. В результате реагирование опирается на разрозненные данные и ручной поиск контекста в смежных системах. Чем больше инструментов приходится подключать, тем выше риск ошибки и тем больше времени уходит на обработку инцидента.

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

Проблема №6: нет инженерной обратной связи — поэтому инциденты повторяются

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

Инженерный подход предполагает постинцидентный анализ: нужно понять не только что произошло, но и почему это стало возможным. Логика та же, что при поиске причины поломки оборудования — разбирать ситуацию до исходного сбоя. Для этого можно использовать принцип «5 почему»: задавая последовательные вопросы, выйти на корневой фактор. Например, заражение критического хоста произошло из-за использования USB-носителя. Почему носитель оказался в системе? Потому что его применение было разрешено. Почему это стало угрозой? Потому что сотрудник не был проинструктирован по правилам обращения. И так далее — пока не станет ясно, где именно возникла системная ошибка, которая привела к возникновению инцидента.

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

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

Один сценарий — два результата: что дает зрелость процессов

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

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

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

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

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

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

Реагирование как культура инженерии

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

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

Источник: https://www.anti-malware.ru/practice/methods/Incident-as-an-engineering-problem

«  1 ...   2   3   4   5   6   7   8   9   10   11   12   ... 22  »

Пользовательское соглашение

Опубликовать
Яндекс.Метрика