учебники, программирование, основы, введение в,

 

Заключение

Основные идеи курса
Знание стандартов и спецификаций важно для специалистов в области информационной безопасности по целому ряду причин, главная из которых состоит в том, что стандарты и спецификации - одна из форм накопления знаний, в первую очередь о процедурном и программно-техническом уровнях ИБ. В них зафиксированы апробированные, высококачественные решения и методологии, разработанные наиболее квалифицированными специалистами.
В статье 12 закона РФ "О техническом регулировании" определен принцип применения международного стандарта как основы разработки национального стандарта. Это означает, что знание международных стандартов требуется для понимания направлений развития отечественной нормативной базы, что, в свою очередь, важно для выработки стратегии построения и совершенствования информационных систем.
Количество стандартов и спецификаций в области ИБ велико. В курсе рассмотрены наиболее существенные из них, изучение которых необходимо всем или почти всем разработчикам, оценщикам, администраторам, руководителям, пользователям.
В курсе выделены две группы стандартов и спецификаций:

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

Обе группы дополняют друг друга. Оценочные стандарты выделяют важнейшие понятия и аспекты ИС, играя роль организационных и архитектурных спецификаций. Другие спецификации определяют, как строить ИС предписанной архитектуры и выполнять организационные требования.
Из числа рассмотренных в курсе оценочных стандартов необходимо выделить международный стандарт "Критерии оценки безопасности информационных технологий" (точнее, его первоисточник - "Общие критерии") и разработанные на его основе профили защиты. Это - основа современной системы сертификации по требованиям безопасности, системы, к которой стремится присоединиться и Россия.
Основным источником технических спецификаций, применимых к современным распределенным ИС, является Internet-сообщество, уделяющее внимание не только программно-техническому, но также административному и процедурному уровням информационной безопасности. Комплексность подхода Internet-сообщества к проблемам ИБ проявляется и в том, что в спецификациях рассматриваются как профилактические меры, направленные на предупреждение нарушений ИБ, так и меры реагирования на нарушения. Вероятно, среди многих международных стандартов, затрагивающих вопросы сетевой безопасности, наиболее часто цитируется документ X.509 "Служба директорий: каркасы сертификатов открытых ключей и атрибутов". Этот стандарт важен и как образец тщательной проработки и продуманного развития простой, но весьма глубокой идеи - идеи цифрового сертификата, способного хранить атрибуты произвольной природы.
Очень ценно, когда стандарт не просто что-то требует, но предлагает образцы, помогающие выполнить те или иные требования. К числу таких конструктивных стандартов принадлежит BS 7799 (ISO/IEC 17799), дающий возможность справиться с проблемами административного и процедурного уровней информационной безопасности.

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

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

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

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

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

  • идентификация (FIA_UID) и аутентификация (FIA_UAU);
  • определение атрибутов пользователя (FIA_ATD);
  • связывание пользователь-субъект (FIA_USB);
  • политика управления доступом (FDP_ACC);
  • функции управления доступом (FDP_ACF);
  • генерация данных аудита безопасности (FAU_GEN);
  • анализ аудита безопасности (FAU_SAA);
  • управление криптографическими ключами (FCS_CKM);
  • криптографические операции (FCS_COP);
  • базовая защита внутренней передачи (FDP_ITT);
  • защита остаточной информации (FDP_RIP);
  • целостность экспортируемых данных (FPT_ITI);
  • управление отдельными функциями безопасности (FMT_MOF);
  • управление данными функций безопасности (FMT_MTD);
  • безопасность при сбое (FPT_FLS);
  • надежное восстановление (FPT_RCV);
  • посредничество при обращениях (FPT_RVM);
  • разделение доменов (FPT_SEP);
  • доверенный канал передачи между функциями безопасности (FTP_ITC);
  • доверенный маршрут (FTP_TRP).

В качестве важнейших общих требований доверия безопасности выделяются:

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

Профили защиты и их проекты, рассматриваемые в курсе, применимы к следующим сервисам безопасности:

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

Изучаются также инфраструктурные элементы информационной безопасности:

  • анонимизаторы;
  • выпуск и управление сертификатами.

Выделим представленный в курсе профиль защиты для одной из разновидностей анонимизаторов. Он поучителен по крайней мере по двум причинам:

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

В свою очередь, изучение упорядоченного семейства из четырех профилей защиты для аппаратно-программных компонентов, реализующих выпуск, аннулирование и управление сертификатами открытых ключей, способствует активному овладению идеями и понятиями стандарта X.509. Кроме того, данное семейство может служить примером при построении классификационных схем в Руководящих документах Гостехкомиссии России.
Важнейшей (и наиболее привычной) комбинацией сервисов безопасности являются операционные системы. Как таковые они содержат лишь небольшое число специфических требований, среди которых выделяются:

  • максимальные квоты (FRU_RSA.1);
  • дополнительный элемент FAU_GEN.1-CSPP.3, предписывающий предоставление прикладного программного интерфейса для добавления собственных данных к общему регистрационному журналу и/или для ведения приложениями собственных журналов;
  • ряд дополнительных требований, направленных на обеспечение конфиденциальности (FPT_ITC.1.1-CSPP), целостности (FPT_ITI.1.1-CSPP), согласованности (FPT_SYN-CSPP.1.1) критичных данных функций безопасности в распределенных конфигурациях.

Анализ профиля защиты для систем управления базами данных показывает, что при использовании стандартных требований "Общих критериев" существует опасность оставить за рамками рассмотрения специфические свойства приложений и присущие им угрозы.
Весьма поучителен профиль защиты для смарт-карт, при его изучении можно усмотреть множество аналогий со стандартом FIPS 140-2 "Требования безопасности для криптографических модулей". И профиль, и стандарт - хорошие примеры систематического подхода к вопросам собственной защищенности средств безопасности.
Из числа специфических функциональных требований  профиля особого внимания заслуживают:

  • автоматическая реакция аудита безопасности (FAU_ARP);
  • противодействие физическому нападению (FPT_PHP.3).

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

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

Спецификации Internet-сообщества для программно-технического уровня ИБ
Из множества спецификаций  Internet-сообщества, относящихся к программно-техническому уровню информационной безопасности, для данного курса были выбраны три: IPsec, TLS и GSS-API.
Выбор IPsec и TLS основан на том, что как на сетевом, так и на транспортном уровне   эталонной семиуровневой модели могут быть реализованы практически все функции безопасности, выделенные в спецификации X.800 (см. курс "Основы информационной безопасности"). (Исключение составляют избирательная конфиденциальность и неотказуемость; кроме того, конфиденциальность трафика реализуется на сетевом, но не на транспортном уровне, а целостность с восстановлением - наоборот, на транспортном, но не на сетевом уровне .)
Протоколы IPsec обеспечивают управление доступом, целостность вне соединения, аутентификацию источника данных, защиту от воспроизведения, конфиденциальность и частичную защиту от анализа трафика.
Основными элементами архитектуры средств безопасности для IP-уровня являются протокол аутентифицирующего заголовка и протокол инкапсулирующей защиты содержимого, а также механизмы управления криптографическими ключами.
Протокол аутентифицирующего заголовка служит в IPsec для обеспечения целостности пакетов и аутентификации источника данных, а также для защиты от воспроизведения ранее посланных пакетов. Он защищает данные протоколов более высоких уровней и те поля IP-заголовков, которые не меняются на маршруте доставки или меняются предсказуемым образом.
Протокол инкапсулирующей защиты содержимого предоставляет три вида сервисов безопасности:

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

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

  • базу данных политики безопасности;
  • базу данных протокольных контекстов безопасности.

Все IP-пакеты (входящие и исходящие) сопоставляются с упорядоченным набором правил политики безопасности. При сопоставлении используется фигурирующий в каждом правиле селектор - совокупность анализируемых полей сетевого и более высоких протокольных уровней. Первое подходящее правило определяет характер обработки пакета.
Таким образом, системы, реализующие IPsec, функционируют в духе межсетевых экранов, фильтруя и преобразуя потоки данных на основе предварительно заданной политики безопасности.
Протокол безопасности транспортного уровня (TLS) - развитие версии 3.0 протокола SSL. Посредством протокола TLS приложения, построенные в архитектуре клиент/сервер, могут защититься от пассивного   и   активного прослушивания сети и подделки сообщений.
TLS имеет двухуровневую организацию. На первом уровне, опирающемся на надежный транспортный сервис, располагается протокол передачи записей, на втором - протокол установления соединений.
Протокол передачи записей обеспечивает конфиденциальность и целостность передаваемых данных. Представим его функционирование в общем виде. Сообщение разбивается на блоки (записи), сжимается, снабжается имитовставкой, шифруется, после чего выполняется передача результата. На стороне получателя принятые данные расшифровываются, верифицируются, подвергаются декомпрессии и сборке, и затем сообщение доставляется клиенту на вышележащем протокольном уровне.
Протокол установления соединений позволяет серверу и клиенту провести взаимную аутентификацию, согласованно выбрать алгоритм шифрования и криптографические ключи, прежде чем прикладной протокол начнет передачу данных. При выработке совместных секретов обеспечивается конфиденциальность, целостность и защита от нелегального посредника.
В спецификациях TLS фигурируют четыре криптографические операции: цифровая подпись, потоковое шифрование, блочное шифрование и шифрование открытым ключом.
Компьютерная криптография - это большая и сложная тема, для которой особенно важно разбиение на относительно независимые аспекты. Мы выделим три из них:

  • алгоритмический;
  • интерфейсный;
  • собственной защищенности.

Алгоритмического аспекта мы не касаемся. Вопросам собственной защищенности криптографических средств посвящены стандарт FIPS 140-2 и профиль защиты для смарт-карт. Интерфейсный аспект - предмет спецификации   Internet-сообщества "Обобщенный прикладной программный интерфейс службы безопасности" (некоторое внимание этому аспекту уделено и в стандарте FIPS 140-2).
Интерфейс GSS-API преследует цель защиты коммуникаций между компонентами программных систем, построенных в архитектуре клиент/сервер. Он предоставляет услуги по взаимной аутентификации общающихся партнеров и по контролю целостности и обеспечению конфиденциальности пересылаемых сообщений.
Основными понятиями обобщенного прикладного программного интерфейса службы безопасности являются:

  • удостоверение;
  • контекст безопасности;
  • токен безопасности;
  • механизм безопасности;
  • имя;
  • канал передачи данных.

Интерфейс GSS-API предоставляет следующие основные виды функций:

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

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

Спецификации Internet-сообщества для административного и процедурного уровней ИБ
В курсе рассматривается три спецификации  Internet-сообщества для административного и процедурного уровней информационной безопасности:

  • "Руководство по информационной безопасности предприятия";
  • "Как реагировать на нарушения информационной безопасности";
  • "Как выбирать поставщика Интернет-услуг".

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

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

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

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

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

 
На главную | Содержание | < Назад....Вперёд >
С вопросами и предложениями можно обращаться по nicivas@bk.ru. 2013 г.Яндекс.Метрика