- •Безопасность вычислительных систем и сетей Учебное пособие
- •Раздел 1. Проектирование и оценка эффективности системы защиты информации 7
- •1.1. Основные понятия и базовые требования к средству защиты информации 7
- •Раздел 2. Проектирование системы защиты персональных данных 52
- •Раздел 3. Основополагающие методы обеспечения информационной безопасности 76
- •3.3. Разграничение доступа к ресурсам 98
- •3.4. Контроль целостности и аудит 163
- •3.5. Защита сети 168
- •3.6. Выводы по разделу 3 182
- •Раздел 1. Проектирование и оценка эффективности системы защиты информации
- •1.1. Основные понятия и базовые требования к средству защиты информации
- •1.1.1. Функциональная безопасность системного средства
- •1.1.1.1. Чем определяются требования к средствам защиты информации
- •1.1.1.2. Требования к достаточности набора механизмов защиты информации
- •1.1.1.2.1. Требования к защите конфиденциальной информации (к классу защищенности 1г)
- •1.1.1.2.2. Требования к защите секретной информации (к классу защищенности 1в)
- •1.1.1.3. Требования к корректности реализации механизмов защиты информации
- •1.1.2. Эксплуатационная безопасность системного средства
- •1.1.2.1. Основы теории надежности систем защиты информации. Основные понятия и определения
- •1.1.2.2. Оценка эксплуатационной безопасности современных ос
- •1.2. Построение системы защиты информации на основе выполения требований к достаточности набора механизмов защиты и корректности их реализации
- •1.3. Общий подход к проектированию системы защиты на основе оценки рисков
- •1.3.1. Общий подход к оценке эффективности системы защиты
- •1.3.2. Способы задания исходных параметров для оценки защищенности
- •1.3.3. Особенности проектирования системы защиты на основе оценки рисков
- •1.3.4. Применение метода последовательного выбора уступок
- •1.3.5. Проектирование системы защиты с избыточным функционалом системы защиты
- •1.4. Выводы по разделу 1.
- •Раздел 2. Проектирование системы защиты персональных данных
- •2.1. Основополагающие документы по защите персональных данных
- •2.2. Классификация испДн
- •2.3. Методика определения актуальных угроз
- •2.3.1 Порядок определения исходной безопасности испДн
- •2.3.2 Порядок определения актуальных угроз безопасности пДн из исходного множества угроз
- •2.3.3. Пример построения модели угроз безопасности пДн и определения актуальных угроз
- •2.4. Выводы по разделу 2.
- •Раздел 3. Основополагающие методы обеспечения информационной безопасности
- •3.1. Общая классификация методов защиты
- •3.2. Идентификация и аутентификация
- •3.2.1. Идентификация и аутентификация субъектов доступа
- •3.2.1.1. Идентификация и аутентификации субъекта доступа «пользователь»
- •3.2.1.1.1. Идентификация и аутентификации пользователя при входе в систему
- •2.2.1.1.2. Идентификация и аутентификации пользователя при доступе к ресурсам
- •3.2.1.2. Идентификация и аутентификации субъекта доступа «процесс»
- •3.2.2. Идентификация и аутентификация объектов доступа
- •3.2.2.1. Идентификация и аутентификация устройств
- •3.2.2.2. Идентификация и аутентификация файловых объектов
- •3.2.2.3. Идентификация и аутентификация сообщений, передаваемых по сети
- •3.3. Разграничение доступа к ресурсам
- •3.3.1. Общие положения
- •3.3.2. Определение и классификация задач, решаемых механизмами управления доступом к ресурсам
- •При функционировании защищаемого объекта в составе лвс дополнительно:
- •3.3.3. Требования к корректности решения задачи управления доступом
- •3.3.3.1. Каноническая модель управления доступом. Условие корректности механизма управления доступом
- •3.3.3.2. Понятие и классификация каналов взаимодействия субъектов доступа. Модели управления доступом с взаимодействием субъектов доступа.
- •3.3.3.3. Классификация методов управления виртуальными каналами взаимодействия субъектов доступа
- •2. В общем случае различие моделей управления доступом базируется на отличиях способов реализации канала взаимодействия субъектов доступа и методах управления им
- •3.3.4. Классификация механизмов управления доступом. Дискреционный и мандатный механизмы управления доступом
- •3.3.5. Разметка иерархических объектов доступа
- •3.3.6. Разграничения доступа для субъекта «процесс»
- •3.3.7. Разграничение доступа к объекту «процесс». Механизм обеспечения замкнутости программной среды
- •3.3.7.1. Механизм обеспечения замкнутости программной среды заданием пользователям списков исполняемых файлов
- •3.3.7.2. Механизм обеспечения замкнутости программной среды заданием пользователям каталогов с исполняемыми файлами, разрешенных на запуск
- •3.3.7.3. Расширение функциональных возможностей механизма обеспечения замкнутости программной среды
- •3.3.8. Управление доступом к каталогам, не разделяемым системой и приложениями
- •3.3.9. Ролевая модель разграничения доступа к ресурсам
- •3.3.10. Разделительная политика доступа к ресурсам. Сессионный контроль доступа
- •3.4. Контроль целостности и аудит
- •3.4.1. Контроль целостности
- •3.4.2. Аудит
- •3.5. Защита сети
- •3.5.1. Задача и способ защиты информации, обрабатываемой в составе лвс. Системный подход к проектированию системы защиты компьютерной информации в составе лвс
- •3.5.2. Задача и способ защиты доступа в сеть
- •5.5.2.1. Трансляция сетевых адресов и портов
- •3.5.2.2. Межсетевое экранирование
- •3.6. Выводы по разделу 3
1.1.2.2. Оценка эксплуатационной безопасности современных ос
Построим математическую модель для количественной оценки эксплуатационной безопасностисовременных ОС.
Допустим, что обнаружение уязвимостей – отказов защиты, описывается пуассоновским входящим потоком (описывает наиболее случайные события, что и имеет место на практике), суммарную интенсивность которого обозначим, через:
Примем также, что время устранения уязвимости – восстановление защиты, имеет экспоненциальное распределение с интенсивностью:
Теперь собственно о модели (СМО). Будем рассматривать следующую гипотетическую ситуацию - любая обнаруженная уязвимость сразу же направляется на обслуживание (устранение). Никакой очереди неустраненных уязвимостей не образуется, т.е. будем рассматривать систему (СМО) с бесконечным числом обслуживающих приборов.
Замечание. Данное допущение позволяет утверждать, что моделью будет описываться гипотетически идеальная (недостижимая) для современных ОС ситуация, т.е. расчетные значения будут не хуже реальных (оцениваем верхнюю границу). Дело в том, что на практике ситуация одновременного (полностью, либо частичного) исправления разработчиком нескольких уязвимостей встречается крайне редко.
В данных предположениях, расчетная формула вероятности того, что в системе находится ровно n требований (или присутствует n неустраненных уязвимостей) выглядит следующим образом (см. стр.159 в кн. Т.Саати. Элементы теории массового обслуживания и ее приложения. – М.: Изд. «СОВЕТСКОЕ РАДИО», 1965. – 511 с.):
С учетом же то, что:
(т.е. в каком-то состоянии система всегда должна находиться) можем определить интересующий нас параметр – критерий эксплуатационной безопасности – вероятность того, что в системе отсутствуют требования n = 0, т.е. отсутствуют неустраненные уязвимости, или вероятность того, что система находится в безопасном состоянии, по следующей достаточно простой формуле:
Итак, модель мы построили, теперь с ее помощью проведем исследование.
Как ранее отмечалось, основными параметрами, используемыми для оценки эксплуатационной безопасности системных средств, являются интенсивности отказов защиты (обнаружения уязвимостей) и восстановления защиты (устранения уязвимостей). Для определения значений данных параметров обратимся к двум любопытным исследование
Первое исследование, которое мы здесь приведем: «"Критические дни": Linux, Mac OS X, Solaris and Windows» опубликовано на сайте www.securitylab.ru 19 июня 2007 года.
Джефф Джонс провел очередное исследование на тему того, как долго компании закрывают найденные дыры в своем ПО. Рассматривались следующие коммерческие операционные системы:
Apple: Mac OS X, все версии, исправленные в 2006 году.
Microsoft: Windows 2000 (Professional и Server), Windows XP, Windows Server 2003.
Red Hat: Red Hat Enterprise Linux 2.1, Red Hat Enterprise Linux 3, and Red Hat Enterprise Linux 4.
Novell: SUSE Linux Enterprise Server 8, SUSE Linux Enterprise Server 9, SUSE Linux Enterprise Server 10, Novell Linux Desktop 9, и SUSE Linux Enterprise Desktop 10.
Sun: Все версии Solaris, исправленные в 2006.
В случае если одна уязвимость устранялась для разных версий ОС в разное время, то за время устранения считалось как среднее значение двух дат.
Если одна уязвимость устранялась в нескольких компонентах одного продукта в разное время, то уязвимость считалась устраненной, когда было выпущено последнее исправления. Например, если 1 января появилась уязвимость в Firefox и Thunderbird в RHEL3, а патч для Firefox был выпушен 10 января, а для Thunderbird 15 января, то сч В результате были получены следующие значения среднего времени устранения уязвимостей в различных операционных системах (см. рис.1.1).
Рис.1.1. Значения среднего времени устранения уязвимостей в различных операционных системах
Как видно из графика, быстрее всех исправление выпускала компания Microsoft, которой требовалось в среднем 29 дней для закрытия уязвимости, а хуже всех компания Sun, которая устраняла уязвимости в среднем за 167 дней.
На следующем графике (см. рис.1.2) представлена скорость устранения критических уязвимостей в различных операционных системах.
Рис.1.2. Скорость устранения критических уязвимостей в различных операционных системах
Заметим, что данные, полученные Джефом, несколько расходятся с исследованием компании Symantec, в котором утверждалось что Microsoft устраняет уязвимости в среднем за 21 день, Red Hat за 58, Appple Maс OS за 66, а Solaris за 122 дня. Однако сравнение Symantec затрагивает меньший период времени – только вторую половину 2006 года. А в нашем исследовании, куда важнее собственно порядок цифр.
А вот теперь мы проведем свое исследование, и оценим, как влияет продолжительность устранения уязвимостей на эксплуатационную (истинную) безопасность современных ОС. С этой целью воспользуемся нашей моделью и оценим вероятность того, что система находится в безопасном состоянии в предположении, что за год обнаруживается и исправляется только одна уязвимость. Результаты исследований представлены на рис.1.3.
Проанализируем полученный результат. Видим, что при существующей интенсивности исправления уязвимостей в ОС, говорить о какой-либо безопасности ОС просто не приходится. Ведь даже при обнаружении одной уязвимости в год (а об этом сегодня можно только мечтать) до 10% (а это лучшие показатели для сравниваемых ОС) времени эксплуатации ОС будет находиться не в безопасном состоянии.
Рис.1.3. Вероятность того, что система находится в безопасном состоянии в предположении, что за год обнаруживается и исправляется только одна уязвимость
А теперь оценим, как влияет на эксплуатационную (реальную) безопасность современных ОС интенсивность обнаружения уязвимостей. Для этого обратимся к другому исследованию под громким названием «Symantec: Windows - самая надежная система», также опубликованному на сайте www.securitylab.ru , но 27 марта 2007 года.
В данном исследовании утверждается следующее.
Microsoft Windows, несмотря на все проблемы с безопасностью, является самой надёжной операционной системой из всех существующих, утверждает Symantec.
Во втором полугодии 2006 г. в системах Windows было найдено и устранено наименьшее число уязвимостей; компания в среднем быстрее всех выпускает обновления безопасности, — говорится в последнем «Докладе об угрозах безопасности интернета», выходящем дважды в год.
Утверждение подтверждается сравнительными показателями среди пяти операционных систем: Windows, Mac OS X, HP-UX, Sun Solaris и Red Hat Linux.
За полгода Microsoft выпустила обновления более чем к 39 уязвимостям; каждая дыра существовала в открытом состоянии в среднем 21 день. На втором месте — Red Hat Linux: 208 уязвимостей и средний срок устранения 58 дней. Несмотря на большее количество, эти уязвимости были в среднем менее опасны, отмечает Symantec. Mac OS X отметилась 43 уязвимостями и средним временем устранения в 66 дней. На уязвимости высокой степени опасности у компании уходило в среднем 37 дней.
Замыкают пятёрку HP-UX и Solaris: 98 дыр и 101 день, и 63 дыры и 122 дня соответственно.
Проведем свое исследование, и попытаемся определиться с тем, что же сегодня называется самой безопасной ОС, какой уровень эксплуатационной безопасности она обеспечивает. Для этого воспользуемся нашей математической моделью и построим зависимость изменения вероятности того, что система находится в безопасном состоянии, от изменения интенсивности обнаружения уязвимостей. За интенсивность исправления уязвимостей примем максимально возможное ее значение на сравниваемом множестве вариантов ОС – интенсивность исправления уязвимостей компанией Microsoft.. Результаты исследований представлены на рис.1.4.
Рис.1.4. Зависимость изменения вероятности того, что система находится в безопасном состоянии, от изменения интенсивности обнаружения уязвимостей
Рассмотрим внимательно данные результаты, при этом будем помнить, что мы говорим о гипотетически идеальных характеристиках – это верхняя теоретическая граница, реальное положение дел куда хуже. Прежде всего, обратимся к красной пунктирной линии на рис.1.4. Этой линией характеризуется следующий случай – вероятность того, что в любой момент времени система находится в безопасном состоянии составляет 0,5, т.е. либо защищена, либо нет. А ведь такова эксплуатационная безопасность ОС достигается (см. рис.1.4) при обнаружении лишь 8 уязвимостей в год, при средней продолжительности их устранения в пределах месяца. Если же за год в среднем обнаруживается 20 уязвимостей, то вероятность того, что система находится в безопасном состоянии, составляет уже около 0,2. Другими словами, в этом случае можно говорить об отсутствии какой-либо безопасности подобной системы. Однако напомним о следующем (см. выше) «…За полгода Microsoft выпустила обновления более чем к 39 уязвимостям…».
Так каков же уровень эксплуатационной безопасности современных ОС – практически нулевой?
Самое неприятное, что с приложениями ситуация еще хуже.
Статистика уязвимостей (за 1 квартал 2008 года, см. рис.1.5, рис.1.6).
Рис.1.5. Соотношение статистики уязвимостей различных системных средств (ОС и приложений)
Всего исправлено 505 уязвимостей (57.58%), исправления отсутствуют для 350 уязвимостей (39.91%), для 14 уязвимостей производители опубликовали инструкции по устранению и 8 уязвимостей устранены частично
Рис.1.6. Статистика исправлений уязвимостей в современных приложениях
Так каков же реальный уровень эксплуатационной безопасности современной вычислительной системы с установленными на нее уязвимыми ОС и приложениями?
Выводы.
Эксплуатационная безопасность – важнейшая составляющая компьютерной безопасности. Низкий уровень эксплуатационной безопасности системного средства может свести на нет все затраты, связанные с реализацией высокого уровня функциональной безопасности системного средства.
Обеспечение высокого уровня эксплуатационной безопасности системного средства – это самостоятельная, крайне важная задача обеспечения безопасности вычислительных систем и сетей. Эта задача должна решаться добавочными средствами, предназначенными нивелировать уязвимости (либо минимизировать последствия атак на эти уязвимости), связанные с ошибками программирования в системном и прикладном ПО.