Подключили завод к Wi-Fi ради аналитики? Ждите гостей (и недобрых)

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

На этом фоне британский NCSC вместе с партнёрами из нескольких стран выпустил рекомендации о том, как проектировать и защищать связность в операционных технологиях. Документ прямо говорит о том, что небезопасные и открытые OT-подключения привлекают как случайных злоумышленников, так и очень сильных игроков, включая группы, которые целенаправленно охотятся за критической инфраструктурой. Авторы отдельно отмечают и волну «оппортунистических» атак, когда в поле зрения попадают плохо защищённые системы, а дальше вопрос времени, кто доберётся до них первым.

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

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

Самый практичный блок рекомендаций касается того, как именно подключать OT к внешним системам и подрядчикам. Авторы настаивают на том, что по возможности соединения должны инициироваться изнутри OT как исходящие, чтобы не оставлять «входные двери» в периметре. Если доступ нужен внешнему участнику, лучше использовать «проброшенное» подключение через промежуточный узел в отдельном защищённом сегменте, например в DMZ, где доступ можно контролировать, ограничивать и мониторить, не выставляя сами OT-активы наружу. Для устаревших устройств, от которых пока нельзя отказаться, предлагаются обходные меры вроде протокольных шлюзов или hardened jump host для поддержки поставщика, плюс строгие ограничения прав и обязательные журналы событий.

Отдельно подчёркивается мысль, которая часто ломает привычный подход «пусть всегда будет включено», то есть не все связи должны быть постоянными. Модель just-in-time, когда доступ открывается только на время работ и закрывается сразу после, заметно сокращает «окно возможностей» для атакующего.

Чтобы OT-среда не превратилась в клубок разрозненных VPN и исключений «для каждого вендора свой тоннель», документ советует централизовать и стандартизировать подключения. Одна повторяемая схема с едиными правилами проще для сопровождения, обновления и контроля. А дальше логичный следующий шаг – отказаться от небезопасных протоколов там, где это возможно, и по умолчанию выбирать современные защищённые варианты, включая переход на более новые версии промышленных протоколов, а на стыке OT и IT использовать стандартные защищённые протоколы поверх TLS. Там, где «как раньше» всё-таки жизненно необходимо, отчёт требует хотя бы формального обоснования и компенсирующих мер.

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

Даже если всё это сделано, остаётся последний слой, на котором обычно «экономят время», пока не станет поздно. Здесь играет свою роль наблюдение. В документе подчёркивается, что цель логирования и мониторинга не в сборе логов ради галочки, а в том, чтобы понимать, как атакующие используют слабые места, и заранее строить правила обнаружения, включая контроль аномалий и особенно жёсткие сигналы на аварийные «аккаунты для разбития стекла» (break-glass).

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

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