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

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

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

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

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

Создайте и поддерживайте безопасную сеть

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

Защитите данные держателей карт

3. Защитите сохраненные данные о держателях карт
4. Зашифруйте передачу данных о держателях карт через открытые общедоступные сети.

Поддерживать программу управления уязвимостями

5. Используйте и регулярно обновляйте антивирусное программное обеспечение или программы
6. Разрабатывайте и обслуживайте безопасные системы и приложения.

Внедрите строгие меры контроля доступа

7. Ограничьте доступ к данным о держателях карт в соответствии с бизнес-требованиями
8. Назначьте уникальный идентификатор каждому лицу, имеющему доступ к компьютеру
9. Ограничьте физический доступ к данным о держателях карт

Регулярный мониторинг и тестирование сетей

10. Отслеживайте и контролируйте любой доступ к сетевым ресурсам и данным держателей карт
11. Регулярно тестируйте системы и процессы безопасности

Поддерживать политику информационной безопасности

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

Определив, что такое 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, IPSec или SSH, для защиты конфиденциальных данных держателей карт во время их передачи по общедоступной сети.

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?

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

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

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

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

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

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

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

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

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

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

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

В. Что такое стандарт безопасности данных в индустрии платежных карт?

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

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

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

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

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

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

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

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

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

Статьи по Теме:

Продолжайте изучать ландшафт дизайна продуктов с помощью этих полезных ресурсов:

Первоначально опубликовано на https://appinventiv.com 29 октября 2019 г.