Программа поощрения поиска уязвимостей

Рейтинг:   / 2
ПлохоОтлично 

Программа VRPВ одной из предыдущих статей - Плата за взлом или как найти лучшего специалиста по информационной безопасности - были рассмотрены так называемые VRP-программы - программы поощрения поиска уязвимостей - программы, представляющие собой не только метод защиты производимого или используемого программного обеспечения от уязвимостей, но и способ превратить врагов IT-бизнеса в друзей, приносящих доход. Рассмотрим пример одной из таких VRP-программ, дающей один из лучших ответов по вопросу защиты информационной системы  от всевозможных уязвимостей. Описанная ниже программа разработана лично мной и является авторской. Просьба использовать её в своих целях только с согласования со мной (кто заинтересуется, контакты в разделе Об авторе). :)

Описание концепции программы

            Главная цель программы поощрений поиска уязвимостей (VRP) состоит в повышении безопасности сервиса <...>. Программа направлена на поощрение инициативы и деятельности независимых исследователей (как внешних пользователей и клиентов сервиса, так и сотрудников компании) по нахождению любого рода уязвимостей и слабых мест в программном обеспечении компании и сервисе <...>, в частности. В рамках данной программы участникам, обнаружившим ту или иную уязвимость / слабое место в системе защиты предоставляется денежное вознаграждение. Кроме того, меняется существующая система выплаты премий разработчикам и тестировщикам ПО Компании.

            Под уязвимостью будем понимать 2 фактора: уязвимость в программном обеспечении исследуемого сервиса, которая может быть использована злоумышленником, и привести к убыткам Компании или её клиентов; какое-либо потенциальное слабое место в ПО, его архитектуре или схеме работы исследуемого сервиса, а также схемы мошенничества, которые также могут привести к убыткам Компании или её клиентов.

 Условия участия в программе

    1. Участвовать в программе и получать вознаграждения может любой желающий, имеющий представление об информационной безопасности и возможных уязвимостях в ПО. При этом разработчик (участник группы разработки) или тестировщик (участник группы тестирования) конкретного ПО сервиса <…> не может быть участником программы VRP по этому ПО.
    2. Участник должен найти уязвимости в доступном ему программном обеспечении сервиса <...>, в том числе как в технологической (актуально, если речь о сотруднике Компании или о клиенте, использующем технологическое ядро сервиса <...>), так и в клиентской части сервиса <...>.
    3. В случае целенаправленного или случайного обнаружения какой-либо уязвимости, следует оформить её в виде отчёта по форме в приложении 1 и переслать в дирекцию ИБ Компании по следующему адресуe-mail: ...
    4. Найденная уязвимость сервиса <...> считается засчитанной за участником, если она ещё не зарегистрирована в сервисе и подтверждается тестами сотрудников сопровождения сервиса.
    5. Запрещается:

5.1.Использовать найденные/известные уязвимости для получения реального доступа к аккаунтам пользователей, проведения разного рода атак, иной деятельности, способной нарушить работу сервиса или Компании в целом (в том числе нарушить свойства конфиденциальности, целостности, доступности).

5.2.Сообщать о найденных уязвимостях третьему лицу (в том числе другому сотруднику Компании в случае, если участник является сотрудником) до того, как в Компанию отправлен отчёт о найденной уязвимости.

    1. Нарушение запретов п. 6 автоматически лишает отправителя награды, а в определённых случаях может вызвать вынесение предупреждения, а также– в случае нарушения п. 6.1 – административное или уголовное преследование.
    2. Вознаграждение за найденную уязвимость может быть больше или равно указанного в главе "Порядок классификации уязвимостей и вознаграждения", в зависимости от потенциальных последствий реализации уязвимости. Потому важно отметить, что финансовое вознаграждение может быть существенно больше указанных по данному классу уязвимостей, если найденная уязвимость является действительно критической.
    3. Случаи, перечисленные в части "Сообщения/проблемы, не входящие в группу уязвимостей" не считаются уязвимостями и вознаграждению не подлежат.

Условия работы инженеров-программистов и инженеров-тестировщиков сервиса

    1. Для каждого разработчика (инженера-программиста) или группы разработчиков сервиса <…> считается количество уязвимостей в разработанном им (его группой) ПО, найденное в течение срока T1 как тестировщиками данного ПО в процессе их работы, так и внешними по отношению к сервису независимыми исследователями. Обозначим количество найденных за T1 дней ошибок за NErr.
    2. Для каждого тестировщика или группы тестировщиков заданного ПО сервиса <> считается количество уязвимостей в протестированного им (его группой) ПО, найденное в течение срока T2 внешними по отношению к сервису независимыми исследователями. Обозначим количество найденных за T2дней ошибок за NErr.
    3. Премия разработчика и тестировщика ПО выплачивается с отсрочкой и определяется следующим образом:
      <формула скрыта>, где Prem – его среднемесячная премия; ErrLim – определённый допустимый лимит ошибок-уязвимостей для разработчиков или тестировщиков (в зависимости от того, для кого считаем премию).
      Обоснование схемы. Имеется определённый лимит уязвимостей (ErrLim), которые совершает разработчик или пропускает в процессе работы тестировщик (у каждого лимит, естественно, свой).Если сотрудник совершает/пропускает ошибок меньше этого лимита, то коэффициент будет больше 1, и его премия будет выше среднестатистической. Если же он совершил ошибок больше лимита, то премия наоборот станет меньше средней (но всегда больше 0).
    4. При превышении определённого лимита LimErrStrong найденных в ПО / пропущенных уязвимостей разработчик/тестировщик лишается премии вовсе.
      Обоснование: ликвидировать риск намеренного совершения ошибок для последующего «сливания» их сторонним лицам и последующего получения совместного вознаграждения.

Можно (и нужно) ввести весовой коэффициент-множитель перед параметром NErr в числителе таким образом, чтобы обеспечить соответствие критичности ошибок в сервисе и обеспечению условия: двойная стоимость вознаграждений <= снижения премии от их последующего выявления.

Можно использовать для выплаты вознаграждений внешним участникам программы премиальный фонд соответствующей группы разработчиков и тестировщиков (что обеспечит одновременное отсутствие доп. расходов Компании и обеспечит большую мотивацию), но текущая схема представляется более разумной и эффективной как с либеральных и психологических представлений, так и с позиции эффективности работы.

Предложенная схема работы разработчиков / тестировщиков позволяет:

    1. Мотивировать разработчиков писать качественное ПО, а тестировщиков – находить как можно больше ошибок.
    2. Включить в участие программы всех сотрудников Компании (которые знают продукты Компании лучше внешних пользователей и соответственно, смогут найти немало доп. уязвимостей), не опасаясь при этом целенаправленного совершения ошибок и последующего их «сливания» на сторону, дабы получить совместное вознаграждение.

Порядок проведения классификации уязвимостей и вознаграждения

Некоторый (неисчерпывающий) перечень уязвимостей:

  • Межсайтовый скриптинг (XSS).
  • Межсайтовые подделки запросов.
  • Межсайтовый сценарий включения (CSSinclusion).
  • Разного рода инъекции (SQL-инъекция; код-include и т.д.).
  • Уязвимости (проблемы) в механизмах аутентификации и авторизации.
  • Выполнение произвольного кода на серверной стороне/каком-либо ПО.
  • Вставка кода в легитимный запрос/модификация запроса (его параметров).
  • Уязвимости и схемы DoS-атаки (не DDoS) на сервис.

Сообщения/проблемы, не входящие в группу уязвимостей:

  • Все виды DDoS-атак.
  • Все виды bruteforce-атак (полный перебор всего что угодно в любом виде).
  • Известные атаки на используемые криптоалгоритмы в чистом виде.
  • Угрозы аппаратных сбоев или физической атаки на аппаратное обеспечение.
  • Угрозы, связанные с управлением Компанией или сервисом и социально-экономическими аспектами.
  • Методы социальной инженерии без привязки к техническим аспектам.

Классы уязвимостей и вознаграждения:

Описание последствий уязвимости Ядро системы Прикладная часть
Удаленное выполнение кода(в т.ч. ошибки переполнения буфера) 10000-30000 р. 5000-15000 р.
Уязвимости, связанные с отсутствием проверки параметров в сетевых запросах (от http до собственных протоколов). 5000 – 15000 р. 3000 – 10000 р.
SQL-инъекция или её эквивалент 5000 - 15000 р. 3000 - 15000 р.
Обход аутентификации (в т.ч. кража паролей) 10000 - 30000 р. 5000 - 15000 р.
Обход механизмов авторизации (повышение привилегий) 5000 - 15000 р. 3000 - 10000 р.
CSS/XSS-уязвимости 1000 - 5000 р. 1000 - 3000 р.
Уязвимости,позволяющие осуществить DoS-атаку 1000 - 5000 р. 1000 - 3000 р.
Другие виды уязвимостей/атак В зависимости от воздействия В зависимости от воздействия

Таблица составлена на основании классификации уязвимостей Googleи TOP10 уязвимостей OWASP, можно дополнять/модифицировать.

 Порядок обработки отчётов сотрудниками дирекции информационной безопасности:

    1. Классификация поступившего отчёта аналитической группой ДИБ в соответствии с таблицей "Классы уязвимостей и вознаграждения".
    2. Верификация уязвимости (проверка на актуальность/соответствие действительности).
    3. Оценка критичности и средних потерь при использования рассматриваемой уязвимости: т.е. произведение вероятности её обнаружения/использования (т.е сложности) и потенциальных последствий от реализации.
    4. Вынесение решения о денежном вознаграждении и его объёме, занесение данных о найденной уязвимости в соответствующую БД уязвимостей (по которой в дальнейшем будет вычисляться параметр NErr).
    5. Отправка сообщения о результате обработки отчёта его владельцу и, в случае положительного решения о вознаграждении, передача данных о выплате кому следует.

 

Приложение 1

Отчёт должен содержать следующие обязательные пункты:

    1. Фамилия, имя, отчество; место работы; отношение к сервису (могут быть следующими: сотрудник, клиент Компании, клиент Банка-клиента, стороннее лицо).
    2. Название сервиса, в котором найдена уязвимость, с указанием модуля сервиса (его части, в которой найдена уязвимость).
    3. Описание сути уязвимости (кратко) и способа реализации в конкретном сервисе (с указанием всех деталей реализации)
    4. Описание потенциальных последствий использования найденной уязвимости.
    5. Дата обнаружения уязвимости.

A.S.

Понравилась статья? Хотите читать этот блог?

Ваш e-mail: *

Ваше имя: *

Добавить комментарий


Защитный код
Обновить

Вы здесь: Home Юридические вопросы Орг. безопасность