---

Разделы На главную История денег и экономики История экономических знаний Формы безналичных денег Международные финансы Экономические концепции Экономические теории Экономика в реальной жизни Экономический анализ и интеграция Макроэкономика Экономика и социальное общество Социальная экономика Социология Кризисная экономика Инфляция в экономике Экономика зарубежных стран Иностранные деньги Государственное регулирование Бюджетная система Политическая экономия Политология Законы денег Налогообложение Аудит Банкротство Теория рынка Конкуренция Международная торговля Товарная биржа Нефть и газ на бирже Логистика Банки - услуги и операции Банки в России Банковский кредит Недвижимость Ипотека в банке Инвестирование Стратегии инвестирования Инвестиционные фонды Ценные бумаги Акции Вексель Облигации Опционы Фьючерсы Биржевая торговля Биржа Forex Фондовый рынок Фондовый рынок России Волны Эллиотта Теория фракталов Торговая теория Ганна Фибоначчи на бирже Графический анализ на бирже Паттерны Биржевой анализ "Крестики-нолики" Японские свечи Технический анализ Математика на бирже Фундаментальный анализ Биржевая торговля Стратегии торговли Механические торговые системы Программирование МТС Управление торговым капиталом Управление портфелем Управление риском Страхование Профессия трейдер Практический трейдинг Технологии инфосистем Информационный рынок Безопасность информации Криптология и криптография Реклама PR - Public Relations Маркетинг Финансовая система Начало бизнеса Предпринимательство Малый бизнес Микроэкономика Торговля Ценообразование Работа в Интернете Сайты, софт, дизайн Управление качеством Управление предприятием Производство продукции Стратегический менеджмент Учебники по менеджменту Системы и организации Теория систем Планирование Статистика финансов Управление персоналом Трудовые отношения Бухгалтерия «1С:Бухгалтерия» Управленческий учет Делопроизводство и офис Автоматизация делопроизводства Рынок труда Карьера Менеджер Лидерство и бизнес карьера Лидерство и карьера Общение и переговоры Общение в бизнесе Бизнес переговоры Инновации в моделировании Экономическое моделирование Нейронные сети Нейролингвистика Логика нейросетей Программирование Пакет Excel Технологии программирования Языки программирования Практическая психология Психологические тренинги Психология в медицине Возрастная психология Ваши скрытые резервы Здоровье и долголетие Работа с эмоциями Пикап Управление временем Гипнотерапия Подсознание Трансовые техники Магия Здоровье советы Спорт для здоровья Йога Религии Эзотерика Мистицизм

---

Маршрутизация, фильтрация и ограничение вещания

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

В граничных маршрутизаторах следует аутентифицировать соседей в рамках протокола BGP.

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

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

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

Рис. 14.1.  Входная фильтрация IP-пакетов по исходным адресам.

Дополнительной мерой защиты потребителей от атак, основанных на подделке исходных адресов, является выходная фильтрация - от сети Internet к периферийной системе (см. рис. 14.2). Во всех граничных маршрутизаторах, к которым подключены потребители, следует сразу отфильтровывать потоки данных, идущие к потребителю и имеющие исходные адреса из выделенного ему пространства.

Рис. 14.2.  Выходная фильтрация IP-пакетов по исходным адресам.

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

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

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

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

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

Меры по защите Internet-сообщества

Поставщики Internet-услуг играют критически важную роль в повышении безопасности Internet.

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

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

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

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

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

Многие маршрутизаторы позволяют злоумышленникам совершать опасные действия, например:

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

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

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

На маршрутизаторы нельзя возлагать выполнение мелких услуг, которые нередко включены по умолчанию.

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

Конфигурационную информацию маршрутизаторов и коммутаторов следует сопровождать на файловом сервере.

Производители предлагают много сетевых устройств - от недорогих маршрутизаторов до принтеров, - принимающих соединения по протоколу telnet без запроса пароля. Если в сети поставщика Internet-услуг есть такое оборудование, доступ к нему следует ограничить. Кроме того, потребителям необходимо рекомендовать блокировать доступ к подобным устройствам из внешних сетей. Крайне нежелательно использовать протокол telnet для управления компонентами сети.

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

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

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


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

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

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

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

Вблизи чужого оборудования никого нельзя оставлять без присмотра. Такое оборудование запрещается трогать, фотографировать или исследовать.

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



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

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

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

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

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

потребители услуг по размещению ресурсов;

потребители, разместившиеся там же, где и поставщики услуг.

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

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

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

Размещение Web-серверов

Многие организации передают свои Web-серверы поставщикам Internet-услуг вместе с обязанностями по эксплуатации и администрированию, исходя, главным образом, из соображений информационной безопасности.

Помимо перечисленных выше аспектов, поставщики услуг при администрировании оборудования, на котором размещены Web-серверы, должны руководствоваться такими положениями:

разумное использование DNS. В момент подключения клиента не следует выполнять поиск его имени, поскольку это делает Web-серверы уязвимыми для атак на доступность и заметно сказывается на производительности;

минимизация привилегий. Web-демон следует выполнять от имени пользователя и группы, специально выделенных для этой цели и имеющих минимальные привилегии. Ответственный за информационное наполнение Web-сервера должен работать от имени другого пользователя;контроль DocumentRoot. Все, что располагается ниже этого каталога, надо тщательнейшим образом проконтролировать. Желательно использовать системный вызов chroot для смены корневого каталога HTTP-демона;контроль UserDir. На сервере нельзя регистрировать других пользователей, кроме администраторов. Если такие пользователи все-таки есть, директиве "UserDir" (в случае ее разрешения) не следует предоставлять доступ к информации пользователей - в частности, не разрешать выполнение командных процедур от имени этих пользователей;разбиение на виртуальные серверы. Единый сервер, на котором размещено множество серверов (виртуальных доменов), необходимо организовать так, чтобы все данные, программы и регистрационные журналы различных виртуальных серверов были отделены друг от друга и чтобы доступ к "чужой" конфигурации или данным был невозможен. Кроме того, надо исключить доступ к данным или программам на сервере одного потребителя через локатор ресурсов, в хостовой части которого указано имя сервера другого потребителя;

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

Программы на серверной стороне, поддерживающие CGI или какой-либо другой интерфейс, важны для гибкости web как коммуникационной среды. Однако эта гибкость достигается ценой появления угроз безопасности, а слабая программа может сделать уязвимыми все виртуальные домены на сервере. Правила, сообразно которым поставщик Internet-услуг разделяет программы на допустимые и недопустимые, является показательным аспектом всей его политики безопасности.

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

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

Данные, которые пишет программа серверной стороны, следует считать конфиденциальными.


Чтобы сделать невозможным доступ к таким данным через навигаторы, права устанавливаются так, чтобы у Web-демона не было права на чтение этих данных.

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

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

Регистрационная информация, генерируемая Web-демоном, должна быть весьма конфиденциальной. Для реализации этого положения понадобится:



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

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



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

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

Загрузку информационного наполнения на сервер поставщика Internet-услуг следует производить по доверенному каналу.

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

Поисковые машины надо сконфигурировать так, чтобы поиск ограничивался частями Web-сервера, доступными всем.

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

Роль поставщика Internet-услуг в реагировании на нарушения безопасности

Мы уже обсуждали тему реагирования на нарушения информационной безопасности и взаимодействие групп реагирования с опекаемым сообществом. Затронута она и в Дополнении.

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

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

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

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

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

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

Если имеет место нарушение, направленное на какого-либо потребителя услуг подключения, поставщик Internet-услуг должен проинформировать его об атаке и, по возможности, оказать помощь в следующем:

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

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

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

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

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

Возможные вопросы к поставщику Internet-услуг

При выборе поставщика Internet-услуг потребителям имеет смысл выяснить целый ряд вопросов:

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

Если существует, то:

Какие у нее права, правила работы и предоставляемые услуги?Какова цепочка эскалации докладов, которой должен следовать потребитель?

Если группы реагирования нет, то:

Какую роль играет поставщик услуг в реагировании на нарушения информационной безопасности?Есть ли какая-нибудь группа реагирования, к которой потребитель может обратиться?

Оказывает ли поставщик Internet-услуг какие-либо дополнительные услуги в области информационной безопасности?Информирует ли поставщик своих потребителей об атаках против них?Оказывается ли помощь в прослеживании источника атаки?Осуществляется ли сбор и сохранение улик, свидетельствующих о нарушении информационной безопасности?Какую информацию сообщает поставщик услуг своим потребителям при обнаружении уязвимостей в предоставляемых им сервисах?Как и когда информация об уязвимостях передается потребителям?К кому может обратиться потребитель по электронной почте для прояснения вопросов информационной безопасности?К кому может обратиться потребитель по электронной почте для доклада о ненадлежащем поведении сторонних пользователей?Как организованы коммуникации между поставщиком Internet-услуг и потребителями, если имеют место признаки нарушения информационной безопасности?Какие меры принимает поставщик услуг, чтобы не допустить несанкционированной маршрутизации потоков данных в свою сеть или через нее?Разделены ли на сегменты сети, поддерживающие потребителей услуг подключения и услуг размещения серверов?Какие принимаются меры для обеспечения безопасности производственных сервисов, предоставляемых по Internet потребителями, в том числе для защиты от атак на доступность, вторжений, подделок?Насколько быстро поставщик накладывает защитные заплаты на программное и микропрограммное обеспечение, функционирующее на производственном оборудовании?Сканируются ли порты в сетях потребителей, и сообщается ли им о найденных аномалиях?Предоставляются ли услуги по аудиту безопасности и усилению защиты систем потребителей?Есть ли у поставщика Internet-услуг система активного аудита, обнаруживающая в реальном времени сетевые и системные атаки?Какова политика добропорядочного пользования для информационного наполнения Web-сервера, размещенного у поставщика?Как организована физическая защита оборудования, использующегося для размещения серверов потребителей?Как часто производится резервное копирование информационного наполнения Web-серверов?Как часто резервные носители передаются на внешнее хранение?Осуществляет ли поставщик услуг балансировку нагрузки, чтобы предотвратить насыщение сети трафиком других потребителей?Какое резервное оборудование используется в случае поломок? Как быстро оно может быть развернуто?Какие виды доступа предоставляются для управления информационным наполнением размещенных у поставщика серверов?Предоставляет ли поставщик защищенные Web-серверы (https)?Закрыт ли доступ к информационному наполнению защищенного Web-сервера для других потребителей?Как передавать информационное наполнение на защищенный Web-сервер?Какова политика добропорядочного пользования для потребителей, разделяющих площади с поставщиком Internet-услуг?Как организована физическая защита оборудования потребителей, размещенного на площадях поставщика?Как обеспечена разводка по сети питания для оборудования разных потребителей, размещенного на общих площадях?Как обеспечено сетевое разделение для оборудования разных потребителей, размещенного на общих площадях?

На этом мы завершаем рассмотрение спецификации Internet-сообщества "Как выбирать поставщика Internet-услуг".

<

Защита системной инфраструктуры

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

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

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

Все услуги выиграют от организации надежной защиты на сетевом уровне средствами IPsec.

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

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

Регистрационная информация должна быть доступна на чтение только системному администратору.

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

Нельзя подключать системы к транзитным сегментам.

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

Отслужившие срок носители должны уничтожаться, а не выбрасываться.

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

Доменная система имен (DNS) играет критически важную роль в повседневной деятельности миллионов пользователей Internet. Поставщикам услуг при администрировании DNS-серверов следует обратить внимание на следующие аспекты:



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

синхронизация часов: синхронизация установленного на серверах времени с помощью протокола NTP с аутентификацией.

При конфигурировании почтовых серверов поставщики Internet-услуг должны руководствоваться такими положениями:

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

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

При конфигурировании серверов телеконференций (NNTP) поставщикам Internet-услуг необходимо соблюдать следующие требования:

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

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

Мы приступаем к детальному рассмотрению четырехфазной (планирование - реализация - оценка - корректировка , ПРОК) модели процесса управления информационной безопасностью, примененной в стандарте BS 7799-2:2002.

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

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

Ключевым элементом фазы планирования является анализ рисков. Этот вопрос детально рассмотрен в курсе "Основы информационной безопасности" [91]; здесь мы не будем на нем останавливаться.

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

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

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

выявлены внутренние противоречия в документации СУИБ;риски вышли за допустимые границы.

Оценка может выполняться в нескольких формах:

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

Аудит должен выполняться регулярно, не реже одного раза в год. В процессе аудита следует убедиться в следующем:

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

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

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

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

При корректировке прежде всего следует устранить несоответствия следующих видов:

отсутствие или невозможность реализации некоторых требований СУИБ;неспособность СУИБ обеспечить проведение в жизнь политики безопасности или обслуживать производственные цели организации.

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

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

<

и процедурному уровням информационной безопасности,

Продолжая рассмотрение стандартов и спецификаций, относящихся к административному и процедурному уровням информационной безопасности, мы приступаем к изучению двух частей британского стандарта BS 7799 (см. [31], [32]), фактически имеющего статус международного (ISO/IEC 17799). Русский перевод первой части опубликован в качестве приложения к информационному бюллетеню Jet Info [28].

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

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

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

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

Предлагаемые в первой части стандарта регуляторы безопасности разбиты на десять групп:



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

общеорганизационные аспекты защиты;

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

безопасность персонала;

физической безопасности и безопасность окружающей среды;

администрирование систем и сетей;

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

контроль соответствия требованиям.

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

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

распределение обязанностей по обеспечению информационной безопасности;

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

уведомление о случаях нарушения защиты;

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

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

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

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

Во второй части стандарта BS 7799-2:2002 "Системы управления информационной безопасностью - спецификация с руководством по использованию" предметом рассмотрения, как следует из названия, является система управления информационной безопасностью.

Под системой управления информационной безопасностью (СУИБ) (Information Security Management System, ISMS) понимается часть общей системы управления, базирующаяся на анализе рисков и предназначенная для проектирования, реализации, контроля, сопровождения и совершенствования мер в области информационной безопасности.Эту систему составляют организационные структуры, политика, действия по планированию, обязанности, процедуры, процессы и ресурсы.

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

планирование;реализацию;оценку;корректировку.

По-русски данную модель можно назвать ПРОК (в оригинале - Plan-Do-Check-Act, PDCA). Детальный анализ каждой из выделенных фаз и составляет основное содержание стандарта BS 7799-2:2002.

Регуляторы безопасности и реализуемые

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

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

В частности, следует рассмотреть необходимость:

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

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

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

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

Четвертая подгруппа - защита системных файлов - предусматривает:

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

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

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

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

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

Процесс планирования бесперебойной работы организации должен включать в себя:

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

Для обеспечения бесперебойной работы организации необходимы процедуры трех типов:

процедуры реагирования на нештатные ситуации;процедуры перехода на аварийный режим;процедуры возобновления нормальной работы.



Примерами изменений, которые могут потребовать обновления планов, являются:

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

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

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

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

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

На этом мы завершаем рассмотрение регуляторов безопасности, предусмотренных стандартом BS 7799.

Регуляторы безопасности и реализуемые ими цели. Часть 1. Регуляторы общего характера

Мы приступаем к рассмотрению десяти групп регуляторов безопасности, выделенных в стандарте BS 7799.

К первой группе отнесено то, что связано с политикой безопасности, а именно:

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

Цель регуляторов этой группы - определить стратегию управления безопасностью и обеспечить ее поддержку.

Рекомендуемая структура документированной политики изложена в курсе "Основы информационной безопасности" [91].

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

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

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

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

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

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

Очень важна третья группа регуляторов безопасности - классификация активов и управление ими.

Меры по безопасному администрированию систем и сетей разделены в стандарте BS 7799 на семь подгрупп:

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

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

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

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

Под повседневным обслуживанием в стандарте имеется в виду резервное копирование, протоколирование действий операторов, регистрация, доведение до сведения руководства и ликвидация сбоев и отказов.

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

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

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

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

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

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

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

организация защищенных областей;защита оборудования;меры общего характера.

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

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

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



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

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

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

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

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

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

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

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



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

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

Управление доступом средствами операционных систем направлено на защиту от несанкционированного доступа к компьютерным системам. Для этого предусматриваются:

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

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

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

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

В федеральном стандарте США FIPS

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

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

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

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



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

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

роли, сервисы и аутентификация;

конечноавтоматная модель;

физическая безопасность;

эксплуатационное окружение; управление криптографическими ключами; электромагнитная совместимость;

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

доверие проектированию;

сдерживание прочих атак.

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

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

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

Модель в виде конечного автомата должна описывать деление на обязательные и дополнительные состояния.

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

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

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



На требованиях электромагнитной совместимости мы останавливаться не будем.

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

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

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

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

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

На втором уровне требуются:



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

К третьему уровню предъявляются следующие дополнительные требования:

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

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


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

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

Требования безопасности. Часть

Мы приступаем к рассмотрению трех последних из одиннадцати предусмотренных стандартом FIPS 140-2 групп требований безопасности для криптографических модулей.

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

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

Специфицированы следующие виды проверок:

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

В число проверок, выполняемых по условию, входят:

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

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

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

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

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

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

Комплект документации состоит из руководства крипто-офицера (аналог руководства администратора) и пользователя.

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

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

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

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

В качестве приложений стандарт FIPS 140-2 содержит рекомендации, дополняющие одиннадцать групп требований безопасности. К ним относятся:

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

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

<

Требования безопасности. Часть 1. Спецификация, порты и интерфейсы, роли, сервисы и аутентификация

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

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

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

Следует описать ручные и логические средства управления криптографическим модулем, физические или логические индикаторы состояния, применимые физические (в частности, электрические) и логические характеристики.

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

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

Обязательный элемент документации - политика безопасности   криптографического модуля.

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

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

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

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

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

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

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

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

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

В рамках криптографического модуля для операторов поддерживаются роли и ассоциированные с ними сервисы и права доступа (ролевой доступ рассматривался в курсе "Основы информационной безопасности" [91]).


Один оператор может быть приписан нескольким ролям. Если модуль поддерживает параллельную работу нескольких операторов, он должен управлять разделением ролей.

Требуется поддержка по крайней мере следующих ролей:

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

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

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

Криптографический модуль должен предоставлять следующие сервисы:

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

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

Если не производится чтение, модификация или замена критичных данных (например, выполняется лишь изучение состояния или тестирование модуля), оператор не обязан активизировать какую-либо роль.

Начиная со второго уровня безопасности, активизации роли должна предшествовать аутентификация оператора: ролевая или (на третьем и четвертом уровнях безопасности) персональная.

В стандарте не оговорены требуемые механизмы аутентификации, специфицирована лишь их стойкость. Вероятность случайного успеха одной попытки должна составлять менее 1/1000000, вероятность случайного успеха какой-либо из нескольких попыток, производимых в течение минуты, - менее 1/100000. Это весьма (а на наш взгляд - чрезмерно) мягкие требования, если учитывать, что в году 525600 минут. Очевидно, необходимы меры противодействия многократным неудачным попыткам аутентификации.

Требования безопасности. Часть 2. Модель в виде конечного автомата, физическая безопасность

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

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

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

Могут быть предусмотрены и другие, дополнительные состояния:

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

Вопросы обеспечения физической безопасности   криптографических модулей исключительно важны и сложны. В стандарте FIPS 140-2 им уделено очень много внимания. Мы, однако, остановимся лишь на основных моментах.

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

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

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

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

И, наконец, в соответствии с принятым в стандарте подходом, меры группируются по четырем уровням безопасности.

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

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

На втором уровне безопасности предусмотрено обнаружение нарушений, а начиная с третьего - реагирование на нарушения.

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

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

Требования безопасности. Часть 3. Эксплуатационное окружение, управление криптографическими ключами

Эксплуатационное окружение - это совокупность необходимых для функционирования модуля средств управления аппаратными и программными компонентами. В стандарте FIPS 140-2 рассматривается несколько видов окружения:

универсальное, с коммерческой операционной системой, управляющей как компонентами модуля, так и другими процессами и приложениями;

ограниченное, являющееся статическим, немодифицируемым (например, виртуальная Java-машина на непрограммируемой плате для персонального компьютера);

модифицируемое, которое может быть реконфигурировано и включать средства универсальных ОС.

Ядро универсального и модифицируемого окружения - операционная система. На первом уровне безопасности к ней предъявляются следующие требования:

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

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

Характерная черта третьего уровня безопасности - использование доверенного маршрута.

На четвертом уровне безопасности криптографического модуля нужна ОС с оценочным уровнем доверия не ниже четвертого.

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

генерация случайных чисел;

генерация ключей;

распределение ключей; ввод/вывод ключей; хранение ключей; обнуление ключей.

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

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

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

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

Модуль должен ассоциировать введенный ключ (секретный или открытый) с владельцем (лицом, процессом и т.п.).

Общие критерии" и профили защиты на их основе

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

Эта цель близка и понятна российским специалистам. В 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).

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

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

По результатам рассмотрения ОК можно наметить следующие направления дальнейших исследований и разработок:

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

Основные идеи курса

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

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

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

В курсе выделены две группы стандартов и спецификаций:

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

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

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

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

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

Очень ценно, когда стандарт не просто что-то требует, но предлагает образцы, помогающие выполнить те или иные требования. К числу таких конструктивных стандартов принадлежит BS 7799 (ISO/IEC 17799), дающий возможность справиться с проблемами административного и процедурного уровней информационной безопасности.

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

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

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

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

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

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

В Руководстве основной упор делается на два последних этапа.

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

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

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

Тема реагирования развивается в спецификации   Internet-сообщества "Как реагировать на нарушения информационной безопасности".

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

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

Чтобы считаться группой реагирования, необходимо:

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

Группа реагирования должна объяснить, кого она опекает, и определить предоставляемые услуги, опубликовать свои правила и регламенты, порядок доклада о нарушениях.

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

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

<

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

Из множества спецификаций  Internet-сообщества, относящихся к программно-техническому уровню информационной безопасности, для данного курса были выбраны три: IPsec, TLS и GSS-API.

Выбор IPsec и TLS основан на том, что как на сетевом, так и на транспортном уровне   эталонной семиуровневой модели могут быть реализованы практически все функции безопасности, выделенные в спецификации X.800 (см. курс "Основы информационной безопасности" [91]). (Исключение составляют избирательная конфиденциальность и неотказуемость; кроме того, конфиденциальность трафика реализуется на сетевом, но не на транспортном уровне, а целостность с восстановлением - наоборот, на транспортном, но не на сетевом уровне .)

Протоколы 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, на уровне исходного текста мобильны по отношению к смене механизмов безопасности. Тем самым реализуется открытость прикладных систем и соответствующих средств защиты.

---

---