Стандарт IEC 62443 не про «купить один продукт и забыть». Это язык для того, чтобы разделить промышленную сеть на зоны, понять пути обмена между ними (кондуиты) и ввести минимально достаточные меры без парализации производства. На объекте чаще всего не хватает не «ещё одного фаервола», а инвентаризации, сегментации, учетных записей, обновлений и реагирования на инциденты.
Ниже - практический старт: зоны и кондуиты, план на 30/60/90 дней, типовые провалы и чек-лист аудита для цеха.
Короткий ответ
Начните с карты активов и потоков данных, затем разделите OT и IT и ограничьте кондуиты (где и чем разрешён обмен). За первые 30 дней закройте самое дешёвое по риску: пароли по умолчанию, лишний удалённый доступ, неучтённые USB и «плоскую» сеть. За 60-90 дней добавьте мониторинг критичных кондуитов, политику патчей и учения на отказ. Без владельца со стороны производства проект обычно застревает.
Зоны и кондуиты в двух словах
Зона - логическая и физическая группа активов с похожими требованиями к безопасности: например, сегмент ПЛК и приводов, сегмент SCADA, сегмент инженерных станций, гостевая сеть подрядчиков.
Кондуит - контролируемый канал между зонами: межсетевой экран с явными правилами, VPN с MFA, односторонний шлюз (data diode) где уместно, DMZ для сервисов, которые «смотрят» и в OT, и в IT.
Цель не «запретить всё», а снизить радиус поражения: компрометация одной станции не должна автоматически открывать путь ко всему цеху.
Минимальные меры за 30 дней
Неделя 1-2: видимость - Список критичных узлов: ПЛК, HMI, серверы SCADA, шлюзы, Wi‑Fi/радио, удалённый доступ. - Схема физических подключений «как на самом деле», не «как в проекте 2018 года». - Учётные записи: кто администратор, кто оператор, где общий пароль.
Неделя 3-4: быстрые победы - Смена паролей по умолчанию, отключение неиспользуемых учёток и сервисов. - Запрет или контроль USB на инженерных станциях (политика + технически где возможно). - Разделение гостевой сети подрядчиков от производственной. - Документ: кто имеет право на удалёнку и через какой канал.
Минимальные меры за 60 дней
- Сегментация VLAN/маршрутизация или отдельные физические сегменты для критичных ПЛК.
- Правила на межсетевых экранах: только необходимые порты и адреса, запрет широких any-any для OT.
- Централизованное резервное копирование конфигураций ПЛК/SCADA и проверка восстановления.
- Журналирование входов на критичные системы и смена политики паролей (длина, ротация, запрет общих).
- Процедура ввода изменений в АСУ ТП (кто утверждает, как фиксируется версия).
Минимальные меры за 90 дней
- Мониторинг и оповещения на кондуитах IT-OT (аномалии трафика, сканирование, нехарактерные протоколы).
- План патчей: окна обслуживания, тестовый стенд, откат, исключения для legacy.
- Учение: сценарий «заражённая инженерная станция» или «подозрительный трафик с HMI».
- Взаимодействие OT и ИБ: единый регламент инцидентов и эскалации.
Типовые провалы (и почему они дорогие)
Провал 1: «у нас воздушный зазор»
На деле ноутбук подрядчика уже бывал в интернете и в тот же день - на шине с ПЛК.
Провал 2: один VLAN на всё
Любой заражённый ПК видит то же, что и SCADA-сервер.
Провал 3: вечный пароль admin
Уходит с объектом вместе с людьми, дублируется между площадками.
Провал 4: удалёнка без MFA и без журналов
После инцидента невозможно доказать, кто что менял.
Провал 5: нет владельца безопасности на стороне цеха
ИБ пишет политику, производство её обходит «чтобы не остановить линию».
Провал 6: игнорирование поставщика
Оборудование без обновлений и с известными уязвимостями. Имеет смысл заранее выбирать вендоров с прозрачной политикой обновлений; в линейках вроде СТАБУР это часть долгосрочной эксплуатации, а не разовой закупки.
Связка с уровнями Purdue / ISA-95 (упрощённо)
Чек-лист аудита для цеха (полевой)
Используйте как основу; дополняйте внутренним регламентом.
Доступ и люди - Список лиц с физическим доступом в шкафы АСУ ТП и к инженерным портам. - Журнал выдачи ключей и пропусков на период работ. - Политика для подрядчиков: отдельная сеть или выделенный ноутбук.
Сеть и сегментация - Нарисована схема: какие устройства в одном широковещательном домене / VLAN. - Нет ли прямого выхода ПЛК в интернет или в корпоративную сеть без шлюза. - Правила на фаерволах согласованы с фактическим обменом (OPC, RDP, SQL и т.д.).
Учётные записи - Нет общих учёток «оператор/инженер» без персонализации. - Отключены дефолтные логины на сетевом оборудовании и панелях. - Удалённый доступ только через утверждённый канал, с MFA где возможно.
Конфигурации и изменения - Версии проектов ПЛК/SCADA хранятся и подписаны датой/автором. - Изменения на пуске не вносятся «вживую» без фиксации в репозитории.
Обновления и уязвимости - Перечень критичных CVE по установленным ОС и ПО (хотя бы ежеквартально). - Окна обновлений согласованы с производством.
Реагирование - Контакт OT-ответственного 24/7 для инцидента. - Заготовлен сценарий изоляции сегмента без полной остановки линии (где применимо).
Физика - Закрыты незанятые порты USB/сетевые розетки. - Камеры/домофоны не в той же «доверенной» сети, что ПЛК, без необходимости.
Заключение
IEC 62443 на практике начинается не с сертификата на бумаге, а с дисциплины зон и кондуитов и с реальных владельцев на стороне цеха и ИТ. За 30 дней можно убрать очевидные дыры, за 60-90 - выстроить устойчивый контур мониторинга и обновлений. Главное - не строить «идеальную крепость» в PowerPoint, а внедрять меры, которые производство готово соблюдать каждый день.
FAQ
Нужно ли сертифицировать всё по IEC 62443 сразу?
Нет. Начинают с оценки риска и поэтапного усиления критичных зон.
Обязателен ли data diode?
Только для отдельных сценариев. Чаще достаточно фаервола, DMZ и строгих правил.
Кто должен вести проект: ИБ или АСУ ТП?
Совместно: ИБ задаёт рамки, АСУ ТП знает процесс и допустимые окна работ.
Что делать с устаревшим ПЛК без патчей?
Сегментация, запрет ненужных сервисов, контроль физического доступа, план замены.
Можно ли использовать облако для OT-данных?
Только через явный кондуит, шифрование, договор и классификацию данных.