«Сертификация ФСТЭК подтверждает соответствие устройства набору проверяемых параметров, но не гарантирует безопасность системы в целом. Настоящие риски рождаются на стыке формальных процедур и живой эксплуатации, где удобство побеждает регламент. История с сертифицированным шлюзом, взломанным через пароль подрядчика, — яркое тому доказательство.»
Контекст: разделённые сети и ложное чувство безопасности
Архитектура сетей на промышленном объекте соответствовала классической модели: сегмент АСУ ТП был физически или логически изолирован от корпоративной среды. Связь между уровнями обеспечивал межсетевой экран, имеющий сертификат ФСТЭК. Формально периметр был защищён.
Политика доступа к шлюзу выглядела строгой. Права были только у двух групп: внутренних технологов и инженеров компании-подрядчика, обслуживающей критическое оборудование. В документах были прописаны требования к сложным паролям, многофакторной аутентификации и ведению журналов.
Однако в рабочем процессе возникла типичная проблема. Для удобства координации и устранения задержек была создана общая учётная запись для всех сотрудников подрядчика. Пароль, установленный при вводе системы в эксплуатацию, не менялся несколько лет. Он хранился в незашифрованном текстовом файле на внутреннем файловом сервере подрядчика и передавался новым сотрудникам устно. Служба ИБ знала об этой учётке, но управление её рисками было переложено на подрядчика по договору. Эта процедурная брешь обошла все технические барьеры.
Эксплуатация: атака через разрешённый канал
Инцидент начался не на атакуемом предприятии, а в инфраструктуре подрядчика. Через фишинг или утечку были скомпрометированы корпоративные почтовые ящики инженеров. Получив доступ во внутреннюю сеть вендора, злоумышленники обнаружили папку с технической документацией, где в открытом виде лежал файл с учётными данными для доступа к системам всех клиентов.
Используя эти реквизиты, атакующие установили VPN-подключение к промышленной сети через легитимный, сертифицированный шлюз. Сессия была успешно авторизована — использовались валидные логин и пароль. Подключение произошло вне регламентного графика работ, что создало событие в SIEM, но оно было классифицировано как ложное срабатывание. Мониторинг предположил внеплановые работы. Главный парадокс: технические средства защиты не умеют отличать легального пользователя со скомпрометированными данными от злоумышленника.
Шлюз, призванный быть непреодолимым барьером, стал безопасным туннелем для угрозы из-за доверия к устаревшим и публично доступным реквизитам.
[ИЗОБРАЖЕНИЕ: Схема цепочки компрометации: компрометация почты подрядчика → доступ к файлу с паролями в его сети → легитимное VPN-подключение к АСУ ТП через сертифицированный шлюз]
Движение по сети АСУ ТП и реализация физического воздействия
Оказавшись в сегменте АСУ ТП, атакующие не использовали сложные эксплойты. Они применили встроенные средства управления, присутствующие на большинстве инженерных рабочих станций: PowerShell и WMI. С их помощью была проведена разведка и выявлены целевые промышленные контроллеры, управлявшие насосной станцией.
Целью был физический ущерб. Считав рабочие программы с ПЛК и изучив логику, злоумышленники выбрали тонкий путь — изменили критическую технологическую переменную (уставку давления) напрямую в оперативной памяти контроллера во время его работы.
Операторский интерфейс продолжал отображать штатные значения. Через несколько часов работы с неверным параметром в трубопроводе возникла кавитация, приведшая к гидроудару и механическому разрушению насосов. Атакующие попытались очистить журналы на шлюзе, но не смогли стереть следы изменений в энергонезависимой памяти ПЛК — это позже стало ключевым доказательством.
Расследование: от производственной аварии к киберинциденту
Сначала инцидент классифицировали как типичную производственную аварию из-за износа оборудования. Версию кибератаки стали рассматривать только после детального анализа дампов памяти с повреждённых ПЛК, где обнаружились записи о несанкционированном изменении уставки. Регрессионный анализ сетевых журналов выявил аномальное VPN-подключение, совпавшее по времени с изменением параметра.
Расследование выявило системные проблемы, которые формальное соответствие требованиям не закрывало:
| Проблемная область | Суть уязвимости |
|---|---|
| Жизненный цикл учётных записей сторонних лиц | Политика смены паролей существовала на бумаге, её исполнение не контролировалось, ответственность была переложена на подрядчика без механизмов верификации. |
| Управление рисками третьих сторон | Аудит подрядчика проверял формальное соблюдение 152-ФЗ и наличие документов, но не реальные практики хранения критичных для доступа данных. |
| Сегментация внутри АСУ ТП | Попадание в сеть через шлюз давало равный доступ ко всем активам, без внутренних барьеров (принцип «плоский периметр»). |
| Допуск стандартных средств | PowerShell и WMI, оставленные для удобства администрирования, стали полноценным инструментарием для перемещения и управления, так как их активность не считалась аномальной. |
[ИЗОБРАЖЕНИЕ: Сравнительная схема архитектур: «До инцидента» (единый периметр, плоская сеть АСУ ТП) и «После» (микросегментация, JIT-доступ, зонирование)]
Принятые меры и системные выводы
По итогам инцидента были внедрены изменения, направленные на устранение процедурных и архитектурных уязвимостей, а не только технических.
| Область | Принятые меры | Суть изменений |
|---|---|---|
| Доступ подрядчиков | Внедрение JIT-доступа | Учётные записи создаются автоматически на строго ограниченный срок для конкретной задачи. Пароли не передаются людям, а выдаются через защищённый портал, после чего учётка блокируется. Устная передача исключена. |
| Мониторинг сессий | Привязка доступа к бизнес-процессу | Подключения валидируются не только по логину/паролю, но и по наличию активного договора и утверждённой заявки в ITSM. Любое отклонение ведёт к немедленному разрыву сессии. |
| Архитектура АСУ ТП | Микросегментация на функциональные зоны | Сеть разбита на изолированные сегменты по принципу «одна установка — один сегмент». Доступ подрядчика маршрутизируется только в предопределённую зону. |
| Инструментарий администрирования | Запрет стандартных средств, белый список ПО | На критических узлах с помощью групповых политик запрещены PowerShell, WMI и стандартный RDP. Внедрены специализированные решения с сессионным шифрованием и протоколированием каждого действия. |
| Защита ПЛК | Контроль целостности и мониторинг изменений | Внедрены средства, отслеживающие целостность программ на контроллерах и журналирующие все изменения технологических параметров. Критические уставки защищены от несанкционированной записи на уровне контроллера. |
Этот случай показывает эволюцию угроз. Основной риск смещается от прямого преодоления барьеров к эксплуатации легальных, но плохо контролируемых каналов, которые часто вынесены за периметр — в процессы и инфраструктуру подрядчиков.
Сертификат ФСТЭК — необходимый фундамент, но не страховой полис. Без жёсткого, а в идеале автоматизированного, контроля за жизненным циклом учётных данных и действиями каждого субъекта в контуре, включая сотрудников сторонних организаций, вся архитектура остаётся уязвимой. Современная защита промышленных систем требует расширения ИБ-повестки на всю цепочку поставок и аудита реальных практик, а не только документооборота третьих сторон. Угроза может прийти по самому доверенному каналу.