«Мы привыкли думать об информационной безопасности как о защите от известных угроз: вирусов, хакерских атак, утечек данных. Но самые опасные риски — те, которые мы не видим, потому что они встроены в саму логику наших систем, в доверие к партнёрам и в нашу уверенность в собственной компетентности. Это не внешние атаки, а внутренние изломы, которые проявляются только в момент отказа.»
Угроза №1: Слепая зона комплаенса
Большинство компаний в России строят защиту, ориентируясь на формальные требования 152-ФЗ и приказов ФСТЭК. Создаётся документированная система, внедряются средства защиты, проводятся проверки. Угроза возникает, когда эта система начинает восприниматься как самоцель, а не как инструмент управления рисками. Защита работает против чек-листа регулятора, а не против реального злоумышленника или сценария отказа.
Пример: организация сертифицировала СЗИ от НСД и считает периметр защищённым. При этом критическая бизнес-логика завязана на микросервис, который общается с внешним API партнёра по незашифрованному HTTP, потому что это «внутренний трафик между доверенными компонентами». Формально нарушения нет — трафик не покидает контур управления. Фактически, это сквозная брешь, которую не увидит ни один сканер уязвимостей, ориентированный на стандартные OWASP Top 10.
Такие слепые зоны часто возникают на стыках:
- Между юрисдикциями данных (обработка в облаке партнёра, не имеющего аттестата ФСТЭК).
- В цепочках поставок ПО (использование библиотек с устаревшими компонентами, которые не входят в реестр Минцифры).
- В процессах аварийного восстановления (когда резервные копии конфигураций хранятся в открытом виде для скорости развёртывания).
Угроза №2: Коллапс доверия в цепочке поставок
Современная ИТ-инфраструктура, это пазл из сотен компонентов: операционные системы, библиотеки, контейнеры, облачные сервисы. Мы доверяем их поставщикам. Угроза — не в том, что в одной библиотеке найдут уязвимость. Угроза в том, что доверие ко всей цепочке может быть подорвано одномоментно.
Представьте, что ключевой российский вендор систем виртуализации или баз данных, чьи продукты лежат в основе ГИС и корпоративных систем, столкнётся с непредвиденным инцидентом. Не с хакерской атакой, а с техническим долгом такой сложности, что для исправления критической ошибки потребуется месяц простоя. Или что обновление безопасности, выпущенное для соответствия требованиям регулятора, сломает обратную совместимость с другим обязательным к использованию ПО.
Это не гипотетический сценарий. Это вопрос архитектурной связанности. Когда десятки критически важных систем в разных отраслях зависят от одного технологического стека, его отказ создаёт каскадный эффект. Нельзя быстро заменить ядро инфраструктуры, особенно если оно прошло все необходимые процедуры согласования и аттестации.
Угроза №3: Процедурная уязвимость
Самая защищённая с технической точки зрения система может быть обрушена корректным, легитимным действием. Это угроза процедурной уязвимости — когда регламенты, инструкции и права доступа, написанные для штатных ситуаций, позволяют совершить действия, ведущие к катастрофе.
Классический пример — процедура аварийного восстановления. По регламенту, в случае сбоя, ответственный инженер имеет право развернуть систему из последней резервной копии. Если злоумышленник получит доступ к учётной записи этого инженера (через фишинг или инсайдера), он может легально, в рабочее время, инициировать процедуру «восстановления», подменив резервную копию на заранее подготовленную, содержащую бэкдор. Системы мониторинга не сработают — идёт штатная операция по регламенту. Защита от НСД бессильна — у пользователя есть все права.
Такие уязвимости живут в:
- Регламентах выдачи прав (например, право на сброс пароля другому пользователю «для оперативности»).
- Сценариях автоматического масштабирования в облаке, которые при определённых условиях могут исчерпать бюджет или создать незащищённые экземпляры.
- Процедурах согласования изменений, которые из-за бюрократии вынуждают администраторов работать в обход них для «срочных фиксов».
Угроза №4: Интеллектуальное устаревание защиты
Средства защиты информации, это не железные ящики. Это программные комплексы, которые тоже развиваются, обновляются и… устаревают. Угроза заключается в том, что модель угроз, заложенная в СЗИ пять лет назад, может не соответствовать современным методам атак. Система будет исправно отрапортовает об отсутствии известных ей инцидентов, пропуская принципиально новые векторы.
Например, система обнаружения вторжений, настроенная на сигнатуры сетевых атак, может быть слепа к атакам на цепочки поставок ПО, которые выглядят как легитимное обновление. Средство контроля съёмных носителей, блокирующее USB-флешки, не остановит передачу данных через порт зарядки современного смартфона, эмулирующего сетевую карту.
Защита устаревает не тогда, когда выходит из строя, а тогда, когда её логика перестаёт понимать контекст происходящего. Это создаёт иллюзию безопасности, которая опаснее её полного отсутствия.
Угроза №5: Неявная зависимость от неконтролируемых инфраструктур
Ни одна крупная организация сегодня не работает в полной изоляции. Даже если весь primary-контур развёрнут на собственном аттестованном ЦОДе, существуют десятки неявных зависимостей: DNS, сервисы точного времени (NTP), репозитории обновлений ПО, CDN для загрузки интерфейсов, сертификаты УЦ. Большинство из них воспринимаются как данность, как воздух.
Что произойдёт, если один из ключевых корневых DNS-серверов, используемых провайдером, станет недоступным или начнёт возвращать подменённые ответы для внутренних доменов? Как система контроля целостности ПО отреагирует, если репозиторий, откуда она берёт эталонные хэши, будет скомпрометирован? Эти инфраструктурные сервисы часто находятся вне зоны ответственности и даже вне поля зрения службы ИБ. Их отказ или компрометация не является нарушением 152-ФЗ, но может парализовать работу.
Что делать? От осознания к действию
Осознание этих угроз — первый шаг. Второй — интеграция их поиска в регулярные процессы.
1. Аудит на стыках и зависимостях
Проводите не только формальные проверки на соответствие приказам ФСТЭК, но и архитектурный анализ. Картируйте все внешние зависимости ваших критических систем: API, библиотеки, DNS, NTP, репозитории. Оцените, что произойдёт, если каждый из этих элементов откажет или будет скомпрометирован.
2. Внедрение принципа «недоверия по умолчанию» (Zero Trust) на уровне процессов
Речь не обязательно о дорогостоящих технологических решениях. Начните с процессов: пересмотрите регламенты под угрозой их злоупотребления. Для каждой привилегированной операции задайте вопрос: «Как эту процедуру можно использовать для нанесения ущерба, если учётная запись исполнителя будет скомпрометирована?» Внедрите разделение обязанностей и обязательное подтверждение для критических действий даже внутри доверенного контура.
3. Регулярные упражнения по кризисным сценариям
Проводите учения, моделирующие нестандартные отказы: не «отказ сервера», а «компрометация репозитория с эталонными конфигурациями» или «получение некорректных данных от доверенного внешнего API». Это вскроет процедурные уязвимости и покажет реальную готовность команды.
4. Мониторинг «воздуха»
Настройте мониторинг доступности и целостности тех самых неконтролируемых инфраструктурных сервисов, от которых вы зависите. Контролируйте не только факт ответа DNS, но и соответствие ответов ожидаемым значениям для критических внутренних доменов.
В итоге настоящая устойчивость формируется не тогда, когда вы закрыли все известные уязвимости из базы. Она начинается с понимания, что самые серьёзные угрозы часто невидимы, потому что они вплетены в саму ткань ваших операционных и технологических процессов. Их поиск и нейтрализация, это непрерывная работа по сомнению в собственной безупречности.