Опишите какие ограничения имеет стандарт «Общие критерии».

Стандарт ISO/IEC 15408-1999 “Common Criteria for Information Technology Security Evaluation” был разработан совместными усилиями специалистов Канады, США, Великобритании, Германии, Нидерландов и Франции в период с 1990 по 1999 год, развитие стандарта непрерывно продолжается. Исторически за стандартом закрепилось разговорное название “Common Criteria” – «Общие критерии».

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

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

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

2. Вопросы защиты информации от утечки по техническим каналам, такие как контроль ПЭМИН, непосредственно не затрагиваются, хотя многие концепции ОК потенциально применимы и в данной области.

3. В ОК не рассматриваются ни методология оценки, ни административно- правовая структура, в рамках которой критерии могут применяться органами оценки.

4. Процедуры использования результатов оценки при аттестации продуктов и систем находятся вне области действия ОК.

5. В ОК не входят критерии оценки специфических свойств криптографических алгоритмов. Независимая оценка математических свойств криптографических компонентов, встроенных в ОО, должна проводиться как самостоятельная независимая процедура

 

СОКРАЩЕНИЯ:

ПЗ – профиль защиты

ОО – объект оценки

ИТ – информационные технологии

ЗБ – задание по безопасности

ОК – общие критерии

 

36. Приведите структуру и содержание профиля защиты в информационной системе.

Профиль защиты – не зависящая от конкретной реализации совокупность требований ИТ для некоторой категории ОО. ПЗ не привязан к конкретному ОО и представляет собой обобщённый стандартный набор функциональных требований и требований доверия для определённого класса продуктов или систем.

Введение ПЗ должно содержать информацию управления документооборотом и обзорную информацию, необходимые для работы с реестром ПЗ:

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

- аннотация ПЗ должна дать общую характеристику ПЗ в описательной форме.

Описание ОО служит цели лучшего понимания его требований безопасности и даёт представление о типе продукта и основных характерных особенностях ИТ

применительно к ОО.

Изложение среды безопасности ОО должно содержать описание аспектов безопасности среды, в которой предполагается использовать ОО, и ожидаемый способ его применения. Это изложение должно включать: 1. Описание предположений, содержащее аспекты безопасности среды, в которой ОО будет использоваться или предполагается к использованию. 2. Описание угроз, включающее все те угрозы активам, против которых требуется защита средствами ОО или его среды. 3. Описание политики безопасности организации, идентифицирующее и, при необходимости, объясняющее все положения политики безопасности организации или правила, которым должен подчиняться объект оценки.

Изложение целей безопасности должно определять цели безопасности как для ОО, так и для его среды. Цели безопасности для ОО должны быть четко изложены и сопоставлены с аспектами установленных угроз, которым необходимо противостоять средствами ОО, или с политикой безопасности организации, которой должен отвечать ОО. Цели безопасности для среды ОО должны быть четко изложены и сопоставлены с аспектами установленных угроз, которым не полностью противостоит ОО, или с политикой безопасности организации и предположениями, не полностью удовлетворяемыми ОО.

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

Раздел ПЗ Замечания по применению является необязательным и может содержать дополнительную информацию, которая считается уместной или полезной для создания, оценки и использования ОО.

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

 

 

37. Приведите структуру и содержание задания по безопасности.

ЗБ – документ, содержащий требования безопасности для конкретного ОО и специфицирующий функции безопасности и меры доверия, предлагаемые объектом оценки для выполнения установленных требований. В ЗБ может быть заявлено соответствие одному или нескольким профилям защиты.

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

В утверждение о соответствии ПЗ включаются материалы, необходимые для подтверждения факта соответствия.

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

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

требованиям доверия. Логическое обоснование утверждений о соответствии ПЗ объясняет любые

различия между целями и требованиями безопасности ЗБ и любого ПЗ, соответствие которому утверждается.

 

1. Опишите функциональные требования безопасности.

Функциональные требования – соответствуют активному аспекту защиты и предъявляются к функциям безопасности ОО и реализующим их механизмам. Функциональные требования разбиты на 11 классов (в трёх группах), 66 семейств и 135 компонентов.

- Первая группа определяет элементарные сервисы безопасности: FAU — аудит, безопасность (требования к сервису, протоколирование и аудит); FIA — идентификация и аутентификация; FRU — использование ресурсов (для обеспечения отказоустойчивости).

- Вторая группа описывает производные сервисы, реализованные на базе элементарных: FCO — связь (безопасность коммуникаций отправитель-получатель); FPR — приватность; FDP — защита данных пользователя; FPT — защита функций безопасности объекта оценки.

- Третья группа классов связана с инфраструктурой объекта оценки: FCS — криптографическая поддержка (обслуживает управление криптоключами и крипто-операциями); FMT — управление безопасностью; FTA — доступ к объекту оценки (управление сеансами работы пользователей); FTP — доверенный маршрут/канал.

 

1. Опишите структуру функционального компонента и идентификацию компонента.

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

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

Функциональный элемент – это наименьшее функциональное требование безопасности, идентифицируемое и признаваемое в ОК. Вводится уникальная краткая форма имени функционального элемента.

Например, имя FDP_IFF.4.2 читается следующим образом: F – функциональное требование, DP – класс «Защита данных пользователя», IFF – семейство «Функции управления информационными потоками»,.4 – четвертый компонент «Частичное устранение неразрешенных информационных потоков», 2 – второй элемент компонента.

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

 

1. Понятие информационной безопасности (ИБ). Основные составляющие. Важность и сложность проблемы ИБ.

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

 

 

41 Объектно-ориентированный подход (ООП) на ИБ и показать его необходимость на примере структурного программирования.

Структурный подход опирается на алгоритмическую декомпозицию, когда выделяются функциональные элементы системы. Основная проблема структурного подхода состоит в том, что он неприменим на ранних этапах анализа и моделирования предметной области, когда до алгоритмов и функций дело еще не дошло. Нужен подход "широкого спектра", не имеющий такого концептуального разрыва с анализируемыми системами и применимый на всех этапах разработки и реализации сложных систем. ООП удовлетворяет таким требованиям. ООП использует объектную декомпозицию, то есть поведение системы описывается в терминах взаимодействия объектов. Класс - это абстракция множества сущностей реального мира, объединенных общностью структуры и поведения. Объект - это элемент класса, то есть абстракция определенной сущности. Объекты активны, у них есть не только внутренняя структура, но и поведение, которое описывается так называемыми методами объекта. Основным инструментом борьбы со сложностью в ООП-е является инкапсуляция - сокрытие реализации объектов (их внутренней структуры и деталей реализации методов) с предоставлением во вне только строго определенных интерфейсов. Понятие " полиморфизм " может трактоваться как способность объекта принадлежать более чем одному классу. Введение этого понятия отражает необходимость смотреть на объекты под разными углами зрения, выделять при построении абстракций разные аспекты сущностей моделируемой предметной области, не нарушая при этом целостности объекта. Наследование означает построение новых классов на основе существующих с возможностью добавления или переопределения данных и методов. Наследование является важным инструментом борьбы с размножением сущностей без необходимости. Общая информация не дублируется, указывается только то, что меняется. При этом класс - потомок помнит о своих "корнях". 3 основных граней ИБ - доступность, целостность и конфиденциальность. Понятие уровня детализации важно не только для визуализации объектов, но и для систематического рассмотрения сложных систем, представленных в иерархическом виде. Само по себе оно очень простое: если очередной уровень иерархии рассматривается с уровнем детализации n > 0, то следующий - с уровнем (n - 1). Объект с уровнем детализации 0 считается атомарным. Неформально компонент можно определить как многократно используемый объект, допускающий обработку в графическом инструментальном окружении и сохранение в долговременной памяти. Контейнеры могут включать в себя множество компонентов, образуя общий контекст взаимодействия с другими компонентами и с окружением. Контейнеры могут выступать в роли компонентов других контейнеров.

 

42 Применение ООП (объектно-ориентированного подхода) к рассмотрению защищаемых систем.

Продемонстрируем теперь, как можно рассматривать защищаемую ИС, варьируя уровень детализации.

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

При взгляде с нулевым уровнем детализации мы увидим лишь то, что у организации есть информационная система

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

На втором уровне констатируется только существование связи между сетями, наличие в них пользователей, а также предоставляемых и внутренних сервисов. Находясь на уровне детализации 2, мы должны учитывать законы, применимые к организациям, ИС которых снабжены внешними подключениями. Речь идет о допустимости такого подключения, о его защите, об ответственности пользователей, обращающихся к внешним сервисам, и об ответственности организаций, открывающих свои сервисы для внешнего доступа. Обратим внимание на то, что контейнер "ИС организации" задает границы контролируемой зоны, в пределах которых организация проводит определенную политику. Internet живет по другим правилам, которые организация должна принимать, как данность. Увеличивая уровень детализации, можно разглядеть две разнесенные производственные площадки и каналы связи между ними, распределение сервисов и пользователей по этим площадкам и средства обеспечения безопасности внутренних коммуникаций, специфику отдельных сервисов, разные категории пользователей и т.п.

43 Основные определения и критерии классификации угроз. Анализ угроз ИБ автоматизированных систем (АС).

Угроза - это потенциальная возможность определенным образом нарушить информационную безопасность.

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

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