Информационная безопасность промышленности

Специфика отрасли в промышленности — это сочетание непрерывных технологических процессов, высоких рисков для жизни и экологии и жёстких требований регуляторов к АСУ ТП и объектам.

Важно честно сказать: промышленность атакуют системно, и в 2024–2026 годах это усилилось из-за:

• роста удалённого обслуживания,
• смешения IT/OT,
• зависимости от подрядчиков,
• импортозамещения «в спешке» без выстроенной архитектуры.

Ниже — типовая матрица угроз.


Критическая особенность отрасли: последствия могут быть не только финансовыми, но и:

• травмы персонала,
• экологические инциденты,
• останов опасных производственных объектов,
• риск претензий надзорных органов.

Поэтому зачастую объекты промышленности и относят к категории “значимых” и однозначно “критичных” информационных систем.

Вот где промышленность отличается от «обычного бизнеса». В ряде случаев вы обязаны защищаться, даже если «не хочется» и «дорого».

1) КИИ: Федеральный закон №187-ФЗ «О безопасности КИИ РФ»

Если предприятие/его объекты относятся к субъектам КИИ, появляется комплекс обязанностей:

• идентификация и категорирование объектов КИИ (что является значимым объектом, какая категория 1–3);
• создание системы защиты значимых объектов, назначение ответственных за защиту;
• выполнение требований регуляторов (ФСТЭК/ФСБ в части их компетенций);
• реагирование на компьютерные инциденты и взаимодействие с инфраструктурой обмена сведениями (ГосСОПКА) по установленным правилам;
• в целом устойчивость и недопустимость нарушения работы ЗОКИИ.

В промышленности типовые кандидаты на КИИ:

• АСУ ТП непрерывных циклов (химия, нефтехимия, металлургия),
• диспетчеризация и управление критическими ресурсами,

обычно это все системы, сбой которых ведёт к значимому ущербу или угрозе безопасности.

Сюда же можно отнести приказ №31, который регламентирует необходимость безопасной работы технологического процесса и оборудования с целью снижения риска ЧС из‑за НСД или сбоев. Это касается всех - даже тех, кто не является ЗОКИИ.

2) Требования ФСТЭК: Приказ №239

Приказ ФСТЭК №239 задаёт обязательный набор организационных и технических мер для значимых объектов КИИ (ЗОКИИ).

Что важно на практике (юридически и технически):

• должна быть модель угроз и нарушителя именно для вашего объекта;
• необходимо разработать подсистему безопасности для каждого ЗОКИИ;
• должна быть архитектура сегментации, разграничение доступа, контроль взаимодействий;
• должен быть мониторинг событий безопасности, управление уязвимостями, контроль целостности;
• должны быть регламенты (ОРД), процедуры реагирования, расследования, управления изменениями;
• должны быть результаты испытаний/проверок, подтверждающие работоспособность мер.

То есть это не «мы поставили коробку NGFW». Это система мер, которую можно показать на проверке.

3) Криптография и компетенции ФСБ

В промышленности криптография часто требуется для:

• защищённых каналов между площадками,
• удалённого доступа,
• передачи технологических данных,
• юридически значимого ЭДО.

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

Для эксплуатации СКЗИ субъекту КИИ не нужно будет получать лицензию ФСБ на этот вид деятельности, если оборудование было куплено и настроено лицензиатом, а дальше просто используется в соответствии с формуляром и правилами на объекте. Однако, если организация распределенная и собственная служба ИТ начинает оказывать “услуги” по настройке и сопровождению - вот тогда уже может потребоваться лицензия от ФСБ!

4) Персональные данные: 152-ФЗ (как сопутствующий контур)

Промпредприятие почти всегда обрабатывает ПДн:

• сотрудники (кадры),
• пропускной режим/СКУД,
• медосмотры,
• подрядчики, посетители.

Это означает необходимость выполнения 152-ФЗ и подзаконных требований, а именно Постановление 1119, приказ ФСТЭК 21.

Придется назначать ответственного за защиту ПДн, утвердить политику, не забыть уведомить Роскомнадзор, создать систему защиты для обеспечения конфиденциальности и целостности обрабатываемых ПДн, вести учет инцидентов и сообщать об утечках. Важно все задокументировать, разработать и утвердить акты, доказать, что набор организационно-технических мер внедрен и работает  - иначе “не считается”.

Из мер защиты приказ 21 требует: аутентификацию, управление доступом, антивирус, межсетевое экранирование, контроль целостности, резервное копирование, защита каналов связи, журналирование - при этом должны использоваться “проверенные” СЗИ. Важно также регулярно проводить контроль и аудит.

5) Конфиденциальная информация и коммерческая тайна

Дополнительно мы упоминали, что

• 49‑ФЗ «Об информации…» требует для владельцев и операторов информационных систем (включая АСУ ТП, корпоративные ИС) обеспечить защиту информации от несанкционированного доступа (НСД), утечки, модификации и уничтожения, определить порядок доступа к информации, внедрить меры по предотвращению, выявлению и пресечению нарушений, соблюдать требования специальных законов и подзаконных актов.
• 98‑ФЗ «О коммерческой тайне»
Требует установить режим коммерческой тайны (перечень сведений, маркировка, порядок доступа), принять организационные и технические меры по защите конфиденциальной информации (регламенты, СЗИ, контроль носителей, защита каналов связи), оформлять договорные обязательства о неразглашении с сотрудниками и подрядчиками.

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

6) IEC 62443, ISO 27001/27019 NIST SP 800-82 - как лучшие практики OT-архитектуры

Если основные нормативные требования в виде 187‑ФЗ и связанных приказов (в том числе 152‑ФЗ) задают обязательные к исполнению требования, то перечисленные здесь стандарты - это методологическая надстройка, которая показывает как строить систему, чтобы не только формально выполнить требования, но и реально повысить устойчивость, “правильно” складывая кубики.

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

IEC 62443 — это не «сертификат ради моды». Это понятная для OT (и ИБшников) логика:

• разделение на зоны (по функции и критичности),
• кондуиты (контролируемые связи),
• целевые уровни безопасности (SL), где для многих промышленных сегментов разумно проектировать SL 3–4 на критичных участках.

ISO 27001/27019 предназначены для менеджмента и определяют правила создания СУИБ на предприятии:

• построения процесса управления рисками, инцидентами, доступом, изменениями;
• выстраивания политики, ролей, процедур, аудита;
• формирования «зонтика», под которым живут все отраслевые требования.

NIST SP 800‑82 - это хорошее подробное руководство по защите ICS/SCADA, как справочник по типовым архитектурам, угрозам и мерам.
Обычно его используют:

• как источник типовых архитектур и перечней мер, которые затем «переводят» на язык 239‑го приказа и российских СЗИ;
• как обоснование при проектировании: «почему мы делаем так, а не иначе» - всегда лучше “выбирать из справочника”, чем придумывать самому.

В промышленности импортозамещение — это не “заменим антивирус”. Это:

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

При проектировании мы учитываем:

• ограничения на иностранное ПО и оборудование в регулируемых контурах,
• требования по сертификации (где применимо),
• совместимость с промышленными протоколами,
• стабильность в условиях 24/7 и ограничения на вмешательство в OT.

В промышленности «типовой офисный» подход ломается. Здесь ключевые принципы такие:

1. Безопасность людей и оборудования

• Недопущение аварий, вреда персоналу, разрушения агрегатов из‑за некорректного управления.
• Любая мера ИБ не должна «ломать» технологию — принцип «не навреди процессу».

2. Непрерывность технологического процесса

• Минимизация простоев линий/цехов, отказоустойчивость АСУ ТП и сетей OT.
• Устойчивость к сбоям/атакам в пределах допустимого времени восстановления.

3. Сохранность и предсказуемость управления

• Защита конфигураций ПЛК/SCADA, сценариев ПАЗ (противоаварийной защиты), рецептур.
• Исключение несанкционированных изменений и «скрытых» закладок.

4. Контроль и наблюдаемость

• Возможность увидеть, кто и что сделал в сети и на оборудовании.
• Централизованный журнал, мониторинг аномалий трафика и действий.

5. Ограничение влияния ИТ-инцидентов на OT

• Чёткое разделение офисной и производственной среды.
• Любой инцидент в IT не должен автоматически распространяться на технологический сегмент (ОТ).

1) Зонирование и сегментация

• Делим инфраструктуру на зоны: офисная ИТ, DMZ, зона мониторинга/интеграций, OT‑ядро (SCADA, серверы), полевая сеть (ПЛК, РЗА и т.п.).
• Между зонами — строго определённые «каналы» (conduits) с фильтрацией, инспекцией и, где нужно, криптозащитой.

2) Жёсткая граница IT/OT

• DMZ между корпоративной сетью и АСУ ТП: там живут отчётность, реплики БД, серверы обновлений, удалённый доступ.
• Прямой доступ с офисных АРМ к ПЛК/SCADA запрещён, только через выделенные jump‑host’ы и контролируемые механизмы.

3) Многоуровневая защита (defence in depth) и управление доступом

• только четкое зонирование: периметр предприятия → граница IT/OT → сегменты внутри OT → сами узлы.
• На каждом уровне свой набор средств: от межсетевых экранов и маршрутизации до контроля целостности прошивок и белых списков ПО на АРМ.

4) Управление доступом и контроль привилегий (особенно инженеров и подрядчиков)

• Централизованное управление учетными записями и ролями для админов, технологов, подрядчиков.
• Принцип «минимально необходимого» доступа и ограничение временных прав (just in time).

5) Контроль изменений и целостности

• Формализованные процедуры изменения логики ПЛК/SCADA, конфигураций сетевого оборудования.
• управление “золотыми образами” инженерных станций, контроллеров;
• Средства контроля целостности (образы прошивок, файлы проекта, конфигурации), обязательное резервное копирование, регулярная сверка конфигураций

6) Специализированный мониторинг OT без “убийства” технологического трафика

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

7) Устойчивость и план аварийного управления

• Резервирование критичных звеньев: коммуникаций, серверов SCADA, ключевых ПЛК/контроллеров.
• Проработанные процедуры перехода в безопасные режимы (fallback, ручное управление) при ИБ‑инцидентах.
• отработанные регламенты восстановления с понятным RTO/RPO.

8) Уязвимости и обновления: безопасный процесс

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

Цель архитектуры — сохранить управляемость и безопасность, не замедлив производство и не создавая риски остановов из-за защитных средств.

9) Снижение зависимости от внешних сервисов и импортозамещение

• Максимально автономная работа критичных сегментов (минимум облаков/Интернета в контуре OT).
• Использование отечественных, сертифицированных средств защиты и платформ, чтобы не зависеть от санкций и снятых с поддержки решений.

В промышленности важен не набор «модных» продуктов, а увязанная линейка решений под АСУ ТП, КИИ и офисную ИТ‑среду с понятными сценариями применения. Главное - не навредить, но и не дать развиться негативному сценарию при инциденте безопасности.

В результате внедрения системы ИБ предприятие получает:

1. Соответствие 187-ФЗ и требованиям ФСТЭК по 239-му приказу (где применимо)
Это снижает риск претензий регуляторов, проблем при проверках и формирует доказуемую базу выполнения требований.

2. Непрерывность производства и снижение простоев при инцидентах
Появляются:

• понятные RTO/RPO,
• процедуры восстановления,
• резервирование критичных сервисов,
• сценарии реагирования.

3. Контроль стыка между IT и OT и снижение вероятности “прохода в технологию”
Это главная практическая цель большинства проектов в промышленности.

4. Защита АСУ ТП и инженерного сегмента
Снижает риск:

• несанкционированных изменений техпроцесса,
• аварийных режимов,
• потери управляемости.

5. Защита коммерческой тайны и R&D
Минимизирует утечки того, что действительно стоит денег и рынка. Обычно именно за это больше всего переживает “бизнес”, а не за “излишние выбросы в атмосферу”.

6. Управляемый удалённый доступ подрядчиков
Вместо хаотичных исключений и “вечных учёток” — прозрачная модель и контроль.

7. Импортозамещение без потери управляемости и безопасности
Не «заменили всё на российское и стало хуже», а спроектировали переход так, чтобы производство не пострадало.