Тема лекции № 6. Методология проектирования систем защиты информации (СЗИ).

Учебные вопросы:

1. Общие сведения о проектировании СЗИ. Стадии проектирования и основные подходы к встраиванию СЗИ.

2. Принципы и методы построения защищённых АС.

3. Место и роль спецификации при проектировании СЗИ.

4. Теория безопасных систем (ТСВ).

Вопрос №1.

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

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

Состав система защиты информации включает следующие подсистемы (слайд):

· защиты от несанкционированного доступа;

· управления учетными записями и правами доступа;

· комплексной антивирусной защиты;

· межсетевого экранирования;

· обнаружения вторжений, контроля и анализа защищенности;

· криптографической защиты;

· управления средствами защиты информации;

· обеспечения безопасности коммутируемой инфраструктуры и беспроводных сетей;

· контроля использования информационных ресурсов;

· управления событиями и инцидентами ИБ;

· контроля эффективности защиты информации;

· обеспечения непрерывности функционирования средств защиты.

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

Проектирование включает следующие шаги(слайд):

• разработку решений по архитектуре системы защиты информации (ЗИ);
• разработку средств ЗИ и контроля;

• разработка технического проекта СЗИ;

• разработку рабочей документации СЗИ;

• подготовку и оформление технической документации на поставку технических и программных средств для СЗИ;

• проектирование помещений АС с учетом требований нормативных документов по защите информации;

• разработку порядка сопровождения СЗИ в АС;

• разработку порядка и этапов внедрения СЗИ, консультирование Заказчика при внедрении СЗИ.

Существуют возможности по реализации отдельных подсистем, которые требуются для достижения каких-либо конкретных целей. Отдельные подсистемы защиты информации реализуются на основе: Cisco Systems, Oracle, Check Point Software Techologies Ltd, Microsoft, CryptoPro, S-Terra, НИП «Информзащита», Лаборатория Касперского, WatchGuard, GFI и т.д.

Помимо использования наложенных средств защиты информации, возможно использование встроенных механизмов обеспечения информационной безопасности в операционные системы, базы данных, сетевое оборудование.

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

Существуют два основных подхода к практической реализации ЗАС (защищенных автоматизированных систем) (слайд).

Первый подход состоит в разработке и внедрению новых информационно-вычислительных систем (АС), в рамках которых решается весь комплекс проблем информационной безопасности. Этот подход является наиболее перспективным. Однако в процессе функционирования уже созданных ЗАС может понадобиться встраивание новых элементов защиты, что уже относится ко второму подходу.

Второй подход состоит в разработке подсистем защиты информации, объединении их в единую систему защиты, налагаемую на уже созданную АС, в которой изначально не предусматривался полный комплекс защитных механизмов. На практике данный подход до настоящего времени является достаточно распространенным, поскольку большое число широко используемых ОС, СУБД и других информационных систем изначально были созданы без должного отношения к проблеме защиты информации.

Вопрос №2.

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

Рассмотрим методы построения защищённых АС. Эти методы условно можно разделить на две группы (слайд):

- относящиеся к произвольному по АС:

• иерархический метод;

• исследование корректности и верификация.

- специфичные только для систем защиты (теория безопасных систем).

В соответствии с принципом абстракции при проектировании АС разработчики могут идти, по меньшей мере, двумя путями: от аппаратуры "вверх" - к виртуальной машине, представляющей АС, или от виртуальной машины "вниз" - к реальному оборудованию. Это и есть два основных метода проектирования - метод снизу вверх и метод сверху вниз. Остальные методы по своей сути сводятся к этим двум или являются их сочетанием.

Метод «снизу вверх» предполагает начало проектирования с основного аппаратного оборудования системы. При проектировании модули разбиваются на ряд слоев, причём нулевой слой виртуальной системы образует аппаратура. Слои, реализующие одно или несколько необходимых свойств, добавляются последовательно, пока не будет получена желаемая виртуальная машина.

К недостаткам метода «снизу вверх»относят:

• необходимость с самого начала принимать решение о выборе способа реализации компонентов АС - с помощью аппаратуры, микропрограмм или программ, что сделать очень трудно;

• возможность проектирования АС только после разработки аппаратуры;

• расхождение между реальной АС и определённой в ТЗ.

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

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

• функциональный блок;

• конструкция обобщенного цикла;

• конструкция принятия двоичного решения.

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

Конструкция принятия двоичного решения называется IF-THEN-ELSE.

Заметим, что эти конструкции могут сами рассматриваться как функциональные блоки, поскольку они обладают только одним входом и одним выходом. Таким образом, можно ввести преобразование операции цикла в функциональный блок и в последующем рассматривать всякий такой оператор цикла эквивалентом (несколько более сложного) функционального блока. Аналогично можно ввести преобразование конструкции принятия решения к функциональному блоку. Наконец, можно привести любую последовательность функциональных элементов к одному функциональному элементу. В то же время обратная последовательность преобразований может быть использована в процессе проектирования программы по нисходящей схеме, т.е. исходя из единственного функционального блока, который постепенно раскладывается в сложную структуру основных элементов.

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

Преимущества использования модульного принципа состоят в следующем:

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

• обеспечивается возможность организации совместной работы больших коллективов разработчиков, так как каждый программист имеет дело с независимой от других частью программы;

• повышается качество программы, так как относительно малый размер модулей и, как следствие, небольшая сложность их позволяют провести более полную проверку программы.

Вопрос №3.

Понятие корректности или правильности подразумевает соответствие проверяемого объекта некоторому эталонному объекту или совокупности формализованных эталонных характеристик и правил.

Корректность при разработке наиболее полно определяется степенью соответствия предъявляемым к ней формализованным требованиям спецификации. В спецификациях отражается совокупность эталонных характеристик, свойств и условий, которым должно соответствовать проектируемое изделие. Основную часть спецификации составляют функциональные критерии и характеристики. Исходной спецификацией, которой должно соответствовать изделие, является ТЗ.

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

Традиционный взгляд на спецификацию требований заключается в том, что она представляет собой документ на естественном языке, который является интерфейсом между заказчиком и изготовителем. Хотя подготовке документа может предшествовать некоторое взаимодействие, именно этот документ в значительной степени выступает как "отправная точка" для изготовителя.

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

– быть формальными;

– позволять проверять непротиворечивость и полноту требований заказчика;

– служить основой для дальнейшего формализованного проектирования.

Существует несколько подходов к определению спецификаций требований (слайд).

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

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

Договорная методология. В рамках "описание заказчика - предписание изготовителю" спецификация рассматривается как формальное разделение между сторонами. Что касается заказчика, то он оговаривает минимально приемлемое, тогда как изготовитель - максимально требуемое. Договор предлагается и принимается при зарождении системы и заканчивается после завершения системы, когда заказчик принимает систему как отвечающую его минимальным требованиям. Во время изготовления системы в принципе не предполагается никаких взаимодействий, даже если изготовитель подозревает, что предписываемое не совсем соответствует тому, что заказчик желает видеть в действительности.

Спецификация как модель. Современные более строгие представления о спецификации трактуют ее как модель системы. При условии, что лежащая в основе модели семантика в достаточной мере обоснована, такая спецификация обеспечивает чёткую формулировку требований.

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

Модели как описание системы имеют следующие отличительные черты по сравнению с другими способами формального описания (слайд):

• хорошее сочетание нисходящего и восходящего подходов к их разработке с возможностью выбора абстрактного описания;

• возможность описания параллельной, распределенной и циклической работы;

• возможность выбора различных формализованных аппаратов для описания систем.

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

Так как целевым объектом проектирования является АС, то модель может описывать либо саму АС, либо ее поведение, т.е. внешние проявления функционирования АС. Модель, описывающая поведение АС по сравнению с моделью АС, обладает одним важным преимуществом - она может быть проверена и оценена как исполнителями, так и заказчиками, поскольку заказчики не знают, как должна работать АС, но зато они представляют, что она должна делать. В результате такого моделирования может быть проверена корректность спецификацийотносительноисходной постановки задачи, т.е. ТЗ. Кроме того, критерии правильности считаются достаточными при условии, что спецификация представляет собой исчерпывающее описание "внешнего" поведения объекта при всех возможных (или запланированных) ситуациях его использования.

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

Формальное проектирование алгоритмов базируется, в основном, на языках алгоритмических логик, которые включают высказывание вида (слайд):

Q {S} R,

читающееся следующим образом: "если до исполнения оператора S было выполнено условие Q, то после него будет R". Здесь Q называется предусловием, а R-постусловием. Эти языки были изобретены практически одновременно Р.У. Флойдом (1967 г.), С.А. Р. Хоаром (1969 г.) и учеными польской логической школы (А. Сальвицкий и др., 1970 г.). Как предусловие. так и постусловие являются предикатами.

Рассмотрение программ в качестве некоего "преобразователя предикатов" позволяет прямо определить связь между начальными и конечными состояниями без каких-либо ссылок на промежуточные состояния, которые могут возникнуть во время выполнения программы.

Преимущество представления алгоритма в виде преобразователя предикатов состоит в том, что оно дает возможность (слайд):

• анализировать алгоритмы как математические объекты;

• дать формальное описание алгоритма, позволяющее интеллектуально охватить алгоритм;

• синтезировать алгоритмы по представленным спецификациям;

• провести формальное верифицирование алгоритма, т.е. доказать корректность его реализации.

Методология формальной разработки и доказательства корректности алгоритмов в настоящее время хорошо разработана и изложена в целом ряде работ. Вкратце суть этих методов сводится к следующему (слайд):

• разработка алгоритма проводится методом последовательной декомпозиции, с разбивкой общей задачи, решаемой алгоритмом, на ряд более мелких подзадач;

• критерием детализации подзадач является возможность их реализации с помощью одной конструкции ветвления или цикла;

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

Для доказательства корректности алгоритма (верификация) формулируется математическая теорема Q{S}R, которая затем доказывается. Доказательство теоремы о корректности принято разбивать на две части. Одна часть служит для доказательства того, что рассматриваемый алгоритм вообще может завершить работу (проводится анализ всех циклов). В другой части доказывается корректность постусловия в предположении, что алгоритм завершает работу.

Вопрос №4.

Понятие "доверенная вычислительная среда" (trusted computing base-ТСВ) появилось в зарубежной практике обеспечения информационной безопасности достаточно давно. Смысл характеристики "доверенная" можно пояснить следующим образом.

Дискретная природа характеристики "безопасный" (в том смысле, что либо нечто является безопасным, полностью удовлетворяя ряду предъявляемых требований, либо не является, если одно или несколько требований не выполнены) в сочетании с утверждением "ничто не бывает безопасным на сто процентов" подталкивают к тому, чтобы вести более гибкий термин, позволяющий оценивать то, в какой степени разработанная защищенная АС соответствует ожиданиям заказчиков.

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

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

Минимальный набор компонентов, составляющий доверенную вычислительную среду, обеспечивает следующие функциональные возможности (слайд):

• взаимодействие с аппаратным обеспечением АС;

• защиту памяти;

• функции файлового ввода-вывода;

• управление процессами.

Некоторые из перечисленных компонентов были рассмотрены в данном разделе.

Дополнение и модернизация существующих компонентов АС с учетом требований безопасности могут привести к усложнению процессов сопровождения и документирования. С другой стороны, реализация всех перечисленных функциональных возможностей в рамках централизованной доверенной вычислительной среды в полном объеме может вызвать разрастание размеров ТСВ и, как следствие, усложнение доказательства корректности реализации политики безопасности. Так, операции с файлами могут быть реализованы в ТСВ в некотором ограниченном объеме, достаточном для поддержания политики безопасности, а расширенный ввод-вывод в таком случае реализуется в той части АС, которая находится за пределами ТСВ. Кроме того, необходимость внедрения связанных с безопасностью функций во многие компоненты АС, реализуемые в различных модулях АС, приводит к тому, что защитные функции распределяются по всей АС, вызывая аналогичную проблему.

Представляется оправданной реализация доверенной вычислительной среды в виде небольшого и эффективного (в терминах исполняемого кода) ядра безопасности, где сосредоточены все механизмы обеспечения безопасности. В связи с перечисленными выше соображениями, а также с учетом определенной аналогии между данными понятиями такой подход предполагает изначальное проектирование АС с учетом требований безопасности. При этом в рамках излагаемой теории определены следующие этапы разработки защищенной АС (слайд):

• определение политики безопасности;

• проектирование модели АС;

• разработка кода АС;

• обеспечение гарантий соответствия реализации заданной политике безопасности.

Процесс создания автоматизированных систем в защищенном ис­полнении (АСЗИ) заключается в выполнении совокупности мероприятий, направ­ленных на разработку и/или практическое применение информационной технологии, реализую­щей функции по ЗИ, установленные в соответствии с требованиями стандартов и/или НД по ЗИ как во вновь создаваемых, так и в действующих АС.

Таким стандартом является ГОСТ Р 51583—2000 «Защита информации. Порядок создания автоматизированных систем в защищённом исполнении».

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

Настоящий стандарт устанавливает дополнительные требования и положения стандартов класса 34 “Информационная технология. Комплекс стандартов на автоматизированные системы” в части порядка создания и применения автоматизированных систем в защищенном исполнении.

Стандарт даёт определение основных терминов и понятий в области защиты в информации и создания автоматизированных систем в защищённом исполнении.

Гост определяет, что целью создания АСЗИ является исключение или существенное затруднение получения злоумышленником защищаемой информации, обрабатываемой в АС, а также исключение или су­щественное затруднение несанкционированного и/или непреднамеренного воздействия на защи­щаемую информацию и ее носители.

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

Разработка и внедрение вновь создаваемой АС производится в соответствии с ТЗ на АС, которое является основным документом, определяющим требования, предъявляемые к АС, поря­док создания АС и приемку АС при вводе в действие.

Для вновь создаваемых AC T3 разрабатывают на систему в целом, предназначенную для работы самостоятельно или в составе другой системы. Дополнительно могут быть разработаны ЧТЗ на части и подсистемы АС. Поэтому требования по ЗИ при создании АСЗИ должны включаться разделом в общее ТЗ на АС или могут быть изложены в виде частного ЧТЗ или дополнения к основ­ному ТЗ на АС.

Порядок утверждения и согласования ЧТЗ (дополнения к основному ТЗ на АС) не должен отличаться от установленного порядка утверждения и согласования ТЗ на АС по ГОСТ 34.602.

Для АСЗИ, создаваемой на базе действующей АС, разрабатывают ТЗ (ЧТЗ) или дополнение к основному ТЗ на АС, в которые включают требования по ЗИ только в части создаваемой системы (подсистемы) защиты обрабатываемой информации в АС.

Утверждение и согласование ТЗ (ЧТЗ) или дополнения к основному ТЗ на АС производится в порядке, установленном ГОСТ 34.602.

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

Основные принципы и положения по созданию и функционированию АСЗИ должны соответствовать требованиям ГОСТ 29339, ГОСТ Р 50543, ГОСТ Р 50739, ГОСТ Р 51275, ГОСТ РВ 50797 др. нормативных документов.

Вычислительную сеть или АС можно считать безопасной в смысле обработки информации, если в ней предусмотрена централизованная система управляемых и взаимосвязанных преград, перекрывающих с гарантированной прочностью заданное в соответствии с моделью потенциального нарушителя количество возможных каналов НСД и угроз, направленных на утрату или модификацию информации, а так же несанкционированное ознакомление с нею посторонних лиц.

Контрольные вопросы

6. В чём состоит построение системы защиты информации?

7. Назовите недостатки метода «снизу вверх».

8. Какие принципы проектирования используют в иерархическом методе?

9. В чём состоит принцип модульного проектирования?

10. Что такое спецификация требований программного обеспечения?

11. Что такое доверенная вычислительная среда?