2. Нормативные документы в области защиты информации от НСД

 

Нормативные документы в области защиты информации от НСД ГТК РФ

          Нормативными (руководящими) документами в области защиты информации от несанкционированного доступа являются:

  • Закон Российской Федерации " О государственной тайне" от 21.7.93 г. N 5485-1.;
  • Закон Российской Федерации "Об информации, информатизации и защите информации" от 25.1.95 г.;
  • Закон Российской Федерации <Об участии в международном информационном обмене>.
  • Закон Российской Федерации <О правовой охране программ для электронных вычислительных машин и баз данных> от 23.09.1992 г;
  • Закон Российской Федерации "О федеральных органах правительственной связи и информации" от 19.2.93 г. N 4524-1;
  • Положение о Государственной технической комиссии при Президенте Российской Федерации (Гостехкомиссии России), распоряжение Президента Российской Федерации от 28.12.92 г. N 829;
  • РД. АС. Защита от НСД к информации. Классификация АС и требования по защите информации. -М.: Гостехкомиссия России, 1992;
  • РД. СВТ. Защита от НСД к информации. Показатели защищенности от НСД к информации. - М.: Гостехкомиссия России, 1992;
  • РД. Концепция защиты СВТ и АС от НСД к информации. - М.: Гостехкомиссия России, 1992;
  • РД. Защита от НСД к информации. Термины и определения. - М.: Гостехкомиссия России, 1992;
  • РД. Временное положение по организации разработки, изготовления и эксплуатации программных и технических средств защиты информации от НСД в АС и СВТ. - М.: Гостехкомиссия России, 1992;
  • Положение об обязательной сертификации продукции по требованиям безопасности информации. - M .:Гостехкомиссия России, 1994.
  • Положение о лицензировании деятельности в области защиты информации. -М.: Гостехкомиссия России, ФАПСИ, 1994.
  • Распоряжение Президента Российской Федерации "О перечне должностных лиц органов государственной власти, наделяемых полномочиями по отнесению сведений к государственной тайне" 30 мая 1997 года N 226-рп
  • Постановление Правительства Российской Федерации "О сертификации средств защиты информации" от 26 июня 1995 г. N 608 (в ред. Постановления Правительства РФ от 23.04.96 N 509)

 

          Рассмотрим важнейшие из них, и которые не анализировались в теме "Руководящие документы Гостехкомиссии и их применение в практической деятельности".
 

Концепция защиты от несанкционированного доступа к информации

          Идейной основой набора "Руководящих документов" является "Концепция защиты СВТ и АС от НСД к информации". Концепция "излагает систему взглядов, основных принципов, которые закладываются в основу проблемы защиты информации от НСД, являющейся частью общей проблемы безопасности информации".
          Мы позволим себе многостраничное цитирование Руководящих документов по двум причинам. Во-первых, данные требования, несомненно, важны с практической точки зрения. Лица, отвечающие за информационную безопасность, должны сопоставлять свои действия с Руководящими указаниями, чтобы обеспечить систематичность защитных мер. Во-вторых, брошюры Гостехкомиссии при Президенте РФ являются библиографической редкостью, и ознакомиться с ними в подлиннике затруднительно.
          В "Концепции" различаются понятия средств вычислительной техники и автоматизированной системы, аналогично тому, как в "Европейских Критериях" проводится деление на продукты и системы. Более точно, "Концепция предусматривает существование двух относительно самостоятельных и, следовательно, имеющих отличие направлений в проблеме защиты информации от НСД. Это - направление, связанное с СВТ, и направление, связанное с АС. Отличие двух направлений порождено тем, что СВТ разрабатываются и поставляются на рынок лишь как элементы, из которых в дальнейшем строятся функционально ориентированные АС, и поэтому, не решая прикладных задач, СВТ не содержат пользовательской информации.
          Помимо пользовательской информации при создании автоматизированных систем появляются такие отсутствующие при разработке СВТ характеристики АС, как полномочия пользователей, модель нарушителя, технология обработки информации."
          Существуют различные способы покушения на информационную безопасность: радиотехнические, акустические, программные и т.п. Среди них НСД выделяется как "доступ к информации, нарушающий установленные правила разграничения доступа, с использованием штатных средств, предоставляемых СВТ или АС. Под штатными средствами понимается совокупность программного, микропрограммного и технического обеспечения СВТ или АС."

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

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

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

          В качестве главного средства защиты от НСД к информации в "Концепции" рассматривается система разграничения доступа (СРД) субъектов к объектам доступа. Основными функциями СРД являются:

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

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

  • "степень полноты охвата ПРД реализованной СРД и ее качество;
  • состав и качество обеспечивающих средств для СРД;
  • гарантии правильности функционирования СРД и обеспечивающих ее средств."

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

Примечание. Средства СВТ могут рассматриваться как объекты НСД только при записи и хранении в них информации. "Голое" железо интерес для хакеров, как правило, не представляет.

 

"Средства вычислительной техники. Защита от несанкционированного доступа к информации. Показатели защищенности."

          Рассмотрим кратко содержание важнейшего документа "Средства вычислительной техники. Защита от несанкционированного доступа к информации. Показатели защищенности." В этом документе определены семь классов защищенности СВТ от НСД к информации. Самый низкий класс - седьмой, самый высокий первый. Каждый класс наследует требования защищенности предыдущего класса.
          Изложенные ниже требования к показателям защищенности предъявляются к общесистемным программным средствам и операционным системам.
          Совокупность всех средств СВТ защиты образует комплекс средств защиты (КСЗ).
          В зависимости от реализованных моделей защиты и надежности их проверки классы подразделяются на четыре группы. Первая группа включает только один седьмой класс (минимальная защищенность).
          Вторая группа характеризуется избирательной защитой и включает шестой и пятый классы. Избирательная защита предусматривает контроль доступа поименованных субъектов к поименованным объектам системы. При этом для каждой пары "субъект-объект" должны быть определены разрешенные типы доступа. Контроль доступа должен быть применим к каждому объекту и каждому субъекту (индивиду или группе равноправных индивидов).
          Третья группа характеризуется полномочной защитой и включает четвертый, третий и второй классы. Полномочная защита предусматривает присвоение каждому субъекту и объекту системы классификационных меток, указывающих место субъекта (объекта) в соответствующей иерархии. Классификационные метки на объекты устанавливаются пользователем системы или специально выделенным субъектом. Обязательным требованием для классов, входящих в эту группу, является реализация диспетчера доступа (в иностранной литературе - reference monitor, монитор ссылок). Контроль доступа должен осуществляться применительно ко всем объектам при явном и скрытом доступе со стороны любого из субъектов. Решение о санкционированности запроса на доступ должно приниматься только при одновременном разрешении его и избирательными и полномочными правилами разграничения доступа (ПРД).
          Четвертый класс характеризуется верифицированной защитой и содержит только первый класс.
          Для присвоения класса защищенности система должна содержать руководство администратора по системе, руководство пользователя, тестовую и конструкторскую (проектную) документацию.
          Перечень показателей по классам защищенности СВТ приведен в таблице 1. Их краткое описание приведено ниже.

Таблица 1. Показатели по классам защищенности СВТ Гостехкомиссии РФ

№№ п/п

Наименование

Показателя

Класс защищенности

C6 (С1)

C5 (С2)

4 (B1)

3 (В2)

2 (В3)

1 (А1)

Политика безопасности

1

Избирательная политика безопасности

+

+

+

=

+

=

2

Полномочная политика безопасности

-

-

+

=

=

=

3

Повторное использование объектов

-

+

+

+

=

=

4

Изоляция модулей

-

-

+

=

+

=

5

Маркировка документов

-

-

+

=

=

=

6

Защита ввода и вывода на отчуждаемый физический носитель информации

-

-

+

=

=

=

7

Сопоставление пользователя с устройством

-

-

+

=

=

=

Учет

8

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

+

=

+

=

=

=

9

Регистрация

-

+

+

+

=

=

10

Взаимодействие пользователя с КСЗ

-

-

-

+

=

=

Гарантии

11

Гарантии проектирования

-

+

+

+

+

+

12

Гарантии архитектуры

-

-

-

-

-

+

13

Надежное восстановление

-

-

-

+

=

=

14

Целостность КСЗ

-

+

+

+

=

=

15

Контроль модификации

-

-

-

-

+

=

16

Контроль дистрибуции

-

-

-

-

+

=

17

Тестирование

+

+

+

+

+

=

Документация

18

Руководство пользователя

+

=

=

=

=

=

19

Руководство по КСЗ

+

+

=

+

+

=

20

Тестовая документация

+

+

+

+

+

=

21

Конструкторская (проектная) документация

+

+

+

+

+

+

Обозначения:
"-" - нет требований к данному классу;
"+" - новые или дополнительные требования,
"=" - требования совпадают с требованиями к СВТ предыдущего класса.

Шестой класс защищенности
          КСЗ этого класса должен предоставлять возможности санкцио-нированного изменения ПРД, списка пользователей я и списка защищаемых объектов. Права изменять ПРД должны предоставляться выделенным субъектам (администрации, службе безопасности и т.д.).
          Перед работой пользователь должен пройти процедуру проверки подлинности (аутентификацию). По ее результатам ему присваиваются определенные права по доступу к объектам в системе (авторизация пользователя). Неавторизованный пользователь не должен иметь доступа к защищаемым ресурсам.

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

          КСЗ должен быть в состоянии осуществлять регистрацию следующих событий:

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

          Для каждого из регистрируемых событий должны

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

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

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

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

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

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

 

Классификация автоматизированных систем по уровню защищенности от НСД

          Для автоматизированных систем как объединений средств СВТ ГТК РФ разработала специальную классификацию автоматизированных систем по уровню защищенности от НСД

          Классификация автоматизированных систем устроена иначе. Снова обратимся к соответствующему "Руководящему документу".
"...устанавливается девять классов защищенности АС от НСД к информации.
          Каждый класс характеризуется определенной минимальной совокупностью требований по защите.
          Классы подразделяются на три группы, отличающиеся особенностями обработки информации в АС.
          В пределах каждой группы соблюдается иерархия требований по защите в зависимости от ценности (конфиденциальности) информации и, следовательно, иерархия классов защищенности АС.
          ... Третья группа классифицирует АС, в которых работает один пользователь, допущенный ко всей информации АС, размещенной на носителях одного уровня конфиденциальности. Группа содержит два класса - ЗБ и ЗА.
Вторая группа классифицирует АС, в которых пользователи имеют одинаковые права доступа (полномочия) ко всей информации АС, обрабатываемой и (или) хранимой на носителях различного уровня конфиденциальности. Группа содержит два класса - 2Б и 2А.
Первая группа классифицирует многопользовательские АС, в которых одновременно обрабатывается и (или) хранится информация разных уровней конфиденциальности и не все пользователи имеют право доступа ко всей информации АС. Группа содержит пять классов - 1Д, 1Г, 1В, 1Б и 1А." В таблице 2 собраны требования ко всем девяти классам защищенности АС.
Таблица 2. Требования к защищенности автоматизированных систем.
Классы
Подсистемы и требования
1. Подсистема управления доступом
1.1. Идентификация, проверка подлинности и контроль доступа субъектов:
в систему;
+
+
+
+
+
+
+
+
+
к терминалам, ЭВМ, узлам сети ЭВМ, каналам связи, внешним устройствам ЭВМ;
-
-
-
+
-
+
+
+
+
к программам;
-
-
-
+
-
+
+
+
+
к томам, каталогам, файлам, записям, полям записей.
-
-
-
+
-
+
+
+
+
1.2. Управление потоками информации.
-
-
-
+
-
-
+
+
+
2. Подсистема регистрации и учета
2.1. Регистрация и учет:
входа/выхода субъектов доступа в/из системы (узла сети);
+
+
+
+
+
+
+
+
+
выдачи печатных (графических) выходных документов;
-
+
-
+
-
+
+
+
+
запуска/завершения программ и процессов (заданий, задач);
-
-
-
+
-
+
+
+
+
доступа программ субъектов доступа к защищаемым файлам, включая из создания и удаления, передачу по линиям и каналам связи;
-
-
-
+
-
+
+
+
+
доступа программ субъектов доступа к терминалам, ЭВМ, узлам сети ЭВМ, каналам связи, внешним устройствам ЭВМ, программам, томам, каталогам, файлам, записям, полям записей;
-
-
-
+
-
+
+
+
+
изменения полномочий субъектов доступа;
-
-
-
-
-
-
+
+
+
создаваемых защищаемых объектов доступа.
-
-
-
+
-
-
+
+
+
2.2. Учет носителей информации.
+
+
+
+
+
+
+
+
+
2.3. Очистка (обнуление, обезличивание) освобождаемых областей оперативной памяти ЭВМ и внешних накопителей.
-
+
-
+
-
+
+
+
+
2.4. Сигнализация попыток нарушения защиты.
-
-
-
-
-
-
+
+
+
3. Криптографическая подсистема
3.1. Шифрование конфиденциалной информации.
-
-
-
+
-
-
-
+
+
3.2. Шифрование информации, принадлежащей различным субъектам доступа (группам субъектов) на разных ключах.
-
-
-
-
-
-
-
-
+
3.3. Использование аттестованных (сертифицированных) криптографических средств.
-
-
-
+
-
-
-
+
+
4. Подсистема обеспечения целостности
4.1. Обеспечения целостности программных средств и обрабатываемой информации.
+
+
+
+
+
+
+
+
+
4.2. Физическая охрана средств вычислительной техники и носителей информации.
+
+
+
+
+
+
+
+
+
4.3. Наличие администратора (службы) защиты информации в АС.
-
-
-
+
-
-
+
+
+
4.4. Периодическое тестирование СЗИ НСД.
+
+
+
+
+
+
+
+
+
4.5. Наличие средств восстановления СЗИ НСД.
+
+
+
+
+
+
+
+
+
4.6. Использование сертифицированных средств защиты.
-
+
-
+
-
-
+
+
+
Обозначения:
"- " - нет требований к данному классу;
"+" - есть требования к данному классу;
"СЗИ НСД" - система защиты информации от несанкционированного доступа.
 
          Ниже приведено подробное изложение требований к достаточно представительному классу защищенности - 1В. По существу, перед нами - минимум требований, которым необходимо следовать, чтобы обеспечить конфиденциальность защищаемой информации (реальные АС часто не соответствуют данному классу).
 

ТРЕБОВАНИЯ К КЛАССУ ЗАЩИЩЕННОСТИ 1В

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

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

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

 

Система стандартов Министерства обороны США в области противодействия НСД

          В период с 1983 по 1988 год в США Министерством обороны (Department of Defence, DoD) и Национальным комитетом по компьютерной безопасности (National Committee of Computer Security, NCSC) была разработана система стандартов в области компьютерной безопасности. Она включает следующие документы:

"Критерий оценки безопасности компьютерных систем", больше известный как "Оранжевая книга";Статья №
"Программа оценки безопасности продуктов";
"Руководство по применению критерия оценки безопасности компьютерных систем в специфических средах" , известный под названием "Желтая книга";
комплект документов под общим названием "Радужная серия" (Rainbow Series), включающий "Разъяснение критерия оценки безопасности компьютерных систем для безопасных сетей", "Разъяснение критерия оценки безопасности компьютерных сетей для безопасных СУБД", "Разъяснение критерия оценки безопасности компьютерных систем для отдельных подсистем безопасности".

 

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

"Оранжевая книга" необходима:

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

          В ней изложена единые для МО США (и промышленности на территории США) требования к политике безопасности, требования безопасности, порядок определения классов защищенности информации в компьютерных системах МО США.
          В документе выделены общие требования по обеспечению безопасности обрабатываемой информации, затем определен перечень показателей (показатели защищенности), характеризующих реализацию общих требований. Совокупность этих показателей определяет уровень безопасности рассматриваемой системы.
          Документ определяет шесть основных требований безопасности. Четыре из них относятся к управлению доступом к информации (политика безопасности, маркировка, идентификация и учет), а два к предоставляемым гарантиям (уверенность в системе и непрерывность защиты).
          Эти основные требования конкретизируются в показателях защищенности. Эти показатели приведены в Таблице 2. В документе подробно описывается требования к реализации каждого показателя защищенности для соответствующего класса.
          Класс защищенности присваивается системе при прохождении ею сертификации. Во время сертификации специалисты NCSC на основании представленных исходных текстов программ и документации на систему оценивают уровень реализации той или иной возможности системы по защите информации.
          Следует отметить, что сертификации подвергается вся система в целом, а класс защищенности присваивается только в том случае, когда самый "слабый" показатель удовлетворяет требованиям класса защищенности.
          Ниже в порядке возрастания предпочтительности с точки зрения безопасности приведены следующие классы компьютерных систем.

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

  • подсистемы обеспечения избирательного управления доступом (Discretionary Access Control, DAC);
  • подсистемы обеспечения очистки памяти перед повторным использованием объектов (Object Reuse, OR);
  • подсистемы обеспечения идентификации и аутентификации субъектов (Identification & Authentication, I&A) ;
  • подсистемы контроля (Audit, AUD).

          В отличие от 7 класса защищенности, предусмотренного в РД ГТК России, в классе D выделяются три подуровня: D1, D2 и D3.
Класс D1 сопоставляется подсистемам, соответствующим интерпретации требований, предъявляемых к системам класса C1. Класс D2 сопоставляется подсистемам, соответствующим интерпретации требований, предъявляемых к системам класса C2. Класс D3 зарезервирован для подсистем избирательного управления доступом и подсистем контроля, соответствующих интерпретациям функциональных требований B3 (см. Таблицу 4).

Таблица 3. Показатели защищенности “Оранжевой книги”

№№ п/п

Наименование

Показателя

Класс защищенности

CС1

CС2

B1

В2

В3

А1

Security Policy

1

Discretionary Access Control

+

+

+

=

=

=

2

Mandatory Access Control

-

-

+

+

=

=

3

Labels

-

-

+

+

=

=

4

Labels Integrity

-

-

+

=

=

=

5

Working Labels

-

-

-

+

=

=

6

Label Frequency

-

-

+

=

=

=

7

Object Reuse

-

+

=

+

=

=

8

Resource Encapsulation

-

+

=

-

-

-

9

Exported Machine Readable Output

-

-

+

=

=

=

10

Exported Human –Readable Labels

-

-

+

=

=

=

ACCOUNTABILITY

11

Identification & Authentication

+

+

=

=

=

=

12

Audit

-

+

+

+

+

=

13

Trusted Path

-

-

-

+

=

=

ASSURANCE

14

Design Specification&Verification

-

-

+

+

+

+

15

System Architecture

+

=

=

+

+

=

16

System Integrity

+

=

=

=

=

=

17

Security Testing

+

+

+

+

+

=

18

Trusted Recovery

-

-

-

-

+

=

19

Configuration Management

-

-

-

+

+

+

20

Trusted Facility Management

-

-

-

+

+

=

21

Trusted Distribution

-

-

-

-

+

=

22

Covert Channel Analysis

-

-

-

+

=

+

DOCUMENTATION

23

Security Features User's Guide

+

=

=

=

=

=

24

Trusted Facility Manual

+

+

+

+

+

=

25

Test Documentation

+

=

=

+

=

+

26

Design Documentation

+

=

+

+

=

+

Обозначения:
"-" - нет требований к данному классу;
"+" - новые или дополнительные требования;
"=" - требования совпадают с требованиями к предыдущему классу.

Таблица 4.

Функция подсистемы

Класс безопасности

Возможные рейтинги

Избирательное управление доступом

DAC/D

DAC/D1
DAC/D2
DAC/D3

Повторное использование объекта

OR/D

OR/D2

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

I&A/D

I&A/D1
I&A/D2

Контроль

AUD/D

AUD/D2
AUD/D3

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

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

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

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

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

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

Класс A1: верифицированная разработка.
          Системы этого класса отличаются от класса B3 тем, что для проверки спецификаций применяются формальные методы.
          Анализ классов защищенности показывает, что чем выше класс защищенности системы, то тем жестче накладываются требования по доверию системе. Это выражается не только в расширенном тестировании возможностей системы и представлении расширенной документации, но и в использовании формальных методов проверки правильности спецификаций программ и верификации текстов программ.
          Для целей криптографической защиты широко используется стандарт DES, утвержденный в США Национальным институтом стандартов и технологий (National Institute of Standarts and Technologies - NIST).

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

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

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

 

Сравнение стандартов России и США

          Прообразом для создания РД Гостехкомиссии послужил стандарт МО США "Orange Book". Это сказалось как на общем подходе к построению РД, так и на терминах и определениях, которые используются в нем. Соответствие между терминами РД Гостехкомиссии терминами стандарта МО США представлено в таблице 5.

Таблица 5. Соответствие терминов РД Гостехкомиссии и стандарта МО США "Orange Book"

п/п

Название показателя по

РД Гостехкомиссии

Название показателя по "Orange Book"

1

Дискреционный принцип контроля доступа

Discretionary Access
Control (DAC)

2

Мандатный принцип контроля доступа

Mandatory Access Control
Labels
Label Integrity
Subject Sensivity Labels
Label Frequency

3

Очистка памяти

Object Reuse

4

Изоляция модулей

Аналогичного термина нет.

5

Маркировка документов

Supported Human-Readable Labels

6

Защита ввода и вывода на отчуждаемый физический носитель информации

Exported Machine-Readable Output

7

Сопоставление пользователя с устройством

Trusted path

8

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

Identification & Authentication

9

Гарантии проектирования

Design Specification & verification

10

Регистрация

Audit

11

Взаимодействие пользователя с КСЗ

Trusted Path

12

Надежное восстановление

Trusted Recovery

13

Целостность КСЗ

System Integrity

14

Контроль модификации

Trusted Facility Management
Configuration Management

15

Контроль дистрибуции

Trusted Distribution

16

Гарантии архитектуры

System Architecture

17

Тестирование

System Testing

18

Руководство пользователя

Security Features User's Guide

19

Руководство по КСЗ

Trusted Facility Manual

20

Тестовая документация

Test documentation

21

Конструкторская (проектная) документация

Design Documentation

22

Аналогичного термина нет

Covert Channel Analysis

            Ниже приводятся результаты сопоставления перечней функциональных требований безопасности и классов защищенности средств и систем, определенных в Руководящих документах ГТК России и стандарте МО США.
          Анализ терминов показывает, что в некоторых случаях они неудачно переведены (например
Discretionary Access Control переведен как "дискреционный принцип контроля доступа", в то время как целесообразнее перевести его как "избирательный принцип" или "избирательное управление доступом").
          В мандатный (лучше полномочный) принцип доступа в РД ГТК объединены сразу несколько показателей защищенности стандарта МО США, связанные с установкой и поддержанием целостности меток безопасности.
          В контроль модификации объединены два важных показателя управление безопасностью (Trusted Facility Management) и управление конфигурацией (Configuration Ma
nagement).
          В РД Гостехкомиссии отсутствует показатель "Covert Channel Analysis" (анализ скрытых каналов), присутствующий в стандарте МО США.
          В то же время добавлен новый показатель "Изоляция модулей", который в стандарте МО США отсутствует.

Сравнительный анализ структуры и содержания РД Гостехкомиссии и стандарта МО США позволяет утверждать следующее:

  1. Отечественный документ менее структурирован, чем его американский прообраз, что затрудняет его понимание и применение;
  2. В отечественном документе применение концепции диспетчера доступа требуется в четвертом классе защищенности, в то время как в американском стандарте это необходимо только на уровне B3. Это усиливает требования по безопасности.
  3. Американский документ конкретнее определяет содержимое документации на КСЗ, в том числе функции администратора безопасности и оператора системы по управлению безопасностью.
  4. В отечественном документе отсутствует упоминание о групповой аутентификации (в классе C1 американского стандарта).
  5. В отечественном документе отсутствует понятие "скрытый канал доступа" и, следовательно, меры по защите от такого типа угроз.

Сопоставляя содержимое таблицы 5, а также содержание обоих документов можно сделать следующие выводы:

  • несмотря на большое сходство РД Гостехкомиссии являются самостоятельным документом;
  • требования классов безопасности отечественного документа не имеют прямого соответствия классам стандарта МО США.

 

Классификация автоматизированных систем по уровню защищенности от НСД

          Классификация автоматизированных систем устроена иначе. Снова обратимся к соответствующему "Руководящему документу".
          "...устанавливается девять классов защищенности АС от НСД к информации.
          Каждый класс характеризуется определенной минимальной совокупностью требований по защите.
          Классы подразделяются на три группы, отличающиеся особенностями обработки информации в АС.
          В пределах каждой группы соблюдается иерархия требований по защите в зависимости от ценности (конфиденциальности) информации и, следовательно, иерархия классов защищенности АС.
          ... Третья группа классифицирует АС, в которых работает один пользователь, допущенный ко всей информации АС, размещенной на носителях одного уровня конфиденциальности. Группа содержит два класса - ЗБ и ЗА.
          Вторая группа классифицирует АС, в которых пользователи имеют одинаковые права доступа (полномочия) ко всей информации АС, обрабатываемой и (или) хранимой на носителях различного уровня конфиденциальности. Группа содержит два класса - 2Б и 2А.
          Первая группа классифицирует многопользовательские АС, в которых одновременно обрабатывается и (или) хранится информация разных уровней конфиденциальности и не все пользователи имеют право доступа ко всей информации АС. Группа содержит пять классов - 1Д, 1Г, 1В, 1Б и 1А." В таблице 1собраны требования ко всем девяти классам защищенности АС.
 
Таблица 1. Требования к защищенности автоматизированных систем.
Классы
Подсистемы и требования
1. Подсистема управления доступом
1.1. Идентификация, проверка подлинности и контроль доступа субъектов:
в систему;
+
+
+
+
+
+
+
+
+
к терминалам, ЭВМ, узлам сети ЭВМ, каналам связи, внешним устройствам ЭВМ;
-
-
-
+
-
+
+
+
+
к программам;
-
-
-
+
-
+
+
+
+
к томам, каталогам, файлам, записям, полям записей.
-
-
-
+
-
+
+
+
+
1.2. Управление потоками информации.
-
-
-
+
-
-
+
+
+
2. Подсистема регистрации и учета
2.1. Регистрация и учет:
входа/выхода субъектов доступа в/из системы (узла сети);
+
+
+
+
+
+
+
+
+
выдачи печатных (графических) выходных документов;
-
+
-
+
-
+
+
+
+
запуска/завершения программ и процессов (заданий, задач);
-
-
-
+
-
+
+
+
+
доступа программ субъектов доступа к защищаемым файлам, включая из создания и удаления, передачу по линиям и каналам связи;
-
-
-
+
-
+
+
+
+
доступа программ субъектов доступа к терминалам, ЭВМ, узлам сети ЭВМ, каналам связи, внешним устройствам ЭВМ, программам, томам, каталогам, файлам, записям, полям записей;
-
-
-
+
-
+
+
+
+
изменения полномочий субъектов доступа;
-
-
-
-
-
-
+
+
+
создаваемых защищаемых объектов доступа.
-
-
-
+
-
-
+
+
+
2.2. Учет носителей информации.
+
+
+
+
+
+
+
+
+
2.3. Очистка (обнуление, обезличивание) освобождаемых областей оперативной памяти ЭВМ и внешних накопителей.
-
+
-
+
-
+
+
+
+
2.4. Сигнализация попыток нарушения защиты.
-
-
-
-
-
-
+
+
+
3. Криптографическая подсистема
3.1. Шифрование конфиденциалной информации.
-
-
-
+
-
-
-
+
+
3.2. Шифрование информации, принадлежащей различным субъектам доступа (группам субъектов) на разных ключах.
-
-
-
-
-
-
-
-
+
3.3. Использование аттестованных (сертифицированных) криптографических средств.
-
-
-
+
-
-
-
+
+
4. Подсистема обеспечения целостности
4.1. Обеспечения целостности программных средств и обрабатываемой информации.
+
+
+
+
+
+
+
+
+
4.2. Физическая охрана средств вычислительной техники и носителей информации.
+
+
+
+
+
+
+
+
+
4.3. Наличие администратора (службы) защиты информации в АС.
-
-
-
+
-
-
+
+
+
4.4. Периодическое тестирование СЗИ НСД.
+
+
+
+
+
+
+
+
+
4.5. Наличие средств восстановления СЗИ НСД.
+
+
+
+
+
+
+
+
+
4.6. Использование сертифицированных средств защиты.
-
+
-
+
-
-
+
+
+
Обозначения:
"- " - нет требований к данному классу;
"+" - есть требования к данному классу;
"СЗИ НСД" - система защиты информации от несанкционированного доступа.
 
          Ниже приведено подробное изложение требований к достаточно представительному классу защищенности - 1В. По существу, перед нами - минимум требований, которым необходимо следовать, чтобы обеспечить конфиденциальность защищаемой информации (реальные АС часто не соответствуют данному классу).

ТРЕБОВАНИЯ К КЛАССУ ЗАЩИЩЕННОСТИ 1В

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

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

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

 

РУКОВОДЯЩИЙ ДОКУМЕНТ Защита от НСД к информации
(Часть 1. Программное обеспечение средств защиты информации. Классификация по уровню контроля отсутствия недекларированных возможностей)

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

  • к составу и содержанию документации, представляемой заявителем для проведения испытаний ПО СЗИ;
  • к содержанию испытаний.

          Руководящий документ разработан в дополнение РД "Средства вычислительной техники. Защита от несанкционированного доступа к информации. Показатели защищенности от несанкционированного доступа к информации", М., Военное издательство, 1992 г., РД "Автоматизированные системы. Защита от несанкционированного доступа к информации. Классификация автоматизированных систем и требования по защите информации", М., Военное издательство, 1992 г. и РД "Средства вычислительной техники. Межсетевые экраны. Защита от несанкционированного доступа к информации. Показатели защищенности от несанкционированного доступа к информации", М., 1997 г.
          Документ предназначен для специалистов испытательных лабораторий, заказчиков, разработчиков ПО СЗИ при его контроле в части отсутствия недекларированных возможностей.

 

ОБЩИЕ ПОЛОЖЕНИЯ

1.1. Классификация распространяется на ПО, предназначенное для защиты информации ограниченного доступа.

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

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

1.4. Самый высокий уровень контроля — первый, достаточен для ПО, используемого при защите информации с грифом "ОВ". Второй уровень контроля достаточен для ПО, используемого при защите информации с грифом "CC". Третий уровень контроля достаточен для ПО, используемого при защите информации с грифом "C". Самый низкий уровень контроля — четвертый, достаточен для ПО, используемого при защите конфиденциальной информации.

 

ТЕРМИНЫ И ОПРЕДЕЛЕНИЯ

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

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

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

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

2.5. Маршрут выполнения функциональных объектов — определенная алгоритмом последовательность выполняемых функциональных объектов.

2.6. Фактический маршрут выполнения функциональных объектов — последовательность фактически выполняемых функциональных объектов при определённых условиях (входных данных).

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

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

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

 

ТРЕБОВАНИЯ К УРОВНЮ КОНТРОЛЯ

Таблица 6. Перечень требований

Наименование требования

Уровень контроля

 

 

4

3

2

1

 

Требования к документации

       

1.

Контроль состава и содержания документации

       

1.1.

Спецификация (ГОСТ 19.202-78)

+

=

=

=

1.2.

Описание программы (ГОСТ 19.402-78)

+

=

=

=

1.3.

Описание применения (ГОСТ 19.502-78)

+

=

=

=

1.4.

Пояснительная записка (ГОСТ 19.404-79)

-

+

=

=

1.5.

Тексты программ, входящих в состав ПО (ГОСТ 19.401-78)

+

=

=

=

 

Требования к содержанию испытаний

       

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.

Отчетность

+

+

+

+

Обозначения:
"-" — нет требований к данному уровню;
"+" — новые или дополнительные требования;
"=" — требования совпадают с требованиями предыдущего уровня.

Требования к четвертому уровню контроля

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

  • спецификация (ГОСТ 19.202-78), содержащая сведения о составе ПО и документации на него;
  • описание программы (ГОСТ 19.402-78), содержащее основные сведения о составе (с указанием контрольных сумм файлов, входящих в состав ПО), логической структуре и среде функционирования ПО, а также описание методов, приемов и правил эксплуатации средств технологического оснащения при создании ПО;
  • описание применения (ГОСТ 19.502-78), содержащее сведения о назначении ПО, области применения, применяемых методах, классе решаемых задач, ограничениях при применении, минимальной конфигурации технических средств, среде функционирования и порядке работы;
  • исходные тексты программ (ГОСТ 19.401-78), входящих в состав ПО.

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

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

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

  • контроль полноты и отсутствия избыточности исходных текстов ПО на уровне файлов;
  • контроль соответствия исходных текстов ПО его объектному (загрузочному) коду.

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

  • контроля исходного состояния ПО;
  • контроля полноты и отсутствия избыточности исходных текстов контролируемого ПО на уровне файлов;
  • контроля соответствия исходных текстов ПО его объектному (загрузочному) коду.

 

Требования к третьему уровню контроля

Контроль состава и содержания документации
         Требования полностью включают в себя аналогичные требования к четвертому уровню контроля.
         Кроме того, должна быть представлена "Пояснительная записка" (ГОСТ 19.404-79), содержащая основные сведения о назначении компонентов, входящих в состав ПО, параметрах обрабатываемых наборов данных (подсхемах баз данных), формируемых кодах возврата, описание используемых переменных, алгоритмов функционирования и т.п.

Контроль исходного состояния ПО
         Требования полностью включают в себя аналогичные требования к четвёртому уровню контроля.

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

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

Динамический анализ исходных текстов программ
         Динамический анализ исходных текстов программ должен включать следующие технологические операции:

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

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

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

Требования ко второму уровню контроля

Контроль состава и содержания документации
         Требования полностью включают в себя аналогичные требования к третьему уровню контроля.

Контроль исходного состояния ПО
         Требования полностью включают в себя аналогичные требования к третьему уровню контроля.

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

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

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

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

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

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

Требования к первому уровню контроля

Контроль состава и содержания документации
         Требования полностью включают в себя аналогичные требования ко второму уровню контроля.

Контроль исходного состояния ПО
         Требования полностью включают в себя аналогичные требования ко второму уровню контроля.

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

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

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

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

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

DigitalSecurity, © 2003