- •Учебное пособие
- •Аннотация
- •Список сокращений
- •Содержание
- •Введение
- •Научные и технические предпосылки кризисной ситуации.
- •Бурное развитие программного обеспечения.
- •Понятие «защищенная система».
- •1. Основные понятия и определения предмета защиты информации
- •1.1. Общее содержание проблемы информационной безопасности
- •1.2 Информация и информационные отношения. Субъекты информационных отношений
- •1.3. Ценность информации
- •1.4. Модель решетки ценностей
- •1.5. Mls решетка
- •1.6. Определение требований к защищенности информации
- •1.7. Критерии, условия и принципы отнесения информации к защищаемой. Виды конфиденциальной информации.
- •1.8. Выводы
- •1.9. Вопросы для самоконтроля
- •Угрозы информации, методология их выявления и оценки
- •2.1. Санкционированный и несанкционированный доступ
- •2.2. Угрозы информации, методология их выявления и оценки
- •2.3. Ретроспективный анализ подходов к формированию множества угроз информации
- •2.4. Цели и задачи оценки угроз информации в современных системах ее обработки
- •2.5. Система показателей уязвимости информации
- •2.6. Классификация и содержание угроз информации
- •2.7. Методы и модели оценки уязвимости информации
- •2.8. Выводы
- •2.9. Вопросы для самоконтроля
- •3. Общая классификация защитных мер
- •3.1. Базовые свойства безопасности информации. Каналы реализации угроз
- •3.2. Основные принципы обеспечения информационной безопасности
- •3.3. Меры обеспечения безопасности компьютерных систем
- •3.4. Характеристика способов защиты компьютерной информации с помощью аппаратно-программных мер
- •3.5. Выводы
- •3.6. Вопросы для самоконтроля
- •4. Идентификация и аутентификация субъектов
- •4.1. Классификация подсистем идентификации и аутентификации субъектов
- •4.2. Парольные системы идентификации и аутентификации пользователей
- •4.3. Идентификация и аутентификация с использованием индивидуальных биометрических характеристик пользователя
- •4.4. Выводы
- •4.5. Вопросы для самоконтроля
- •5. Элементы теории чисел
- •5.1. Модулярная арифметика
- •5.2. Простые числа и их свойства
- •5.3. Числовые функции
- •5.4. Выводы
- •5.5. Вопросы для самоконтроля
- •6. Методы и средства криптографической защиты
- •6.1. Принципы криптографической защиты информации
- •6.2. Традиционные симметричные криптосистемы
- •6.2.1. Шифрование методом замены
- •6.2.2. Шифрование методами перестановки
- •6.2.3. Шифрование методом гаммирования
- •6.3. Элементы криптоанализа
- •6.4. Современные симметричные системы шифрования
- •6.4.1. Стандарт шифрования des (сша)
- •6.4.2. Отечественный стандарт симметричного шифрования
- •6.5. Асимметричные криптосистемы
- •6.5.1. Недостатки симметричных криптосистем и принципы асимметричного шифрования
- •6.5.2. Однонаправленные функции
- •6.5.3. Алгоритм шифрования rsa
- •6.6. Выводы
- •6.7. Вопросы для самоконтроля
- •7. Контроль целостности информации. Электронно-цифровая подпись
- •7.1. Проблема обеспечения целостности информации
- •7.2. Функции хэширования и электронно-цифровая подпись
- •7.3. Выводы
- •7.4. Вопросы для самоконтроля
- •8. Протоколы безопасной аутентификации пользователей
- •8.1. Аутентификация на основе сертификатов
- •8.2. Процедура «рукопожатия»
- •8.3. Протокол Диффи-Хеллмана
- •8.4. Выводы
- •8.5. Вопросы для самоконтроля
- •9. Управление носителями конфиденциальной информации и внесением изменений.
- •9.1. Носители информации как объект защиты
- •9.2 Разделение тестовой среды и среды промышленной эксплуатации информационной системы. Процесс управления изменениями.
- •9.3. Выводы
- •9.4. Вопросы для самоконтроля
- •10. Разграничение доступа к информации в компьютерных системах
- •10.1. Модели разграничения доступа к информации
- •10.2. Субъектно-объектная модель компьютерной системы в механизмах и процессах коллективного доступа к информационным ресурсам
- •10.2. Монитор безопасности и основные типы политик безопасности
- •10.3. Гарантирование выполнения политики безопасности
- •10.4. Выводы
- •10.5. Вопросы для самоконтроля
- •11. Политики безопасности
- •11.1. Формальные и неформальные политики безопасности
- •11.2. Формальные методы анализа систем
- •11.3. Характеристика моделей безопасности
- •11.4. Выводы
- •11.5. Вопросы для самоконтроля
- •12. Модели безопасности
- •12.1. Модели разграничения доступа
- •12.2. Модели дискреционного доступа
- •12.2.1. Модель дискреционного доступа адепт-50.
- •12.2.2. Пятимерное пространство Хартсона
- •12.2.3. Модель Харрисона-Руззо-Ульмана
- •12.3. Модели мандатного доступа
- •12.3.1. Модель Белла и Лападула
- •12.4. Специализированные модели
- •12.4.1. Модель mms
- •12.5. Проблемы моделей предоставления прав
- •12.6. Информационные модели
- •12.6.1. Модель невмешательства
- •12.6.2. Модель невыводимости
- •12.7. Вероятностные модели
- •12.7.1. Игровая модель
- •12.7.2.Модель системы безопасности с полным перекрытием
- •12.8 .Модели контроля целостности
- •12.8.1. Модель Биба
- •12.8.2. Модель Кларка-Вилсона
- •12.9. Механизмы защиты от угрозы отказа в обслуживании
- •12.9.1. Основные понятия ово
- •12.9.2. Мандатная модель ово
- •12.9.3. Модель Миллена распределения ресурсов (мрр)
- •12.10. Выводы
- •12.11. Вопросы для самоконтроля
- •13. Обзор и сравнительный анализстандартов информационной безопасности
- •13.1. Основные понятия и определения
- •13.2. Критерии безопасности компьютерных систем министерства обороны сша ("Оранжевая книга")
- •13.2.1. Таксономия требований и критериев "Оранжевой книги"
- •13.2.2. Классы безопасности компьютерных систем
- •13.2.3. Интерпретация и развитие "Оранжевой книги"
- •13.3. Европейские критерии безопасности информационных технологий
- •13.3.1. Основные понятия
- •13.3.2. Функциональные критерии
- •13.3.3. Критерии адекватности
- •13.4. Руководящие документы Гостехкомиссии России
- •13.4.1. Основные положения
- •13.4.2. Концепция защиты свт и ас от нсд к информации
- •13.4.3. Показатели защищенности средств вычислительной техники от нсд
- •13.4.4. Показатели защищенности автоматизированных систем от нсд
- •13.5. Федеральные критерии безопасности информационных технологий
- •13.5.1. Цель разработки
- •13.5.2. Основные положения
- •13.5.3. Профиль защиты
- •13.5.4. Этапы разработки Профиля защиты
- •13.5.5. Функциональные требования к ит–продукту
- •13.5.6. Таксономия функциональных требований
- •13.5.7. Ранжирование функциональных требований
- •13.5.8. Требования к технологии разработки ит–продукта
- •13.5.9. Требования к процессу квалификационного анализа ит-продукта
- •13.6. Единые критерии безопасности информационных технологий
- •13.6.1. Цель разработки
- •13.6.2. Основные положения
- •13.6.3. Профиль защиты
- •13.6.4. Проект защиты
- •13.6.5. Требования безопасности
- •13.6.6. Функциональные требования
- •13.6.7. Требования адекватности
- •13.7. Анализ стандартов информационной безопасности
- •13.8. Выводы
- •13.9. Вопросы для самоконтроля
- •Список литературы
- •420111, Г. Казань, ул. К.Маркса, 10
9.2 Разделение тестовой среды и среды промышленной эксплуатации информационной системы. Процесс управления изменениями.
Защита автоматизированных систем должна обеспечиваться на всех стадиях их жизненного цикла, в том числе на этапах тестирования и промышленной эксплуатации. В последнем случае в организации должны быть внедрены следующие процедуры.
Контроль программного обеспечения, находящегося в промышленной эксплуатации
Необходимо обеспечивать контроль за процессом внедрения программного обеспечения в промышленную эксплуатацию. Чтобы свести к минимуму риск повреждения систем, находящихся в промышленной эксплуатации, целесообразно использовать следующие мероприятия по обеспечению информационной безопасности:
обновление библиотек программ следует выполнять только назначенному специалисту - библиотекарю при соответствующей авторизации его обязанностей руководством;
по возможности, системы, находящиеся в промышленной эксплуатации, должны состоять только из исполнимых программных кодов;
исполняемую программу не следует внедрять в промышленную эксплуатацию до тех пор, пока не получены подтверждения ее успешного тестирования и принятия пользователями, а также не обновлены соответствующие библиотеки исходных текстов программ;
необходимо, чтобы журнал аудита регистрировал все обновления библиотек программ, находящихся в промышленной эксплуатации;
предыдущие версии программного обеспечения следует сохранять для восстановления системы в случае непредвиденных обстоятельств.
Необходимо, чтобы программное обеспечение, используемое в промышленной эксплуатации, поддерживалось на уровне, заданном разработчиком. При любом решении провести обновление до уровня новой версии следует принимать во внимание безопасность данной версии: какие новые функциональные возможности обеспечения информационной безопасности она имеет или имеются ли серьезные проблемы обеспечения безопасности, связанные с этой версией. Целесообразно использовать программные модификации (патчи), если они могут закрыть или снизить угрозы безопасности.
Физический или логический доступ предоставляется поставщикам (разработчикам), по мере необходимости, только для поддержки программного обеспечения при наличии разрешения руководства. При этом действия поставщика (разработчика) должны контролироваться.
Защита тестовых данных
Данные тестирования следует защищать и контролировать. Для осуществления системного и приемочного тестирования требуются существенные объемы тестовых данных, которые максимально приближены к операционным данным. Следует избегать использования баз данных, находящихся в промышленной эксплуатации и содержащих личную информацию. Если такая информация требуется для тестирования, то перед использованием следует удалить личную информацию (деперсонифицировать ее). Для защиты операционных данных, когда они используются для целей тестирования, необходимо применять следующие мероприятия по обеспечению информационной безопасности:
процедуры контроля доступа, применяемые для прикладных систем, находящихся в промышленной эксплуатации, следует также применять и к прикладным системам в среде тестирования;
при каждом копировании операционной информации для прикладной системы тестирования предусматривать авторизацию этих действий;
после того, как тестирование завершено, операционную информацию следует немедленно удалить из прикладной системы среды тестирования;
копирование и использование операционной информации необходимо регистрировать в журнале аудита.
Контроль доступа к библиотекам исходных текстов программ
Для снижения риска искажения компьютерных программ необходимо обеспечивать строгий контроль доступа к библиотекам исходных текстов программ, для чего:
по возможности, исходные библиотеки программ следует хранить отдельно от бизнес-приложений, находящихся в промышленной эксплуатации;
назначать специалиста - библиотекаря программ для каждого бизнес-приложения;
персоналу поддержки информационных технологий не следует предоставлять неограниченный доступ к исходным библиотекам программ;
программы, находящиеся в процессе разработки или текущего обслуживания, не следует хранить в библиотеках с исходными текстами программ, находящихся в промышленной эксплуатации;
обновление библиотек и обеспечение программистов исходными текстами следует осуществлять только назначенному специалисту - библиотекарю после авторизации, полученной от менеджера, отвечающего за поддержку конкретного бизнес-приложения;
листинги программ следует хранить в безопасном месте;
следует вести журнал аудита для всех доступов к исходным библиотекам;
старые версии исходных текстов необходимо архивировать с указанием точных дат и времени, когда они находились в промышленной эксплуатации, вместе со всем программным обеспечением поддержки, управления заданиями, определениями данных и процедурами;
поддержку и копирование исходных библиотек следует проводить под строгим контролем с целью предотвращения внесения неавторизованных изменений.
Безопасность в процессах разработки и поддержки. Контроль изменений
Менеджеры, ответственные за прикладные системы, должны быть ответственными и за безопасность среды проектирования или поддержки. Они должны проводить анализ всех предложенных изменений системы и исключать возможность компрометации безопасности как системы, так и среды промышленной эксплуатации.
Чтобы свести к минимуму повреждения информационных систем, следует строго контролировать внедрение изменений - строго придерживаться формализованных процедур обеспечения информационной безопасности; осуществлять контроль за возможной компрометацией самих процедур; программистам, отвечающим за поддержку, предоставлять доступ только к тем частям системы, которые необходимы для их работы; обеспечивать формализацию и одобрение соответствующим руководством всех изменений. Изменения в прикладном программном обеспечении могут повлиять на информационную безопасность используемых бизнес-приложений. Там, где возможно, следует объединять меры по обеспечению информационной безопасности используемых бизнес-приложений и изменений в прикладных программах. Необходимо, чтобы этот процесс включал:
обеспечение протоколирования согласованных уровней авторизации;
обеспечение уверенности в том, что запросы на изменения исходят от авторизованных соответствующим образом пользователей;
анализ мер информационной безопасности и процедур, обеспечивающих целостность используемых систем;
идентификацию всего программного обеспечения, информации, объектов, баз данных и аппаратных средств, требующих изменений;
получение формализованного одобрения детальных запросов/предложений на изменения перед началом работы;
разрешение внесения изменений в прикладные программы авторизованным пользователем до их непосредственной реализации;
осуществление процесса внедрения изменений в прикладные программы с минимальными отрицательными последствиями для бизнеса;
обеспечение обновления комплекта системной документации после завершения каждого изменения и архивирование или утилизация старой документации;
поддержку контроля версий для всех обновлений программного обеспечения;
регистрацию в журналах аудита всех запросов на изменение;
коррекцию эксплуатационной документации и пользовательских процедур в соответствии с внесенными изменениями;
осуществление процесса внедрения изменений в согласованное время без нарушения затрагиваемых бизнес-процессов.
Технический анализ изменений в операционных системах
Периодически возникает необходимость внести изменения в операционные системы, например, установить последнюю поддерживаемую версию программного обеспечения. В этих случаях необходимо провести анализ и протестировать прикладные системы с целью обеспечения уверенности в том, что не оказывается никакого неблагоприятного воздействия на их функционирование и безопасность. Необходимо, чтобы этот процесс учитывал:
анализ средств контроля бизнес-приложений и процедур целостности, чтобы обеспечивать уверенность в том, что они не были скомпрометированы изменениями в операционной системе;
обеспечение уверенности в том, что ежегодный план поддержки и бюджет предусматривает анализ и тестирование систем, которые необходимо осуществлять при изменениях в операционной системе;
обеспечение своевременного поступления уведомлений об изменениях в операционной системе для возможности проведения соответствующего анализа их влияния на информационную безопасность перед установкой изменений в операционную систему;
контроль документирования соответствующих изменений в планах обеспечения непрерывности бизнеса.
Модификаций пакетов программ следует избегать. Насколько это возможно и допустимо с практической точки зрения, поставляемые поставщиком пакеты программ следует использовать без внесения изменений. Там, где все-таки необходимо вносить изменения в пакет программ, следует учитывать:
риск компрометации встроенных средств контроля и процесса обеспечения целостности;
необходимость получения согласия поставщика;
возможность получения требуемых изменений от поставщика в виде стандартного обновления программ;
необходимость разработки дополнительных мер поддержки программного обеспечения, если организация в результате внесенных изменений станет ответственной за будущее сопровождение программного обеспечения.
В случае существенных изменений оригинальное программное обеспечение следует сохранять, а изменения следует вносить в четко идентифицированную копию. Все изменения необходимо полностью тестировать и документировать таким образом, чтобы их можно было повторно использовать, при необходимости, для будущих обновлений программного обеспечения.