Обнаружение уязвимостей: рассуждение о полноте и точности

В предыдущем посте мы рассмотрели две модели уязвимостей, которые используются при статическом и динамическом анализе веб-приложений.
При выборе инструмента для поиска уязвимостей внимание обычно обращают (помимо цены) на две характеристики: на полноту и на точность обнаружения. В этом посте я бы хотел порассуждать как раз на эту тему.
Полнота обычно вычисляется как отношение числа найденных уязвимостей к общему числу уязвимостей в приложении (в идеале мы бы хотели получать единицу). Возникает справедливый вопрос: откуда мы узнаем общее число уязвимостей? Правильный ответ — ниоткуда :)
А как же тогда замерять полноту? В голову приходят два варианта:
1. Провести испытания на куче веб-приложений, замерить интересующие характеристики, подсчитать статистику.
2. Формально доказать, что метод, реализованный в средстве, полон при обнаружении определенного класса уязвимостей (например, Input Validation).
Так как для средств динамического тестирования (black-box или white-box) второе обычно не представляется возможным, остается только первый вариант. Кстати, отсюда такой интерес к методикам сравнительного тестирования сканеров веб-приложений.¹
А вот для методов статического анализа уже можно проводить доказательства полноты. Правда, это получается проделать не для всех классов уязвимостей. Таким образом, для статических анализаторов методики сравнительного анализа тоже актуальны. ²
Вообще, полнота обычно является главным конкурентным преимуществом при позиционировании средства. Это логично: чем больше полнота, тем больше уверенности в том, что если средство не найдет уязвимостей, то их действительно нет.

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

Еще надо сказать пару слов о том, зачем в эффективность обнаружения включают два показателя, а не какой-то один. Дело в том, что при измерении эффективности с использованием одного показателя можно придумать тривиальный анализатор, который будет выдавать 100% эффективность (точность или полноту). Действительно, 100% полнота будет у статического анализатора, который скажет, что в каждой строке кода есть уязвимость, а 100% точность будет у анализатора, который ничего не будет выдавать (а значит и не будет ошибаться).

В заключении о главной мысли данного поста. Точность и полнота работы средства обнаружения уязвимостей в первую очередь зависит от двух факторов:
— от ограничений используемой модели уязвимостей;
— от выбранного подхода применения модели: статический vs динамический анализ.
Рассмотрим каждый из этих факторов подробнее. Каждая модель уязвимости — суть абстракция от чрезмерного уровня детальности, который характерен реальному миру. Соответственно, для каждой модели можно сформулировать ряд допущений, при выполнении которых модель будет применима. Если эти допущения не будут выполнены (то есть у нас ситуация, существенные детали которой не учтены в абстрактной модели), то модель не гарантирует качественный результат — может снижаться полнота или точность анализа.
Кроме того, каждая модель уязвимостей заточена под конкретное представление программы (я об этом писал ранее). Таким образом, если анализатор строит это представление некачественно (неточно или неполно), то применение даже самой лучшей в мире модели уязвимостей (если бы такая была) не дало бы 100% эффективности.

Краткое резюме. Даже если некоторое средство SuperAnalyzer будет уметь строить самые качественные представления программ (что невозможно из-за неразрешимых задач), полнота или точность обнаружения любого класса уязвимостей не будет 100%, если используемая модель уязвимостей имеет соответствующие ограничения. А обе рассмотренные ранее модели такие ограничения имеют. Именно об ограничениях этих моделей и пойдет речь в очередном посте.

Note 1. На эту тему я планирую скоро тоже написать парочку постов. Пока же, если кому интересно, можно почитать материалы по ссылкам:

1. Web Application Scanners Comparison
2. Web Application Vulnerability Scanners — a Benchmark
3. Первая попытка Лари Суто и критика его подхода нумер айнц унд цвай.
4. Вторая попытка Лари Суто и критика его второго подхода раз, два, три и четыре.

Note 2. Наверное, самый известный проект по исследованию эффективности инструментов для поиска уязвимостей называется SAMATE, и ведет его NIST. Особенного внимания, на мой взгляд, заслуживает публикация NIST SP 500-279.