Законодательство Казахстана on-line   

Приказ Агентства по защите госсекретов от 29.01.2001 N 2
"ОБ УТВЕРЖДЕНИИ ИНСТРУКЦИИ ПО ОБЕСПЕЧЕНИЮ РЕЖИМА СЕКРЕТНОСТИ ПРИ ОБРАБОТКЕ СВЕДЕНИЙ, СОСТАВЛЯЮЩИХ ГОСУДАРСТВЕННЫЕ СЕКРЕТЫ, С ПРИМЕНЕНИЕМ СРЕДСТВ ВЫЧИСЛИТЕЛЬНОЙ ТЕХНИКИ"

 
 
Навигация
  • Отправить другу ссылку на эту страницу
Рекомендуем посетить:
RealSpeed.CO.KZ: Быстрый тест реальной скорости Вашего доступа к Интернет
Оплата услуг IP-телефонии. Ваучеры Skype, Betamax и другие. Моментальная доставка.

Приложение 1. Классификация систем защиты секретной информации

Приложение 1

КЛАССИФИКАЦИЯ
систем защиты секретной информации

1. Общие положения

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

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

Конкретные перечни показателей определяют классы защищенности СВТ.

Уменьшение или изменение перечня показателей, соответствующего конкретному классу защищенности СВТ, не допускается.

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

Дополнительные требования к показателю защищенности СВТ и соответствие этим дополнительным требованиям оговариваются особо.

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

Документация системы защиты секретной информации (СЗСИ) должна быть неотъемлемой частью конструкторской документации (КД) на СВТ.

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

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

первая группа содержит седьмой класс (четвертая категория);

вторая группа характеризуется дискреционной защитой и содержит шестой и пятый классы (третья категория);

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

четвертая группа характеризуется верифицированной защитой и содержит первый класс (первая категория).

5. Выбор класса защищенности СВТ зависит от присвоенной объекту категории.

6. Применение в комплекте СВТ средств криптографической защиты информации может быть использовано для повышения гарантий качества защиты.

2. Требования к показателям защищенности

7. Приведенные в данном разделе наборы требований к показателям каждого класса являются минимально необходимыми.

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

Требования к показателям защищенности шестого класса

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

СЗСИ должна контролировать доступ наименованных субъектов (пользователей) к наименованным объектам (файлам, программам, томам и т.д.).

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

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

Контроль доступа должен быть применим к каждому объекту и каждому субъекту (индивиду или группе равноправных индивидов).

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

Права изменять ПРД должны предоставляться выделенным субъектам (администрации, службе безопасности и т.д.).

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

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

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

В СВТ шестого класса должны тестироваться:

реализация дискреционных ПРД (перехват явных и скрытых запросов, правильное распознавание санкционированных и несанкционированных запросов на доступ, средства защиты механизма разграничения доступа, санкционированные изменения ПРД);

успешное осуществление идентификации и аутентификации, а также их средств защиты.

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

Документация на СВТ должна включать в себя краткое руководство для пользователя с описанием способов использования СЗСИ и ее интерфейса с пользователем.

13. Руководство по СЗСИ

Данный документ адресован администратору защиты. Он должен содержать:

описание контролируемых функций;

руководство по генерации СЗСИ;

описание старта СВТ и процедур проверки правильности старта.

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

Должно быть предоставлено описание тестов и испытаний, которым подвергалось СВТ и результатов тестирования.

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

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

Требования к показателям пятого класса защищенности

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

Должны быть предусмотрены средства управления, ограничивающие распространение прав на доступ.

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

При первоначальном назначении или при перераспределении внешней памяти СЗСИ должна предотвращать доступ субъекту к остаточной информации.

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

На начальном этапе проектирования СВТ должна быть построена модель защиты. Модель должна включать в себя ПРД к объектам и непротиворечивые правила изменения ПРД.

19. Регистрация

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

использование идентификационного и аутентификационного механизма;

запрос на доступ к защищаемому ресурсу (открытие файла, запуск программы и т.д.);

создание и уничтожение объекта;

действия по изменению ПРД.

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

дата и время;

субъект, осуществляющий регистрируемое действие;

тип события (если регистрируется запрос на доступ, то следует отмечать объект и тип доступа);

успешно ли осуществилось событие (обслужен запрос на доступ или нет).

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

20. Целостность СЗСИ

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

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

В данном классе защищенности должны тестироваться:

реализация ПРД (перехват явных и скрытых запросов на доступ, правильное распознавание санкционированных и несанкционированных запросов, средства защиты механизма разграничения доступа, санкционированные изменения ПРД);

успешное осуществление идентификации и аутентификации, а также их средства защиты;

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

работа механизма, осуществляющего контроль за целостностью СЗСИ.

22. Руководство по СЗСИ

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

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

Должно быть предоставлено описание тестов и испытаний, которым подвергалось СВТ, и результатов тестирования.

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

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

Требования к показателям четвертого класса защищенности

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

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

Дискреционные ПРД для систем данного класса являются дополнением мандатных ПРД.

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

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

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

СЗСИ должна реализовывать мандатный принцип контроля доступа применительно ко всем объектам при явном и скрытом доступе со стороны любого из субъектов:

субъект может читать объект, только если иерархическая классификация в классификационном уровне субъекта не меньше, чем иерархическая классификация в классификационном уровне объекта, и неиерархические категории в классификационном уровне субъекта включают в себя все иерархические категории в классификационном уровне объекта;

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

Реализация мандатных ПРД должна предусматривать возможности сопровождения: изменения классификационных уровней субъектов и объектов специально выделенными субъектами.

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

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

При первоначальном назначении или при перераспределении внешней памяти СЗСИ должна затруднять субъекту доступ к остаточной информации. При перераспределении оперативной памяти СЗСИ должна осуществлять ее очистку.

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

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

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

При выводе защищаемой информации на документ проставляется штамп N 1 и заполняют его реквизиты в соответствии с Инструкцией по обеспечению режима секретности в Республике Казахстан (N 390-16с).

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

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

Изменения в назначении и разметке устройств и каналов должны осуществляться только под контролем СЗСИ.

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

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

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

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

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

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

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

Проектирование СЗСИ должно начинаться с построения модели защиты, включающей в себя:

непротиворечивые ПРД;

непротиворечивые правила изменения ПРД;

правила работы с устройствами ввода и вывода информации и каналами связи.

34. Регистрация

СЗСИ должна регистрировать все попытки доступа, все действия оператора и выделенных пользователей (администраторов защиты и т.п.).

35. Целостность СЗСИ

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

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

В данном классе защищенности должны тестироваться:

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

невозможность присвоения субъектом себе новых прав;

очистка оперативной и внешней памяти;

работа механизма изоляции процессов в оперативной памяти;

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

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

идентификация и аутентификация, а также их средства защиты;

запрет на доступ несанкционированного пользователя;

работа механизма, осуществляющего контроль за целостностью СВТ;

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

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

Должно быть представлено описание тестов и испытаний, которым подвергалось СВТ и результатов тестирования.

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

Конструкторская (проектная) документация в четвертом классе защищенности должна содержать:

общее описание принципов работы СВТ;

общую схему СЗСИ;

описание внешних интерфейсов СЗСИ и интерфейсов модулей СЗСИ;

описание модели защиты;

описание диспетчера доступа;

описание механизма контроля целостности СЗСИ;

описание механизма очистки памяти;

описание механизма изоляции программ в оперативной памяти;

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

описание механизма идентификации и аутентификации;

описание средств регистрации.

Требования к показателям третьего класса защищенности

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

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

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

На начальном этапе проектирования СЗСИ должна строиться модель защиты, задающая принцип разграничения доступа и механизм управления доступом. Эта модель должна содержать:

непротиворечивые правила изменения ПРД;

правила работы с устройствами ввода и вывода;

формальную модель механизма управления доступом.

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

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

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

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

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

43. Целостность СЗСИ

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

Программы должны выполняться в отдельной части оперативной памяти. Это обстоятельство должно подвергаться верификации.

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

Должны тестироваться:

очистка памяти;

работа механизма надежного восстановления.

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

Требование совпадает с аналогичным требованием четвертого класса.

46. Руководство по СЗСИ

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

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

В документации должно быть представлено описание тестов и испытаний, которым подвергалось СВТ.

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

Необходимы:

высокоуровневая спецификация СЗСИ и его интерфейсов;

верификация соответствия высокоуровневой спецификации СЗСИ модели защиты.

Требования к показателям второго класса защищенности

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

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

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

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

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

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

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

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

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

Должен осуществляться контроль точности копирования в СВТ при изготовлении копий с образца. Изготовляемая копия должна гарантированно повторять образец.

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

Должен тестироваться контроль дистрибуции.

55. Руководство по СЗСИ

Должны быть представлены руководства по надежному восстановлению, по работе со средствами контроля модификации и дистрибуции.

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

Должно быть представлено описание тестов и испытаний, которым подвергалось СВТ.

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

Должны быть описаны гарантии процесса проектирования и эквивалентность дискреционных и мандатных ПРД.

Требования к показателям первого класса защищенности

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

Требование включает в себя требование второго класса. Дополнительно требуется верификация соответствия объектного кода тексту СЗСИ на языке высокого уровня.

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

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

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

Разрабатывают описание гарантий процесса проектирования.

3. Оценка класса защищенности СВТ

61. Оценка класса защищенности СВТ проводится группой экспертов (оценочной комиссией).

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

В соответствии с данными показателями выполняется два вида работ:

оценка проекта;

оценка класса защищенности СВТ.

Представление комиссии СВТ с реализованными требованиями по защите для оценки (сертификации) осуществляется в сроки, указанные в плане - графике создания СВТ или в директивном документе.

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

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

63. Оценка класса защищенности СВТ проводится в два этапа:

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

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

64. Отказ СЗСИ (или отдельных средств СЗСИ) не должен приводить к отказу СВТ.

В случае отказа какого-либо элемента СЗСИ должно обеспечиваться функционирование СВТ в ограниченном объеме СЗСИ с одновременным формированием сообщения об отказе.

По итогам второго этапа оценки СВТ эксперты оценочной комиссии составляют техническое заключение, в котором излагают:

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

оценка класса защищенности СВТ в соответствии с заданными показателями;

наличие и соответствие дополнительных требований;

аргументация данной оценки: объяснение соответствия СЗСИ требованиям данных показателей, посредством каких средств обеспечивается выполнение каждого требования;

описание испытаний, которым подвергалось СВТ (с указанием состава технических и программных средств);

вывод о соответствии СВТ определенному классу защищенности и объяснение, почему СВТ не может быть сопоставлено (сертифицировано) по более высокому классу защищенности;

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


 
Основные источники публикуемых текстов нормативных правовых актов: газета "Казахстанская правда", база данных справочно-правовой системы Adviser, Интернет-ресурсы online.zakon.kz, adilet.zan.kz, другие средства массовой информации в Сети.
Хотя информация получена из источников, которые мы считаем надежными и наши специалисты применили максимум сил для выверки правильности полученных версий текстов приведенных нормативных актов, мы не можем дать каких-либо подтверждений или гарантий (как явных, так и неявных) относительно их точности.
Компания "КАМАЛ-Консалтинг" не несет ответственности за любые последствия какого-либо применения формулировок и положений, содержащихся в данных версиях текстов нормативных правовых актов, за использование данных версий текстов нормативных правовых актов в качестве основы или за какие-либо упущения в текстах публикуемых здесь нормативных правовых актов.



defacto.kz
Оплата услуг IP-телефонии. Ваучеры Skype, Betamax и другие. Моментальная доставка. 
 
Счетчик посещений Counter.CO.KZ - бесплатный счетчик на любой вкус!   dok from 01.05.2007
 
© 1998-2016 ТОО "КАМАЛ-Консалтинг", Павлодар, Казахстан
Реклама на xFRK