Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

Yazov_ITKS

.pdf
Скачиваний:
352
Добавлен:
31.05.2015
Размер:
7.37 Mб
Скачать

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

Следует подчеркнуть, что собственно нормативной базы с требованиями по защите различных информационных систем, как это имеет место в документах ФСТЭК России, «Общие критерии» не содержат. В них также не отражены вопросы защиты информации от утечки по техническим каналам, криптографической защиты и защиты от электромагнитных воздействий. Нет в них и методического обеспечения количественной оценки эффективности защиты.

Во второй части приводится каталог функциональных компонентов для задания в стандартизованном виде функциональных требований для информационных продуктов и систем. Для структуризации пространства требований в ОК введена иерархия «класс-семейство- компонент-элемент». Всего в ОК имеется 11 функциональных классов (табл. 4.3), 66 семейств и 135 компонентов.

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

411

Таблица 4.3

Функциональные требования

Функциональный класс

Направленность требований, содержащихся в классе

Функциональное семейство

 

 

 

Класс FAU: Аудит безопасности

Регламентируют процедуры распознавания, регистрации, хране-

Автоматическая реакция аудита безопасности

 

 

 

ния и анализа информации, относящейся к системе безопасности

Генерация данных аудита безопасности

 

 

 

 

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

 

 

 

 

Просмотр аудита безопасности

 

 

 

 

Выбор событий аудита безопасности

 

 

 

 

Сохранение событий аудита безопасности

Класс FCO: Связь

Обеспечивает гарантию, что передающий информацию не сможет

Подтверждение отправления

 

 

 

отказаться от посланного сообщения, а принимающий – от его

Подтверждение приема

 

 

 

получения

 

Класс

FCS:

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

Определяет требования по управлению криптографическими клю-

Управление криптографическими ключами

поддержка

 

чами и операциями

Криптографические операции

Класс FDP: защита данных поль-

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

Политика управления доступом

зователя

 

литикам безопасности, относящимся к защите данных пользовате-

Функции управления доступом

 

 

 

ля

Аутентификация данных

 

 

 

 

Экспорт данных за пределы области управления

 

 

 

 

Политика управления информационными потоками

 

 

 

 

 

 

 

 

 

Функции управления информационными потоками

 

 

 

 

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

 

 

 

 

 

 

 

 

 

Внутренняя передача объекта оценки

 

 

 

 

 

 

 

 

 

Защита остаточной информации

 

 

 

 

Возврат

 

 

 

 

 

 

 

 

 

Целостность хранимых данных

 

 

 

 

Защиты конфиденциальности данных при передаче между функциями без-

 

 

 

 

опасности

 

 

 

 

Защита целостности данных при передаче между функциями безопасности

Класс

FIA:

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

Определяет требования к функциям установления и проверки

Отказы аутентификации

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

подлинности заявленного идентификатора пользователя, а также

Определение атрибутов пользователя

 

 

 

связывания атрибутов безопасности с авторизованным пользова-

Определение секретов

 

 

 

телем

Аутентификация пользователя

 

 

 

 

Идентификация пользователя

 

 

 

 

Связи: пользователь-субъект

Класс FMT: Управление без-

Определяет требования, регламентирующие управление функция-

Управление функциями безопасности

опасностью

 

ми безопасности и их данными, атрибутами и ролями безопасно-

Управление атрибутами безопасности

 

 

 

сти

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

 

 

 

 

Отмена

 

 

 

 

Срок действий атрибутов безопасности

 

 

 

 

Роли управления безопасностью

412

 

 

Продолжение табл. 4.3

Функциональный класс

Направленность требований, содержащихся в классе

Функциональное семейство

 

 

 

Класс FPR: Приватность

Определяет требования по защите пользователя от раскрытия не-

Анонимность

 

санкционированного использования его идентификационных дан-

 

 

Псевдонимы

 

ных

 

 

 

Невозможность обобщения

 

 

 

 

Ненабдюдаемость

Класс FPT: Защита функций

Определяет требования, направленные на обеспечение архитек-

Тест основной абстрактной машины

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

турной безопасности, защиту реализации функций безопасности и

Защита от сбоев

 

защиту данных функций безопасности, а также требования к те-

 

 

Доступность экспортируемых данных функций безопасности

 

стированию, демонстрирующему правильность предположений,

 

 

 

Конфиденциальность экспортируемых данных

 

обеспечиваемых программно-аппаратной платформой и касаю-

 

щихся функций безопасности

Целостность экспортируемых данных

 

 

Передача данных функций безопасности внутри системы

 

 

 

 

 

Физическая защита функций безопасности

 

 

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

 

 

Обнаружение подмены

 

 

Посредничество при ссылках

 

 

Разделение областей

 

 

 

 

 

Протокол синхронности состояний

 

 

Отметка времени

 

 

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

 

 

 

 

 

Согласованность тиражирования функций безопасности

Класс FRU: Использование ре-

Определяет требования, которые поддерживают доступность тре-

Отказоустойчивость

сурсов

буемых ресурсов, а также обеспечивают защиту в случае блоки-

 

Приоритет обслуживания

 

ровки функциональных возможностей, вызванных отказами си-

 

 

 

стемы

 

 

Распределение ресурсов

 

 

 

 

 

Класс FTA: Доступ к системе

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

Ограничение области выбираемых атрибутов

 

 

 

 

 

Ограничение числа одновременных сеансов

 

 

Блокирование сеанса

 

 

Сообщение при доступе к системе

 

 

Хронология доступа

 

 

 

 

 

Открытие сеанса

 

 

 

Класс FTP: Надежный путь/ ка-

Определяет требования, направленные на обеспечение уверенной

Надежный внутренний канал функций безопасности

нал

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

Надежный путь

 

и целостность передаваемых данных

 

413

 

 

Таблица 4.4

 

Классы и семейства требований доверия

 

Класс требований доверия

Направленность требований, содержащихся в классе

Семейство требований доверия

 

 

 

Класс АСМ: Управление кон-

Содержит требования, направленные на обеспечения целостности контролируемых ими частей

Автоматизация управления конфигурацией

фигурацией

объекта оценки (системы), предоставляя метод отслеживания любых изменений, обеспечения

 

Объем управления конфигурацией

 

таким образом доверия к тому, что объект оценки и документация представляют собой дей-

 

 

 

ствительно продукт и документы, подготовленные для распространения

 

Класс ADO: Поставка и функ-

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

Поставка

ционирование

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

 

Инсталляция, генерация и запуск

 

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

 

 

Класс ADV: Разработки

Определяет требования к пошаговому уточнению функций безопасности в процессе разработки

Функциональная спецификация

 

 

Высокоуровневый проект

 

 

Представление реализации

 

 

 

 

 

Внутренние организации функции безопасности

 

 

Низкоуровневый проект

 

 

 

 

 

Соответствие представлений

 

 

Моделирование политики безопасности

Класс AGD: Руководящие до-

Содержит требования, направленные на обеспечение понятности и полноты документации,

Руководство администратора

кументы

представляемой разработчиком

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

Класс ADC: Поддержка жиз-

Определяет требования, определяющие доверия к модели жизненного цикла для всех шагов

Безопасность разработки

ненного цикла

разработки системы, в том числе процедур и политики устранения изъянов, правильного ис-

 

Устранение изъянов

 

 

 

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

Определение жизненного цикла

 

среды разработки

 

Инструменты и методы

 

 

Класс АТЕ: Испытания

Устанавливает требования к испытаниям, которые демонстрируют, что функции безопасности

Покрытие

 

удовлетворяют установленным требованиям

Глубина

 

 

Функциональные тесты

 

 

Независимое тестирование

Класс AVA: Оценивание уяз-

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

Анализ скрытых каналов

вимости

эксплуатации (возникающих при проектировании, построении, функционировании, неправиль-

Неправомерное использование

 

ном использовании или конфигурировании системы)

 

 

Стойкость функции безопасности

 

 

Анализ уязвимости

 

 

 

414

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

4.6. Специальные требования и рекомендации по защите информации

При проектировании ИТКС в защищенном исполнении или СЗИ для функционирующих ИТКС необходимо учитывать требования по организации защиты информации ограниченного доступа, не содержащей сведения, составляющих государственную тайну (далее конфиденциальной информации), которые регламентируются специальным нормативно-методическим документов «Специальные требования и рекомендации по защите конфиденциальной информации (СТР-К)» [52].

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

Некоторые из положений этого документа, касающиеся создания ИТКС в защищенном исполнении и СЗИ, сводятся к следующему.

415

 

Управление досту-

 

 

Дистрибуция

 

пом

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Средства управ-

 

 

 

 

Поставка

 

 

ления проектом

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Управление вер-

 

 

 

 

Установка,

 

 

сиями

 

 

 

 

настройка,

 

 

 

 

 

 

 

 

 

 

 

 

 

запуск

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Конфигурация

 

 

 

 

 

 

 

 

 

 

 

 

 

 

проекта

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Требования доверия

Разработка

 

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

 

Процесс разработки

 

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

 

Анализ защиты

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Общие функциональные спецификации

Архитектура

защиты

Форма представления продукта на сертифика-

Структура средств защиты

Частные спецификации средств защиты

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

Средства разработки

 

Руководство

 

Безопасность

 

 

Полнота те-

 

администра-

 

среды разра-

 

 

стирования

 

 

 

 

 

 

тора

 

ботки

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Исправление

 

 

 

 

Руководство

 

ошибок и

 

 

 

 

пользователя

 

 

устранения

 

 

 

 

 

 

 

уязвимостей

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Технология

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Методика те-

 

 

 

 

разработки

 

 

 

 

 

 

 

 

 

стирования

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Средства раз-

 

 

 

 

 

 

 

 

 

 

 

 

 

 

работки

 

 

Независимое

 

 

 

 

 

 

 

 

 

 

 

 

 

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Рис. 4.14. Таксономия требований доверия

416

Анализ скрытых каналов

Анализ стойкости средств защиты

Анализ продукта на наличие уязвимостей

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

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

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

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

Ворганизации должен быть документально оформлен

417

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

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

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

Для обеспечения ЗИ в процессе эксплуатации ИТКС должно быть предусмотрено соблюдение следующих основных положений и требований:

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

на период обработки защищаемой информации в помещениях, где размещаются основные техни-

418

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

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

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

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

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

23 Средства и системы, в которых обрабатывается защищаемая информация

419

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

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

Временно не используемые носители информации должны храниться пользователем в местах, не доступных для посторонних лиц.

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

420

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]