2. Неправильное внедрение модели безопасности. Несмотря на правильный выбор модели безопасности, ее реализация и применение к архитектуре конкретной ОС в силу свойств самой модели или ОС было проведено не­удачно. Это означает, что в ходе реализации были поте­ряны теоретические достижения, полученные при фор­мальном доказательстве безопасности модели. Это наи­более распространенная причина нарушения безопасно­сти ВС. Обычно неправильное внедрение модели безопасности в систему выражается в недостаточном ограничснии доступа к наиболее важным для безопасности системы службам и объектам, а также во введении раз­личных исключений из предусмотренных моделью пра­вил разграничения доступа типа привилегированных процессов, утилит и т. д. В качестве примеров можно привести случаи I1, I4, I6, I7, MU3, Bl. UN1, U4, U5, U14 из Приложения IV.

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

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

5. Ошибки, допущенные в ходе программной реали­зации средств обеспечения безопасности. Эта группа причин нарушения безопасности будет существовать до тех пор, пока не появятся технологии программирова­ния, гарантирующие производство безошибочных про­грамм. По-видимому, такие технологии не появятся и ошибки такого рода будут возникать всегда. Исчерпы­вающее тестирование и верификация программных про­дуктов (особенно реализующих функции защиты) позво­ляют сократить вероятность появления подобных ошибок (примеры МТ1, MU2, DT1, Dl, U2, U3, U7, |U11, U 12 Приложения IV).

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

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

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

Рис. 3.1 Таксономия прпичин нарушения безопасности ВС

3.4.2. Взаимосвязь таксономии причин нарушения безопасности и классификации ИЗ

Рассмотрим взаимосвязь между рассмотренной таксономией причин возникновения ИЗ и предложенной в работе [1] классификацией источников появления и этапов внедрения ИЗ.

Сопоставление предложенной таксономии причин нарушения безопасности и классификации источников появления ИЗ [I] показано на рис. 3.2.

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

На рис. 3.3 показано соответствие между причинами нарушений безопасности и классификацией ИЗ по этапу внесения [I].

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