2016-11-17 12 views
0

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

Это поразило меня, как потенциального минного поля PCI:

  • В нажатия клавиш собираются в тот же процесс, как и остальные приложения точка-оф-продажи и WebBrowser также обеспечивает в процессе DOM перехватывает
  • Я не уверен, что это означает для проверки сертификата HTTPS в случае MitM с отдельной машины
  • Возможно, другие вещи, о которых я не знаю, так же важны. (Устаревшие протоколы и алгоритмы?)

Уверенный, что в автономном веб-браузере могут быть некоторые из этих же проблем, но, по крайней мере, это не будет зависеть от кода приложения. Я бы не хотел, чтобы ревизия PCI имела проблемы с чем-то, не связанным в кодовой базе, только потому, что она имеет кодовую базу с платежной записью.

Я переусердствую это, потому что это только метод резервного копирования, который будет использоваться, если устройство чтения карт памяти не работает? Каков стандартный способ обращения с этим?

+0

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

+0

Как я уже сказал, я думал, что автономный веб-браузер может быть * более безопасным для PCI, чем [WebBrowser приложения] (https://msdn.microsoft.com/en-us/library/system.windows.controls.webbrowser .aspx), не менее. Я бы не хотел, чтобы ревизия PCI имела проблемы с чем-то, не связанным в кодовой базе, только потому, что она имеет кодовую базу с платежной записью. Я прошу учиться. :) – jnm2

+0

Извините, теперь я вижу, где вы спрашивали о встроенном управлении браузером. Является ли браузер встроенным в ваше приложение? –

ответ

1

Если вы были проверены, аудитор будет обращать внимание на следующие основные вещи:

  1. Как часто встроенный браузер обновляется производителем? Как он получает обновления? Будет ли оно получать/развертывать автоматические обновления? Или вам придется повторно развертывать приложение, когда обнаружен/исправлен критический недостаток безопасности? Как вы управляете этими обновлениями? Если обновления автоматические, как вы оцениваете их после того, как они находятся в prod? Если вам нужно перераспределить приложение, как вы сможете его развернуть пользователям? Как вы будете уверены, что все пользователи будут обновляться с небезопасных версий до защищенных версий? Как часто их подталкивают? У вас есть хороший набор процессов для управления между обновлением настолько часто, что ваши пользователи никогда не знают, что они собираются открывать и обновлять так редко, что вы используете чрезвычайно уязвимое программное обеспечение?

  2. На практике (особенно если вы подвергаетесь аудиту после нарушения), встроенный браузер полностью обновлен для защиты от исправленных угроз безопасности?

  3. Поддерживает ли встроенный браузер защиту от угроз, основанных на браузере, таких как накопитель при загрузке? Будет ли ваше антивирусное решение работать со встроенным браузером? Ты уверен? Как вы это протестировали?

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

Для таких вещей, как атаки MITM, я не совсем уверен, что понимаю ваш вопрос. Встроенный браузер был бы столь же уязвим, как и обычный браузер для MITM, хотя некоторые обычные браузеры имеют более высокую защиту от людей в средних атаках.Например, если ваш встроенный браузер был обновленной версией Google Chrome, я бы чувствовал себя намного более безопасным, чем если бы ваш встроенный браузер был версией IE 6, которая не видела обновления в этом десятилетии.

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

Скажем, например, что ваш процесс заключается в следующем:.

а) У эксперта по вашей команде сделать поиск уязвимостей каждую вторую пятницу. b.) Нанять внешнюю фирму, чтобы выполнить полную проверку уязвимости раз в квартал.

Вы должны были бы иметь записи:.

а) Кто ваш эксперт? Как она тренировалась? Является ли она квалифицированной для сканирования уязвимостей? Если она обнаруживает уязвимость, как она обостряется? Какие даты она выполнила сканирование? У нее есть распечатки результатов? Она заполняет форму своими выводами? У вас есть все формы? Могу ли я увидеть результаты сканирования уязвимостей, которые она выполнила 18 декабря 2015 года?

b.) Когда у вас есть профессиональные проверки, кто их выполняет? Как вы подтверждаете, что фирма квалифицирована? Как вы подтверждаете, что человек, который их сделал, квалифицирован? Что произойдет, если они обнаружат уязвимости? Что произойдет, если они обнаружат уязвимости, которые ваш собственный эксперт не находит? Могу ли я увидеть их последний отчет? Могу ли я увидеть отчет три четверти назад?