Причины возникновения ПББ

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

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

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

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

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

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

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

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