Yazov_ITKS
.pdfэффективно обеспечивается заявленный уровень безопасности, а также степень реализации средств защиты. Уровень доверия определяется технологиями, используемыми в процессе проектирования, создания и эксплуатации ИТпродукта. Поэтому требования доверия регламентируют технологию и процесс создания ИТ-продукта, а также необходимость проведения анализа слабых мест защиты.
Следует подчеркнуть, что собственно нормативной базы с требованиями по защите различных информационных систем, как это имеет место в документах ФСТЭК России, «Общие критерии» не содержат. В них также не отражены вопросы защиты информации от утечки по техническим каналам, криптографической защиты и защиты от электромагнитных воздействий. Нет в них и методического обеспечения количественной оценки эффективности защиты.
Во второй части приводится каталог функциональных компонентов для задания в стандартизованном виде функциональных требований для информационных продуктов и систем. Для структуризации пространства требований в ОК введена иерархия «класс-семейство- компонент-элемент». Всего в ОК имеется 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