8(495)909-90-01
8(964)644-46-00
pro@sio.su
Главная
Системы видеонаблюдения
Охранная сигнализация
Пожарная сигнализация
Система пожаротушения
Система контроля удаленного доступа
Оповещение и эвакуация
Контроль периметра
Система домофонии
Парковочные системы
Проектирование слаботочных сетей
Аварийный
контроль
Вы находитесь в разделе Типовых решений систем безопасности

Ведение в теорию надежности защиты информации. задачи резервирования механизмов защиты



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

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

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

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

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

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

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

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

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



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

При расчете надежности принимается, что интенсивность отказов постоянная во времени величина. Если предположить, что угрозы НСД взаимонезависимы и любая i – я, i = 1,…,I угроза носит катастрофический характер, предоставляя злоумышленнику несанкционированный доступ к информации, то интенсивность отказов системы защиты равна сумме интенсивностей угроз НСД к соответствующей системе защиты:



Тогда вероятность исправной работы системы защиты в течение произвольного интервала времени t определяется следующим образом:



Соответственно обратная величина интенсивности отказов системы защиты равна среднему промежутку времени между двумя отказами и называется временем наработки на отказ:



Определение.
Интервал времени, в течение которого после возникновения отказа системы защиты обнаруженный канал НСД к информации (уязвимость) устраняется, будем называть временем восстановления. Время восстановления (в общем случае случайная величина, тогда речь идет о среднем времени восстановления) характеризуется следующими компонентами:
  • временем устранения соответствующего канала НСД к информации (уязвимости) разработчиком;
  • временем внедрения на защищаемый объект исправленной версии системы защиты, включая ее установку и настройку администратором, соответственно имеем:




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

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

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

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

Определение.
Под интенсивностью восстановления системы защиты от НСД после отказа следует понимать интенсивность устранения в ней каналов НСД к информации (уязвимостей) в единицу времени.



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



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



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

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

Заметим, что далее нас интересует установившийся режим (условие стационарности), определяемый выполнением условия:









(не выполнение этого условия означает неограниченный рост уязвимостей – полностью незащищенная система).

Расчетные значения для исследуемого параметра сведены в табл.2.1.

Таблица 2.1



Проанализируем полученный результат. Видим, что в заданных условиях характеристики надежности недопустимо низки. Что значит “0,98” (лучшее значение надежности в Табл.2. – это означает, что лишь в среднем при одной уязвимости, найденной в год, и при среднем времени ее восстановления, составляющем 1 неделю, вероятность того, что в любой момент времени объект защищен равна лишь 0,98 (т.е. в любой момент времени с вероятностью 0,02 систему защиты можно считать отказавшей). Но это ведь для современных систем практически идеальная ситуация (потенциально не достижимая) - сегодня во многих современных системных средствах за год находится отнюдь не одна уязвимость, а продолжительность устранения уязвимости разработчиком ПО может составлять несколько месяцев (а что, если это ПО вообще не поддерживается разработчиком, например, это не коммерческое ПО).

Современная статистика уязвимостей такова, что в год в ОС и приложениях находят сотни уязвимостей (для подтверждения сказанного, можем адресовать читателя, например, к следующему сайту: www.cert.org). Ради справедливости, отметим, что не все обнаруживаемые и исправляемые уязвимости носят катастрофический для безопасности системы характер. Однако, при средней задержке появления исправлений 1 – 2 месяца (что сегодня является нормой), как видно из табл.2.1, обнаружение лишь 5 катастрофических для безопасности системы уязвимостей в год, уже является достаточным для того, чтобы потребителю системы задать следующий вопрос: система скорее защищена или скорее не защищена (очевидно, что пограничная зона разделения этих событий определяется значением вероятности 0, .

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

Видя тупиковость складывающейся ситуации, обратимся к классической теории надежности – какие она дает рекомендации в данном случае?

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

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

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

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


то с использованием добавочной защиты, получаем:



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

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


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

В качестве замечания отметим, что подобные исследования могут быть проведены и в отношении современных средств антивирусного противодействия. Здесь основная проблема кроется в высокой интенсивности появления новых вирусов (это связано с относительной простотой их создания), поэтому, как не стремиться уменьшить (а здесь опять же есть граница возможного) время восстановления (время внесения информации о новом вирусе в базу), надежность системы защиты, на наш взгляд, будет желать лучшего. Выводы по работе.
  1. По ряду объективных причин большинством современных сложных системных средств не может быть обеспечена требуемая надежность системы защиты (по крайней мере, не менее 0,9 .
  2. В качестве же, на наш взгляд, единственно возможного сегодня подхода к повышению надежности системы защиты является резервирование механизмов защиты добавочными СЗИ НСД.
  3. Задача использования СЗИ НСД в качестве резервирующего средства защиты, выставляет дополнительные требования к ее реализации, которые могут формулироваться, как последовательное включение в систему защиты избыточных механизмов, реализующих те же функции защиты, что и основные механизмы, но иным способом и средствами.
В качестве же замечания отметим, что задача резервирования встроенных в ОС механизмов защиты может решаться СЗИ НСД только в том случае, если все механизмы защиты в СЗИ НСД реализованы собственными средствами (СЗИ НСД не использует встроенные в ОС механизмы).

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

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




Читайте далее:
24 - 30 апреля 2006 года
24 мая 2006 года
1 - 4 июня 2006 года
17 - 23 июля 2006 года
7 - 13 августа 2006 года
Я помню, как все начиналось ,часть 7,
1 - 8 октября 2006 года
31 октября 2006 года
20 - 26 ноября 2006 года
01 - 10 декабря 2006 года
15 - 21 января 2007 года
5 - 11 февраля 2007 года
19 - 25 марта 2007 года