Журнал "Information Security/ Информационная безопасность" #4, 2026

– Сергей, расскажите о своем профессиональном пути, как вы пришли к теме управления кибер- безопасностью и развитию ИБ- продуктов. – Я занимаюсь информационной без- опасностью около 25 лет, в разных ролях. За плечами два высших образо- вания – техническое и экономическое, мне повезло видеть кибербезопасность одновременно со стороны техники и со стороны маркетинга. Сейчас я сосредо- точен на продуктовом менеджменте, но современный продукт обычно часть более сложной системы – с сервисами и проектами. Поэтому держу в фокусе внимания не отдельные средства защи- ты, а то, как продукты, экспертиза и сервисы складываются в работающую систему управления киберустойчи- востью. – Какие проблемы заказчиков сегодня заставляют уходить от схемы "проверили – выдали отчет – закрыли проект"? – Заказчики все больше понимают, что кибербезопасность – это не разовая акция, а системная работа в среде, где постоянно растут угрозы и требования. Отсюда цикличность на разных уровнях. Ценность проверки определяется не чис- лом найденных недостатков, а тем, что изменилось после нее, поэтому нужно периодическое подтверждение защи- щенности. Бюджетные ограничения заставляют жестче обосновывать затра- ты на ИБ, а результат проверки не может оставаться просто отчетом, он должен приводить к изменениям. – После аудита, пентеста или кибериспытаний заказчик полу- чает перечень недостатков, но не всегда доходит до их устране- ния. Где возникает главный раз- рыв? – Единственный фактор выделить сложно – здесь работает совокупность причин. Во-первых, не ясно, что исправ- лять в первую очередь. Во-вторых, для проектирования изменений не хватает компетенций. В-третьих, ответственность размазана между ИБ, ИТ, эксплуатацией и бизнесом. В-четвертых, исправления затрагивают рабочую инфраструктуру и создают риск нарушить ее работу. Поэто- му главный разрыв возникает не на этапе поиска проблемы, а на этапе пре- вращения технического замечания в без- опасное, приоритетное и реализуемое изменение. Плюс качество результатов после аудита и, например, кибериспыта- ний сильно различается, поэтому иногда устранение недостатков, особенно архи- тектурных, занимает много времени. – Формальное соответствие требованиям регуляторов не все- гда означает реальную защищен- ность. Как найти баланс между комплаенсом и реальной киберу- стойчивостью? – Долгое время усилия рынка были сосредоточены на выполнении обяза- тельных требований, и фокус защиты сместился в сторону пассивного контро- ля, а не противодействия сложным ата- кам, включая угрозы со стороны внут- реннего нарушителя. Современная нор- мативная база смещает акцент на мони- торинг и реагирование – то есть работу с инцидентами, что делает киберустой- чивость непрерывным процессом. Ком- плаенс задает базовый уровень, а кибе- рустойчивость показывает, работает ли защита в реальных сценариях атак и способна ли организация обнаружить, остановить атаку и восстановиться. Глав- ный вызов для любого заказчика – пере- строить процессы так, чтобы регулярная оценка безопасности стала частью общей системы управления предприя- тием. – Крупная инфраструктура не позволяет устранить все выявленные недостатки сразу. Как определить, какие изменения дадут максимальный прирост защищенности при ограниченных ресурсах? – Допустим, есть сто критических CVE, но это не значит, что перед нами сто одинаково важных задач. В первую оче- редь, нужно устранять недостатки, кото- рые формируют реальный путь к наибо- лее критичным активам или позволяют реализовать недопустимое для бизнеса событие. Одно точное изменение может закрыть сразу множество векторов атаки на критичную систему и оказаться важ- нее устранения десятков отдельных уязвимостей. – Пентест, Red Team, Bug Boun- ty и кибериспытания решают раз- ные задачи. Как вы разграничи- ваете эти подходы? – Коротко поясню ключевые различия. Пентест показывает, можно ли техниче- ски преодолеть защиту. Red Team ими- тирует реальные атаки и заодно выявляет недостатки в работе SOC. Bug Bounty подключает ресурсы независи- мых исследователей для масштабиро- вания поиска уязвимостей в заданном периметре и вознаграждает за подтвер- жденные результаты. Кибериспытания – это комплекс мероприятий для проверки на реализацию недопустимых для пред- приятия событий. Они особенно нужны крупным заказчикам с технологическим сегментом инфраструктуры, где воз- можности проверок ограничены: прове- ряются не только технические аспекты, но и действия персонала, включая тех, кто не относится к службам ИБ. Кибериспытания проверяют сценарий целиком: как спроектирована и сконфи- гурирована защита, как организованы мониторинг и реагирование. Ключевая особенность – проверяется не отдельное средство защиты, а способность всей системы не допустить или ограничить последствия критичного для бизнеса сценария. – Для кибериспытаний исполь- зуется киберполигон. Какие сце- нарии невозможно или слишком рискованно отрабатывать на бое- вой инфраструктуре и зачем в этом случае нужна наиболее точ- ная копия инфраструктуры? – Пентест и Red Team могут выявлять попытки доступа в технологически значи- мый сегмент сети (АСУ ТП, видеона- блюдение, СКУД), но дальнейшие дей- ствия атакующих в АСУ ТП уже опасны. При этом взаимодействие между узлами в этом сегменте предсказуемо из-за особенностей автоматизации техпроцес- сов, поэтому испытания на репрезента- тивной модели с киберполигоном мак- симально приближены к реальному пове- дению системы. – Рынок хорошо научился искать способы взлома, но насколько хорошо организации умеют обнаруживать атаку, реа- гировать на нее и восстанавли- ваться? – Технологии поиска атак исторически развивались быстрее, чем процессы реа- гирования. Одна из проблем реагирова- ния – нехватка контекста для быстрого решения: обнаружено внештатное пове- дение объекта сети, а что это за объект, на какие сервисы влияет, кто за него отвечает – не всегда понятно. Восстанов- ление вообще сложно проверить, поэтому его редко тестируют в реальных сцена- риях. Более зрелым подходом является способность пройти весь цикл: обнару- жить атаку, локализовать последствия, восстановить сервис и сделать выводы для следующей итерации защиты. – Где сегодня наиболее заметен дефицит компетенций? – Дефицит компетенций заметен на стыке областей, за которые отвечают разные подразделения: ИТ, ИБ, сетевая безопасность, безопасность приложений, АСУ ТП. При устранении замечаний по результатам проверок заказчикам слож- нее всего с приоритизацией результатов и архитектурными изменениями, если они нужны. Специалистов по отдельным классам решений хватает, а вот людей, способных видеть всю цепочку атаки и проектировать архитектуру безопасно- сти, – мало. – Регуляторный импульс может сделать кибериспытания обяза- тельной практикой для отдель- ных отраслей. Как избежать пре- вращения их в формальную про- цедуру, а результатов – в очеред- ной отчет? • 11 ПЕРСОНЫ www.itsec.ru