Как пройти сертификацию PCI DSS: опыт ИТ-ГРАД

В одном из прошлых постов мы отметили, что успешно ресертифицировали свою инфраструктуру по PCI DSS и рассказали о видах хостинга PCI DSS: co-location, IaaS Basic и IaaS Advanced. Сегодня мы подробнее поговорим о самом процессе сертификации и собственном опыте прохождения аудита.

/ фото NTNU CC

Кому нужно проходить сертификацию

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

Суть её заключается в том, что руководству организации достаточно ответить на эти вопросы:

1. Компания работает с ПД держателей карт?
2. Влияют ли рабочие процессы компании на сохранность и защищенность данных карт?

Если ответ на оба эти вопроса положительный, то компании нужно проходить сертификацию. За несоблюдение требования PCI DSS, организация обязана заплатить штраф в размере от 10 до 200 тысяч долларов, в зависимости от:

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

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

Далее мы расскажем, как проходил этот процесс.

Этап 1: подготовка документации

Перед тем как пройти аудит, компания должна подготовить нормативно-распорядительные документы по ИБ (инструкции, регламенты, политики). На момент первой сертификации большинство из них уже были нами разработаны, но некоторые все же пришлось дорабатывать.

Например, нам пришлось править политику, которая содержит цели, задачи и способы обеспечения информационной безопасности на предприятии. Мы также корректировали регламенты, определяющие принципы управления уязвимостями и инцидентами. Например, мы сформировали «Регламент управления доступом к информационным активам» — в нем описаны правила работы с правами доступа и требования к учетным данным пользователей.

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

Этап 2: построение ИТ-инфраструктуры

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

Для этого нам пришлось организовать отдельную инфраструктуру с выделенной сетью, развернуть серверы ESX, vSphere и vCenter, установить свитчи и сетевой экран, чтобы предотвратить атаки злоумышленников. Всё это оборудование мы задублировали, а затем составили схемы сервисов, сети и бизнес-процессов.

Сертифицируемая инфраструктура должна быть отделена от других сетей организации — доступ к ней обязан предоставляться через изолированный интерфейс. Чтобы выполнить это требование, мы используем VPN с 2FA и изолируем сегмент каждого клиента.

Внутри периметра располагается NTP-сервер, сервисы логирования, антивирус, файрвол, а также решения для предотвращения кибератак и контроля сохранности данных. Схему нашей сети можно посмотреть здесь.

Этап 3: прохождение пентеста

Пентест проводит специальная команда от лица аудиторской компании. Аудиторы проверяют работу решений, которые применяются для защиты данных владельцев карт, и выявляют потенциальные «дыры» в безопасности.

Перед тем как начать проверку инфраструктуры на устойчивость к проникновению, наша команда подготовила два скопа. Первый со служебными сервисами и приложениями, участвующими в тестировании. На второй была настроена ВМ с ОС, назначены необходимые права соответствующим учетным записям.

/ Пример скопа с размещенными сервисами и приложениями

Пентест нашей инфраструктуры проводился в несколько этапов.

Сканирование утилитой nmap

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

Подключение по VPN и проверка внутренней сети

Пентест-команда попыталась получить доступ из недоверенной сети. Результаты теста показали, что проникнуть в инфраструктуру «ИТ-ГРАД» по VPN без 2FA нельзя. Проверка внутренней сети также не выявила нарушений.

Попытка доступа подключения к инфраструктуре по учетной записи

На стороннем ресурсе (этим ресурсом был iaas-blog.it-grad.ru) эксперты получили учетные данные одного из наших коллег. Этот коллега также имел учетку в тестируемой инфраструктуре «ИТ-ГРАД». Аудиторы попытались авторизоваться, используя его аккаунт и пароль, но у них это не получилось, так как сеть была достаточно сегментирована.

Всего по итогам проверки у нас обнаружили 7 уязвимостей разной степени критичности: одну высокого и по 3 среднего и низкого уровня «опасности».

Наша самая критичная уязвимость — неправильная работа WAF — возникла из-за того, что используемый межсетевой экран не справлялся со сложными атаками. Для того чтобы устранить уязвимость мы развернули веб-сервер Apache с модулем Modsecurity, а затем обновили БД сигнатур WAF.

Уязвимостей среднего уровня было три. Первая — включенный метод TRACE, который злоумышленники могут использовать, например, для межсайтового скриптинга. Чтобы устранить уязвимость, мы деактивировали метод TRACE.

Второе несоответствие — отсутствие безопасных HTTP-заголовков. Уязвимость может стать причиной атак злоумышленников на пользовательский интерфейс. Эту задачу мы решили с помощью включения безопасных заголовков на соответствующем сервере приложений.

И третья уязвимость — незащищенность программного обеспечения на одном из хостов (из-за устаревшей версии ПО). Для устранения этой уязвимости мы настроили регулярные обновления ПО на всех узлах.

Среди уязвимостей низкой критичности аудиторы обнаружили тестовые данные с хэшами паролей в продакшн-среде. Нам также указали на ненадежные пароли и лишнее ПО. Мы заменили уязвимые пароли на безопасные и удалили неиспользуемые данные и программное обеспечение. После исправления всех уязвимостей, мы успешно прошли повторный пентест.

Этап 4: финальный аудит

На последнем этапе проверки аудитор оценивает комплектность и параметры ПО и железа, топологию сети, конфигурацию ОС, изолированность сегментов инфраструктуры и другие характеристики. Кроме того, он может проверить документацию и знания сотрудников, задать вопросы организационного или технического характера.

Если у вашей компании обнаружатся незначительные отклонения от требований стандарта, их можно устранить во время аудита. Например, у нас нашли неактивную учетную запись компьютера в Active Directory, которую мы оперативно удалили.

Если вам потребовалось что-то поменять до или во время аудита, это тоже не проблема. Главное здесь — вносить изменения так, как этого требует PCI DSS.

Например, перед аудитом нам в «ИТ-ГРАД» понадобилось отследить загрузку и выгрузку файлов на SFTP-сервере. Для этого мы должны были срочно написать декодер для сервера avusm. Без декодера сервер не сохранял нужные сообщения, поскольку не мог «разбирать» логи и формировать оповещения.

В конечном счете мы получили сертификат соответствия требованиям PCI DSS и стали одним из первых IaaS-провайдеров в России, который оказывает услугу хостинга PCI DSS.

---

P.S. Несколько материалов по теме из Первого блога о корпоративном IaaS:

• Облачная услуга «PCI DSS хостинг»
• На что обратить внимание при выборе услуги облачного PCI DSS хостинга
• Подводные камни при сертификации по PCI DSS: CVV и запись телефонных разговоров
• Платежные системы и шлюзы о сертификации PCI DSS, аутсорсинге и облаках

Автор: it_man

Источник