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

Но мы попробуем. В этой статье вместе с экспертом Дмитрием Никифоровым из CardSec разберем основные изменения PCI DSS, которые коснутся всех, кто работает с данными платежных карт в интернете. Заодно расскажем, какие действия нужно выполнить, чтобы закрыть новые требования, и как это сделали мы в Nubes.

Как все начиналось

Стандарт PCI DSS появился достаточно давно — в 2008 году. Его создали на основе существовавших стандартов отдельных платежных систем — Visa и MasterCard в первую очередь. И, вопреки распространенному мнению, разрабатывался он в большей степени для применения не банками, а прочими компаниями, которые обрабатывают данные платежных карт (merchant в терминологии стандарта). Основной идеей было то, что банки уже занимаются своей безопасностью. А вот взломать какой-нибудь магазин (или, особенно, интернет-магазин) намного легче и, возможно, и выгоднее.

Исторически требования стандарта распространялись на два типа компаний: уже упомянутые merchant и все остальные, вовлеченные в обработку персональных данных. Все они называются service providers.

В категорию service providers попадали все, кто участвует в обработке карт или способен получить доступ к данным карт: банки, процессинговые центры, поставщики услуг эквайринга. С развитием технологий и сервисов в интернете часто в область действия стандарта PCI DSS стали попадать и нефинансовые компании: хостинговые площадки (для сайтов), дата-центры, облачные провайдеры.

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

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

Что нового в PCI DSS 4.0

Прошлая версия стандарта — PCI DSS v3.2.1 — вышла в 2018-м году и продержалась сравнительно долго. В 2022-м году была опубликована новая версия — v4.

Нового в 4.0 оказалось много. Причем изменения касаются даже основных понятий. Например, раньше в качестве service providers рассматривались и финансовые организации, и технологические компании. Стандарт PCI DSS предъявлял одинаковые требования как к банкам, так и к облачным провайдерам. Никакая специфика не учитывалась.

В версии 4.0 мы видим, что наконец-то появилось понятие «‎технологический провайдер» (Third-Party service providers)‎. К этой группе теперь относятся технологические компании, не вовлеченные в непосредственную обработку данных платежных карт, но способные на нее повлиять. Так, например, в эту категорию попали дата-центры, облачные провайдеры и интернет-провайдеры.

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

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

1. Обязательное назначение ответственного

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

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

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

2. План периодических мероприятий

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

В такой план обычно вносят регулярные процедуры:

• пересмотр учетных записей и предоставленных прав доступа (и отключение забытых, устаревших или более не актуальных учетных записей и доступов);

• пересмотр правил межсетевого экранирования (и отключение забытых, устаревших или более не актуальных правил межсетевого экранирования);

• мониторинг уязвимостей ПО, а также анализ эффективности их устранения;

• проведение тестирования на проникновение, а также анализ эффективности выявленных недостатков;

• тренинги, тестовые фишинговые email-рассылки и прочие обучающие мероприятия;

• сканирование конечных устройств пользователей на наличие вредоносного ПО и т.д.;

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

3. Более ответственное отношение к проверкам своей защищенности

Нововведение касается всех сервис-провайдеров и технологических провайдеров.  Более ответственный подход к ИБ отразился во многих требованиях. Так, например, теперь нужно минимум раз в 6 месяцев:

• проверять актуальность правил межсетевого экранирования,

• оценивать актуальность предоставленных доступов,

• проводить тестирование на проникновение.

Раньше все эти мероприятия требовалось проводить реже — раз в год.

4. Новые правила защиты данных карт

В версии 4.0:

• изменились требования к применимым алгоритмам шифрования и хэширования при сокрытии номеров карт. Теперь необходимо использовать keyed-hash,

• уточнили, что именно и когда можно шифровать, а также хэшировать. В том числе указали, как применять шифрование на уровнях диска, СУБД и приложения.

5. Требования к шифрованию как сервису

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

6. Явные требования к управлению доступом клиентов к данным (для технологических провайдеров)

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

7. Соучастие в расследовании инцидентов ИБ (для технологических провайдеров)

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

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

8. Изменения в безопасности приложений

Теперь для публично доступных интерфейсов обязательно применять Web Application Firewall — WAF. Это отложенное требование, которое вступает в силу весной 2025 года.

9. Новые требования к средству управления инцидентами ИБ

Теперь обязательно применять SIEM — средство, которое позволяет автоматизированно производить корреляцию информации о событиях ИБ и автоматически уведомлять ответственных сотрудников об инцидентах. Как в случае с WAF, требование вступает в силу весной 2025 года.

Как мы выполнили требования PCI DSS v4

В начале 2024 года мы провели аудит на соответствие нашего облака NGcloud обновленному стандарту совместно с CardSec. На подготовку ушло не больше месяца, так как многое уже было настроено и внедрено до этого.

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

Что касается требований № 2 и № 3 — плана периодических мероприятий и более ответственного отношения к ИБ-проверкам, — то в основном вся работа здесь заключалась в изменении периодичности проведения процедур и создании единого документа. Например, мы указали в нем следующие регулярные мероприятия:

• аудит парольной политики в компании,

• работы по совершенствованию процессов ИБ,

• проверки работы средств антивирусной защиты.

Выполнить план мероприятий можно с использованием типовых решений service desk или других средств автоматизации, которые используются во многих современных компаниях. Так легче перевести бумажный план в практику: составляете заявки на проверку с нужными датами, система инициирует задачу исполнителям, а по завершении мероприятия вы получаете результаты в виде отчетов.

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

Чтобы соблюсти требование № 6 (управление парольными политиками при доступе клиентов к сервису), мы внедрили систему Identity Management (IdM)  Keycloak. Благодаря этому получили единый механизм аутентификации для всех облачных сервисов, которые предоставляем клиентам.

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

Как технологический провайдер Nubes также должен оказывать содействие при расследовании инцидентов на стороне клиента (требование № 7). Для этого мы начали собирать множество логов с нашего облака и мониторить все, до чего можем дотянуться: хосты, межсетевые экраны, антивирусы, пользовательские устройства.

Чтобы понять, что этих данных достаточно, прошли необязательную проверку Pre-IR. Независимые эксперты подтвердили, что у нас есть SIEM-система (требование № 9) и она собирает достаточно данных для полноценной реконструкции клиентских ИБ-событий.

Для более детального и тщательного расследования инцидентов на стороне клиентов привлекаются внешние эксперты по цифровой криминалистике. С этой целью мы заключили соглашения с F.A.С.С.T. и Angara Security. 

И наконец, еще одно условие, которое нужно выполнить к весне 2025 года, — наличие Web Application Firewall. И мы его уже давно выполнили. Файрвол для веб-приложений встроен в Sangfor NGAF — интегрированный NGFW + WAF (отсюда и название Next Generation Application Firewall), который мы используем для публикации наших облачных сервисов.

А теперь коротко

В общем, ничего страшного в новом PCI DSS нет. Если ваша компания уже проходила успешно проверку по PCI DSS, то переход на v4 будет плавным. По большому счету, нужно:

1. Доработать собственные процессы управления ИБ в части контроля и определения ответственных сотрудников. И отразить это во внутренних документах.

2. Если компания относится к сервис-провайдерам, чаще планировать и проводить контрольные мероприятия.

3. Если у вас нет WAF и SIEM, запланировать их внедрение (время еще есть).

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

Все остальное — менее значительные требования и детали. Чтобы разобраться с ними, потребуется меньше времени и затрат.

PCI DSS — не единственный стандарт, которому должны соответствовать организации при работе с данными платежных карт. Также есть ГОСТ Р 57580 и другие нормативные акты Центробанка. А сегодня в Госдуме идет работа еще над одной инициативой регулятора, которая касается операционной безопасности. О ней мы поговорим в следующий раз.