Предисловие (стр. 98 )

повторное подтверждение рамок проведенного аудита;

краткое изложение найденных несоответствий, согласованных изменений;

краткое изложение замечаний и предложений;

общие замечания по ходу аудита и комментарии к отчету;

рекомендация или отказ в сертификации (или продолжении сертификации);

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

Участники вступительного собрания и заключительного совещания должны быть официально зарегистрированы.

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

соответствие полученных результатов внутренним требованиям организации в области информационной безопасности и стандартам BS7799 – согласно плану проведения аудита и «Ведомости соответствия»;

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

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

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

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

в них реализован учет аспектов, связанных с рисками, что позволяет оптимизировать построение подсистемы безопасности по критерию цена/эффективность;

в то время как российские РД в основном ориентированы на обеспечение конфиденциальности, в зарубежных существует лучший учет таких аспектов ИБ, как целостность и доступность;

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

19.3.1. Средства аудита СУБД

Ядром построения ИС предприятия является СУБД промышленного уровня. Полноценная система обеспечения безопасности ИС должна обладать развитыми средствами аудита, то есть, как минимум, СУБД должна обладать средствами  автоматического ведения протоколов действий пользователей системы.

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

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

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

запускать и останавливать средства аудита;

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

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

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

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

Категория AUDIT (audit events). При фиксации событий категории AUDIT в журнальный файл записывается информация об изменениях настроек аудита и выполнении операций доступа к журнальному файлу.

Категория CHECKING (checking events). При фиксации событий категории CHECKING в журнальный файл заносится информация о выполнении операций контроля привилегий, которые осуществляются DB2 при выполнении операций с объектами системы.

Категория OBJMAINT (object maintenance events). При фиксации событий категории OBJMAINT в журнальный файл заносится информация о выполнении операций создания или уничтожения объектов системы.

Категория SECMAINT (security maintenance events). При фиксации событий категории SECMAINT в журнальный файл заносится информация о выполнении операций предоставления и отзыва полномочий и привилегий. Также в журнальный файл заносится информация о выполнении операций модификации параметров sysadm_group, sysctrl_group или sysmaint_group.

Категория SYSADMIN (system administrator events). При фиксации событий категории SYSADMIN в журнальный файл заносится информация о выполнении операций, для выполнения которых требуются полномочия SYSADM, SYSCTRL  или SYSMAINT.

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

Категория CONTEXT (context events). При фиксации событий категории CONTEXT в журнальный файл заносится информация о контексте выполнении операции. Для этой категории характерна фиксация нескольких событий, связанных с одним действием (выполнением одного SQL-предложения) с базой данных.

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

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

Определение перечня фиксируемых событий может быть модифицировано в любое время пользователем, имею­щим привилегию AUDIT SYSTEM (для аудита системных со­бы­тий) или AUDIT ANY (для аудита событий, связанных с до­ступом к объекту системы). Заметим, что модификация пе­речня фиксируемых событий может быть выполнена и в пе­риод, когда служба аудита не активизирована. Есте­ст­вен­но, что записи о событиях перечня начнут появляться только по­сле активизации службы.

ЛИТЕРАТУРА

Гостехкомиссия России. Руководящий документ. Средства вычислительной техники. Защита от несанкционированного доступа к информации. Показатели защищенности от несанкционированного доступа к информации. М., Военное издательство, 1992г.

Гостехкомиссия России. Руководящий  документ. Автоматизированные системы. Защита от несанкционированного доступа к информации. Классификация автоматизированных систем и требования по защите информации. М„ Военное издательство, 1992 г.

, . Основы защиты информации. –  М: в ППО «Известия», 1997. 537с.

, Тимонина основы защиты информации. – М.: Яхтсмен, 1996.-192с.

Дейт. К. Введение в системы баз данных. : Пер. С англ. - 6-е изд. – К.: Диалектика, 1998.- 784с., ил.

, Ивашко безопасности информационных систем. – М.: Горячая линия – Телком, 2000. - 452 с., ил.

Лукацкий атак. – СПб.: БХВ-Петербург, 2001.- 624с.

, Петренко безопасности Intranet. –  М.: ДМК Пресс, 2002.- 416 с., ил. 

, , Безопасность электронного бизнеса.— М.: Гелиос АРВ, 2001.— 416 с.

Симонов рисков в информационных системах. Практические аспекты. Защита информации. Конфидент. Март-апрель № 2, 2001 г. сс. 48-53

Симонов аудита информационной безопасности. Защита информации. Конфидент. Март-апрель № 2, 2002 г. сс. 36-41

,   Работаем с Oracle: Учебное пособие/ 2-е изд., испр. и доп..— М.: Гелиос АРВ, 2002.— 496 с.

CobiT: Executive Summary. — ISACA, 3nd Edition, 2000. Размещен на сайте ISACA http://www. ISACA. org

Code of practice for Information security management. British Standard BS7799, 1995.

Information security management. Part 2. Specification for information security management systems. British Standard BS7799, Part 2, 1998.

Контрольные вопросы

Сформулируйте понятие безопасности информационной системы. Укажите связи с понятиями безопасности систем более высокого уровня.

Предложите некоторую формулировку понятия информационная безопасность.

Какие угрозы безопасности по цели реализации угроз Вам известны?

Охарактеризуйте и приведите конкретные примеры активного и пассивного воздействия на информационные системы.

Какие характеристики  безопасности информационных систем Вам известны. Дайте содержательное объяснение существа каждой характеристики.

Что такое политика безопасности?

Сформулируйте определения базовых моделей безопасности данных.