Часть 1. Современное состояние автоматизированных систем с точки зрения проблемы защиты данных

1. Архитектура АС

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

1.1 Элементы АС

Возможно два уровня рассмотрения АС: системный (низкий) и прикладной (высокий). В первом случае единица измерения данных -- физический объект (байт, дисковый сектор и т.п.), во втором -- объект прикладной модели (учётная карточка, чертёж, документ и т.п.). От уровня к уровню метод выделения структурных элементов АС не меняется.

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

Программно-аппаратный блок АС работает с данными в рамках установленной политики доступа к данным субъектов системы. Защита и учёт данных внутри программно-аппаратного блока производится средствами системы. Таким образом, нарушение целостности и/или безопасности данных внутри этого блока всегда является следствием возникшей нештатной ситуации: поломки оборудования, ошибки программного обеспечения, нарушения политики безопасности субъектом системы. Если механизм защиты данных удовлетворяет требованиям пользователя по безопасности системы, прочие действия по повышению безопасности носят административный характер.

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

Программно-аппаратный блок.

Средства обработки данных.

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

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

Средства хранения данных.

Устройства, содержащие данные постоянно, в том числе и тогда, когда АС находится в нерабочем или выключенном состоянии.

На системном уровне это -- несъёмные жёсткие диски, ПЗУ и ППЗУ и прочие внуренние накопители данных. На прикладном уровне -- файловые системы, хранилища баз данных и т.п.

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

Среда взаимодействия.

Средства передачи данных.

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

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

Интерфейсные средства.

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

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

Средства диагностики и обслуживания

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

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

1.2 Роль человека в человеко-машинных системах

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

Пользователь АС.

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

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

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

Разработчик АС.

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

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

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

Администратор АС.

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

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

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

1.4 Типы АС.

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

Монолитные АС содержат один программно-аппаратный блок, а среда взаимодействия в таких АС ограничивается интерфейсными элементами. Обработка и хранение данных в такой системе полностью подчиняются политике безопасности на протяжение всего ЖЦ, начиная со входа в систему и заканчивая выходом из неё.

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

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

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

Классификация АС на основе требований к защите

Классификация АС на основе требований к защите производится на основе следующих определяющих признаков:

2. Функции АС

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

Стадия исследования.

Стадия проектирования.

Стадия подготовки инфраструктуры.

Стадия реализации.

Интеграция всех стадий ЖЦ продукта.

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

Информационная служба АС.

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

Подсистема диагностики.

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

Подсистема мониторинга.

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

Справочная и обучающая подсистемы.

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

Сервисные службы АС.

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

Архив.

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

Средства повышения надёжности АС.

Для повышения надёжности системы применяется функциональное дублирование элементов программно-аппаратного блока и среды взаимодеёствия (т.н. зеркалирование), дополнительный контроль цельности и аутентичности потоков данных (например, двойная или множественная проверка информации), техническая и административная защита всех элементов АС от внешнего воздеёствия. Внедрение всех этих средств позволяет поднять требования и к гарантированным свойствам продукта или надёжности пользовательского сервиса. Более того, наличие таких требований в условиях решаемой пользовательской задачи как правило приводит к введению их на уровне системы. Например, требование бесперебойной работы АС в режиме 24*7 скорее всего повлечёт за собою полное дублирование функций всех элементов АС, включая программно-аппаратный блок (допустим, кластер вместо одного компьютера) и среды взаимодеёствия (допустим, использование двух независимых каналов связи).

Средства оперативного восстановления сбоев.

Применяются для отработки нештатных ситуаций в системе нарядусо средствами восстановления данных из архивов. Как правило, с этой целью организуется резервный парк оборудования для полной или частичной замены оборудования с остановкой работы сбойного узла АС. Для частичной замены оборудования без остановки сбойного узла АС применяется технология "горячей замены" (hot spare) или подобная ей. Как и в случае средств повышения надёжности, наличие требования оперативного восстановления данных на уровне пользовательской задачи влечёт за собою соответствующие решения на системном уровне.

3. Аппаратное обеспечение АС.

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

3.1 Вычислительное аппаратное обеспечение.

Вычислительное аппаратное обеспечение имеет дело с данными, циркулирующими в системе.

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

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

3.2 Вспомогательное аппаратное обеспечение.

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

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

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

4. Программное обеспечение АС.

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

4.1 Системное программное обеспечение.

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

Внутрисистемное ПО.

Взаимодействие происходит внутри одного программно-аппаратного блока. Внутрисистемное ПО, таким образом, составляет монолитную подсистему АС.

Ядро, модули ядра, драйверы.

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

Системные службы.

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

Ведение системных журналов и реестров

Профилактика, резервное копирование

Средства интегрирования.

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

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

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

Управляющее ПО.

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

Настройка и оптимизация системы.

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

Диагностика.

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

Управление службами.

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

Межсистемное ПО.

Взаимодействие происходит между программно-аппаратными блоками АС посредством среды взаимодействия. Межсистемное ПО, таким образом, возникает в одноуровневых и иерархических АС.

Поддержка связности.

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

Масштабирование.

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

Удалённые хранилища и сервисы ресурсов.

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

4.2 Специализированное ПО.

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

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

Автоматическое ПО.

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

Функциональность автоматических подсистем изменяется только разработчиком.

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

Предустановленные службы.

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

Целевое ПО.

Во некоторых случаях вместо системы общего назначения, программное обеспечение АС составляет единственный продукт, решающий пользовательскую задачу; обычно его код размещается при этом в ПЗУ. Оснащённый таким образом программно-аппаратный блок превращается в специализированный прибор (например, маршрутизатор 2-го уровня, комплексный датчик, спецвычислитель и т.д.).

Профилируемое ПО.

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

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

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

Настраиваемое ПО

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

Утилиты

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

Интерактивное ПО.

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

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

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

Диалог с отложенным взаимодействием.

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

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

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

Диалог с продолженным взаимодействием.

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

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

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

Диалог с предварительным профилированием.

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

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

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

5. Управление АС

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

5.1 Планирование.

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

Административный проект.

Проект аппаратной части.

Проект програмного наполнения.

Системное ПО.

Может быть описано одним из следующих способов, или их совмещением:

Специализированное ПО.

Может быть описано одним из следующих способов, или их совмещением:

Проект прикладных свойств (проектное задание).

5.2 Начальная настройка.

Действия над реальной системой, предшествующие введению её в эксплуатацию. Дополнения и исправления любой части АС быстрее и дешевле делать до этапа эксплуатации. Этап начальной настройки посвящён проблемам, которые невозможно решить в проекте в отсутствие реальной системы.

Административная и юридическая регистрация.

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

Подготовка инфраструктуры.

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

Установка ПО.

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

Профилирование.

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

Опытный пуск.

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

5.3 Сопровождение.

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

Отработка нештатных ситуаций.

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

Диагностика и профилактика.

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

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

Если возможности профилактического отключения определённого блока АС нет (напрмер, система работает в режиме 24*7), такой блок должен быть зеркалирован. На время профилактики работу этого блока выполняет его зеркало.

Оптимизация и перенастройка.

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

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

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

5.4 Утилизация.

Действия по исключению отработавшей свой срок АС из технологического цикла и административных отношений.

Останов.

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

Разрегистрация.

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

Демонтаж и уничтожение.

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

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

6. Требования к элементам АС

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

Характеристики элемантов АС используются на всех этапах ЖЦ системы как исходные данные для планирования, настройки, диагностики АС и т.п.

6.1 Обшие характеристики.

Применимы, как правило, ко всем эламентам АС.

Наработка на отказ.

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

Стоимость установки и сопровождения.

Условная стоимость действий по управлению элементом АС (см. Управление). На прикладном уровне можно также рассматтривать цену простоя.

Экологические, эргономические и пр. характеристики

6.2 Специфические характеристики для каждого вида элементов АС.

Средства обработки данных

Производительность

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

Точность вычислений.

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

Средства хранения данных

Вместимость

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

Скорость обмена.

Может различаться скорость чтения и записи данных на устройство.

Средства передачи данных.

Пропускная способность.

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

Среднее и/или гарантированное время доставки.

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

Максимальное и/или штатное расстояние между узлами.

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

Интерфейс

Эргономичность.

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

Охват.

Возможность формулировки задач из прикладной области; актуально на прикладном уровне.

Требования к аппаратуре.

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

Часть 2. Информационная безопасность в автоматизированных системах.

1. Введение

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

1.1 Определение информационной безопасности

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Идентификация объекта - это процедура распознавания объекта по его идентификатору. Выполняется при попытке объекта войти в систему (сеть).

Следующий этап взаимодействия системы с объектом - аутентификация.

Аутентификация объекта - это проверка подлинности объекта с данными индентификатором. Процедура аутентификации устанавливает, является ли объект именно тем, кем он себя объявил.

После идентификации и аутентификации объекта выполняют авторизацию.

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

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

Ущерб безопасности подразумевает нарушение состояния защищенности информации, содержащейся в системе (сети).

С понятием угрозы безопасности тесно связано понятие уязвимости компьютерной системы (сети).

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

Атака на компьютерную систему (сеть) - это действие, предпринимаемое злоумышленником с целью поиска и использования той или иной уязвимости системы. Таким образом, атака - это реализация угрозы безопасности.

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

Безопасная или защищенная система - это система со средствами защиты, которые успешно и эффективно противостоят угрозам беззопасности.

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

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

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

Автоматизированныя системы должна гарантированно быть:

1.2 Подход к обеспечению безопасности АС

Существуют два подхода к проблеме безопасности АС: "фрагментарный" и комплесный.

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

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

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

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

Комплексный подход к проблеме обеспечения безопасности основан на разработанной для конкретной АС политике безопасности.

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

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

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

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

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

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

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

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

Чем важнее объект, тем выше его метка конфиденциальности. Поэтому самыми защищенными оказывается объекты с наиболее высокими значениями метки конфиденциальности.

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

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

1.4 Утечка информации

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

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

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

1.5 Этапы оценки безопасности АС

Этапы оценки безопасности заключаются в следующем:

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

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

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

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

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

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

Для целых и дробных чисел, значений времени и тому подобных типов данных запись производится всегда в фиксированном объеме (2 байта, 4 байта, 10 байт). А вот для строк и массивов данных проверки длины перед операциями записи необходимы. Для того, чтобы заставить ЭВМ выполнить код или записать данные туда, куда у него нет прав записи, злоумышленник специально заставляет систему обрабатывать строки очень большой длины, либо помещать в массив количество элементов большее, чем его объем. В случае успеха возможно либо попадание части строки в сегмент кода или стека с последующим исполнением, либо модификация каких-либо служебных данных, что позволит затем злоумышленнику войти в систему в обход системы защиты. Естественно, что содержимое конца строки (оказывающееся после переполнения буфера в ненадлежащей области памяти) подбирается специальным образом. Сами данные или строки можуг быть абсолютно бессмысленными.

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

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

2. Проблема стандартизации безопасности.

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

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

2.1. Trusted Computer System Evaliation Criteria ("Оранжевая книга")

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 В "Оранжевой книге" определяется четыре уровня безопасности (надежности) -  D, C, B и A. Уровень D предназначен для систем, признанных неудовлетворительными. В настоящее время он содержит две подсистемы управления доступом для ПК. По мере перехода от уровня C к A к надежности систем предъявляются все более жесткие требования. Уровни C и B подразделяются на классы (C1, C2, B1, B2, B3) с постепенным возрастанием надежности. Таким образом, всего имеется шесть классов безопасности -  C1, C2, B1, B2, B3, A1. Чтобы система в результате процедуры сертификации могла быть отнесена к некоторому классу, ее политика безопасности и гарантированность должны удовлетворять приводимым ниже требованиям. Поскольку при переходе к каждому следующему классу требования только добавляются, мы, будем выписывать лишь то новое, что присуще данному классу, группируя требования в согласии с предшествующим изложением.

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

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

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

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

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

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

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

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

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

Класс B2. в дополнение к B1, все ресурсы системы (в том числе ПЗУ, устройства ввода/вывода) должны иметь метки безопасности и служить объектами принудительного управления доступом.

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

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

Класс B1. в дополнение к C2, надежная вычислительная база должна поддерживать метки безопасности пользователей.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Класс B3. в дополнение к B2, аналогичная процедура должна быть проделана для временных каналов.

Класс A1. в дополнение к B3, для анализа должны использоваться формальные методы.

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

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

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

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

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

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

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

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

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

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

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

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

Класс B3. в дополнение к B2, должны быть приведены убедительные аргументы соответствия между спецификациями и моделью.

Класс A1. в дополнение к B3, помимо описательных, должны быть представлены формальные спецификации верхнего уровня, относящиеся к аппаратным и/или микропрограммным элементам, составляющим интерфейс надежной вычислительной базы. Комбинация формальных и неформальных методов должна подтвердить соответствие между спецификациями и моделью. Должны использоваться современные методы формальной спецификации и верификации систем, доступные Национальному центру компьютерной безопасности США. Ручное или иное отображение формальных спецификаций на исходные тексты должно подтвердить корректность реализации надежной вычислительной базы.

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

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

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

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

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

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

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

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

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

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

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

Класс A1. в дополнение к B2, должно быть описано соответствие между формальными спецификациями верхнего уровня и исходными текстами.

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

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

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

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

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

Этот стандарт был разработан давно и в настоящее время представляет только исторический интерес. Однако многое было сзелано впервые именно здесь и сыглало большую роль в создании следующих стандартов, а именно:
Тем не менее со временем выявились и недостатки:
Часть этих недостатков была исправлена в последующих стандартах.
Вскоре после после "Оранжевой Книги" в  США, в других государствах были приняты свои, во многом похожие стандарты безопасности информации. В нашем государстве подобную роль выполняют Руководящие документы Государственной Технической Комиссии при президенте РФ. Как и во многих стандартах вышедших после TCSEC, отдельно разнесены уровень надежности системы и уровень гарантии оценки. Последнее называется "Классификация по уровню контроля отсутствия недекларированных возможностей ". Также отдельно оцениваются автоматизированные системы (АСУ) и средства вычислительной техники (СВТ). Основная идея разделения состояла в том, что для сертификации отдельно взятой автоматизированной системы следует предварительно просертифицировать её комноненты (СВТ).

2.2 РД ГТК для СВТ

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

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

Данные показатели содержат требования защищенности СВТ от НСД к информации.

Показатели защищенности СВТ применяются к общесистемным программным средствам и операционным системам (с учетом архитектуры ЭВМ).

Требования к показателям реализуются с помощью программно-технических средств.

Устанавливается семь классов защищенности СВТ от НСД к информации. Самый низкий класс - седьмой, самый высокий - первый. Классы подразделяются на четыре группы, отличающиеся качественным уровнем защиты:

Выбор класса защищенности СВТ для автоматизированных систем, создаваемых на базе защищенных СВТ, зависит от грифа секретности обрабатываемой в АС информации, условий эксплуатации и расположения объектов системы.

Применение в комплекте СВТ средств криптографической защиты информации по ГОСТ 28147-89 может быть использовано для повышения гарантий качества защиты.

Требования данного РД охватывают следющий ряд методов обеспечения безопасности от НСД

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

2.3 РД ГТК для АСУ

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

Руководящий документ разработан в дополнение ГОСТ 34.003-90, ГОСТ 34.601-90, РД 50-680-88, РД 50-34.680-90 и других документов.

Документ может использоваться как нормативно-методический материал для заказчиков и разработчиков АС при формулировании и реализации требований по защите.

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

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

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

Основными этапами классификации АС являются

Необходимыми исходными данными для проведения классификации конкретной АС являются:

Выбор класса АС производится заказчиком и разработчиком с привлечением специалистов по защите информации

К числу определяющих признаков, по которым производится группировка АС в различные классы, относятся

Устанавливается девять классов защищенности АС от НСД к информации

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

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

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

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

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

Первая группа включает многопользовательские АС, в которых одновременно обрабатывается и (или) хранится информация разных уровней конфиденциальности. Не все пользователи имеют право доступа ко всей информации АС. Группа содержит пять классов - 1Д, 1Г, 1В, 1Б и 1А

Требования предъявляемые данным РД к разрабатываемым АС охватывают следующий спектр вопросов:

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

Подсистема регистрации и учет

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

Подсистема обеспечения целостности

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

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

При разработке АС, предназначенной для обработки или хранения информации, являющейся собственностью государства и отнесенной к категории секретной, необходимо ориентироваться в соответствии с РД "Средства вычислительной техники. Защита от несанкционированного доступа к информации. Показатели защищенности от несанкционированного доступа к информации" на классы защищенности АС не ниже (по группам) 3А, 2А, 1А, 1Б, 1В и использовать сертифицированные СВТ:

Несмотря на то что данный стандарт был принят спустя почти десять лет после TCSEC, многие его положения и методология уже устарели. Для подготовки смены данным стандартам в Российской Федерации был принят международный стандарт ISO-15408, более широко известный как "Общие критерии".

2.4 Common Criteria (ISO 15408-{1,2,3}, ГОСТ Р ИСО/МЭК 15408-{1,2,3})

В 1990 году была начата разработка международного стандарта критериев оценки общего пользования в Международной организации по стандартизации (ISO). Новые критерии были призваны обеспечить взаимное признание результатов стандартизированной оценки безопасности на мировом рынке ИТ.

Версия 1.0 ОК была завершена CCEB в январе 1996 года и одобрена ISO в апреле 1996 года для распространения как Проект комитета. Был проведен ряд экспериментальных оценок на основе версии 1.0 ОК, а также организовано широкое обсуждение документа. Затем в рамках Проекта ОК была предпринята значительная переработка ОК на основе замечаний, полученных при его экспериментальном использовании, публичном обсуждении и взаимодействии с ISO. Переработка документа была выполнена преемником CCEB, названным Советом по реализации ОК (CCIB).

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

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

Итак, давайте вкратце пройдёмся по этапам разработки продукта, согласно требованиям Общих критериев.

Первым делом необходимо составить так называемое Задание Безопасности (Security Target). ЗБ содержит совокупность требований безопасности. "Задание Безопасности" содержит общую спецификацию, совместно с требованиями и целями безопасности и их обоснованием. "Задание Безопасности" является основой для соглашения между всеми сторонами (разработчиками, потребителями и экспертами) относительно безопасности продукта.
Стандарт определяет что и в каком формате должно быть описано в этом документе. После того как продукт пройдёт сертификацию, его "Задание Безопасности" помещается в реестр (на данный момент этот реестр публично доступен по адресу http://www.commoncriteria.org) вместе с описанием продукта и доступно для просмотра потенциальными покупателями. Поскольку линейной классификации (как это было в "Оранжевой Книге" ) больше нет, то покупателю придётся внимательно изучить этот документ, прежде чем понять удовлетворяет ли его этот продукт. Здесь сразу проявляется преимущество и недостатки Общих Критериев. С одной стороны, больше нет привязки к конкретному типу систем и можно точно подобрать требования которые необходимы для того или иного продукта. С другой стороны, надо подробнее изучать характеристики продуктов, чтобы выбрать наиболее подходящий.

Требования по безопасности в "Задании Безопасности" могут быть сформулированны с использованием:
Таким образом, перед тем как составить Задание Безопасности для продукта,  необходимо посмотреть есть ли в стандарте готовые предопределённые профили защиты или составить свой профиль.

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

Уровень Гарантии Оценки (Evaluation Assuarance Level) - это предопределённые   пакеты гарантий. Определяют уровень доверия к проведённой сертификации продукта. Чем выше уровень гарантии, тем выше доверие пользователя, что продукт действительно представляет из себя то о чём заявлено в Задании Безопасности.
В общих критериях определены уровни гарантии оценки с 0 по 7. По уровням 1 - 4 проводится сертификация в ISO, сертификация (и детали требований)
по остальным уровням оставлено на откуп правительственным учреждениям стран.

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

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

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

В общих критериях определяются следующие классы  требований:
Пример семейства требований -  FTA_SSL Блокирование сеанса.
Пример компонента - "FTA_SSL.1       Блокирование сеанса, инициированное комплексом средств обеспечения безопасности".
Сложность Общих критериев (которую вы наверное уже ощутили на себе) с лихвой компенсируется огромной гибкостью и повторным использованием уже подготовленных компонент. Например существуют сертифицированные готовые профили защиты, которые помещены в общий репозитарий и могут использоваться всеми желающими.
Самые интересные из них это Labeled Security Protection Profile (SLPP) - замена класса B1, а также Controlled Access Protection Profile  (CAPP) - замена класса C2. Оба профиля разработаны Агенством Национальной безопасности США и призваны обеспечить переход с требований "Оранжевой книги" на новый стандарт.
Немаловажно также что это международный стандарт. В настоящее время глобальной интеграции экономикии промышленности стран очень кстати иметь общие критерии оценки, ведь зачастую заказы, связанные с инфморационными технологиями для одного государства выполняются на территории другого.
Что касается Российской Федерации, то нам ещё предстоит проделать большую работу по разработке собственных профилей на смену требований Руководящих Документов. На момент написания подобная работа только начиналась. Возможно правильным являлось бы ,по примеру США, просертифицировать в последствии эти профили в ISO, так они пройдут проверку корректность и получат международное признание.
Кроме того новые критерии гораздо сложнее в работе, поэтому предстовит провести ещё большую работу по обучению сертифицирующих организаций новой методологии.

3. Информационная безопасность в Автоматизированных Системах

3.1 Угрозы безопасности функционирования Автоматизированных Систем

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

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

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

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

  • угрозы, обусловленные действиями субъекта (антропогенные)

  • угрозы, обусловленные техническими средствами (техногенные)

  • угрозы, обусловленные стихийными источниками.

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

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

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

  • Кража: технических срудств, носителей информации, информации, средств доступа

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

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

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

  • Ошибки при инсталяции ПО, ОС, СУБД, при написании прикладного ПО, при эксплуатации ПО, при эксплуатации технических средств.

  • Перехват информации (несанкционированный): за счет ПЭМИ от технических средств, за счет наводок по линиям электропитания, за счет наводок по посторонним проводникам, по акустическому каналу от средств вывода, по акустическому каналу при обсуждении вопросов, при подключении к каналам передачи информации, за счет нарушения установленных правил доступа (взлом)

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

  • некачественные технические средства обработки информации

  • некачественные программные средства обработки информации

  • вспомогательные средства (охраны, сигнализации, телефонии)

  • другие технические средства, применяемые в учреждении

и внешними:

  • средства связи

  • близко расположенные опасные производства

  • сети инженерных коммуникаций (энерго-, водоснабжения, канализации)

  • транспорт

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

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

  • Уничтожение (разрушение): программного обеспечения, ОС, СУБД, средств обработки информации (броски напряжений, протечки), помещений, информации (размагничивание, радиация и т.д.), персонала

  • Модификации (изменения): программного обеспечения, ОС, СУБД, информации при передачи по каналам связи и телекоммуникациям

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

  • пожары

  • землетрясения

  • наводнения

  • ураганы

  • другие форс-мажорные обстоятельства

  • различные непредвиденные обстоятельства

  • необъяснимые явления

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

  • Уничтожение (разрушение):

    • технических средств обработки информации

    • носителей информации

    • программного обеспечения (ОС, СУБД, прикладного ПО)

    • информации (файлов, данных)

    • помещений

    • персонала

  • Исчезновения (пропажа):

    • информации в средствах обработки

    • информации при передаче по телекоммуникационным каналам

    • носителей информации

    • персонала

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

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

  • кража (копирование) программного обеспечения

  • подмена (несанкионированный ввод) информации

  • уничтожение (разрушение) данных на носителях информации

  • нарушение нормально работы (прерывание) в результате вирусных атак

  • модификация (изменение) даннх на носителях информации

  • перехват (несанкионированный съем) информации

  • кража (несанкионированное копирование) ресурсов

  • нарушение нормальной работы (перегрузка) каналов связи

  • непредсказуемые потери

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

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

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

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

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

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

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

3.2 Внутренние и внешние угрозы

Отдельно рассмотрим угрозы, которые наиболее распространены в последнее время, благодаря тому что большинство АС распространились за пределы одного здания, одной организации, одного государства. Если проанализировать угрозы по местонахождению нарушителя, то возникают следующие основные классы:
  • внешние угрозы
  • внутренние угрозы
Внутренние угрозы проистекают со стороны персонала. В основном он вызваны следующими причинам:
  • Сотрудник может находится под шантажом
  • Личная выгода
  • Банальная месть
Внешние угрозы специфичны для современных автоматизированных систем. Благодаря большей распределённости современных АС, их каналы связи зачастую проходят через сети публичного доступа. В связи с этим возникают новые классы проблем:
  • Публичная сеть, и её политика безопасности, не контролируются какой либо одной организацией. Как следствие фактически нет лиц ответственных за безопасность информации
  • Доступ к отдельным узлам АС (преимущественно шлюзам) получают все пользователи публичной сети. В случае глобальных сетей, таких как Internet потенциально доступ к шлюзам АС имеют миллионы людей.
С какой целью может действовать внешний злоумышленник? Да фактически с любой. В атаках на автоматизированные системы могут проявляться любые деструктивные особенности характера человека.  Характер атак в основном ориентирован на каналы инфморации:
  • Изменение маршрута следования данных
  • Прослушивание
  • Внедрение в канал ложных данных
  • Перекрытие канала (атака типа "Отказ Обслуживания" (DOS))

3.2.1 Наиболее распространённые сетевые атаки

Атаки компьютерных сетей типа "отказ в обслуживании" (DoS, Denial of Service) являются одними из самых, а быть может, и самыми распространенными. Частично виной тому простота их реализации и высокая эффективность. Целью таких атак, как следует из названия, является приведение сервера-жертвы в состояние, когда он не может отвечать на запросы клиентов. Побочным эффектом таких атак является большой трафик, направленный на жертву. Далее мы рассмотрим некоторые, наиболее распространенные, атаки и методы их сдерживания. Важно понимать, что не существует методов, которые защитили бы вас от DoS-атак, можно лишь попытаться минимизировать причиненные убытки и оперативно отреагировать на атаку.
В классическом понимании успехом атаки "отказ в обслуживании" является отказ оператора (сервера) в предоставлении сервиса. Но, беря во внимание специфику домашней сети и малого провайдера, я считаю, что в крайнем случае, приемлемо перестать временно (на период атаки) предоставлять сервис клиенту, чтобы не обанкротиться.

Атаки типа "SYN-flood"

Как известно, TCP использует трехэтапное квитирование для установления соединения. В основу данного типа атак заложена идея превышения ограничения на количество соединений, находящихся в состоянии установки. Результатом является состояние системы, в котором она не может устанавливать новые соединения. Кроме того, при такой атаке на каждый входящий пакет система-жертва высылает ответ, что ещё сильнее увеличивает злонамеренный трафик.
Возможность данной атаки обусловлена тем, что в сети Internet (стандарта IPv4) не предусмотрен контроль за IP-адресом отправителя сообщения, следовательно невозможно отследить истинный маршрут, пройденный IP-пакетом, и, следовательно, у конечных абонентов сети нет возможности ограничить число возможных запросов, принимаемых в единицу времени от одного хоста. Поэтому возможно осуществление данного типа атаки, которая будет заключаться в передаче на атакуемый хост как можно большего числа ложных TCP-запросов на создание соединения от имени любого хоста в сети. При этом атакуемая сетевая ОС в зависимости от вычислительной мощности компьютера либо - в худшем случае - практически зависает, либо - в лучшем случае - перестает реагировать на легальные запросы на подключение (отказ в обслуживании). Это происходит из-за того, что для всей массы полученных ложных запросов система должна, во-первых, сохранить в памяти полученную в каждом запросе информацию и, во-вторых, выработать и отослать ответ на каждый запрос. Таким образом, все ресурсы системы "съедаются" ложными запросами: переполняется очередь запросов и система занимается только их обработкой. Эффективность данной удаленной атаки тем выше, чем больше пропускная способность канала между атакующим и целью атаки, и тем меньше, чем больше вычислительная мощь такуемого компьютера (число и быстродействие процессоров, объем ОЗУ и т. д.).
Поскольку такие атаки не предусматривают обратной связи с атакующим, нет необходимости использовать настоящий адрес источника.
В заключение необходимо отметить, что в существующем стандарте сети Internet IPv4 нет приемлемых способов надежно обезопасить свои системы от этой
удаленной атаки.

DoS-атаки основанные на протоколе ICMP.

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

DoS-атаки основанные на программных ошибках

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

DDoS - атаки

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

Перейдём к рассмотрению атак направленных изменение маршрута следования сетевых пакетов.

ARP-spoofing

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

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

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

Ложный DNS-сервер в сети Internet

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

Рассмотрим DNS-алгоритм удаленного поиска IP-адреса по имени в сети Internet:
  • хост посылает на IP-адрес ближайшего DNS-сервера (он устанавливается при настройке сетевой ОС) DNS-запрос, в котором указывает имя сервера, IP-адрес которого необходимо найти
  • DNS-сервер, получив запрос, просматривает свою базу имен на наличие в ней указанного в запросе имени. В случае, если имя найдено, а, следовательно, найден и соответствующий ему IP-адрес, то на запросивший хост DNS-сервер отправляет DNS-ответ, в котором указывает искомыйIP-адрес. В случае, если указанное в запросе имя DNS-сервер не обнаружил в своей базе имен, то DNS-запрос отсылается DNS-сервером на один из корневых DNS-серверов, адреса которых содержатся в файле настроек DNS-сервера root.cache, и описанная в этом пункте процедура повторяется, пока имя не будет найдено (или не найдено)
Анализируя с точки зрения безопасности уязвимость этой схемы удаленного поиска с помощью протокола DNS, можно сделать вывод о возможности осуществления в сети, использующей протокол DNS, удаленной атаки, а имеено создание ложного объекта в сети. Практические изыскания и критический анализ безопасности службы DNS позволяют предложить три возможных варианта удаленной атаки на эту службу:
  • внедрение в сеть Internet ложного DNS-сервера путем перехвата DNS-запроса
  • внедрение в сеть Internet ложного сервера путем создания направленного "шторма" ложных DNS-ответов на атакуемый хост
  • внедрение в сеть Internet ложного сервера путем перехвата DNS-запроса или создания направленного "шторма" ложных DNS-ответов на атакуемый DNS-сервер
В первом случае для реализации атаки путем перехвата DNS-запроса атакующему необходимо перехватить DNS-запрос, извлечь из него номер UDP-порта отправителя запроса, двухбайтовое значение ID идентификатора DNS-запроса и искомое имя и затем послать ложный DNS-ответ на извлеченный из DNS-запроса UDP-порт, в котором указать в качестве искомого IP-адреса настоящий IP-адрес ложного DNS-сервера. Это позволит в дальнейшем полностью перехватить трафик между атакуемым хостом и сервером.
Необходимым условием осуществления данного варианта атаки является перехват DNS-запроса. Это возможно только в том случае, если атакующий находится
либо на пути основного трафика, либо в сегменте настоящего DNS-сервера. Выполнение одного из этих условий местонахождения атакующего в сети делает подобную удаленную атаку трудно осуществимой на практике (попасть в сегмент DNS-сервера и, тем более, в межсегментный канал связи атакующему, скорее всего, не удастся). Однако в случае выполнения этих условий возможно осуществить межсегментную удаленную атаку на сеть Internet.
Во втором случае осуществления удаленной атаки, направленной на службу DNS). В этом случае атакующий осуществляет постоянную передачу на атакуемый хост заранее подготовленного ложного DNS-ответа от имени настоящего DNS-сервера без приема DNS-запроса! Другими словами, атакующий создает в сети Internet направленный "шторм" ложных DNS-ответов. Это возможно, так как обычно для передачи DNS-запроса используется протокол UDP, в котором отсутствуют средства идентификации пакетов. Единственными критериями, предъявляемыми сетевой ОС хоста к полученному от DNS-сервера ответу, является, во-первых, совпадение IP-адреса отправителя ответа с IP-адресом DNS-серве-ра; во-вторых, чтобы в DNS-ответе было указано то же имя, что и в DNS-запросе, в-третьих, DNS-ответ должен быть направлен на тот же UDP-порт, с которого был послан DNS-запрос (в данном случае это первая проблема для атакующего), и, в-четвертых, в DNS-ответе поле идентификатора запроса в заголовке DNS (ID) должно содержать то же значение, что и в переданном DNS-запросе (а это вторая проблема).
Поэтому для осуществления данной удаленной атаки атакующему необходимо выбрать интересующий его хост (например, aaa.bbb.com), маршрут к которому требуется изменить так, чтобы он проходил через ложный сервер - хост атакующего. Это достигается постоянной передачей (направленным "штормом" ) атакующим ложных DNS-ответов на атакуемый хост от имени настоящего DNS-сервера на соответствующие UDP-порты. В этих ложных DNS-ответах указывается в качестве IP-адреса хоста aaa.bbb.com IP-адрес атакующего. Далее атака развивается по следующей схеме. Как только цель атаки (атакуемый хост) обратится по имени к хосту aaa.bbb.com, то от данного хоста в сеть будет передан DNS-запрос, который атакующий никогда не получит, но этого ему и не требуется, так как на хост сразу же поступит постоянно передаваемый ложный DNS-ответ, что и будет воспринят ОС атакуемого хоста как настоящий ответ от DNS-сервера. Все! Атака состоялась, и теперь атакуемый хост будет передавать все пакеты, предназначенные для aaa.bbb.com, на IP-адрес хоста атакующего, который, в свою очередь, будет переправлять их на aaa.bbb.com
Таким образом, реализация данной удаленной атаки, использующей пробелы в безопасности службы DNS, позволяет из любой точки сети Internet нарушить маршрутизацию между двумя заданными объектами (компьютерами)! Данная удаленная атака осуществляется межсегментно по отношению к цели атаки и угрожает безопасности любого хоста Internet, использующего обычную службу DNS.
Третий вид атаки основан на слудующей технологии работы службы DNS. Из схемы удаленного DNS-поиска следует, что в том случае, если указанное в запросе имя DNS-сервер не обнаружил в своей базе имен, то запрос отсылается сервером на один из корневых DNS-серверов, адреса которых содержатся в файле настроек сервера root.cache.
Итак, в случае, если DNS-сервер не имеет сведений о запрашиваемом хосте, то он сам, пересылая запрос далее, является инициатором удаленного DNS-списка. Поэтому ничто не мешает атакующему, действуя описанными в предыдущих пунктах методами, перенести свой удар непосредственно на DNS-сервер. В качестве цели атаки теперь будет выступать не хост, а DNS-сервер и ложные DNS-ответы будут направляться атакующим от имени корневого DNS-сервера на атакуемый DNS-сервер.
При этом важно учитывать следующую особенность работы DNS-сервера. Для ускорения работы каждый DNS-сервер кэширует в области памяти свою таблицу соответствия имен и IP-адресов хостов. В том числе в кэш заносится динамически изменяемая информация об именах и IP-адресах хостов, найденных в процессе функционирования DNS-сервера, а именно, если DNS-сервер, получив запрос, не находит у себя в кэш-таблице соответствующей записи, он пересылает ответ на следующий сервер и, получив ответ, заносит найденные сведения в кэш-таблицу в память. Таким образом, при получении следующего запроса DNS-серверу уже не требуется вести удаленный поиск, так как необходимые сведения уже находятся у него в кэш-таблице. Из анализа только что подробно описанной схемы удаленного DNS-поиска становится очевидно, что в том случае, если в ответ на запрос от DNS-сервера атакующий направит ложный DNS-ответ (или в случае "шторма" ложных ответов будет вести их постоянную передачу), то в кэш-таблице сервера появится соответствующая запись с ложными сведениями и в дальнейшем все хосты, обратившиеся к данному DNS-серверу, будут дезинформированы, и при обращении к хосту, маршрут к которому атакующий решил изменить, связь с ним будет осуществляться через хост атакующего. И, что хуже всего, с течением времени эта ложная информация, попавшая в кэш DNS-сервера, будет распространяться на соседние DNS-серверы высших уровней, а, следовательно, все больше хостов в Internet будут дезинформированы и атакованы. Очевидно, что в том случае, если атакующий не может перехватить DNS-запрос от DNS-сервера, то для реализации атаки ему необходим "шторм" ложных DNS-ответов, направленный на DNS-сервер. При этом возникает следующая проблема, отличная от проблемы подбора портов в случае атаки, направленной на хост. Как уже отмечалось ранее, DNS-сервер, посылая запрос на другой DNS-сервер, идентифицирует этот запрос двухбайтовым значением (ID). Это значение увеличивается на единицу с каждым передаваемым запросом. Узнать атакующему это текущее значение идентификатора DNS-запроса не представляется возможным. Поэтому предложить что-либо, кроме перебора 256 возможных значений ID, достаточно сложно. Зато исчезает проблема перебора портов, так как все DNS-запросы передаются DNS-сервером на 53 порт.
Следующая проблема, являющаяся условием осуществления этой удаленной атаки на DNS-сервер при направленном "шторме" ложных DNS-ответов, состоит в том, что атака будет иметь успех только в случае, если DNS-сервер пошлет запрос на поиск имени, которое содержится в ложном DNS-ответе. DNS-сервер посылает этот столь необходимый и желанный для атакующего запрос в том и только том случае, когда на него приходит DNS-запрос от какого-либо хоста на поиск данного имени и этого имени не оказывается в кэш-таблице DNS-сервера. В принципе, этот запрос может возникнуть когда угодно, и атакующему придется ждать результатов атаки неопределенное время. Однако, ничто не мешает атакующему, не дожидаясь никого, самому послать на атакуемый DNS-сервер подобный DNS-запрос и спровоцировать DNS-сервер на поиск указанного в запросе имени! Тогда эта атака с большой вероятностью будет иметь успех практически сразу же после начала ее осуществления.

3.2.2 Наиболее вероятные угрозы безопасности АС различных типов

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

Угрозы безопасности данных в монолитных системах

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

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

Угрозы безопасности в одноуровневых системах

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

Угрозы безопасности в иерархических системах

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

Угрозы безопасности в многосвязных системах

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

3.3 Методы защиты Автоматизированных Систем

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

  • организационные методы

  • инженерно-технические методы

  • технические методы

  • программно-аппаратные методы

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

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

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

Кроме того, некоторые методы, например резервирование средств и каналов связи, оказывают эффект при определенных техногенных факторах.

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

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

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

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

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

3.4 Организационные методы обеспечения информационной безопасности

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

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

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

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

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

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

Хороший пример объединения административных и программных мер защиты - процедура авторизации сотрудников. Проходя на территорию организации сотрудник проходит авторизацию у охраны (face-control или с использованием каких либо специальных средств), далее следует вторичная авторизация при входе на територрию, где размещаются терминалы АС, и наконец происходит завершающая авторизация средствами АС. При поступлении на работу, сотрудник получает все отличительные аттрибуты, начиная с удостоверения и пропуска, заканчивая выдачей account'а и пароля. При этом пароль как правило бывает создан автоматически, предаётся в конверте, так что выдающий не знает какой пароль у данного пользователя. При выдаче вышеперечисленных аттрибутов заполняются необходимые формуляры, которые позволят в дальнейшем анлизировать случаи нарушения и законно применять административные санкции.

3.5 Принципы построения комплексных систем защиты

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • отчетность и подконтрольность - система защиты должна предоставлять доказательства корректности своей работы

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

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

  • полнота и согласованность - надежная системы защиты должна быть полностью специфицирована, протестирована и согласована

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

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

  • привлечение человека -- наиболее важные критические решения должны приниматься человеком

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

3.6 Типичные методы защиты АС различного типа от реализации угроз

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

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

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

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

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

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

Защита монолитных систем

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

Защита одноуровневых систем

Предметом дополнительной защиты в одноуровневых системах служит среда взаимодействия.

Защита иерархических систем

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

Защита многосвязных систем

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

4. Программно-аппаратные средства обеспечения безопасности

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

4.1 Регистрация и аудит

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

Вряд ли может существовать какое-то другое решение, разве когда изменится архитектура современных информационных систем. Но можно оттянуть момент завершения места на диске проведением регулярных мер по контролю за дисковым пространством: например, производить регулярную архивацию данных, вовремя заменять диск, выделенный для журнала, на новый.
Тут сразу встаёт другая проблема. Если регистрационные данные так важны,  то их тоже надо защищать. То есть журнал является эдаким "един в двух лицах" . С  одной стороны он явдяется частью системы защиты,  с другой  - защищаемыми данными.  Записать в журнал все возможные действия с журналом невозможно, необходимо привлечение администратвных мер.
Ещё для полноты важно чтобы в записи содержались исчерпывающие данные о произошедшем событии. Например если будет сообщено что открыт файл, но не будет указано точное (именно точное, например для операционных систем типа Unix это номер i-node) местоположеине файла, то информация теряет свой смысл.  Она просто ничего на даст. Также обязательно надо регистрировать дату и время события.
Вернёмся к рассмотрению задач стоящих перед регистрацией. Достоверность данных.  Внутри системы у пользователей не существует никаких подписей, все пользователи (и их процессы) различаются исключительно по уникальным идентификаторам, выдаваемым при входе в систему. Таким образом ключевую роль в этом вопросе играет подсистема идентификации и аутентификации. Если мы считаем идентификацию пользовтеля достоверной, то записи журнала будут также достоверными, если, конечно, авторы операционной системы докажут, что исключена подделка записи от момента создания и до момента записи в файл.
Для достоверности также необходимо доказать что системные события генерируются неподделываемым образом, то есть что невозможно возникновение ложных событий. Самым правильным является генерация событий на аксимально возможном низком уровне и ни в коем случае не на высоком. Например: противопоказано ганерировать события на уровне текстового редактора, нет никакой гарантии что пользователь будет работать именно через него.
При простановки даты и времени события необходимо знать достоверное время. В противном случае события потеряют свою истинную последовательность и могут быть неверно истолкованы. Время действия играло решающую роль в бумажных журналах,  его роль не преуменьшилась и в информационную эпоху. Эту последовательнось ни в коем случае нельзя пытаться восстановить по порядку записи в регистрационную базу. Дело в том что многие из них могут возникать одновременно и одновременно идти в журнал.
Таким образом архитекторы информационной системы обязаны доказать, что время в системе по крайней мере строго возрастать и с одной скоростью. Я не говорю об обязательном соответствии астрономическому времени. Это конечно тоже должно выполняться, но в отдельных случаях можно обойтись и без этого.
В случае проектирования распределённой информационной системы желательно обеспечить синхронизацию времени по всем узлам, в противном случае администратору придётся все время держать перед глазами (или в уме) локальное время каждого узла, что затруднит его работу. Особенно это касается случая распределённых атак , когда надо восстановить цепочку событий по всей территории защищаемой АС.
Говоря о регистрации ни в коем случае нельзя забывать об аудите, анализе журнальных записей.
Как уже было сказано выше чем на более низком уровне генерируются события тем больше к ним доверия. Оборотная сторона этого состоит в том, что записи в журнале сложно поддаются чтению и изучению. Система может только сообщить
что тогда-то и тогда-то такой-то процесс, выполняющийся от имени такого-то пользователя пытался получить доступ к такому-то ресурсу. Для надёжного контроля же необходимо знать больше:
Для того чтобы было возможно использовать аудит на журнальные записи накладывается ещё одно довольно жёсткое ограничение: записи должны иметь максимально стандартный формат. В противном случае невозможно будет осуществить автоматический анализ. А ручной анализ при большом потоке данных вещь нереальная в особенности для огромных информационных систем, простирающихся на территории нескольких регионов (или даже стран).  Это требование также должно быть изначально заложено в архитектуру системы ибо все без исключения cлужбы АС,  как низкоуровневые так и высокоуровневые должны поддерживать один формат сообщений.

4.2 Разграничение доступа

Самый распространённый приём защиты и в реальной жизни и в информационных системах - не допускать всех подряд к данным. Даже если в данном компоненте информационной системы циркулируют данные одного уровня конфиденциальности, всё равно есть данные относящиеся к разным категориям пользователей, ведь финансовый отчёт вряд ли должен быть доступен администратору системы и его процессам также как и файл с паролями не надо давать на прочтение финансовому директору.
Выход - данные надо каким либо образом классифицировать, а потом раграничить доступ в соответствии с выбранной классификации.
Что касается разграничения, То или иное раграничение доступа в системе сводится к заполнению некоторой матрицы , в строках которой указаны объекты, в столбцах - субъекты, а на пересечении - права доступа соответствующего субъект к соответсвующему субъекту.
Подобная схема называется дискреционной или произвольной и упоминается практически во всех стандартах, посвящённых защите операционных систем (например в "Оранжевой книге"). Напомним ещё раз, что наиболее часто она встречается в современных системах в виде прав доступа (или списков доступа - ACL) на файлы.
Дискреционная модель является простой, эффективной, но слишком низкоуровневой. В жизни требуются более хитрые и гибкие подходы, но почти все из них в конечном итоге сводятся к этой самой матрице доступа в том или ином виде.
Первый шаг к облегчению пользования материцай доступа - укрупнение, группировка субъектов и объектов по тому или иному принципу, то есть классификация. Классификация может быть одноуровневой и многоуровневой, иерархия может быть линейной и нет.
Под одноуровневой классификацией я понимаю, когда происходит просто разделение по линии субъектов и объектов на непересекающиеся множества. И доступ может быть только внутри своей группы. Например пользователь test1 не имеет доступа к данным пользователя test2.
Многоуровневая классификация - это когда объекты делятся на вложенные друг в друга множества. И объект имеет доступ к объектам из того множества в которые он входит. Например пользователь из группы с допуском "секретно" читает данные из группы "секретно", а также и из группы "конфиденциально" и "несекретно". Но он же, например, совершенно не имеет никакого доступа к данным группы "совершенно секретно".
Как правило решения прежде всего ориентированные на раграничение доступа нежели на использование какой-то классификации требуют минимальной доработки существующего программного обеспечения, поэтому сначала проведём краткий обзор именно их:

4.2.1 Изолированные среды исполнения

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

4.2.2 Минимизация полномочий

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

4.2.3. Блокираторы поведения

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

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

4.2.4 Мандатное раграничение доступа

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

Освовная идея состоит в следующем. Необходимо реализовать систему обработки грифованной информации. Система должна работать в полностью автоматическом режиме и не допускать возможности перетекания информации из ''большего грифа" в "меньший". То есть "совершенно секретная" информация никогда не должна стать "секретной".
Для строго математического обоснования было формально описано что такое состояние системы, описаны правила перехода системы из одного состояния в другое. Далее было определено что такое безопасное состояние и доказано, что никакими разрешёнными переходами невозможно перевести систему из безопасного состояния в опасное.
Метка безопасности состоит из двух компонент. Первая компонента - собственно гриф, он образует линейную иерархию в классификации. Вторая компонента - категория,  абстракция описания множества ведомств к которым принадлежит данный субъект или объект.
Считается что метка (A,B) доминирует над меткой (C,D) если A>=C и B надмножество D. Например, если элементы категорий брать из множества {a,b,c,d}, а гриф - натуральное число, то метка {2,{a,b}} доминирует над меткой {1,{a}}. А вот метка {2,{a,b}} не доминирует над {1,{c,d}}. Таким образом устанавливается на множестве меток отношение частичного порядка. Линейный порядок нас не устраивает поскольку два документа с одним и тем же грифом могут относиться к разным ведомствам и человек имеющий доступ к документом данного уровня в своём ведомстве может вовсе не иметь доступа к документам другого ведомства. В принципе вторая компонента метки успешно эмулируется дискреционным доступом (для назначения множественных групп объекту можно использовать систему вложенных каталогов принадлежащих соответствующим группам), но поскольку в оригинальной модели метка была именно двойная - будем придерживаться той же схемы.
Для каждого объекта и субъекта две метки: максимальный уровень безопасности и текущий уровень безопасности. Для объектов эти два метки совпадают, для субъектов могут различаться. Максимальный уровень всегда доминирует над текущим.
Назначаются следующие правила игры:
Таким образом права доступа назначают только субъекту при его заведении в системе, а потом вся регуляция происходит автоматически. Модель создана так что потоки данных могут идти только наверх или на тот же уровень но ни в коем случае не в низ. Несмотря на простоту и красоту первая же реализация показала, что подобная модель плохо уживается в реальной системе и необходимо делать исключения  - "доверенные " процессы. Так жизнь опять вносит свои коррективы и красивая математическая модель в жизни покрывается множеством дополнительных винтиков гаечек и лазеек.
Вот ещё одна проблема связанная с мандатным доступом. Когда речь идёт о простейшей системе со статическими объектами, всё хорошо, но как только система приходит в движение...
При "перемещении" данных необходимо перемещать вместе с ними и привязанные к ним метки. Эта проблема актуальна для всех автоматизированных систем обработки информации. Там практически никогда не бывает статических данных, собранных в одном узле, данные как правило циркулируют по всей сети. Если данные перемещаются в своём исходном контейнере (файле), то протокол передачи файлов должен передавать вместе с файлом и все его аттрибуты, включая метки. В противном случае после копирования секретных данных с машины A на машину B они могут перестать быть секретными. Если данные перемещаются без контейнера, то при доставке в конечный пункт они должны обрести новый контейнер с той же меткой. Например при передачи результата запроса из базы данных из поля категории секретно, в клиентской программе данные тоже должны быть отмеченны как секретные. При сохранении части данных в буфере обмена они должны быть отмечены там как секретные и не могут быть вставлены в нескретный документ.
Ещё немаловажный момент - преобразование данных. При преобразовании данных в другой формат может происходить естественная потеря метки из-за изменения их представления. Например, человек не может работать с файлами в их электро-магнитном или ином представлении непосрественно, для этого данные преобразуются в символьную или иную форму и выводятся при помощи соответствующего устройства. Надо помнить что в этот момент данные покинули систему и более не контролируются. Если на экран монитора выведено содержимое секретного файла, то предотвратить дальнейшую утечку информации можно только административными мерами. В конце-концов человек может использовать свою память в качестве буфера обмена в обход всех красивых мандатных моделей.
Итак, резюмирую. При передаче (преобразовании) грифованных данных, протоколы передачи должны сохранять (для преобразования по возможности) метку.  Это необходимо помнить и не возлагать особо больших надежд на программные методы защиты.

4.2.5 Нелинейная иерархия

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

4.2.5.1 Domain Type Enforcement

Самая простая из нелинейных иерархий преложнена в модели, называемой Domain Type Enforcement или сокращённо DTE. Основная идея состоит в разделении исполняемых процессов на непересекающиеся группы с более точным (и сложным) определением взаимодействий этих групп. Эта модель очень действенна например для разделения процессов по задачам, например на сетевые и локальные.
Type Enforcement - это модель базирующая на таблице. Субъекты разделяются на домены, объекты на типы. Возможен доступ на чтение, запись, исполнение и отказ в доступе. Возможные варианты доступа описываются в таблице (Глобальная таблица определения доменов, Domain Definition Table (DDT)) где в столбцах перечислены домены, в строках типы, а на пересечении указаны возможные права доступа.
Взаимодействие между субъектами контролируется дополнительной таблицей (Domain Interaction Table - DIT). В строках и столбах данной таблицы перечислены домены, на пересечении возможные права доступа, например:  послать сигнал, создать/уничтожить,  и т.д.
В отличие от TE, DTE поддерживает неявное определение аттрибутов. Например, аттрибуты могут быть заданы на каталог и наследоваться на все файлы и подкаталоги данного каталога.
Каждый процесс может перейти из одного домена в другой только через запуск специального процесса, так называемую точку входа. Переход возможен, только если один домен имеет право запуска для другого домена. Право запуска "auto" на некотором домене автоматически выбирает этот домен, если произошёл вход в одну из его точек входа.
В результате получаем высокоуровневое описание схемы которую уже можно легко привязать к реальной системе. Сильная сторона этой модели - максимально возможная точность при определении матрицы доступа. Слабая сторона следует из сильной, столь подробное описание сложно поддерживать. Как правило домены определяются один раз и больше не меняются.

4.2.5.2 Ролевая модель

Ролевая модель (Role Based Access Control - RBAC) определяет субъекты, роли и транзакции. Транзакция - это процедура изменения состояния, рассматриваемая вместе с необходимыми для этого правами доступа к данным. Вся деятельность в системе происходит через определённые транзакции, за исключением сугубо системных задач, таких как идентификация и аутентификация.
Три основных правила ролевой модели:
  1. Назначение ролей: Субъект может запустить транзакцию только если субъект имеет назначенную или выбранную роль.
  2. Авторизация роли: Активная роль субъекта должна быть одна из авторизованных данному субъекту
  3. Авторизация транзакции: Субъект может запустить транзакцию только если эта транзакция авторизована для активной роли субъекта.
Дополнительно в описании транзакций возможно указать какая роль какие права доступа к объектам имеет во премя запуска процедуры трансформации.
Роли могут иметь представительство в другой роли. Дочерняя роль наследует права всех родительских ролей, включая их авторизации на запуск транзакций. Для поддержания правила Разделения обязанностей дополнительно действует правило взаимного исключения. Благодаря этому пары ролей не могут иметь общей дочерней роли, или иначе говоря не могут быть одновременно актифированны для одного и того же субъекта.
Для каждой роли определяется максимально возможное количество дочерних ролей, а также максимально возможное количество субъектов, которые могут иметь её в качестве активной.
Данная модель интересна своей ориентированностью на выполняемые задачи. Каждая задача получает ровно столько полномочий сколько ей необходимо - не больше и не меньше. Нет необходимости в отличие от DTE заполнять права на все файлы. Разрешения возникают только там где это необходимо. Тем н менее данная модель всё-таки достаточно сложная и требует большой квалификации обслуживающего персонала. Но это общее правило - тем длинее поводок, чем точнее минимизируются полномочия пользователей, тем сложнее используемая модель.

4.2.6 Заключение

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

4.3 Контроль целостности

Пожалуй самый распространённый приём защиты данных - это контроль целостности. Данная технология применяется в различных контекстах и на разных этапах жизненного цикла программного обеспечения.
Во-первых, контроль целостности играет доказательную роль в любом сертификационном процессе. Сертифицированный продукт не может быть изменён по дороге от сертификационного центра до покупателя. Помимо чисто административных мер (пломбирование дисков с информацией), распространённым является сличение контрольных сумм данных на диске с контрольными суммами указанными на сопроводительных документах.
Второе применение, это подтверждение замкнутости программной среды. Одним из важных организационных приёмов является неизменность программной среды узлов автоматизированной системы. Ведь если пользователи будут ставить на рабочих местах какие угодно программы, то это равносильно тому что пронести оружие в защищаемое помещение. Умышленно или случайно таким способов в автоматизированной системе могут возникнуть вирусы, "троянские" программы, процессы приводящие к атакам типа отказ в обслуживании и многое другое. Просто ограничить список используемого ПО недостаточно, необходимо ещё как-то это контролировать. Замкнутая программная среда означает, что все исполняемые файлы не возможно удалить или перезаписать, а пользователь не может запускать никаких приложений кроме тех, которые разрешены ему поисполняемым задачам.  Регулярная проверка и совпадение с эталонными контрольных сумм файлов исполняемых программ убеждает (до некоторорой степени) администратора, что в системе исполняются только те программы, которые были инсталлированы им и нет никаких новых, нелегальных программ. Эту процедуру можно назвать "статическим протоколированием". Периодически делается "слепок" системы и сравнение с эталонным состоянием. Данная процедура весьма полезна для анализа глобальных изменений, просмотр как бы с высоты птичьего полёта.
Контроль целостности может проводиться в любое время - как до загрузки операционной системы специальными аппаратными средствами, так и во время работы системы или аппаратными или программными средствами. При использовании и разработке программных средств следует иметь в виду что:
Для расчёта контрольных сумм как правило используются так называемые хеш-функции. Их задача "перемолотить" переданные данные до неузнаваемости и при этом достичь эффекта, когда сложно подобрать две такие входные комбинации, когда будет одинаковый выход. Наиболее часто используются такие проверенные временем алгоритмы как:
Полезно также использовать имитовставки ГОСТ-28147-89, это вносит ещё один уровень надёжности - невозможно подделать  контрольную сумму не зная секретного ключа.
Работая с контрольными суммами необходимо помнить, что они хоть и дают вероятность обнаружения изменения файла, но эта вероятность не стопроцентная. Как правило размер файла во много раз превышает размер контрольной суммы. Получить стопроцентную гарантию можно только путём побайтового сравнения с эталоном.

4.4 Анализаторы исходного кода

Данный класс средств предназначен для того чтобы изначально предотвратить большинство стандартных ошибок в программном обеспечении. Использование хорошо проверенного программного обеспечения снимает как минимум половину наиболее распространённых атак на АС.
В настоящий момент используются два класса подобных средств:
При этому средства аудита могут быть:
Средства предотвращения как правило являются расширениями к стандартным компиляторам добавляющие дополнительные проверки на соблюдение границ структур данных во время исполнения программы.

4.5 Сетевые средства

4.5.1. Межсетевые экраны

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


Функциониальные требования к МЭ охватывают слудующие сферы:


Основные компоненты межсетевых экранов . Большинство компонентов
межсетевых экранов можно отнести к одной из трех категорий:


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

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


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

К положительным качествам фильтрующих маршрутизаторов можно отнести:




Недостатками фильтрующих маршрутизаторов являются:


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



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



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



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



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


К недостаткам шлюзов уровня приложений отностятся:





 Основные схемы сетевой защиты на базе межсетевых экранов

При подключении АС к глобальным сетям администратор сетевой
безопасности должен решать следующие задачи:


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


Для защиты АС применяются следующие основные схемы организации МЭ:



4.5.2 Виртуальные частные сети



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

Виртуальные частные сети (Virtual Private Networks - VPN) предназначены
для безопасного обмена данными между удалёнными пользователями и
удалёнными друг от друга ЛВС. Основным компонентом VPN являются
криптографические устройства, располагаемые на шлюзах АС. Возможны
следующие варианты реализации VPN:


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



4.5.3 Сканеры безопасности

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

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


4.5.4 Средства обнаружения атак

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



4.6 Криптографические средства



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


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

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

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

Работа прикладных программ с дисковыми накопителями состоит их двух
этапов - "логического" и "физического". Логический этап соответствует
уровню взаимодействия прикладной программы с операционной системой
(например, вызов сервисных функций чтения/записи данных). На этом
уровне
основным объектом является файл. Физический этап соответствует уровню
взаимодействия операционной системы и аппаратуры. В качестве объектов
этого уровня выступают структуры физической организации данных - сектор
диска.

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

Другим классификационным признаком систем шифрования дисковых даных
является способ из функционирования . По способу функционирования
системы шифрования дисковых данных делят на два типа:


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

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

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

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


Шифрование передаваемых данных на сетевом уровне в настоящее время
регламентируется новым протоколом IPSec, предназначенным для
аутентификации, туннелирования и шифрования IP-пакетов.
Стандартизиванный консорциумом Internet Engineering Task Force (IETF)
протокол IPSec вобрал в себя все лучшие решения по шифрованию пакетов и
должен войти в качестве обязательного компонента в протокол IPv6.
Протокол IPSec предусматривает не только стандартные способы
использования шифрования конечными точками виртуального туннеля, но и
стандартные методы идентификации пользователй или компьютеров при
инициации туннеля, а также стандартные методы обмена и управления
ключами шифрования между конечными точками. Шифрование передаваемых
данных на транспортном уровне осуществляется, в сущности, шифраторами,
которые зачастую привязаны к единственному приложению, например
электронной почте. Наиболее известными из таких протоколов являются
SMTP
over Transport Layer Security, Secure Shell и т.д.

Некоторые виртуальные частные сети используют подход под названием
"посредники каналов" (circuit proxy). Этот метод функционирует над
транспорнтым уровнем и ретранслирует трафик из защищенной сети в
общедоступную сеть Internet для каждого сокета в отдельности (сокет IP
идентифицируется комбинацией TCP-соединения и конкретного порта или
заданным портом UDP). Стек TCP/IP не имеет пятого - сеансовго - уровня,
однако ориентированные на сокеты операции часто называют операциями
сеансового уровня. Шифрование информации, передаваемой между
инициатором
и терминатором тунеля, часто осуществляется с помощью защиты
транспортного уровня TLS (Transport Layer Security) ранее протокола
защищенных сокетов SSL. Для стандартизации аутентифицированного прохода
через межсетевые экраны консорциум IETF определил протокол под
названием
SOCKS, и в настоящее время протокол SOCKS v.5 применяется для
стандартизованной реализации посредников каналов.

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

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

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


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

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

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

Код аутентификации сообщения формируют с помощью симметричных систем
шифрования данных. В частности, симметричный алгоритм шифрования данных
DES при работе в режиме сцепления блоков шифра CBC позволяет
сформировать с помощью секретного ключа и начального вектора IV код
аутентификации сообщения MAC (Message Authenication Code). Проверка
целостности принятого сообщения осуществляется путем проверки кода MAC
получателем сообщения.

Аналогичные возможности предоставляет отечественный стандарт
симметричного шифрования данных ГОСТ 28147-89. В этом алгоритме
предусмотрен режим выработки имитовставки, обеспечивающий имитозащиту,
то есть защиту систмы шифрованной связи от навязывания ложных данных.

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

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

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

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

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

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

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

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

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



4.7 Безопасность и производительность системы

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




4.8 Интеграция сервисов безопасности с ПО  



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

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

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

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

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


5. Проблемы существующих решений

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




5.1 Система печати с  поддержкой вывода грифованной информации

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

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

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

Документ это объект более высокого уровня нежели файл потому что:


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




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


Отметим, что  это минимальный набор без системы совместной работы
над документом.

Всё перечисленное наводит на мысль о том что система защиты ОС вроде
как нигде не участвует. Однако это не так: ОС как доверенная основа
обеспечивает:


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


5.2 Электронная почта с поддержкой пересылки грифованной информации

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

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

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

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

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

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

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

Когда письмо готово покинуть сервер, последний связывается со службой
DNS на предмет MX, то есть адреса того сервера который обслуживает
почту
данного домена. Либо протокол должен поддерживать метку доступа
(стандартный протокол конечно же этого не делает) либо надо эту метку
инкапсулировать в письмо причём защищённым образом (с применением
шифрования) чтобы не могла произойти подмена метки во время пути.
Маршрут письма совершенно не определён. Всегда надо быть готовым что
письмо канет в небытие. Злоумышленник может подсунуть ложную запись
DNS,
спровоцировать DOS для принимающего сервера, попытаться подсунуть
вместо
данного письма совсем другое.

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

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

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

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


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

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


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



5.6 Распределённые файловые системы с поддержкой мандатной модели
доступа

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

Принципиально возможны две модели работы распределённой файловой
системы:


    
  
  1. Когда пользователь пытается получить доступ к файлу, файл
скачивается на локальную машину и далее вся работа идёт с локальной
копией. Так работает например AFS.
    
  
    2. 
  
  2. Работа полностью происходит на удалённой машине. Вся работа с
файлом происходит удалённо. Так например работает NFS, но с некоторыми
оговорками, поскольку для оптимизации применяется кеширование.
    3. 


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

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

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




Выводы и рекомендации

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

Первый момент. Со времени появления первых автоматизированных систем
мир изменился. Современные автоматизированные системы вышли за рамки
закрытых предприятий. Часто их маршрут стал пролегать через сети
публичного доступа. Интерфейс современных компьютерных технологий
упростился до такой степени, что стало возможным участие в качестве
пользователей практически всех людей планеты. Даже ученик 6-го класса
уже может иметь доступ к сети общего доступа и случайно "наткнуться" на
шлюз правительственной автоматизированной системы. Компьютерные сети
вышли за пределы государств и соответственно морально-этических норм.
Человек может теперь совершать преступления на территории одного
государства, физически находясь на территории другого. Законодательные
нормы же его собственного государства могут просто не предусматривать
никакого наказания за преступления в компьютерной сфере. Всё это делает
автоматизированные системы уязвимыми как никогда. А с учётом того что
на
них возлагаются всё более и более ответственные функции, зачастую
связанные с безопасностью жизнедеятельности. Это означает что цена
информации во много раз превышает стоимость оборудования на котором она
обрабатывается и последствия простой атаки могут стать просто
катастрофическими. Вывод, не надо жалеть средств и времени для
огранизации комплексной защиты автоматизированной системы, в противном
случае потом придётся заплатить больше. Есть ли выход из сложившейся
ситуации? Ответ однозначен - есть. Необходим комплескный и детальный
подход к проектированию автоматизированной системы. При проектировании
необходимо изначально учитывать высокие требования безопасности
актуальные для современного мира. Надо учитывать всё: начиная с
физической топологии сети, заканчивая выбором протоколов и программного
обеспечения.

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

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

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

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

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


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