Практически одновременно запущенно два сайта по PCI DSS: один от Информзащиты и второй от Digital Security.
Интересным оказалось наличие у аудиторов двух диаметрально противоположных взглядов на хранение PAN.
Если Digital Security достаточно категорично выступает против хранения PAN в открытом виде и предлагает использовать их хэш-значения, то Информзащита не видит ничего противоречащего требованиям PCI в хранении PAN в открытом виде в почтовых ящиках пользователей.
Цитировать и вырывать из контекста не хочу, лучше посмотреть оригинальные обсуждения.
14 комментариев:
Сергей, хочу уточнить, что никакого противоречия нет. На форуме, по приведенной Вами ссылке, Андрей Казимиров совершенно правильно заметил, что передача PAN по внутренней почте (прошу заметить - речь в его сообщении идет именно о передаче и именно по внутренней почте, когда почтовый трафик не выходит за пределы сегмента карточных данных), не нарушает требования 4.
При этом следует заметить, что если переданное письмо сохраняется на почтовом сервере, то к нему применимо требование раздела 3 о запрете хранения PAN в открытом виде во всех местах хранения.
Сергей, я себе совершенно не представляю передачу без хранения. Т.е. PAN долетел до почтового сервера/почтового клиента и испарился?
А я легко даже представляю. Передалося по сети PAN и - пыщь-пыщь - исчезл. У меня всегда так.
И вообще, что за неприкрытый PR Digital Security?
После передачи сообщение попадает на почтовый сервер или почтовый клиент на рабочей станции, и там сообщения с PAN внутри могут храниться в зашифрованном хранилище. Требование 3 выполнено.
>могут храниться в зашифрованном хранилище.
Откуда такая информация?
В сообщении ничего про зашифрованное хранилище на почтовых ящиках клиентов не говорится.
У меня, например, сложилось стойкое впечатление, что никаких возражений против использования корпоративной электронной почты для передачи PAN нет. Но ведь они есть! А именно - даже если передача - зашифрована, то при хранение должно использоваться шифрование.
Так ведь?
Требование 3.4 гласит (в оригинале):
"Render PAN, at minimum, unreadable anywhere it is stored... by using any of the following approaches:
- One-way hashes based on strong cryptography;
- Truncation;
- Index tokens and pads (pads must be securely stored);
- Strong cryptography with associated key-management processes and procedures."
Отсюда вывод - если PAN хранятся в сообщениях на почтовом сервере, то следует шифровать.
Подробнее здесь.
Сергей, ты явно не очень внимательно читал форум на pcisecurity.ru и видимо поэтому сделал неправильный вывод о том что QSA ИЗ ничего не имеют против хранения PAN в открытом виде в почтовых базах.
Там на самом деле речь шла только о передаче PAN по внутренней почте.
При этом не возбраняется использовать шифрование дисков, где хранятся почтовые архивы. Или просто удалять почту после обработки ( так делают многие)
вдогонку:
похоже что консул все же не одобряет пересылку незашифрованных PAN и во внутренней почте ( хотя в стандарте об этом не написано)
Can unencrypted PANs be sent over end-user messaging technologies like instant messaging or chat?
PCI DSS requirement 4.2 prohibits the sending of primary account numbers (PANs) via unencrypted email, whether sent internally or over public networks. Instant messaging and chat should be considered an alternative mechanism of email and thus required to meet PCI DSS requirement 4.2 Per PCI DSS requirement 4.1, strong cryptography and security protocols should be used when cardholder data is sent over open, public networks As a reminder, under no circumstances should sensitive authentication data such as the card validation codes and values (CAV2, CID, CVC2, CVV2) be stored after obtaining authorization.
http://selfservice.talisma.com/article.aspx?article=5388&p=81
Хотя в каждом случае конечно надо смотреть на реальный риск :)
Всем привет! Мне кажется, здесь не хватает моего комментария :)
"Сколько людей, столько мнений" - с этим сложно спорить, даже если речь идет о мнениях аудиторов QSA. Несмотря на то, что стандарт PCI DSS и процедуры оценки определенные в нем вполне конкретны, в каждом случае при вынесении заключения учитывается комплекс факторов, которые не могут быть описаны двумя-тремя строчками. И ответственность за принятое решение в каждом случае лежит на QSA. Для того же, чтобы разночтений было все-таки меньше и создана организация под названием "PCI Security Standards Council" разъясняющая требования стандарта, а аудиторы ежегодно подтверждают свой статус на тренингах и сертификациях QSA.
"наличие у аудиторов двух диаметрально противоположных взглядов на хранение PAN" - соглашусь с коллегами, которые высказались ранее – никакого противоречия не было, т.к. изначально речь шла о разных требованиях стандарта и о разных вопросах.
"вырывать из контекста не хочу" - хорошая была идея, правда не воплощенная в жизнь. В итоге Вы противопоставили два мнения, по совершенно разным требованиям PCI DSS, касающихся хранения данных и их передачи. Не корректно немного, но как способ активизации общения на собственной ленте очень даже неплохо )).
А теперь переходим к самому интересному. Maxus уже написал про разъяснение от Консула по пункту 4.2, так что риски рисками, но мы должны его учитывать. Подробный ответ см. нашем форуме.
Видимо, "консул" все же сложил 2+2 и согласился со мной ;)
>Отсюда вывод - если PAN
>хранятся в сообщениях
>на почтовом сервере,
>то следует шифровать.
А если сообщения хранятся не на сервере, а на клиентах?
Аккуратней надо, господа, аккуратней. Только и всего.
Сергей, нет разницы где хранятся сообщения - на сервере или на клиенте. PAN должен быть в нечитаемом виде в любом месте хранения. Если это рабочая станция - возможно использование шифрования жесткого диска.
Собственно об этом я и писал в блоге PCIDSS.RU:
"Что же касается хранения сообщений, содержащих PAN, на почтовом сервере или клиенте, то здесь в любом случае применимо требование 3.4, предписывающее приведение PAN в нечитаемый вид во всех местах его хранения, и тут без шифрования уже не обойтись."
>Сергей, нет разницы где хранятся сообщения
ВО! Добился!
Я собственно исключительно об этом и говорю. Что аккуратнее надо с публичными рекомендациями. Люди склонны понимать все достаточно прямолинейно и так как им это удобно. А потом при разборе сошлются на сайт ИЗ или DS и скажут, вот - нам аудиторы порекомендовали :)
Кстати, если вам однажды потребуется заблокировать какой-либо сотовый телефон или другое средство связи, то попробуйте использовать для этого Блокираторы мобильного.
Кстати, если вам когда-нибудь понадобится заглушить какой-либо мобильный телефон или другое средство связи, то попробуйте использовать для этого Блокиратор мобильного.
Отправить комментарий