Файл: Федеральное государственное бюджетное образовательное учреждение высшего образования санктпетербургский.pdf
ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 05.12.2023
Просмотров: 556
Скачиваний: 2
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
виртуальные сети сеансового уровня могут использоваться с другими типами протоколов
VPN, поскольку эти технологии не являются взаимоисключающими.
4.2.5.4. Распределение криптографических ключей и согласование параметров защищенных туннелей
При создании безопасных виртуальных сетей одной из наиболее важных функций является распределение криптографических ключей и согласование параметров безопасного туннеля. Эти функции выполняются при формировании каждого криптографически защищенного туннеля.
На уровне сети и сеанса модели OSI в большинстве случаев используются асимметричные криптосистемы, на основе протоколов распределения временных (сеансовых) ключей (SKIP, ISAKMP, SSL
Handshake Protocol). При использовании этих криптосистем временные ключи распределяются с использованием главных открытых ключей.
Распределение временных ключей на сетевом уровне чаще всего осуществляется алгоритмом Диффи-Хеллмана [32]. На уровне сеанса временные ключи обычно распределяются с использованием асимметричных систем, таких как RSA и El Gamal.
В протоколах формирования защищенных туннелей на канальном уровне модели OSI (PPTP, L2F, L2TP) временные ключи чаще всего генерируются на основе паролей пользователей [33]. Генерация осуществляется каждой стороной информационного взаимодействия после взаимной аутентификации. Согласование двух временных ключей, генерируемых противоположными сторонами для одного защищаемого туннеля, обеспечивается их расчётом на основе одних и тех же параметров, включающих в себя согласованное случайное число или временную метку, а также хэш-функцию от пароля. Учитывая, что пароли являются аналогами основных ключей симметричного шифрования, более эффективным способом распределения временных ключей на канальном уровне является централизованное их распределение, например, на основе протокола
Kerberos.
В зависимости от простоты реализации и достигаемой степени безопасности возможны следующие способы построения защищенного канала между двумя узлами компьютерной сети:
– для каждого соединения, устанавливаемого от имени какого-либо программного приложения;
– между сетевыми узлами и создание в рамках этого канала отдельных защищенных соединений, устанавливаемых от имени программных приложений;
Формирование защищенного виртуального канала для каждого соединения предполагает реализацию следующих этапов:
– выдача запроса одной из сторон и достижение соглашения на создание защищенного туннеля;
– аутентификация сторон, которая выполняется с помощью ранее
VPN, поскольку эти технологии не являются взаимоисключающими.
4.2.5.4. Распределение криптографических ключей и согласование параметров защищенных туннелей
При создании безопасных виртуальных сетей одной из наиболее важных функций является распределение криптографических ключей и согласование параметров безопасного туннеля. Эти функции выполняются при формировании каждого криптографически защищенного туннеля.
На уровне сети и сеанса модели OSI в большинстве случаев используются асимметричные криптосистемы, на основе протоколов распределения временных (сеансовых) ключей (SKIP, ISAKMP, SSL
Handshake Protocol). При использовании этих криптосистем временные ключи распределяются с использованием главных открытых ключей.
Распределение временных ключей на сетевом уровне чаще всего осуществляется алгоритмом Диффи-Хеллмана [32]. На уровне сеанса временные ключи обычно распределяются с использованием асимметричных систем, таких как RSA и El Gamal.
В протоколах формирования защищенных туннелей на канальном уровне модели OSI (PPTP, L2F, L2TP) временные ключи чаще всего генерируются на основе паролей пользователей [33]. Генерация осуществляется каждой стороной информационного взаимодействия после взаимной аутентификации. Согласование двух временных ключей, генерируемых противоположными сторонами для одного защищаемого туннеля, обеспечивается их расчётом на основе одних и тех же параметров, включающих в себя согласованное случайное число или временную метку, а также хэш-функцию от пароля. Учитывая, что пароли являются аналогами основных ключей симметричного шифрования, более эффективным способом распределения временных ключей на канальном уровне является централизованное их распределение, например, на основе протокола
Kerberos.
В зависимости от простоты реализации и достигаемой степени безопасности возможны следующие способы построения защищенного канала между двумя узлами компьютерной сети:
– для каждого соединения, устанавливаемого от имени какого-либо программного приложения;
– между сетевыми узлами и создание в рамках этого канала отдельных защищенных соединений, устанавливаемых от имени программных приложений;
Формирование защищенного виртуального канала для каждого соединения предполагает реализацию следующих этапов:
– выдача запроса одной из сторон и достижение соглашения на создание защищенного туннеля;
– аутентификация сторон, которая выполняется с помощью ранее
распределенных основных ключей шифрования или назначенных паролей;
– распределение временных ключей и согласование параметров защищенного туннеля.
Вторая и третья фазы чаще всего пересекаются друг с другом, и аутентификация выполняется совместно с распределением временных ключей. Исключением является только случай проверки подлинности сторон осуществляемой на основе парольных методов.
В случае формирования между двумя сетевыми узлами общего защищенного канала, в контексте которого создаются отдельные защищенные соединения, перечисленные этапы выполняются также и при создании каждого защищенного соединения, устанавливаемого от имени программных приложений взаимодействующих сторон. Формирование между двумя сетевыми узлами общего защищенного канала и создание на его базе отдельных защищенных соединений характеризуется более высокой сложностью реализации. Однако в этом случае снижается уязвимость закрытых основных ключей, служащих для распределения главного сеансового ключа, и может быть обеспечено более эффективное расходование компьютерных ресурсов, затрачиваемых на генерацию временных ключей. Снижение ресурсных издержек на генерацию временных ключей достигается за счет переноса основной части вычислений на стадию распределения и генерации главного сеансового ключа.
4.2.3. Организационно-технические решения для организации защиты
межсетевого взаимодействия с применением межсетевых экранов
Для межсетевой защиты в корпоративной сети и ее экранирования от атак извне, для обнаружения и регистрации внешних атак необходимо применение межсетевых экранов [13]. С помощью журналов аудита межсетевых экранов необходимо отслеживать:
– попытки соединения с ЛВС «открытого» контура с неразрешенных IP- адресов;
– попытки использования неразрешенных протоколов уровня TCP/UDP и соединения с неразрешенными портами серверов ЛВС «открытого» контура извне;
– попытки компрометации защищенных IP-соединений к ресурсам корпоративной сети;
– попытки использования незащищенных IP-соединений при межсетевом взаимодействии в региональной корпоративной сети.
Для оперативного анализа информации аудита необходимо настроить журнал syslogd межсетевых экранов таким образом, чтобы события аудита дублировались на сервер аудита службы безопасности, т. е. для всех межсетевых экранов хост loghost в файле /etc/hosts должен ссылаться на сервер аудита службы безопасности.
Для обеспечения надежности функционирования механизмов фильтрации трафика необходимо резервировать межсетевые экраны.
– распределение временных ключей и согласование параметров защищенного туннеля.
Вторая и третья фазы чаще всего пересекаются друг с другом, и аутентификация выполняется совместно с распределением временных ключей. Исключением является только случай проверки подлинности сторон осуществляемой на основе парольных методов.
В случае формирования между двумя сетевыми узлами общего защищенного канала, в контексте которого создаются отдельные защищенные соединения, перечисленные этапы выполняются также и при создании каждого защищенного соединения, устанавливаемого от имени программных приложений взаимодействующих сторон. Формирование между двумя сетевыми узлами общего защищенного канала и создание на его базе отдельных защищенных соединений характеризуется более высокой сложностью реализации. Однако в этом случае снижается уязвимость закрытых основных ключей, служащих для распределения главного сеансового ключа, и может быть обеспечено более эффективное расходование компьютерных ресурсов, затрачиваемых на генерацию временных ключей. Снижение ресурсных издержек на генерацию временных ключей достигается за счет переноса основной части вычислений на стадию распределения и генерации главного сеансового ключа.
4.2.3. Организационно-технические решения для организации защиты
межсетевого взаимодействия с применением межсетевых экранов
Для межсетевой защиты в корпоративной сети и ее экранирования от атак извне, для обнаружения и регистрации внешних атак необходимо применение межсетевых экранов [13]. С помощью журналов аудита межсетевых экранов необходимо отслеживать:
– попытки соединения с ЛВС «открытого» контура с неразрешенных IP- адресов;
– попытки использования неразрешенных протоколов уровня TCP/UDP и соединения с неразрешенными портами серверов ЛВС «открытого» контура извне;
– попытки компрометации защищенных IP-соединений к ресурсам корпоративной сети;
– попытки использования незащищенных IP-соединений при межсетевом взаимодействии в региональной корпоративной сети.
Для оперативного анализа информации аудита необходимо настроить журнал syslogd межсетевых экранов таким образом, чтобы события аудита дублировались на сервер аудита службы безопасности, т. е. для всех межсетевых экранов хост loghost в файле /etc/hosts должен ссылаться на сервер аудита службы безопасности.
Для обеспечения надежности функционирования механизмов фильтрации трафика необходимо резервировать межсетевые экраны.
Известно [16], что любые механизмы защиты вносят временную, протокольную и потоковую избыточность в информационное окружение сети и приводят к ухудшению ее характеристик. Эти виды избыточности при проектировании защищенной корпоративной МСС должны быть учтены в ее критериях эффективности и ограничениях задач анализа [16]. Прикладные аспекты указанной проблемы связаны с повышением качества проектирования защищенных МСС, что в конечном итоге приводит к повышению эффективности использования сетевых ресурсов и сокращению затрат на их создание. В Приложении 1 приведена формализация процессов предоставления механизмов защиты в корпоративной мультисервисной сети.
4.3. Организационно-технические решения по настройке журналов
аудита на объектах мониторинга ИС
Система мониторинга ИБ ИС для выявления инцидентов ИБ постоянно осуществляет сбор и анализ событий журналов штатного аудита подконтрольных объектов ИС, в том числе СЗИ. При регистрации событий должны быть выполнены следующие требования:
1. Полнота регистрируемых событий должна быть достаточна и не избыточна для доказательного разбора ситуации;
2. Должна быть обеспечена максимально возможная независимость данных аудита от администратора контролируемой системы;
3. Должна быть обеспечена невозможность несанкционированного искажения журналов аудита, в том числе и администраторами контролируемой системы;
4. Хранение журналов аудита должно быть обеспечено в течение сроков, определенных руководящими документами ИБ организации.
Независимо от типа операционной системы в журналах штатного аудита должны регистрироваться следующие события:
1. Идентификационная информация, в том числе и попытки подбора пароля пользователями;
2. Операции, отвергнутые ИС из-за недостатка полномочий у пользователей;
3. Факты модификации конфигурационных файлов ИС;
4. Факты изменения администраторами полномочий пользователей
«закрытого» и «открытого» контура ИС;
5. Факты отключения системы аудита администраторами;
6. Факты запуска и останова ИС.
4.3.1. Организационно-технические решения по настройке и сбору
данных журнала аудита ОС HP-UX
Получение данных журнала аудита ОС HP-UX может осуществляться двумя способами:
1) на сервер, с консоли «root» инсталлируется агент, который в режиме
«on-line» передаёт свой аудит. На серверной части обработки аудита, на основе двоичных событий аудита в формате ОС HP–UX формируются события для записи в базу данных сервера аудита службы безопасности.
Достоинство данного режима заключается в следующем:
– агент осуществляет полностью автоматический режим управления подсистемой аудита (устанавливает для подсистемы аудита вспомогательный файл аудита, размер вспомогательного файла аудита, осуществляет сбор информации из файлов wtmp, btmp, sulog для генерации более качественных записей в БД, осуществляет контроль за размером файлов wtmp, btmp, sulog);
– ручная работа администраторов (пользователей «root» и «auditor») минимальна, и сводится только к инсталляции агента и добавлению событий, подлежащих аудиту;
2) вторая схема предполагает накопление аудита на подконтрольных объектах и дальнейшее использование службы удаленного доступа к их файловым системам (например, по протоколу FTP) для переноса данных аудита на сервер аудита службы безопасности. После разбора, преобразования, аудит записывается в базу данных сервера аудита службы безопасности. Недостатки такого подхода заключаются в следующем:
– наличие ручной работы администраторов по управлению подсистемой аудита (установка вспомогательного файла аудита, размера файла);
– политика безопасности на серверах под управлением ОС HP-UX разрешает читать и записывать файлы аудита только пользователю «root», это обеспечивается установкой прав доступа на файлы аудита (0600).
Следовательно, для чтения данных аудита необходимо использовать учетную запись «root»;
– администратор должен как минимум раз в сутки переписывать заполненные файлы аудита с подконтрольных серверов на сервер аудита службы безопасности. Очевидно, что при большом потоке данных аудита съем аудита должен осуществляться чаще. Соотношение размера файлов аудита и периодичности их съема должны быть установлены в ходе опытной эксплуатации.
4.3.2. Организационно-технические решения по настройке и сбору
данных журнала аудита СУБД Oracle
Требования к настройкам журнала штатной подсистемы регистрации событий.
Штатная процедура регистрации событий (ШПРС) СУБД Oracle опциональна. Опции аудита устанавливаются при помощи SQL-команды
AUDIT. При эксплуатации с включенным аудитом требуется определенный расход вычислительных ресурсов СУБД, необходимый для генерации записей аудита. В случае неграмотной настройки аудита (например, включения аудита на применение всех привилегий ко всем объектам) может привести к полной неработоспособности СУБД из-за недостатка вычислительных ресурсов. Кроме того, при переполнении таблицы аудита,
SQL-операции с БД, которые вызывают появление новых записей в таблице аудита, перестают выполняться. Поэтому необходимо точное определение перечня необходимых событий аудита и перечня объектов БД, для которых необходимо включить аудит.
В подсистеме аудита СУБД Oracle можно настроить аудит по следующим критериям:
– можно выполнять аудит конкретных SQL-операторов безотносительно к конкретным объектам. Например, можно генерировать запись аудита каждый раз, когда какой-либо пользователь выполняет оператор DROP
TABLE, и не учитывать, к какой таблице относится этот оператор;
– можно выполнять аудит использования мощных системных привилегий. Например, генерировать запись аудита каждый раз, когда какой- либо пользователь применяет системную привилегию SELECT ANY TABLE для запроса к таблице БД;
– можно выполнять аудит определенных SQL-операторов для конкретных объектов БД. Например, генерировать запись аудита каждый раз, когда какой-либо пользователь удаляет запись из таблицы MODES;
– можно выполнять формирование одной аудиторской записи на применение каждого тип SQL-оператора в течение сеанса работы пользователя.
Наименее ресурсоемким и минимально необходимым является аудит привилегии CREATE SESSION, включение которого позволяет фиксировать факты регистрации и завершения работы пользователей. При наличии указанных фактов подсистема анализа способна выявить нетипичную активность пользователей:
– регистрация пользователя в СУБД в нерабочее время;
– регистрация с нетипичного для данного пользователя компьютера
(терминала);
– регистрация пользователя в СУБД с именем, несоответствующим его имени в ОС.
С целью улучшения качества контроля, аудит для контролируемых объектов БД необходимо установить для всех пользователей СУБД. Для минимизации ресурсов, потребляемых аудитом, необходимо воспользоваться возможностью формирования одной аудиторской записи на каждый тип
SQL-выражения.
СУБД Oracle генерирует записи аудита только после того, как аудит разрешен и для него установлены соответствующие опции. Например, можно установить опции аудита для конкретных субъектов. В Oracle разрешается сохранять генерируемые записи аудита либо в журнале аудита базы данных
(фактически таблица записей аудита входит в состав контролируемой БД), либо в таком же журнале операционной системы, в которой работает СУБД
Oracle Server. При использовании журнала аудита базы данных можно легко просматривать и находить записи аудита с помощью SQL-запросов и предварительно созданных для этого журнала представлений словаря данных.
4.3.3. Организационно-технические решения по настройке и сбору
данных журнала аудита ОС Windows
Подсистема аудита ОС Windows обеспечивает регистрацию событий, связанных с работой ОС, и функционирование механизмов сохранения данных о событиях в журналы событий. В ОС Windows по умолчанию создаются следующие журналы событий:
– система (system);
– приложение (application);
– безопасность (security);
– установка (setup);
– перенаправленные события (forwarded events).
Системный журнал содержит события, записываемые системными компонентами ОС. Например, в журнале системы регистрируются сбои при загрузке драйвера или других системных компонентов в процессе загрузки системы. Типы событий, которые регистрируются компонентами системы, определены на уровне операционной системы.
В журнале приложений фиксируются события, относящиеся к работе приложений и программ. События, регистрируемые в журнале приложений, определяются разработчиками соответствующих приложений.
Журнал безопасности содержит события, связанные с безопасностью.
Например, успешные и неуспешные попытки входа в систему, события, относящиеся к использованию ресурсов, такие как создание, открытие и удаление файлов и других объектов.
В журнале установки фиксируются события, связанные с установкой и обновлением системы, ее ролей, компонентов и приложений.
Журнал перенаправленных событий используется для хранения событий, собранных с удаленных компьютеров.
Состав событий, регистрируемых подсистемой аудита ОС Windows, определяется политикой аудита и настройками аудита конкретных объектов доступа (файлов, каталогов, ключей реестра, объектов каталога Active
Directory и т. д.). Параметры политики аудита ОС Windows подконтрольных объектов необходимо настроить следующим образом:
– аудит входа в систему (audit logon events) – успех (success), отказ
(failure);
– аудит изменения политики (audit policy change) – успех;
– аудит управления учетными записями (audit account management) – успех, отказ;
– аудит доступа к объектам (audit object access) – успех, отказ; аудит доступа к службе каталогов (audit directory service access) – успех, отказ;
– аудит системных событий (audit system events) – успех;
– аудит отслеживания процессов (audit process tracking) – успех.
Для контроля функций управления локальными политиками подконтрольных объектов дополнительно необходимо настроить аудит
доступа к соответствующим разделам реестра ОС, перечень которых приведен в табл. 4.4.
Таблица 4.4
Подконтрольные разделы реестра
Таблица 4.4
Подконтрольные разделы реестра
1 2 3 4 5 6 7 8 9 ... 16