Конфигурация механизма регистрации событий и оповещения об атаках

Система обнаружения атак при возникновении событий безопасности должна сочетать следующие действия:

· регистрацию и оповещение об обнаруженных атаках, уязвимостях и иных нарушениях политики безопасности;

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

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

· действительно свершившихся атаках;

· потенциальных атаках, которые могут привести к компрометации всей сети в целом; неудачных попытках регистрации в контролируемой системе;

· изменениях или реконфигурации программного обеспечения системы обнаружения атак или иного средства защиты, установленного в сети;

· системных сообщениях (переполнение памяти, нарушение соединения между сенсором и консолью и т. д.).

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

Журналы регистрации

Нет необходимости хранить журналы регистрации более 3-4 недель. Поскольку системы обнаружения атак являются средствами защиты в реальном режиме времени, то хранение журналов больше указанного срока не имеет большого практического значения. Кроме того, как показывает опыт, администраторы системы обнаружения атак очень редко обращаются даже к событиям, произошедшим на прошлой неделе, не говоря уже о записях двух- и трехнедельной давности. Данный тезис не относится к системам анализа защищенности, которые могут обращаться к данным трех- и даже шестимесячного срока давности для исследования произошедших на анализируемом участке изменений (рис. 10.10). В любом случае по истечении заданного срока журналы регистрации систем обнаружения атак и анализа защищенности следует сохранять в архиве, чтобы при необходимости можно было к ним обратиться в любое время.

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

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

· Ожидаемый размер журнала регистрации для каждого компонента. Как правило, если для сенсоров "классических" систем обнаружения атак можно указать максимальный размер журнала регистрации, то для консоли или для систем анализа защищенности обычно этого не делается, т. к. заранее определить, как быстро будет заполняться журнал регистрации невозможно. Существуют два способа задания размера журнала – в байтах и записях. Различные системы обнаружения атак совмещают оба эти способа, причем сделать выбор в пользу того или иного достаточно трудно, т. к. каждый из них имеет свои преимущества.

Рис. 10.10. Сравнительный анализ уровня защищенности за заданный

интервал времени

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

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

· Порядок резервного копирования и восстановления журналов регистрации. Поскольку журналы регистрации очень быстро заполняются, необходимо регистрировать только то, что действительно необходимо. Иначе журнал регистрации будет "распухать" настолько "споро", что займет все выделенное ему пространство, и любые последующие события не будут фиксироваться. Иногда это может послужить поводом для реализации атаки типа "отказ в обслуживании" (Log Flood) на саму систему обнаружения атак. Поскольку заранее предсказать, как скоро будет заполняться журнал регистрации, невозможно, то желательно задействовать механизм автоматической синхронизации, реализованный в некоторых системах обнаружения атак (например, в RealSecure). Этот механизм позволяет копировать журнал регистрации сенсора системы обнаружения атак на центральную консоль в момент удовлетворения определенному критерию (например, числу записей или объему файла журнала регистрации).

В том случае, когда условие соблюдено, но осуществить синхронизацию невозможно (скажем, по причине нарушения соединения между сенсором и консолью), то повторная попытка синхронизации начинается через так называемый интервал уведомления (notification interval). И критерий синхронизации, и интервал уведомления задаются администратором (рис. 10.11).

Рис. 10.11. Синхронизация журналов регистрации

Хочу напомнить, что в настоящий момент стоимость жестких дисков невелика, и поэтому не стоит экономить на их приобретении. Объем дискового пространства для хранения журналов регистрации не должен быть сдерживающим фактором для уменьшения частоты регистрации и количества регистрируемых событий.