 |
Показатели защищённости от НСД к информации
|
|
|
|
Руководящий документ устанавливает классификацию межсетевых экранов по уровню защищённости от НСД к информации на базе перечня показателей защищённости и совокупности описывающих их требований.
Показатели защищённости применяются к межсетевым экранам (МЭ) для определения уровня защищённости, который они обеспечивают при межсетевом взаимодействии.
Устанавливаются 5 классов защищённости МЭ, однозначно сопоставленных с классами автоматизированных систем (табл. 3.3.5).
Таблица 3.3.5.
Соответствие классов защищённости МЭ и АС
| Класс МЭ | Класс АС |
| 1Д | |
| 1Г | |
| 1В | |
| 1Б | |
| 1А |
Тем самым, для каждого класса защищённости АС определён класс МЭ, который должен применяться для осуществления безопасного взаимодействия АС с внешней средой.
Принадлежность к тому или иному классу МЭ определяется путём анализа соответствия следующим показателям защищённости:
1. Управление доступом (фильтрация данных и трансляция адресов). Для различных классов защищённости фильтрация производится на разных уровнях модели ISO/OSI.
2. Идентификация и аутентификация (входящих и исходящих запросов).
3. Регистрация.
4. Администрирования: идентификация и аутентификация.
5. Администрирование: регистрация.
6. Администрирование: простота использования.
7. Целостность.
8. Восстановление.
9. Тестирование (возможность проведения регламентного тестирования).
10. Руководство администратора защиты.
11. Тестовая документация.
12. Конструкторская (проектная) документация.
Ключевая особенность рассмотренного документа состоит в том, что классификация межсетевых экранов производится в том числе и по уровням модели ISO/OSI, на которых осуществляется фильтрация. Данный подход впервые был предложен именно в этом руководящем документе.
|
|
|
Защита от НСД к информации.
Часть 1. Программное обеспечение средств защиты информации. Классификация по уровню контроля отсутствия недекларированных возможностей
Руководящий документ устанавливает классификацию программного обеспечения по уровню контроля отсутствия в нём недекларированных возможностей. Под недекларированными возможностями понимаются возможности программного обеспечения, не описанные или не соответствующие описанным в документации, при использовании которых возможно нарушение конфиденциальности, доступности или целостности обрабатываемой информации.
Одной из возможных реализаций недекларированных возможностей являются программные закладки – преднамеренно внесённые в программное обеспечение (ПО) функциональные объекты, которые при определённых условиях инициируют выполнение не описанных в документации функций ПО, приводящих к нарушению конфиденциальности, доступности или целостности обрабатываемой информации.
Устанавливаются 4 уровня контроля, каждый из которых характеризуется определённой совокупностью минимальных требований. В общем случае к ПО предъявляются следующие требования:
· Требования к документации
1. Контроль состава и содержания документации
1.1. Спецификация.
1.2. Описание программы.
1.3. Описание применения.
1.4. Пояснительная записка.
1.5. Тексты программ, входящих в состав программного обеспечения.
· Требования к содержанию испытаний
2. Контроль исходного состояния программного обеспечения.
3. Статический анализ исходных текстов программ.
3.1. Контроль полноты и отсутствия избыточности исходных текстов.
3.2. Контроль соответствия исходных текстов ПО его объектному (загрузочному) коду.
3.3. Контроль связей функциональных объектов по управлению.
|
|
|
3.4. Контроль связей функциональных объектов по информации.
3.5. Контроль информационных объектов.
3.6. Контроль наличия заданных конструкций в исходных текстах.
3.7. Формирование перечня маршрутов выполнения функциональных объектов.
3.8. Анализ критических маршрутов выполнения функциональных объектов (критическим считается маршрут, при выполнении которого существует возможность неконтролируемого нарушения установленных правил обработки информационных объектов).
3.9. Анализ алгоритма работы функциональных объектов на основе блок-схем, построенных по исходным текстам контролируемого программного обеспечения.
4. Динамический анализ исходных текстов программ.
4.1. Контроль выполнения функциональных объектов.
4.2. Сопоставление фактических маршрутов выполнения функциональных объектов и маршрутов, построенных в процессе проведения статического анализа.
5. Отчётность.
Предъявляются требования к документам, разрабатываемым в ходе и по результатам проведённых испытаний.
Испытания, проводимые в соответствии с данным документом, должны содержать проверки, относящиеся к двум основным категориям – статическому и динамическому анализу. Статический анализ исходных текстов программ – это совокупность методов контроля соответствия реализованных и декларированных в документации функциональных возможностей ПО, основанных на структурном анализе и декомпозиции исходных текстов программ. В свою очередь, динамический анализ основывается на идентификации фактических маршрутов выполнения функциональных объектов с последующим сопоставлением маршрутам, построенным в процессе проведения статического анализа. Статически и динамический методы анализа дополняют друг друга: результаты статического анализа используются при проведении динамического анализа.
Общие критерии
Введение
Как для «Оранжевой книги», так и для аналогичных ей руководящих документов Гостехкомиссии России, характерны многочисленные недостатки. Перечислим наиболее существенные из них:
· Документы ориентированы на обеспечение защиты информации от угроз нарушения конфиденциальности и, в определённой степени, целостности. Угрозы нарушения доступности практически не рассматриваются.
|
|
|
· Используемый «табличный» подход не позволяет учесть специфику конкретных систем или продуктов, в том числе порядок обработки информации в автоматизированной системе. Так, например, понятие «политика безопасности» в РД Гостехкомиссии России не упоминается.
· Документы содержат перечень механизмов, наличие которых необходимо для отнесения СВТ или АС к тому или иному классу защищённости. При этом совершенно не формализованы методы проверки корректности и адекватности реализации функциональных требований.
· Формулировки ряда требований чрезвычайно туманны и допускают неоднозначную интерпретацию.
В целом, РЛ Гостехкомиссии России и «Оранжевая книга», как и все другие оценочные стандарты первого поколения, создавались для давно ушедшей в прошлое материально-технической базы и по целому ряду аспектов являются морально устаревшими.
Стандарт ISO/IEC 15408-1999 “Common Criteria for Information Technology Security Evaluation” был разработан совместными усилиями специалистов Канады, США, Великобритании, Германии, Нидерландов и Франции в период с 1990 по 1999 год, развитие стандарта непрерывно продолжается. Исторически за стандартом закрепилось разговорное название “Common Criteria” – «Общие критерии».
В России аутентичный перевод «Общих критериев» версии 2.0 принят в качестве ГОСТ в 2002 году и введён в действие с 1 января 2004 г. Точное название документа: ГОСТ Р ИСО/МЭК 15408-2002 «Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий».
Документ состоит из трёх частей:
1. Введение и общая модель.
2. Функциональные требования безопасности.
3. Требования доверия к безопасности.
В перспективе «Общие критерии» должны заменить РД Гостехкомиссии России во всех системах сертификации средств защиты информации. В настоящий момент оба поколения стандартов используются одновременно, причём «Общие критерии» применяются исключительно при проведении сертификации продуктов, не предназначенных для обработки информации, составляющей государственную тайну.
|
|
|
