АСУ ТП

UDV Group: что вы недооцениваете при внедрении комплексной защиты АСУ ТП

от

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

Невидимые активы за периметром

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

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

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

Инженерные ограничения АСУ ТП

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

Критически важным требованием является также отказоустойчивость: средства защиты не должны создавать единую точку отказа, способную остановить технологический цикл. Ситуацию усугубляют промышленные протоколы, изначально не рассчитанные на современные механизмы безопасности и плохо поддающиеся анализу стандартными ИТ-инструментами.

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

Точки риска в архитектуре

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

Карта активов и потоков

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

Сложности на стадии эксплуатации

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

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

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

Контроль изменений и работа с подрядчиками

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

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

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

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

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

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

Инженерный подход к распределению ответственности

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

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

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

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

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

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

Что определить до начала внедрения?

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

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

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

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

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

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

Заключение

Чтобы проекты по безопасности были жизнеспособными в реальной инфраструктуре, ИТ-директорам важно требовать не формального внедрения средств, а инженерной обоснованности решений.

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

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

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

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

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

UDV Group: практические рекомендации по внедрению эффективной системы кибербезопасности на промышленном предприятии

от

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

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

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

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

Архитектура внедрения: итерации, риски и распределение ролей

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

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

Карта рисков и сценарное моделирование. На практике компании переходят от формальных перечней угроз к сценарному анализу. «Карта рисков 2.0» моделирует последствия изменений кода ПЛК, потери связи или сбоев инженерных станций. Методология базируется на принципах ФСТЭК: определение недопустимых событий и оценка их влияния на бизнес-процессы. Для объектов КИИ это обязательный элемент, для остальных — инструмент обоснования приоритетов информационной защиты и бюджета.

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

Техническая настройка: от видимости к управляемости

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

1.Инвентаризация

Инвентаризация активов уже давно не ведётся вручную. Сейчас для этого применяются ITSM-системы и смежные решения: при вводе оборудования в эксплуатацию данные заносятся в систему, затем дополняются сведениями из источников по информационной безопасности. Эти источники могут быть взаимосвязаны и использоваться совместно.

Со стороны ИБ для инвентаризации применяются собственные инструменты — от утилит уровня Nmap до систем, анализирующих сетевой трафик. ИТ-инструменты дают базовую картину, но не позволяют увидеть все «темные зоны» инфраструктуры, тогда как методы ИБ помогают выявлять неучтенные устройства и сегменты.

Каждый подход имеет ограничения. Анализ сетевого трафика требует настройки передачи данных через SPAN или аналогичные механизмы, что занимает время и ресурсы. Активное сканирование, наоборот, сталкивается с техническими ограничениями — необходимо открывать сетевые порты, чтобы хосты могли отвечать на запросы. В промышленных сетях это не всегда безопасно и требует осторожности.

Поэтому на практике используется комбинация подходов. Современные discovery-инструменты позволяют запускать инвентаризацию регулярно, фиксируя изменения инфраструктуры в динамике. При использовании анализа сетевого трафика данные обновляются почти в реальном времени, а актуальность результатов напрямую зависит от выбранного метода и частоты получения данных.

2. Интеграция

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

Интеграция критически важна вне зависимости от конкретного продукта или вендора. Здесь определяющими становятся два фактора. Первый — возможности вендора. Вендор должен изначально предусматривать механизмы для обмена данными. Это могут быть события информационной безопасности в формате Syslog или CEF, передача инцидентов, активов или другой информации через открытые интерфейсы. На практике далеко не все решения поддерживают такие функции, особенно на российском рынке. Даже у ведущих поставщиков интеграционные возможности реализованы не всегда полно.

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

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

Для обмена чаще всего применяются REST API и gRPC с использованием, использующие протоколы HTTP/HTTPS. Через них передаются события, инциденты, данные об активах и другие сущности, необходимые для объединения ИТ- и ИБ-контуров. В некоторых случаях API используется для обогащения информации: данные из одного источника дополняют контекст в другом, формируя более полную и достоверную картину активов и инцидентов.

3. Приоритизация

Для большинства предприятий первым шагом в выстраивании ИБ-системы остаются сетевые барьеры — firewall и сегментация сети. Это оправдано: современные NGFW уже включают встроенные средства IPS, IDS и механизмы анализа трафика с элементами машинного обучения. Такие меры дают наибольший эффект при минимальных трудозатратах — порядка 70–80% результата при примерно 20% стоимости и усилий.

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

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

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

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

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

Люди и ИБ-культура: главная уязвимость

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

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

Такие методологии, как, например, NIST Cybersecurity Framework прямо указывают, что работа с персоналом должна быть встроена в систему безопасности на всех уровнях — от корпоративных политик до производственных процедур.

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

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

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

Метрики и поддержка: что реально работает

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

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

При этом технические метрики тоже требуют корректного понимания. Например, показатель времени реакции SOC на аномалию в OT-сегменте не всегда объективен. Его значение зависит от того, что считать аномалией и насколько система подвержена ложноположительным и ложноотрицательным срабатываниям. Поэтому ориентироваться стоит не на общее количество реакций, а на работу с реальными инцидентами. Аналогично и показатель инцидентов, выявленных до их влияния на производство, должен учитывать только подтвержденные события, реально затрагивающие технологическую среду, а не программные уведомления или записи в CMDB.

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

Параллельно с этим растет необходимость в постоянной актуализации защиты. Количество угроз и уязвимостей увеличивается ежедневно: новые эксплойты часто появляются в даркнете раньше, чем вендоры узнают о проблеме. Особенно сложно, когда уязвимости обнаруживают злоумышленники, а не исследователи. Поэтому важно выстраивать корректный патч-менеджмент и применять наложенные средства информационной защиты, способные выявлять и компенсировать уязвимости нулевого дня. К ним относятся IPS, решения с элементами машинного анализа, а также автоматизированные системы реагирования — SOAR в связке с firewall, EDR или XDR. Эти инструменты позволяют блокировать угрозы как на уровне сети, так и на конечных точках.

Надежная защита невозможна без компетентных специалистов. Даже при наличии автоматизации сотрудники должны понимать текущие тенденции, знать, какие угрозы появляются, и уметь применять защитные инструменты на практике. Отдельное внимание требует новая группа рисков, связанная с использованием искусственного интеллекта. Практически каждая крупная организация уже внедряет ИИ, что создает новые векторы атак. Эти угрозы необходимо учитывать и отслеживать наряду с общим трендом на непрерывное обновление и адаптацию систем безопасности.

Управление рисками: реализм вместо иллюзий

Важно помнить: абсолютной защиты не существует. Реалистичный подход заключается не в стремлении закрыть всё, а в правильной приоритизации — определении недопустимых событий и концентрации ресурсов на действительно критичных областях. Остальные риски можно принимать осознанно или смягчать простыми, менее затратными методами, сохраняя баланс между уровнем защиты и стоимостью ее обеспечения.

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

Эффективное управление рисками возможно только при совместной работе ИТ-директора, директора по ИБ и руководства компании. Приоритизация строится на анализе критичности бизнес-процессов: определяется, какие из них влияют на непрерывность производства, рассчитывается ущерб от их остановки, затем выявляются системы и сотрудники, обеспечивающие их работу. На этой основе формируется инженерно обоснованная модель защиты, ориентированная не на формальное соответствие, а на снижение реальных потерь.

Заключение

В 2025 году промышленная безопасность — это не набор «коробочных» решений и не формальное соответствие требованиям. Это системная работа на снижение MTTR, интеграцию OT-сегмента в SOC и минимизацию реальных бизнес-рисков.

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

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

Автор: Федор Маслов, менеджер продукта UDV DATAPK Industrial Kit

Источник: https://neftegaz.ru/analisis/digitalization/911582-prakticheskie-rekomendatsii-vnedrenie-effektivnoy-sistemy-kiberbezopasnosti-na-promyshlennom-predpri/

Илона Киреёнок, UDV Group: Компании хотят не просто укрепить защиту, но и сократить время восстановления после атак

от

За последний год российский рынок информационной безопасности заметно изменился: выросла сложность атак, сместился фокус злоумышленников, а требования бизнеса к ИБ стали более прагматичными. Компании все чаще говорят не только о защите, но и о цифровой устойчивости, эффективности ИБ-команд и предсказуемости решений в эксплуатации. На этом фоне вендорам приходится одновременно развивать продукты, экосистему партнеров и отраслевую экспертизу, адаптируясь к запросам разных сегментов — от промышленности до корпоративных сетей. О том, какие тренды стали определяющими в 2025 г., как они повлияли на продуктовую стратегию и развитие UDV Group, а также о ключевых ориентирах компании на 2026 г. CNews поговорил с Илоной Киреёнок, коммерческим директором UDV Group.

CNews: Если подводить итоги 2025 года, какие изменения вы считаете наиболее значимыми для российского рынка ИТ и информационной безопасности? Что в первую очередь изменилось в запросах заказчиков?

Илона Киреёнок: Если говорить о ключевых трендах, то прежде всего стоит отметить качественное изменение ландшафта угроз. В 2025 году мы видели не столько рост числа атак, сколько рост их качества, сложности и длительности. Если раньше заметная их часть была хаотична и безрезультатна, то сегодня атаки становятся более адресными и чаще достигают цели. Теперь за ними стоят профессиональные и мотивированные команды.

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

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

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

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

CNews: Вы говорите о росте зрелости атак и смещении фокуса с периметра на обнаружение инцидентов внутри сети. Повлияли ли эти изменения на продуктовую стратегию UDV Group?

Илона Киреёнок: Да, эти изменения стали для нас определяющими. Модель, в которой безопасность сводится к защите периметра, больше не работает. Сегодня заказчики исходят из того, что злоумышленник рано или поздно окажется внутри сети, и ключевым становится вопрос скорости и точности обнаружения происходящего.

Именно под этот запрос мы и создали продукт UDV NTA. Рост интереса к решениям класса NTA напрямую связан с повышением качества атак: когда периметр уже пройден, сетевой анализ трафика и поведения остается одним из немногих способов увидеть и понять, что именно происходит в инфраструктуре, как развивается атака и какие узлы затронуты. На практике это особенно важно для SOC, которые работают с большим потоком событий от разных источников. UDV NTA позволяет связать эти сигналы с реальной сетевой активностью, получить необходимый контекст и заметно сократить время расследования инцидентов, снижая нагрузку на ИБ-команды.

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

В результате и UDV NTA, и UDV MultiProtect отражают ключевые тренды рынка: рост профессионализма атакующих, смещение атак в СМБ сегмент и требование произвести расследование быстро и избежать потерь для бизнеса.

CNews: Если говорить о промышленном сегменте в целом, как за последнее время изменились запросы со стороны предприятий и какие потребности сегодня выходят для них на первый план в части защиты АСУ ТП?

Илона Киреёнок: В промышленности мы видим желание ответственных за распределенные и геораспределенные инфраструктуры ИБ АСУ ТП руководителей и специалистов быть в курсе событий. Для этого в UDV DATAPK версии 3.0 мы добавили новый компонент SuperVision. который дал нашим заказчикам удобный инструмент для видимости и контроля за ИБ АСУ ТП даже в крупных корпорациях, возможность централизованно контролировать состояние систем и оперативно реагировать на отклонения в любой точке распределенной инфраструктуры.

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

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

CNews: Появление сразу нескольких новых продуктов в большинстве случаев требует от вендора расширения экосистемы. Пришлось ли вам усиливать партнерскую сеть или дистрибуцию?

Илона Киреёнок: 2025 год действительно стал для нас годом заметного роста интереса со стороны партнерского сообщества. Мы вдвое расширили партнерскую сеть, при этом сделали акцент не на количестве, а на качестве — появились новые компетентные партнеры, которые прошли обучение, развернули демостенды и готовы самостоятельно работать с нашими решениями. Параллельно мы заключили несколько соглашений о стратегическом партнерстве.

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

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

CNews: Вы говорили о сотрудничестве с производителями АСУ ТП и систем управления производством. Насколько вообще имеет значение совместимость решений и предсказуемость их работы в реальных проектах?

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

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

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

CNews: В условиях дефицита ИТ и ИБ-специалистов многие проекты сегодня сталкиваются с рисками уже на этапе внедрения и сопровождения. Как в этой ситуации меняется роль партнерского канала и на что вы как вендор делаете ставку?

Илона Киреёнок: Сегодня партнерский канал фактически определяет, насколько успешно решение будет внедрено и продолжит эксплуатироваться у заказчика. Ни один вендор, даже самый крупный, не может закрыть все регионы и объекты собственной командой — это просто невозможно.

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

CNews: В этом году вы вышли в новый для себя сегмент — ОПК. С какими особенностями этого рынка вы столкнулись и как это повлияло на подход к продуктам и проектам?

Илона Киреёнок: Выход в сегмент ОПК для нас во многом стал логичным продолжением работы с технологическими партнерами. Точкой входа стал проект, связанный с задачами телеметрии у одного из заказчиков. Наши решения напрямую не занимаются сбором телеметрии, но обеспечивают безопасность съема и передачи данных из сегмента АСУ ТП — и именно это оказалось критически важным в рамках проекта. Этот кейс стал отправной точкой для серии проектов, которые начались в 2025 году и переходят в 2026 год.

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

Отдельно стоит отметить выход в ранее нехарактерные для нас отрасли — телеком и финансы. Здесь важную роль сыграл UDV NTA, который оказался востребован в распределенных корпоративных сетях с высокими требованиями к видимости сети заказчика.

CNews: По мере расширения присутствия в новых сегментах и роста клиентской базы все более заметной становится и роль бренда. Как, на ваш взгляд, формируется доверие к ИБ-вендору сегодня и какие шаги UDV Group предпринимала в 2025 году для усиления своей репутации на рынке?

Илона Киреёнок: Сила бренда и доверие рынка действительно тесно связаны, и в основе здесь всегда лежит качество продуктов, успешно проявивших себя в реальных кейсах и инфраструктурах. Без устойчивых, зрелых решений о репутации говорить сложно.

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

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

Открытие представительства в Москва-Сити стало еще одним шагом к более открытому и прямому диалогу с заказчиками и партнерами. Для нас это прежде всего про клиентоориентированность — фактор, который напрямую влияет на восприятие бренда и уровень доверия к компании.

CNews: Если подытожить разговор, какое достижение 2025 года вы считаете для UDV Group наиболее стратегическим? И на каких ориентирах компания будет фокусироваться в следующем году?

Илона Киреёнок: Для нас 2025 год стал по-настоящему переломным. Это был год более глубокого погружения в потребности заказчиков, осознания того, что мы делаем правильно, а что нет. Мы пересмотрели наш продуктовый портфель, вышли в новые сегменты, заключили новые партнерства. Диверсифицировали выручку — как по отраслям и типам заказчиков, так и по партнерскому каналу, это дает нам ощущение устойчивости.

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

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

Источник: https://www.cnews.ru/articles/2026-01-19_ilona_kireenokudv_group_kompanii_hotyat?erid=2W5zFHqWGQg

UDV Group: Контроль версий проектов ПЛК в АСУ ТП

от

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

Автор: Владислав Ганжа, руководитель производственного направления лаборатории кибербезопасности UDV Group

Контроль версий в промышленности – это не просто инструмент удобства инженеров, а фундаментальный элемент кибербезопасности. Однако есть сложности в использовании на предприятиях традиционных систем контроля версий, ведь среды разработки проектов ПЛК в АСУ ТП имеют свою специфику. Рассмотрим этот вопрос подробнее.

Несовместимость с ИТ-практиками

Такие известные решения для контроля версий, как Git, к работе с АСУ ТП практически не применимы. Причина простая: каждая среда разработки предполагает свои подходы к хранению и обработке кода. Проект может храниться, например, в виде набора файлов, либо одного большого бинарного файла, который умеет читать только проприетарная среда разработки. В промышленности почти все проекты ПЛК – это бинарные или полубинарные форматы, завязанные на проприетарные среды, такие как TIA Portal от Siemens, Unity Pro от Schneider Electric, CODESYS и др. Тогда как Git изначально был ориентирован на работу с исходными кодами ядра Linux, то есть с множеством небольших текстовых файлов.

Форматами, завязанными на проприетарные среды, продолжают пользоваться многие российские предприятия, где старые производственные линии остаются на зарубежных решениях. Однако надо отметить, что в свете тренда на импортозамещение успешно развиваются и российские среды разработки. Неплохие результаты, например, у компаний «Прософт-Системы», ТРЭИ и некоторых других. Новые производственные линии сейчас изначально строятся на российских продуктах.

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

Работа в условиях реальности цеха

В отличие от классической ИТ-разработки, изменения в логике ПЛК в АСУ ТП могут вноситься прямо на производстве и в срочном порядке – в соответствии с текущими задачами, часто без полноценного документирования и тестирования. Горячие правки особенно характерны для металлургии и пищевой промышленности.

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

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

Отсутствие централизованного подхода

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

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

Технические особенности решений для ПЛК в АСУ ТП

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

  1. Хранение золотых эталонных конфигураций для быстрого восстановления. При модернизации и импортозамещении АСУ ТП предприятия часто привлекают интегратора АСУ ТП в качестве подрядчика. Эксперты грамотно выполняют сложный процесс пусконаладки, который, как правило, происходит постепенно, уровень за уровнем, без полной остановки производства. Золотые копии работ подрядчика хранятся, чтобы в дальнейшем служба эксплуатация могла разобраться в ходе внесения изменений. Золотые копии также помогают максимально быстро восстановить настройки, если контроллер выходит из строя или надо запустить ранее отлаженный проект на новом контроллере.
  2. Интеграция с Active Directory/LDAP для управления доступом. Персонализированные учетные записи в сегментах АСУ ТП уже появляются, но этот процесс идет медленно. До сих пор инженеры часто работают под одной учетной записью. Интеграция со службой каталогов для управления парольной политикой и разграничения доступа позволяет организовать централизованное управление учетными записями и полномочиями.
  3. Поддержка работы в условиях ограниченной сети. Для сокращения возможных векторов атак объекты КИИ зачастую работают on-premise, без выхода в Интернет. Это касается и АСУ ТП, и хотя вопрос конфиденциальности стоит не так остро, но вопросы целостности и доступности критически важны.

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

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

Практическая ценность управления версиями

Управление версиями ПЛК дает предприятиям ряд преимуществ как в части соблюдения требований регуляторов, так и внутренней дисциплины.

  • В IEC 62443 прямо указана необходимость процедур Change Management, а ФСТЭК России в новых методических рекомендациях акцентирует внимание именно на контроле изменений проектов ПЛК. Требования регуляторов – весомая причина, по которой все больше предприятий переходят от бумажного соответствия к практической реализации контроля версий.
  • При наличии системы версий можно за минуты показать аудитору историю изменений и регламенты – вместо недельной ручной подготовки. Любая другая отчетность строится легче и для руководителя, и для инженера, если можно посмотреть, какие практики кода применялись.
  • MTTR (Mean Time to Recovery) – ключевой показатель устойчивости киберфизических систем. В любой момент на предприятии что-то может сломаться, пойти не по плану, и это не всегда зависит от человеческого фактора. Но система контроля версий дает уверенность, что инженеры в любой момент смогут сделать «как два дня назад, когда все работало хорошо».
  • Если инженеры знают, что каждый их шаг фиксируется, они действуют более осторожно и собранно, снижается количество ночных патчей на объекте без уведомления. Порой инженеру, который хорошо знает свою линию, не хочется согласовывать работы. И есть соблазн быстро внести изменения так, чтобы никого не беспокоить. При наличии контроля такое своеволие постепенно сходит на нет.

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

Можно выделить типичные негативные последствия, которые повторяются на предприятиях, где не ведется контроль версий ПЛК.

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

Вывод

Вывод простой: контроль версий ПЛК – обязательный элемент для предприятий, не желающих рисковать стабильностью работы АСУ ТП

Практика показывает, что довольно большое число инцидентов в АСУ ТП связано с изменениями в коде ПЛК без фиксации и контроля. Там, где проекты до сих пор хранятся на флешках или на рабочих столах инженеров, риск потери данных или подмены логики – вопрос времени.

Система контроля версий позволяет быстро вернуть проверенную конфигурацию после сбоя, показать полную историю изменений за минуты и зафиксировать, кто именно внес изменения в код контроллера. Это не дополнительная опция, а инструмент, который снижает среднее время реагирования закрывает все более строгие требования ФСТЭК России и способствует защите производства от простоев и аварий.

Источник: https://www.itsec.ru/articles/kontrol-versij-plk-v-asu-tp

UDV Group: построение комплексной защиты АСУ ТП — ошибки, которые совершают предприятия

от

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

Ошибка № 1. Выбор технологий без привязки к контексту производства

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

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

Ошибка № 2. Ожидание быстрых результатов

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

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

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

Ошибка № 3. Считать АСУ ТП «дополнением» к ИТ и не иметь владельца технологического риска

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

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

Еще одно следствие отсутствия владельца — размывание технологических рисков. ИТ сфокусированы на своих КЦД, но риски остановки производства, повреждения оборудования, угрозы жизни и даже экологические последствия могут вообще не попадать в зону внимания. Ответственность расползается между инженерными службами, производством и ИТ, но фактически не принадлежит никому.

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

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

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

Ошибка № 4. Разорванное реагирование между подразделениями

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

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

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

Ошибка № 5. Игнорирование жизненного цикла оборудования

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

Особенно остро это проявляется при переходе между поколениями ОС. Например, когда технологические узлы работают на Windows XP, а предприятие переходит на Windows 7, установить защиту «по учебнику» зачастую невозможно. Любое вмешательство может нарушить технологический процесс, и приходится выбирать между риском остановки и временной изоляцией.

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

Ошибка № 6. Уверенность в закрытом контуре

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

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

Ошибка № 7. Ориентация на формальное соответствие требованиям вместо управления реальными рисками

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

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

Как понять, что защита строится под галочку? Самый простой способ — выйти в цеха. Поговорить с инженерами и операторами: какие меры безопасности применяются, какие правила они знают, как работают с паролями, знакомы ли с инструкциями. То же касается реагирования на инциденты: проводятся ли реальные тренировки или все ограничивается отчетом о неком «плане отработано».

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

Заключение

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

Источник: https://www.itweek.ru/industrial/article/detail.php?ID=233994

Пользовательское соглашение

Опубликовать