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

вторник, 19 июня 2012 г.

пятница, 8 июня 2012 г.

PHP более "дырявый" чем ASP.NET?

Именно такое впечатление может сложиться при прочтении различных интерпретаций нашей статистики по уязвимостям web-приложений. На хабре даже разгорелась по этому поводу небольшая священная война.
На самом деле все не так. На самом деле вероятность найти уязвимость в приложении на PHP гораздо проще найти уязвимость при соблюдении следующих условияй:

— вы анализируете приложение российских компаний из топ 100
— в вашем поле зрения наиболее бизнес-критичные системы, доступные из Интернет (именно с ними связаны основные риски, именно их и заказывают)
— вы честно признаетесь, что не можете найти ВСЕ уязвимости. Поскольку ограничения методики, которая не дает гарантии, да и все мы люди-человеки.

К сожалению других чисел у нас нет. То, что делает WASC и Whitehat Security чуть менее адекватно, поскольку содержит либо смесь черного и белого ящика (WASC), либо только черный с ручной верификацией (Whitehat).

Из highlighs - на 10% всех сайтов мы встречали вредоносное ПО либо закладку под его установку. Т.е. кто-то там уже был.




Вот такие вот пироги. Подробнее:
Русский
English

среда, 2 февраля 2011 г.

Истинная цена Compliance

Цитата

Расходы организаций, не соблюдающих правила информационной безопасности, в среднем превышают расходы организаций, их соблюдающих, в 2,65 раза, подсчитали аналитики из Ponemon Institute.

http://hitech.newsru.com/article/02feb2011/moresafe

http://www.tripwire.com/ponemon-cost-of-compliance/pressKit/True_Cost_of_Compliance_Report.pdf

Смело заявление. Надо покурить методику.


четверг, 5 августа 2010 г.

Обзор инцидентов: Verizon Breach Report 2010

Опубликован обзор инцидентов Verizon Breach Report 2010. Рекомендую.


http://www.verizonbusiness.com/go/2010databreachreport/



PS. В отчете широко используется WASC WATCv2. Приятно. 



PPS. Без комментариев:

вторник, 25 мая 2010 г.

Статистика уязвимостей Web 2009


В этом году были проанализированы данные о 5560 веб-приложениях протестированных специалистами компании Positive Technologies в ходе предоставления консалтинговых и сервисных услуг по информационной безопасности, таких как тесты на проникновение, анализ защищенности в рамках стандарта PCI DSS и мониторинг защищенности внешнего периметра с использованием системы MaxPatrol.
Практически половина проанализированных систем содержали уязвимости. Суммарно во всех приложениях было обнаружено 13434 ошибок различной степени риска, зафиксировано 1412 образцов вредоносного кода, содержащихся на страницах уязвимых систем. Доля скомпрометированных сайтов распространявших вредоносное программное обеспечение составила 1,7%. Каждый из таких сайтов содержал уязвимости, позволяющие выполнять команды на сервере, что подтверждает возможность использование этих уязвимостей для компрометации системы.
Основной результат исследования неутешителен. Вероятность обнаружения критичной ошибки в веб-приложении автоматическим сканером составляет около 35% и достигает 80% при детальном экспертном анализе. Этот факт демонстрирует невысокую защищенность современных Web-приложений не только от атак со стороны квалифицированных злоумышленников, но и от действий атакующих, вооруженных готовыми утилитами для «автоматического взлома».
Как и ранее, наиболее распространенными ошибками, допускаемыми разработчиками приложений, являются уязвимости «Межсайтовое выполнение сценариев» и «Внедрение операторов SQL» на которые пришлось более 19% и 17% всех обнаруженных уязвимостей соответственно.
С точки зрения соответствия требованиям регуляторов (compliance management) ситуация улучшилась незначительно. До 84% веб-приложений не удовлетворяет требованиям стандарта по защите информации в индустрии платежных карт PCI DSS и 81% не соответствуют критериям ASV-сканирования, определенного в стандарте.
Сравнение результатов с отчетами предыдущих четырех лет показал, что ситуация со степенью защищенности веб-приложений в 2009 в целом улучшилась. Так, анализ устранения уязвимостей на 768 сайтах проверявшихся в 2008 и 2009 году показал, что более 60 процентов владельцев устранили все критичные уязвимости в течение года и существенно повысили защищенность своих ресурсах. В целом регулярный анализ защищенности веб-приложений и налаженный процесс устранения выявленных недостатков позволяют за год уменьшить число уязвимых сайтов в среднем втрое.


Ссылки: pdf html

вторник, 9 марта 2010 г.

Verizon опубликовал Verizon Incident Metrics Framework

Итересную новость опубликовал Verizon. В ответ на критику Data Breach Investigations Report был подготовлен опросник для обмена данными об инцидентах. Полезный документ, думаю, что компаниям, работающим в этой области стоит взять на вооружение.

Что приятного - в качестве классификации Web используется WASC WATCv2. Дополнительно - Verizon "вернул" группировку атак и уязвимостей по классам, чего мне очень не хватало во второй версии:

  • Authentication 
  • Authorization 
  • Command Execution/Injection
  • Abuse of Functionality
  • Denial of Service
  • Client-side 
  • Encryption 
  • Protocol Manipulation
  • Miscellaneous



понедельник, 25 января 2010 г.

Иногда автоматизация вредна...

Широко прогремела в новостях статистика паролей пользователей RockYou от компании Imperva. Не смотря, на то, что анализ этого инцидента был опубликован Дмитрием Евтеевым около месяца назад, аккурат перед новым годом, юмор ситуации не в том.

Данные, предоставленные Imperva - немного расходятся с действительностью. И не потому, что они где-то просчитались. Просто какой-то из продуктов, используемый для форматирования документа, заменил "неправильный" password на "правильный" Password и далее по всем "словарным" паролям.

Анекдотс.

понедельник, 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 - сравнение различных методик . Вот он, свободный демократический мир :)

понедельник, 22 июня 2009 г.

Secret, Sex, Love, God? Нет, 1234567!

Опубликован подготовленный Дмитрием Евтеевым обзор наиболее распостраненных нарушений парольной политики в российских компаниях.
Как показано в публикации, статистика используемых паролей российских пользователей значительно отличается от данных западных исследований. Так, список наиболее распространенных паролей включает только фразы, составленные из расположенных рядом символов, таких как 1234567 и qwerty, тогда как западные пользователь больше склонны использовать слова английского языка (password, love и т.д.). Более 50% используемых паролей состоят только из цифр, что крайне негативно сказывается на их стойкости.
Требования PCI DSS нарушаются в 74 случаях из 100, а администраторы более склонны к использованию пустых паролей чем обычные пользователи.

Полный текст исследования:
http://www.ptsecurity.ru/download/PT-Metrics-Passwords-2009.pdf

Другие исследования Positive Technologies:
http://www.ptsecurity.ru/analytics.asp

воскресенье, 24 мая 2009 г.

Отчет о PCI Moscow

В четверг закончилась конференция PCI Moscow. Не смотря на узкую специфику мероприятие оказалось достаточно интересным и хорошо организованным.
Из запомнившихся докладов:

"Безопасность банкоматов. Опыт борьбы с кибер-преступниками."
Иван Стригин, Системный инженер, Московское представительство компании «Диболд, Инк»



"Стандарты PCI DSS и СТО БР ИББС 1.0. Сходства и отличия"
Павел Гениевский, Секретарь Совета Сообщества ABISS


Иван раскрыл timeline "борьбы" со злобным вирусом, занимавшимся кражей данных пластиковых карт из банкоматов. И выразил неодобрение отсутствием координации разглашения со стороны антивирусных вендоров. Теперь не только исследователи уязвимостей стоят на тонком льду Full-Disclosure :)). Что хуже - антивирусных вендоров подталкивает мощная маркетинговая машина.

Организаторы обещают опубликовать материалы и презентации на сайте в течении недели.

Мой доклад - "Измеряя защищенность. Метрики безопасности для PCI DSS" ниже.


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

PCI Moscow - Обеспечивая безопасность данных платежных карт в России


21 мая пригласили поучаствовать в "франшизе" международной конференции по безопасности платежных карт PCI Moscow

http://www.pci-portal.com/lang-ru/events/event-info/pcimoscow/agenda

Доклад будет посвящен метрикам безопасности в контексте PCI DSS. Планирую поделиться нашими наработками в этой области и международным передовым опытом. Тезисы ниже:

Измеряя защищенность. Метрики безопасности для PCI DSS


Цикл практических работ по обеспечению соответствия PCI DSS кроме ежегодных аудитов включает ежеквартальное сканирование периметра сети, анализ защищенности Web-приложений и тесты на проникновение. В ходе этих работ, как правило, обнаруживаются уязвимости различной степени риска, приводящие к несоответствию стандарту. Многие из этих проблем требуют серьезных затрат для полного устранения и их полное искоренение может занять не один год. Какие типы уязвимостей наиболее распространены? Какова вероятность обнаружения той или иной проблемы? Какие компенсационные меры наиболее адекватны? Как продемонстрировать прогресс в обеспечении соответствия стандарту?


PS. Как ни печально, практически не слышал интересных выступлений на тему PCI. Все в основном сводится к "пугалам", или пересказу основных требований стандарта. Хотя есть и редкие исключения. Например, доклад Максима Эмма по наиболее распространенным нарушением.

четверг, 23 апреля 2009 г.

понедельник, 20 апреля 2009 г.

Microsoft SIR. Россия в лидерах!

Microsoft опубликовала очередной отчет Security Intelligence Report.

Россия среди лидеров по проценту зараженных компьютеров:



У нас метрика заражений на 1000 запусков "чистилки" составляет 21,1, тогда как среднемировой показател 8,6.
Очень странный показатель.

Возможно он плотно связан с вероятностью заражения различных платформ:



Думаю, ни кто не будет удивлен, что у большинства домашних пользователей стоит XP SP0, SP1, который "боятся" обновлять, чтобы не "слетела" крякнутая активация. Хотя тогда откуда у них Malicious Software Removal Tool? Не на дискете же "мастер" принес? Скорее уж что-то от Касперского или DrWeb.

Странно все это. Неужели корпоративщики?

PS. Вообще - удивительный отчет.

В России наиболее распостраненная угроза - Taterf, распространяющийся через общие папки, в USA - Win32/Renos и Win32/Zlob. Про Conficker написано очень много, но первых строчках статистики он отсутствует.

Чудеса?

воскресенье, 19 апреля 2009 г.

РИФ+КИБ 2009

Пригласили сделать обзор Web-угроз на РИФ'е.
Планирую "зарелизить" 0-day, свежую статистику WASC (http://www.webappsec.org/projects/statistics/) за 2009 год. Официальный релиз планируется на первую декаду мая.

http://ok2009.ru/program/?type=group&gid=22.17001900&id=230

четверг, 19 февраля 2009 г.

Сложно ли взломать сайт?

Как показывает наша статистика - квалифицированный человек сделает это с вероятностью 0,8...




Именно такова вероятность обнаружения уязвимостей высокой степени риска в ходе наших работ. Даже самому страшно.

Отрелизили статистику безопасности Web-приложений за 2008 год.

Это уже третий релиз:

2008
2007
2006

В этом году в качестве исходных данных использовались результаты анализа 59 Web-приложений различными жестокими методами от fuzzing до dynamic source code analysis и более чем 10000 сайтов, расположенных на Хостинг-Центре РБК, которому мы (и MaxPatrol) помогаем оказывать услугу "Проверка Безопасности Сайта".

В первый раз в статистику вошли данные по обнаруженным последствиям "взлома", т.е. по тем сайтам, на которых MaxPatrol обнаружил вредоносный код, php-shell и т.п.


В этом году обнаружилась еще одна интересная аномалия. Это нереально большое количество SQLi (обнаружено в 68% всех сайтов при детальном анализе). Просто прорыв какой-то...



Вот такие жестокие цифры...

понедельник, 26 января 2009 г.

Риски, риски, риски...

Недавно, в ходе работ по анализу защищенности наткнулись на уязвимость Web-интерфейса управления одним UTM-устройством. Достаточно типичное сочетание CSRF и XSS примечательно тем, что через Web-интерфейс позволяет получить доступ к коммандной строке устройства и интерактивно "рулить" системой в браузере администратора. Но не суть, уязвимость типичная.
Интересное началось, как обычно на этапе взаимодействия с вендором. Мы не сошлись в степени риска, связанной с этой уязвимостью, что привело к ожесточенной переписке. В связи с этим, хотелось бы поделится своими наработками в данном направлении.
Как правило, степень риска присваивается уязвимости производителем системы, в которой изъян был обнаружен, либо компанией, выпускающей средства защиты (сканеры уязвимостей, системы обнаружения атак и т. д.). В этом случае используется привычная по правилам дорожного движения схема: низкая степень риска (зеленый), средняя степень риска (желтый), высокая степень риска (красный). Иногда выделяется дополнительный, четвертый уровень риска — критические уязвимости.
Такого подхода придерживаются многие производители, например, Microsoft в своих уведомлениях об обновлениях программного обеспечения использует четыре уровня критичности уязвимостей.
Однако, "светофорная модель" весьма непрозрачна и очень зависит от мировозрения и самочувствия эксперта и других факторов. В связи с этим мы широко используем в своей работе методику CVSSv2.
http://www.securitylab.ru/analytics/355336.php
http://www.securitylab.ru/analytics/356476.php

Достаточно простые метрики, заложенные в CVSSv2 позволяют более или менее однозначно оценить риск. Более того, метрики позволяют оценивать и различные дополнительные факторы, такие как вероятность эксплуатации и среду. Что очень важно.
Цитирую:

Не касаясь достоинств или недостатков каждого из методов можно выделить следующие особенности, которые могут влиять на достоверность оценки:

  1. зависимость от контекста;
  2. зависимость от конфигурации системы;
  3. зависимость от метода определения.

В различных приложениях уязвимости одного типа могут иметь различную степень риска. Так, уязвимость «Подделка 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".

Вот такая она разная, оценка рисков.

четверг, 18 декабря 2008 г.

Анализ рисков. Web-приложения

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

Статья Оценка рисков использования Web-приложений касается этой проблемы в контексте Web-приложений.
Полагаю, что собранные в ней данные и источники будут полезны для широкого круго специалистов.

среда, 29 октября 2008 г.

Метрики безопасности. Infosecurity 2008

Сейчас плотно занимаюсь метриками безопасности в контексте развития MaxPatrol. В связи с этим делал небольшой доклад на Infosecurity Moscow 2008. Формальная тема "Проактивный котроль", но де-факто - доклад о метриках.