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

5 часов назад

© Антон Паламарчук, эксперт по кибербезопасности, основатель Expice Security

Для системы видеонаблюдения сегодня уже недостаточно лишь правильно установленных камер и работающей записи — нужно контролировать, как и с какими серверами она обменивается данными. Эксперт по кибербезопасности, основатель Expice Security Антон Паламарчук рассказал журналу RUБЕЖ, как выявить подозрительный сетевой обмен, проверить закрытое ПО и определить, когда действительно стоит ограничить работу системы. 

— Как проверить сетевые соединения иностранного ПО для видеоаналитики?

Антон Паламарчук: Я бы начинал не с расшифровки трафика, а с наблюдения за сетевым обменом в сегменте видеонаблюдения. Для этого можно настроить зеркалирование порта коммутатора через SPAN или использовать TAP — устройство, которое копирует сетевой трафик для анализа. Если в инфраструктуре есть межсетевой экран следующего поколения (NGFW), часть данных можно собирать и через него. Параллельно стоит анализировать запросы к DNS-серверу: это недорогой и часто достаточно информативный способ выяснить, к каким доменам обращаются устройства.

Даже если трафик зашифрован, можно определить IP-адрес назначения и владельца сети, доменное имя, сертификат сервера, параметры защищенного соединения, объём и направление передачи данных, периодичность и продолжительность сеансов.

Если IP-камера используется только для передачи видеопотока на сетевой видеорегистратор (NVR), с которого ведутся просмотр и запись, ей незачем подключаться к произвольным публичным серверам. Тем более опасны ситуации, когда извне устанавливаются соединения с самой камерой. Поэтому стоит заранее просканировать оборудование, проверить открытые порты и выяснить, для чего они используются. На устройствах могут оказаться административные панели, доступ по SSH или Telnet и учетные записи с паролями по умолчанию.

— Как отличить штатный сетевой обмен от подозрительного?

А. Паламарчук: Штатный обмен предсказуем. Он идёт на домены производителя, указанные в документации, связан с понятными событиями — например, запуском службы, проверкой обновлений или активацией лицензии, — имеет ожидаемый объём и инициируется тем компонентом, который отвечает за соответствующую функцию.

Если в документации нет информации о доменах и IP-адресах, стоит запросить её у производителя. Многие поставщики оборудования готовы предоставить такие сведения.

Насторожить должен исходящий трафик, объём которого не соответствует заявленному назначению программы, обращения напрямую к IP-адресам без предварительных DNS-запросов, использование нестандартных портов и туннелей, подозрительные DNS-запросы с длинными поддоменами или собственный зашифрованный DNS (DoH), работающий в обход корпоративного резолвера.

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

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

— Можно ли проверить закрытый продукт, если исходный код недоступен?

А. Паламарчук: В основном проверка будет опираться на поведенческий анализ, изучение сетевого трафика, подключений и DNS-запросов. Однако такой анализ не позволяет доказать отсутствие программной закладки.

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

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

— Как проверить, не изменилось ли поведение давно установленного ПО?

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

— Когда результаты аудита становятся основанием для ограничения эксплуатации системы?

А. Паламарчук: Я бы разделил меры по стоимости и серьёзности последствий.

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

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

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

Для значимых объектов критической информационной инфраструктуры вопрос может решаться не только по результатам аудита, но и в рамках нормативных требований, в том числе Указа Президента РФ № 166. Применимость конкретных требований нужно оценивать с учётом типа объекта и действующего регулирования.

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

Не менее важна цепочка хранения доказательств: кто, когда и каким образом получал доступ к материалам. Наконец, необходимо чётко разделять факты и интерпретации. «Наблюдалось соединение с адресом X объёмом N» — факт. «Вероятно, передаются кадры» — предположение, для которого нужно указывать основания и степень достоверности.

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

— Какие доказательства нужны, чтобы утверждать, что видеоаналитика передаёт данные за пределы объекта?

А. Паламарчук: Само по себе соединение с публичным сервером ещё не означает утечку. Чтобы говорить о передаче чувствительной информации, нужна цепочка доказательств.

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

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

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

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

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

Поэтому иногда единственный обоснованный вывод звучит так: «Передаются данные неустановленного содержания объёмом N на инфраструктуру провайдера X в юрисдикции Y».

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

Ранее журнал RUБЕЖ писал о том, как системы облачного видеонаблюдения защищены от крупных сбоев в дата-центрах.