Представление класса

Основы информационной безопасности 90

указании различий между компонентами при принятии решения о том, что семейство

является необходимой или полезной частью требований доверия для ПЗ/ЗБ.

Необязательный подраздел «Замечания по применению» содержит

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

использования или областях, требующих особого внимания.

Структура компонента доверия приведена на рис. 3.4.6.2.

Подраздел «Идентификация компонента» содержит описательную информацию,

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

Каждому компоненту доверия присвоено уникальное имя. Имя содержит информацию о

тематических разделах, на которые распространяется компонент доверия. Каждый

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

безопасности.

Представлена также уникальная краткая форма имени компонента доверия как

основной способ ссылки на компонент. Принято, что за краткой формой имени семейства

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

назначены последовательно, начиная с единицы

Необязательный подраздел «Цели» компонента доверия содержит конкретные

цели этого компонента. Для компонентов доверия, которые имеют этот подраздел, он

включает в себя конкретное назначение данного компонента и подробное разъяснение

целей.

Необязательный подраздел «Замечания по применению» компонента доверия

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

Зависимости среди компонентов доверия возникают, когда компонент не

самодостаточен, а предполагает присутствие другого компонента. Для каждого

компонента доверия приведен полный список зависимостей от других компонентов

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

указано: "Нет зависимостей". Компоненты из списка, могут, в свою очередь, иметь

зависимости от других компонентов.

Список зависимостей определяет минимальный набор компонентов доверия, на

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

высокими по отношению к компоненту в списке зависимостей, также могут

использоваться для удовлетворения зависимости.

В отдельных ситуациях обозначенные зависимости могут быть неприменимы.

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

обоснование, почему данная зависимость неприменима.

Каждый компонент доверия содержит набор элементов доверия. Элемент доверия

Оценочный уровень доверия (ОУД) представляет собой рассчитанную на

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

одного компонента из каждого семейства доверия.

В стандарте определены 7 оценочных уровней доверия. С возрастанием

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

Оценочный уровень доверия 1 (ОУД1) предусматривает функциональное

тестирование. ОУД1 применим в тех случаях, когда требуется некоторая уверенность в

правильном функционировании ОО, а угрозы безопасности не рассматриваются как

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

утверждения о том, что было уделено должное внимание защите персональных данных

или подобной информации. Предполагается, что оценка ОУД1 может успешно

проводиться без помощи разработчика ОО и с минимальными затратами. Анализ

поддерживается независимым тестированием ФБО.

Оценочный уровень доверия 2 (ОУД2) предусматривает структурное

тестирование. ОУД2 содержит требование сотрудничества с разработчиком для

получения информации о проекте и результатах тестирования без существенного

увеличения стоимости или затрат времени. Анализ поддерживается независимым

тестированием ФБО, свидетельством разработчика об испытаниях, основанных на

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

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

разработчиком явных уязвимостей (например, из общедоступных источников).

Оценочный уровень доверия 3 (ОУД3) предусматривает методическое

тестирование и проверку. ОУД3 позволяет достичь максимального доверия путем

применения надлежащего проектирования безопасности без значительного изменения

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

всестороннего исследования ОО и процесса его разработки без существенных затрат на

изменение технологии проектирования. Анализ поддерживается независимым

тестированием ФБО, свидетельством разработчика об испытаниях, основанных на

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

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

и свидетельством поиска разработчиком явных уязвимостей (например, из

общедоступных источников).

Оценочный уровень доверия 4 (ОУД4) предусматривает методическое

проектирование, тестирование и просмотр. ОУД4 применим, когда разработчикам или

пользователям требуется независимо получаемый уровень доверия от умеренного до

высокого в ОО общего назначения и имеется готовность нести дополнительные,

связанные с безопасностью производственные затраты. Это самый высокий уровень, на

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

продуктов. Анализ поддерживается независимым тестированием ФБО, свидетельством

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

верхнего уровня, выборочным независимым подтверждением результатов тестирования

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

уязвимостей и независимым анализом уязвимостей, демонстрирующим противодействие

попыткам проникновения нарушителей с низким потенциалом нападения.

Оценочный уровень доверия 5 (ОУД5) предусматривает полуформальное

проектирование и тестирование. ОУД5 применим, когда разработчикам или

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

запланированной разработки со строгим подходом к разработке, не влекущим излишних

затрат на применение узко специализированных методов проектирования безопасности.

Тем самым, предполагается, что ОО будут проектироваться и разрабатываться с

намерением достичь ОУД5. Анализ поддерживается независимым тестированием ФБО,

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

спецификации, проекте верхнего уровня и проекте нижнего уровня, выборочным

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

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

анализом уязвимостей, демонстрирующим противодействие попыткам проникновения

нарушителей с умеренным потенциалом нападения. Анализ также включает проверку

правильности анализа разработчиком скрытых каналов.

Оценочный уровень доверия 6 (ОУД6) предусматривает полуформальную

верификацию проекта и тестирование. ОУД6 позволяет разработчикам достичь

высокого доверия путем применения специальных методов проектирования безопасности

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

для защиты высоко оцениваемых активов от значительных рисков. Анализ

поддерживается независимым тестированием ФБО, свидетельством разработчика об

испытаниях, основанных на функциональной спецификации, проекте верхнего уровня и

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

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

разработчиком уязвимостей и независимым анализом уязвимостей, демонстрирующим

противодействие попыткам проникновения нарушителей с высоким потенциалом

Основы информационной безопасности 98

нападения. Анализ также включает проверку правильности систематического анализа

разработчиком скрытых каналов.

Оценочный уровень доверия 7 (ОУД7) предусматривает формальную

верификацию проекта и тестирование. ОУД7 применим при разработке безопасных

ОО для использования в ситуациях чрезвычайно высокого риска и/или там, где высокая

ценность активов оправдывает более высокие затраты. Практическое применение ОУД7 в

настоящее время ограничено ОО, которые строго ориентированы на реализацию

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

формальный анализ. Анализ поддерживается u1085 независимым тестированием ФБО,

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

спецификации, проекте верхнего уровня, проекте нижнего уровня и представлении

реализации, полным независимым подтверждением результатов тестирования

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

уязвимостей и независимым анализом уязвимостей, демонстрирующим противодействие

попыткам проникновения нарушителей с высоким потенциалом нападения. Анализ также

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

каналов.

Сводное описание оценочных уровней доверия приведено в таблице 3.4.6.2. Все

уровни являются иерархически упорядоченными, и каждый ОУД представляет более

высокое доверие, чем любой из предыдущих. Увеличение доверия от ОУД к ОУД

достигается заменой какого-либо компонента доверия иерархически более высоким

компонентом из того же семейства доверия (т.е. увеличением строгости, области и/или

глубины оценки) и добавлением компонентов доверия из других семейств доверия (т.е.

добавлением новых требований).

Таблица 3.4.6.2. Сводное описание оценочных уровней доверия

Помимо заявленных в части 3 ОК ОУД, можно представлять другие комбинации

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

добавление компонентов доверия (из семейств доверия, до этого не включенных в ОУД)

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

компонентами доверия из того же самого семейства доверия. Исключение из ОУД какого-

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

производится усиление ОУД, необходимо строго обосновать полезность и

дополнительную ценность добавленного к ОУД компонента доверия. ОУД может быть

также расширен за счёт применения требований доверия, сформулированных в явном

виде.

47) Стандарты в области управления информационной безопасностью

Общие положения

При рассмотрении ограничений «Общих критериев» мы обращали внимание на то,

что они не затрагивают вопросов, касающихся администрирования механизмов

безопасности, непосредственно не относящихся к мерам безопасности информационных

технологий. Действительно, при построении системы управления информационной

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

отдельного рассмотрения.

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

являются документы, разработанные Британским институтом стандартов (BSI – British

Standards Institution). Стандарты BS 7799-1, BS 7799-2 и BS 7799-3 крайне популярны во

всём мире, первые два из них имеют международный статус стандартов ISO (последние

версии данных стандартов имеют обозначения ISO/IEC 17799:2005 и ISO/IEC 27001:2005

соответственно).

По сравнению с общими критериями, данные документы носят гораздо более

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

по развёртыванию и поддержанию системы управления информационной безопасностью.

Основы информационной безопасности 104

3.5.2. ISO/IEC 17799:2005

Стандарт ISO/IEC 17799:2005 “Information technology – Security techniques – Code

of practice for information security management” [41] (Информационные технологии.

Методы обеспечения безопасности. Практическое руководство по управлению

информационной безопасностью) представляет собой набор практических рекомендаций

по построению комплексной корпоративной системы управления информационной

безопасностью.

Согласно положениям стандарта, информационная безопасность рассматривается

как процесс защиты информационных активов организации от различного рода угроз,

который достигается путём реализации тех или иных сервисов безопасности1.

Требования к системе безопасности определяются по результатам предварительно

проведённого анализа рисков, исходя из требований нормативных и законодательных

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

таким образом, чтобы минимизировать идентифицированные u1080 информационные риски.

Именно каталог рекомендуемых сервисов безопасности и составляет основное

содержание стандарта. Сервисы сгруппированы по следующим тематическим разделам:

1. Политика безопасности.

2. Организация информационной безопасности.

3. Управление активами.

4. Безопасность человеческих ресурсов.

5. Физическая безопасность и безопасность окружающей среды.

6. Управление телекоммуникациями и операциями.

7. Управление доступом.

8. Приобретение, разработка и внедрение информационных систем.

9. Управление инцидентами в сфере информационной безопасности.

10. Управление непрерывностью бизнеса.

11. Соответствие.

Для каждого сервиса приведены его определение, руководство по реализации и

дополнительная информация.

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

высокоуровневый документ, утверждённый высшим руководством организации и

определяющий общий подход к организации и управлению информационной

безопасности. Политика также содержит ссылки на низкоуровневые стандарты,

руководства и процедуры, определяющие практические аспекты реализации механизмов

безопасности. Пересмотр политики осуществляется через запланированные промежутки

времени или в случае принципиальных изменений в информационной системе.

Требования по организации информационной безопасности включают в себя

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

участниками информационного взаимодействия, существующего в организации.

1 Устоявшийся перевод англоязычного термина “control” на русский язык в настоящее время отсутствует.

Наиболее распространённые варианты перевода - «сервис», «контрмера», «механизм контроля». В

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

Отдельно рассматриваются вопросы взаимодействия с органами власти, контрагентами и

другими сторонними организациями, а также возникающие в ходе такого взаимодействия

вопросы конфиденциальности.

Управление активами предполагает проведение инвентаризации активов и

обеспечение корректного их использования. В качестве одного из базовых механизмов

обеспечения информационной безопасности предлагается проведение категорирования

информации с точки зрения её ценности, секретности, критичности для организации, или

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

Вопросы безопасности человеческих ресурсов призваны обеспечить соблюдении

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

Во всех случаях права и обязанности сторон в сфере информационной безопасности

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

корректного увольнения сотрудников, а также вопросы обучения и образовательных

тренингов в области информационной безопасности

Физическая безопасность и безопасность окружающей среды достигаются

путём применения комплекса механизмов управления физическим доступом к активам

организации, использования противопожарных систем, систем кондиционирования, а

также путём своевременного и полноценного технического обслуживания сооружений и

инфраструктуры. Рассматриваются вопросы корректной утилизации активов и повторного

использования оборудования.

Управление телекоммуникациями и операциями реализуется путём чёткой

формализации всех процедур, связанных с обработкой информации в АС. Все изменения в

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

Определяются механизмы борьбы с вредоносным программным обеспечением и методы

обеспечения безопасности мобильного кода. Предлагаются подходы к обеспечению

безопасности специфических сетевых сервисов, таких, например, как механизмы

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

информации.

При рассмотрении вопросов управления доступом особое внимание уделяется

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

порядок организации удалённого доступа пользователей к информационной системе,

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

В ходе приобретения, разработки и внедрения информационных систем

Управление инцидентами в сфере информационной безопасности может

осуществляться силами специалистов организации или с привлечением уполномоченных

органов безопасности. Данная деятельность в общем случае включает в себя сбор улик,

проведение расследования и анализ результатов расследования в целях недопущения

повторных инцидентов и повышения общей защищённости информационной системы.

Обеспечение непрерывности бизнеса является одной из основных задач системы

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

Основы информационной безопасности 106

бизнес-процессов от сбоев или стихийных бедствий. Разрабатываемые планы

непрерывности бизнеса должны гарантировать доступность критических

информационных ресурсов и сервисов на требуемом уровне. Планы непрерывности

бизнеса должны тщательно тестироваться и своевременно обновляться при изменении

структуры информационной системы или бизнес-модели организации.

Соответствие требованиям законодательных актов, отраслевых стандартов и

других нормативных документов является обязательным для всех информационных

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

обязательствах. Рассматриваются также вопросы обеспечения защиты от злоупотреблений

пользователей различными сервисами и информационными ресурсами.

В России аутентичный перевод стандарта в настоящее время планируется к

принятию в качестве ГОСТ.

3.5.3. ISO/IEC 27001:2005

Стандарт ISO/IEC 27001:2005 “Information technology – Security techniques –

Information security management systems - Requirements” [43] (Информационные

технологии. Методы обеспечения безопасности. Системы управления информационной

безопасностью. Требования.) представляет собой расширение ISO/IEC 17799:2005,

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

анализу, поддержке и совершенствованию корпоративных систем управления

информационной безопасностью (СУИБ).

Реализация СУИБ осуществляется путём внедрения четырёхфазной модели PDCA

Вычисление рисков, в свою очередь, включает:

- непосредственно вычисление рисков, выполненное по некоторой методике;

- соотнесение вычисленных значений рисов с установленной шкалой

приемлемых уровней риска.

По результатам анализа рисков необходимо выбрать одну из четырёх возможных

стратегий управления рисками2:

1. Уменьшение риска. Риск считается неприемлемым, и для его уменьшения

выбираются и реализуются те или иные сервисы безопасности.

2. Осознанное и обоснованное принятие риска. Риск в данном случае считается

допустимым. Обычно это означает, что стоимость внедрения сервисов

безопасности значительно превосходит финансовые потери в случае

реализации угрозы.

3. Передача риска. Риск считается неприемлемым и на определённых условиях –

например, в рамках страхования – передаётся сторонней организации.

4. Избежание риска. Риск считается неприемлемым, и в качестве

корректирующих мер осуществляются изменения в бизнес-модели организации

– например, отказ от осуществления того или иного вида деятельности.

Вне зависимости от того, какие стратегии управления рисками будут выбраны,

после их реализации всегда будут существовать остаточные риски, которые также

подлежат оценке. Тот факт, что остаточные риски являются неприемлемыми, служит

основанием поиска более эффективных механизмов управления рисками.

Деятельность, связанная с реализацией результатов управления рисками, должна

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

1. ограничения и зависимости между сервисами безопасности;

2. приоритеты;

3. сроки и ключевые промежуточные этапы реализации;

4. требуемые ресурсы;

5. ссылки на разрешения использования требуемых ресурсов;

6. критические маршруты выполнения плана.

Непрерывный процесс управления рисками в организации должен

контролироваться уполномоченным специалистомили командой специалистов,

которые должны удовлетворять следующим требованиям:

- способность реализовать систематический и организованный подход к

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

- ориентация на бизнес-процессы организации и учёт актуальных в данный

момент приоритетов бизнеса;

2 Наиболее корректным переводом двух англоязычных терминов – “risk management” и “risk treatment”

является «управление рисками». О каком из двух понятий идёт речь, обычно очевидно по контексту.

- настойчивость и независимость суждений, способность учитывать

альтернативные точки зрения;

- способность решать вопросы на всех уровнях корпоративной иерархии

организации;

- хорошее понимание рисков, технологий и сервисов информационной

безопасности.

Большинство сервисов безопасности для обеспечения их корректного и

эффективного функционирования требуют непрерывной поддержки и мониторинга.

Соответствующая деятельность может, например, включать:

- анализ файлов системных журналов;

- модификацию параметров, связанную с произошедшими в системе

изменениями;

- повторный анализ корректности использования сервисов безопасности;

- обновление сервисов, политик и процедур.

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

Возникновение изменений в значениях рисков может быть связано со следующими

факторами:

- изменения в бизнес-модели организации;

- появление новых данных относительно корректности и эффективности

используемых сервисов безопасности;

- изменения, связанные с политической обстановкой, социальными факторами

или окружающей средой;

- возникновение новых, ранее неизвестных угроз и уязвимостей.

Результаты повторного анализа рисков, проводимого с учётом возникших

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

динамику происходящих изменений.

В приложении к стандарту содержатся примеры активов, угроз, уязвимостей, а

также приводится типовая методика оценки рисков.

Выводы

Мы рассмотрели основные оценочные и управленческие стандарты, используемые

при проектировании, реализации, оценке, поддержке, управлении и эксплуатации

автоматизированных систем. Современные стандарты являются бесценным источником

оптимальных и заведомо эффективных решений, а потому их использование во многих

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

информационной безопасности. Тот факт, что в России стандартизация в данной области

идёт по пути поэтапного принятия международных стандартов, не может не сказываться

самым позитивным образом на развитии отрасли в целом.

48) Методы шифрования. Симметричное шифрование. Блочное шифрование. Поточное шифрование.

Алгоритмы шифрования можно разделить на две категории:

1.Алгоритмы симметричного шифрования;

2.Алгоритмы асимметричного шифрования.

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

В асимметричном шифровании ключ зашифрования легко вычисляется из ключа таким образом, что обратное вычисление невозможно. Например, соотношение ключей может быть таким:

,

где и - параметры алгоритма шифрования, имеющие достаточно большую размерность.

Такое соотношение ключей используется и в алгоритмах электронной подписи.

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

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

Симметричное шифрование бывает двух видов:

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

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

49) Блочные шифры. Шифры перестановок. Шифры замены.

Блочные шифры бывают двух основных видов:

1. шифры перестановки;

2. шифры замены.

Шифры перестановок переставляют элементы открытых данных (биты, буквы, символы) в некотором новом порядке. Шифры замены заменяют элементы открытых данных на другие элементы по определенному правилу.

Шифры замены делятся на две группы:

1. моноалфавитные (код Цезаря);

2. полиалфавитные (шифр Видженера)

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

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

Описание метода шифрования перестановочным шифром