Файл: Конспект лекций профессиональная образовательная программа.docx

ВУЗ: Не указан

Категория: Не указан

Дисциплина: Не указана

Добавлен: 09.11.2023

Просмотров: 395

Скачиваний: 3

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

г) фильтрация на транспортном уровне:

  • должна обеспечиваться возможность фильтрации запросов на установление виртуальных соединений. При этом должны учитываться транспортные адреса отправителя и получателя. Фильтрация должна производиться по IP-адресам для TCP и UDP соединений;

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

  • должна обеспечиваться регистрация и учет запросов на установление виртуальных соединений.

д) фильтрация на прикладном уровне:

  • должна обеспечиваться возможность фильтрации на прикладном уровне запросов к прикладным сервисам. При этом должны учитываться прикладные адреса отправителя и получателя; Фильтрация производится по сокетам (sockets) для TCP и UDP соединений;

  • должна обеспечиваться возможность сокрытия субъектов (объектов) и/или прикладных функций «закрытого» контура.

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

  • должна обеспечиваться регистрация и учет запрашиваемых сервисов прикладного уровня (посредством связки IP-адреса и номера порта удаленного сервера для устанавливаемого сеанса связи).

  1. Авторизацию МАС-адресов АРМ пользователей «закрытого» контура при их подключении к ЛВС контура. При обнаружении неавторизованного МАС-адреса порт соответствующего устройства должен автоматически отключаться.

  2. Использование режима работы концентраторов, обеспечивающего прием пакетов, адресованных только авторизованному МАС-адресу.

  3. Исключение возможности несанкционированного удаленного подключения к локальным ресурсам «закрытого» контура и управление доступом к этим ресурсам.

  4. Обязательный контроль точек открытого доступа в периметр «закрытого» контура. При организации однонаправленных соединений из «открытого» контура в «закрытый» контур с целью обеспечения доступа к секретной информации, обрабатываемой на серверах «закрытого» контура, предварительно должен быть решен вопрос о криптографической защите трафика этих соединений (организация VPN) с помощью сертифицированных средств ФСБ России. При этом для разрешенных исходящих из «открытого» контура TCP-соединений должны конкретно задаваться адрес назначения, исходный адрес и номер IP порта, соответствующий внешнему по отношению к контуру «О» сервису. При управлении доступом к серверам «закрытого» контура МЭ – в access-листах должны конкретно задаваться адрес назначения, исходный адрес и номер IP порта, соответствующий сервису «закрытого» контура.

  5. Регистрацию входящих пакетов в «закрытый» контур, не соответствующих правилам access-листов маршрутизатора и внутреннего МЭ за счет вывода в syslog соответствующих событий.

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

  7. Программируемую реакцию на события в средстве защиты (возможность формирования заданного уровня детализации событий в журнале регистрации АИБ. Регистрация категорий событий, таких как установка связи, изменение конфигурации и т.д.).

  8. Оперативную сигнализацию на основе защищенного протокола SNMPv.3:


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

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

  1. Организацию событийного протоколирования и подотчетности пользователей и администраторов «закрытого» контура.


2.2.2.6. Подсистема администрирования

Подсистема администрирования «закрытого» контура предназначена для настройки прав доступа (далее - ПРД) субъектам «закрытого» контура к объектам управления.

В «закрытом» контуре должна быть реализована централизованная подсистема администрирования СЗИ «закрытого» контура.

Администрирование СЗИ «закрытого» контура должно производиться АИБ «закрытого» контура с локальной консоли либо удаленно с использованием шифрования управляющего трафика на уровне IP или с помощью использования управляющих протоколов, поддерживающих шифрование данных (SNMPv3). При удаленных запросах на доступ к средству защиты идентификация и аутентификация должны обеспечиваться методами, устойчивыми к пассивному и активному перехвату информации. Для этих целей должны применяться криптографические механизмы аутентификации с использованием электронной подписи.

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

Подсистема администрирования должна обеспечивать:

  • установку ключевых элементов и механизмов доступа в средства СЗИ «закрытого» контура с целью обеспечения им возможности доступа к объектам управления. При этом установка и переустановка ключевых элементов и механизмов доступа должна осуществляться как по команде администратора центра генерации и распределения ключей (ЦГРК), так и по инициативе администратора «закрытого» контура.

  • взаимодействие с ЦГРК с целью обеспечения доставки ключевых элементов и механизмов доступа;

  • установку ПРД и их изменение;

  • идентификацию и аутентификацию АИБ «закрытого» контура при его запросах на доступ;

  • возможность делегирования прав (т. е. присвоения пользователю ограниченных административных привилегий управления некоторым набором учетных записей);

  • использование универсальных шаблонов настроек политики безопасности «закрытого» контура;

  • возможность моделирования существующей организационной иерархии и административной структуры «закрытого» контура – пользователя «закрытого» контура;

  • возможность блокировки учетной записи пользователя «закрытого» контура или её ограничения по времени работы;

  • возможность доставки информации о нештатных ситуациях и ошибках, возникающих в процессе функционирования механизмов доступа, до АИБ «закрытого» контура.



2.2.2.7. Подсистема обнаружения и противодействия вторжений.

Подсистема обнаружения и противодействия вторжений должна обеспечивать:

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

  • контроль за вычислительной средой объектов «закрытого» контура, в которой выполняются прикладные задачи;

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

  • контроль правильности работы операторов и администраторов «закрытого» контура.


2.2.2.8. Подсистема аудита информационной безопасности.

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

Регистрация и анализ данных аудита должна производится централизованно на серверах (машинах) безопасности (далее - МБ) в режиме реального времени в соответствии с заданной политикой безопасности;

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

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

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

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

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

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

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

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

  • расследование событий ИБ.


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

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

Система внешнего (независимого) мониторинга представляет собой специально разработанные программные средства, основу которых составляют программные агенты (сенсоры), функционирующие на уровне драйверов соответствующих операционных систем. Необходимо отметить, что независимый мониторинг часто является единственным инструментом контроля привилегированных пользователей, а именно, в тех случаях, когда невозможно ограничить выполнение ими несанкционированных/деструктивных действий не лишив их при этом необходимой функциональности. Кроме того, для некоторых систем (например, ОС Novell NetWare) дополнительно все права по управлению штатным аудитом могут быть переданы независимому администратору.

Учитывая значительный объем данных аудита, поступающих от различных контролируемых подсистем ИС, а также многообразие требований политики безопасности, которые должны быть отслежены через эти данные, становится очевидной необходимость автоматизации процесса их анализа. В настоящее время на мировом рынке уже появились системы указанного класса, производящие в режиме реального времени анализ, как данных штатного аудита различных систем, так и данных доверенного мониторинга на предмет соответствия определенному набору шаблонов, выражающих требования заданной политики безопасности. При этом в режиме реального времени на консоль АИБ поступают сигналы о тех или иных нарушениях. Кроме того, информация по всем событиям первичного (не разобранного) аудита и результатам анализа накапливается в базе данных, что позволяет производить последующие детальные расследования действий пользователей, в том числе с привлечением статистических методов. Особое значение имеет возможность совместного анализа данных аудита от различных подсистем, что позволяет с большей достоверностью выявлять подозрительные действия пользователей, в том числе распределенные атаки на систему.


Контрольные вопросы по разделу 2.2.

1. Требования к подсистеме защиты информации от НСД «закрытого» контура;

2. Требования к подсистеме криптографической защиты информации «закрытого» контура;

  1. Требования к подсистеме антивирусной защиты информации «закрытого» контура;

  2. Требования к подсистеме контроля целостности «закрытого» контура;

  3. Требования к подсистеме защиты межсетевого взаимодействия «закрытого» контура;

  4. Требования к подсистеме администрирования «закрытого» контура;

  5. Требования к подсистеме обнаружения и противодействия вторжений«закрытого» контура;

  6. Требования к подсистеме аудита состоянии ИБ «закрытого» контура