Напишите свой первый отчёт по безопасности, который будут читать

Большинство первых отчётов по безопасности терпят неудачу предсказуемым образом: они сохраняют процесс тестировщика. Затем читатель должен самостоятельно восстановить картину риска. И отчёт остаётся незавершённым. Читабельность — это средство контроля безопасности, поскольку именно она определяет, дойдёт ли уязвимость до человека, который может её устранить.

Начинайте отчёт по безопасности с решения. Отделяйте последствия для руководства от технических доказательств. Проверяйте каждую уязвимость вручную. Давайте каждому ответственному конкретное исправление. Затем перед отправкой отредактируйте текст на предмет точности, ясности и единообразия. Задача отчёта — побуждать к действию, а не вести дневник тестирования.

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

В этой статье

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

Отчёты терпят неудачу, когда читателю приходится проводить анализ

Отчёт может быть технически корректным и всё равно не выполнять свою задачу. В первых отчётах обычно наблюдается предсказуемый дисбаланс: страницы повествования о работе сканера и слишком мало объяснений решения (по части сканирования см. наш гид по выбору инструментов для пентеста), которое должен принять читатель.

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

Hack The Box точно формулирует проблему написания: «Письмо — это технология. В истории человечества она независимо изобреталась как минимум четыре или пять раз». Вашему первому отчёту не нужно доказывать, что вы от природы специалист по написанию security-текстов. Ему нужен воспроизводимый метод.

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

Определите, кто должен действовать, до начала написания

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

Читатель	Нужно в первую очередь	Нужно в следующих слоях
Руководители и руководители направления безопасности	Последствие, затронутая область бизнеса и приоритет устранения	Степень воздействия, ограничения и требуемое решение
Технические команды	Затронутый компонент, проверенное состояние и направление устранения	Параметры, первопричина, шаги воспроизведения и доказательства

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

Рассмотрим этот вымышленный иллюстративный пример: endpoint /admin/export без аутентификации возвращает записи клиентов. Этот endpoint и его поведение выдуманы для демонстрации написания отчёта.

Для руководителя описание уязвимости может выглядеть так:

Endpoint /admin/export приложения возвращал записи клиентов без требования аутентифицированной сессии. Владелец должен ограничить endpoint авторизованными пользователями и проверить, остаются ли существующие ссылки на экспорт действительными после добавления авторизации.

Для инженера в том же описании потребуются протестированный метод, запрос, ответ, состояние аутентификации, затронутые данные, шаги воспроизведения и подробности устранения. Версия для руководителя отвечает на вопрос: «Какое решение нам следует принять?» Техническая версия отвечает на вопрос: «Какое условие мы должны изменить и как проверим результат?»

Руководителям нужны последствия и решение, а не экскурсия по цепочке атаки. Техническим командам нужна цепочка атаки, потому что она показывает, что именно следует изменить.

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

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

Поместите решение в начало, а доказательства сохраните ниже

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

Документ должен следовать пути читателя:

1. Резюме для руководства: Объясните, что оценивалось, и укажите основные последствия. Опишите важные уязвимости и необходимые решения или меры устранения. Включайте резюме инцидента или угрозы только в том случае, если задание было связано с инцидентом или выявленной угрозой.
2. Область и ограничения: Определите оценённые системы и среды. Включите даты, исключения, тестовые учётные записи и условия, ограничивающие интерпретацию результатов.
3. Методология: Кратко опишите подход к оценке. Указывайте стандарты или инструменты, если они проясняют охват.
4. Обзор уязвимостей: Покажите количество уязвимостей и распределение по степени серьёзности. Используйте одинаковые обозначения во всём документе.
5. Подробные описания уязвимостей: Для каждой подтверждённой слабости укажите её состояние, влияние, доказательства, устранение и границы применимости.
6. Статус устранения и повторного тестирования: Укажите рекомендуемые действия и то, были ли исправления проверены, находятся ли они в ожидании или выходят за рамки задания.
7. Приложения: Переместите сюда подробные запросы и вывод инструментов. Здесь же разместите терминологию и другие вспомогательные материалы.

Для большинства отчётов о penetration testing и отчётов об оценке безопасности такой структуры достаточно. Всё остальное — это путь читателя.

Вымышленная проблема /admin/export должна быть представлена в резюме как решение:

В ходе оценки была подтверждена слабость контроля доступа в endpoint /admin/export приложения. Endpoint возвращал записи клиентов без аутентифицированной сессии. Для устранения требуются серверные проверки аутентификации и авторизации с последующей проверкой того, остаются ли существующие ссылки на экспорт действительными.

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

CVSS — полезные метаданные, но не замена объяснению влияния на бизнес. Число степени серьёзности не может сказать ответственному, что исправлять в первую очередь.

Если ваша организация использует CVSS, укажите эту систему оценки и добавьте оценку и вектор там, где это требуется. Объясните техническую оценку с учётом соответствующих условий атаки и привилегий. Включите взаимодействие с пользователем и затронутые свойства безопасности. Отделяйте эту оценку от бизнес-приоритета. Если организация применяет локальную корректировку степени серьёзности с учётом критичности актива и чувствительности данных, также укажите воздействие или компенсирующие меры контроля и объясните причину. Локальный приоритет — это организационное решение; это не замаскированная оценка CVSS.

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

Озаглавливайте уязвимость, указывая состояние и цель:

Доступ к экспортам клиентов без аутентификации в /admin/export

«Проблема с контролем доступа» даёт читателю категорию и больше ничего. Полезное описание уязвимости отвечает на семь вопросов.

• Что произошло?
• Где это произошло?
• Как это было проверено?
• Почему это важно?
• Насколько это серьёзно согласно указанному методу?
• Что должно произойти дальше?
• Каковы границы доказательств?

TrustedSec определяет простой язык как язык, который «может быть понят слушателем/читателем при первой встрече», и говорит, что его цель — ясность и доступность, а не «упрощение» содержания. Это правильный стандарт для технических текстов по безопасности.

Простой язык — это техническое письмо, не заставляющее читателя переводить каждое предложение. Используйте конкретные подлежащее и сказуемое. Заменяйте «это» на endpoint или контроль, если местоимение может быть неоднозначным. При необходимости называйте сервис или учётную запись. При первом использовании раскрывайте сокращения. «Операционная команда» помогает большему числу читателей, чем «Ops», а «штаб-квартира» понятнее, чем «HQ».

До и после

Слабый, намеренно слабый вариант

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

Это предложение скрывает endpoint, условие доступа, затронутый ресурс и действие. Слово «проблема» почти ничего не сообщает. «Потенциально может» добавляет туман вместо полезной неопределённости.

Более сильный вариант

Endpoint /admin/export возвращал записи клиентов без требования аутентифицированной сессии. Неаутентифицированный пользователь мог получить URL экспорта и получить доступ к записям. Ограничьте endpoint аутентифицированными пользователями с соответствующими правами, затем проверьте, остаются ли существующие ссылки на экспорт действительными после добавления авторизации.

Первое предложение описывает проверенное состояние. Второе описывает продемонстрированный путь доступа. Третье даёт ответственному упорядоченное требование по устранению. Пример остаётся вымышленным и иллюстративным.

Используйте страдательный залог, когда он делает состояние понятнее. «Учётная запись была отключена во время повторного тестирования» вполне подходит, если исполнитель действия не имеет значения. Избегайте страдательных конструкций, скрывающих ответственного или действие.

Указывайте первопричину, если вы её знаете. Если вы подтвердили отсутствие авторизации на endpoint, но не установили, какой компонент фреймворка стал причиной, сообщите о состоянии контроля доступа. Догадки о middleware или процессе разработки ослабляют описание уязвимости.

В устранении должны быть названы контроль и его расположение. «Примените лучшие практики безопасности» — именно так уязвимость регистрируют, одобряют и игнорируют. Для этого вымышленного endpoint требуются аутентификация и серверные проверки авторизации, а затем проверка существующих ссылок на экспорт. Если эти ссылки остаются действительными после добавления авторизации, их следует сделать недействительными или заменить. Это требования по устранению, а не наблюдения о том, что уже доказало тестирование.

Наконец, опишите ожидаемый результат проверки. Неаутентифицированный запрос должен получать отказ в авторизации, а разрешённый пользователь должен получать только те записи, которые допускает его роль. Повторное тестирование должно установить этот результат; рекомендация не является повторным тестированием.

Доказательства должны подтверждать утверждение, а не украшать страницу

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

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

Для вымышленной уязвимости /admin/export письменные шаги должны объяснять, как безопасно выполнить запрос в специально предназначенной тестовой среде и какой ответ подтверждает наличие проблемы. На скриншоте должны быть показаны соответствующие запрос и ответ, а также видимый результат успешного доступа.

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

Подпишите вымышленную иллюстрацию: «Неаутентифицированный запрос возвращает экспорт клиентов; токен, имена и значения замаскированы». Подпись такого типа сообщает читателю, где искать. Полный рабочий стол, десять несвязанных команд и одна крошечная строка доказательства дают противоположный эффект.

Укажите, были ли доказательства получены в production, staging или специально предназначенной тестовой среде. Если тестирование остановилось после подтверждения доступа, скажите об этом. Точная граница не позволяет читателю предположить больший масштаб воздействия, чем установила оценка.

Редактируйте в несколько проходов, потому что первый черновик и должен быть плохим

Редактирование — часть оценки. Это больше, чем административная полировка. Каждое неясное предложение добавляет вопрос, на который читатель должен ответить, прежде чем назначить или устранить проблему.

Сначала подготовьте описания уязвимостей. Перед редактированием сделайте паузу минимум на 15 минут; если график позволяет, лучше подождать день или два. Hack The Box предлагает совет, который стоит сохранить: «Один из лучших советов по написанию, которые я когда-либо получал, — плохо написать первый черновик, а затем вернуться и исправить его». Отредактируйте описания уязвимостей, напишите резюме для руководства, затем выполните финальный проход на единообразие по всему отчёту.

Используйте пять проходов:

1. Точность. Сверьте область, активы и endpoints с записью о тестировании. Также проверьте затронутые данные, ссылки на доказательства, степень серьёзности, устранение и заявления о повторном тестировании.
2. Проверка читателем. Отметьте в резюме каждое последствие и решение. В каждом описании уязвимости отметьте отсутствующие актив, ссылку на доказательство, действие ответственного или подробность воспроизведения.
3. Язык. Замените расплывчатые существительные, неясные местоимения, необъяснённые акронимы и ненужное описание работы инструментов. Уберите детали процесса, которые не помогают интерпретировать результат.
4. Единообразие. Согласуйте количество уязвимостей и обозначения степени серьёзности. Затем проверьте терминологию, регистр, использование акронимов и порядок списков. Проверьте каждую таблицу, диаграмму, резюме и перекрёстную ссылку.
5. Оформление. Проверьте заголовки, таблицы и разрывы страниц. Проверьте читаемость скриншотов, маскирование, навигацию и форматирование экспортированного PDF.

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

Используйте чек-лист вместо того, чтобы полагаться на память. Если возможно, попросите другого человека прочитать отчёт: автор, не знакомый с текстом, может проверить объяснение для бизнеса, а технический коллега — воспроизведение. Один внешний читатель лучше, чем ни одного.

Избегайте сокращённых путей, из-за которых отчёт становится ненадёжным

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

• Расширение области: Сначала подтвердите хосты и приложения. Затем проверьте учётные записи, даты, среды и исключения. Не создавайте впечатление охвата систем, которые не оценивались в рамках задания.
• Зависимость от сканера: Вручную проверяйте результаты автоматизированных проверок, фиксируйте наблюдения и обозначайте непроверенный вывод как требующий дальнейшей проверки.
• Отсутствующий статус повторного тестирования: Укажите, проверялось ли исправление, когда оно проверялось и какой результат был зафиксирован. Если повторное тестирование выходило за рамки задания, скажите об этом.
• Рефлекторное сопоставление с требованиями: Сопоставляйте уязвимости с NIST, ISO, CMMC, PCI или другой структурой только тогда, когда такое покрытие требуется заданием и подтверждается тестированием. Ссылка на контроль не доказывает соответствие требованиям.
• Несоответствие заинтересованных сторон: До написания подтвердите аудиторию и шкалу степени серьёзности. Также проверьте требуемый формат и крайний срок принятия решения. Даже технически точной уязвимости нужны определённый ответственный и следующее действие.

Это общие рекомендации по подготовке отчётов, отражённые в руководствах Indusface и GuidePoint Security, а не измеренные универсальные результаты. Используйте их для проверки рабочего процесса, а не для добавления в отчёт неподтверждённой статистики.

Перед отправкой выполните этот финальный чек-лист

Скопируйте его во внутреннюю QA-задачу:

Решение

• Резюме для руководства находится ближе к началу.
• В резюме для руководства указаны последствие и требуемое решение.
• Область и исключения описаны явно. То же относится к датам, средам и ограничениям.
• В каждой рекомендации указано действие ответственного.

Доказательства

• В каждой уязвимости названы актив и состояние. Также указаны влияние, метод оценки степени серьёзности, устранение и ссылка на доказательство.
• Подтверждённые уязвимости проверены вручную.
• Непроверенные потенциальные проблемы явно обозначены.
• Шаги воспроизведения указывают состояние аутентификации и ожидаемый результат.
• На скриншотах показаны контекст и доказательство.
• Учётные данные, токены, PII и данные клиента замаскированы.
• В статусе повторного тестирования указано, было ли проверено исправление.

Единообразие

• Количество уязвимостей совпадает в тексте, таблицах и диаграммах.
• Обозначения степени серьёзности и решения о локальном приоритете согласованы.
• Акронимы и регистр совпадают. То же относится к терминологии и порядку списков.
• Ссылки на соответствие требованиям присутствуют только там, где они поддерживаются заданием.
• По возможности объяснение для бизнеса прочитал человек, не являющийся автором.
• По возможности технический коллега проверил воспроизведение.

Перед отправкой спросите себя, может ли лицо, принимающее решение, определить приоритет проблемы, может ли ответственный назначить её и может ли инженер проверить исправление. Если на какой-либо вопрос ответ «нет», отчёт всё ещё является частью оценки.