Rambler's Top100
Реклама
 
Статьи ИКС № 3 2006
Алексей ЛУКАЦКИЙ  01 марта 2006

Мониторинг событий в IT и безопасности

Представим себе негативную ситуацию, когда снижается пропускная способность сети. С одной стороны, событие может быть вызвано не только некорректной настройкой сетевого оборудования (такая ситуация – предмет рассмотрения систем мониторинга сетевых событий), но и атакой «отказ в обслуживании» (это сфера заботы систем мониторинга событий безопасности). А сама атака такого типа, например SYN Flood, в свою очередь может быть вызвана как целенаправленными действиями злоумышленника, так и обычными неполадками в сетевой карте.

Так в чем же различие подходов к реализации систем мониторинга и почему эти системы не рекомендуется объединять в одном продукте?

Представление о предмете зависит от ракурса

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

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

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

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

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

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

Для одних слон – веревка, для других – столб

Источники данных, которыми пользуются системы мониторинга инфраструктуры и безопасности, также различны. Например, системный журнал Windows больше ориентирован на контроль сбоев в системе, а для целей безопасности мало пригоден. Журнал системы обнаружения атак оптимально подходит для мониторинга с точки зрения безопасности, но совсем не приспособлен для контроля полосы пропускания, анализа качества обслуживания и т.п. Правда, есть примеры и «универсальных» источников: сетевой системный журнал Syslog одинаково эффективен и для контроля системных/сетевых сбоев, и для обнаружения проблем с безопасностью; на уровне сети аналогичную роль может выполнять NetFlow, но с оговорками.

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

Операционные функции

Если сравнивать функции рассматриваемых систем, реализуемые каждой из них, то при мониторинге инфраструктуры – это обнаружение и устранение сбоев. При мониторинге безопасности операций производится гораздо больше: обнаружение инцидента, его расследование, реагирование на угрозы и устранение причин.

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

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

Разные миссии – разные департаменты

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

В тех случаях, когда отдел защиты информации тоже относится к IT-департаменту, возникает другая проблема – конфликт интересов. Подразделение информационной безопасности становится «костью в горле» и в завершение, как правило, оказывается в подчиненном положении у других служб департамента. Это и понятно. Вряд ли системные и сетевые администраторы будут в восторге, если их огрехи в настройке оборудования, приведшие к инцидентам безопасности, выплывут наружу. Значит, исполнители постараются скрыть от высокого руководства любые проблемы с безопасностью.

Наконец, нельзя забывать и о классическом принципе разделения полномочий, который особенно важно соблюдать в вопросах, касающихся безопасности.

Так что единая служба – только во вред эффективному управлению информационными технологиями и сохранности данных информационной системы компании.
Заметили неточность или опечатку в тексте? Выделите её мышкой и нажмите: Ctrl + Enter. Спасибо!