Технология Sandbox как средство обеспечения кибербезопасности электронных государственных услуг

Первая половина 2017 г. запомнится массовыми эпидемиями вирусов-шифровальщиков (WannaСry, Petya, Netya и т. п.). Массовость заражения поражала: публичность получили инциденты в крупнейших предприятиях всех отраслей (телеком, промышленность, ТЭК, государственные услуги). При этом большая часть инцидентов не выходила на уровень СМИ, так как вредоносы были вовремя локализованы и все в круглосуточном режиме занимались установкой обновлений. Эти события, безусловно, стали одним из главных драйверов ускорения принятия нового законопроекта о безопасности критической информационной инфраструктуры РФ, направленного в первую очередь на государственные организации. За ним последовало принятие программы «Цифровая экономика», целевым показателем которой является, в частности, средний срок простоя государственных информационных систем в результате компьютерных атак в объеме не более одного часа.

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

Электронные государственные услуги как объект повышенной вероятности атаки

Электронные государственные услуги − один из наиболее привлекательных объектов для распространения атак, которые на языке маркетологов принято называть целенаправленными (Advance Persistent Threat). Атаки на электронные государственные услуги позволяют быстро повысить свой статус в глазах «тусовки» для условных скрипт-киддис, получить доступ к значительному объему персональных данных и, конечно, заработать на выкупе за расшифрование данных. Государственные органы подвержены массовым атакам, использующим уязвимости, которые устранены в обновлениях, доступных за пару месяцев до первых атак, как это было с упомянутыми инцидентами. Вспоминается случай, когда на портале gosuslugi.ru был обнаружен вредоносный код рекламного характера, переводящий пользователя на внешние сайты. Следующий год тоже будет богат на события, повышающие как вероятность и мотивацию возможных злоумышленников, так и степень возможного ущерба в результате реализации атак (Чемпионат мира по футболу и выборы Президента Российской Федерации).

Практически любой портал государственных услуг как объект атаки обладает следующими отличительными свойствами:

• находится в зоне внимания граждан и СМИ − любой выход из строя или отклонение от нормального состояния не остаются незамеченными;
• большое количество пользователей, особенно для федеральных информационных систем и крупных муниципальных (г. Москва, Московская область, Санкт-Петербург и др.), что предполагает высокую нагруженность портала и жесткие требования к показателям назначения портала;
• предполагается возможность загрузки вложений в различных форматах, включая популярные форматы распространения вредоносного ПО – Adobe Acrobat, MS Word;
• используются заказная разработка и самописное ПО, следовательно, не исключены ошибки в разработке, например, возникшие в результате последних доработок перед дедлайном госконтрактов и отсутствия применения подходов безопасного программирования (SDLC);
• использование государственных услуг большим количеством органов исполнительной власти, степень осведомленности персонала которого в области ИБ в среднем достаточно низкая.

Если проанализировать возможные векторы распространения вредоносного ПО, то можно выделить следующие (рис. 1):

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

Рис. 1. БУДЕТ ПРЕДОСТАВЛЕН ДРУГОЙ РИСУНОК

Среди указанных векторов атак под потенциальное закрытие «песочницей» подходят первые три. Рассмотрим принципы работы «песочницы» и возможные сценарии ее применения.

Общие принципы работы «песочниц»

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

Разберемся, что же такое Sandbox и какие механизмы обнаружения вредоносного кода используют производители в своих «песочницах».

Sandbox («песочница») – это выделенная аппаратная или аппаратно-программная среда для исполнения файлов программ. Такая технология применяется, как правило, для эмуляции неотлаженного или подозрительного программного кода в изолированной среде, когда есть вероятность нарушения работы продуктивных систем. В нашей статье речь пойдет о «песочницах», в которых осуществляется исполнение подозрительного кода для выявления вредоносного содержимого в файлах, полученных из ненадежных источников.

С технической точки зрения Sandbox с определенной долей вероятности позволяет выявить неизвестные типы атак на основании поведенческого анализа вредоносного программного обеспечения. В этом и состоит главное преимущество этого класса решений, ведь в традиционных антивирусах и других системах сетевой безопасности слабо представлены методы защиты от 0day-атак.

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

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

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

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

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

• повышения полномочий;
• получения сетевого доступа к внешним ресурсам или широковещательным запросам по сети;
• изменения параметров реестра;
• обращения к системным файлам или данным на диске.

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

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

Тип операционной системы на базе, на которой создается виртуальная машина, определяется настройками системы. Как правило, производители поддерживают возможность использования актуальных операционных систем Microsoft Windows, как серверных, так и персональных, мобильных операционных систем iOS и Android, нескольких дистрибутивов операционных систем Linux. В отдельных случаях есть возможность загрузки эталонных образов виртуальных машин, используемых в ведомстве, с соответствующим перечнем установленного программного обеспечения.

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

• установка Sandbox в режиме мониторинга;
• установка Sandbox в режиме мониторинга и реагирования.

Схемы установки Sandbox в режиме мониторинга вредоносных файлов

1. Установка на SPAN-порт. Трафик от защищаемых систем перенаправляется на сетевой шлюз Sandbox путем передачи копии трафика на SPAN-порт коммутатора.
2. Интеграция с почтовым сервером по BCC. Шлюз Sandbox получает копию писем с почтовых серверов по технологии пересылки скрытых копий BCC.

Эти схемы не предусматривают активной реакции на обнаруженные угрозы и позволяют получить результаты эмуляции уже после того, как зараженный файл попадет к получателю. Другим существенным минусом является отсутствие возможности проверять файлы, которые передаются по протоколам, использующим шифрование – SSL/TLS и SMTPS. Такая схема актуальна, когда показатель доступности сервисов значительно выше, чем риски ведомства в случае заражения пользователя, или в случаях, когда необходимо провести оценку необходимости использования данного решения и правильно масштабировать Sandbox.

Схемы установки Sandbox в режиме обнаружения и блокирования

1. Установка в режиме «Inline» (или «в разрыв»). В такой схеме сетевой шлюз (или в случае с облачным решением − сенсор, обеспечивающий передачу файлов в облако) устанавливается таким образом, чтобы весь трафик до защищаемых систем проходил через Sandbox. Система может быть установлена как на уровне L3, так и на уровне L2 сетевой модели OSI. Как правило, в схеме установки на уровне L3 решение Sandbox интегрировано в UTM (Unified Threat Management). Подобная интеграция не всегда выгодна, так как эмуляция файлов внутри − достаточно затратное действие с точки зрения вычислительных ресурсов. В момент пиковой нагрузки шлюз UTM просто не сможет обработать поток входящих файлов, что повлечет снижение пропускной способности, а в некоторых случаях − кратковременный отказ в обслуживании. Стоимость такого решения, безусловно, будет ниже по сравнению со схемами, где предполагается применение отдельного шлюза, а также в случаях, когда используется облачный сервис для эмуляции файлов.
2. Установка в режиме MTA (Mail Transfer Agent). В этой схеме устройство Sandbox выступает в качестве Relay для входящей почты по аналогии с антиспам-фильтрами. Почта от внешнего Relay в первую очередь пересылается на шлюз Sandbox, затем письма перенаправляются на внутренние почтовые серверы. Письма, содержащие вложения, задерживаются на устройстве на время эмуляции файлов на «песочнице». При выявлении вложений, содержащих вредоносное программное обеспечение, дальнейшее перенаправление письма будет прервано, а пользователю будет направлено письмо соответствующего содержания. Такая схема наиболее приоритетна для защиты от вредоносных вложений, но, к сожалению, под защитой остаются только почтовые серверы, а другие каналы получения файлов не будут охвачены.
3. Установка в режиме ICAP (Internet Content Adaptation Protocol). Перенаправление трафика проводится по протоколу ICAP на устройство Sandbox для эмуляции файлов. По результатам анализа файла Sandbox возвращает результаты обратно на шлюз контентной фильтрации. Такая интеграция выгона в случаях, когда уже используются системы контентной фильтрации, поддерживающие протокол ICAP. В качестве минусов можно отметить, что ICAP разрабатывался в первую очередь как протокол работы с HTTP-трафиком и не всегда возможно передать на обработку контент, передаваемый по протоколу SMTP.
4. Прямая интеграция с системами контентной фильтрации. Многие производители устройств контентной фильтрации или решений класса UTM (Unified Threat Management) предлагают собственные решения Sandbox. Как правило, в этих случаях интеграция систем осуществляется с помощью проприетарных протоколов взаимодействия. Такая интеграция практически не имеет технических недостатков, однако не оставляет возможности выбора Sandbox-решения, отличного от предлагаемого производителем систем контентной фильтрации.

Рекомендации по применению

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

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

Для каждого канала проникновения необходимо отдельно прорабатывать архитектуры установки Sandbox. Как минимум, нужно учитывать следующие параметры:

• пути поступления файлов из внешней среды;
• основные типы (расширения) входящих файлов;
• операционные системы, используемые в ведомстве;
• размещение инфраструктуры ведомства с точки зрения географического распределения представительств;
• процессы работы пользователей – удаленная работа или работа в периметре организации;
• объем поступающих файлов – количество и средний размер файла.

Применение Sandbox тем не менее не является панацеей от 0day-атак: вредоносное программное обеспечение способно определять, находится оно в «песочнице» или попало в продуктивную систему. В качестве примеров механизмов сокрытия вирусов от «песочницы» можно рассматривать проверку доступности домена (Sandbox Evasion Techniques), разрешение экрана, наличие базовых установленных программ, отсутствие действий при запуске приложения. Все это факторы, свидетельствующие о том, что файл запущен в «песочнице», а не на рабочей станции конечного пользователя. С частью механизмов обнаружения «песочницы» вирусы уже умеют справляться, но постоянное развитие Sandbox обеспечивает создание все новых и новых способов сокрытия вредоносного кода внутри документов от способов обнаружения в «песочницах».