Вы находитесь в разделе Типовых решений систем безопасности
Контроль целостности и аудит событийПодчас, на практике к решению таких задач защиты информации, как контроль целостности и аудит событий, относятся несколько поверхностно, не очень заботясь о том, как эти задачи защиты решены в СЗИ от НСД. Вместе с тем, это очень важные задачи (если не относится к ним поверхностно), которые в большой мере взаимосвязаны, если речь заходит о построении эффективного средства защиты информации. В данной работе попытаемся взглянуть на данные задачи защиты несколько шире, чем общепринято, что позволит совсем иным образом их спозиционировать. Предлагаемые нами подходы к решению рассматриваемых задач проиллюстрируем на примере их реализации в Комплексной системе защиты информации (КСЗИ) Панцирь-К для ОС Windows 2000/XP/2003 (разработка ЗАО НПП Информационные технологии в бизнесе, сертификат ФСТЭК №1144 от 17.01.200 .Задачи контроля целостности, как отдельного направления защиты информации от НСД К задаче контроля целостности необходимо подходить с двух позиций. Во-первых, необходимо дать ответ на вопрос, с какой целью реализуется контроль целостности. Дело в том, что при корректном реализации разграничительной политики доступа к ресурсам их целостность не может быть несанкционированно нарушена. Отсюда напрашивается вывод, что целостность ресурсов следует контролировать в том случае, когда невозможно осуществить корректное разграничение доступа (например, запуск приложения с внешнего накопителя – для внешних накопителей замкнутость программной среды уже не реализовать), либо в предположении, что разграничительная политика может быть преодолена злоумышленником. Это вполне резонное предположение, т.к. СЗИ от НСД, обеспечивающую 100% защиту, построить невозможно даже теоретически. Во-вторых, необходимо понимать, что контроль целостности – это весьма ресурсоемкий механизм, поэтому на практике допустим контроль (а тем более с высокой интенсивностью, в противном случае, данный контроль не имеет смысла) лишь весьма ограниченных по объему объектов. В нормативных документах, в части реализации контроля целостности, сформулировано следующее требование: В СВТ пятого класса защищенности должны быть предусмотрены средства периодического контроля за целостностью программной и информационной части КСЗ (практически, по своей сути, аналогично формулируется требование к контролю целостности и для АС 1Г). Однако, это весьма ограниченное требование (локальное), когда речь заходит о целом направлении защиты информации. Рассмотрим, в чем же состоит принципиальная особенность защиты информации на прикладном уровне, и чем это обусловливается. Естественно, что реализация какой-либо разграничительной политики доступа к ресурсам (основная задача СЗИ от НСД) на этом уровне не допустима (потенциально легко преодолевается злоумышленником). На этом уровне могут решаться только задачи контроля, основанные на реализации функций сравнения с эталоном. При этом априори предполагается, что с эталоном могут сравниваться уже произошедшие события. Т.е. задача защиты на прикладном уровне состоит не в предотвращении несанкционированного события, а в выявлении и в фиксировании факта того, что несанкционированное событие произошло. Рассмотрим достоинства и недостатки защиты на прикладном уровне, по сравнению с защитой на системном уровне. Основной недостаток состоит в том, что на прикладном уровне в общем случае невозможно предотвратить несанкционированное событие, т.к. контролируется сам факт того, что событие произошло, поэтому на подобное событие лишь можно отреагировать (максимально оперативно), с целью минимизаций его последствий. Основное достоинство состоит в том, что факт того, что произошло несанкционированное событие, может быть зарегистрирован практически всегда, вне зависимости от того, с какими причинами связано его возникновение (так как регистрируется сам факт подобного события). Проиллюстрируем сказанное простым примером. Один из основных механизмов защиты в составе СЗИ от НСД является механизм обеспечения замкнутости программной среды (суть – не дать запускать любые сторонние процессы и приложения, вне зависимости от способа их внедрения на компьютер). Данная задача должна решаться на системном уровне. При решении задачи на системном уровне, драйвер средства защиты перехватывает все запросы на запуск исполняемого файла и анализирует их, обеспечивая возможность запуска лишь разрешенных процессов и приложений. При решении же аналогичной задачи на прикладном уровне осуществляется анализ того, какие процессы и приложения запущены, и если выявляется, что запущен несанкционированный процесс (приложение), он завершается средством защиты (реакция СЗИ от НСД на несанкционированное событие). Как видим, преимуществом реализации на системном уровне является то, что при этом должен в принципе предотвращаться запуск несанкционированных процессов (приложений), при реализации же на прикладном уровне, событие фиксируется по факту совершения, т.е. в данном случае – уже после того, как процесс запущен, как следствие, до момента его завершения средством защиты (если установлена такая реакция на такое событие), данным процессом может быть выполнено какое-либо несанкционированное действие (по крайней мере, его часть, почему важнейшим условием здесь и становится оперативное реагирование на обнаруженное событие). С другой стороны, а кто может гарантировать, что системный драйвер, решает данную задачу защиты корректно и в полном объеме, а потенциальная опасность, связанная с ошибками и закладками в системном и прикладном ПО и т.д.? Другими словами, никогда нельзя гарантировать, что системный драйвер не может быть обойден злоумышленником при определенных условиях. Что мы получим в первом случае – администратор даже не узнает о том, что совершен факт НСД. При реализации же решения задачи на прикладном уровне, уже не важна причина, приведшая к возникновению несанкционированного события, так как фиксируется сам факт проявления данного события (даже, если оно вызвано использованием ошибок и закладок ПО). В этом случае, мы зарегистрируем, что событие произошло, однако, не сумеем его предотвратить в полном объеме, лишь можем попытаться минимизировать последствия. С учетом сказанного можем сделать следующий важный вывод. Механизмы защиты, призванные решать одну и ту же задачу на системном и на прикладном уровнях, ни в коем случае нельзя рассматривать в качестве альтернативных решений. Эти решения дополняют друг друга, так как предоставляют совершенно различные свойства защиты. Следовательно, при реализации эффективной защиты (в первую очередь, речь идет о корпоративных приложениях) наиболее критичные задачи должны решаться одновременно обоими способами: и на системном, и на прикладном уровнях. Теперь попытаемся понять, а так ли действительно ограничены возможности механизмов защиты прикладного уровня в части предотвращения несанкционированного доступа к защищаемым информационным ресурсам. Итак, основой защиты на прикладном уровне должна являться непрерывная регистрация событий, происходящих в системе, и их контроль, посредством сравнения с заданным (эталонным) списком санкционированных (разрешенных) событий. Поскольку реализующие данное решение механизмы – это механизмы защиты, а не аудита, то на любое зарегистрированное в системе несанкционированное событие соответствующий механизм прикладного уровня должен вырабатывать реакцию, призванную минимизировать последствия несанкционированного события (например, завершать несанкционированный процесс). А теперь перейдем к самому главному. Любое действие пользователя представляет собою не некое единичное событие, а их некую последовательность. Например, доступ пользователя к ресурсу может быть охарактеризован соответствующим набором последовательно выполняемых событий: вход в систему под своей учетной записью, запуск приложения, которое может обращаться к реестру и к системным настройкам, формирование запроса, возможно формирование запроса олицетворения и т.д.. Каждое из этих событий может контролироваться в соответствии со списком санкционированных – разрешенных, либо несанкционированных – запрещенных событий (например, списком разрешенных для регистрации в системе пользователей, списком разрешенных олицетворений для учетных записей, списком разрешенных для пользователя к запуску процессов, списком ключей реестра ОС, разрешенных для изменения, списком устройств, к которым разрешен доступ пользователю и т.д.). Следовательно, посредством контроля отдельных событий в системе, появляется возможность контроля санкционированности действий пользователей в целом, что в КСЗИ Панцирь-К реализовано следующим образом. В системе выделяются те события, которые в совокупности, но по отдельности, нужно контролировать, чем может достигаться контроль действия в целом, см. рис. Создается эталонная копия свойств каждой контролируемой группы (списка санкционированных событий). Каждый из списков формирует отдельный уровень контроля. Свойства системы считаются нарушенными в случае расхождения эталонной копии и оригинала при контроле любого из списков. В процессе работы защищаемой системы осуществляется контроль событий, путем сравнения эталонных копий списков каждого уровня и их эталонных значений. При расхождении генерируется состояние нарушения безопасности системы, реакцией на которое может быть восстановление целостности контролируемых системных файловых объектов или объектов реестра ОС, прекращение события (например, завершение несанкционированного процесса, останов несанкционированного драйвера), возобновление события (например, запуск обязательного процесса), или другой сценарий, предусмотренный в системе. Таким образом, при быстрой проверке отдельных признаков (событий) нарушения безопасности системы, реализуется контроль действия пользователя в целом. Применительно к механизмам защиты прикладного уровня, можно говорить о следующем новом свойстве защиты от НСД. Осуществив оперативную реакцию на какое-либо зафиксированное несанкционированное событие, не имея возможности предотвратить это событие, тем самым можно предотвратить несанкционированное действие пользователя, элементом которого является данное событие.  Рис. 1 Теперь посмотрим, а каким образом взаимосвязаны механизмы контроля целостности и аудита событий. Для этого определимся с тем, а какую собственно информацию из состава данных аудита необходимо предоставлять администратору немедленно (в реальном времени), чтобы администратор мог оперативно осуществить противодействие факту НСД, либо, по крайней мере, минимизировать (опять же за счет оперативности принятия решения) возможный ущерб предприятия, связанный с этим событием? Можно предположить, что поскольку основными механизмами защиты в составе СЗИ от НСД являются системные драйверы, которые реализуют разграничительную политику доступа к ресурсам, следовательно, априори ведут аудит, именно данные аудита безопасности, зарегистрированные подобными механизмами защиты, и предназначаются для отправки на сервер безопасности в реальном времени. Однако зададим себе вопрос, а зачем эти данные администратору безопасности получать в реальном времени? Во-первых, подобные данные в большинстве своем не являются зарегистрированными фактами НСД (заметим, что если ограничиваются какие-либо права приложений и т.д., т.е. если система защиты многофункциональна и эффективна, то большинство зарегистрированных фактов отказа в доступе к ресурсам вообще никак не будет связано с действиями пользователей), во-вторых, основная задача – это оперативное реагирование на факт НСД. Однако, если механизм защиты, реализованный на системном уровне, зарегистрировал событие в качестве запрещенного, то он априори на него уже прореагировал (пользователь получил отказ в запрошенном им доступе к ресурсу). Другими словами, противоречие решения здесь состоит в том, что в реальном времени для оперативного реагирования администратору выдается информация о тех событиях, на которые соответствующие механизмы защиты уже прореагировали (например, отказали пользователю или приложению, в зависимости от субъекта доступа в разграничительной политике, в запрошенном им доступе к ресурсу), т.е. СЗИ от НСД работает корректно, что позволяет предположить, что любое повторное аналогичное событие также будет предотвращено. Если администратор безопасности здесь все равно статист - задача защиты решена и без его участия, то зачем дополнительно загружать канал связи отправкой данных аудита, регистрируемых механизмами защиты системного уровня, в реальном времени? Пусть получает их по запросу - в этом случае уже никакой оперативности не требуется! Возникают вопросы. Как разрешить подобную нелепую ситуацию? Какие же данные аудита следует предоставлять администратору безопасности в реальном времени, а какие по его запросу? Вот здесь нам на помощь и приходят механизмы защиты прикладного уровня, одной из функций которых является регистрация несанкционированных событий. Реализация данных механизмов, при построении сетевой системы аудита безопасности, позволяет выделить два уровня аудита, для которых принципиально различаются режимы обработки запросов (интерактивная обработка – по запросу администратора, и обработка в реальном времени - автоматически). Это, с одной стороны, позволяет существенно повысить оперативность обработки действительно критичных событий, непосредственно связанных с фактами НСД (да и вообще сделать задачу администратора безопасности функционально понятной), обеспечивая реакцию на критичные события в реальном масштабе времени, с другой стороны, существенно снизить нагрузку на трафик сети. В реальном времени по сети на сервер безопасности в этом случае должны передаваться только данные второго уровня аудита – данные аудита, регистрируемые рассмотренным механизмами защиты прикладного уровня (контроля целостности), данные же первого уровня аудита (регистрируемые механизмами контроля доступа к ресурсам) могут получаться администратором в интерактивном режиме (по его запросу, в соответствии с каким-либо регламентом), т.е. нагрузка на сетевой трафик подсистемой аудита сводится к минимуму, а работа администратора безопасности - понятной (ведь по сети на сервер безопасности в этом случае будут передаваться только те данные, которые непосредственно связаны с зарегистрированными фактами НСД – обход механизмов защиты, реализованных на системном уровне, и эти события критичны – для полного устранения зарегистрированного несанкционированного события может потребоваться уч астие администратора безопасности). С учетом всего сказанного, можем сделать крайне важный вывод. Механизм контроля целостности является весьма важной компонентой защиты, образуя отдельный функциональный уровень защиты информации от НСД. Его принципиальным отличием от остальных механизмов защиты является то, что данных механизмом может быть зарегистрирован сам факт НСД, причем вне зависимости от причин его происхождения (например, в результате использования злоумышленником ошибок и закладок в ПО). Поэтому развитый набор механизмов контроля целостности является важнейшим условием эффективной защиты от НСД. Поскольку контроль целостности – это механизм защиты, а не аудита, то на выявленные несанкционированные события КСЗИ должна обеспечивать оперативное реагирование. Реализация развитого набора механизмов контроля целостности позволяет построить систему действительно эффективного и оперативного аудита. Реализация в КСЗИ Панцирь-К В КСЗИ реализованы следующие механизмы контроля целостности:
 Рис. 2
 Рис. 3
 Рис. 4
 Рис. 5
 Рис. 6
 Рис. 7 Контроль объектов файловой системы, интерфейс представлен на рис.8, рис.9.  Рис. 8  Рис. 9 Кроме того, в части решения задачи контроля целостности, при загрузке КСЗИ производится проверка контрольных сумм ее основных модулей. В случае обнаружения нарушения целостности модулей производится автоматическое восстановление КСЗИ из резервной копии, предварительно созданной (естественно, после настройки механизмов защиты) администратором безопасности из интерфейса, представленного на рис. 10.  Рис. 10 Следует обратить внимание на настройку способа запуска контроля объектов файловой системы (см. рис. . Здесь в КСЗИ предусмотрены весьма широкие возможности, что обусловливается следующим. В некоторых случаях на контроль целостности могут устанавливаться файловые объекты больших объемов. Это может привести к большим потерям производительности системы. Вместе с тем, как было показано выше, для того, чтобы несанкционированно модифицировать файловый объект (осуществить к нему несанкционированный доступ), прежде, как правило, злоумышленник должен осуществить некоторую последовательность несанкционированных действий, которые могут быть зарегистрированы КСЗИ. Т.е. в КСЗИ реализован асинхронный (не по расписанию) контроль целостности объектов файловой системы, запускаемый по установленному факту несанкционированного действия пользователя в системе. Механизмы контроля целостности, приведенные выше, в большинстве своем реализованы по одним принципам:
Задача администрирования приведенных механизмов контроля целостности сводится к следующему:
Задачи аудита событий В целом система управления информационной безопасностью призвана решать ключевой вопрос построения сложной технической системы - вопрос комплексирования технических средств защиты. Важность решения данной задачи обусловливается тем, что при отсутствии централизации звена управления, в принципе не приходится говорить о системе защиты в АС, как таковой, в этом случае можно говорить лишь о неком наборе технических средств защиты, установленных на соответствующие средства обработки информации. Ключевое место в системе управления информационной безопасности занимает система оперативного аудита. Система оперативного аудита событий (аудита безопасности) АС средствами КСЗИ предназначена для системного объединения средств аудита информационной безопасности вычислительных средств, используемых в составе АС, в интересах максимизации информационной устойчивости и эффективности функционирования корпоративной сети в условиях деструктивных внешних и внутренних воздействий, и именно она призвана обеспечить минимизацию суммарного риска возможного ущерба при нарушениях в информационных технологиях, нарушениях дисциплины обмена информацией, качества и полноты информации, хищениях информации, потери ее целостности, доступности информационных ресурсов. Система обеспечивает в АС централизованную схему сбора (на выделенный сервер администратора безопасности) информации, регистрируемой механизмами защиты из состава КСЗИ, как в реальном масштабе времени, так и по запросу администратора. Вывод. Именно оперативный аудит безопасности информации АС является центральным звеном системы управления безопасностью, как следствие, основой комплексирования технических средств защиты информацию в единую систему обеспечения безопасности информации АС. Замечание. Действительно, а какова иначе роль администратора информационной безопасности АС (что будет входить в его повседневные обязанности, в предположении, что механизмы защиты уже настроены), если он не будет обладать в реальном времени информацией о критичных событиях безопасности, не будет обладать инструментарием оперативного реагирования на зафиксированные события, возможностью в реальном времени осуществлять контроль действий пользователей на защищаемых вычислительных средствах и т.д. – только настройка механизмов защиты? А как реализовать регламент его ознакомления с данными аудита, фиксируемыми распределенными средствами защиты в АС, при отсутствии сервера системы аудита? О какой информационной безопасности при этом можно говорить? В общем случае можно выделить следующие задачи аудита событий, которые должны решаться СЗИ от НСД (и решаются КСЗИ Панцирь-К):
Инструментальный аудит событий предназначен для формирования (уточнения) разграничительной политики безопасности, в первую очередь, при реализации разграничительной политики доступа для процессов и при реализации разграничительной политики доступа к системным ресурсам. Интерактивный аудит безопасности призван контролировать действия пользователей на защищаемом компьютере и регистрировать факты попыток НСД (факты попыток обхода разграничительной политики доступа к ресурсам, зафиксированные механизмами защиты системного уровня из состава СЗИ от НСД). Данные аудита могут быть по запросу (интерактивно) получены администратором удаленно на сервер безопасности, где могут быть проанализированы с использованием соответствующих фильтров. Интерактивность режима данного уровня аудита обусловливается тем, что на зафиксированные факты НСД механизмами защиты системного уровня реакция уже оказана (в частности, в запрошенном злоумышленником несанкционированном доступе к ресурсам, ему отказано), это обусловливает возможность не оперативной обработки данных аудита этого уровня администратором (в соответствии с каким-либо регламентом). Оперативный аудит безопасности призван контролировать корректность функционирования механизмов защиты системного уровня из состава СЗИ от НСД и регистрировать уже факты собственно НСД (факты обхода соответствующих механизмов защиты системного уровня). Данные аудита этого уровня в реальном времени поступают администратору со всех защищаемых компьютеров АС, и отображаются в едином окне интерфейса АРМа администратора безопасности (на сервере безопасности). Данный подход, реализованный в КСЗИ, позволяет не только сделать аудит событий действительно эффективным механизмом защиты, но и существенно снизить влияние сетевой КСЗИ на загрузку связного ресурса – в штатном режиме функционирования (не регистрируются факты НСД – факты обхода механизмов защиты системного уровня) КСЗИ практически не создает собственного сетевого трафика. С учетом сказанного можем сделать следующий важный вывод. Возможности аудита в КСЗИ принципиально (функционально) расширены, по сравнению с требованиями нормативных документов. Это обусловливается реализованной архитектурой КСЗИ. В частности, необходимость корректной реализации ключевых механизмов защиты, а также решение задач защиты информации в комплексе (противодействие внутренним и внешним угрозам, антивирусная защита) требует включения процесса в разграничительную политику доступа к ресурсам в качестве самостоятельного субъекта доступа. Для формирования разграничительной политики доступа к ресурсам процессов в состав КСЗИ введены дополнительные инструментальные средства, основанные на реализации функций расширенного аудита событий (инструментальный аудит). Выполнение требований нормативных документов реализуется средствами интерактивного аудита безопасности. Данные средства фиксируют не факты НСД, а их попытки, которые предотвращаются механизмами защиты из состава КСЗИ. Ввиду большого объема регистрируемых данных (что требуется нормативными документами) и отсутствия необходимости обработки этих данных администратором безопасности в реальном времени, в основе схемы централизованного сбора в КСЗИ для данного уровня аудита принята интерактивная (по запросу администратора) схема сбора регистрационных данных. Для реализации эффективной модели аудита безопасности в КСЗИ введен уровень оперативного аудита, основанный на реализации механизмов защиты прикладного уровня. Данный уровень аудита уже регистрирует не неудачные попытки НСД, а собственно факты НСД – факты обхода механизмов защиты системного уровня из состава КСЗИ. Эти данные со всех защищаемых компьютеров АС поступают на сервер безопасности в реальном времени, т.к. эти зарегистрированные события требуют немедленного вмешательства со стороны администратора безопасности. Именно оперативный аудит безопасности информации АС является центральным звеном системы управления безопасностью сложной технической системы, как следствие, основой комплексирования технических средств защиты информацию в единую систему обеспечения безопасности информации АС. Реализация в КСЗИ Панцирь-К В КСЗИ реализованы следующие возможности аудита:
Инструментальный аудит событий и интерактивный аудит безопасности реализуются механизмами защиты системного уровня, и из этих же механизмов настраивается. Например, интерфейс настройки аудита доступа к файловым объектам приведен на рис. 1 По умолчанию (чтобы не задавать в настройках) регистрируются все события связанные с попытками НСД, если в интерфейсе задать какой-либо объект (см. рис.1 , то будут регистрироваться все запросы доступа к этому объекту (как успешные, так и НСД), что необходимо для инструментального аудита событий.  Рис. 11 Аудит доступа к любому объекту, из интерфейса соответствующего механизма контроля доступа, администратором может быть включен, либо выключен (пример, см. на рис.1 .  Рис. 12 Пример представления данных в журнале аудита приведен на рис.13.  Рис. 13 Все регистрируемые механизмами защиты КСЗИ события группируются в отдельные журналы по функциональному признаку, см. рис.14.  Рис. 14 Администратор может как локально (из интерфейса КСЗИ), так и удаленно с сервера, предварительно выбрав защищаемый компьютер и получив с него текущие значения журналов, открыть необходимый журнал, в котором, в случае необходимости, оставить только зарегистрированные события НСД (из интерфейса, см. рис.1 , либо отфильтровать его по времени, см. рис. 16, также имеет возможность фильтрации событий по ключевым словам.  Рис. 15  Рис. 16 Для обработки зарегистрированных событий в рамках реализации инструментального аудита событий, КСЗИ предоставляет администратору фильтр событий с более развитыми функциональными возможностями, см. рис.17.  Рис. 17 Оперативный аудит безопасности реализуется механизмами контроля целостности (задачи и принципы их настройки описаны в предыдущем разделе). Для формирования данного уровня аудита безопасности в КСЗИ реализована самостоятельная компонента сервер ошибок, которая может устанавливаться как на том же компьютере, что и сервер безопасности КСЗИ, так и на отдельном компьютере. Сервер ошибок предоставляет возможность сбора и отображения в реальном времени в одном окне, см. рис.18, фактов НСД, регистрируемых на всех защищаемых компьютерах в составе АС. Поскольку сервером ошибок регистрируются собственно факты НСД, и оперативность реагирования на данные события является важнейшим элементом защиты, КСЗИ предоставляет администратору возможность формирования и запуска на сервере (в дополнение к реакциям, реализуемым локально – клиентскими частями КСЗИ) командного файла реакции. Командный файл реакции может быть установлен на любой тип строки (на каждый тип строки он может быть своим), поступающий на сервер ошибок, что реализуется из интерфейса, представленного на рис.1 В этом случае, при поступлении на сервер соответствующей строки сообщения, им будет автоматически запускаться командный файл реакции.  Рис. 19 Задачи администрирования механизмов аудита событий сводится к следующему:
В заключение отметим, что целью данной работы являлось проиллюстрировать, в какой мере могут быть расширены функциональные возможности двух, на первый взгляд, не самых обязательных при реализации защиты от НСД, механизмов защиты. Какие принципиально новые возможности защиты могут обеспечиваться при реализации в СЗИ от НСД инновационных подходов и технологий. Автор надеется, что опубликованные им (в этой и в иных статьях) материалы позволят читателю более пристально взглянуть на представленные на рынке средств защиты СЗИ от НСД, среди которых встречаются действительно эффективные решения, практическое использование которых позволяет решать многие проблемы защиты информации от НСД. Читайте далее:  3. самые успешные компании 2007 года ,часть 1, Ах ты, камбала - не вобла... Ежегодный анализ тайваньского рынка безопасности. Комментарий к 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, Организация строительно-монтажных, пусконаладочных работ и ввода в эксплуатацию интегрированных сист Наш опыт прокладки кабелей
|
