А.Ю.Щеглов Учебное пособие
.pdfСоответственно обратная величина интенсивности отказов системы равна среднему промежутку времени между двумя отказами называется временем наработки на отказ:
T 1/
Интенсивность отказов системы определяется рядом параметров, в том числе, сложностью исследования механизмов защиты, реализованных в системе, квалификацией злоумышленника, временным интервалом эксплуатации системы защиты.
Сложность исследования механизмов защиты зависит не только от качества разработки системы защиты (уровня квалификации разработчика), но и от доступности информации о системе защиты для исследования злоумышленником. С точки зрения доступности для исследования можно выделить следующие категории:
Очень высокая. Сюда относятся некоммерческие средства, в том числе ОС, характеризуемые свободным доступом злоумышленника к исходным кодам ПО;
Высокая. Сюда относятся широко используемые на практике коммерческие средства, в том числе ОС, характеризуемые отсутствием доступа злоумышленника к исходным кодам ПО;
Низкая. Сюда относятся ограниченно (по различным причинам) используемые на практике коммерческие средства, в том числе ОС, характеризуемые отсутствием доступа злоумышленника к исходным кодам ПО;
Очень низкая. Сюда относятся используемые на практике коммерческие средства, имеющие формализованные правила ограниченного распространения, характеризуемые отсутствием доступа злоумышленника к исходным кодам ПО. К этой категории, в первую очередь, относятся коммерческие добавочные средства защиты отечественных производителей.
Квалификация злоумышленника (это очень важный аспект, т.к. для обнаружения некорректностей в реализации механизма защиты, либо ошибок, требуется проведение некоторого системного анализа, архитектурного анализа защищаемого объекта и т.д.) определяется областью применения защищаемого объекта, т.е. ценностью той информации, которая обрабатывается защищаемым объектом.
Временной интервал эксплуатации системы защиты также весьма важный аспект, влияющий на интенсивность отказов, т.к. понятно, что сначала злоумышленником выявляются наиболее очевидные каналы несанкционированного доступа к информации, которые соответствующим образом ликвидируются разработчиком. Соответственно, чем дольше эксплуатируется система, тем сложнее злоумышленнику найти канал несанкционированного доступа к информации (при условии, что
21
исправления, вносимы в систему разработчиком, не приведут к новым, еще более очевидным некорректностям и ошибкам).
Не менее (если не более) важной, при оценке эксплуатационной безопасности системного средства, является другая составляющая надежности системы защиты – «время восстановления».
Определение. Интервал времени, в течение которого после возникновения отказа системы защиты, обнаруженный канал несанкционированного доступа к информации устраняется, будем называть временем восстановления.
Время восстановления (в общем случае случайная величина, тогда речь идет о среднем времени восстановления) характеризуется следующими компонентами:
временем устранения соответствующего канала несанкционированного доступа к информации разработчиком;
временем внедрения на защищаемый объект исправленной версии системы защиты, включая ее настройку, соответственно:
Tу ,Tвн
Очевидно, что можем принять, что среднее время восстановления определяется временем устранения соответствующего канала несанкционированного доступа к информации разработчиком (другой компонентой, ввиду ее относительной малости, можем пренебречь), имеем:
Tв Tу
С учетом сказанного можем отметить, что в рассматриваемом случае одна из основных характеристик надежности функционирования системы защиты – среднее время восстановления (определяется тем, насколько предприятие-разработчик системы защиты (при использовании встроенных механизмов защиты – соответственно разработчик ОС или приложения) оперативно исправляет обнаруживаемые каналы несанкционированного доступа к информации).
Отметим, что характеристика «время восстановления» объективно зависит от сложности системы. Действительно, исправление одной ошибки требует тестирования практически всех функциональных модулей системы вновь (в единой сложной технической системе все функциональные модули сильно взаимосвязаны) и, кроме того, может привести к другим ошибкам. Поэтому исправление ошибок в ОС и сложных приложениях требует реализации соответствующей технологии внесения исправления, предполагающей серьезного тестирования ПО практически по всем функциям, т.е. может составлять месяцы (например, для ОС семейства Windows данный параметр можно охарактеризовать, как половину среднего интервала времени между выходами в свет доработок ОС – Servisе Pack). Отметим, что с учетом сложности исправления ошибок, на
22
практике разработчики сложных систем стараются не исправлять ошибки по одиночке, т.е. приступать к тестированию системы уже по факту исправления некоторой совокупности ошибок (с учетом совокупности внесенных изменений).
При этом необходимо учитывать, что в течение всего времени восстановления можно считать систему защиты отказавшей, а защищаемый объект – незащищенным.
Таким образом, характеристика надежности системы защиты – «время восстановления» может служить требованием к предприятиюразработчику системы защиты.
С позиций надежности эксплуатационные свойства системы защиты можно охарактеризовать коэффициентом готовности:
Kг T /(T Tв )
Коэффициент готовности, во-первых, характеризует долю времени, в течение которого система защиты работоспособна (выполняет свои функции), во-вторых, характеризует вероятность того, что в любой произвольный момент времени система защиты работоспособна. Соответственно получаем долю времени, в течение которого объект находится в незащищенном состоянии, а также вероятность того, в любой момент времени объект незащищен:
Kнг 1 Kг
1.1.2.2. Оценка эксплуатационной безопасности современных ОС
Построим математическую модель для количественной оценки эксплуатационной безопасностисовременных ОС.
Допустим, что обнаружение уязвимостей – отказов защиты, описывается пуассоновским входящим потоком (описывает наиболее случайные события, что и имеет место на практике), суммарную интенсивность которого обозначим, через:
Примем также, что время устранения уязвимости – восстановление защиты, имеет экспоненциальное распределение с интенсивностью:
Теперь собственно о модели (СМО). Будем рассматривать следующую гипотетическую ситуацию - любая обнаруженная уязвимость сразу же направляется на обслуживание (устранение). Никакой очереди неустраненных уязвимостей не образуется, т.е. будем рассматривать систему (СМО) с бесконечным числом обслуживающих приборов.
23
Замечание. Данное допущение позволяет утверждать, что моделью будет описываться гипотетически идеальная (недостижимая) для современных ОС ситуация, т.е. расчетные значения будут не хуже реальных (оцениваем верхнюю границу). Дело в том, что на практике ситуация одновременного (полностью, либо частичного) исправления разработчиком нескольких уязвимостей встречается крайне редко.
В данных предположениях, расчетная формула вероятности того, что в системе находится ровно n требований (или присутствует n неустраненных уязвимостей) выглядит следующим образом (см. стр.159 в кн. Т.Саати. Элементы теории массового обслуживания и ее приложения. – М.: Изд. «СОВЕТСКОЕ РАДИО», 1965. – 511 с.):
p n Pn 0 n!
С учетом же то, что:
pn 1
n 0
(т.е. в каком-то состоянии система всегда должна находиться) можем определить интересующий нас параметр – критерий эксплуатационной безопасности – вероятность того, что в системе отсутствуют требования n = 0, т.е. отсутствуют неустраненные уязвимости, или вероятность того, что система находится в безопасном состоянии, по следующей достаточно простой формуле:
|
|
|
p |
|
|
n |
|
|
|
|
|||||
Pn 1 |
|
|
0 |
|
|
|
|
(1 |
|
|
|
|
|
) |
|
|
|
n 1 |
n! |
|
|
||
Итак, модель мы построили, теперь с ее помощью проведем исследование.
Как ранее отмечалось, основными параметрами, используемыми для оценки эксплуатационной безопасности системных средств, являются интенсивности отказов защиты (обнаружения уязвимостей) и восстановления защиты (устранения уязвимостей). Для определения значений данных параметров обратимся к двум любопытным исследование
Первое исследование, которое мы здесь приведем: «"Критические дни": Linux, Mac OS X, Solaris and Windows» опубликовано на сайте www.securitylab.ru 19 июня 2007 года.
Джефф Джонс провел очередное исследование на тему того, как долго компании закрывают найденные дыры в своем ПО. Рассматривались следующие коммерческие операционные системы:
Apple: Mac OS X, все версии, исправленные в 2006 году.
Microsoft: Windows 2000 (Professional и Server), Windows XP, Windows Server 2003.
24
Red Hat: Red Hat Enterprise Linux 2.1, Red Hat Enterprise Linux 3, and Red Hat Enterprise Linux 4.
Novell: SUSE Linux Enterprise Server 8, SUSE Linux Enterprise Server 9, SUSE Linux Enterprise Server 10, Novell Linux Desktop 9, и SUSE Linux Enterprise Desktop 10.
Sun: Все версии Solaris, исправленные в 2006.
Вслучае если одна уязвимость устранялась для разных версий ОС в разное время, то за время устранения считалось как среднее значение двух дат.
Если одна уязвимость устранялась в нескольких компонентах одного продукта в разное время, то уязвимость считалась устраненной, когда было выпущено последнее исправления. Например, если 1 января появилась уязвимость в Firefox и Thunderbird в RHEL3, а патч для Firefox был
выпушен 10 января, а для Thunderbird 15 января, то сч В результате были получены следующие значения среднего времени устранения уязвимостей в различных операционных системах (см. рис.1.1).
Рис.1.1. Значения среднего времени устранения уязвимостей в различных операционных системах
Как видно из графика, быстрее всех исправление выпускала компания Microsoft, которой требовалось в среднем 29 дней для закрытия уязвимости, а хуже всех компания Sun, которая устраняла уязвимости в среднем за 167 дней.
На следующем графике (см. рис.1.2) представлена скорость устранения критических уязвимостей в различных операционных системах.
25
Рис.1.2. Скорость устранения критических уязвимостей в различных операционных системах
Заметим, что данные, полученные Джефом, несколько расходятся с исследованием компании Symantec, в котором утверждалось что Microsoft устраняет уязвимости в среднем за 21 день, Red Hat за 58, Appple Maс OS за 66, а Solaris за 122 дня. Однако сравнение Symantec затрагивает меньший период времени – только вторую половину 2006 года. А в нашем исследовании, куда важнее собственно порядок цифр.
А вот теперь мы проведем свое исследование, и оценим, как влияет продолжительность устранения уязвимостей на эксплуатационную (истинную) безопасность современных ОС. С этой целью воспользуемся нашей моделью и оценим вероятность того, что система находится в безопасном состоянии в предположении, что за год обнаруживается и исправляется только одна уязвимость. Результаты исследований представлены на рис.1.3.
Проанализируем полученный результат. Видим, что при существующей интенсивности исправления уязвимостей в ОС, говорить о какой-либо безопасности ОС просто не приходится. Ведь даже при обнаружении одной уязвимости в год (а об этом сегодня можно только мечтать) до 10% (а это лучшие показатели для сравниваемых ОС) времени эксплуатации ОС будет находиться не в безопасном состоянии.
26
Рис.1.3. Вероятность того, что система находится в безопасном состоянии в предположении, что за год обнаруживается и исправляется
только одна уязвимость
А теперь оценим, как влияет на эксплуатационную (реальную) безопасность современных ОС интенсивность обнаружения уязвимостей. Для этого обратимся к другому исследованию под громким названием «Symantec: Windows - самая надежная система», также опубликованному на сайте www.securitylab.ru , но 27 марта 2007 года.
В данном исследовании утверждается следующее.
Microsoft Windows, несмотря на все проблемы с безопасностью, является самой надёжной операционной системой из всех существующих, утверждает Symantec.
Во втором полугодии 2006 г. в системах Windows было найдено и устранено наименьшее число уязвимостей; компания в среднем быстрее всех выпускает обновления безопасности, — говорится в последнем «Докладе об угрозах безопасности интернета», выходящем дважды в год.
Утверждение подтверждается сравнительными показателями среди пяти операционных систем: Windows, Mac OS X, HP-UX, Sun Solaris и Red
Hat Linux.
За полгода Microsoft выпустила обновления более чем к 39 уязвимостям; каждая дыра существовала в открытом состоянии в среднем 21 день. На втором месте — Red Hat Linux: 208 уязвимостей и средний срок устранения 58 дней. Несмотря на большее количество, эти уязвимости были в среднем менее опасны, отмечает Symantec. Mac OS X отметилась 43 уязвимостями и средним временем устранения в 66 дней. На уязвимости высокой степени опасности у компании уходило в среднем 37 дней.
27
Замыкают пятёрку HP-UX и Solaris: 98 дыр и 101 день, и 63 дыры и 122 дня соответственно.
Проведем свое исследование, и попытаемся определиться с тем, что же сегодня называется самой безопасной ОС, какой уровень эксплуатационной безопасности она обеспечивает. Для этого воспользуемся нашей математической моделью и построим зависимость изменения вероятности того, что система находится в безопасном состоянии, от изменения интенсивности обнаружения уязвимостей. За интенсивность исправления уязвимостей примем максимально возможное ее значение на сравниваемом множестве вариантов ОС – интенсивность исправления уязвимостей компанией Microsoft.. Результаты исследований представлены на рис.1.4.
Рис.1.4. Зависимость изменения вероятности того, что система находится в безопасном состоянии, от изменения интенсивности
обнаружения уязвимостей
Рассмотрим внимательно данные результаты, при этом будем помнить, что мы говорим о гипотетически идеальных характеристиках – это верхняя теоретическая граница, реальное положение дел куда хуже. Прежде всего, обратимся к красной пунктирной линии на рис.1.4. Этой линией характеризуется следующий случай – вероятность того, что в любой момент времени система находится в безопасном состоянии составляет 0,5, т.е. либо защищена, либо нет. А ведь такова эксплуатационная безопасность ОС достигается (см. рис.1.4) при обнаружении лишь 8 уязвимостей в год, при средней продолжительности их устранения в пределах месяца. Если же за год в среднем обнаруживается 20 уязвимостей, то вероятность того, что система находится в безопасном состоянии, составляет уже около 0,2. Другими
28
словами, в этом случае можно говорить об отсутствии какой-либо безопасности подобной системы. Однако напомним о следующем (см. выше) «…За полгода Microsoft выпустила обновления более чем к 39 уязвимостям…».
Так каков же уровень эксплуатационной безопасности современных ОС – практически нулевой?
Самое неприятное, что с приложениями ситуация еще хуже. Статистика уязвимостей (за 1 квартал 2008 года, см. рис.1.5, рис.1.6).
Рис.1.5. Соотношение статистики уязвимостей различных системных средств (ОС и приложений)
Всего исправлено 505 уязвимостей (57.58%), исправления отсутствуют для 350 уязвимостей (39.91%), для 14 уязвимостей производители опубликовали инструкции по устранению и 8 уязвимостей устранены частично
Рис.1.6. Статистика исправлений уязвимостей в современных приложениях
Так каков же реальный уровень эксплуатационной безопасности современной вычислительной системы с установленными на нее уязвимыми ОС и приложениями?
Выводы.
29
1.Эксплуатационная безопасность – важнейшая составляющая компьютерной безопасности. Низкий уровень эксплуатационной безопасности системного средства может свести на нет все затраты, связанные с реализацией высокого уровня функциональной безопасности системного средства.
2.Обеспечение высокого уровня эксплуатационной безопасности системного средства – это самостоятельная, крайне важная задача обеспечения безопасности вычислительных систем и сетей. Эта задача должна решаться добавочными средствами, предназначенными нивелировать уязвимости (либо минимизировать последствия атак на эти уязвимости), связанные с ошибками программирования в системном и прикладном ПО.
1.2. Построение системы защиты информации на основе выполения требований к достаточности набора механизмов защиты и корректности их реализации
Как отмечалось выше, требования к корректности реализации механизмов защиты сформулированы в действующем сегодня нормативном документе [1].
Требования к достаточности – полноте набора механизмов защиты, применительно к условиям использования системного средства, сформулированы в действующем сегодня нормативном документе [2].
Достаточно долгое время (а для некоторых приложений, и по сию пору) построение системы защиты сводилось к двум задачам:
К обеспечению достатоточности механизмов защиты применительно к требуемому классу АС (определяемого в результате классификации АС, например, 1Г) в соответствии с нормативным документом, что подтвекрждается последующей аттестацией;
К обеспечению корректности механизмов защиты применительно к требуемому классу СВТ (определяемого в результате классификации АС, например, АС 1Г требуются средства защиты 5 класса СВТ) в соответствии с нормативным документом, что подтвекрждается сертификацией средств защиты.
Достоинства:
Все предельно просто и ясно, не требуется никакого анализа, какихлибо исследований и т.д., все сводится к выполнению некого набора формализованных требований к АС и к СВТ.
Недостатки:
Не решается каких-либо задач проектирования (никакие критерии оптимальности не определены – все сводится к выбору средств по критерию «цена» из множества средств, удовлетворяющих соответствующим формализованным требованиям). Здесь речь идет не о проектировании, а о построении системы защиты;
30