Вопросы к экзамену по курсу проектирование защищенных систем

Вопросы к экзамену по курсу
Проектирование защищенных систем (2014-15)
1. Нормативное обеспечение процессов проектирования программных комплексов и автоматизированных систем.
2. Определение понятий актива, угрозы, уязвимости, риска.
3. Общая характеристика ЕСПД.
4. Общая характеристика ЕКСАС.
5. Стадии и этапы создания АС. Содержание этапов (ГОСТ 34.601-90).
6. Порядок выполнения работ. Организация выполнения работ.
7. Подходы к оценке эффективности комплексной системы ЗИ. Классический подход.
8. Подходы к оценке эффективности комплексной системы ЗИ. Официальный подход.
9. Подходы к оценке эффективности комплексной системы ЗИ. Экспериментальный подход.
Под экспериментальным подходом понимается организация процесса определения эффективности существующих Комплексной системы защиты информации путем попыток преодоления защитных механизмов системы специалистами, выступающими в роли злоумышленников. Такие исследования проводятся следующим образом. В качестве условного злоумышленника выбирается один или несколько специалистов в области информационной борьбы наивысшей квалификации. Составляется план проведения эксперимента. В нем определяются очередность и материально-техническое обеспечение проведения экспериментов по определению слабых звеньев в системе защиты. При этом могут моделироваться действия злоумышленников, соответствующие различным моделям поведения нарушителей: от неквалифицированного злоумышленника, не имеющего официального статуса в исследуемой КС, до высококвалифицированного сотрудника службы безопасности.
Служба безопасности до момента преодоления защиты «злоумышленниками» должна ввести в Комплексной системы защиты информации новые механизмы защиты (изменить старые), чтобы избежать «взлома» системы защиты.
Такой подход к оценке эффективности позволяет получать объективные данные о возможностях существующих Комплексной системы защиты информации, но требует высокой квалификации исполнителей и больших материальных и временных затрат. Для проведения экспериментов необходимо иметь самое современное оборудование (средства инженерно-технической разведки, аппаратно-программные и испытательные комплексы (стенды) и т. п.)

10. Механизм описания требований по безопасности по методологии Общих критериев.
11. Гарантийные требования. Уровни гарантий.
Гарантии
Компьютерная система должна содержать аппаратные и/или программные механизмы, которые могут независимо определять обеспечивается ли достаточная уверенность в том, что система исполняет указанные выше требования. Вдобавок уверенность должна включать гарантию того, что безопасная часть системы работает только так, как запланировано. Для достижения этих целей необходимо два типа гарантий и соответствующих им элементов:
Механизмы гарантий
• Операционная гарантия — уверенность в том, что реализация спроектированной системы обеспечивает осуществление принятой стратегии защиты системы. Сюда относятся системная архитектура, целостность системы, анализ скрытых каналов, безопасное управление возможностями и безопасное восстановление.
• Гарантия жизненного цикла — уверенность в том, что система разработана и поддерживается в соответствии с формализованными и жестко контролируемыми критериями функционирования. Сюда относятся тестирование безопасности, задание на проектирование и его проверка, управление настройками и соответствие параметров системы заявленным.
• Гарантии непрерывной защиты — надёжные механизмы, обеспечивающие непрерывную защиту основных средств от преступных и/или несанкционированных изменений.
Уровень гарантированности[
Подразумевает меру доверия, которая может быть оказана архитектуре и реализации информационной системы, и показывает, насколько корректны механизмы, отвечающие за реализацию политики безопасности (пассивный аспект защиты).
4.1. Концепция обеспечения гарантии

Гарантийные требования формируют уверенность в том, что изделия ИТ обеспечивают достижение поставленных перед ними целей безопасности. Гарантийные требования включают совокупность требований к необходимым действиям разработчика изделия ИТ, к представлению соответствующих свидетельств обеспечения необходимой безопасности и к действиям при оценке безопасности изделия ИТ. В их состав входят следующие требования:
– к поддержке жизненного цикла;
– к процессу разработки;
– к управлению конфигурацией;
– к эксплуатационной документации;
– к тестированию;
– к анализу уязвимостей;
– к поставке и вводу в эксплуатацию;
– к поддержке доверия к безопасности при эксплуатации.
Обеспечение гарантии достигается путем оценки (активного исследования) конечного продукта или системы ИТ и документации к ним экспертами с возможно максимальным объемом и глубиной, и строгостью проводимых исследований.
Концепция обеспечения гарантии состоит в следующем:
– угрозы безопасности ИС и требования по осуществлению ПБ организации должны быть ясно сформулированы, а предложенные меры обеспечения безопасности доказуемо достаточны для решения задач безопасности;
– должны быть приняты меры по снижению вероятности наличия в системе уязвимых мест и возможностей преднамеренного использования или не преднамеренной активизации;
– должны быть приняты меры по обеспечению возможности обнаружения и ликвидации уязвимых мест, уменьшения степени проявления их признаков и для получения сведений о том, что уязвимые места использовались или активизировались.
Концепция предполагает, что могут быть нарушители, которые будут активно искать и использовать возможности нарушить ПБ в корыстных целях, активизировать уязвимости, нанося этим ущерб организации. Особенно это опасно для критически важных объектов.

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

4.2. Обеспечение гарантий на этапах жизненного цикла

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

12. Назначение комплекса стандартов «Общие критерии защищенности информационных технологий».
Разработка этого стандарта преследовала следующие основные цели:
• Унификация национальных стандартов в области оценки безопасности ИТ;
• Повышение уровня доверия к оценке безопасности ИТ;
• Сокращение затрат на оценку безопасности ИТ на основе взаимного признания сертификатов.
Общие критерии были призваны обеспечить взаимное признание результатов стандартизованной оценки безопасности на мировом рынке ИТ.
Официальный текст международного стандарта ISO/IEC 15408 [1 – 3] издан 1 декабря 1999 года. Изменения, внесенные в стандарт на завершающей стадии его принятия, учтены в версии 2.1 Общих критериев (ОК), идентичной стандарту по содержанию.
В отличие от стандарта FIPS 140[2] , Common Criteria не приводит списка требований по безопасности или списка особенностей, которые должен содержать продукт. Вместо этого он описывает инфраструктуру (framework), в которой потребители компьютерной системы могут описать требования, разработчики могут заявить о свойствах безопасности продуктов, а эксперты по безопасности определить, удовлетворяет ли продукт заявлениям. Таким образом, Common Criteria позволяет обеспечить условия, в которых процесс описания, разработки и проверки продукта будет произведён с необходимой скрупулёзностью.
В 2002 году на основе аутентичного текста ISO/IEC 15408 был принят российский стандарт ГОСТ Р ИСО/МЭК 15408-2002 «Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий», а белорусская версия общих критериев принята в 2004 году и закреплена в стандартах СТБ 34.101.1/СТБ 34.101.2/СТБ 34.101.3 – 2004.
13. Общие критерии защищенности информационных технологи. Концептуальные понятия безопасности и их взаимосвязь.

Авторизованный (полномочный) пользователь (Authorized user) – пользователь, наделенный правами выполнять операции в соответствии с политикой безопасности объекта оценки.
Активы (Assets) – информация или ресурсы, которые должны быть защищены средствами объекта оценки.
Атрибуты безопасности (Security attribute) – сведения о субъектах, пользователях и/или объектах, используемые при осуществлении политики безопасности объекта оценки.
Базовая стойкость средства безопасности (SOF-basic) – уровень стойкости средства безопасности, при котором достигается требуемая степень защищенности от случайного воздействия на объект оценки нарушителями с низким потенциалом атаки.
Внутренний канал связи (Internal communication channel) – канал связи между отдельными частями объекта оценки.
Выбор
Высокая стойкость средства безопасности (SOF-high) – уровень стойкости средств безопасности, на котором достигается требуемая степень защищенности от тщательно спланированного и организационного воздействия на объект оценки нарушителями с высоким потенциалом атаки.
Гарантия– основа уверенности в том, что продукт или система удовлетворяет своим задачам безопасности.
Данные комплекса средств безопасности объекта оценки– данные, созданные объектом оценки или для объекта оценки, которые могут влиять на его работу.
Данные пользователя
Доверенный канал – канал связи, по которому комплекс средств безопасности объекта оценки и удаленный доверенный объект информационных технологий взаимодействуют между собой и который обеспечивает необходимую степень уверенности в поддержании политики безопасности объекта оценки.
Задание по безопасности – совокупность требований безопасности и спецификаций, предназначенная для использования в качестве основы для оценки конкретного объекта оценки.
Задача безопасности – сформулированное намерение противостоять установленным угрозам и/или следовать установленной политике безопасности организации и предположениям объекта оценки.
Идентификатор
Итерация
Класс (Class) – совокупность семейств требований безопасности, объединенных общими задачами безопасности.
Комплекс средств безопасности объекта оценки – совокупность всех средств безопасности объекта оценки, на которые возлагается осуществление политики безопасности объекта оценки.
Компонент– наименьшая выбираемая совокупность элементов, которая может быть включена в профиль защиты, задание по безопасности или пакет.
Модель политики безопасности объекта оценки - структурированное представление политики безопасности, осуществляемой объектом оценки.
Назначение (Assignment) – установление определенного параметра элемента в компоненте.
Область действия комплекса средств безопасности объекта оценки (TSF Scope of Control) – совокупность возможных взаимодействий с объектом оценки или в его пределах, которые подчинены правилам политики безопасности объекта оценки.
Объект (Object) – устройство или программа в пределах области действия комплекса средств безопасности объекта оценки, которые содержат, передают или обрабатывают информацию и с помощью которых субъекты выполняют операции.
Объект оценки
Оператор-пользователь
Орган оценки – организация, которая устанавливает стандарты и контролирует качество оценок, проводимых организациями в пределах данного сообщества.
Оценка (Evaluation) – установление соответствия профиля защиты, задания по безопасности или объекта оценки определенным критериям.
Передача за пределы области действия комплекса средств безопасности объекта оценки
Передача между комплексами средств безопасности– передача данных между комплексом средств безопасности объекта оценки и комплексом средств безопасности других доверенных объектов информационных технологий.
Политика безопасности объекта оценки (TOE Security Policy) – совокупность правил, регулирующих управление активами, их защиту и распределение в объекте оценки.
Политика безопасности организации (Organisational security policies) – совокупность правил, процедур, практических приемов или руководящих принципов в области безопасности, которыми руководствуется организация в своей деятельности.
Политика средства безопасности (Security Function Policy) – политика безопасности, осуществляемая средством безопасности.
Пользователь
Потенциал атаки (Attack potential) – прогнозируемый потенциал успеха атаки, определяемый показателями компетенции, ресурсов и мотивации нарушителя.
Продукт (Product) – совокупность программных, программно-аппаратных реализующих определенные функции как автономно, так и в составе других систем.
Расширение
Роль (Role) – заранее определенная совокупность правил допустимого взаимодействия между пользователем и объектом оценки.
Секрет (Secret) – сведения, доступные только авторизованным (полномочным) пользователям
Система
Средняя стойкость средств безопасности (SOF-medium) – уровень стойкости средств безопасности, при котором достигается требуемая степень защищенности от прямого или умышленного воздействия
Стойкость средства безопасности– способность средств безопасности объекта оценки противостоять воздействию атак.
Субъект (Subject) – процесс, средство в области действия комплекса средств безопасности объекта оценки, взаимодействующие с объектом оценки.
Уровень гарантии оценки– пакет гарантийных требований, который соответствует определенному значению на шкале гарантий Общих критериев.
Усиление– добавление одного или нескольких компонентов гарантийных требований в уровень гарантии оценки или пакет гарантийных требований.
Уточнение – детальное описание компонента.
Функциональное требование безопасности (Security functional requirement) – требование безопасности, направленное на обеспечение решения задач безопасности объекта оценки.
Элемент (Element) – неделимое требование безопасности.













14. Общие критерии защищенности информационных технологи. Среда безопасности.
Среда безопасности (СЛ.19)
Среда безопасности включает предположения о свойствах (характеристиках) среды функционирования объекта, политику безопасности организации, все законы в области безопасности ИТ, опыт и знания, которые используются или могут быть использованы при формулировании требований безопасности. Это является определением внешних условий, в которых предполагается использовать объект. Среда безопасности включает также имеющиеся или потенциальные угрозы безопасности объекту в данной среде.
Профиль защиты (ПЗ) – подлежащий включению в специальный каталог документ, содержащий набор требований безопасности для типового объекта информационных технологий
Задание по безопасности (ЗБ) – совокупность требований безопасности и спецификаций, предназначенная для использования в качестве основы для оценки конкретного объекта оценки.

При определении среды безопасности разработчикам ПЗ и Задание по безопасности необходимо обратить внимание на:
1) описание физической среды объекта, содержащее все факторы, имеющие отношение к его безопасности, и включающее все известные физические аспекты и вопросы безопасности, связанные с подбором персонала;
2) описание активов, требующих защиты элементами объекта, содержащее все активы, к которым относятся требования или политики безопасности. Оно может включать активы, к которым требования применяются непосредственно, например файлы и базы данных, а также активы, требования
3) безопасности к которым применяются неявно, например данные, подтверждающие полномочия, или сама реализация объекта ИТ;
4) назначение объекта, которое определяется типом продукта и сферой применения.
На основании исследования политики безопасности, угроз безопасности и анализа риска готовится описание объекта с точки зрения безопасности:
1) заключение об условиях среды, при которых объект можно считать защищенным. Такие заключения при оценке объекта принимаются за аксиому;
2) описание угроз безопасности активам ИТ, которое должно включать все угрозы, от которых, по мнению исследователей, необходимо защищать объект. В настоящем стандарте угрозы представляются в следующих понятиях: нарушитель, его мотивация, квалификация и используемые ресурсы; предполагаемый метод атаки; уязвимое место, которое может быть подвергнуто атаке; актив, который может быть объектом атаки. Анализ риска – процесс определения угроз, уязвимых мест, возможного ущерба, контрмер;
3) описание политики безопасности организации, включающее используемые частные политики и правила безопасности. Для системы ИТ такая политика может быть установлена явным образом. Для продуктов ИТ общего назначения или класса продуктов, исходя из практики их использования, могут быть приняты допущения в описании политики безопасности организации.

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

16. Общие критерии защищенности информационных технологи. Функциональные требования безопасности.
Требования безопасности информационных технологий
Требования безопасности ИТ формулируются на основе задач безопасности. Они группируются в совокупность требований безопасности для объекта и в совокупность требований безопасности для окружающей среды объекта таким образом, чтобы при их реализации объект мог решать задачи безопасности.
Требования безопасности представлены в виде четко выделенных классов функциональных и гарантийных требований.
Функциональные требования представлены в виде тех функций объекта, которые обеспечивают безопасность ИТ и поддерживают режим безопасности объекта. Функциональные требования приведены в СТБ 34.101.2. Примерами функциональных требований являются требования идентификации, аутентификации, аудита (контроля) безопасности, подтверждения источника передаваемой информации и др.
Если объект содержит СБ, реализованные с помощью вероятностного механизма или перестановки (например, с помощью пароля или хэш-функции), то гарантийные требования могут быть определены как минимальный уровень стойкости СБ, согласованный с задачами безопасности. В этом случае уровень стойкости средства безопасности может быть одним из следующих: уровень базовой стойкости, уровень средней стойкости, уровень высокой стойкости средства безопасности. Каждому такому средству необходимо обеспечивать минимальный уровень стойкости или хотя бы заданную степень безопасности.
Совокупности функциональных требований могут соответствовать определенные уровни гарантии, которые упорядочены по степени усиления входящих в них гарантийных компонентов. В СТБ 34.101.3 содержатся гарантийные требования и построенная на их основе шкала уровней гарантии оценки.
Гарантийные требования обеспечиваются действиями разработчика, заключением по результатам оценки и действиями эксперта. Примерами гарантийных требований являются: ограничения на процесс разработки, требования к процессу поиска возможных уязвимых мест и анализу их влияния на безопасность объекта.
Гарантия того, что задачи безопасности будут решены с помощью выбранных СБ, определяется двумя факторами:
1) уверенностью в правильности реализации КСБО, т. е. оценкой такой реализации;
2) уверенностью в эффективности КСБО, т. е. оценкой степени решения сформулированных задач безопасности.
Требования безопасности включают как требования по безопасности объекта для заданных в проекте режимов работы, так и требования по исключению нежелательных режимов работы объекта.
Реализация в объекте первого вида требований безопасности устанавливается в процессе испытаний (тестирования) или в процессе эксплуатации объекта. Однако отсутствие нежелательных режимов работы объекта не всегда можно установить. Уменьшение риска нежелательных режимов обеспечивают испытания (тестирование), исследование проекта и наблюдение за работой объекта в процессе эксплуатации. Обоснованность требований также снижает риск появления нежелательных режимов работы объекта.