Стандарты в области активного аудита

Активный аудит — относительно новая область коммерческой деятельности, однако, проблемы совместимости, согласованной работы различных систем, разумеется, уже дают о себе знать. Начинают формироваться стандарты, которые можно назвать внутренними. Они помогают взаимодействовать между собой компонентам систем активного аудита и системам в целом. Мы кратко опишем две инициативы. Одна исходит от Интернет-сообщества, другая — от академических кругов.

Многие атаки на информационные системы носят распределенный характер. При этом разные средства активного аудита видят один и тот же инцидент с разных точек зрения. Несомненно, совместный, многоаспектный анализ полезен для прослеживания злоумышленников, определения причин и масштабов инцидентов. Разделение информации о подозрительной активности является главным направлением работ недавно созданной в рамках Тематической группы по технологии Интернет (Internet Engineering Task Force, IETF) Рабочей группы по обнаружению вторжений (Intrusion Detection Working Group, IDWG).

В июне 1999 года появился первый (на момент написания статьи — единственный) проект группы — "Требования к формату обмена данными о подозрительной активности". Это "мета-стандарт", выдвигающий довольно общие требования к будущим рекомендациям группы; тем не менее, он представляет несомненный интерес.

Группе IDWG предстоит специфицировать формат и процедуры разделения данных между системами выявления подозрительной активности, реагирования и управления. Для формата уже выбрано название, как это часто бывает, весьма неудачное: Intrusion Detection Exchange Format (IDEF). (Специалисты по технологии программирования знают, что аббревиатура IDEF уже давно занята.) Предполагается, что автоматизированные системы активного аудита будут использовать формат IDEF при формировании сообщений о подозрительной активности. На самом деле требования разрабатывались, в первую очередь, в расчете на взаимодействие между анализирующим компонентом и компонентом реагирования, происходящее по протоколу TCP/IP.

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

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

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

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

Если анализатор сам принял ответные меры, в IDEF-сообщениях должна быть информация об этом. Если анализатор может оценить последствия зафиксированной атаки, он также обязан сообщить об этом.

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

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

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

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

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

Общий каркас систем активного аудита (Common Intrusion Detection Framework, CIDF) разрабатывается группой исследовательских организаций, финансируемых агентством DARPA и работающих в области выявления подозрительной активности. Впрочем, присоединиться к группе может любой желающий.

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

В рамках CIDF разработан язык описания подозрительной активности и способ кодирования информации о подозрительных событиях. Язык приспособлен для описания по крайней мере трех видов сообщений:

Кроме того, на языке могут быть описаны следующие сущности:

По внешнему виду язык CIDF является лиспоподобным. Его основу составляют так называемые S-выражения, первым элементом которых должен быть семантический идентификатор, определяющий смысл последующих элементов. В статье среди прочих приводится пример S-выражения (см. Листинг 3) с небольшими изменениями.

Листинг 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 постепенно угаснет. Однако не вызывает сомнений, что в ближайший год ядро стандартов в области активного аудита так или иначе сформируется, что, несомненно, в перспективе облегчит заказчикам построение интегрированных систем безопасности и управления.