- •Безопасность вычислительных систем и сетей Учебное пособие
- •Раздел 1. Проектирование и оценка эффективности системы защиты информации 7
- •1.1. Основные понятия и базовые требования к средству защиты информации 7
- •Раздел 2. Проектирование системы защиты персональных данных 52
- •Раздел 3. Основополагающие методы обеспечения информационной безопасности 76
- •3.3. Разграничение доступа к ресурсам 98
- •3.4. Контроль целостности и аудит 163
- •3.5. Защита сети 168
- •3.6. Выводы по разделу 3 182
- •Раздел 1. Проектирование и оценка эффективности системы защиты информации
- •1.1. Основные понятия и базовые требования к средству защиты информации
- •1.1.1. Функциональная безопасность системного средства
- •1.1.1.1. Чем определяются требования к средствам защиты информации
- •1.1.1.2. Требования к достаточности набора механизмов защиты информации
- •1.1.1.2.1. Требования к защите конфиденциальной информации (к классу защищенности 1г)
- •1.1.1.2.2. Требования к защите секретной информации (к классу защищенности 1в)
- •1.1.1.3. Требования к корректности реализации механизмов защиты информации
- •1.1.2. Эксплуатационная безопасность системного средства
- •1.1.2.1. Основы теории надежности систем защиты информации. Основные понятия и определения
- •1.1.2.2. Оценка эксплуатационной безопасности современных ос
- •1.2. Построение системы защиты информации на основе выполения требований к достаточности набора механизмов защиты и корректности их реализации
- •1.3. Общий подход к проектированию системы защиты на основе оценки рисков
- •1.3.1. Общий подход к оценке эффективности системы защиты
- •1.3.2. Способы задания исходных параметров для оценки защищенности
- •1.3.3. Особенности проектирования системы защиты на основе оценки рисков
- •1.3.4. Применение метода последовательного выбора уступок
- •1.3.5. Проектирование системы защиты с избыточным функционалом системы защиты
- •1.4. Выводы по разделу 1.
- •Раздел 2. Проектирование системы защиты персональных данных
- •2.1. Основополагающие документы по защите персональных данных
- •2.2. Классификация испДн
- •2.3. Методика определения актуальных угроз
- •2.3.1 Порядок определения исходной безопасности испДн
- •2.3.2 Порядок определения актуальных угроз безопасности пДн из исходного множества угроз
- •2.3.3. Пример построения модели угроз безопасности пДн и определения актуальных угроз
- •2.4. Выводы по разделу 2.
- •Раздел 3. Основополагающие методы обеспечения информационной безопасности
- •3.1. Общая классификация методов защиты
- •3.2. Идентификация и аутентификация
- •3.2.1. Идентификация и аутентификация субъектов доступа
- •3.2.1.1. Идентификация и аутентификации субъекта доступа «пользователь»
- •3.2.1.1.1. Идентификация и аутентификации пользователя при входе в систему
- •2.2.1.1.2. Идентификация и аутентификации пользователя при доступе к ресурсам
- •3.2.1.2. Идентификация и аутентификации субъекта доступа «процесс»
- •3.2.2. Идентификация и аутентификация объектов доступа
- •3.2.2.1. Идентификация и аутентификация устройств
- •3.2.2.2. Идентификация и аутентификация файловых объектов
- •3.2.2.3. Идентификация и аутентификация сообщений, передаваемых по сети
- •3.3. Разграничение доступа к ресурсам
- •3.3.1. Общие положения
- •3.3.2. Определение и классификация задач, решаемых механизмами управления доступом к ресурсам
- •При функционировании защищаемого объекта в составе лвс дополнительно:
- •3.3.3. Требования к корректности решения задачи управления доступом
- •3.3.3.1. Каноническая модель управления доступом. Условие корректности механизма управления доступом
- •3.3.3.2. Понятие и классификация каналов взаимодействия субъектов доступа. Модели управления доступом с взаимодействием субъектов доступа.
- •3.3.3.3. Классификация методов управления виртуальными каналами взаимодействия субъектов доступа
- •2. В общем случае различие моделей управления доступом базируется на отличиях способов реализации канала взаимодействия субъектов доступа и методах управления им
- •3.3.4. Классификация механизмов управления доступом. Дискреционный и мандатный механизмы управления доступом
- •3.3.5. Разметка иерархических объектов доступа
- •3.3.6. Разграничения доступа для субъекта «процесс»
- •3.3.7. Разграничение доступа к объекту «процесс». Механизм обеспечения замкнутости программной среды
- •3.3.7.1. Механизм обеспечения замкнутости программной среды заданием пользователям списков исполняемых файлов
- •3.3.7.2. Механизм обеспечения замкнутости программной среды заданием пользователям каталогов с исполняемыми файлами, разрешенных на запуск
- •3.3.7.3. Расширение функциональных возможностей механизма обеспечения замкнутости программной среды
- •3.3.8. Управление доступом к каталогам, не разделяемым системой и приложениями
- •3.3.9. Ролевая модель разграничения доступа к ресурсам
- •3.3.10. Разделительная политика доступа к ресурсам. Сессионный контроль доступа
- •3.4. Контроль целостности и аудит
- •3.4.1. Контроль целостности
- •3.4.2. Аудит
- •3.5. Защита сети
- •3.5.1. Задача и способ защиты информации, обрабатываемой в составе лвс. Системный подход к проектированию системы защиты компьютерной информации в составе лвс
- •3.5.2. Задача и способ защиты доступа в сеть
- •5.5.2.1. Трансляция сетевых адресов и портов
- •3.5.2.2. Межсетевое экранирование
- •3.6. Выводы по разделу 3
3.4.2. Аудит
Прежде всего, рассмотрим примеры требований нормативных документов к механизмам аудита (подсистема регистрации и учета) в автоматизированных системах, например, класса защищенности 1Г (защита конфиденциальной информации) [2]:
должна осуществляться регистрация входа (выхода) субъектов доступа в систему (из системы) либо регистрация загрузки и инициализации операционной системы и ее программного останова. Регистрация выхода из системы или останова не проводится в моменты аппаратурного отключения АС. В параметрах регистрации указываются:
- дата и время входа (выхода) субъекта доступа в систему (из системы) или загрузки (останова) системы;
- результат попытки входа: успешная или неуспешная (при НСД);
- идентификатор (код или фамилия) субъекта, предъявленный при попытке доступа;
- код или пароль, предъявленный при неуспешной попытке.
должна осуществляться регистрация выдачи печатных (графических) документов на “твердую” копию. В параметрах регистрации указываются:
- дата и время выдачи (обращения к подсистеме вывода);
- краткое содержание документа (наименование, вид, код, шифр) и уровень его конфиденциальности;
- спецификация устройства выдачи (логическое имя (номер) внешнего устройства);
- идентификатор субъекта доступа, запросившего документ.
должна осуществляться регистрация запуска (завершения) программ и процессов (заданий, задач), предназначенных для обработки защищаемых файлов, в параметрах регистрации указывается:
- дата и время запуска;
- имя (идентификатор) программы (процесса, задания);
- идентификатор субъекта доступа, запросившего программу (процесс, задание);
- результат запуска (успешный, неуспешный - несанкционированный);
должна осуществлять регистрация попыток доступа программных средств (программ, процессов, задач, заданий) к защищаемым файлам. В параметрах регистрации указывается:
- дата и время попытки доступа к защищаемому файлу с указанием ее результата: (успешная, неуспешная - несанкционированная);
- идентификатор субъекта доступа;
- спецификация защищаемого файла;
должна осуществлять регистрация попыток доступа программных средств к следующим дополнительным защищаемым объектам доступа: терминалам, ЭВМ, узлам сети ЭВМ, линиям (каналам) связи, внешним устройствам ЭВМ, программам, томам, каталогам, файлам, записям, полям записей. В параметрах регистрации указывается:
- дата и время попытки доступа к защищаемому файлу с указанием ее результата: (успешная, неуспешная - несанкционированная);
- идентификатор субъекта доступа;
- спецификация защищаемого объекта [логическое имя (номер)].
Как видим, в требованиях не сформулированы собственно задачи аудита, просто перечислено, какие события должны протоколироваться. Другой недостаток, отчасти, следующий из первого недостатка – это отсутствие полноты требований (по-сути, требований к корректности аудита) для решения различных конкретных задач защиты. Нет также требований и к тому, как строить подсистему аудита событий, как реализовывать фильтрацию журналов аудита. При этом необходимо понимать, что аудит событий – это очень ресурсоемкая процедура, реализация протоколирования излишних для решения необходимых задач защиты событий, может привести к существенному влиянию на вычислительный ресурс защищаемого компьютера. Поэтому, как и в случае реализации разграничительной политики доступа к ресурсам, да и построения системы в защите в целом, необходимо ориентироваться на нейтрализацию актуальных угроз, соответственно, протоколировать события, связанные именно с такими угрозами.
В общем случае, аудит событий можно классифицировать по типам. Можно выделить три основных типа аудита событий, применяемых на практике для решения совершенно различных задач протоколирования событий:
Инструментальный аудит, используется для настройки механизмов защиты (не в процессе функционирования защищаемого объекта). Применяется, когда необходимо настроить «тонкие» права доступа субъектов, например, приложений, либо системных процессов к защищаемым объектам, обеспечив при этом требуемый уровень безопасности и корректность функционирования системы и приложений. Основное требование к полноте и корректности реализации подсистемы инструментального аудита – возможность полного протоколирования доступа любого субъекта к любому защищаемому и системному объекту с последующей фильтрацией журнала аудита по субъекту, объекту, событию, с возможностью отключения аудита в процессе эксплуатации защищаемого объекта;
Функциональный полный аудит, используется для полного протоколирования всех событий, происходящих в процессе эксплуатации защищаемого объекта, применительно к решаемым задачам защиты. Журнал (журналы) аудита предоставляются системой защиты администратору по его запросу с целью последующего анализа событий и их последовательности для выявления злоумышленника и его действий. Фильтрация журнала (журналов) функционально полного аудита должна быть ориентирована на совокупный анализ некоего множества событий (возможно, журналов аудита) с возможности их взаимного увязывания по определенным параметрам (время, субъект, объект и т.д.). Основное требование к полноте и корректности реализации подсистемы функционального полного аудита – возможность полного протоколирования доступа субъектов объектам, применительно к решаемым задачам защиты (в части нейтрализации актуальных угроз), с предоставлением администратору журнала (журналов) аудита по его запросу;
Функциональный оперативный аудит, используется для протоколирования наиболее критичных в части решаемых задач защиты информации событий, происходящих в процессе эксплуатации защищаемого объекта. События аудита (здесь речь не о журналах, а именно о событиях, например, отельные строки журнала) предоставляются системой защиты администратору в реальном времени, например, выводятся на экран), инициатором выдачи адиминистратору запротоколированного события уже является система защиты. Какая-либо фильтрация здесь уже не требуется, а особый интерес представляет возможность формирования и автоматического запуска системой защиты (что очень важно в отсутствии администратора) реакции на зарегистрированное событие в реальном времени, например, завершение процесса, сеанса пользователя и т.д. Основное требование к полноте и корректности реализации подсистемы функционального оперативного аудита – возможность протоколирования наиболее критичных в части решаемых задач защиты информации событий, применительно к решаемым задачам защиты (в части нейтрализации актуальных угроз), с предоставлением администратору зарегистрированных событий в реальном масштабе времени;
В функционально развитой системе защиты должны присутствовать все типы аудита событий, т.к. они предназначены для решения совершенно различных задач.
Вывод. Аудит событий – это механизм защиты, который должен использоваться для протоколирования событий, связанных возможностью реализации актуальных угроз, противодействовать которым призвана система защиты. Аудит событий в общем случае включает в себя: инструментальный аудит, функциональный полный аудит, функциональный оперативный аудит. Данными типами аудита решаются совершенно различные задачи регистрации событий, они принципиально различаются требованиями к полноте и корректности реализации. Поэтому на практике в функционально развитой системе защиты должны присутствовать все эти типы аудита событий.