ОИБ. основы информ. безопасности. Учебное пособие Томск
 Скачать 1.99 Mb.
|
|
2.5. Методология построения защищенных АС Рассмотрим методы построения защищенных АС. Эти методы условно можно разделить на две группы: 1) относящиеся к произвольному ПО АС: иерархический метод разработки; исследование корректности и верификация. 2) специфичные только для систем защиты (теория безопасных систем). Иерархический метод разработки ПО АС. В соответствии с принципом абстракции при проектировании АС разработчики могут идти по меньшей мере двумя путями: от аппаратуры «вверх» - к виртуальной машине, представляющей АС, или от виртуальной машины «вниз»- к реальному оборудованию. Это и есть два основных метода проектирования - метод снизу вверх и метод сверху вниз. Остальные методы по своей сути сводятся к этим двум или являются их сочетанием. Первый метод достаточно прост, требует намного меньших капитальных вложений, но и обладает меньшими возможностями. Он основан на известной схеме : «Вы – злоумышленник. Ваши действия?». То есть служба информационной безопасности, основываясь на данных о всех известных видах атак, пытается применить их на практике с целью проверки, а возможно ли такая атака со стороны реального злоумышленника. Метод снизу вверх предполагает начало проектирования с основного аппаратного оборудования системы. При проектировании модули разбиваются на ряд слоев, причѐм нулевой слой виртуальной системы образует аппаратура. Слои, реализующие одно или несколько необходимых свойств, добавляются последовательно пока не будет получена желаемая виртуальная машина. К недостаткам метода проектирования снизу вверх относят: необходимость с самого начала принимать решение о выборе способа реализации компонентов АС-с помощью аппаратуры, микропрограмм или программ, что сделать очень трудно; возможность проектирования АС только после разработки аппаратуры; расхождение между реальной АС и определѐнной в ТЗ. 34 Метод «сверху вниз» представляет собой, наоборот, детальный анализ всей существующей схемы хранения и обработки информации. Первым этапом этого метода является, как и всегда, определение, какие информационные объекты и потоки необходимо защищать. Далее следует изучение текущего состояния системы информационной безопасности с целью определения, что из классических методик защиты информации уже реализовано, в каком объеме и на каком уровне. На третьем этап производится классификация всех информационных объектов на классы в соответствии с ее конфиденциальностью, требованиями к доступности и целостности (неизменности). Далее следует выяснение насколько серьезный ущерб может принести фирме раскрытие или иная атака на каждый конкретный информационный объект. Этот этап носит название «вычисление рисков». В первом приближении риском называется произведение «возможного ущерба от атаки» на «вероятность такой атаки». Существует множество схем вычисления рисков, остановимся на одной из самых простых. Ущерб от атаки может быть представлен неотрицательным числом в приблизительном соответствии со следующей таблицей 2.1. Таблица 2.1. Величина ущерба Описание 0 Раскрытие информации принесет ничтожный моральный и финансовый ущерб фирме 1 Ущерб от атаки есть, но он незначителен, основные финансовые операции и положение фирмы на рынке не затронуты 2 Финансовые операции не ведутся в течение некоторого времени, за это время фирма терпит убытки, но ее положение на рынке и количество клиентов изменяются минимально 3 Значительные потери на рынке и в прибыли. От фирмы уходит ощутимая часть клиентов 4 Потери очень значительны, фирма на период до года теряет положение на рынке. Для восстановления положения требуются крупные финансовые займы. 5 Фирма прекращает существование Вероятность атаки представляется неотрицательным числом в приблизительном соответствии со следующей таблицей 2.2. Таблица 2.2. Вероятность Средняя частота появления 0 Данный вид атаки отсутствует 1 реже, чем раз в год 2 около 1 раза в год 3 около 1 раза в месяц 4 около 1 раза в неделю 5 практически ежедневно Необходимо отметить, что классификацию ущерба, наносимого атакой, должен оценивать владелец информации, или работающий с нею персонал. А вот оценку вероятности появления атаки лучше доверять техническим сотрудникам фирмы. 35 Следующим этапом составляется табл. 2.3. - таблица рисков предприятия. Она имеет следующий вид. Таблица 2.3. Таблица рисков Описание атаки У щерб Вероя тность Риск (=Ущерб*Вероятность) Спам (переполнение почтового ящика) 1 4 4 Копирование жесткого диска из центрального офиса 3 1 3 2 Итого: 9 На этапе анализа таблицы рисков задаются некоторым максимально допустимым риском, например значением 7. Сначала проверяется каждая строка таблицы на не превышение риска этого значения. Если такое превышение имеет место, значит, данная строка – это одна из первоочередных целей разработки политики безопасности. Затем производится сравнение удвоенного значения (в нашем случае 7*2=14) с интегральным риском (ячейка «Итого»). Если интегральный риск превышает допустимое значение, значит, в системе набирается множество мелких погрешностей в системе безопасности, которые в сумме не дадут предприятию эффективно работать. В этом случае из строк выбираются те, которые дает самый значительный вклад в значение интегрального риска и производится попытка их уменьшить или устранить полностью. На самом ответственном этапе производится собственно разработка политики безопасности предприятия, которая обеспечит надлежащие уровни как отдельных рисков, так и интегрального риска. При ее разработке необходимо, однако, учитывать объективные проблемы, которые могут встать на пути реализации политики безопасности. Такими проблемами могут стать законы страны и международного сообщества, внутренние требования корпорации, этические нормы общества. После описания всех технических и административных мер, планируемых к реализации, производится расчет экономической стоимости данной программы. В том случае, когда финансовые вложения в программу безопасности являются неприемлимыми или просто экономически невыгодными по сравнению с потенциальным ущербом от атак, производится возврат на уровень, где мы задавались максимально допустимым риском 7 и увеличение его на один или два пункта. Завершается разработка политики безопасности ее утверждением у руководства фирмы и детальным документированием. За этим должна следовать активная реализация всех указанных в плане компонентов. Перерасчет таблицы рисков и, как следствие, модификация политики безопасности фирмы чаще всего производится раз в два года. Структурный принцип имеет фундаментальное значение и составляет основу большинства реализаций. Согласно этому принципу, для построения ПО требуются только три основные конструкции: функциональный блок; конструкция обобщенного цикла; конструкция принятия двоичного решения. Функциональный блок можно представить как отдельный вычислительный оператор или как любую другую реальную последовательность вычислений с единственным входом и единственным выходом, как в подпрограмме. Организация цикла в литературе часто упоминается как элемент DO-WHILE. Конструкция принятия двоичного решения называется 36 IF-THEN-ELSE. Эти конструкции могут сами рассматриваться как функциональные блоки, поскольку они обладают только одним входом и одним выходом. Таким образом, можно ввести преобразование операции цикла в функциональный блок и в последующем рассматривать всякий такой оператор цикла эквивалентом (несколько более сложного) функционального блока. Аналогично можно ввести преобразование конструкции принятия решения к функциональному блоку. Наконец, можно привести любую последовательность функциональных элементов к одному функциональному элементу. В то же время обратная последовательность преобразований может быть использована в процессе проектирования программы по нисходящей схеме, т.е. исходя из единственного функционального блока, который постепенно раскладывается в сложную структуру основных элементов. Принцип модульного проектирования заключается в разделении программ на функционально самостоятельные части (модули), обеспечивающие заменяемость, кодификацию, удаление и дополнение составных частей. Преимущества использования модульного принципа состоят в следующем: Упрощается отладка программ, так как ограниченный доступ к модулю и однозначность его внешнего проявления исключают влияние ошибок в других, связанных с ним, модулях на его функционирование. Обеспечивается возможность организации совместной работы больших коллективов разработчиков, так как каждый программист имеет дело с независимой от других частью программы. Повышается качество программы, так как относительно малый размер модулей и, как следствие, небольшая сложность их позволяют провести более полную проверку программы. Исследование корректности реализации и верификация АС. Понятие корректности или правильности подразумевает соответствие проверяемого объекта некоторому эталонному объекту или совокупности формализованных эталонных характеристик и правил. Корректность ПО при разработке наиболее полно определяется степенью соответствия предъявляемым к ней формализованным требованиям программной спецификации. В спецификациях отражается совокупность эталонных характеристик, свойств и условий, которым должна соответствовать программа. 1 Основную часть спецификации составляют функциональные критерии и Ц характеристики. Исходной программной спецификацией, которой должна соответствовать программа, является ТЗ При отсутствии полностью формализованной спецификации требований в качестве ТЗ, которому должна соответствовать АС и результаты ee функционирования, иногда используются неформализованные предоставления разработчика, пользователя или заказчика программ. Однако понятие корректности программ по отношению к запросам пользователя или заказчика сопряжено с неопределѐнностью самого эталона, которому должна соответствовать АС. Для сложных программ всегда существует риск обнаружить их некорректность (по мнению пользователя или заказчика) при формальной корректности относительно спецификаций вследствие неточности самих спецификаций. Традиционный взгляд на спецификацию требований заключается в том, что она представляет собой документ на естественном языке, который является интерфейсом между заказчиком и изготовителем. Хотя подготовке документа может предшествовать некоторое взаимодействие, именно этот документ в значительной степени выступает как «отправная точка» для изготовителя программ. Таким образом, можно сделать вывод о том, что создание совокупности взаимоувязанных непротиворечивых спецификаций является необходимой базой для обеспечения корректности проектируемой программы. При этом спецификации должны: быть формальными; позволять проверять непротиворечивость и полноту требований заказчика; 37 служить основой для дальнейшего формализованного проектирования ОС. Существует несколько подходов к определению спецификаций требований. Спецификация как описание. Заказчик выдает спецификацию, чтобы изготовители могли снабдить его тем изделием, которое он желает, поэтому заказчик видит этот документ главным образом как описание системы, которую он желал бы иметь. В принципе, в описании должно быть указано, что должна и что не должна делать система. На практике обычно по умолчанию предполагается, что система должна делать то, что уточняется в спецификации, и не должна делать ничего более. В этом состоит главная проблема с описательной стороной спецификации. Предполагается, что заказчик всегда точно знает всѐ, что система должна и не должна делать. Более того. в дальнейшем предполагается, что заказчик полностью перенѐс это знание в специфицированный документ. Спецификация как предписание. Изготовитель смотрит на специфицированный документ как на набор составных частей, подлежащих сборке, чтобы разрешить проблему заказчика. Такой предписывающий взгляд обуславливается не только трудностями создания описательного документа (как указывалось выше), но и сведениями, которые умышленно или неумышленно расширяют или ограничивают свободу изготовителя. Договорная методология. В рамках «описание заказчика-предписание изготовителю» спецификация рассматривается как формальное разделение между сторонами. Что касается заказчика, то он оговаривает минимально приемлемое, тогда как изготовитель - максимально требуемое. Договор предлагается и принимается при зарождении системы и заканчивается после завершения системы, когда заказчик принимает систему как отвечающую его минимальным требованиям. Во время изготовления системы в принципе не предполагается никаких взаимодействий, даже если изготовитель подозревает, что предписываемое не совсем соответствует тому, что заказчик желает видеть в действительности. Спецификация как модель. Современные более строгие представления о спецификации трактуют ее как модель системы. При условии, что лежащая в основе модели семантика в достаточной мере обоснована, такая спецификация обеспечивает чѐткую формулировку требований. Соответствующие модели подходят также для автоматизированного контроля целостности и другого прогнозного анализа, который, в частности, обеспечит прекращение разработки системы, в принципе не способной удовлетворить требованиям. Модели как описание системы имеют следующие отличительные черты по сравнению с другими способами формального описания: хорошее сочетание нисходящего и восходящего подходов к их разработке с возможностью выбора абстрактного описания; возможность описания параллельной, распределенной и циклической работы; возможность выбора различных формализованных аппаратов для описания систем. Основное преимущество использования формальной модели заключается в возможности исследования с ее помощью особенностей моделируемой системы. Основывая формальный метод разработки на математической модели и затем, исследуя модель, можно выявить такие грани поведения системы, которые в противном случае не были бы очевидны до более поздних стадий. Так как целевым объектом проектирования является АС, то модель может описывать либо саму АС, либо ее поведение, т.е. внешние проявления функционирования АС. Модель, описывающая поведение АС по сравнению с моделью АС, обладает одним важным преимуществом - она может быть проверена и оценена как исполнителями, так и заказчиками, поскольку заказчики не знают, как должна работать АС, но зато они представляют, что она должна делать. В результате такого моделирования может быть проверена корректность спецификаций относительно исходной постановки задачи, т.е. ТЗ. Кроме того, критерии правильности считаются достаточными при условии, что спецификация представляет собой. 38 исчерпывающее описание «внешнего» поведения объекта при всех возможных (или запланированных) ситуациях его использования. Как было отмечено выше, при разработке АС, особенно ее компонентов, представляющих систему защиты информации, для обеспечения высоких гарантий отсутствия неисправностей и последующего доказательства того, что система функционирует согласно требованиям ТЗ, используются формальные подходы к ее проектированию. Формальное проектирование алгоритмов базируется, в основном, на языках алгоритмических логик, которые включают высказывание вида Q{S}R, читающееся следующим образом: если до исполнения оператора S было выполнено условие Q, то после него будет R'. Здесь Q называется предусловием, а R-постусловием. Эти языки были изобретены практически одновременно Р.У. Флойдом (1967 г.), С.А.Р. Хоаром (1969 г.) и учеными польской логической школы (А. Сальвицкий и др., 1970 г.). Как предусловие, так и постусловие являются предикатами. Преимущество представления алгоритма в виде преобразователя предикатов состоит в том, что оно дает возможность: анализировать алгоритмы как математические объекты; дать формальное описание алгоритма, позволяющее интеллектуально охватить алгоритм; синтезировать алгоритмы по представленным спецификациям; провести формальное верифицирование алгоритма, т.е. доказать корректность его реализации. Методология формальной разработки и доказательства корректности алгоритмов в настоящее время хорошо разработана и изложена в целом ряде работ. Вкратце суть этих методов сводится к следующему: разработка алгоритма проводится методом последовательной декомпозиции, с разбивкой общей задачи, решаемой алгоритмом, на ряд более мелких подзадач; критерием детализации подзадач является возможность их реализации с помощью одной конструкции ветвления или цикла; разбиение общей задачи на подзадачи предусматривает формулирование пред- и постусловий для каждой подзадачи с целью их корректного проектирования и дальнейшей верификации. Для доказательства корректности алгоритма (верификация) формулируется математическая теорема Q{S}R, которая затем доказывается. Доказательство теоремы о корректности принято разбивать на две части. Одна часть служит для доказательства того, что рассматриваемый алгоритм вообще может завершить работу (проводится анализ всех циклов). В другой части доказывается корректность постусловия в предположении, что алгоритм завершает работу. Теория безопасных систем (ТСВ). Понятие «доверенная вычислительная среда» (trusted computing base-ТСВ) появилось в зарубежной практике обеспечения информационной безопасности достаточно давно. Смысл характеристики «доверенная» можно пояснить следующим образом. Дискретная природа характеристики «безопасный» (в том смысле, что либо нечто является безопасным, полностью удовлетворяя ряду предъявляемых требований, либо не является, если одно или несколько требований не выполнены) в сочетании с утверждением «ничто не бывает безопасным на сто процентов» подталкивают к тому, чтобы вести более гибкий термин, позволяющий оценивать то, в какой степени разработанная защищенная АС соответствует ожиданиям заказчиков. В этом отношении характеристика «доверенный» более адекватно отражает ситуацию, где оценка, выраженная этой характеристикой (безопасный или доверенный), основана не на мнении разработчиков, а на совокупности факторов, включая мнение независимой экспертизы, опыт предыдущего сотрудничества с разработчиками, и в конечном итоге, является прерогативой заказчика, а 39 не разработчика. Доверенная вычислительная среда (ТСВ) включает все компоненты и механизмы защищенной автоматизированной системы, отвечающие за реализацию политики безопасности - комплекс превентивных мер по защите конфиденциальных данных и информационных процессов на предприятии. Политика безопасности включает в себя требования в адрес персонала, менеджеров и технических служб. Основные направления разработки политики безопасности: определение какие данные и насколько серьезно необходимо защищать, определение кто и какой ущерб может нанести фирме в информационном аспекте, вычисление рисков и определение схемы уменьшения их до приемлемой величины. Все остальные части АС, а также ее заказчик полагаются на то, что ТСВ корректно реализует заданную политику безопасности даже в том случае, если отдельные модули или подсистемы АС разработаны высококвалифицированными злоумышленниками с тем, чтобы вмешаться в функционирование ТСВ и нарушить поддерживаемую ею политику безопасности. Минимальный набор компонентов, составляющий доверенную вычислительную среду, обеспечивает следующие функциональные возможности: взаимодействие с аппаратным обеспечением АС; защиту памяти; функции файлового ввода-вывода; управление процессами. Дополнение и модернизация существующих компонентов АС с учетом требований безопасности могут привести к усложнению процессов сопровождения и документирования. С другой стороны, реализация всех перечисленных функциональных возможностей в рамках централизованной доверенной вычислительной среды в полном объеме может вызвать разрастание размеров ТСВ и, как следствие, усложнение доказательства корректности реализации политики безопасности. Так, операции с файлами могут быть реализованы в ТСВ в некотором ограниченном объеме, достаточном для поддержания политики безопасности, а расширенный ввод-вывод в таком случае реализуется в той части АС, которая находится за пределами ТСВ. Кроме того, необходимость внедрения связанных с безопасностью функций во многие компоненты АС, реализуемые в различных модулях АС, приводит к тому, что защитные функции распределяются по всей АС, вызывая аналогичную проблему. Определены следующие этапы разработки защищенной АС: определение политики безопасности; проектирование модели АС; разработка кода АС; обеспечение гарантий соответствия реализации заданной политике. |