Bug-bounty для правительства: хороший, плохой, злой

В переписке по поводу стратегии кибербезопасности возник вопрос: «Объясните пожалуйста, почему bug-bounty будет вреден для гос. органов?».
Коротко не получилось, опять много букв.
Здесь и далее мое личное, частное мнение.




Прежде всего bug-bounty можно разбить на 2 основные категории:

1. Продуктовый, когда производитель объявляет о поощрении за обнаруженные недочеты в своих продуктах или защитных механизмах, как правило «отчуждаемых», т.е. продаваемых в виде «коробки» например по лицензионному договору. Примеры: Google с Chromium, Mozilla Foundation с Firefox, Microsoft BlueHat и т.д.
2. Инфраструктурный, когда владелец информационной системы объявляет о поощрении за недочеты в своей «живой» инфраструктуре, развернутых и активно эксплуатируемых сервисах (как правило, сервисах массового обслуживания). Примеры: Yandex, Faceboox, опять Google и т.д.

Есть, конечно и вариации, когда поощрение обеспечивает третья сторона, не всегда с согласия производителя или владельца информационной системы, но это уже «серая» зона, рассматривать не будем. Примеры: ZDI, iDefense и т.д.

Вариант #1, продуктовый, годный.

Применяется достаточно давно и успел доказать свою эффективность. Исследования я приводил, повторю.
Причины успешности понятны:

1. Продукт и так отчуждаемый, и, если он кому-то интересен, уязвимости в нем будут искать без твоего согласия. Максимум что ты можешь, написать в лицензионном соглашении о «reverse engineering is strictly prohibited», что конечно же всех остановит.
2. Как правило у разработчика есть команда разработки (должна быть), которая может (надеюсь) понять и исправить уязвимость. Есть служба внешней технической поддержки, которая создана для таких задач.
3. Наличие bug-bounty позволяет исследователям подстраховаться на случай вольных трактовок фразы «нейтрализации средств защиты компьютерной информации» в новой редакции статьи 273 УК. Как я писал ранее, они и так ходят по тонкому льду даже при проведении договорных работ, не говоря уже о госорганах где сплошь и рядом персональные данные, ДСП (которого нет, но он есть) или хуже того - гостайна.

Таким образом bug-bounty на продукты, системы и СЗИ, используемые в госорганах выглядит полезной и перспективной. На поверхности два варианта реализации – когда производитель сам объявляет и реализует программу, либо программа проводится централизованно и участие в ней является одним из условий сертификации/использования в госорганах (жесток я сегодня, да).
Идеальным тут  выглядит наличие лаборатории, в которой развернуты системы и СЗИ, используемые в госорганах, в которую, после предварительной регистрации можно получить удаленный доступ и поломать в свое удовольствие.
Естественно под присмотром.
Естественно с понятными ответственными.
Ответственными, которые известны, вызывают уважение, помогают, платят, не заставляют носится в налоговую после каждых 100 рублей.
В качестве примера могу привести ICS CERT, который умудрился занять в умах исследователей безопасности АСУ ТП эту нишу. Люди просто отправляют туда уязвимости, чтобы снять головную боль работы с вендором. Хотя, ICS CERT не платит, и у него начали появляются интересные альтернативы в «серой» зоне.

Вариант #2, инфраструктурный. Выглядит опасно.

1. Конечно, многие крупные провайдеры online-сервисов сейчас используют этот механизм. Но начали они его применять после того, как зрелость их СУИБ достигла высокого уровня. Какие аспекты СУИБ тут важны? Управление уязвимостями, обнаружение атак и управление инцидентами. Последний, процессный и даже административный момент, но по практике тестов на проникновение, службы ИТ и ИБ часто не готовы к «атакам», даже в их облегченном варианте пентеста. Они просто не знают, что делать. Что же будет если такие инциденты посыпятся десятками и сотнями в день?
2. При текущем положении в большинстве случаев для выявления уязвимостей bug-bounty не нужен, достаточно просто запустить MaxPatrol и вы получите миллионы багов. О которых знают, но которые не устраняют. Иногда, потому что «в обязательных документах уязвимостей не существует» и «устранять их не требуется» и «система аттестована». В качестве доказательства приведу статистику. Цитирую:

«В 65% систем были выявлены уязвимости, связанные с отсутствием актуальных обновлений безопасности, среднего или высокого уровня риска. Почти половина систем содержала критические уязвимости. Средний возраст неустановленных обновлений по системам, где такие уязвимости были обнаружены, составляет 51 месяц, то есть более 4 лет. В одном из исследуемых государственных учреждений обновления не устанавливались в течение более чем 7 лет, в результате было обнаружено множество уязвимостей, в том числе критические уязвимости, позволяющие выполнять произвольный код на системе.»

3. В большинстве случаев инициатор bug bounty - это не только владелец и оператор информационной системы, но и ее разработчик. Т.е. если ты нашел XXE у Yandex или SQLi у Google, именно специалисты Yandex и Google (которые и создали эту XXE и SQLi) возьмутся за эту проблему, устранят, оттестируют и развернут новую версию. Кто будет этим заниматься внутри госоргана, являющегося владельцем системы электронного правительства «Гражданин 2.0», внедренной подрядчиком (договор закрыт), эксплуатируемой оператором, разработанной субподрядчиком субподрядчика (вообще непонятно, кто там этот код писал) на open-source CMS (такого не бывает)?
4. И в конце, но не в последнюю очередь – bug bounty это легализация атак. В настоящее время (де-юре и де-факто), если ты просканировал XSpider сайт госоргана, или например Олимпиады, будь готов поиметь душеспасительную (если повезет) беседу с парнями в штатском в районе Детского Мира или на ул. Ленина, д.64. Инфа 100%.

Но если на сайте системы электронного правительства «Гражданин 2.0» явно написано, что ЛОМАТЬ МОЖНО, то и вопросов никаких. Парням в штатском остается только наблюдать за многомиллионными журналами систем обнаружения атак, пытаясь разве что угадать преобладающий цвет предупреждений. Конечно, возможно, кто-то может отличить по срабатываниям системы защиты хорошие, годные атаки и плохие, негодные атаки, но у меня приходит на ум только RFC 3514.

Приведу пример «презумпции виновности» для исследователей. Предвижу волну возмущения, но пример рабочий, жизненный, хороший пример.

Выводы

Я далеко не апологет «бумажной безопасности» и «security through obscurity» и вообще за демократию. Однако для государственных информационных систем (не продуктов, используемых в государственных информационных системах!) введение bug-bounty разрушит хрупкий механизм сдерживания массовых атак, практически переведя их в легальное русло.
Вводить программы поощрения поиска уязвимостей для государственных информационных систем можно и нужно, но только после того, как:
- будут установлены обязательные требования по управлению уязвимостями в госорганах и запущены механизмы их выполнения и контроля;
- будет как-то проработан вопрос Application Security (безопасности прикладных информационных систем), который пока слегка «подвис в воздухе»;
- будет понятен и отлажен механизм реагирования на инциденты (обнаружение уязвимости – это тоже инцидент, если уязвимость за рамками принятого уровня compliance) в госорганах, с понятной точкой входа, внутренним и внешним взаимодействием, и эффективным устранением обнаруженных проблем (что также включает в себя пересмотр отношений с разработчиками ИС);
- процессы управления уязвимостями госорганов будут доведены до уровня «сканер критичных багов на периметре сети не находит»;
- используемые системы обнаружения атак будут позволять отсеять «шум», характерный для любой интернет-системы, вызывающей пристальное внимание исследователей и «исследователей».