Общая информация

Начало - договор об оказании услуги. В нем указываются юридические, технические, временнЫе, ... рамки и ограничения, ответственность сторон. Часть вышеуказанной информации попадает в отчет.

Основа хорошего отчета закладывается перед началом тестирования. 

Тестирование бывает White box (Организация предоставляет все данные) и Black box (тестирование вслепую). 

Оценка уязвимостей и составление отчета

Перед постановкой задачи устранения уязвимости необходимо:

1. Пересчитать критичность уязвимости с учетом "веса" активов и исключений. Добавление исключений должен быть формализован, и включать в себя согласование исключений и регулярный пересмотр. Для пересчета критичности может использоваться фреймворк CVSS.
2. Убедиться, что уязвимость присутствует на самом деле. 
3. Определить владельца актива, который будет ответственным за устранение проблемы.

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

Типы отчетов

• Технический отчет — предназначен для инженеров, которые будут работать над устранением уязвимостей. Это наиболее исчерпывающий отчет, включающий в себя множество технических данных. Не предназначен для технически не подкованных людей.
• Отчет об изменениях — показывает изменения с момента предыдущего скана, например, новые сервисы и уязвимости, которые появились в сети, либо же наоборот, устраненные за наблюдаемый период проблемы.
• Отчет о трендах(тенденциях) — показывает изменения уровня рисков и уязвимостей за период времени. Например, отчет может показать, что в этом месяце было обнаружено на 10% больше критичных уязвимостей чем в прошлом.
• Высокоуровневый отчет — предоставляет результаты сканирования в сжатой форме, без технических подробностей. Предназначен для менеджмента и нетехнического персонала, часто включает в себя графики и диаграммы. 

Внутренние требования

Шаг 1. Выбор стандарта оценки уязвимостей. Стандарт CVSS v3 используется для оценки технической серьезности уязвимости. Стандарт OWASP Risk Rating Methodology используется для оценки рисков web приложения для бизнеса. Иногда рекомендуют использовать оба стандарта.

Шаг 2. Используемая среда / правила оформления / способ хранения информации о найденных уязвимостях. Упоминаются Dradis, CherryTree, OneNote. В правилах оформления определяется набор данных для каждой уязвимости (например дата и время проведения, скриншоты, формат описания последовательности действий). 

Вариант структуры.

1 Всту­питель­ная часть
1.1 Клас­сифика­тор най­ден­ных уяз­вимос­тей
2. Общее опи­сание про­делан­ной работы
3. Тех­ничес­кий отчет
4. Рекомен­дации по устра­нению уяз­вимос­тей

Вступительная часть
Фак­ты, извес­тные исполнителю и заказ­чику до начала работ. К ним отно­сят­ся: дата про­веде­ния пен­теста, методи­ка, которая применя­лась (очень крат­ко), основные эта­пы тес­тирова­ния, перечень сис­тем для тес­тирова­ния и исклю­чения из объ­ема работ, перечень узлов, а так­же методи­ки, которые исполнитель обя­зуется не при­менять (соци­аль­ную инже­нерию или ата­ки на отказ в обслу­жива­нии).

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

В зак­лючении всту­питель­ной час­ти необходимо описать уточнения договора, акту­ализированные на эта­пе тес­тирова­ния. Нап­ример, просьба обратить осо­бое вни­мание на какой‑то новый сер­вис, который появил­ся за неделю до начала тес­тирова­ния, или, наобо­рот, в пос­ледний момент поп­росил исклю­чить из иссле­дова­ния веб‑при­ложе­ние, уяз­вимос­ти в котором наш­ли сво­ими силами бук­валь­но за день до начала работ и которое собира­ются капиталь­но дорабо­тать преж­де, чем вновь показы­вать поль­зовате­лям.

Общее описание проделанной работы
Этот раз­дел дол­жен содер­жать зна­чимую для руково­дите­лей ком­пании‑заказ­чика информа­цию о про­делан­ной работе и ее резуль­татах. Глав­ные тре­бова­ния, предъ­явля­емые к нему, — понят­ность и крат­кость. Сам отчет может рас­тянуть­ся на десят­ки, если не сот­ни стра­ниц. Руково­дитель не всег­да готов читать докумен­тацию такого объ­ема, и зачас­тую в этом нет необ­ходимос­ти. Глав­ное — понять кри­тичес­ки важ­ные резуль­таты для при­нятия даль­нейших решений. Наша задача в этом раз­деле — зав­ладеть вни­мани­ем читате­ля с любым уров­нем под­готов­ки, опи­сать общую ситу­ацию и сооб­щить о наибо­лее зна­чимых выводах.

Технический отчет
Пред­назна­чен для тех­ничес­ких спе­циалис­тов. В нем мы, как инже­неры, объ­ясня­ем дру­гим тех­ничес­ким спе­циалис­там, что мы наш­ли при тес­тирова­нии и чем это может гро­зить.

Вариант - отчет в виде кар­точек по най­ден­ным уяз­вимос­тям с раз­делами:

Крат­кое опи­сание най­ден­ного.	Прос­то и дос­тупно опи­сыва­ем, что уда­лось най­ти, что прив­лекло наше вни­мание.
Уро­вень рис­ка.	Прос­тавля­ем бал­лы по той шка­ле, о которой говори­лось ранее.
Ука­зание мес­тонахож­дения в сис­теме.	Ука­зыва­ем IP-адрес, DNS-имя или что‑то, что однознач­но иден­тифици­рует сис­тему.
Опи­сание инс­тру­мен­тария.	Это необя­затель­ный пункт, но он может очень помочь инже­нерам со сто­роны заказ­чика, ког­да они решат вос­про­извести твои дей­ствия.
Ссыл­ка на опи­сание уяз­вимос­ти.	Что­бы чрез­мерно не уве­личи­вать раз­меры отче­та, рекомен­дуем сде­лать внеш­ние ссыл­ки на опи­сания уяз­вимос­тей из откры­тых баз зна­ний. Выб­рать мож­но любую,  нап­ример cve.mitre.org, cvedetails.com, snyk.io или rapid7.com.
Скрин­шоты и дру­гие под­твержде­ния.	Скрин­шоты нуж­но добав­лять толь­ко при усло­вии, что они наг­лядно что‑то объ­ясня­ют.
Ре­комен­дации, как испра­вить уяз­вимость.	В этом раз­деле нуж­но при­вес­ти рекомен­дации про­изво­дите­ля уяз­вимого прог­рам­мно­го обес­печения или свои собс­твен­ные. В любом слу­чае ответс­твен­ность за устра­нение уяз­вимос­тей лежит на заказ­чике и толь­ко ему решать, как они будут устра­нены и будут ли.

СVSS (Common Vulnerability Scoring System)

Открытый стандарт, позволяющий описывать уязвимости. Пример: 

AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H

CVSS состоит из трех групп метрик, которые описывают уязвимость:

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

Базовая группа

В версии CVSS 3.0 сюда входят следующие метрики:

Метрика	Описание
AV (Attack Vector)	вектор атаки. Варианты: N сетевой (Network) A локальная сеть (Adjacent) L локальный (Local) P физический (Physical).
AC (Attack Complexity)	сложность атаки. Варианты: H высокая. необходимо выполнение доп. условий для эксплуатации уязвимости M средняя L низкая
PR (Privileges Required)	привилегии для эксплуатации уязвимости. Варианты: N (None, привилегии не нужны),  L (Low, нужны низкие привилегии, например права пользователя) H (High нужны высокие привилегии)
UI (User Interaction)	необходимость пользовательского взаимодействия. Варианты: N (None, взаимодействие не требуется) R (Required, требуется)
S (Scope)	граница эксплуатации. Показывает, может ли уязвимость повлиять на безопасность другого компонента системы. Варианты: U (Unchanged, граница не меняется) C (Changed, меняется) Например, уязвимость побега из контейнера, позволяющая выполнить код на хосте будет иметь свойство S:C.
C (Confidentiality)	затрагивает ли уязвимость конфиденциальность информации. Варианты: H высокий M средний L низкий
I (Integrity)	затрагивает ли уязвимость целостность информации. Варианты: H высокий M средний L низкий
A (Availability)	затрагивает ли уязвимость доступность информации. Варианты: H высокий M средний L низкий

Временная группа

Метрика	Описание
E (Exploit Code Maturity)	доступность средств эксплуатации. Варианты: ND/X (Not Defined не определено) H (High средства доступны или не требуются)  F (Functional средства доступны) POC/P (Proof-of-Concept есть пример эксплуатации, но он может не работать) U (Unproven средства недоступны или уязвимость теоретическая)
RL (Remediation Level)	уровень исправления. Очень важная для приоритезации метрика. ND/X (Not Defined информация отсутствует) U (Unavailable исправление недоступно) W (Workaround есть неофициальное исправление) FT/T (Temporary Fix есть официальное, но временное решение)  OF/O (Official Fix официальное исправление уязвимости)
RC (Report Confidence)	достоверность отчета. X (Not Defined не определена) U (Unknown нет информации) R (Reasonable известны некоторые детали об уязвимости) C (Confirmed отчет подтвержден)

Переменные среды

Данные параметры проставляются аналитиком для корректировки оценки уязвимости. Например, если для компании важна доступность какого-либо актива, то специалист может выставить параметр Availability Requirement (AR) в значение High(H).

Метрика	Описание
CR (Confidentiality Requirement)	требования к конфиденциальности. Варианты: H высокий M средний L низкий ND/X не определены
IR (Integrity Requirement)	требования к целостности. Варианты: H высокий M средний L низкий ND/X не определены
AR (Availability Requirement)	требования к доступности. Варианты: H высокий M средний L низкий ND/X не определены

Итоговая оценка

После определения метрик по стандарту CVSS рассчитывается итоговая оценка уязвимости, которая считается по шкале от 0 до 10, где 0 — отсутствие уязвимости, а 10 — максимально критичный приоритет. Формула расчета достаточно сложная, проще библиотеками python или калькулятором. 

Источники:

Статья на Хакере

CVSS V 3.1 Calculator