Совсем немного времени прошло с момента публикации о доверии пентестеру. В двух словах, тогда я пытался показать, что провести оценку качества работы пентестера крайне сложно, а, следовательно, весьма затруднительно судить об эффективности (как “effectiveness”, так и “efficiency”) такой работы, что, в конечном итоге, сводит к нулю возможность проведения всяких cost/benefit анализов. Сейчас я попытаюсь порассуждать вообще на тему необходимости проведения аудита в режиме теста на проникновение в сравнении с т.н. Анализом защищенности.
Сначала разберемся с терминологией. Здесь под «тестом на проникновение» я понимаю аудит, в рамках которого производится попытка имитации действий вероятного злоумышленника с целью получения неавторизованного доступа. Принципиально здесь то, что а) сведения о конфигурации системы у аудитора ограничены (в реальной жизни зачастую – это blackbox-тестирование), б) аудитор пытается эксплуатировать выявленную уязвимость, довести ее до проникновения.
Под «анализом защищенности» я буду понимать полностью открытый аудит (whitebox-тестирование), в рамках которого производится проверка конфигурации системы и сопоставление ее с соответствующими рекомендациями производителей и независимых экспертов. Принципиально здесь то, что а) аудитор располагает полнейшими сведениями о конфигурации системы, б) аудитор удовлетворяется тем, что выявил уязвимость, которая, по сути, является не чем иным, как расхождением с какой-либо «лучшей практикой», не пытается ее эксплуатировать.
Заказывая аудит, я не склонен играть в «кошки-мышки». Я заинтересован, чтобы аудитор отработал максимально эффективно, для чего логично предоставить ему максимально возможное количество информации о проверяемой системе. Аудитор работает на меня, мне выгоден сценарий whitebox-тестирования. Да и в реальной жизни надежнее полагать, что злоумышленнику известно больше, чем мы ожидаем.
Теперь немного об уязвимостях. Крайне крупно их можно подразделить на:
- Уязвимости непосредственно самого ПО. Они полностью на совести разработчика и могут быть исправлены, главным образом, только им самим (выпущено исправление).
- Уязвимости конфигурации. Они возникают ввиду неправильной настройки системы. В конечном итоге их можно свести к нарушению каких-либо рекомендаций кого-либо («лучших практик»).
Классическая ситуация на коммерческом предприятии, в задачи которого не входит финансирование исследований в области информационной безопасности, состоит в том, что:
- Процесс установки обновлений используемых программных продуктов отстроен: обновления ставятся своевременно, в соответствии с рекомендациями производителей ПО.
- Новые системы представляют собой, как правило, «коробочные» решения, разработанные известными производителями ПО, внедренные внешними подрядчиками или своими силами.
В целом, я работаю на коммерческом предприятии, и ситуация у меня ровно такая же. Производитель коробочного решения мне гарантирует, что он сделает все возможное для того, чтобы его ПО было безопасным. Для этого у него есть отработанная процедура выпуска обновлений безопасности. Причем, обычно, эксплоит «в природе» появляется позже, чем производитель моего ПО публикует advisory и выпускает заплатку. Мои доблестные ИТшники имеют настолько хорошо отлаженный процесс установки обновлений, что на момент выхода эксплоита, нужный патч уже стоит. Ну, а если эксплоит появился раньше, чем производитель моего ПО смог обнаружить у себя уязвимость (zero-day), то и здесь мировое сообщество, производители решений безопасности (например, IPS и AV, оборона должна быть эшелонированной!), да и сам производитель ПО, меня не оставят – предложат обходные/временные варианты, которые смогут значительно снизить вероятность эксплуатирования zero-day-я, пока разработчик ПО не исправит проблему. В общем, вероятность быть компрометированным из-за уязвимости «коробочного» ПО крайне мала, при условии, что я выполняю все рекомендации его производителя (а это надо делать!). Более того, на процесс повышения безопасности коробочного ПО крайне сложно влиять: я не защищусь от уязвимости никак, пока производитель не выпустит advisory. Так стоит ли мне искать такие уязвимости? Очевидно, нет. Как выйдет патч, он будет установлен, независимо от того, чьими ресурсами было произведено исследование узявимости. Итого, уязвимости непосредственно самого ПО мне искать нет необходимости.
Другое дело – уязвимости конфигурации. Есть масса причин почему вероятность их возникновения достаточно высока – от недостаточной квалификации подрядчика или «своих сил», до действительно высокой сложности выполняемых настроек. Но, в отличие от «дыр в ПО» на такие уязвимости можно самостоятельно влиять. Анализ защищенности мне здесь поможет. Кропотливо, внимательнейшим образом, провести полный анализ настроек на предмет наличия уязвимостей конфигурации. Выявленные проблемы соответствующим образом исправить. Очевидно, это сразу приведет к повышению безопасности моей системы.
Теперь поговорим об эффективности видов аудита.
Тест на проникновение способен выявить оба типа уязвимостей. Но его effectiveness достаточно низкая, поскольку:
- Гарантировано не все уязвимости будут им выявлены, поскольку классический сценарий ближе к blackbox, тогда как whitebox для поиска уязвимостей конфигураци, очевидно, продуктивнее.
- Уязвимости самого ПО вообще нет смысла искать, так как их обнаружение не ведет к повышению безопасности ПО, пока производитель не выпустит advisory.
Не велика и его efficiency, поскольку, мне не надо показывать «фокус» – не надо демонстрировать, что уязвимость может быть эксплуатирована, я верю написанному в advisory и так. Был показательный случай. У меня работали аудиторы, делали пентест. Отсканировали nmap-ом с флажком –v (показывать версии), узнали, что стоит уязвимый sendmail, в котором можно через переполнение буфера и получить shell пользователя root. В целом, мне этой информации достаточно: sendmail надо либо остановить (в том случае надо было делать именно так, так как он не использовался), либо обновить на неуязвимую версию. Но мы играем в пентест, а значит, мы должны довести уязвимость до эксплуатирования. Аудиторы обшарили весь интернет, но так и не нашил эксплоит для моей операционной системы (HP-UX), есть под SUN Solaris, под RedHat Linux, а под HP-UX на PA-процессоре – нет. Что ж, как я говорил, я заинтересован помогать аудиторам, - я нашел им такое же железо с такой же ОС и тем же Sendmail-ом. У них в команде был программист, который убил несколько дней на упражнения с gdb, но так и не написал эксплоит… И это эффективная трата ресурсов?
Анализ защищенности не способен выявлять уязвимости самого ПО. Да это и не надо! Зато уязвимости конфигурации по сценарию whitebox им будут выявлены очень даже хорошо. Вера в effectiveness такого аудита у меня значительно выше: скорее всего большая часть «косяков» будет успешно найдена и исправлена. С efficiency тоже все понятно – как минимум, не надо тратить время на эксплуатирование уязвимости, особенно, на написание эксплоитов.
Итого:
- Если в проекте вы не разрабатываете ПО, а используете «коробочные» решения и настраиваете их – вам не нужен пентест, тщательный Анализ защищенности – ваш выбор.
- Если вы разрабатываете ПО и есть возможность провести анализ кода – тщательный Анализ защищенности и code review – ваш выбор.
- Если вы разрабатываете ПО и исходников нет, - тут только пентест, может, что-то выявится. Но настройки, как и прежде, лучше посмотрит Анализ защищенности.
Эффективность Анализа защищенности косвенно подтверждается рынком, - как правило, он значительно дороже, чем пентест.
PS: Перечитал написанное. Может сложиться неправильное впечатление, что пентесты не нужны как класс. Совсем нет! Просто, все хорошо к месту. Возможна ситуация, когда действительно есть задача поиграть с «черные шляпы» и «белые шляпы». Ну, например, ИТ и ИТ-безопасность у меня аутсорсятся и есть задача проверить, насколько хорошо я защищен. Логично в этой ситуации именно провести пентест на мою информационную систему, и тем самым проверить насколько мои аутсорсеры хорошо выполняют наше с ними SLA. Почему логично пентест? Потому что он а) дешевле, как следствие, быстрее, б) нагляднее, как для проверяемых ИТшников и Безопасников, так и для меня-заказчика: приближен к реальным условиям, сразу показывает неоспоримый результат, в) можно действительно остановиться после первого же успешного взлома – задача показать возможность взлома при данном уровне работы аутсорсера, найти все остальные варианты реализации взлома – уже факультативно. Подумав, можно найти и другие случаи, когда пентест – лучший выбор, но всегда перед заказом аудита обязательно внимательно проанализируйте цели этой работы, решите, что вам нужно. Не надо тут полагаться на мнение подрядчика-аудитора, - он вам продаст все, что умеет, для него - это бизнес, но никто и ничто не заменит вам вашу логику.
