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

Никита Фотин, "Газинформсервис" Контроль изменений в целом стоит больше отнести к задаче ИБ, ведь с точки зрения эксплуатации АСУ ТП вносимые изменения продиктованы изменением технологического регла- мента, техническими решениями, дооснащением или модернизацией про- изводства, а в таких случаях изменения зафиксированы на бумаге. Более того, бумага предшествует вносимым изме- нениям. Мы, конечно, можем рассмот- реть вопрос оценки изменений на пред- мет определения легитимности, но это уже задача экономической, а не инфор- мационной безопасности. Вячеслав Половинко, АМТ-ГРУП Это уже давно вопрос безопасности, но на практике часто маскируется под эксплуатацию. Несогласованное изме- нение (обновление ПЛК, правка логики) может незаметно отключить механизмы защиты. Эксплуатация смотрит на изменения как на аспекты работоспо- собности, в то время как информа- ционная безопасность – не стал ли узел уязвим. В целом, конечно, наблю- даются позитивные сдвиги: появляются процессы согласование изменений через ИБ, но массово процессы обнов- лений и изменений в OT сегменте пока еще проходят без массового контроля со стороны ИБ. Антон Кутепов, Positive Technologies Контроль изменений в ОТ всегда был вопросом безопасности: невоз- можно защитить то, о чем у тебя нет достоверной информации. При этом, зачастую, инвентаризация и контроль изменений остается в ведении экс- плуатации, поскольку исторически гра- ница между функциями ИБ, ИТ и АСУ ТП размыта. Многие подходы и инстру- менты для ИТ-сетей не применимы в ОТ-сетях из-за требований к непре- рывности процессов и специфики про- токолов. В результате контроль есть, но он фрагментирован. Поэтому эффек- тивно защищать технологические сети возможно только при комплексном под- ходе, когда данные об изменениях, конфигурациях и активности объеди- няются в единую систему и доступны всем вовлеченным функциям. Евгений Гончаров, Kaspersky ICS CERT Я бы не стал противопоставлять друг другу безопасность и эксплуатацию. Но тема контроля изменений со сторо- ны безопасности, безусловно, очень важная в OT. Собственно, тот факт, что изменений в OT, как правило, силь- но меньше чем в ИТ, позволяет реали- зовать многие функции безопасности как раз через контроль изменений – зафиксировать некое стационарное состояние как безопасное (например, различными средствами контроля целостности среды – приложений, кон- фигураций, сетевых коммуникаций и т. д.) – и контролировать лишь попытки их изменения. Денис Назаренко, UDV Group По зрелым практикам – это уже пря- мой вопрос безопасности. Потому что большинство критичных инцидентов в OT так или иначе связано с изменениями: прошивки, логика ПЛК, правила доступа, сетевые настройки, временные обходы. Эксплуатация исторически видит изме- нения как вопрос работоспособности, ИБ – как вопрос риска. В реальности это одно и то же: неуправляемое изме- нение одновременно бьет и по безопас- ности, и по устойчивости процесса. Таким образом в OT изменение без контроля – это как операция без прото- кола. Поэтому Change Management дол- жен быть общим контуром ИБ и экс- плуатации. Антон Кутепов, Positive Technologies Судя по запросам клиентов, острее стоит проблема "не видим": нет целост- ной картины активов, сетевых коммуни- каций и текущего состояния систем. Даже при наличии данных, они, как пра- вило, разрознены, так как находятся в разных системах. Это типичная про- блема отдельных невзаимосвязанных решений – каждое из них закрывает свою задачу, но не дает общего пони- мания происходящего. Здесь поможет объединение всех источников в единый контекст: сетевого трафика, событий с конечных устройств, конфигураций и технологической телеметрии. Без дан- ных ни аналитика, ни автоматизация, ни современные технологии машинного обучения не дадут результата. Андрей Кузнецов, "АйТи Бастион" Зачастую вторую проблему легче решить, чем первую, поэтому "не видим" побеждает в этом грустном соревнова- нии. И вот тут хочется передать заказ- чикам: если что-то в решении непонятно, не настраивается, не видно – не стес- няйтесь идти к разработчику этого про- дукта и уточнять. В 99% случаев у про- изводителя есть готовый ответ на ваш вопрос, в оставшемся 1% – исследовать проблему лучше самого вендора мало кто сможет. Денис Назаренко, UDV Group Сейчас чаще больнее второе: данных много, смысла мало. Телеметрию собрали, события текут, алерты горят – а приоритизации под технологический риск нет. В итоге команда тонет в шуме и пропускает важное. Но и "не видим" все еще встречается на участках с наследованной инфраструктурой. Поэтому правильнее говорить о двух- этапной задаче: сначала обеспечить базовую наблюдаемость, потом – кон- текст и аналитику. Цель, как я ее вижу – это когда система не просто показывает события, а помогает отве- тить: что реально угрожает процессу здесь и сейчас. Евгений Гончаров, Kaspersky ICS CERT Обе эти проблемы нераздельно свя- заны друг с другом. Если отталкиваться от нашего опыта расследования кибе- ринцидентов, то обычно "не видим" зна- чит "не было человека, способного уви- деть и мотивированного увидеть". Почти всегда основная причина – в том, что квалифицированных мотивированных людей сильно меньше, чем нужно для эффективной защиты. Вячеслав Половинко, АМТ-ГРУП На наш взгляд острее – "видим слиш- ком много, но не понимаем". Поток событий (SIEM, сетевые датчики, логи ПЛК) уже сейчас огромен, но нет моде- ли нормального поведения технологи- ческого процесса и квалификации интерпретировать события. В OT край- не высок риск ложных срабатываний: любой нештатный режим (пуск, авария, ремонт) генерит шум, похожий на атаку. Никита Фотин, "Газинформсервис" Зайду с несколько философского рас- суждения, что на наш век выпала про- блема, скорее, избыточности информа- ции, обрабатываемой человеком. Важно сфокусироваться на чем-то конкретном, при этом человек всегда стремится орга- низовать свою работу и создать некий порядок. Ведь в хаосе попросту невоз- можно будет выполнить задачи ИБ. Поэтому несмотря на засилье различных инструментов для мониторинга ИБ и автоматизации процессов ее обеспече- ния, я бы отметил нехватку решений- платформ, где функциональность поз- волит справиться с задачами обеспече- ния ИБ из единой точки входа без пере- ключения между кучей различных кон- солей управления, от условно сетевой безопасности до резервного копирова- ния. Какая проблема сегодня острее: "не видим" или "видим слишком много, но не понимаем"? Контроль изменений в OT уже стал вопросом без- опасности или все еще воспринимается как зада- ча эксплуатации? 34 • СПЕЦПРОЕКТ