Таксономия причин возникновения нарушений информационной безопасности представлена на Рис. 3.
Рис. 3.Причины нарушения безопасности ИС.
Все случаи нарушений информационной безопасности происходят по одной из следующих причин:
1. Выбор модели безопасности, несоответствующей назначению или архитектуре вычислительной сети. Модель безопасности должна соответствовать как требованиям, предъявляемым к безопасности вычислительной сети, так и принятой в ней парадигме обработке информации. При выборе модели безопасности необходимо учитывать архитектуру и специфику вычислительной сети, в противном случае, несмотря на все достоинства модели, гарантированного ею уровня безопасности достичь не удастся.
2. Неправильное внедрение модели безопасности. В этом случае модель безопасности выбрана правильно, но ее применение к конкретной реализации операционной системы в силу свойств модели или самой операционной системы было проведено неудачно. Это означает, что при реализации были потеряны все теоретические достижения, полученные при формальном доказательстве безопасности модели. Неправильное внедрение модели безопасности в систему выражается в недостаточном ограничении доступа к наиболее важным для безопасности операционной системы и системным службам и объектам, а также введении различных исключений из предусмотренных моделью правил разграничения доступа типа привилегированных процессов, утилит и т. д.
3. Отсутствие идентификации и/или аутентификации субъектов и объектов. Во многих современных операционных системах (Unix, Novell Netware, Windows) идентификация и аутентификация субъектов и объектов взаимодействия находятся на весьма примитивном уровне – субъект взаимодействия может сравнительно легко выдать себя за другого субъекта и воспользоваться его полномочиями доступа к информации. Кроме того, можно внедрить в систему «ложный» объект, который будет при взаимодействии выдавать себя за другой объект. Часто идентификация и аутентификация носят непоследовательный характер и не распространяются на все уровни взаимодействия – в операционной системе Novell Netware предусмотрена аутентификация пользователя, но отсутствует аутентификация рабочей станции и сервера. В стандартной версии операционной системе Unix аутентификация пользователей находится на примитивном уровне – программы подбора пароля легко справляются со своей задачей при наличии у злоумышленника идентификатора пользователя и зашифрованного пароля. Ряд служб операционной системы Unix вообще не предусматривает аутентификации.
4. Отсутствие контроля целостности средств обеспечения безопасности. Во многих операционных системах недостаточное внимание уделено контролю целостности самих механизмов, реализующих функции защиты. Во многих системах возможна прозрачная для служб безопасности подмена компонентов. В операционной системе Unix система традиционно построена таким образом, что для обеспечения ее функционирования многие процессы должны выполняться с уровнем полномочий, превышающим обычный пользовательский уровень (с помощью механизма замены прав пользователя на права владельца программы). Такие программные приложения являются потенциальной брешью в системе защиты, так как нуждаются в проверке на безопасность при их установке в систему и постоянном контроле целостности. С точки зрения безопасности такая ситуация нежелательна – не соблюдается принцип минимальной достаточности при распределении полномочий пользователей и процессов. Перечень критичных приложений и пользователей, обладающих высоким уровнем привилегий, должен быть максимально ограничен. Это достигается последовательным применением принципа локализации функций обеспечения безопасности и целостности в ядре операционной системы.
5. Ошибки, допущенные при программной реализации систем обеспечения безопасности. Эта группа причин нарушения безопасности будет существовать до тех пор, пока не появятся технологии программирования, гарантирующие производство безошибочных программ. Тщательное тестирование и верификация программных продуктов позволит сократить вероятность появления подобных ошибок до минимума.
6. Наличие средств отладки и тестирования в конечных продуктах. Многие разработчики оставляют в коммерческих продуктах «люки», «дыры», «отладочные возможности» и т. п. Причины, по которым это происходит, – программные продукты становятся все более сложными, и отладить их в лабораторных условиях становится невозможно. Следовательно, для определения причин сбоев и ошибок уже в процессе эксплуатации программного продукта, разработчикам приходится оставлять в своих продуктах возможности для отладки и диагностики. Для тех ситуаций, где безопасность имеет решающее значение применение подобной практики недопустимо.
Читать дальше
Конец ознакомительного отрывка
Купить книгу