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%)
… и т.д.

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

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