Сканеры информационной безопасности (или сканеры уязвимостей) – это программно-аппаратные средства мониторинга и контроля информационной безопасности сетевой инфраструктуры. Сканеры информационной безопасности (ИБ) позволяют проверять информационные системы: компьютерные сети, отдельные компьютеры и установленные на них приложения на наличие уязвимостей, эксплуатация которых злоумышленниками может нанести ущерб организации, которой принадлежит данная инфосистема. Большинство сканеров безопасности позволяют детектировать уязвимости описанные классификатором WASC Threat Classification.
С тестированием ИБ и основными определениями в этой области можно ознакомиться в нашей прошлой статье: "Основы тестирования безопасности web-приложений". В данной статье попытаемся рассмотреть вопросы, связанные с тестированием сканеров информационной безопасности web-приложений как программных продуктов.
С тестированием ИБ и основными определениями в этой области можно ознакомиться в нашей прошлой статье: "Основы тестирования безопасности web-приложений". В данной статье попытаемся рассмотреть вопросы, связанные с тестированием сканеров информационной безопасности web-приложений как программных продуктов.
Современный сканер ИБ для web-приложений – это сложный, многофункциональный и комплексный продукт, тестирование которого и сравнение с другими аналогичными продуктами имеет ряд особенностей. Далее рассматриваются общие подходы и критерии тестирования таких сканеров:
- основная тестовая процедура для любых сканеров web-приложений;
- возможные виды проводимых тестовых испытаний;
- используемые на данный момент критерии оценки сканеров web-приложений;
- предлагаемые типы тестов для сканеров web-приложений.
I. ТЕСТОВАЯ ПРОЦЕДУРА
В качестве общих подходов к тестированию сканеров web-приложений предлагается опираться на статью "Построение тестовых сценариев для сканеров web-приложений", оригинал (en):
В частности, там предлагается Тестовая Процедура (пункт 4.1, стр. 6) для сравнения работы различных сканеров web-приложений. Предлагается модифицировать эту процедуру следующим образом:
- Подготовить необходимый тестовый контент для функциональной проверки всех технических требований, развернуть тестовые стенды.
- Инициализировать тесты, получить все необходимые настройки для тестов.
- Сконфигурировать сканируемое web-приложение: выбрать для него тип уязвимости и уровень защиты.
- Запустить сканер с выбранными настройками на тестируемое web-приложение и пройти набор функциональных тестов.
- Подсчитать и классифицировать найденные сканером web-объекты (уникальные ссылки, уязвимости, векторы атаки и т. п.).
- Повторить шаги 2-5 для каждого типа уязвимостей и уровней защиты.
Измерения после каждой итерации тестовой процедуры предлагается заносить в Сводную таблицу результатов детектирования объектов, с метрикой, введённой ниже. Например, такая таблица может выглядеть следующим образом:
| Тип уязвимости или функциональный модуль сканера | Уровень защиты | Кол-во обнаруженных объектов | False Positive | False Negative | Всего реальных объектов для поиска | Общее время сканирования |
|---|---|---|---|---|---|---|
Модуль Crawler - для первоначального поиска объектов сканирования (ссылок)
|
0
|
100
|
0
|
50
|
150
|
500 с.
|
1
|
90
|
0
|
60
|
600 с.
| ||
2
|
80
|
0
|
70
|
700 с.
| ||
...
|
...
|
...
|
...
|
...
| ||
Модуль поиска XSS-уязвимостей
|
0
|
2
|
0
|
2
|
4
|
15 c.
|
1
|
1
|
1
|
3
|
20 c.
| ||
2
|
0
|
2
|
4
|
30 c.
| ||
...
|
...
|
...
|
...
|
...
| ||
Модуль поиска SQL-уязвимостей
|
0
|
1
|
2
|
1
|
2
|
60 c.
|
1
|
0
|
3
|
2
|
120 c.
| ||
2
|
0
|
4
|
2
|
240 c.
| ||
...
|
...
|
...
|
...
|
...
| ||
Модуль определения установленных сетевых служб Application Fingerprint
| 0 | 3 | 0 | 0 | 3 | 50 c. |
| 1 | 1 | 2 | 2 | 60 c. | ||
| 2 | 0 | 2 | 3 | 70 c. | ||
| ... | ... | ... | ... |
Конечно, не все сканеры ИБ для web-приложений имеют одинаковый набор сканирующих модулей. Тем не менее, при сравнении разнотипных сканеров можно использовать схожую таблицу, где отсутствующие модули сканирования и функционал в конечном итоге будут уменьшать общий рейтинг сканера.
При составлении такой таблицы имеются трудности и в плане определения количества реальных объектов для поиска: невозможно подготовить тестовое приложение с заранее точно известным числом уязвимостей определенного типа. На практике, для частичного решения этой проблемы можно предпринять следующее шаги.
Типы уязвимостей, которые должны быть реализованы в тестовом контенте для проверки сканера, могут быть взяты из классификатора WASC Threat Classification.
Понятно, что ожидаемое число запусков тестовой процедуры для всех возможных комбинаций установленных приложений будет невероятно велико. Уменьшить число проверяемых комбинаций возможно используя технику тестирования pairwise analysis, о которой мы подробнее расскажем в одной из статей.
На основании получаемых по результатам сканирования числовых векторов вида:
В каждом испытании следует выполнять Тестовую Процедуру, описанную выше.При составлении такой таблицы имеются трудности и в плане определения количества реальных объектов для поиска: невозможно подготовить тестовое приложение с заранее точно известным числом уязвимостей определенного типа. На практике, для частичного решения этой проблемы можно предпринять следующее шаги.
- В качестве одной уязвимости рассматривают класс эквивалентных уязвимостей, которые могут быть найдены в тестовом web-приложении. Например, для sql-инъекций классом эквивалентных уязвимостей можно считать все уязвимости, найденные для одного и того же параметра GET-запроса к приложению. То есть, если имеется некий уязвимый параметр id, изменение которого вызывает сбой web-сервера или базы данных, то все векторы атаки, использующие этот параметр, можно считать эквивалентными между собой с точностью до перестановки параметров:
http://example.com/page.php?id=blabla ~ http://example.com/page.php?a=1&id=bla&b=2 - Реализуют самые простейшие тестовые приложения, реализующие или моделирующие некоторую уязвимость, но используя различные фреймворки и разворачивая их на множестве вариантов операционных систем, различных web-серверах, с использованием различных баз данных, с доступом по различным видам сетевых протоколов, а также через различные цепочки прокси.
- Разворачивают на тестовых стендах множество различных CMS, уязвимых приложений (например, DVWA) и сканируют их множеством сканеров безопасности. Общее число уязвимостей, найденных всеми сканерами, берут за эталон и используют в дальнейших тестах на сравнение.
Типы уязвимостей, которые должны быть реализованы в тестовом контенте для проверки сканера, могут быть взяты из классификатора WASC Threat Classification.
Понятно, что ожидаемое число запусков тестовой процедуры для всех возможных комбинаций установленных приложений будет невероятно велико. Уменьшить число проверяемых комбинаций возможно используя технику тестирования pairwise analysis, о которой мы подробнее расскажем в одной из статей.
На основании получаемых по результатам сканирования числовых векторов вида:
(уровень защиты, кол-во обнаруженных объектов, False Positive, False Negative, всего объектов, время сканирования)
предлагается ввести метрику качества сканирования, для дальнейшего сравнения показателей и сканеров между собой. Например, это может быть простейшая евклидова метрика.
предлагается ввести метрику качества сканирования, для дальнейшего сравнения показателей и сканеров между собой. Например, это может быть простейшая евклидова метрика.
II. ВИДЫ ТЕСТОВЫХ ИСПЫТАНИЙ
Вторая статья, которую можно использовать при тестировании сканеров web-приложений называется "Анализ точности и временных затрат работы сканеров web-приложений", оригинал (en):
В ней описано проведение испытаний различных сканеров web-приложений (BurpSuitePro, Qualys, WebInspect, NTOSpider, Appscan, Hailstorm, Acunetix). В частности, для каждого конкретного сканера предлагается проводить четыре типа испытаний:
- Выполнить сканирование web-приложения в режиме Point and Shoot (PaS) и определить число найденных и подтвержденных уязвимостей.
- Выполнить повторное сканирование web-приложения после предварительного "обучения" и настройки сканера на работу с данным типом приложений, определить число найденных и подтвержденных уязвимостей в этом случае.
- Оценить точность и полноту описания найденных уязвимостей.
- Оценить сумму общего времени, потраченного специалистами, на подготовку и проведение тестирования, анализ и обеспечение качества результатов сканирования.
Обучение включает в себя любые дополнительные конфигурации настроек, правку скриптов, запросы к экспертам, связь поставщиками сканера и т. п.
Для того, чтобы определить количество времени специалистов для создания качественного результата в статье предлагается простая формула:
Общее время = Время обучения + #False Positive * 15 мин. + #False Negative * 15 мин.
Общее время = Время обучения + #False Positive * 15 мин. + #False Negative * 15 мин.
III. КРИТЕРИИ ОЦЕНКИ ДЛЯ СКАНЕРОВ WEB-ПРИЛОЖЕНИЙ
При тестировании сканеров web-приложений можно опираться еще на одну статью "Об определении критериев оценки возможностей сканеров web-приложений", оригинал (en):
- Сравнение цены продукта по отношению к оценкам критериев. (A Price Comparison – in Relation to the Rest of the Benchmark Results). Пример сравнения можно посмотреть в сводной таблице: http://www.sectoolmarket.com/price-and-feature-comparison-of-web-application-scanners-unified-list.html
- Универсальность применения сканера – это число поддерживаемых протоколов и Векторов Доставки – методов доставки данных к серверу. (Scanner Versatility – A Measure for the Scanner's Support of Protocols & Input Delivery Vectors). Вектора Доставки включают в себя такие методы доставки данных к серверу, как HTTP-параметры строк запроса, параметры HTTP-body, JSON, XML, двоичные методы доставки для конкретных технологий таких, как AMF, Java сериализованные объекты и WCF. Пример сравнения можно посмотреть в сводной таблице: http://www.sectoolmarket.com/input-vector-support-unified-list.html
- Количество поддерживаемых векторов атаки: количество и тип активных плагинов сканера. (Attack Vector Support – The Amount & Type of Active Scan Plugins (Vulnerability Detection)). Пример сравнения можно посмотреть в сводной таблице: http://sectoolmarket.com/audit-features-comparison-unified-list.html
- Точность обнаружения CSS. (Reflected Cross Site Scripting Detection Accuracy). Пример сравнения можно посмотреть в сводной таблице: http://sectoolmarket.com/reflected-cross-site-scripting-detection-accuracy-unified-list.html
- Точность обнаружения SQL-инъекций. (SQL Injection Detection Accuracy). Пример сравнения можно посмотреть в сводной таблице: http://sectoolmarket.com/sql-injection-detection-accuracy-unified-list.html
- Точность обхода структуры web-приложения и обнаружения локальных файлов. (Path Traversal / Local File Inclusion Detection Accuracy). Пример сравнения можно посмотреть в сводной таблице: http://sectoolmarket.com/path-traversal-local-file-inclusion-detection-accuracy-unified-list.html
- Удаленное использование файлов, XSS, фишинг через RFI. (Remote File Inclusion Detection Accuracy (XSS / Phishing via RFI)). Пример сравнения можно посмотреть в сводной таблице: http://sectoolmarket.com/remote-file-inclusion-detection-accuracy-unified-list.html. Пример тест-кейсов RFI приведен на схеме: https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgWSkHzw-G0ovZJa5tE1YAfV98hrppdJjvjlc1mSHiDBowhpZ_WS7zLJyCHUyDu7DckVKeEIqaz0Ho-oSrOMakn1TqXeH0CeJYYEpBE4w0CRiT_hyzT8hnxrv3d_EUbdHRQOTeWLyS44Jo/s640/Remote+File+Inclusion+Tests.png
- WIVET-сравнение: автоматизированный краулинг и получение входных векторов для атаки. (WIVET (Web Input Vector Extractor Teaser) Score Comparison - Automated Crawling / Input Vector Extraction). Пример сравнения можно посмотреть в сводной таблице: http://sectoolmarket.com/wivet-score-unified-list.html
- Адаптивность сканера: количество дополнительных возможностей сканера для преодоления защитных барьеров (Scanner Adaptability – Complementary Coverage Features and Scan Barrier Support). Пример сравнения можно посмотреть в сводной таблице: http://sectoolmarket.com/coverage-features-comparison-unified-list.html
- Сравнение особенностей аутентификации: количество и тип поддерживаемых способов авторизации и аутентификации. (Authentication Features Comparison). Пример сравнения можно посмотреть в сводной таблице: http://sectoolmarket.com/authentication-features-comparison-unified-list.html
- Количество дополнительных возможностей сканирования и встроенных механизмов. (Complementary Scan Features and Embedded Products). Пример сравнения можно посмотреть в сводной таблице: http://sectoolmarket.com/complimentary-features-comparison-unified-list.html
- Общее впечатление о работе основной функции сканирования. (General Scanning Features and Overall Impression). Пример сравнения можно посмотреть в сводной таблице: http://sectoolmarket.com/general-features-comparison-unified-list.html
- Сравнение лицензий и технологий. (License Comparison and General Information). Пример сравнения можно посмотреть в сводной таблице: http://sectoolmarket.com/list-of-tested-web-application-scanners-unified-list.html
Часть из этих критериев, например, пункты 4-8, уже упоминались выше и входят в Сводную таблицу результатов детектирования объектов. Кроме того видно, что для большинства критериев требуются экспертные оценки, что затрудняет автоматизированное тестирование и сравнение сканеров. Таким образом, предлагаемые в статье критерии оценок можно использовать, например, как разделы содержания более Общего отчета по исследованию характеристик сканера – некоторого документа, содержащего все итоги тестирования и сравнения сканера с конкурентами.
IV. ТИПЫ ТЕСТОВ ДЛЯ СКАНЕРОВ WEB-ПРИЛОЖЕНИЙ
Опираясь на исследование приведённых выше статей, предлагаем следующую классификацию типов тестов для использования их в Тестовой процедуре:
- базовые функциональные тесты (smoke);
- функциональные тесты (functional);
- тесты на сравнение функционала (compare);
- тесты на сравнение показателей оценочных критериев (criteria).
Базовые функциональные тесты должны проверять работоспособность основных низкоуровневых узлов сканера: работу транспортной подсистемы, подсистемы конфигурации, подсистемы логирования и т. п. При сканировании простейших тестовых целей не должно быть сообщений об ошибках, exceptions и traceback в логах, сканер не должен зависать при использовании различных транспортов, редиректов, прокси-серверов и т. д.
Функциональные тесты должны реализовать проверку основных сценариев для проверки технических требований. Должна проверяться работоспособность каждого сканирующего модуля по порядку при различных настройках модуля и тестового окружения. Выполняются позитивные и негативные тестовые сценарии, различные стресс-тесты с использованием больших массивов корректных и некорректных данных, оправляемых сканеру в ответ от web-приложения.
Тесты на сравнение функционала. В таких тестах выполняется сравнение качества и скорости поиска объектов выбранным модулем сканера с аналогичными по функционалу модулями в продуктах-конкурентах. Условия прохождения таких тестов:
- при сканировании эталонной цели время работы выбранного сканирующего модуля должно быть не больше, чем у аналогичного модуля в продуктах-конкурентах;
- при сканировании эталонной цели оценка качества поиска объектов должна быть неотрицательной величиной.
Для каждого конкретного сканирующего модуля должны даваться определения, что подразумевать под объектами для него и качеством их поиска.
Например, для модуля crawler, который имеется в большинстве сканеров web-приложений, можно привести следующие примеры таких определений (для модулей поиска уязвимостей даются аналогичные определения):
Например, для модуля crawler, который имеется в большинстве сканеров web-приложений, можно привести следующие примеры таких определений (для модулей поиска уязвимостей даются аналогичные определения):
- Под однотипными объектами для модуля crawler будем понимать ссылки, найденные тестируемым сканером, для которых имеются соответствующие ссылки, найденные сканерами-конкурентами, с полем url содержащим эквивалентную ссылку.
- Под оценкой качества поиска ссылок модулем crawler будем понимать разницу между числом уникальных ссылок найденных тестируемым сканером и аналогичными модулями продуктов-конкурентов.
Тесты на сравнение показателей оценочных критериев. В таких тестах проверяется, что скорость и качество поиска объектов каждым сканирующим модулем в каждой новой версии тестируемого сканера не ухудшились, по сравнению с предыдущей версией. Определения скорости и качества задаются аналогично, как и для тестов на сравнение функционала. Разница в том, что в данном типе тестов в качестве "конкурента" для тестируемого сканера выступает его предыдущая версия.
Использовать описанные в данной статье Тестовую процедуру, виды тестовых испытаний, критерии оценки и типы тестов возможно для любых сканеров ИБ web-приложений. Применяя метрику качества сканирования, мы получаем инструмент для качественного сравнения сканеров через сравнение их метрик. Как дальнейшее развитие данной идеи предлагается использовать нечеткие показатели, шкалы и метрики для упрощения работы экспертов над качественным сравнением сканеров ИБ web-приложений.
