Профиль защиты ЦБ РФ и мобильные приложения: разбираемся, как соответствовать
Всем привет! На связи Юрий Шабалин, генеральный директор «Стингрей Технолоджиз». Вообще я сторонник технических материалов, статей с примерами кода или разбором технологий, но сегодня речь пойдет о другом. Меня всегда интересовало, почему в требованиях регуляторов в области ИБ не указываются проверки мобильных приложений на соответствие государственным стандартам или федеральным законам. И вот недавно, изучая материалы документа по сертификации процесса безопасной разработки, я наткнулся на упоминание мобильной составляющей, что, конечно, вызвало у меня интерес и желание разобраться. Если вы тоже хотите понять, каким образом приложения упоминаются в Профиле защиты Банка России, и какие проверки необходимо осуществлять, чтобы ему соответствовать, приглашаю погрузиться со мной в этот увлекательный мир.
Профиль защиты Банка России. Единственный и неповторимый
Изучая законодательные материалы и требования регуляторов, я наткнулся на упоминание мобильных приложений в документе ЦБ РФ «Профиль защиты прикладного программного обеспечения».
Совместимым объектом оценки для настоящего ПЗ является прикладное программное обеспечение автоматизированных систем и приложений финансовых организаций, предназначенное для функционирования на средствах вычислительной техники общего назначения (автоматизированные рабочие места, серверы), а также на мобильных устройствах (ноутбуки, смартфоны, планшеты, телефоны и иные).
…
Тестирование на проникновение, в зависимости от типа ОО, может включать в себя следующие направления исследований, применимые к ОО и среде его функционирования:
а) оценка защищенности веб-приложений;
б) оценка защищенности специализированных банковских приложений (специализированного ПО) финансовых организаций;
в) оценка защищенности мобильных устройств
Скажу честно, так как я мало знаком с нюансами законодательства, пришлось много чего прочитать и разобрать. В этой статье постараюсь объяснить, что же из себя представляет Профиль защиты, для чего он был создан и как влияет на безопасность наших любимых «мобилок».
В 2020 году Технический комитет Банка России (ТК 122) разработал «Профиль защиты прикладного программного обеспечения и автоматизированных систем и приложений кредитных организаций и некредитных финансовых организаций». Цели стандарта — обеспечить единую практику применения отраслевых нормативов (Положения № 683-П, № 684-П и № 382-П) при проведении анализа уязвимостей ПО для финансовых услуг. Эти документы регулируют защиту информации при осуществлении денежных операций, но только одно из требований каждого из них касается проверки безопасности приложений.
Профиль защиты, помимо оценки уязвимостей, предъявляет множество дополнительных условий (их раз в 50 больше). Кроме того, он требует проводить оценку уязвимостей не по среднему ОУД4 (оценочный уровень доверия, четвёртый из семи существующих), а по максимально возможному (ОУД6 и ОУД7). Да еще и ЦБ ввел дополнительные необходимые проверки (_EXT). Так как не всем будут интересны подробности, я оставлю расширенную информацию ниже. Если вам хочется погрузиться в детали — добро пожаловать «под кат».
Подробности формирования требований в Профиле Защиты
Есть ГОСТ ИСО/МЭК 15408–3. В нем описаны компоненты типа ABC_DEF.X. Они входят в семейства АBC_xxx.Y, которые содержатся в классах (без кодов, но имеют названия «разработка», «руководства»).
Компоненты выдвигают более или менее высокие требования к конкретным действиям. Например, семейство ADV_ARC содержит только 1 составляющую ADV_ARC.1, а в ADV_FSP есть иерархически возрастающие элементы от ADV_FSP.1 до ADV_FSP.6. Чем больше цифра, тем сложнее условия к действиям и/или к свидетельствам.
В ГОСТ ИСО/МЭК 15408 есть отдельное понятие «пакет» (пакет доверия) — это уже набор нескольких компонентов. При этом цифры могут быть любые. В ГОСТ ИСО/МЭК 15408–3 введены следующие «стандартные» пакеты ОУД (оценочный уровень доверия):
Обзор оценочных уровней доверия
Регуляторы разных стран выбирают минимальную планку, например, для вхождения на рынок. Что касается банковской сферы РФ, ЦБ в 2019 году (372-П) написал следующее:
2.5.5.1. Оператору по переводу денежных средств, оператору услуг платежной инфраструктуры на стадиях создания и эксплуатации объектов информационной инфраструктуры необходимо обеспечить:
использование для осуществления переводов денежных средств прикладного программного обеспечения автоматизированных систем и приложений, сертифицированных в системе сертификации Федеральной службы по техническому и экспортному контролю на соответствие требованиям по безопасности информации, включая требования по анализу уязвимостей и контролю отсутствия недекларированных возможностей, в соответствии с законодательством Российской Федерации или в отношении которых проведен анализ уязвимостей по требованиям к оценочному уровню доверия не ниже чем ОУД4 в соответствии с требованиями национального стандарта Российской Федерации ГОСТ Р ИСО/МЭК 15408–3–2013…
То есть из всего пакета ОУД4 нужно выполнить только элементы компонента AVA_VAN.3 — это довольно средний уровень сложности требований. Бывают от AVA_VAN.1 до AVA_VAN.5. Если AVA_VAN.1 — проверка минимума, например защиты от «школьников», то AVA_VAN.5 анализирует, может ли ПО взломать группа хакеров с неограниченными возможностями.
Оценка уязвимостей
Однако в Профиле защиты ЦБ указал:
Оценочный уровень доверия 4 (ОУД4), усиленный компонентами:
ADV_IMP.2 «Полное отображение представления реализации ФБО»,
ALC_FLR.2 «Процедуры сообщений о недостатках»,
AVA_VAN.5 «Усиленный методический анализ»,
и расширенный компонентами:
ADV_IMP_EXT.3 «Реализация ОО»,
ALC_FPU_EXT.1 «Процедуры обновления программного обеспечения»,
ALC_LCD_EXT.3 «Определенные разработчиком сроки поддержки»,
AMA_SIA_EXT.3 «Анализ влияния обновлений на безопасность» и
AVA_CCA_EXT.1 «Анализ скрытых каналов».
То есть контроль вроде как по ОУД4, но конкретно по стандартным проверкам на уязвимости — уже максимальный — как по ОУД6 и ОУД7. Да еще и ЦБ ввел дополнительные требования (_EXT), которых нет в ГОСТ.
В среде организаций-членов ТК 122 осталось много вопросов о том, можно ли исследовать ПО не только при помощи испытательных лабораторий и других лицензиатов ФСТЭК РФ по заказу финансовых компаний. А также, как вообще применять ПЗ в процессе быстрой разработки. В ответ на это в 2022 году Банк России дополнил Профиль защиты разделом 7.4, в котором изложены требования к гибкому безопасному созданию и тестированию продуктов. Теперь необязательно проводить оценку соответствия по ОУД4 каждой новой версии программы, а достаточно внедрить и сертифицировать сами ИБ-процессы в разработке. И, конечно, в этом случае анализ уязвимостей проводить необходимо.
Другими словами, теперь компании могут выбирать продуктовый или процессный путь оценки соответствия по ОУД. В первом случае нужно подтверждать и проверять каждую новую версию разрабатываемого продукта, а во втором — сам процесс безопасной разработки, при этом все релизы будут считаться прошедшими оценку соответствия (сертифицированными). Давайте рассмотрим оба варианта более подробно и выясним, как их применение отражается на мобильных приложениях.
Продуктовый путь оценки соответствия
Дано: банк подает заявку во ФСТЭК России на проведение дорогих испытаний одной из 50 аккредитованных испытательных лабораторий. А что, так бывает? Вряд ли. Это же очень дорого и долго. Куда более вероятно, что заявитель будет искать вариант подешевле, а именно — одного из нескольких тысяч других лицензиатов ФСТЭК России. Даже без аттестата аккредитации испытательной лаборатории он имеет право проводить оценку соответствия (хотя качество и глубина здесь сильно разнится, да и на выходе вместо сертификата будет технический отчет об оценке или еще какой-нибудь документ). Для описания возможностей среднестатистического лицензиата по проведению оценки соответствия по ОУД4 как нельзя лучше подходит фраза: «Да! И … нет. Но это не точно».
Продуктовый путь оценки соответствия предполагает разработку порядка двух десятков документов на продукт, а также выполнение ряда тестов и проверок в отношении ПО, причем его конкретной версии, которая «фиксируется» и больше не может быть изменена производителем.
Одна из ключевых проблем при проведении оценки соответствия на ОУД4 по ГОСТ Р ИСО/МЭК 15408–3–2013 — необходимость выполнения требований компонента доверия AVA_VAN.3 «Сосредоточенный анализ уязвимостей». Сложности связаны с поиском эксперта или приобретением сканера кода, который «досконально знает нужные языки программирования».
Процессный путь оценки соответствия
Выбрав этот путь, банк просто внедряет у себя процессы гибкой безопасной разработки и тестирования — и готово! Так бывает, да, но и здесь не всё так просто. Нужно найти консультанта по таким вопросам (например, ту же испытательную лабораторию или лицензиата ФСТЭК России). Кто-то скажет: «Зато не нужно проводить оценку каждой версии всех приложений, которые выпускает компания!» Увы, нужно. Но анализировать уже можно своими силами — это и предполагают процессы безопасной разработки.
Рассмотрим подробнее. Итак, в Профиле защиты появились термины: безопасный жизненный цикл разработки ПО (DevSecOps) и команда безопасной разработки ПО (команда DevSecOps). Это значит, что компания должна интегрировать ИБ в процесс создания программы и нанять практикующих экспертов.
Более того, согласно п.7.4 ПЗ компания должна иметь:
наличие в компании ИТ-архитекторов, аналитиков кода («AppSec-еры»), DevOps-инженеров и тестировщиков, Security Champions;
целый комплекс программ по обеспечению безопасной разработки, тестирования и переноса ПО в промышленную эксплуатацию.
Выбирать процессный или продуктовый подход стоит в зависимости от частоты выхода версий продукта и множества других факторов. Но в любом случае компаниям нужны ИБ-эксперты и эффективные инструменты, так как при тестировании программ на соответствие требованиям ПЗ нужно применять много практик безопасности, таких как Code Review, Security Review, статический и динамический анализ кода, фаззинг, проверки на проникновение и др.
Кейсы по тестированию ПО с помощью Стингрей
Итак, мы уже знаем, что мобильные приложения, отмеченные в Профиле защиты, должны проходить множество проверок безопасности. Со статическим анализом всё более-менее ясно (многие сервисы поддерживают языки программирования в мобильной разработке), а вот с остальными практиками — не очень. И здесь может оказаться вполне кстати наш инструмент для анализа безопасности мобильных продуктов. Вы знаете, что я не фанат саморекламы, но здесь нам самим было интересно разобраться, а делать это всегда приятно и полезно при помощи собственных наработок. И тут, как нельзя кстати то, что внутри Стингрей поддерживаются все методы анализа защищенности, которые могут быть применимы к мобильным приложениям. Мы умеем тестировать файлы сборки продукта и декомпилированный код, изучаем программу во время работы и, конечно, проводим активные проверки методом фаззинга, то есть отправляем подготовленные векторы атак в открытые компоненты ПО (Applink/Deeplink, Activity, Content Providers. URL Scheme и т.д.). Сейчас покажем, как.
Разбираться с применением требований Профиля защиты к мобильным продуктам будем на примере приложений банков из ТОП-50 финансовых организаций России. Как правило, в таких крупных компаниях (или у их подрядчиков) уже внедрены процессы DevSecOps, поэтому количество уязвимостей в таких продуктах минимально, а их поиск становится очень сложной задачей. Так как Стингрей работает только с итоговым артефактом (собранным приложением), мы будем проверять те из них, что уже опубликованы в магазинах Google Play, RuStore, RuMarket и др.
Итак, банк заказал у разработчика мобильное приложение. В соответствии с продуктовым подходом, компания (или нанятый лицензиат ФСТЭК России) проходит проверки на соответствие ОУД4. Что сразу пропускаем:
Составление отчетности, предусмотренной ПЗ/ГОСТ Р ИСО/МЭК 15408–3–2013 — это «бумажная безопасность», которая выходит за рамки нашей статьи. Для примера, просто посмотрите на список документов, который необходимо иметь разработчику (и это еще не всё поместилось):
Краткий список материалов для соответствия
Тестирование функциональных требований безопасности, определенных в Профиле защиты — по этой теме уже написано 100500 статей, книг и блогов от экспертов:
Тестирование функциональных требований
Оставляем самое интересное, то, ради чего всё затевалось Банком России — выявление уязвимостей.
Из ПЗ Банка России:
7.2.6. Оценка уязвимостей (AVA)
Из ГОСТ Р ИСО/МЭК 15408–3–2013:
Оценка уязвимостей согласно ГОСТ Р ИСО/МЭК 15408–3–2013
Согласно государственному стандарту нам нужно выполнить 4 действия и пройти 12 шагов оценивания (они подробно описаны в п. 14.2.3 ГОСТ Р ИСО/МЭК 18045–2013):
Шаги оценки
При этом Банк России требует использовать определенные методы, такие как статический и динамический анализ, а также тестирование на проникновение. Обычно это занимает несколько недель или даже месяцев лабораторных исследований при помощи ИБ-экспертов. Для сокращения трудозатрат и повышения эффективности мы применяем ̶м̶а̶г̶и̶ю̶ автоматизацию, а именно — платформу Стингрей.
Пример 1
После аудита тестируемого приложения при помощи платформы можно увидеть много интересного:
Небезопасное хранение PIN-кода в мобильном приложении
Что по фактам? В переводе на русский:»Проверим, не хранится ли пин-код в открытом виде. А вот и он! Сразу после его ввода пользователем он записывается в кейчейн».
Нужно ли нам это для соблюдения требований ГОСТ или Профиля защиты? Да. Смотрим в ПЗ и видим, что наиболее близкими к найденной уязвимости являются:
пункт «а» из мероприятий по оценке защищенности веб-приложений: «выявление уязвимостей, связанных с раскрытием защищаемой информации о приложении, в том числе путем … поиска защищаемой информации в коде». Только разработчики ПЗ зачем-то ограничили тип приложений, к которым это относится, указав лишь веб-программы;
пункт «а» из процедур по анализу безопасности специализированных банковских приложений: «прослушивание сетевого трафика и поиск в нем защищаемой информации, включая пароли и хеш-значения паролей пользователей, идентификаторы сессий, авторизационные маркеры, криптографические ключи». Здесь также установили рамки, но уже на способ сбора свидетельств — »прослушивание сетевого трафика». А мы выявили эту уязвимость при хранении Pin-кода локально на устройстве. Но если посмотреть в трафик этого же приложения, можно увидеть в нем передачу пароля в открытом виде и логине пользователя. Конечно, всё защищено на сетевом уровне при помощи https, но учитывая, что в приложении не реализован SSL Pinning, говорить о надежном способе транспортировки данных еще рано:
Включение чувствительной информации в параметры GET-запроса
пункт «а» из мероприятий по оценке безопасности мобильных устройств: «проверка наличия защищаемой информации в файлах данных». Тут вообще сложно понять, о какой именно защищенности идет речь, если в п. 2.3.3 указано:»В рамках настоящего ПЗ аппаратные средства, программное обеспечение, программно-аппаратные средства, не входящие в ОО, не рассматриваются».
Так или иначе, в ПЗ Банка России эти ограничения «поданы со вкусом»:»…в зависимости от типа ОО, может включать в себя следующие направления исследований, применимые к ОО и среде его функционирования». То есть требования носят лишь рекомендательный характер, поэтому здесь у нас руки развязаны. Будем считать, что найдена »уязвимость, связанная с раскрытием защищаемой информации».
Пример 2
Загружаем в Стингрей другое приложение:
Серверный ключ доступа в коде приложения
Этот вариант несколько хуже для безопасности, чем в первом примере — разработчик дарит злоумышленнику валидный ключ от внешнего сервиса. Стингрей идентифицирует ключ и сервис, проверяет достоверность секрета и его права доступа. В этом случае с помощью API-ключа можно отправить PUSH-уведомление всем пользователям приложения.
Эксплуатация данной проблемы ранее была представлена 4-мя строками на Python, но после «исправления» от Google задача немного усложнилась, и теперь нужно сначала найти группу пользователей, в которую мы будем отправлять пуш. Тем не менее, это всё еще реальная угроза для компании и клиентов. Представьте, что станет с организацией, если от ее имени придет странное PUSH-сообщение, например с предложением перейти к конкуренту, нелицеприятной картинкой или вовсе оскорблением? Предлагаю посмотреть, как именно это работает:
Пример отправки PUSH-сообщения
Отнесем найденную ИБ-проблему к типу »уязвимость, связанная с раскрытием API- ключей».
Конечно, большая часть выявленных уязвимостей формально не будет подпадать под требования ПЗ, так как для проведения оценки защищенности веб-приложений регулятор рекомендует использовать 16 видов проверок, а для анализа специализированных банковских ПО только 4. Но мы уже определились, что говорим про практическую, а не «бумажную» безопасность, поэтому смело применяем любые проверки к разным видам ПО — реальные хакеры вряд ли вообще в курсе существования ПЗ и такого ограниченного списка тестирований. Если интересно, то также под катом можно изучить все эти требования.
Мероприятия при оценке защищенности
При проведении оценки защищенности веб-приложений рекомендуются следующие мероприятия:
а) выявление уязвимостей, связанных с раскрытием защищаемой информации о приложении, в том числе путем отправки некорректных сообщений, анализа стандартных системных сообщений об ошибках, поиска защищаемой информации в коде и комментариях веб-страниц;
б) получение сведений о структуре файловой системы перебором путей и имен файлов (полный перебор, перебор по словарю, проверка наличия стандартных файлов используемых платформ и средств разработки, поиск резервных копий файлов);
в) проверка корректности обработки специальных символов в параметрах запроса (символы форматирования вывода, перевода строки и возврата каретки, перехода в вышестоящий каталог, двойное URL-кодирование);
г) проверка корректности обработки параметров различной длины;
д) проверка корректности обработки числовых параметров, в том числе не предусмотренных технологией обработки больших величин, отрицательных и нулевых значений;
е) проверка корректности приведения и преобразования типов параметров;
ж) проверка корректности обработки различного представления пользовательских данных, в том числе дублирование заголовков запроса, дублирование параметров сценария;
з) проверка корректности обработки параметров универсального идентификатора ресурса (URI — uniform resource identifier), в том числе возможности подключения произвольного внешнего источника данных или перенаправления на внешний или внутренний веб-сайт, возможности обращения к сетевым протоколам, возможности замены полного пути к ресурсу на относительный;
и) проверка наличия ошибок, связанных с обработкой загружаемых файлов, в том числе с обработкой имен файлов без расширения, несоответствием расширения типу файла, альтернативными расширениями для файлов одного типа, специальными символами (включая нулевой символ) в имени файла;
к) проверка корректности исполнения сценариев при манипулировании входными параметрами, в том числе атрибутами безопасности, используемыми при управлении доступом;
л) проверка возможности подбора аутентификационных данных (паролей, включая словарные, идентификаторов сессий, атрибутов, используемых для восстановления паролей);
м) проверка корректности обработки идентификаторов сессий пользователей, в том числе обработки событий завершения сессии, интервалов неактивности, сопоставление идентификатора сессии с дополнительными атрибутами, прямо или косвенно идентифицирующими пользователя или его рабочее место, предотвращение повторного и множественного использования идентификаторов сессий;
н) проверка корректности реализации механизмов авторизации;
о) проверка корректности противодействия атакам на клиентские приложения, в том числе с использованием межсайтового выполнения сценариев и подделки межсайтовых запросов;
п) проверка корректности обработки входных параметров сценариев при внедрении в них команд операционных систем, синтаксических конструкций языков программирования и разметки;
р) проверка невозможности обхода средств межсетевого экранирования прикладного уровня путем фрагментации данных, смешивания параметров, замены алгоритма кодирования и формата представления данных, замены специальных символов их альтернативными представлениями.
При проведении оценки защищенности специализированных банковских приложений (специализированного ПО) финансовых организаций рекомендуются следующие мероприятия:
а) прослушивание сетевого трафика и поиск в нем защищаемой информации, включая пароли и хеш-значения паролей пользователей, идентификаторы сессий, авторизационные маркеры, криптографические ключи;
б) запуск программ с различными параметрами, в том числе нестандартными, в том числе с использованием значений различной длины, дублирование отдельных параметров с присвоением им разных значений, включение в значения параметров специальных символов, команд операционной системы, операторов интерпретируемых языков программирования;
в) мониторинг характера взаимодействия приложения с операционной системой в процессе функционирования, включая идентификацию файлов данных, содержащих защищаемую информацию, трассировку системных вызовов;
г) проверка прав доступа к файлам данных, содержащим защищаемую информацию, а также контроль целостности исполняемых файлов приложения.
Пример 3
Хранение данных в файле лога
Стингрей нашел логин и пароль прямо в log-файле. Можно догадаться, зачем это разработчикам, но в релизе такого быть не должно. Данную проблему безопасности для банковского приложения можно классифицировать как »уязвимость, связанную с наличием защищаемой информации в сообщениях об ошибках».
Пример 4
Проблема межпроцессного взаимодействия (Intent Redirection)
В этом примере Стингрей выявил критическую уязвимость межпроцессного взаимодействия приложения. Это значит, что любое ПО может вызвать внутренний сервис программы, отправив в нее сформированный запрос (Intent). Однако классифицировать ИБ-проблему по ПЗ затруднительно. Исследователь обязан сообщить о ней клиенту, а для ее включения в отчет нужно будет «допилить» категорию из Профиля защиты.
Пример 5
Персональные данные в открытом виде
Здесь мы обнаружили приватную информацию в одном из файлов приложения. Это явный ИБ-недостаток приложения, который мы отнесем к типу »уязвимость, связанная с хранением персональных данных в открытом виде». При этом, если детально изучить российские законы в отношении содержания и обработки ПД, становится понятно, что мобильные приложения точно попадают под их условия. Я думаю, мы еще напишем об этом отдельную статью, но уже сейчас ясно, что хранение персональных данных в открытом виде на устройстве запрещено на государственном уровне. Это может привести к прямым финансовым и репутационным потерям.
Анализ в процессном пути оценки соответствия
Что касается исполнения условий раздела 7.4 ПЗ, определяющего требования к гибкой безопасной разработке и тестированию, тут ситуация похожая — отличается перечень необходимой документации:
Перечень документации
Но зато в п.7.4.3.8 ПЗ прописано, что кроме своих экспертов по безопасности кода у организации должны быть Инструментальные средства для тестирования безопасности. Это понятно — нужен максимальный уровень автоматизации. Конечно, в этом случае специалисту понадобятся динамические анализаторы, фаззеры, инструменты интеграционного тестирования и многое другое. Именно таким сервисом, который объединяет в себе все перечисленные практики, является платформа Стингрей.
Что еще?
Кроме прочего, мы можем упростить себе жизнь, сократив ресурсоемкую и специфическую работу по определению найденных уязвимостей, слабостей и прочих дыр в безопасности. Речь идет об идентификации типов недостатков потенциальных ИБ-угроз на шагах AVA_VAN.X-4 и AVA_VAN.X-5 (пункты 14.2.3.6.1 и 14.2.3.6.2 ГОСТ Р ИСО/МЭК 18045–2013).
Перечень CWE для тестирования
Для этого просто переписываем то, что предлагает Стингрей для всех типов выявляемых уязвимостей, — уже найденные в рамках аудита проблемы безопасности с мировой классификацией слабостей CWE:
Маппинг CWE на обнаруживаемые уязвимости
Резюме
Несмотря на упоминание мобильных продуктов в тексте Профиля защиты, само описание угроз, векторов атак и необходимости применения ИБ-практик всё еще достаточно слабо продумано, многое приходится «притягивать за уши». Очень хочется, чтобы мобильные приложения рассматривались как часть системы и имели четкие требования безопасности. И главное, это должно быть не рекомендательным, а обязательным условием, поскольку «мобилки» являются основой для многих компаний и имеют огромную аудиторию. А пока мы действуем вслепую и применяем практики тестирования защищенности приложений без конкретных указаний регулятора. Но это уже намного лучше, чем было до выхода ПЗ. Начало положено, мобильные приложения попадают в перечень проверяемых подсистем — и это уже очень большой шаг в обеспечении их безопасности.
Примеры в статье и наше ежегодное исследование показывают, что сегодня уровень безопасности в разработке мобильных программ финансовой сферы равен эффективности используемых при этом средств по анализу защищенности. Это мало зависит от того, идете ли вы по продуктовому или по процессному пути оценки соответствия.
Ситуация с безопасностью на рынке усугубляется тем, что многие приложения для iPhone удалены из магазинов Apple, и для того, чтобы дать возможность своим пользователям продолжать работу с сервисом, компаниям приходится очень быстро выпускать другие продукты. Они меняют «вылизанные», проверенные десятками пентестов приложения на полностью новые разработки без детальной проверки. А что за ними кроется и насколько они безопасны, решается и проверяется, как правило, уже после публикации, так как время релиза играет огромное значение.
Сейчас большая часть иностранных эффективных средств оказалась недоступна для использования, но есть на отечественном рынке и свои эффективные инструменты для обеспечения безопасности продуктов. Так что, если вы хотите провести аудит защищенности своего мобильного приложения или подтвердить соответствие разработки требованиям Профиля защиты, мы всегда рады помочь!
