Вы находитесь в разделе Типовых решений систем безопасности
Современные условия использования вычислительных средств диктуют необходимость новых требований к их защитеОснову реализации защиты компьютерной информации всегда составляла реализация разграничительной политики доступа к ресурсам. Это определено и в действующих сегодня нормативных документах в области защиты информации. Но не будем забывать, что эти документы практически в неизменном виде действуют уже более десяти лет. Что же изменилось за это время, при столь бурном развитии ИТ технологий, на что требуется обратить внимание? Наверное, самое основное изменение состоит в том, что персональный компьютер стал действительно персональным. Сегодня трудно представить себе ситуацию, когда одним и тем же компьютером пользуются несколько сотрудников предприятия. Но тогда возникает резонный вопрос: насколько актуальны и аргументированы на сегодняшний день требования и решения, состоящие в реализации разграничительной политики доступа к ресурсам между пользователями (между учетными записями), что, к слову сказать, реализуется в современных универсальных ОС и во многих СЗИ от НСД. Может быть, настала пора пересмотреть собственно задачи защиты, которые должны решаться разграничительной политикой доступа к ресурсам? Иначе, как оценить функциональную безопасность современных системных средств, если ими реализуются требования и технические решения, которые не могут быть использованы на практике в рассматриваемых приложениях, в чем тогда состоит (и как ее оценить) потребительская стоимость механизмов защиты ОС и СЗИ от НСД? Попытаемся ответить на этот, на наш взгляд, важнейший вопрос, диктующий ключевые принципы построения средств защиты информации. Рассмотрим, в чем могут в современных условиях состоять задачи реализации разграничительной политики доступа к ресурсам. В порядке иллюстрации предлагаемых подходов рассмотрим технические решения, реализованные и апробированные в КСЗИ Панцирь-К для ОС Windows 2000/XP/2003 (разработка ЗАО НПП Информационные технологии в бизнесе). Прежде всего, отметим, что функциональная безопасность системного средства определяется набором реализованных в нем механизмов защиты (не следует путать с эксплуатационной безопасностью, характеризуемой, в первой очередь, уязвимостью системного средства, связанной с наличием в нем и в приложениях ошибок программирования). Достигаемый уровень функциональной безопасности определяется реализацией двух типов требований – требованиями к корректности реализации механизмов защиты и требованиями к достаточности (полноте набора) механизмов защиты, применительно к условиям практического использования системного средства. Заметим, что данные требования и сформулированы в соответствующих нормативных документах в области защиты информации. Требования к корректности реализации механизмов защиты сформулированы в действующем сегодня нормативном документе Гостехкомиссия России. Руководящий документ. Средства вычислительной техники. Защита от несанкционированного доступа к информации. Показатели защищенности от НСД к информации, который используется при сертификации средств защиты. Требования к достаточности – полноте набора механизмов защиты, применительно к условиям использования системного средства, сформулированы в действующем сегодня нормативном документе Гостехкомиссия России. Руководящий документ. Автоматизированные системы. Защита от несанкционированного доступа к информации. Показатели защищенности от НСД к информации, используемом при аттестации объекта информатизации. Все достаточно логично, когда дело касается функциональной безопасности системного средства - если средство сертифицировано, т.е. экспертизой подтверждена корректность реализации в нем механизмов защиты, остается провести экспертизу достаточности их набора, применительно к условиям использования, т.е. применительно к конкретной аттестуемой АС. В порядке замечания отметим, что анализ уровня функциональной безопасности системного средства отнюдь не дает оценки его истинной безопасности. Это мы видим на примере современных универсальных ОС, уровень эксплуатационной безопасности которых ничтожно мал (подобное исследование мы провели в одной из своих опубликованных на сайте www.itsec.ru работ). Однако в данной работе мы будем говорить о функциональной безопасности системных средств. Продолжая наше исследование, попытаемся сформулировать особенности использования современных персональных компьютеров в корпоративных приложениях. Мы ранее отмечали, что использование персонального компьютера, в большинстве корпоративных приложений стало действительно персональным – в рамках выполнения своих служебных задач на нем должен работать только один сотрудник предприятия, т.е. должна быть заведена только одна его учетная запись. Но мы говорим о корпоративных приложениях, для которых существует свое правило использования вычислительных средств, и состоит оно в следующем. Основу защиты современных универсальных ОС составляет возможность заведения учетных записей с различными привилегиями. Одной из ключевых учетных записей является запись с привилегией администратора. При работе под этой учетной записью, по существу, какая-либо защита системного средства отсутствует – можно остановить/запустить любую системную службу, установить/удалить драйвер и т.д. Т.е. сотрудник работать с правами администратора системы априори не должен. Вместе с тем, кто-то должен задавать права доступа сотруднику к ресурсам (с какой целью – рассмотрим ниже). Это вызвано двумя причинами. Во-первых, нельзя требовать от каждого сотрудника предприятия каких-либо серьезных знаний вопросов информационной безопасности (это просто глупо), т.е. этими вопросами должен заниматься специалист - выделенный сотрудник – администратор, во-вторых, необходимо учитывать, что сотрудник, по ряду причин, также может рассматриваться в качестве потенциального злоумышленника (инсайдера). Таким образом, получаем, что при реализации защиты персонального компьютера в системе должны быть заведены две учетные записи, одна из которых с правами администратора. При этом администратор должен разграничивать права доступа к ресурсам сотрудника, а какие-либо разграничения для учетной записи администратора просто не имеют смысла. Как видим, что о каких-либо разграничениях прав доступа между пользователями (между учетными записями) в данных приложениях речи не идет! Условие корректности реализации разграничительной политики доступа к ресурсам для персонального компьютера. Прежде всего, напомним основные понятия, которые нами будут здесь использованы. Идентификация — это процесс распознавания элемента системы, обычно с помощью заранее определенного идентификатора или другой уникальной информации; каждый субъект или объект системы должен быть однозначно идентифицируем. Аутентификация — это проверка подлинности идентификации пользователя, процесса, устройства или другого компонента системы (обычно осуществляется перед разрешением доступа). Ранее мы показали, что в рассматриваемых приложениях в системе должны быть заведены две учетные записи (сотрудника и администратора), при этом администратор должен разграничивать права доступа к ресурсам для учетной записи сотрудника, а для учетной записи администратора каких-либо разграничений назначать не имеет смысла. Естественно, что механизмами идентификации и аутентификации (здесь, парольная защита) должен быть реализован санкционированный вход пользователя в систему под учетной записью сотрудника или администратора (но это очевидно, решений множество, рассматривать эту задачу далее не будем). Чтобы далее вести разговор о том, что для персонального компьютера в рассматриваемых приложениях отсутствует необходимость в реализации разграничительной политики доступа к ресурсам между учетными записями, необходимо предусмотреть противодействие входу в систему под несанкционированно заведенной в системе иной учетной записью (для которой права доступа к ресурсам администратором не задаются), а также противодействие несанкционированной смене учетной записи (повышения привилегий) сотрудника при осуществлении им доступа к ресурсам (подобную возможность предоставляет реализуемый современными универсальными ОС сервис олицетворения). Сервис олицетворения (impersonation) предоставляет возможность отдельному потоку выполняться в контексте защиты, отличном от контекста защиты процесса, его запустившего, т.е. запросить олицетворить себя с правами другого пользователя, в результате - действовать от лица другого пользователя. Как следствие, возникают вопросы корректности идентификации и аутентификации пользователя при запросе доступа к ресурсам, а задача идентификации и аутентификации пользователей при запросах на доступ сводится к контролю корректности олицетворения. В порядке замечания отметим, что одним из требований, сформулированных в соответствующем нормативном документе: “КСЗ должен обеспечивать идентификацию пользователей при запросах на доступ…, как раз и предусмотрено решение задачи контроля корректности олицетворения. В общем виде решение этой задачи должно состоять в следующем. При запросе доступа к ресурсу должны выявляться факты произошедшего олицетворения (соответственно, субъектом доступа здесь выступает процесс, для которого анализируется наличие олицетворяющего маркера доступа) и проверяться их корректность в соответствии с заданными разрешениями (запретами). Таким образом, в качестве субъекта доступа выступает процесс (в том числе, это обусловливается и тем, что различные процессы (приложения) могут затребовать и различных правил разрешенных (запрещенных) олицетворений, что невозможно обеспечить, если в качестве субъекта доступа для данного механизма защиты принять пользователя - учетную запись). На Рис.1 представлен интерфейс, реализованного в КСЗИ Панцирь-К для ОС Windows 2000/XP/2003, механизма Проверка олицетворения субъектов доступа. Механизм защиты, реализованный в КСЗИ Панцирь-К, предполагает возможность назначить разрешительную, либо запретительную политику смены первичного маркера для процессов, причем в качестве субъекта доступа здесь выступает процесс (может задаваться полнопутевым именем, именем папки – одинаковые разграничения действую для всех процессов, запускаемых из этой папки, маской), что обеспечивает максимальную гибкость применения механизма; а в качестве объектов разграничений – пара: исходный меркер безопасности (исходное имя пользователя) и маркер безопасности, на который разрешается, либо запрещается менять исходный маркер (эффективное имя пользователя), с которым осуществляется доступ к ресурсам. Для любого субъекта доступа (процесса) может быть реализована разрешительная или запретительная политики смены первичного маркера.  Рис.1 Настройками механизма защиты, представленными на Рис.1, обеспечивается решение следующей задачи – для любого процесса (субъект задается маской *) запрещена смена идентификатора User1 (учетная запись сотрудника) на идентификатор Administrator (учетная запись администратора). Другими словами, сотрудник не может получить неограниченные права доступа к ресурсам, предоставляемые учетной записи администратора. Другая задача, как отмечали ранее, состоит в предотвращении возможности входа в систему под некой новой учетной записью, несанкционированно созданной, для которой администратором не установлены права доступа к ресурсам. Это реализуется настройками механизма защиты, представленными на Рис.2, обеспечивающими возможность входа в систему лишь под двумя учетными записями, вне зависимости от того, сколько их будет зарегистрировано в системе (в том числе, и несанкционированно), что реализуется соответствующими правилами олицетворения пользователя System, устанавливаемыми для процесса winlogon.  Рис.2 Итак, что же мы в результате использования рассмотренного механизма защиты получили? В системе всегда присутствует только одна учетная запись, под которой может работать сотрудник при любых условиях. Т.е. корректно реализовали наиболее часто используемую сегодня в корпоративных приложениях схему применения персонального компьютера: персональный компьютер – один сотрудник, использующий вычислительное средство – одна учетная запись, используемая для обработки информации на компьютере. В этом случае задача реализации разграничительной политики доступа к ресурсам между пользователями (между учетными записями) уже теряет свою актуальность! Следует говорить о разграничительной политики доступа к ресурсам для персонального компьютера. При этом субъектом доступа становится сущность система - персональный компьютер или приложение (функциональная задача сотрудника), объектом доступа ресурс. Рассмотрим, принципы реализации разграничительной политики доступа к ресурсам в данных условиях. Требование к достаточности (полноте набора) механизмов защиты применительно к условиям использования системного средства для персонального компьютера Еще раз напомним, что требования к достаточности – полноте набора механизмов защиты, применительно к условиям использования сформулированы в действующем сегодня нормативном документе (Гостехкомиссия России. Руководящий документ. Автоматизированные системы. Защита от несанкционированного доступа к информации. Показатели защищенности от НСД к информации). Данный нормативный документ используется при аттестации объектов информатизации. Например, в части защиты конфиденциальной информации это требования к классу АС 1Г. Применительно к рассматриваемым нами вопросам реализации разграничительной политики доступа к ресурсам, остановимся на следующем всеобъемлющем требовании:
Таким образом, данное требование предполагает, что ко всем используемым в системе защищаемым ресурсам (файловые объекты, объекты реестра ОС, внешние накопители, сетевые ресурсы и т.д.; вообще говоря, практически невозможно, применительно к какому-либо компьютерному ресурсу, заявить, что он не требует защиты, т.е. не может использоваться либо в качестве, либо для создания канала НСД к информации) средством защиты должен быть реализован контроль доступа. Другими словами, это требование можно сформулировать следующим образом: Есть ресурс – к нему должен контролироваться доступ, не контролируется доступ – не должно быть ресурса. Вот основополагающее требование к достаточности набора механизмов, а самое главное, правило, на основании которого может быть определена область практического использования средства защиты. На наш взгляд, именно в подобной трактовке данное требование снимает все неоднозначности, которые могут возникнуть при аттестации объекта информатизации. Однако под контролем доступа к ресурсам здесь понимается разграничение прав доступа между пользователями. Это следует из другого нормативного документа, формулирующего требования к корректности реализации механизмов защиты. Требования к корректности реализации механизмов защиты сформулированы в действующем сегодня нормативном документе (Гостехкомиссия России. Руководящий документ. Средства вычислительной техники. Защита от несанкционированного доступа к информации. Показатели защищенности от НСД к информации). Например, в части реализации разграничительной политики доступа к ресурсам для средств, предназначенных для защиты конфиденциальной информации (5 класс СВТ), данные требования формулируются следующим образом:
В рассматриваемых же нами приложениях только один субъект доступа (один сотрудник, для работы которого на персональном компьютере заводится одна учетная запись). Следовательно, в качестве субъекта доступа здесь уже необходимо рассматривать сущность система, в качестве ресурсов – устройства, а контроль должен осуществляться в части разрешения (запрета) монтирования устройств к системе (о разграничении доступа пользователей к устройствам, в том числе и к файловым объектам, речь уже не идет). С учетом всего сказанного, требование к достаточности (полноте набора) механизмов защиты применительно к условиям использования системного средства для персонального компьютера может быть сформулировано следующим образом:
Другими словами, это требование можно сформулировать следующим образом: Есть необходимость в ресурсе (устройстве) для работы сотрудника на персональном компьютере – ресурс (устройство) должен быть подключен (смонтирован) к системе, нет - не должна предоставляться возможность подключения (монтирования) ресурса (устройства) сотрудником. Вот, на наш взгляд, основополагающее требование к достаточности набора механизмов, а самое главное, правило, на основании которого может быть определена область практического использования средства защиты персонального компьютера (в рассматриваемых приложениях). Естественно, что данный механизм реализован корректно только в том случае, если он позволяет возможность контролировать подключение (монтирование) всех возможных устройств к системе. В порядке иллюстрации реализации данного основополагающего механизма защиты персонального компьютера, на Рис.3 – Рис.6 проиллюстрированы интерфейсы его настройки в КСЗИ Панцирь-К. Заметим, что очень важным свойством реализации контроля монтирования устройств является возможность идентификации конкретного устройства по его серийному номеру изготовителя (что реализовано в КСЗИ Панцирь-К), обеспечивающая возможность разрешать подключение сотрудником конкретных устройств, например, конкретного Flash - устройства. Серийный номер отображается при выборе меню Информация для конкретного устройства, см. Рис.  Рис.3  Рис.4  Рис.5  Рис.6 Итак, с вопросами достаточности набора механизмов защиты, применительно к условиям использования системного средства для персонального компьютера мы определились. Теперь сотрудник сможет работать только с теми ресурсами (устройствами), которые ему необходимы для выполнения своей служебной деятельности. В системе заведена только одна учетная запись, которая может быть использована для обработки информации. Выходит, что отсутствуют субъекты, между которыми следует разграничивать права доступа, т.е. еще какой-либо контроль доступа к ресурсам нам не нужен? А если нужен, то что контролировать, между чем (учетная запись одна) и с какой целью разграничивать доступ к ресурсам, к каким ресурсам? Какие задачи контроля доступа к ресурсам сегодня восстребованы в рассматриваемых приложениях, и почему? Попытаемся разобраться с этими вопросами. Задачи контроля доступа к ресурсам для персонального компьютера Как правило, угрозы компьютерной безопасности делят на внешние и внутренние ИТ угрозы. Внешние угрозы обусловливаются возможностью атаки на информационные и системные компьютерные ресурсы из сети. Внутренние – санкционированным пользователем, допущенным к обработке информации на защищаемом компьютере (инсайдером). При этом в качестве объектов защиты следует рассматривать как информационные ресурсы (в части нарушения их конфиденциальности или доступности, в первую очередь, за в результате несанкционированной модификации), так и системные ресурсы – объекты системного диска, реестра ОС. Достаточно обратиться к анализу существующей статистики уязвимостей современных системных средств (например, на сайте www.itsec.ru, систематически публикуемой в разделе Новости), чтобы показать, что в общем случае именно процесс следует рассматривать в качестве источника возникновения внешней ИТ-угрозы. Может быть предложена следующая классификация процессов, в основу которой положено группирование свойств процессов, порождающих внешние ИТ-угрозы:
С учетом сказанного, напрашивается следующая концепция противодействия внешним ИТ-угрозам. Ввиду того, что именно процесс несет в себе уязвимость, т.е. именно процесс следует рассматривать в качестве источника возникновения внешней ИТ-угрозы, защита от внешних ИТ-угроз может быть реализована по средством реализации разграничительной политики доступа к ресурсам для субъекта процесс, что позволяет локализовать внешнюю ИТ-угрозу, путем локализации прав доступа к ресурсам процессов. Целью же локализации прав доступа процессов является защита системных ресурсов вычислительного средства и обрабатываемых на нем конфиденциальных данных. Видим, что эта концепция полностью укладывается в вопросы защиты персонального компьютера в рассматриваемых приложениях (одна учетная запись для работы одного сотрудника). Таким образом, в данных (наиболее сегодня востребованных на практике) приложениях кардинально должна быть изменена сама суть разграничительной политики доступа к ресурсам (к объектам файловой системы, к объектам реестра ОС, к сетевым ресурсам и т.д.) – в качестве субъекта доступа должен рассматриваться процесс, для которого должны устанавливаться разграничения прав доступа. Суть назначения данных разграничений состоит в защите информационных и системных ресурсов от внешних ИТ угроз. Заметим, что подобная, на наш взгляд, наиболее сегодня востребованная на практике задача защиты информации, не сформулирована в нормативных документах в области защиты информации, как следствие, не решается и большинством известных нам СЗИ от НСД (невольно возникает вопрос об их назначении, либо потребительской стоимости), не решается она и большинством современных универсальных ОС, что, как следует из существующей статистики успешных атак, делает их уязвимыми. Теперь рассмотрим примеры механизмов защиты, реализованных в КСЗИ Панцирь-К в части реализации предложенной концепции защиты информации для персональных компьютеров. На Рис.7 представлен интерфейс (реализованный в КСЗИ Панцирь-К) настройки разграничений прав доступа процессов к объектам файловой системы (на жестком диске и на внешних накопителях, локальных и разделенных в сети, для разделенных – по исходящему и входящему запросам доступа).  Рис.7 Посмотрим на настройки разграничительной политики доступа к ресурсам, заданные в интерфейсе. Видим, что любому процессу (маска *) разрешен запуск исполняемых файлов только из двух системных каталогов и запрещена возможность модификации этих каталогов. Очевидно, что реализовав подобную разграничительную политику доступа к ресурсам вы в принципе забудете о каких-либо вредоносных программах, в том числе, шпионских, троянских и т.д. Вот решение всех ваших проблем! В порядке замечания отметим, что под данные разграничения подпадают и все системные процессы (здесь не важно под какой учетной записью запускается процесс). Для обеспечения работоспособности системы при данных настройках некоторым системным процессам, таким, как winlogon.exe, lsass.exe, csrss.exe, svchost.exe, services.exe необходимо разрешить право записи на системный диск. Однако это не приведет к снижению безопасности системы, т.к. данные системные процессы не имеют пользовательского интерфейса. Теперь об ошибках приложений. Они связаны с уязвимостью ОС (из-за соответствующих архитектурных недостатков встроенной в ОС защиты – ошибка в приложении не должна приводить к предолению механизма защиты, реализованного на системном уровне). Их систематическое выявление и высокая продолжительность исправлений сводят на нет всю защиту системного средства. Применим наш подход, помятуя о том, что защищать необходимо как информационные, так и системные ресурсы. Для защиты данных выделим отдельный каталог для работы с приложением (либо с приложениями, безопасность которых нас по каким-то причинам беспокоит), и соответствующему процессу приложения разрешим доступ к данным только в этом каталоге. Какая бы ни была обнаружена ошибка в приложении, возможность получения несанкционированного доступа к защищаемым данным (хранящимся в иных каталогах) мы предотвратили. Теперь, в порядке примера, рассмотрим реализацию разграничительной политики доступа к системным ресурсам для наиболее часто используемых на практике сетевых приложений, при которых обеспечивается корректность их функционирования. Разграничения для соответствующих процессов данных приложений приведены в Табл.1 – Табл. Посмотрите внимательно на эти настройки. Что сможет сделать злоумышленник, используя известную ему ошибку в сетевом приложении? Вот решение, применительно к защите от атак на критичные и скомпрометированные процессы. Таблица 1
На Рис.8 представлен интерфейс (реализованный в КСЗИ Панцирь-К) настройки разграничений прав доступа процессов к объектам сети. Заметим, чтобы запретить доступ в сеть всем процессам, кроме назначаемых администратором, достаточно в интерфейсе внести строку, состоящую в том, что для субъекта процесс, задаваемого маской *, запрещен любой тип доступа к любому ресурсу. Затем вводить разрешения, какому процессу, а при необходимости, какой тип и к каким сетевым объектам следует разрешить.  Рис.8 Естественно, что объект доступа здесь должен идентифицироваться в общем случае (как по адресу, так и по сетевому имени), см. Рис.9, иначе на практике данный механизм защиты будет мало востребован.  Рис.9 Если же вести речь о процессах, априори обладающих недекларируемыми разработчиком (документально не описанными) возможностями, то и в этом случае может быть эффективно использован рассмотренный подход, состоящий в задании разграничительной политики доступа к ресурсам для субъекта доступа процесс. Здесь решение состоит в том, чтобы наделить процессы, априори обладающие недекларируемыми возможностями, например, процессы офисных приложений, такими правами, чтобы минимизировать последствия их несанкционированных действий. Это касается не только системных ресурсов (сетевой диск и реестр ОС), но и папок с данными. Для этого достаточно завести две папки. Одну использовать для постоянного хранения документов, куда запретить доступ приложенияю, обладающему недекларируемыми свойствами, другую, для промежуточного хранения обрабатываемого документа, осуществив возможность копирования документов из одной папки в другую проводником, не обладающим недекларируемыми свойствами, например, процессом far.exe. В этом случае, при чтении документа из папки промежуточного хранения, только в эту папку будет разрешен доступ на запись приложению, которое может быть наделено недекларируемыми свойствами после чтения документа, доступ к папке, используемой для постоянного хранения доркументов данному критичному приложению запрещен. В результате получаем весьма эффективную возможность противодействия вирусам (заражение исполняемых файлов), макро-вирусам и т.д. То же касается скриптов и апплетов. Разрешите соответситвующему процессу чтение (заметим, здесь уже не выполнение) из определенной папки, куда запретите всем приложениях доступ на запись, и разместите в этой папке необходимые для запуска объекты. Задач защиты и решений здесь можно предложить массу. Например, достаточно запретить офисным приложением запуск библиотеки vbe6intl.dll и запустить макро-вирус станет невозможно в принципе. Главное, что все эти задачи подпадают под модель защиты, отличающуюся тем, что в качестве субъекта доступа выступает сущность процесс. Вкратце коснемся вопросов защиты от внутренних ИТ-угроз. Для решения этой задачи, как правило, необходимо разграничивать функции обработки данных различных категорий конфиденциальности. Например, сотрудник на одном и том же компьютере обрабатывает конфиденциальные данные и открытые (должен иметь доступ в сеть Интернет), причем конфиденциальные данные не должны попасть в сеть. Здесь также можем использовать рассматриваемый подход. Разрешим доступ в сеть конкретному приложению и запретим ему доступ к папке, где хранятся конфиденциальные данные – создадим отдельную папку для работы с сетью и только к этой папке разрешим доступ сетевому приложению, всем остальным процессам доступ к этой папке (по крайней мере, на запись) запретим. Получим, что это приложение не сможет отправить конфиденциальные данные в сеть. Остается еще буфер обмена, как основное средство межпроцессного взаимодействия (остальные способы перекрываются тем, что в системе разрешается запускать только санкционированные процессы, об этом, правда, для решения иной задачи, было сказано ранее). Т.е. буфер обмена здесь следует рассматривать в качестве объекта доступа, в качестве субъекта – опять же процесс. Решение состоит в том, что необходимо запретить доступ к буферу обмена процессу, реализующему доступ в сеть. На Рис.10 представлен интерфейс (реализованный в КСЗИ Панцирь-К) управления доступом к буферу обмена. Настройками в интерфейсе, приведенном на Рис.10, соответствующему процессу запрещено использование буфера обмена.  Рис.10 А теперь проанализируем все сказанное. Что же мы получаем? А получаем мы, что в рассматриваемых приложениях – защита персонального компьютера, наиболее актуальные сегодня задачи защиты информации (для обоснования актуальности достаточно предложить читателю познакомиться с существующей мировой статистикой успешных атак, и их причин, на персональные компьютеры), такие как, противодействие запуску вредоносного кода, включая троянские программы, противодействие шпионским программам и шпионским (недекларируемым) функциям санкционированно используемых программ, противодействие атакам на ошибки в системном и прикладном ПО, антивирусное противодействие, противодействие инсайдерам и т.д., может быть эффективно реализовано лишь при кардинальном пересмотре самих принципов реализации разграничительной политики доступа к ресурсам. В качестве субъекта доступа, для которого реализуется разграничительная политика, в этих приложениях уже необходимо рассматривать сущность процесс. Найдите упоминание об этом в существующих нормативных документах в области защиты информации. А ведь именно эти документы используются при сертификации средств защиты, т.е., по большому счету, и для оценки уровня функциональной безопасности системного средства. Как видим, современные условия использования вычислительных средств диктуют необходимость новых требований к их защите! Читайте далее:  Ах ты, камбала - не вобла... Ежегодный анализ тайваньского рынка безопасности. Комментарий к security 50 04 - 10 февраля 2008 года Созидающая волоконная оптика 08 - 09 марта 2008 года 14 - 20 апреля 2008 года ,рынок it, 28 - 30 апреля 2008 года ,рынок безопасности, 01. 04. 2008 05 - 11 мая 2008 года ,рынок безопасности, 12 - 18 мая 2008 года ,рынок it, 26 - 31 мая 2008 года ,рынок it, Организация строительно-монтажных, пусконаладочных работ и ввода в эксплуатацию интегрированных сист Наш опыт прокладки кабелей Заземление в системах промышленной автоматизации ,часть 2,
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
