• О проекте
  • Услуги
  • Заказать услугу
  • Новости
  • Блог
  • Глоссарий
  • Акции
  • Контакты
  • Блог

    Отчет аудита информационной безопасности. Часть II. Структура отчета аудита

    Оглавление

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

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

    Разберем состав основных 4 частей отчета аудита безопасности

    Введение

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

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

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

    Следующей частью отчета является аналитическая записка

    Аналитическая записка – это как раз та часть отчета, которую будут читать руководители компании.  Она не должна быть больше 2-3 страниц, в ней нестоит использовать жаргон, и после ее прочтения у руководства заказчика должно возникнуть четкое представление о состоянии безопасности информации в компании.

    Возможно, вам предложат оценить уровень состояния безопасности в компании по их собственной шкале рисков, в противном случае, можете воспользоваться распространенными DREAD или CVSSv2. Данной шкале мы посвятим отдельную развернутую статью. Аналитическая часть – это не только страницы сплошного текста. Все выводы должны быть выделены, большое количество графиков и сводных таблиц приветствуется, необходимо привести статистические данные. Текст лишь их поясняет и дополняет.

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

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

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

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

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

    • краткое описание уязвимости;
    • значение показателя CVSSv2 с обязательным указанием его  вектора;
    • обязательно привести ссылки на дополнительную информацию  из баз уязвимостей WASC, MITRECVE и OSVBD;
    • если проводиться тест на проникновение – информация о примененных эксплойтах, скриншоты и схемы выполненных атак.

    Имя уязвимости должно быть взято из WASC Threat Classification, MITRE CWE или OWASP TOP 10. Описание уязвимости должно быть взято из этих же источников, или NIST или OSVDB. Такие источники данных об уязвимостях, как MITRE CVE, OSVDB, NIST, WASC – заслуживают отдельного разговора о них, поэтому мы обязательно восполним этот пробел в ближайшее время.

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

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

    Важно указать сложность эксплуатации, наиболее важные характеристики уязвимости, которые они обычно включены в вектор CVSSv2.

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

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