Альтернативна задача захисту інформації від НСД.

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

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

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

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

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

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

Дата добавления: 2015-11-14