Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
БИТиС / Лекции_Мошак_Птицына_ Пособие_БИТиС.docx
Скачиваний:
83
Добавлен:
05.09.2023
Размер:
4.32 Mб
Скачать

3.2.7. Подсистема мониторинга информационной безопасности «закрытого» контура

Подсистема мониторинга информационной безопасности «закрытого» контура предназначена для оперативного контроля ее стояния с целью выявления нарушений требований политики ИБ «закрытого» контура и нормативных документов, выявления нештатных (или злоумышленных) действий и локализации инцидентов безопасности. Регистрация и анализ данных аудита должна производится централизованно на серверах (машинах) безопасности (далее – МБ) в режиме реального времени в соответствии с заданной политикой безопасности.

Подсистема аудита ИБ «закрытого» контура должна обеспечивать:

– контроль выполнения требований политики ИБ «закрытого» контура и нормативных документов по ИБ;

– независимый мониторинг действий пользователей «закрытого» контура;

– сбор первичных событий штатных журналов аудита объектов мониторинга, в том числе СЗИ;

– регистрацию первичных событий аудита;

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

– обеспечение возможности создания и редактирования, а также проверки описаний событий ИБ;

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

– формирование сообщений о событиях ИБ и извещения персонала службы ИБ о зафиксированных событиях ИБ;

– расследование событий ИБ и регистрацию инцидентов ИБ.

3.3. Подсистема защиты информации «открытого» контура

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

– защиты информации от НСД;

– защиты межсетевого взаимодействия «открытого» контура;

– администрирования.

Основные требования к подсистемам «открытого» контура приведены в [17].

3.3.1. Подсистема защиты информации от нсд «открытого» контура

Подсистема защиты информации от НСД «открытого» контура предназначена для предназначена для организации сегментации и защиты информации, передаваемой между «открытого» контура и «открытыми» контурами взаимодействующих ИС по открытым каналам, включая Интернет.

Подсистема защиты информации от НСД «открытого» контура должна обеспечивать:

– разграничение доступа к маршрутизаторам и к серверам «открытого» контура на уровне сетевых служб и процессов, обеспечивающих доступ к сетевым ресурсам по следующим параметрам:

а) пользователям;

б) процессам;

в) времени доступа;

г) по службам доступа (портам);

д) политике безопасности (запрещенные/разрешенные сервера и службы);

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

а) согласование используемых протоколов аутентификации и отсутствие жесткой привязки к конкретным протоколам аутентификации;

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

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

г) выполнение не только начальной аутентификации до допуска к ресурсам ЛВС с "открытым" контуром, но и динамической аутентификации взаимодействующих сторон при работе удаленного соединения;

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

– усиленную аутентификацию входящих и исходящих запросов методами, устойчивыми к пассивному и/или активному прослушиванию сети;

– разграничение доступа к маршрутизаторам и к серверам «открытого» контура на уровне сетевых служб и процессов, обеспечивающих доступ к сетевым ресурсам по следующим параметрам:

а) пользователям;

б) процессам;

г) времени доступа;

д) по службам доступа (портам);

е) политике безопасности (запрещенные/разрешенные сервера и службы);

– однозначную идентификацию пользователей в ИС и в операционной системе ОС АРМ (использование общих идентификаторов (ни в СЗИ, ни в ОС) не допускается;

– идентификацию по логическим именам информационных ресурсов (логических устройств, каталогов, файлов);

– исключение возможности удаленного подключения к локальным ресурсам «открытого» контура и управление доступом к этим ресурсам за счет настроек ОС;

– дискреционное (одноуровневое) разграничение доступа с помощью ТРД. Для реализации дискреционного разграничения полномочий доступа отдельных категорий пользователей одного уровня в «открытом» контуре должна применяться матричная модель контроля доступа субъектов к защищаемым объектам:

а) ТРД должна храниться в отдельном файле отдельного каталога. Полное имя и путь данного файла должны задаваться в консоли АИБ «открытого» контура;

б) ТРД должна содержать перечисление санкционированных (разрешенных) операций для каждой пары «субъект–объект» системы защиты «открытого» контура. Должно быть задано явное и недвусмысленное перечисление допустимых типов доступа: читать, писать, удалять, запускать, переименовывать, т. е. тех типов доступа, которые являются санкционированными для данного субъекта к данному ресурсу (объекту);

– управление дискреционным доступом субъектов в «открытом» контуре к объектам контура через доверенного диспетчера доступа. При этом доверенный диспетчер должен выполнять следующие задачи:

а) установление прав на разграничение доступа субъектов к объектам;

б) аудит успешных/или неудачных попыток идентификации, аутентификации и авторизации пользователей в "разомкнутом" цикле;

в) включение/выключение аудита событий выхода или прерывания сеанса пользователей в "открытом" контуре и "открытом" контуре;

г) аудит успешных и/или неудачных попыток доступа отдельных объектов в "разомкнутом" цикле (пользователей домена, групп или всех) к отдельным объектам на дискреционной основе;

д) аудит успешных и/или неудачных попыток доступа к объектам в "разомкнутом" цикле;

е) аудит запрошенных прав доступа к объекту в "разомкнутом" цикле;

и) постановку на аудит успешные и/или неудачные попытки пользователей использовать привилегии в процессе эксплуатации объектов "открытого" контура;

к) включение/отключение аудита событий блокировки/разблокировки работы прикладного программного обеспечения в "разомкнутом" контуре;

л) включение/отключение аудита изменений прав пользователей домена или групп в прикладном программном обеспечении;

м) указание полного имени и пути файла, содержащего ТРД субъектов «открытого» контура к объектам, управляемым прикладным программным обеспечением;

н) выполнение операции блокировки/разблокировки работы прикладного программного обеспечения;

– администрирование доступом субъектов «открытого» контура к объектам должно быть реализовано с помощью отдельной оснастки, консоли либо утилиты администрирования АИБ «открытого» контура, представляющая собой отдельный файл, в которой должна быть реализована возможность:

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

б) назначения отдельным пользователям или группам пользователей встроенных ролей прикладного ПО;

– регламентацию доступа пользователей к физическим устройствам АРМ (дискам, портам ввода-вывода);

– создание замкнутой программной среды разрешенных для запуска программ, расположенных как на локальных, так и на сетевых дисках АРМ «открытого» контура. Управление замкнутой программной средой в «открытом» контуре должно осуществляться централизованно;

– контроль целостности модулей системы защиты «открытого» контура, системных областей диска и произвольных списков файлов в автоматическом режиме и по командам АИБ «открытого» контура:

а) контроль целостности должен выполняться по контрольным суммам, как в процессе загрузки, так и динамически;

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

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

– оперативное восстановление средств защиты от НСД после сбоев и отказов оборудования в штатном режиме работы;

– оповещение АИБ «открытого» контура обо всех событиях НСД, происходящих в «открытом» контуре.

Доверенный диспетчер должен регистрировать в журнале безопасности ОС следующие события, которые должны быть доступны для аудита:

– успешные и/или неудачные попытки идентификации, аутентификации и авторизации пользователей в прикладном ПО;

– выход или прерывание сеанса работы пользователя в прикладном ПО;

– успешные и/или неудачные попытки доступа к объектам, управляемым прикладным ПО, со стороны пользователей по дискреционному принципу;

– успешные и/или неудачные попытки верификации пользователей при выполнении тех или иных действий в системе;

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

– события блокировки/разблокировки работы прикладного ПО;

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

– успешные и/или неудачные попытки доступа к объектам со стороны пользователей по мандатному признаку;

– запрашиваемые права доступа к объекту.

При записи событий в журнале должны фиксироваться:

– код (ID) события;

– тип события (успех, неудача);

– категория события («начало сеанса работы», «прекращение сеанса работы», «доступ к объектам», «применение полномочий», «изменение полномочий», «блокировка работы прикладного ПО», «разблокировка работы прикладного ПО», «критическая ошибка», «неустранимая ошибка»);

– дата и время события;

– источник события;

– пользователь, инициировавший данное событие;

– компьютер, на котором инициировано данное событие;

описание события.