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