Обеспечение безопасности сетей электросвязи

Обеспечение безопасности сетей электросвязи

Общие положения и терминология

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

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

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

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

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

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

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

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

Сеть связи — технологическая система, включающая в себя средства и линии связи и предназначенная для электросвязи(информация в любом виде) или почтовой связи..

Контрольные вопросы и задания

1. Что понимается под безопасностью сети электросвязи?

2. Приведите пример дестабилизирующего воздействия на сеть электросвязи.

3. В чем разница между понятиями « безопасность сети электросвязи»и « устойчивость функционирования сети электросвязи»?

4. Определите соотношение между понятиями «меры обеспечения безопасности» « механизмы обеспечения безопасности».

5. Отличается ли понимание термина «риск нарушения безопасности сети электросвязи» от понимания термина «риск», выраженного в ГОСТ Р 51898 «Аспекты безопасности. Правила включения в стандарты»?

6. Проведите сопоставительный анализ определений терминов «угроза безопасности сети электросвязи» и «угроза» (в трактовке ГОСТ Р ИСО/МЭК 13335-1 ), а также «уязвимость сети электросвязи» и «уязвимость» (также в трактовке ГОСТ Р ИСО/МЭК 13335-1) на предмет выявления существенных различий.

Основные понятия и идеи Общих Критериев

Общие Критерии содержат два основных вида требований безопасности:

– функциональные требования, соответствующие активному аспекту защиты, предъявляемые к функциям безопасности и реализующим их механизмам;

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

Требования безопасности формулируются и их выполнение проверяется для определенного объекта оценки (ОО) аппаратно-программного продукта ИТ или системы ИТ.

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

– профиля защиты (ПЗ);

– задания по безопасности (ЗБ).

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

Задания по безопасности содержат совокупность требований к конкретной разработке продукта или системы.

Системой ИТ называется специфичная реализация ИТ с конкретным назначением и условиями эксплуатации.

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

Продукт или система могут быть уже существующими либо проектируемыми.

В среду безопасности ОО включаются:

– законодательная среда (нормативные акты, затрагивающие ОО);

– административная среда (положения политик и программ безопасности, учитывающих особенности ОО);

– процедурная среда (физическая среда ОО и меры его физической защиты, персонал и его свойства, принятые эксплуатационные и иные процедуры);

– программно-техническая среда (предназначение ОО и предполагаемые области его применения, активы (ресурсы), которые требуют защиты средствами ОО).

Из анализа среды безопасности должны быть описаны следующие аспекты:

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

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

- источник;

- метод воздействия;

- опасные с точки зрения закономерности использования уязвимости;

- активы, потенциально подверженные повреждению.

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

3) положения политики безопасности, предназначенные для применения к ОО. Для системы ИТ такие положения могут быть описаны точно, для продукта ИТ — в общих чертах.

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

ОК, а именно их вторая и третья части, являются каталогами требований безопасности.

В основу методологии ОК положена модель безопасности, представленная на рисунке 2.

 

Рисунок 2 - Модель безопасности, положенная в основу методологии ОК

Для структуризации пространственных требований в ОК введена иерархия класс – семейство – компонент - элемент.

Классы определяют наиболее общую группировку требований.

Семейства в пределах класса различаются по строгости и другим характеристикам требований.

Компонент определяется минимальным набором требований, фигурирующим как единое целое.

Элемент — это неделимое требование безопасности.

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

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

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

ПЗ включает в себя следующие разделы:

– введение, состоящее из разделов идентификации ПЗ и аннотации ПЗ;

– описание ОО;

– среда безопасности ОО, состоящая из подразделов предположений безопасности, угрозы, политики безопасности организации;

– цели безопасности, состоящие из подразделов целей безопасности для ОО и целей безопасности для среды;

– требования безопасности ИТ, состоящие из требований безопасности для ОО, включая функциональные требования безопасности ОО, требований доверия безопасности к ОО и требований безопасности для среды ИТ;

– замечания по применению и обоснование, состоящее из подразделов логического обоснования требований безопасности и логического обоснования целей безопасности.

Состав ЗБ отличается наличием двух разделов и нескольких подразделов. Дополнительно в ЗБ имеются следующие разделы:

– краткая спецификация ОО, состоящая из функций безопасности ОО и спецификации мер доверия;

– утверждение соответствия ПЗ, в котором приводится ссылка на ПЗ, конкретизация ПЗ и дополнение ПЗ.

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

Краткая спецификация определяет отображение требований на функции безопасности.

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

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

При проведении оценки главными являются следующие вопросы:

1) отвечают ли функции безопасности ОО функциональным требованиям?

2) конкретна ли реализация функций безопасности?

Если оба ответа положительны, то говорят о достижении целей безопасности.

Контрольные вопросы

1. Опишите алгоритм формирования требований безопасности, используемый в Общих критериях.

2. Можно ли при создании безопасных систем информационных технологий в соответствии с подходами Общих критериев использовать алгоритм создания автоматизированной системы, предписываемый ГОСТ 34.601 «Автоматизированные системы. Стадии создания»?

3. Каков состав задания по безопасности и чем он отличается от состава профиля защиты?

4. Какими параметрами характеризуется в Общих критериях угроза безопасности объекта оценки?

5. Из каких сущностей (класс, семейство, компонент или элемент) формируются профиль защиты и задание по безопасности?

6. Почему для системы ИТ положения политики безопасности могут быть описаны при ее создании точно, а для продукта ИТ — только в общих чертах?

17 Классификация функциональных требований безопасности

Часть вторая ОК описывает 11 классов, 66 семейств, 135 компонентов функциональных требований безопасности и содержит сведения о том, какие цели безопасности могут быть достигнуты при современном уровне ИТ и каким образом. Функциональные компоненты могут быть не до конца конкретизированы в ОК, поэтому фактические параметры подставляются в ПЗ и ЗБ. Такая операция называется назначением. В качестве параметров могут выступать, например, такие сложные сущности, как политика безопасности.

Некоторые компоненты в ОК задаются с «запросом». В них включается список возможностей, из которых потом осуществляется выбор той, что необходима в конкретной ситуации, например, обнаружение и/или предотвращение определенных нарушений политики безопасности.

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

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

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

К первой группе можно отнести следующие классы:

– FAU - аудит безопасности;

– FIA - идентификация и аутентификация;

– FRU - использование ресурсов.

Класс FAU состоит из 6 семейств, содержащих требования к отбору, регистрации, хранению и анализу данных о действиях и событиях, затрагивающих безопасность объекта оценки. Класс FIA состоит из 6 семейств, содержащих требования к идентификации пользователя, к аутентификации пользователей, определению атрибутов пользователя, к связыванию пользователя с субъектом, к отказам аутентификации и к спецификации секретов. Класс FRU включает 3 семейства, призванные разными способами поддерживать высокую доступность: отказоустойчивость, приоритет обслуживания и распределение ресурсов.

Ко второй группе можно отнести следующие классы:

– FCO – связь;

– FPR — приватность.

Класс FCO состоит из 2 семейств, обеспечивающих неотказуемость отправки или получения данных, которая достигается путем избирательной или принудительной генерации, допускающих верификацию свидетельств, позволяющих ассоциировать атрибуты отправителя (получателя) с элементами передаваемых данных. Класс FPR содержит 4 семейства, обеспечивающих защиту пользователя от раскрытия и несанкционированного использования его идентификационных данных: анонимность, псевдонимность, невозможность ассоциаций и скрытность.

Достичь высокоуровневых целей безопасности помогают два класса:

– FDP — защита данных пользователя;

– FPT — защита функций безопасности ОО.

Класс FDP включает 13 семейств, которые можно разбить на четыре группы:

– политики защиты данных пользователя;

– виды защиты данных пользователя;

– импорт и экспорт данных пользователя;

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

Класс FPT включает 16 семейств, которые можно условно разделить на четыре группы:

– архитектурная безопасность;

– защита реализаций функций безопасности;

– защита данных функций безопасности;

– инфраструктурные требования.

Наибольшее число компонентов сосредоточено в классах инфраструктурной группы:

– FCS — криптографическая поддержка;

– FMT — управление безопасностью;

– FTA — доступ к ОО;

– FTP — доверенный маршрут/канал.

Класс FCS состоит из двух семейств, где в самом общем виде (в виде параметризованных шаблонов) рассматриваются генерация, распределение, доступ и уничтожение ключей, а также криптографические операции. Смысл требований состоит в том, что необходимо действовать в соответствии с некими алгоритмами, длинами ключей и стандартами. Какие-либо содержательные специфики отсутствуют. Класс FMT, включающий шесть семейств, регламентирует управление функциями безопасности и их данными, атрибутами и ролями безопасности. Класс FTA содержит шесть семейств, куда вошли требования управления сеансами работы пользователей (помимо идентификации и аутентификации). Класс FTP, состоящий из двух семейств: «доверенный маршрут» и «доверенный канал» – обеспечивает требования по созданию маршрутов/каналов передачи информации безопасным образом.

Контрольные вопросы

1. На базе каких элементарных сервисов безопасности первой группы классов функциональных требований могут быть реализованы требования второй группы функциональных требований класса FCO?

2. Чем отличается доверенный маршрут от доверенного канала?

3. Почему требования класса FTA отнесены условно к инфраструктурной группе?

4. Обеспечивает ли реализация требований класса FPR абсолютную неподотчетность действий пользователя в системе?

 

15 Пример описания функциональных требований

Рассмотрим описание класса, семейства, компонента и элементов требований на примере класса FCO «Связь».

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

Декомпозиция класса на составляющие его компоненты показана на рисунке 3

Рисунок 3 – Декомпозиция класса FCO «Связь»

Семейство FCO_NRO «Неотказуемость отправления» обеспечивает невозможность отрицания отправителем информации факта ее отправления. Семейство FCO_NRO содержит требование, чтобы функции безопасности объекта оценки обеспечили метод предоставления субъекту-получателю свидетельства отправления информации. Это свидетельство может быть затем верифицировано этим субъектом или другими субъектами.

Ранжирование компонентов показано на рисунке 4

Рисунок 4 - Ранжирование компонентов семейства FCO_NRO

FCO_NRO.1 «Избирательное доказательство отправления» содержит требование, чтобы функции безопасности объекта оценки предоставили субъектам возможность запросить свидетельство отправления информации.

FCO_NRO.2 «Принудительное доказательство отправления» содержит требование, чтобы функции безопасности объекта оценки всегда генерировали свидетельство отправления передаваемой информации.

Управление: FCO_NRO.1, FCO_NRO.2

Для функций управления из класса FMT может рассматриваться следующее действие.

а) Управление изменениями типов и полей информации, атрибутов отправителей информации и получателей свидетельств.

Аудит: FCO_NRO.1

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

а) Минимальный: идентификатор пользователя, который запросил генерацию свидетельства отправления.

б) Минимальный: обращение к функции неотказуемости.

в) Базовый: идентификатор информации, получателя и копии предоставляемого свидетельства.

г) Детализированный: идентификатор пользователя, который запросил верификацию свидетельства.

Аудит: FCO_NRO.2

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

а) Минимальный: обращение к функции неотказуемости.

б) Базовый: идентификация информации, получателя и копии предоставляемого свидетельства.

в) Детализированный: идентификатор пользователя, который запросил верификацию свидетельства.

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

Иерархический для FCO_NRO.1: нет подчиненных компонентов.

Элементы компонента FCO_NRO.1 описаны ниже.

FCO_NRO.1.1 ФБО должны быть способны генерировать свидетельство отправления передаваемой [назначение: список типов информации ]при запросе [выбор: отправитель, получатель, [назначение: список третьих лиц] ].

FCO_NRO.1.2 ФБО должны быть способны связать [назначение: список атрибутов ]отправителя информации и [назначение: список информационных полей ] информации, к которой прилагается свидетельство.

FCO_NRO.1.3 ФБО должны предоставить возможность верифицировать свидетельство отправления информации [выбор: отправитель, получатель, [назначение: список третьих лиц] ]при установленных [назначение: ограничения на свидетельство отправления ]

Зависимости: FIA_UID.1 Выбор момента идентификации

Выбор и назначение – здесь операции которые возможно проводить над элементами требований при их описании в профиле защиты или задании по безопасности для типов или конкретных объектов оценки.

Контрольные вопросы

1. Почему без компонента FIA_UID.1 «Выбор момента идентификации» компонент FCO_NRO.1 является несамодостаточным и не может обеспечить выполнение соответствующих целей безопасности?

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

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

13 Основные понятия и классификация требований доверия безопасности

Доверие в интерпретации ОК — это основа для уверенности в том, что продукт или система ИТ отвечают целям безопасности. Доверие обеспечивается через активные исследования (оценку) продукта или системы.

Требования доверия безопасности охватывают весь жизненный цикл ОО и предполагают выполнение следующих действий:

– оцениваются ЗБ и ПЗ, как источники требований безопасности;

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

– проверяются процессы и процедуры безопасности, их применение, анализируется документация, верифицируются представленные доказательства;

– анализируются тесты и их результаты, а также уязвимости ОО;

– проводится независимое тестирование, в том числе тестирование проникновением.

Каждое требование (элемент) доверия принадлежит одному из трех типов:

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

– элементы представления и содержания свидетельств (помечаются буквой S);

– элементы действия оценщика (помечаются буквой Е).

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

Требования доверия разделены на 10 классов, 44 семейства, 93 компонента. Классы можно сгруппировать в зависимости от охватываемых этапов жизненного цикла ОО.

К первой группе, логически предшествующей разработке и оценке ОО, принадлежат классы:

– APE — оценка ПЗ;

– ASE — оценка ЗБ.

Цель требований классов APE и ASE - проверить полноту, непротиворечивость и реализуемость профиля защиты или задания по безопасности.

Во вторую группу входят классы:

– ADV — разработка;

– ALC — поддержка жизненного цикла;

– ACM — управление конфигурацией.

Класс ADV (разработка) состоит из семи семейств и содержит требования для постепенного повышения уровня детализации проекта вплоть до представления реализаций с демонстрацией соответствия между уровнями. В этом классе предусмотрено три стиля изложения спецификации: неформальный, полуформальный и формальный – и три способа демонстрации соответствия. Технологические требования процедурного характера составляют содержание класса ALC (поддержка жизненного цикла), состоящего из четырех семейств. Прежде всего, определяется модель жизненного цикла (семейство ALC_LCD), затем следует обосновать выбор инструментальных средств и методов (семейство ALC_TAD). Безопасность разработки организуется в соответствии с требованиями семейства ALC_DVC. Важнейшим элементом этапа сопровождения является устранение недостатков (семейство ALC_FLR). Управление конфигурацией (класс ACM) - необходимый инструмент коллектива разработчиков. В этот класс входят три семейства, самое содержательное из которых ACM_CAB, специфицирующее возможности управления конфигурацией. Семейство ACM_SCP специфицирует область действия управления конфигурацией. Для уменьшения числа возможных ошибок управление конфигурацией следует максимально автоматизировать. В этом состоит смысл требований семейства ACM_AOT.

К этапу получения, представления и анализа результатов разработки можно отнести классы:

– AGD — руководство пользователя, администратора;

– ATE — тестирование;

– AVA — оценка уязвимостей.

Класс AGD состоит из двух семейств, где сформулированы требования к руководствам администратора (AGD_ADM) и пользователя (AGD_USR). Класс ATE состоит из четырех семейств, содержащих требования к полноте, глубине, способам и результатам тестирования функций безопасности на предмет их соответствия спецификациям. Один из ключевых моментов оценки безопасности продуктов информационных технологий – это оценка уязвимостей (класс AVA), отправным пунктом которой является анализ уязвимостей (семейство AVA_VLA), выполняемый разработчиком и оценщиком. Анализ стойкости функций безопасности объекта оценки (семейство AVA_SOF) проводится на уровне реализующих механизмов. Требования семейства AVA_MSV (неправильное применение) направлено на то, чтобы исключить возможность такого конфигурирования и (или) применения объекта оценки, которое администратор или пользователь считает безопасным, в то время как оно таковым не является. Анализ скрытых каналов, регламентируемый семейством AVA_CCA, требует, чтобы разработчик проводил исчерпывающий поиск скрытых каналов для каждой политики управления информационными потоками и предоставлял документацию анализа, а оценщик должен выборочно подтвердить правильность анализа скрытых каналов посредством тестирования.

Класс ADO (поставка и эксплуатация) содержит требования к процедурам поставки, установки, генерации и запуска объекта оценки.

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

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

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

– расширение границ ОО;

– увеличение уровня детализации рассматриваемых аспектов ОО;

– повышение строгости рассмотрения и применения более формальных методов верификации.

Контрольные вопросы

1. Реализация требований доверия увеличивает защищенность объекта оценки или повышает уверенность в его защищенности у оценщика и потребителя?

2. Раскройте смысл понятия «скрытый канал» и поясните, могут ли они оставаться в действующем объекте оценки, если разработчик осуществлял их поиск в процессе разработки объекта оценки?

3. Позволяет ли применение требований класса АМА избежать переоценки действующего сертифицированного ранее объекта оценки?

Рекомендация ITU-T X.1051.Процессный подход и модель СМИБ телекоммуникаций

(Процессный подход и модель систем менеджмента информационной безопасности телекоммуникаций)

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

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

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

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

Часто выходные данные одного процесса непосредственно образуют входные данные следующего процесса.

Применение системы процессов внутри организации совместно с идентификацией и взаимодействием этих процессов, а также управлением ими может быть названо "подходом, основанным на процессах".

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

– понимания требований бизнеса к информационной безопасности и необходимости установления политики и целей информационной безопасности;

– реализации и эксплуатации средств управления с точки зрения управления всеми рисками бизнеса организации;

– контроля и анализа рабочих характеристик и эффективности СМИБ;

– постоянного совершенствования, основанного на объективных измерениях.

Модель, известная как модель "Планирование-Работа-Проверка-Действие" (PDCA), может быть применима ко всем процессам СМИБ. На рисунке 3 показано, как использовать СМИБ для введения требований к ИБ и ожиданий организаций электросвязи и заинтересованных сторон, связанных со сферой электросвязи, и как путем необходимых действий и процессов создать выходные продукты информационной безопасности (т. е. управляемую информационную безопасность), которые соответствуют этим требованиям и ожиданиям.

Рисунок 3 - Модель СМИБ

Планирование и установление СМИБ создает политику безопасности, цели, задачи, процессы и процедуры, соответствующие управляемым рискам и улучшенной информационной безопасности, для представления результатов в соответствии с общей политикой и целями организации.

Осуществление, реализация и эксплуатация СМИБ реализует и применяет политику безопасности, средства управления, процессы и процедуры.

Проверка, мониторинг и анализ СМИБ — оценка и, где это применимо, измерение рабочих характеристик процесса, относящегося к политике, целям безопасности и практическому опыту, и представление отчета о результатах в систему управления для анализа.

Действия, поддержка и усовершенствование СМИБ — принятие корректирующих и превентивных действий, основанных на результатах анализа руководством, для достижения непрерывных усовершенствований СМИБ.

Контрольные вопросы

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

2. Как реализуется рабочий цикл модели СМИБ: однократно, регулярно через определенные интервалы времени или циклически непрерывно?

3. Что такое управляемая информационная безопасность?

4. Для функционирования СМИБ необходимо чтобы вся деятельность организации электросвязи была формализована на основе процессного подхода или только деятельность по управлению ИБ?

Рекомендация ITU-T X.1051.Процессы СМИБ

(Процессы системы менеджмента информационной безопасности)

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

Процессы СМИБ.

Создание СМИБ. Организация должна:

– определить область применения СМИБ;

– определить политику СМИБ;

– определить системный подход к определению риска;

– идентифицировать риски;

– количественно определить риски;

– идентифицировать и оценить варианты обработки рисков;

– выбрать цели управления и средства управления для обработки рисков;

– подготовить заявление о применимости;

– получить согласие руководства на предлагаемые остаточные риски и разрешение на реализацию и эксплуатацию СМИБ.

Реализация и эксплуатация СМИБ. Организация д