Содержание статьи
Тестирование на проникновение (penetration testing) — метод оценки безопасности компьютерных систем или сетей средствами моделирования атаки злоумышленника. Для кого-то это хобби, для кого-то работа, для кого-то это стиль жизни. На страницах нашего журнала мы постараемся познакомить тебя с профессией настоящего «этичного хакера», с задачами, которые перед ним ставятся, и их решениями.
Intro
Ты наверняка знаешь, что работа пентестера как минимум на 30% состоит из документирования активностей, которые имели место в рамках тестирования на проникновение. Мнения о качестве этого документирования у исполнителя и заказчика часто не совпадают, и каждый начинает крепко задумываться о компетенции другого. Чтобы такой ситуации не возникло, перед началом работ необходимо основательно обсудить с заказчиком те результаты, которые он рассчитывает получить.
Консалтинг Inc.
Некоторое время назад в колонке я поднимал тему о том, что популяризация бизнеса в сфере ИБ может стать причиной спада качества оказания консалтинговых услуг: нет общепринятых локальных стандартов, которые можно было бы применить к упомянутым работам.
Я пришел к выводу, что проще всего это можно предотвратить, предъявив адекватные требования к единственному осязаемому результату работ — отчету. Напомню, отчет по результатам тестирования на проникновение обычно состоит из двух частей: аналитической и технической. Аналитическая часть представляет собой осмысление технических результатов тестирования в рамках конкретной организации. Чтобы ты понимал, хороший аналитический отчет можно подготовить даже на основе результатов одних только автоматизированных проверок. В этом случае качество будет напрямую зависеть от человека, который готовил отчет, и его способности адекватно расставлять приоритеты и интерпретировать результат скана Nessus.
В глазах технического специалиста такой отчет выглядит достаточно высокоуровневым. Заказчик в лице руководителя отдела ИБ организации прекрасно понимает, на какие вопросы должен отвечать аналитический отчет. Это помогает в тех случаях, когда качество аналитической части никуда не годится. К сожалению, этого нельзя сказать о технической части — нередко в отделе ИБ мало кто разбирается в вопросе, что не позволяет установить адекватные требования к этой части документа. А ведь она является задокументированным результатом оказания консалтинговой услуги.
Вот здесь и кроется проблема. Результат оказания консалтинговых услуг не должен выглядеть только как ответы на вопросы «могут ли меня взломать?» и «как меня могут взломать?».
Технический отчет, который отвечает на вопросы «как и что исправлять?», — это аналог хак стори вроде тех, что публиковали в Х лет пять назад. Сегодня я расскажу об основных требованиях, которые исполнитель должен предъявлять к техническому отчету.
В какой-то момент своей практики проведения тестов на проникновение я заметил за собой одну не очень хорошую черту: в разговорах с заказчиками и их техническими специалистами я употреблял жаргонизмы, характерные для сферы ИБ. Они понятны мне, понятны представителю ИБ, но не совсем понятны представителям ИТ. Подобные вещи можно было найти и в технических отчетах — на то они и технические. Стандартная ситуация: тест проведен, документация передана заказчику, год спустя ты эксплуатируешь абсолютно те же самые уязвимости в рамках очередных работ. Уязвимости никто не устраняет, совсем. Почему?
Уязвимости исправляют инженеры по ИБ. Когда такого инженера нет, эту задачу перекладывают на представителей ИТ-отдела. Они отлично справляются с рядовыми задачами, будь то патч-менеджмент или нужные правила на файрволе, но впадают в ступор при попытке исправить ошибку переполнения буфера в компоненте ActiveX.
Сейчас я понимаю, что проблема заключалась в отсутствии на стороне заказчика компетенций, которые бы позволили превратить технические детали взлома в информацию, которой может оперировать рядовой специалист отдела ИТ. В итоге все сводится к проблеме коммуникации внутри организации, но это совсем другая история.
Так я пришел к выводу, что технический отчет должен представлять собой документ, который мог бы помочь незнакомому с ИБ техническому специалисту убедиться в наличии проблемы и устранить ее. Я проанализировал совокупность потребностей отделов ИБ и ИТ отдельно взятой организации и составил список требований, которые можно предъявить к содержанию технического отчета по результатам пентеста.
Table of contents
Технический отчет должен быть не только понятным, но и полным. Чтобы оценить, насколько полон твой отчет, представь, что его изучает другой пентестер. Какие вопросы у него возникнут? По поводу состава выполненных тобой проверок или же вектора атаки? Естественно, подобная оценка напрямую зависит от твоей компетентности, но мы, как и технологии, не стоим на месте и развиваемся в нужном направлении. Напомню, технический отчет в большинстве случаев логически должен быть структурирован в соответствии с составом работ. Наличие художественной составляющей описания взлома роли не играет.
Introduction
В первую очередь технический отчет должен содержать определения всех используемых терминов и аббревиатур. Вне зависимости от состава работ, документ должен полно обозначить скоуп работ — список проверяемых ресурсов. Должна быть описана и методология тестирования (состав работ) — как минимум список выполняемых (и выполненных) проверок.
Если речь идет о внешнем тестировании на проникновение, то следует включить информацию о том, какие именно сервисы доступны на внешнем периметре и какие проверки были проведены в отношении каждого из них. Естественно, не стоит упоминать обо всех автоматизированных проверках. К примеру, для FTP-сервиса, доступного на внешнем периметре, достаточно будет упомянуть, что в отношении его был проведен брутфорс по списку логинов и паролей (необходимо предоставить ссылки на эти списки), а также что установленная эвристическим путем версия сервиса не содержит уязвимостей, информация о которых доступна публично. Со стороны заказчика адекватно просить подобную информацию о внешнем периметре.
Шаблон описания уязвимости
Описание каждой уязвимости, исправление которой не подходит под шаблон «установите патч от вендора», должно содержать в себе следующую информацию:
- информация о типе уязвимости и его краткая характеристика;
- информация о причине уязвимости;
- указание сервисов, которые подвержены уязвимости;
- proof of concept, который позволит подтвердить наличие уязвимости;
- рекомендации по устранению уязвимости.
Proof of concept должен представлять собой код или мануал в стиле «руководство к действию», которое было бы понятно представителю ИТ. Рекомендации должны полностью описывать этапы устранения уязвимости. Если уязвимость до текущего момента не была известна вендору, пентестер берет на себя обязанности общения с вендором уязвимого продукта (разумеется, в зависимости от условий договора), включив в переписку представителей тестируемой организации. В отчет в таком случае включается описание возможности временного фикса проблемы, а также указание на конкретных людей, которые принимают участие в процессе общения с вендором, и прямая ссылка на переписку с ним.
Если уязвимость более типовая (к примеру, она возникла из-за некорректного процесса патч-менеджмента), рекомендации следует дополнять информацией о том, как этот самый процесс реализуется технически в условиях текущей инфраструктуры.
Hack story
В процессе документирования процесса взлома стоит уделять внимание не только вектору атаки и описанию уязвимостей, но и информации о своей активности во время проведения работ. Запуская sqlmap, задокументируй в отчете время, в которое проводилась проверка. Это позволит техническим специалистам заказчика увидеть атаку в логах, если таковые ведутся, и настроить триггеры, которые смогут сигнализировать о возможной атаке в дальнейшем.
Описывая процесс взлома, не стоит обходить стороной причины тех или иных твоих действий и предположений. К примеру, ты использовал сервер внутри корпоративной сети в качестве плацдарма для развития атаки. Ты считаешь, что это будет менее похоже на взлом извне по следующему списку причин, а в случае, если плацдарм будет отключен, никто не выявит точку твоего входа в корпоративную сеть по причине отсутствия механизмов логирования. Ты же будешь знать, что о твоем присутствии догадываются.
Важное дополнение описания взлома — это информация обо всех изменениях, которые пентестер вносил в ИС заказчика, будь то веб-шелл на веб-сайте или же созданная для развития вектора атаки учетная запись локального администратора. Естественно, по результатам работ пентестер должен все за собой почистить (кроме логов).
Outro
Технический отчет, который отвечает всем перечисленным требованиям, будет представлять собой документ, ясно описывающий проблемы и пути их решения. Их можно будет реализовать не только силами отдела ИБ, но и подключив ресурсы отдела ИТ. Пентестер, в свою очередь, помимо благодарности заказчика и гонорара, получит моральное удовлетворение от понимания того, что подготовленный им технический отчет написан не «в стол», а действительно станет руководством, которое поможет сделать инфраструктуру безопаснее.
Увидимся на ZeroNights! Stay tuned!
WWW
Полезная информация
Общая теория по пентестам
- Vulnerability Assessment
- Open Source Security Testing Methodology Manual
- The Penetration Testing Execution Standard
