Информационная безопасность операционных систем (стр. 1 из 2)

Контрольная работа

по дисциплине:

«Информационная безопасность»

на тему: «Информационная безопасность ОС»

СОДЕРЖАНИЕ:

Введение………………………………………………………………………..3

Из чего складывается безопасность системного средства………………….4

Подход к оценке эксплуатационной безопасности системного средства…4

Оценка уровня эксплуатационной безопасности современных

универсальных ОС…………………..……………………………………….6

Заключение……………………………………………………………………11

Использованная литература………………………………………………….12

ВВЕДЕНИЕ

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

Из чего складывается безопасность системного средства.

Безопасность системного средства в общем случае может быть оценена с двух совершенно различных (отнюдь не полностью взаимосвязанных между собой) позиций. С одной стороны, безопасность системного средства может быть охарактеризована достигаемым им уровнем функциональной безопасности – набором функционала (средств, механизмов и т.д.), призванного решать задачи защиты информации. Уровень функциональной безопасности можно оценить, проанализировав достаточность механизмов защиты, применительно к условиям эксплуатации системного средства, и корректность их реализации. Естественно, что, как недостаточность механизмов, так и некорректность их реализации, таят в себе уязвимость системного средства. Заметим, что именно уровень функциональной безопасности системного средства и определяется при его сертификации по требованиям (в части выполнения соответствующего набора требований) информационной безопасности. С другой стороны, в конечном счете, для потребителя интерес представляет не только (а может быть, и не столько) некая гипотетическая экспертная оценка эффективности механизмов защиты, основанная на анализе архитектурных решений, а, именно эксплуатационная безопасность системного средства – реальный уровень безопасности, обеспечиваемый системным средством в процессе его практической эксплуатации, т.к. только на основании результатов практического использования средства и может быть дана объективная оценка его безопасности. Важность этой оценки обусловливается и тем, что при ее формировании могут быть учтены такие параметры эффективности защиты, никак не связанные с архитектурными решениями, как качество разработки системного средства и его технической поддержки производителем.

В данной работе акцентируем свое внимание на вопросах оценки эксплуатационной безопасности современных универсальных ОС.

Подход к оценке эксплуатационной безопасности системного средства.

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

Под «отказом защиты» будем понимать обнаружение уязвимости системного средства. Наличие уязвимости делает данное средство незащищенным до момента устранения ее производителем системного средства.

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

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

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

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

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

Допустим, что обнаружение уязвимостей – отказов защиты, описывается пуассоновским входящим потоком (описывает наиболее случайные события, что и имеет место на практике), суммарную интенсивность которого обозначим, через:

Примем также, что время устранения уязвимости – восстановление защиты, имеет экспоненциальное распределение с интенсивностью:

Теперь собственно о модели (СМО). Будем рассматривать следующую гипотетическую ситуацию - любая обнаруженная уязвимость сразу же направляется на обслуживание (устранение). Никакой очереди неустраненных уязвимостей не образуется, т.е. будем рассматривать систему (СМО) с бесконечным числом обслуживающих приборов.

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

В данных предположениях, расчетная формула вероятности того, что в системе находится ровно n требований (или присутствует n неустраненных уязвимостей) выглядит следующим образом (см. стр.159 в кн. Т.Саати. Элементы теории массового обслуживания и ее приложения. – М.: Изд. «СОВЕТСКОЕ РАДИО», 1965. – 511 с.):

С учетом же то, что:

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

Итак, модель мы построили, теперь с ее помощи проведем исследование.

Оценка уровня эксплуатационной безопасности современных универсальных ОС.

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

Первое исследование, которое здесь будет приведено: «"Критические дни": 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.
• 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 января появилась уязвимость в Firefox и Thunderbird в RHEL3, а патч для Firefox был выпушен 10 января, а для Thunderbird 15 января, то считалась устранненной 15 января.

В результате были получены следующие значения среднего времени устранения уязвимостей в различных операционных системах (см. рис.1).

Рис.1

На следующем графике (см. рис.2) представлена скорость устранения критических уязвимостей в различных операционных системах.

Рис.2