В данной статье прежде всего хотелось бы обратить внимание на важность безопасности приложений как таковых и платежных приложений в частности в рамках стандарта PA-DSS. Тема безопасности приложений давно входит в приоритетные направления деятельности нашей компании, и это не случайно. Последние годы вектор атак смещается вверх по модели OSI. Если раньше были актуальны проблемы безопасности сетевого уровня, атаки на сеть, платформы и операционные системы, то последние годы вектор заметно смещается в сторону приложений. Соответственного мнения придерживаются и западные компании, к примеру, в отчете инцидентов Verizon за 2009 год 86% атак были направлены на WEB-приложения и только оставшиеся 14 – на инфраструктуру. С другой стороны, количество обнаруженных уязвимостей в программном обеспечении ежегодно растет. По данным лаборатории IBM X-Force на 2009 год, в базе насчитывается порядка 44000 различных уязвимостей, и только исследовательским центром DSecRG было обнаружено порядка 150 уязвимостей в 2009 году, а в мире существует десятки подобных центров. Кроме того, существует огромный черный рынок уязвимостей и исследователей, которые их продают, и информации об этих уязвимостях нет в публичном доступе. Таким образом, проблема безопасности приложений сегодня стоит довольно остро.
Если перейти от более общей проблемы к платежной среде и рассмотреть подробнее статистику того, какие системы чаще всего подвергаются атакам (Отчет Verizon), то это будут: POS-терминалы (32%), СУБД (30%), серверы приложений (12%), web-серверы (10%). На рабочие станции, серверы аутентификации, серверы резервного копирования, файловые хранилища и прочее выпадает только 10%. Из данной статистики также наглядно видна актуальность безопасности именно приложений, так как через их уязвимости чаще всего становится возможным получение доступа к данным.
Что же крадут злоумышленники и какие данные им интересны? Данный вопрос был освящен в двух различных отчетах: компании Verizon и Trustwave. По их данным, в 85% и 98% соответственно, целью атаки были именно карточные данные. Честно говоря, цифры шокирующие. Еще два интересных исследования были проведены данными компаниями. Компания Verizon проводила поверхностную проверку на соответствие PCI DSS компаний, у которых произошел инцидент, связанный с кражей данных. В результате данных проверок была получена статистика, показывающая, на сколько процентов в среднем соответствовали компании различным требованиям стандарта PCI DSS. Самым последним в этом списке было требование 6 («Безопасность приложений»), которому компании в среднем соответствовали на 5%. В отчете компании Trustwave было показано что ни одна из компаний, в которой произошел инцидент, не соответствовала полностью пункту 6 стандарта PCI DSS, отвечающему за безопасность приложений. Что мы имеем в итоге, на самом деле парадоксально. С одной стороны, «Безопасность приложений» одно из наименее часто выполняемых требований, а, с другой стороны, через уязвимые приложения происходит большинство инцидентов, что странно со стороны компании, которая пытается защитить свои данные, но логично со стороны злоумышленника.
Если бы вы спросили у злоумышленника как украсть деньги, он бы без тени сомнения ответил: “Естественно через уязвимые приложения”. Нельзя не согласиться с этим мнением, озвученным в статье на портале Pcworld, ведь, действительно, какой смысл придумывать какие-то сложные схемы, если через банальную SQL-инъекцию в платежном приложении можно получить базы номеров карт. Данная атака была не раз продемонстрирована в ряде отчетов по инцидентам, даже в тех компаниях, в которых были выполнены требования стандарта PCI DSS.
К слову об инцидентах, прямые потери финансовых структур в США от инцидентов составляют 7.5 млрд долларов в год. Для сравнения эти потери составляют стоимость порядка 50 крупных островов. В Англии потери от фрода, по данным APACS, составили порядка 500 млн долларов. Что касается России, то цифры тоже существенные. По данным АРБР, годовой ущерб от действий кардеров составляет порядка 30 млн долларов. Это все были прямые потери компаний, в которые не входят удар по репутации и потеря клиентов, а также возможная потеря бизнеса. Например, если вспомнить всем известный инцидент с Heartland, то стоимость акций этой компании на нью-йоркской бирже упала в 10 раз за 1 неделю, а такие падения даже в недавний кризис случалась крайне редко.
После такого отнюдь не радужного вступления встает резонный вопрос - Что делать?
Первым на помощь пришел документ Visa PABP, который являлся набором лучших практик по безопасности платежных приложений и состоял из различных требований к платежным приложениям. Тем не менее, множество действительно важных требований, относящихся к безопасности, через которые и осуществляются атаки на приложения, не были освещены в данном стандарте. К таким требованиям можно отнести: удаление критичных данных после истечения максимально допустимого срока хранения данных, хранение и передача паролей в зашифрованном виде, ряд требований по безопасному программированию, аудит управления изменениями и прочее.
Следующим этапом в повышении безопасности платежных систем было появление стандарта PCI DSS, который, в отличие от PABP, стал обязательным и регламентировал выполнение требований по безопасности для систем, обрабатывающих карточные данные. В нем уже достаточно четко были прописаны требования, относящиеся к любым приложениям и системам, которые обрабатывают карточные данные. Тем не менее, данный стандарт был направлен на компании, осуществляющие обработку карточных данных, а не на приложения, что на практике породило множество проблем, мешающих компаниям достичь соответствия PCI DSS из-за приложений, которые не поддерживают эти требования или напрямую им противоречат. Ведь в случае если у приложения, которое использует компания, передаются пароли в открытом виде, необходимо «накручивать» дополнительные средства защиты в виде шифрования и оформлять компенсирующие меры; если не был проведен аудит на наличие программных уязвимостей, то необходимо приобрести и установить межсетевой экран уровня приложений, а если приложение, не дай Бог, хранит TRACK после авторизации, то компания и вовсе лишается возможности получить сертификат соответствия 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 и, наконец, в-четвертых, что наиболее важно – они получают безопасное приложение, тем самым существенно уменьшая риск компрометации данных.
Причем следует отметить, что эта безопасность не формальна. За ней стоит реальный аудит безопасности с применением общепризнанных методик, таких как OWASP и WASC на наличие программных уязвимостей. Стоит отметить, что аудит на наличие программных уязвимостей – это далеко не только статический анализ кода стандартными утилитами на наличие типовых строк, таких как strcpy, указывающих на возможное наличие уязвимости переполнения буфера, и не только blackbox fuzzing с использованием типовых программных средств, это еще и глубокий интеллектуальный анализ бизнес-логики приложения и поиск соответствующих уязвимостей в процессе реальной работы приложения. Как следует из опыта DSecRG по анализу защищенности бизнес-приложений, значительная доля уязвимостей относится именно к классу логических ошибок, которые не обнаруживаются стандартными утилитами, что также подтверждается известными западными компаниями в их отчетах. В списке TOP 10 уязвимостей, составленном компанией Cenzic (производитель сканера для поиска уязвимостей в WEB-приложениях), на 2 месте (22% уязвимостей) находятся логические уязвимости, связанные с контролем доступа, а в аналогичном списке компании Trustwave логические ошибки занимают второе место, а третье и четвертое принадлежит ошибкам авторизации и аутентификации. Для поиска ошибок такого класса в отличие от переполнений буфера и различных инъекций кода, не существует программных средств, полностью автоматизирующих данный процесс, поэтому уповать можно только на опыт конкретного эксперта в области анализа защищенности приложений.
И, естественно, самый главный мотиватор – это официальные сроки, установленные платежными системами. Условия Visa таковы: начиная с 1 июля 2010 года, вновь подключаемые к эквайерам торгово-сервисные предприятия должны использовать только сертифицированные по стандарту PA-DSS платежные приложения или быть проверены по PCI DSS. Начиная с 1 июля 2012 года, эквайеры должны гарантировать, что все торгово-сервисные предприятия и агенты используют только сертифицированные по стандарту PA-DSS платежные приложения. Условия MasterCard немного мягче. Они требуют, чтобы начиная с 1 июля 2012 года, все торгово-сервисные предприятия и поставщики услуг должны использовать только сертифицированные по стандарту PA-DSS платежные приложения.
3 февраля 2012
Алина Оприско
