сс. Политика безопасности
 Скачать 32.11 Kb.
|
|
1.1 Степень доверия оценивается по двум основным критериям [1]. Политика безопасности – набор законов, правил и норм поведения, определяющих, как организация обрабатывает, защищает и распространяет информацию. В частности, правила определяют, в каких случаях пользователь может оперировать конкретными наборами данных. Чем выше степень доверия системе, тем строже и многообразнее должна быть политика безопасности. В зависимости от сформулированной политики можно выбирать конкретные механизмы обеспечения безопасности. Политика безопасности — это активный аспект защиты, включающий в себя анализ возможных угроз и выбор мер противодействия. Уровень гарантированности – мера доверия, которая может быть оказана архитектуре и реализации ИС. Доверие безопасности может проистекать как из анализа результатов тестирования, так и из проверки (формальной или нет) общего замысла и реализации системы в целом и отдельных ее компонентов. Уровень гарантированности показывает, насколько корректны механизмы, отвечающие за реализацию политики безопасности. Это пассивный аспект защиты. Монитор обращений должен обладать тремя качествами: Изолированность. Необходимо предупредить возможность отслеживания работы монитора. Полнота. Монитор должен вызываться при каждом обращении, не должно быть способов обойти его. Верифицируемость. Монитор должен быть компактным, чтобы его можно было проанализировать и протестировать, будучи уверенным в полноте тестирования. Реализация монитора обращений называется ядром безопасности. Ядро безопасности – это основа, на которой строятся все защитные механизмы. Помимо перечисленных свойств монитора обращений, ядро должно гарантировать собственную неизменность. Согласно «Оранжевой книге», политика безопасности должна обязательно включать в себя следующие элементы [1]: произвольное управление доступом; безопасность повторного использования объектов; метки безопасности; принудительное управление доступом. Если понимать политику безопасности как правила разграничения доступа, то механизм подотчетности является дополнением подобной политики. Цель подотчетности - в каждый момент времени знать, кто работает в системе и что делает. Средства подотчетности делятся на три категории: идентификация и аутентификация; предоставление доверенного пути; анализ регистрационной информации. Обычный способ идентификации – ввод имени пользователя при входе в систему. Стандартное средство проверки подлинности (аутентификации) пользователя - пароль. Гарантированность – это мера уверенности с которой можно утверждать, что для воплощения в жизнь сформулированной политики безопасности выбран подходящий набор средств, и что каждое из этих средств правильно исполняет отведенную ему роль. Операционная гарантированность относится к архитектурным и реализационным аспектам системы, в то время как технологическая – к методам построения и сопровождения. Операционная гарантированность включает в себя проверку следующих элементов: архитектура системы; целостность системы; проверка тайных каналов передачи информации; доверенное администрирование; доверенное восстановление после сбоев. Операционная гарантированность – это способ убедиться в том, что архитектура системы и ее реализация действительно реализуют избранную политику безопасности. Технологическая гарантированность охватывает весь жизненный цикл системы, то есть периоды проектирования, реализации, тестирования, продажи и сопровождения. Все перечисленные действия должны выполняться в соответствии с жесткими стандартами, чтобы исключить утечку информации и нелегальные «закладки». Согласно "Оранжевой книге", в комплект документации надежной системы должны входить следующие тома: Руководство пользователя по средствам безопасности. Руководство администратора по средствам безопасности. Тестовая документация. Описание архитектуры. Разумеется, на практике требуется еще по крайней мере один том - Письменное изложение политики безопасности данной организации. Типичное оглавление Руководства администратора включает в себя следующие пункты: Каковы основные защитные механизмы? Как администрировать средства идентификации и аутентификации? В частности, как заводить новых пользователей и удалять старых? Как администрировать средства произвольного управления доступом? Как защищать системную информацию? Как обнаруживать слабые места существующей системы защиты? Как администрировать средства протоколирования и аудита? Как выбирать регистрируемые события? Как анализировать результаты? Как администрировать средства принудительного управления доступом? Какие уровни секретности и категории выбрать? Как назначать и менять метки безопасности? Как генерировать новую, переконфигурированную надежную вычислительную базу? Как безопасно запускать систему и восстанавливать ее после сбоев и отказов? Как организовать резервное копирование? Как разделить обязанности системного администратора и оператора? Тестовая документация содержит описания тестов и их результаты. По идее она проста, но зачастую весьма пространна. Кроме того, тестовая документация должна содержать план тестирования и условия, налагаемые на тестовое окружение. Описание архитектуры в данном контексте должно включать в себя сведения о внутреннем устройстве надежной вычислительной базы. Вообще говоря, это описание должно быть формальным, допускающим автоматическое сопоставление с политикой безопасности на предмет соответствия требованиям последней. Объем описания архитектуры может оказаться сопоставимым с объемом исходных текстов программной реализации системы. Классы безопасности. В рассматриваемом стандарте определены подходы к ранжированию информационных систем по степени надежности. В "Оранжевой книге" рассматривается четыре уровня безопасности (надежности) — D, С, В и А. [1] Эти классы безопасности обозначают следующее: D1 – неудовлетворительная безопасность; С1, С2 – произвольное управление доступом; В1, В2, В3 – принудительное управление доступом; А1 – верифицированная защита. По мере перехода от уровня С к А к надежности систем предъявляются все более жесткие требования. Уровни С и В подразделяются на классы (С1, С2, В1, В2, ВЗ) с постепенным возрастанием надежности. Таким образом, всего практически используются шесть классов безопасности – С1, С2, В1, В2, ВЗ, А1. Чтобы система в результате процедуры сертификации могла быть отнесена к некоторому классу, ее политика безопасности и гарантированность должны удовлетворять приводимым далее требованиям. Поскольку при переходе к каждому следующему классу требования только добавляются, то дополнительно вписываются только новые, что присуще данному классу, группируя требования в согласии с предшествующим изложением. Каждый класс безопасности включает набор требований с учетом элементов политики безопасности и требований к гарантированности. Так, для класса С1 требования предусматривают следующее: – С учетом политики безопасности: Надежная вычислительная база должна управлять доступом именованных пользователей к именованным объектам. Механизм управления (права для владельца/группы/прочих, списки управления доступом) должен позволять пользователям специфицировать разделение файлов между индивидами и/или группами; Пользователи должны идентифицировать себя, прежде чем выполнять какие-либо иные действия, контролируемые надежной вычислительной базой. Для аутентификации должен использоваться какой-либо защитный механизм, например пароли. Аутентификационная информация должна быть защищена от несанкционированного доступа; – С учетом гарантированности: Надежная вычислительная база должна поддерживать область, защищенную от внешних воздействий (в частности, от изменения команд и/или данных) и от попыток слежения за ходом работы. Ресурсы, контролируемые базой, могут составлять определенное подмножество всех субъектов и объектов системы. Должны быть в наличии аппаратные и/или программные средства, позволяющие периодически проверять корректность функционирования аппаратных и микропрограммных компонентов надежной вычислительной базы. Защитные механизмы должны быть протестированы на предмет соответствия их поведения системной документации. Тестирование должно подтвердить, что у неавторизованного пользователя нет очевидных способов обойти или разрушить средства защиты надежной вычислительной базы. Отдельный фрагмент документации (глава, том) должен описывать защитные механизмы, предоставляемые надежной вычислительной базой, и их взаимодействие между собой, содержать рекомендации по их использованию. Руководство должно содержать сведения о функциях и привилегиях, которыми управляет системный администратор посредством механизмов безопасности. Разработчик системы должен представить экспертному совету документ, содержащий план тестов, процедуры прогона тестов и результаты тестов. Должны быть описаны подход к безопасности, используемый производителем, и применение этого подхода при реализации надежной вычислительной базы. Если база состоит из нескольких модулей, то должен быть описан интерфейс между ними. 1.2 Рекомендации X.800 - документ довольно обширный. Мы остановимся на специфических сетевых функциях (сервисах) безопасности, а также на необходимых для их реализации защитных механизмах. Выделяют следующие сервисы безопасности и исполняемые ими роли: Аутентификация. Данный сервис обеспечивает проверку подлинности партнеров по общению и проверку подлинности источника данных. Аутентификация партнеров по общению используется при установлении соединения и, быть может, периодически во время сеанса. Она служит для предотвращения таких угроз, как маскарад и повтор предыдущего сеанса связи. Аутентификация бывает односторонней (обычно клиент доказывает свою подлинность серверу) и двусторонней (взаимной). Управление доступом. Обеспечивает защиту от несанкционированного использования ресурсов, доступных по сети. Конфиденциальность данных. Обеспечивает защиту от несанкционированного получения информации. Отдельно упомянем конфиденциальность трафика (это защита информации, которую можно получить, анализируя сетевые потоки данных). Целостность данных подразделяется на подвиды в зависимости от того, какой тип общения используют партнеры - с установлением соединения или без него, защищаются ли все данные или только отдельные поля, обеспечивается ли восстановление в случае нарушения целостности. Неотказуемость (невозможность отказаться от совершенных действий) обеспечивает два вида услуг: неотказуемость с подтверждением подлинности источника данных и неотказуемость с подтверждением доставки. Побочным продуктом неотказуемости является аутентификация источника данных. 1.3 Мы возвращаемся к теме оценочных стандартов, приступая к рассмотрению самого полного и современного среди них - "Критериев оценки безопасности информационных технологий" (издан 1 декабря 1999 года). Этот международный стандарт стал итогом почти десятилетней работы специалистов нескольких стран, он вобрал в себя опыт существовавших к тому времени документов национального и межнационального масштаба. По историческим причинам данный стандарт часто называют "Общими критериями" (или даже ОК). Мы также будем использовать это сокращение. "Общие критерии" на самом деле являются метастандартом, определяющим инструменты оценки безопасности ИС и порядок их использования. В отличие от "Оранжевой книги", ОК не содержат предопределенных "классов безопасности". Такие классы можно строить, исходя из требований безопасности, существующих для конкретной организации и/или конкретной информационной системы. С программистской точки зрения ОК можно считать набором библиотек, помогающих писать содержательные "программы" - задания по безопасности, типовые профили защиты и т.п. Программисты знают, насколько хорошая библиотека упрощает разработку программ, повышает их качество. Без библиотек, "с нуля", программы не пишут уже очень давно; оценка безопасности тоже вышла на сопоставимый уровень сложности, и "Общие критерии" предоставили соответствующий инструментарий. Важно отметить, что требования могут быть параметризованы, как и полагается библиотечным функциям. Как и "Оранжевая книга", ОК содержат два основных вида требований безопасности: функциональные, соответствующие активному аспекту защиты, предъявляемые к функциям безопасности и реализующим их механизмам; требования доверия, соответствующие пассивному аспекту, предъявляемые к технологии и процессу разработки и эксплуатации. Требования безопасности предъявляются, а их выполнение проверяется для определенного объекта оценки - аппаратно-программного продукта или информационной системы. Очень важно, что безопасность в ОК рассматривается не статично, а в привязке к жизненному циклу объекта оценки. Выделяются следующие этапы: определение назначения, условий применения, целей и требований безопасности; проектирование и разработка; испытания, оценка и сертификация; внедрение и эксплуатация. В ОК объект оценки рассматривается в контексте среды безопасности, которая характеризуется определенными условиями и угрозами. В свою очередь, угрозы характеризуются следующими параметрами: источник угрозы; метод воздействия; уязвимые места, которые могут быть использованы; ресурсы (активы), которые могут пострадать. Уязвимые места могут возникать из-за недостатка в: требованиях безопасности; проектировании; эксплуатации. Слабые места по возможности следует устранить, минимизировать или хотя бы постараться ограничить возможный ущерб от их преднамеренного использования или случайной активизации. С точки зрения технологии программирования в ОК использован устаревший библиотечный (не объектный) подход. Чтобы, тем не менее, структурировать пространство требований, в "Общих критериях" введена иерархия класс-семейство-компонент-элемент. Классы определяют наиболее общую, "предметную" группировку требований (например, функциональные требования подотчетности). Семейства в пределах класса различаются по строгости и другим нюансам требований. Компонент - минимальный набор требований, фигурирующий как целое. Элемент - неделимое требование. Как и между библиотечными функциями, между компонентами ОК могут существовать зависимости. Они возникают, когда компонент сам по себе недостаточен для достижения цели безопасности. Вообще говоря, не все комбинации компонентов имеют смысл, и понятие зависимости в какой-то степени компенсирует недостаточную выразительность библиотечной организации, хотя и не заменяет объединение функций в содержательные объектные интерфейсы. Как указывалось выше, с помощью библиотек могут формироваться два вида нормативных документов: профиль защиты и задание по безопасности. Профиль защиты (ПЗ) представляет собой типовой набор требований, которым должны удовлетворять продукты и/или системы определенного класса (например, операционные системы на компьютерах в правительственных организациях). Задание по безопасности содержит совокупность требований к конкретной разработке, выполнение которых обеспечивает достижение поставленных целей безопасности. Выше мы отмечали, что в ОК нет готовых классов защиты. Сформировать классификацию в терминах "Общих критериев" - значит определить несколько иерархически упорядоченных (содержащих усиливающиеся требования) профилей защиты, в максимально возможной степени использующих стандартные функциональные требования и требования доверия безопасности. Выделение некоторого подмножества из всего множества профилей защиты во многом носит субъективный характер. По целому ряду соображений (одним из которых является желание придерживаться объектно-ориентированного подхода) целесообразно, на наш взгляд, сформировать сначала отправную точку классификации, выделив базовый (минимальный) ПЗ, а дополнительные требования компоновать в функциональные пакеты. Функциональный пакет - это неоднократно используемая совокупность компонентов, объединенных для достижения определенных целей безопасности. "Общие критерии" не регламентируют структуру пакетов, процедуры верификации, регистрации и т.п., отводя им роль технологического средства формирования ПЗ. Базовый профиль защиты должен включать требования к основным (обязательным в любом случае) возможностям. Производные профили получаются из базового путем добавления необходимых пакетов расширения, то есть подобно тому, как создаются производные классы в объектно-ориентированных языках программирования. 1.4 Наше изложение "Гармонизированных критериев" основывается на версии 1.2, опубликованной в июне 1991 года от имени соответствующих органов четырех стран - Франции, Германии, Нидерландов и Великобритании. Принципиально важной чертой Европейских Критериев является отсутствие требований к условиям, в которых должна работать информационная система. Так называемый спонсор, то есть организация, запрашивающая сертификационные услуги, формулирует цель оценки, то есть описывает условия, в которых должна работать система, возможные угрозы ее безопасности и предоставляемые ею защитные функции. Задача органа сертификации - оценить, насколько полно достигаются поставленные цели, то есть насколько корректны и эффективны архитектура и реализация механизмов безопасности в описанных спонсором условиях. Таким образом, в терминологии "Оранжевой книги", Европейские Критерии относятся к гарантированности безопасной работы системы. Требования к политике безопасности и наличию защитных механизмов не являются составной частью Критериев. Впрочем, чтобы облегчить формулировку цели оценки, Критерии содержат в качестве приложения описание десяти классов функциональности, типичных для правительственных и коммерческих систем. Европейские Критерии рассматривают все основные составляющие информационной безопасности - конфиденциальность, целостность, доступность. В Критериях проводится различие между системами и продуктами. Система - это конкретная аппаратно-программная конфигурация, построенная с вполне определенными целями и функционирующая в известном окружении. Продукт - это аппаратно-программный "пакет", который можно купить и по своему усмотрению встроить в ту или иную систему. Таким образом, с точки зрения информационной безопасности основное отличие между системой и продуктом состоит в том, что система имеет конкретное окружение, которое можно определить и изучить сколь угодно детально, а продукт должен быть рассчитан на использование в различных условиях. Из практических соображений важно обеспечить единство критериев оценки продуктов и систем - например, чтобы облегчить оценку системы, составленной из ранее сертифицированных продуктов. По этой причине для систем и продуктов вводится единый термин - объект оценки. Каждая система и/или продукт предъявляет свои требования к обеспечению конфиденциальности, целостности и доступности. Чтобы удовлетворить эти требования, необходимо предоставить соответствующий набор функций (сервисов) безопасности, таких как идентификация и аутентификация, управление доступом или восстановление после сбоев. Сервисы безопасности реализуются посредством конкретных механизмов. Чтобы объекту оценки можно было доверять, необходима определенная степень уверенности в наборе функций и механизмов безопасности. Степень уверенности мы будем называть гарантированностью. Гарантированность может быть большей или меньшей в зависимости от тщательности проведения оценки. Гарантированность затрагивает два аспекта - эффективность и корректность средств безопасности. При проверке эффективности анализируется соответствие между целями, сформулированными для объекта оценки, и имеющимся набором функций безопасности. Точнее говоря, рассматриваются вопросы адекватности функциональности, взаимной согласованности функций, простоты их использования, а также возможные последствия эксплуатации известных слабых мест защиты. Кроме того, в понятие эффективности входит способность механизмов защиты противостоять прямым атакам (мощность механизма). Определяются три градации мощности - базовая, средняя и высокая. Под корректностью понимается правильность реализации функций и механизмов безопасности. В Критериях определяется семь возможных уровней гарантированности корректности - от E0 до E6 (в порядке возрастания). Уровень E0 означает отсутствие гарантированности. При проверке корректности анализируется весь жизненный цикл объекта оценки - от проектирования до эксплуатации и сопровождения. Общая оценка системы складывается из минимальной мощности механизмов безопасности и уровня гарантированности корректности. Гармонизированные критерии Европейских стран явились для своего времени весьма передовым стандартом, они создали предпосылки для появления "Общих критериев". 1.5 Как и "Оранжевая книга", ОК содержат два основных вида требований безопасности: • функциональные (security functional requirements ), соответствующие активному аспекту защиты, предъявляемые к функциям безопасности и реализующим их механизмам; • требования доверия к адекватности реализации функций безопасности (security assurance requirements), соответствующие пассивному аспекту, предъявляемые к технологии и процессу разработки и эксплуатации. Требования безопасности предъявляются, а их выполнение проверяется для определенного объекта оценки - аппаратно-программного продукта или информационной системы. Очень важно, что безопасность в ОК рассматривается не статично, а в привязке к жизненному циклу объекта оценки (этапам создания и эксплуатации). Выделяются следующие этапы: • определение назначения, условий применения, целей и требований безопасности; • проектирование и разработка; • испытания, оценка и сертификация; • внедрение и эксплуатация. В ОК объект оценки рассматривается в контексте среды безопасности, которая характеризуется определенными условиями и угрозами. В свою очередь, угрозы характеризуются следующими параметрами: • источник угрозы; • метод воздействия; • уязвимые места, которые могут быть использованы; • ресурсы (активы), которые могут пострадать. Уязвимые места могут возникать из-за недостатка в: • требованиях безопасности; • проектировании; • эксплуатации. Слабые места по возможности следует устранить, минимизировать или хотя бы постараться ограничить возможный ущерб от их преднамеренного использования или случайной активизации. С точки зрения технологии программирования в ОК использован устаревший библиотечный (не объектный) подход. Чтобы, тем не менее, структурировать пространство требований, в "Общих критериях" введена иерархия: класс – семейство – компонент - элемент. Классы определяют наиболее общую, "предметную" группировку требований (например, функциональные требования подотчетности). Семейства в пределах класса различаются по строгости и другим нюансам требований. Компонент - минимальный набор требований, фигурирующий как целое. Элемент - неделимое требование. Как и между библиотечными функциями, между компонентами ОК могут существовать зависимости. Они возникают, когда компонент сам по себе недостаточен для достижения цели безопасности. В принципе, не все комбинации компонентов имеют практический смысл, и понятие зависимости в некоторой степени компенсирует недостаточную выразительность библиотечной организации, хотя и не заменяет объединение функций в содержательные объектные интерфейсы. С помощью библиотек могут формироваться два вида нормативных документов: профиль защиты и задание по безопасности. Профиль защиты (ПЗ) - представляет собой типовой набор требований, которым должны удовлетворять продукты и/или системы определенного класса (например, операционные системы на компьютерах в правительственных организациях). Задание по безопасности - содержит совокупность требований к конкретной разработке, выполнение которых обеспечивает достижение поставленных целей безопасности. Принципиально, что в ОК нет готовых классов защиты. Сформировать классификацию видов и методов защиты в терминах "Общих критериев" - значит определить несколько иерархически упорядоченных (содержащих усиливающиеся требования) профилей защиты, в максимально возможной степени использующих стандартные функциональные требования и требования доверия безопасности. Выделение некоторого подмножества из всего множества профилей защиты во многом носит субъективный характер. По целому ряду соображений (одним из которых является желание придерживаться объектно-ориентированного подхода) целесообразно сформировать сначала отправную точку классификации, выделив базовый (минимальный) ПЗ, а дополнительные требования компоновать в функциональные пакеты. •Функциональный пакет - это неоднократно используемая совокупность компонентов, объединенных для достижения определенных целей безопасности. "Общие критерии" не регламентируют структуру пакетов, процедуры верификации, регистрации и т.п., отводя им роль технологического средства формирования ПЗ. Базовый профиль защиты - должен включать требования к основным (обязательным в любом случае) возможностям. Производные профили - получаются из базового путем добавления необходимых пакетов расширения, то есть подобно тому, как создаются производные классы в объектно-ориентированных языках программирования. |