27.02.2009

Когда глобальный червь поразит все наши маршрутизаторы?

image

В этой статье будет описан метод определения вероятности наличия уязвимостей в программном обеспечении.

Дмитрий Кузнецов

Подход к управлению информационной безопасностью, основанный на менеджменте рисков, до сих пор вызывает довольно бурные споры. С одной стороны, находятся люди, заявляющие о своей готовности разработать строгую математическую модель рисков отдельно взятой компании. Их наиболее радикальные оппоненты заявляют о полной несостоятельности такого подхода к управлению информационной безопасностью. Нужно заметить, что у обеих сторон есть разумные доводы.

Пытаясь оценить риски информационной безопасности, мы регулярно сталкиваемся с одной и той же проблемой: нужно дать какие-то априорные оценки событию, которое мы, строго говоря, ни разу не наблюдали, и которое, хочется надеяться, нам наблюдать не придется. В самой примитивной математической модели величина риска, связанного с определенной угрозой в отношении определенного актива, - это величина потенциального ущерба от реализации угрозы, умноженная на вероятность реализации угрозы. И численная оценка риска (хоть количественная, хоть качественная) упирается в невозможность оценить эту вероятность. Действительно, на момент оценки риска нам еще ни разу не приходилось наблюдать реализацию угрозы, так что для эмпирической оценки нам банально не хватает статистических данных.

Чаще всего, обосновывая необходимость внедрения того или иного механизма, заинтересованные лица апеллируют к статистическим исследованиям, проводимым авторитетными организациями. К сожалению, подобные исследования нерепрезентативны, неточны и недостоверны. К примеру, исследование, опубликованное в CSI Survey 2007, основывается на опросе 500 респондентов из одной страны, причем четверть респондентов затруднилась ответить на вопрос, были ли в их компании какие-либо инциденты ИБ. Вряд ли оправданно переносить статистику инцидентов из такого исследования на свою информационную систему.

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

Самый простой пример такой оценки - оценка вероятности невозможного события. Рассмотрим в качестве примера угрозу, вокруг которой разгорелась дискуссия на одном из форумов: "А что, если появится сетевой червь, который выведет из строя все оборудование Cisco?". На первый взгляд, такое событие кажется возможным. С другой стороны, такое событие кажется уж слишком невероятным. А насколько оно невероятно?

В самой примитивной модели событие I={"реализована угроза в отношении некоторого продукта"} можно представить как одновременное происшествие нескольких независимых событий:

  • у нарушителя появился мотив реализовать угрозу (M);
  • в данном продукте есть уязвимость, с помощью которой технически возможно реализовать эту угрозу (V);
  • нарушитель обладает ресурсами (например, квалификацией или финансами для привлечения специалистов), достаточными для реализации угрозы (R).

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

Почему нам так важны именно уязвимости? Причин несколько:

  • Информация об уязвимостях появляется регулярно (последние несколько лет - примерно по 8000 сообщений в год). Всего за 10 лет наблюдений зарегистрировано около 40000 уязвимостей
  • Информация об уязвимостях систематизирована. Каждая уязвимость имеет идентификатор  в каталоге CVE, оценку возможности реализации и оценку возможных последствий (все это можно посмотреть, например, в National Vilnerability Database)
  • Информация об уязвимостях структурирована. В частности, с помощью той же базы NVD легко определить, какие уязвимости относятся к интересующему нас продукту.
  • Уязвимости хорошо описываются вероятностными моделями.

О последнем - чуть подробнее. Если взять А - множество уязвимостей, зафиксированных в какой-то период времени и обладающих определенным признаком (например, уязвимости в ОС),  - и выделить в нем подмножество B уязвимостей, обладающих определенным свойством (например, memory leaks или integer overflows), то соотношение |B|/|A| оказывается примерно одинаковым за разные периоды наблюдения (см. например, таблицу 2 в исследовании ("Vulnerability Type Distributions in CVE"). Примем в качестве предположения, что и распределение прочих свойств наблюдаемых уязвимостей (например, доля уязвимостей, имеющих определенную оценку по CVSS среди наблюдаемых уязвимостей) также одинаково распределены. Так это или нет - сравнительно легко подтвердить (или опровергнуть), пробежавшись по базе CVE, но этим мы займемся в следующий раз.

Попробуем сделать оценку. Пусть X={xi} - множество событий "наблюдаемая уязвимость Vi может использоваться для получения контроля над всеми экземплярами какого-либо IT-продукта", Y={yi} - множество событий "наблюдаемая уязвимость Vi может использоваться для получения контроля над всеми экземплярами маршрутизаторов Cisco c IOS текущей версии". Множество A включает в себя множество B и не совпадает с ним, т.е. . Иными словами, вероятность того, что появится уязвимость, которая позволит вывести из строя все экземпляры данного продукта (например, все маршрутизаторы Cisco) меньше вероятности того, что появится уязвимость, которая позволит вывести из строя все экземпляры какого-либо продукта. Мы располагаем информацией о 40000 уязвимостей  и знаем, что до сих пор ни одна из этих уязвимостей не привела к тотальному поражению ни одного продукта, т.е.

.Понятно, что эта оценка слишком грубая. Даже если в каком-то продукте обнаружится  искомая уязвимость, не факт, что этим продуктом будет именно Cisco IOS. Воспользуемся предположением, сформулированным двумя абзацами выше, причем множеством A будет множество уязвимостей, внесенных  в репозиторий OVAL, а множеством B - те из них, которые относятся к Cisco IOS. На момент написания этого текста в репозитории OVAL содержится информация  о 5528 уязвимостях, эксплуатация которых приводит к получению нарушителем полного контроля над атакуемым узлом, и только 110 из них относятся к продуктам Cisco. В силу сделанного нами предположения

Какова вероятность того, что в 2009 году произойдет рассматриваемая нами угроза, и " глобальный червь поразит все наши маршрутизаторы"? В год регистрируется около 8000 уязвимостей, и вероятность того, что угроза все-таки будет реализована, можно оценить сверху как

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

Заметим, что и это очень грубая оценка:

  • Мы оцениваем сверху вероятность события, которое не фиксировалось ни разу за 10 лет наблюдений. Если оно не произойдет и в следующем году, верхняя  оценка уменьшится, т.е. оцениваемая величина окажется еще ближе к нулю.
  • Мы используем "среднюю температуру по больнице", не учитывая особенности разработки нужного продукта. Скажем, если меры контроля качества, принимаемые компанией-разработчиком, выше чем "среднебольничные", то искомая вероятность оказывается значительно меньшей.
  • Используя "среднебольничные" оценки, мы не учитываем особенности продукта. К примеру, вероятность наличия уязвимости в программном продукте растет с количеством предоставляемых внешнему разработчику функций API. В этом смысле вероятность найти уязвимость в ядре IOS существенно меньше вероятности найти уязвимость в ядрах Windows или Linux систем (безусловных лидерах, как по числу уязвимостей, так и по их влиянию на “среднюю температуру”). В нашем случае искомая вероятность будет существенно ниже.

Разумеется, не стоит относиться к приведенным выше рассуждениям как к научному исследованию. Тем, кто считает, что можно строить серьезные и точные математические модели управления рисками на основе статистики, хочу процитировать слова академика Ю.В. Прохорова (сказанные немножко по другому поводу): “Бесполезно моделировать реальную жизнь статистическими методами – в жизни нет места случайности”. Но, тем не менее, здравый смыл и некоторое количество достоверных и проверяемых статистических данных позволяют использовать методы анализа рисков для обоснования разумных решений.

или введите имя

CAPTCHA
Страницы: 1  2  3  
sunny
27-02-2009 15:03:01
Г-н Малотавр, Если продолжаете упорствовать в своём неведении, потрудились бы дать и ссылку на обсуждение этой наукообразной чуши на bаnkir.ru
0 |
27-02-2009 15:49:12
В той дискуссии я не услышал ничего содержательного (не считать же таким ваше "учебников не читал, лекции прогуливал, но доказал вам, что вы не правы", "моя чуйка мне подсказывает" и "время нас рассудит"). А постоянные страшилки, что завтра-послезавтра нас всех поломают, меня откровенно достали еще года четыре назад, когда я занимался НИРами по скрытым каналам и сам такие страшилки сочинял.
0 |
sunny
27-02-2009 16:03:39
Нет в той теме ничего из того, что вы тут написали, ни про чуйку, ни про время, ни про лекции. Там контрпримеры, расчёты и элементарная логика, больше ничего.
0 |
27-02-2009 16:38:58
Вам напомнить? "Вот вам моё определение вероятности события. (Феллера не читал, не обессудьте. И на пары забивал в ВУЗе.) Вероятность события - это степень уверенности наблюдателя в том, что это событие произойдёт, основанная на понимании наблюдателем сути происходящего." Последний перл достоин занесения в анналы мировой науки. C элементарной логикой и теорией вероятностей у вас, увы, проблемы - где-то примерно на уровне базовых понятий. "Я не золопамятный - я просто злой и память у меня хорошая" ©
0 |
sunny
27-02-2009 16:44:10
Это из другой темы, которая к вашей "работе" отношения не имеет.
0 |
27-02-2009 16:57:19
Милейший, тема вероятности реализации угрозы обсуждалась как минимум в трех топиках Банкира. "Тут играем, тут не играем, а тут мы рыбу заворачивали?" Отрицать авторство цитаты, надеюсь, не будете? Ну не собираюсь я давать ссылки на все эти темы и на ваш "информационный керосин". А приведенная цитата вполне объясняет мое отношение к вам и вашим аргументам
0 |
sunny
27-02-2009 17:10:19
Отрицать авторство фразы не буду, хотя оказалось, что это определение вероятности по Байесу. Аргументы по поводу вашей "работы" приведены в указанной мной теме. В рамках вашей же модели и классического определения вероятности ваши выкладки были приведены к логическому противоречию. Всего хорошего.
0 |
27-02-2009 17:12:38
"...оказалось, что это определение вероятности по Байесу" Именно это я и имел в виду, говоря про проблемы в базовых понятиях
0 |
sunny
03-03-2009 18:16:58
К сожалению, ссылку на обсуждение стёрли модераторы. Ссылку автора в статье при этом оставили. Надеюсь, никого не обижу, написав, что критика статьи находится в теме "Вероятность ненаблюдавшегося инцидента" в форуме "Информационная безопасность" на bankir.ru.
0 |
Dominator
27-02-2009 16:58:13
На тему поражения маршрутизатора вирусом: все зависит от правильно настроенной политики безопасности!
0 |
27-02-2009 17:04:30
Ищо важно, что за маршрутизатор. Если это неправильный Хуавей, с ними понятно, и хуавей то с ним. Можно вероятности посчитать, и даже, наверное дисер защитить... А если, например, правильный маршуртизатор? От лидера? Какие нафиг уязвимости? Выключат из Лэнгли когда надо и все.
0 |
27-02-2009 17:12:16
Коллегу Дмитрия Кузнецова надо забить палками... Нет, я согласен что приведенные цифры приблизительно соответствуют реальности, но ведь я об этом молчу! И в результате моего молчания я и другие "офицеры безопасности" имеют свой хлеб. Понимаете к чему я веду?... )))
0 |
27-02-2009 18:46:53
Я уверен, что коллега Дмитрий Кузнецов в легкую еще на 5 страницах математических выкладок докажет, что расслабляться нельзя, и зарплата "офицера безопасности" ОБЯЗАННА включать не только хлеб, но и масло, и икру (это не считая премиальных и прочих праздничных случаев). Математика - великая сила!
0 |
27-02-2009 20:43:03
Как известно, юрист, прежде, чем зарыться в законы, интересуется - а на чьей он стороне? А математик чем хуже? На мой взгляд, на первом месте должен быть здравый смысл. Если вам убедительно доказывают что-то, противоречащее здравому смыслу - сто пудов обманывают
0 |
27-02-2009 21:31:30
Мастерская подмена понятий "уязвимости" и "атаки"
0 |
28-02-2009 00:22:32
Ни фига. Не знаю, как на практике, а в теории для успешной атаки нужна уязвимость. Если так, то вероятность успешной атаки на узел не выше вероятности найти на этом узле подходящую уязвимость.
0 |
01-03-2009 10:28:06
Вы правы Коллега malotavr (я про сообщение от «28.02.2009 00:22:32»). Риск складывается из угрозы и уязвимости (ну и влияния на нас, хотя это иногда опускают). Если нет уязвимости, то нет риска, и атака не получится. Точнее атака как процесс может реализовываться сколько угодно, но она никогда не достигнет результата. Это как с разбега врезаться в бетонную стену, надеясь, что у нее есть уязвимость. Банальный пример. 1. У Вас стоит сервер ОС Linux. 2. Есть злодей, который очень хочет взломать этот сервер (это угроза). 3. Этот злодей знает, как атаковать с помощью уязвимости присущую только службам ОС Windows. Такой уязвимости нет на нашем сервере Linux (уязвимость нашего сервера = НУЛЮ). 4. Если он будет атаковать сервер Linux неподходящей уязвимостью от Windows, то это не к чему не приведет (Риск = 0). P.S. против лома нет приема. DDoS не делает различий между расовой принадлежностью ваших серверов (я про ОС). С уважением, к присутствующим.
0 |
01-03-2009 22:31:40
Ну предположим, как на практике ты тоже знаешь Припомни пентест какой-нибудь. Там "глобальному червю" таки вполне удалось поразить все их маршрутизаторы. Через вполне банальные уязвимости типа "слабые пароли" и "недостаточная фильтрация трафика". А для чистоты - посчитай какова вероятность того,что "глобальный червь поразит все наши серверы" через уязвимость в службах SMB и RPC Windows ? На моей памяти это 2-3 раза уже случалось, а что скажет наука?
0 |
02-03-2009 10:58:14
На мой взгляд, на первом месте должен быть здравый смысл. Если вам убедительно доказывают что-то, противоречащее здравому смыслу - сто пудов обманывают На мой нескромный взгляд, уважаемый коллега, масло поверх хлеба есть практически Абсолютный Здравый Смысл. Причем, если уж вдаваться в философию, АЗС как со стороны работника, так и со стороны работодателя. Посему, предлагаю считать это исследование "закрытым" и вообще ДСП. А в паблик выложить про хлеб, масло и икру.
0 |
spy.com
28-02-2009 15:58:54
помоему в этих рассуждениях отсутствует такое понятие как "уровень поддержки"... ну или что-то типа этого, не знаю как правильней сформулировать, но если за конкретным объектом наблюдает более-менее грамотный специалист, ограничив доступ в железу(логический и физический), закрыв извне все лишнее и т.д., то вероятность опять же стремится к нулю! ведь уязвимости тоже работают только в спец. условиях.... "если да кабы" С другой стороны, безопасность это процесс! +) так что вероятность все время растет вверх и нужно регулярно принимать действия по её уменьшению... если пустить это дело на самотек, то через пару месяцев вероятнсть приравняется 0.99 ^_^
0 |
Free_Nice
15-05-2009 23:52:59
Про то и говорят Нанимаете спецов Давайте спецам денег И страшое не случится Даешь масло икру хлеб !!!
0 |
02-03-2009 09:52:30
".. статистические методы не подходят в силу несоблюдения закона больших чисел, а экспертные методы еще далеки от совершенства из-за нерациональности поведения человека при решении многокритериальных задач и требуют больших ресурсов .."
0 |
Страницы: 1  2  3