Жизнь без Интернета — как сохранить киберустойчивость?

Ещё недавно постоянное подключение к интернету — мобильному или фиксированному — казалось бизнесу аксиомой. И кибербезопасность рассматривала наличие Интернета как нечто незыблемое. Обновление индикаторов компрометации и прошивок ПО, мониторинг удаленных площадок, MDR-сервисы, работа VPN и т.п.; список можно продолжать долго. Но сегодня наличие Интернет уже не является гарантией. В ряде российских регионов (и их все больше) для борьбы с дронами и в других экстренных ситуациях мобильный Интернет стали отключать полностью или частично. Для компаний, которые привыкли полагаться на постоянный онлайн (например, доставка, каршеринг, удалённый мониторинг производства, цифровые сервисы банков и т.п.), это становится проблемой не только для операционной деятельности, но и для кибербезопасности.

Почему отключения интернета — это не только про доступность

В ИБ принято говорить про триаду КЦД (Конфиденциальность, Целостность, Доступность). Массовое отключение мобильного интернета напрямую бьёт в первую очередь по третьему компоненту – доступности. Но на этом проблемы не заканчиваются:

1. Рост числа обходных каналов

   При отключении штатного канала сотрудники и подрядчики начинают искать обходные пути – личные смартфоны, VPN из «серых» источников, открытые Wi-Fi. Это увеличивает площадь атаки и делает мониторинг непростой задачей.

2. Отказ от централизованного мониторинга

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

3. Уязвимость резервных каналов

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

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

Важно! Я не настоящий «сварщик»; поэтому ниже просто мои несвязанные мысли о том, что стоило бы учесть/использовать в новой архитектуре ИБ.

Общие принципы устойчивой архитектуры связи

1. Резервные каналы

   • Спутниковая связь (Starlink, OneWeb, Газпром Космические системы) – устойчива к локальному глушению, подходит для критически важных процессов, удалённых филиалов и транспорта, требующих коммуникаций и непрерывного мониторинга.

   • Радиосети (рации, PMR, TETRA) – для оперативной связи внутри локальных объектов.

   • LoRaWAN, NB-IoT – энергоэффективные сети для передачи телеметрии и данных с датчиков.

   • Проводной Интернет – там, где есть возможность, он должен оставаться «опорным» каналом для критичных систем.

2. Офлайн-режим и локальное кэширование

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

   • Офлайн-карты и заранее загруженные маршруты – обязательный стандарт для мобильных команд проведения расследований и реагирования на инциденты в распределенных организациях.

3. Локальные и децентрализованные сети

   • Mesh-сети (Bluetooth, Wi-Fi Direct) позволяют устройствам обмениваться данными напрямую.

   • Локальные корпоративные сети (LAN / Wi-Fi / Private LTE) обеспечивают автономную работу производства и складов.

4. Альтернативные каналы передачи данных

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

   • Голосовая связь – резервный канал для критических инструкций.

Резервные каналы с учётом российских реалий

Private LTE / 5G

Создание собственной корпоративной сотовой сети на лицензированных или выделенных частотах.

• Где применимо: производственные предприятия, нефтегаз, логистика.

• Плюсы: контроль над инфраструктурой, шифрование, интеграция с SIEM/SOC.

• Минусы: стоимость, лицензирование, необходимость частотного ресурса.

• Пример: крупные заводы в РФ уже разворачивают Private LTE для подключения датчиков и техники в зонах с нестабильной связью, но пока не всегда задействуются в ИБ-проектах.

Спутниковый интернет

В России доступны отечественные операторы (РТКОММ, AltegroSky, Газпром Космические Системы).

• Где применимо: удалённые регионы, транспорт, аварийный канал связи.

• Особенности: доступ к зарубежным системам, например, Starlink, в РФ ограничен. Также при проектировании стоит предусматривать шифрование данных поверх канала связи.

Проводные и оптические каналы

• Плюсы: максимальная стабильность, высокая скорость, возможность выделения защищённых каналов (L2/L3 VPN).

• Минусы: привязка к конкретным точкам присутствия.

Радиосети и LoRaWAN

• Для локальных операций и передачи телеметрии от датчиков.

• При правильном шифровании – безопасный способ передачи технологических данных без интернета.

Есть еще технология FabFi, о которой я писал еще в 2011-м году, но это уже совсем попахивает анахронизмом. А с другой стороны, почему бы и нет…

Кибербезопасность в условиях гибридной связи

При добавлении новых каналов важно не создать новые дыры. Поэтому стоит учитывать следующее:

1. Единая точка контроля трафика. Все резервные каналы (спутник, Private LTE, радиосети) должны проходить через защищённый шлюз с NGFW и IDS/IPS, чтобы трафик проверялся так же, как и в основном канале.

2. Шифрование по умолчанию. Даже если канал считается «частным» (Private LTE), поверх него нужен VPN, возможно, на отечественных алгоритмах и сертифицированные.

3. Edge computing и локальное хранение логов. В условиях отсутствия связи локальные узлы (промышленные контроллеры, филиальные серверы, межсетевые экраны, NDR, EDR, SIEM и т.п.) должны продолжать собирать логи, чтобы после восстановления соединения их можно было синхронизировать с SOC.

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

Как выбрать решение с учетом задач службы ИБ?

Не факт, что выбранное вами решение учитывает описанные нюансы. Но это повод поговорить с разработчиком, не так ли?..

При проектировании архитектуры связи в условиях периодических отключений Интернета важно учитывать не только операционную деятельность, но и сохранение способности выполнять ключевые задачи ИБ. Решения должны обеспечивать непрерывность:

• Мониторинга событий и телеметрии

  • Локальное накопление логов (журналы сетевых устройств, серверов, рабочих станций, приложений) с гарантией целостности (подпись, WORM-носители).

  • Автоматическая синхронизация данных с SIEM/SOC при восстановлении связи.

  • Возможность локальной корреляции базовых событий на уровне филиала или цеха (edge-SIEM) с последующей передачей основных или скоррелированных событий на старший в иерархии SIEM/XDR.

• Обновления ПО и средств защиты

  • Локальные зеркала обновлений антивирусов, EDR/EDR-агентов, сигнатур IDS/IPS, уязвимостей сканеров и т.п.

  • Возможность применения заранее загруженных обновлений по расписанию.

  • План аварийного обновления при длительном отсутствии связи (например, через физическую доставку носителей в критичные сегменты и важные точки).

• Получения индикаторов компрометации (IoC)

  • Локальное хранилище актуальных IoC (IP, домены, хэши файлов) с регулярной синхронизацией при доступе к TI-фидам.

  • Использование автономных TI-агентов, встроенных в NGFW, NTA, EDR, SIEM и т.п., способных проверять события на основе локальной базы IoC.

• Удалённого расследования инцидентов

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

  • Использование защищённых каналов (VPN, TLS ГОСТ) при передаче артефактов.

• Удалённого доступа и администрирования

  • Резервные защищённые каналы (Private LTE, спутник) с обязательной многофакторной аутентификацией и политикой Zero Trust.

  • Возможность ограниченного локального администрирования критичных систем в офлайн-режиме по заранее определённым сценариям.

• Уведомления об инцидентах и оповещения

  • Резервный канал оповещений (SMS, радиосвязь, корпоративные мессенджеры с автономным режимом).

  • Многоуровневая система уведомлений: локальное оповещение ИБ-команды + передача уведомлений в центральный SOC при восстановлении связи.

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

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