Риски и уязвимость

Цель

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

Цели, которые преследуют атакующие, могут быть очень разными. Мотивом может быть и получение материальной выгоды, и желание продемонстрировать свою «крутость», и месть. Более того, нападающему не обязательно получать прямую выгоду от взлома, он может быть заинтересован другим человеком. Возможна целая цепочка таких заинтересованностей, и в каждом ее звене свою роль будут играть совершенно разные мотивы. Конечно, чем длиннее подобная цепочка, тем сложнее ее построить.

В любом случае, потенциальный нарушитель оценивает все выгоды, которые он получит в случае успешного завершения атаки. На другой чаше весов — затраты и риски:

• затраты, которые он должен понести при осуществлении атаки;
• вероятность, что атака не достигнет цели, несмотря на все старания и расходы;
• вероятность быть пойманным;
• серьезность последствий в случае поимки.

Важно понимать, что взвешиваются исключительно субъективные оценки перечисленных параметров. Так школьники, воруя пароли и используя их для доступа в интернет, часто не осознают, что совершают преступление. Для них это просто продолжение игры, и открытое уголовное дело воспринимается ими как большой сюрприз. Если бы они заранее понимали, какому риску подвергаются, многие отказались бы от своих действий.

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

Не очень однозначна и оценка соотношение выгода/затраты.

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

С другой стороны, если потенциальный нарушитель изначально переоценивает защищенность системы, это может предотвратить попытки взлома.

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

Естественно, в этом случае потенциальный нарушитель будет атаковать ту цель, которая, по его мнению, защищена менее остальных. Поэтому ощутимое превышение защищенности нашей системы над подобными ей, уже существенно снизит ее привлекательность. Следовательно, мы можем существенно снизить вероятность атаки, сохранив при этом стоимость защиты минимальной. Для этого достаточно сделать нашу систему «немного сильнее», чем в среднем.

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

С другой стороны, может оказаться, что некий ресурс не представляет для нас никакой ценности, но может быть интересен нападающему. Надо ли его защищать? Я думаю, да. И мы должны подумать при этом, как использовать этот ресурс для получения прибыли. Хорошим примером здесь может служить интернет-магазин amazon.com, вычислительные ресурсы которого простаивали между периодами активных покупок. Теперь эта компания продает облачный сервис. Всем этот пример очень хорошо известен.

Итак, число попыток преодолеть нашу защиту определяется числом заинтересованных людей. Людей, которые оценивают свой интерес в осуществлении взлома выше, чем необходимые для его осуществления затраты и свои риски. Это количество можно примерно оценить. Для каждой компании, конечно, оно будет своим. И зависит оно только от субъективных оценок потенциальных нарушителей, не от реальной защищенности.

Количество же удавшихся взломов будет определяться соотношением имеющихся у атакующего ресурсов и защищенности нашей системы.

Доступность

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

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

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

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

С другой стороны, чтобы использовать ошибку в программе, исполняющейся с повышенными привилегиями (например, suid программы в Un*x), может оказаться необходимым иметь локальный доступ к системе и быть зарегистрированным пользователем. Имеющих такой доступ людей меньше по количеству, и мы знаем их. По крайней мере, мы знаем их лучше, чем любого анонимного пользователя. Мы можем отслеживать действия этих людей и сопоставлять с событиями в нашей системе (конечно, такая функциональность должна быть предусмотрена в системе). Атакующий в этом случае рискует быть обнаруженным и наказанным. Больше риска для нападающего — меньше его мотивация, меньше наши риски.

Конечно, говоря о каналах доступа, мы должны помнить не только «штатные» каналы, как, например, клавиатура и монитор. Мы должны понимать, что существуют способы взаимодействия с нашими компьютерами, которые не рассматривались при их разработке. Вспомним уже упоминавшееся прослушивание электромагнитного излучения компьютера. Физическое снятие носителя и прямое его чтение — тоже пример канала доступа к информационной системе. Продажа компании своего программного обеспечения — пример еще одного канала доступа в информационную систему, в которой программное обеспечение будет установлено.

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

Оборудование

Для проведения любой атаки необходимо то или иное оборудование. Как минимум, атакующий должен использовать технические устройства для доступа к информационной системе: люди не умеют взаимодействовать с компьютером напрямую. Кроме того, некоторые атаки по своей природе могут потребовать задействования некоторого дополнительного оборудования. Так для проведения успешной DDOS атаки злоумышленник должен иметь возможность управлять большим количеством компьютеров, подключенных к интернету. Для взлома криптографической защиты может понадобиться провести сложные вычисления.

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

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

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

Знания и умения

Знания и умения являются одним из важнейших ресурсов, необходимых для успешного преодоления средств защиты.

При проведении атаки, нападающему необходимо последовательно решить три задачи:

• собрать информацию о нашей системе;
• обнаружить уязвимости;
• провести атаку — воспользоваться найденными уязвимостями.

Иногда к этим трем шагам добавляется еще один: уничтожение следов проникновения.

Как сбор информации, так и обнаружение уязвимостей атакующий может производить полностью без контакта с нашей системой. Он может воспользоваться имеющейся документацией (руководства пользователя, администратора, разработчика), он может сделать у себя стенд и на нем проверять свои предположения. Таким образом, эти фазы нападения будут от нас скрыты.

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

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

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

Нарушители низкого уровня могут находить и использовать известные уязвимости. Это самая простая задача: необходимо выяснить версию программного обеспечения и сопоставить со списком уязвимостей. Еще более простой вариант поведения подобных противников: предположить, что используется определенное программное обеспечение и попытаться воспользоваться имеющимися в нем ошибками. Если предположение верно — атака будет успешной, если нет — атакующий ничего не получит. Несмотря на свою примитивность, такое поведение позволяет находить и атаковать уязвимые системы. При этом от атакующего требуется только запустить у себя на компьютере скачанную из интернета программу. Следы именно такого поведения мне каждый день приходится видеть в протоколах моего веб сайта.

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

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

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

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

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

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

И, наконец, нарушители высокого уровня могут находить новые, не известные до сих пор методы атак на информационные системы. Они открывают возможности атаковать программы, до этого признаваемые всеми специалистами, как безопасные, не содержащие уязвимостей. Таких людей не очень много. Сами они, возможно, не будут участвовать в нападении. Но именно благодаря им мы знаем все современные способы атаковать информационные системы. Всё: и подборы пароля, и переполнение буфера, все социальные атаки — все это результат их работы.

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

Но я думаю, между этими группами существовало бы значительное пересечение. Действительно, противник, который располагает финансовыми ресурсам, может нанять специалиста, обладающего необходимыми знаниями. С другой стороны, квалифицированный специалист имеет множество возможностей зарабатывать деньги, причем не только за счет взлома информационных систем. У него есть возможность выбора путей зарабатывания денег, и, если он занимается атакой на какую-то информационную систему, значит, дело стоит его усилий. А значит, это привлечет и «инвестиции».

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

Внедрение уязвимостей

Здесь я хочу сделать небольшое отступление и поговорить об очень специфическом канале доступа к информационной системе: о поставке программного обеспечения.

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

Я даже не буду здесь обсуждать возможность предложить жертве «решение» ее задачи на каком-нибудь форуме системных администраторов. Это один из мощнейших способов обхода средств защиты.

Давайте обсудим возможность существования «закладок» во вполне солидных продуктах. Внедрить уязвимость в такой продукт по силам даже нарушителю среднего уровня. Например, программист может «сделать ошибку» в программном обеспечении, за разработку которого он отвечает. Если он более или менее хороший программист, понимающий процесс разработки своей компании, то обнаружить эту «ошибку» будет достаточно сложно. Еще сложнее будет доказать, что уязвимость была внедрена намеренно. Более того, при правильном подходе программист может избежать даже подозрений в злоупотреблении своими возможностями.

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

Очевидно, противники высокого уровня (включая спецслужбы) обладают еще большими возможностями. Они обладают и опытом, и ресурсами для вербовки специалистов. И это дает им огромное преимущество. Более того, такие противники могут создавать уязвимости нового типа, обнаружение которых при обычном коммерческом процессе разработки практически невозможно.

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

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

Так мне приходилось слышать мнение, что слабости шифрования трафика в GSM и в первых версиях Wi-Fi были связаны с желанием спецслужб сохранить возможность перехвата передающейся информации. Впрочем, надо признать, что эти уязвимости вполне могут быть связаны и с простым желанием коммерческих разработчиков сделать защиту как можно более простой и дешевой.

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

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

И я хочу еще раз напомнить: поставка программного обеспечения — мощный канал доступа к информационной системе. Всегда думайте, кому вы его предоставляете.

Время

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

Учет времи, необходимого для проведения атаки важен по нескольким причинам.

Первая причина: существует большое количество данных, которые очень быстро устаревают. Если эти данные защищены настолько, что атакующий может получить к ним необходимый доступ, но затратит на это слишком много времени, для него этот «успех» окажется абсолютно бесполезным.

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

Поэтому при разработке систем, в которых обрабатывается быстро устаревающая информация, нам не обязательно использовать очень сильные механизмы защиты.

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

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

Таким образом, время «жизни» информации, которая будет обрабатываться в проектируемой системе, напрямую отражается на требованиях к ее защищенности.

Вторая причина важности времени проведения атаки: «окно» доступности атакуемой системы. Например, пусть в мобильном телефоне присутствует уязвимость. И, благодаря этой уязвимости, телефон может быть атакован через соединение по Bluetooth. Если атака длится доли секунд, взломщик сможет атаковать всех людей, которых он встретит на улице. В случае же, если атака займет часы, это становится невозможным.

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

Посмотрим теперь, на что тратит свое время атакующий. Это время, можно разделить на две категории: «пассивное» и «активное».

Расходую «пассивное» время, атакующий создает условия для нарушения защиты, и пассивно ожидает события, которое приведет к реализации его плана. Например, разместив на одном из веб сайтов троянского коня, атакующий может спокойно ожидать, когда целевой пользователь его задействует. Другой пример «пассивного» времени: атакующий ждет, когда кто-нибудь откроет уязвимость в нашей системе.

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

«Активное» время, с другой стороны, это время, в течение которого атакующий вынужден совершать какие-либо действия, задействовать имеющиеся у него ресурсы. Например, проведение криптографического анализа, скорее всего, потребует использования имеющихся у нападающего вычислительных ресурсов. Анализ программы с целью обнаружения в ней уязвимостей — еще один пример такого расходования времени.

В отличие от «пассивного», «активное» время может серьезно зависеть от имеющихся у нарушителя ресурсов.

Таким образом, мы видим, что время является не менее, а то и более важным ресурсом, по сравнению со всеми остальными. Мы можем уменьшить наши риски двумя способами: уменьшить «окно доступности» нашей информационной системы, или/и увеличить время, необходимое для проведения атаки.

Инфляция ресурсов атакующего

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

Не является исключением и область защиты информации.

Современные вычислительные системы дают новые мощные средства для атаки. Мой мобильный телефон предоставляет мне больше вычислительных ресурсов, чем мэйнфрейм, которым я пользовался, будучи студентом университета. Чтобы атаковать тот мэйнфрейм, нарушителю надо было зайти на территорию университета, в компьютерную комнату. Атаковать мой мобильный телефон может практически любой пользователь интернета.

О развитии средств вычислительной и телекоммуникационной техники говориться многое. Даже сформулирован широко известный эмпирический «закон Мура». О совершенствовании методов обхода средств защиты говориться немного меньше.

Когда новый программный продукт только-только выходит на рынок, никто толком не знает его особенностей, для всех он пока «terra incognita». В программе могут существовать очень серьезные уязвимости, но о них некоторое время ничего не будет известно. Продукт в этот период может быть очень безопасным, никто не будет знать, как его атаковать.

По мере знакомства, к новой программе будут «примеряться» известные типы уязвимостей (то есть, его будут изучать противники среднего уровня). Через какое-то время уязвимости будут обнаружены. Как скоро это случится, кто будет автором этого открытия, зависит от очень многих причин, в число которых входит и степень интереса взломщиков к этому продукту, и качество его разработки.

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

Другие продукты могут быть взломаны только специалистами, которых уже можно частично отнести к высокому уровню (мы помним, что граница между уровнями специалистов не очень четкая). Их мало, и занимаются они только достаточно привлекательными задачами. Поэтому такие продукты могут оставаться «неуязвимыми» очень долго.

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

Но открывший уязвимость может передать ее тому, кто заинтересован в атаке на наши системы. Тогда мы, возможно, узнаем о существовании ошибки, занимаясь «разбором полетов» по факту произошедшего нарушения. Может так случиться, что мы будем долго находиться в счастливом неведении об успешной атаке нашей системы.

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

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

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

Аналогично развивается и знание о новых типах уязвимостей.

Когда возникает новая технология, изначально никто не знает ее проблемы: ее принципиальные слабости, возможности разработчику сделать ошибку. Здесь в игру вступают высококвалифицированные специалисты, которых, конечно, имеет смысл отнести к противникам высокого уровня. Дальше эти данные живут почти той же жизнью, что и информация о конкретной ошибке: открывается новый тип уязвимостей, постепенно эта информация распространяется. Сразу после открытия новый тип уязвимости понятен только ограниченному кругу высококлассных специалистов. По мере изучения, новый тип уязвимости становится привычным и доступным уже менее квалифицированным взломщикам. Естественно, информация о типе уязвимостей ничего не даст противнику низкого уровня. Хотя, разобравшись в ней, он делает шаг для перехода на следующий уровень.

Распространению информации о новом типе уязвимости препятствует не только необходимость иметь высокую квалификацию. Может оказаться, что новые способы атаки будут открыты в группе людей, которые будут использовать эти знания для достижения своих целей. Тогда эта группа будет очень сильно заинтересована в сохранении информации о таких уязвимостях в тайне. Так есть основания полагать, что «format string vulnerability» были известны в узких кругах профессиональных взломщиков за много лет до того, как информация о них распространилась среди большинства специалистов.

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

Большая Игра

Итак, мы знаем, что ресурсы атакующего возрастают со временем. В частности, в программах открываются новые уязвимости. Открываются, они, конечно, не сами по себе. Есть люди, которые заинтересованы в этих открытиях. В свою очередь, пользователи программного обеспечения заинтересованы в соответствующем усилении защиты, в устранении найденных уязвимостей. Под их давлением(!) разработчики вносят улучшения в свои продукты. Таким образом, в этой области идет своя Большая Игра.

Давайте обсудим эту игру, конечно, существенно упрощая.

В нашей Большой Игре участвуют четыре стороны: Разработчик, Пользователь, Белая Шляпа, Черная Шляпа.

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

Но вернемся к нашим героям.

Разработчик создает программные продукты, которые приобретает Пользователь. Разработчик заинтересован в том, чтобы произвести продукт и его продать. Произвести как можно дешевле и быстрее (time-to-market!) — продать как можно дороже. С другой стороны, в большинстве случаев разработчик заинтересован и в том, чтобы продолжать в дальнейшем продавать новые продукты, обновления существующего, поэтому ему важна и его репутация. Перед разработчиком стоит очень сложная задача. Ему надо найти баланс между снижением затрат на выпуск продукта и его качеством. Качеством, включающим безопасность.

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

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

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

Белая Шляпа по каким-то своим причинам заинтересован в публикации информации о найденных уязвимостях. Чаще всего это не прямая материальная заинтересованность, а вопрос престижа. Поэтому Белая Шляпа заинтересован в широком распространении этой информации, от него об уязвимостях узнают и Разработчики, и Пользователи, и Черные Шляпы.

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

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

Мы, будучи Пользователями, до определенной степени можем влиять на Разработчика, предъявляя требования к программным продуктам и голосуя своими деньгами. При этом надо, однако, помнить, что безопасность, наличие или отсутствие ошибок в программном обеспечении — только одна из его характеристик, часто не самая важная.

Таким образом, динамика знаний об ошибках в той или иной программе зависит от баланса интересов двух сторон. С одной стороны — от интереса Белых Шляп и Черных Шляп к поиску уязвимостей. Чем выше этот интерес, тем быстрее открываются новые уязвимости. С другой стороны эта динамика зависит от заинтересованности Разработчика создать качественную программу и устранять открывающиеся уязвимости. Я, в процессе написания этой статьи, некоторое время думал, а от чего больше зависит качество программы: от способности разработчика делать качественный продукт, или от его заинтересованности в этом. Думаю, что сейчас у разработчика есть все возможности создавать качественные программы, вопрос в его желании.

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

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

DREAD

Конечной задачей оценки серьезности уязвимости по методике DREAD является присвоение каждой уязвимости одного числа, условного рейтинга. Методика является качественной. Поэтому шкала чисел может выбираться произвольно, исходя из соображений удобства. Например, это может быть диапазон чисел от 1 до 10. Самая серьезная уязвимость должна получить рейтинг 10, самая малозначимая — 1. Ошибки, получившие наибольшие баллы, должны исправляться в первую очередь.

Рейтинг уязвимость рассчитывается, как средняя оценка по пяти критериям.

Damage potential.

Этот показатель оценивает возможный ущерб, который возможен вследствие злоупотребления данной уязвимостью. Критерии могут быть использованы различные. С одной стороны, мы можем заложить в эту оценку те потери, которые в нашей формуле риска обозначены, как $L_i$, то есть, оценку материального ущерба. С другой стороны, мы можем учитывать и косвенный ущерб, который может повлечь за собой удавшаяся атака. Например, пусть уязвимость позволяет получить администраторские привилегии. Повышение привилегий само по себе не наносит ущерба, но может позволить атакующему обойти множество защитных механизмов. Поэтому такой уязвимости (согласно DREAD) стоит присвоить высокую оценку потенциального ущерба.

Reproducibility.

С помощью этого показателя оценивается вероятность успеха атаки, использующей оцениваемую уязвимость. Напомню, успех многих атак зависит не только от действий нападающего, но и от ситуации, складывающейся в системе: от последовательности запуска процессов, от последовательности передачи пакетов по сети. То есть, некоторые атаки будут достигать своей цели не всегда, а с определенной вероятностью. Максимальное значение этого показателя будет присваиваться тем уязвимостям, которые гарантируют успешную атаку.

Exploitability.

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

Affected Users.

С помощью этого показателя оценивается количество пользователей, использующих уязвимый продукт. При этом учитывается и то, при каких конфигурациях программа является уязвимой. Так, например, ошибка может проявляться при установке системы «по умолчанию», тогда почти все пользователи этого приложения пострадают. Другая уязвимость будет проявляться только в редко используемой конфигурации, тогда от такой ошибки пострадает не очень много пользователей. Согласно методике DREAD ошибки, затрагивающие интерес большего количества людей, получают большую оценку серьезности.

Discoverability.

Здесь специалисты из Microsoft, разрабатывавшие данную методику исходят из предположения, что они знают больше уязвимостей своих систем, чем потенциальные нарушители. Этим показателем мы должны оценивать, насколько открытую нами уязвимость будет сложнее открыть другим исследователям.

Можно заметить, что в DREAD используется небольшое число показателей, и очень простая формула для получения общего показателя (напомню, простое их усреднение). Таким образом, DREAD — простая, но как мы увидим в дальнейшем, достаточно эффективная методика оценки уязвимостей.

Common Vulnerability Scoring System

Методика Common Vulnerability Scoring System, CVSS, была разработана группой специалистов из разных организаций. Независимость методики от какой-то одной компании сделали ее более привлекательной для использования всеми заинтересованными сторонами. Как это часто бывает при создании стандарта консорциумом, результат оказывается сложнее аналогов, созданных одной компанией. И CVSS оказывается более сложным, по сравнению с DREAD.

Как и в DREAD, в этой методике уязвимость сначала оценивается по отдельным критериям. Затем, на основании полученных оценок вычисляется общий показатель.

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

Все критерии в CVSS отнесены к одной из трех групп.

В первую, базовую группу (Base Metrics), входят стабильные показатели. Их значения практически не меняются со временем и не зависят от окружения, в котором работает оцениваемый продукт.

Access Vector (AV).

Значение этого показателя определяется доступом, который должен иметь атакующий для использования уязвимости. Самый высокий рейтинг получают уязвимости, злоупотребить которыми может удаленный пользователь. Самый низкий — уязвимости, для использования которых необходим локальный доступ.

Access Complexity (AC).

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

Authentication (Au).

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

Confidentiality Impact (C), Integrity Impact (I), Availability Impact (A).

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

Во вторую группу (Temporal Metrics) входят показатели, значение которых может меняться со временем.

Exploitability (E).

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

Remediation Level (RL).

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

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

Report Confidence (RC).

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

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

Collateral Damage Potential (CDP).

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

Target Distribution (TD).

С помощью этого показателя учитывается доля уязвимых систем среди всех установленных. В большой степени этот показатель подобен показателю Affected Users из методики DREAD. Однако, разница существует. Affected Users оценивает пользователей «вообще», по всему миру. Target Distribution оценивается для конкретной локальной системы.

Security Requirements (CR, IR, AR).

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

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

Важной особенностью CVSS является то, что все описанные показатели публикуются вместе с итоговой оценкой. Таким образом, если конечному потребителю этой информации по каким-либо причинам не нравится формула вычисления этой оценки, он может придумать свою.

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

Как мы видим, CVSS в отличие от DREAD является достаточно сложной методикой, при разработке которой постарались учесть все возможные ее использования. Делает ли это ее более приемлемой? Не знаю. Но именно показатели CVSS широко публикуются. И это хорошее основание для ее использования при оценке защищенности, если вы в своей системе используете программное обеспечение сторонних разработчиков.

Сопоставление DREAD и CVSS с оценкой ожидаемых потерь

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

Думаю, что сделать точное, верное во всех случаях сопоставление здесь невозможно. Но я постарался обозначить некоторые общие зависимости.

DREAD

	Потери при инциденте	Количество потенциальных нарушителей	Знают уязвимости системы	Умеют использовать уязвимости	Имеют необходимое оборудование	Располагают временем	Имеют доступ
Damage Potential	✓
Reproducibility						✓
Exploitability				✓	✓
Affected Users		✓					✓
Discoverability			✓

Показатель «Damage Potential», очевидно, соответствует оценке возможных потерь при инциденте. Заметим, что при этом не учитывается ценность защищаемого ресурса. Эта ценность зависит от конкретного использования программы. В DREAD же оценивается только степень ущерба как доли ценности.

Показатель «Reproducibility» напрямую влияет на количество попыток взлома, которые необходимо произвести до того, как сработает правильно примененный метод. Поэтому этот показатель можно сопоставить оценке времени, необходимого для проведения атаки.

Показатель «Exploitability» является оценкой сложности проведения атаки. Поэтому в разных ситуациях его можно сопоставить как со знанием методов атаки, так и с требованием использования специального оборудования, наличия материальных ресурсов.

Показатель «Affected Users» я сопоставил с показателями «количество потенциальных нарушителей» и «имеют доступ». Моя логика здесь такова: больше развернутых систем — большее число тех, кто хочет взломать одну из них и большее число потенциальных нарушителей, имеющих к ним доступ.

Ну и, наконец, показатель «Discoverability» я сопоставил с числом тех нападающих, которым известно о существовании уязвимости в данной системе.

Таким образом, несмотря на свою относительную простоту, показатель DREAD очень хорошо соответствует нашей модели ожидаемых потерь. Поэтому его можно рекомендовать разработчикам.

CVSS

	Потери при инциденте	Количество потенциальных нарушителей	Знают уязвимости системы	Умеют использовать уязвимости	Имеют необходимое оборудование	Располагают временем	Имеют доступ
Access Vector							✓
Access Complexity				✓	✓
Authentication				✓			✓
Impact	✓
Exploitability				✓	✓
Remediation Level
Report Confidence
Collateral Damage Potential	✓
Target Distribution		✓					✓
Security Requirements	✓

В этой таблице я объединил для краткости показатели Confidentiality Impact, Integrity Impact, Availability Impact в одну строку «Impact». Аналогично получена строка «Security Requirements».

Показатели «Impact», «Collateral Damage Potential» и «Security Requirements» сопоставляются возможным потерям при инциденте. При этом стоит еще раз отметить наличие зависящих от окружения параметров. С их помощью оценивается ценность защищаемых ресурсов. Это позволяет более точно оценить влияние уязвимости на безопасность конкретной системы.

Показатель «Target Distribution» коррелирует с «количеством потенциальных нарушителей» и с «количеством имеющих доступ». Логика здесь такая же, как я использовал в случае «Affected Users» в DREAD. Имеет смысл только помнить про локальность показателя Target Distribution

Показатели «Access Complexity» и «Exploitability» сопоставляются с количеством пользователей, умеющих использовать данную уязвимость и с количеством пользователей, имеющих необходимое оборудование.

Показатель «Access Vector», очевидно, сопоставляется с количеством пользователей имеющих необходимый для атаки доступ.

В некоторой степени, с этим количеством сопоставляется и показатель «Authentication». Требование аутентификации до того, как атакующий сможет воспользоваться уязвимостью, очевидно, сокращает число потенциальных нарушителей. С другой стороны, этот же показатель может коррелировать и со сложностью метода использования уязвимости. Это утверждение можно обосновать тем, что аутентификация требует выполнения дополнительных действий, даже если необходимые данные у атакующего имеются. О том, что такую зависимость имели в виду авторы CVSS, говорит и тот факт, что повторная аутентификация считается усложняющим фактором, даже в случае, когда используется одинаковая информация.

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

С другой стороны, показатели «Remediation Level» и «Report Confidence» не коррелируют, на мой взгляд, ни с одним из факторов, влияющих на потери. Как я уже отмечал, они, скорее, служат для организации процесса управления уязвимостями.

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

Профиль уязвимости

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

Так мы можем говорить, что нападающие могут пройти внутрь через ворота. Для этого им понадобится таран и несколько человек, которые будут этим тараном работать. Им понадобится 30 минут, чтобы ворота сломать. За это время защитники крепости смогут их обстреливать из луков, кидать на головы камни, лить кипящую смолу. Следовательно, некоторые из ломающих ворота погибнут или будут покалечены. Если у нападающих таких ресурсов нет или они не готовы рисковать здоровьем и жизнью, они не смогут пройти по этому пути.

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

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

Давайте сделаем аналогичный анализ и для информационной системы.

Как мы уже обсуждали, любой атакующий имеет определенную цель. Давайте обозначим ее как $G$. В примере с крепостью, целью было проникновение внутрь.

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

Канал доступа к системе, которым располагает атакующий, мы обозначим как $A$. Атакующий должен располагать как минимум одним каналом, но он может располагать и несколькими. Проводя аналогию со штурмом крепости, взлом ворот и перелезание через стены — разные каналы доступа.

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

Для того, чтобы достичь своей цели $G$, имея доступ $A$, атакующий должен выполнить определенную последовательность действий. Давайте обозначим эту последовательность, как $P$. Очевидно, таких последовательностей может быть несколько. В аналогии с крепостью, нападающие могут взломать ворота, а могут подкупить предателя, который откроет их изнутри.

Поэтому мы можем поставить каждой паре доступ-цель множество путей их достижения:

Каждый из таких путей — это проявление конкретной уязвимости нашей системы. При прохождении его используется одна или несколько слабостей программного обеспечения.

Для прохождения каждого пути $P$ атакующий должен обладать вполне определенными возможностями. Напомню, ему необходимо обладать некоторыми знаниями, иметь определенное оборудование. И атакующий не может мгновенно пройти весь этот путь, это займет у него некоторое время.

Обозначим множество всех знаний, которые должен иметь атакующий, как $\left\{K\right\}$; множество всех материальных ресурсов как $\left\{R\right\}$ Обозначим время, которое необходимо атакующему, чтобы пройти весь путь, как $t$.

Теперь давайте вспомним, что не все атаки могут быть удачными и обозначим вероятность успешного прохождения данного пути, как $p_s$; обозначим вероятность, того, что атакующий будет обнаружен и идентифицирован как $p_f$. Причем, $p_f$ — вероятность идентификации, которая может повлечь за собой какое-то наказание, это мера риска нападающего. Вероятность того, что атака будет обнаружена и прервана, учитывается в $p_s$.

Таким образом, каждому пути мы можем поставить в соответствие набор требуемых ресурсов и вероятность успешного и провального завершения данной атаки:

Соответственно, множеству путей $\left\{R\right\}$ может быть сопоставлено множество ресурсов, которые требуются для прохождения каждого из путей, входящих в это множество.

Теперь мы можем каждой паре доступ-цель, сопоставить набор ресурсов, которые могут потребоваться для достижения цели:

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

Исходя из профиля уязвимости, мы можем предсказывать, кто из потенциальных нарушителей обладает достаточными ресурсами для преодоления нашей защиты. Кто эти люди, сколько их, есть ли такие вообще, — все это задача бизнес анализа.

Сразу хочу отметить, что профиль уязвимости сам по себе не является метрикой безопасности. Это фреймворк, позволяющий нам создавать такие метрики.

Например, мы можем зафиксировать пару-тройку моделей нарушителя и задаться вопросом: «какой процент информационных ресурсов нашей системы может быть скомпрометирован каждым из этих нарушителей?». Ответ на этот вопрос будет метрикой безопасности.

Другую метрику мы можем получить, задав вопрос «какими минимальными ресурсами должен обладать нарушитель, чтобы преодолеть нашу защиту?».

Очевидно, мы можем легко ответить на эти вопросы, используя введенную нами конструкцию. Кроме того, эта конструкция является хорошим инструментом для оценки влияния различных факторов на безопасность системы, для ответа на вопрос: «как изменится уязвимость, если…». Этим его свойством мы воспользуемся для построения полного профиля уязвимости, позволяющего прогнозировать наши риски.

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

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

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

Соответственно, к профилю уязвимости добавиться новый набор ресурсов. Пусть для атаки потребуются знания $\{K{\}}^v$ и материальные ресурсы $\{R{\}}^v$. Атака займет время $t^v$, будет успешной с вероятностью $p_s^v$ и будет обнаружена с вероятностью $p_f^v$. Тогда наше добавление к профилю уязвимости будет выглядеть следующим образом:

Может случиться, что противник, который до этого момента не мог преодолеть нашу защиту, теперь легко это сделает. И атакующий может рассчитывать на такую удачу. Пока новая уязвимость не найдена, у него есть две стратегии.

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

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

Мы хотим учесть обе эти стратегии в нашем профиле уязвимости. Давайте для этого рассматривать поиск злоумышленником нашей ошибки в качестве первой стадии атаки. Как и все остальные действия, для ее прохождения атакующему потребуются знания, ресурсы, время. Очевидно также, эта стадия может закончиться для атакующего ничем, уязвимость не будет найдена. Кроме того, если для проведения исследований нападающему необходим контакт с нашей системой, он может быть обнаружен.

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

К уже знакомым нам ресурсам, необходимым для преодоления защиты, добавим ресурсы, необходимые для поиска уязвимостей. Соответственно, изучение системы займет время $t^r$, потребует знаний $\{K{\}}^r$, и ресурсов $\{R{\}}^r$. Вероятность, что в ходе изучения атакующий будет обнаружен, я обозначил, как $p_f^r$. Вероятность, что искомая уязвимость будет обнаружена $p_s^r$; эта вероятность учитывает как вероятность того, что уязвимость реально существует в нашей программе, так и эффективность методов ее обнаружения.

Тогда ресурсы, необходимые «активному» атакующему для обнаружения уязвимости и проведения атаки, будут следующими:

Ресурсы, необходимые «пассивному» атакующему будут описываться примерно таким же членом. При этом мы должны учитывать, что такой атакующий сам не прикладывает усилий для обнаружения атаки. С другой стороны мы должны учесть, что такой противник получает информацию об уязвимости не сразу после ее открытия, а через некоторое время, которое я обозначил, как $t^d$. Также мы должны учитывать, что он вообще может не получить эту информацию до устранения уязвимости. Обозначим вероятность того, что он все-таки эту информацию получил, как $p^d$. Таким образом, для «пассивного» атакующего мы будем иметь:

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

Таким образом, по своей структуре полный профиль уязвимости очень похож на мгновенный профиль. Поэтому в дальнейшем я всегда буду говорить просто про профиль уязвимости, добавляя «мгновенный» или «полный» только в тех случаях, когда это серьезно меняет смысл.

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

• обнаружение ожидаемых уязвимостей;
• обнаружение уязвимостей, которых не ожидали;
• необнаружение уязвимостей там, где они ожидались.

Поэтому построенный профиль должен регулярно пересматриваться с учетом новых данных.