Google+
Журнал Плас Плас Журнал http://www.plusworld.ru/
ул. Кржижановского, д. 29, корп. 5 Москва, 117218 Россия
+7 495 961 1065 http://www.plusworld.ru/upload/templates/logo_plus_ru.png
RSS RSS RSS RSS

Безопасность платежных приложений и стандарт PA-DSS

(Нет голосов)

28.06.2010 Количество просмотров 1212 просмотров

Александр Поляков, руководитель направления аудита ИБ компании Digital Security, QSA, PA-QSA
В одном из прошлых номеров журнала «ПЛАС»* мы уже обращались к рассмотрению требований стандарта PA-DSS с точки зрения тех задач, которые встают перед банком-эквайером. В настоящей статье изложены проблемы безопасности бизнес-приложений в целом и, в частности, платежных приложений в рамках стандартов PCI DSS и PA-DSS, а также рассмотрены основные предпосылки появления на свет PA-DSS, его особенности, назначение и преимущества, обеспечиваемые достижением соответствия стандарту.
Об Авторе
Александр Поляков, QSA, PA-QSA, руководитель направления аудита ИБ компании Digital Security. Специализируется на проведении аудитов защищенности, тестов на проникновение, анализе защищенности бизнес-приложений и исследовательской деятельности в области информационной безопасности. Является известным экспертом в сфере безопасности бизнес-приложений таких производителей, как Oracle и SAP, обнаружившим и опубликовавшим информацию о большом количестве уязвимостей в приложениях этих производителей. Один из основателей и руководитель исследовательского центра Digital Security Research Group (DSecRG), занимающегося поиском и анализом уязвимостей приложений и операционных систем. Автор ряда статей и исследований по информационной безопасности, автор книги «Oracle глазами аудитора: нападение и защита».

Что происходит?

Тема обеспечения безопасности бизнес-приложений давно входит в приоритетные направления деятельности компании Digital Security, и это не случайно. В последние годы вектор атак смещается вверх по модели OSI. Если в предыдущем десятилетии были особенно актуальны проблемы безопасности сетевого уровня, атаки на сеть, IT-платформы и операционные системы, то в последние годы вектор заметно смещается в сторону приложений. Соответственного мнения придерживаются и зарубежные компании, к примеру, в отчете инцидентов Verizon [1] за 2009 г. 86% атак были направлены на web-приложения, и только оставшиеся 14% – на сетевую инфраструктуру. С другой стороны, количество обнаруженных уязвимостей в программном обеспечении ежегодно растет. По данным лаборатории IBM X-Force [2] на 2009г., в ее базе насчитывается порядка 44000 различных уязвимостей. Так, одним лишь исследовательским центром DSecRG [3] в 2009г. было обнаружено порядка 150 уязвимостей, а в мире оперируют десятки подобных центров. Кроме того, существует огромный черный рынок уязвимостей и исследователей, которые продают соответствующие данные, при этом информации о таких уязвимостях пока нет в публичном доступе. Таким образом, проблема безопасности приложений сегодня стоит довольно остро.

Если перейти от более общей проблемы к платежной среде и рассмотреть подробнее статистику, отражающую, какие системы чаще всего подвергаются атакам (Отчет Verizon), то это будут: POS-терминалы (32%), СУБД (30%), серверы приложений (12%), web-серверы (10%). На рабочие станции, серверы аутентификации, серверы резервного копирования, файловые хранилища и прочее выпадает в общей сложности не более 10%. Данная статистика также наглядно отражает актуальность обеспечения безопасности именно приложений, так как через их уязвимости чаще всего становится возможным получение злоумышленниками доступа к данным.

Что же выбирают злоумышленники в качестве основных целей, какие именно данные им интересны? Данный вопрос был освещен в двух различных отчетах компаний Verizon [3] и Trustwave [4]. По их данным, в 85% и 98% случаях, соответственно, целью атаки были именно данные держателей карт – статистика, которую можно без преувеличения назвать шокирующей. Данными компаниями были проведены еще два интересных исследования. Verizon [3] проводила поверхностную проверку на соответствие стандарту PCI DSS компаний, у которых произошел инцидент, связанный с кражей данных. В результате этих проверок была получена статистика, показывающая, на сколько процентов в среднем соответствовали такие компании различным требованиям стандарта PCI DSS. Самым последним в этом списке было требование 6 («Обеспечение безопасности приложений»), которому компании в среднем соответствовали на 5%. В свою очередь, результаты отчета Trustwave [4] показали, что ни одна из компаний, в которой произошел инцидент, не соответствовала полностью пункту 6 стандарта PCI DSS, отвечающему за безопасность приложений.

Картина, открывающаяся в свете этой статистики, парадоксальна. С одной стороны, «Обеспечение безопасности приложений» – одно из наименее часто выполняемых требований, с другой – через уязвимые приложения происходит большинство инцидентов: такое положение вещей странно со стороны компании, если она действительно пытается защитить свои данные, но вполне логично со стороны злоумышленников.

Если бы вы спросили у злоумышленника, как украсть деньги, он бы без тени сомнения ответил: «естественно, через уязвимые приложения». Нельзя не согласиться с этим мнением, озвученным в статье на портале Pcworld [5], ведь действительно, какой смысл придумывать какие-то сложные схемы, если через банальную SQL-инъекцию в платежном приложении можно получить базы номеров карт. Данная атака была не раз продемонстрирована в ряде отчетов по инцидентам, даже в тех компаниях, в которых были выполнены требования стандарта PCI DSS.

К слову об инцидентах: прямые потери финансовых структур в США от инцидентов составляют 7,5 млрд долларов в год.

Для сравнения – это общая сумма стоимости порядка 50 небольших островов. В Великобритании потери от фрода, по данным APACS, составили в 2009г. порядка 500 млн долл. США [6]. Что касается России, то здесь объемы потерь аналогичных действий преступников также впечатляют.

По данным АРБР, годовой ущерб от действий карточных мошенников составляет порядка 30 млн долл. [7]. Следует учесть, что эти цифры отражают лишь прямые потери компаний, в которые не входят репутационный ущерб и ущерб от потери клиентов, а также возможная потеря бизнеса.

Например, если вспомнить всем известный инцидент с Heartland, то стоимость акций этой компании на Нью-Йоркской бирже упала в 10 раз за 1 неделю, а такие падения даже в нынешний глобальный кризис случались крайне редко.

Что делать?

Первым на помощь участникам рынка пришел документ Visa PABP, который являлся набором лучших на тот момент практик по безопасности платежных приложений и состоял из различных требований к приложениям такого рода. Тем не менее множество действительно важных требований, относящихся к безопасности, через которые и осуществляются атаки на приложения, в данном стандарте освещены не были. К таким требованиям можно отнести: удаление критичных данных после истечения максимально допустимого срока их хранения, хранение и передача паролей в зашифрованном виде, ряд требований по безопасному программированию, аудит управления изменениями и др.

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

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

На самом деле, разработчик ПО, проходя аудит по PA-DSS, получает ряд преимуществ. Во-первых, это возможность оставаться на рынке, так как после 1 июля 2012г. использование несертифицированных приложений компаниями, попадающими под действие стандарта PCI DSS, будет запрещено международными платежными системами Visa и MasterCard. Во-вторых, это повышение защищенности приложения, что само по себе стоит немалых денег, и которого гораздо выгоднее добиться в связке с сертификацией по PA-DSS, чем в рамках отдельной работы. В-третьих, это конкурентное преимущество на рынке, так как компании, выбирающие платежные приложения или собирающиеся поменять поставщика услуг, уже сейчас будут смотреть в сторону сертифицированных приложений. Ну и наконец, звучный прессрелиз и листинг приложения на сайте PCI SSC в списке сертифицированных приложений – это еще один шаг для повышения «веса» приложения на рынке.

В свою очередь, для компаний, попадающих под действие стандарта PCI DSS, преимущества использования сертифицированных по PA-DSS приложений не менее очевидны. Во-первых, они также получают возможность оставаться на рынке после наступления даты, с которой выполнение требований стандарта становится обязательным, во-вторых, компания сокращает количество необходимых для выполнения требований PCI DSS, перенося их на разработчика приложений и минимизируя расходы на соответствие PCI DSS, в-третьих, компания получает руководство по безопасному внедрению (Implementation Guide), которое также помогает ей привести свою систему в соответствие стандарту PCI DSS. И наконец, в-четвертых, что наиболее важно, – компания получает гарантированно безопасное приложение, тем самым существенно снижая риск компрометации данных держателей карт.

Следует отметить, что сертификация приложений по PA-DSS отнюдь не формальный процесс. За ним стоит реальный аудит на наличие программных уязвимостей с применением общепризнанных методик, таких как OWASP и WASC. Стоит отметить, что аудит на наличие программных уязвимостей – это вовсе не только статический анализ кода стандартными утилитами на наличие типовых строк, таких как «strcpy», указывающих на возможное наличие уязвимости переполнения буфера, и не только blackbox fuzzing с использованием типовых программных средств. Это еще и глубокий интеллектуальный анализ бизнес-логики приложения и поиск соответствующих уязвимостей в процессе анализа реальной работы приложения. Как следует из опыта исследовательского центра DSecRG в области анализа защищенности бизнес-приложений, значительная доля уязвимостей относится именно к категории логических ошибок, которые не обнаруживаются стандартными утилитами, что также подтверждается зарубежными компаниями в их отчетах. В рейтинге TOP-10 уязвимостей, составленном компанией Cenzic [8] (разработчик сканера для поиска уязвимостей в web-приложениях), на втором месте (22% уязвимостей) находятся логические уязвимости, связанные с контролем доступа, а в аналогичном рейтинге компании Trustwave логические ошибки занимают второе место, а третье и четвертое принадлежит ошибкам авторизации и аутентификации. Для поиска ошибок такой категории в отличие от переполнений буфера и различных инъекций кода не существует программных средств, полностью автоматизирующих данный процесс, поэтому уповать можно только на опыт конкретного эксперта в области анализа защищенности приложений.

И, естественно, самый главный мотиватор – это официальные сроки, установленные платежными системами. Условия Visa таковы: начиная с 1 июля 2010 г.

вновь подключаемые к эквайерам торгово-сервисные предприятия должны использовать только сертифицированные по стандарту PA-DSS платежные приложения, в противном случае эти предприятия должны быть сертифицированы по PCI DSS. Начиная с 1 июля 2012 года эквайеры должны гарантировать, что все находящиеся у них на обслуживании торгово-сервисные предприятия, а также агенты используют только сертифицированные по стандарту PA-DSS платежные приложения. Условия MasterCard немного мягче. Они требуют, чтобы с 1 июля 2012 года все торгово-сервисные предприятия и поставщики услуг использовали только сертифицированные по стандарту PA-DSS платежные приложения.


Полный текст статьи читайте в журнале "ПЛАС" 5 (157) ’2010 сс. 30-33

Комментарии (0):

Добавлять комментарии могут только зарегистрированные Пользователи


Читайте в этом номере:
обновить

а вы знаете, что...

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