Представляю вашему вниманию продолжение перевода второй главы Owasp Testing Guide. В данной статье речь пойдет о анализе результатов тестирования и написании отчета.

Анализ результатов тестирования и отчёт

Установка целей для метрик по тестированию безопасности

Для использования результатов тестирования при анализе рисков и в процессах управления необходимо создать количественные показатели (или, по-другому, метрики) тестирования. Для их создания, в свою очередь, необходимо определить цели, которые будут достигаться с помощью метрик. Например, измерение общего числа уязвимостей, найденных во время тестов, может измерить состояние безопасности приложения. Эти метрики также помогают определить цели безопасности в тестировании. К примеру, снижение числа уязвимостей до приемлемого числа (минимума) перед тем как приложение будет выпущено на боевую среду.

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

В традиционном тестировании ПО количество найденных багов может являться мерой качества продукта. Подобным образом тестирование безопасности может являться мерой безопасности ПО. С точки зрения управления дефектами и отчётности, оценка качества ПО и тесты безопасности могут использовать одинаковое распределение по категориям для корневых причин проблем и способов исправления дефектов. Если исходить из корневых причин, дефект безопасности может быть из-за ошибки проектирования (например, брешь в системе безопасности) или из-за ошибки в коде (баг). Усилия, требуемые для его исправления, как и для дефекта качества могут быть измерены в часах, требуемых разработчику для внедрения исправления, а также средств, ресурсов и стоимости этого внедрения.

Характеристика итогов теста безопасности, сопоставленная с качеством тестируемых данных, это распределение для определения риска в терминах угроз, эксплуатации уязвимостей и потенциального влияния уязвимости. Проверка приложения на безопасность включает управление техническими рисками чтобы убедиться в том, что контрмеры в приложении достаточны в текущей ситуации. По этой причине данные, полученные в ходе тестирования безопасности, должны поддерживать стратегию контроля рисков безопасности в критичных контрольных точках ЖЦ.

Качественная мера риска для уязвимости может быть определена исходя из возможности её эксплуатации и вероятности того, что она будет эксплуатирована, а также подтверждения уязвимости пентестами. Меры рисков, связанные с найденными уязвимостями, заставляют бизнес принимать решения по их управлению, например, они могут решить, может ли риск быть принят, смягчен или перенесён на другой уровень внутри организации.

Оценивая состояние безопасности приложения важно брать в расчёт некоторые факторы, такие как размер разрабатываемого приложения. Статистически доказано, что размер приложения связан с количеством проблем, которые в нём обнаруживаются в процессе тестирования. Одной метрикой размера приложения является количество строк кода. Обычно качество приложения варьируется от 7 до 10 дефектов на 1000 строк кода [http://www.criminal-justice-careers.com/resources/SDLCFULL.pdf]. Поскольку тестирование может снизить общее количество дефектов на 25% при одном только тесте, логично, что приложения большего размера должны тестироваться чаще, чем маленькие приложения.

Когда тестирование безопасности производится на нескольких стадиях ЖЦ, данные результатов тестирования могут продемонстрировать возможности тестов в обнаружении уязвимостей в момент их появления. Данные тестирования могут также доказать эффективность борьбы с уязвимостями за счёт внедрения контрмер на разных контрольных точках ЖЦ ПО. Измерения такого типа также определяются как «ограничительные» и отражают меру способности сохранять безопасность на каждой стадии. Эти ограничительные меры являются также критическим фактором в снижении стоимости исправления уязвимостей. Гораздо дешевле справится с уязвимостью в той же стадии ЖЦ ПО, в которой они были найдены, чем исправлять их позже в другой стадии.

Метрики тестирования безопасности могут участвовать в анализе рисков безопасности, стоимости и управления рисками в случаях, когда они связаны с ощутимыми временными целями, такими как:

• снижение общего числа уязвимостей на 30%
• исправление проблем безопасности к определённому дедлайну (например, перед выпуском бета версии).

Данные тестирования могут быть абсолютными, как например количество найденных уязвимостей в процессе ручного анализа кода, а также относительными: количество уязвимостей, обнаруженных при анализе кода по сравнению с пентестами. Для оценки качества процесса обеспечения безопасности нужно определить базовый уровень, то есть то, что считается приемлемым для безопасности. Данные по результатам тестирования могут также помочь отслеживать особые цели анализа безопасности. Это может быть, например, соответствие нормам безопасности и стандартам ИБ, управление процессами безопасности, определение корневых причин проблем безопасности и улучшение процессов, а также анализ выгоды от вложений в ИБ.

Когда данные тестирования представляются в отчёте, к ним должны быть прикреплено описание метрик. Целью анализа является интерпретация этих данных для поиска ключевых моментов по защищённости выпускаемого ПО, а также эффективности процесса безопасности.

Некоторые примеры сведений, которые можно найти в данных тестирования:

• Были ли уязвимости смягчены до приемлемого уровня для выпуска ПО?
• Насколько безопасен данный продукт по сравнению с аналогичным ПО на рынке?
• Все ли требования тестирования безопасности были выполнены?
• Какие основные корневые причины проблем безопасности существуют?
• Насколько многочисленны бреши в безопасности по сравнению с багами для ИБ?
• Какой метод тестирования позволил найти наибольшее число уязвимостей?
• Какая команда была наиболее продуктивна в исправлении дефектов безопасности и уязвимостей?
• Какой процент высокорисковых уязвимостей от их общего числа?
• Какие инструменты наиболее эффективны в определении уязвимостей?
• Какой тип тестов безопасности наиболее эффективен в поиске уязвимостей (например, черным/белым ящиком)?
• Сколько проблем безопасности было найдено в процессе проверки кода?
• Сколько проблем безопасности было найдено в процессе проверки архитектуры приложения?

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

Проблемой является то, что не найденные проблемы с безопасностью не тестируются. Факт того, что тесты безопасности проходят без проблем, не говорит о том, что приложение или ПО являются защищёнными. Некоторые исследования [http://cwe.mitre.org/documents/being-explicit/BlackHatDC_BeingExplicit_Slides.ppt слайд 30] демонстрируют это: в лучшем случае инструменты могут найти только 45% от общего числа уязвимостей.

Даже самые современные инструменты автоматизации не сравнятся с опытным тестировщиком ИБ. Полагаясь только на успешные результаты тестирования от средств автоматизации, специалисты будут иметь ложное чувство уверенности в защищённости. Обычно, чем более опытны тестировщики в работе с методологиями тестирования безопасности и инструментами, тем лучшие результаты теста безопасности и анализа они будут выводить. Важно то, что менеджеры, вкладываясь в инструменты тестирования безопасности, рассматривают инвестирование в найм опытных сотрудников также, как и в обучение тестированию безопасности.

Требования к отчёту по тестированию

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

Уязвимости могут быть классифицированы по различным критериям. Наиболее широко используемая метрика серьёзности уязвимости это Common Vulnerability Scoring System (CVSS) от Forum of Incident Response and Security Teams (FIRST), которая сейчас доступна в 3-ей версии.

Предоставляя отчёт по данным тестирования хорошей практикой является включение в него следующей информации:

• Категоризирование каждой уязвимости по типу
• Угроза безопасности, которой подвергнут каждый описанный тест-кейс
• Корневая причина проблем безопасности (баги, бреши)
• Техника тестирования, использованная для обнаружения проблемы
• Исправление уязвимости (контрмеры)
• Серьёзность уязвимости (высокая, средняя, низкая или в рейтинге CVSS).

Отчёт о корневой причине проблемы может помочь заострить внимание на том, что должно быть исправлено. В случае с тестированием методом белого ящика, например, корневой причиной уязвимости приложения будет исходный код.

Когда отчёт о тестировании составлен, важно также предоставить руководство для разработчика ПО о том, как обнаружить эту уязвимость при повторном тестировании. Это может включать использование тестирования методом белого ящика (например, пересмотр безопасного кода статическим анализатором) с целью обнаружить, является ли код уязвимым. Если уязвимость может быть найдена с помощью тестирования методом чёрного ящика (пентест), отчёт о тестировании должен также предоставлять информацию по тому, как подтвердить проявление уязвимости для клиентской части.

Информация о том, как исправить уязвимость, должна быть достаточно детальной, чтобы разработчик понял, как внедрить исправление. Она должна предоставлять примеры безопасного кода, изменений конфигурации и предлагать ссылки на необходимые материалы.

В конце концов, степень серьёзности уязвимости способствует расчёту уровня риска и помогает расставить приоритеты по исправлению ошибок. Обычно расчёт уровня риска уязвимости включает внешний анализ, опирающийся на такие факторы, как влияние и проявление уязвимости.

Влияние на бизнес

Для того, чтобы метрики тестирования безопасности были полезны, они должны иметь ценность для стейкхолдеров организации. Они могут включать менеджеров проекта, разработчиков, офицеров ИБ, аудиторов и менеджеров ИТ отдела. Ценность для разных областей бизнеса, за которые отвечают стейкхолдеры проекта, может быть разной.

Разработчики ПО могут использовать данные тестирования чтобы показать, что код ПО стал безопаснее и рациональнее. Это оправдывает использование инструментов анализа исходного кода, а также следование стандартам безопасного программирования и посещение обучений безопасности ПО.

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

Данные тестов безопасности также помогают офицерам ИБ. Например, они могут предоставить доказательства того, что тестирование безопасности на стадиях ЖЦ не влияет на сроки проекта, но значительно сокращает нагрузку, требуемую для устранения уязвимостей после выпуска ПО.

Для аудиторов по соответствию законодательству, метрики тестов безопасности могут предоставить уверенность в защищённости ПО, также уверенность в том, что соответствие стандартам соблюдается.

Наконец, менеджеры ИТ и ИБ отделов, ответственные за бюджет на обеспечение безопасности, интересуются частью с анализом стоимостной выгоды от итогов тестирования. Это позволяет им принять осознанные решения, в какие активности по безопасности и инструменты следует инвестировать. Одной метрикой, которая поддерживает такой анализ, является возврат с инвестиций (ROI) в безопасности [http://www.blackhat.com/presentations/bh-usa-06/bh-us-06-Morana-R3.0.pdf]. Для вывода таких метрик из данных тестирования нужно измерить разницу между риском из-за эксплуатации уязвимостей и эффективностью тестов безопасности в смягчении данного риска, и сравнить эту разницу со стоимостью активности тестирования или использованных инструментов.