Предисловие дорогие коллеги!

Вид материала

Документы

Содержание 4.6. Выбор метода моделирования процесса создания комплексной системы защиты информации в организации

Подобный материал:

• План работы с 3 по 07 октября 2011 года, 46.99kb.
• Дорогие коллеги!, 61.26kb.
• Дорогие друзья! Уважаемые коллеги!, 90.01kb.
• Областной Дом Детей и Юношества, 680.22kb.
• Глубокоуважаемый Владимир Владимирович! Глубокоуважаемые участники и гости съезда!, 297.51kb.
• Дорогие друзья и уважаемые коллеги, 108.19kb.
• Дорогие коллеги!, 58.67kb.
• Дорогие коллеги!, 22.65kb.
• Дорогие друзья и коллеги!, 15.57kb.
• Дорогие коллеги, товарищи, друзья, 451.25kb.

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

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

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

Сегодня, после первого этапа построения КСЗИ – принятия решения о создании КСЗИ – руководитель или ответственное лицо встаёт перед проблемой поиска структурировано изложенной информации, плана действий или готового руководящего документа по разработке КСЗИ. Вместо этого он буквально «тонет» в разнородных рекомендациях, подходах, версиях и различных субъективных мнениях.

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

Моделирование КСЗИ является сложной задачей, потому что такие системы относятся к классу сложных организационно-технических систем, которым присущи следующие особенности:

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

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

Для преодоления этих сложностей применяются:

• макромоделирование [95];
  
• декомпозиция общей задачи на ряд частных задач;
  
• объектно-ориентированный подход;
  
• специальные методы неформального моделирования.
  

Из вышеперечисленных методов моделирования наиболее популярным является объектно-ориентированный подход. В работе [35] отмечается, что попытки создания больших информационных систем еще в 60-х годах прошлого столетия вскрыли многочисленные проблемы программирования, главной из которых является сложность создаваемых и сопровождаемых систем. Результатами исследований в области технологии программирования стали сначала структурированное программирование, затем объектно-ориентированный подход (ООП).

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

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

Любой разумный метод борьбы со сложностью опирается на принцип «devide et impera» – «разделяй и властвуй». В данном контексте этот принцип означает, что сложная система (КСЗИ) на верхнем уровне должна состоять из небольшого числа относительно независимых компонентов. Относительная независимость здесь и далее понимается как минимизация числа связей между компонентами. Затем декомпозиции подвергаются выделенные на первом этапе компоненты, и так далее до заданного уровня детализации. В результате система оказывается представленной в виде иерархии с несколькими уровнями абстракции.

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

Объектно-ориентированный подход использует объектную декомпозицию, то есть поведение системы описывается в терминах взаимодействия объектов.

Что же понимается под объектом и каковы другие основополагающие понятия данного подхода?

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

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

Объект – это элемент класса, то есть абстракция определенной сущности.

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

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

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

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

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

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

Применение ООП предполагает использование определенной методологии, наиболее популярной из которых является Rational Unified Process (RUP) – методология разработки программного обеспечения, созданная компанией Rational Software [29].

В основе RUP лежат следующие основные принципы:

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

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

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




Рис. 5. Полный жизненный цикл в соответствии с RUP


На этапе «Начало»:

• Формируются видение и границы проекта.
  
• Создается экономическое обоснование (business case).
  
• Определяются основные требования, ограничения и ключевая функциональность продукта.
  
• Создается базовая версия модели прецедентов.
  
• Оцениваются риски.
  

При завершении начальной стадии оценивается достижение вехи целей жизненного цикла (англ. Lifecycle Objective Milestone), которое предполагает соглашение заинтересованных сторон о продолжении проекта.

На этапе «Уточнение» производится анализ предметной области и построение исполняемой архитектуры. Это включает в себя:

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

На этапе «Конструирование» происходит реализация большей части функциональности продукта. Этап «Конструирование» завершается первым внешним релизом системы и вехой начальной функциональной готовности (Initial Operational Capability).

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

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

Таким образом, при разработке модели процесса проектирования КСЗИ необходимо использовать надежный и многократно проверенный ООП совместно с отлаженной методологией RUP, что позволит избежать многочисленных ошибок на первых этапах создания КСЗИ.