Активный аудит — относительно новая область коммерческой деятельности, однако, проблемы совместимости, согласованной работы различных систем, разумеется, уже дают о себе знать. Начинают формироваться стандарты, которые можно назвать внутренними. Они помогают взаимодействовать между собой компонентам систем активного аудита и системам в целом. Мы кратко опишем две инициативы. Одна исходит от Интернет-сообщества, другая — от академических кругов.
Многие атаки на информационные системы носят распределенный характер. При этом разные средства активного аудита видят один и тот же инцидент с разных точек зрения. Несомненно, совместный, многоаспектный анализ полезен для прослеживания злоумышленников, определения причин и масштабов инцидентов. Разделение информации о подозрительной активности является главным направлением работ недавно созданной в рамках Тематической группы по технологии Интернет (Internet Engineering Task Force, IETF) Рабочей группы по обнаружению вторжений (Intrusion Detection Working Group, IDWG).
В июне 1999 года появился первый (на момент написания статьи — единственный) проект группы — "Требования к формату обмена данными о подозрительной активности" [20] . Это "мета-стандарт", выдвигающий довольно общие требования к будущим рекомендациям группы; тем не менее, он представляет несомненный интерес.
Группе IDWG предстоит специфицировать формат и процедуры разделения данных между системами выявления подозрительной активности, реагирования и управления. Для формата уже выбрано название, как это часто бывает, весьма неудачное: Intrusion Detection Exchange Format (IDEF). (Специалисты по технологии программирования знают, что аббревиатура IDEF уже давно занята.) Предполагается, что автоматизированные системы активного аудита будут использовать формат IDEF при формировании сообщений о подозрительной активности. На самом деле требования [20] разрабатывались, в первую очередь, в расчете на взаимодействие между анализирующим компонентом и компонентом реагирования, происходящее по протоколу TCP/IP.
Прежде всего, в [20] формулируются общетехнические требования, призванные сделать формат IDEF универсальным и долгоживущим.
IDEF должен поддерживать все механизмы обнаружения подозрительной активности. Он должен быть рассчитан на IPv6, содержать все необходимое для интернационализации/локализации, поддерживать фильтрацию и агрегирование сообщений компонентом реагирования, их надежную доставку (в том числе через межсетевой экран без внесения в конфигурацию последнего изменений, способных ослабить периметр безопасности).
Разумеется, формат IDEF должен поддерживать взаимную аутентификацию общающихся сторон, неотказуемость от факта передачи, а также целостность и конфиденциальность потока сообщений.
В сообщениях формата IDEF должны содержаться дата и время подозрительных событий и, если возможно, дата и время атаки. Естественно, оговаривается, что формат даты должен быть свободен от Проблемы 2000 и аналогичных сложностей. Специфицируется присутствие в сообщениях списка сенсоров, зафиксировавших подозрительное событие.
Если анализатор сам принял ответные меры, в IDEF-сообщениях должна быть информация об этом. Если анализатор может оценить последствия зафиксированной атаки, он также обязан сообщить об этом.
Формат IDEF должен поддерживать информацию о производителе системы активного аудита, сгенерировавшей сообщение, а также расширения, специфичные для конкретной системы.
Предполагается, что будет утвержден список стандартных атак и методов их проведения. Если анализатор может идентифицировать атаку и используемый метод, он должен включить соответствующую информацию в IDEF-сообщение. Если атака является нестандартной, ее имя может быть специфичным для производителя системы активного аудита.
В сообщениях могут содержаться идентификаторы источника и цели атаки. Если атака имеет сетевой характер, в качестве идентификаторов могут использоваться IP-адреса. Для системных и прикладных атак идентификаторы источника/цели пока не ясны.
Формат IDEF должен допускать включение в сообщения дополнительной информации, ассоциированной с подозрительным событием. В частности, в сообщениях должно быть предусмотрено поле для размещения рекомендаций какого-либо авторитетного органа, такого как CERT.
Будем надеяться, что выполнение сформулированных требований не заставит себя долго ждать, и уже в этом, 1999 году, мы увидим спецификации формата сообщений и процедур обмена.
Общий каркас систем активного аудита (Common Intrusion Detection Framework, CIDF, см. [21] ) разрабатывается группой исследовательских организаций, финансируемых агентством DARPA и работающих в области выявления подозрительной активности. Впрочем, присоединиться к группе может любой желающий.
Цель создания общего каркаса близка к исходным посылкам группы IDWG (см. предыдущий пункт) — обеспечить интероперабельность и разделение информации различными системами активного аудита и их компонентами, максимизировать повторное использование последних в различных контекстах. В сходстве целей нет ничего удивительного, поскольку именно участники группы CIDF стали инициаторами организации группы IDWG, хотя теперь последняя живет своей, вообще говоря, независимой жизнью.
В рамках CIDF разработан язык описания подозрительной активности и способ кодирования информации о подозрительных событиях. Язык приспособлен для описания по крайней мере трех видов сообщений:
Кроме того, на языке могут быть описаны следующие сущности:
По внешнему виду язык CIDF является лиспоподобным. Его основу составляют так называемые S-выражения, первым элементом которых должен быть семантический идентификатор, определяющий смысл последующих элементов. В статье [21] среди прочих приводится пример S-выражения (см. Листинг 3 ) с небольшими изменениями.
(Delete (Context (HostName 'main.strange.com') (Time '23:55:12 Aug 11 1999') ) (Initiator (UserName 'root') ) (Source (FileName '/etc/passwd') ) ) |
Данное выражение означает, что в указанное время пользователь root удалил файл /etc/passwd на компьютере main.strange.com. Семантические идентификаторы задают действия (Delete) и роли (Context, Initiator и т.п.), выполняемые объектами. В результате становится понятно, что, кто, где и когда сделал.
Для организации взаимодействия между компонентами в каркасе CIDF предлагается использовать службу каталогов (LDAP). Компоненты регистрируются и афишируют виды выражений, которые они отправляют или воспринимают. Разумеется, в каталоге может быть и другая информация, например, сертификаты в стандарте X.509 и т.п.
На момент написания данной статьи судьба спецификаций CIDF представляется неясной. С одной стороны, в них предложены вполне разумные идеи. С другой стороны, какой-либо поддержки со стороны производителей коммерческих систем у CIDF нет (возможно, потому, что производители еще не доросли до стандартов). Вероятно, центр активности переместится в группу IDWG и инициатива CIDF постепенно угаснет. Однако не вызывает сомнений, что в ближайший год ядро стандартов в области активного аудита так или иначе сформируется, что, несомненно, в перспективе облегчит заказчикам построение интегрированных систем безопасности и управления.
|
|
|
|
| Методы проведения активного аудита | Содержание | Примеры систем активного аудита |
| Copyright ╘ 1993-2000, Jet Infosystems |