Тема безопасности платежных приложений становится все более актуальной, и это не случайно. В последние годы вектор атак смещается вверх по модели OSI. К примеру, в отчете инцидентов Verizon за 2009 год констатируется, что 86% атак были направлены на веб-приложения и только 14% – на инфраструктуру. Одновременно растет количество обнаруженных уязвимостей в программном обеспечении. По данным лаборатории IBM X-Force за 2009 год, в ее базе насчитывается порядка 44 тыс. различных уязвимостей, и только исследовательским центром DSecRG было обнаружено порядка 150 уязвимостей в 2009 году, а в мире существуют десятки подобных центров.

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

     Что же крадут злоумышленники и какие данные им интересны? Этот вопрос был затронут в двух различных отчетах — компании Verizon и Trustwave. По их данным, в 85 и 98% случаев соответственно целью атаки были именно карточные данные. Эти цифры шокировали аналитиков. Обе компании провели еще два интересных исследования. Verizon осуществляла поверхностную проверку на соответствие стандарту PCI DSS компаний, у которых произошел инцидент, связанный с кражей данных. Была получена статистика, показывающая, на сколько процентов в среднем соответствовали компании различным требованиям PCI DSS. Самым последним в этом списке было требование № 6 (безопасность приложений), которому компании в среднем соответствовали на 5%. В отчете компании Trustwave зафиксировано, что ни одна из компаний, в которых произошел инцидент, не соответствовала полностью шестому пункту стандарта PCI DSS.

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

     К слову об инцидентах, прямые потери от них у финансовых структур в США составляют 7,5 млрд в год. В Англии потери от фрода, по данным APACS, составили порядка 500 млн долл. Что касается России, то и у нас цифры существенные. По данным АРБР, годовой ущерб от действий так называемых кардеров составляет порядка 30 млн долл. Это прямой ущерб, который не учитывает репутационные потери и последствия ухода клиентов.

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

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

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

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

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

Александр Поляков - технический директор компании Digital Security, руководитель исследовательского центра DSecRG (www.dsec.ru)