В рубрику "Защита информации" | К списку рубрик | К списку авторов | К списку публикаций
А.Ю.Щеглов, д.т.н, проф.
В своих предыдущих работах автор акцентировал внимание читателя на том, что безопасность системного средства может быть оценена с двух совершенно различных (и, отнюдь, не полностью коррелированных между собой) позиций. С одной стороны, безопасность системного средства может быть охарактеризовано достигаемым им уровнем функциональной безопасности. Уровень функциональной безопасности системного средства на сегодняшний день может быть определен только путем экспертного оценивания реализованных в нем технологий и решений по защите информации. Данный подход широко используется на практике, как в нашей стране, так и за рубежом. В частности, именно уровень функциональной безопасности системного средства и определяется при его сертификации по требованиям (в части выполнения соответствующего набора требований) информационной безопасности. С другой стороны, в конечном счете, для потребителя интерес представляет не только (а может быть, не столько) некая гипотетическая экспертная оценка эффективности механизмов защиты, основанная на анализе архитектурных решений, а, в первую очередь, эксплуатационная безопасность системных средств – реальный уровень безопасности, обеспечиваемый системным средством в процессе его практической эксплуатации, т.к. только на основании результатов практического использования средства и может быть дана объективная оценка его эффективности. Интерес этой оценки обусловливается и тем, что при ее формировании могут быть учтены и такие параметры эффективности, никак не связанные с архитектурными решениями, как качество разработки системного средства и его технической поддержки производителем. Поневоле, напрашивается вывод, что сертификация (или оценка эффективности) системных средств по требованиям информационной безопасности должна быть комплексной, позволяющей учитывать достигаемый им уровень и функциональной, и эксплуатационной безопасности.
Введение. Сертификация по требованиям информационной безопасности является важнейшим этапом создания средства защиты информации, либо защищенного системного средства. Это обусловливается тем, что именно процедура сертификации призвана дать объективную (по крайней мере, максимально к этому стремиться) оценку эффективности средства защиты. По большому счету, именно наличие сертификата, соотносящего заявляемые разработчиком возможности средства защиты с определенными требованиями, в большой мере (а в некоторых случаях, практически в полном объеме) определяет возможность, являясь необходимым, а, порою, и достаточным, условием использования средства защиты в соответствующих приложениях.
Оценка функциональной безопасности системного средства. Уровень функциональной безопасности системного средства определяется тем, в какой мере достаточен набор механизмов защиты, применительно к условиям его конкретного использования, и тем, насколько корректно данные механизмы реализованы (естественно, что как недостаточность механизмов, так и некорректность их реализации, обусловливают уязвимость системного средства). Заметим, что именно такой подход к оцениванию функциональной безопасности системных средств реализуется действующими сегодня нормативными документами в области защиты информации.
Требования к корректности реализации механизмов защиты сформулированы в действующем сегодня нормативном документе "Гостехкомиссия России. Руководящий документ. Средства вычислительной техники. Защита от несанкционированного доступа к информации. Показатели защищенности от НСД к информации", который используется при сертификации средств защиты.
Требования к достаточности – полноте набора механизмов защиты, применительно к условиям использования системного средства, сформулированы в действующем сегодня нормативном документе "Гостехкомиссия России. Руководящий документ. Автоматизированные системы. Защита от несанкционированного доступа к информации. Показатели защищенности от НСД к информации", используемом при аттестации объекта информатизации.
Сертификация системного средства, в части объективной оценки достигаемого им уровня функциональной безопасности, важна тем, что, как недостаточность механизмов защиты, применительно к условиям использования системного средства, так и некорректность их реализации, являются уязвимостями системного средства, создавая угрозу осуществления злоумышленником успешной атаки на защищаемые ресурсы.
Таким образом, оценка уровня функциональной безопасности системного средства является самостоятельной очень важной задачей оценки его эффективности, призванной уменьшить (в идеале, свести на нет) вероятность существования в нем уязвимостей, вызванных архитектурными недостатками реализации механизмов защиты. Как мы отмечали в статье "Функциональная безопасность системных средств", опубликованной ранее на сайте www.itsec.ru, ключевым вопросом оценивания функциональной безопасности является формирование требований к набору и к реализации механизмов защиты, применительно к современным условиям использования системного средства. Ведь каковы будут требования, такова, в конечном счете, будет и эффективность защиты, по крайней мере, настолько объективно будет проведена его оценка.
Оценка эксплуатационной безопасности системного средства. Уровень эксплуатационной безопасности системного средства определяется тем, в какой мере обеспечивается реализованный уровень функциональной безопасности в процессе эксплуатации системного средства. В качестве критерия оценки эксплуатационной безопасности системного средства в статье "Эксплуатационная безопасность системных средств", опубликованной ранее на сайте www.itsec.ru, нами предлагается рассматривать коэффициент его готовности обеспечивать защиту информации в процессе эксплуатации. В качестве же основных параметров предлагается рассматривать: интенсивности отказов и восстановления средства защиты.
Под "отказом" средства защиты понимается обнаружение уязвимости или "канала" НСД к информации (например, это могут быть ошибки в реализации ОС, либо приложений), которая потенциально может привести к несанкционированному доступу к информации.
Под интенсивностью отказов средства защиты от НСД (интенсивностью появления уязвимостей средства защиты) понимаем интенсивность обнаружения в ней "каналов" НСД к информации (уязвимостей) в единицу времени.
Под интенсивностью восстановления средства защиты от НСД после отказа (обнаружения уязвимости) понимаем интенсивность устранения в ней "каналов" НСД к информации (уязвимостей) в единицу времени.
Для оценки эксплуатационной безопасности системного средства может быть построена математическая модель с использованием аппарата теории массового обслуживания (по аналогии с тем, как это делается в теории надежности, ведь в конечном счете, применительно к средству защиты информации, надежность – это свойство средства обеспечивать защиту информации в течение заданного промежутка времени). Приведем пример простейшей математической модели. Будем считать, что потоки обнаружения "каналов" НСД к информации (уязвимостей) – отказов средства защиты, и процесс их устранения являются пуассоновскими (описывающими наиболее случайные процессы), причем уязвимости устраняются по очереди (не одновременно), по мере их обнаружения (наверное, именно в этом и состоит основная "грубость" данной математической модели, однако, на практике, в большинстве случаев, подобное упрощение уместно, если речь идет об одном системном средстве). В данных предположениях, вероятность того, что в любой момент времени объект защищен (определяется тем условием, что число не устраненных "каналов" НСД (уязвимостей) равно 0) можно оценить по формуле:
Естественно, что на практике нас будет интересовать установившийся режим (условие стационарности), определяемый выполнением условия:
т.к. не выполнение этого условия означает неограниченный рост уязвимостей, что характеризует состояние полной незащищенности системного средства, что определяется условием:
Зависимости:
для различных значений интенсивностей обнаружения уязвимостей (значения интенсивностей обнаружения уязвимостей заданы в единицах: число/год, а интенсивность устранения уязвимостей – ось абсцисс, заданы в 1/неделя – за сколько недель в среднем устраняется одна уязвимость), рассчитанные с использованием нашей математической модели, приведены на рис.1.
На этом рисунке следует обратить внимание на выделенную пунктирную прямую (на рис.1 имеет красный цвет). Она характеризует, что в любой момент времени объект защищен с вероятностью 0,5. Это означает, что в любой момент времени системное средство либо защищено, либо нет. Все значения, располагаемые ниже этой прямой, характеризуют следующее свойство средства защиты – системное средство скорее не защищено, чем защищено, располагаемые выше этой прямой – системное средство скорее защищено, чем не защищено.
Рассмотрим гипотетически идеальный случай – в среднем обнаруживается одна уязвимость в год (зеленая кривая на рис.1 ). Эта зависимость нам интересна с точки зрения того, как влияет на эксплуатационную безопасность интенсивность устранения уязвимостей. Видим, что подобное влияние весьма заметно. Из рис.1 следует, что если в среднем уязвимость (в частности, ошибка программирования) исправляется разработчиком за 1 месяц, то получаем в нашем гипотетически идеальном случае, что в любой момент времени объект защищен лишь с вероятностью 0,9. А что такое 1 месяц на устранение ошибки в сложном системном средстве, его потребуется только тестировать после внесения исправления не меньше месяца, иначе сразу сталкиваемся с проблемами надежности (отказоустойчивости) и корректности функционирования системного средства. А ведь этот месяц включает в себя после обнаружения уязвимости злоумышленником: получение об этом информации производителем, собственно устранение уязвимости, в той или иной мере крупномасштабное тестирование системного средства после исправления, получение обновления потребителем и внедрение обновления в системное средство. Месяц для выполнения подобной совокупности условий – это очень мало!
Рис. 1. Результаты моделирования
Какие же предположения мы можем сделать, глядя на картину, приведенную на рис.1. Да только одно, что оценка уровня функциональной безопасности (которая, как мы отмечали ранее, необходима) в принципе не может дать объективной оценки эффективности защиты. Возможно, мы преувеличиваем, и это не так? Чтобы ответить на этот вопрос, проведем небольшое исследование.
Как известно, 03 декабря 2004 года был выдан сертификат на ОС Windows XP Professional (№844/2), т.е. была проведена оценка уровня функциональной безопасности данного системного средства. Не будем в этой работе останавливаться на вопросах анализа актуальности используемых требований для оценки эффективности защиты ОС в современных условиях (данная работа посвящена исследованию иных вопросов).
Сертификация данного системного средства позволила некоторым поставщикам услуг в области защиты информации декларировать следующее:
"Применение сертифицированной ОС Microsoft позволяет легально обрабатывать на клиентских рабочих местах конфиденциальную информацию, защищаемую в соответствии с законодательством Российской Федерации.
Преимущества использования сертифицированной ОС:
Весьма оптимистичные заявления – все здорово!
Но вот в чем вопрос, а что же на самом-то деле, ведь ранее мы говорили, что истинным мерилом эффективности защиты системного средства является обеспечиваемый им уровень эксплуатационной безопасности.
Напомним читателю, что характеристиками, используемыми при оценке уровня эксплуатационной безопасности системного средства, являются интенсивности отказов и восстановления средства защиты (соответственно, интенсивности обнаружения и устранение уязвимостей).
Рассмотрим данные характеристики для исследуемого системного средства (с учетом того, что анализ уровня его функциональной безопасности проведен в декабре 2003 года) по порядку.
Сначала об интенсивности обнаружения уязвимостей в ОС. Воспользуемся данными, опубликованными в открытой печати, в частности на сайтах www.itsec.ru и www.cnews.ru (в порядке замечания отметим, что автор не занимается систематическим сбором и анализом соответствующей статистики, это лишь некая подборка эпизодических данных):
* — за 7 месяцев
Рис.2. Динамика роста обнаруженных уязвимостей
Рассматривая данную статистику обнаружения уязвимостей ОС, поневоле задаешь вопрос, как все это "вяжется" с тем оптимизмом, которым мы были наделены в результате оценки уровня ее функциональной безопасности. Вернемся к рис.1 , и посмотрим, о какой безопасности может идти речь, если число обнаруженных за год уязвимостей составляет десятки? Вот и вывод, в части определения места оценки уровня функциональной безопасности системного средства – это необходимая, но отнюдь не достаточная мера для объективной оценки истинной эффективности средства защиты!
Теперь, в нескольких словах, об интенсивности исправления уязвимостей в ОС. На наш взгляд, весьма показателен следующий пример. Обратимся к публикации К.Касперски "Обзор эксплойтов" в журнале "Хакер" от декабря 12(96) 2006, см. стр.60-65. Приведем без комментариев несколько выдержек из этой статьи "Просто поразительно, как гиганты компьютерной индустрии реагируют на сообщения об ошибках, которые они не могут исправить. 22 октября 2004 года основатель группы Argeniss Information Security и ее CEO в одном лице – Cesar Cerrudo обнаружил серьезнейшую ошибку в Windows, о чем тут же сообщил в Microsoft. Но та продолжила выпускать дырявые операционные системы, а для уже существующей заплатка отсутствует и по сей день". Следующая выдержка "…система не препятствует ремапингу секции с атрибутами чтения/записи, что позволяет любому локальному пользователю проникнуть на уровень ядра…". Далее "По заявлению Argeniss Research Team, уязвимости подвержены W2K (до W2K SP4) и XP (до XP SP2) и не подвержены Server 2003 и Vista beta 2". Что же нам, как потребителям, рекомендует автор этой статьи "Официальной заплатки от Microsoft до сих пор нет, и все, что нам остается – это мигрировать на Server 2003 или Vista, в которых огрехи проектирования без лишнего шума были устранены (но, как известно, исправляя одну ошибку, Microsoft добавляет десяток новых; Vista – это не вариант, а вот над переходом на Server 2003 можно подумать)".
Чудовищно, критическая уязвимость существует более двух лет и не исправляется производителем. В это трудно поверить! Однако, исходный код эксплойта для данной уязвимости, в подтверждение сказанному, автор привел в своей статье. По крайней мере, в отношении XP SP2 он прав, (заметим, что наша проверка заняла не более пяти минут), уязвимость присутствует.
Необходимость комплексной сертификации системных средств. Проведенное выше исследование, надеемся, убедило читателя, что оценку эффективности защиты системного средства можно получить, лишь оценив уровень его функциональной и эксплуатационной безопасности в комплексе, т.к. только оценка функциональной и эксплуатационной безопасности в совокупности и могут дать объективный результат, который, по большому счету, и интересует потребителя средства защиты.
С оценкой уровня функциональной безопасности все более или менее ясно, именно такая оценка должна осуществляться и осуществляется на сегодняшний день на практике при сертификации системного средства (правда, еще раз отметим, что "краеугольным камнем" оценки функциональной безопасности является обоснованная актуальность требований к механизмам защиты (достаточности и корректности реализации), применительно к современных условиям использования системного средства).
Что же делать с оценкой уровня эксплуатационной безопасности? На наш взгляд – это вполне решаемая задача. Достаточно провести экспертную оценку и определиться с тем, каким значениям критерия эффективности - вероятности того, что в любой момент времени системное средство защищено, должно удовлетворять системное средство в процессе его эксплуатации. Предположим, при обработке конфиденциальной информации должно выполняться условие:
Мы не настаиваем на этом значении, приведенном лишь в качестве примера. Однако согласитесь, что принимать значение критерия эффективности 0,9 или менее, наверное, даже при защите открытых данных "как-то неловко".
В процессе же эксплуатации системного средства должна производиться периодическая (например, раз в год) сертификация или оценка уровня его эксплуатационной безопасности. Для этого достаточно иметь для отчетного периода статистику обнаружения и исправления уязвимостей в сертифицируемом системном средстве. Это позволит с использованием соответствующих математических моделей сделать расчет критерия эффективности. Если результат экспертизы будет удовлетворительным, системное средство соответствует – сертификация успешно пройдена, если нет, то системное средство не соответствует определенному для него классу защищенности, оно не должно при обеспечиваемом уровне эксплуатационной (заметим, истинной, а не гипотетической) безопасности использоваться в приложениях, требующих данного класса защищенности.
Повысить уровень эксплуатационной безопасности системного средства можно различными способами. Во-первых, это, конечно же, задача производителя системного средства, если он претендует на отнесение системного средства к соответствующему классу защищенности, что позволяет его использование в соответствующих приложениях. Во-вторых, если производитель по каким-либо причинам не в состоянии справиться с этой задачей, повысить уровень эксплуатационной безопасности системного средства возможно с использованием добавочных средств защиты (правда, к подобным средствам, в части решения данной задачи, выдвигаются определенные требования, которые мы попытались сформулировать в статье "Эксплуатационная безопасность системных средств", опубликованной ранее на сайте www.itsec.ru).
Согласитесь, что с учетом проведенных выше исследований, иллюстрирующих сложившееся положение дел, основной тезис поставщиков сертифицированной ОС Windows XP Professional "отсутствие необходимости установки дополнительных сертифицированных "наложенных" средств защиты информации" выглядит мало обоснованным. А если бы была проведена сертификация уровня эксплуатационной безопасности данного системного средства, возможно, рекомендации были бы иными?!
Вместо заключения приведем следующее, несколько шокирующее сообщение:
Опубликовано: Сайт ITSec.Ru-2007