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

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

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

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

Чаще всего, обосновывая необходимость внедрения того или иного механизма, заинтересованные лица апеллируют к статистическим исследованиям, проводимым авторитетными организациями. К сожалению, подобные исследования нерепрезентативны, неточны и недостоверны. К примеру, исследование, опубликованное в 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 систем (безусловных лидерах, как по числу уязвимостей, так и по их влиянию на “среднюю температуру”). В нашем случае искомая вероятность будет существенно ниже.

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