Лаборатория информационной безопасности

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

Рейтинг:   / 2

ПлохоОтлично 

Подробности

Категория: Организационная безопасность

Дата публикации: 18.07.2013 21:52

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Приложение 1

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

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

A.S.