Распространение независимых и спонсируемых определенными вендорами программ Bug Bounty не только обогатило многих ИБ-исследователей, но также заставило компании и разработчиков ПО задуматься о том, какие процессы необходимо наладить для того, чтобы получать сторонние отчеты об уязвимостях.

«Недостаточно просто сказать, что вам нужен отчет, — заявила Кейти Муссурис (Katie Moussouris), главный специалист по политике взаимодействия известной платформы для Bug Bounty — HackerOne. — Руководителям в области безопасности нужно сначала понять, готовы ли они к тому, чтобы получать отчеты об уязвимостях со стороны».

HackerOne объявил о запуске сервиса, который компания назвала «инструментом моделирования оценки готовности к управлению информацией об уязвимостях», или Vulnerability Coordination Maturity Model. Это онлайн-инструмент, позволяющий компаниям определить, в каких областях им еще нужно поработать, чтобы принимать сторонние отчеты о багах. Он оценивает, есть ли проблемы, мешающие работать со сторонними баг-хантерами, — например, можно ли рассчитывать на поддержку со стороны руководства, хорошо ли налажены коммуникации с представителями ИБ-сообщества и другими участниками отрасли, достаточно ли имеющихся поощрительных мер. Такая оценка позволяет узнать многое о готовности компании бороться с уязвимостями до того, как они соберутся получать принятый в отрасли сертификат ISO, который стандартизирует обращение с информацией об уязвимостях с точки зрения анализа первопричины и инжиниринга.

Сервис Vulnerability Coordination Maturity Model — это онлайн-опрос, занимающий пять минут и оценивающий уровень «зрелости» по трем общим параметрам, соответствие которым необходимо для успеха программы поиска уязвимостей. Эта анкета помогает определить, насколько компания готова работать со сторонними исследованиями, а также присваивает организации рейтинг среди других компаний и оценивает уровень компании в определенный момент времени. При помощи такого отчета директора по информационной безопасности могут правильно распределить ресурсы и запланировать инвестиции.

«Этот подход открывает перед вами обширные возможности, даже если вы владелец небольшой команды разработчиков, — объясняет Муссурис. — Решив, что вы готовы принимать сторонние отчеты об уязвимостях в соответствии с уже налаженным процессом, вы можете справиться, даже поручив эту задачу одному разработчику. Но, конечно, для более высокого уровня анализа и инжиниринга кода нужно обладать и большими ресурсами. Если вы решили запускать программу премирования за поиск уязвимостей, вам потребуются соответственные ресурсы».

На основе анализа каждого параметра в ходе моделирования организации присваивается один из трех уровней: базовый, продвинутый и экспертный. Например, если в секции, где оценивается поддержка со стороны организации, указано, что руководство поддерживает идею и считает безопасность одним из ключевых факторов в работе организации, такой компании присваивается базовый уровень готовности. Компании, отнесенные к «продвинутым», применяют соответствующие стандартам ISO 29147 или ISO 30111 правила и процессы в деле обработки информации об уязвимостях. Компании экспертного уровня не только располагают поддержкой экспертов и бюджетом на борьбу с багами, но и имеют в штате специалистов, обрабатывающих отчеты об уязвимостях.

Аналогичная шкала применяется к каждой из следующих позиций:

  • В инжиниринговых процессах высокого уровня должны использоваться системы отслеживания уязвимостей и анализ первопричин, чтобы бороться с целыми классами уязвимостей.
  • Системы аналитики экспертного уровня отслеживают телеметрические данные известных эксплойтов в реальном времени, чтобы выявить метод исправления бага и отправить данные анализа в цикл разработки ПО.
  • Структурированный обмен информацией и наличие правильного посыла для ИБ-сообщества, партнеров по бизнесу, клиентов директивы и СМИ — признаки высшего уровня готовности.

Наконец, данная модель позволяет также оценить привлекательность мер поощрения. Более мощные программы предусматривают мотивации, которые дестабилизируют рынок уязвимостей и выходят за рамки финансовых премий или программ Bug Bounty для поиска критических уязвимостей. Важно также, чтобы организация могла гарантировать, что исследователь не предстанет перед судом за обнаружение серьезной уязвимости.

«Если вы не поняли, как принимать сторонние отчеты о багах со стороны клиентов, хакеров, партнеров, это значит, что вы не все продумали и ваша концепция безопасности неполноценна», — говорит Муссурис.

HackerOne уже предоставил ознакомительную версию инструмента нескольким организациям, в том числе FDA, управлению по санитарному надзору за качеством пищевых продуктов и медикаментов США.

«Они оценили, насколько успешной может быть координация работы по уязвимостям в среде производителей медицинских устройств и учреждений здравоохранения. Ведь такое ПО спасает жизни, — подчеркнула Муссурис. — Чтобы заботиться о здоровье нации, организациям, работающим в сфере здравоохранения, нужно иметь возможность принимать отчеты о найденных багах. В FDA оценили инструмент моделирования, были удовлетворены его простотой и считают его полезным. Они жаждут приступить к совершенствованию своих процессов и последовательно, шаг за шагом, двигаться к намеченной цели».

Категории: Уязвимости