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

При временном разделении каналов каждому абоненту отводится свой независимый интервал времени, не перекрывающийся по времени с другими абонентами. Сообщения абонентов передаются последовательно одно за другим с частотой следования канальных импульсов, определяемой теоремой Котельникова. Для осуществления синхронной работы передающего и приемного устройств в системе предусмотрены сигналы синхронизации (СС). Временная эпюра распределения каналов при ВРК показана на рис. 1.35 [3].

Рис. 1.35. Временная эпюра распределения каналов при ВРК

Групповой сигнал лежит на общем интервале времени T_кi, но временные интервалы канальных сигналов не перекрываются. В силу этого

(74)

Следовательно, такие сигналы ортогональны.

Системы с ВРК характеризуются следующими параметрами:

– период следования канальных импульсов T_кi = 1/μF_в, где F_в – верхняя частота в спектре аналогового сигнала; μ – коэффициент, μ ³ 2;

– длительность канального импульса t_сi=1/(μF_вN);

– защитный интервал t_зi = (0,1...0,5)t_сi;

– канальный интервал t_кi = t_сi + t_зi;

– частота следования N каналов F_к = NF_кi (F_кi=1/T_кi);

– ширина полосы спектра сигнала Δf_с = 1/t_с.

В системах передачи с ВРК в качестве переносчиков используются периодические последовательности импульсов. Модулируя какой-либо параметр импульса, можно получить: АИМ, ШИМ, временную импульсную модуляцию – ВИМ (разновидностью которой является ФИМ), ЧИМ.

На рис. 1.36. приведена структурная схема системы с ВРК.

Рис. 1.36. Структурная схема системы с ВРК: ГТИ – генератор тактовых импульсов; ГКИ – генератор канальных импульсов; СС – система синхронизации, формирующая синхроимпульсы; КМ – канальный модулятор; S – сумматор канальных импульсов; О – отправитель сообщения; ЛС – линия связи; ВСК – временной селектор каналов; КД – канальный демодулятор; ГСИ – генератор селекторных импульсов; П – получатель сообщения; ФНЧ – фильтр нижних частот с полосой 0,3...3,4 кГц

В этой системе может использоваться любой из ранее перечисленных видов модуляции канального импульса при передаче телефонных сигналов. Телефонные сигналы ограничиваются полосой частот 0,3...3,4 кГц с помощью фильтров нижних частот, стоящих перед канальными модуляторами. Сигналы поступают на входы канальных модуляторов, при помощи которых речевые сигналы преобразуются в сигналы АИМ посредством импульсных переносчиков, поступающих от ГКИ.

Сигналы АИМ менее устойчивы к помехам, чем сигналы ФИМ, поэтому при помощи преобразования АИМ-ФИМ в канальных модуляторах импульсные сигналы, модулированные по амплитуде, преобразуются в сигналы, модулированные по фазе. Затем все канальные сигналы объединяются в групповой сигнал в сумматоре и подаются вместе с синхроимпульсом в ЛС. Синхросигнал отличается от канальных сигналов определенными признаками, что позволяет выделить его на приемной стороне.

В приемной части аппаратуры сигналы поступают на временные селекторы каналов, поочередно открывающиеся и пропускающие импульсы, относящиеся только к данному каналу. Далее в канальных демодуляторах осуществляется преобразование ФИМ-АИМ, а восстановление непрерывного сигнала производится ФНЧ с полосой частот 0,3...3,4 кГц.

В принципе, системы передачи с ВРК могут использовать только АИМ или ШИМ. В этом случае после канальных демодуляторов сигналы поступают на ФНЧ, где и происходит восстановление аналогового сигнала.

Если же в системе использовалась ФИМ, то сначала нужно произвести обратные преобразования ФИМ-АИМ и уже после этого подать сигнал на ФНЧ.

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

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

Следует отметить, что взаимные помехи, появляющиеся между каналами в системах передачи с ВРК, являются результатом ограничения полосы пропускания группового тракта, неравномерности его АЧХ и нелинейности ФЧХ.

61. Процесс квалификационного анализа ИТ-продуктов с использованием профилей защиты и заданий по безопасности. ГОСТ Р 15408:2002 - структура и области применения. последовательность формирования требований и спецификаций: среда безопасности, цели безопасности, требования безопасности и краткая спецификация объекта оценки. Парадигма функциональных требований. Представление функциональных требований: классы, семейства (ранжирование, управление, аудит), компоненты (подчиненность по иерархии, зависимости – прямые, косвенные, выбираемые, операции – итерация, назначение, выбор, уточнение), элементы. Примеры функциональных классов.

ГОСТ Р 15408:2002 РД Критерии оценки безопасности информационных технологий

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Среда безопасности

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

При установлении среды безопасности автор ПЗ или ЗБ должен принять во внимание:

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

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

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

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

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

Рисунок 4.5 – Последовательное формирование требований и спецификаций

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

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

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

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

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

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

Требования безопасности ИТ проистекают только из целей безопасности ОО и целей безопасности его среды, относящихся к ИТ

Требования безопасности ИТ

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

В ОК представлены две различные категории требований безопасности – функциональные требования и требования доверия.

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

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

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

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

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

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

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

Краткая спецификация ОО

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