Digital Security N1 в аудите безопасности
  
На главную info@dsec.ru

Наши Партнеры
Статьи наших экспертов
ISO 17799: Эволюция стандарта в период 2002 - 2007
Илья Медведовский: «Информационной безопасностью заниматься придется. И лучше делать это рано, чем поздно»
Современные методы и средства анализа и управления рисками информационных систем компаний
Описание классификации угроз DSECCT
Репортаж с выставки Infosecurity 2004
Интервью Ильи Медведовского о информационной безопасности
Показательное проникновение
Методика оценки риска ГРИФ 2006 из состава Digital Security Office
Интервью Ильи Медведовского журналу "Хакер"
Интервью Ильи Медведовского о проблемах сетевых атак
Подготовка к аудиту – схема сети и матрица данных о держателях карт
С чего начинается безопасность?
Заказчик – Консультант – Интегратор
Настройка парольной политики в популярных ОС
Аудитор или консультант?
Настройка парольной политики в СУБД Oracle
5 основных проблем вашей инфраструктуры на пути к соответствию PCI DSS
Хранить нельзя удалять
Типовые проблемы SSL при прохождении ASV-сканирования
Процессы информационной безопасности
Заполнение матрицы данных о держателях карт, поиск PAN в системах
Подводные камни процесса достижения соответствия PCI DSS
Безопасность SCADA: Stuxnet – что это такое и как с ним бороться?
Безопасность банк-клиентов
PCI DSS - соответствие в пространстве
Безопасность платежных приложений и стандарт PA-DSS
Получение доступа к ОС, используя уязвимости сервера приложений Lotus Domino
Получение доступа к ОС при использовании уязвимости сервера приложений Apache Geronimo
Безопасность SAP: атаки на SAP-клиентов
Практика выделения области аудита PCI DSS
Основные мифы безопасности бизнес-приложений
PCI DSS как средство повышения уровня защищенности информационной инфраструктуры
Получение доступа к ОС, используя непривилегированную учётную запись в СУБД Oracle
Принципы проведения активного аудита информационной безопасности компании
Обход фильтрации загружаемых изображений в ряде Web-приложений для осуществления XSS атак
Управление инцидентами информационной безопасности
Повышение квалификации в области информационной безопасности
Практические аспекты применения ISO 27001:2005
Интервью Ильи Медведовского о сертификации по ISO 27001
Управление информационной безопасностью или модные тенденции на рынке ИБ
Некоторые вопросы безопасности в Oracle
Практические аспекты аудита
Информационная война - превращаем пользователей в союзников
Security Awareness Program. Программа повышения квалификации сотрудников
Получение доступа к ОС, используя уязвимости сервера приложений IBM Websphere
Различные способы получения SID базы данных в СУБД Oracle
Безопасность Oracle глазами аудитора: нападение и защита
Современные методы обучения сотрудников компании по вопросам информационной безопасности
Политика безопасности делает систему защиты эффективной
Как защитить компанию от сотрудников
Российские предприятия приобщаются к риск-менеджменту
Сертификация системы управления ИБ обеспечит эффективное управление информационными рисками
Рыночные регуляторы в обеспечении информационной безопасности
Все, что вы хотели знать о PCI DSS, но боялись спросить


Наши клиенты:



Обратите внимание:

PCI DSS


Поиск:

Сергей Шустиков
руководитель направления менеджмента ИБ компании Digital Security, PCI QSA

Область соответствия и область аудита

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

Для начала следует сказать, что есть разница между тем, какие системы должны соответствовать стандарту PCI DSS и тем, какие системы подлежат проверке в ходе QSA-аудита. Эти области не всегда совпадают.

Любая система, хранящая, обрабатывающая, либо передающая данные о держателях карт, должна соответствовать требованиям стандарта PCI DSS. Пусть даже если это PAN одной единственной карты. Эту область назовём термином «область соответствия».

Что касается области, подлежащей проверке на соответствие требованиям стандарта в ходе QSA-аудита, то для большинства организаций она совпадает с изолированной областью соответствия (средой данных о держателях карт, CDE). Назовём множество систем, подлежащее проверке, «областью аудита».

Однако для банков здесь не всё так просто. Позиция Совета PCI SSC изложена на его официальном сайте в разделе «Часто задаваемые вопросы». В ответе на вопрос «применим ли стандарт PCI DSS к эмитентам?» Совет сообщает следующее: «Стандарт PCI DSS применим ко всем сущностям, хранящим, обрабатывающим или передающим данные о держателях карт и все эти сущности должны соответствовать PCI DSS, включая эмитентов. Однако каждая международная платежная система применяет свою собственную программу управления соответствием PCI DSS, определяющую кто проверяет соответствие PCI DSS, уровни поставщиков услуг и торгово-сервисных предприятий, а также крайние сроки достижения соответствия. По своему усмотрению международные платежные системы могут потребовать у эмитентов проверить соответствие PCI DSS. Для уточнения детальных требований к проверке соответствия связывайтесь с международными системами».

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

Сложившаяся на рынке практика QSA-компаний, причем как российских, так и западных, предполагает следующий подход: соответствовать должны все системы, так или иначе связанные с данными о держателях карт, но проверке соответствия стандарту PCI DSS подлежит только эквайринговая часть платежной инфраструктуры, если речь идет о банке. Граница между эквайринговой и эмиссионной частью, которую, к слову, бывает очень непросто провести, проходит по обработке «On-Us» транзакций. Поток данных эквайринговой «On-Us» транзакции проверяется на соответствие стандарту, а всё, что связано с процессом выпуска карт, остается за рамками аудита. Безусловно, подразумевается то, что эмиссионная часть отделена от эквайринговой корректно настроенным межсетевым экраном, иначе эмиссия попадет в область аудита по формальному признаку связанной системы.

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

Минимизация области соответствия

Приводить в соответствие требованиям стандарта необходимо всю область соответствия, к которой относятся все системы, хранящие, обрабатывающие и передающие данные о держателях карт. При правильном подходе эту область можно значительно сократить. Вывести из неё информационные системы можно двумя основными способами:

  • исключение данных о держателях карт из отдельных систем, если это позволяют бизнес-требования;
  • изоляция области соответствия при помощи межсетевых экранов.

Исключение данных о держателях карт из отдельных систем

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

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

Принимая решение лишить ту или иную систему карточных данных, следует помнить о хранящихся в архиве носителях резервных копий этой системы. И если после внесения соответствующих изменений информационная система, которая отныне никак не связана с карточными данными, смело может не рассматриваться с точки зрения PCI DSS, то резервные копии из её «прошлой жизни» продолжают оставаться носителями данных о держателях карт. С ними следует обращаться по всем правилам PCI.

Изоляция области соответствия и внедрение DMZ

После того, как в перечне остались только те системы, которым работа с карточными данными необходима с точки зрения бизнеса компании, необходимо подумать об их изоляции. Дело в том, что по правилам, определенным в стандарте, в область аудита входят все системы хранящие, передающие или обрабатывающие данные о держателях карт, а также связанные с ними системы. Под связанными понимаются системы, соединения с которыми не защищены корректно настроенными межсетевыми экранами.

Особенно остро проблема выделения карточных систем в отдельный сегмент стоит в банках, которые имеют масштабные информационные инфраструктуры, часто бывающие распределенными территориально.

Среду данных о держателях карт по требованиям стандарта PCI DSS следует отделить от внешнего мира при помощи демилитаризованной зоны (DMZ). DMZ должна обеспечивать отсутствие прямых маршрутов между внешней средой и средой данных о держателях карт. С целью минимизации затрат на обеспечение соответствия PCI DSS, рекомендуется размещать DMZ непосредственно на границе среды данных о держателях карт и остальной сети организации.

На рисунке 1 приведен пример не рекомендуемой схемы изоляции среды данных о держателях карт, когда DMZ устанавливается на входе каждого канала связи с внешней средой. Терминалы торгово-сервисных предприятий и банкоматы могут подключаться к сети банка через его филиалы (каналы связи C-1, C-2 и C-3), и им требуется соединение с CDE. В этом случае на маршрутизаторе (межсетевом экране) R-2 потребуется открыть входящие соединения из сетей DMZ-1, DMZ-2, DMZ-3. Эти сети попадут в область аудита, так как будут являться связанными. Такое решение имеет право на жизнь, однако потребует от банка значительных ресурсов на достижение и поддержание соответствия. Филиалы, где расположены такие DMZ, придется приводить к соответствию PCI DSS, а аудитору придется их все обследовать в ходе QSA-аудита, что значительно повысит затраты банка.

Наоборот, внедряя DMZ непосредственно на границе DMZ и остальной локальной сети организации, мы можем вынести все офисы и филиалы за скобки аудита, как показано на рисунке 2. Доступ в CDE разрешен только из DMZ. При этом остальная сеть организации приравнивается к недоверенной и проходящий по ней трафик, содержащий данные о держателях карт должен быть зашифрован. Нарушение этого требования сразу же включит всю оставшуюся сеть компании в область аудита.

Рисунок 1. Не рекомендуемое решение


Рисунок 2. Рекомендуемое решение


наверх

+7 (812) 703-1547
+7 (812) 430-9130
© Digital Security, 2002-2012
При использовании материалов сайта
ссылка на источник обязательна