Там же в статье CNews рассмотрен риск, который мы упустили в статье. Если я разработчик, скажем, из Кубы, и мне не дали пройти верификацию, моё приложение можно будет распространять на Кубе, но в странах, где работает верификация - нельзя.
Там этот кейс рассмотрен на примере RuStore. Если он не пройдёт верификацию, то, например, в ЕС или СНГ пользоваться им станет сложно - нужно будет включить расширенный режим. То же самое касается других потенциально подсканционных приложений - клиенты банков, Госуслуги, клиент горячо любимого мессенджера Макс.
Правда в оригинальной статье под санкциями всё же не вся Россия, а только новые регионы. Но позиция Google, как и позиция США, чьи санционные списки они чтят, по этому вопросу может и измениться.
Вчера на CNews вышла заметка по теме. Пишут, что Google может перекрыть верификацию разработчиков из подсанкционных стран. Поэтому налетай-торопись, пока вентиль не перекрыли.
По поводу Фриды. Один из сценариев атаки - это встраивание библиотек фриды в приложение. Декомпилировать приложение для этого не нужно. Либу можно встроить на уровне байткода. Там есть заморочки с поиском точек входа в 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.
Там же в статье CNews рассмотрен риск, который мы упустили в статье. Если я разработчик, скажем, из Кубы, и мне не дали пройти верификацию, моё приложение можно будет распространять на Кубе, но в странах, где работает верификация - нельзя.
Там этот кейс рассмотрен на примере RuStore. Если он не пройдёт верификацию, то, например, в ЕС или СНГ пользоваться им станет сложно - нужно будет включить расширенный режим. То же самое касается других потенциально подсканционных приложений - клиенты банков, Госуслуги, клиент горячо любимого мессенджера Макс.
Правда в оригинальной статье под санкциями всё же не вся Россия, а только новые регионы. Но позиция Google, как и позиция США, чьи санционные списки они чтят, по этому вопросу может и измениться.
Вчера на CNews вышла заметка по теме. Пишут, что Google может перекрыть верификацию разработчиков из подсанкционных стран. Поэтому налетай-торопись, пока вентиль не перекрыли.
По поводу Фриды. Один из сценариев атаки - это встраивание библиотек фриды в приложение. Декомпилировать приложение для этого не нужно. Либу можно встроить на уровне байткода. Там есть заморочки с поиском точек входа в 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.