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

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

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

События могут регистрироваться различными модулями. Например, идентификатор модуля «$AUDIT» обозначает, что событие зарегистрировано основным модулем аудита. Для записей о событиях, генерируемых этим модулем характерна, структура подробного описания события, состоящая из следующих полей:

• 
  идентификатор типа события;
  
• 
  идентификатор пользователя (UID), в сеансе которого произошло событие;
  
• 
  идентификатор группы пользователя (GID), в сеансе которого произошло событие;
  
• 
  информация об операции (функции) и ее параметрах.
  

В ОС семейства Microsoft Windows NT для доступа к данным аудита необходимо использовать специальные функции, которые обеспечивают считывание данных аудита в буферы в оперативной памяти, формат которых хорошо документирован. Запись о событии аудита в ОС семейства

Microsoft Windows NT содержит следующую информацию:

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

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

---

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

• 
  N – порядковый номер события. Тип значения – целое число.
  
• 
  RegistrationTime – время регистрации события. Тип значения – дата.
  
• 
  StartTime – время начала обработки. Тип значения – дата.
  
• 
  EventID – идентификатор разновидности события. Тип значения – целое число.
  
• 
  EventType – идентификатор типа события. Тип значения – целое число.
  
• 
  EventCategory – идентификатор категории (группы разновидностей событий), к которой относится событие. Тип значения – целое число.
  
• 
  EventClasss – класс события – промежуточный результат обработки события в системе, класс события определяется системой на основе анализа данной структуры, описывающей событие. Тип значения - целое число.
  
• 
  SourceName – имя источника события
  
• 
  или модуля, зарегистрировавшего событие. Тип значения – строка символов.
  
• 
  UserName – имя пользователя в сеансе которого зарегистрировано событие. Тип значения – строка символов.
  
• 
  Domain – имя домена пользователя. Тип значения – строка символов.
  
• 
  Host – идентификатор (имя или сетевой адрес) компьютера, на котором зарегистрировано событие. Тип значения – строка символов.
  
• 
  EventParameters – дополнительные параметры события, зависящие от разновидности события. Тип значения - строка символов.
  

Рисунок 1 - Алгоритм преобразования данных в новый вид

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

Проанализируем данные, которые мы извлекли из журнала аудита. Разделим все события на классы в зависимости от важности. То есть на основании полей записи будем относить события к какому-нибудь классу.

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

---

Выделим следующие классы:

1. Архивные – это все события безопасности, регистрируемые на компьютерах сети.

2. Отказы – это события, связанные с отказами в предоставлении доступа, а также со сбоями в работе средств обеспечения безопасности.

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

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

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

Разрабатываемые организационно-распорядительные документы по защите информации должны определять правила и процедуры:

управления (администрирования) системой защиты информации информационной системы;

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

---

При внедрении организационных мер защиты информации осуществляются:

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

Анализ уязвимостей информационной системы проводится в целях оценки возможности преодоления нарушителем системы защиты информации информационной системы и предотвращения реализации угроз безопасности информации.

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

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

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

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

Требования к реализации ОЦЛ.1: В информационной системе должен осуществляться контроль целостности программного обеспечения, включая программное обеспечение средств защиты информации.

---

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

• 
  контроль целостности программного обеспечения средств защиты информации, включая их обновления, по наличию имен (идентификаторов) и (или) по контрольным суммам компонентов средств защиты информации в процессе загрузки и (или) динамически в процессе работы информационной системы;
  
• 
  контроль целостности компонентов программного обеспечения (за исключением средств защиты информации), определяемого оператором исходя из возможности реализации угроз безопасности информации, по наличию имен (идентификаторов) компонентов программного обеспечения и (или) по контрольным суммам в процессе загрузки и (или) динамически в процессе работы информационной системы;
  
• 
  контроль применения средств разработки и отладки программ в составе программного обеспечения информационной системы;
  
• 
  тестирование с периодичностью, установленной оператором, функций безопасности средств защиты информации, в том числе с помощью тест-программ, имитирующих попытки несанкционированного доступа, и (или) специальных программных средств, в соответствии с АНЗ.1 и АНЗ.2(ФСТЭК).
  

---

Смотрите также файлы

• Отчет по производственной практики (практика по получению профессиональных умений и опыта профессиональной деятельности).docx

• Протоколов 16 Организация и настройка ip телефонии 17.docx

• Создание условий для развития математических знаний у детей 34 лет. Закрепление у детей представлений о геометрических фигурах.docx

• Промежуточная аттестация по разделу 3Тест начат суббота, 3 Июнь 2023, 05 52Состояние.pdf

• Реферат по дисциплине Философия студент гр. 101Сз22 Деяк Ю. Проверил.docx