После завершения любого проекта (по пентесту, анализу защищенности, Red Teaming и др.) специалисты приступают к самому душному увлекательному этапу – к написанию отчета. Казалось бы, ничего особенного – нужно всего лишь свести в единый документ все свои достижения. Но правда жизни такова, что именно отчет выступает итоговым результатом работ, который видит заказчик и по которому он будет судить о качестве проделанной работы. То есть, какие бы суперисследования мы ни провели, какие бы крутые баги ни нашли, заказчик никогда не узнает, какие мы молодцы, солнышки, котики профессионалы, если полученные результаты с их экспертной оценкой не будут понятно, структурировано и в полном объеме изложены в отчете. А это далеко не всегда простая задача.
В этом посте поделимся некоторыми нюансами и особенностями, которые мы учитываем при подготовке отчетов. Надеемся, эта информация будет полезна всем, кто так или иначе задействован в подобных процессах.
Фантастический отчет и как его писать
Отчет – это подробное описание проведенных работ, полученных результатов, выявленных векторов атак, уязвимостей и недостатков, рекомендаций по их устранению, а также всего, что нужно сообщить заказчику по итогам проекта.
Написать хороший отчет – задача творческая и далеко не всегда тривиальная, ведь нужно учесть ряд важных моментов.
1. Отчет – это тот результат работ, за который платит заказчик
Именно по отчету заказчик судит о качестве проделанной работы. Поэтому важно, чтобы отчет был понятным, структурированным, в полной мере отражал всю проделанную работу, а также содержал экспертную оценку полученных результатов (критичность выявленных уязвимостей и недостатков, возможные последствия их успешной эксплуатации и т.д.).
2. Отчет читают разные люди
Это могут быть как технические специалисты, например, разработчики или ИБ-команда заказчика, которые фиксят найденные баги, так и представители бизнесовой сферы. Поэтому в отчете следует избегать профессиональных жаргонизмов, минимизировать англицизмы, правильно употреблять слова в соответствии с их значением.
Если нужно добавить в отчет текст из иностранного источника, например, рекомендации по устранению уязвимости от разработчиков программного обеспечения, то это не должен быть топорный перевод из переводчика - текст нужно переписать понятным для восприятия языком.
Также важно правильно использовать те или иные слова. Наш «любимый» пример – «функционал» и «функциональность». Понятно, что в разговорной речи фраза «функционал программы» - давно устоявшееся и привычное выражение. Но если включить режим душнилы заглянуть в энциклопедический словарь, то мы увидим, что «функционал» – это понятие из математики, а вот у программы есть функциональность. И таких ситуаций может быть много.
3. Формат отчета может меняться при передаче заказчику
Например, отчет изначально делается в каком-либо текстовом редакторе, а для передачи заказчику переводится в PDF или распечатывается. Почему это важно?
В технической части отчета (той самой, где приводится детальное описание всех находок) всегда много скринов, иллюстрирующих процесс и результаты работ и являющихся пруфами для заказчика.
При этом если сделать плохие скрины, которые еще плюс-минус будут читаться в первоначальном варианте, то после всех итераций конвертирования они станут нечитаемыми, и достижения по проекту будут просто обесценены. А у заказчика возникнут сложности при изучении отчета.
4. На структуру отчета влияет тип работ, по которому этот отчет пишется
Основные работы, которые нужны заказчикам всегда – это анализ защищенности и пентест, поэтому их мы выполняем наиболее часто и далее подробно поговорим именно про них. При этом, стоит отметить, что ключевые принципы построения отчета можно использовать для любого типа работ:
5. Для разных заказчиков отчеты могут составляться по-разному
Не стоит забывать, что каждый проект уникален. И требования заказчиков (в том числе и к отчетной документации) могут быть разными. Например, один хочет, чтобы в отчете была классификация уязвимостей по методологии ФСТЭК, другой – по OWASP TOP 10 и т.д. Все это необходимо учитывать.
Еще один важный момент: структура и специфика отчета зависят от конкретной компании и ее внутренних правил. Соответственно, та структура и особенности, о которых пойдет речь далее – это наши устоявшиеся правила написания отчетов, выработанные методом проб и ошибок за время долгой практики. При этом в разных компаниях они могут быть разными, и мы не претендуем на то, что наши правила – единственно верный вариант написания отчетов, а лишь делимся своей экспертизой.
Структурируем отчет
Как мы писали выше, многое зависит от типа работ, по которому пишется отчет. Однако в целом можно выделить некую обобщенную структуру. В отчеты мы включаем следующие разделы:
Ведение
Вводная часть, в которой приводится общее описание проекта. Здесь мы указываем следующее:
Тип работ (что делали);
Информацию о заказчике (для кого делали);
Информацию о договоре (на каком основании копались в системе заказчика);
Границы работ, или скоуп (что исследовали: подсети IP-адреса, названия приложений и т.д.);
Цель и задачи работ (зачем проводили исследования и чего пытались добиться);
Методика проведения работ (список проводимых проверок, используемое ПО и др.);
Методика оценки степени критичности уязвимостей и недостатков (по какому принципу выделяем самое опасное и какие критерии учитываем при формировании экспертной оценки).
Краткое изложение результатов
Отчет читают разные люди: как технари, так и представители бизнеса, которые могут не разбираться во всех технических деталях. Поэтому в отчете важно предусмотреть раздел, в котором лаконичным и понятным для нетехнических специалистов языком будут описаны основные результаты. В каких-то компаниях практикуют разделение отчета на две части: краткий на 3-5 страниц для «бизнеса» и подробный технический – для профильных специалистов.
Чтобы не разделять отчет и структурировать все результаты в едином документе, мы выделяем для бизнесовой части раздел «Краткое изложение результатов». В него мы включаем:
1. «Саммари» (summary) - без технических подробностей и деталей описываем «самое-самое»: что сделали, что нашли, какие задачи решили, какие риски информационной безопасности актуальны для заказчика.
Из саммари заказчик сразу может понять, каких результатов мы добились – реализовали несколько векторов пробива внешнего периметра, повысили привилегии во внутренней сети, получили доступ к персональным данным и др., и какие уязвимости и недостатки для этого были задействованы.
2. Список уязвимостей и недостатков. Наша практика показывает, что максимально удобная форма для визуального восприятия — это таблица, содержащая информацию о выявленных уязвимостях и недостатках, уровнях их критичности, угрозах, которые из них следуют, и ссылки на соответствующие пункты отчета.
В этой таблице кратко приводится наша экспертная оценка, которая позволяет заказчику сразу увидеть, сколько критичных уязвимостей и недостатков было обнаружено, какие из них проще проэксплуатировать и к реализации каких угроз может привести их успешная эксплуатация.
3. Схемы векторов атак и таймлайны. Это актуально в основном для пентестов и Red Teaming. Схемы векторов наглядно отражают основные шаги, которые привели к достижению цели (преодолению внешнего периметра, повышению привилегий во внутренней сети, получению доступа к критичным системам и др.). В настоящее время существует множество удобных инструментов для создания подобных схем, начиная с древнейшего Visio и заканчивая собственными разработками.
Таймлайн, или хронология, позволяет показать, как развивалась атака во времени и зафиксировать моменты выполнения критичных действий. Если в отчет планируется добавлять таймлайн, то рекомендуем записывать тайминги сразу в процессе работ, потому что, как показывает практика, восстановить точную хронологию после завершения проекта затруднительно, а иногда вообще невозможно.
Подробное описание
Эта часть ориентирована в первую очередь на технических специалистов заказчика, которые будут работать с отчетом и устранять выявленные уязвимости и недостатки. В данном разделе мы приводим подробное техническое описание проведенных работ: даем детали по обнаруженным уязвимостям и недостаткам с экспертной оценкой, примерами эксплуатации и рекомендациями по устранению, подробное разбираем шаги векторов атак.
Приложение
Приложение – это скорее опциональный раздел. Мы выносим в него большие списки, таблицы и прочие подобные материалы (например, списки скомпрометированных учеток). Это позволяет не перегружать отчет списками на 100500 страниц, которые заказчику придется пролистывать при прочтении документа.
Различия между отчетами по пентесту и анализу защищенности
Давайте подробнее остановимся на специфике и основных различиях отчетов по пентесту и анализу защищенности.
Пентест
Отчет по пентесту в первую очередь отвечает на вопрос «как достигли цели?», то есть основная задача – описать векторы атак (пробивы внешнего периметра, взятие домена админа и др.).
В отчете по пентесту каждый пункт – шаг атаки. Пункты отражают какое-либо действие и могут называться, например, «повышение привилегий», «компрометация узла example.com». Если векторов много, то каждый из них может быть выделен в отдельный пункт, а шаги – в подпункты.
Также мы всегда вносим в отчет потенциальные векторы атак. Например, бывают ситуации, когда мы обнаруживаем уязвимость, из которой можно развить успешный вектор атаки, однако ее эксплуатация может привести систему к состоянию неработоспособности, и после обсуждения с заказчиком принимаем решение этот вектор не развивать. Или реализовать вектор не позволяют какие-либо настройки сети, при изменении которых вектор уже будет не потенциальным. В таком случае важно указать заказчику на проблему, так как реальный хакер все еще может попытаться развить такой вектор.
Кроме того, в ходе пентеста могут быть найдены уязвимости и недостатки, которые в векторах не задействованы, но от этого не менее опасны. В таком случае имеет смысл вынести их в отдельный пункт, например, «Прочие уязвимости и недостатки, обнаруженные на внешнем периметре/во внутренней сети».
Анализ защищенности
Главная цель анализа защищенности – выявить все имеющиеся в приложении уязвимости и недостатки. И в этом случае отчет отвечает на вопрос «что нашли?». Каждый пункт – это описание конкретной уязвимости или недостатка.
Векторов здесь, конечно, уже нет, но баги могут быть связаны между собой. Например, в ходе работ обнаружена возможность подбора учетных данных на основе анализа ответов от сервера. Далее с помощью этой баги был получен список учеток. При этом в приложении могут отсутствовать механизмы защиты от атак подбора паролей, что позволяет провести такую атаку для полученных учеток и подобрать пару «логин-пароль».
А помимо возможности подбора учетных данных, может быть еще найдена какая-нибудь публично доступная админка, для которой эти учетные данные отлично подойдут. Бинго!
В подобном случае есть смысл сделать между багами перекрестные ссылки.
Хорошей практикой также является перечисление уязвимостей и недостатков в порядке убывания степени их критичности. Так можно акцентировать внимание заказчика на самых опасных вещах и показать, что в первую очередь нужно исправить.
Описываем свои находки
- Штурман, прибор!
- Шессот!
- Что шессот?
- А что прибор?
В предыдущем разделе мы дали общее представление о построении «скелета» отчета. Теперь поговорим о его наполнении и смысловой нагрузке – об описании обнаруженных уязвимостей и недостатков. Отметим, что это актуально не только для анализа защищенности, но и для пентестов, так как шаги векторов атак также основываются на эксплуатации тех или иных уязвимостей.
В разных компаниях процесс описания найденных баг построен по-разному. Например, у нас есть специальная система, в которой предусмотрены шаблоны для занесения баг. После завершения проекта мы выгружаем единый документ со всеми внесенными багами и работаем с ним. В каких-то компаниях отчет пишется вручную с нуля. Например, каждый пишет про свою часть в отдельном доке, после чего все сводится в единый файл.
Однако, независимо от того, как построен процесс подготовки отчета, мы считаем важным предусмотреть следующие основные моменты для описания уязвимостей и недостатков:
1. Продумать принцип описания сути выявленной уязвимости (недостатка), т.е. решить, какую основную информацию необходимо сообщить заказчику и как эту информацию структурировать. Это может быть как общее описание уязвимости и принципа ее работы в целом, независимо от конкретной системы, так и описание принципа ее эксплуатации непосредственно в системе (инфраструктуре) заказчика. Для максимально полной картины имеет смысл привести обе составляющие.
2. Разработать «систему координат», которая позволит максимально точно локализовать найденную уязвимость (недостаток) и показать заказчику, где нужно провести работу по ее устранению. То есть показать, где именно в приложении и/или сети она была выявлена. Важно помнить, что чем точнее будет указано место обнаружения уязвимости (недостатка), тем проще заказчику будет ее найти в своей системе и исправить.
3. Определиться с системой экспертной оценки уязвимостей и недостатков, которая продемонстрирует заказчику степени критичности тех или иных уязвимостей для его сети и/или системы и поможет расставить приоритеты при их устранении. Для оценки могут быть использованы как существующие методики, например, CVSS, так и собственные разработки, при этом часто применяется «микс» из двух подходов. В большинстве случаев в оценке применяются такие параметры, как уровень критичности уязвимости и сложность ее эксплуатации, но каждая команда исполнителей формирует подобную методику на основании собственного опыта и устоявшейся практики.
4. Продумать правила описания процесса эксплуатации и оформления иллюстраций. В отчете необходимо описать, какие действия нужно выполнить, чтобы воспроизвести багу. Например, это могут быть как отдельные запросы, так и последовательности определенных действий.
Доказательством успешной эксплуатации в свою очередь выступают скриншоты, иллюстрирующие выполняемые пентестерами действия и их результаты.
Мы рекомендуем делать скрины сразу по ходу работ, а не ждать начала написания отчета. Лучше сделать лишние скрины, которые потом можно просто удалить, чем не зафиксировать что-то нужное. Это важно потому, что после завершения работ заказчик может заблокировать доступ к исследуемым ресурсам или же исправить какие-то из найденных критичных баг в ходе работ. В таком случае возможность привести доказательство успешной эксплуатации баги будет потеряна.
Еще один полезный совет: начальным этапом любого проекта является сбор информации, в ходе которого в открытых источниках (например, на Github) могут быть обнаружены учетки, в последующем используемые в проекте. В таком случае мы обязательно делаем скрин, доказывающий что мы действительно получили эти данные с Github, а не ворвались под покровом ночи в офис заказчика и не обнаружили на мониторе стикер с теми самыми злосчастными кредами «admin:11111» (если только мы не проводим работы с возможностью физического проникновения ;)). К тому же проинформировать заказчика об утечке подобных данных не менее важно.
5. Проработать правила написания рекомендаций по устранению найденных уязвимостей и недостатков. Помимо описания выявленных уязвимостей и недостатков и реализованных векторов атак важно также прописать, что делать со всем тем барахлом набором проблем, который был обнаружен, и как заказчику защитить свои информационные активы.
Грамотно составленные исчерпывающие рекомендации помогут заказчику своевременно принять меры по устранению обнаруженных проблем и повысить уровень защищенности системы. При этом имеет смысл соблюдать «золотую середину» между обобщенностью и детализацией. Мы можем порекомендовать заказчику, например, разработать строгую парольную политику и указать критерии сложности устанавливаемых паролей, так как это не повлияет на текущую работоспособность его систем. Но стоит воздержаться от советов заказчику по внесению каких-либо конкретных правок в программный код или изменению настроек его программных средств, так как мы не обладаем полной картиной устройства всей системы и/или инфраструктуры заказчика и не можем гарантировать, что внесенные им изменения не скажутся на работе как самой системы, так и взаимодействующих с ней элементов других систем.
Disclamer
Важно заметить, что на сегодняшний день существует множество различных приемов и методик, используемых при составлении отчетов: методик оценки уязвимостей и недостатков, способов описания и подтверждения обнаруженных баг, примеров описания рекомендаций и т.д. Более того, каждой командой исполнителей могут разрабатываться и применяться собственные приемы и методики.
Мы не даем каких-то конкретных советов в пользу той или иной системы оценки, способа подтверждения уязвимостей и т.д., так как выбор конкретных методик и приемов зависит от практического опыта команды исполнителей, требований заказчиков, экспертной оценки специалистов и многих других факторов. И даже выработанные изначально правила могут постепенно меняться и корректироваться с течением времени.
Задача же этой статьи – поделиться общими рекомендациями относительно тех аспектов, которые необходимо учесть при подготовке отчета, для того чтобы понятно, структурировано и в полном объеме изложить полученные в ходе проекта результаты.
Заключение
В заключении еще раз обратим внимание на следующие основные моменты, которые мы рекомендуем учитывать при подготовке отчета:
1. Именно отчет является итоговым результатом работ, который видит и оценивает заказчик. Кроме того, отчет читают разные люди (как технари, так и представители бизнеса).
2. На структуру и специфику отчета влияют такие факторы, как внутренние правила компании, тип работ, пожелания заказчика, формат, в котором будет передаваться отчет.
3. Для описания уязвимостей и недостатков нужно продумать:
принципы описания сути проблемы;
«систему координат», которая позволит однозначно локализовать выявленную проблему;
систему экспертной оценки выявленных уязвимостей и недостатков;
правила описания процесса эксплуатации и оформления иллюстраций;
правила составления рекомендаций по устранению выявленных уязвимостей и недостатков.
4. Чем точнее и понятнее результаты работ изложены в отчете, тем меньше вероятность, что у заказчика возникнут дополнительные вопросы при его изучении.
Авторы:
Анна Коваленко, аналитик отдела анализа защищенности
Ирина Лескина, руководитель направления аналитики отдела анализа защищенности