Альтернативная задача защиты информации от нсд на прикладном уровне.

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

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

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

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

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

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

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

В порядке иллюстрации рассмотрим реализацию данного решения в КСЗИ «Панцирь-К» для ОС Windows 2000/XP/2003. Все зарегистрированные данные аудита безопасности механизмами защиты прикладного уровня на всех защищаемых компьютерах в составе корпоративной сети, в реальном времени поступают на сервер безопасности, где соответствующим образом отображаются в одном едином окне (рис. 3).

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

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

Например, в КСЗИ “Панцирь-К” для ОС Windows 2000/XP/2003 для любого типа сообщения о несанкционированном событии (для любой строки, отображаемой в окне, см. рис. 3) может быть установлена своя реакция (при регистрации данного события на сервере безопасности на сервере автоматически запускается заданный командный файл реакции), что задается в соответствующем интерфейсе настройки реакций (рис. 4).

Рис. 4. Интерфейс настройки сценариев автоматической реакции на строку события

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

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

Аппаратные решения в данной работе рассматривать не будем (это вопрос самостоятельного, довольно-таки интересного исследования - что эффективнее доверенная загрузка, либо контроль активности, этим вопросам мы посвятим отдельную работу). Здесь рассмотрим сетевое решение, реализованное в КСЗИ “Панцирь-К” для ОС Windows 2000/XP/2003.

В порядке иллюстрации, покажем, как выглядят интерфейсы серверной части КСЗИ “Панцирь-К” для ОС Windows 2000/XP/2003, позволяющие отображать, как защищаемые компоненты в составе корпоративной сети (рис.5), так и предоставляющие администратору необходимую справочную информацию по пользователям (сотрудникам предприятия, работающим на защищаемых компьютерах) (рис.6).

Рис.5. Отображение структуры защищаемой корпоративной сети предприятия

Рис.6. Представление справочной информации по пользователям

В КСЗИ реализован механизм удаленного с сервера безопасности контроля активности клиентской части СЗИ от НСД. На рис. 7 проиллюстрированы возможные варианты текущего состояния клиентской части СЗИ от НСД, удаленно фиксируемые и отображаемые на сервере безопасности (в интерфейсе, приведенном на рис. 5): 1) компьютер выключен (по питанию) или не подключен к сети; 2) компьютер подключен к сети, но при соединении клиентской части СЗИ от НСД с сервером безопасности, аутентификация не проходит; 3) компьютер подключен к сети, но клиентская часть СЗИ от НСД на нем не активна; 4) компьютер подключен к сети и на нем активна клиентская часть СЗИ от НСД (штатный режим).

Компьютер в состоянии "1" обозначается темно-зеленым, в состоянии "2" – красно-желтым, в состоянии "3" – красным, и в состоянии "4" – ярко-зеленым цветом (рис.7).

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

Рис.7. Варианты отображения состояния защищаемых компьютеров на сервере безопасности

Таким образом, использование в СЗИ от НСД механизмов защиты на прикладном уровне позволяет говорить о реализации средством защиты уровневой (иерархической) модели защиты (рис. 8). Заметим, что именно такая модель защиты реализуется КСЗИ “Панцирь-К” для ОС Windows 2000/XP/2003.

Рис.8 Уровневая модель защиты информации

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

Опубликовано: Сайт ITSec.Ru-2007
------------------

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

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

К ак примеры комбинаций вышеперечисленных мер можно привести: