Написание эффективной политики безопасности

Выявление и анализ проблем могут помочь улучшить такой  параметр безопасности, как доступность. Обнаружив узкие места, можно  попытаться переконфигури-ровать или перенастроить систему, снова измерить производительность и т.д.

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

Задачи контроля целостности, как отдельного направления  защиты информации от НСД

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

В нормативных документах, в части реализации контроля целостности, сформулировано следующее требование: "В СВТ пятого класса защищенности должны быть предусмотрены средства периодического контроля за целостностью программной и информационной части  КСЗ" (практически, по своей сути, аналогично формулируется требование к контролю целостности и для АС 1Г). Однако, это весьма ограниченное требование (локальное), когда речь заходит о целом направлении защиты информации.

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

Рассмотрим достоинства  и недостатки защиты на прикладном уровне, по сравнению с защитой  на системном уровне.

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

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

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

С учетом сказанного можем сделать следующий важный вывод.

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

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

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

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

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

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

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

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

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

С учетом всего сказанного, можем сделать крайне важный вывод.

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