01.01.2008

»сследование на тему: кака€ ќ— безопаснее?

image

Ќе настала ли пора признать, что мы работаем на полностью незащищенных системах, и что все попытки производителей повысить безопасность современных универсальных ќ—, св€занные с расширением встроенного функционала безопасности, не привод€т к желаемым результатам!

ј.ё.ўеглов, д.т.н, проф.

«јќ «Ќѕѕ «»нформационные технологии в бизнесе»

www.npp-itb.spb.ru

¬ последнее врем€ все чаще по€вл€ютс€ публикации на тему, кака€ из современных ќ— безопаснее. Ёто св€зано с тем, что безопасность сегодн€ становитс€ важнейшим потребительским свойством, как системных средств, так и приложений. –азработчики системных средств вынуждены удел€ть вопросам безопасности все больше внимани€, дабы повысить конкурентную способность своего продукта. Ќо вот что у них при этом получаетс€? „то на самом деле «скрываетс€» за хвалебными деклараци€ми производителей?  »меет ли в принципе смысл сравнивать сегодн€ между собою безопасность современных универсальных ќ— различных производителей, а если сравнивать, то как? ћожет ли в принципе  быть создана безопасна€ универсальна€ ќ—?

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

Ѕезопасность системного средства в общем случае может быть оценена с двух совершенно различных (отнюдь не полностью взаимосв€занных между собой) позиций. — одной стороны, безопасность системного средства может быть охарактеризована достигаемым им уровнем функциональной безопасности – набором функционала (средств, механизмов и т.д.), призванного решать задачи защиты информации. ”ровень функциональной безопасности можно оценить, проанализировав достаточность механизмов защиты, применительно к услови€м эксплуатации системного средства, и корректность их реализации. ≈стественно, что, как недостаточность механизмов, так и некорректность их реализации, та€т в себе у€звимость системного средства. «аметим, что именно уровень функциональной безопасности системного средства и определ€етс€ при его сертификации по требовани€м (в части выполнени€ соответствующего набора требований) информационной безопасности. — другой стороны, в конечном счете, дл€ потребител€ интерес представл€ет не только (а может быть, и не столько) нека€ гипотетическа€ экспертна€ оценка эффективности механизмов защиты, основанна€ на анализе архитектурных решений, а, именно эксплуатационна€ безопасность системного средства – реальный уровень безопасности, обеспечиваемый системным средством в процессе его практической эксплуатации, т.к. только на основании результатов практического использовани€ средства и может быть дана объективна€ оценка его безопасности. ¬ажность этой оценки обусловливаетс€ и тем, что при ее формировании могут быть учтены такие параметры эффективности защиты, никак не св€занные с архитектурными решени€ми, как качество разработки системного средства и его технической поддержки производителем.

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

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

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

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

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

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

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

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

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

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

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

  “еперь собственно о модели (—ћќ). Ѕудем рассматривать следующую гипотетическую ситуацию - люба€ обнаруженна€ у€звимость сразу же направл€етс€ на обслуживание (устранение). Ќикакой очереди неустраненных у€звимостей не образуетс€, т.е. будем рассматривать систему (—ћќ) с бесконечным числом обслуживающих приборов.

«амечание. ƒанное допущение позвол€ет утверждать, что моделью будет описыватьс€ гипотетически идеальна€ (недостижима€) дл€ современных ќ— ситуаци€, т.е. расчетные значени€ будут не хуже реальных (оцениваем верхнюю границу). ƒело в том, что на практике ситуаци€ одновременного (полностью, либо частичного) исправлени€ разработчиком нескольких у€звимостей встречаетс€ крайне редко.

¬ данных предположени€х,  расчетна€ формула веро€тности того, что в системе находитс€ ровно 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

 
 ак видно из графика, быстрее всех исправление выпускала компани€ Microsoft, которой требовалось в среднем 29 дней дл€ закрыти€ у€звимости, а хуже всех компани€ Sun, котора€ устран€ла у€звимости в среднем за 167 дней.

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




–ис.2



¬ конце ƒжефф ƒжонс сравнил скорость изменени€ всех у€звимостей в различных операционных системах по сравнению с 2005 годом, см. рис.3.



–ис.3

«аметим, что данные, полученные ƒжефом, несколько расход€тс€ с исследованием компании Symantec, в котором утверждалось что Microsoft устран€ет у€звимости в среднем за 21 день, Red Hat за 58, Appple Maс OS за 66, а Solaris за 122 дн€. ќднако сравнение Symantec затрагивает меньший период времени – только вторую половину 2006 года. ј в нашем исследовании, куда важнее собственно пор€док цифр.

ј вот теперь мы проведем свое исследование, и оценим, как вли€ет продолжительность устранени€ у€звимостей на эксплуатационную (истинную) безопасность современных ќ—. — этой целью воспользуемс€ нашей моделью и оценим веро€тность того, что система находитс€ в безопасном состо€нии в предположении, что за год обнаруживаетс€ и исправл€етс€ только одна у€звимость. –езультаты исследований представлены на рис.4.

ѕроанализируем полученный результат. ¬идим, что при существующей интенсивности исправлени€ у€звимостей в ќ—, говорить о какой-либо безопасности ќ— просто не приходитс€. ¬едь даже при обнаружении одной у€звимости в год (а об этом сегодн€ можно только мечтать) до 10% (а это лучшие показатели дл€ сравниваемых ќ—) времени эксплуатации ќ— будет находитьс€ не в безопасном состо€нии.

 

 

–ис.4

 ј теперь оценим, как вли€ет на эксплуатационную (реальную) безопасность современных ќ— интенсивность обнаружени€ у€звимостей. ƒл€ этого обратимс€ к другому исследованию под громким названием «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 дней.

«амыкают п€тЄрку HP-UX и Solaris: 98 дыр и 101 день, и 63 дыры и 122 дн€ соответственно.

ѕроведем свое исследование, и попытаемс€ определитьс€ с тем, что же сегодн€ называетс€ самой безопасной ќ—, какой уровень эксплуатационной безопасности она обеспечивает. ƒл€ этого воспользуемс€ нашей математической моделью и построим зависимость изменени€ веро€тности того, что система находитс€ в безопасном состо€нии, от изменени€ интенсивности обнаружени€ у€звимостей. «а интенсивность исправлени€ у€звимостей примем максимально возможное ее значение на сравниваемом множестве вариантов ќ— – интенсивность исправлени€ у€звимостей компанией Microsoft.. –езультаты исследований представлены на рис.5.


 

–ис.5

 

 –ассмотрим внимательно данные результаты, при этом будем помнить, что мы говорим о гипотетически идеальных характеристиках – это верхн€€ теоретическа€ граница, реальное положение дел куда хуже. ѕрежде всего, обратимс€ к красной пунктирной линии на рис.5. Ётой линией характеризуетс€ следующий случай – веро€тность того, что в любой момент времени система находитс€ в безопасном состо€нии составл€ет 0,5, т.е. либо защищена, либо нет. ј ведь такова эксплуатационна€ безопасность ќ— достигаетс€ (см. рис.5) при обнаружении лишь 8 у€звимостей в год, при средней продолжительности их устранени€ в пределах мес€ца. ≈сли же за год в среднем обнаруживаетс€ 20 у€звимостей, то веро€тность того, что система находитс€ в безопасном состо€нии, составл€ет уже около 0,2. ƒругими словами, в этом случае можно говорить об отсутствии какой-либо безопасности подобной системы. ќднако напомним о следующем (см. выше) «…«а полгода Microsoft выпустила обновлени€ более чем к 39 у€звимост€м…» и речь идет о том, что «Windows - сама€ надежна€ система». «амечательно!

Ќевольно возникают вопросы, о какой безопасности в приведенных исследовани€х говоритс€, что с чем и с какой целью сравниваетс€. ¬ыводы о том, что одна ќ— безопаснее других, вообще паразительны! Ќапрашиваетс€ следующа€ аналоги€. —равнить, из чего лучше сделать лобовую броню танка, из бумаги или из картона, и на основании проведенных исследований сделать неоспоримый вывод, что из картона – безопаснее.

’отелось бы обратить внимание читател€ еще на один важный вопрос. Ќас ведь, в конечном счете, интересует не безопасность ќ—, а безопасность компьютера. ј в этом случае еще прибав€тс€ и у€звимости приложений, невольно, перейдем к обсуждению вопросов функциональной безопасности ќ—, т.к. у€звимость приложени€ в принципе не должна сказыватьс€ на компьютерной безопасности, с учетом того, что основные механизмы защиты реализуютс€ на уровне €дра ќ—.

» в заключение еще немного «свежей» статистики с сайта www.securitylab.ru, от 08 окт€бр€ 2007 года. « орпораци€ Microsoft в текущем мес€це планирует опубликовать семь бюллетеней безопасности с описанием новых дыр в операционных системах Windows, офисных приложени€х и браузере Internet Explorer.

 ак сообщаетс€ в предварительном уведомлении, четыре из окт€брьских бюллетеней будут содержать сведени€ о критически опасных у€звимост€х, позвол€ющих выполнить произвольный вредоносный код на удаленном компьютере. ƒыры, получившие максимальный рейтинг опасности по классификации Microsoft, вы€влены в новой операционной системе Windows Vista, а также Windows 2000/’– и Windows Server 2003.  роме того, Microsoft намерена выпустить патчи дл€ критических у€звимостей в офисных приложени€х, браузере Internet Explorer, программе Outlook Express и почтовом клиенте Windows Mail.

≈ще две дыры в программных платформах Windows получили статус важных. ќдна из них теоретически может использоватьс€ злоумышленниками с целью организации DoS-атак, а друга€ - дл€ имитации соединений.  роме того, еще одна у€звимость, охарактеризованна€ важной, может использоватьс€ с целью повышени€ привилегий в Windows и Office».

Ќе настала ли пора признать, что мы работаем на полностью незащищенных системах, и что все попытки производителей повысить безопасность современных универсальных ќ—, св€занные с расширением встроенного функционала безопасности, не привод€т к желаемым результатам!

 

или введите им€

CAPTCHA
—траницы: 1  2  3  4  
01-01-2008 14:28:35
ћне вот интересно, как долго ещЄ будут местные "аналитики" рвать один тот же ба€н про "среднее врем€ устранени€ у€звимостей в различных операционных системах"? ¬о-первых, начнЄм с того, что в статье говоритс€ не про врем€ устранени€ (!) у€звимости, а о скорости доставки патчей/апдейтов/сервиспаков до конечных пользователей. ¬ случае закрытых продуктов врем€ устранени€ у€звимости вообще не может быть известно, но дл€ критических у€звимостей - это скорее всего несколько часов после того как у€звимость найдут. » это врем€ одинаково и у крупных открытых и у закрытых проектов. —разу предоставить апдейты пользовател€м невозможно из-за того, что нужно дополнительное тестирование патчей, но у открытых ќ— в этом гигантское преимущество - обновление можно поставить сразу после того как его напишут программисты, в то врем€ как в лучае того же Windows приходитс€ ждать пресловутого "вторника патчей" или как он там. ¬сЄ это моЄ личное »ћ’ќ.
0 |
01-01-2008 15:17:50
ј почему не спользовали в тестировании системы типа Open/NetBSD? ¬едь они именно OpenBSD €вл€етс€ эталоном безопасности... ” мен€ аптайм уже полтора года уже...
0 |
01-01-2008 15:22:12
¬идимо исследовались только коммерческие системы.
0 |
01-01-2008 20:23:52
ј то, что в закрытых ќ— гораздо труднее искать у€звимости - ибо код их в основном знают только разработчики - а остальным остаетс€ только наде€тс€ на 'reverse engeneering' или компетенцию девелоперов. “ак что, братцы, ¬ендекапец
0 |
03-01-2008 23:12:39
—кажи это √ейтсу, что винде капец, котора€ стоит на 80 % компьютеров
0 |
01-01-2008 20:51:00
¬едь они именно OpenBSD €вл€етс€ эталоном безопасности...с чего бы это?
0 |
03-01-2008 14:29:52
ѕотому что лет 10 как не ломали OpenBSD в дефолтной конфигурации.
0 |
03-01-2008 20:52:42
что за бред
0 |
03-01-2008 12:10:20
"¬едь они именно OpenBSD €вл€етс€ эталоном безопасности..." „то-то новенькое!
0 |
03-01-2008 14:31:46
Ёто очень старый факт —емейство BSD вообще плохо ломаетс€, а openBSD вообще запаришьс€ взламывать.
0 |
03-01-2008 20:53:36
а что значит взломать опенЅ—ƒ?
0 |
05-01-2008 03:13:42
пользы от того что не сломать? ну да, а танк вообще секурен, т.к. т€желый, бронированный и к интернет не подключен. ј то что openbsd мало чего полезного умеет - это да, это маловажно.
0 |
31-01-2008 10:54:01
мд€.. слышали звон не знаете где он вообще в openBSD провер€етс€ адрес возврата функций, т.о. сорвать стэк практически невозможно. но от этого каптиально страдает производительность. теоретически в винде это реалзиовать можно, но тогда она лагать будет
0 |
04-01-2008 12:10:46
"Only two remote holes in the default install, in more than 10 years!" “ео, конечно, не подарок - но дело свое знает, и благодар€ именно его старани€м опенок де-факто €вл€етс€ самой секурной ќ— в мире (де-юре сама€ безопасна€ - XTS-300(400)STOP).
0 |
01-01-2008 20:55:35
такое впечатление, что стать€ кастрирована по самое немогу
0 |
01-01-2008 22:16:04
стать€ куплена гомесеками. по€вилась нова€ категори€ аналитиков - доказывают народу что снег черный а вода квадратна€.
0 |
01-01-2008 23:55:58
rage@localhost ~ $ cat shit.txt | sed 's/ /\n/g' | grep Windows | wc -l 16 rage@localhost ~ $ cat shit.txt | sed 's/ /\n/g' | grep Linux | wc -l 11 rage@localhost ~ $ cat shit.txt | sed 's/ /\n/g' | grep Mac | wc -l 4 rage@localhost ~ $ cat shit.txt | sed 's/ /\n/g' | grep Microsoft | wc -l 10 rage@localhost ~ $ cat shit.txt | sed 's/ /\n/g' | grep 'Hat' | wc -l 7 rage@localhost ~ $ cat shit.txt | sed 's/\./\n/g' | grep езопасн | grep Linux | wc -l 0 rage@localhost ~ $ cat shit.txt | sed 's/\./\n/g' | grep езопасн | grep Windows | wc -l 3 rage@localhost ~ $ cat shit.txt | sed 's/\./\n/g' | grep езопасн | grep Microsoft | wc -l 2 итд... вообщем, стать€ скучна€, необъективна€ и проплаченна€. Ќа opennet уже разобрали по косточкам.
0 |
—траницы: 1  2  3  4