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

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

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

Уровень 1. Система для обработки информации с грифом не выше “для служебного пользования”;

Уровень 2. Система для обработки информации с грифом не выше “секретно”;

и т. д.

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

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

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

Таким образом, перед стандартами информационной безопасности стоит непростая задача — примирить эти три точки зрения и создать эффективный механизм взаимодействия всех сторон. Причем “ущемление” потребностей хотя бы одной из них приведет к невозможности взаимопонимания и взаимодействия и, следовательно, не позволит решить общую задачу — создание защищенной системы обработки информации. Необходимость в подобных стандартах была осознана уже достаточно давно (по меркам развития информационных технологий), и в этом направлении достигнут существенный прогресс, закрепленный в новом поколении документов разработки 90-годов. Наиболее значимыми стандартами информационной безопасности являются (в хронологическом порядке): “Критерии безопасности компьютерных систем министерства обороны США”, Руководящие документы Гостехкомиссии России (только для нашей страны), “Европейские критерии безопасности информационных технологий”, “Федеральные критерии безопасности информационных технологий США”, “Канадские критерии безопасности компьютерных систем” и “Единые критерии безопасности информационных технологий”.

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

Стандарт должен:

1) Определить, что понимать под безопасностью и ввести концептуальную базу.

2) Выдвинуть набор требований к безопасной системе.

3) Предложить шкалу оценки безопасности, определенной в первой части стандарта.

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

«Оранжевая книга» является первым стандартом информационной безопасности, он был разработан Министерством обороны США в 1983 году.

Концептуальная часть

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

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

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

Набор требований и система оценок

В данном стандарте определена классификация безопасных информационных систем (A, B, C, D). В каждом классе свои функций безопасности (контроля доступа, аутентификации, аудита и т.д.), которые определяются из приведенных угроз. Также существуют так называемые assurance – набор мер, подтверждающих, что все методы обеспечения безопасности реализованы корректно.

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

1) D – минимальная защита. Этот класс является пустым, то есть не содержит никаких требований к функциям защиты, следовательно, любая система может быть сертифицирована по данному классу.

2) C – дискреционная защита.

3) B – мандатная защита.

4) A – верифицированная защита.

Рассмотрим классы более подробно.

Класс C:

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

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

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

Класс B:

В качестве правил доступа используются правила модели Белла-ЛаПадулы.

Существуют три подкласса B1, B2, B3, отличающиеся тем, на что распространяется контроль доступа.

Класс A:

Данный класс отличается тем, что требования гарантированности (assurance) для реализованной системы должны быть доказаны формально.

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

На практике большинство систем сертифицировано по классу C и гораздо меньше по классу B.

Появление стандарта позволило:

1) Потребителю и производителю использовать единую терминологию.

2) Потребителю формулировать конкретные требования к необходимому им продукту информационных технологий (ИТ-продукту).

3) Сравнивать уровень безопасности существующих ИТ-продуктов по единой шкале.

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

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

Существует несколько категорий информации:

1) Государственная тайна – информация, имеющая гриф «секретно».

2) Конфиденциальная информация – информация ограниченного распространения.

3) Персональные данные. Конфиденциальность персональных данных человека должна быть обеспечена теми, кому доверяет этот человек. Существует закон о персональных данных.

В Руководящих документах основной угрозой считается несанкционированный доступ к информации (НСД).

Основными Руководящими документами являются следующие:

1) «Концепция защиты средств вычислительной техники от несанкционированного доступа к информации»;

2) «Средства вычислительной техники. Защита от несанкционированного доступа к информации. Показатели защищенности от несанкционированного доступа к информации»;

3) «Автоматизированные системы. Защита от несанкционированного доступа к информации. Классификация автоматизированных систем и требований по защите информации».

Руководящие документы предлагают две группы критериев: показатели защищенности средств вычислительной техники (СВТ) от несанкционированного доступа (НСД) и критерии защищенности автоматизированных систем (АС).

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

Для оценки безопасности АС требуется оценить безопасность ее компонентов.

Показатели защищенности СВТ от НСД

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

В документе «Средства вычислительной техники. Защита от несанкционированного доступа к информации. Показатели защищенности от несанкционированного доступа к информации» приведены следующие показатели защищенности СВТ от НСД:

1) Дискреционный принцип контроля доступа;

2) Мандатный принцип контроля доступа;

3) Очистка памяти (используется для мандатного КД);

4) Изоляция модулей;

5) Маркировка документов – расстановка грифов;

6) Защита ввода/вывода на отчужденный носитель информации;

7) Сопоставление пользователя с устройством;

8) Идентификация и аутентификация;

9) Гарантии проектирования (assurance): документирование, тестирование, представление подтверждающей документации;

10) Регистрация событий;

11) Взаимодействие пользователя с КСЗ;

12) Надежное восстановление (действия, предпринимаемые при возникновении сбоя);

13) Целостность КСЗ;

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

15) Контроль дистрибуции;

16) Гарантии архитектуры – формальное доказательство;

17) Тестирование;

18) Руководство пользователя;

19) Конструкторская и проектная документация.

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

Классы защищенности автоматизированных систем

Группа АС определяется на основании следующих признаков:

- наличие информации различного уровня конфиденциальности;

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

- индивидуальный/коллективный доступ к информации.

Соответственно, выделяют три группы АС. В переделах каждой группы определена иерархия классов защищенности АС.

Третья группа, содержащая классы 3А и 3Б, включает в себя АС, где работает один пользователь, допущенный ко всей информации, размещенной на носителях одного уровня конфиденциальности;

Вторая группа, содержащая классы 2А и 2Б, включает АС, в которых пользователи имеют одинаковые полномочия доступа к информации на носителях различного уровня конфиденциальности;

Первая группа, содержащая классы 1Д, 1Г, 1В, 1Б и 1А, включает многопользовательские системы, содержащие информацию различных уровней конфиденциальности. Не все пользователи имеют одинаковые права доступа.

Требования к средствам защиты АС от НСД сгруппированы вокруг реализующих их подсистем:

- подсистемы управления доступом;

- подсистемы регистрации и учета;

- криптографической подсистемы;

- подсистемы обеспечения целостности.

В пределах каждой группы выделены подгруппы требований.

Группа требований к подсистеме управления доступом включает требования:

- идентификации, проверки подлинности и КД;

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

Группа требований к подсистеме регистрации и учета включает требования:

- регистрации/учета;

- учета носителей информации;

- очистки освобождаемых областей памяти и внешних накопителей;

- сигнализации попыток нарушения защиты.

Группа требований к криптографической подсистеме включает требования:

- шифрования конфиденциальной информации;

- шифрования на различных ключах для различных пользователей;

- использования сертифицированных криптографических средств.

Группа требований к подсистеме целостности включает требования:

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

- физической охраны СВТ и носителей информации;

- наличия администратора ЗИ или службы ЗИ;

- периодического тестирования;

- наличие средств восстановления СЗИ;

- использования сертифицированных средств ЗИ и использования сертифицированных СВТ.

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

Требования носят обобщенный характер, поэтому не все требования могут быть применимы.

Рассмотрим более подробно подсистемы и требования к средствам защиты АС от НСД:

1. Подсистема управление доступом:

1.1 Идентификация. Проверка подлинности и контроль доступа субъектов в систему, к терминалам, ЭВМ, к программам, к томам, каталогам, файлам, записям, полям записей.

1.2 Управление потоками информации.

2. Подсистема регистрации и учета:

2.1 Регистрация и учет

- входа/выхода субъектов доступа в/из системы (узла сети);

- выдача графических выходных документов;

- запуск/завершение программ и процессов;

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

- доступа программ к терминалам ЭВМ, узлам сети, каналам связи ЭВМ, программам, каталогам, файлам, записям, полям записей;

- изменения полномочий субъектов доступа, создаваемых защищаемых субъектов доступа.

2.2 Учет носителей информации.

2.3 Очистка (обнуление, обезличивание) освобождаемых областей оперативной памяти ЭВМ и внешних накопителей.

2.4 Сигнализация попыток нарушения защиты.

3. Криптографическая подсистема:

3.1 Шифрование конфиденциальной информации.

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

3.3 Использование сертифицированных криптографических средств.

4. Подсистема обеспечения целостности:

4.1 Обеспечение целостности программных средств и обрабатываемой информации.

4.2 Физическая охрана средств вычислительной техники носителей информации.

4.3 Наличие администратора (службы) защиты информации в АС.

4.4 Периодическое тестирование СЗИ НСД

4.5 Наличие средств восстановления СЗИ НСД.

4.6 Использование сертифицированных средств защиты.

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

Все требования к криптографической подсистеме действуют полностью, начиная с класса Б.

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

1. Что такое «Оранжевая книга»?

2. В чем заключаются отличия класса А от класса В стандарта "Оранжевая книга"?

3. Какие руководящие документы по вопросу информационной безопасности действуют в РФ?

4. Какие существуют категории информации согласно руководящим документам РФ?

5. На основании каких признаков выделяется группа АС?

Лекция 3.

ЕДИНЫЕ КРИТЕРИИ БЕЗОПАСНОСТИ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ (ГОСТ Р ИСО 15408)

Наиболее актуальный стандарт — ГОСТ Р ИСО 15408.

Разработкой данного стандарта занималась международная организация по стандартизации ISO. Стандарт разрабатывался в 1993-1999 годах, первая версия появилась в 1996 году. В данном документе рассматривается не только IT-продукт, но и процесс разработки. Пользователями данного документа являются три группы специалистов: потребители, верификаторы (evaluators) и разработчики.

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

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

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

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

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

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

Рассмотрим структуру профиля защиты.

Введение содержит идентификатор профиля и обзор содержания.

Описание ИТ-продукта содержит краткую характеристику продукта и позволяет понять, стоит ли этот профиль применять к данному продукту.

Раздел описание среды эксплуатации содержит описание среды функционирования с точки зрения безопасности. Он состоит из следующих подразделов:

- условия безопасности;

- угрозы безопасности – описание внешних угроз;

- политика безопасности – описание правил политики безопасности реализованных в ИТ-продукте.

Раздел «Задачи защиты» отражает потребности потребителей в противодействии угрозам и защите IT-продукта. Он состоит из следующих подразделов:

- защита IT-продукта;

- задачи, которые могут быть решены с помощью IT-продукта;

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

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

- подраздел требований адекватности, содержащий ссылки на требования адекватности стандарта;

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

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

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

Раздел «Обоснования» состоит из следующих подразделов:

- обоснования задач защиты;

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

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

б) требования безопасности являются согласованными (не противоречащими);

в) выбор требований является оправданным;

г) выбранный набор требований и уровень адекватности соответствует задачам защиты.

Взаимосвязь всех вышеуказанных компонентов приведена на Рис..

Задание по безопасности(Security Task)

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

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

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

На Рис. приведена схема взаимосвязи между компонентами, дополненная с учетом задания по безопасности.

Рис. 3.1. Взаимосвязь компонентов профиля защиты

Рис. 3.2. Взаимосвязь компонентов профиля защиты с учетом задания по безопасности

Дата добавления: 2014-11-20