PCI DSS — это стандарт безопасности, принятый в 2004 году крупными эмитентами кредитных карт, потому что — и это неудивительно — приложения для обработки платежей стали привлекательной мишенью для хакеров и злоумышленников.
Содержание
Миссия PCI DSS — обеспечить безопасность операций с кредитными и дебетовыми картами, но не только для сокращения убытков банков и индустрии платежных карт, а также для защиты и повышении доверия потребителей. Для этого применяется набора средств контроля безопасности, которые защищают конфиденциальность, целостность и точность данных карты. Этот стандарт обязаны соблюдать все организации которые хранят, обрабатывают и передают данные кредитных карт. В отличие от требований NIST, соблюдать которые желательно, но не обязательно, стандарт PCI DSS является обязательным для соблюдения.
Требования PCI DSS
PCI DSS состоит из двенадцати требований, сгруппированных по шести целям контроля, которые обеспечивают безопасность сред обработки, хранения и передачи данных кредитных карт. Соблюдение стандарта помогает защитить информацию о держателях карт и укрепить общие меры безопасности.
Цель 1: создание и поддержание безопасной сети
Правило 1: применяйте межсетевой экран.
Правило 2: не используйте пароли или конфигурации поставщика по умолчанию
Цель 2: защита данных о держателях карт
Правило 3: защищайте хранимые данные о держателях карт
Правило 4: шифруйте передаваемые данные о держателях карт
Цель 3: применение программы управления уязвимостями
Правило 5: обеспечьте защиту от вредоносных программ
Правило 6: разработайте и поддерживайте защищенные системы
Цель 4: управление контролем доступа
Правило 7: ограничьте доступ к данным держателей карт
Правило 8: обеспечьте уникальную идентификацию всех, кто имеет доступ к данным о держателях карт
Правило 9: ограничьте физический доступ к данным о держателях карт
Цель 5: мониторинг и тестирование сетей
Правило 10: отслеживайте весь доступ к данным о держателях карт
Правило 11: тестируйте системы безопасности
Цель 6: применение политики информационной безопасности
Правило 12: разработайте и обеспечьте соблюдение политики информационной безопасности в организации
Существует четыре уровня соответствия в зависимости от ежегодного количества обработанных транзакций по кредитной или дебетовой карте. Классификация определяет, что необходимо сделать организации для поддержания комплаенса:
Уровень 1: более 6 млн транзакций в год. Требование: ежегодный внутренний аудит, проводимый уполномоченным аудитором PCI. Кроме того, они должны ежеквартально выполнять сканирование PCI с привлечением авторизованного поставщика услуг сканирования (ASV).
Уровень 2: 1–6 млн транзакций в год. Требование: ежегодная оценка с помощью листа самооценки (SAQ). Может потребоваться ежеквартальное сканирование PCI.
Уровень 3: от 20 тыс. до 1 млн транзакций в год. Требование: ежегодная самооценка и, возможно, ежеквартальное сканирование PCI.
Уровень 4: менее 20 тыс. транзакций в год. Требование: ежегодная самооценка и, возможно, ежеквартальное сканирование PCI.
Почему важно соблюдать требования PCI DSS
Каждый сотрудник организации играет важную роль в поддержании комплаенса, включая директора по ИБ и всех команд SecOps и DevOps. В идеальном мире DevSecOps в сфере безопасности между этими командами нет разделения — они работают сообща. SecOps помогает командам DevOps понять, что нужно сделать на уровне разработки приложений.
Вот несколько примеров того, что непрерывное соблюдение двенадцати требований стандарта PCI DSS требует командной работы:
Правило 6: разработчики должны создавать системы с учетом требований безопасности.
Правило 8: для управления идентификацией и доступом необходимо назначить каждому пользователю уникальный идентификатор.
Правило 9: отдел физической безопасности должен обеспечить контроль доступа в здание и серверные помещения.
Правило 10: команда SecOps должна наладить ведение логов для записи и отслеживания доступа к данным о держателях карт.
Правило 11: команды сопровождения и разработки должны работать вместе для тестирования серверов и программного обеспечения.
Правило 12: руководство должно разработать политики и соответствующие документы, чтобы подробно описать необходимый уровень информационной безопасности и комплаенса.
Как видите, все вносят свой вклад в комплаенс, причем не только ради общего блага, но и в практических целях, например, чтобы после сборки и развертывания приложения не получить десять тысяч оповещений SOS.
Как мы уже говорили, ваша ответственность в основном лежит на уровне приложения. Сюда входит использование безопасного исходного кода, обеспечение надлежащей конфигурации для конвейера CI/CD и многое другое. Возможно, вы задаетесь вопросом, как узнать, какие меры необходимо принять. К счастью, вам не обязательно быть специалистом по безопасности или комплаенсу, так же как вам не нужно быть нейрохирургом, чтобы наклеить пластырь. Достаточно знать и применять необходимые ресурсы (например, рану лучше закрыть пластырем, а не закрепленной скотчем салфеткой).
Чтобы избежать ошибок конфигурации, изучите документацию на сайте для своего поставщика услуг облачных вычислений (CSP). Если вы не хотите читать обширную документацию, мы советуем найти автоматизированное решение для обеспечения безопасности.
Первым на ум приходит инцидент, при котором в результате атаки на Capital One было раскрыто 106 млн заявок на кредитные карты. Компании пришлось заплатить штраф в размере 80 млн долларов США. Рассмотрим другие примеры нарушений, которых можно было бы избежать.
Hobby Lobby
В начале 2021 года были раскрыты данные компании Hobby Lobby. Проблему заметил независимый исследователь под псевдонимом Boogeyman. Он нашел на Amazon Web Services (AWS) открытую базу данных, содержащую конфиденциальную информацию более 300 000 клиентов Hobby Lobby — 138 ГБ данных, включая имена, адреса, номера телефонов и частичные данные карт. В той же базе данных обнаружился исходный код для приложения компании, что стало еще одной проблемой.
Причиной стала неправильная конфигурация облачной базы данных. Это явное нарушение правил PCI DSS 3, 7 и 9, поскольку данные платежных карт хранились на открытом сервере. Компания Hobby Lobby также не выполнила правило 10, в котором говорится, что доступ к данным о держателях карт и соответствующим сетевым ресурсам должен отслеживаться и контролироваться. Если бы правило было выполнено, компания смогла бы устранить ошибку конфигурации и избежать инцидента.
Macy’s
В октябре 2019 года у крупного ритейлера произошла утечка данных — номеров, кодов безопасности и сроков действия кредитных карт. Пострадали клиенты, которые использовали онлайн-систему оформления заказов. Macy’s не назвали количество затронутых клиентов, но за апрель того года сайт ритейлера посетило 55,7 млн пользователей. На наш взгляд, проблемой является кража информации даже одного клиента.
Утечка произошла из-за целевой атаки Magecart, в результате которой вредоносное ПО было занесено на страницы оформления заказа и кошелька. Macy’s, очевидно, нарушили ряд правил PCI DSS, тем более что методы Magecart хорошо известны. В том году Macy’s стали одной из многих жертв наряду с FILA, Ticketmaster, British Airways и другими. Предыдущие атаки на других крупных ритейлеров должны были мотивировать Macy’s провести аудиты безопасности и устранить уязвимости в соответствии с требованиями PCI DSS.
Скотт Сарджант, вице-президент по управлению продуктами, является опытным техническим руководителем с более чем 25-летним опытом в поставке корпоративных решений в области кибербезопасности и ИТ.