Выработка и анализ требований к защищенной мобильной операционной системе

ВЫРАБОТКА И АНАЛИЗ ТРЕБОВАНИЙ К ЗАЩИЩЕННОЙ МОБИЛЬНОЙ ОПЕРАЦИОННОЙ СИСТЕМЕ

DEVELOPMENT AND ANALYSIS OF REQUIREMENTS FOR PROTECTED MOBILE OPERATING SYSTEM

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

This paper deals w ith the issue of security of mobile devises and data stored and processed by them. The authors provide the analysis of the requirements for the protected mobile operating system.

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

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

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

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

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

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

Рассмотрим требования к защищенной операционной системе (на примере ОС Android [4]).

Управление доступом. Аутентификация и идентификация

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

Базовая операционная система предполагает возможность идентификации пользователя в системе следующими способами:

• PIN-код устройства;

• буквенно-цифровой пароль;

• графический ключ;

• портрет пользователя;

• NFC-метка.

Для обеспечения соответствия разрабатываемой ОС сформированным требованиям необходимо ввести ограничение на минимальную длину пароля пользователя при использовании буквенно-цифрового пароля в шесть символов. Также администратором устройства могут быть установлены следующие политики безопасности для пароля пользователя:

• тип пароля (PIN-код/пароль и т.д.);

• минимальная длина;

• обязательные символы.

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

Управление доступом. Дискреционная модель

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

Так как ОС Android базируется на ядре Linux, то дискреционная модель безопасности разрабатываемой мобильной ОС основывается на модели безопасности Linux.

Индекс файла в Linux содержит информацию о владельце файла (UID), его первичной группе (GID) и векторе доступа к файлу для трех категорий субъектов — владельца, членов его группы и всех остальных пользователей.

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

Дополнительно может быть реализована возможность настроить индивидуальные права доступа к файлам с использованием механизма списков контроля доступа (ACL). Данный механизм позволяет обеспечить возможность более гибкой настройки прав доступа объектов к субъектам. Например, ACL может быть использован при не-

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

Управление доступом. Мандатная модель

Каждому объекту и субъекту в системе должна присваиваться мандатная метка

— контекст безопасности. В качестве субъектов рассматриваются приложения (каждому приложению соответствует отдельный пользователь Linux) и запускаемые ими процессы, в качестве объектов — файлы, сокеты, именованные каналы.

Реализация мандатного доступа к данным основана на интегрированной с базовой мобильной операционной системе SELinux [5].

SELinux поддерживает следующие режимы работы:

• Permissive — разрешается нарушение политики безопасности. Такие нарушения только регистрируются в системном журнале. То есть по сути SELinux не работает, а только лишь фиксирует нарушения политики безопасности.

• Enforcing — нарушения политики безопасности блокируются.

• Disable — SELinux отключен.

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

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

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

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

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

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

Базовая ОС содержит [4] средства проверки цифровой подписи приложений при установке, однако может быть установлено приложение, подписанное анонимной цифровой подписью. Данная возможность должна быть изъята из разрабатываемой ОС. Проверка цифровой подписи должна быть реализована в соответствии с отечественными стандартами.

Подсистема межсетевого взаимодействия

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

Таким образом, в рамках ОС реализуется виртуальный сетевой интерфейс, осуществляющий безопасное взаимодействие с корпоративной сетью. Поступающие от мобильных устройств запросы перенаправляются в сеть Интернет; далее осуществляется прием и анализ ответа. В случае, если сервис анализа траффика, реализованный в инфраструктуре, считает траффик безопасным, производится перенаправление ответа на мобильное устройство.

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

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

Очистка освобождаемые областей оперативной памяти и внешних носителей

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

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

Krp-прспь доступа р шкроципи

ШНфрСй^НД лк.г|2наы

Требования к защищенной мобильной операционной системе на базе ОС Android

Таким образом, сформированы требования по доработке базовой операционной системы Android для приведения ее в соответствие с общими требованиями для защищенных мобильных ОС.

ЛИТЕРАТУРА

1. Фроимсон М.И., Кутепов С.В., Тараканов О.В., Шереметов А. В. Основные принципы построения защищенной операционной системы для мобильных устройств // Спецтехника и связь. — 2013. — №1. — С. 43—47.

2. Zhukov Igor, Mikhaylov Dmitry, Starikovskiy Andrey, Dmitry Kuznetsov, Tolstaya Anastasia, Zuykov Alexander. Security Software Green Head for Mobile Devices Providing Comprehensive Protection from Malware and Illegal Activities of Cyber Criminals // International Journal of Computer Network and Information Security (IJCNIS). — Vol. 5. — No. 5.

— April 2013. —Р. 1—8.

3. Михайлов Д.М., Жуков И.Ю. Защита мобильных телефонов от атак / под ред. А.М. Ивашко. — М.: Фойлис, 2011. — 192 с.: ил.

4. Архитектура операционной системы Android. 2011. — URL: http://android-shark.ru/arhitektura-operatsionnoy-sistemyi-android.

5. SELinux Documentation. National Security Agency, 2011. — URL:

http:// www. nsa.go v/rese arch/se linux/docs.s html.

REFERENCES

1. Froimson M.I., Kutepov S.V., Tarakanov O.V., Sheremetov A.V. Osnovnyie print-sipyi postroeniya zaschischennoy operatsionnoy sistemyi dlya mobilnyih ustroystv // Spet-stehnika i svyaz. — 2013. — №1. — S. 43—47.

2. Zhukov Igor, Mikhaylov Dmitry, Starikovskiy Andrey, Dmitry Kuznetsov, Tolstaya Anastasia, Zuykov Alexander. Security Software Green Head for Mobile Devices Providing Comprehensive Protection from Malware and Illegal Activities of Cyber Criminals // Interna-

tional Journal of Computer Network and Information Security (IJCNIS). — Vol. 6. — No. 6.

— April 2GB. —R. l—8.

3. Mihaylov D.M., Zhukov I.Yu. Zaschita mobilnyih telefonov ot atak / pod red. A.M. Ivashko. — M.: Foylis, 2Gll. — l92 s.: il.

4. Arhitektura operatsionnoy sistemyi Android. 2Gll. — URL: http://android-shark.ru/arhitektura-operatsionnoy-sistemyi-android.

6. SELinux Documentation. National Security Agency, 2Gll. — URL: http:// www. nsa.go v/rese arch/se linux/docs.s html.