17 августа 2012, 16:17
Количество просмотров 140

PA-DSS vs разработчики, или Ожидает ли российские банки эпидемия взломов?

Статья посвящена перспективам внедрения стандарта PA-DSS, а также обеспечению информационной безопасности банковского ПО в целом –...
PA-DSS vs разработчики, или Ожидает ли российские банки эпидемия взломов?


Илья Медведовский, к.т.н., директор компании Digital Security
Статья посвящена перспективам внедрения стандарта PA-DSS, а также обеспечению информационной безопасности банковского ПО в целом – вопросам, которые периодически поднимаются на форуме Сообщества PCIDSS.RU.

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

Но если решение создается для продажи? В этом случае ситуация в целом крайне печальна (для клиентов, но не для производителей!), что, в частности, подтверждается нашими ежегодными исследованиями безопасности банк-клиентов (см. http://dsec.ru/press_releases/?news_id=223).

Подобное отсутствие интереса разработчиков к вопросам безопасности вполне логично – зачем разработчику тратить свои деньги на безопасность, если их решения покупают и так?!

Ниже приведена небольшая выдержка из нашего исследования за 2009–2010 годы: «Все, что было сказано и продемонстрировано в нашем небольшом исследовании, необходимо лишь для того, чтобы банки и разработчики ПО для банков поняли, что взламывать можно все, включая их собственные продукты. Сейчас очень важно поднять качество кода отечественного ПО, ведь найти ошибку, скажем, в системе банк-клиент сейчас гораздо легче, чем в популярном ПО западных разработчиков. Поэтому необходимо обращать внимание на такое положение дел, ведь злоумышленники тоже ищут эти уязвимости и используют их в своих целях, и мы должны максимально усложнить им эту задачу», – комментирует Алексей Синцов, ведущий аудитор компании Digital Security.

В целом за 2009–2010 гг. исследовательским центром DSecRG были обнаружены ошибки в коде большинства популярных банковских решений. Производители были своевременно уведомлены нами о данных уязвимостях и сообщили об их успешном закрытии и отправке обновлений всем клиентам».

Причем в данном случае речь идет не о глубоком исследовании (как в случае заказного платного тестирования продукта или системы), а не более чем о небольшой проверке в рамках волонтерской деятельности нашего исследовательского центра DSecRG – мы каждый год выделяем 3–5 чел/дней и проводим ознакомительное тестирование выбранных нами продуктов (1–2 дня на продукт). И результатом является 100%-ное проникновение в продукты, которые составляют ядро российской банковской индустрии! Это говорит не просто о печальной ситуации в области обеспечения банковской безопасности; это форменная катастрофа, когда серьезные уязвимости обнаруживаются через 1–2 дня поверхностного изучения продукта, и здесь нужно называть вещи своими именами. От настоящей эпидемии атак банки пока спасает только то, что пользователи защищены гораздо хуже, и поэтому основной вектор хакерских атак до сих пор направлен именно на пользователей. Но при таком, как показывает практика, халатном отношении разработчиков к вопросам безопасности это, поверьте, ненадолго.

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

Но, в любом случае, даже плохо сертифицированное приложение лучше, чем то, которое не проходило никакую проверку и выпущено разработчиком, которого вопросы безопасности вообще не волновали. Кстати, существует одна очень серьезная типовая проблема, связанная со стандартизацией в целом, и PA-DSS (как и PCI DSS) не является исключением: как только стандарт становится массовым, часто в течение короткого промежутка времени резко падает качество проводимой оценки. Причин множество: от вынужденной минимальной стоимости работ аудитора до слабости контролирующей инстанции. Эти причины приводят к появлению низкоквалифицированных аудиторов и откровенной халтуры, что мы довольно активно начинаем наблюдать уже сейчас, хотя Совет PCI SSC и пытается бороться с некачественным аудитом.

Резюмируя вышесказанное: не стоит надеяться, что разработчики продаваемых решений по своей воле займутся безопасностью – это утопия. Также не стоит считать PA-DSS панацеей или гарантией безопасности сертифицированного решения.

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

Учитывая актуальность поставленных в данном материале вопросов, журнал «ПЛАС» подолжит следить за развитием ситуации на страницах своих следующих номеров и информационном портале PlusWorld.ru

Рубрика:
{}
Теги:
#

PLUSworld в соцсетях:
telegram
vk
dzen
youtube