Стандарты информационной безопасности
       

Общие функциональные требования


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

Для сервисов безопасности предусмотрены общие требования по протоколированию и аудиту (класс FAU):

  • автоматическая реакция аудита безопасности (FAU_ARP.1.1), включая генерацию записи в регистрационном журнале, а также локальную или удаленную сигнализацию об обнаружении вероятного нарушения безопасности, адресованную администратору;
  • генерация данных аудита безопасности (FAU_GEN.1). Обязательному протоколированию подлежат запуск и завершение регистрационных функций, а также все события для базового уровня аудита . В каждой регистрационной записи должны присутствовать дата и время события, тип события, идентификатор субъекта и результат (успех или неудача) события;
  • анализ аудита безопасности (FAU_SAA.1.2). С целью выявления вероятных нарушений должны производиться по крайней мере накопление и/или объединение неуспешных результатов использования механизмов аутентификации, а также неуспешных результатов выполнения криптографических операций;
  • просмотр аудита безопасности (FAU_SAR). Администратору предоставляется возможность читать всю регистрационную информацию. Прочим пользователям доступ к ней закрыт, за исключением явно специфицированных случаев;
  • выбор событий аудита безопасности (FAU_SEL.1). Избирательность регистрации событий должна основываться хотя бы на минимально необходимом наборе атрибутов, состоящем из идентификатора объекта, идентификатора субъекта, адреса узла сети, типа события, даты и времени события;
  • хранение данных аудита безопасности (FAU_STG.1.2). Регистрационную информацию следует защитить от несанкционированной модификации.

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


  • управление криптографическими ключами (FCS_CKM). Должны поддерживаться генерация криптографических ключей (FCS_CKM.1), распределение криптографических ключей (FCS_CKM.2), управление доступом к криптографическим ключам (FCS_CKM.3), уничтожение криптографических ключей (FCS_CKM.4);
  • криптографические операции (FCS_COP.1). Всю информацию, передаваемую по доверенному каналу, необходимо шифровать и контролировать ее целостность согласно требованиям стандартов и других нормативных документов.


Любой сервис безопасности содержит данные пользователей (например, информацию для идентификации и аутентификации), поэтому общими являются и требования класса FDP (защита данных пользователя):

  • политика управления доступом (FDP_ACC.1.1). Должно осуществляться разграничение доступа для пользователей, прямо или косвенно выполняющих операции с сервисом безопасности;
  • функции управления доступом (FDP_ACF.1.1). Применение функций разграничения доступа основывается на следующих атрибутах безопасности: идентификаторы субъектов доступа, идентификаторы объектов доступа, адреса субъектов доступа, адреса объектов доступа, права доступа субъектов;
  • базовая защита внутренней передачи (FDP_ITT.1). Следует осуществлять заданную политику управления доступом и/или информационными потоками, чтобы предотвратить раскрытие, модификацию и/или недоступность данных пользователя при их передаче между физически разделенными частями сервиса безопасности (FDP_ITT.1.1);
  • защита остаточной информации (FDP_RIP.2.1). Для всех объектов должна обеспечиваться полная защита остаточной информации, то есть недоступность предыдущего состояния при освобождении ресурса.


Необходимость идентификации и аутентификации пользователей сервисов безопасности (класс FIA) стала следствием общего требования подотчетности:

  • отказы аутентификации (FIA_AFL.1.2). При достижении определенного администратором числа неуспешных попыток аутентификации необходимо отказать субъекту в доступе, сгенерировать запись регистрационного журнала и сигнализировать администратору о вероятном нарушении безопасности;
  • определение атрибутов пользователя (FIA_ATD.1.1).


    Для каждого пользователя поддерживаются идентификатор, пароль и права доступа (роль). Кроме того, если используются криптографические операции, требуется поддержка открытых и секретных ключей;
  • идентификация (FIA_UID) и аутентификация (FIA_UAU) пользователя. Каждый пользователь должен быть успешно идентифицирован (FIA_UID.2.1) и аутентифицирован (FIA_UAU.2.1) до разрешения любого действия, выполняемого сервисом безопасности от его имени. Необходимо предотвращать применение аутентификационных данных, которые были подделаны или скопированы у другого пользователя (FIA_UAU.3). Следует аутентифицировать любой представленный идентификатор пользователя (FIA_UAU.5.2) и повторно аутентифицировать пользователя по истечении определенного администратором интервала времени (FIA_UAU.6.1). Функции безопасности должны предоставлять пользователю только скрытую обратную связь во время выполнения аутентификации (FIA_UAU.7);
  • связывание пользователь-субъект (FIA_USB.1.1). Соответствующие атрибуты безопасности пользователя нужно ассоциировать с субъектами, действующими от имени этого пользователя.


Управление - важнейший аспект информационной безопасности, а требования управления (класс FMT), несомненно, принадлежат к числу общих:

  • управление отдельными функциями безопасности (FMT_MOF.1.1). Только администратору позволяется определять режим функционирования, отключения, подключения, модифицировать режимы идентификации и аутентификации, управлять правами доступа, протоколирования и аудита;
  • управление атрибутами безопасности (FMT_MSA). Только администратору предоставляется право изменения подразумеваемых значений, а также опроса, изменения, удаления, создания атрибутов безопасности и правил управления потоками информации (FMT_MSA.1.1). Следует обеспечить присваивание атрибутам безопасности исключительно безопасных значений (FMT_MSA.2.1);
  • управление данными функций безопасности (FMT_MTD). Только администратор должен иметь возможность изменения подразумеваемых значений, опроса, изменения, удаления, очистки, определения типов регистрируемых событий, размеров регистрационных журналов, прав доступа субъектов, сроков действия учетных записей субъектов доступа, паролей, криптографических ключей (FMT_MTD.1.1).


    Только он определяет ограничения размеров регистрационных журналов, сроков действия учетных записей субъектов доступа, паролей, криптографических ключей, числа неудачных попыток аутентификации, интервалов бездействия пользователей (FMT_MTD.2.1). При выходе за допустимые границы должны выполняться установленные действия: передача уведомления администратору, блокирование или удаление учетной записи, запрос на смену пароля или ключа и т.д. (FMT_MTD.2.2). Следует обеспечить присваивание данным функциям лишь безопасных значений (FMT_MTD.3.1);
  • отмена (FMT_REV.1). Только уполномоченным администраторам разрешено выполнять отмену атрибутов безопасности, ассоциированных с пользователями. Важные для безопасности полномочия должны отменяться немедленно (FMT_REV.1.2);
  • роли управления безопасностью (FMT_SMR). Поддерживаются следующие роли: уполномоченный пользователь, удаленный пользователь, администратор (FMT_SMR.1.1). Получение ролей удаленного пользователя и администратора может производиться только по явному запросу (FMT_SMR.3.1).


Приватность (класс FPR) - специфический аспект информационной безопасности, однако требование открытости для уполномоченного пользователя носит общий характер:

  • скрытность (FPR_UNO). Администратору необходимо иметь возможность наблюдать за использованием ресурсов сервиса безопасности (FPR_UNO.4.1).


Собственная защищенность (класс FPT) - важная характеристика любого сервиса безопасности. В число общих входят следующие требования:

  • тестирование абстрактной машины (FPT_AMT.1). Для демонстрации выполнения предположений безопасности, обеспечиваемых абстрактной машиной, положенной в основу сервиса безопасности, при запуске и/или по запросу администратора выполняется пакет тестовых программ (FPT_AMT.1.1);
  • безопасность при сбое (FPT_FLS). Сервис должен сохранять безопасное состояние при аппаратных сбоях (вызванных, например, перебоями электропитания) (FPT_FLS.1.1);
  • целостность экспортируемых данных (FPT_ITI). Сервис предоставляет возможность верифицировать целостность всех данных в момент их передачи между ним и удаленным доверенным изделием ИТ, выполняет повторную передачу информации, а также генерирует запись регистрационного журнала, если модификации обнаружены (FPT_ITI.1.2);
  • надежное восстановление (FPT_RCV).


    Когда автоматическое восстановление после сбоя или прерывания обслуживания невозможно, следует обеспечить переход сервиса в режим аварийной поддержки, позволяющий вернуться к безопасному состоянию (FPT_RCV.2.1). После аппаратных сбоев требуется возврат к безопасному состоянию с использованием автоматических процедур (FPT_RCV.2.2);
  • обнаружение повторного использования (FPT_RPL). Сервис должен обнаруживать повторное использование аутентификационных данных (FPT_RPL.1.1), отказывать в доступе, генерировать запись регистрационного журнала и сигнализировать администратору о вероятном нарушении безопасности (FPT_RPL.1.2);
  • посредничество при обращениях (FPT_RVM). Функции, осуществляющие политику безопасности сервиса, вызываются и успешно выполняются прежде, чем разрешается выполнение любой другой функции сервиса (FPT_RVM.1.1). Компонент FPT_RVM.1 направлен на обеспечение невозможности обхода защитных средств;
  • разделение доменов (FPT_SEP). Функции безопасности должны поддерживать отдельный домен для собственного выполнения, который защищает их от вмешательства и искажения недоверенными субъектами (FPT_SEP.1.1);
  • метки времени (FPT_STM). Функциям безопасности нужно предоставлять надежные метки времени (FPT_STM.1.1);
  • согласованность данных между функциями безопасности (FPT_TDC). Необходима согласованная интерпретация регистрационной информации, а также параметров используемых криптографических операций (FPT_TDC.1.1);
  • согласованность перечисленных функций безопасности при дублировании в пределах объекта оценки (FPT_TRC). Должна обеспечиваться согласованность функций безопасности при дублировании их в различных частях объекта оценки (FPT_TRC.1.1). Когда части, содержащие дублируемые данные, разъединены, она выполняется после восстановления соединения перед обработкой `любых запросов к заданным функциям безопасности (FPT_TRC.1.2);
  • самотестирование функций безопасности (FPT_TST). Для демонстрации правильности работы функций безопасности в процессе нормального функционирования и/или по запросу администратора при запуске периодически должен выполняться пакет программ самотестирования (FPT_TST.1.1), а администратор верифицирует целостность данных (FPT_TST.1.2) и выполняемого кода функций безопасности (FPT_TST.1.3).




Требования класса FTA (доступ к объекту оценки) направлены на обеспечение защищенности от агрессивного потребления ресурсов:

  • ограничение на параллельные сеансы (FTA_MCS). Ограничение максимального числа параллельных сеансов, предоставляемых одному пользователю (FTA_MCS.1.1). У этой величины должно быть подразумеваемое значение, устанавливаемое администратором (FTA_MCS.1.2);
  • блокирование сеанса (FTA_SSL). По истечении установленного администратором значения длительности бездействия пользователя сеанс работы принудительно завершается (FTA_SSL.3.1);
  • открытие сеанса с объектом оценки (FTA_TSE). Сервис должен быть способен отказать в открытии сеанса, основываясь на идентификаторе субъекта, пароле субъекта, правах доступа субъекта (FTA_TSE.1.1).


Обеспечение защищенного взаимодействия сервисов безопасности в распределенной среде (класс FTP (доверенный маршрут/канал)) - одно из важнейших общих требований:

  • доверенный канал передачи между функциями безопасности (FTP_ITC). Для связи с удаленным доверенным изделием ИТ функции безопасности должны предоставлять канал, который логически отличим от других и обеспечивает надежную аутентификацию его сторон, а также защиту данных от модификации и раскрытия (FTP_ITC.1.1). Обеим сторонам необходимо иметь возможность инициирования связи через доверенный канал (FTP_ITC.1.2, FTP_ITC.1.3);
  • доверенный маршрут (FTP_TRP). Для связи с удаленным пользователем функции безопасности предоставляют маршрут, который логически отличим от других и обеспечивает надежную аутентификацию его сторон, а также защиту данных от модификации и раскрытия (FTP_TRP.1.1). Пользователю позволяется инициировать связь через доверенный маршрут (FTP_TRP.1.2). Для начальной аутентификации удаленного пользователя и удаленного управления использование доверенного маршрута является обязательным (FTP_TRP.1.3).



Содержание раздела