IEC 62443 как рабочий чеклист: зонирование, каналы связи с ПЛК и патчинг
После Stuxnet серия IEC 62443 из теоретических документов превратилась в практический инструмент. Как мы применяем её при проектировании защиты промышленных сегментов.
Серия стандартов IEC 62443 (бывший ISA-99) по кибербезопасности промышленных систем управления активно обсуждается после Stuxnet.
Когда в профессиональных списках рассылки и на отраслевых форумах начали активно ссылаться на IEC 62443, у нас была примерно такая реакция: ещё одна бумажная серия про то, как надо правильно. Промышленная автоматизация - область консервативная, там и без стандартов хватает регламентов, которые живут в файлах на сервере и не влияют ни на что реальное.
Stuxnet изменил эту позицию. Не мгновенно, но довольно быстро.
Откуда взялся интерес к 62443
После нашего разбора Stuxnet в июле и построения DMZ у производственного клиента несколько заказчиков из промышленного сектора пришли с похожим запросом: «Хорошо, мы понимаем, что надо что-то делать. Но как понять, что сделали достаточно и правильно?»
Это честный вопрос. Изолировать сеть - понятно. Убрать дефолтные пароли - понятно. Но дальше начинается туман: что именно проверять, в каком порядке, где граница между «достаточно» и «паранойя»?
IEC 62443 - это серия документов ISA-99, переименованная при принятии в международный стандарт. Она описывает безопасность промышленных систем управления (ICS/SCADA) структурированно: зоны безопасности, уровни доверия, требования к каналам связи, жизненный цикл системы. Документов там много, часть ещё в черновиках, часть платная - обычная история для стандартов. Но даже те части, до которых можно добраться, дают полезную структуру.
Мы начали использовать её как чеклист при аудитах промышленных объектов. Не как священный текст, а как набор вопросов, которые надо задать.
Три вещи, которые реально работают как чеклист
Зонирование и определение границ. 62443 вводит понятие «зоны безопасности» - группы активов с одинаковым уровнем доверия и требованиями. Это не просто VLAN и не просто «технологическая сеть отдельно». Вопрос ставится так: у каких активов одинаковые требования к доступу и одинаковые последствия при компрометации? ПЛК управления конвейером и инженерная станция Step 7 - это одна зона? Или разные? Историк данных, который читает теги из ПЛК и отдаёт их в ERP - в какой зоне он живёт?
На практике у большинства наших клиентов до проведения аудита этого разграничения не существовало вообще. Всё промышленное оборудование считалось «технологической сетью» как единым монолитом. Stuxnet показал, что это не так - у инженерной станции с Step 7 и у панели оператора очень разная роль в атаке.
Защита каналов связи с ПЛК. Здесь у стандарта есть конкретные требования: аутентификация на уровне канала, шифрование где возможно, мониторинг аномалий. На практике - это больной вопрос. Большинство промышленных протоколов (Modbus, старый Profibus) вообще не предусматривают аутентификации: ПЛК принимает команду от любого, кто пришёл на правильный порт. Это не баг конкретного вендора - это архитектурное решение двадцатилетней давности, когда предполагалось, что до ПЛК никто посторонний не доберётся физически.
Применить требования 62443 к такой среде буквально - невозможно. Применить как направление - полезно. Мы стали явно документировать для заказчиков: вот этот канал не имеет аутентификации и никогда не будет иметь без замены оборудования, вот компенсирующие меры (изоляция сегмента, мониторинг трафика, контроль физического доступа). Это честнее, чем делать вид, что всё в порядке.
Процедуры патчинга. Наверное, самый болезненный пункт. В корпоративной ИТ-среде патчинг - это процесс с понятными инструментами: WSUS, менеджер обновлений, тестовая среда. В промышленной - это потенциальный останов производства, сертификационные ограничения вендора и системный интегратор, который говорит «не трогайте, мы не отвечаем за работу после обновления».
62443 требует управления патчами как обязательного элемента безопасности. Что это значит на практике: у заказчика должен быть хотя бы реестр того, что стоит, какая версия ПО, когда последний раз обновлялось и почему. У большинства этого нет. Начинаем с инвентаризации - это само по себе ценность.
Сложно, но не бессмысленно
Серьёзный ограничитель - стандарт написан под специалиста, который хорошо понимает и ИБ, и промышленную автоматизацию одновременно. Таких людей мало. Большинство ИБ-специалистов не понимают, как работает ПЛК. Большинство автоматизаторов не понимают, что такое модель угроз. Применять 62443 в одиночку - сложно.
Ещё один момент: стандарт описывает что, но не всегда как. Для типовых ИТ-сред есть готовые инструменты и референсные архитектуры. Для промышленных - в основном придётся проектировать под конкретный объект. Хорошо хоть структура вопросов зафиксирована.
Мы не стали фанатами стандарта и не рекомендуем его как единственный ориентир. Но как структуру для разговора с заказчиком - что проверять, что документировать, где риски - он работает. После Stuxnet у клиентов появился запрос на системность, а не просто «закройте дыру». 62443 этот запрос отчасти закрывает.
Насколько широко его начнут применять в России - посмотрим. ФСТЭК развивает собственную нормативную базу, которая идёт параллельным курсом. Пока международный стандарт и отечественные требования живут в разных мирах, хотя пересечений достаточно.