Главная > Uncategorized > Lessons learned: что же такое — «лучший» сканер?

Lessons learned: что же такое — «лучший» сканер?

Продолжаю серию постов об уроках, полученных в результате сравнения сканеров.
Сегодня речь пойдет о коварности задачи «найти лучший сканер».

Ранее мы сформулировали критерий того, что сканер А лучше сканера Б: сканер А должен находить объемлющее множество уязвимостей. Представим себе, что вооружившись этим определением, мы провели испытания трех сканеров — А, Б и С, в результате чего получили:
1-ое место: сканер Б. Нашел 5 уязвимостей из 100000. Процент ложных срабатываний — 0.
2-ое место: сканер С. Нашел 4 уязвимости из 100000 с таким же процентом ложных срабатываний.
3-ье место: сканер А. Нашел 1 уязвимость из 100000 с таким же процентом ложных срабатываний.
Из чего делаем вывод, что сканер Б — лучший.

Мы правы? Безусловно!
Полезен ли сканер Б в реальном мире? На первый взгляд, вряд ли. Но подождите, не все так просто.

Так какое же дополнительное исследование нужно еще провести, чтобы полученный рейтинг оказался практически полезным?

Во-первых, необходимо посмотреть на равномерность классов тестового покрытия. Вдруг, получится так, что 100 000 элементов тестового покрытия делятся на два класса: класс А с очевидными уязвимостями, состоящий из 5 тестов, и класс Б с вымышленными уязвимостями, которые никогда не встречаются в реальных приложениях, состоящий из 99 995 тестов. В итоге получится, что победитель имеет 100% полноту на реальных задачах и нулевую полноту на нереальных. Выходит, сканер все-таки немного полезен! А создателю тестового набора надо оторвать …
А вот еще пример того, как можно легко подыграть сканеру в конкурсе, где лучший сканер определяется по критерию полноты и точности (помните, мы резко осудили такой подход?).
[ В сторону: кстати, никому не нужно бесчестное сравнение инструментов с заранее известным победителем? ]
Итак, есть два сканера. Первый лучше обнаруживает SQLi error-based методом, а второй — time-based. Для того, чтобы победителем стал первый сканер, делаем тестовый набор, в котором больше тестов на error-based метод, и наоборот, если хотим, чтобы победил второй.

Во-вторых, как можно было догадаться из приведенного выше описания, необходимо убедиться, что в тестовом покрытии отражены реальные задачи. В идеале, для лучшего сканера необходимо привести вектор полноты по основным классам реальных задач (классы могут пересекаться), например:
— обнаружение SQLi по ошибке в ответе: (95%, 0.1%);
— обнаружение SQLi слепым методом (без внедрения задержек) при стабильном HTTP-ответе: (65%, 1%)
— обнаружение SQLi слепым методом (без внедрения задержек) при нестабильном HTTP-ответе: (45%, 3%)
— обнаружение SQLi в DML-запросах (INSERT/UPDATE/DELETE) при отсутствии ошибок: (30%, 1%)
… и т.д.

Для чего это все нужно? Конечно, для понимания того, какой процент уязвимостей обнаружил сканер в заданном приложении после прогона, и где (в каких классах) искать необнаруженные уязвимости. Ведь всё затевается именно ради этого: использовать инструмент, сэкономить время, а свои усилия направить на те вещи, которые инструмент обнаружить не способен.

Резюме: при поиске лучшего необходимо рассматривать два аспекта — относительную «лучшесть» и абсолютную. Относительная «лучшесть» расставляет сканеры в упорядоченный (или частично-упорядоченнй) список. Абсолютная лучшесть показывает, насколько победитель полезен в реальном мире.

Реклама
  1. 23.09.2011 в 16:18

    Проблема еще в том, что метрик типа «нашел слепую скуль при нестабильном соединении» бесконечно много.
    Сколько их них актуальны для конкретного проекта — ХЗ. Часто пока не начнешь работать сам не узнаешь %)

    Все сравнения сканеров сводятся к одному — они помогают понять порядок в последовательном сканировании каждым из них. Сначала те, у которых покрытия побольше, потом все остальные. Больше ничего имхо.

    Для аудита все-равно всеми средствами пользуешься )))

  2. 23.09.2011 в 16:23

    d0znpp :

    Проблема еще в том, что метрик типа «нашел слепую скуль при нестабильном соединении» бесконечно много.

    Разумеется. Я для примера привел просто. В идеале, статистика должна быть динамической — то есть, ты сам строишь класс тестов, для которого тебе говорят полноту и точность. Мы, например, в своей среде собираемся делать именно так.

    А по поводу использования всех последовательно я не согласен — времени не напасешься. Поэтому, как раз, важно понять разумное количество сканеров, которые дают объемлющий результат. Среди открытых на данный момент это wapiti + w3af.

    p.s. Скоро начнем тестировать коммерческие.

  1. No trackbacks yet.

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

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

Логотип WordPress.com

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

Фотография Twitter

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

Фотография Facebook

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

Google+ photo

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

Connecting to %s

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