PCI DSS PA-DSS Статьи Блог Форум О Сообществе PCI DSS Russia Семинар


PCI DSS
Тэги
инцидент (371)
в мире (318)
исследования (293)
банки (246)
ДБО (240)
malware (176)
сообщество (114)
конференция (109)
статистика (100)
кража (95)
утечка данных (88)
digital security (77)
законодательство (58)
carders (54)
visa (47)
банкоматы (46)
соответствие (40)
mastercard (40)
pci dss (37)
phishing (35)
выполнение требований (31)
стандарт (29)
blackhat (25)
skimming (24)
pci ssc (18)
pci dss russia (18)
аудит (16)
pa-dss (16)
insider (15)
социальная инженерия (15)
dsecrg (14)
биометрия (13)
сертификация (12)
authentication (12)
pin (11)
вебинар (11)
публикации (9)
инфографика (6)
mobile (6)
пентест (5)
СТО БР ИББС (5)
oracle (4)
erp (4)
полезные советы (4)
cash (4)
область аудита (3)
шифрование (3)
обновления (3)
atm (3)
вредные советы (2)
документация (2)
sap (2)
бизнес-приложения (2)
owasp (2)
asv (1)
итоги (1)
мнение (1)
фишинг (1)
банк (1)
исследвания (1)
конференции (1)
Урасльский форум (1)
Самые комментируемые за месяцСамые комментируемые за месяц

Опросы
Где расположена ваша информационная инфраструктура?

В собственной серверной комнате
На арендованной площадке в дата-центре
В арендованной у дата-центра виртуальной среде

 
FAQ:
PCI DSS & PA-DSS


Что такое PCI DSS и PA-DSS? Ответы на главные вопросы.
Путь к соответствию PCI DSS

Выполнение требований стандарта и разработка компенсирующих мер.
Проверка
соответствия


Правила проверки соответствия компании требованиям стандартов и контакты тех, кто проверяет.
Копилка
полезностей


Здесь можно скачать стандарты PCI DSS и PA-DSS на русском языке и другие полезные материалы.
Главная Блог Блог

Open Source и PA-DSS

Можно ли говорить о том, что приложения электронной коммерции с открытым исходным кодом, такие как Magento Community, VirtueMart, Ubercart, Zen Cart и другие, еще долго не смогут пройти PA-DSS сертификацию, поскольку, в силу своих особенностей, они свободно модифицируемы и расширяемы плагинами? Означает ли это то, что приложения должны быть защищены от модификации путем шифрования исходного кода для того, чтобы они удовлетворяли требованиям PA-DSS?

14 основных требований, соблюдаемых при PA-DSS Compliance:

• приложение не должно сохранять данные с магнитной полосы карты, значения CAV2, CID, CVC2, CVV2 или PIN-блок;
• должно защищать хранящиеся данные о держателе карты;
• должно обеспечивать безопасную аутентификацию;
• активность платежного приложения должна регистрироваться;
• должна обеспечиваться разработка безопасных платежных приложений;
• должна обеспечиваться защита при беспроводной передаче;
• должно проводиться тестирование платежных приложений на наличие уязвимостей;
• способствовать построению безопасной сети;
• данные о держателях карт никогда не должны храниться на сервере, имеющим прямое соединение с сетью Интернет;
• должно обеспечиваться безопасное удаленное обновление ПО;
• должен обеспечиваться безопасный удаленный доступ к платежным приложениям;
• должно применяться шифрование критичных аутентификационных данных, таких как при их передаче через общедоступные сети;
• должно применяться шифрование при удаленном административном доступе;
• должна обеспечиваться поддержка учебной документации и обучающих программ для клиентов, партнеров и интеграторов;

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

Документация по «opensource» программам, как правило, доступна только в  сети Интернет, и может быть, в лучшем случае, неполной. Обычно акцент делается на установке и основных правилах эксплуатации. Согласно требованиям PA-DSS и PCI DSS, необходима документация о правильной инсталляции программы, чтобы убедиться в том, что процесс соответствует PCI DSS. Документация «opensource» решений может и не включать в себя такую информацию.

Одним из самых больших препятствий для открытого ПО будет необходимость документирования цикла разработки данного ПО (SDLC — System Development Life Cycle). Если документация по эксплуатации может быть неполной, то документации по разработке открытого ПО обычно не существует. В результате получается невозможность соответствия требованию SDLC.

Также существует проблема тестирования ПО и подготовки соответствующей документации. Конечно, разработчики свободного ПО проводят тестирование перед его выпуском, но этот процесс еще должен быть документирован в соответствии со стандартом PA-DSS.

А какая организация будет ручаться за приложение? Большинство «opensource» проектов юридически не существуют, в результате, с технической точки зрения, они не могут быть представлены для PA-DSS сертификации. Кому брать на себя ответственность за такой продукт? Кто будет платить за сертификацию? Ведь большинство таких проектов разрабатывается энтузиастами и, понятно, что никто из них не станет платить тысячи долларов для того, чтобы этот продукт был сертифицирован по стандарту PA-DSS.

Наконец, если предположить, что такой открытый продукт получил сертификат PA-DSS, то как узнать, что он будет нетронутым, не модифицированным другими разработчиками? Это значит, что распространять такой продукт надо безопасным образом. То есть организации необходимо иметь свой пункт для безопасного распространения продукта, а значит, такой софт будет доступен не всем. Конечно, возможно использовать алгоритмы хэширования, чтобы подтвердить немодифицируемость версии, однако «opensource» организации придется инвестировать дополнительные средства в безопасность такой системы распространения.

Сообщение в Twitter от ducomputergeek:

«Мы создали новую ветку продукта, потому что нам прямо сказали, что оригинальная версия не может быть сертифицирована по PA-DSS и кажется, посчитали, что стандарт к нему не применим. Сейчас мы проходим сертификационный процесс. Технические изменения в ПО для соответствия требованиям PA-DSS были минимальны и заняли всего пару недель. 5 месяцев написания необходимой документации и мы вскоре будем проходить проверку».

В заключении следует отметить, что стандарт PA-DSS направлен на коммерческое ПО. Возможно, организации начнут выпускать сертифицированные «opensource» приложения, однако такие программы будут доступны только на платной основе. В качестве примера можно привести концепцию Linux версий компаний Red Hat и Novell.

Источники:

http://pa-dss.blogspot.com/2010/04/pa-dss-and-open-source-applications.html

http://slashdot.org/submission/1227990/PA-DSS-and-Opensource-Applications?from=rss&utm_source=twitterfeed&utm_medium=twitter

http://pciguru.wordpress.com/2010/04/10/open-source-pa-dss-certification/

соответствие | сертификация | стандарт | pa-dss
КомментарииКомментарии

Добавьте комментарий!
Представьтесь, пожалуйста
Укажите адрес вашей почты
Опубликован не будет
Следить за дискуссией по почте
 











Партнеры