Защита АСУ ТП: как доказать соответствие требованиям безопасности

🔍 Что именно нужно подтвердить

АСУ ТП управляет технологическим процессом. Она включает контроллеры, серверы, рабочие места и сети.

Проверка безопасности не равна проверке промышленной безопасности. Эти области связаны, но имеют разные цели и документы.

Промышленная безопасность снижает риск аварий. Информационная безопасность защищает данные и управление.

Одна система может одновременно попадать в обе области. Поэтому команда сначала разделяет требования.

Нельзя считать сертификат универсальным доказательством. Его действие связано с границами оценки.

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

Отдельно описывают внешние системы. К ним относятся подрядчики, диспетчерские центры и сервисные площадки.

Если объект относится к КИИ, применяют требования Федерального закона № 187-ФЗ. Для значимых объектов КИИ дополнительно проверяют применимость приказа ФСТЭК России № 31.

Этот приказ связан с защитой значимых объектов КИИ. Он также касается управления технологическими процессами.

Сначала составьте короткое описание объекта. Укажите процесс, владельца, границы и ответственных лиц.

Что сделать сейчас: разделите требования промышленной безопасности и информационной безопасности.

📌 Как определить границы АСУ ТП

Оценка начинается с точного описания системы. Без этого проверка быстро теряет смысл.

В перечень включают серверы, рабочие места и контроллеры. Также фиксируют сетевое оборудование и средства защиты.

Нужно показать технологические контуры. Каждый контур связывают с конкретной функцией процесса.

Схема должна отражать реальные соединения. Формальной схемы из старого проекта недостаточно.

Отдельно отмечают каналы между зонами. Для каждого канала указывают направление и назначение.

Так команда видит лишние связи. Она также находит неучтённые удалённые подключения.

В границы входят учётные записи. В список попадают инженеры, операторы и подрядчики.

Нужно указать зоны ответственности. Владелец процесса не всегда отвечает за сеть.

Такая граница помогает распределить задачи. Она также упрощает сбор доказательств.

• Опишите назначение каждого технологического контура.
• Свяжите активы с владельцами и ответственными.
• Отметьте внешние каналы и точки удалённого доступа.
• Зафиксируйте версии оборудования и программ.
• Укажите границу будущей оценки.

После инвентаризации сравните схему с настройками. Несовпадения внесите в отдельный список.

Что сделать сейчас: проведите сверку схемы сети с фактическими соединениями.

⚖️ Как выбрать применимые требования

Одна АСУ ТП может подчиняться разным наборам норм. Сначала определяют статус объекта.

Если система связана со значимым объектом КИИ, применяют соответствующие требования. Важную роль играет Федеральный закон № 187-ФЗ.

Далее проверяют требования к защите. Для значимых объектов оценивают применимость приказа ФСТЭК России № 31.

Нельзя переносить требования другой системы без проверки. Разные объекты имеют разные границы и риски.

Категорирование или классификация задаёт основу оценки. Результат нужно хранить вместе с обоснованием.

В документе указывают исходные данные. Также фиксируют решение ответственных лиц.

После выбора норм составляют перечень требований. Каждое требование получает понятный способ проверки.

Например, доступ проверяют по матрице ролей. Журналирование проверяют по настройкам и записям событий.

Неиспользуемые требования тоже нужно объяснять. Молчание создаёт пробел в доказательствах.

Такой подход создаёт матрицу соответствия. Она показывает состояние системы без общих фраз.

Что сделать сейчас: составьте таблицу применимых требований и способов их проверки.

🧩 Как подготовить модель угроз

Модель угроз объясняет, от чего защищается система. Она связывает риски с конкретными мерами.

В модели описывают нарушителя. Указывают его доступ, цели и возможные действия.

Нужно учитывать внутренние и внешние сценарии. Отдельно рассматривают ошибки сотрудников и подрядчиков.

Для АСУ ТП важен технологический эффект. Потеря управления может нарушить процесс.

Команда описывает критичные компоненты. К ним относят средства, от которых зависит управление.

Затем определяют последствия нарушения. Это помогает выбрать разумные компенсирующие меры.

Модель должна соответствовать реальной архитектуре. Изменение сети требует её пересмотра.

Нельзя ограничиваться списком общих угроз. Каждая угроза должна иметь связь с активом.

Также нужна связь с защитной мерой. Проверяющий должен видеть логику принятого решения.

Модель угроз не заменяет испытания. Она задаёт основу для программы проверки.

Если система получает новые функции, модель обновляют. Особенно важны новые каналы и роли.

Что сделать сейчас: свяжите каждую критичную угрозу с активом и защитной мерой.

🛠️ Какие документы собирают для проверки

Доказательства соответствия состоят из разных документов. Один отчёт не заменяет весь комплект.

Базовый пакет начинается с описания объекта. В него входит назначение системы и её границы.

Далее прикладывают схему сети. Она должна показывать зоны и каналы обмена.

Нужен перечень оборудования и программ. Для компонентов фиксируют версии и владельцев.

Также собирают модель угроз. К ней добавляют матрицу соответствия требованиям.

Политики и регламенты показывают порядок работы. В них описывают доступ, резервирование и реагирование.

Матрица доступа показывает права пользователей. Она должна отражать реальные роли.

Журналы событий подтверждают работу контроля. Важно указать период и источник записей.

Результаты анализа уязвимостей входят в пакет. К ним добавляют оценку рисков и план исправления.

Проверка конфигураций также требует протоколов. В протоколе фиксируют объект, дату и результат.

Отдельно хранят планы резервного копирования. Нужны и записи проверок восстановления.

Для испытаний готовят программу и методики. В них задают порядок, критерии и ожидаемый результат.

• Паспорт или описание объекта.
• Актуальная схема сети и зон.
• Перечень активов, программ и учётных записей.
• Модель угроз и модель нарушителя.
• Матрица требований и мер защиты.
• Протоколы проверок и испытаний.
• Журналы событий и отчёты мониторинга.
• Планы резервирования и восстановления.

Документы должны совпадать между собой. Разные названия одного актива создают сомнения.

Что сделать сейчас: заведите реестр доказательств с владельцем каждого документа.

🔐 Как проверить доступ и технологическую сеть

Доступ проверяют не только по наличию пароля. Важно понять права и порядок их выдачи.

Для каждой роли задают минимальные полномочия. Оператору не нужны права администратора.

Учетные записи подрядчиков требуют отдельного контроля. Их доступ ограничивают временем и задачей.

Неактивные записи удаляют или блокируют. Общие учётные записи усложняют расследование.

При удалённом обслуживании фиксируют канал и владельца. Также записывают время и цель работ.

Сетевую архитектуру делят на зоны. Между зонами оставляют только нужные соединения.

Каждый канал должен иметь понятное назначение. Неиспользуемые соединения закрывают после проверки.

Обмен контролируют средствами защиты. События такого обмена попадают в журналы.

Сегментация снижает область возможного инцидента. Она не отменяет контроль учётных записей.

Для удалённых работ задают отдельный порядок. Он должен учитывать непрерывность технологического процесса.

После завершения работ доступ закрывают. Результат фиксируют в журнале.

Что сделать сейчас: сравните список учётных записей с текущими сотрудниками и подрядчиками.

📊 Как управлять уязвимостями и обновлениями

АСУ ТП нельзя обновлять так же, как обычный офисный компьютер. Сначала оценивают влияние на процесс.

Инвентаризация показывает состав программ. Без неё невозможно понять область уязвимости.

Вспомогательные серверы тоже входят в проверку. Уязвимость в веб-интерфейсе может затронуть промышленную систему.

Например, Apache Tomcat применяют в веб-интерфейсах. Он может работать в диспетчерских и вспомогательных системах.

CVE-2015-5351 получила оценку CVSS 8.8. Она связана с обходом защиты от межсайтовой подделки запросов.

Уязвимость затрагивает Manager и Host Manager. Это пример риска для веб-компонента.

CVE-2014-7810 получила оценку CVSS 5.0. Она связана с обходом SecurityManager в Expression Language.

Обе уязвимости опубликованы давно. Их нельзя считать доказательством риска всей АСУ ТП.

Они показывают другую задачу. Организация должна знать версии компонентов и меры защиты.

Если обновление нельзя установить сразу, описывают причину. Затем назначают компенсирующие меры.

План должен учитывать простой процесса. Каждое решение согласуют с владельцем технологии.

Результат проверки записывают в реестр. В нём указывают статус, срок и ответственного.

Что сделать сейчас: найдите версии веб-компонентов и свяжите их с реестром уязвимостей.

🧪 Как проводить испытания и оценку мер

Испытания проверяют работу выбранных мер. Они должны опираться на программу и методики.

Сначала задают цель проверки. Затем описывают объект и безопасный порядок действий.

Для каждой меры устанавливают критерий. Результат должен быть проверяемым и понятным.

Настройки средств защиты проверяют на практике. Одного снимка экрана иногда недостаточно.

Журналирование проверяют тестовым событием. Затем смотрят запись и путь её хранения.

Резервное копирование проверяют восстановлением. Копия без успешного восстановления не даёт полной уверенности.

Контроль доступа проверяют по ролям. Тест показывает разрешённые и запрещённые действия.

Сетевые меры проверяют по каналам. Нужно убедиться, что обмен соответствует схеме.

Испытания проводят без вреда для процесса. Работы согласуют с ответственными за технологию.

Каждый результат заносят в протокол. Там указывают условия, действия и итог.

Несоответствие не скрывают. Для него назначают срок исправления и временную меру.

Что сделать сейчас: составьте перечень испытаний для доступа, журналов, сети и восстановления.

✅ Как оформить итоговое подтверждение

Финальный документ должен показывать логику оценки. Он связывает объект, требования, меры и результаты.

Сначала указывают границы системы. Затем приводят применимые нормативные основания.

После этого описывают найденные риски. Для каждого риска показывают принятую меру.

Если мера работает частично, это фиксируют. Также указывают остаточный риск.

Отдельно перечисляют исключения. Для каждого исключения нужно обоснование.

В итог включают протоколы испытаний. Ссылки ведут на конкретные документы и записи.

Аттестация является отдельной процедурой. Она включает ряд мероприятий и выдачу аттестата соответствия.

Такой аттестат служит документарным доказательством. Он относится к проверенному объекту и условиям оценки.

Аттестация может быть обязательной или добровольной. Решение зависит от применимых требований и типа объекта.

Для процедуры готовят программу и методики. Также оценивают применяемые средства защиты.

Учитывают и условия эксплуатации объекта. Это важно для реальной, а не формальной оценки.

Один отчёт не подтверждает постоянную защищённость. После изменений систему оценивают снова.

Новые версии, каналы и роли меняют картину рисков. Поэтому комплект доказательств регулярно обновляют.

Что сделать сейчас: проверьте, что итоговый документ связан с актуальной схемой и реальными настройками.

🔮 Как поддерживать соответствие после проверки

Соответствие требует постоянного контроля. Система меняется вместе с технологическим процессом.

Изменения проходят через установленный порядок. До работ оценивают влияние на защитные меры.

После работ обновляют схему и перечень активов. Затем повторяют нужные проверки.

Подрядчики также влияют на состояние системы. Их действия должны попадать в общий контроль.

Нужно регулярно пересматривать доступ. Сотрудники меняют роли, а договоры заканчиваются.

Журналы помогают увидеть отклонения. Мониторинг показывает необычные действия и связи.

Команда должна проверять резервные копии. Восстановление проводят по утверждённому плану.

Управление уязвимостями продолжается после оценки. Новые сведения требуют анализа применимости.

Отдельный вызов создаёт самоэволюционирующееся программное обеспечение. Агент может менять систему по намерению пользователя.

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

Из-за этого меняется объект проверки. Нельзя оценить только заранее заданный набор экранов.

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

Любое изменение должно иметь автора и причину. После изменения проверяют его влияние на защиту.

Практика подтверждения соответствия строится вокруг доказательств. Чем точнее связь между требованием и проверкой, тем надёжнее итог.

Что сделать сейчас: назначьте периодический пересмотр схемы, доступа, уязвимостей и протоколов.

📚 Читайте также

• Публичное облако и АСУ ТП: как защитить ключи от цепной компрометации
• Запрос на сброс пароля оказался атакой: расследование в IDM
• Квантовая угроза архивам: защита данных от атаки «сейчас собирай»
• Дипфейк начальника в видеозвонке: как распознать срочный обман
• Зашифрованный диск выключенного ноутбука: границы реальной защиты

📖 Термины

IAM (Identity and Access Management) · Ics Security · Plc · Scada · КИИ

🔗 Источники

• Аттестация объектов информатизации(2026-10-19 ✓)
• Ландшафт угроз для систем промышленной автоматизации. Второй квартал 2026 года(2026-08-29 ✓)
• Самоэволюционирующееся ПО и новые вызовы в оценке соответствия требованиям ИБ(2026-10-19 ✓)