Сертифицированный этичный хакер
Многие, наверное, слышали о такой сертификации для специалистов, специализирующихся на тестировании на проникновение, как Certified Ethical Hacker (сертификационный экзамен можно сдать в любом авторизованном центре Prometric).
Недавно мне удалось познакомиться с материалами для подготовки к экзамену. Порадовало то, что основатели сертификации подошли к вопросу системно – в ходе подготовки к сдаче экзамена слушателям предлагается пройти 67 модулей, которые покрывают такие темы, как предварительный сбор информации, сканирование уязвимостей, вирусы, трояны, руткиты, социальная инженерия, разработка эксплойтов, DoS-атаки, SQL-инъекция и т.д.
Единственное, что мне не удалось найти в материалах для подготовки, так это тем, посвященных административной части тестирования — управлению рисками проекта, результатах проекта (deliverables) и т.п.
В нашем двухдневном семинаре мы хотим эту административную тему тоже закрыть, так как она является очень важной для качественного проведения работ по тестированию на проникновение.
Вот такой шаблон отчета по тестированию на проникновение войдет в нашу раздатку. Если у читателей этого блога есть свой взгляд на оптимальный отчет по тесту на проникновение, очень прошу высказать свое мнение в комментариях.
Жаль, что сертификация Certified Ethical Hacker пока не стала популярной (я не смог найти в социальной сети ”Мой круг” ни одного специалиста по информационной безопасности, обладающего данным статусом). На мой взгляд, каждый специалист по ИБ должен иметь хорошее представление о технологиях хакеров и уметь проводить реальное тестирование защищенности вверенных ему корпоративных систем.
рекомендую делать два шаблона: отчет пентеста по PCI DSS и отчет пентеста по требованию
в текущем отчете (по требованию) нет
Для высшего руководства (CEO/CFO):
— оценки влияния совокупного использования всех уязвимостей на бизнес-процессы
Для CIO/CISO:
— оценки по векторам проникновения и/или по процессам обеспечения ИБ (если работы проводятся не в первый раз, должна быть отражена динамика)
— отсутствует полученный уровень доступа к системам (должно быть выделено в самом начале, помимо упоминания среди использования уязвимостей)
— модели нарушителя
— определены границы, но нет целей! Цель должна быть заранее определена и отражена в отчете (достигнута или нет).
— красивой картинки проведения работ 🙂
— рекомендации не разделены на оперативные и долгосрочные (логично вынести однотипные рекомендации во вложения)
Для администратора/сотрудника отдела ИБ:
— вместо подробного протокола проведения тестирования (мы выполнили то-то, получили то-то, это нам позволило сделать то-то и в результате достигнуто то-то) в отчете содержатся несвязанные уязвимости. Понимание последовательности выполняемых действий атакующим позволяет защищающейся стороне заранее их предвидеть и держать хвост пистолетом 😉
Кроме того, протокол требуется для разбора моментов вроде: почему в момент, когда пентестер выполнял то-то не сработало то-то или пентестер выполнил то-то, администратор зафиксировал это так-то, а должен был вот-так и т.д.
И опционально — сравнение состояния порутанных систем с отраслевыми стандартами aka CIS/NIST/SANS. Это полезно, как для CIO/CISO (нас можно взломать за N-дней, потому что у нас X%-систем не соответствуют рекомендуемым настройкам YYY), так и администраторам (мне нужно создать групповую политику, которая поменяет этот параметр в реестре на вот этих серверах и тогда я выполню вот этот контроль).
Александр, в отчете, предложенном Вами, я больше увидел не отчет по тестированию на проникновение, а отчет по инструментальному обследованию с ручной верификацией уязвимостей. Хотя возможно у меня просто завышены требования к подобным работам…
Спасибо, Дима, за такой расширенный комментарий!
>>Для высшего руководства (CEO/CFO):
>>- оценки влияния совокупного использования всех уязвимостей на бизнес-процессы
В совокупности все уязвимости врядли кто-то будет использовать, для каждой уязвимости (или группы уязвимостей, если их можно логически связать в группы) описывается риск в терминах влияния на бизнес.
Согласен, что в резюме для руководства нужно добавлять самые критичные возможные последствия реализации угроз.
>>Для CIO/CISO:
>>- оценки по векторам проникновения и/или по процессам обеспечения ИБ (если работы
>>проводятся не в первый раз, должна быть отражена динамика)
Эффективность процессов обеспечения ИБ мы оцениваем в ходе аудита СУИБ, по сути пентест позволяет найти недостатки всего в нескольких процессах: Patch management, Security Awareness, Access Control Management.
>>- отсутствует полученный уровень доступа к системам (должно быть выделено в самом начале, >>помимо упоминания среди использования уязвимостей)
Да, согласен, стоит вначале упомянуть для какого процента систем был получен административный доступ, а для кого – на уровне пользователя.
>>- модели нарушителя
Согласен.
>>- определены границы, но нет целей! Цель должна быть заранее определена и отражена в >>отчете (достигнута или нет).
Наверное стоит, но пока все понимали, что цель тестирования – захватить административный доступ.
>>- красивой картинки проведения работ
Не думаю. Руководство прочитает в лучшем случае первую страницу.
>>- рекомендации не разделены на оперативные и долгосрочные (логично вынести однотипные рекомендации во вложения)
Здесь приведен только отрывок. В полноценном отчете недостатки группируются по категориям, а внутри категорий первыми идут с наивысшем риском. Хотя согласен в итоге сделать roadmap будет весьма полезно.
>>Для администратора/сотрудника отдела ИБ:
>>- вместо подробного протокола проведения тестирования (мы выполнили то-то, получили то-то,
>>это нам позволило сделать то-то и в результате достигнуто то-то) в отчете содержатся
>>несвязанные уязвимости. Понимание последовательности выполняемых действий атакующим
>>позволяет защищающейся стороне заранее их предвидеть и держать хвост пистолетом
Такая последовательность описана в разделе ”Наш подход”, где идет связка между этапами тестирования и выявленными уязвимостями.
Я категорично против написания комиксов о том, как круто нам удалось, что-то поломать. Может быть администратору будет это и интересно читать, но далеко не факт, что реальный злоумышленник пойдет именно по-этому пути. Да на самом деле уже и не пойдет раз такие работы проведены.
>>Александр, в отчете, предложенном Вами, я больше увидел не отчет по тестированию на
>>проникновение, а отчет по инструментальному обследованию с ручной верификацией
>>уязвимостей. Хотя возможно у меня просто завышены требования к подобным работам…
Дима, не хочется возвращаться к долгим дискуссиям, что такое пентест (их уже было множество), но, если взять за данность то, что пентестом называется тестирование с применением методик злоумышленников (http://en.wikipedia.org/wiki/Penetration_test), то данный подход является полноценным тестированием, целью которого является выявление максимального количества реальных уязвимостей. Сканеры используются исключительно для экономии средств заказчика. Зачем вручную анализировать баннер сервиса и искать потом в Google информацию об уязвимости, если специальное ПО сделает это за несколько секунд?
На мой взгляд, классический пентест, нацеленный на поиск одной-двух уязвимостей с целью демонстрации руководству, что их компанию легко можно взломать, уходит в прошлое. На дворе 2010, про хакеров сняты уже десятки фильмов, сегодня практически любой знает, что информация имеет свою стоимость и ее можно и нужно защищать.
Александр,
>> Я категорично против написания комиксов о том, как круто нам удалось, что-то поломать.
это не комиксы 🙂 вот есть у Заказчика IPS, он хочет выяснить, почему она не сработала. Есть у Заказчика группа системных администраторов, кто-то заметил атаку, сменил пароль на систему и не сообщил об этом инциденте в службу ИБ. Заказчику нужно об этом знать.
>> но далеко не факт, что реальный злоумышленник пойдет именно по-этому пути.
не факт, но весьма вероятно.
>> на самом деле уже и не пойдет раз такие работы проведены.
…если уязвимости буду устранены…
>> но, если взять за данность то, что пентестом называется тестирование с применением методик злоумышленников (http://en.wikipedia.org/wiki/Penetration_test
Александр 🙂 Я конечно хорошо отношусь к вики, но иногда люди, которые в нее пишут не до конца разбираются в предметной области. Я против того, чтобы считать материалы с вики стандартом де-факто.
>> На мой взгляд, классический пентест, нацеленный на поиск одной-двух уязвимостей с целью демонстрации руководству, что их компанию легко можно взломать, уходит в прошлое.
Я придерживаюсь другого мнения по данному вопросу.
>>Я придерживаюсь другого мнения по данному вопросу.
Дмитрий, скажите, какой процент проектов по тестированию на проникновение, в которых вы участвовали, были ”открывалками” нового клиента, которому затем продавалось программное обеспечение для автоматизированного выявления уязвимостей?
На мой взгляд, классический тест на проникновение больше полезен компании-провайдеру услуг, так как позволяет немного припугнуть клиента плохим состоянием дел в области ИБ и продать ему полноценный аудит ИБ или же какой-нибудь полезный софт. Соответственно, чем больше повышается грамотность клиентов в области ИБ, тем в меньшей степени требуется демонстрация их уязвимости перед угрозой взлома.
Александр,
>> какой процент проектов по тестированию на проникновение, в которых вы участвовали, были ”открывалками” нового клиента, которому затем продавалось программное обеспечение для автоматизированного выявления уязвимостей?
К счастью, я об этом даже не задумываюсь 🙂 и у меня нет данных по этому вопросу. Я лишь стараюсь выполнить свою работу максимально качественно и с максимальной пользой для Заказчика, не забивая голову всякой ерундой 🙂 А продажами, пусть занимается отдел sales. У меня нет процента от продаж, видимо, я счастливый человек 😉
>> На мой взгляд,… позволяет немного припугнуть клиента…
Это одна из возможных целей пентеста.
>> чем больше повышается грамотность клиентов в области ИБ, тем в меньшей степени требуется демонстрация их уязвимости перед угрозой взлома
Ну не знаю, не знаю. Вот работаем мы с одним клиентом уже N-ый год. В самом начале было очень плохо у него с безопасностью. За несколько лет, совместными усилиями, ситуация с безопасностью изменилась в лучшую сторону. Сейчас мы помогаем ему, чтобы благоприятная тенденция сохранялась. И он, насколько мне известно, не собирается отказываться от дальнейшей работы с нами.
И по поводу отчетов по пентестам: http://devteev.blogspot.com/2010/02/blog-post_23….
"Дмитрий, скажите, какой процент проектов по тестированию на проникновение, в которых вы участвовали, были ”открывалками” нового клиента"
Если вы намекаете, что для нас пентест это способ продвижения продукта, то вы капитально ошибаетесь 🙂
Вы допускаете довольно странную для специалиста вашего уровня ошибку: считаете, что человека, который выделяет бюджет на меры безопасности, действительно интересует, сколько именно уязвимостей у него смогли найти, 20 или 25. На самом деле его интересует:
— правда ли, что злоумышленник может обойти применяемые ими механизмы бузопасности?
— как ои докатились до такой жизни?
— и что сделать для того, чтобы ситуацию улучшить?
Так вот, правильно проведенный пентест (и ключевое слово здесь — "правильно"), вскрывает системные ошибки в организации защиты, которые не выявляются ни аудитом СМИБ, ни сканированием. Типичный пример, с которым Дмитрий часто сталкивается: проводится арп-спуфинг, после чего заказчик садится, и начинает разбираться, а почему это у него IDS не отработал, а если отработал — почему никто не отреагировал. Это не patch management, не awareness, не access control management, это комплекс ощшибок как в управлении конфигурацией сетевых устройств, так и в менеджментеинцидентов.
Если бы мы проводили тьесты на проникновение так, как описываете вы, они действительно были бы просто "открывалками". Но мы понимаем пентест гораздо шире 🙂
to Malatavr: Чувствую, задел за живое. Прошу прощения!
Дмитрий, Малатавр, я ратую за то, что тестирование на проникновение должно проходить с использованием определенной методологии и быть нацеленным не на демонстрацию нескольких уязвимостей, а на поиск максимального их количества. Иначе это выливается в развлечение технического специалиста за деньги клиента: приходит человек с десятком домашних заготовок + берет парочку private эксплойтов , пробует первый способ, и… удача — клиент взломан. Работа на этом прекращается.
Cогласен, что среди процессов, в которых находятся недостатки с помощью пентести,security incident management занимает не последнее место.
Дмитрий, Малатавр,
хочу еще добавить, что лично я считаю, что программные продукты вашей компании являются одними из лучших на рынке.
Александр,
По поводу "задел за живое" — есть такое дело 🙂 Хотя для нас пентесты являются побочным напрвлением, мы действительно вкладываем в понятие "тест на проникновение" значительно быльший смысл, чем вы или Андрей Соколов. И это никоим образом не принижение коллег по цеху, а скорее попытка привести это мероприятие к единому знаменателю и к большей пользе для заказчика 🙂
Грубо говоря, мой лично интерес в подобных обсуждениях:
1. Проинформировать потенциальных потребителей услуги о том, что от пентеста они могут получитть значительно больше пользы, чем кажется на первый взгляд
2. Подтолкнуть коллег по цеху к тому, что не нужно ограничивать себя рамками определения из википедии, а исходить из реальных потребностей заказчика.
В противном случае мы рискуем свести тест на проникновение к такому же бессмысленному набору телодвижений, каки стала обязательная сертификация СЗИ 🙂