PCI DSS 1.1 и первый gap-анализ: что нашли в карточной инфраструктуре ретейлера

Клиент пришёл с конкретным вопросом: «Нам сказали, что мы должны соответствовать PCI DSS. Что это вообще такое и что нам грозит?» Сетевой ретейлер, несколько точек, собственные POS-терминалы, эквайринг через процессинговый центр. Карточные данные проходят через их систему - значит, стандарт Payment Card Industry Data Security Standard касается их напрямую.

Версия 1.1 - актуальная на сегодня - включает 12 требований, сгруппированных в шесть блоков: защита сети, защита данных держателей карт, управление уязвимостями, контроль доступа, мониторинг и тестирование, политика безопасности. Звучит разумно. На практике - это несколько десятков конкретных контрольных точек, и почти каждая из них требует либо технической реализации, либо документации, либо и того и другого.

Что мы сделали первым делом

Прежде чем лезть в настройки - составили карту окружения. Определили периметр CDE (cardholder data environment): какие системы хранят, обрабатывают или передают данные карт, какие к ним подключены, какие сети с ними пересекаются. Без этого gap-анализ превращается в гадание.

Карта получилась неожиданно широкой. Оказалось, что часть офисных машин технически находится в том же VLAN, что и серверы процессинга. Никто специально так не проектировал - просто сеть росла органически, и однажды всё оказалось в одной плоскости.

Три главных пробела

По итогам анализа приоритизировали находки. Три вещи оказались критическими - именно они формируют большую часть риска.

Первое - отсутствие сегментации карточной сети. Требование 1 PCI DSS прямо требует изолировать CDE от остальной сети с помощью межсетевых экранов. Сейчас CDE и корпоративная сеть - одно пространство. Любая скомпрометированная офисная машина имеет прямой маршрут к серверам процессинга. Это самый серьёзный пробел, устранение которого тянет за собой переработку сетевой архитектуры.

Второе - нет penetration test. Требование 11.3 обязывает проводить внешнее и внутреннее тестирование на проникновение не реже раза в год, а также после значимых изменений в инфраструктуре. У клиента сканирование уязвимостей было - Nessus запускали периодически, мы об этом писали применительно к другим проектам. Но сканирование и pentest - разные вещи. Сканер ищет известные уязвимости по сигнатурам; тестирование на проникновение проверяет, можно ли реально использовать найденное для достижения цели. Задокументированного pentest не было никогда.

Третье - логи хранятся меньше года. Требование 10.7 устанавливает минимальный срок хранения audit trail в 12 месяцев, из которых три - в оперативном доступе. У клиента логи ротировались через два-три месяца: диски не резиновые, и когда место кончалось - старые логи удалялись. Фактически при инциденте провести ретроспективный анализ за полгода было бы нечем.

Что нашли ещё

Помимо трёх главных пробелов - несколько менее критичных, но тоже требующих внимания:

• Политика паролей - требование 8 задаёт конкретные параметры: минимум 7 символов, смена раз в 90 дней, запрет повторного использования последних четырёх. Реальная политика была мягче.
• Управление патчами - требование 6.1 обязывает устанавливать критические патчи в течение месяца. Фактический цикл у клиента был примерно квартальным.
• Документация - по нескольким пунктам техническая реализация была вполне приличной, но без задокументированных процедур это не считается выполненным с точки зрения аудитора.

Что дальше

Составили план на шесть месяцев с расстановкой по приоритетам. Первые два - сегментация сети: проектируем выделенный VLAN для CDE, прописываем правила межсетевого экрана, изолируем. Это самое трудоёмкое и самое важное. Параллельно - переконфигурация хранения логов: централизованный сбор с достаточным объёмом, ротация в архив, а не в удаление. Третий-четвёртый месяц - ужесточение парольной политики, ускорение цикла патчинга, закрытие документарных пробелов. Пятый-шестой - первый pentest и финальная проверка.

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

Работа по аудиту и соответствию не заканчивается на gap-анализе - это точка старта, от которой понятно, куда и в каком порядке идти.