 |
Подходы к созданию защищённых АС
|
|
|
|
К созданию современных защищённых АС предъявляются две группы требований: по функциональности и по информационной безопасности. При создании такого рода АС разработчики вынуждены искать компромисс между защищенностью системы, объемом ее функциональных возможностей и затратами на ее создание и сопровождение.
На сегодняшний день к решению проблемы создания защищённых АС существует теоретический и практический подходы.
Первый, будучи абстрактным, позволяет определить стратегические направления разработки, общие критерии, определить степень защищённости АС и её компонент. Гарантии безопасности в этом случае могут быть получены только формальным доказательством защищённости АС.
Во втором случае из-за отсутствия методологии анализа и синтеза (разработки, выбора и интеграции) защитных средств характерен интуитивный подход, основанный на опыте и т.п. В связи с этим возникает ряд проблем. К примеру, возникают неоправданные затраты на дублирование встроенных защитных механизмов механизмами дополнительных средств защиты. Возникает задача разделения прав и обязанностей системных администраторов и администраторов безопасности.
К настоящему времени единая методология анализа уровня защищённости отсутствует. Хотя существует руководящий документ Госкомиссии, определяющий жёсткие требования к классам защищённости, перечень практических методов и средств не сформирован.
Мировой опыт построения защищённых операционных систем позволяет выделить две основные технологии, лежащие в основе их разработки:
Разработка «с нуля». При данном подходе система разрабатывается как единое целое, включая аппаратную часть, ОС и приложения пользователя. В этом случае:
|
|
|
Происходит сбор и подготовка данных о степени конфиденциальности информации и будущих условиях эксплуатации. Речь идёт об условиях, предписанных быть теоретически.
Определяется формулировка задач и требований по защите информации и к процессам проектирования и реализации АС.
Разрабатывается архитектура защищённой АС.
Выполняется проектирование и реализация.
Разработка, точнее доработка системы защиты ресурсов уже эксплуатируемой АС. В этом случае используется та же последовательность действий, но речь идёт уже о фактических условиях эксплуатации и о доработке архитектуры. Сбор и подготовка данных о степени конфиденциальности информации и фактических условиях эксплуатации в этом случае называются аудитом.
При данном подходе уже имеется некоторая система-прототип, на основании которой строится новая система с улучшенными характеристиками и доработанной системой защиты информации (СЗИ).
Существует два варианта реализации второго подхода: «Добавление СЗИ на уровне ОС» и «Переработка СЗИ на уровне ядра».
В первом варианте система-прототип не модифицируется. Защитные механизмы накладываются на нее, образуя дополнительный программный уровень между системой-прототипом и вышележащими приложениями. Данный подход используется для построения защищенной операционной системы (ЗОС) на основе ОС с закрытым исходным кодом.
Во втором варианте происходит переработка системы-прототипа, что обязательно требует наличия её исходного кода. Основными преимуществами являются анализ системы-прототипа на уровне исходного кода, меньшие объемы конечной системы и более эффективная реализация механизмов защиты. Данный вариант может быть выполнен одним из двух методов: «Добавление СЗИ на уровне ядра» и «Замещение СЗИ на уровне ядра».
Первый метод заключается в реализации СЗИ, как отдельной подсистемы ядра с определенным интерфейсом к другим подсистемами ядра. Обычно при данном способе используется некоторый универсальный принцип построения системы защиты, который является инвариантным к конкретной системе-прототипу. Данный метод используется при создании ЗОС на основе разных систем-прототипов для построения на их основе защищенных информационных систем с учетом особенностей политики безопасности, проводимой в данной организации.
|
|
|
Второй метод заключается в изменении базовых механизмов безопасности системы-прототипа. Данный способ применяется при построении ЗОС, изначально ориентированных на определенное функциональное назначение. Обычно такого рода системы разрабатываются для организаций с известной заранее и редко изменяемой политикой безопасности. Можно утверждать, что по эффективности реализации механизмов защиты данный метод стоит ближе других к методу разработки ЗОС «с нуля».
Однако, в любом случае необходим повторный сбор и анализ данных, что делает процесс создания защищённых АС итеративным. Этапы создания такой АС в общем случае можно разделить на два этапа – анализ (на этом этапе принято использовать термин «защищённая АС») и синтез (используется термин «безопасная АС»).
Нормативные документы, регламентирующие синтез АС отсутствуют, за исключением документа «специальные требования и рекомендации по созданию…»
В некоторых аспектах могут применяться стандарты Единой системы программной документации (ЕСПД) и АС. Документы Гостехкомиссии содержат лишь требования к защищенности СВТ АС и процедуры их аттестации.
Наиболее общим документом, регламентирующим процесс разработки, квалификации и эксплуатации защищенных АС, является стандарт ИСО15408.
В ходе синтеза система проходит следующие этапы:
- Обследование АС, на котором происходит сбор исходных данных, их анализ, обоснование задач, требований и принципиальных решений и оформление "Концепции защиты АС". Единые критерии требуют разработки двух базовых документов концептуального "Профили защиты, функциональные требования средств защиты ресурсов (СЗР)" и технического "Проекта защиты" – основой служат спецификации средств защиты ресурсов.
Основывается на рекомендациях ГОСТ 34.601-90. Решается 5 групп задач:
|
|
|
- сбор и анализ исходных данных об АС, как объекте защиты.
Ведётся сбор информации об АС: условиях эксплуатации, перечисление видов обеспечения, определяется наличие конфиденциальных данных, анализ угроз, обоснование выбора политики безопасности. Анализ проектной документации, запуск и анализ результатов тестовых задач. Аналитика с трудом подается формализации.
В итоге должна быть разработана структурная схема АС, отражающая все аспекты ее эксплуатации в заданных условиях с точки зрения безопасности ресурсов.
- объявление политики безопасности;
Общая политика безопасности в данной АС является совокупностью частных политик безопасности. Может объявляться руководящим документом. Политика безопасности может быть представлена минимально необходимой совокупностью следующих документов:
- Концепция защиты предприятия, описывающая общие принципы и подходы в организации информационной безопасности. Документ составляет организационную основу для построения всей системы информационной безопасности организации, и должен быть одобрен руководством предприятия.
- Процедуры информационной безопасности предприятия. В документе указывается, что должно быть сделано и должно делаться в данной организации для того, чтобы уровень информационной безопасности соответствовал заявленному в соответствии с каким либо стандартом.
- Методы информационной безопасности. Документ – сборник должностных инструкций, предназначенный для конечного пользователя. В нём указывается, как будут выполняться процедуры информационной безопасности конечными пользователями.
- Аварийный план. Документ, описывающий план действий в случае инцидентов в области информационной безопасности.
- формулировка задач защиты ресурсов АС.
Администратором АС формулируется список конкретных угроз. Последовательность действий для последующей формулировки задач:
- определение (выбор) общих угроз безопасности из классов угроз;
|
|
|
- конкретизация угроз безопасности по каждому из выбранных классов;
- определение частных политик безопасности по конкретным угрозам или их группе;
- формулировка требований безопасности ресурсов защищенной АС.
Они содержат набор качественных или количественных показателей, которым должна удовлетворять защищенная АС для решения задач защиты ресурса. Это основа технического задания (ТЗ) на проектирование, СВТ или доработки ее СЗР.
Формулировка соответствует разделу "Технические требования" ТЗ и может быть выполнена на основании класса защищенности АС или СВТ.
- обоснование задач, требования и концептуальные решения.
Объективные экономические расчеты эффекта от внедрения СЗР АС сделать не удается.
Поэтому на практике зачастую выполняется расчет затрат на реализацию СЗР АС, который затем сопоставляют со стоимостью АС.
Считается, что предлагаемое решение экономически обоснованно, например для АС, защищенных по классу 1Г, если затраты на СЗР составляют 15-20% от стоимости АС.
Здесь необходимо доказывать:
1) полноту (достаточность) рассмотренных задач и необходимость их рассмотрения с точки зрения объявленных угроз, а также корректность постановок задач защиты ресурсов;
2) полнота, непротиворечивость сформулированных функциональных требований, т.е. доказательство того, что они решают постановленную задачу;
3) описание и объяснение концептуальных (принципиальных) решений и возможных альтернатив по построению СЗР АС, включая политику безопасности.
- Разработка проекта;
АС реализуется на базе проектной документации. Ее конкретный состав регламентируется соотв. стандартами, но нам необходима только та ее часть, которая дает фактические сведения о состоянии АС, которые могут повлиять на СЗР.
Состав этих уточняемых данных определяется разницей между данными, требуемыми содержанием проекта и данными, имеющимися в "Концепции".
Проект СЗР от "Концепции" имеет существенные отличия:
- в "Концепции" вырабатываются принципиальные решения и возможные альтернативные варианты их технической реализации. В проекте СЗР разрабатываются конкретные технические решения по отдельным средствам защиты АС и системы в целом;
- состав уточняемых данных в проекте СЗР определяется конкретными техническими решениями, принятыми в проекте СЗР;
- одним из важных конечных документов является "Спецификация" средств защиты ресурсов";
- проект СЗР содержит проекты организационно-распорядительной документации, регламентирующей правила корректной эксплуатации АС;
- проект СЗР содержит исчерпывающую информацию для проведения аттестации АС.
- реализация и аттестация защищенных АС.
|
|
|
