СОИБ. Анализ. Пентест н-надо?

В последние 3 месяца мы наблюдаем растянутую во времени публичную дискуссию про пентесты. Вот эта история:

1. Очередной виток начал известный блогер, рассказав как одна компания-пентестер обманула ввела в заблуждение заказчика, а именно: был проведен пентест, который показал, что система защищена, а через неделю после окончания работ в системе была обнаружена критическая уязвимость, посредством которой она была вероятно взломана.

В результате были подняты вопросы:

·        А нужен ли пентест вообще на таких условиях? Он не гарантирует что отсутствуют уязвимости, он не гарантирует что система защищена.

·        Может ли компания пентестер предложить что-то полезное заказчику?

2. Продолжил тему один пентестер на вебинаре RISC “ Тестирование на проникновение: задача, решение и ограничения”, который дал определение пентеста, указал ограничения,  условия и разъяснил многие моменты из своего опыта пентеста.

С моей точки зрения там было дано достаточно полное, правильное  часовое описание Пентеста.

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

Ещё вебинаре и в блогах после него было озвучена пара спорных моментов, которые я прокомментирую позднее:

·        Если клиент не знает ничего о своей ИТ-инфраструктуре, то лучший способ разобраться, это провести пентест

·        Риск утечки информации от пентестеров не превышает риск утечки от Интеграторов. .... у Интегратора априори больше информации о системах Заказчика.

3. Далее тему развивает директор одной компании-пентестера в статье "сломать всё", который отвечает на вопросы:

·        За что может и должен отвечать пентестер, а за что не может и не должен?

·        Можно ли доверять пентестеру?

·        Что может подтвердить квалификацию пентестера?

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

Дальнейший комментарий автора статьи в facebook только показал что он отлично все понимает, но специально так написал в статье. Можно сделать вывод, что компания-пентестер пытается перейти из узкой ниши услуг пентестов в поле услуг аудитов и исследований.

Заметил ещё одну общую проблему из части 2 и 3: пентестеры ошибочно считают, что в результате пентеста помогут разработать заказчику план дальнейших действий в области ИБ, могут заменить работу интеграторов, могут заменить «системный полный аудит защищенности информации».

Мои выводы по результатам дискуссии:

1.      Если кратко, то пентест – это тест/набор тестов. Тест проверяющий является ли система “слабозащищенной”. Основной результат – это ответ Да или Нет. В крайнем случае возможно градация по шкале от 0 до 10. Не стоит ожидать от пентеста большего. (Более длинное и четкое определение смотрите в вебинаре RISC)

2.      Мы так и не получили ответа на вопрос – а нужны ли такие пентесты и когда нужны?

Мое мнение, что пентесты нужны в двух случаях:

·        Показать руководству (а не безопаснику) что сейчас “все плохо” и нужно принимать какие-то дополнительные меры (но не показать какие именно меры)

·        После внедрения комплекса организационных и технических мер, проверить, что теперь не “все плохо” и заодно провести независимую практическую проверку работы интегратора по ИБ

3.      На рынке ИБ есть высококлассные “специалисты по поиску уязвимостей”= “специалисты в слабостях настройки сервисов/систем” = “хакеры в белых шляпах” = “практические безопасники” = “пентестеры”. Им хотелось бы как-то монетизировать свои знания и умения.  

Для того чтобы лучше монетизироваться они предлагают проводить пентесты чаще, силами только пентестеров проводить обследования ИТ-инфраструктуры, давать консультации по созданию системы защиты, проводить аудиты ИБ.

А вот это считаю совсем не корректным:

При проведении обследования ИТ-инфраструктуры достаточно базовых знаний в обследуемой области и работа обычно заключается в опросе специалистов, сборе документов, рисовании схем сети (L2, L3, маршрутизации), рисовании схем ИС, рисовании схем информационных потоков,  фотографировании стоек , сборе текущей конфигурации. Не вижу где тут применить особые знания по “практическому хакингу”.

И давайте сравним консультации которые может дать технический специалист “пентестер” в сравнении с техническим специалистом “архитектором ИБ”.

Пусть найдена уязвимость X. Что может пентестер при консультациях – это сказать что уязвимость X нужно устранить и через три месяца провести повторный пентест. Он даже не всегда может сказать как устранить данную уязвимость – уметь искать уязвимости это не тоже что уметь безопасно программировать и не то же самое что организовать процесс безопасной разработки. А то что в системе кроме найденной уязвимости может быть ещё сотня уязвимостей и закладок, это пентестера совершенно не беспокоит – найдет в следующем пентесте.

Архитектор ИБ + консультант ИБ в аналогичных условиях сначала оценивают риски связанных с ИБ в данной системе (может быть и не стоит её защищать), потом создают процессы управления уязвимостями, процессы мониторинга ИБ, процессы реагирования на инциденты, разрабатывают требования к разработчику ИС, при необходимости внедряют SS, FW, IPS, WAF, DBF, SIEM. В результате заказчик получает эффективную систему защиты, которая будет и обнаруживать уязвимости (пусть не такие сложные как пентестер, но зато с полным охватом), быстро принимать решения по их обработке, опасные атаки будут обнаруживаться быстро, 0-day уязвимости будут наносить небольшой ущерб, пропущенная в одном месте уязвимость или неправильная настройка будет компенсироваться другой мерой защиты.

По сравнению с этим заказчик, выбравший для консультаций пентестера садится на “пентестерскую иглу”. Он должен регулярно заказывать пентест и надеятся что пентестер найдет все уязвимости, ничего не пропустит, не ошибется, не скроет, он будет обязан сразу устранять все уязвимости (не смотря на то что придется останавливать производство, заключать с разработчиком ИС невыгодные контракты на доработку). А пропущенная пентестером уязвимость (смотрите ограничения пентеста из дискуссии) может обернуться для заказчика существенно большим ущербом (ведь он не внедрит компенсирующих мер).  

PS: Да, высококлассные “специалисты по практическому хакингу” нужны, но давайте их использовать правильно. Интеграторам, проводящим аудиты нужно брать таких специалистов с свой штат или привлекать на субподряд. При создании систем защиты консультации таких специалистов тоже нужны, но в определенных частях – в правильной настройке существующих ОС, сервисов, сетевого оборудования, поэтому тоже пригодятся в штате или на субподряде.