По поводу Фриды. Один из сценариев атаки - это встраивание библиотек фриды в приложение. Декомпилировать приложение для этого не нужно. Либу можно встроить на уровне байткода. Там есть заморочки с поиском точек входа в smali коде, но при наличии продвинутой LLM решить эту задачу можно решить в рамках 20-ти долларовой подписки. Короче, мы тоже прифигели, с того, что может Фрида и как нетривиально её детектировать )
Понял, на устройстве может быть только один админ, который доставляет KSP настройки. Но мучает любопытство, как же KSP их применяет? Он же не Device Owner, да и лицензию Knox уже мог MDM активировать.
@pavelmedvedev79 подскажи, как устроено взаимодействие MDM с KSP с точки зрения кибербезы. Интересны два аспекта:
По идее на устройстве может быть только одно приложение "владелец устройства" (в терминах Android Enterprise) и только одно приложение может активировать Knox лицензию. Как KSP применяет политики, если все права уже у MDM?
Если KSP может применять политики, как организована защита, чтобы он не начал "служить двум хозяевам"? Может ли другое приложение на устройстве отменить политики KSP, которые применил MDM? Какая есть защита от инжекта? Например, продвинутый мобильный апсек возьмёт Frida и захочет с помощью инжекта отключить в рантайме проверку, что политики поступают только от MDM - как от этого защититься?
Немного разверну поинт про коллизии MDM с OEMConfig.
Допустим, админ решил запретить на устройстве камеру с помощью MDM политик через Android Enteprise. Второй админ в дополнение к этому создал OEMConfig с запретом камеры через Knox. Когда речь про запрет+запрет коллизий не возникает. Но какое будет состояние устройства, если один из админов решит разрешить камеру - вопрос. Причём ответ может зависеть от того, какой запрет снимается - первый или второй.
Можно развить идею дальше. Админ докинул две Wi-Fi сети с помощью Android Enteprise и ещё две через OEMConfig. Причём одна из сетей в OEMConfig совпадает с Android Enteprise. Внимание вопрос - сможет ли пользователь подключиться к этой сети, если удалить OEMConfig? А если на устройство отправят enterprise wipe, будут ли стёрты клиентские сертификаты для аутентификации в Wi-Fi сетях, которые пришли на устройство в OEMConfig?
Кейсы с админами, действия которых противоречат или повторяют друг друга, могут показаться вырожденными. Поверьте, это не так. При наличии 3-5 админов на третьей линии поддержки такие ситуации случаются нередко. А если L2 поддержки дают права в MDM, пусть и ограниченные, вероятность таких ситуаций начинает стремиться к 1 😁
Знаю, что OEMConfig есть у Nokia, Zebra и M3 Mobile. Напромтил, что ещё у ряда ТСД есть типа Honeywell, DataLogic и Bluebird. В ТСД такой конфиг обычно используют, чтобы настроить разные аппаратные вещи типа сканера и т.д.
Согласен. Конкретного ответа на этот вопрос нет. Но если мы рассматриваем граждан как конечных бенефициаров от ИБ портала госуслуг, то можно в первом приближении считать, что требования по защите ГИС не меньше (а на самом деле почти эквивалентны) требованиям по защите ИСПДн, которой гослуслуги и nalog.ru точно являются.
Нужен, если технически реализуем (на iOS нет), и есть риск появления вредоносных файлов или ПО (например, у некоторого бортового ПО такого риска нет, как и потребности ставить антивирус).
Начиная от решения сделать условный ГОСТ до того, как его напишут, согласуют и примут как рекомендации, уходит 1-3 года. Даже если в течение этих 1-3 лет времени тратится меньше, чем хотелось бы.
Если применять все ГОСТ, систему в пром никогда не сдать, потому что их Очень много. С другой стороны, процесс сертификации ПО во ФСТЭК сейчас таков, что проще реализовать требования ГОСТ по безопасной разработке, чем не реализовать.
Хотелось бы к этому стремиться, но есть несколько препятствий:
Всестороннее обсуждение приводит к тому, что эксперт каждого производителя будет пытаться перетянуть одеяло на себя. Просто бизнес, ничего личного. Это приводит к затягиванию процесса разработки и согласования документа.
Документ выйдет устаревшим. Даже если все эксперты будут белыми и пушистыми, разработка и согласование нормативного документа федерального уровня займёт два-три года. За это время часть технологий устареют.
Было бы здорово иметь публичные "лучшие практики", которые сообщество экспертов самостоятельно актуализирует, но заставить следовать им участников рынка будет непросто.
На уровне российских или московских гослуг или крупных банковских систем следование лучшим практикам проще траснформировать в деньги на компенсацию убытков. В конце концов, ИБ может быть атрибутом престижа.
Но в каком-нибудь далёком уезде к ИБ относятся как к налогам: "если их можно не платить, их нужно не платить". В этом случае рекомендации не работают. Только требования.
Предлагаю вернуться к исходному вопросу. "Если ГИС, то нужно 1, 2, 3." Если не вдаваться в степень детализации требований, для ИСПДн нужны те же самые 1, 2 и 3. Отличие только в том, что эти "1, 2, 3" нужно подтвердить до ввода в ГИС в пром.
Иногда требования закрывают оргмерами типа деда с берданкой, наличия СКУД или жалюзи на окнах (чтобы супостат не подглядел лишнего через окно).
Обоснованность применения оргмер при проверке или аттестации ещё нужно обосновать. Например, на iOS нельзя написать антивирус. В принципе нельзя. Поэтому риски ИБ нужно закрывать иначе. Например, запретив пользователю устанавливать приложения не из App Store - организационно или технически.
За вашу статью и работу, которую проделали до её написания - спасибо. Надеюсь, что владельцы ИС, которые вы проверили, с ней ознакомились и запланировали доработки.
С сайтом сложно, потому что тот же mos.ru даёт пользователю доступ к десятку разных ГИСов. Возможно, среди сервисов mos.ru есть и неГИСы.
В определении ГИС или неГИС есть определённый бардак, но предлагаю взглянуть на проблему под другим углом.
Меня, как гражданина, больше заботят не данные госоргана, а мои собственные персональные данные. Их госорган обязан защищать, руководствуясь требованиями 21 приказа ФСТЭК.
Если сравнить требования 17 и 21 приказа ФСТЭК, то они во многом совпадают с точностью до названия систем (ГИС или ИСПДн). Поэтому портал госуслуг должен защищать данные граждан не хуже, чем коммерческий банк, даже если бы портал госуслуг не был бы ГИС.
Разница между защитой ПДн и ГИС в том, что защищать ПДн можно без аттестации. То есть нет проверяющего с дубиной перед запуском в пром, но, если будет утечка, наказания не миновать.
Объективно за свои данные на mos.ru мне страшно меньше, чем в какой-то noname-анкете, где дети могут узнать, на какого персонажа мультфильма они больше похожи. Понимаю, что сравнение гиперболизировано. Но такие сервисы, как mos.ru или nalog.ru, находящиеся на виду и имеющие тысячи пользователей и за ними сотни разработчиков, айтишников и ибэшников, кажутся достаточно безопасным местом вне зависимости от их отнесения к ГИС.
Не знаю, как это выглядит со стороны госорганов, которые разрабатывают ИС. Обычно сталкивался с ГИС, когда заказчик уже уверен, что она ГИС :)
Для владельца ИС есть pro и contra отнесения к ГИС. Pro - если ошибочно не отнести систему к ГИС, можно получить штраф или не ввести ИС в пром в срок. Contra - ГИС не ввести в пром без аттестации по требованиям безопасности, а это затраты времени и денег.
Поскольку реестр ГИС ведёт Минцифра, на месте госоргана, который не понимает ГИС у него или неГИС, я бы отправил оф.запрос в Минцифру...
Разделение ИТ и ИБ - это best practive. Как и разделение разработчиков и тестировщиков или как разделение менеджеров и юристов. Желательно, чтобы эти роли выполняли разные люди. Но когда людей мало, они начинают исполнять несколько ролей одновременно.
Формально эта проблема прикрывается внутренним приказом или тем, что сотрудника берут на несколько ставок одновременно. Админ ИТ по совместительству подрабатывает админом ИБ.
Это повсеместно создаёт конфликты интересов. С точки зрения ИТ нужно действовать быстро, а с точки зрения ИБ безопасно. Это редко одно и то же. Поэтому и вымышленному герою статьи приходится иногда бить себя по рукам :)
Портал госулуг есть в реестре федеральных ГИС (ФГИС): https://portal.eskigov.ru/fgis/237. Надеюсь, что информацию о технологиях просто не обновили и сейчас там не mySQL, Alt Linux 5 и Windows XP.
В том же реестре ФГИС можно найти налоговую систему: https://portal.eskigov.ru/fgis/303. Вопросы по технике те же. Ещё вопрос как АИС "Налог 3" соотносится с nalog.ru. Скорее всего, nalog.ru - это витрина для сервисов "Налог 3". При этом часть сервисов на nalog.ru могут не являться ГИС. Например, новостной портал.
Ключевое - macOS Server подходит, если устройств несколько десятков. Если устройств больше 50, нужно другое решение. Плюс мало компаний ограничиваются только техникой Apple. В этом случае macOS Server тоже не подойдёт.
С точки зрения числа устройств ситуация в чём-то похожа на AD. Если в компании всего 10-20 персоналок на Windows, она не всегда будет использовать AD. Чем больше устройств, тем нужнее AD.
Если устройства только Apple и их несколько десятков, можно поставить на один из Маков macOS Server и управлять устройствами с его помощью. На сегодняшний день этот софт в Mac App Store стоит 1790 руб. Нужна 1 шт.
Если кроме техники Apple есть Андроиды или устройств Apple от сотни, нужна система управления мобильностью. Одну из таких систем производим мы. У SafePhone есть разные виды лицензий. Для простоты можно ориентироваться на 2000 руб. на 1 устройство в год.
Про нюансы, с которыми сталкиваются компании при внедрении управления устройствами Apple, можно почитать в одной из наших прошлых статей.
Относительно порядка внедрения он скорее всего будет выглядеть так:
Отсупервайзить корпоративные устройства. Отсупервайзить = перепрошить для корпоративного использования. Можно обойтись без этого, но тогда будет доступно меньше политик и установка приложений будет требовать подтверждения пользователя. Руководители этого не любят. Для супервайза нужен Мак. По времени можно ориентироваться на 0,5-1 час для каждого устройства. Устройства можно супервайзить параллельно.
Развернуть сервер управления. Нужна одна или несколько VM в зависимости от числа клиентских устройств. Плюс "белые" порты. Технически решается за несколько дней. Может затянуться, если согласование VM или портов требует кучи подписей и бумаг.
Подключить устройства к серверу. Могут делать пользователи. Если пользователи подключаются по доменным учёткам, им достаточно сообщить адрес сервера. Обычно хватает почтовой рассылки.
Хотелось бы верить, но есть сомнения. В докладе WWDC сказано, что команда MDM работает, если для устройства доступно И мажорное, И минорное обновление. Нужно проверять, что будет, если доступно только мажорное обновление. Условно для iPhone доступен iOS 15, но iOS 14.что-то-там для него нет. Может оказаться так, что в этом случае нужно по-старинке подсовывать профиль для Apple TV.
Документация Apple в этой части удивительно лаконична. Нужна политика принимает три возможных значения - 0, 1 и 2. Чтобы узнать, что такое 0, 1 и 2, видимо, нужно смотреть доклад на WWDC...
Скорее всего речь про приложение BlackBerry Work для iOS, а не про BlackBerry OS :)
Разработчик iOS приложения может запретить передавать данные в другие приложения из буфера обмена. Если не ошибаюсь, это одна из базовых функций UIPasteboard. Если разработчик об этом подумал, то всё будет тип-топ.
Если же в приложении эта функция не реализована, могли быть нюансы. Например, на устройство добавили корпоративный Exchange аккаунт и пользователь юзает Apple Mail. Политики запрещают передавать файл из почтового вложения в воцап, но скопировать и вставить туда его текст можно было без проблем.
Теперь запрет несанкционированной копипасты управляется на уровне ОС и не зависит от того, какие приложения вы используете.
По поводу Фриды. Один из сценариев атаки - это встраивание библиотек фриды в приложение. Декомпилировать приложение для этого не нужно. Либу можно встроить на уровне байткода. Там есть заморочки с поиском точек входа в smali коде, но при наличии продвинутой LLM решить эту задачу можно решить в рамках 20-ти долларовой подписки. Короче, мы тоже прифигели, с того, что может Фрида и как нетривиально её детектировать )
Понял, на устройстве может быть только один админ, который доставляет KSP настройки. Но мучает любопытство, как же KSP их применяет? Он же не Device Owner, да и лицензию Knox уже мог MDM активировать.
@pavelmedvedev79 подскажи, как устроено взаимодействие MDM с KSP с точки зрения кибербезы. Интересны два аспекта:
По идее на устройстве может быть только одно приложение "владелец устройства" (в терминах Android Enterprise) и только одно приложение может активировать Knox лицензию. Как KSP применяет политики, если все права уже у MDM?
Если KSP может применять политики, как организована защита, чтобы он не начал "служить двум хозяевам"? Может ли другое приложение на устройстве отменить политики KSP, которые применил MDM? Какая есть защита от инжекта? Например, продвинутый мобильный апсек возьмёт Frida и захочет с помощью инжекта отключить в рантайме проверку, что политики поступают только от MDM - как от этого защититься?
Немного разверну поинт про коллизии MDM с OEMConfig.
Допустим, админ решил запретить на устройстве камеру с помощью MDM политик через Android Enteprise. Второй админ в дополнение к этому создал OEMConfig с запретом камеры через Knox. Когда речь про запрет+запрет коллизий не возникает. Но какое будет состояние устройства, если один из админов решит разрешить камеру - вопрос. Причём ответ может зависеть от того, какой запрет снимается - первый или второй.
Можно развить идею дальше. Админ докинул две Wi-Fi сети с помощью Android Enteprise и ещё две через OEMConfig. Причём одна из сетей в OEMConfig совпадает с Android Enteprise. Внимание вопрос - сможет ли пользователь подключиться к этой сети, если удалить OEMConfig? А если на устройство отправят enterprise wipe, будут ли стёрты клиентские сертификаты для аутентификации в Wi-Fi сетях, которые пришли на устройство в OEMConfig?
Кейсы с админами, действия которых противоречат или повторяют друг друга, могут показаться вырожденными. Поверьте, это не так. При наличии 3-5 админов на третьей линии поддержки такие ситуации случаются нередко. А если L2 поддержки дают права в MDM, пусть и ограниченные, вероятность таких ситуаций начинает стремиться к 1 😁
Знаю, что OEMConfig есть у Nokia, Zebra и M3 Mobile. Напромтил, что ещё у ряда ТСД есть типа Honeywell, DataLogic и Bluebird. В ТСД такой конфиг обычно используют, чтобы настроить разные аппаратные вещи типа сканера и т.д.
Согласен. Конкретного ответа на этот вопрос нет. Но если мы рассматриваем граждан как конечных бенефициаров от ИБ портала госуслуг, то можно в первом приближении считать, что требования по защите ГИС не меньше (а на самом деле почти эквивалентны) требованиям по защите ИСПДн, которой гослуслуги и nalog.ru точно являются.
Нужен, если технически реализуем (на iOS нет), и есть риск появления вредоносных файлов или ПО (например, у некоторого бортового ПО такого риска нет, как и потребности ставить антивирус).
Начиная от решения сделать условный ГОСТ до того, как его напишут, согласуют и примут как рекомендации, уходит 1-3 года. Даже если в течение этих 1-3 лет времени тратится меньше, чем хотелось бы.
Если применять все ГОСТ, систему в пром никогда не сдать, потому что их Очень много. С другой стороны, процесс сертификации ПО во ФСТЭК сейчас таков, что проще реализовать требования ГОСТ по безопасной разработке, чем не реализовать.
На странице https://fstec.ru/tekhnicheskaya-zashchita-informatsii/dokumenty/114-spetsialnye-normativnye-dokumenty/805-metodicheskij-dokument нужно нажать на "Методический документ" слева сверху.
У меня так скачивается.
Хотелось бы к этому стремиться, но есть несколько препятствий:
Всестороннее обсуждение приводит к тому, что эксперт каждого производителя будет пытаться перетянуть одеяло на себя. Просто бизнес, ничего личного. Это приводит к затягиванию процесса разработки и согласования документа.
Документ выйдет устаревшим. Даже если все эксперты будут белыми и пушистыми, разработка и согласование нормативного документа федерального уровня займёт два-три года. За это время часть технологий устареют.
Было бы здорово иметь публичные "лучшие практики", которые сообщество экспертов самостоятельно актуализирует, но заставить следовать им участников рынка будет непросто.
На уровне российских или московских гослуг или крупных банковских систем следование лучшим практикам проще траснформировать в деньги на компенсацию убытков. В конце концов, ИБ может быть атрибутом престижа.
Но в каком-нибудь далёком уезде к ИБ относятся как к налогам: "если их можно не платить, их нужно не платить". В этом случае рекомендации не работают. Только требования.
Более конкретно требования к реализации мер прописаны в методических рекомендациях: https://fstec.ru/tekhnicheskaya-zashchita-informatsii/dokumenty/114-spetsialnye-normativnye-dokumenty/805-metodicheskij-dokument
Здесь тоже есть не вся конкретика. Но уровень детализации заметно выше, чем у 17 приказа.
Поскольку требования 17 и 21 приказов во многом схожи, можно при защите ИСПДн использовать эти же рекомендации.
Предлагаю вернуться к исходному вопросу. "Если ГИС, то нужно 1, 2, 3." Если не вдаваться в степень детализации требований, для ИСПДн нужны те же самые 1, 2 и 3. Отличие только в том, что эти "1, 2, 3" нужно подтвердить до ввода в ГИС в пром.
Иногда требования закрывают оргмерами типа деда с берданкой, наличия СКУД или жалюзи на окнах (чтобы супостат не подглядел лишнего через окно).
Обоснованность применения оргмер при проверке или аттестации ещё нужно обосновать. Например, на iOS нельзя написать антивирус. В принципе нельзя. Поэтому риски ИБ нужно закрывать иначе. Например, запретив пользователю устанавливать приложения не из App Store - организационно или технически.
За вашу статью и работу, которую проделали до её написания - спасибо. Надеюсь, что владельцы ИС, которые вы проверили, с ней ознакомились и запланировали доработки.
Может быть это я мало читаю (: Дайте ссылочку, пожалуйста.
С сайтом сложно, потому что тот же mos.ru даёт пользователю доступ к десятку разных ГИСов. Возможно, среди сервисов mos.ru есть и неГИСы.
В определении ГИС или неГИС есть определённый бардак, но предлагаю взглянуть на проблему под другим углом.
Меня, как гражданина, больше заботят не данные госоргана, а мои собственные персональные данные. Их госорган обязан защищать, руководствуясь требованиями 21 приказа ФСТЭК.
Если сравнить требования 17 и 21 приказа ФСТЭК, то они во многом совпадают с точностью до названия систем (ГИС или ИСПДн). Поэтому портал госуслуг должен защищать данные граждан не хуже, чем коммерческий банк, даже если бы портал госуслуг не был бы ГИС.
Разница между защитой ПДн и ГИС в том, что защищать ПДн можно без аттестации. То есть нет проверяющего с дубиной перед запуском в пром, но, если будет утечка, наказания не миновать.
Объективно за свои данные на mos.ru мне страшно меньше, чем в какой-то noname-анкете, где дети могут узнать, на какого персонажа мультфильма они больше похожи. Понимаю, что сравнение гиперболизировано. Но такие сервисы, как mos.ru или nalog.ru, находящиеся на виду и имеющие тысячи пользователей и за ними сотни разработчиков, айтишников и ибэшников, кажутся достаточно безопасным местом вне зависимости от их отнесения к ГИС.
Пардон за многабукафф ))
Не знаю, как это выглядит со стороны госорганов, которые разрабатывают ИС. Обычно сталкивался с ГИС, когда заказчик уже уверен, что она ГИС :)
Для владельца ИС есть pro и contra отнесения к ГИС. Pro - если ошибочно не отнести систему к ГИС, можно получить штраф или не ввести ИС в пром в срок. Contra - ГИС не ввести в пром без аттестации по требованиям безопасности, а это затраты времени и денег.
Поскольку реестр ГИС ведёт Минцифра, на месте госоргана, который не понимает ГИС у него или неГИС, я бы отправил оф.запрос в Минцифру...
Разделение ИТ и ИБ - это best practive. Как и разделение разработчиков и тестировщиков или как разделение менеджеров и юристов. Желательно, чтобы эти роли выполняли разные люди. Но когда людей мало, они начинают исполнять несколько ролей одновременно.
Формально эта проблема прикрывается внутренним приказом или тем, что сотрудника берут на несколько ставок одновременно. Админ ИТ по совместительству подрабатывает админом ИБ.
Это повсеместно создаёт конфликты интересов. С точки зрения ИТ нужно действовать быстро, а с точки зрения ИБ безопасно. Это редко одно и то же. Поэтому и вымышленному герою статьи приходится иногда бить себя по рукам :)
Портал госулуг есть в реестре федеральных ГИС (ФГИС): https://portal.eskigov.ru/fgis/237. Надеюсь, что информацию о технологиях просто не обновили и сейчас там не mySQL, Alt Linux 5 и Windows XP.
В том же реестре ФГИС можно найти налоговую систему: https://portal.eskigov.ru/fgis/303. Вопросы по технике те же. Ещё вопрос как АИС "Налог 3" соотносится с nalog.ru. Скорее всего, nalog.ru - это витрина для сервисов "Налог 3". При этом часть сервисов на nalog.ru могут не являться ГИС. Например, новостной портал.
Приказ о вводе в промэксплуатацию московского портала госуслуг есть на самом mos.ru: https://www.mos.ru/kgu/anticorruption/nezavisimaia-antikorruptcionnaia-ekspertiza/view/76863220/
В целом, вопрос ГИС это или неГИС нетривиальный и 149-ФЗ не даёт на него однозначного ответа. Об этом писали в т.ч. на Хабре: https://habr.com/ru/post/458732/. Наиболее понятный ответ для меня дал Контур: https://kontur.ru/articles/1609. Статья Контура от 2015 года. С тех пор реестр ФГИС отдали Минцифре. Сейчас он доступен по ссылке: https://portal.eskigov.ru/fgis/
Согласен, подозрительно дёшево.
Ключевое - macOS Server подходит, если устройств несколько десятков. Если устройств больше 50, нужно другое решение. Плюс мало компаний ограничиваются только техникой Apple. В этом случае macOS Server тоже не подойдёт.
С точки зрения числа устройств ситуация в чём-то похожа на AD. Если в компании всего 10-20 персоналок на Windows, она не всегда будет использовать AD. Чем больше устройств, тем нужнее AD.
Если устройства только Apple и их несколько десятков, можно поставить на один из Маков macOS Server и управлять устройствами с его помощью. На сегодняшний день этот софт в Mac App Store стоит 1790 руб. Нужна 1 шт.
Если кроме техники Apple есть Андроиды или устройств Apple от сотни, нужна система управления мобильностью. Одну из таких систем производим мы. У SafePhone есть разные виды лицензий. Для простоты можно ориентироваться на 2000 руб. на 1 устройство в год.
Про нюансы, с которыми сталкиваются компании при внедрении управления устройствами Apple, можно почитать в одной из наших прошлых статей.
Относительно порядка внедрения он скорее всего будет выглядеть так:
Отсупервайзить корпоративные устройства. Отсупервайзить = перепрошить для корпоративного использования. Можно обойтись без этого, но тогда будет доступно меньше политик и установка приложений будет требовать подтверждения пользователя. Руководители этого не любят. Для супервайза нужен Мак. По времени можно ориентироваться на 0,5-1 час для каждого устройства. Устройства можно супервайзить параллельно.
Развернуть сервер управления. Нужна одна или несколько VM в зависимости от числа клиентских устройств. Плюс "белые" порты. Технически решается за несколько дней. Может затянуться, если согласование VM или портов требует кучи подписей и бумаг.
Подключить устройства к серверу. Могут делать пользователи. Если пользователи подключаются по доменным учёткам, им достаточно сообщить адрес сервера. Обычно хватает почтовой рассылки.
Хотелось бы верить, но есть сомнения. В докладе WWDC сказано, что команда MDM работает, если для устройства доступно И мажорное, И минорное обновление. Нужно проверять, что будет, если доступно только мажорное обновление. Условно для iPhone доступен iOS 15, но iOS 14.что-то-там для него нет. Может оказаться так, что в этом случае нужно по-старинке подсовывать профиль для Apple TV.
Документация Apple в этой части удивительно лаконична. Нужна политика принимает три возможных значения - 0, 1 и 2. Чтобы узнать, что такое 0, 1 и 2, видимо, нужно смотреть доклад на WWDC...
Скорее всего речь про приложение BlackBerry Work для iOS, а не про BlackBerry OS :)
Разработчик iOS приложения может запретить передавать данные в другие приложения из буфера обмена. Если не ошибаюсь, это одна из базовых функций UIPasteboard. Если разработчик об этом подумал, то всё будет тип-топ.
Если же в приложении эта функция не реализована, могли быть нюансы. Например, на устройство добавили корпоративный Exchange аккаунт и пользователь юзает Apple Mail. Политики запрещают передавать файл из почтового вложения в воцап, но скопировать и вставить туда его текст можно было без проблем.
Теперь запрет несанкционированной копипасты управляется на уровне ОС и не зависит от того, какие приложения вы используете.