Защита операционных технологий: руководство NCSC

Операционные технологии (OT) отвечают за управление промышленным оборудованием и  автоматизацию технологических процессов на производстве, в энергетике и на транспорте. Все чаще они становятся целью киберпреступников. Если раньше такие системы были изолированы, то сегодня они интегрируются с ИТ и облаками, что ускоряет работу, но делает инфраструктуру более уязвимой. 

При этом компании часто не имеют целостного представления о своей OT-архитектуре: системы сложные, изменения накапливаются годами, а документация остается фрагментарной. Для решения этой проблемы Национальный центр кибербезопасности Великобритании (NCSC) предлагает подход под названием «дефинитивная запись» (definitive record) – единый источник актуальных данных об OT. Он позволяет видеть картину целиком, оценивать риски и принимать взвешенные решения. Полный текст руководства NCSC «Creating and maintaining a definitive view of your OT Architecture» доступен по ссылке.

Ключевые приоритеты дефинитивной записи

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

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

Принцип 1. Определение процессов для создания и ведения записи

Источники информации для записи об архитектуре OT могут быть разными: инвентарь активов, проектная документация, знания инженеров, результаты мониторинга и сканирования. Дополнительно используют перечни компонентов от производителей – SBOM и HBOM, которые показывают состав оборудования и ПО, а также возможные уязвимости.

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

Принцип 2. Безопасность дефинитивной записи OT

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

Руководство выделяет несколько категорий:

• проектная документация (схемы, инвентарь, сетевые диаграммы);
• бизнес-данные (цели работы системы, сведения о клиентах и поставщиках);
• учетные записи и ключи доступа;
• операционные данные (сигналы датчиков, журналы, аналитика);
• результаты аудитов и тестов.

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

Принцип 3. Классификация активов

В третьем принципе руководства NCSC отмечается – чтобы управлять рисками, нужно понимать роль каждого элемента в системе OT. Руководство предлагает оценивать три фактора:

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

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

Принцип 4. Документирование связности внутри OT

Современные OT-системы редко изолированы – для работы им нужны внешние соединения: с корпоративными сетями, облаками или подрядчиками. Это ускоряет процессы, но повышает уязвимость. Поэтому важно фиксировать, как именно связаны активы внутри системы и какие внешние каналы они используют.

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

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

Принцип 5. Управление рисками третьих сторон

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

Руководство NCSC предлагает разделять внешние подключения по уровням доверия:

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

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

Заключение

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

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

Главное условие успеха – совместная работа ИТ- и OT-команд, поддержка руководства и участие поставщиков. Только так можно обеспечить надежную защиту систем, от которых зависят производство, транспорт и энергетика.