Мельников Д. А. - Информационная безопасность открытых систем - 2013

•постоянство внутренних данных, данная величина явля­ ется внутренне постоянной тогда и только тогда, когда все модификации этой величины удовлетворяют соот­ ветствующим ПЛЦЛ;

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

Если описанное выше отличие принимается, то оно может быть совмещено с классификацией по уровню защиты целост­ ности, а именно:

•высокий уровень защиты сохраняет постоянство вну­ тренних и внешних данных;

•низкий уровень защиты выявляет нарушения постоян­ ства внутренних и/или внешних данных.

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

1)может ли быть нарушена элементарность самой элемен­ тарной операции?

2)существуют ли гарантии того, что операцию необходимо проводить?

И в заключение можно классифицировать СПЦЛ, которые касаются сохранения следующих свойств:

•внутренняя/внешняя целостность;

•низкий/высокий уровень защиты;

•элементарность/гарантированность операций над защи­ щенными данными.

354

Таким образом, когда определяется СПЦЛ, целесообразно проанализировать следующие вопросы:

1)Какую форму целостности (внутреннюю, внешнюю, обе сразу) обеспечивают СПЦЛ?

2)Какой уровень защиты целостности данных обеспечи­ вается (низкий или высокий)? Устойчив ли СПЦЛ к целенаправленным атакам, к случайным изменениям или обоим вариантам? Обеспечивает СПЦЛ восстанов­ ление?

3)Защищает ли СПЦЛ элементарные операции или он обе­ спечивает гарантии (также) того, что операция будет про­ ведена?

Общая структура службы обеспечения целостности пред­ ставлена в табл. 7.1, где используются следующие концептуаль­ ные термины.

Объекты/субъекты обеспечения целостности в системах ЭМВОС или Интернет-архитектуры:

•инициатор. Объект, который формирует данные, це­ лостность которых подлежит защите, путем защиты данных и их передачи или хранения;

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

•ДТС, предоставляющая средства для обеспечения це­ лостности. Субъект, который предоставляет ВИ для защиты целостности данных или ВИ для обнаруже­ ния модификации данных и осуществляет соответст­ вующие ПРЦЛ от имени инициатора или проверяю­ щей стороны.

355

356

Глава 8 ___________________________

ТЕОРЕТИЧЕСКИЕ ОСНОВЫ АУДИТА БЕЗОПАСНОСТИ И ОПОВЕЩЕНИЯ ОБ ОПАСНОСТИ

В данной главе описывается базовая модель обработки сиг­ налов службы оповещения об опасности (о нарушении безопас­ ности) и проведения аудита безопасности открытых систем ЭМВОС и Интернет-архитектуры. Аудит безопасности (АДБ) представляет собой независимые ревизию и анализ системных записей и основных направлений деятельности. Служба аудита безопасности (СЛАД) предоставляет аудиторскому центру воз­ можность определять, отбирать и администрировать события, которые необходимо зарегистрировать в качестве данных для последующего проведения аудиторской проверки обеспечения (состояния) ИБ.

Рассматриваемая далее концепция АДБ включает выявле­ ние событий и определяет процедуры, которые являются след­ ствием обнаружения этих событий. В главе рассматривается не только АДБ, но и служба оповещения об опасности (СЛОО).

Целями АДБ являются:

•участие в процедуре идентификации и анализе неавтори­ зованных действий (процедур) или атак;

•помощь в обеспечении гарантий того, что всем операциям в интересах объектов/субъектов, которые за них отвеча­ ют, могут быть присвоены соответствующие атрибуты;

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

•подтверждение соответствия существующей ПЛБ;

•доведение (доклад) информации, которая может указы­ вать на несоответствия в системных средствах управле­ ния;

•определение соответствующих изменений, которые необ­ ходимо внести в средства управления, ПЛБ и процедуры.

358

АДБ включает обнаружение, отбор и регистрацию различ­ ных событий, которые тем или иным образом связаны с обеспе­ чением (состоянием) безопасности (событием безопасности), для аудиторской проверки обеспечения (состояния) безопасно­ сти и анализ таких событий.

Аудит и идентифицируемость (accountability) требуют,

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

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

•оповещение о реальных или очевидных попытках нару­ шения безопасности;

•оповещение о различных событиях безопасности, вклю­ чая «штатные» события;

•оповещение о событиях, которые обусловлены достиже­ нием некоторых предельных ограничений.

Таким образом, функциональным предназначением СЛАД и СЛОО является обеспечение гарантий того, что события безо­ пасности обрабатываются, анализируются и контролируются согласно ПЛБ соответствующего ЦБ.

359

Далее рассматриваются:

•базовые концепции АДБ и оповещения об опасности;

•общая модель АДБ и оповещения об опасности;

•взаимосвязи СЛАД и СЛОО с другими СЛБ.

8 .1 . О б щ и е п о л о ж е н и я

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

СОП формируется вслед за обнаружением любых событий безопасности, определяемых ПЛБ как условие оповещения об опасности. Это могло бы включать предварительно согласован­ ный предельный случай, достижение которого тоже является условием подачи СОП. Некоторые из этих случаев могут потре­ бовать незамедлительного проведения процедуры восстановле­ ния, а другие —последующего расследования в целях определе­ ния, какое действие необходимо, если не предписано что-либо другое.

Реализация модели АДБ и СОП может потребовать исполь­ зование других СЛБ в целях обеспечения самих СЛАД и СЛОО, а также для обеспечения гарантий их корректного и надежного функционирования.

Несмотря на то, что итоговые данные (результаты) АДБ и процедуры аудиторской проверки обеспечения (состояния) безопасности (ПРАД) обладают определенными характеристи­

360

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

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

ПРИМ ЕЧАНИЕ. Модель АДБ и СОП не рассматривает, как

с ней связаны функциональные и вспомогательные средства обе­

спечения.

8 .1 .1 . М одель и ф ун кц и и

8.1.1.1. Функции СЛАД и СЛОО

Для реализации СЛАД и СЛОО необходимо выполнение различных функций, среди которых:

•определение (классификация) события (event discrimina­ tor), которая обеспечивает предварительный анализ со­ бытия и определяет, куда следует направлять данные о событии: либо средству регистрации, либо средству об­ работки СОП;

•регистрация данных (результатов) АДБ (audit recor­ der), которая заключается в формировании записей АДБ и хранении этих записей в базе данных для результатов АДБ(БДРА);

•обработка СОП (alarm processor), которая заключается в формировании сообщения аудиторской проверки и реа­ гировании на поступивший СОП;

•анализрезультатов АДБ (audit analyser), который заклю­ чается в проверке результатов АДБ и, если необходимо, формирует СОП и сообщения АДБ;

361

•формирование отчета по результатам АДБ (audit trail examiner), которое заключается в формировании отчетов (электронных докладов) на основе одного или несколь­ ких результатов АДБ;

•предоставление записей БДРА (audit provider), которое заключается в передаче (доставке) записей БДРА по не­ которому критерию;

•архивирование записей БДРА (audit archiver), которое заключается в передаче (доставке) некоторых записей БДРА на архивное хранение (в архив).

Для распределенных СЛАД и СЛОО необходимо выполне­ ние следующих дополнительных функций:

•отбор результатов АДБ (audit trail collector), который заключается в сборе записей из распределенных БДРА в одну определенную БДРА;

•диспетчеризация результатов АДБ (audit dispatcher), ко­ торая заключается в доставке частей (или в целом виде) записей из распределенных БДРА средству, реализующе­ му функцию отбор результатов АДБ.

8.1.1.2. Модель АДБ и СОП

Модель АДБ и СОП включает несколько фаз (рис. 8.1). За обнаружением события следует его обязательная классифи­ кация, т.е. связано ли это событие с обеспечением (состояни­ ем) безопасности или нет. Средство классификации события

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

362

татов АДБ на основе определенного критерия. Иначе говоря, на основе анализа результатов АДБ формируются соответствую­ щие отчеты и/или СОП.

Рис. 8.1. Модель процессов аудита безопасности и оповещения об опасности

8.1.13. Объединение в группы функций АДБ и оповещения об опасности

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

363