Вы находитесь в разделе Типовых решений систем безопасности
Как оценить уровень безопасности системного средства или необходимость комплексной сертификации системных средствВ своих предыдущих работах автор акцентировал внимание читателя на том, что безопасность системного средства может быть оценена с двух совершенно различных (и, отнюдь, не полностью коррелированных между собой) позиций. С одной стороны, безопасность системного средства может быть охарактеризовано достигаемым им уровнем функциональной безопасности. Уровень функциональной безопасности системного средства на сегодняшний день может быть определен только путем экспертного оценивания реализованных в нем технологий и решений по защите информации. Данный подход широко используется на практике, как в нашей стране, так и зарубежом. В частности, именно уровень функциональной безопасности системного средства и определяется при его сертификации по требованиям (в части выполнения соответствующего набора требований) информационной безопасности. С другой стороны, в конечном счете, для потребителя интерес представляет не только (а может быть, не столько) некая гипотетическая экспертная оценка эффективности механизмов защиты, основанная на анализе архитектурных решений, а, в первую очередь, эксплуатационная безопасность системных средств – реальный уровень безопасности, обеспечиваемый системным средством в процессе его практической эксплуатации, т.к. только на основании результатов практического использования средства и может быть дана объективная оценка его эффективности. Интерес этой оценки обусловливается и тем, что при ее формировании могут быть учтены и такие параметры эффективности, никак не связанные с архитектурными решениями, как качество разработки системного средства и его технической поддержки производителем. Поневоле, напрашивается вывод, что сертификация (или оценка эффективности) системных средств по требованиям информационной безопасности должна быть комплексной, позволяющей учитывать достигаемый им уровень и функциональной, и эксплуатационной безопасности. Введение Сертификация по требованиям информационной безопасности является важнейшим этапом создания средства защиты информации, либо защищенного системного средства. Это обусловливается тем, что именно процедура сертификации призвана дать объективную (по крайней мере, максимально к этому стремиться) оценку эффективности средства защиты. По большому счету, именно наличие сертификата, соотносящего заявляемые разработчиком возможности средства защиты с определенными требованиями, в большой мере (а в некоторых случаях, практически в полном объеме) определяет возможность, являясь необходимым, а, порою, и достаточным, условием использования средства защиты в соответствующих приложениях. Оценка функциональной безопасности системного средства Уровень функциональной безопасности системного средства определяется тем, в какой мере достаточен набор механизмов защиты, применительно к условиям его конкретного использования, и тем, насколько корректно данные механизмы реализованы (естественно, что как недостаточность механизмов, так и некорректность их реализации, обусловливают уязвимость системного средства). Заметим, что именно такой подход к оцениванию функциональной безопасности системных средств реализуется действующими сегодня нормативными документами в области защиты информации. Требования к корректности реализации механизмов защиты сформулированы в действующем сегодня нормативном документе Гостехкомиссия России. Руководящий документ. Средства вычислительной техники. Защита от несанкционированного доступа к информации. Показатели защищенности от НСД к информации, который используется при сертификации средств защиты. Требования к достаточности – полноте набора механизмов защиты, применительно к условиям использования системного средства, сформулированы в действующем сегодня нормативном документе Гостехкомиссия России. Руководящий документ. Автоматизированные системы. Защита от несанкционированного доступа к информации. Показатели защищенности от НСД к информации, используемом при аттестации объекта информатизации. Сертификация системного средства, в части объективной оценки достигаемого им уровня функциональной безопасности, важна тем, что, как недостаточность механизмов защиты, применительно к условиям использования системного средства, так и некорректность их реализации, являются уязвимостями системного средства, создавая угрозу осуществления злоумышленником успешной атаки на защищаемые ресурсы. Таким образом, оценка уровня функциональной безопасности системного средства является самостоятельной очень важной задачей оценки его эффективности, призванной уменьшить (в идеале, свести на нет) вероятность существования в нем уязвимостей, вызванных архитектурными недостатками реализации механизмов защиты. Как мы неоднократно отмечали, ключевым вопросом оценивания функциональной безопасности является формирование требований к набору и к реализации механизмов защиты, применительно к современным условиям использования системного средства. Ведь каковы будут требования, такова, в конечном счете, будет и эффективность защиты, по крайней мере, настолько объективно будет проведена его оценка. К сожалению, на сегодняшний день еще действуют нормативные документы, вышедшие в свет в 1992 году. Можно предположить, что при столь бурном развитии ИТ-технологий, настало время пересмотреть некоторые базовые требования к защите информации.На наш взгляд, ключевыми (базовыми) требованиями в современных условиях использования системных средств являются:Первое базовое требование – достаточность набора механизмов защиты, которое может быть сформулировано следующим образом:
Необходимость реализации данного требования вызвана следующим. Достаточно обратиться к существующей статистике успешных атак на системные средства, чтобы сделать вывод о том, что основные уязвимости, позволяющие осуществлять успешные атаки на системные средства, несут в себе процессы (приложения). Приведем классификацию процессов, в основу которой положим группирование свойств процессов, порождающих угрозу:
Видим, что о пользователях, либо об учетных записях здесь речь вообще не идет – речь идет о доверии к процессам (приложениям), что и должно быть положено в основу реализации разграничительной политики доступа к ресурсам. Обратимся к проблеме защиты от вирусных атак. Для этого приведем классификацию угроз вирусных атак: Вредоносные программы (трояны и т.п.). Отдельные программы, которые выполняют те или иные деструктивные/несанкционированные действия. Вирусы. Программы, обычно не имеющие собственного исполняемого модуля и живущие (заражение осуществляется по средством их присоединения к исполняемому файлу) внутри другого файлового объекта или части физического носителя. Черви. Разновидность 1,2,4, использующая сетевые возможности для заражения. Макро-вирусы (скриптовые вирусы) - программы, для исполнения которых требуется определенная среда выполнения (командный интерпретатор, виртуальная машина и т.п.). К этой же группе относятся и офисные приложения, позволяющие создавать и подключать макросы. Видим, что и в данном случае задача защиты может (да, по большому счету, и должна) решаться механизмами контроля доступа к ресурсам. Естественно, что никакими средствами контроля, к которым относятся сигнатурные анализаторы, эффективно задачу антивирусной защиты априори не решить, что, кстати говоря, подтверждает и существующая статистика. И в этом случае основу реализации разграничительной политики доступа к ресурсам составляет назначение разграничений для субъекта процесс.Третье базовое требование – достаточность набора режимов обработки категорированных данных может быть сформулировано следующим образом:
 где С = {С1,..., Ск} и О = {О1,..., Оk}) линейно упорядоченные множества субъектов и объектов;
Данное требование на наш взгляд также весьма очевидно. Защищать, в первую очередь, имеет смысл именно конфиденциальную информацию. При этом на одном компьютере, как правило, обрабатывается как конфиденциальная, так и открытая информация (в противном случае, для обработки каждой категории информации потребуется собственный компьютер, это недопустимая роскошь). Как следствие, актуальной становится задача реализации различных режимов обработки на одном компьютере информации различных категорий. В порядке замечания отметим, что реализация данного требования направлена, в том числе, и на защиту информации от внутренних ИТ-угроз, от угроз ее хищения санкционированными пользователями (инсайдерами). Как, например, решить задачу защиты персональных данных, не выполнив данного условия? А вот, и статистика, в порядке подтверждения актуальности решения данной задачи защиты:
А теперь вопрос к читателю. Найдите хотя бы одно системное средство, например, универсальную ОС, которое хоть частично реализует данные требования к защите? Но тогда, невольно, напрашивается вопрос, а для чего данные средства имеют в своем составе некий набор механизмов защиты, как позиционируется их использование производителем, если данные механизмы не призваны решать основные на сегодняшний день задачи защиты информации? А средства добавочной защиты? Позиционируется ли производителями большинства из них круг решаемых задач защиты? Все сводится к реализации некого набора механизмов защиты, требования к которым сформулированы в соответствующих нормативных документах, а достаточен ли он для решения современных задач защиты, как использовать эти механизмы, а ведь именно это и интересует потребителя. Оценка эксплуатационной безопасности системного средства Уровень эксплуатационной безопасности системного средства определяется тем, в какой мере обеспечивается реализованный уровень функциональной безопасности в процессе эксплуатации системного средства. В качестве критерия оценки эксплуатационной безопасности системного средства нами предлагается рассматривать коэффициент его готовности обеспечивать защиту информации в процессе эксплуатации. В качестве же основных параметров предлагается рассматривать: интенсивности отказов и восстановления средства защиты. Под отказом средства защиты понимается обнаружение уязвимости или канала НСД к информации (например, это могут быть ошибки в реализации ОС, либо приложений), которая потенциально может привести к несанкционированному доступу к информации. Под интенсивностью отказов средства защиты от НСД (интенсивностью появления уязвимостей средства защиты) понимаем интенсивность обнаружения в ней каналов НСД к информации (уязвимостей) в единицу времени. Под интенсивностью восстановления средства защиты от НСД после отказа (обнаружения уязвимости) понимаем интенсивность устранения в ней каналов НСД к информации (уязвимостей) в единицу времени. Для оценки эксплуатационной безопасности системного средства может быть построена математическая модель с использованием аппарата теории массового обслуживания (по аналогии с тем, как это делается в теории надежности, ведь в конечном счете, применительно к средству защиты информации, надежность – это свойство средства обеспечивать защиту информации в течение заданного промежутка времени). Приведем пример простейшей математической модели. Будем считать, что потоки обнаружения каналов НСД к информации (уязвимостей) – отказов средства защиты, и процесс их устранения являются пуассоновскими (описывающими наиболее случайные процессы), причем уязвимости устраняются по очереди (не одновременно), по мере их обнаружения (наверное, именно в этом и состоит основная грубость данной математической модели, однако, на практике, в большинстве случаев, подобное упрощение уместно, если речь идет об одном системном средстве). В данных предположениях, вероятность того, что в любой момент времени объект защищен (определяется тем условием, что число не устраненных каналов НСД (уязвимостей) равно можно оценить по формуле:  Естественно, что на практике нас будет интересовать установившийся режим (условие стационарности), определяемый выполнением условия:  не выполнение этого условия означает неограниченный рост уязвимостей, что характеризует состояние полной незащищенности системного средства, что определяется условием:  Зависимости:  для различных значений интенсивностей обнаружения уязвимостей (значения интенсивностей обнаружения уязвимостей заданы в единицах: число/год, а интенсивность устранения уязвимостей – ось абсцисс, заданы в 1/неделя – за сколько недель в среднем устраняется одна уязвимость), рассчитанные с использованием нашей математической модели, приведены на рис.1. На этом рисунке следует обратить внимание на выделенную пунктирную прямую (на рис.1 имеет красный цвет). Она характеризует, что в любой момент времени объект защищен с вероятностью 0, Это означает, что в любой момент времени системное средство либо защищено, либо нет. Все значения, располагаемые ниже этой прямой, характеризуют следующее свойство средства защиты – системное средство скорее не защищено, чем защищено, располагаемые выше этой прямой – системное средство скорее защищено, чем не защищено. Рассмотрим гипотетически идеальный случай – в среднем обнаруживается одна уязвимость в год (зеленая кривая на рис. . Эта зависимость нам интересна с точки зрения того, как влияет на эксплуатационную безопасность интенсивность устранения уязвимостей. Видим, что подобное влияние весьма заметно. Из рис.1 следует, что если в среднем уязвимость (в частности, ошибка программирования) исправляется разработчиком за 1 месяц, то получаем в нашем гипотетически идеальном случае, что в любой момент времени объект защищен лишь с вероятностью 0, А что такое 1 месяц на устранение ошибки в сложном системном средстве, его потребуется только тестировать после внесения исправления не меньше месяца, иначе сразу сталкиваемся с проблемами надежности (отказоустойчивости) и корректности функционирования системного средства. А ведь этот месяц включает в себя после обнаружения уязвимости злоумышленником: получение об этом информации производителем, собственно устранение уязвимости, в той или иной мере крупномасштабное тестирование системного средства после исправления, получение обновления потребителем и внедрение обновления в системное средство. Месяц для выполнения подобной совокупности условий – это очень мало!  Рис. Результаты моделирования Какие же предположения мы можем сделать, глядя на картину, приведенную на рис. Да только одно, что оценка уровня функциональной безопасности (которая, как мы отмечали ранее, необходима) в принципе не может дать объективной оценки эффективности защиты. Возможно, мы преувеличиваем, и это не так? Чтобы ответить на этот вопрос, проведем небольшое исследование. Как известно, 03 декабря 2004 года был выдан сертификат на ОС Windows XP Professional, т.е. была проведена оценка уровня функциональной безопасности данного системного средства. Не будем в этой работе останавливаться на вопросах анализа актуальности используемых требований для оценки эффективности защиты ОС в современных условиях (данная работа посвящена исследованию иных вопросов). Сертификация данного системного средства позволила некоторым поставщикам услуг в области защиты информации декларировать следующее: Применение сертифицированной ОС Microsoft позволяет легально обрабатывать на клиентских рабочих местах конфиденциальную информацию, защищаемую в соответствии с законодательством Российской Федерации. Преимущества использования сертифицированной ОС:
Весьма оптимистичные заявления – все здорово, особо заниматься вопросами безопасности и не стоит, достаточно установить сертифицированную ОС! Больше всего в подобных высказываниях шокирует то, что использование сертифицированной ОС снижает требования к объему знаний администратора безопасности. Но ведь именно высокая квалификация лиц, отвечающих за безопасность обработки информации на предприятии, является одним из необходимых условий эффективного решения задач защиты! Именно квалификация администраторов безопасности, на наш взгляд, является на сегодняшний день и одной из основных проблем защиты информации в корпоративных приложениях. Может быть, правильнее, говорить о необходимости повышения квалификации?! Однако попытаемся проанализировать, как же обстоят дела с безопасностью современных системных средств на самом-то деле, ведь ранее мы говорили, что истинным мерилом эффективности защиты системного средства является обеспечиваемый им уровень эксплуатационной безопасности. Напомним читателю, что характеристиками, используемыми при оценке уровня эксплуатационной безопасности системного средства, являются интенсивности отказов и восстановления средства защиты (соответственно, интенсивности обнаружения и устранение уязвимостей). Рассмотрим данные характеристики для исследуемого системного средства (с учетом того, что анализ уровня его функциональной безопасности проведен в декабре 2003 года) по порядку. Сначала об интенсивности обнаружения уязвимостей в ОС. Воспользуемся данными, опубликованными в открытой печати, в частности на сайтах www.itsec.ru и www.cnews.ru (в порядке замечания отметим, что автор не занимался систематическим сбором и анализом соответствующей статистики, которой, кстати говоря, предостаточно - это лишь некая подборка эпизодических данных):
По данным mi2g ежегодно хакерами взламывается до 90% сетей предприятий. Динамика роста обнаруженных уязвимостей представлена на рис.2.  Рис. Динамика роста обнаруженных уязвимостей * — за 7 месяцев
Рассматривая данную статистику обнаружения уязвимостей ОС, поневоле задаешь вопрос, как все это вяжется с тем оптимизмом, которым мы были наделены в результате оценки уровня ее функциональной безопасности. Вернемся к рис.1, и посмотрим, о какой безопасности может идти речь, если число обнаруженных за год уязвимостей составляет десятки, если не сотни? Вот и вывод, в части определения места оценки уровня функциональной безопасности системного средства – это необходимая, но отнюдь не достаточная мера для объективной оценки истинной эффективности средства защиты! Теперь, в нескольких словах, об интенсивности исправления уязвимостей в ОС. На наш взгляд, весьма показателен следующий пример. Обратимся к публикации К.Касперски Обзор эксплойтов в журнале Хакер от декабря 12(9 2006, см. стр.60-6 Приведем без комментариев несколько выдержек из этой статьи Просто поразительно, как гиганты компьютерной индустрии реагируют на сообщения об ошибках, которые они не могут исправить. 22 октября 2004 года основатель группы Argeniss Information Security и ее CEO в одном лице – Cesar Cerrudo обнаружил серьезнейшую ошибку в Windows, о чем тут же сообщил в Microsoft. Но та продолжила выпускать дырявые операционные системы, а для уже существующей заплатка отсутствует и по сей день. Следующая выдержка …система не препятствует ремапингу секции с атрибутами чтения/записи, что позволяет любому локальному пользователю проникнуть на уровень ядра…. Далее По заявлению Argeniss Research Team, уязвимости подвержены W2K (до W2K SP и XP (до XP SP и не подвержены Server 2003 и Vista beta Что же нам, как потребителям, рекомендует автор этой статьи Официальной заплатки от Microsoft до сих пор нет, и все, что нам остается – это мигрировать на Server 2003 или Vista, в которых огрехи проектирования без лишнего шума были устранены (но, как известно, исправляя одну ошибку, Microsoft добавляет десяток новых; Vista – это не вариант, а вот над переходом на Server 2003 можно подумать). Чудовищно, критическая уязвимость существует более двух лет и не исправляется производителем. В это трудно поверить! Однако, исходный код эксплойта для данной уязвимости, в подтверждение сказанному, автор привел в своей статье. По крайней мере, в отношении XP SP2 он прав, (заметим, что наша проверка заняла не более пяти минут), уязвимость присутствует. Необходимость комплексной сертификации (комплексной оценки уровня безопасности) системных средств Проведенное выше исследование, надеемся, убедило читателя, что оценку эффективности защиты системного средства можно получить, лишь оценив уровень его функциональной и эксплуатационной безопасности в комплексе, т.к. только оценка функциональной и эксплуатационной безопасности в совокупности и могут дать объективный результат, который, по большому счету, и интересует потребителя средства защиты. С оценкой уровня функциональной безопасности все более или менее ясно, именно такая оценка должна осуществляться и осуществляется на сегодняшний день на практике при сертификации системного средства (правда, еще раз отметим, что краеугольным камнем оценки функциональной безопасности является обоснованная актуальность требований к механизмам защиты (достаточности и корректности реализации), применительно к современных условиям использования системного средства). Что же делать с оценкой уровня эксплуатационной безопасности? На наш взгляд – это вполне решаемая задача. Достаточно провести экспертную оценку и определиться с тем, каким значениям критерия эффективности - вероятности того, что в любой момент времени системное средство защищено, должно удовлетворять системное средство в процессе его эксплуатации. Предположим, при обработке конфиденциальной информации должно выполняться условие:  Мы не настаиваем на этом значении, приведенном лишь в качестве примера. Однако согласитесь, что принимать это значение менее 0,9, наверное, даже при защите открытых данных как-то неловко. А вот теперь, самое время напомнить читателю, одно из позиционируемых достоинств использования сертифицированной ОС (об этом мы говорили ранее): отсутствие необходимости установки дополнительных сертифицированных наложенных средств защиты информации. Возвратимся к исследованию, приведенному на рис.1, и повторим один из результатов проведенного исследования: из рис.1 следует, что если в среднем обнаруживается одна уязвимость в год (зеленая кривая на рис.1, при этом в среднем уязвимость (в частности, ошибка программирования) исправляется разработчиком за 1 месяц, то получаем в нашем гипотетически идеальном случае, что в любой момент времени объект защищен лишь с вероятностью 0, Так как, стоит серьезно заниматься вопросами безопасности, либо будем продолжать говорить об отсутствии необходимости установки дополнительных сертифицированных наложенных средств защиты информации? Продолжим. В процессе эксплуатации системного средства должна производиться периодическая (например, раз в год) сертификация или оценка уровня его эксплуатационной безопасности. Для этого достаточно иметь для отчетного периода статистику обнаружения и исправления уязвимостей в сертифицируемом системном средстве. Это позволит с использованием соответствующих математических моделей сделать расчет критерия эффективности. Если результат экспертизы будет удовлетворительным, системное средство соответствует – сертификация успешно пройдена, если нет, то системное средство не соответствует определенному для него классу защищенности, оно не должно при обеспечиваемом уровне эксплуатационной (заметим, истинной, а не гипотетической) безопасности использоваться в приложениях, требующих данного класса защищенности. Повысить уровень эксплуатационной безопасности системного средства можно различными способами. Во-первых, это, конечно же, задача производителя системного средства, если он претендует на отнесение системного средства к соответствующему классу защищенности, что позволяет его использование в соответствующих приложениях. Во-вторых, если производитель по каким-либо причинам не в состоянии справиться с этой задачей, повысить уровень эксплуатационной безопасности системного средства возможно с использованием добавочных средств защиты. Согласитесь, что с учетом проведенных выше исследований, иллюстрирующих сложившееся положение дел, основной тезис поставщиков сертифицированной ОС Windows XP Professional отсутствие необходимости установки дополнительных сертифицированных наложенных средств защиты информации выглядит мало обоснованным. Позиция же автора такова, что такие сложные системные средства, как современные ОС, особенно универсальные ОС, к каким относятся и ОС семейства Windows, не могут в принципе обеспечить высокого уровня информационной безопасности, какие механизмы защиты в них не реализовывай. Данная позиция основана на следующих соображениях. Во-первых, на практике мы, как правило, сталкиваемся с универсальными ОС, для которых априори задачи защиты информации не являются доминирующими, куда важнее универсальность – ведь одно и то же средство используется и в домашних условиях, и в корпоративных приложениях. А ведь производителю необходимо обеспечить высокие потребительские свойства системного средства, но в этих приложениях, они кардинально различны, а в некоторых случаях, просто противоположны. Во-вторых, это сложность системного средства. В нем всегда будут присутствовать ошибки, которые порою очень сложно (если в разумные сроки вообще возможно) исправить. Все это мы видели выше. Ну и, на конец, очень важной причиной можно считать современную тенденцию к быстрому моральному старению системных средств, в большой мере это относится опять же к универсальным ОС. Это приводит, на наш взгляд, к необоснованно частому выходу в свет новых версий ПО, как следствие, еще на не выявленные ошибки, накладываются все новые и новые. Как правило, при появлении нового системного средства, получаем и обвал обнаруженных в нем ошибок. Здесь, кстати говоря, приходим и к серьезному противоречию – с одной стороны, новые версии системных средств априори должны обладать более развитыми функциональными возможностями защиты, с другой стороны, не достаточная апробированность решений может привести к снижению эксплуатационной безопасности системного средства. Если же мы позиционируем необходимость использования средств добавочной защиты, понимая, что высокий уровень эксплуатационной безопасности производителям системных средств по ряду причин не обеспечить, то в данных предположениях к таким средствам (СЗИ НСД) могут быть сформулированы дополнительные требования: При построении СЗИ НСД в качестве ключевых должны решаться задачи устранения архитектурных недостатков механизмов защиты современных универсальных ОС, и противодействие атакам, основанным на ошибках в системном и прикладном ОС. СЗИ НСД должны строиться не по принципу добавления механизмов защиты к механизмам универсальной ОС, а по принципу их полного замещения. Теперь вернемся к вопросам комплексной оценки безопасности системного средства, но уже в предположении, что оно используется в совокупности с добавочной СЗИ НСД. А вот здесь интерес представляет то, в какой мере СЗИ НСД позволяет обеспечивать эффективную защиту системного средства при обнаружении в последнем уязвимостей (в частности, ошибок программирования). Таким образом, в данных приложениях рассмотренный выше подход, связанный с непрерывной (периодической) оценкой эксплуатационной безопасности системного средства, весьма уместен, но уже применительно к тому, какой уровень эксплуатационной безопасности обеспечивается СЗИ НСД. Заметим, что анализ уязвимостей системного позволяет формировать и дополнительные требования к функциональной безопасности, в данном случае, к механизмам защиты СЗИ НСД. Видим, что это является еще одной задачей комплексной оценки безопасности системного средства – периодический анализ требований к функциональной безопасности, на основании анализа причин снижения эксплуатационной безопасности (анализа уязвимостей, обнаруженных за отчетный период). Проиллюстрируем сказанное, для чего опять же обратимся к статистике обнаруженных уязвимостей:
Наверное можно сделать вывод, что с функциональной безопасностью ОС семейства Windows не все здорово, если ошибка в приложении позволяет преодолевать механизмы защиты, реализованные на уровне ядра. Но вернемся к одному из требований к защите системных средств, сформулированных нами выше. Рассмотрим, какой эффект защиты можно в данном случае получить, установив и настроив СЗИ НСД, позволяющей разграничивать права доступа процессов к ресурсам. Единые разграничения (заметим, достаточно грубые) к системным ресурсам для приложений Microsoft Office Word 2003, Microsoft Office Excel 2003, Microsoft Office Outlook 2003, обеспечивающие их корректное функционирование и минимизирующие последствия атаки на системные ресурсы, с использованием уязвимости этих приложений, вне зависимости от типа угрозы (вирусная атака, ошибка программирования и т.д.), представлены в Табл.1. В порядке замечания отметим, что при обращении к настройкам разграничительной политики доступа к ресурсам процессов офисных приложений, представленным в Табл.1, невольно возникает вопрос, о каком поведенческом анализаторе для этих процессов может идти речь (зачем он нужен), если механизмом контроля доступа к ресурсам им разрешены только те права доступа к системным ресурсам, без которых невозможно корректное их функционирование, а любые иные возможности доступа априори без всякого анализа исключаются. Заметим, что, если говорить о защите от макро-вирусов, то задача защиты системных ресурсов при этом, в отличие от средств сигнатурного анализа, решается в общем виде, т.к. становится неважным, известным ли, либо каким-либо новым макро-вирусом осуществляется атака. То же можно сказать и об уязвимостях, связанных с ошибками программирования. Однако задача защиты должна решаться не только применительно к системным ресурсам (сетевой диск и реестр ОС), но и применительно к данным. Для этого достаточно завести две папки. Одну использовать для постоянного хранения документов, куда запретить доступ приложениям, обладающим недекларируемыми свойствами. Другую применять для промежуточного хранения обрабатываемого документа, осуществив возможность копирования документов из одной папки в другую проводником, не обладающим недекларируемыми свойствами, например, процессом far.exe. В этом случае, при чтении документа из папки промежуточного хранения, только в эту папку будет разрешен доступ на запись приложению, которое может быть наделено недекларируемыми свойствами. После чтения документа доступ к папке, используемой для постоянного хранения документов, данному критичному приложению запрещен. Вот и решение в части защиты хранящейся на компьютере информации, опять же в общем виде – защита от атак на уязвимости, связанные с ошибками программирования приложений, с запуском макро-вирусов и т.д. и т.п. В порядке замечания отметим, что в статье представлен лишь некоторый пример использования, возможности же механизмов контроля доступа к объектам (ресурсам) для субъекта процесс очень широки, они позволяют эффективно противодействовать угрозам вирусных атака, сетевых атак, атак на ошибки в приложениях, атак с использованием недекларированных разработчиком функций приложений и др. На наш взгляд, без реализации в средстве защиты подобных механизмов, трудно вообще говорить о какой-либо эффективности данного средства. Таблица 1
Но вот еще одно исследование:
 Рис. Результаты исследования Читайте далее:  Проектирование видеосистем с учетом требований к безопасности объектов Гост р 51558-2008. каким ему быть ? Экономическая эффективность ни и окр в машиностроении Dx-tl304e – новый dvr компании mitsubishi electric Видеосервер domination на выставке в уфе Газовое пожаротушение требования британских стандартов Как измерять разрешающую способность ,попытка осмысления, Rustock.c - не миф, а реальность! Выставка ifsec 2008 ,11 - 20, Справка о проводноволновых средствах охраны О безопасности в великобритании и не только... половая безопасность О безопасности в великобритании и не только... голубей не кормить! О безопасности в великобритании и не только... дорога железная Максимальный спектр ит-услуг из одних рук Риф стринг-202 расширяет границы возможного
|
||||||||||||||||||||||||
