Эксплуатационная безопасность системных средств

Эксплуатационная безопасность системных средств.
Основные понятия и определения. Подход к оцениванию.
Требования к с СЗИ от НСД

А.Ю.Щеглов, д.т.н., проф.

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

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

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

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

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

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

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

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

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

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

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

λ, T_в

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

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

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

p(t)=e^-λt

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

T_но = 1 / λ

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

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

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

-  временем внедрения на защищаемый объект исправленной версии (обновления) средства защиты, включая ее установку и настройку администратором.

Соответственно имеем:

T_в = Т_у + Т_вн

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

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

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

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

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

μ = 1 / Т_в

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

K_i = T / (T + T_в)

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

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

К_нг = 1 - К_г 

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

Р₀ = 1 - λ / μ

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

λ / μ < 1

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

P₀ = 0

т.к. не выполнение этого условия означает неограниченный рост уязвимостей, что характеризует состояние полной незащищенности  системного средства, что определяется условием: 

Зависимости:

P₀ = f ( λ, μ )

для различных значений интенсивностей обнаружения уязвимостей (значения интенсивностей обнаружения уязвимостей заданы в единицах: число/год, а интенсивность устранения уязвимостей – ось абсцисс, заданы в 1/неделя – за сколько недель в среднем устраняется одна уязвимость), расчитанные с использованием нашей математической модели, приведены на рисунке.

 

Рисунок. Результаты исследований

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

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

Но обратимся к рисунку. Рассмотрим гипотетически идеальный случай – в среднем обнаруживается одна уязвимость в год (на рисунке - зеленая кривая). Это случай идеален, т.к. ошибки программирования, а следовательно и потенциальные уязвимости в системном средстве присутствуют всегда, продолжительность же эксплуатации в 1 год, вполне достаточна, чтобы они могли быть выявлены. Эта зависимость нам интересна с точки зрения того, как влияет на эксплуатационную безопасность интенсивность устранения уязвимостей. Видим, что подобное влияние весьма заметно. Из рисункаследует, что если в среднем уязвимость (в частности, ошибка программирования) исправляется разработчиком за 1 месяц, то получаем в нашем гипотетически идеальном случае, что в любой момент времени объект защищен уже с вероятностью лишь 0,9. А что такое 1 месяц на устранение ошибки в сложном системном средстве, его потребуется только тестировать после внесения исправления не меньше месяца, иначе сразу сталкиваемся с проблемами надежности (отказоустойчивости) и корректности функционирования системного средства. А ведь этот месяц включает в себя: обнаружение уязвимости злоумышленником и получение об этом информации производителем, собственно устранение уязвимости, в той или иной мере крупномасштабное тестирование системного средства после исправления, получение обновления потребителем и внедрение обновления в системное средство на объекте защиты. Месяц для выполнения  подобной совокупности условий – это очень мало!

Из рисунка видим, что уже при 10 обнаруженных и исправленных производителем уязвимостях в год, эксплуатационную безопасность системного средства можно охарактеризовать, что средство скорее не защищено, чем защищено. При 20 же и более уязвимостях, просто, на наш взгляд, не стоит и заикаться о какой-либо защищенности средства защиты – в этом случае, не смотря на реализованный набор механизмов защиты, можно говорить, что защита системного средства отсутствует, как таковая. Вот действительно объективная оценка уровня защищенности!

Переведем наши теоретические исследования в практическое русло и посмотрим, какова же реальная эксплуатационная безопасность современных универсальных ОС. Для этого приведем одну из множества публикуемых сегодня экспертных оценок: "В минувшем (2005) году в ОС Windows было выявлено 812 "дыр" (исследования US-CERT). Специалисты из McAfee отмечают, что из 124 "дыр", обнаруженных в Windows XP Professional на сайте Secunia (Security Provider), 29 так и осталось не устраненными, что дало компании основание присвоить Windows статус критически опасной ОС" (материал был взят из новостей, опубликованных на сайте www.cnews.ru от 12.01.06).

Ничего себе статистика! В системе координат на рисунке нам кривую по данным значениям не построить, все "сольется" в прямую линию со значением "0"! О какой защите здесь вообще можно говорить?! Вот и явное противоречие. С одной стороны, семейство ОС Windows сегодня, пожалуй, наиболее динамично развивающаяся универсальная ОС, в части расширения как набора механизмов защиты, так и их функциональных возможностей. С другой стороны, видим, что все это не оказывает сколько-нибудь заметного влияния на повышение эксплуатационной безопасности данных системных средств.

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

Нам здесь важны общие тенденции (какой смысл спорить о том, что в любой момент времени эксплуатируемая универсальная ОС защищена с вероятностью 0,05 или, скажем, 0,15, потребитель наш спор “не оценит”, когда ему необходимо обеспечить значение данного параметра, по крайней мере, 0,9, лучше 0,99). Проведенного же исследования, на наш взгляд, вполне достаточно, чтобы сделать соответствующие выводы. Выводы мы сделали, что дальше, какие существуют пути повышения эксплуатационной безопасности современных системных средств, в частности, универсальных ОС?

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

C точки зрения эксплуатационной безопасности недопустимо использование не поддерживаемых производителем системных средств (например, ОС Windows 9X), т.к. уязвимости в них не устраняются, т.е. для них имеем не выполнение условия стационарности, другими словами объект при этом защищен с вероятностью "0", т.е. полностью незащищен. Исходя из сказанного, по тем же причинам, следует предостеречь потребителя и от использования им свободно распространяемого ПО. Здесь также возникают вопросы, а устраняются ли в нем в принципе обнаруженные уязвимости, и если да, то с какой интенсивностью и кто за это несет ответственность (за это ПО не платятся деньги, т.е. априори никто не отвечает за его техническую поддержку и исправление ошибок).

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

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

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

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

Если говорить об интенсивности обнаружения уязвимостей, то она может быть снижена при использовании СЗИ от НСД ввиду следующего:

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

Если же говорить об интенсивности устранения уязвимостей, то она может быть повышена при использовании СЗИ от НСД ввиду следующего:

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

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

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

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

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

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

Приведем цитату: "Грэхем Ингрэм, главный управляющий австралийского подразделения Группы оперативного реагирования на чрезвычайные ситуации в компьютерной области (AusCERT) утверждает, что распространённые антивирусные приложения блокируют лишь около 20% недавно появившихся вредоносных программ. При этом популярные антивирусы пропускают до 80%  новых троянов, шпионов и других вредоносных программ. Это означает, что в восьми из десяти случаев недавно появившийся вирус может проникнуть на компьютер пользователя" (источник: www.itsec.ru  от 24.07.2006 г.), На наш взгляд, наличие подобных заявлений является вполне серьезным основанием для получения объективной оценки эксплуатационной безопасности антивирусных средств защиты.