Оценка безопасности мобильных приложений (часть 3) – методы тестирования и результаты
- Оценка безопасности мобильных приложений (Часть 2) — Тестирование приложения
Это третий отрывок из этой серии статей. В предыдущих статьях мы рассмотрели оценку мобильных приложений, используя методический подход. В статье одной из серий мы рассмотрели этап раннего планирования, за которым последовали начальные шаги процесса тестирования приложения.
Двигаясь вперед, мы обсудим более глубокий взгляд на различные методы тестирования мобильных приложений, которые можно использовать для тестирования приложений, и, наконец, рассмотрим мыслительный процесс, лежащий в основе принятия решения об одобрении или отклонении приложения, основанного на знаниях, полученных в процессе проверки приложения.
Введение
Использование мобильных устройств и мобильных приложений на предприятии явно продвинуло производство, однако потенциальный риск безопасности, связанный с мобильными приложениями на предприятии, также очевиден и не должен игнорироваться, поэтому необходима строгая система проверки приложений.
Цель этой серии статей — помочь организациям в процедурах, связанных с проверкой потенциальных приложений или уже работающих на мобильных устройствах, чтобы в конечном итоге повысить безопасность, когда мобильные вычисления используются для корпоративных функций, что в настоящее время является обычным явлением на предприятиях.
Методы тестирования, используемые для проверки мобильных приложений, должны использоваться для эффективного манипулирования приложением, чтобы любая потенциальная уязвимость могла быть обнаружена, а организация могла принять обоснованные решения относительно того, является ли уровень риска приемлемым или нет, и, в конечном счете, следует ли приложение утвержден или отклонен.
Методы испытаний
Для проверки приложений можно использовать разнообразный набор методов тестирования. С помощью этого процесса тестирования приложений/манипулирования приложениями организации определят, соответствует ли рассматриваемое приложение требованиям безопасности организации (описанным во второй части).
После тестирования аудиторы оценят результаты и на основе уникальных бизнес-функций организации и требований безопасности, а также уровней приемлемости риска решат, следует ли утвердить приложение или отклонить его.
При проведении тестирования должны быть охвачены все уровни, от уровня клиента, кода и пользовательского интерфейса до уровня сервера, поскольку все области потенциально могут содержать уязвимости в системе безопасности.
Методы тестирования адаптируются под тестирование мобильных приложений. Методы, используемые в течение некоторого времени, такие как статическое тестирование безопасности приложений (SAST) и динамическое тестирование безопасности приложений (DAST), были адаптированы для целей тестирования мобильных приложений. Поведенческое тестирование, анализ работающего приложения для мобильных приложений также теперь обычно используется и может раскрыть ценную информацию.
Для более тщательного и всестороннего процесса тестирования потребуется несколько наборов тестовых инструментов. Один тип инструмента может быть лучше для определения конкретного требования, но может быть плохим для другого. Следует уделить время и внимание тому, чтобы выбрать лучший набор инструментов, подходящий для тестирования вашего приложения, чтобы достичь максимально возможного успешного уровня тестирования.
Методы испытаний могут включать:
- Проверка правильности
- Анализ исходного или бинарного кода
- Статический или динамический анализ
- Ручное тестирование
- Автоматизированное тестирование
Метод испытания | Функциональность | Когда выбрать этот метод тестирования | Достоинства/недостатки метода |
Тестирование корректности программного обеспечения | Выполнение программы с намерением найти ошибки | Подтвердить качество приложения Чтобы оценить надежность приложения Для подтверждения заявленной функциональности приложений Для выявления уязвимостей безопасности (обычно специфичных для конкретного приложения) | Этот тип тестирования обычно строится на уникальных спецификациях тестируемого приложения. Улучшение тестирования уязвимостей, которые могут быть уникальными для конкретного приложения, вместо более общего подхода к тестированию с более обобщенными результатами. |
Анализ исходного или бинарного кода | Анализируйте исходный код или двоичный код, используя различные методы и инструменты. Ручной подход — физический просмотр файлов кода Автоматизированный подход с использованием автоматизированных инструментов статического анализа Навыки и знания в области разработки и областей безопасности приложений чрезвычайно важны для точного и успешного проведения этого типа анализа. Трудоемкий | Когда исходный код доступен, для просмотра исходного кода и поиска уязвимостей в исходном коде. Когда приложение с открытым исходным кодом. Также для подтверждения результатов анализатора. | Можно использовать различные инструменты (ручной или автоматизированный подход) Трудоемкий |
Статический анализ | Исследует код Включает анализ поведения приложения Обратный инжиниринг часто требуется, если исходный код недоступен. | Предусмотреть все потенциальные сценарии, которые могут возникнуть при запуске приложения. Для анализа поведения приложений и поиска уязвимых мест | Достижима точная гарантия того, как приложение будет вести себя независимо от входных данных приложения или среды, в которой оно выполняется. Реверс-инжиниринг кода может быть сложным в зависимости от типа кода. Обратный инжиниринг полезен, чтобы позволить людям просматривать код |
Динамический анализ | Входной анализ Рассматривает различные варианты использования с помощью различных входных данных и анализирует поведение приложений в соответствии с различными входными сценариями. Используйте эмулятор или исполняющее приложение или оба | Чтобы увидеть работу кода по мере его выполнения | Отнимает много времени из-за многочисленных потенциальных входных сценариев Точность сомнительна, поскольку вы не можете гарантировать охват всех сценариев, а полный анализ кода маловероятен. Использование как эмуляторов, так и физических устройств снижает количество ложноотрицательных результатов. |
Ручное тестирование | Тестирование уязвимостей приложений с помощью человеческого ввода и анализа | Проверка приложений на наличие уязвимостей вручную | Кропотливый Требуется хорошая база знаний, набор навыков и опыт |
Автоматизированное тестирование | Проверка приложений на уязвимости Использует симулятор или доступ к удаленному устройству Типы инструментов включают:
| Тестировать на наличие уязвимостей с помощью различных автоматизированных инструментов | Получите отчет и оценку рисков Мобильная функция хорошо подходит для автоматизированного тестирования |
Таблица 1
Вы провели исследование, объединили большой набор типов инструментов тестирования и провели тестирование своего приложения. Какими должны быть следующие шаги после сбора многочисленных результатов?
После всей работы, которую вы проделали для достижения своих результатов, вы можете почувствовать себя обязанным оставить эти результаты себе. Однако настоятельно рекомендуется, чтобы обмен результатами через базу данных сообщества Software Assurance был очень полезным. Благодаря этому специалисты по безопасности и организации могут извлечь выгоду из коллективных усилий, сократив затраты и время. Собранные данные помогают в управлении безопасностью и уязвимостями, а также в усилиях по стандартизации и соответствию требованиям. Его также можно регулярно отслеживать, чтобы быть в курсе изменений в уязвимостях приложений и помогать расставлять приоритеты в этой области.
Отчетность о результатах и оценках рисков является критически важной областью. Результаты должны сообщаться интуитивно и таким образом, чтобы аудитору было легко их понять и интерпретировать.
Утверждение или отклонение приложения
Перед проверкой приложения необходимо установить процедуру обработки утвержденного или отклоненного приложения. Это должно стать частью процедур политики организации в отношении безопасности приложений. Это необходимо для того, чтобы шаги по внедрению или удалению приложения были четко прояснены и их можно было легко выполнить после принятия решения об одобрении или отклонении.
Аудитор(ы) (рекомендуется более одного аудитора для получения более убедительного результата) должны решительно рассмотреть результаты, полученные в отчете об оценке, и уровень риска, связанного с использованием приложения, в отношении функции предприятия и изначально установленных требований безопасности для посмотрите, поддерживаются ли эти требования приложением, а затем дайте рекомендацию для утверждения или отклонения приложения. Для того чтобы аудитор мог выдвинуть соответствующее решение, аудитор должен иметь глубокое представление о предприятии и его функциях.
Аудитор будет использовать и учитывать следующие критерии, чтобы прийти к решению:
- Воспринимаемый уровень риска, если приложение будет одобрено и использовано
- Учитывайте уровень безопасности приложений
- Учитывайте порог риска организации
- Подумайте о требованиях к проверке организаций и о том, были ли они поддержаны или нет.
- Рассмотрите отчеты и результаты тестирования приложения для оценки рисков.
- Учитывайте тип данных, которые будут обрабатываться
- Подумайте, насколько важно приложение для предприятия
- Подумайте, кто будет использовать приложение
- Учитывайте среду, в которой приложение будет использоваться или находится, и тип аппаратного обеспечения, которое ему потребуется.
- Рассмотрите документацию приложения и соглашения об уровне обслуживания
В конечном счете решение об одобрении или отклонении заявки остается за организацией. Лицо или команда в организации, ответственные за процедуру окончательного утверждения или отклонения, должны принять во внимание эту рекомендацию вместе с другими бизнес-критериями, связанными с потенциальным использованием приложения (не на основе безопасности приложения).
Затем должны быть выполнены процедуры внедрения или удаления приложения в зависимости от того, одобрено оно или отклонено.
Вывод
Эта третья статья в серии завершает процесс тестирования приложения.
Количество приложений собственного производства или сторонних приложений, разработанных с возможностями, специально предназначенными для удовлетворения уникальных требований организаций, вероятно, возрастет. Кроме того, это будет иметь основополагающее значение для оказания помощи организациям в получении максимальной производительности от использования мобильных технологий.
Многие виды уязвимостей проявляются в дизайне и кодировании приложений. Выявление этих слабых мест требует сначала определения требований к приложениям на этапах планирования, чтобы любые несоответствия этим требованиям можно было легко определить как слабые места и не допустить снижения уровня безопасности предприятия за счет использования приложений.
Преимущества использования мобильных приложений в бизнесе не должны достигаться в ущерб безопасности предприятия, поэтому необходимо проводить надлежащую проверку приложений, чтобы гарантировать, что стандарты безопасности в организации поддерживаются и высоко ценятся.
- Оценка безопасности мобильных приложений (Часть 2) — Тестирование приложения