Все более или менее крупные российские компании, которые проводят платежные онлайн‑транзакции, должны сегодня выполнять требования двух стандартов по защите и безопасности карточных данных их покупателей — PCI DSS и ГОСТ 57 580.1–2017. Первый придумали за рубежом, а второй — результат творчества Банка России. Что это за стандарты, какие аспекты работы онлайн‑продавцов они регулируют, насколько различаются их требования и как обойтись при их внедрении малой кровью — читайте в нашей статье.

PCI DSS и ГОСТ Р 57580.1-2017 – кому они нужны и насколько похожи

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

Достаточно часто я слышал мнение, что стандарт PCI DSS — это для банков. Но это не совсем так. Стандарт PCI DSS придумали именно для магазинов (merchant, в терминологии стандартов), когда платежи с помощью карт плотно вошли в жизнь и стало понятно, что взломать интернет‑магазин существенно проще, чем банк.

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

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

• который распространяется через банки или платежные центры, то есть те организации, которые подключаются к платежным системам напрямую;

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

А дальше банк или платежный центр сам выстраивает свою стратегию:

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

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

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

Несколько лет назад Банк России разработал массу требований по защите данных при обработке платежей — платежных данных. К банкам и некредитным финансовым организациям (платежным центрам, например) эти требования применяются через разнообразные Положения Банка России: 683-П, 757-П, 719-П и 747-П. Все эти положения содержат ссылку на стандарт ГОСТ Р 57 580.1–2017, а также описание того, какие системы и процессы в компании нужно защитить в соответствии с требованиями стандарта.

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

• обеспечить защиту собственных систем;

• обезопасить себя при оказании услуг третьим лицам. В том числе — при предоставлении услуги «оплатить картой» магазинам. И банк при заключении договора обслуживания с интернет‑магазином вправе включить в этот договор условие, по которому магазин защищает себя в соответствии с требованиями Положения Банка России или ГОСТа. И банк снова волен выбирать:

• рисковать и не требовать;

• требовать защиты, но иметь меньше клиентов;

• требовать выполнения стандартов по защите платежных данных, начиная с какого‑то оборота.

Логично, что платежи по картам — это тоже платежи. т. е. оплата по карте подпадает и под требования стандарта PCI DSS, и под требования стандарта ГОСТ Р 57 580.1–2017.

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

Короткий ответ: сэкономить можно, но не на процедуре получения сертификата, а именно на выполнении мер. Как это сделать — читайте дальше в статье.

Про стандарты изнутри: сходства

Приведение в соответствие требованиям любого стандарта состоит из:

• покупки необходимых средств защиты;

• покупки и ежегодного продления поддержки и подписки на эти средства защиты;

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

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

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

• дополнительных тестовых процедур: пен‑тестов (тестов на проникновение) в данном случае. Их тоже практически всегда проводят нанятые подрядчики.

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

В Scope стандартов входят:

• серверы, на которых происходит непосредственная обработка платежа (web и web‑api, application);

• серверы, на которых хранятся данные о транзакциях или данные карт (База данных);

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

• элементы управления, то есть системы, с помощью которых управляются серверы, обрабатывающие и хранящие карточные данные: система управления доступом (MS AD, например), система управления обновлениями и конфигурациями (repo, MS SCCM), система управления антивирусом;

• так называемые connected‑системы, то есть системы, из которых в один прыжок можно достичь серверов, обрабатывающих или хранящих карточные данные: сетевое оборудование, различные системы закачки обновлений и т. п. (обычно правило про connected‑системы используют для уточнения перечня элементов управления).

Для соответствия обоим стандартам нужны следующие средства и меры защиты:

• межсетевой экран (обязательно со stateful‑инспекцией. т. е. просто списком ACL на ближайшем роутере или коммутаторе не обойтись);

• IDS или IPS‑система;

• антивирус на уязвимых системах;

• контроль целостности;

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

• двухфакторная аутентификация при удаленном доступе;

• двухфакторная аутентификация при административном доступе (часто объединяется с предыдущей мерой);

• внутренний сканер уязвимостей;

• сбор и хранение логов, правда с разными требованиями по длительности хранения логов.

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

Оба стандарта регламентируют не просто перечень средств защиты, но и то, как система защиты в целом должна работать. То есть требования к процессам управления защитой. Описания этих требований в PCI DSS и в ГОСТ Р 57 580.1–2017 отличаются уже существенно, но все же можно выделить схожие требования. Оба стандарта примерно одинаково требуют внедрить следующие процессы:

• процесс управления логическим доступом;

• процесс управления конфигурациями;

• процесс управления изменениями;

• процесс управления уязвимостями;

• процесс управления инцидентами ИБ;

• процессы безопасной разработки (с существенно различающейся детализацией требований).

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

Про стандарты изнутри: отличия

Первое же отличие — в том, к чему нужно применить стандарт.

Во‑первых, чуть‑чуть различаются критерии отнесения к connected‑системам.

Во‑вторых, PCI DSS не предъявляет никаких требований к тестовым системам. ГОСТ Р 57 580.1 — строже, и описывает некоторые требования к тестовым средам и средам разработки. Впрочем, на «бытовом» уровне эти требования сводятся к:

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

2. управлению процессом установки (устанавливать обновления из известных тестовых и разработческих сред, и не устанавливать непонятные обновления из неизвестных сред).

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

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

Есть различия в процедурах проверки:

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

Однако во многих случаях заказчики могут проводить самооценку по требованиям PCI DSS, то есть заполнять PCI SAQ.

Соответствие требованиям стандарта ГОСТ Р 575 780.1–2017 должна всегда проверять внешняя компания, и у нее должна быть лицензия ФСТЭК на деятельность по технической защите конфиденциальной информации (ТЗКИ). Таких компаний существенно больше, чем со статусом PCI QSA.

У аудита по требованиям PCI DSS может быть два результата: пройден успешно или пройден неуспешно.

Для стандарта ГОСТ Р 57 580.1 разработан целый отдельный стандарт проверки: ГОСТ Р 57 580.2–2017. И для каждого пункта из стандарта 1 ставится численное значение степени выполнения. В конце проверки аудитор по специальной формуле считает численный бал. Таким образом, соответствовать требованиям ГОСТ Р 57 580.1 можно в разной степени (на разную оценку). И требования к минимально необходимой оценке есть как раз в положениях Банка России, а не в самом ГОСТ.

И самое сложно объяснимое различие: в процессах, точнее в документах, описывающих процесс и способы контроля по нему.

И это различие мне проще объяснить именно со стороны проверяющего. Стандарт PCI DSS — и старше, и международный — должен применяться сравнительно единообразно в разных странах с разным уровнем зрелости ИБ и ИТ в целом.

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

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

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

Стандарт же ГОСТ Р 57 580.1 является обязательным для целой отрасли (финансовой). И требует достаточно большой детализации в процессах и процедурах контроля:

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

• процедур контроля (кто контролирует, как часто, как);

• подтверждений выполнения (протоколов проверок, выборок с процентным соотношением «хороших» и «плохих» значений).

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

Таким образом, документы (процессы, процедуры проверки, метрики контроля), разрабатываемые для соответствия требованиям ГОСТ Р 57 580.1, существенно подробнее.

Итого: внедряем оба стандарта. И...?

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

Однако, если вы уже привели систему в соответствие одному стандарту, то вы уже сэкономили, потому что:

• установили большую часть средств защиты, необходимых для обоих стандартов;

• ваш персонал привык к дополнительным требованиям безопасности при работе с карточными или платежными системами и так или иначе уже обеспечивает их безопасность;

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

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