Лекции Беликова. Лекции БЕЛИКОВОЙ Н.В.. Конспект лекций по дисциплине Информационная безопасность для специальности 080505 Управление персоналом

• Название: Конспект лекций по дисциплине Информационная безопасность для специальности 080505 Управление персоналом
• Анкор: Лекции Беликова
• Дата: 17.11.2020
• Размер: 1.25 Mb.
• Имя файла: Лекции БЕЛИКОВОЙ Н.В..doc
• Тип: Конспект лекций; #151366
• страница: 9 из 14

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

Таксономия (Тахоnоmу), Наука о систематизации и классификации сложноорганизованных объектов и явлений, имеющих иерархическое строение (от греческого taxis — расположение, строй, порядок и nomos — закон). Прямое взаимодействие (Trusted Path). Принцип организации информационного взаимодействия (как пра¬вило, между пользователем и системой), гарантирующий, что передаваемая информация не подвергается перехвату или искажению.

4.2.1 Таксономия изъянов защиты (ИЗ)

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

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

1. Каким образом ИЗ появляются в системе защиты? (Классификация ИЗ по источнику появления.)

2. На каком этапе они вносятся? (Классификация ИЗ по этапу возникновения.)

3. В каких компонентах системы защиты (или ВС в целом) они возникают и проявляются? (Классификация ИЗ по размещению в системе).

Классификация ИЗ по источнику появления

Как следует из определения ИЗ, источником их появления является ошибка или недоработка в системе безопасности.

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

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

Классификация изъянов защиты по этапу возникновения

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

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

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

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

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

Классификация ИЗ по размещению в системе

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

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

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

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

• инициализация (загрузка) системы;

• управление распределением памяти;

• управление устройствами;

• управление процессами;

• управление файловой системой;

• идентификация и аутентификация.

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

4.2.2 Таксономия причин возникновения изъянов защиты

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

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

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

3. Отсутствие идентификации и/или аутентификации субъектов и объектов. Во многих современных ОС (различные версии Unix, Novell NetWare, Windows) идентификация и аутентификация субъектов и объектов взаимодействия находятся на весьма примитивном уровне — субъект может сравнительно легко выдать себя за другого субъекта и воспользоваться его полномочиями доступа к информации. Кроме того, можно внедрить в систему «ложный» объект, который будет при взаимодействии выдавать себя за другой объект. Часто идентификация и аутентификация носят непоследовательный характер и не распространяются на все уровни взаимодействия; так, например, в ОС Novell NetWare предусмотрена аутентификация пользователя, но отсутствует аутентификация рабочей станции и сервера. В стандартной версии ОС Unix аутентификация пользователей находится на очень примитивном уровне: программы подбора пароля легко справляются со своей задачей при наличии у злоумышленника идентификатора пользователя и зашифрованного пароля. Ряд служб ОС Unix (в первую очередь сетевые службы, использующие стек протоколов TCP/IP) и всемирная информационная сеть Internet в силу сложившихся обстоятельств и необходимости соблюсти требования по совместимости в глобальном масштабе вообще не предусматривают аутентификации при сетевых взаимодействиях.

4. Отсутствие контроля целостности средств обеспечения безопасности. Во многих ОС контролю целостно¬сти самих механизмов, реализующих функции защиты, уделяется слабое внимание, но, как уже говорилось, в условиях распространения РПС контроль целостности приобретает решающее значение. Многие системы допускают прозрачную для служб безопасности подмену компонентов. Например, ОС Unix традиционно построена таким образом, что для обеспечения ее функционирования многие процессы должны выполняться с уровнем полномочий, превышающим обычный пользовательский уровень (с помощью механизма замены прав пользователя на права владельца программы). Такие приложения являются потенциальной брешью в системе защиты, так как нуждаются в проверке на безопасность при установке в систему и постоянном контроле целост¬ности в ходе эксплуатации. С точки зрения безопасно¬сти, такая ситуация является недопустимой, так как не соблюдается принцип минимальной достаточности при распределении полномочий процессов и пользователей. Список критичных приложений и пользователей, обла¬дающих высоким уровнем привилегий, должен быть максимально ограничен. Этого можно достичь путем последовательного применения принципа локализации функций обеспечения безопасности и целостности в рам¬ках ядра ОС.

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

6. Наличие средств отладки и тестирования в конечных продуктах. Многие разработчики оставляют в комерческих продуктах т. н. «люки», «дыры», отладочные возможности и т.д. Наиболее известные примеры — отладочная опция в программе sendmail и встроенный отладчик ОС Novell NetWare. Причины, по которым это происходит, вполне понятны — программные продукты становятся все сложнее, и отладить их в лабораторных условиях становится просто невозможно. Следовательно, для определения причин сбоев и ошибок уже в процессе эксплуатации разработчикам приходится оставлять в своих продуктах возможности для отладки и диагностики в ходе эксплуатации. Очевидно, что для тех ситуаций, где безопасность имеет решающее значение, применение подобной практики недопустимо.

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

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

4.2.3 Анализ способов нарушений информационной безопасности

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

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

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

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