PCI DSS and ГОСТ Р 57580.1-2017
Last updated
Was this helpful?
Last updated
Was this helpful?
Все более или менее крупные российские компании, которые проводят платежные онлайн‑транзакции, должны сегодня выполнять требования двух стандартов по защите и безопасности карточных данных их покупателей — PCI DSS и ГОСТ 57 580.1–2017. Первый придумали за рубежом, а второй — результат творчества Банка России. Что это за стандарты, какие аспекты работы онлайн‑продавцов они регулируют, насколько различаются их требования и как обойтись при их внедрении малой кровью — читайте в нашей статье.
PCI DSS — это стандарт защиты карточных данных. С его помощью должна обеспечиваться безопасность данных и их обработки с момента ввода пользователем данных в форму «оплатить картой» на сайте магазина и до момента движения денег между банками и счетами.
А там можно много чего натворить: перенаправить покупателя на поддельный сайт магазина, отправлять платежи за другой товар, модифицировать платежные поручения, да и просто увести всю базу карт, которыми оплачивали покупки.
Другое дело, что для обычного владельца интернет‑магазина, платежная система — это просто какая‑то организация, с которой нет никаких каналов общения: подключаются к ней через банк (или платежный центр). И платежные системы придумали стандарт:
который распространяется через банки или платежные центры, то есть те организации, которые подключаются к платежным системам напрямую;
в котором написано, что банки и платежные центры должны обязать подключаемые магазины выполнять требования 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 — строже, и описывает некоторые требования к тестовым средам и средам разработки. Впрочем, на «бытовом» уровне эти требования сводятся к:
изоляции средств защиты. Они должны быть как минимум отделены от продуктивной защищаемой среды, и должен быть хоть какой‑то контроль доступа к непродуктивным средам;
управлению процессом установки (устанавливать обновления из известных тестовых и разработческих сред, и не устанавливать непонятные обновления из неизвестных сред).
Также есть различия в требованиях к средствам защиты:
В PCI DSS также есть различия в описании требований к шифрованию: очевидно, PCI DSS ничего не знает о российской криптографии, но требует обязательно шифровать некоторые данные. Грубо говоря, если владелец системы хочет хранить данные карт (номер, дату, имя владельца), то он должен их или шифровать, или хэшировать. И применять определенные современные алгоритмы шифрования, хэширования и обмена ключевой информацией. Требования к применимым алгоритмам существенно обновились в PCI DSS v4, и теперь многие ранее разрешенные протоколы запрещены.
Есть различия в процедурах проверки:
Однако во многих случаях заказчики могут проводить самооценку по требованиям PCI DSS, то есть заполнять PCI SAQ.
У аудита по требованиям 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, — то, скорее всего, придется дополнить достаточно много процессов и документов.
Достаточно часто я слышал мнение, что — это для банков. Но это не совсем так. Стандарт PCI DSS придумали именно для магазинов (merchant, в терминологии стандартов), когда платежи с помощью карт плотно вошли в жизнь и стало понятно, что взломать интернет‑магазин существенно проще, чем банк.
Соответствие стандарту с выдачей сертификата могут проводить только специальные компании, имеющие статус квалифицированных PCI аудиторов, — PCI QSA. Таких аудиторов сравнительно мало. Искать их можно, например, .
Соответствие требованиям стандарта ГОСТ Р 575 780.1–2017 должна всегда проверять внешняя компания, и у нее должна быть лицензия ФСТЭК на деятельность по технической защите конфиденциальной информации (ТЗКИ). Таких компаний , чем со статусом PCI QSA.
