Платим за взлом или как найти лучшего специалиста по информационной безопасности
Одна из тенденций современного мира IT направлена на всеобщее повышение интеллекта трудящихся в этой сфере людей: уже давно нет людей, которые ещё в начале, середине и даже конце 90-ых назывались словами типа "крутой программист" или "супер IT-шник": "универсальные программисты" начали вымирать с наступлением 21-го века и с тех пор практически исчезли с лица Земли: сейчас есть только java-девелоперы, C#-разработчики, админы UNIX, DBA и прочие буквенные сочетания из постоянно расширяющегося списка IT-профессий. Те же тенденции наблюдаются и в сфере информационной безопасности. Найти специалиста, который бы мог без труда находить ошибки buffer overflow в 10-модульной Си-шной программе и одновременно - улаживать любые проблемы с проверяющими из ФСТЭК в части 152-ФЗ, - это что-то из разряда произведений Джона Толкина. Даже универсальных технических специалистов, которые бы знали особенности и проблемы любой современной технологии найти почти нереально. Тогда как развитие IT-технологий и их повсеместное внедрение в критически важные сферы жизни ставит всё новые и более жёсткие требования к уровню их безопасности. Сталкиваясь со всеми этими бедами, современный европейский бизнес начинает искать новые способы защиты своих ИС. И находит их в так называемых Vulnerability reward program или, как их ещё называют, Bugs Bounty program - программах поощрения поиска уязвимостей (VRP-программах), представляющих собой революционный шаг в защите от уязвимостей в ПО.
Что же это за изобретение такое, как оно помогает защитить бизнес и стоит ли его внедрять? Рассмотрим вопрос подробнее...
Что же такое VRP?
Смысл и суть любой VRP-программы сводится к защите бизнеса компании (в особенности, если она производит собственное ПО), а именно - к привлечению к исследованией безопасности своего продукта или сервиса специалистов со стороны, в идеале - со всего мира. Естественно, таким специалистам надо платить. Конечно, есть энтузиасты, готовые работать бесплатно просто потому, что им интересен хакинг сам по себе, но, во-первых, таких немного; во-вторых, в лучшем случае они просто ничего не сообщат жаждущей улучшить свою ИБ копании, в худшем - взломают её, да ещё и прихватят с собой парочку know-how или денег со счёта. Потому платить надо и платить в соответствии с результатами: чем опаснее обнаруженная проблема, тем выше цена.
Итак, рассмотрим первопроходцев технологий vulnerability reward program - современных гигантов рынка IT: Google, Microsoft и Facebook.
Наиболее известна VRP-программа Google: http://www.google.com/about/appsecurity/reward-program/
Она включает в себя тестирование всех существующих web-сервисов знаменитого гиганта на предмет наличия в них всевозможных уязвимостей и предлагает за нахождение различных "дыр" хорошее пополнение Вашего дебитового лимита в банке. К примеру, после нахождения уязвимости типа SQL-injection Вы можете смело прикупить себе без доп. расходов 4-5 летнюю тойоту короллу (10 000$). А вот, если обнаружили ошибку, позволяющую исполнить произвольный код на уязвимом ресурсе, можете смело рассчитывать на новую короллу (20 000$). :) Вся классификация вознаграждений идёт с позиции типов найденных уязвимосгей: удалённое исполнение кода; SQL-инъекция; кража аутентификационной информации; XSS-атаки; XSRF и XSSI-уязвимости.
За Google-ом неразрывно следует Microsoft: http://www.microsoft.com/security/msrc/report/bountyprograms.aspx
Microsoft в своей тарифной сетке, в отличие от Google, не выделяет отдельных классов уязвимосгей - она платит за критичность найденной проблемы: чем выше опасность, тем дороже тачку Вы себе сможете приобрести. Надо заметить, что Microsoft в этом отношении имеет более выгодные расценки: если Вы - крутой кул-хацкер, то после нахождения парочки серьёзных дыр на сайте Microsoft сможете прикупить себе новенькую Bentley Continental или Porsche 911 GT3 (200 000$). Весьма неплохо для одного вечера (в некоторых случаях) работы! Стоит задуматься над сменой работы, а также своими занятиями на пенсии. :)
Следующая в рассмотрении Bugs Bounty program - Facebook: https://www.facebook.com/whitehat
Социальный гигант пошёл по пути Google и в зял за основу гугловскую же классификацию уязвимостей, разве что добавив к ней (а точнее, выделив из прочих) уязвимости повышения привилегий. Что же касается их прайс-листа, то ситуация туг неоднозначная. Они лишь ограничивают нижнюю планку, но ничего не говорят ни о конкретных классах, ни о верхней планке, позиционируя свою точку зрения очень элегантно: "There is no maximum reward: each bug is awarded a bounty based on its severity and creativity". Что тут сказать, от креативности в самом деле зависит очень многое. В том числе мысли о выгоде: получить единожды reward от Facebook или открыть бизнес по торговле аккаунтами всемирной социальной сети. :)
После описанных гигантов за ними подтянулись и такие крупные игроки, как Amazon, Agava и многие другие.
Внедрение VRP в реальную практику. Стоит или не стоит?
Описанные выше рассуждения и примеры программ вряд ли оставят кого-либо в сомнениях в части полезности и надобности подобных VRP-програм в современном IT-бизнесе, но полезность данных программ в практическом опыте российского IT-рынка уже не вызывает такого восторга, каким он бып на первый взгляд. Смысл применения таких программ, как и всего, что есть в мире информационной безопасности, основывается на простом анализе рисков: так ли критичны уязвимости в сервисах компании и её ПО? Превышают пи усреднённые финансовые потери от реальных взломов ПО / сервисов компании потенциальные расходы на выппату вознаграждений "умникам" со стороны? (а платить придётся всем, иначе такой экономной компании просто перестанут доверять и никто искать ошибки для них не будет, ещё и сломают всё до упора в качестве мести за жадность) Много ли дыр в предоставляемом ПО / сервисе? (от этого зависит копичесгво уязвимосгей и соответственно, вылат) Конечно, в условиях программы можно искусственно ограничить направпения поисков, но тем не менее указанные вопросы останутся актуальными. Требуется конкретный и чёткий анализ рисков на основе прошлого опыта работы: средние потери по каждому виду угроз; количество найденных/использованных уязвимосгей; потенциальные выплаты по каждому из направлений; возможные концепции VRP-программ. И уже после такого анализа следует принятие решения о применении ипи неприменении конкретной программы.
Кроме того, в VRP-программах есть ещё один важный и тонкий нюанс, который часто не виден с первого взгляда. Покажем суть на примере.
Не так давно в Москве была проведена закрытая конференция по ИБ, организованная знаменитым Positive Technologies. Направлена она была на поиск уязвимостей в банковском ПО, и позитивисты собирались провести такое же мероприятие в Новосибирске, но... До дела так и не дошло, но обо всём по порядку. Цель организаторов была в выявлении/демонстрации возможных проблем в банковском ПО (главная цель) и возможном последующем предложении своих услуг по улучшению ситуации. Набрали команду спецов. Участвовать согласились 15 банков. Спецы, конечно же, нашли той или иной степени критичности дыры во всём предоставленном ПО. В итоге, после проведённых исследований произошла вещь, которую товарищи из Positive Technologies никак не ожидали: все 15 банков отказались от своего ПО.
В чём же была ошибка Positive и многих из нас? Рынок Google, Facebook, Amazon, да и от части ОС от Microsoft – это в основном потребительские сервисы, главная задача которых – доступность. Ошибки, без которых никак, там не столь уж критичны и психологического эффекта «у нас есть дыры?! Да мы же можем потерять миллионы!» у них, в отличие от банков, нет. А вот финансовый сектор – это нечто другое. Там люди придают каждой проблеме в ПО критическое значение: и в силу незнания специфики (деления критичных / некритичных сервисов), и в силу обыкновенной психологии (роботы работают с деньгами => ошибка роботов – страшная вещь). Потому не удивительно, что 15 банков, согласившихся на предложение Positive, поступили именно таким образом.
Внедрение такой программы VRP в российских реалиях (в компаниях-производителях банковского ПО, таких как ЦФТ или ФИС) так или иначе приведёт к распространению информации: внешние исследователи не ограничены ничем: нет-нет, да расскажут, что нашли уязвимость в том или ином продукте, к примеру, ЦФТ. Банки такие вещи мониторят. Эффект предсказуем: резкое сужение рынка банковского ПО и всего, что явно связано с транзакционными финансовыми сервисами. Потому, похоже, что в таком секторе рынка стратегия поведения простая: лучше не знать о плохом и иметь его больше, чем иметь меньше ошибок, но знать о том, что они есть.
Итоги
Итоги сводятся к вышеописанным приёмам: к проведению адекватного и всестороннего анализа рисков с учётом основанного на реальной статистике ущерба компании от уязвимостей в её продукте / сервисе, потенциальных растрат на выплату вознаграждений (с учётом ограничений по направлениям поиска и допустимого прайс-листа программы / его гибкости) и последствий от возможного распространения информации о найденных уязвимостях (пусть и пос-фактум).
На вопрос о том, какая жолжна быть идеальная VRP-программа ответить по понятным причинам невозможно, но пример одной из самых интересных и универсальных по мнению автора программ для компании - разработчика собственного ПО - приведён в следующей статье: авторская VRP-программа.
Конечно, VRP-программами все проблемы не решить. К таким относятся, к примеру, вопросы об опасностях смартфонов на Android и iOS. Но есть и другие - куда более концептуальные и стратегические - вопросы, касаемые теоретической и практической безопасности. Интересные моменты относительно этих аспектов описаны в статье "О различии практической и бумажной безопасности" (есть в этом же разделе).
A.S.
