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 vs разработчики, или Ожидает ли российские банки эпидемия взломов?

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

19.05.2011 Количество просмотров 1232 просмотра

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


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

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


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

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

… предоплаченные платежные карты возникли как платежный инструмент в середине 1990-х гг., и первыми из них были карты Electronic Benefits Transfer (EBT) в США, на которые заменили ранее выдаваемые нуждающимся бумажные продовольственные сертификаты?