Заглавная страница Избранные статьи Случайная статья Познавательные статьи Новые добавления Обратная связь КАТЕГОРИИ: АрхеологияБиология Генетика География Информатика История Логика Маркетинг Математика Менеджмент Механика Педагогика Религия Социология Технологии Физика Философия Финансы Химия Экология ТОП 10 на сайте Приготовление дезинфицирующих растворов различной концентрацииТехника нижней прямой подачи мяча. Франко-прусская война (причины и последствия) Организация работы процедурного кабинета Смысловое и механическое запоминание, их место и роль в усвоении знаний Коммуникативные барьеры и пути их преодоления Обработка изделий медицинского назначения многократного применения Образцы текста публицистического стиля Четыре типа изменения баланса Задачи с ответами для Всероссийской олимпиады по праву Мы поможем в написании ваших работ! ЗНАЕТЕ ЛИ ВЫ?
Влияние общества на человека
Приготовление дезинфицирующих растворов различной концентрации Практические работы по географии для 6 класса Организация работы процедурного кабинета Изменения в неживой природе осенью Уборка процедурного кабинета Сольфеджио. Все правила по сольфеджио Балочные системы. Определение реакций опор и моментов защемления |
Исследование корректности реализации и верификация АС⇐ ПредыдущаяСтр 15 из 15
Понятие корректности или правильности подразумевает соответствие проверяемого объекта некоторому эталонному обьекту или совокупности формализованных эталонных характеристик и правил. Корректность ПО при разработке наиболее полно определяется степенью соответствия предъявляемым к ней формализованным требованиям программной спецификации. В спецификациях отражается совокупность эталонных характеристик, свойств и условий, которым должна соответствовать программа. Основную часть спецификации составляют функциональные критерии и характеристики. Исходной программной спецификацией, которой должна соответствовать программа, является ТЗ. При отсутствии полностью формализованной спецификации требований в качестве ТЗ, которому должна соответствовать АС и результаты ее функционирования, иногда используются неформализованные представления разработчика, пользователя или заказчика программ. Однако понятие корректности программ по отношению к запросам пользователя или заказчика сопряжено с неопределённостью самого эталона, которому должна соответствовать АС. Для сложных программ всегда существует риск обнаружить их некорректность (по мнению пользователя или заказчика) при формальной корректности относительно спецификаций вследствие неточности самих спецификаций. Традиционный взгляд на спецификацию требований заключается в том, что она представляет собой документ на естественном языке, который является интерфейсом между заказчиком и изготовителем. Хотя подготовке документа может предшествовать некоторое взаимодействие, именно этот документ в значительной степени выступает как "отправная точка" для изготовителя программ. Таким образом, можно сделать вывод о том, что создание совокупности взаимоувязанных непротиворечивых спецификаций является необходимой базой для обеспечения корректности проектируемой программы. При этом спецификации должны: • быть формальными; • позволять проверять непротиворечивость и полноту требований заказчика; • служить основой для дальнейшего формализованного проектирования ОС. Существует несколько подходов к определению спецификаций требований. Спецификация как описание. Заказчик выдает спецификацию, чтобы изготовители могли снабдить его тем изделием, которое он желает, поэтому заказчик видит этот документ главным образом как описание системы, которую он желал бы иметь. В принципе, в описании должно быть указано, что должна и что не должна делать система. На практике обычно по умолчанию предполагается, что система должна делать то, что уточняется в спецификации, и не должна делать ничего более. В этом состоит главная проблема с описательной стороной спецификации. Предполагается, что заказчик всегда точно знает всё, что система должна и не должна делать. Более того, в дальнейшем предполагается, что заказчик полностью перенёс это знание в специфицированный документ.
Спецификация как предписание. Изготовитель смотрит на специфицированный документ как на набор составных частей, подлежащих сборке, чтобы разрешить проблему заказчика. Такой предписывающий взгляд обуславливается не только трудностями создания описательного документа (как указывалось выше), но и сведениями, которые умышленно или неумышленно расширяют или ограничивают свободу изготовителя. Договорная методология. В рамках "описание заказчика-предписание изготовителю" спецификация рассматривается как формальное разделение между сторонами. Что касается заказчика, то он оговаривает минимально приемлемое, тогда как изготовитель - максимально требуемое. Договор предлагается и принимается при зарождении системы и заканчивается после завершения системы, когда заказчик принимает систему как отвечающую его минимальным требованиям. Во время изготовления системы в принципе не предполагается никаких взаимодействий, даже если изготовитель подозревает, что предписываемое не совсем соответствует тому, что заказчик желает видеть в действительности. Спецификация как модель. Современные более строгие представления о спецификации трактуют ее как модель системы. При условии, что лежащая в основе модели семантика в достаточной мере обоснована, такая спецификация обеспечивает чёткую формулировку требований. Соответствующие модели подходят также для автоматизированного контроля целостности и другого прогнозного анализа, который, в частности, обеспечит прекращение разработки системы, в принципе не способной удовлетворить требованиям.
Модели как описание системы имеют следующие отличительные черты по сравнению сдругими способами формального описания: • хорошее сочетание нисходящего и восходящего подходов к их разработке с возможностью выбора абстрактного описания; • возможность описания параллельной, распределенной и циклической работы; • возможность выбора различных формализованных аппаратов для описания систем. Основное преимущество использования формальной модели заключается в возможности исследования с ее помощью особенностей моделируемой системы. Основывая формальный метод разработки на математической модели и затем исследуя модель, можно выявить такие грани поведения системы, которые в противном случае не были бы очевидны до более поздних стадий. Так как целевым объектом проектирования является АС, то модель может описывать либо саму АС, либо ее поведение, т.е. внешние проявления функционирования АС. Модель, описывающая поведение АС по сравнению с моделью АС, обладает одним важным преимуществом - она может быть проверена и оценена как исполнителями, так и заказчиками, поскольку заказчики не знают, как должна работать АС, но зато они представляют, что она должна делать. В результате такого моделирования может быть проверена корректность спецификаций относительно исходной постановки задачи, т.е. ТЗ. Кроме того, критерии правильности считаются достаточными при условии, что спецификация представляет собой исчерпывающее описание "внешнего" поведения объекта при всех возможных (или запланированных) ситуациях его использования. Как было отмечено выше, при разработке АС, особенно ее компонентов, представляющих систему защиты информации, для обеспечения высоких гарантий отсутствия неисправностей и последующего доказательства того, что система функционирует согласно требованиям ТЗ, используются формальные подходы к ее проектированию. Формальное проектирование алгоритмов базируется, в основном, на языках алгоритмических логик, которые включают высказывание вида Q {S} R, читающееся следующим образом: "если до исполнения оператора S было выполнено условие Q, то после него будет R". Здесь Q называется предусловием, a R - постусловием. Эти языки были изобретены практически одновременно Р.У.Флойдом (1967г.), С.А.Р.Хоаром (1969г.) и учеными польской логической школы (А. Сапьвицкий и др., 1970 г.}. Как предусловие, так и постусловие являются предикатами. Рассмотрение программ в качестве некоего "преобразователя предикатов" позволяет прямо определить связь между начальными и конечными состояниями без каких-либо ссылок на промежуточные состояния, которые могут возникнуть во время выполнения программы. Преимущество представления алгоритма в виде преобразователя предикатов состоит в том, что оно дает возможность: • анализировать алгоритмы как математические обьекты; • дать формальное описание алгоритма, позволяющее интеллектуально охватить алгоритм; • синтезировать алгоритмы по представленным спецификациям;
• провести формальное верифицирование алгоритма, т.е. доказать корректность его реализации. Методология формальной разработки и доказательства корректности алгоритмов в настоящее время хорошо разработана и изложена в целом ряде работ. Вкратце суть этих методов сводится к следующему: • разработка алгоритма проводится методом последовательной декомпозиции, с разбивкой общей задачи, решаемой алгоритмом, на ряд более мелких подзадач; • критерием детализации подзадач является возможность их реализации с помощью одной конструкции ветвления или цикла; • разбиение общей задачи на подзадачи предусматривает формулирование пред- и постусловий для каждой подзадачи с целью их корректного проектирования и дальнейшей верификации. Для доказательства корректности алгоритма (верификация) формулируется математическая теорема Q{S}R, которая затем доказывается. Доказательство теоремы о корректности принято разбивать на две части. Одна часть служит для доказательства того, что рассматриваемый алгоритм вообще может завершить работу (проводится анализ всех циклов). В другой части доказывается корректность постусловия в предположении, что алгоритм завершает работу.
Теория безопасных систем (ТСВ) Понятие "доверенная вычислительная среда" (trusted computing base - TCB) появилось в зарубежной практике обеспечения информационной безопасности достаточно давно. Смысл характеристики "доверенная" можно пояснить следующим образом. Дискретная природа характеристики "безопасный" (в том смысле, что либо нечто является безопасным, полностью удовлетворяя ряду предъявляемых требований, либо не является, если одно или несколько требований не выполнены) в сочетании с утверждением "ничто не бывает безопасным на сто процентов" подталкивают к тому, чтобы вести более гибкий термин, позволяющий оценивать то, в какой степени разработанная защищенная АС соответствует ожиданиям заказчиков. В этом отношении характеристика "доверенный" более адекватно отражает ситуацию, где оценка, выраженная этой характеристикой (безопасный или доверенный), основана не на мнении разработчиков, а на совокупности факторов, включая мнение независимой экспертизы, опыт предыдущего сотрудничества с разработчиками, и в конечном итоге, является прерогативой заказчика, а не разработчика. Доверенная вычислительная среда (ТСВ) включает все компоненты и механизмы защищенной автоматизированной системы, отвечающие за реализацию политики безопасности (понятие политики безопасности рассматривается в гл. 4). Все остальные части АС, а также ее заказчик полагаются на то, что ТСВ корректно реализует заданную политику безопасности даже в том случае, если отдельные модули или подсистемы АС разработаны высококвалифицированными злоумышленниками с тем, чтобы вмешаться в функционирование ТСВ и нарушить поддерживаемую ею политику безопасности.
Минимальный набор компонентов, составляющий доверенную вычислительную среду, обеспечивает следующие функциональные возможности: • взаимодействие с аппаратным обеспечением АС; • защиту памяти; • функции файлового ввода-вывода; • управление процессами. Некоторые из перечисленных компонентов были рассмотрены в данном разделе. Дополнение и модернизация существующих компонентов АС с учетом требований безопасности могут привести к усложнению процессов сопровождения и документирования. С другой стороны, реализация всех перечисленных функциональных возможностей в рамках централизованной доверенной вычислительной среды в полном объеме может вызвать разрастание размеров ТСВ и, как следствие, усложнение доказательства корректности реализации политики безопасности. Так, операции с файлами могут быть реализованы в ТСВ в некотором ограниченном объеме, достаточном для поддержания политики безопасности, а расширенный ввод-вывод в таком случае реализуется в той части АС,,которая находится за пределами ТСВ. Кроме того, необходимость внедрения связанных с безопасностью функций во многие компоненты АС, реализуемые в различных модулях АС, приводит к тому, что защитные функции распределяются по всей АС, вызывая аналогичную проблему. Представляется оправданной реализация доверенной вычислительной среды в виде небольшого и эффективного (в терминах исполняемого кода} ядра безопасности (см. гл.4), где сосредоточены все механизмы обеспечения безопасности. В связи с перечисленными выше соображениями, а также с учетом определенной аналогии между данными понятиями такой подход предполагает изначальное проектирование АС с учетом требований безопасности. При этом в рамках излагаемой теории определены следующие этапы разработки защищенной АС: • определение политики безопасности; • проектирование модели АС; • разработка кода АС; • обеспечение гарантий соответствия реализации заданной политике безопас-ности.
СПИСОК ЛИТЕРАТУРЫ
1. Барсуков B.C. Обеспечение информационной безопасности/Яехнологии электронных коммуникаций. Т.63.-М.: Эко-Трендз Ко, 1996. 2. Березин Б.В., Дорошкевич П. В. Цифровая подпись на основе традиционной криптографии. II Защита информации.-1992.- № 2. 3. ВасипецВ.И., Голованов В. Н., Самотуга В. А. Практика обеспечения информационной безопасности акционерного общества // Конфидент. 4'95. 4. Варфоломеев А.А., Пеленицин М. Б. Методы криптографии и их применение в банковских технологиях, -М., МИФИ, 1995.
5. Водолазкий В.В, Коммерческие системы шифрования: основные алгоритмы и их реализация // Монитор. 5-7.92, 8.92, 6.93. 6. Гайкович В.Ю., Першин А.Ю. Безопасность электронных банковских систем -М.: Компания "Единая Европа", 1994. 7. Гроувер Д. и др. Защита программного обеспечения: Пер. с англ.-М.: Мир, 1992. 8. Жельников В. Криптография от папируса до компьютера.- М.: ABF, 1996. 9. Клопов В.Д., Мотуз О.В. Основы компьютерной стеганографии // Конфидент.-4'97. 10. ЛипаевВ.В. Программно-технологическая безопасность информационных систем // Информационный бюллетень Jei info.-1997. № 6/7. 11. Мафтик С. Механизмы защиты в сетях.-М.: Мир, 1993. 12. Мельников В. В. Защита информации в компьютерных системах-М.: Финансы и статистика-Электроинформ, 1997. 13. Мур Дж.Х. Несостоятельность протоколов криптосистем: Пер. с англ.// ТИИ-ЭР.-1938.-Т.76, N95. 14. Правиков Д.И. Применение циклического контрольного кода // Библиотека информационной технологии/Сб. ст. под ред. Г.Р.Громова.-М.: ИнфоАрт, 1992.-Вып.5. 15. Правиков Д.И. Разработка и исследование методов создания корректных операционных систем реального времени: Дис. канд. тех. науи.-М., 1994. 16. Прокофьев И.В., ШрамковИ.Г, Щербаков А. Ю. Введение в теоретические основы компьютерной безопасности - М.: Издательство МГИЭМ, 1998. 17. РасторгуевС.П. Программные методы защиты информации в компьютерах и сетях.-М.: "Яхтсмен", 1993. 18. Ронин Р. Своя разведка, - Минск: Харвест, 1997. 19. Сапомаа А. Криптография с открытым ключом: Пер. с англ.-М.: "Мир", 1996- 20. Симмонс Г.Дж. Обзор методов аутентификации информации: Пер. с англ.// ТИИЭР.-1988.-Т.76, N25. 21. Спесивцев А.В. и др. Защита информации в персональных ЭВМ.-М.: Радио и связь, 1992. 22. Щербаков А.Ю. Разрушающие программные воздействия.-М.: Эдэль, 1993- 23. Организация и современные методы защиты информации-М.: Концерн "Банковский деловой центр", 1993. 24. Гостехкомиссия России, Руководящий документ: Защита от несанкционированного доступа к информации. Термины и определения.-М.: Военное издательство, 1992. 25. Clark D., Wilson D. A comparison of Commercial and Military Computer Security Policies// Proce. of the 1987 IEEE Symposium on Security and Privacy.- Oakland, Cal., 1987. 26. Saltzer J., ScrtroederM.D. The protection of Information in Computer Systems// Proce. of the IEEE.-September1975.-63(9):1278-!3Q8. Порядок выполнения работы 1.Ознакомиться с методологией построения систем защиты информации в АС. 2.Выполнить практическое задание. 3.Ответить на контрольные вопросы.
3. Практические задания 1. Разработать интерфейс пользователя «ПОСТРОЕНИЕ СИСТЕМ ЗАЩИТЫ ОТ УГРОЗЫ НАРУШЕНИЯ КОНФИДЕНЦИАЛЬНОСТИ ИНФОРМАЦИИ». 2. Разработать интерфейс пользователя «ПОСТРОЕНИЕ СИСТЕМ ЗАЩИТЫ ОТ УГРОЗЫ НАРУШЕНИЯ ЦЕЛОСТНОСТИ ИНФОРМАЦИИ». 3. Разработать интерфейс пользователя «ПОСТРОЕНИЕ СИСТЕМ ЗАЩИТЫ ОТ УГРОЗЫ ОТКАЗА ДОСТУПА К ИНФОРМАЦИИ». 4. Разработать интерфейс пользователя «ПОСТРОЕНИЕ СИСТЕМ ЗАЩИТЫ ОТ УГРОЗЫ РАСКРЫТИЯ ПАРАМЕТРОВ ИНФОРМАЦИОННОЙ СИСТЕМЫ» 5. Разработать интерфейс пользователя «МЕТОДОЛОГИЯ ПОСТРОЕНИЯ ЗАЩИЩЕННЫХ АС».
4. Контрольные вопросы 1) Описать порядок действий злоумышленника с целью получения доступа к информации на машинном носителе. 2) Что такое учетная запись пользователя? 3) Перечислить требования к СКЗИ. 4) Что такое корректное использование МРКФ? 5) Назвать правило Е2 модели Кларка-Вилсона.
|
|||||||||
Последнее изменение этой страницы: 2017-01-27; просмотров: 360; Нарушение авторского права страницы; Мы поможем в написании вашей работы! infopedia.su Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Обратная связь - 3.15.10.137 (0.036 с.) |