Показаны сообщения с ярлыком fuzzing. Показать все сообщения
Показаны сообщения с ярлыком fuzzing. Показать все сообщения

четверг, 4 февраля 2010 г.

Все-таки зачем эти пентесты нужны?

В очередной раз поднята тема "пользы pentest".
Что не может не радовать. Значит актуальность некоторая есть и на Рускрипто я тему вынес в секцию не напрасно.
Попробую кратко высказаться.

Зачем pentest?

Реально встречаю четыре варианта (заслуживающих внимания):
  • доказать/наказать
  • придать импульс, приступить к планированию
  • посмотреть на результаты, проконтролировать
  • так надо (compliance)

Самый жесткий и зачастую чреватый для исполнителя/заказчика - первый. Поскольку доказуемые и наказываемые редко хотят быть доказанными и наказанными, что приводит к активному противодействию. Как на техническом так и на организационных фронтах.
В результате доказующий и доказуемый, вполне договорятся (в одной конторе крутимся, жить дальше надо вместе), а крайним "за ЭТО" (результаты подножек) +"все что еще было" (приписки не умерли с СССР) будет назначен кто-то внешний.

Жесткий вариант, требует жесткого контроля и жесткого согласования каждого чиха (лучше под подпись) и, что самое жесткое - не всегда распознается до наступления последствий (..из избы..).

Как pentest?

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

И в принципе - возможные результаты работ (те самые пользы) должны быть понятны из ТКП ибо говорится что и на что проверяется.

Что же касается "внешний/внутренний"... Самый худший для меня вариант, когда при "red team" заказчик всячески настаивает чтобы "расхакали" вот эти критичные систетемы во глубине инфраструктуры. И всячески отвергает "серый ящик (поговорить, посмотреть, детализировать) после того, как закончим с периметром". Неэффективно, опасно.

Приведу пример неэффективности. Немного технически, но суть та же - "беганье с антенной" - далеко не самый эффективный метод. Хотя и без антенны сложно. Поэтому антенна нужна для установления наличия присутствия, а детализация - поговорить/посмотреть.

Причем "серый" ящик не отменят "пентеста". Все наиболее эффективные работы такого плана проходили по сценарию:

- покопали, много дырок;
- пару страшных каждого типа использовали;
- собрали всех вовлеченных/подверженных - показали.
-- Теперь верите?
-- Верим.
-- Дальше также или чтобы польза была?
-- Да и так все ясно... А что вы про пользу говорили?
- переходим в детальному анализу больных мест, названных консолидированным заказчиком.
Причем не всегда с помощью "penetration". Где MaxPatrol поаудитим, где с админами посидим, где с менеджерами кофейка. Вполне себе аудит получается :)

Конечно, если взять на флаг "передовой материал" по "методикам пентеста" или чеклист "как делать пентест под PCI", то такого не получится. Ибо не написано зачастую в методике :)
Мне пытались возразить, что мол "бюджет, нагрузка, проектные риски". Ничего подобного. Эффективность выше. И для заказчика и для исполнителя.

И тут подползаем к самому интересному

Что в результате

Pentest не отвечает на вопрос "почему?". Да и не ставится такой вопрос.
Есть ответ на вопрос "что?" и, в некоторых случаях "в какой степени?".

Вопрос "Мы знаем, что с Web у нас не очень, но непонятно насколько". Дальше варианты: пару раз ломали, затыкали, но ломали опять/аудитор из большой четверки сказал что у нас нет в договорах разработки систем требований по безопасности (Secure SDLC, нового модного термина №4)."

Ответ "Да, у вас здесь 374 SQLi, это больше чем в среднем по отрасли в 5 раз. Заткнуть не сможете, кривой дизайн. Хоть WAF прикройтесь. Или выключите в отдельном загоне".

Или "У вас 30 процентов кисок настроены так, что вообще непонятно, как работают. Падают? А...."

Или "Adobe патчить надо? А мы думали, что это за истерика у антивирусов"

Ну и плюс много-много мелочей, пропущенных, забытых, оставшихся без приоритетов. Админам побаловаться.

Вот где-то так.

вторник, 10 марта 2009 г.

Лаборатория безопасности Positive Technologies

С этого года решили возобновить публикацию информации об обнаруженных в ходе исследований и тестов на проникновение уязвимостях.

http://www.securitylab.ru/lab/

В 2006 году, в связи с рядом причин, было решено переложить бремя публикации обработки уязвимостей на вендора и приостановить публикацию ранее найденных проблем (http://www.ptsecurity.ru/advisory.asp). Однако многие заказчики просят содействовать в устранении уязвимостей в программах третьих производителей, в связи с чем, пришлось возобновить процесс.
Наиболее интересной проблемой из текущих (по моему мнению) является набор уязвимостей в VMWare, которые позволяют "выйти" из гостевой операционной системы на узловую. Причем сразу в kernel.
Персонально я в свое время побаловался с разными методами устранения уязвимостей в продуктах третьих производителей, от экстремизма Full-Disclosure до продажи уязвимостей на «белом» рынке, например iDefense (http://labs.idefense.com/vcp/). Некоторые соображения по этим вопросам доступны здесь:
http://www.securitylab.ru/analytics/241826.php

четверг, 16 октября 2008 г.

Выступление SQADays 2008

Нечаянно набрел в сети на видео. Весной участвовал в конференции братской хартии - специалистов по качеству ПО. Да, да это те самые люди, которые вместо bugtraq пишут bugtrack. С ошибкой в общем. Как оказалось, проблематика у нас, особенно в области Application Security достаточно сильно пересекается, как и инструментарий. Однако тестировщикам чаще верят на слово - не приходится ничего "доламывать" для обоснования затрат. Верят на слово. Оно и понятно - QA обычно часть процесса разработки, а не приходящие наёмники, мешающие сдать проект в срок.

Доклад общеметодический и достаточно нудный :)

Видео:



Презентация:

Sergey Gordeychik SQADays 2008
View SlideShare presentation or Upload your own. (tags: web security)