Александр Герасимов
Пентест, то есть проверка инфраструктуры компании на возможность хакерского проникновения, — это распространенная услуга, которую предоставляют ИБ?компании. Однако пентесты бывают очень разными. В этой статье я расскажу, как, на мой взгляд, должны и как не должны выглядеть результаты таких работ. Думаю, мои советы пригодятся и заказчикам, и исполнителям.
На мысль написать такой текст меня навел комментарий заказчика, оставленный после завершения проекта. Он демонстрирует, какие, казалось бы, обычные вещи могут впечатлить и порадовать.
У нас была уязвимая библиотека с высоким CVSS, и при этом она легко эксплуатировалась. PoC не было, но составить его не проблема — коллеги из Китая оставили очень хорошие описания к CVE, за недельку можно заиметь боевой образец. Но мы знали, что благодаря нашим усилиям эта уязвимость была неприменима.
Мы ждали отчет с кричащими тегами CRITICAL. Но увидели эту библиотеку с маркером LOW. Исполнители прекрасно понимали, как мы защитились, сами же описали причину, по которой эта уязвимость не может быть проэксплуатирована, и корректно отметили, что библиотека уязвима и ее нужно обновить, когда появится патч.
После такого понимаешь:
- Твое временное решение проблемы компетентно, раз сторонняя команда пришла к тому же выводу.
- Исполнитель не просто использовал какие?то анализаторы, но осмыслил происходящее, проанализировал потоки данных, сопоставил логику уязвимости и бизнес?процессы. Получив такое, веришь, что он был настолько же дотошен и в других параметрах оценки.
ПРОГРАММА МИНИМУМ
Итак, что же нужно делать, чтобы заказчики были счастливы и писали приятные отзывы?
- Самый важный аспект — вникать в логику работы. Не просто сканировать инфраструктуру, валидировать баги руками, что?то тыкать и фаззить, но еще и понять, как работает сервис, посмотреть потоки данных и взаимодействие с остальными микросервисами и интеграциями.
- Покрывать все сервисы автоматизированными средствами.
- Валидировать все уязвимости. Не просто отдавать репорты сканера, обернутые в логотипы твоей компании, а обязательно проверять, что каждая найденная уязвимость реальна.
- Корректировать уровень опасности уязвимостей согласно критичности сервиса и возможности эксплуатации. Даже если сканеры пишут, что уязвимость критична, нужно учитывать обстоятельства: можно ли ее проэксплуатировать, есть ли реальные уязвимости с PoC, критичный ли сервис и так далее.
- Весь чек?лист пройден в ручном режиме. 90% работы над проектом должно занимать ручное тестирование, ресерч, попытки эксплуатации именно в ручном режиме.
КАК ПИСАТЬ ОТЧЕТ
Отчет — это результат проекта, ради него все и делается, поэтому переоценить его значение вряд ли возможно. В хорошем отчете должны быть:
- Единый стиль изложения, отсутствие грамматических и стилистических ляпов, описание рисунков, схем, таблиц. Чтобы всем было приятно смотреть на отчет и содержание было предельно ясным.
- Детальное описание недостатков. Не просто общее описание, а для конкретных случаев: где нашли уязвимость, в каком параметре или модуле.
3. Примеры эксплуатации. Показаны найденные баги, прикреплена картинка как пруф. Читающий может повторить действие с картинки. Также не помешает детальное описание процесса тестирования, ссылки на базы уязвимостей ФСТЭК России или техник MITRE.
4. Рекомендации также прописаны для конкретных случаев, описаны точечные советы, именно для того фреймворка и стека технологий, который использует заказчик. Нет двусмысленности. Есть разные варианты устранения.
Например, ты нашел уязвимость, которая позволяет перебирать пользователей. Система реагировала по?разному в тех случаях, когда пользователь существует и когда его нет. Можно дать общую рекомендацию — внедрить CAPTCHA-тест. Но если знаешь, что у заказчика используется, например, Django, то можно дать рекомендации именно для этого фреймворка.
5. Резюме работы с цифрами, рекомендациями и выводом.
6. Отчет оформлен на основе вопросов, заданных заказчиком перед проектом. Затем идет то, что специалисты считают важным и релевантным. Если вопросов не было, то по иерархии критичности всех находок.
7. Приведена аналитика: количество уязвимостей, хостов, которые были проверены, или топ уязвимостей в компании, или динамика по предыдущим пентестам и времени жизни уязвимостей, если есть такая возможность.
8. Моделирование угроз поведения злоумышленника. Нужно показать, что случится, если злоумышленник проэксплуатирует уязвимость. Например, уязвимость с SMS-спамом, как правило, заказчики не понимают. Поэтому нужно показать, в чем ее риск, объяснить, что провайдер позволяет крупным компаниям отправлять до 3 тысяч SMS в секунду. На отправку 200 запросов компания тратит 400 рублей в секунду. Если атака длится час, то злоумышленник сожжет почти 1,5 миллиона рублей с баланса компании.
ЧТО ВАЖНО ОБСУДИТЬ
Пентест — это такая услуга, где результат сильно зависит не только от исполнителя, но и от заказчика, поэтому важно договориться на берегу. Вот список вопросов, которые, на мой взгляд, обязательно стоит обсудить.
- Инструментарий исполнителя не будет ограничен.
- Заказчик не будет препятствовать проведению пентеста, если не оговорены какие?то исключения (не отключать сервисы, не патчить «на лету» и так далее).
- Нужно определить четкие цели работ: получение прав администратора на такой?то системе и так далее.
- Обязательно определить скоуп работ.
- Определить модель нарушителя.
- Заказчик должен отличать пентест от анализа защищенности, сканирования.
- Стоит составить план работ с промежуточными этапами. Например, каждую неделю узнавать результаты и планы на следующую неделю.
Заказчикам могу порекомендовать выбирать исполнителей, для которых пентест — профильная услуга (если непрофильная, компания скорее отдаст выполнение на аутсорс). Не помешает и провести с исполнителем интервью, выяснить опыт команды, расспросить о том, как устроен процесс тестирования. Бывает полезно ротировать исполнителей или хотя бы просить менять состав команды, чтобы был свежий взгляд на одну и ту же инфраструктуру.
КАК НЕ ОПОЗОРИТЬСЯ
Есть целый класс так называемых «уязвимостей» вроде поддержки ранних версий протоколов SSL и TLS, не выставленного на сессионную куки флага безопасности и прочих сообщений, которые автоматически генерируют сканирующие движки.
Если в отчете перечислены такие уязвимости, то к ним нужны описания, которые будут пояснять, почему та или иная строчка включена в отчет. Не помешает и описание того, как уязвимость влияет на систему, какие нужны условия для ее эксплуатации и какая предполагается модель нарушителя.
Без таких пояснений отчет можно считать формальной отпиской. Исполнитель не потрудился примерить найденное к жизни и дать более глубокую оценку. Вываливать в отчете автоматически сгенерированный текст не нужно.
Вряд ли порадуют заказчика и короткие формальные описания уязвимостей без пруфов и примеров эксплуатации. Даже специалист по ним вряд ли поймет суть бага и не сможет применить результат тестирования в своей работе.
Если заказчик не получает ответы на главные вопросы о том, что угрожает компании, смысл проекта тоже теряется, поэтому отчет без описанных рисков — не отчет.
Плохо, когда нет конкретных рекомендаций. Например, понятно, что надо ограничить количество запросов, но непонятно, как это сделать. Даже если заказчик не воспользуется рекомендациями, нужно показать пример, как это можно сделать в его случае.
В примере справа добавлены риски, пример эксплуатации, ответ веб?сервера и техническое описание того, к чему приведет эксплуатация уязвимости. Даны рекомендации, которые объясняют, как ограничить количество запросов. То есть для заказчика составлено готовое решение, в котором учтен его технологический стек.
EXECUTIVE SUMMARY КАК ИНСТРУМЕНТ
У нас был такой кейс. Мы продвигались по сети и попали в интересную подсеть, к которой была подключена машина с очень злой уязвимостью и сессией достаточно значимого человека в домене. Эксплуатацию мы проводили по согласованию, поэтому позвонили девопсу (не хотелось ронять ему сервис своим эксплоитом и прерывать процессы), описали ситуацию и свои мысли, мотивы. На что получили ответ: «Да, обязательно это делайте, я даю добро! И независимо от результата, пожалуйста, опишите это в отчете — я уже год прошу выделить ресурсы на то, чтобы эту подсеть перестроить, но меня никто не слушает. Если получится, значит, меня наконец?то услышат».
В течение следующих пятнадцати минут мы получили права администратора домена. Из этой истории и опыта работы с большими компаниями с глубокой субординацией мы сделали вывод: даже оказывая сложную техническую услугу, общаться следует на языке денег.
Владельцы бизнеса мыслят прибылью, в этом плане информационная безопасность — просто траты. Но избежать этих трат все равно не выйдет. Запросы к начальству со стороны ИБ нередко сфокусированы на локальной задаче, выражены сложным техническим языком и требуют дополнительной «расшифровки», а значит, и дополнительной аргументации.
Не нужно говорить «тут уязвимость, это опасно», нужно говорить «если мы сейчас не вложим сюда небольшие деньги, то когда нас пробьют — мы потеряем большие деньги, решайте сами».
Да, это требует подготовки и анализа активов, но благодаря такому подходу проблемы недостатка бюджета или ресурсов решаются гораздо быстрее. Окончание пентеста — это всего лишь начало большой работы для наших коллег. Они будут заниматься устранением найденных уязвимостей, построением новых ИБ?процессов и прочими изменениями, направленными на защиту систем.
Так что большим плюсом для пентеста станет такое саммари, чтобы совет директоров легко его понял и захотел пойти навстречу отделу безопасности. Еще лучше, если твоя компания в состоянии провести защиту проекта бизнес?заказчику и заставить биг?боссов быстро понять, насколько все уязвимо и что нужно делать, чтобы изменить это.
ЧТО НУЖНО ДЛЯ ХОРОШЕГО EXECUTIVE SUMMARY?
- Конкретика и цифры. Поскольку этот раздел читают менеджеры, зачастую незнакомые с техническими терминами, важно доходчиво донести бизнес?риски, к которым ведут уязвимости.
- Объяснить, каким был перечень работ: например, сделали пентест, фишинг и так далее. Рассказать, зачем это было нужно и к каким выводам привело. Схемы, картинки, например ход пентеста верхнеуровнево, «для самых маленьких».
- Небольшая аналитика, например количество критичных уязвимостей, время, которое потребуется злоумышленнику для компрометации инфраструктуры, уровень злоумышленника, необходимый для реализации всех атак, сколько человек в компании попалось на фишинг.
- Декомпозиция рисков: какой ущерб может нанести реализация атаки, к чему может привести успешный фишинг и так далее.
- И конечно, отработка возражений. Рекомендации, понятные всем. Например: внедрение таких?то средств защиты позволит избежать реализации атаки № 1, непрерывный анализ защищенности позволит не допустить событий № 2 и № 3.
ВЫВОДЫ
Если ты работаешь в ИБ?компании, надеюсь, мои советы помогут тебе усовершенствовать ваш процесс и начать радовать клиентов еще больше. Если же ты трудишься на стороне потенциального заказчика, то, думаю, уже понял, на что нужно ориентироваться при заказе услуги. Помни: чем глубже пентестер погрузится в особенности инфраструктуры и чем лучше будет их учитывать, тем больше будет отдача.
Читайте ещё больше платных статей бесплатно: https://t.me/xakep_1