Таксономия причин возникновения ПББ.

 

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

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

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

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

2. Неправильное внедрение модели безопасности. В этом случае модель безопасности была выбрана верно, но ее применение к конкретной реализации ОС в силу свойств модели или самой ОС было проведено неудачно. Это означает, что при реализации были потеряны все теоретические достижения, полученные при формальном доказательстве безопасности модели. Это наиболее распространенная причина нарушения безопасности ВС Обычно, неправильное внедрение модели безопасности в систему выражается в недостаточном ограничении доступа к наиболее важным для безопасности ОС и системным службам и объектам, а также введении различных исключений из предусмотренных моделью правил разграничения доступа типа привилегированных процессов, утилит и т. д. В качестве примеров можно привести случаи, обозначенные в Приложении 1 индексами 11, 14, 16, 17, MU3, В1, UN1, U4, U5, U14.

3. Отсутствие идентификации и/или аутентификации субъектов и объектов. Во многих современных ОС (различные версии Unix, Novell Netware, Wndows) идентификация и аутентификация субъектов и объектов взаимодействия находятся на весьма примитивном уровне — субъект взаимодействия может сравнительно легко выдать себя за другого субъекта и воспользоваться его полномочиями доступа к информации. Кроме того, можно внедрить в систему "ложный" объект, который будет при взаимодействии выдавать себя за другой объект. Часто идентификация и аутентификация носят непоследовательный характер и не распространяются на все уровни взаимодействия — так, например, в ОС Novell Netware предусмотрена аутентификация пользователя, но отсутствует аутентификация рабочей станции и сервера (см главу 4). В стандартной версии ОС Unix аутентификация пользователей находится на очень примитивном уровне — программы подбора пароля легко справляются со своей задачей при наличии у злоумышленника идентификатора пользователя и зашифрованного пароля. Ряд служб ОС Unix(B первую очередь сетевые службы) в силу сложившихся традиций (необходимости соблюсти требования по совместимости в глобальном масштабе) вообще не предусматривает аутентификации. Пример в Приложении 1 — MU1

 

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

 

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

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

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

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

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