Обсуждая комплексную защиту, ИБ-директора чаще всего фокусируются на средствах, требованиях регуляторов и документации. Формально это выглядит корректно, но в результате на практике защита оказывается внедренной, но не встроенной в архитектуру и процессы предприятия. То есть она превращается в набор разрозненных решений, формально соответствующих требованиям, но не обеспечивающих реальной устойчивости. В этом кроется ключевая ошибка – воспринимать комплексную защиту как набора технологий, а не как изменения процессов и модели управления безопасностью.
Невидимые активы за периметром
Часть технологической инфраструктуры регулярно остается вне поля зрения ИБ из-за разрыва ответственности между подразделениями. Активы, находящиеся в зоне производственных служб, не воспринимаются ИТ и ИБ как часть управляемого контура, а технологи, в свою очередь, не считают их объектами информационной безопасности. В результате эти элементы выпадают из процессов защиты, хотя напрямую участвуют в технологическом процессе. В первую очередь это инженерные и технологические станции – отдельные ноутбуки и планшеты, используемые в цехах для настройки и обслуживания оборудования. Они не входят в домен, не управляются ИТ и зачастую даже не учтены формально. К этой же категории относятся встроенные (Embedded) системы, программируемые логические контроллеры (ПЛК) с сетевыми интерфейсами, пассивное сетевое оборудование в цехах, а также устройства индустриального интернета вещей (IIoT): датчики, умные счетчики и камеры, закупленные производственными подразделениями в обход ИТ. Для систем ИБ таких устройств зачастую не существует, а значит, на них не распространяются ни контроль, ни мониторинг, ни требования по обновлениям и реагированию.
Вторая проблемная зона – сервисные технологические учетные записи. Они используются в ПО АСУ ТП, контроллерах и активном сетевом оборудовании, но не интегрированы с централизованными системами управления доступом. Парольная политика для них часто отсутствует, контроль использования не ведется, а сами учетные записи живут годами без пересмотра и анализа защищенности.
Отдельный риск представляет удаленный доступ подрядчиков, который нередко организуется технологами напрямую, в обход ИТ и ИБ. В таких случаях в инфраструктуре появляются рабочие станции и каналы доступа, о которых службы безопасности могут не знать вовсе, но которые при этом используются для реального воздействия на технологический контур.
Инженерные ограничения АСУ ТП
Попытка внедрять защиту АСУ ТП по принципам обычных ИТ-проектов почти всегда приводит к сбоям. Причина в инженерных ограничениях, которые невозможно обойти управленческими решениями. Любые изменения в АСУ ТП жестко привязаны к технологическим остановам. Защиту нельзя внедрять на ходу: обновления и настройка средств безопасности возможны только в заранее запланированные временные окна, которые зависят от производственного графика и исключают быстрые итерации. Дополнительным ограничением становится длительный жизненный цикл оборудования. Контроллеры и SCADA работают годами, а иногда десятилетиями, тогда как современные средства защиты обновляются значительно чаще и не всегда совместимы с устаревшими ОС, протоколами и аппаратными платформами. В результате защита вынуждена подстраиваться под технологию, а не наоборот. Отдельная специфика касается требований к работе в реальном времени. АСУ ТП чувствительны к задержкам, и стандартные ИТ-средства защиты могут нарушать управление процессом.
Критически важным требованием является также отказоустойчивость: средства защиты не должны создавать единую точку отказа, способную остановить технологический цикл. Ситуацию усугубляют промышленные протоколы, изначально не рассчитанные на современные механизмы безопасности и плохо поддающиеся анализу стандартными ИТ-инструментами.
Еще один системный фактор риска – несовпадение жизненных циклов средств защиты и технологического оборудования. Защита обновляется каждые несколько лет из-за новых уязвимостей и угроз, а оборудование АСУ ТП остается неизменным на протяжении десятилетий. Со временем новые средства безопасности все хуже взаимодействуют со старыми активами и не учитывают их архитектурные ограничения. Это приводит к архитектурной деградации: защита становится формальной или начинает мешать технологическому процессу, а в системе появляются разрывы совместимости, закрываемые временными и компенсирующими мерами.
Точки риска в архитектуре
При проектировании комплексной защиты чаще всего недооцениваются точки риска, которые воспринимаются как временные или вспомогательные, но на практике остаются в системе надолго. В первую очередь это точки удаленного администрирования. Их сохраняют на всякий случай для быстрого доступа к критическим активам, но именно они становятся одной из самых сложных зон с точки зрения последующей защиты и контроля. Дополнительный риск создают временные каналы связи. Подключения для удаленной работы подрядчиков, временный выход в интернет или соединение с офисной сетью часто воспринимаются как разовые меры, но фактически они либо используются повторно, либо остаются в системе, формируя неконтролируемые точки входа.
Карта активов и потоков
Несмотря на исключительную важность, карта активов и информационных потоков редко строится на практике. Основная причина кроется в сложности этой задачи. Она требует работы не только с ИТ-службой, но и с технологами, а также глубокого понимания реальной архитектуры промышленных сетей. Речь идет не просто о сетевой схеме, а о понимании того, как данные и сигналы проходят через уровни промышленных систем – от полевого оборудования до верхнего уровня управления. Без этого невозможно корректно определить границы доверия, точки входа и реальные векторы атак. Пока такой карты нет, защита опирается на предположения, а не на фактическую топологию системы.
Сложности на стадии эксплуатации
На этапе внедрения система защиты только проектируется и настраивается. Реальные проблемы проявляются позже, в процессе эксплуатации. Именно здесь становится понятно, насколько архитектура жизнеспособна и управляема.
Ключевая ошибка – игнорирование этапов Check и Act в цикле Деминга-Шухарта. Система должна не только работать, но и регулярно проверяться, анализироваться и корректироваться. На практике же изменения конфигурации часто происходят без контроля и документации: меняются адреса рабочих станций и контроллеров, появляются новые учетные записи, временные доступы становятся постоянными.
Если эти изменения не отслеживаются, система защиты постепенно теряет актуальность. Ошибки, допущенные на этапе проектирования, начинают накапливаться, и через некоторое время защита либо перестает выполнять свою функцию, либо начинает мешать работе.
Контроль изменений и работа с подрядчиками
При проектировании комплексной защиты редко закладываются процессы постоянного контроля изменений и управления эксплуатацией. Предполагается, что система будет работать в идеальном состоянии и не потребует вмешательства, но в реальности технологическая среда постоянно меняется.
Особенно остро это проявляется при работе с подрядчиками. Состав внешних специалистов меняется, появляются новые подрядные организации, в том числе из-за процессов импортозамещения. Эти сценарии часто не предусмотрены на этапе проектирования, а взаимодействие с ними выстраивается ситуативно, без формализованных процедур и контроля со стороны ИБ. В результате защита остается статичной, тогда как сама система живет и развивается. Именно этот разрыв между проектной моделью и эксплуатационной реальностью со временем становится одним из главных источников архитектурных рисков.
Отсутствие владельца технологического риска
Одна из ключевых недооценок при внедрении комплексной защиты – отсутствие единого владельца технологического риска. АСУ ТП формально относят к ИТ, безопасность замыкают на ИБ, а фактическая ответственность за непрерывность и устойчивость процесса остается размытой между подразделениями. В результате технологический контур оказывается без управляемого центра принятия решений.
Возникает системный конфликт приоритетов. ИТ и ИБ ориентируются на конфиденциальность и целостность, технологи – на доступность и недопущение остановов. Решения принимаются с разных позиций, без единой логики риска, поэтому любые изменения в архитектуре защиты либо блокируются, либо внедряются в компромиссном виде, который по факту не устраивает ни одну из сторон.
Отсутствие владельца риска быстро переходит из управленческой проблемы в техническую. Средства защиты внедряются без согласования с технологами и мешают работе промышленных протоколов. Производственные подразделения, в свою очередь, обходят ИТ и ИБ, самостоятельно подключают оборудование и организуют доступы. Возникают технические блокировки, неучтенные изменения и конфликтующие решения внутри одной системы.
Инженерный подход к распределению ответственности
Большинство перечисленных проблем, возникающих при внедрении комплексной защиты, можно избежать, если изначально использовать инженерный подход к управлению безопасностью АСУ ТП. Он предполагает не формальное распределение ролей по подразделениям, а выстраивание ответственности в соответствии с реальной архитектурой и влиянием решений на технологический процесс.
Ключевая ошибка многих предприятий – попытка закрепить всю ответственность за безопасность за ИБ или ИТ, игнорируя технологическую специфику. В промышленной среде такая модель не работает, потому что меры безопасности напрямую влияют на непрерывность и устойчивость производства.
Инженерная логика начинается с определения владельца технологического риска. Эту роль должен выполнять производственный блок, чаще всего главный инженер. Именно он отвечает за допустимые последствия для оборудования, продукции и технологического цикла и принимает решения, исходя из этих критериев.
ИТ в этой модели обеспечивает инфраструктурную основу: сети, вычислительные ресурсы, рабочие станции и их стабильную эксплуатацию. ИБ отвечает за методологию, архитектуру защиты и управление рисками, но не изолированно, а в связке с АСУ ТП. Ее задача – проектировать защиту так, чтобы она закрывала угрозы инженерно и не нарушала технологический процесс.
Рабочая модель строится по принципу тандема. Главный инженер задает технологические ограничения и уровень приемлемого риска. ИБ формирует архитектуру защиты и сценарии реагирования с учетом этих ограничений. ИТ реализует и сопровождает решения на уровне инфраструктуры. Такой подход позволяет избежать технических блокировок, конфликтов решений и несанкционированных обходов защиты.
В результате безопасность перестает быть внешней надстройкой и становится частью системы управления производством. Именно это отличает формальную комплексную защиту от реально работающей.
Что определить до начала внедрения?
Большая часть проблем комплексной защиты закладывается еще до начала внедрения — на этапе подготовки. Инженерный подход здесь начинается не с выбора средств, а с правильных вопросов, на которые ИТ и ИБ должны получить ответы заранее.
Первый и базовый вопрос – полнота картины. Учтены ли все активы, проведена ли реальная инвентаризация, понятны ли зоны ответственности и владельцы этих активов. Пока этого понимания нет, любое внедрение опирается на предположения. На этом же этапе важно определить нормативный контекст: какие требования действительно применимы к конкретному производству, какие отраслевые и регуляторные нормы необходимо учитывать и где именно они пересекаются с архитектурой АСУ ТП.
Следующий уровень – практическая применимость защиты. Подходят ли выбранные решения для конкретных технологических узлов, как они будут работать в существующей архитектуре, как будут контролироваться изменения и вестись учет активов. Здесь же должны быть заранее определены процессы реагирования: кто отвечает за инциденты, как формируется группа реагирования, как она взаимодействует с технологами и как эти процессы синхронизируются с графиками модернизации оборудования и технологических остановов.
Чтобы все это не осталось на уровне договоренностей, необходим минимальный архитектурный пакет данных. В его основе – объединенная карта активов и информационных потоков, включающая не только физическое размещение, но и логическую структуру: какие системы взаимодействуют между собой, какие данные передаются, какие операционные системы, программное обеспечение и версии прошивок используются, и кто несет ответственность за каждый элемент. Дополнительно должен быть определен перечень критичных технологических процессов, нарушение которых недопустимо, и построена модель угроз, отражающая именно реальное производство, а не абстрактный набор нарушителей.
Именно на этом фундаменте становятся видны ключевые инженерные факторы успешной защиты. Первый – корректно заложенная архитектура: сегментация, изоляция, выделение защищенных контуров и отказ от избыточных подключений. Второй – эксплуатационные процессы: контроль изменений, постоянный мониторинг и своевременное реагирование. Третий – управление рисками и четкое распределение ответственности, при котором каждый участник понимает не только свою роль, но и последствия принимаемых решений.
Если эти элементы не определены заранее, комплексная защита превращается в набор разрозненных решений. Если же они выстроены до начала внедрения, защита становится управляемой системой, а не формальным проектом по внедрению средств.
Заключение
Чтобы проекты по безопасности были жизнеспособными в реальной инфраструктуре, ИТ-директорам важно требовать не формального внедрения средств, а инженерной обоснованности решений.
В первую очередь – подтвержденную совместимость. Проект должен показывать, что средства защиты реально работают с конкретным технологическим оборудованием, используемыми промышленными протоколами и версиями ОС, а не просто заявлены в документации.
Второй ключевой элемент – понятная модель эксплуатации. Необходимо заранее определить, как система будет обслуживаться, обновляться и мониториться с учетом производственного цикла и технологических остановов, без влияния на управление процессом.
Третье – связка с модернизацией. Защита должна быть встроена в дорожную карту развития АСУ ТП: когда и в какие окна выполняются обновления, какие изменения планируются и как они синхронизируются с обновлением оборудования.
Отдельное требование – единая модель знаний и ответственности. ИБ, ИТ и технологи должны работать в связке, использовать общий контур знаний и обеспечивать передачу экспертизы, чтобы устойчивость защиты не зависела от конкретных людей.
И, наконец, критерии успеха. Эффективность проекта должна оцениваться не фактом установки средств защиты, а метриками устойчивости: контролем изменений, выявляемостью инцидентов и снижением архитектурных слепых зон. Именно это показывает, что комплексная защита работает в реальной среде, а не только на бумаге.
