Вы находитесь в разделе Типовых решений систем безопасности
Часть 8. технология контроля санкционированности событийВ предыдущих частях работы мы рассматривали вопросы реализации важнейших, в части обеспечения компьютерной безопасности, механизмов защиты информации от несанкционированного доступа (НСД) – механизмов контроля доступа к ресурсам. Именно тем, в какой мере научно обосновано и технически грамотно реализованы разработчиками СЗИ НСД эти механизмы, в большинстве своем, и определяется достигаемая эффективность компьютерной безопасности. В предыдущих же частях работы мы проиллюстрировали сложности, возникающие при реализации принципов контроля доступа к ресурсам, а также исследовали причины потенциально возможных уязвимостей соответствующих механизмов защиты. В данной части работы мы рассмотрим технологию (технологию в том смысле, что предлагаемый в работе подход к защите информации от НСД предполагает применение некой совокупности различных по своему назначению механизмов защиты, построенных на одних и тех же принципах, взаимодействие которых осуществляется по определенным правилам) защиты, используемую уже в априори сделанном предположении о наличии уязвимостей в механизмах контроля доступа к ресурсам, т.к. в противном случае, при построении системы защиты следует считать реализацию механизмов контроля доступа к ресурсам идеальной, что не достижимо в принципе, как следствие, не достижима и эффективная защита информации от НСД. На сегодняшний день принято характеризовать систему защиты от НСД (СЗИ НСД), причем, как встроенную в ОС и приложения, так и добавочную, совокупностью реализуемых ею механизмов защиты, кстати говоря, именно по этим признакам оценивается и класс защищенности средства вычислительной техники по соответствующим нормативным документам в области защиты информации. Однако, в общем случае набор механизмов защиты и эффективность защиты это далеко не напрямую взаимосвязанные понятия. В качестве подтверждения сказанному, можем рассмотреть динамику развития современных ОС и взаимосвязанную с нею динамику изменения уязвимостей. Действительно, количественно набор механизмов защиты в современных ОС непрерывно возрастает (особенно это характерно для ОС семейства Windows), однако системы остаются уязвимы. Очевидно, что с изменением номенклатуры механизмов защиты, качественно меняются и сами уязвимости. Естественно, что при появлении механизма защиты уязвимость уже определяется не собственно отсутствием механизма, а его архитектурными недостатками (непродуманностью решения), некорректностью реализации, ошибками программирования (все эти вопросы рассмотрены в предыдущих частях работы касательно механизмов контроля доступа к ресурсам). Именно противодействовать подобным уязвимостям, на наш взгляд, в первую очередь и призваны добавочные СЗИ НСД (о чем говорилось ранее), что, на наш взгляд, и является основной потребительской стоимостью добавочных средств защиты (а иначе, зачем они нужны в современных условиях, характеризуемых расширением возможностей встроенной защиты?). Однако все сказанное выше относится и применительно к добавочным СЗИ НСД, что проиллюстрировано на рис.8.1.  При этом, еще раз отметим (этот вопрос подробно рассматривался нами в третьей части работы), что использование добавочных СЗИ НСД при некорректности их реализации, может не только не повышать, но и снижать эффективность защиты (на рис.8.1 подобная СЗИ НСД выделена синим цветом, красным же цветом выделена корректно реализованная СЗИ НСД, вносящая дополнительные свойства защиты), о чем должен помнить потребитель, выбирая СЗИ НСД для использования на своем предприятии. Ну что толку в большом количестве механизмов, если каждый из них реализован так, как показано синим цветом на рис.8.1, кому нужна такая система защиты, в которой будут систематически обнаруживаться все новые и новые уязвимости? К чему это приведет, мы рассмотрели во второй части работы, обсуждая вопросы надежности защиты информации. В качестве же замечания, возвращаясь к рис.8.1, можем отметить и бесперспективность какой-либо осмысленной формализованной оценки (на наш взгляд, она невозможна в принципе) уровня эффективности защиты (либо уровня защищенности), т.к. формально на рис.8.1 данный параметр может быть определен лишь как отношение числа возможностей (или способов) доступа к ресурсам, включенным в зеленую стрелку, к общему числу возможностей (или способов) доступа к ресурсам, включенным, как в зеленую, так и в синюю стрелки, что естественно определить не представляется возможным (в противном случае зеленой стрелки на рис.8.1 вообще не должно было бы быть). На самом деле, это весьма важный вывод, т.к. потребителя, в конце концов, интересует именно достигаемый уровень защищенности, который объективно оценить-то и невозможно. Остается лишь одно, брать документацию на сравниваемые СЗИ НСД и методично оценивать реализованные в них подходы и технологии защиты, надеясь на то, что квалификация разработчиков СЗИ НСД достаточно высока, чтобы корректно реализовать то, что ими декларируется и не внести новых уязвимостей в систему защиты. На самом деле текущее состояние защищенности системы может иметь одно из двух состояний: полностью защищена, либо полностью незащищена, что проиллюстрировано на рис.8.2.  Однако, вернемся к исследуемым нами вопросам, но уже в следующих предположениях, обоснованных выше – в любой момент времени систему следует считать полностью незащищенной, т.к. система защищена только до тех пор, пока не обнаружена очередная уязвимость. Другими словами, добавочную СЗИ НСД следует строить в предположении о наличии уязвимостей в механизмах контроля доступа к ресурсам (причем, в общем случае, не только непосредственно в данных механизмах, а любой уязвимости, позволяющей получить НСД к информации в обход этих механизмов). В качестве замечания отметим, что в подобном посыле нет противоречия с исследованиями, проведенными нами во второй части работы, посвященной вопросам надежности защиты информации. Там мы привели стохастическую оценку защищенности, на основании предположений, сделанных в части задания интенсивности обнаружения уязвимостей (отказов системы защиты). Интенсивность же обнаружения уязвимостей, как параметр, характеризует не наличие, либо отсутствие, уязвимостей в системе (они всегда присутствуют), а то, насколько много их обнаруживается в единицу времени, как следствие, именно этот параметр (а не количественный набор механизмов защиты) можно использовать для объективной оценки эффективности системы защиты (и то лишь косвенной оценки – здесь масса вторичных факторов: насколько широко используется система и в каких приложениях, срок использования версии ПО, доступность к исходным текстам системы и т.д.). Таким образом, можем сформулировать следующее требование к добавочной СЗИ НСД - должна строиться в предположении о наличии уязвимостей в механизмах контроля доступа к ресурсам, т.е. добавочная СЗИ НСД должна иметь возможность оказывать противодействие и тем уязвимостям, природа возникновения которых не известна (например, ошибки программирования). Замечание. Здесь уже идет речь об уязвимостях, не связанных с архитектурными недостатками системы защиты (данные недостатки должны выявляться и устраняться разработчиками добавочных СЗИ НСД, о чем мы говорили в первой части работы), а об уязвимостях, которые невозможно обнаружить, путем архитектурного анализа ПО, в частности, это ошибки программирования, которые всегда присутствуют в ПО и могут нести в себе возможность обхода механизмов защиты. Заметим также, что данный метод защиты может быть использован и в части противодействия закладкам в ПО (закладки, это те же недекларируемые возможности – возможности системы, не описанные разработчиком в документации, но внесенные разработчиками в систему не по ошибке, а сознательно, с целью возможности получения НСД к информации в обход встроенных механизмов защиты), т.к. фиксируется собственно факт появления события без учета причин, его вызвавшего. Метод контроля санкционированности событий Сразу, в качестве замечания, отметим, что, во-первых, рассмотренные в этой и в других статьях авторов решения апробированы при создании семейства СЗИ НСД – КСЗИ «Панцирь» (для ОС семейства Windows) - разработка НПП «Информационные технологии в бизнесе», во-вторых, они либо уже запатентованы, либо находятся в стадии патентования, поэтому без нарушения авторских прав, рассмотренные в работах авторов технологии не могут быть реализованы в разработках иных производителей. Выше было показано, что все возможности доступа к ресурсам в общем случае выявить практически не представляется возможным, т.е. реализовать механизм контроля доступа, перекрывающий все каналы НСД невозможно в принципе. Вместе с тем, всегда можно осуществить контроль того, корректно ли функционирует соответствующий механизм, или контроль санкционированности событий. Проиллюстрируем сказанное на примере. Рассмотрим механизм обеспечения замкнутости программной среды (механизм контроля запуска исполняемых файлов), позволяющий запускать только санкционированные процессы. Одновременно можно осуществлять контроль того, какие же процессы в системе запускаются, но уже иным механизмом защиты – механизмом контроля запускаемых процессов. Отличие данных механизмов принципиально: первый выполняется в виде драйвера, перехватывает и анализирует запросы на доступ к ресурсам, в результате чего разрешает, либо не разрешает, запуск исполняемого файла; второй выполняется в виде приложения и лишь фиксирует, какие процессы запускаются в системе, что проиллюстрировано на рис.8.3.  Таким образом, механизм контроля санкционированности событий (на рис. 8.3 – контроля санкционированности доступа к ресурсам) ничего не разграничивает, а лишь фиксирует факт появления события и анализирует санкционированное это событие, либо нет (для нашего примера – запущен разрешенный, либо неразрешенный процесс), в соответствии со списком санкционированных событий, задаваемых при настройке механизма защиты. Принципиальным отличием данного механизма является то, что он фиксирует сам факт появления события в системе, т.е. вне зависимости от того, каким способом это событие активизировано – санкционированно, либо нет (зеленая, либо синяя стрелка на рис. 8.3, соответственно, на рис.8. , оно будет зафиксировано. Это позволяет утверждать, что данным механизмом будет зафиксировано любое событие, как санкционированное, так и несанкционированное, произошедшее в системе, в том числе, и событие, которое могло быть следствием обхода механизмом контроля доступа к ресурсам, обусловливаемого наличием ошибок программирования, либо закладок в ПО. Поскольку рассматриваемый механизм – это механизм защиты, а не аудита, то на любое несанкционированное событие механизм должен вырабатывать реакцию (в нашем примере одной из возможных реакций является завершение несанкционированного процесса). В качестве замечания отметим, что механизм контроля санкционированности событий не имеет ничего общего со средствами аудита, реализуемого механизмами контроля доступа к ресурсам (данные средства аудита зафиксируют лишь то событие, которое анализируется соответствующим механизмом, в частности запросы доступа, реализующие возможности, отмеченные зеленной стрелкой на рис.8.3, средствами аудита зафиксированы не будут). Механизм же контроля санкционированности событий должен фиксировать не запросы активизации событий, а сами факты осуществления событий, в чем и состоит принципиальная разница рассматриваемых механизмов. Технология контроля санкционированности событий Итак, в качестве возможного способа противодействия ошибкам и закладкам в системном и прикладном ПО, а также контроля (мониторинга) корректности функционирования механизмов контроля доступа к ресурсам, реализующих разграничительную политику доступа к ресурсам защищаемого объекта, предлагается использовать методы контроля санкционированности событий. Основу же предлагаемой технологии контроля санкционированности событий составляет следующее. В общем случае получение пользователем доступа к ресурсу можно представить набором некоторых событий (например, какой пользователь обращается к ресурсу, какой процесс запущен пользователем, к какому ресурсу обращается пользователь и т.д.). Таким образом, доступ пользователя к ресурсу представляет собою некоторую последовательность действий, каждое из которых может быть охарактеризовано соответствующим списком санкционированных – разрешенных, либо несанкционированных – запрещенных событий (действий, настроек и т.д.), например, список зарегистрированных в системе пользователей, список возможных олицетворений потоков, список разрешенных к запуску процессов, список ключей реестра ОС, разрешенных для изменения, список устройств, к которым разрешен доступ пользователям и т.д. Анализируя известные атаки, осуществленные с использованием знания злоумышленником ошибок в ПО, можно показать, что большинство несанкционированных доступов к ресурсам осуществлялось с использованием события, которое может быть определено как несанкционированное (при соответствующем составлении и анализе списков санкционированных событий). Таким образом, контролируя текущие события системы в соответствии со списками разрешенных событий (списками санкционированных событий) можно контролировать корректность (санкционированный или несанкционированный) доступа пользователя к ресурсам. Таким образом технология контроля санкционированности событий представляет собой подход к защите информации, основанный на определении событий, происходящих при доступе к ресурсу, выявлении списков санкционированных событий, и непрерывном по заданным правилам, определяющим очередность, контроле происходящих в системе событий в процессе функционирования системы на соответствие заданным эталонным спискам. В случае обнаружения несанкционированного события вырабатывается реакция системы защиты, с целью предотвращения несанкционированного доступа к ресурсам (например, завершение несанкционированного процесса, восстановление контролируемого ключа реестра ОС, завершение сеанса несанкционированного пользователя в системе и т.д.). Отличительной особенностью рассматриваемого подхода является то, что в принципе неважно, каким образом злоумышленник пытается осуществить несанкционированный доступ к информации, т.к. фиксируются не конкретные описания, а косвенные признаки атаки – несанкционированные для системы события. Принципиально важным является то, что рассматриваемый подход позволяет противодействовать скрытым угрозам, а также использованию злоумышленником ошибок и закладок в системном, функциональном и прикладном программном обеспечении без необходимости выявления последних. Реализация технологии – механизм уровневого контроля списков санкционированных событий Механизм уровневого контроля (это запатентованное нами решение - патент №216994 состоит в следующем: в системе выделяются те события, которые нужно контролировать. При большом количестве событий они объединяются в группы (списки) по функциональному признаку (или другому общему свойству), см. рис.8. Создается эталонная копия свойств данной группы (списка санкционированных событий). Каждый из списков формирует отдельный уровень системы. Свойства системы считаются нарушенными в случае расхождения эталонной копии и оригинала. В процессе работы защищаемой системы осуществляется периодический контроль, путем сравнения эталонных копий списков каждого уровня и их реальных значений. При расхождении генерируется состояние нарушения безопасности системы, реакцией на которое может быть восстановление нарушенного списка или другой сценарий, предусмотренный в системе. Важнейшим условием эффективности использования механизма (это один из элементов технологии) является определение и задание правил, прежде всего, очередности контроля списков санкционированных событий. Отнесение списка к определенному уровню (положение в очередности) осуществляется, исходя из следующих соображений:
 Таким образом, при быстрой проверке косвенных признаков нарушения безопасности системы, в случае обнаружения расхождений с проверяемым списком санкционированных событий, можно немедленно запустить внеочередную проверку других важных для безопасности системы событий (требующих больших затрат производительности), см. рис.8. При правильном выборе уровневых списков и их взаимодействия (зависимости проверок) можно утверждать, что, если при проверках уровневых списков не выявлено нарушений, то безопасность системы соблюдена на данный момент времени.  Как видим из схемы, представленной на рис.8.5, структуру рассматриваемого механизма защиты составляет три основных типа блоков:
Дополнительные возможности механизма Дополнительные функциональные возможности Собственно описанная технология, включающая некий набор механизмов защиты (соответственно, правила формирования данного набора – создание уровней и отнесение контролируемых событий к уровням), взаимодействующих по определенным законам, призвана осуществлять контроль корректности функционирования механизмов, реализующих разграничительную политику доступа к ресурсам. Однако каждый отдельный механизм контроля списков санкционированных событий может быть самодостаточным в части реализации им дополнительных функций защиты. Рассмотрим пример. Большинство современных ОС являются не только многозадачными, но и многопользовательскими – в системе может регистрироваться и одновременно работать несколько пользователей. К таким ОС, в частности можно отнести и современные ОС семейства Windows. Подобная возможность накладывает ряд практически не выполнимых требований к изоляции процессов различных пользователей. В частности, в соответствующем нормативном документе данные требования сформулированы следующим образом:
В пятой части нашей работы, посвященной рассмотрению мандатного принципа контроля доступа в части корректности его реалиции, мы отмечали, что, кроме буфера обмена, существует масса иных возможностей (каналов) обмена данными процессов – вот лишь некоторые из них: MMF (Memory Mapped File), Pipe (именованные и неименованные каналы), DDE (Dynamic Data Exchange), Mailslot, Winsocket, RPC, LPC, COM Data Copy (OLE), System Messages (через функции SendMessage/PostMessage). Тогда для корректной реализации контроля доступа к ресурсам в многопользовательском режиме необходимо обеспечить контроль всех каналов межпроцессного взаимодействия, что, на наш взгляд, является трудно выполнимой задачей, для решения ее средствами добавочной СЗИ НСД. Поэтому, кстати говоря, нам кажется не очень корректным решение реализации мандатного механизма контроля доступа, основанное на том, что пользователь может назначать метки запускаемым им процессам, т.к. в этом случае получаем многопользовательскую систему даже в случае регистрации одного пользователя в системе (см. пятую часть работы). Вместе с тем отметим, что режим многопользовательской (не многозадачной) обработки, в частности, при использовании ОС семейства Windows, используется на практике достаточно редко, по сути, только при применении терминальных серверов. В качестве замечания отметим, что (в частности, и с учетом сказанного выше), наверное, трудно, без проведения дополнительных серьезных исследований, согласиться с бытующим мнением, относительно того, что терминальные комплексы характеризуются лучшей защищенностью, чем системы распределенной обработки данных. Рассмотрим, как в данных приложениях можно использовать механизм контроля списков санкционированных событий. Обозначим в качестве санкционированного события – возможность регистрации только одного пользователя в системе в сеансе взаимодействия с компьютером. При этом под сеансом будем понимать временной интервал, начиная с момента регистрации пользователя в системе, до момента ее полной перезагрузки (выключение компьютера – режим мягкой перезагрузки добавочными средствами защиты запретим). Будем контролировать с заданным периодом число зарегистрированных пользователей в системе – несанкционированным событием будет регистрация более одного пользователя. Реакцией на несанкционированное событие будет завершение сеанса пользователя, зарегистрированного не первым, либо перезагрузка компьютера. Что мы имеем – по сути, мы сводим задачу к однопользовательской (оставляя ее многозадачной), причем другой пользователь сможет зарегистрироваться только после полной перезагрузки компьютера (как следствие, после очистки оперативной памяти). Таким образом, видим, что задачи изоляции модулей и очистки оперативной памяти здесь решены в общем виде в том смысле, что их решение при таком режиме функционирования системы становится не актуальным, что может использоваться в 95-99% приложений ОС семейства Windows. Заметим, что в частности рассмотренный механизм, как одна из возможностей защиты межпроцессного взаимодействия, реализован в нашей разработке КСЗИ «Панцирь» для ОС Windows 2000/XP/2003. Расширение возможностей механизма контроля целостности файловых объектов Контроль целостности файловых объектов представляет собой самостоятельную задачу защиты информации. Основу механизмов защиты контроля целостности файловых объектов представляет проверка соответствия контролируемого объекта эталонному образцу, при этом для контроля могут использоваться контрольные суммы и ряд иных признаков, например, дата последней модификации объекта и т.д. При необходимости содержать контролируемый объект в эталонном состоянии, данные механизмы могут осуществлять автоматическое, либо автоматизированное (под управлением пользователя или администратора безопасности) восстановление несанкционированно измененного файлового объекта из эталонной копии. Основной проблемой реализации механизмов контроля целостности файловых объектов является их весьма сильное влияние на загрузку вычислительного ресурса системы, что обусловливается следующими причинами. Во-первых, может потребоваться контролировать большие объемы информации, что связано с большой продолжительностью выполнения процедуры контроля. Во-вторых, может потребоваться непрерывное поддержание файлового объекта в эталонном состоянии. При этом возникает вопрос, с какой частотой запускать продолжительную процедуру контроля, если часто – получим существенные затраты вычислительного ресурса, если редко – данный контроль, в частности автоматическое восстановление объектов из эталонной копии, вообще имеет мало смысла. Таким образом, основным вопросом при реализации механизма контроля целостности файловых объектов является выбор принципов и механизмов запуска процедуры контроля (очевидно, что синхронный запуск – запуск контроля по расписанию, который без существенного снижения производительности системы может производиться достаточно редко, следует рассматривать в качестве дополнительного механизма). Контролируемые файловые объекты могут быть классифицированы в соответствии с функциональным назначением – исполняемые файлы (программы) файлы данных. Рассмотрим возможные подходы к реализации асинхронного (причинного) запуска процедуры контроля целостности. С точки зрения контроля исполняемых файлов асинхронный механизм запуска процедуры контроля интуитивно понятен – контроль следует запускать перед запуском программы – перед чтением соответствующего исполняемого файла. Другими словами, система защиты должна перехватывать команду запуска исполняемого файла, запускать процедуру контроля и затем (при необходимости, уже после восстановления файла из эталонной копии) выдавать данную команду на обработку в ядро ОС. В данном случае достигается минимальное влияние на загрузку вычислительного ресурса системы, так как контроль осуществляется только в необходимые моменты – только при запуске программы (при этом предполагается, что программа запускается редко, по крайней мере, значительно реже, чем осуществляется обращение к файлам данных). Таким образом, описанный подход позволяет гарантировать, что контролируемая программа будет запускаться в эталонном состоянии. С точки зрения контроля целостности файлов данных имеем принципиально более сложную ситуацию. Отличие от контроля исполняемых файлов здесь состоит в том, что к файлам данных обращения могут быть частыми. Поэтому механизм контроля перед чтением файла данных (по аналогии с контролем исполняемых файлов), практически не может быть применим (использование данного подхода может привести к существенному влиянию механизма защиты на загрузку вычислительного ресурса системы). В качестве альтернативного подхода к асинхронному запуску процедуры контроля целостности файлов данных, может быть рассмотрен способ запуска процедуры контроля, как реакции, вырабатываемой механизмом уровневого контроля списков санкционированных событий (механизм описан выше), что проиллюстрировано на рис. 8.8.  Здесь механизм контроля событий N-го уровня не что иное, как контроль целостности файлов данных. Управление данному механизму передается остальными механизмами контроля событий (уровней 1, 2,…, N- при обнаружении любым из этих уровней несанкционированного события в системе. Таким образом, при данном способе контроля причиной запуска процедуры контроля файлов данных (асинхронный запуск) является наличие косвенных признаков несанкционированного доступа – запуск процедуры контроля файлов данных осуществляется только при обнаружении в системе потенциально опасной ситуации – угрозы НСД. Синхронный контроль (по расписанию) здесь может использоваться в дополнение к процедуре причинного запуска процедуры контроля, запуск процедуры по расписанию реализуется системой диспетчеризации. При реализации запуска процедуры контроля файлов данных, как реакции, вырабатываемой механизмом уровневого контроля списков санкционированных событий, минимизируется дополнительная загрузка вычислительного ресурса системы на выполнение процедуры контроля, т.к. в штатном режиме функционирования системы – при отсутствии угрозы НСД, контроль не осуществляется. Двухуровневая модель аудита Система защиты должна осуществлять регистрацию основных событий при функционировании защищаемого объекта. В рамках построения иерархической системы защиты (первый уровень иерархии защиты – контроль доступа к ресурсам, второй уровень иерархии защиты – контроль корректности реализации разграничительной политики доступа к ресурсам), как следствие, может строиться иерархической система аудита, содержащая следующие уровни иерархии. Первый уровень иерархии аудита - регистрация событий уровня защиты, реализующего разграничительную политику доступа к ресурсам. В рамках данной функции аудита решаются следующие задачи:
Второй уровень иерархии аудита - регистрация событий уровня, реализующего контроль корректности функционирования механизмов защиты, реализующих разграничительную политику доступа к ресурсам (механизмов контроля доступа к ресурсам). Данный контроль ведется механизмом уровневого контроля списков санкционированных событий (описан выше). Принципиальным отличием в регистрации событий для рассмотренных уровней иерархии аудита является то, что на первом уровне иерархии фиксируются все события, связанные с доступом к защищаемым ресурсам (ведутся журналы регистрации), на втором уровне регистрируются только ошибки (ведутся журналы ошибок) – регистрируются факты некорректности срабатывания механизмов защиты, реализующих разграничительную политику доступа к ресурсам, или их преодоление злоумышленником, в том числе и с использованием знаний об ошибках и закладках в ПО, т.е. факты НСД. Реализация иерархической модели аудита позволяет ввести в системе защиты различные схемы обработки журналов, в частности при удаленном управлении системой защиты – ее клиентской частью, с сервера безопасности (серверная часть системы защиты). Журналы регистрации – регистрационная информация первого уровня аудита, сохраняются в соответствующих файлах клиентской части системы защиты и могут быть переданы на сервер безопасности по запросу администратора безопасности (затем соответствующим образом им обработаны с применением фильтров, входящих в состав системы защиты). Регистрационная информация об ошибках – регистрационная информация второго уровня аудита, в реальном времени выдается клиентской частью системы защиты на сервер безопасности и отображается в специальном окне интерфейса сервера безопасности – в окне сервера ошибок. Кроме того, на каждый тип ошибки администратор безопасности может задать реакцию, как на клиентской части системы защиты, так и на сервере безопасности. Таким образом, использование механизма уровневого контроля позволяет выделить два уровня аудита, для которых принципиально различаются режимы обработки запросов (оперативная обработка и обработка в реальном времени). Это, с одной стороны, позволяет существенно повысить оперативность обработки критичных событий, обеспечивая реакцию на критичные события в реальном масштабе времени, с другой стороны, существенно снизить нагрузку на трафик сети. В реальном времени по сети на сервер безопасности передаются только данные второго уровня аудита, т.е. нагрузка на сетевой трафик подсистемой аудита сводится к минимуму (при этом отметим, что в штатном режиме функционирования сетевой системы защиты именно интенсивность и объемы передачи данных аудита определяют дополнительную нагрузку, генерируемую системой защиты, на сетевой ресурс). В порядке иллюстрации приведем окно сервера ошибок, реализованного в сервере безопасности КСЗИ «Панцирь» для ОС Windows 2000/XP/2003, представлено на рис.8. Заметим, как говорили ранее, чтобы сообщение о зафиксированном событии поступало на сервер ошибок сразу, после его обнаружения, необходимо настроить данную возможность в интерфейсах механизмов контроля санкционированных событий, примеры которых приведены на рис.8.6, 8. .  Естественно, что здесь (на сервере безопасности) также имеет смысл предусмотреть автоматический запуск реакции, которая может задаваться администратором. Например, в КСЗИ “Панцирь” для ОС Windows 2000/XP/2003 для любого типа сообщения о несанкционированном событии (для любой строки в окне сервера ошибок, см. рис.8. может быть установлена своя реакция (запускается программа реакции), что задается в интерфейсе настройки сервера ошибок, представленном на рис. 8.1  Читайте далее:  1 - 4 июня 2006 года 17 - 23 июля 2006 года 7 - 13 августа 2006 года Я помню, как все начиналось ,часть 7, 1 - 8 октября 2006 года 31 октября 2006 года 20 - 26 ноября 2006 года 01 - 10 декабря 2006 года 15 - 21 января 2007 года 5 - 11 февраля 2007 года 19 - 25 марта 2007 года
|
