Мошак_Птицына_ Учебное пособие. Федеральное государственное бюджетное образовательное учреждение высшего образования санктпетербургский
 Скачать 3.09 Mb.
|
|
Глава 3. Требования к построению защищенной информационной системы 3.1.Общие требования к подсистемам «закрытого» и «открытого» контуров ИС При построении системы ИБ «закрытого» и «открытого» контура ИС организации в ней должны быть реализованы следующие общие подсистемы: – резервирования и восстановления информации; – контроля эталонного состояния информации и рабочей среды; – управления безопасностью; – антивирусной защиты информации; 3.1.1. Общие требования к подсистеме резервирования и восстановления информации Подсистема резервного копирования и восстановления предназначена для обеспечения непрерывной работы ИС и ее восстановления путем резервного копирования программ и данных и их восстановления из резервных копий. Резервному копированию подлежат все программы и данные, обеспечивающие работоспособность системы и выполнение её задач (системное и прикладное программное обеспечение, базы данных и другие наборы данных), а также архивы, журналы транзакций, системные журналы и т. д. Рабочие конфигурации серверов, на которых хранится и обрабатывается конфиденциальная информация, подлежат резервному копированию. Все программное обеспечение, используемое в системе, должно иметь справочные (дистрибутивные) копии. Их местоположение и информация об ответственных за их создание, хранение и использование должны быть указаны в формах для каждого АРМ. Также указываются перечни наборов данных, подлежащих страховому копированию, периодичность копирования, место хранения и ответственных за создание, хранение и использование страховых копий данных. Соответствие состояния защищаемых информационных ресурсов и рабочих конфигураций серверов и АРМ, обрабатывающих конфиденциальную информацию, контролируется подсистемой управления эталонным состоянием информации и рабочей средой. Быстрое восстановление программ с использованием справочных копий и данных, включенных в перечень неизменяемых защищенных информационных ресурсов (с использованием страховых копий) в случае уничтожения или повреждения в серьезной или угрожающей кризисной ситуации обеспечивается резервным (страховым) копированием и внешним (в отношении основных компонентов системы) хранением копий. 3.1.2. Общие требования к подсистеме контроля эталонного состояния информации и рабочей среды Подсистема контроля эталонного состояния информации и рабочей среды предназначена для фиксации и динамического контроля изменений состояния наборов данных, эталонного состояния параметров рабочей среды путем сравнения текущих характеристик контролируемых объектов с эталонными характеристиками. Должна быть предусмотрена возможность выбора объектов ИС для проверки их соответствия стандарту. Объекты выбираются на основе перечня защищаемых информационных ресурсов и частоты их изменений, а также перечня программных средств, участвующих в обработке конфиденциальной информации и степени их влияния на работу защищаемых ИС. Контрольное состояние должно контролироваться динамически, в соответствии с нормативами, при загрузке ОС серверов, рабочих станций, при регистрации пользователей в ИС или в системе безопасности. Должна быть реализована функция периодической проверки. Результаты проверок должны быть отправлены в подсистему управления безопасностью для обработки. 3.1.3. Общие требования к подсистеме управления безопасностью Подсистема управления безопасностью предназначена для контроля эффективности защиты, регистрации данных о событиях в ИЭ, событиях в системе безопасности, автоматизированной обработки данных и поддержки принятия решений о разработке управляющих действий на других подсистемах системы безопасности посредством сбора и автоматизированной обработки регистрационных данных. Подсистема управления безопасностью должна выполнять функции обновления системы безопасности. Комплексный подход к обеспечению актуальности системы информационной безопасности должен охватывать следующие функциональные области: – периодический и, по возможности, динамический контроль безопасности, обеспечивающий своевременное обнаружение возникающих уязвимостей, которые могут быть использованы для проведения атак; – обнаружение атак в режиме реального времени, что позволяет своевременно выявлять и локализовать попытки совершения несанкционированных действий и выявлять факты несанкционированного воздействия на компьютерные ресурсы; – централизованное и упреждающее управление, обеспечивающее автоматизированную поддержку принятия решений, а также эффективный контроль за пользователями и ресурсами сети для уменьшения количества ошибок администрирования и принятия упреждающих мер для предотвращения наихудших событий. Контроль защищенности должен обеспечивать периодическое, а в некоторых случаях динамическое, выполнение следующих базовых функций: – проверка системы безопасности на соответствие новым руководящим принципам и нормативным документам в области информационной и компьютерной безопасности; – контроль за правилами правильного использования средств защиты в зависимости от их состава и назначения; – контроль целостности и подлинности компонентов системы безопасности; – контроль правильного изменения параметров конфигурации системы безопасности; динамическая регистрация данных о функционировании системы защиты, их анализ и уведомление ответственных лиц в случае нарушения правильности средств защиты; – тестирование подсистем защиты на правильность реагирования при моделировании процесса реализации возможных атак; – контроль работоспособности подсистем защиты при имитации неисправностей отдельных элементов компьютерной сети; – проверка на отсутствие ошибок администрирования и конфигурации; – анализ политики формирования и использования справочной информации (ключей, паролей и т.д.); – проверка на своевременность обновления программного обеспечения; – проверка на отсутствие программных закладок и вирусов. Проверка системы безопасности на соответствие соответствующим руководящим принципам и правилам в области информационной и компьютерной безопасности должна обеспечивать своевременное выявление недостатков в системе безопасности на основе анализа передовой практики систематизации требований к таким системам. Контроль за соблюдением правил правильного использования средств защиты в зависимости от их состава и назначения заключается в периодическом контроле и пересмотре политики в области безопасности на ее административном и процедурном уровнях. При изменении структуры, шаблонов процессов или условий работы компьютерной системы концепция безопасности и подробные процедурные меры могут изменяться, в частности, конкретная информация и инструкции по компьютерной безопасности, относящиеся к администраторам и пользователям компьютерной системы. Контроль целостности и подлинности компонентов системы защиты предполагает периодический или динамический контроль: – наличия требуемых резидентных компонентов системы защиты в оперативной памяти компьютера; – всех программ системы защиты, находящихся во внешней и оперативной памяти, на соответствие эталонным характеристикам; – корректности параметров настройки системы защиты, располагаемых как в оперативной, так и во внешней памяти; – корректности эталонной информации (идентификаторов, паролей, ключей шифрования и т.д.). При проверке правильности изменения параметров конфигурации системы безопасности подсистема мониторинга не должна разрешать установку параметров, противоречащих политике безопасности, принятой в организации. Запись данных о работе системы безопасности предполагает запись и накопление информации о последующих действиях всех подсистем безопасности, всех администраторов и пользователей других категорий по использованию средств безопасности. Помимо регистрации данных о работе системы безопасности, следует обеспечить периодический анализ накопленной информации. Основной целью такого анализа является своевременное выявление недопустимых действий, а также прогнозирование степени защищенности информации и её обработки в компьютерной системе. Для проведения периодического анализа необходимо заранее подготовить правила описания политики функционирования системы защиты по одному из принципов: «допустимо все, что не запрещено в работе системы защиты» и «запрещено все, что явно недопустимо». Более высокий уровень контроля и безопасности обеспечивается вторым принципом, так как на практике не всегда можно в полной мере учитывать все действия, которые запрещены. Надежнее выявить все разрешенные действия и запретить все остальные. Если подсистема мониторинга обнаруживает какие-либо нарушения в надлежащем функционировании подсистемы безопасности, соответствующие представители безопасности должны быть немедленно уведомлены. Тестирование подсистем защиты на правильность реагирования при моделировании процесса реализации возможных атак осуществляется с помощью специализированных средств анализа безопасности, которые, как правило, обеспечивают выполнение оставшихся функций контроля безопасности. 3.1.4. Подсистема антивирусного контроля Подсистема антивирусного контроля должна реализовать архитектуру, позволяющую организовать централизованное управление антивирусными шлюзами с помощью средств управления ИС, включающих антивирусную защиту рабочих станций и серверов как «закрытого», так и «открытого» контуров. Архитектура антивирусных шлюзов должна основываться на принципе централизованного управления шлюзами как компонентами системы антивирусной защиты ИС. Антивирусные шлюзы должны быть реализованы в виде программных агентов, установленных на серверной ОС, используемой для взаимодействия в ИС, что должно обеспечить выполнение функций антивирусной проверки содержания информации, передаваемой по сетевым каналам. Управление агентами должно осуществляться по защищенному логическому каналу с аутентификацией пользователя (защита должна обеспечиваться от наложения контрольных действий на агенты антивирусной системы). Подсистема управления должна обеспечивать возможность создания логической структуры системы антивирусной защиты независимо от логической структуры ЛВС. Возможность включения в сегмент, защищенный антивирусными агентами, не должна зависеть от количества сетевых доменов, должна быть реализована сегментация сети посредством физической и логической сегментации, а также возможность управления агентами через брандмауэры. Агенты должны интегрироваться в системы передачи данных IS в качестве дополнительного модуля. Во время работы подсистема антивирусного контроля должна обеспечивать: – централизованный контроль антивирусной защиты в соответствии с правилами антивирусной защиты со стороны подразделения безопасности (администраторов антивирусной защиты) и передача данных, генерируемых в результате антивирусной проверки, в подсистему управления безопасностью; – автоматический запуск при инициализации ИС, а также в ручном режиме. В активном режиме антивирусный контроль должен обеспечивать обнаружение вирусов в программах и файлах данных, получаемых по каналам связи и с отчуждаемых носителей. В пассивном режиме – запускаться как самостоятельная задача и после окончания текущей проверки завершать работу. Работать в пассивном режиме (как самостоятельная задача) и после окончания текущей проверки завершать работу. 3.2. Требования к подсистемам обеспечения ИБ «закрытого» контура Подсистемы обеспечения безопасности «закрытого» контура типовой ИС организации должны обеспечивать: – защиту информации от НСД; – криптографическую защиту информации; – контроль целостности; – защиту межсетевого взаимодействия; – администрирование; – обнаружение и противодействие вторжений; – резервирования и восстановления информации; – контроля эталонного состояния информации и рабочей среды; – управления безопасностью; – мониторинг состоянии ИБ. Основные требования к подсистемам «закрытого» контура приведены в [17]. 3.2.1. Типовые требования к подсистеме защиты информации от НСД Отметим, что при создании конкретной ИС Заказчик формирует требования по защите информации в том числе и в соответствии с классификацией защищенности ИС и средств вычислительной техники (СВТ) определяемой, в частности, Руководящими документами ФСТЭК [11- 13] и др. Руководящим документом [11] устанавливается девять классов защищенности АС от НСД к информации. Необходимыми исходными данными для проведения классификации конкретной АС являются: – перечень защищаемых информационных ресурсов АС и их уровень конфиденциальности; – перечень лиц, имеющих доступ к штатным средствам АС, с указанием их уровня полномочий; – матрица доступа или полномочий субъектов доступа по отношению к защищаемым информационным ресурсам АС; – режим обработки данных в АС. К числу определяющих признаков, по которым производится группировка АС в различные классы, относятся: – наличие в АС информации различного уровня конфиденциальности; – уровень полномочий субъектов доступа АС на доступ к конфиденциальной информации; – режим обработки данных в АС - коллективный или индивидуальный. Руководящий документ [12] устанавливает классификацию средств вычислительной техники по уровню защищенности от несанкционированного доступа к информации на базе перечня показателей защищенности и совокупности описывающих их требований. Устанавливается семь классов защищенности СВТ от НСД к информации. Самый низкий класс - седьмой, самый высокий - первый. Организационные и технические меры по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных приведены в [14, 23]. При этом, Постановление Правительства РФ [23] устанавливает 4 уровня защищенности персональных данных, которые определяются видом ИСПДн, типом актуальных угроз и количеством субъектов ПДн, обрабатываемых в информационной системе (табл. 1). Таблица 1 Классификация ИСПДн по уровням защищенности и типам угроз Виды ИСПДн Уровни защищенности ИСПДн угрозы 1 типа угрозы 2 типа угрозы 3 типа ИСПДн-С 1 2 < 100000 > 1 3 < 100000 > 2 ИСПДн-Б 1 Тип ИСПДн 3 ИСПДн-О 2 3 < 100000 > 2 4 ИСПДн-И 1 3 < 100000 > 2 4 < 100000 > 3 Виды ИСПДн категорируются по типам обрабатываемой информации. ИСПДн-С – ИС персональных данных, обрабатывающая специальные категории ПДн, касающиеся расовой, национальной принадлежности, политических взглядов, религиозных и философских убеждений, состояния здоровья, интимной жизни субъектов; ИСПДн-Б – ИС персональных данных, обрабатывающая биометрические сведения, которые характеризуют физиологические и биологические особенности человека, на основании которых можно установить его личность и которые используются оператором для установления личности субъекта персональных данных, и не обрабатываются сведения, относящиеся к специальным категориям персональных данных; ИСПДн-О – ИС персональных данных, обрабатывающая общедоступные ПДн; ИСПДн-И – ИС персональных данных, обрабатывающая иные категории. Подсистема защиты от НСД «закрытого» контура предназначена для разграничения доступа к сетевым, информационным и вычислительным ресурсам контура как со стороны пользователей и администраторов внутри контура, так и со стороны пользователей и администраторов «открытого» контура. Подсистема должна требовать от пользователей идентификации в запросах на доступ и аутентификации идентификатора - его аутентификации, а также. Запретить доступ к защищенным ресурсам неустановленных пользователей и пользователей, чье удостоверение не было аутентифицировано. Механизмы управления доступом. Механизмы управления доступом используются для предоставления услуг управления доступом. Механизмы контроля доступа - это те, которые используются для усиления стратегии ограничения доступа к ресурсу через доступ только к тем субъектам, которые имеют на это полномочия. Управление доступом используется для определения полномочий отправителя данных устанавливать сеанс связи и/или использовать ресурсы в сеансе связи. Требования, подходы и проблемы контроля доступа. Механизмы контроля доступа являются основой защиты ресурсов, обеспечивая решение задачи разграничения доступа субъектов к защищенным информационно- техническим ресурсам - объектам. В качестве субъектов в простейшем случае понимается пользователь. На практике механизмы управления доступом необходимы, даже если в системе может присутствовать только один пользователь приложения. Это связано с тем, что, как правило, в системе должна быть создана учетная запись пользователя с правами администратора, которая настраивает параметры системы безопасности и права доступа к ресурсам защищаемого объекта. При этом администратор имеет принципиально иные права, чем пользователь приложения. Механизм контроля доступа реализует на практике некую абстрактную (или формальную) модель, определяющую правила установления политики делимитации доступа к защищаемым ресурсам и правила обработки запросов на доступ к защищаемым ресурсам. Дискреционная (матричная) модель. Рассмотрим так называемую матричную модель защиты (ещё называемую дискреционной моделью), ставшую более распространённой на практике сегодня. С точки зрения матричной модели система защиты описывается как S, O, M: где S - совокупность субъектов, являющихся активными структурными элементами модели; O - объекты множественного доступа, являющиеся пассивными защищёнными элементами модели. Каждый объект уникально заражен именем объекта; M - матрица доступа. Значение элемента матрицы M [S, O] обеспечивает права доступа субъекта S к объекту O. Права доступа регулируют доступ субъекта S к различным типам объектов доступа. В частности, права доступа субъектов к файловым объектам обычно определяются как чтение (R), запись (W) и выполнение (E). Основой реализации управления доступом является анализ строки матрицы доступа при обращении субъекта к объекту. При этом проверяется строка матрицы, соответствующая объекту, и анализируется, разрешены ли ей права доступа для субъекта или нет. На основании этого принимается решение о предоставлении доступа. При всей наглядности и гибкости возможных настроек разграничитель- ной политики доступа к ресурсам, матричным моделям присущи серьезные недостатки. Основной из них — это излишне детализированный уровень описания отношений субъектов и объектов. Из-за этого усложняется процедура администрирования системы защиты. Причем это происходит как при задании настроек, так и при поддержании их в актуальном состоянии при включении в схему разграничения доступа новых субъектов и объектов. Как следствие, усложнение администрирования может приводить к возникновению ошибок. Многоуровневые (обязательные) модели. Для устранения недостатков матричных моделей были разработаны так называемые многоуровневые модели защиты, классическими примерами которых являются модель конечного состояния Белла и ЛаПадулы, а также модель решетки Д. Демнинга. Многоуровневые модели предполагают формализацию процедуры присвоения прав доступа с помощью так называемых меток конфиденциальности или мандатов, назначенных субъектам и объектам доступа. Таким образом, для объекта доступа, например, метки могут быть определены в соответствии с уровнем доступа человека к информации, а для объекта доступа (самих данных) признаки конфиденциальности информации. Признаки конфиденциальности ИС регистрируются в метке объекта. В связи с использованием терминов «мандат», «метка», «полномочия» многоуровневую защиту часто называют соответственно либо мандатной защитой, либо защитой с метками конфиденциальности, либо полномочной защитой. Права доступа каждого объекта и характеристики конфиденциальности каждого объекта отображаются как набор уровней конфиденциальности и набор категорий конфиденциальности. Уровень последовательности может принимать одну из строго упорядоченных серий для ИК предприятия фиксированных значений, например, конфиденциальных, секретных, для служебного пользования, необеспеченных и т. д. Основой реализации контроля доступа являются: 1. Официальное сравнение метки субъекта, запросившего доступ, и метки объекта, к которому запрашивался доступ. 2. Решения о предоставлении доступа основываются на определенных правилах, которые основаны на противодействии снижению конфиденциальности защищаемой информации. Таким образом, многоуровневая модель предотвращает возможность преднамеренного или случайного снижения уровня конфиденциальности рассматриваемой информации из-за её утечки (умышленной передачи), то есть эта модель предотвращает передачу информации от объектов с высоким уровнем конфиденциальности и узким набором категорий доступа к объектам с более низким уровнем конфиденциальности и более широким набором категорий доступа. Практика показывает, что многоуровневые модели защиты гораздо ближе к потребностям реальной жизни, чем матричные модели, и обеспечивают хорошую основу для построения автоматизированных систем разграничения доступа. Кроме того, поскольку отдельные категории одного уровня равны, для их различения наряду с многоуровневой (мандатной) моделью требуется применение матричной модели. С помощью многоуровневых моделей можно значительно упростить задачи администрирования (настройки). Кроме того, это касается как первоначальной установки политики доступа с делителями (такой высокий уровень и детализация установки отношения «предмет-объект» не требуется), так и последующего включения новых субъектов и объектов доступа в схему администрирования. Подсистема защиты от НСД «закрытого» контура должна обеспечивать: – однозначную идентификацию пользователей в ИС и в операционной системе (далее – ОС) АРМ (использование общих идентификаторов (ни в СЗИ, ни в ОС) не допускается; – идентификацию по логическим именам информационных ресурсов (логических устройств, каталогов, файлов); – исключение возможности удаленного подключения к локальным ресурсам «закрытого» контура и управление доступом к этим ресурсам за счет настроек ОС и СЗИ АРМ «закрытого» контура; – управление доступом между «закрытым» контуром и «открытым» контуром на основе применения технологии межсетевых экранов (далее – МЭ); – мандатное (многоуровневое) разграничение доступа субъектов «закрытого» контура к объектам с помощью маркеров доступа СЗИ ОС доменных пользователей и меток конфиденциальности объектов, хранящихся в их дескрипторах безопасности таблиц контроля доступа (далее – ТРД). Мандатное разграничение доступа должно быть реализовано в соответствии с моделью Белла-ЛаПадула: а) классификационные метки безопасности каждого субъекта и каждого объекта должны соответствовать, отражая их место в соответствующей иерархии. С помощью этих меток уровни классификации должны присваиваться субъектам и объектам; б) при вводе новых данных в систему метка этих данных запрашивается и принимается от уполномоченного пользователя; в) при наличии полномочий на перечисление пользователей новой организации она сравнивается с классификационными метками; г) Предписанный принцип контроля доступа должен быть реализован для всех объектов с явным и скрытым доступом любого из субъектов. "Явный" здесь относится к доступу, сделанному с помощью системных инструментов - системных макросов, высокоуровневых языковых инструкций и т. д., в то время как "скрытый" относится к другому доступу, в том числе с использованием собственных программ устройств; д) субъект может читать объект только в том случае, если иерархическая классификация на уровне классификации субъекта не меньше иерархической классификации на уровне классификации объекта; е) субъект записывает объект только в том случае, если уровень классификации субъекта в иерархической классификации не превышает уровень классификации объекта в иерархической классификации; ж) должна быть возможность изменения уровней классификации субъектов и объектов специально выделенными субъектами. Для реализации дискреционного разграничения полномочий доступа отдельных категорий пользователей одного уровня в «закрытом» контуре должна применяться матричная модель контроля доступа субъектов к защищаемым объектам ТРД. Она должна: – храниться в отдельном файле отдельного каталога. Полное имя и путь данного файла должны задаваться в консоли АИБ «закрытого» контура; – содержать перечисление санкционированных (разрешенных) операций для каждой пары «субъект–объект» системы защиты. Должно быть задано явное и недвусмысленное перечисление допустимых типов доступа: читать, писать, удалять, запускать, переименовывать, т. е. тех типов доступа, которые являются санкционированными для данного субъекта к данному ресурсу (объекту). Управление мандатным и дискреционным доступом субъектов в «закрытом» контуре к объектам контура – через доверенного диспетчера доступа (далее – доверенный диспетчер). При этом доверенный диспетчер должен обеспечить выполнение следующих задач: а) присваивают пользователям домена и группам любые встроенные функциональные роли или роли безопасности в прикладном программном обеспечении "замкнутого" цикла или лишают их перечисленных ролей; б) устанавливает права разграничения доступа субъектов «закрытого» контура к объектам, контролируемым прикладным программным обеспечением; в) аудит успешных/или неудачных попыток идентификации, аутентификации и авторизации пользователей в специальном программном обеспечении «закрытого» контура, а также включение/отключение аудита событий выхода или прерывания сеанса пользователей прикладного программного обеспечения «закрытого» контура; г) аудит успешных и/или неудачных попыток доступа отдельных субъектов «закрытого» контура (пользователей домена, групп или всех) к отдельным объектам, управляемым прикладным программным обеспечением на дискретной основе; д) аудит успешных и/или неудачных попыток доступа к объектам, управляемым прикладным программным обеспечением пользователями в соответствии с мандатом, а также запрашиваемых прав доступа к объекту; е) аудит успешных и/или неудачных попыток пользователей реализовать права в процессе работы с прикладным программным обеспечением; ж) включение/отключение аудита событий блокировки/разблокировки операций прикладного ПО, а также изменений пользователей домена или полномочий групп в прикладном программном обеспечении (их включение/исключение из определённых функциональных ролей и/или ролей безопасности прикладного ПО); з) задавать полное имя и путь к файлу, содержащему ТРД субъектов «закрытого» контура к объектам, управляемым прикладным ПО; и) выполнять операции блокировки/разблокировки работы специального ПО. Доверенный диспетчер должен регистрировать в журнале безопасности ОС следующие события, которые должны быть доступны для аудита: – успешные и/или неудачные попытки идентификации, аутентификации и авторизации пользователей в прикладном ПО; – выход или прерывание сеанса работы пользователя в прикладном ПО; – успешные и/или неудачные попытки доступа к объектам, управляемым прикладным ПО, со стороны пользователей по дискреционному принципу; – успешные и/или неудачные попытки верификации пользователей при выполнении тех или иных действий в системе; – успешные и/или неудачные попытки назначение доменным пользователям или группам тех или иных встроенных функциональных ролей безопасности в прикладном ПО с консоли администрирования «закрытого» контура; – события блокировки/разблокировки работы прикладного ПО; – критические и фатальные ошибки, возникающие в программном коде доверенного диспетчера без возможности его отключения; – успешные и/или неудачные попытки доступа к объектам со стороны пользователей по мандатному признаку; – запрашиваемые права доступа к объекту. При записи событий в журнале должны фиксироваться – код (ID) события; – тип события (успех, неудача); – категория события («начало сеанса работы», «прекращение сеанса работы», «доступ к объектам», «применение полномочий», «изменение полномочий», «блокировка работы прикладного ПО», «разблокировка работы прикладного ПО», «критическая ошибка», «фатальная ошибка»); – дата и время события; – источник события; – пользователь, инициировавший данное событие; – компьютер, на котором инициировано данное событие; описание события. Администрирование доступом субъектов «закрытого» контура к защищенным объектам должно быть реализовано с помощью отдельной оснастки, консоли либо утилиты администрирования «закрытого» контура, представляющая собой отдельный файл, в котором должны быть реализованы возможности: – разграничения доступа доменных пользователей и групп к объектам «закрытого» контура с учетом явного или косвенного (через несколько вложений в группы) включения пользователя во все группы, которым разрешен или явно запрещен доступ к указанному объекту с возможностью блокировки доступа в случае его запрета (дискреционный принцип); – выдачи мандатных меток объектов, управляемых прикладным ПО «закрытого» контура; – назначения отдельным пользователям или группам пользователей встроенных ролей прикладного ПО; – регламентации доступа пользователей к физическим устройствам АРМ (дискам, портам ввода-вывода); – разграничения доступа к маршрутизаторам и к серверам «закрытого» контура на уровне сетевых служб и процессов, обеспечивающих доступ к сетевым ресурсам по следующим параметрам: а) пользователям; б) процессам; в) времени доступа; г) по службам доступа (портам); д) политике безопасности (запрещенные/разрешенные сервера и службы). – создания замкнутой программной среды разрешенных для запуска программ, расположенных как на локальных, так и на сетевых дисках АРМ «закрытого» контура. Управление замкнутой программной средой должно осуществляться централизованно; – контроля целостности модулей системы защиты, системных областей диска и произвольных списков файлов в автоматическом режиме и по командам АИБ «закрытого» контура: а) контроль целостности должен выполняться по контрольным суммам, как в процессе загрузки, так и динамически; б) механизм верификации контрольных сумм должен использовать аттестованный алгоритм; в) анализ контрольных сумм должен проводиться как в процессе загрузки, так и динамически. – оперативного восстановления средств защиты от НСД после сбоев и отказов оборудования в штатном режиме работы; – регистрации всех действий пользователя в защищенном журнале «закрытого» контура с учетом наличия нескольких уровней регистрации; – оповещения АИБ «закрытого» контура обо всех событиях НСД, происходящих в «закрытом» контуре. 3.2.2. Требования к криптографической подсистеме Подсистема защиты криптографической информации предназначена для обеспечения конфиденциальности, целостности и авторизации информации, хранящейся, передаваемой и обрабатываемой в замкнутом контуре. Подсистема криптографической защиты информации обеспечивает выполнение функций шифрования согласно ГОСТ 28147-89 и формирование/проверку электронной цифровой подписи (далее – ЭЦП). Следует использовать только стандартизированные алгоритмы цифровой подписи. Подсистема защиты криптографической информации должна включать в себя компонент управления и распространения ключевой информации, а также компоненты, работающие на объектах управления, серверах и рабочих станциях администраторов и операторов ИС. Компонент управления и распространения ключевой информации подсистемы криптографической защиты информации должен включать в себя формирование ключевых элементов шифрования и ЭЦП. Подсистема криптографической защиты информации должна обеспечивать: – шифрование всей секретной информации, которая записывается на совместно используемых различными субъектами носителей доступа (разделенных) данных, а также на съемных портативных носителях данных (дискетах, компакт-дисках, флэш-носителях и т.д.) долговременной внешней памяти для хранения вне сеансов уполномоченных субъектов доступа. Необходимо выполнить принудительную очистку областей внешней памяти, содержащих ранее незашифрованную информацию. Доступ субъектов к операциям шифрования и соответствующим криптографическим ключам должен далее контролироваться подсистемой управления доступом. Порядок работы с ключевыми материалами криптографических систем защиты информации регулируется; – использование различных ключей шифрования для групп пользователей в соответствии с их полномочиями для доступа к защищенным ресурсам при использовании криптографических средств для контроля доступа уполномоченных пользователей к информационным ресурсам «закрытого» контура. Ключи шифрования должны быть защищены; – формирование и проверка ЭЦП; – формирование ключевых элементов шифрования для пользователей «закрытого» контура ЛВС, пользователей «открытого» контура и для пользователей «закрытых» контуров взаимодействующих систем ведомственных сегментов; – управление ключевой информацией и ее распространение; – криптографическую стойкость и многоуровневую защиту от компрометации ключевой информации, разделение пользователей по уровням защиты и областям их взаимодействия между собой и пользователями других уровней; – криптографическую защиту межсетевого обмена между ЛВС «закрытого» контура и взаимодействующими системами ведомственных сегментов. Информация должна быть зашифрована перед отправкой по сети. При передаче секретной информации на носителе - перед записью на носитель. – раздельное шифрование всей конфиденциальной информации, которая записывается на совместно используемую различными субъектами внешнюю память, а также на съемных носителях данных (компакт-дисках, носителях USB и т. д. – принудительную очистку участков внешней памяти, содержащих ранее незашифрованную информацию. Доступ субъектов к операциям шифрования и соответствующим криптографическим ключам должен контролироваться подсистемой управления доступом и др. Должны использоваться сертифицированные средства криптографической защиты. 3.2.3. Подсистема контроля целостности «закрытого» контура Подсистема контроля целостности «закрытого» контура должна обеспечивать контроль: – файлов операционной системы до ее загрузки; – изменения файлов; – создания и удаления файлов; – переименования файлов; – создания и удаления каталогов; – переименования файлов; – перемещения файлов из каталога в каталог; – содержимого системных областей. Подсистема должна запускаться автоматически при инициализации аппаратно-программных средств «закрытого» контура, а также в ручном режиме. Контроль целостности должен осуществляться путем: – перехвата обращений к функциям ОС работы с файловой системой и задания перечня разрешенных действий; – сравнения зафиксированного эталонного состояния объектов с их текущим состоянием. Фиксация эталонного состояния контролируемых объектов должна осуществляться путем создания эталонных копий, хранение которых осуществляется в защищенных областях жесткого диска или на защищенных внешних носителях. Подсистема должна иметь удобный пользовательский интерфейс для создания списка контролируемых объектов с помощью масок, шаблонов и поисковой системы. Контроль целостности должен осуществляться в соответствии с контрольными суммами как во время загрузки, так и динамически. Механизм проверки контрольной суммы должен использовать сертифицированный алгоритм. Анализ контрольной суммы должен выполняться как во время загрузки, так и динамически. Защита должна включать в себя процедуру восстановления от отказов и отказов оборудования, которая должна обеспечивать восстановление свойств. Должен быть реализован механизм восстановления работоспособности средств защиты в случае нарушений в его нормальном режиме работы. Функциональность должна быть восстановлена сразу после обнаружения сбоя в нормальной работе. 3.2.4. Подсистема защиты межсетевого взаимодействия «закрытого» контура Подсистема защиты межсетевого взаимодействия, закрытого «закрытого» контура предназначена для защиты однонаправленной передачи данных из «открытого» контура в «закрытый» контур и сегментирования ЛВС указанных контуров. Подсистема защиты межсетевого взаимодействия, закрытого «закрытого» контура должна обеспечивать: 1. Сегментацию ЛВС «закрытого» контура и ЛВС «открытого» контура на канальном, сетевом и прикладном уровнях семиуровневой модели OSI. Управление потоками между ЛВС «закрытого» контура и ЛВС «открытого» контура обеспечивается: а) однонаправленной фильтрацией потока данных между «открытым» контуром и «закрытым» контуром; б) фильтрацией на канальном уровне, а именно: – фильтрацией потока данных на основе MAC-адресов отправителя и получателя; – фильтрацией средствами защиты с учетом входного и выходного сетевого интерфейса и проверкой подлинности сетевых адресов. В настройках параметров фильтрации должна присутствовать возможность допускать или – запрещать прохождение сетевыми пакетами из списка адресов указанный сетевой интерфейс; – фильтрацией с учетом даты/времени и возможности определения временных интервалов для выполнения правил фильтрации. в) фильтрация на сетевом уровне, а именно: – фильтрацией каждого сетевого пакета независимо на основе сетевых адресов отправителя и получателя или на основе других эквивалентных атрибутов. Фильтрация производится по IP-адресам и MAC-адресам; – фильтрацией на межсетевых экранах с учетом любых значимых полей сетевых пакетов; – фильтрацией пакетов служебных протоколов, служащих для диагностики и управления работой сетевых устройств «закрытого» контура. Должна обеспечиваться поддержка фильтрации протокола ICMP; – фильтрацией с учетом даты/времени и возможность определения временных интервалов для выполнения правил фильтрации; – регистрацией и учетом фильтруемых пакетов. В параметры регистрации должны включаться адрес, время и результат фильтрации. г) фильтрация на транспортном уровне, а именно: – фильтрацией запросов на установление виртуальных соединений. При этом должны учитываться транспортные адреса отправителя и получателя. Фильтрация должна производиться по IP-адресам для TCP и UDP соединений; – фильтрацией с учетом даты/времени и возможности определения временных интервалов для выполнения правил фильтрации; регистрацией и учетом запросов на установление виртуальных соединений. д) фильтрация на прикладном уровне, а именно: – фильтрацией на прикладном уровне запросов к прикладным сервисам. При этом должны учитываться прикладные адреса отправителя и получателя; Фильтрация производится по сокетам (sockets) для TCP и UDP соединений; – возможностью сокрытия субъектов (объектов) и/или прикладных функций «закрытого» контура; – фильтрацией с учетом даты/времени и возможности определения временных интервалов для выполнения правил фильтрации; – регистрацией и учетом запрашиваемых сервисов прикладного уровня (посредством связки IP-адреса и номера порта удаленного сервера для устанавливаемого сеанса связи). 2. Авторизация MAC-адресов АРМ пользователей с «закрытым» контуром при подключении к локальной сети с «закрытым» контуром. При обнаружении неавторизованного MAC-адреса порт соответствующего устройства должен быть автоматически отключен. 3. Использует режим концентратора, который принимает пакеты, адресованные только авторизованному MAC-адресу. 4. Исключить и контролировать доступ к несанкционированным удаленным подключениям к локальным ресурсам «закрытого» контура. 5. Обязательный мониторинг открытых точек доступа к периметру «закрытого» контура. При организации однонаправленных соединений из «открытого» контура в «закрытый» контур для обеспечения доступа к секретной информации, обрабатываемой на серверах «закрытого» контура, необходимо заранее решить вопрос криптографической защиты трафика этих соединений с помощью сертифицированных средств ФСБ России. В то же время для разрешенных TCP-соединений, исходящих из «открытого» контура, необходимо указать адрес назначения, адрес источника и номер IP- порта, соответствующие службе, внешней для «открытого» контура. 6. Регистрация входящих пакетов в «закрытый» контур, не соответствующих правилам листов доступа маршрутизатора и внутреннего MЭ, путем отображения соответствующих событий в системном журнале. 7. Контроль информации, передаваемой через электронную систему обмена сообщениями в «закрытом» контуре путем фильтрации протоколов передачи электронной почты специализированными средствами, установленными на серверах, обеспечивающих работу почтовой системы внутри «закрытого» контура. Правила фильтрации должны регулироваться. Рабочие данные фильтра передаются в подсистему управления безопасностью. 8. Программируемый ответ на события в устройстве защиты (возможность генерировать заданный уровень детализации событий в журнале AИБ. Регистрация категорий событий, таких как изменение конфигурации и т.д.). 9. Оперативная сигнализация на основе защищенного протокола SNMP v.3, а именно: – локальная сигнализация попыток нарушения правил фильтрации (оповещение АИБ «закрытого» контура о попытках установления запрещенных соединений непосредственно фильтрующим модулем (звуковое сопровождение, вывод сообщения на экран, световая индикация и т.п.)); – дистанционная сигнализация попыток нарушения правил фильтрации (информирование АИБ «закрытого» контура и уполномоченных лиц о попытках установления запрещенных соединений с помощью электронной почты, SMS-сообщений или внешних систем оповещения). 3.2.5. Подсистема администрирования «закрытого» контура Подсистема администрирования «закрытого» контура предназначена для настройки прав разграничения доступа (далее – ПРД) субъектам «закрытого» контура к объектам управления. В «закрытом» контуре должна быть реализована централизованная подсистема администрирования СЗИ «закрытого» контура. Управление активным сетевым оборудованием «закрытого» и «открытого»контуров ЛВС ИС должно контролироваться специалистами отдела информационной безопасности с использованием механизмов регулярного аудита сетевого оборудования. Подсистема аудита должна управляться подразделениями информационной безопасности. Администрирование СЗИ «закрытого» контура должно производиться АИБ «закрытого» контура с локальной консоли или удаленно с использованием шифрования трафика управления на IP-уровне или с использованием протоколов управления с поддержкой шифрования данных (SNMP v3). Удаленные запросы безопасности должны использовать методы, устойчивые к пассивному и активному перехвату информации. Для этого следует использовать криптографические механизмы аутентификации с использованием ЭЦП. В подсистеме администрирования должна быть реализована система агентов, для всех защищенных АРМ, позволяющая АИБ «закрытого» контура в реальном времени получать информацию и осуществлять централизованное управление политикой безопасности системы защиты. Подсистема администрирования должна обеспечивать: – установку ключевых элементов и механизмов доступа в средства СЗИ «закрытого» контура с целью обеспечения им возможности доступа к объектам управления. При этом установка и перестановка ключевых элементов и механизмов доступа должна осуществляться как по команде администратора центра генерации и распространения ключей (ЦГРК), так и по инициативе администратора «закрытого» контура; – взаимодействие с ЦГРК с целью обеспечения доставки ключевых элементов и механизмов доступа; – установку ПРД и их изменение; – идентификацию и аутентификацию АИБ «закрытого» контура при его запросах на доступ; – возможность делегирования прав (т. е. присвоения пользователю ограниченных административных привилегий управления некоторым набором учетных записей); – использование универсальных шаблонов настроек политики безопасности «закрытого» контура; – возможность моделирования существующей организационной иерархии и административной структуры «закрытого» контура – пользователя «закрытого» контура; – возможность блокировки учетной записи пользователя «закрытого» контура или её ограничения по времени работы; – возможность доставки информации о нештатных ситуациях и ошибках, возникающих в процессе функционирования механизмов доступа, до АИБ «закрытого» контура. 3.2.6. Подсистема обнаружения и противодействия вторжений Подсистема обнаружения и противодействия вторжений должна обеспечивать: – удаленный централизованный, автоматизированный контроль функционирования процессов создания, обработки, хранения и передачи информации в рамках «закрытого» контура; – контроль за вычислительной средой объектов «закрытого» контура, в которой выполняются прикладные задачи; – контроль правильности работы прикладного программного обеспечения «закрытого» контура, реализующего функции обработки информации; – контроль правильности работы операторов и администраторов «закрытого» контура. 3.2.7. Подсистема мониторинга информационной безопасности «закрытого» контура Подсистема мониторинга информационной безопасности «закрытого» контура предназначена для оперативного контроля ее стояния с целью выявления нарушений требований политики ИБ «закрытого» контура и нормативных документов, выявления нештатных (или злоумышленных) действий и локализации инцидентов безопасности. Регистрация и анализ данных аудита должна производится централизованно на серверах (машинах) безопасности (далее – МБ) в режиме реального времени в соответствии с заданной политикой безопасности. Подсистема аудита ИБ «закрытого» контура должна обеспечивать: – контроль выполнения требований политики ИБ «закрытого» контура и нормативных документов по ИБ; – независимый мониторинг действий пользователей «закрытого» контура; – сбор первичных событий штатных журналов аудита объектов мониторинга, в том числе СЗИ; – регистрацию первичных событий аудита; – анализ первичных событий аудита в реальном времени и фиксацию событий ИБ на основе правил анализа событий ИБ от разнотипных источников «закрытого» контура; – обеспечение возможности создания и редактирования, а также проверки описаний событий ИБ; – обеспечение централизованного хранения зафиксированной информации о событиях ИБ и их последующий (отложенный) анализ (разбор событий аудита, выявление цепочек операций, выполняемых на серверах, рабочих станциях администраторов и операторов «закрытого» контура; – формирование сообщений о событиях ИБ и извещения персонала службы ИБ о зафиксированных событиях ИБ; – расследование событий ИБ и регистрацию инцидентов ИБ. |