Что ИБ-директора недооценивают при внедрении комплексной защиты

Формально такой подход выглядит корректно, но на практике именно он становится причиной большинства проблем при эксплуатации. Защита оказывается внедренной, но не встроенной в реальную архитектуру и процессы предприятия. В такой логике комплексная защита обычно воспринимается как набор средств безопасности и регламентов, формально обеспечивающих соответствие обязательным требованиям. Реализация строится по принципу выполнения предписаний, зафиксированных в нормативных документах. В результате защита превращается в совокупность разрозненных решений и документов, которые слабо связаны между собой и не образуют целостную систему. При этом упускается главное: комплексная защита — это не технологии сами по себе, а изменение процессов и подходов к управлению безопасностью. Если безопасность не встроена в систему управления, она остается внешней надстройкой и не закрывает реальные архитектурные и процессные риски. Именно здесь и возникают проблемы: средства защиты работают изолированно, регламенты живут собственной жизнью, а фактическая устойчивость системы остается на бумаге. Большинство этих проблем закладывается еще на старте — в виде недооценок при проектировании и внедрении комплексной защиты. В этой статье предлагаем разобрать, какие из них встречаются чаще всего и к каким последствиям они приводят.

Недооценка «невидимых» активов за пределами ИТ-периметра

Часть технологической инфраструктуры регулярно остается вне поля зрения ИБ-директоров из-за разрыва ответственности между подразделениями. Активы, находящиеся в зоне производственных служб, не воспринимаются ИТ и ИБ как часть управляемого контура, а технологи, в свою очередь, не считают их объектами информационной безопасности. В результате эти элементы выпадают из процессов защиты, хотя напрямую участвуют в технологическом процессе. В первую очередь это инженерные и технологические станции — отдельные ноутбуки и планшеты, используемые в цехах для настройки и обслуживания оборудования. Они не входят в домен, не управляются ИТ и зачастую даже не учтены формально. К этой же категории относятся встроенные (embedded) системы, программируемые логические контроллеры (ПЛК) с сетевыми интерфейсами, пассивное сетевое оборудование в цехах, а также устройства «Индустриального интернета вещей» (IIoT): датчики, умные счетчики и камеры, закупленные производственными подразделениями в обход ИТ. Для систем ИБ таких устройств зачастую не существует, а значит, на них не распространяются ни контроль, ни мониторинг, ни требования по обновлениям и реагированию.

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

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

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

Недооценка инженерных ограничений АСУ ТП при внедрении защиты

Попытка внедрять защиту АСУ ТП по принципам обычных ИТ-проектов почти всегда приводит к сбоям. Причина в инженерных ограничениях, которые невозможно обойти управленческими решениями. Любые изменения в АСУ ТП жестко привязаны к технологическим остановам. Защиту нельзя внедрять «на ходу»: обновления и настройка средств безопасности возможны только в заранее запланированные окна, которые зависят от производственного графика и исключают быстрые итерации. Дополнительным ограничением становится длительный жизненный цикл оборудования. Контроллеры и SCADA работают годами, а иногда десятилетиями, тогда как современные средства защиты обновляются значительно чаще и не всегда совместимы с устаревшими ОС, протоколами и аппаратными платформами. В результате защита вынуждена подстраиваться под технологию, а не наоборот. Отдельная специфика — требования к работе в реальном времени. АСУ ТП чувствительны к задержкам, и стандартные ИТ-средства защиты, вносящие дополнительную нагрузку, могут нарушать управление процессом.  Критически важным требованием является также отказоустойчивость: средства защиты не должны создавать «единую точку отказа», способную остановить технологический цикл. Ситуацию усугубляют промышленные протоколы, изначально не рассчитанные на современные механизмы безопасности и плохо поддающиеся анализу стандартными ИТ-инструментами. Поэтому прямое копирование ИТ-практик в АСУ ТП либо не работает, либо создает новые риски, сопоставимые с теми, от которых защита должна избавлять.

Недооценка расхождения жизненных циклов защиты и оборудования

Еще один системный фактор риска — несовпадение жизненных циклов средств защиты и технологического оборудования. Защита обновляется каждые несколько лет из-за новых уязвимостей и угроз, тогда как оборудование АСУ ТП остается неизменным на протяжении десятилетий. Со временем новые средства безопасности все хуже взаимодействуют со старыми активами и не учитывают их архитектурные ограничения. Это приводит к архитектурной деградации: защита становится формальной или начинает мешать технологическому процессу, а в системе появляются разрывы совместимости, закрываемые временными и компенсирующими мерами. Чем дольше эти разрывы игнорируются, тем сложнее вернуть архитектуре целостность. Решения наслаиваются друг на друга, и вместо управляемой системы защиты формируется набор компромиссов, снижающий общую устойчивость АСУ ТП.

Недооценка реальных точек риска в архитектуре

При проектировании комплексной защиты чаще всего недооцениваются точки риска, которые воспринимаются как временные или вспомогательные, но на практике остаются в системе надолго. В первую очередь это точки удаленного администрирования. Их сохраняют «на всякий случай» для быстрого доступа к критическим активам, но именно они становятся одной из самых сложных зон с точки зрения последующей защиты и контроля. Еще одна уязвимая область — технологические сегменты вне основного периметра. Это активы, которые не попадают в зону видимости ИТ и ИБ, например, оборудование, закупленное производственными подразделениями напрямую. Такие активы появляются в инфраструктуре без учета в архитектуре защиты и остаются вне планов по мониторингу и сопровождению. Дополнительный риск создают временные каналы связи. Подключения для удаленной работы подрядчиков, временный выход в интернет или соединение с офисной сетью часто воспринимаются как разовые меры, но фактически они либо используются повторно, либо остаются в системе, формируя неконтролируемые точки входа.

Недооценка необходимости карты активов и потоков

Несмотря на критическую важность, карта активов и информационных потоков редко строится на практике. Основная причина — сложность этой задачи. Она требует работы не только с ИТ-службой, но и с технологами, а также глубокого понимания реальной архитектуры промышленных сетей. Речь идет не просто о сетевой схеме, а о понимании того, как данные и сигналы проходят через уровни АСУ ТП — от полевого оборудования до верхнего уровня управления. Без этого невозможно корректно определить границы доверия, точки входа и реальные векторы атак. Пока такой карты нет, защита опирается на предположения, а не на фактическую топологию системы.

Недооценка эксплуатационной стадии по сравнению с внедрением

На этапе внедрения система защиты только проектируется и настраивается. Реальные проблемы проявляются позже — в процессе эксплуатации. Именно здесь становится понятно, насколько архитектура жизнеспособна и управляема.

Ключевая ошибка ИБ-директоров — игнорирование этапов check и act в цикле Деминга-Шухарта. Система должна не только работать, но и регулярно проверяться, анализироваться и корректироваться. На практике же изменения конфигурации часто происходят без контроля и документации: меняются адреса рабочих станций и контроллеров, появляются новые учетные записи, временные доступы становятся постоянными.

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

Недооценка процессов контроля изменений и работы с подрядчиками

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

Особенно остро это проявляется при работе с подрядчиками. Состав внешних специалистов меняется, появляются новые подрядные организации, в том числе из-за импортозамещения. Эти сценарии часто не предусмотрены на этапе проектирования, а взаимодействие с ними выстраивается ситуативно, без формализованных процедур и контроля со стороны ИБ.

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

Недооценка отсутствия владельца технологического риска

Одна из ключевых недооценок при внедрении комплексной защиты — отсутствие единого владельца технологического риска. АСУ ТП формально относят к ИТ, безопасность замыкают на ИБ, а фактическая ответственность за непрерывность и устойчивость процесса остается размытой между подразделениями. В результате технологический контур оказывается без управляемого центра принятия решений.

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

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

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

Инженерный подход к распределению ответственности между ИБ, ИТ и технологами

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

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

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

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

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

В результате безопасность перестает быть внешней надстройкой и становится частью системы управления производством. Именно это отличает формальную «комплексную защиту» от реально работающей.

Что должно быть определено до начала внедрения комплексной защиты

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

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

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

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