Как обеспечить безопасность мобильных приложений

Автор: Андрей Красовский, директор по маркетингу Swordfish Security

Сегодня компании активно внедряют практики и инструменты для обеспечения безопасности, чтобы повысить уровень защищенности продуктов, а также выполнить требования регуляторов, индустриальных стандартов или заказчиков, для которых разрабатываются приложения. Согласно исследованию Positive Technologies, сегодня 34% крупных игроков и 31% представителей малого бизнеса уже строят процесс безопасной разработки. Часть оставшихся организаций только задумываются об этом. 

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

Основные подходы к обеспечению безопасности

С каждым годом популярность мобильных приложений растет. Согласно отчету State of Mobile 2022, в 2021 году пользователи со всего мира провели в приложениях рекордные 3,8 трлн. часов. За прошедший год было выпущено 2 млн. новых мобильных программ и игр, их общее число достигло 21 млн. За этот период российские пользователи скачали больше 5,5 млрд. приложений — это шестое место в мировом рейтинге. 

Такая популярность приложений привлекает хакеров, они совершают все больше атак на мобильные программы, используя их уязвимости. Чаще всего в приложениях встречаются такие ошибки, как небезопасное хранение данных, обход архитектурных ограничений, небезопасная передача данных, слабая криптостойкость — полный перечень распространенных уязвимостей описан к классификации OWASP Mobile Top 10. Несмотря на стремительное развитие рынка мобильных приложений, документ обновлялся в последний раз в 2016 году. Таким образом, все указанные в классификации ошибки до сих пор актуальны — это подчеркивает низкую проработанность проблем и процессов безопасности в компаниях-разработчиках. 

В рамках обеспечения защищенности приложений существуют два основных пути, по которым могут пойти компании:

• внедрение инструментов ИБ в процесс разработки;

• повышение уровня безопасности готовых продуктов. 

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

Инструменты тестирования безопасности приложений

Сегодня рынок предлагает ряд различных технологий для анализа безопасности мобильных приложений, в их числе:

• Практики статического тестирования: SAST, OSA, SCA, BCA. Такие инструменты работают по методу «белого ящика»: анализируют исходный код, а в случае его недоступности проверяют декомпилированный или байт-код;

• Сканеры динамического анализа (DAST). Они используют метод «черного ящика»: тестируют готовые приложения в процессе их работы, имитируют работу злоумышленников или вредоносных программ и таким образом находят уязвимости; 

• Инструменты для проверки бэкенда мобильных приложений (API ST). В рамках тестирования происходит обмен сообщениями между фронтендом (пользовательский интерфейс) и бэкендом (программно-аппаратная часть, «начинка» приложения). Как и DAST, API ST широко использует неподходящие команды и некорректные данные;

• Практика интерактивного тестирования (IAST). В таких инструментах объединяются технологии SAST и DAST. IAST анализирует код в то время, как мобильное приложение функционирует, ищет проблемы безопасности в режиме реального времени, проверяя потоки данных, HTTP-запросы и ответы, конфигурации, фреймворки, библиотеки и другие компоненты. 

Критерии выбора инструментов безопасности

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

Качество сканирования. Это соотношение найденных и пропущенных уязвимостей. Конечно, понять сходу, насколько хорошо анализирует сканер, не получится. Для оценки нужно хотя бы примерно представлять, какие уязвимости есть в приложениях, чтобы сравнить их с результатами, выданными этим инструментом. На качество сканирования также влияет количество ложных срабатываний — они засоряют отчеты. Чтобы оценить работу сканера в этом случае, нужно изучить результаты, разобрать срабатывания и посчитать примерный процент ложных (он должен быть минимальным). 

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

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

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

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

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

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

Организация автоматизированного тестирования безопасности

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

Тестирование безопасности мобильных приложений отличается от сканирования веб-приложений и имеет ряд особенностей, которые обязательно нужно учитывать в процессе организации проверок:

• Необходимо создать для тестирования специальное окружение. Это могут быть физические мобильные устройства с загруженными инструментами для сканирования или эмуляторы (в случае с Android). В дальнейшем их нужно поддерживать в рабочем состоянии. На объекты окружения желательно установить различные версии операционных систем. 

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

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

• Если существует веб-версии приложений, нужно интегрировать их с тестированием безопасности вариантов для смартфонов. Зачастую в мобильных и веб-версиях используется один и тот же API (программный интерфейс). Используя эту особенность при сканировании, можно получить синергетический эффект и провести более эффективные проверки. 

Ручное тестирование

Автоматизированные инструменты анализа позволяют найти примерно 80% уязвимостей, но при этом отнимают около 20% ресурсов. Оставшаяся часть проблем — это сложные ошибки, которые можно обнаружить с помощью penetration testing (pentest, или тестирование на проникновение). Практика работает без доступа к исходному коду, в процессе анализа пентестеры разными способами имитируют атаки злоумышленников (например, фишинг или утечку данных), чтобы найти и проанализировать уязвимости, которые способны нарушить работу приложений или дать хакерам доступ к конфиденциальной информации. В рамках пентеста можно пользоваться результатами автоматизированного тестирования для повышения эффективности проверок. 

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

Заключение

Компании, в которых не налажен процесс разработки защищенного ПО, оставляют безопасность на потом. Такой подход неудобен тем, что может вызвать аврал на последних этапах разработки ПО. Безопасники обнаружат большое количество уязвимостей и вернут приложения разработчикам, чтобы те все исправили — это затянет весь процесс релиза. Поэтому сегодня с учетом тенденций сокращения времени вывода продуктов на рынок и повышения качества ПО актуален подход, называемый Shift Left, в рамках которого проверки безопасности осуществляются на всех этапах жизненного цикла разработки приложений. Он предусматривает полную автоматизацию процессов, позволяет сэкономить время ИБ-специалистов и разработчиков и при этом повысить уровень защищенности продуктов. Реализация процесса безопасной разработки представляет собой целую программу последовательных и системных действий. Ключевое место среди них занимает внедрение инструментов безопасности в процессы DevOps. 

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