Как разработать мобильное приложение Fintech, совместимое с PCI DSS?

Опубликовано: 2019-10-29

Независимо от того, является ли ваше приложение полноценным финтех-приложением, таким как PayPal, или приложением для потоковой передачи мультимедиа, таким как Netflix , которое просит пользователей платить за подписку в приложении, есть одна вещь, которую вы не можете позволить себе упустить — соответствие PCI DSS.

Несоблюдение стандартов безопасности PCI, которые приводят к утечке данных, может привести к разрушительным финансовым последствиям, таким как сборы, штрафы и даже потеря бизнеса. В этой статье описаны все основы соответствия требованиям PCI для финтех-приложений, которые помогут двигаться в правильном направлении развития.

Вот что повлечет за собой наше руководство по безопасности приема мобильных платежей PCI:

  1. Что такое PCI DSS?
  2. Объем требований соответствия PCI
  3. Зачем уделять внимание соответствию стандарту PCI DSS?
  4. Как поддерживать соответствие PCI?
  5. Создание плана для постоянного соблюдения
  6. Вывод
  7. Часто задаваемые вопросы о разработке мобильных приложений Fintech, совместимой с PCI DSS

Что такое PCI DSS?

Payment Devices Ecosystem

Стандарт безопасности данных индустрии платежных карт PCI (PCI DSS) — это строго предписывающий технический стандарт, направленный на защиту сведений о кредитных и дебетовых картах, называемых в отрасли «данными о держателях карт». Целью PCI DSS является предотвращение мошенничества с платежными картами за счет защиты данных держателей карт внутри организаций, принимающих платежи по картам.

Соответствие PCI сосредоточено вокруг услуг информационных технологий. Руководящие ИТ-специалисты, назначенные с целью обеспечения соответствия внутри организаций, должны обладать необходимым опытом и знаниями в области разработки программного обеспечения, чтобы гарантировать , что процесс разработки мобильных приложений, отвечающих требованиям PCI, соответствует контрольному списку требований PCI DSS.

Определив, что такое PCI DSS, давайте рассмотрим конкретные требования к разработке PCI для финтех-приложений.

Объем требований соответствия PCI

Большинство требований PCI DSS, влияющих на процесс разработки финтех-приложений, подпадают под требования 3, 4 и 6. Эти требования охватывают хранение данных держателей карт, методы шифрования, контроль доступа и сетевую безопасность. Давайте рассмотрим все три из них по отдельности, чтобы получить полное представление о руководстве по охвату PCI.

Требование разработки PCI 3: защита хранимых данных о держателях карт

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

Как правило, данные держателей карт не должны храниться до тех пор, пока это не станет абсолютно необходимым для удовлетворения деловых потребностей. Конфиденциальные данные, упомянутые на магнитной полосе, никогда не должны храниться, и в случае, если вам придется хранить данные PAN, их следует сделать нечитаемыми. Вот некоторые другие вещи, которые следует учитывать в контрольном списке соответствия PCI при рассмотрении требования 3.

3.1

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

3.2

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

3.3

PAN должен быть замаскирован при отображении. Вы должны отображать только первые шесть или последние четыре цифры.

3.4

PAN следует сделать нечитаемым, где бы он ни хранился, включая цифровые носители, журналы, резервные носители и данные, полученные из беспроводных сетей. Технологические решения, которые мы предлагаем для этой точки в Appinventiv, включают надежную одностороннюю хеш-функцию полного PAN, надежную криптографию, токен индекса с высокозащищенными хранимыми блокнотами и т. д.

3,5

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

3,6

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

Требование разработки PCI 4: Шифровать передачу данных держателей карт через общедоступные открытые сети.

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

4.1

Компании-разработчики приложений должны использовать надежные протоколы безопасности и криптографию, такие как TLS/ SSL Pinning в приложениях для iOS и решения для Android, защищающие конфиденциальные данные держателей карт во время их передачи по общедоступной сети.

4.2

Незащищенные PAN никогда не должны отправляться технологиями обмена сообщениями конечных пользователей.

Требование разработки PCI 6: разработка и поддержка безопасных приложений

Требования PCI к финтех-приложениям касаются разработки внешних и внутренних приложений, которые считаются находящимися в рамках соответствия мобильным приложениям PCI DSS — это относится к каждому разработанному приложению, которое обрабатывает, хранит и передает данные держателей карт.

Платежные приложения PCI, которые создаются компаниями- разработчиками Fintech для использования внешними организациями, должны соответствовать Стандарту безопасности данных платежных приложений (PA-DSS) и должны оцениваться PA-QSA.

6.1

Соответствие требованию 6.1 требует наличия должным образом документированного реестра программных активов библиотек и инструментов, которые используются в цикле разработки программного обеспечения. Каждый элемент реестра программных активов должен включать:

  • Номер версии
  • Как и где используется программное обеспечение
  • Четкое объяснение функции, которую они обеспечивают.

Поскольку программные библиотеки и инструменты часто обновляются, крайне важно, чтобы реестр постоянно пересматривался и обновлялся.

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

Требование 6.1 также требует ранжирования риска, которое должно быть присвоено каждой уязвимости, идентифицированной в элементах реестра активов. Уязвимости должны быть оценены с точки зрения риска и должны быть помечены меткой оценки риска, которая называется «Критический», «Высокий», «Средний» или «Низкий». Эти уровни риска затем помогут определить приоритетность исправлений.

6.2

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

Исправления уязвимостей, которые оцениваются как низкие, должны применяться в течение 2-3 месяцев после выпуска.

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

6.3

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

Документ по разработке платежного приложения PCI должен быть достаточно описательным, чтобы охватывать части того, как приложение обрабатывает, передает и хранит данные о держателях карт. Чтобы достичь соответствия 6.3, цель должна состоять в том, чтобы сделать документацию достаточно описательной, чтобы даже сторонние разработчики могли ее понять.

Чтобы убедиться, что разработчики придерживаются жизненного цикла разработки, завершение каждого этапа разработки должно быть задокументировано, а аудиты процесса разработки должны проводиться регулярно.

  • 6.3.1: Учетные записи тестовых или настраиваемых приложений, пароли и идентификаторы пользователей должны быть удалены до того, как приложения будут выпущены для конечных пользователей.
  • 6.3.2: Пользовательские коды должны быть проверены перед выпуском, чтобы выявить уязвимости кодирования, если таковые имеются.

6.4

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

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

6,5

Требуется, чтобы компания- разработчик программного обеспечения Fintech и разработчики финансовых приложений прошли обучение методам безопасного кодирования, которые соответствуют языкам кодирования приложения. Методы кодирования должны быть основаны на лучших отраслевых практиках и должны быть задокументированы, чтобы гарантировать, что команда будет следовать им в полном объеме.

6,6

Платежные приложения, предназначенные для общественности, такие как веб-приложения, к которым можно получить доступ через Интернет, должны быть защищены либо с помощью брандмауэра веб-приложений (WAF), либо с помощью строгого процесса сканирования уязвимостей веб-приложений.

Учитывая важность этого требования PCI и то, как оно устанавливает минимальный уровень контроля безопасности, некоторые организации, заботящиеся о безопасности, выбирают подход «пояс и скобки» в рамках безопасности своих веб-приложений.

Зачем уделять внимание соответствию стандарту PCI DSS?

Для новых компаний или стартапов, которым необходимо сотрудничать с крупными поставщиками финансовых услуг, PCI DSS не подлежит обсуждению.

Причины, по которым они должны учитывать соответствие, заключаются в том, что PCI улучшает меры в дополнение к увеличению и демонстрации доверия к клиентам и другим организациям.

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

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

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

Как поддерживать соответствие PCI?

Этапы соответствия PCI DSS можно разделить на две части: первая часть — достижение состояния соответствия PCI DSS , которое может быть обеспечено путем создания контрольного списка соответствия PCI , а вторая часть — поддержание Состояние соответствия DSS.

Вторая часть — соблюдение требований PCI DSS — труднодостижимое состояние, часто из-за ошибочных предположений о том, что соответствие сводится к простому следованию контрольному списку аудита PCI DSS. Формула поддержания соответствия заключается в разработке процессов, обеспечивающих постоянное соответствие стандарту PCI.

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

Создание плана для постоянного соблюдения

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

  1. План контроля доступа
  2. Разработка политики для соответствия требованиям PCI
  3. Ведение и ведение подробных записей
  4. Управление надзором
  5. Регулярное тестирование для измерения уязвимостей

Вывод

Поскольку все, от безопасности конечных пользователей до будущего вашего бизнеса, зависит от правильной реализации и поддержания соответствия PCI DSS, вам необходимо связаться с компанией по разработке приложений для финансовых технологий, которая понимает формальности соответствия наизнанку. Компания может находиться в вашем родном регионе, а может быть и в любой другой части мира, например, вы можете выбрать компанию по разработке финтех-приложений в США . Убедитесь, что вы выбираете лучшее, чтобы получить качественные результаты. В любом случае проверьте опыт и знания агентства, прежде чем что-либо дорабатывать.

Часто задаваемые вопросы о разработке мобильных приложений Fintech, совместимой с PCI DSS

В. Каковы уровни соответствия PCI?

Стандарт PCI DSS требуется всем организациям, которые хранят, используют или передают данные владельцев автомобилей для ведения своего бизнеса. Но требования различаются в зависимости от бизнес-операций, что делит соответствие на четыре уровня.

Уровень 4: обработка мерчантами менее 20 000 транзакций в год

Уровень 3: обработка продавца составляет от 20 000 до 1 миллиона транзакций в год.

Уровень 2: продавец обрабатывает от 1 до 6 миллионов транзакций в год.

Уровень 1: обработка продавца составляет более 6 миллионов транзакций в год.

В. Что такое PCI DSS?

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

В. Что означает соответствие PCI для бизнеса приложений Fintech?

Бизнес приложений Fintech, совместимый с PCI, юридически готов обходить данные карты пользователей для своего процесса. Финтех-компаниям, которые не соответствуют требованиям PCI, не разрешается работать с конфиденциальными данными держателей карт, и они могут столкнуться с серьезными финансовыми последствиями, такими как сборы, штрафы и даже потеря бизнеса. Такие последствия делают разработку программного обеспечения, отвечающего требованиям PCI, для финтех-приложений абсолютно необходимой необходимостью.

В. Как стать PCI-совместимым?

В контрольный список соответствия PCI следует включить пять основных пунктов:

  1. Анализ вашего уровня соответствия
  2. Заполнение анкеты самооценки
  3. Внесение необходимых изменений/восполнение недостатков
  4. Прохождение аттестации соответствия
  5. Подача документов

В. Требуется ли сертификат PCI DSS при использовании платежного шлюза?

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

В. Какова взаимосвязь между PA DSS и PCI DSS?

PA DSS — это стандарт для разработчиков и интеграторов мобильных платежных приложений, использующих карточную информацию для авторизации и проведения платежей. Для обеспечения соответствия PA DSS приложения должны продаваться, распространяться или лицензироваться третьим лицам. Соответствие PA DSS разделено на два этапа:

Phases of PA-DSS

Соблюдение требований PA DSS поможет вам соответствовать стандарту PCI DSS.