Главная > Uncategorized > Lessons learned: как надо и как не надо сравнивать сканеры

Lessons learned: как надо и как не надо сравнивать сканеры

Уже не первый год мне интересна тема сравнения сканеров уязвимостей (посты по теме — раз, два и три). В небольшой серии постов под названием «Lessons learned» я поделюсь своим видением проблемы — надеюсь, кому-то это окажется полезным в систематизации его миропредставления.
Первая тема — это критерии сравнения сканеров.

Обычно в зависимости от цели сравнения разделяют сравнение функциональных возможностей и сравнение эффективности. При сравнении функциональных возможностей берется некоторый чек-лист типа «Web Application Security Scanner Evaluation Criteria» и/или «OWASP Web Application Scanner Specification Project» и для каждого инструментального средства ставятся плюсики и минусики в большой-большой таблице. Пример подобного обзора для сканеров уязвимостей SQLi можно посмотреть тут.
Часто у нескольких средств в таблице функциональных возможностей в одной и той же строке будет стоять «+»: мол, да, умеем обнаруживать уязвимости не только по ошибкам, но и другими методами (blind, time-based). Возникает справедливый вопрос — а насколько хорошо? Тут-то и появляется задача оценки эффективности.

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

В качестве примера рассмотрим ситуацию: есть два сканера – С и D, у первого сканера показатели эффективности – (0.67, 0.01), а у второго – (0.55, 0.01). На первый взгляд, сканер С лучше сканера D. На второй – абсолютно не понятно, как соотносятся множества обнаруживаемых сканерами уязвимостей: насколько сильно они пересекаются (может, быть вообще вложены)? Таким образом, у эксперта не достаточно данных для выбора инструмента под конкретную задачу.

В качестве возможного решения можно предложить разделить множество тестов на классы, которые будут соответствовать классам возникающих на практике задач, и замерять вектор эффективности для каждого класса. Недостатками этого подхода является невозможность сравнения между собой сканеров с разными векторами эффективности (т.е. {(0.55, 0.01); (0.95, 0.01)} vs. {(0.75, 0.01); (0.75, 0.01)), а также заранее фиксированное разделение на классы: у эксперта может быть своя классификация задач, которая не соотносится с той, по которой проведены измерения.

Как же тогда быть? Единственное адекватное решение — это:

  1. Признавать лучшим сканером не тот, у которого больше численные характеристики, а тот, который находит объемлющее число уязвимостей. Т.е. сканер А лучше сканера Б, если все уязвимости, найденные сканером Б, будут так же найдены сканером А, при этом процент ложных срабатываний сканера А не превысит процента ложных срабатываний сканера Б.
  2. Так как такой сканер вряд ли найдется, замерять лучшесть (т.е. искать объемлющее множество обнаруживаемых уязвимостей) нужно для каждого класса задач в отдельности. А в итоге лучшим будет не какой-то один сканер, а суперпозиция сканеров, каждый из которых будет лучшим на соответствующем классе задач.

Надеюсь, данный текст был полезен. Если есть вопросы или сомнения в адекватности — велкам в комменты.

Реклама
  1. Комментариев нет.
  1. No trackbacks yet.

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

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

%d такие блоггеры, как: