BIS Journal №3(14)/2014

7 августа, 2014

Внешняя разработка платежных приложений в рамках PCI DSS v.3.0

В конце 2013 года опубликована новая версия стандарта безопасности данных платежных карт – PCI DSS v3.0, которая становится обязательной с 1 января 2015 года. Помимо множества изменений и уточнений сугубо технических защитных мер, новая редакция стандарта накладывает дополнительные требования на взаимодействие с поставщиками услуг. Об взаимодействии с одним из типов таких поставщиков услуг – с разработчиками платежного программного обеспечения – пойдет речь в этой статье.

ВМЕСТО ВВЕДЕНИЯ

Ни для кого не секрет, что далеко не все компании, осуществляющие обработку данных платежных карт, используют исключительно «коробочные» версии платежных приложений. Одним проще сильно кастомизировать решение, чем менять устоявшиеся бизнес процессы и информационную инфраструктуру. Другие ставят перед собой задачи настолько специфичные, что для их решения просто нет «коробочных» продуктов (по крайней мере, пока). Так или иначе, многие компании сталкиваются с разработкой платежных приложений, и выполняют ее либо своими силами, либо с помощью подрядных организаций.

Вопросы безопасности «коробочного» программного обеспечения (ПО) снимаются путем сертификации по PA-DSS, а для приложений, разработанных или кастомизированных под нужды отдельных компаний, существуют требования 6.3 и 6.5 PCI DSS, которые должны проверяться в ходе аудита этих компаний на соответствие PCI DSS. И если до выхода PCI DSS v3.0 применимость этих требований для внешней разработки была не очевидна и оставалась на понятийном уровне, то теперь стандарт явно указывает на то, что данные требования должны проверяться и для тех компаний, которые привлекают сторонних специалистов к разработке платежных приложений.

Сразу отмечу, что разработка ПО, выполняемая собственными силами, и «коробочные» продукты не являются предметом рассмотрения в настоящей статье.

Для краткости дальнейшего изложения введу следующие термины:

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

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

РАССМАТРИВАЕМЫЕ ТРЕБОВАНИЯ

Освежим в памяти перечень требований, которые необходимо выполнять при разработке платежных приложений (точные формулировки требований и соответствующих процедур проверки приведены в официальном тексте стандарта PCI DSS v.3.0):

Краткое изложение требования

6.3

Процедуры разработки платежных приложений должны:

  • учитывать необходимость реализации всех применимых к приложению требований PCI DSS;
  • основываться на отраслевых стандартах и/или лучших практиках;
  • уделять внимание информационной безопасности (ИБ) на всех этапах проектирования, разработки и внедрения ПО.

6.3.1

Перед передачей ПО в эксплуатацию все учетные данные, используемые при разработке и тестировании, должны быть удалены.

6.3.2

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

  • анализ (контроль) кода может выполняться вручную или в автоматизированном режиме;
  • не допускается, чтобы автор кода самостоятельно проводил анализ (контроль) своего кода;
  • анализ (контроль) кода должен выполняться лицом, обладающим достаточными компетенциями в области техник анализа (контроля) кода и практик «безопасного программирования»;
  • в ходе анализа (контроля) кода должен осуществляться контроль следования существующим руководствам по «безопасному программированию»;
  • все недостатки, выявленные в ходе анализа (контроля) кода, должны быть устранены до передачи ПО в эксплуатацию;
  • результаты анализа (контроля) кода должны проверяться и утверждаться руководством, до передачи ПО в эксплуатацию.

6.5

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

  • обучения разработчиков техникам «безопасного программирования»;
  • разработки приложений на основе руководств по «безопасному программированию».

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

По роду своей деятельности и характеру оказываемых услуг, Разработчик способен влиять на безопасность данных платежных карт, обрабатываемых Клиентом. Поэтому Клиентом по отношению к привлекаемому Разработчику должны выполняться требования подраздела 12.8 PCI DSS. Другими словами, Клиент должен выполнить следующее:

Краткое изложение требования

12.8.1

Включить всех привлеченных Разработчиков в свой список сервис-провайдеров.

12.8.2

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

12.8.3

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

12.8.4

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

12.8.5

Четко определить и документировать, какие требования PCI DSS выполняются Разработчиками, а какие Клиенту необходимо выполнять собственными силами.

ТЕКУЩЕЕ ПОЛОЖЕНИЕ

Отсутствие в предыдущих версиях стандарта прямого указания на то, что требования по обеспечению безопасности при разработке ПО применимы и к сторонним разработчикам, оставляло Клиентам и QSA-аудиторам возможность ошибочно или сознательно исключать процессы внешней разработки из области аудита на соответствие требованиям PCI DSS. Многие аудиторы запрашивали тексты договоров между Клиентом и Разработчиками и тексты технических заданий на разрабатываемые системы/модули, только для того, чтобы убедиться, что в текст договора включены заявления об ответственности за соответствие разработки полученному ТЗ, а само ТЗ учитывает применимые к приложению требования стандарта.

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

Более того, новое для PCI DSS требование 12.8.5 предписывает самим Клиентам вести учет, какое требование в чьей области ответственности лежит. Другими словами, в рамках рассматриваемой темы, теперь Клиентов в явном виде просят ответить на вопрос, кто будет обеспечивать соответствие требованиям 6.3 и 6.5 – Клиент или Разработчик.

Но ответить на этот вопрос на сегодняшний день большинству Клиентов не так просто. Проблема заключается в том, что договоры с разработчиками уже заключены, отношения выстроены, процессы отработаны и прижились. И ни заключенные договоры, ни устоявшиеся процедуры взаимодействия в подавляющем большинстве случаев не удовлетворяют требованиям PCI DSS v.3.0.

Для Клиентов самый очевидный, проторенный и простой путь решения проблемы – заключение договоров только с теми Разработчиками, которые подтвердили соответствие процессов разработки ПО требованиям PCI DSS, и готовы предоставить действующий Attestation of Compliance. Однако на практике вряд ли удастся заставить Разработчика вкладываться в непрофильную для него деятельность по обеспечению безопасности и ежегодно платить за QSA-аудит без существенного увеличения стоимости услуг по разработке/доработке ПО. Кроме того, замена Разработчика без полного отказа от разрабатываемой им системы в большинстве случаев практически невозможна.

Поэтому более реальным представляется другой вариант – перестроить взаимоотношения с Разработчиком таким образом, чтобы иметь возможность в ходе собственного QSA-аудита предоставить все необходимые свидетельства выполнения применимых требований стандарта. Именно об этом мы и будем говорить в следующей части статьи.

РАЗДЕЛЕНИЕ ОТВЕТСТВЕННОСТИ

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

В нашем случае эти вопросы звучат примерно так: готов ли Разработчик взять на себя ответственность за безопасность разрабатываемого приложения, отсутствие в нем распространенных уязвимостей, или он может отвечать только за то, что разработка будет соответствовать требованиям технического задания? Как изменится стоимость услуг в каждом из этих случаев?

Давайте чуть подробнее рассмотрим оба возможных варианта ответов.

Вариант 1 – Ответственность за безопасность приложения лежит на Разработчике

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

Безусловно, Клиент должен помнить о том, что платежное приложение – системный компонент в среде данных платежных карт, и к нему применимы многие другие (кроме обсуждаемых сейчас требований 6.3 и 6.5) требования PCI DSS. Поэтому, при формировании технического задания, кроме обычных функциональных требований, необходимо уделять внимание и специфичным для PCI DSS требованиям по защите информации: подсистеме аутентификации; механизмам разграничения доступа; подсистеме регистрации событий; мерам защиты данных платежных карт при их хранении, обработке, передаче, отображении, уничтожении; и многому другому.

Зато все непрофильные для Клиента функции переносятся на Разработчика:

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

 

№ требования PCI DSS v.3.0

Область ответственности

Клиент

Разработчик

6.3

ДА
в части определения и включения в ТЗ функциональных требований к подсистемам безопасности платежного приложения

ДА
в части формирования и использования Руководства по программированию

6.3.1

нет

ДА

6.3.2

нет

ДА

6.5

нет

ДА

6.5.1 – 6.5.10

нет

ДА

При этом свидетельства выполнения всех этих действий должны быть переданы Клиенту, поскольку они потребуются при прохождении аудита на соответствие требованиям PCI DSS.

Про Руководство по программированию необходимо сказать несколько слов отдельно. Во-первых, оно должно быть основано на отраслевых стандартах и/или лучших практиках и содержать явные ссылки на них, что не представляет сложности. А во-вторых, Руководство должно содержать конкретные техники, позволяющие предотвратить появление в коде приложения распространенных уязвимостей, перечень которых приведен в требованиях 6.5.1 – 6.5.10 PCI DSS. И вот тут возникают проблемы, поскольку перечень этот не статичен – по факту изменения статистики эксплуатации уязвимостей в него будут вноситься изменения, как минимум, этот перечень должен соответствовать OWASP Top 10, SANS CWE Top 25 и прочим подобным чартам. Более того, в требовании 6.5.6 говорится обо всех уязвимостях, которым сам Клиент присвоил высокую степень критичности по результатам исполнения процедур управления уязвимостями и оценки рисков ИБ. Другими словами, Руководство по программированию должно оперативно изменяться по запросу Клиента.

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

Таким образом, договор с Разработчиком должен предусматривать:

  • ответственность Разработчика за соответствие разрабатываемого приложения требованиям технического задания, предоставленного Клиентом;
  • ответственность Разработчика за формирование и согласование с Клиентом Руководства по программированию, включающего конкретные техники по предотвращению появления в коде приложения уязвимостей, перечень которых определяется Клиентом;
  • ответственность Разработчика за оперативное внесение изменений в Руководство по программированию в случае изменения Клиентом перечня уязвимостей;
  • ответственность Разработчика за выполнение анализа (контроля) исходного кода приложения в полном соответствии с требованиями стандарта PCI DSS;
  • ответственность Разработчика за соответствие процедур разработки приложения требованиям Руководства по программированию, согласованного с Клиентом;
  • ответственность Разработчика за организацию и проведение регулярного обучения лиц, ответственных за разработку и анализ (контроль) исходного кода, в соответствии с требованиями стандарта PCI DSS;
  • ответственность Разработчика за предоставление Клиенту свидетельств выполнения анализа (контроля) исходного кода, устранения выявленных недостатков, обучения программистов и контролеров, и прочих свидетельств, необходимых для подтверждения соответствия действующих процедур разработки приложения требованиям стандарта PCI DSS;
  • ответственность Разработчика за оперативное предоставление Клиенту (и его QSA-аудитору) возможности проведения интервью с лицами, ответственными за разработку платежного приложения и анализ (контроль) его исходного кода.

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

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

Конечно, нельзя забывать и про требования подраздела 12.8 PCI DSS, перечень которых уже был приведен выше.

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

Вариант 2 – Разработчик отвечает только за соответствие техническому заданию

Это второй вариант работы, на случай неготовности Разработчика брать на себя ответственность за безопасность приложения (или чрезмерного увеличения стоимости оказываемых услуг). В данной схеме взаимодействия область ответственности Разработчика существенно сокращается по сравнению с предыдущим случаем. По сути, все, за что отвечает Разработчик, – это:

  • выполнение требований технического задания;
  • знание Руководства по программированию, и следование ему при выполнении работ.

А вот все остальное, включая разработку Руководства по программированию, проведение анализа (контроля) кода и проведение обучений для сотрудников Разработчика, к сожалению, ложится на плечи самого Клиента.

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

К слову, PCI DSS допускает проведение анализа (контроля) кода не в ручном режиме, а с использованием средств автоматизации, что позволит снизить нагрузку на этих специалистов, и использовать их в реализации прочих процессов обеспечения ИБ.

Другой вариант для Клиента – поручить разработку Руководства по программированию, анализ (контроль) кода и обучение разработчиков еще одной подрядной организации, заключив с ней соответствующий договор.

?

 

№ требования PCI DSS v.3.0

Область ответственности

Клиент

Разработчик

6.3

ДА
в части определения и включения в ТЗ функциональных требований к подсистемам безопасности платежного приложения;
а также в части формирования Руководства по программированию

ДА
в части знания и использования Руководства по программированию

6.3.1

нет

ДА

6.3.2

ДА

нет

6.5

ДА
в части формирования Руководства по программированию и проведения обучения для разработчиков

ДА
в части знания и использования Руководства по программированию

6.5.1 – 6.5.10

ДА
в части формирования Руководства по программированию

ДА
в части знания и использования Руководства по программированию

В описанной схеме взаимодействия практически все свидетельства выполнения требований 6.3 и 6.5 PCI DSS формирует сам Клиент, а Разработчик должен только предоставить возможность QSA-аудитору провести интервью с разработчиками кода.

В этом случае договор с Разработчиком должен предусматривать:

  • ответственность Разработчика за соответствие разрабатываемого приложения требованиям технического задания, предоставленного Клиентом;
  • ответственность Разработчика за соответствие процедур разработки приложения требованиям Руководства по программированию, предоставленного Клиентом;
  • ответственность Разработчика за предоставление рабочего времени лиц, ответственных за разработку платежного приложения, для прохождения обучения по требованиям Руководства по программированию;
  • ответственность Разработчика за оперативное предоставление Клиенту (и его QSA-аудитору) возможности проведения интервью с лицами, ответственными за разработку платежного приложения и анализ (контроль) его исходного кода.

Конечно, и в этом случае Клиенту тоже нельзя забывать про выполнение раздела требований 12.8 PCI DSS.

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

ЗАКЛЮЧЕНИЕ

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

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

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

Стать автором BIS Journal

Смотрите также

Подписаться на новости BIS Journal / Медиа группы Авангард

Подписаться
Введите ваш E-mail

Отправляя данную форму вы соглашаетесь с политикой конфиденциальности персональных данных

29.03.2024
Евросоюз обозначил ИБ-угрозы на ближайшие шесть лет
29.03.2024
В законопроекте об оборотных штрафах есть лазейки для злоупотреблений
28.03.2024
Аитов: Ограничения Samsung Pay на использование карт «Мир» можно обойти
28.03.2024
Киберпреступления — 35% всех преступлений в России
28.03.2024
Почему путешествовать «налегке» не всегда хорошо
28.03.2024
«Тинькофф»: Несколько платёжных систем лучше, чем одна
28.03.2024
В РФ готовят базу для «усиленной блокировки» незаконного контента
28.03.2024
Термин «риск ИБ» некорректен по своей сути
27.03.2024
Samsung Pay перестанет дружить с «мировыми» картами
27.03.2024
Канадский университет восстанавливает работу после ИБ-инцидента

Стать автором BIS Journal

Поля, обозначенные звездочкой, обязательные для заполнения!

Отправляя данную форму вы соглашаетесь с политикой конфиденциальности персональных данных