Методы проведения активного аудита

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

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

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

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

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

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

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

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

Мы оставляем вне рамок нашего рассмотрения интерфейсы с СУБД (для хранения и обработки регистрационной информации), и с системами управления, поскольку это стандартные технические моменты, многократно описанные в литературе. Еще раз подчеркнем, что безопасность — это инфраструктурное свойство информационных систем. Сервисы безопасности должны быть интегрированы с другими инфраструктурными механизмами (управления, хранения и т.п.), иначе эксплуатация и развитие информационной системы окажутся крайне сложными и дорогостоящими.

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

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

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

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

На наш взгляд, по многим причинам полезно представлять себе информационную систему как совокупность сервисов (а не сетей и узлов). Соответственно, нужно протоколировать и анализировать поведение сервисов независимо от места их локализации и степени распределенности. Сеть как таковая обеспечивает передачу данных (мы не берем сейчас в расчет дополнительные сетевые сервисы, это отдельный вопрос). Пытаться извлечь из сетевого трафика нечто большее (например, информацию о поведении приложений) нецелесообразно, да и невозможно (мы вернемся к этому вопросу в разделе, посвященном тестированию систем активного аудита). Даже в таком продвинутом продукте, как FireWall-1 компании CheckPoint, не удалось достичь полного успеха в деле фильтрации с восстановлением контекста — разграничение межсетевого доступа с точностью до команд прикладных протоколов осталось возможным только при применении "честных" proxy-сервисов. А ведь у межсетевых экранов цели анализа проще, чем у систем активного аудита!

Рискнем утверждать, что без понимания семантики защищаемых или анализируемых объектов обеспечение безопасности невозможно. Это понимание может быть выражено в процедурном (программы) или декларативном (описания) видах, но оно должно существовать. Декларативная семантика предпочтительнее, поскольку она позволяет без изменений применять программный продукт к различным объектам. Здесь опять-таки напрашивается аналогия с системами управления и административными информационными базами (MIB).

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

Традиционным является вопрос, где размещать сенсоры систем активного аудита. Столь же традиционный ответ гласит: "везде, где можно". Только анализ всех доступных источников информации позволит с достоверностью обнаруживать атаки и злоупотребления полномочиями и докапываться до их первопричин. Если вернуться к трактовке информационной системы в виде совокупности сервисов, то средства обнаружения атак должны располагаться перед защищаемыми ресурсами (имея в виду направление движения запросов к сервисам), а средства выявления злоупотреблений полномочиями — на самих сервисах. Обнаружение аномальной активности полезно во всех упомянутых точках. Только при таком размещении сенсоров будет выполнен важнейший принцип невозможности обхода защитных средств. Кроме того, будет минимизировано число сенсоров, что в условиях сегментации сетей и применения коммутационных технологий также оказывается проблемой.

К числу часто задаваемых относится и вопрос о том, как сочетать средства активного аудита (в первую очередь, сетевого) и межсетевые экраны. Разумеется, эти механизмы безопасности не исключают, а дополняют друг друга. Например, межсетевой экран бессилен против нелегальных модемных входов/выходов, а активный аудит позволяет обнаруживать их. Еще один вопрос — располагать ли средства выявления атак перед межсетевым экраном, чтобы защитить его. Любопытно, что за "круглым столом" специалисты высказывали на этот счет прямо противоположные мнения. На наш взгляд, межсетевым экранам нужно доверять, они являются продуктом более зрелой технологии, чем коммерческие системы активного аудита. Конечно, целесообразно контролировать целостность конфигурации экрана, выявлять иные возможные аномалии, но это происходит уже не снаружи, а внутри. Если же становится известно о каких-либо слабостях в программном обеспечении межсетевого экрана, то их, несомненно, нужно немедленно устранять, а не наблюдать за тем, как их пытаются использовать.

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

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

Для выявления злоумышленной активности пытались и пытаются использовать несколько универсальных технологий: экспертные системы, нейронные сети, сопоставление с образцом, конечные автоматы и т.п. Одной из первых и до сих пор самой употребительной остается технология обнаружения сигнатур злоумышленных действий. Идея состоит в том, чтобы каким-либо образом задать характеристики злоумышленного поведения (это и называется сигнатурами), а затем отслеживать поток событий в поисках соответствия с предопределенными образцами. Иногда сопоставление основывается на простом (применительно к активному аудиту — наивном) механизме регулярных выражений, известному всем по ОС Unix. В более серьезных разработках уже свыше десяти лет используются экспертные системы, опирающиеся на наборы правил, задающие более мощные языки.

Грубо можно считать, что экспертная система состоит из универсальной оболочки и наполнения в виде правил вывода, являющихся формализацией знаний о предметной области. В области активного аудита чаще всего используется оболочка P-BEST (Production-Based Expert System Toolset). Ее мы и рассмотрим вместе с некоторыми сигнатурами атак, заимствованными из той же статьи.

Разумеется, мы не будем вдаваться в теорию и тонкости экспертных систем. Нас будут интересовать, в основном, вопросы эффективности и сопряжения с окружением (обычно управляющим). Отметим лишь, что P-BEST относится к категории систем прямого связывания, то есть она отправляется от известных фактов, сопоставляет их с записанными в правилах условиями и выводит новые факты до тех пор, пока не будет достигнута цель (в нашем случае — обнаружена злоумышленная активность).

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

В состав P-BEST входит компилятор pbcc, транслирующий правила вывода в функции языка C. После компиляции может быть получена либо самостоятельная экспертная система, либо набор библиотек, которые можно подключить к более широкому окружению. Для нас существенно, что язык P-BEST достаточно прост и интуитивно ясен, поэтому в принципе пользователи сами могут описывать на нем новые атаки и иные злоумышленные действия. Компиляция (в противовес интерпретации) правил позволяет получить эффективное решение, пригодное для работы в реальном масштабе времени. В состав антецедентов и консеквентов могут входить произвольные функции языка C. Это упрощает связь с окружением, программирование реакций и т.п.

Приведем пример простого правила, записанного на языке P-BEST (см. Листинг 1). Оно обрабатывает неудачную попытку входа в систему. Предполагается, что ранее были описаны типы event и bad_login с соответствующими полями.

Листинг 1

  rule [Bad_Login(#10;*):
  [e:event| event_type == login,
            return_code == 'BAD_PASSWORD]
==>
  [+bad_login| username = e.username,
               hostname - e.hostname]
  [-|e]
  [!|printf("Bad login for user %s from host %s\n", e.username, e.hostname)]
]

В первой строке, помимо названия правила, указан его приоритет (10), влияющий на порядок выполнения, а также дано разрешение на его многократное применение. Чтобы не случилось зацикливания, оператор "[-|e]" в консеквенте удаляет факт e из базы фактов, но предварительно в эту базу добавляет факт bad_login, который затем можно использовать, например, для подсчета числа неудачных попыток входа. Наконец, конструкция "!|" позволяет выполнять функции языка C. Разумеется, в реальных системах реакция должна быть более изощренной.

В качестве реального примера использования языка P-BEST рассмотрим правило, идентифицирующее атаки посредством переполнения буфера, резервируемого для хранения параметров (см. Листинг 2). Подобные атаки используют ошибки в программном обеспечении, связанные с проверкой корректности параметров (точнее, с отсутствием или недостаточностью таких проверок). Если подходящим образом задать слишком длинные параметры некоторым утилитам, выполняющимся от имени суперпользователя (таким, например, как eject или fdformat в Solaris 2.5), можно выполнить в привилегированном режиме произвольную команду.

Листинг 2

  
rule[BSM_LONG_SUID_EXEC(*):
  [+e:bsm_event]
  [?|e.header_event_type == AUE_EXEC ||
     e.header_event_type == AUE_EXECVE]
  [?|e.subject.euid != e.subject.ruid]
  [?|e.header_size > 'NORMAL_LENGTH]
==>
  [!|printf("ALERT: buffer overrun attack on command %s\n", e.header_command)]
]

Приведенное правило рассчитано на модуль регистрации/аудита BSM в ОС Solaris. Идея выявления атак посредством переполнения буфера основана на анализе длины аргументов системных вызовов группы exec. Оказывается, размер учетной записи о "зловредном" exec составляет не менее 500 байт, в то время как в нормальных случаях он практически никогда не превышает 400.

Имеются и другие примеры. Например, набор для выявления атак на доступность "SYN flood" состоит из семи правил, самое длинное из которых насчитывает 12 строк. Это означает, что подобные наборы вполне реально разрабатывать самостоятельно.

Впрочем, выразительная сила языка правил для экспертных систем никогда не вызывала сомнений. Традиционной проблемой была эффективность функционирования. Согласно приведенным в литературе данным, на обработку регистрационного журнала размером 1.41 ГБ с числом записей 4.2 миллиона при 16 наборах правил на компьютере с процессором Pentium II (330 МГц) и операционной системой FreeBSD 2.2.6 потребовалось чуть больше 30 минут. Журнал был накоплен за пять суток (120 часов) работы. Значит, поиск сигнатур в данном случае отнимает менее 0.5% процессорного времени. Поскольку, как выяснилось, время обработки растет гораздо медленнее, чем первая степень числа правил, имеется масса резервов для увеличения количества сигнатур и усложнения выполняемых проверок.

Таким образом, подход, основанный на выявлении сигнатур злоумышленных действий средствами экспертных систем, оказывается вполне работоспособным со всех точек зрения.

Подчеркнем еще раз, что выразительная сила языка регулярных выражений для задания сигнатур, конечно, не является достаточной в силу возможности вариаций при проведении атак. Простая фрагментация IP-пакетов или смена подразумеваемых значений в зловредном коде на какие-то иные (например, изменение входного имени и/или пароля известной программы Back Orifice) способна обмануть систему активного аудита, использующую жесткие сигнатуры. Системы на основе регулярных выражений делать относительно несложно, но технологически они уже устарели, вне зависимости от занимаемой ими доли рынка.

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

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

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

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

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

Статистический анализ (с учетом сделанных оговорок) представляется нам наиболее перспективным, отчасти "от противного", в силу недостатков, присущих другим подходам.

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

Основной недостаток экспертных систем был указан выше — неумение выявлять (и, следовательно, отражать) неизвестные атаки.

У статистического подхода также есть проблемы:

Тем не менее, как показывает опыт, с этими проблемами можно бороться.

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

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

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

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

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

В литературе рассматривается ряд сценариев сетевой активности и предлагаются эффективно работающие наборы параметров. Так, для сервисов типа SMTP или FTP целесообразно отслеживать категориальные характеристики: имена каталогов, к которым осуществляется доступ; протоколы, используемые для определенных портов; типы фиксируемых ошибок.

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

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

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

Для успеха статистического подхода важен правильный выбор субъектов, поведение которых анализируется. На наш взгляд, целесообразно анализировать поведения сервисов или их компонентов (например, доступ анонимных пользователей к FTP-сервису). По сравнению с отдельными пользователями, поведение сервисов отличается большей стабильностью, да и для информационной безопасности организации важны именно сервисы. Совсем нет смысла анализировать сетевой трафик "вообще", его также нужно структурировать по типам поддерживаемых сервисов (плюс служебные моменты сетевого и транспортного уровней, такие как установление соединений).

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

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

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

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

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

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

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

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

На первое место следует поставить требование полноты. Это весьма емкое понятие, включающее в себя следующие аспекты:

Пропуск даже одного сетевого пакета может дать злоумышленнику шанс на успешную атаку. Если известно, что система активного аудита обладает недостаточной производительностью, она может стать объектом атаки на доступность, на фоне которой будут развиваться другие виды нападения. Для локальных сетей стандартными стали скорости 100 Мбит/с. Это требует от системы активного аудита очень высокого качества реализации, мощной аппаратной поддержки. Если учесть, что защищаемые сервисы находятся в постоянном развитии, то станет понятно, что требование производительности одновременно является и требованием масштабируемости.

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

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

Системы активного аудита принадлежат к области высоких технологий. У них развитая математическая база, продвинутая архитектура, они вобрали в себя знания по информационной безопасности. Мало кто из реселлеров понимает, как работает то, что они продают; им остается пересказывать рекламные буклеты производителей, где, конечно, все выглядит замечательно. Заказчики тоже не обязаны вдаваться в детали, но они должны знать, о чем спрашивать поставщиков. Не всегда те смогут ответить, но и молчание многое скажет заказчику.