Региональные информатизаторы заинтересованы в bug bounty
В ходе Международного форума "ИТ-Диалог 2022" тема bug bounty поднималась сразу на нескольких сессиях. В ходе панельной дискуссии "Новая эра в информационной безопасности" заместитель губернатора, министр цифрового развития Калужской области Дмитрий Разумовский предложил создать единую государственную платформу bug bounty, которой могли бы пользоваться региональные власти. Создавать же разного рода киберполигоны и песочницы своими силами региональные минцифры в основной массе не могут. Тем более что затраты на поддержание ИБ не компенсируются из федерального бюджета, тогда как расходы на внедрение ИТ включены в различные федеральные программы.
Вице-губернатор Петербурга Станислав Казарин обратил внимание, что ИТ-системы становятся все сложнее и регуляторы опаздывают с выставлением требований по их защите. Это вполне естественный процесс, и использовать охранительный подход в нынешних условиях уже невозможно.
При этом, по данным исследовательской группы Positive Technologies, уязвимыми являются 65% приложений. Устранение этих проблем в безопасности с помощью традиционного подхода в разумные сроки и с приемлемым уровнем затрат часто невозможно.
В ходе заседания секции "Кибербезопасность: от концепции к реальности" участники дискуссии, среди которых заместитель председателя правительства, министр по информатизации, связи и вопросам открытого управления Тульской области Ярослав Раков, министр цифрового развития Удмуртской Республики Тимур Меджитов, заместитель руководителя - начальник Управления информатизации и защиты информации администрации главы Республики Карелия Наталья Никольская и начальник управления информационной безопасности Министерства цифрового развития и связи Оренбургской области Михаил Шляпников предложили давать преференции продуктам из Реестра отечественного ПО, разработчики которых прошли программу bug bounty. Это предложение родилось в ходе ответа на вопрос модератора дискуссии, эксперта по информационной безопасности Positive Technologies Алексея Лукацкого о готовности участия в таких программах после того, как федеральное Минцифры публично объявило о плане провести тестирование портала госуслуг с помощью bug bounty до конца текущего года.
По мнению заместитель генерального директора Postgres Professional, главы комитета по интеграции российского ПО АРПП "Отечественный софт" Ивана Панченко, главной проблемой Реестра российского ПО является отсутствие в нем данных о качестве включенных продуктов, и в таких условиях хороши любые идеи, которые помогут дополнить реестр информацией о реальном качестве ПО: "Рейтинг, учитывающий bug bounty, - одна из таких идей. При этом, хотя этот показатель и важный, он далеко не единственный. Рейтинг может учитывать также зрелость процессов управления разработкой, скорость реакции на инциденты, частоту обновления версий, участие в open-source-проектах, образовательную или научную активность разработчика и др. Можно ожидать, что при введении рейтинга по bug bounty особо хитрые разработчики будут его накручивать, намеренно внося в продукт баги и тут же их "находя" силами аффилированных лиц. Вывода два: чем больше показателей учитывает рейтинг, тем лучше; без "ручной" экспертной оценки ПО все равно не обойтись".
Генеральный директор ООО "Инновейв" Денис Солодков считает неверным рейтинговать ПО из реестра на основании прохождения bug bounty: "Сам механизм запущен не так давно и отсутствует отлаженная процедура, которая могла бы дать однозначную картину. Но при этом стоит отметить, что безопасность продуктов как с точки зрения их разработки, так и с точки зрения последующей эксплуатации - это крайне важный аспект, который должен учитываться. В этой связи наличие галочки о соответствии продукта не только критерию отсутствия уязвимостей, но и наличие криптографии в продукте, например, наличие иных функциональных особенностей продукта, связанных с информационной безопасностью, было полезным дополнением, помогающим клиенту при выборе продуктов опираться на данные параметры. То есть речь идет не о рейтинге ПО, а об обогащении реестра информацией о продукте факторами его безопасности от разработки до эксплуатации. Этот механизм должен быть исключительно аналогом добровольной сертификации".
Директор производственного центра департамента цифровых решений R-Style Softlab Илья Шаронов считает bug bounty отличным инструментом для поиска уязвимостей в сложных программных комплексах: "Готовность компании тратить усилия на обеспечение безопасности пользователей может и должна поддерживаться со стороны государства. Однако в случае с bug bounty актуальнее не составление рейтинга, а предоставление преференций тем решениям, которые в принципе участвуют в программе поиска ошибок и уязвимостей. Ведь, по сути, это процесс, который разработчик должен поддерживать непрерывно, и бинарный подход "участвует/не участвует" может быть внедрен достаточно быстро. Также стоит учитывать, что в современных реалиях программные продукты развиваются очень быстро и новые функции могут нести в себе и новые уязвимости. И если продукт часто обновляется, то возникает вопрос - какой временной промежуток достаточен для успешного прохождения программы поиска уязвимостей для конкретной редакции ПО. Еще один важный момент - интерес к участию в программе bug bounty экспертов по безопасности. И если продукт уже пользуется популярностью, то для его тестирования найдется большое количество энтузиастов. Но если ПО только готовится к выходу на рынок или является нишевым решением, то и найти тестировщиков будет гораздо сложнее. Стимулировать заинтересованность в продукте можно высоким вознаграждением за найденную уязвимость. Однако и это способно исказить результаты рейтинга: у всех компаний разные возможности для финансирования программ bug bounty ".
Директор по разработке ООО "Аурига" Елена Баранова считает предложение рейтинговать ПО из реестра не вполне продуманным: "Прежде всего, большая часть решений, представленных в реестре, закрыты для внешнего доступа разработчикам, не говоря уже о пользователях. Так происходит в силу разных причин - класс ПО (встраиваемое, системное…), требований по безопасности или в силу прав интеллектуальной собственности. Во-вторых, встает вопрос о финансировании услуг bug bounty. Это недешевое удовольствие и позволить его могут только крупные игроки рынка. И конечно, встанет вопрос о квалификации потенциальных охотников за багами. Тестирование продукта или сервиса - это сложная деятельность, требующая квалификации, иногда специального оборудования или инструментального ПО, которая ведется в соответствии со стандартизированными процессами. Кто поручится, что самодеятельные тестировщики не нанесут больше вреда, чем пользы? Таким образом, инициатива представляется мне пока довольно сырой и применимой только к решениям для массового пользователя от крупных компаний-разработчиков, большинство которых уже имеют свои программы bug bounty. С моей точки зрения, логичнее было бы обязать проходить Penetration testing для сервисов, критичных к персональным данным любого типа".
Основатель, директор по разработке и развитию продуктов "МойОфис" Дмитрий Комиссаров считает данную инициативу полезной, но требующей тщательной проработки: "Если появляется обязательность либо преференциальное применение, то надо обеспечить равные условия всем участникам рынка. В первую очередь потребуется определить критерии, по которым будет определяться эффективность программы bug bounty - например, были найдены ошибки и приемы для взлома или нет. Также стоит иметь в виду, что многие ИТ-компании сегодня ведут собственные программы bug bounty, которые позволяют выявлять уязвимости в продуктах. Например, "МойОфис" привлекает независимые исследовательские лаборатории для проведения аудита наших решений и проведения постоянных исследований попыток взлома продуктов".
Директор по маркетингу и коммуникациям ООО "Ракета" Дарья Зубрицкая считает, что использование bug bounty имеет смысл в рамках отдельного рейтинга по устойчивости и безопасности ПО: "Такой подход дает возможность клиентам и пользователям посмотреть рейтинг, оценить безопасность продукта и спланировать свое будущее использование. Но надо иметь в виду, что в любых рейтингах очень важны системы оценки: каким образом будут проверяться продукты, нужна ли единая система проверки или она должна отличаться по классам продуктов. Пока понятна только идея - помочь надежным и безопасным продуктам, чтобы их чаще выбирали, но очень важно продумать технологические и операционные вопросы такой оценки.
Основной преференцией здесь будет как раз некая отметка или "знак качества" о том, что в продукте минимальное количество ошибок, что он стабилен и надежен, что, в свою очередь, приведет к росту числа пользователей продукта. Ведь для всех клиентов важно использовать стабильный, "рабочий" продукт".
Заместитель генерального директора Zecurion Александр Ковалев считает использование bug bounty полезным, но при этом необходимо ПО и оборудование разделить на разные категории: "Во-первых, есть критичность - его отношение к КИИ, к персональным данным, то есть насколько это ПО и оборудование важно - что произойдет, если его взломать. Во-вторых, есть сертификация, например ФСТЭК, и имеет смысл это между собой связать, потому что часть тех требований, которые там есть, позволяют предотвратить ряд возможных атак. Также стоит иметь в виду, что у маленьких вендоров на раннем этапе своего развития не всегда будет возможность фиксировать множество багов и уязвимостей, которые найдут. Тут возникает такой момент: баги найдут, а технически зафиксировать не успеют, рейтинги будут низкие, продажи будут падать, и это будет замкнутый круг, который тормозит развитие компании. Я считаю, это все-таки это должно быть добровольно, чтобы люди, которые за это отвечают, были заинтересованы, чтобы свои разработки туда отправлять и получать какие-то более интересные возможности для доработок. Рейтинг - это не очень хорошо, а статус, что это проверено, - уже лучше идея".
Директор по стратегии и развитию технологий Axiom JDK "Беллсофт", руководитель ИБ-комитета АРПП "Отечественный софт" Роман Карпов рекомендует начинать работу с рейтинга государственных информационных систем (ГИС): "Не секрет, что при их построении подрядчики и ведомства, эксплуатирующие системы, пренебрегают базовыми правилами ИТ-гигиены, фиксируют версии ПО, на которых построены ГИС, и не обновляют их, в том числе не делают апдейтов безопасности, обосновывая это эксплуатацией систем в "закрытом контуре". Для продуктов на базе проектов с открытым кодом (при условии соблюдения ИТ-гигиены) подводные камни отсутствуют. А вот для проприетарных систем или систем ограниченного доступа программа может подсветить ряд существующих проблем. В целом вряд ли за bug bounty нужно давать преференции. Само по себе, если такая программа есть у производителя, показывает высокий уровень зрелости решения".
