Сегодня выступал на мероприятии, которое странным образом оказалось знакомым. Пока готовил презентацию, понял, что такое уже делал. Посмотрел и действительно, с подобным докладом выступал на SQL Days. Но сейчас доклад получился более помпезным. Видимо окружение обязовало.
На этом же круглом столе выступал также Юрий Гуревич из Microsoft Research. Оказывается Microsoft упорно пишит аналог MaxPatrol. Я в шоке :). Придется интегрироваться... Пообщались, проблемы теже. В том числе и управление требованиями. И тоже пока не решена.
К сожалению, работа не дала возможности остаться на все выступления. Пришлось убежать.
Показаны сообщения с ярлыком assesment. Показать все сообщения
Показаны сообщения с ярлыком assesment. Показать все сообщения
среда, 28 октября 2009 г.
понедельник, 19 октября 2009 г.
Статистика безопасности Web-приложений 2008
Опубликована статистика уязвимостей Web-приложений за 2008 г. консорциума Web Application Security Consortium (WASC). Ознакомиться с ней можно здесь.
Русский вариант для загрузки.
WASC Web Application Security Statistics 2008 (Russian)
Публикация содержит обзорную статистику уязвимостей Web-приложений, полученную в ходе работ по тестированиям на проникновение, аудитов безопасности и других работ, проводимых Компаниями, входящими в консорциум WASC в 2008 году. Всего статистика содержит данные о 12186 сайтах, в которых было обнаружено 97554 уязвимости различной степени риска.
Дмитрий Евтеев опубликовал сравнение с нашей статистикой:
Забавно, но между русским (первоначальным, как вы могли догадаться) и "word-wide" есть некоторые различия. Для соблюдения политесу был выкинут раздел 4.3 - сравнение различных методик . Вот он, свободный демократический мир :)
Русский вариант для загрузки.
WASC Web Application Security Statistics 2008 (Russian)
Публикация содержит обзорную статистику уязвимостей Web-приложений, полученную в ходе работ по тестированиям на проникновение, аудитов безопасности и других работ, проводимых Компаниями, входящими в консорциум WASC в 2008 году. Всего статистика содержит данные о 12186 сайтах, в которых было обнаружено 97554 уязвимости различной степени риска.
Дмитрий Евтеев опубликовал сравнение с нашей статистикой:
Забавно, но между русским (первоначальным, как вы могли догадаться) и "word-wide" есть некоторые различия. Для соблюдения политесу был выкинут раздел 4.3 - сравнение различных методик . Вот он, свободный демократический мир :)
среда, 8 апреля 2009 г.
пентесты и Пентесты.. Я в шоке
Попался на глаза опус:
http://www.iso27000.ru/blogi/aleksandr-astahov/pentest-stoit-li-ovchinka-vydelki
Я в шоке, мой ноутбук в шоке и даже игрушечная собачка моего сына в шоке.
Понимаю, если бы это было написано в 2000 году, когда зрелость российского рынка консалтинга была близка к нулю. Но сейчас... Все таки не зря на Рускрипто целая секция была практически повещена тестированию на проникновение (понимаю, что я уже делал слишком много анонсов, но подождите, в скором времени опубликуем презентации и даже видео некоторых выступлений).
И так, пройдемся по тезисам:
Польза от пентеста для заказчика заключается в следующем:
# возможность обнаружения и устранения одной или нескольких серьезных уязвимостей
В рамках пентеста обнаруживаются сотни проблем в безопасности и ошибок в реализации СУИБ, на устранение которых зачатую уходят годы. Примеры - недостаточная осведомленность сотрудников или ошибки в процессе защиты Web-приложений. Только сегодня проводили совместно с 1С-Bitrix представление их нового продукта - модуля проактивной защиты. Яркий пример компании, которую пентест подвиг не только на устранение уязвимостей, но и на изменение процессов (аудит исходного кода, создание штата разработчиков), и даже больше - к созданию собственного продукта в области безопасности - web application firewall.
Не хочу никого обижать, но средний пентест делается практически по себестоимости. Это технологическая услуга требующая большой организационной работы (чтобы ничего не завалить :), специалистов с уникальными навыками и специфичного, зачастую недешевого софта.
Конечно можно нанять "крутого хакера", который просканирует систему "взломанной" версией XSpider и попробует пару экплойтов с milw0rm. Тогда, наверное и результат будет подобный описанному в статье и услуга будет "высокорентабельной".
Теперь о том, чего заказчик не получает от пентеста:
* объективной оценки защищенности своей корпоративной сети
Объективной оценки, господа, не дает ничего. Даже, простят меня, сертификация. Есть только уязвимости и вероятность реализации угрозы, полученные в рамках указанной модели угроз и бюджета. То, что уязвимости никто не обнаружил, не говорит о том, что её нет. Иначе бы Microsoft, тратящий миллионы и миллионы на безопасность, аудит кода, построение безопасных процессов разработки и т.д. и т.п., уже давно бы выпускал программы без уязвимостей. И мы бы забыли про вторые вторники...
идентификации и анализа всех существующих уязвимостей корпоративной сети, позволяющих судить об общем уровне защищенности (для успешного проникновения достаточно обнаружить лишь одну или несколько уязвимостей)
Процитирую свою небольшой кусок из тезисов к Рускрипто:
Цель пентеста в том, чтобы взломать
Цель пентеста в том, чтобы оценить эффективность существующей СУИБ и продемонстрировать наиболее яркие проблемные места в рамках выбранной модели злоумышленника, устранить которые требуется в первую очередь. Сам "взлом" только подручный механизм реализации основной задачи и может использоваться с различными целями. Например, для облегчения понимания результатов работ руководством или для развития хода работ, например прыжка их Интернет в ДМЗ, из ДМЗ в технологическую сеть и т.д. Если проводить работы с установкой на "взлом", то максимум к чему может привести тест, это обнаружение нескольких "страшных" уязвимостей, устранение которых может занять несколько минут или часов. И в такой ситуации пентест полностью оправдывает отношение как к фрагментарной, малоэффективной услуги.
# уверенности в том, что удалось устранить имеющиеся уязвимости и повысить защищенность систем (исполнитель продемонстрировал заказчику лишь один или несколько возможных сценариев проникновения, а сколько их еще может быть?)
Странный тезис. Уязвимости были устранены? Были. Защищенность была повышена? Несомненно. Исполнитель продемонстрировал только один сценарий? А что в ТЗ было написано? Поломайте меня как-нибудь?
уверенность в том, что конфиденциальные данные заказчика не утекли насторону (пентест не предполагает, что все действия исполнителя осуществляются под контролем представителей заказчика, как это происходит при обычном аудите безопасности, по крайней мере, вероятность утечки данных при пентесте значительно выше)
Это вообще полный бред. Утечка регулируется соглашением о конфиденциальности. Ни один из вменяемых исполнителей не будет против, если в ходе работ будет присутствовать представитель заказчика. Более того, тесный контакт с заказчиком и согласование "ходов", это залог успешных работ. Я обычно даже люблю в ходе внутреннего теста "почитать лекции" о том, что я сейчас делаю, и как все это ловко у меня получается :) Или не получается :(
Обычный анализ защищенности корпоративной сети при помощи сетевых и хостовых сканеров, требующий куда меньше времени (и квалификации) от исполнителя и денежных затрат от заказчика, позволять получить куда как более полезные результаты, а именно:
* идентифицировать и проранжировать все имеющиеся технические уязвимости (по крайней мере те, о которых известно из доступных исполнителю источников)
* дать объективную оценку уровня защищенности систем заказчика и его адекватность
* разработать подробный план действий по устранению, либо смягчению всех имеющихся уязвимостей, а не только тех, которые использовались в ходе пентеста
Тут я теряюсь совершенно. Опять эта объективная оценка всплыла... Как пентест, в ходе которого используется пяток специализированных сканеров, дополнительных утилит для верфикации и эксплуатации уязвимостей, ручной анализ уязвимостей может дать худший результат, чем просто запуск сканера? Как сканер реализует задачи глубокой оценки защищенности Web или беспроводных сетей, или уровня оценки персонала? Мне не понятно.
Сканеры никто не отменяет, но за ними должен сидеть человек, который "делает пентест в голове", чтобы расставить приоритеты и эффективно устранять обнаруженные проблемы. Сами сканеры этого не могут. Хотя мы работаем над этим :)
Если вам нужен именно анализ защищенности, либо оценка рисков, тогда глупо заказывать пентест, т.к. заплатите вы намного больше, а требуемого результата в виде реального повышения уровня защищенности и уменьшения рисков не получите.
Еще раз - пентесты не стоят дорого. Так сложился рынок. Есть дорогие задачи, когда пентест может стоить на уровне аудита. Но как правило это задачи с большим объемом работ или с узкой специализацией (например пентест специфического приложения). Более того, нормальный аудит, без которого невозможен нормальный анализ рисков, как правило включает в себя пентест. Где логика?
Я понимаю, что многим хочется быть Брюсом (http://www.schneier.com/blog/archives/2007/05/is_penetration.html), на повторять его спорные мнения не стоит.
Пентест, это одна из работ в области ИБ со своими плюсами и минусами, ограничениями, со своей методиками и целями. И зачастую с ожидаемыми результатами. Пугающими?...
http://www.iso27000.ru/blogi/aleksandr-astahov/pentest-stoit-li-ovchinka-vydelki
Я в шоке, мой ноутбук в шоке и даже игрушечная собачка моего сына в шоке.
Понимаю, если бы это было написано в 2000 году, когда зрелость российского рынка консалтинга была близка к нулю. Но сейчас... Все таки не зря на Рускрипто целая секция была практически повещена тестированию на проникновение (понимаю, что я уже делал слишком много анонсов, но подождите, в скором времени опубликуем презентации и даже видео некоторых выступлений).
И так, пройдемся по тезисам:
Польза от пентеста для заказчика заключается в следующем:
# возможность обнаружения и устранения одной или нескольких серьезных уязвимостей
В рамках пентеста обнаруживаются сотни проблем в безопасности и ошибок в реализации СУИБ, на устранение которых зачатую уходят годы. Примеры - недостаточная осведомленность сотрудников или ошибки в процессе защиты Web-приложений. Только сегодня проводили совместно с 1С-Bitrix представление их нового продукта - модуля проактивной защиты. Яркий пример компании, которую пентест подвиг не только на устранение уязвимостей, но и на изменение процессов (аудит исходного кода, создание штата разработчиков), и даже больше - к созданию собственного продукта в области безопасности - web application firewall.
Полезность пентеста для исполнителя состоит в следующем:
- возможность заработать приличные деньги (пентест - услуга высокорентабельная)
Не хочу никого обижать, но средний пентест делается практически по себестоимости. Это технологическая услуга требующая большой организационной работы (чтобы ничего не завалить :), специалистов с уникальными навыками и специфичного, зачастую недешевого софта.
Конечно можно нанять "крутого хакера", который просканирует систему "взломанной" версией XSpider и попробует пару экплойтов с milw0rm. Тогда, наверное и результат будет подобный описанному в статье и услуга будет "высокорентабельной".
Теперь о том, чего заказчик не получает от пентеста:
* объективной оценки защищенности своей корпоративной сети
Объективной оценки, господа, не дает ничего. Даже, простят меня, сертификация. Есть только уязвимости и вероятность реализации угрозы, полученные в рамках указанной модели угроз и бюджета. То, что уязвимости никто не обнаружил, не говорит о том, что её нет. Иначе бы Microsoft, тратящий миллионы и миллионы на безопасность, аудит кода, построение безопасных процессов разработки и т.д. и т.п., уже давно бы выпускал программы без уязвимостей. И мы бы забыли про вторые вторники...
идентификации и анализа всех существующих уязвимостей корпоративной сети, позволяющих судить об общем уровне защищенности (для успешного проникновения достаточно обнаружить лишь одну или несколько уязвимостей)
Процитирую свою небольшой кусок из тезисов к Рускрипто:
Цель пентеста в том, чтобы взломать
Цель пентеста в том, чтобы оценить эффективность существующей СУИБ и продемонстрировать наиболее яркие проблемные места в рамках выбранной модели злоумышленника, устранить которые требуется в первую очередь. Сам "взлом" только подручный механизм реализации основной задачи и может использоваться с различными целями. Например, для облегчения понимания результатов работ руководством или для развития хода работ, например прыжка их Интернет в ДМЗ, из ДМЗ в технологическую сеть и т.д. Если проводить работы с установкой на "взлом", то максимум к чему может привести тест, это обнаружение нескольких "страшных" уязвимостей, устранение которых может занять несколько минут или часов. И в такой ситуации пентест полностью оправдывает отношение как к фрагментарной, малоэффективной услуги.
# уверенности в том, что удалось устранить имеющиеся уязвимости и повысить защищенность систем (исполнитель продемонстрировал заказчику лишь один или несколько возможных сценариев проникновения, а сколько их еще может быть?)
Странный тезис. Уязвимости были устранены? Были. Защищенность была повышена? Несомненно. Исполнитель продемонстрировал только один сценарий? А что в ТЗ было написано? Поломайте меня как-нибудь?
уверенность в том, что конфиденциальные данные заказчика не утекли насторону (пентест не предполагает, что все действия исполнителя осуществляются под контролем представителей заказчика, как это происходит при обычном аудите безопасности, по крайней мере, вероятность утечки данных при пентесте значительно выше)
Это вообще полный бред. Утечка регулируется соглашением о конфиденциальности. Ни один из вменяемых исполнителей не будет против, если в ходе работ будет присутствовать представитель заказчика. Более того, тесный контакт с заказчиком и согласование "ходов", это залог успешных работ. Я обычно даже люблю в ходе внутреннего теста "почитать лекции" о том, что я сейчас делаю, и как все это ловко у меня получается :) Или не получается :(
Обычный анализ защищенности корпоративной сети при помощи сетевых и хостовых сканеров, требующий куда меньше времени (и квалификации) от исполнителя и денежных затрат от заказчика, позволять получить куда как более полезные результаты, а именно:
* идентифицировать и проранжировать все имеющиеся технические уязвимости (по крайней мере те, о которых известно из доступных исполнителю источников)
* дать объективную оценку уровня защищенности систем заказчика и его адекватность
* разработать подробный план действий по устранению, либо смягчению всех имеющихся уязвимостей, а не только тех, которые использовались в ходе пентеста
Тут я теряюсь совершенно. Опять эта объективная оценка всплыла... Как пентест, в ходе которого используется пяток специализированных сканеров, дополнительных утилит для верфикации и эксплуатации уязвимостей, ручной анализ уязвимостей может дать худший результат, чем просто запуск сканера? Как сканер реализует задачи глубокой оценки защищенности Web или беспроводных сетей, или уровня оценки персонала? Мне не понятно.
Сканеры никто не отменяет, но за ними должен сидеть человек, который "делает пентест в голове", чтобы расставить приоритеты и эффективно устранять обнаруженные проблемы. Сами сканеры этого не могут. Хотя мы работаем над этим :)
Если вам нужен именно анализ защищенности, либо оценка рисков, тогда глупо заказывать пентест, т.к. заплатите вы намного больше, а требуемого результата в виде реального повышения уровня защищенности и уменьшения рисков не получите.
Еще раз - пентесты не стоят дорого. Так сложился рынок. Есть дорогие задачи, когда пентест может стоить на уровне аудита. Но как правило это задачи с большим объемом работ или с узкой специализацией (например пентест специфического приложения). Более того, нормальный аудит, без которого невозможен нормальный анализ рисков, как правило включает в себя пентест. Где логика?
Я понимаю, что многим хочется быть Брюсом (http://www.schneier.com/blog/archives/2007/05/is_penetration.html), на повторять его спорные мнения не стоит.
Пентест, это одна из работ в области ИБ со своими плюсами и минусами, ограничениями, со своей методиками и целями. И зачастую с ожидаемыми результатами. Пугающими?...
понедельник, 26 января 2009 г.
Риски, риски, риски...
Недавно, в ходе работ по анализу защищенности наткнулись на уязвимость Web-интерфейса управления одним UTM-устройством. Достаточно типичное сочетание CSRF и XSS примечательно тем, что через Web-интерфейс позволяет получить доступ к коммандной строке устройства и интерактивно "рулить" системой в браузере администратора. Но не суть, уязвимость типичная.
Интересное началось, как обычно на этапе взаимодействия с вендором. Мы не сошлись в степени риска, связанной с этой уязвимостью, что привело к ожесточенной переписке. В связи с этим, хотелось бы поделится своими наработками в данном направлении.
Как правило, степень риска присваивается уязвимости производителем системы, в которой изъян был обнаружен, либо компанией, выпускающей средства защиты (сканеры уязвимостей, системы обнаружения атак и т. д.). В этом случае используется привычная по правилам дорожного движения схема: низкая степень риска (зеленый), средняя степень риска (желтый), высокая степень риска (красный). Иногда выделяется дополнительный, четвертый уровень риска — критические уязвимости.
Такого подхода придерживаются многие производители, например, Microsoft в своих уведомлениях об обновлениях программного обеспечения использует четыре уровня критичности уязвимостей.
Однако, "светофорная модель" весьма непрозрачна и очень зависит от мировозрения и самочувствия эксперта и других факторов. В связи с этим мы широко используем в своей работе методику CVSSv2.
http://www.securitylab.ru/analytics/355336.php
http://www.securitylab.ru/analytics/356476.php
Достаточно простые метрики, заложенные в CVSSv2 позволяют более или менее однозначно оценить риск. Более того, метрики позволяют оценивать и различные дополнительные факторы, такие как вероятность эксплуатации и среду. Что очень важно.
Цитирую:
(AV:N/AC:L/Au:N/C:C/I:N/A:P/E:H/RL:W/RC:C) = 8.1
Если же Web-сервер работает с SQL-server с чрезмерными привилегиями, например sa, то эта же уязвимость будет гораздо более опасной:
(AV:N/AC:L/Au:N/C:C/I:C/A:C/E:H/RL:W/RC:C) = 9.5
Если перевести эти оценки к "светофорной" модели или 5 уровням, принятых в PCI DSS (Urgent, Critical, High, Medium, Low), то получим:
1. Средний (2) и High (3)
2. Средний (2) и Critical (4)
3. Высокий (3) и Urgent (>4).
Т.е. степень риска одной и той же уязвимости может серьезно меняться в зависимости от конкретной системы и её настроек.
Что же касается XSS с которого начиналась заметка, то ее вектор будет
(AV:N/AC:H/Au:N/C:C/I:C/A:C/E:F/RL:W/RC:C) = 6.9
Т.е. с точки зрения PCI DSS (а именно эту модель сейчас "модно" использовать) степень риска данной проблемы можно обозначить как High или даже Critical, а не Low. В любом случае, аудит провален :)).
ЗЫ. Хотя я могу понять вендора, ведь если безопасность не заложена в приложение изначально, то, цитирую: "hardening the management interface would probably imply a complete redesign of it".
Вот такая она разная, оценка рисков.
Интересное началось, как обычно на этапе взаимодействия с вендором. Мы не сошлись в степени риска, связанной с этой уязвимостью, что привело к ожесточенной переписке. В связи с этим, хотелось бы поделится своими наработками в данном направлении.
Как правило, степень риска присваивается уязвимости производителем системы, в которой изъян был обнаружен, либо компанией, выпускающей средства защиты (сканеры уязвимостей, системы обнаружения атак и т. д.). В этом случае используется привычная по правилам дорожного движения схема: низкая степень риска (зеленый), средняя степень риска (желтый), высокая степень риска (красный). Иногда выделяется дополнительный, четвертый уровень риска — критические уязвимости.
Такого подхода придерживаются многие производители, например, Microsoft в своих уведомлениях об обновлениях программного обеспечения использует четыре уровня критичности уязвимостей.
Однако, "светофорная модель" весьма непрозрачна и очень зависит от мировозрения и самочувствия эксперта и других факторов. В связи с этим мы широко используем в своей работе методику CVSSv2.
http://www.securitylab.ru/analytics/355336.php
http://www.securitylab.ru/analytics/356476.php
Достаточно простые метрики, заложенные в CVSSv2 позволяют более или менее однозначно оценить риск. Более того, метрики позволяют оценивать и различные дополнительные факторы, такие как вероятность эксплуатации и среду. Что очень важно.
Цитирую:
Не касаясь достоинств или недостатков каждого из методов можно выделить следующие особенности, которые могут влиять на достоверность оценки:
- зависимость от контекста;
- зависимость от конфигурации системы;
- зависимость от метода определения.
В различных приложениях уязвимости одного типа могут иметь различную степень риска. Так, уязвимость «Подделка HTTP-запроса» может не представлять угрозы для типичного репрезентативного сайта или поисковой машины, и наоборот – классифицироваться как проблема высокой степени риска в Web-интерфейсе электронной почты или платежной системы. В результате утечки информации злоумышленник может получить доступ к журналам работы приложения (низкая или средняя степень риска), а может загрузить резервную копию исходных текстов сайта (высокая степень риска).
Конфигурация конкретной системы также может оказывать серьезное влияние на степень риска. Так, уязвимость «Внедрение операторов SQL» обычно классифицируют как имеющую высокую опасность. Однако в случае если Web-приложение работает с сервером СУБД с ограниченными привилегиями, она может быть отнесена к проблемам средней или низкой степени риска. В другой инсталляции или реализации приложения эта же уязвимость может быть использована для получения доступа к операционной системе с правами суперпользователя, что естественно делает её наиболее критичной.
В зависимости от метода у глубины анализа степень одна и та же уязвимость может быть оценена по-разному. Если взять приведенный выше пример «Внедрения операторов SQL», использование сетевого сканера позволит только констатировать наличие проблемы. Для определения привилегий, доступных потенциальному злоумышленнику требуется либо попытаться использовать ошибку, либо уточнить порядок взаимодействия между Web-приложением и СУБД методом «белого ящика».
Т.е. крайне некорректно относить две различные уязвимости одного типа (например SQL Injection) к одной степени риска без детального анализа.
Привожу пример.
Предположим SQL Injection позволяет получить доступ к СУБД минимально необходимыми для Web-сервера привилегиями, например db_reader. Причем Web-приложение не хранит в СУБД конфиденциальной информации, например паролей.
Тогда вектор и степень риска CVSSv2 будет равены:
(AV:N/AC:L/Au:N/C:P/I:N/A:P/E:H/RL:W/RC:C) = 6.1
(AV:N/AC:L/Au:N/C:C/I:N/A:P/E:H/RL:W/RC:C) = 8.1
Если же Web-сервер работает с SQL-server с чрезмерными привилегиями, например sa, то эта же уязвимость будет гораздо более опасной:
(AV:N/AC:L/Au:N/C:C/I:C/A:C/E:H/RL:W/RC:C) = 9.5
Если перевести эти оценки к "светофорной" модели или 5 уровням, принятых в PCI DSS (Urgent, Critical, High, Medium, Low), то получим:
1. Средний (2) и High (3)
2. Средний (2) и Critical (4)
3. Высокий (3) и Urgent (>4).
Т.е. степень риска одной и той же уязвимости может серьезно меняться в зависимости от конкретной системы и её настроек.
Что же касается XSS с которого начиналась заметка, то ее вектор будет
(AV:N/AC:H/Au:N/C:C/I:C/A:C/E:F/RL:W/RC:C) = 6.9
Т.е. с точки зрения PCI DSS (а именно эту модель сейчас "модно" использовать) степень риска данной проблемы можно обозначить как High или даже Critical, а не Low. В любом случае, аудит провален :)).
ЗЫ. Хотя я могу понять вендора, ведь если безопасность не заложена в приложение изначально, то, цитирую: "hardening the management interface would probably imply a complete redesign of it".
Вот такая она разная, оценка рисков.
четверг, 16 октября 2008 г.
Выступление SQADays 2008
Нечаянно набрел в сети на видео. Весной участвовал в конференции братской хартии - специалистов по качеству ПО. Да, да это те самые люди, которые вместо bugtraq пишут bugtrack. С ошибкой в общем. Как оказалось, проблематика у нас, особенно в области Application Security достаточно сильно пересекается, как и инструментарий. Однако тестировщикам чаще верят на слово - не приходится ничего "доламывать" для обоснования затрат. Верят на слово. Оно и понятно - QA обычно часть процесса разработки, а не приходящие наёмники, мешающие сдать проект в срок.
Доклад общеметодический и достаточно нудный :)
Видео:
Презентация:
Доклад общеметодический и достаточно нудный :)
Видео:
Презентация:
Подписаться на:
Сообщения (Atom)