учебники, программирование, основы, введение в,

 

Профили защиты, разработанные на основе "Общих критериев". Часть 1. Общие требования к сервисам безопасности

Общие положения
Мы приступаем к анализу профилей защиты и их проектов, построенных на основе "Общих критериев" и описывающих сервисы безопасности, их комбинации и приложения. В первой части выделяются общие требования, которые могут войти в состав применимого ко всем сервисам функционального пакета, упрощающего разработку и понимание профилей для конкретных сервисов. Анализ профилей защиты позволяет оценить сильные и слабые стороны "Общих критериев", наметить возможные направления новых исследований.
"Общие критерии" в применении к оценке безопасности изделий информационных технологий (ИТ) являются, по сути, метасредствами, задающими систему понятий, в терминах которых должна производиться оценка, но не предоставляющих конкретных наборов требований и критериев, подлежащих обязательной проверке. Эти требования и критерии фигурируют в профилях защиты (ПЗ) и заданиях по безопасности (ЗБ) (см., например,  [GTKRRPP]).
Профили защиты, в отличие от заданий по безопасности, носят универсальный характер: они характеризуют определенный класс изделий ИТ вне зависимости от специфики условий применения. Именно официально принятые профили защиты образуют построенную на основе "Общих критериев" (ОК) и используемую на практике нормативную базу в области информационной безопасности (ИБ).
В настоящее время такая база и в мире (см., например, , ), и в России только создается. В нашей стране эту работу курирует Государственная техническая комиссия при Президенте РФ (Гостехкомиссия России).
Профили защиты могут характеризовать отдельные сервисы безопасности, комбинации подобных сервисов, реализованные, например, в операционной системе, а также прикладные изделия ИТ, для которых обеспечение информационной безопасности критически важно (пример - смарт-карты).
Нас в первую очередь будут интересовать профили защиты сервисов безопасности, поскольку последние являются универсальными строительными блоками, позволяющими формировать защитные рубежи информационных систем (ИС) различного назначения, разной степени критичности. В курсе["Основы информационной безопасности" выделены следующие базовые сервисы безопасности:

  • идентификация и аутентификация;
  • управление доступом;
  • протоколирование и аудит;
  • шифрование;
  • контроль целостности;
  • экранирование;
  • анализ защищенности;
  • обеспечение отказоустойчивости;
  • обеспечение безопасного восстановления;
  • туннелирование;
  • управление.

В силу разных причин не для всех перечисленных сервисов профили защиты разработаны или разрабатываются. Так, традиционные протоколирование и аудит, отказоустойчивость и безопасное восстановление адекватно описываются соответствующими классами функциональных требований "Общих критериев", поэтому формировать на их основе привычные классы защищенности относительно несложно (однако сделать это, разумеется, все же необходимо).
Выделение сервисов туннелирования и управления еще не вошло в общепринятую практику, поэтому пока они обойдены вниманием разработчиков ПЗ.
Наконец, криптография во многих странах (да и в самих "Общих критериях") является "особой точкой" безопасности, поэтому создание профилей защиты для сервисов шифрования и контроля целостности, а также для других сервисов, реализация которых опирается на криптографические механизмы, затруднено по законодательным и/или организационным причинам. (Заметим, что, хотя сложившееся вокруг компьютерной криптографии положение можно объяснить, его никак нельзя признать нормальным.)
Если придерживаться объектно-ориентированного подхода (см., например, курс, а также книгу ), то целесообразно выделить по крайней мере два уровня в иерархии наследования требований к сервисам безопасности:

  • общие требования, применимые ко всем или многим сервисам;
  • частные требования, специфичные для конкретного сервиса.

С точки зрения технологии программирования, "Общие критерии" построены по дообъектной, "библиотечной" методологии. Они предоставляют параметризованные функциональные требования, но не содержат необходимые для практического применения комбинации таких требований или универсальные интерфейсы, допускающие конкретизацию в контексте различных сервисов. Тем не менее, мы попытаемся выделить из разных профилей общие требования к сервисам безопасности, поскольку это упростит охват и понимание всей системы имеющихся профилей защиты.
При изложении общих и частных требований к сервисам безопасности, их комбинациям и приложениям мы будем следовать стандартной структуре профилей защиты (см. выше описание класса требований доверия APE), обращая особое внимание на интересующие нас аспекты:

  • предположения безопасности;
  • угрозы безопасности;
  • политика безопасности;
  • цели безопасности для объекта оценки;
  • цели безопасности для среды;
  • функциональные требования безопасности;
  • требования доверия безопасности.

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

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

 

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

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

Общие элементы политики и цели безопасности
Сформулируем общие положения политики безопасности организации, относящиеся к защитным сервисам:

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

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

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

Цели безопасности для среды дополняют цели безопасности объекта оценки и состоят в следующем:

  • обеспечение минимальной достаточности аппаратной и программной конфигурации вычислительной установки, на которой функционирует сервис безопасности;
  • управление физическим доступом к компонентам и ресурсам сервиса;
  • обеспечение невозможности обхода защитных средств;
  • обеспечение достаточной подготовки уполномоченных пользователей сервиса безопасности;
  • проведение в жизнь политики управления данными аутентификации: пользователи меняют эти данные должным образом и с требуемой регулярностью;
  • ликвидация данных аутентификации и привилегий пользователей, лишенных доступа к сервису безопасности;
  • разработка и реализация процедур и механизмов, предохраняющих от вторжения вредоносного программного обеспечения (ПО);
  • разработка и реализация дисциплины доклада о нарушениях информационной безопасности;
  • подготовка пользователей и обслуживающего персонала для противостояния методам морально-психологического воздействия;
  • оперативная ликвидация выявленных уязвимостей.

Общие функциональные требования
Для различных сервисов безопасности общими являются функциональные требования, связанные с идентификацией и аутентификацией, управлением доступом, протоколированием и аудитом, а также обеспечением высокой доступности. Далее эти требования разбиты в соответствии с иерархией, принятой в "Общих критериях".
Для сервисов безопасности предусмотрены общие требования по протоколированию и аудиту (класс 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).

Общие требования доверия безопасности
Требования доверия безопасности, по сравнению с функциональными, представляются более проработанными, поскольку для них определены оценочные уровни доверия (ОУД).
Для большинства областей применения достаточно третьего уровня доверия, но поскольку он достижим при разумных затратах на разработку, его можно считать типовым.
В число требований доверия третьего оценочного уровня входят:

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

В принципе реален и четвертый оценочный уровень, который можно рекомендовать для конфигураций повышенной защищенности. К числу дополнительных требований этого уровня относятся:

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

Вероятно, это самый высокий уровень, который можно достичь при существующей технологии программирования и разумных затратах материальных и временных ресурсов.
Мы завершаем изложение общих требований к сервисам безопасности. На наш взгляд, знакомство с ними необходимо для усвоения и последующего практического использования "Общих критериев".

 

 
На главную | Содержание | < Назад....Вперёд >
С вопросами и предложениями можно обращаться по nicivas@bk.ru. 2013 г.Яндекс.Метрика