Стандарт PCI DSS: среда ДДК vs область проверки vs область применения стандарта
Анализируя перевод стандарта PCI DSS я столкнулся со следующим предложением, которое ввело меня в ступор:
The entity considers any cardholder data found to be in scope of the PCI DSS assessment and part of the CDE unless such data is deleted or migrated/consolidated into the currently defined CDE.
Недоумение по большей части вызвала вторая часть предложения, т.к. у меня не складывалась в голове картинка — как так получается, что обнаруженные ДДК становятся частью среды ДДК, пока они не объединены со средой ДДК… Бред какой-то…
Эти размышления заставили меня провести небольшое терминологическое исследование, где я пытался найти ответы на вопросы:
— как соотносятся область проверки и среда ДДК (она же «среда данных о держателях карт»)?
— как соотносятся область применимости требований стандарта (она же «область применения») и область проверки на соответствие стандарту (она же «область QSA-аудита», «область оценки», «область проведения аудита» и т.д.)?
— как в конечном итоге должно переводиться предложение, из-за которого я и впал в ступор?
Среда ДДК vs область проверки
В поисках ответа на этот вопрос я натолкнулся на любопытную англоязычную статью, перевод которой я и предлагаю Вашему вниманию.
<Начало статьи>
PCI DSS: мало проблем с определением области проверки? Сейчас добавим…
Оригинал: http://blog.anitian.com/pci-i-find-your-lack-of-scope-disturbing/Автор: Андрю Плато (Andrew Plato)
Вольный перевод: мой
Любой, кто тратил больше пары минут на выполнение требований стандарта PCI DSS неизбежно сталкивался с проблемой определения загадочной области проверки. Что такое «область проверки» в рамках стандарта PCI DSS? Как уменьшить эту область? Что входит в среду данных о держателях карт (среду ДДК) ?
На эти вопросы не всегда можно легко ответить. Для начала, нужно понять кое-какие важные отличия.
Многие люди считают, что среда ДДК и область проверки — это одно и то же. На самом же деле, среда ДДК и область проверки совсем необязательно совпадают.
Среда ДДК – это места, где присутствует ДДК. В такую среду может входить сервер, обрабатывающий транзакции; коммутатор, через который проходит трафик с ДДК; прочие системы, которые напрямую связаны с хранением, передачей или обработкой ДДК. Среду ДДК необходимо изолировать и сегментировать от остальной сети, и, как правило, это делается с помощью списков контроля доступа (ACL) на виртуальных ЛВС или, еще лучше, через межсетевые экраны. Изоляция среды ДДК является требованием стандарта.
Тем не менее, область проверки зачастую выходит за пределы среды ДДК, т.к. любая система, которая подключена к среде ДДК, тоже входит в область проверки. Это утверждение, взятое напрямую из текста стандарта, имеет огромное значение, и ключевыми словами здесь являются «подключена к». Любая система, которая подключена к среде ДДК, входит в область проверки и соответственно, должна соответствовать применимым требованиям стандарта. Это означает, что серверы, выполняющие важные функции управления, администрирования и мониторинга тоже входят в область проверки, даже если они находятся за пределами среды ДДК. Например, если у вас есть сервер в среде ДДК, который подключается к серверу Active Directory за пределами среды ДДК, то сервер Active Directory включается в область проверки. Возможно, он не будет входить в среду ДДК и, следовательно, не будет требовать изоляции, но он тем не менее будет входить в область проверки.
Таким образом, любой хост, подключенный к ДДК и находящийся под контролем Вашей организации, входит в область проверки.
Под подключениями может пониматься что угодно: это и обновления с сервера обновлений, и передача журналов в SIEM-систему, и связь с управляющими серверами, обслуживающими систему мониторинга целостности файлов. Всё это примеры хостов, которые входят в область проверки, но не являются при этом частью среды ДДК.
Для анализа таких соединений можно, например, посмотреть на списки контроля доступа или на правила межсетевого экранирования. Если устройство внутри среды ДДК связано с устройством внутри корпоративной ЛВС, то для выполнения требований стандарта это устройство должно быть включено в область проверки. Соответственно, для выполнения требований стандарта к защитным мерам, которые подлежат реализации на таком хосте, на нем желательно установить антивирусное ПО, систему журналирования, системы обновления и т.д.
Однако в правилах определения области проверки есть одно исключение – устройства, доступ к которым реализован через двухфакторную аутентификацию. Если хост подключается к среде ДДК, например, для удаленного администрирования или получения доступак к терминалу, и при таком подключении проходит двухфакторную аутентификацию, то подключаемый хост в область проверки не входит. Очень серьезное и полезное исключение. Это также очень полезный способ выкинуть из области проверки хосты, которым требуется доступ к системам, входящих в среду ДДК. Учитывая невысокую стоимость реализацию двухфакторной аутентификации, любому, кто сталкивается с выполнением требований стандарта, есть смысл обратить особое внимание на это исключение.
И еще один нюанс – стандарт не требует установки системы мониторинга целостности файлов на хостах за пределами среды ДДК. Если Ваша среда ДДК корректно изолирована и сегментирована, то система мониторинга целостности файлов на хостах за пределами среды ДДК не требуется (хотя эти хосты и входят в область проверки).
Именно эти нюансы стандарта PCI DSS делают задачу определения области проверки по настоящему важной. Многие компании не включают эти подключенные устройства в область проверки, а это в свою очередь может привести к очень неприятным сюрпризам, когда аудитор QSA внесет туда эти устройства.
Кстати, это еще раз подтверждает важность документирования и схематического отражения потоков данных в Вашей организации. Мы часто сталкиваемся с организациями, которые некорректно отражают на схеме потоки ДДК внутри сети. Стандарт PCI DSS требует, чтобы организации документировали и схематично отражали все потоки ДДК, а также всю среду ДДК и все подключенные к ней системы.
Если у вас возникают затруднения с определением области проверки, мы предлагаем Вам следующий план действий:
- Составить схему своих потоков данных в MS Visio. Подготовить четкие разъяснения о том, где именно ДДК поступают в сеть, куда они проходят, где сохраняются. Важно уметь учитывать все места в своей организации, где имеются ДДК.
- Определить свою среду ДДК. Подготовить точный список систем (вместе с сетевым оборудованием), которые напрямую связаны с обработкой ДДК.
- Изолировать среду ДДК через межсетевой экран. Весь входящий и исходящий трафик среды ДДК подлежит строжайшей фильтрации. Запретить любой дискреционный доступ. Каждое правило должно назначаться для отдельного хоста или группы хостов либо для отдельного порта или диапазона портов. На межсетевом экране среды ДДК не должно быть никаких правил с фильтром «any» (любой).
- Учесть каждую систему, подключение которой проходит через периметр среды ДДК. Все эти устройства входят в область проверки и должны соответствовать всем остальным требованиям стандарта, применимым для систем, входящих в область проверки.
После выполнения данного плана действий скорее всего у вас появится понимание того, что у вас входит в область проверки. Следующим этапом следует начать работать над реализацией на хосте защитных мер, требуемых для систем, входящих в область проверки. К таким мерам относятся:
- антивирусное сканирование и ведение журналов;
- мониторинг журналов;
- стандарты повышения надежности хоста, конфигурационный контроль хоста;
- управление уязвимостями;
- управление обновлениями;
- уникальные учетные записи для всех пользователей и приложений;
- политики, определяющие сложность пароля и порядок его сброса;
- система мониторинга целостности файлов (только для хостов, находящихся в среде ДДК);
- система обнаружения и предотвращения вторжений;
- тестирование на проникновение.
У нас для Вас есть хорошие новости — здесь тоже есть множество вариантов, как можно сократить область проверки на соответствие стандарту PCI DSS. Однако будьте осторожны, прибегая к решениям, где обещается по быстрому сделать соответствие — нередко в таких решениях делается размах на рубль, а выхлоп — на копейку.
<Конец статьи>
Область применимости требований vs область проверки
Итак, про область применения неплохо написал Сергей Шустиков из компании «Дейтерий», поэтому изобретать велосипед не буду, просто процитирую его:
…следует также различать области QSA-аудита от области применимости требований стандарта PCI DSS. Заметим, что для многих организаций эти области совпадают, однако исключением из этого правила являются банки, которые осуществляют в своей информационной инфраструктуре как процесс эквайринга платежных карт, так и процесс их эмиссии, обрабатывая при этом карточные данные. Поэтому область применимости требований стандарта PCI DSS для банков — это компоненты как из эквайринговой части инфраструктуры, так и из эмиссионной. Таким образом, везде, где есть хотя бы один номер карты (PAN) — неважно, «своей» карты, или карты, эмитированной другим банком, — применимы требования стандарта PCI DSS.
С областью же QSA-аудита ситуация не так однозначна. На сегодня порядок таков: эквайринговая часть инфраструктуры, то есть те компоненты, где хотя бы теоретически может быть обработан, передан или сохранен номер карты, эмитированной другим банком, обязательно входит в область QSA-аудита. Эмиссионная же часть — т. е. все компоненты, где обрабатываются только номера «своих» карт, включается в область QSA-аудита по желанию аудируемого банка.
Мой вариант перевода злосчастного предложения:
The entity considers any cardholder data found to be in scope of the PCI DSS assessment and part of the CDE unless such data is deleted or migrated/consolidated into the currently defined CDE.
Организация включает любые обнаруженные ДДК в область оценки на соответствие стандарту PCI DSS и в среду ДДК, если только эти данные не будут удалены или не будут перенесены в заданную на текущий момент среду ДДК, или объединены с ней.
С уважением,
Евгений Бартов,
Руководитель ГК «Альянс ПРО»,
маркетолог, копирайтер, переводчик.
Оставить сообщение