ПР6 Методология обследования и проектирования защищенных информационных (автоматизированных) систем.

1. Корректность реализации и верификация информационных (автоматизированных) систем. Понятие корректности или правильности проверяемого объекта. (см. вопрос 9). Спецификация требований программного обеспечения.

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

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

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

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

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

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

2. Представления функциональных требований. Рекомендации к структуре и методам описания программных требований. Основные ключевые требования «хорошей спецификации». Требования к программной спецификации. Основные подходы к определению спецификаций требований.

Согласно "ГОСТ Р ИСО/МЭК 15408-2-2013 Информационная технология (ИТ). Методы и средства обеспечения безопасности.

Критерии оценки безопасности информационных технологий. Часть 2. Функциональные компоненты безопасности" существуют следующие

каталоги функциональных требований к защищенным АС

· Аудит безопасности

· Связь

· Криптографическая поддержка

· Защита данных пользователя

· Идентификация и аутентификация

· Управление безопасностью

· Приватность

· Защита ФБО (функции безопасности объекта оценки)

· Использование ресурсов

· Доступ к 00 (объекту оценки)

· Доверенный маршрут/канал

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

Каждый компонент включает в себя набор элементов. Каждый элемент определяется отдельно и является самодостаточным.

Функциональный элемент - это функциональное требование безопасности, дальнейшее разделение которого не меняет значимо результат оценки. Является наименьшим функциональным требованием безопасности, идентифицируемым и признаваемым в ИСО/МЭК 15408.

При формировании ПЗ, ЗБ и/или пакетов не разрешается выбирать только часть элементов компонента. Для включения в ПЗ, ЗБ или пакет необходимо выбирать всю совокупность элементов компонента.

Вводится уникальная краткая форма имени функционального элемента. Например, имя FDP_IFF.4.2 читается следующим образом: F - функциональное требование, DP - класс "Защита данных пользователя", _IFF - семейство "Функции управления информационными потоками", 4 (после точки) - четвертый компонент "Частичное устранение неразрешенных информационных потоков", 2 (после точки) - второй элемент компонента.

3. Теория безопасных систем (ТСВ). Понятие «доверенная вычислительная среда» (trusted computing base-ТСВ). Дискретная природа характеристики «безопасный». Характеристика «доверенный». Доверенная вычислительная среда. Набор компонентов, составляющий доверенную вычислительную среду. Этапы разработки, защищённой АС. Процесс создания автоматизированных систем в защищенном исполнении (ГОСТ Р 51583—2000). Цель создания АСЗИ.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4. Сущность построения системы защиты информации. Оптимальные механизмы обеспечения защиты информации и механизмы управления. Выбор способа постановки задачи.

На основе теоретических исследований и практических работ в области ЗИ сформулирован системно-концептуальный подход к защите информации.

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

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

Комплексный (системный) подход — это принцип рассмотрения проекта, при котором анализируется система в целом, а не ее отдельные части. Его задачей является оптимизация всей системы в совокупности, а не улучшение эффективности отдельных частей. Это объясняется тем, что, как показывает практика, улучшение одних параметров часто приводит к ухудшению других, поэтому необходимо стараться обеспечить баланс противоречий требований и характеристик, а также целенаправленной организации всех работ по ЗИ.

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

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

Известный канадский специалист в области стратегического управления Г. Минцберг предложил определение стратегии в рамках системы «5-Р». По его мнению, она включает:

1) план (Plan) — заранее намеченные в деталях и контролируемые действия на определенный срок, преследующие конкретные цели;

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

3) модель поведения (Patten of behaviour) — часто спонтанного, неосознанного, не имеющего конкретных целей;

4) позицию по отношению к другим (Position in respect to others);

5) перспективу (Perspective).

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

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

Стратегия формируется под воздействием внутренней и внешней среды, постоянно развивается, ибо всегда возникает что-то новое, на что нужно реагировать.

В СЗИ должно быть предусмотрено два вида функций:

— функции, основной целью которых является создание механизмов защиты;

— функции, осуществляемые с целью непрерывного и оптимального управления механизмами защиты.

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

Общая цель управления — обеспечение максимально возможной эффективности использования ресурсов.

Задачи управления:

1. Обеспечение заданного уровня достижения цели при минимальном уровне затрат;

2. Обеспечение максимального уровня достижения цели при заданном уровне затрат.

5. Методы построения защищённых АС. Два основных метода проектирования. Метод проектирования «снизу-вверх». Недостатки метода проектирования «снизу-вверх».

Методы построения защищенных АС можно условно разделить на две группы:

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

· иерархический метод разработки

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

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

Иерархический метод разработки ПО АС

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

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

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

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

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

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

6. Иерархический метод построения защищённой АС («сверху вниз»).

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

7. Принципы проектирования. Структурный принцип и принцип модульного проектирования.

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

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

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

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

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

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

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

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

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

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

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

8. Три основных конструкции для проектирования. Использование элемента DO-WHILE для организации цикла. Конструкция принятия двоичного решения IF-THEN-ELSE. Преимущества использования модульного принципа.

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

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

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

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

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

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

9. Корректность реализации и верификация информационных (автоматизированных) систем. Понятие корректности или правильности проверяемого объекта.

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

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

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

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

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

10. Спецификация требований программного обеспечения. Функциональные критерии и характеристики. Неформализованные представления разработчика. Спецификация требований программного обеспечения (Software Requirements Specification).

Спецификация требований программного обеспечения (англ. Software Requirements Specification, SRS) — структурированный набор требований (функциональность, производительность, конструктивные ограничения и атрибуты) к программному обеспечению и его внешним интерфейсам. (Определение на основе IEEE Std 1012:2004) Предназначен для того, чтобы установить базу для соглашения между заказчиком и разработчиком (или подрядчиками) о том, как должен функционировать программный продукт.

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

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

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

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

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

11. Представления функциональных требований. Рекомендации к структуре и методам описания программных требований. Основные ключевые требования «хорошей спецификации». Требования к программной спецификации. Основные подходы к определению спецификаций требований.

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

Согласно "ГОСТ Р ИСО/МЭК 15408-2-2013 Информационная технология (ИТ). Методы и средства обеспечения безопасности.

Критерии оценки безопасности информационных технологий. Часть 2. Функциональные компоненты безопасности" существуют следующие

каталоги функциональных требований к защищенным АС

· Аудит безопасности

· Связь

· Криптографическая поддержка

· Защита данных пользователя

· Идентификация и аутентификация

· Управление безопасностью

· Приватность

· Защита ФБО (функции безопасности объекта оценки)

· Использование ресурсов

· Доступ к 00 (объекту оценки)

· Доверенный маршрут/канал

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

Каждый компонент включает в себя набор элементов. Каждый элемент определяется отдельно и является самодостаточным.

Функциональный элемент - это функциональное требование безопасности, дальнейшее разделение которого не меняет значимо результат оценки. Является наименьшим функциональным требованием безопасности, идентифицируемым и признаваемым в ИСО/МЭК 15408.

При формировании ПЗ, ЗБ и/или пакетов не разрешается выбирать только часть элементов компонента. Для включения в ПЗ, ЗБ или пакет необходимо выбирать всю совокупность элементов компонента.

Вводится уникальная краткая форма имени функционального элемента. Например, имя FDP_IFF.4.2 читается следующим образом: F - функциональное требование, DP - класс "Защита данных пользователя", _IFF - семейство "Функции управления информационными потоками", 4 (после точки) - четвертый компонент "Частичное устранение неразрешенных информационных потоков", 2 (после точки) - второй элемент компонента.

12. Теория безопасных систем (ТСВ). Понятие «доверенная вычислительная среда» (trusted computing base-ТСВ).

13. Дискретная природа характеристики «безопасный». Характеристика «доверенный». Доверенная вычислительная среда. Набор компонентов, составляющий доверенную вычислительную среду.

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

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

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

· определение какие данные и насколько серьезно необходимо защищать,

· определение кто и какой ущерб может нанести фирме в информационном аспекте,

· вычисление рисков и определение схемы уменьшения их до приемлемой величины.

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

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

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

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

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

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

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

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

Определены следующие этапы разработки защищенной АС:

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

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

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

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

14. Этапы разработки защищённой автоматизированной системы (АСЗИ). Процесс создания автоматизированных систем в защищенном исполнении (ГОСТ Р 51583—2014). Цель создания АСЗИ.

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

В ГОСТ P 51583-2014 выделен следующий комплекс работ по созданию системы защиты информации:

1. формирование требований к системе защиты информации АСЗИ;

2. разработка (проектирование) системы защиты информации АСЗИ;

3. внедрение системы защиты информации АСЗИ;

4. аттестация АСЗИ по требованиям безопасности информации и ввод в действие;

5. сопровождение системы защиты информации в ходе эксплуатации АСЗИ.