Профили защиты, разработанные на основе "Общих критериев". Часть 2. Частные требования к сервисам безопасности

Системы активного аудита

В работе [ 6 ] приведен набросок семейства профилей защиты для классификации систем активного аудита, а также соображения по расширению набора функциональных требований "Общих критериев". Проекты ПЗ для важнейших компонентов подобных систем - анализатора и сенсора - представлены в [ 57 ] , [ 58 ] .

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

Назначение активного аудита - оперативно выявлять подозрительную активность и предоставлять средства для автоматического реагирования на нее.

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

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

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

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

С целью адекватного отражения специфики средств активного аудита в [ 6 ] предложен ряд добавлений к стандартному набору функциональных требований.

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

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

Еще один предлагаемый компонент - FAU_GEN.4 - предназначен для обеспечения неотказуемости сервиса, пользующегося услугами семейства FAU_GEN, от регистрации события. Вообще говоря, неотказуемость реализуется, даже если не были востребованы коммуникации, поэтому здесь нельзя прибегнуть к классу FCO.

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

Автоматический анализ регистрационной информации с целью выявления подозрительной активности представлен в "Общих критериях" четырьмя компонентами семейства FAU_SAA.

FAU_SAA.1 ориентирован на обнаружение превышения порогов, заданных фиксированным набором правил.

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

"Общие критерии" допускают анализ и в реальном времени, и постфактум; поддержку анализа в реальном времени следует рассматривать как важнейшую отличительную особенность средств активного аудита.

FAU_SAA.3 направлен на обнаружение простых атак путем проведения сигнатурного анализа.

FAU_SAA.4 позволяет выявлять сложные, многоэтапные атаки, осуществляемые группой злоумышленников.

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

В [ 6 ] вводится еще один компонент, FAU_SAA.5, фиксирующий нарушения политики безопасности. Задавать политики предлагается с помощью предикатов первого порядка.

Что касается автоматического реагирования на подозрительную активность, то "Общие критерии", по сути, ограничились констатацией подобной возможности. В [ 6 ] рассматривается более сложная сущность - решатель, который, получив рекомендации от компонентов анализа, определяет, действительно ли имеет место подозрительная активность, и, при необходимости, надлежащим образом реагирует (выбирая форму реакции в зависимости от серьезности выявленных нарушений).

Это значит, что решатель должен уметь:

• ранжировать подозрительную активность ;
• реагировать в соответствии с рангом нарушения.

Управление обоими аспектами поручено администратору безопасности.

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

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

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

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

Первая группа обслуживается семейством FPT_SEP.

Вторая группа свойств поддерживается такими техническими решениями, как программное обеспечение (ПО) промежуточного слоя, кластерные конфигурации и т.д. В плане безопасности целесообразно следовать требованиям FPT_FLS.1 (невозможность перехода в небезопасное состояние в случае сбоя или отказа), а также FPT_RCV.2, FPT_RCV.3, FPT_RCV.4 (надежное восстановление в автоматическом режиме, без потери данных, с точностью до функции безопасности).

Безопасность интерфейсов   монитора (с другими мониторами, сенсорами, администратором безопасности) может обеспечиваться компонентами FPT_ITI.1, FPT_ITI.2 (обнаружение и исправление модификации экспортируемых данных), FPT_ITC.1 (конфиденциальность экспортируемых данных), FPT_ITA.1 (доступность экспортируемых данных).

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

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

При формировании классификационной схемы средств активного аудита в [ 23 ] предлагается выделить базовый (минимальный) ПЗ, а дополнительные требования компоновать в функциональные пакеты.

Профили защиты, соответствующие классам защищенности, строятся на основе базового ПЗ и соответствующих комбинаций ФП.

В [ 23 ] предлагается зафиксировать профили для следующих разновидностей средств активного аудита:

• класс 5 - защита одного информационного сервиса с отслеживанием фиксированного набора характеристик и пороговым анализом (базовый ПЗ);
• класс 4 - защита однохостовой конфигурации с произвольным набором информационных сервисов, отслеживанием сетевого трафика, системных и прикладных событий, пороговым и простым сигнатурным анализом в реальном масштабе времени;
• класс 3 - защита сегмента локальной сети от многоэтапных атак при сохранении остальных предположений класса 4;
• класс 2 - защита произвольной конфигурации с выявлением нетипичного поведения при сохранении остальных предположений класса 3;
• класс 1 - наложение всех требований с возможностью обеспечения заданного соотношения между ошибками первого и второго рода.

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

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

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

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