

ВМЕСТО ВВЕДЕНИЯ
Ни для кого не секрет, что далеко не все компании, осуществляющие обработку данных платежных карт, используют исключительно «коробочные» версии платежных приложений. Одним проще сильно кастомизировать решение, чем менять устоявшиеся бизнес процессы и информационную инфраструктуру. Другие ставят перед собой задачи настолько специфичные, что для их решения просто нет «коробочных» продуктов (по крайней мере, пока). Так или иначе, многие компании сталкиваются с разработкой платежных приложений, и выполняют ее либо своими силами, либо с помощью подрядных организаций.
Вопросы безопасности «коробочного» программного обеспечения (ПО) снимаются путем сертификации по PA-DSS, а для приложений, разработанных или кастомизированных под нужды отдельных компаний, существуют требования 6.3 и 6.5 PCI DSS, которые должны проверяться в ходе аудита этих компаний на соответствие PCI DSS. И если до выхода PCI DSS v3.0 применимость этих требований для внешней разработки была не очевидна и оставалась на понятийном уровне, то теперь стандарт явно указывает на то, что данные требования должны проверяться и для тех компаний, которые привлекают сторонних специалистов к разработке платежных приложений.
Сразу отмечу, что разработка ПО, выполняемая собственными силами, и «коробочные» продукты не являются предметом рассмотрения в настоящей статье.
Для краткости дальнейшего изложения введу следующие термины:
Я также не ставлю себе целью предоставление неоспоримой консультации, покрывающей все возможные случаи. Безусловно, я стремлюсь обозначить направления возможных решений поставленной проблемы. Но в каждом конкретном случае отталкиваться стоит именно от официального текста стандарта, ни в коем случае не ограничиваясь только приведенным ниже текстом.
РАССМАТРИВАЕМЫЕ ТРЕБОВАНИЯ
Освежим в памяти перечень требований, которые необходимо выполнять при разработке платежных приложений (точные формулировки требований и соответствующих процедур проверки приведены в официальном тексте стандарта PCI DSS v.3.0):
№ |
Краткое изложение требования |
---|---|
6.3 |
Процедуры разработки платежных приложений должны:
|
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 (включая разделение тестовых и промышленных сред, разделение обязанностей, оценку влияния изменения на безопасность информации, тестирование функций безопасности, сканирование уязвимостей, и многое другое).
Таким образом, договор с Разработчиком должен предусматривать:
Последний пункт необходим для успешного прохождения 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-аудитору провести интервью с разработчиками кода.
В этом случае договор с Разработчиком должен предусматривать:
Конечно, и в этом случае Клиенту тоже нельзя забывать про выполнение раздела требований 12.8 PCI DSS.
Безусловно, и у этой схемы есть обратная сторона. Во-первых, Клиенту придется потратиться на привлечение хотя бы одного эксперта в области «безопасного программирования», либо на привлечение подрядной организации, обладающей соответствующими компетенциями. А во-вторых, чтобы данный вариант был работоспособен, Разработчик должен согласиться на передачу Клиенту исходного кода приложения.
ЗАКЛЮЧЕНИЕ
Конечно, реальная жизнь гораздо богаче и разнообразнее описанных выше двух вариантов взаимодействия между Клиентом и Разработчиком, и с каждым конкретным случаем необходимо внимательно разбираться отдельно. Но, я надеюсь, что эта статья обратит внимание компаний, обрабатывающих данные платежных карт, на текущую проблему и наметит хотя бы основные направления мысли при ее решении.
Так или иначе, любой способ всегда будет иметь свои плюсы и минусы, и нужно выбирать тот, который лучшим образом удовлетворяет интересам и Клиента, и Разработчика. Подходящий именно Вам вариант может быть сформирован только в ходе диалога с Разработчиком. Важно только, чтобы требования PCI DSS при этом не нарушались.
Отправляя данную форму вы соглашаетесь с политикой конфиденциальности персональных данных
Отправляя данную форму вы соглашаетесь с политикой конфиденциальности персональных данных