Диссертация

федеральное государственное автономное образовательное учреждение
высшего образования «Санкт-Петербургский национальный
исследовательский университет информационных технологий, механики и
оптики»
На правах рукописи
/
Теплоухова Ольга Александровна
Алгоритмы и методы повышения степени доверия безопасности
вычислительной среды на тонких клиентах
05.13.19 - Методы и системы защиты информации, информационная
безопасность
Диссертация на соискание ученой степени
кандидата технических наук
Научный руководитель
д.т.н, профессор
Гатчин Юрий Арменакович
Санкт-Петербург - 2016
2
ОГЛАВЛЕНИЕ
ВВЕДЕНИЕ.................................................................................................... 6
1 Глава. Анализ методов построение доверенной вычислительной
среды применительно к системам терминального доступа .............................. 14
1.1 Определение концепции доверенной вычислительной среды ... 14
1.2 Анализ
существующих
методов
обеспечения
доверенной
вычислительной среды ...................................................................................... 19
1.3 Системы терминального доступа .................................................. 21
1.4 Терминальные ОС ........................................................................... 27
1.5 Классификация типовых уязвимостей систем терминального
доступа
31
1.6 Протоколы удаленной загрузки операционной системы на
тонкие клиенты .................................................................................................. 34
1.7 Постановка задачи .......................................................................... 36
1.8 Выводы к первой главе. .................................................................. 37
2 Глава.
Классификация
угроз
информационной
безопасности
данных, обрабатываемых на тонких клиентах ................................................... 37
2.1 Построение модели нарушителя и классификация угроз ........... 37
2.1.1 Состав работ по проведению анализа нарушителя и угроз ИБ
39
2.1.2 Модель нарушителя .................................................................. 40
2.1.3 Классификация угроз................................................................ 42
2.1.4 Угрозы безопасности образа ОС, загружаемого на тонкий
клиент
45
2.2 Формирование
перечня
требований,
необходимых
для
выполнения при построении доверенной вычислительной среды ............... 50
3
2.3 Выводы ко второй главе ................................................................. 58
3 Глава.
Алгоритмы
и
методы
формирования
доверенной
вычислительной среды на тонких клиентах ....................................................... 59
3.1 Доверенная
загрузка
операционной
системы
как
основа
построения доверенной вычислительной среды ............................................ 59
3.2 Метод загрузки и проверки целостности образа ОС на тонкий
клиент
61
3.2.1 Описание разрабатываемого модуля доверенной сетевой
загрузки
61
3.2.2 Анализ существующих способов контроля целостности
информации .................................................................................................... 64
3.2.3 Описание инфраструктуры открытого ключа........................ 65
3.2.4 Реализация метода загрузки и проверки целостности образа
ОС
68
3.2.5 Сравнение
и
анализ
предлагаемого
метода
с
существующими методами контроля целостности .................................... 71
3.3 Алгоритм
аутентификации
участников
информационного
взаимодействия при удаленной загрузке операционной системы на тонкий
клиент
74
3.3.1 Алгоритм аутентификации с использованием одноразовых
паролей
77
3.3.2 Алгоритм аутентификации участников информационного
взаимодействия при удаленной загрузке операционной системы на
тонкий клиент с использованием инфраструктуры открытых ключей .... 79
3.3.3 Сравнение
и
анализ
предлагаемых
алгоритмов
с
существующими алгоритмами аутентификации ........................................ 86
3.4 Метод анализа эффективности системы защиты информации .. 92
4
3.4.1 1 Этап: Формализация процесса оценки эффективности
системы защиты.............................................................................................. 93
3.4.2 2 Этап: Разработка классификации угроз безопасности
информации, защищаемой с использованием данной системы защиты .. 95
3.4.3 3 Этап: Разработка математического аппарата для анализа
стойкости средств защиты информации по отношению к выявленным
угрозам
95
3.4.4 Сравнение
и
анализ
предлагаемого
метода
с
существующими методами оценки эффективности ................................... 99
3.5 Метод
повышения
степени
доверия
безопасности
вычислительной среды на тонких клиентах, входящих в состав СТД ...... 103
3.6 Выводы к третьей главе ................................................................ 108
4 Глава. Разработка прототипа аппаратно-программного модуля
доверенной сетевой загрузки и апробация разработанных алгоритмов и
методов на целевой системе терминального доступа ..................................... 108
4.1 Разработка
прототипа
аппаратно-программного
модуля
доверенной сетевой загрузки .......................................................................... 108
4.1.1 Описание аппаратных компонентов ..................................... 108
4.1.2 Программная реализация разработанных алгоритмов и
методов
112
4.2 Апробация метода создания доверенной вычислительной среды
на тонких клиентах .......................................................................................... 114
4.3 Описание объекта исследования ................................................. 114
4.4 Построение классификации угроз для ОИ ................................. 118
4.5 Построение системы защиты клиентской части СТД ............... 129
4.5.1 Идентификация и аутентификация субъектов доступа и
объектов доступа. ......................................................................................... 131
5
4.5.2 Целостность информационной системы и информации..... 132
4.5.3 Управление
доступа.
доступом
субъектов доступа
к
объектам
133
4.5.4 Ограничение программной среды. ........................................ 134
4.5.5 Защита машинных носителей информации (МНИ). ........... 134
4.5.6 Регистрация событий безопасности. ..................................... 134
4.5.7 Антивирусная защита (в т.ч. проактивная защита). ............ 135
4.5.8 Обнаружение/предотвращение вторжений .......................... 135
4.5.9 Контроль защищённости информации. ................................ 136
4.5.10 Защита технических средств................................................ 136
4.5.11 Выявление инцидентов и реагирование на них ................. 137
4.6 Сопоставление применяемых СЗИ актуальным угрозам ......... 138
4.7 Оценка
эффективности
применяемой
системы
защиты
информации ...................................................................................................... 144
4.7.1 Построение параметрической модели системы защиты..... 144
4.8 Выводы к четвертой главе............................................................ 160
ЗАКЛЮЧЕНИЕ ......................................................................................... 161
СПИСОК ЛИТЕРАТУРЫ ........................................................................ 163
ПРИЛОЖЕНИЕ 1 ...................................................................................... 180
ПРИЛОЖЕНИЕ 2 ...................................................................................... 188
ПРИЛОЖЕНИЕ 3 ...................................................................................... 189
6
ВВЕДЕНИЕ
Актуальность темы. Существующие в настоящее время сетевые
вычислительные платформы не в состоянии в полной мере выполнять
многочисленные требования в отношении безопасности обрабатываемых
данных,
предъявляемые
со
стороны
возможных
участников
информационного взаимодействия: компаний-владельцев инфраструктуры,
конечных
пользователей,
контент-провайдеров
и
других.
При
этом
значимость наличия в проектируемых автоматизированных системах (АС)
так называемого ядра безопасности – набора программных (в том числе
микропрограммных) и аппаратных компонентов, реализующих механизмы
защиты, определяемые политикой безопасности – понимают многие
компании-интеграторы.
При
формировании
аппаратно-программной
вычислительной
платформы в защищенном исполнении для современных систем вопрос
формирования доверия стоит на первом месте. При этом немаловажная роль
уделяется
используемым
подходам
в
обеспечении
защищенности
выполнения критичных вычислительных операций. Говоря о современных
тенденциях, также необходимо учитывать смещение выбора аппаратной базы
для построения АС в пользу терминальных решений. Кроме того, в
последние годы задача проектирования все чаще осуществляется с учетом
концепции
облачных
вычислений,
постепенно
проникающей
в
отечественную бизнес-структуру.
Все чаще при построении систем терминального доступа (СТД) в
качестве автоматизированного рабочего места пользователя выбираются
бездисковые терминалы – так называемые аппаратные тонкие клиенты (ТК),
представляющие собой предельно упрощенный компьютер, в составе
которого нет ни одной движущейся детали: вентиляторов, оптического
привода, даже жесткого диска. Использование такой архитектуры позволяет
обеспечить повышенный уровень информационной безопасности (ИБ),
поскольку локально на рабочих местах пользователей никакие данные не
7
хранятся. Но несмотря на разнообразие представленных в области защиты
информации (ЗИ) механизмов и средств для пользовательских рабочих
станций, гарантия корректности их функционирования строится на доверии к
операционной системе (ОС), загружаемой по сети на ТК. Уязвимости,
присутствующие
в
полученном
злоумышленнику,
изменив
с
свойства
сервера
системы
образе,
позволяют
защиты,
реализовать
несанкционированный доступ (НСД) к устройству и защищаемым данным.
Соответственно, одна из приоритетных задач, которая должна быть
решена на данном этапе – это доверенная загрузка ОС, обеспечивающая
контроль целостности загружаемого образа. Однако, среди представленных
на рынке ИБ средств защиты информации (СЗИ) в условиях удаленной
загрузки на бездисковый ТК данная задача не решена, что не позволяет
обеспечить необходимую степень доверия к вычислительной среде (ВС) с
целью гарантии корректного функционирования программных продуктов и
СЗИ. Поэтому основной задачей является повышение степени доверия к ВС
ТК путем разработки ориентированных на соответствующую аппаратную
платформу алгоритмов и методов построения ДВС.
Степень разработанности проблемы.
Поскольку вместе с развитием СЗИ, функционирующих на различных
вычислительных платформах, возник вопрос о гарантиях выполнения их
свойств, тот же самый вопрос затронул и реализацию всех критичных
вычислений с точки зрения защиты процесса. В связи с этим в зарубежной
литературе в 80-е годы прошлого века было сформулировано понятие
доверенной вычислительной среды (trusted computing base, ДВС) [1,2,3,4],
корректно
реализующей
выполняемые
в
ее
рамках
операции
и
гарантирующей свойства заданной модели безопасности. Позже данная
концепция и развитие связанных с нею методов отразились в работах
российских специалистов, наметив тенденцию к появлению решений по
реализации описываемых механизмов.
8
Впоследствии данная концепция и развитие связанных с нею методов
нашли отражение в работах российских специалистов [5,6,7,8], после чего
наметилась тенденция к появлению решений в области реализации
механизмов, позволяющих формировать доверенную вычислительную среду
(как на практике, так и в теории).
В последовавших вслед за этим исследованиях в качестве одной из
основных задач концепции ДВС рассматривалась реализация контроля
целостности [9]. В том числе, было обозначено, что первым и обязательным
этапом для этого является доверенная загрузка операционной системы.
Изучению данного механизма отводится достаточно большое место среди
работ по информационной безопасности [10,11,12,13,14,15].
Ряд работ при этом посвящается формированию новых архитектурных
решений (в том числе и мобильных), реализующих доверенную загрузку для
определённого класса задач [16,17].
В соответствии с существующими практическими потребностями
параллельно друг другу происходит развитие механизмов, обеспечивающих
доверенную загрузку ОС в Windows- и Linux-ориентированных платформах
[18,19,20,21,22].
В свете возникающей тенденции широкого использования систем
терминального доступа, в том числе, при подключении к облачной
инфраструктуре, было отмечено, что защита серверных компонентов
системы бессмысленна без обеспечения ДВС на пользовательских рабочих
станциях [23,24,25,26]. Также были выявлены особенности данной задачи по
сравнению с реализацией ДВС в привычных ранее корпоративных
информационных средах. Данная область исследования освещалась и в
работах зарубежных авторов [27,28,29,30].
В качестве альтернативы построению перманентной доверенной
вычислительной среды развивается концепция доверенного сеанса связи
удалённых
пользователей
с
сервисами
доверенной
распределенной
информационной системы. Тем не менее, доверенная загрузка операционной
9
системы
(во
время
такого
сеанса)
остается
обязательным
этапом
[31,32,33,34,35].
В рамках решения этой задачи часть работ была посвящена разработке
способов контроля целостности и аутентичности образов операционных
систем, загружаемых по сети на стационарный компьютер [36], в других
работах изучались особенности доверенной загрузки операционной системы
на тонкие клиенты, с использованием в качестве источника загружаемого
образа различных компонентов (аппаратный модуль доверенной загрузки,
отчуждаемый usb-носитель, сервер) [37,38].
В силу того, что предложенные методы формирования ДВС на
бездисковых ТК либо недостаточно универсальны, поскольку подразумевают
применение адаптированных аппаратных средств, либо недостаточно
формализованы, исследуемая задача окончательно не решена. Кроме того,
остается открытым вопрос эффективности применяемых для этого СЗИ.
Целью настоящего исследования является повышение степени
доверия со стороны пользователей к безопасности вычислительной среды на
бездисковых аппаратных тонких клиентах.
Задачи исследования:
1. Проведение анализа методов построения ДВС для объектов СТД.
2. Построение базовой модели нарушителя и классификации угроз
информационной безопасности в СТД.
3. Формирование перечня требований, необходимых для выполнения
при построении ДВС на ТК.
4. Разработка метода загрузки и проверки целостности ОС на ТК.
5. Разработка
алгоритма
аутентификации
с
использованием
одноразовых паролей.
6. Разработка
алгоритма
аутентификации
участников
информационного взаимодействия при удаленной загрузке ОС на ТК.
7. Разработка
информации.
метода
анализа
эффективности
системы
защиты
10
8. Разработка метода повышения степени доверия безопасности ВС на
ТК.
9. Апробация разработанных методов и алгоритмов.
Объектом исследования являются системы терминального доступа,
процессы загрузки операционной системы и дальнейшей обработки
информации на аппаратных тонких клиентах в составе систем терминального
доступа.
Предметом исследования являются аппаратная платформа, протоколы
загрузки и передачи информации, основное и дополнительное программное
обеспечение аппаратных тонких клиентов.
Научная новизна исследования
1. Разработаны новые подходы, методы и алгоритмы, способствующие
повышению степени доверия безопасности терминальных систем на основе
формирования ДВС на ТК, отличающиеся от существующих тем, что
гарантия корректного выполнения необходимых требований ИБ к ВС
обеспечивается
реализацией
доверенной
сетевой
загрузки
ОС
на
бездисковый ТК.
2. Разработан метод доверенной сетевой загрузки ОС, отличающийся
от известных методов применением инфраструктуры открытых ключей
(ИОК), аппаратно-программного модуля на бездисковом ТК и в результате
более высоким показателем защищенности от НСД к его компонентам.
3. Предложен алгоритм аутентификации, позволяющий реализовать
взаимную аутентификацию пользователя, ТК и защищенного usb-носителя с
применением одноразовых паролей, отличающийся от существующих
алгоритмов повышенной защищенностью от компрометации данных за счет
обновления контрольных значений при каждом сеансе доступа.
4. Предложен
алгоритм,
позволяющий
реализовать
взаимную
аутентификацию всех компонентов, задействованных в процессе загрузки
ОС (пользователя, сервера, ТК и защищенного usb-носителя, содержащего
загрузчик ОС), на основе пар открытых и закрытых ключей и организовать
11
защищенный
обмен
вспомогательных
использующий
информацией
ключей,
в
на
отличие
криптографические
от
основе
вырабатываемых
существующих
примитивы
в
алгоритмов
соответствии
с
государственными стандартами (при отсутствии отечественного стандарта на
асимметричную криптографию).
5. Разработан метод анализа эффективности построенной системы
защиты информации, отличающийся от существующих методов детальной
проработкой
атак непосредственно на
СЗИ, а
также
применением
многопараметрических моделей нарушителя, атак и самих СЗИ, что
позволяет достичь полноты, непересекаемости и четкости формируемых
критериев оценки.
6. Разработан метод повышения степени доверия безопасности ВС на
ТК, отличающийся от существующих возможностью оценить выполнимость
требований к ВС на ТК и обеспечить постоянный контроль значения степени
доверия на необходимом уровне.
Теоретическая
значимость
работы
заключается
в
том,
что
проведенные исследования и полученные результаты развивают и дополняют
теоретическую базу для построения систем терминального доступа в
защищенном исполнении.
Практическая значимость работы состоит в создании прототипа
аппаратного модуля доверенной сетевой загрузки ОС на ТК, реализующего в
собственной микропрограмме разработанные в ходе исследования методы и
алгоритмы.
Преимуществом
предлагаемого
модуля
является
его
универсальность и гибкость, поскольку не накладываются ограничения ни на
используемое оборудование, ни на тип ОС. Данное решение может быть
реализовано как в виде отдельного аппаратного модуля и применяться в
качестве средств наложенной защиты, так и в качестве прошивки для сетевой
карты. Во втором случае это позволит выпускать ТК (в совокупности с
защищенным
usb-носителем)
сразу
в
защищенном
исполнении.
Предлагаемое решение может быть востребованным для применения в
12
системах с повышенными требованиями к обеспечению информационной
безопасности,
например,
при
подключении
к
государственным
информационным системам. Теоретические аспекты диссертационного
исследования нашли свое применение в учебных процессах Университета
ИТМО в материалах учебно-методической базы по курсу «Экспертные
системы комплексной оценки безопасности объекта / Технологии и методы
комплексной защиты объектов», в публикациях, а также в выступлениях на
международных и отечественных конференциях, отчетах по полученным
грантам. Результаты диссертационной работы внедрены в ООО «Акрибия.
Проекты и сервис» и применены в рамках проектной деятельности
организации по обеспечению безопасности информационных систем.
Практическое использование результатов работы подтверждено актами
внедрения.
Методология исследования. Методы исследования базируются на
использовании теории защиты информации, математических моделей
информационной
безопасности,
методов
математической
логики
и
экспертного оценивания.
Положения, выносимые на защиту:
1. Метод загрузки и проверки целостности ОС на ТК.
2. Алгоритм аутентификации с использованием одноразовых паролей.
3. Алгоритм
аутентификации
участников
информационного
взаимодействия при удаленной загрузке ОС на тонкий клиент.
4. Метод анализа эффективности системы защиты информации.
Степень достоверности результатов подтверждается внутренней
непротиворечивостью логики исследования, корректным использованием
современного научного аппарата и методов исследований, согласованностью
вытекающих из них следствий с практически полученными результатами
апробации разработанных методов и алгоритмов, публикацией основных
результатов диссертации в ведущих рецензируемых журналах.
13
Апробация результатов
1. Международная
научно-практическая
Интернет-конференция
«Научные исследования и их практическое применение. Современное
состояние и пути развития 2012», г. Одесса, 2012.
2. Научно-практическая конференция "Информационная безопасность
и непрерывность бизнеса", г. Санкт-Петербург, 2012.
3. II, III, IV Всероссийские конгрессы молодых ученых, г. СанктПетербург, 2013-2015.
4. Научно-практическая
конференция
«Комплексная
безопасность
бизнеса в условиях экономической нестабильности», г. Санкт-Петербург,
2014.
5. Конгресс по интеллектуальным системам и информационным
технологиям «IS&IT'14», «IS&IT'16», пос. Дивноморское, 2014, 2016.
Международная
6. XIV-ая
научно-техническая
конференция
«Интеллектуальные системы ‘14» (AIS’14), пос. Дивноморское, 2014.
7. Всероссийская
молодежная
научно-техническая
конференция
«Информационные системы и технологии - 2014», пос. Дивноморское, 2014.
8. Конференция в рамках конкурса «IT-прорыв» (Региональный этап),
г. Санкт-Петербург, 2015.
9. Победитель конкурса грантов «Участник молодежного научноинновационного конкурса (УМНИК)», г. Санкт-Петербург, 2014.
10. Конкурс грантов 2014, 2015, 2016 годов для студентов вузов,
расположенных
на
территории
Санкт-Петербурга,
аспирантов
вузов,
отраслевых и академических институтов, 2014-2016.
Публикации.
По теме диссертации опубликовано 13 печатных работ, из которых 5
опубликованы
в
журналах,
входящих
в
утвержденный
Высшей
Аттестационной комиссией «Перечень ведущих рецензируемых научных
журналов и изданий, выпускаемых в Российской Федерации, в которых
14
должны быть опубликованы основные научные результаты диссертаций на
соискание ученой степени доктора и кандидата наук».
Личный
вклад.
Все
научные
результаты,
приведенные
в
диссертационной работе и сформулированные в положениях, выносимых на
защиту, получены автором лично. Во всех опубликованных работах автор
принимал главное участие в постановке и решении задач, построении
экспериментальной
части
исследования,
обсуждении
полученных
результатов, их интерпретации и последующем написании статей.
Структура диссертации. Диссертация состоит из введения, четырех
глав, заключения и списка литературы, состоящего из 137 наименований,
включая труды автора. Материал изложен на 187 страницах машинописного
текста, содержит 19 рисунков и 28 таблиц.
1
Глава. Анализ методов построение доверенной вычислительной
среды применительно к системам терминального доступа
1.1 Определение концепции доверенной вычислительной среды
Концепция доверенной вычислительной среды (ДВС) [39] уже
достаточно давно закрепилась в мировой практике информационной
безопасности (ИБ). При этом выбор понятия "доверенная" объясняется тем,
что такое свойство объекта как «безопасный» является, скорее, дискретным:
объект либо соответствует некоторому набору требований и в результате
определяется как «безопасный», либо нет, если не выполняется хотя бы одно
из выдвигаемых требований. Осознавая, что невозможно создать абсолютно
безопасный объект, специалисты решили ввести более гибкий термин,
который
позволил
бы
оценить,
насколько
объект
соответствует
предъявляемым требованиям [40]. Таким образом появилось свойство
«доверенный», более адекватно демонстрирующее ситуацию, в которой
оценка «безопасности» объекта определяется не мнением создателей, а по
совокупности факторов, будь то результаты независимой экспертизы,
исследований или значения формализуемых параметров объекта.
15
Основное место в процессе проектирования современных защищенных
АС
занимает
вопрос
обеспечения
доверия
аппаратно-программной
платформе, особенно в части выполнения критичных вычислительных
операций. Пользователи АС предпочитают быть уверенными в соответствии
необходимым требованиям безопасности используемой IT-системы.
Примечательно, что сама концепция ДВС определяется по-разному как
в различных научных работах и статьях, так и в основополагающих
международных/государственных стандартах в области защиты информации.
Это может объясняться тем, что формирование концепции происходило в
разных контекстах и с отличающимся целями. Например, в "Критериях
оценки доверенных компьютерных систем" [3] (стандарт Министерства
обороны США, значительно повлиявший в свое время на процесс
стандартизации ИБ в мире) понятие ДВС определяется как базовое для
оценки такого параметра, как степень доверия к АС. В качестве основных
критериев
при
этом
выбраны
политика
безопасности
и
уровень
гарантированности. Под первым понимается «набор законов, правил,
процедур и норм поведения, определяющих, как организация обрабатывает,
защищает и распространяет информацию». Строгость и многообразность
такой политики обязана соответствовать степени доверия, оказываемой АС.
Политика безопасности, согласно данному стандарту, – это активный аспект
защиты, включающий оценку потенциальных угроз и создание способов их
нейтрализации. Второй критерий, уровень гарантированности, определяется
как «мера доверия, которая может быть оказана архитектуре и реализации
информационной системы, и показывает, насколько корректны механизмы,
отвечающие за реализацию политики безопасности (пассивный аспект
защиты)».
Другой международный стандарт «Гармонизированные критерии
Европейских
стран»
[41]
рассматривает
безопасности
функционирования
АС,
вопрос
исходя
из
гарантированности
«корректности
и
эффективности ее архитектуры и реализации механизмов безопасности».
16
Главный акцент при этом ставится на обеспечение основных свойств
безопасности данных (конфиденциальности, целостности и доступности)
обрабатываемых данных за счет набора сервисов ИБ, которые смогут. Само
понятие ДВС в данном стандарте не формулируется, но главным условием
для
признания
надежности
АС
является
степень
уверенности
(гарантированности) в эффективности и корректности функционирования
механизмов ИБ. Таким образом, можно построить прямую связь с понятием
уровня гарантированности, вводимым в "Критериях оценки доверенных
компьютерных систем".
Из
отечественных
стандартов
в
качестве
основополагающего
необходимо рассмотреть Нормативные документы в области ЗИ от НСД
Гостехкомиссии РФ [42,43,44,45,46]. В стандарте от 2003 года по разработке
профилей защиты и заданий по безопасности [47] требования доверия к
безопасности «определяют степень уверенности в правильности реализации
функций безопасности объекта оценки». При этом важным этапом защиты
АС является процесс оценки эффективности, комплексно рассматривающей
применяемые
аппаратные/программные
СЗИ
защиты
и
практическое
исполнение механизмов ИБ. При этом обязательным этапом является анализ
СЗИ от НСД в части гарантии корректного функционирования систем
защиты (в том числе, контроля доступа), что также можно рассматривать как
отсылку к концепциям, применяемым в упомянутых международных
стандартах.
Таким образом, наблюдается схожее восприятие понятия «степень
доверия
к
АС»,
определяющую
которое
весомость
можно
определить,
априорных,
как
дополнительных
характеристику,
и
косвенных
доказательств способности владельца системы гарантировать выполнение
заданной (регламентациями высшего уровня) целевой функции в течение
всего времени функционирования АС. В термине «гарантированность» при
этом необходимо рассматривать два аспекта (согласно «Критериям оценки
доверенных компьютерных систем» [3]): операционную и технологическую.
17
При разработке и
внедрении
механизмов ИБ акцент ставится на
операционной гарантированности, позволяющей быть уверенными, что АС
действительно соответствует принятой политике безопасности и на уровне
архитектуры, и в части исполнения конкретных требований. Операционная
гарантированность подразумевает контроль непосредственно архитектуры
системы, ее целостности, тайных каналов передачи информации, процессов
доверенного восстановления после сбоев и доверенного администрирования.
При
этом
целью
технологической
гарантированности
является
исключить НСД и утечку защищаемых данных для всего времени
функционирования АС.
Концепция ДВС как основа создания и функционирования доверенной
АС в дальнейшем будет использоваться и для оценки степени доверия к
системе. ДВС должна включать все составные компоненты и механизмы
защищенной АС, которые отвечают за реализацию политики безопасности.
Все остальные компоненты системы будут основываться на том факте, что
ДВС
корректно
исполнит
высококвалифицированные
свои
функции,
злоумышленники
даже
вмешаются
если
в
функционирование остальных модулей и подсистем АС и нарушат
поддерживаемую политику ИБ. При этом компонентам вне ВС не
обязательно быть доверенными, но безопасность всей АС в целом не должна
зависеть от этого. То есть чтобы оценить степень доверия безопасности АС,
необходимо определить, насколько можно доверять её вычислительной
среде.
ДВС в соответствии со своим назначением должна обеспечивать
следующие функциональные возможности:
− контроль доступа субъектов к объектам;
− взаимодействие с аппаратно-программным обеспечением АС;
− защиту памяти;
− журналирование и анализ всех событий, касающихся ИБ.
18
Необходимо
понимать,
что
дополнение
и
усовершенствование
компонентов АС с учетом требований ИБ, приводят, как правило, к
усложнению эксплуатации самой системы и ее обслуживания. Но с другой
стороны, если все необходимые требования реализовывать только в рамках
компонентов ДВС, это неизбежно приведет к ее разрастанию и, как
следствие, усложнению контролирования корректности ее механизмов.
Совершенно ясно, что все требования по обеспечению ИБ не могут
быть выполнены исключительно на уровне ДВС – она должна играть роль
доверенной базы, на основе которой можно гарантировать, что функции,
выполняемые остальными средствами защиты, отрабатываются корректно
[48]. С учетом того факта, что обеспечение ИБ – это обязательно
комплексная деятельность, которая так или иначе будет охватывать всю АС в
целом, распределение защитных функций по ее составным компонентам АС
становится неизбежным.
При реализации защитных механизмов АС предъявляемые к ним
требования должны исходить из принципа разумной достаточности, то есть
опираться на следующие постулаты:
1. Невозможно
построить
такую
защиту,
которую
не
сможет
преодолеть ни один злоумышленник;
2. При построении защиты необходимо соблюдать баланс между
рисками, которые несет владелец защищаемой информации, и затратами,
необходимыми на обеспечения ее безопасности;
3. Стоимость построенной защиты не должна превышать стоимости
активов: как защищаемой информации, так и других сопряженных ресурсов;
4. Необходимо исходить из мотивации нарушителя: его затраты (как
финансовые, так и трудоемкость осуществления атаки) не должны
превышать выгоду, получаемую им при успешной реализации атаки и
получении доступа к защищаемой информации.
Таким образом, ДВС должна включать механизмы защиты, которые
экономически целесообразно применять в АС независимо от масштаба в
19
соответствии
с
принятой
политикой
безопасности
организации,
эксплуатирующей рассматриваемую АС. Корректное функционирование
компонентов ДВС при этом образует основу, на которой будет возможно
построить систему безопасности, отвечающую требованиям мировых
стандартов.
1.2 Анализ
существующих
методов
обеспечения
доверенной
вычислительной среды
Как показывает практика, часто именно отсутствие доверия к
вычислительной среде, в рамках которой должны выполняться критичные
вычисления, становится причиной реализации атак, целью которых является
получение
и
несанкционированное
ключевой/аутентификационной
информации,
использование
изменение
защищаемых
данных и т.д. [49,50]. Исходя из формируемого опыта, ДВС должна
обеспечивать [51,52,53]: защиту аппаратного, программного обеспечения и
обрабатываемых
данных
от
неправомерного
доступа
и
нарушения
целостности, реализацию прав на доступ к информации, проверки
аутентичности получаемых данных, своевременное обнаружение попыток
НСД к защищаемым данным, постоянный контроль за обеспечением уровня
защищенности информации.
Среди
механизмов,
используемых
для
формирования
ДВС,
наибольшую эффективность и, как следствие, распространенность получили
следующие:
1) Контроль целостности [54] – является одним из основных и,
вероятно, наиболее фундаментальных механизмов ДВС. Под понятием
«контроль целостности» понимается вычисление (определение) состояния
вычислительного устройства (ВУ) (или компонента АС) и сохранение этого
состояния в неизменном виде.
Осуществление контроля целостности во время загрузки операционной
системы (ОС) на ВУ называется доверенной загрузкой. Данный метод с
высокой степенью достоверности определяет, может ли тот или иной образ
20
быть загружен и принят к выполнению. При этом положительное решение о
загрузке принимается только после осуществления ряда проверок. В
зависимости
от
реализации
средства
доверенной
загрузки,
может
определяться, разрешен ли данный носитель с образом ОС (жесткий диск,
usb-носитель и т.д.), целостность программных и технических средств ВУ,
осуществляться
аутентификация
пользователя.
Успешный
результат
проведения проверок позволяет гарантировать, что перед загрузкой ОС не
произошло несанкционированных изменений аппаратной конфигурации,
физических секторов жесткого диска, системного реестра, файлов, и что
загрузка осуществляется именно легитимным пользователем.
Средства доверенной загрузки осуществляют также регистрацию всех
критичных с точки зрения ИБ событий (факт входа пользователя, введение
неправильного кода доступа, идентификационные данные пользователя и
т.д.), что позволяет администратору АБ получать информацию обо всех
попытках доступа к ВУ. Более детально механизм доверенной загрузки ОС
будет рассмотрен далее.
2) Замкнутая (ограниченная) программная среда [55] – механизм,
позволяющий задавать перечень («белый список») разрешенного ПО для
каждого пользователя АС, – также является одним из способов обеспечения
ДВС. Функционал данного механизма позволяет разграничить доступ к
таким критичным и потенциально рискованным компонентам системы, как
исполняемые файлы, скрипты, сценарии и т.д., не соответствующие
определенным требованиям, а также осуществлять управление установкой
нового ПО.
3) «Песочница» [55] – под данным термином подразумевается
изолированная среда исполнения с контролируемыми правами для эмуляции
поведения
потенциально
программные
СЗИ
(к
опасного
ним
также
кода.
можно
Применяемые
отнести
и
для
этого
антивирусы)
функционируют непосредственно в рамках ОС и значительно снижают
вероятность НСД к защищаемым данным. Тем не менее, активно
21
совершенствующиеся в своих навыках и используемых инструментах (в том
числе, использование ошибок в реализации ПО и его настройках) не
позволяют обеспечить необходимый уровень защиты для выполнения
критичных вычислений и хранения данных.
4) Антивирусы и проактивные технологии защиты, построенные на
эвристическом анализе поведения ПО [55,56,57,58]. Технология Host-Based
Intrusion Prevention System (HIPS) не использует сигнатурный поиск по базам
вирусов и относится к средствам проактивной защиты. Не оперируя
понятиями «легитимность» и «вредоносность» относительно файлов, целью
HIPS является разрешить или запретить конкретное действие. Минусом
данной
технологии
является
достаточно
высокая
квалификация
пользователей, необходимая для задействования функционала СЗИ в полно
мере (в том числе, для реализации его обучаемости). По принципу
построения HIPS делятся на два класса. Первый класс – это ПО, обладающее
формируемой таблицей решающих правил, на основе которых выдается
запрет или разрешение на определенное действия приложения. Также к
решению по дальнейшей работе подозрительных приложений такие средства
привлекают и пользователя. Ко второму классу относятся средства HIPS,
осуществляющие анализ работы приложений, по результатам которого
определяется показатель подозрительности или потенциальной опасности
действия объекта, выносится вердикт о присутствии потенциального
вредоносного ПО.
Элементы HIPS-защиты могут быть включены в состав функционала
уже традиционных средств борьбы с вредоносным ПО – например,
антивирусных программ.
1.3 Системы терминального доступа
Реализуя идею построения АС в защищенном исполнении, необходимо
учитывать смещение выбора аппаратной базы в пользу терминальных
решений, наблюдающееся в последние годы в области IT-технологий.
Построенные таким образом системы терминального доступа (СТД)
22
объединяют основные вычислительные ресурсы на группе терминальных
серверов, обеспечивающих выполнение кода бизнес-приложений, а также
предоставляют пользователям АС безопасный доступ к бизнес-приложениям
посредством специальных оптимизированных протоколов [59].
Централизованный принцип архитектуры СТД основан на применении
сетевых технологий, соединяющих серверные компоненты (терминальные
серверы, ТС) и терминальные рабочие станции (Рисунок 1). Назначением ТС
является
предоставление
вычислительных
мощностей
клиентам,
а
терминальная станция – это компактный (в силу возлагаемого на него
функционала) аппаратный клиент, с использованием которого можно
подключаться к ТС, применяя для ввода информации клавиатура и мышь
(коды нажатых клавиш, координаты перемещения), а для получения
информации – монитор и звуковые устройства. При этом все используемое
ПО установлено и функционирует на ТС, там же обеспечивается хранение
данных и выполняется вся вычислительные операции.
Рисунок 1 – Пример использования терминальных систем
23
Применение технологии терминального доступа практически на любом
предприятии, независимо от размера и количества пользователей в
развернутой на нем информационной системе, несет целый ряд преимуществ:
1) Предоставление пользователям доступа к данным и приложениям
независимо от их расположения [60].
2) Облегченное
настраиваемых
администрирование
компонентов
в
(включая
силу
централизованности
возможность
удаленного
подключение к клиентскому рабочему месту).
3) Легкая масштабируемость АС в силу отсутствия необходимости
локальной
установки
и
настройки
ОС,
прикладного
ПО
и
их
конфигурирования при добавлении нового терминала. Проблема нехватки
серверных мощностей решается созданием терминального кластера с
настройкой балансировки нагрузки.
4) Высокая надежность в силу отсутствия локального хранения на
пользовательских рабочих местах. Резервирование данных в таких системах
также реализуется значительно проще, что повышает их сохранность.
5) Повышенный
уровень
безопасности.
Недостаточность
прав
пользователей для установки нового ПО снижает риск заражения рабочей
станции. Отсутствие локально хранящейся конфиденциальной информации
снижает ущерб от возможной кражи терминала до минимума.
6) Упрощенная модернизация
в силу более
низкой стоимости
клиентских терминалов по сравнению с обычными компьютерами. Основные
вложения потребуются только на серверные компоненты. Кроме того, в
качестве клиентского рабочего места можно использовать устаревшие
компьютеры,
поскольку
их
мощностей
будет
достаточно
для
функционирования в рамках терминальной сессии.
7) Экономически
более
выгодное
использование
заниженной стоимости терминальной лицензии.
ПО
в
силу
24
8) Малая чувствительность к пропускной способности сети по причине
небольших объемов передаваемой информации (необходимо порядка
10 KB/сек на терминал).
На основе сказанного можно сделать вывод о экономической
целесообразности применения СТД в организации, характеризующейся
также более высокими показателями по безопасности, надежности и
гибкости по сравнению с обычными АС.
На всем пути существования технологии терминального доступа
используемая в ее контексте терминология изменялась. И если касательно
серверных компонентов особых вопросов не возникает, то в отношении
клиентской части сформировался ряд терминов, которые были или являются
популярными, при этом даже со временем изменяя свое значение: терминал,
терминальный клиент, тонкий клиент, бездисковая станция, сетевой
компьютер. В рамках настоящей исследовательской работы определим, что
будет подразумеваться под данными терминами.
С развитием технологий понятие «терминал» уточнялось: вместо
оконечного
устройства,
предназначенного
для
взаимодействия
с
компьютерной системой, данный термин стал обозначать устройство вводавывода данных. Появившиеся позднее «умный терминал» (smart terminal) или
«толстый клиент» (fat client) позволили выделить группу устройств,
обладающих возможностью обработки большого объёма данных. В свою
очередь, терминал, в значительной степени зависящий от ТС, на котором
осуществляется выполнение всех операции, а также хранение данных,
называется тонким клиентом (thin client) [61].
На сегодняшний день, зачастую «тонкий клиент» понимается в более
широком смысле, нежели аппаратная платформа в рамках СТД, и обозначает
в принципе технологию, в которой основные вычисления производятся на
централизованном сервере, а на клиентскую станцию выводятся результаты
[62]. В англоязычной литературе для этого принят термин «slimcomputing»,
что обозначает «тонкие вычисления». Таким образом, тонкий клиент – это
25
компьютер или программа-клиент в системах с архитектурой «клиентсервер» или терминальной архитектурой, переносящая все либо основную
часть вычислительных задач на ТС.
По мере того, как менялась аппаратная составляющая компонентов АС,
происходили
изменения
и
в
используемых
терминах:
поскольку
терминальная функция является только одной из задач, решать которую
способен терминал, произошла смена названия из терминала в "тонкого
клиента" [63].
В контексте аппаратной платформы под тонкими клиентами, как
правило, понимаются компьютеры, обладающие ограниченным объемом
ресурсов (в т.ч. отсутствуют винчестеры, вентиляторы, мало оперативной
памяти, «слабые» по мощности процессоры) и др. [64]. Часто к данному
термину также относят X-терминалы, бездисковые станции, сетевые
компьютеры и клиенты WinFrame. Данные клиенты отличаются входящими в
их состав как аппаратными, так и программными компонентами (их
количеством
и
мощностью).
Согласно
проведенному
анализу
[65],
перечисленные виды аппаратных клиентов характеризуются следующими
качествами:
1) X-терминалы (устаревший термин) – это сетевые устройства,
функционирующие в среде X Window System (была разработана в 1984 году,
в 1987 – последняя версия). Система X Window System работала в клиентсерверной архитектуре без зависимости от платформы или ОС, передавая
данные по собственному протоколу X;
2) «бездисковая станция» – рабочая станция, в состав которой не
входит
винчестер
(жесткий
диск).
Загрузка
ОС
в
таких
случаях
осуществлялась, как правило, удаленно, но иногда с использование флэшпамяти или ПЗУ;
3) «сетевой компьютер», получивший популярность вместе с развитием
Web-технологий
–
бездисковый
компьютер,
предназначенный
выполнения Java-приложений в среде Internet/Intranet;
для
26
4) WinFrame-клиент – самый «тонкий» из всех «тонких» клиентов,
применяемый в многопользовательской сетевой среде, построенной на
использовании протокола ICA (Independent Computing Architecture). В рамках
данной системы приложения могут выполняться полностью на сервере, при
этом передавая на клиент лишь изменения в изображении. Ввод данных
осуществляется с использованием клавиатуры и мыши.
Таким образом, на основе произведенного обзора, в рамках настоящей
работы под термином «тонкий клиент» будем понимать именно бездисковую
рабочую станцию, входящую в состав СТД в качестве клиентского
компонента. Т.е. в силу его архитектурных особенностей, тонкий клиент
может работать только в состоянии подключения к локальной сети СТД.
Основываясь на удобстве администрирования СТД, наиболее удобным
вариантом загрузки ОС на тонкий клиент является сетевая загрузка с ТС.
Этот способ обеспечивает хорошую масштабируемость, а его настройка
производится централизовано [66]. В этом случае сетевая карта тонкого
клиента
должна
поддерживать
загрузку
с
использованием
сетевых
протоколов.
При включении питания тонкий клиент самостоятельно находит ТС с
запущенной терминальной службой. В соответствии с принятыми в СТД
политиками безопасности, как правило, пользователь доступ к запуску
необходимых приложений в адресном пространстве ТС только после
успешной аутентификации [67]. Также пользователь на любом рабочем месте
в пределах СТД получает возможность работать со своими документами и
программами в соответствии с настроенными правилами доступа. Таким
образом облегчается управление и эффективное распределение ресурсов
клиентских мест.
Необходимо
отметить,
что
применение
именно
бездисковых
аппаратных тонких клиентов экономически более эффективно. Отсутствие в
их составе движущихся частей значительно снижает вероятность поломки.
Технология «холодного процессора» позволяет отказаться от применения
27
системы охлаждения и обеспечивает сверхнизкое энергопотребление, при
этом предоставляя всю необходимую функциональность.
К недостаткам данной технологии терминального доступа при этом
стоит отнести значительно более высокие требования к производительности
и надежности ТС как к единственной точке отказа (хотя в современных СТД
это решается кластером терминальных серверов) [27,68]. В таких системах
нецелесообразно применять ресурсоемкие приложения, однако для задач
стандартного
офиса
терминальные
решения
являются
оптимальным
вариантом.
1.4 Терминальные ОС
В настоящее время активно развиваются IT-проекты, в рамках которых
разрабатываются технологии реализации системы «удалённого терминала»
[69]. Среди основных целей таких технологий – обеспечить реакцию
запускаемых через тонкий клиент программ, сравнимую со временем их
выполнения на локальной системе. К таким проектам относятся FreeNX,
RealVNC, LTSP, Ndiyo, x2go, Neatx и др (Таблица 1).
Таблица 1 – Описание популярных ОС и технологий, применяемых в СТД
Название
Описание
проекта
Некоммерческий проект, в рамках которого свободно
LTSP
(Linux
Terminal
Server
Project) [70]
распространяется дополнительный пакет для Linux;
предназначен для использования в СТД с использованием
сетевой загрузки; на клиентских местах – простейшая ОС,
основанная на X Window System и Linux, подготовленная
заранее в среде chroot на LTSP-сервере. Входит в состав
дистрибутива Edubuntu [71], предназначенного для
применения в образовательных учреждениях.
Skolelinux
[72]
ОС сформирована на основе Debian GNU/Linux и
предназначена для применения в образовательных
учреждениях.
28
Название
проекта
Описание
Свободно распространяемое ПО, основанное на Ubuntu
Linux, предназначенное для использования в СТД, целью
которых является снижение сложности инфраструктуры и
Ndiyo [73]
зависимости от серьезной технической поддержи;
применяются ТК клиентов nivo (network in, video out);
технология получила большое распространение в странах
третьего мира.
Основан на «урезанном» Linux, в состав которого входит ПО,
Thinstation
предназначенное для работы в сети. Размер образа составляет
[74]
десятки Мб, что делает возможным его применения на
устаревшем парке ТК с небольшим объемом памяти.
29
Название
проекта
WTware
[75]
Продолжение Таблицы 1
Описание
ОС, разработанная для ТК с использованием сетевой
загрузки. Применяется, как правило, для подключения по
протоколу RDP (Remote Desktop Protocol).
Windows
Embedded
[76]
Семейство ОС, разрабатываемых Microsoft Windows для
встраивания в специализированные устройства.
Оконная ОС, обеспечивающая базовые функции
X Window
System [77]
графического интерфейса пользователя, взаимодействие с
периферийными устройствами ввода-вывода (последняя
версия была выпущена в 2012 г.). Используется в ОС
семейства Unix.
Как уже было отмечено, для реализации терминального доступа (и в
рамках перечисленных выше проектов, и в остальных случаях) в качестве ОС
для тонких клиентов не подходят стандартные системы, тем более в том
случае, когда используется сетевая загрузка. Терминальные ОС должны
характеризоваться модульной структурой, отсутствием менеджера пакетов,
низкой потребностью в памяти. Также особый акцент ставится на поддержке
сетевых протоколов удаленного доступа.
В итоге для решения поставленной задачи получается следующий
выбор: портативный вариант ОС из семейства Windows, Linux или Android.
Все перечисленные варианты используются в настоящий момент на практике
и обладают рядом преимуществ и недостатков. Системы Android отличаются
в отрицательную сторону большим количеством уязвимостей. Особой
популярностью пользуются именно системы Linux: с учетом минимального
наполнения при сборке дистрибутива под аппаратные ресурсы может
подойти почти любая из семейств ОС: Ubuntu, в том числе, ее портативный
вариант Easy Peasy, Suse, Centos, Mint, Debian или Fedora. Среди
минимальных дистрибутивов распространен DSL (Damn Small Linux). Также
30
есть возможность создать свой собственный дистрибутив – как это позволяет
проект Suse Studio [78].
При таком разнообразии чаще всего дистрибутива, основанного на
Linux, хватает, чтобы обеспечить приверженцев СТД необходимыми ОС, но
необходимо отметить некоторые возникающие при этом проблемы. Одна из
первых сложностей – это используемый в ПО на базе Linux протокол RDP
определенной версии. Дело в том, что применение самой последней версии
клиента RDP под Linux, гарантия поддержки некоторых особенных функций
может оказаться недоступна [79]. В силу того, что разработчики Linux в
конкретном данном вопросе постоянно оказываются в роли догоняющих.
Второй сложностью, с которой можно столкнуться при использовании
на ТК ОС Linux – это драйверы. Поскольку, в зависимости от сферы
применения
ТК,
может
возникнуть
необходимость
добавить
новое
устройство, для которого не разработан драйвер под ОС Linux, владельцы
СТД вынуждены отказаться от бесплатных систем.
Далее приведены наиболее популярные в настоящее время семейства
ОС, применяемые в СТД:
Существующие на рынке готовые аппаратные тонкие клиенты чаще
всего уже содержат либо ориентированы на использование одной или
нескольких терминальных ОС. Ниже (Таблица 2) приведены примеры
выбора производителей в этой области:
Таблица 2 – Представленные на рынке аппаратные тонкие клиенты
Модель тонкого
№ Производитель
ОС
клиента
Собственный
образ
ОС,
Aquarius TCC U30
1 Аквариус
разработанный
на
основе
S24
Windows Embedded Standard 7
2
OPTION
OPTION EASY
Собственная ОС
31
№ Производитель
Продолжение Таблицы 2
Модель тонкого
клиента
ОС
Windows
XP
3
OPTION TOP
4
ТОНК LXBOX
5
ТОНК 1000
Android 4.2.2 и Linux
ТОНК ALT Linux
АЛЬТ ЛИНУКС СПТ 6.0
6
ТОНК
7
Embedded, Linux Embedded
ОС Linux Mint (на основе Ubuntu
12.04 LTS)
ТОНК
TN1902, Linux Embedded и MS Windows
ТОНК
TN1921, Embedded
ТОНК 1500
Microsoft Windows CE 6.0 R3,
АК-Systems
8
АК-Systems
терминал и Linuxтерминал
9
Норма
1.5 Классификация
Microsoft Windows CE 7.0, Linux
Windows-
Norma-TS
типовых
Embedded, Microsoft Windows
XP
Embedded,
Microsoft
Windows Embedded Standard 7
Linux/GTC
уязвимостей
систем
терминального
доступа
Необходимость в реализации требований и механизмов безопасности
при построении СТД спровоцировала создание либо адаптацию для тонких
клиентов многочисленных средств защиты, как программных, так и
аппаратных. Тем не менее, злоумышленники также повышают свою
квалификацию, изобретая новые инструменты и методы, в результате чего
организации, использующие терминальный доступ, подвергаются все более
искусным мошенническим действиям. Киберпреступники продолжают
искать, и весьма успешно, уязвимости в применяемых системах защиты, что
порождает появление новых способов атак [80]. Далее перечислены
ключевые уязвимости самых широко применяемых способов защиты в СТД.
32
1) Установка антивирусного ПО на тонкие клиенты.
Основным слабым местом данного способа является «Проблема
нулевого дня», присущая абсолютно всем антивирусам [81]. Данная
проблема состоит в том, что антивирусные сигнатуры всегда (в силу
архитектуры работы антивирусов) появляются позже, чем появляется или
изменяется непосредственно вирус, что приводит к задержке возможности
его распознать и обезвредить на время выпуска антивирусной компанией
необходимой сигнатуры и обновления пользователем своей базы в
антивирусе.
Данные
задержки
составляют
существенное
время
(до
нескольких суток), что приводит к постоянной угрозе существования на
компьютере
неопознанных,
а,
следовательно,
и
неудаленных
угроз
приватным данным. Кроме того, антивирусы утрачивают свои возможности
по обезвреживанию вредоносного кода в связи с возрастанием вероятности
«целевой атаки» – использования злоумышленниками «персонального»
вредоносного кода, для которого «проблема нулевого дня» существенно
выше (время задержки сигнатур существенно больше).
Дополнительным негативным моментом является тот факт, что
корректность функционирования антивирусных СЗИ основывается на
недоверенной изначально ОС, потенциально имеющей уязвимости и
недекларированные возможности (НДВ). Кроме того, использование в ТК
параллельно с рабочим функционалом ПО, подразумевающего доступ в сеть
Internet (электронная почта, браузеры, мессенджеры и т.д.), значительно
повышает риск заражения вредоносным ПО, особенно в отсутствии культуры
ИБ среди пользователей организации.
Помимо этого, не стоит забывать, что алгоритмы обнаружения,
реализованные в антивирусных СЗИ, являются вероятностными и не
предоставляют полной гарантии обнаружения всех вирусов (особенно в
части того, что относится к технологии rootkit, перехватывающих управление
компьютером еще до загрузки ОС).
2) Защита от логирования данных доступа [82].
33
Под данным механизмом защиты имеется в виду применение таких
инструментов,
как
«виртуальные
клавиатуры»
и
другие
средства
противодействия «клавиатурным шпионам», целью которых является
перехват аутентификационной информации пользователя. Также эти методы
действенны при борьбе с атаками типа bruteforce [81]. Однако постоянно
развивающиеся технологии разработки вирусов учитывают в своей работе
шаги противодействия данным механизмам защиты и учатся их обходить.
3) Шифрование передаваемых данных.
Способ,
шифрования
как
правило,
в
рамках
подразумевает
протокола
применение
SSL/TLS,
алгоритмов
обеспечивающего
аутентификацию сервера и закрытие передаваемой в рамках сессии
информации, что позволяет противостоять ряду несложных атак (перехват
аутентификационных данных, Man-in-the-Middle [82] и т.п.). Однако
параллельно развиваются вектора атаки и на сам протокол, подменяющие
сертификаты корневых удостоверяющих центров на ТК или использующие
уязвимости реализации протокола. Кроме того, постоянным слабым местом в
применении шифрования является наличие момента, когда данные открыты,
чем и пользуются злоумышленники в целях перехвата и модификации
информации.
4) Двухфакторная аутентификация.
Одной из самых распространенных проблем систем терминального
доступа является непроработанная аутентификация пользователей и ПО. К
этому относятся и слабая требования к формированию паролей, и
недостаточная защита от атак bruteforce, и предсказуемый формат
идентификаторов пользователей (либо наличие информации о применяемых
идентификаторах
в
открытом
доступе).
И
хотя
по
отдельности
перечисленные уязвимости не вносят серьезные риски в СТД, их
совокупность часто используется злоумышленником в рамках реализации
других векторов атак.
34
1.6 Протоколы удаленной загрузки операционной системы на тонкие
клиенты
Одной из основных сетевых технологий, применяемая как в СТД, так и
в
обычных
сетевых
вычислительных
системах,
является
удаленное
включение по сети с использованием технологии Preboot Execution
Environment (PXE) [83]. Обычно в рамках этого протокола предусмотрена
загрузка ОС из ROM-памяти, а не с жесткого диска, что позволяет
технологии PXE широко применяться для загрузки ТК. И альтернативным
вариантом использования протокола PXE является загрузка ОС на тонкий
клиент по сети.
В состав технология вошли такие стандартные протоколы PXE, как
TCP/IP, DHCP и т.д. Обычно сетевая карта, входящая в ТК и
поддерживающая PXE, находится в состоянии подключения к сети даже при
выключенном питании клиента, что позволяет при просмотре трафика
обнаруживать особую последовательность, содержащую адрес доступа к
серверу, уникальный для каждого клиента. При получении такого пакета
сетевая карта инициирует включение питания ТК (в BIOS при этом должен
быть установлен флаг, разрешающий удаленное включение по сети).
При включении ТК сетевая карта переходит в активное состояние и
происходит
конфигурация.
обеспечиваться
Для
поддержи
протокола
PXE
соответствующая
серверная
инфраструктура.
должна
Процесс
загрузка ТК по данному протоколу осуществляется следующим образом
(Рисунок 2):
35
Сетевая плата прослушивает трафик
локальной сети на предмет наличия
определенных последовательностей данных
Сетевая плата фиксирует в передаваемых
данных нужный пакет и подает питание на
тонкий клиент через разъем питания на
системной плате
Клиент PXE запрашивает IP-адрес у DHCP
или прокси-сервера
DHCP передает имя загрузочного файла
PXE запрашивает файл с сервера загрузки
Рисунок 2 – Процесс загрузки ОС по протоколу PXE
Параллельно с коммерческой технологией PXE развивается проект со
свободно распространяемым исходным кодом Etherboot (или gPXE), также
обеспечивающий сетевую загрузку ОС на ТК [84]. Загрузчик gPXE также
может располагаться на жестком диске, usb-носителе или в BIOS (PXE
располагается именно в микропрограмме сетевой карты) и помимо
перечисленных осуществляет поддержку сетевых протоколов FTP, HTTP и
NFS. При обращении к серверу загрузчик gPXE запрашивает доступ к
хранящимся там ОС, скачивает необходимый образ и загружает его в
оперативную память ТК. На сервере при этом могут храниться различные
дистрибутивы семейства Linux-дистрибутивов. В частности, Etherboot
осуществляет поддержку следующих ОС: Debian Lenny, Debian Testing,
Fedora, OpenSUSE, Ubuntu Jaunty, Ubuntu Karmic, FreeBSD 7.2, MirOS bsd4me
current (создана на базе Open и NetBSD) и др. [85].
36
1.7 Постановка задачи
Механизмы
построения
доверенных
систем постоянно
должны
адаптироваться под те аппаратные платформы и конфигурации, на базе
которых и создаются АС. Как мы можем наблюдать, для вычислительных
систем,
основу
которых
составляют
полноценные
рабочие
станции
(компьютеры), реализующие практический весь необходимый функционал
локально, на сегодняшний день создано значительное число способов
построения ДВС. Кроме того, выпущен ряд стандартов по ИБ, позволяющих
поддерживать необходимую степень доверия к такой системе на протяжении
всего её жизненного цикла.
Однако для систем терминального доступа, компонентами которых
являются тонкие клиенты и терминальные серверы, значительная часть
разработанных методов построения ДВС не подходит в силу именно
архитектурной составляющей. При этом нельзя говорить, что никакие из
сформированных практик ИБ не применимы к таким системам –
значительная
часть
способов,
программном
уровне,
которые
способны
работают
частично
исключительно
обеспечить
на
операционную
гарантированность в части реализации выбранной политики ИБ. Замкнутая
программная среда, «песочница», антивирусы и проактивная защита – для
всего этого уже есть разработанные и зарекомендовавшие себя средства
защиты либо встроенные механизмы ОС.
Таким образом, основной задачей является повышение степени доверия
к вычислительной базе тонких клиентов путем разработки ориентированных
на соответствующую аппаратную платформу алгоритмов и методов
построения ДВС. Учитывая, что в качестве основного способа загрузки ОС в
терминальных системах используется загрузка по сети с сервера, то особый
акцент в разрабатываемых методах должен быть сосредоточен на способах
контроля целостности загружаемого образа и на тех механизмах, которые
отрабатываются на тонком клиенте до момента передачи управления в ОС.
37
1.8 Выводы к первой главе.
В первой главе рассмотрена концепция доверенной вычислительной
среды и приведено обоснование значимости компонентов, реализующих её в
современных
информационных
системах.
Также
проведен
анализ
существующих методов повышения степени доверия к ВС в различных
аппаратных платформах и механизмов, которые используются в рамках
таких
методов.
Для
выбранных
в
качестве
основного
объекта
диссертационного исследования систем терминального доступа определены
основные функциональные характеристики, в том числе, для аппаратного
тонкого клиента, являющегося составным компонентом таких систем. С
учетом выделенных характеристик классифицированы типовые уязвимости,
характерные для систем терминального доступа, в том числе, в реализации
применяемых механизмов защиты информации.
2
Глава. Классификация угроз информационной безопасности данных,
обрабатываемых на тонких клиентах
2.1 Построение модели нарушителя и классификация угроз
Цели безопасности, преследуемые при построении ДВС на тонких
клиентах должны учитывать применяемую в организации политику
безопасности. Все компоненты, которые участвуют в процессе построения
ДВС, должны соответствовать определенным функциональным требованиям
и иметь соответствующую степень доверия, что должно учитываться при
формировании перечня требований ИБ.
Так как обеспечение доверенной удаленной загрузки образа ОС с
терминального сервера на тонкий клиент является основополагающим
механизмом для построения ДВС, требуется идентифицировать возможные
опасности, угрожающие данному процессу [86]. Необходимо понимать, что
при подготовке данной классификации угроз должны быть учтены все риски,
реализация которых возможна исходя из проектируемой модели нарушителя.
38
Согласно нормативным документам ФСТЭК [91,93], классификация
угроз безопасности защищаемой информации – это совокупность условий и
факторов, создающих опасность несанкционированного, в том числе
случайного, доступа к защищаемым данным, формируемая с учетом
характеристик ИС, свойств среды (пути) распространения информативных
сигналов, содержащих защищаемые данные, и возможностей источников
угрозы.
Формирование такой классификация угроз ИБ в рамках процесса
обработки на ТК позволяет сформировать набор требований и защитных мер,
направленных на нейтрализацию выявленных уязвимостей. В итоге этот
процесс позволяет спроектировать соразмерную (неизбыточную) системы
защиты, обеспечивающей в нужной степени безопасность процесса загрузки
данных с сервера на тонкие клиенты и дальнейшую с ними работу [87,88].
Необходимость построения и анализа классификации угроз также
следует из требований различных нормативно-правовых актов, касающихся
построения защищенных АС. Среди документов, регламентирующих
процессы
обработки
данных
с
соответствующим
уровнем
конфиденциальности в СТД, особое место занимают ГОСТ Р 51583 «Защита
информации. Порядок создания автоматизированных систем в защищенном
исполнении. Общие положения» [89] и ГОСТ Р 51624 «Защита информации.
Автоматизированные системы в защищенном исполнении» [90].
Необходимо заметить, что общий перечень потенциальных угроз ИБ
различной категории защищаемых данных, на основе которого может быть
сформирована итоговая классификация, также приводится как в российских
нормативно-правовых актах, регламентирующих порядок построения защиты
АС [91,92,93], так и в международных стандартах, посвященных анализу
рисков, связанных с автоматизированной обработкой информации [94,95].
Однако на практике часто можно наблюдать, что исходный перечень угроз
оказывается не полным и не в полной мере соответствует активно
развивающимся
IT-технологиям.
В
силу
чего
задача
построения
39
классификации угроз защищенности данных, обрабатываемых на тонком
клиенте (в том числе образа ОС, загружаемого по сети с сервера),
представляется актуальной и требует детального рассмотрения в рамках
построения защищенной СТД.
2.1.1 Состав работ по проведению анализа нарушителя и угроз ИБ
Анализ угроз ИБ данных, обрабатываемых на ТК (в том числе
загружаемого образа ОС) осуществляется в рамках 3 этапов [93]:
1) Построение модели нарушителя.
Для всех процессов обработки информации в СТД разрабатывается
модель нарушителя. При этом учитываются особенности функционирования
системы на протяжении всего жизненного цикла, категории физических лиц,
которым предоставлен санкционированный доступ к ресурсам системы с
соответствующими правами [91,96]. При разработке модели нарушителя
рассматриваются возможные внутренние нарушители (в основном –
сотрудники организации), и внешние - инсайдеры (злоумышленники,
получившие доступ к СТД извне).
2) Построение
классификации
угроз
безопасности
данных,
обрабатываемых в СТД.
В качестве основных угроз рассматриваются нарушения целостности
(особенно
в
отношении
загружаемого
образа
ОС)
и
доступности
передаваемых данных, которые могут привести к нарушениям как режима
работы пользователя системы, так и ее качества в условиях отсутствия
доверенной среды исполнения критичных вычислений.
Классификация угроз безопасности информации включает выделение
внутренних,
внешних,
воздействующих
на
объективных
защищаемые
и
данные.
субъективных
факторов,
Анализ
для
угроз
СТД
осуществляется с учетом всех возможных их форм проявления – от
несанкционированного использования информационных ресурсов до явлений
техногенного характера [97]. После проведения анализа угроз для каждой из
них приводятся ожидаемые последствия с точки зрения нарушения свойств
40
информации (доступность, целостность). Нарушение свойств информации
рассматривается в контексте последствий осуществления угрозы для
критичных ресурсов.
Для каждой угрозы указываются категории нарушителей, создающих
данную угрозу или имеющих возможность ей воспользоваться, а также
превентивные и восстановительные меры по предотвращению угрозы и
последствий осуществления угрозы.
3) Соотношение классификации угроз с моделью нарушителя ИБ.
На данном этапе происходит соотношение выявленных на предыдущих
этапах нарушителей и угроз ИБ. Таким образом формируется матрица,
определяющая всевозможные пары (угроза, нарушитель, объект атаки) и
характеризующая соответствующие вектора атак.
2.1.2 Модель нарушителя
Целью построения модели нарушителя является получение важнейших
свойств о потенциальных для рассматриваемой системы нарушителях.
В рамках процесса моделирования будем использовать следующие
предположения:
1. Нарушитель – это физическое лицо или группа лиц.
2. Нарушитель
обладает
возможностями
осуществить
несанкционированные действия.
3. Нарушитель обладает желанием совершить несанкционированные
действия или существует ненулевая вероятность совершить такие действия
случайно или по незнанию.
На основе сделанных предположений опишем исходные данные для
моделирования.
Пусть
𝐻𝐻внут ⊂ 𝐻𝐻
и
𝐻𝐻внеш ⊂ 𝐻𝐻, 𝐻𝐻внеш ∪ 𝐻𝐻внут = 𝐻𝐻 –
множества внутренних и внешних нарушителей, при этом 𝐻𝐻внеш ∩ 𝐻𝐻внут = ∅.
Каждому нарушителю ставится в соответствие потенциал 𝑃𝑃 н𝑗𝑗 ∈ 𝑃𝑃 н (𝑗𝑗 =
1,2,3), и полномочия 𝐴𝐴н 𝑘𝑘 ∈ 𝐴𝐴н (𝑘𝑘 = 1,2, … ,5). Для обеспечения адекватности
модели определим соответствующие множества значений потенциала и
41
полномочий. Потенциал нарушителя может принимать следующие значения:
𝑃𝑃н = {0, 1, 2}, где
0 – соответствует низкому потенциалу,
1 – среднему,
2 – высокому.
Полномочия нарушителя принимают следующие значения: 𝐴𝐴ℎ =
{0,1 ,2,3,4 }, где
0 – соответствует отсутствию каких-либо полномочий для доступа к
защищаемым активам,
1 – наличию полномочий доступа к компонентам ИС, но без
полномочий доступа к информационным активам,
2 – наличие полномочий непривилегированного пользователя ИС (с
доступом к информационным активам и СЗИ в соответствии с принятой
моделью доступа),
3 – отсутствие полномочий доступа к защищаемым информационным
активам при наличии полномочий привилегированного пользователя к
программным/аппаратным средствам, в т.ч. СЗИ,
4 – наличие полномочий привилегированного пользователя ИС (с
доступом к информационным активам и СЗИ в соответствии с принятой
моделью доступа).
Определение пары (𝑃𝑃н𝑗𝑗 , 𝐴𝐴н 𝑘𝑘 ) для каждого из рассматриваемых
нарушителей позволяет получить результат моделирования.
Сформируем перечень потенциальных нарушителей ИБ в СТД и
определим их потенциал и возможности (Таблица 3).
Таблица 3 – Соответствие базовой модели нарушителя с организационноштатной структурой
Потенциал
полномочия,
(0,0)
Описание нарушителя
Внешние субъекты (физические лица), бывшие
работники
Идентификатор
Н1
42
Продолжение Таблицы 3
Потенциал
ИдентиОписание нарушителя
полномочия,
фикатор
Преступные группы (криминальные структуры),
(1,0)
Н2
конкурирующие организации
(2,0)
Спецслужбы иностранных государств
Н3
Лица, обеспечивающие функционирование
информационных систем или обслуживающие
инфраструктуру оператора (администрация,
(0,1),
охрана, уборщики и т.д.), имеющие
(1,1),
санкционированный доступ к аппаратным
компонентам СТД, но не имеющие доступа к
(2,1)
обрабатываемой информации и ПО; полномочия
Н4
конкретных лиц распределяются в соответствии с
принятой в организации моделью доступа
Зарегистрированные пользователи СТД,
(0,2), (1,2), осуществляющие удаленный доступ к
обрабатываемой информации с использованием
(2,2)
ТК;
Разработчики и лица, обеспечивающие поставку,
сопровождение и ремонт технических средств,
(0,3),
входящих в состав СТД
Н5
(1,3),
Программисты-разработчики (поставщики)
(2,3)
прикладного ПО и лица, обеспечивающие его
сопровождение
Зарегистрированные пользователи СТД с
(1,4),
Н6
полномочиями администратора информационной
(2,4)
безопасности / системного администратора СТД;
В процессе построения модели нарушителя были определены: цель,
предпосылки и предположения, исходные данные, результат и описано
преобразование исходных данных в результат. Таким образом, можем
считать модель адекватной, универсальной, точной и экономичной.
2.1.3 Классификация угроз
Для классификации угроз безопасности информации, обрабатываемой
на тонких клиентах, в качестве базовых параметров применялись параметры
методик ФСТЭК и ФСБ [93,98,99]. На основе приводимой систематизации
43
рассматриваемые угрозы ИБ классифицируются таким образом (Рисунок 3)
[100,101]:
Параметры
классийикации угроз
ИБ:
по видам возможных источников угроз ИБ
по объекту воздействия
по виду нарушаемого свойства
по используемой уязвимости
по способу реализации угроз ИБ
Рисунок 3 – Параметры классификации угроз ИБ
В качестве параметра «объект воздействия», определяющего вектор
угрозы, в рамках данной работы определены следующие компоненты СТД,
задействованные в процессе обработки информации:
− тонкий клиент (в том числе, энергонезависимое постоянное
запоминающее устройство (ПЗУ), содержащее загрузчик, BIOS);
− канал передачи данных;
− сетевое и коммутационное оборудование.
Необходимо
отметить,
что
терминальный
сервер,
являющийся
источником загружаемого образа ОС, в рамках настоящей классификации не
рассматривается как объект угрозы. В качестве исходных условий установим,
что сервер, как и сетевое и коммутационное оборудование, расположены в
защищенной контролируемой зоне (КЗ). Помимо этого, не учитываются
угрозы, нацеленные на перехват ПЭМИН и данных по акустическим каналам
в силу принимаемых в организации, владеющей СТД, организационнотехнических мер, регламентирующих доступ в КЗ, а также отсутствие
голосового ввода и воспроизведения защищаемой информации. В
В силу структурно-функциональных характеристик терминальных
систем
угрозы
безопасности
образа
ОС,
создаваемые
вредоносной
программой, загруженного на тонкий клиент в процессе сеанса работы
пользователя, не представляются актуальными. Все изменения, потенциально
вносимые при этом в ОС, не загружаются обратно на сервер: при каждом
44
новом сеансе работы пользователь загружает на тонкий клиент неизменный
образ с осуществленными администратором настройками и правами доступа.
Угрозы конфиденциальности загружаемого по сети образа ОС (утечки,
перехвата,
съема,
копирования,
хищения,
разглашения)
в
рамках
рассматриваемой классификации не представляются актуальными: сам по
себе
образ
не
содержит
никакой
конфиденциальной
информации
(персональные/аутентификационные данные и др.).
В рамках построения данной классификации актуально следующее
определение угроз, связанных с НСД [91]: это угрозы, представляемые в виде
совокупности обобщенных классов возможных источников угроз НСД,
уязвимостей программного и аппаратного обеспечения СТД, способов
реализации угроз, объектов воздействия и возможных деструктивных
действий. По отношению к защищаемым данным, обрабатываемым на
тонком клиенте, формальное описание угрозы НСД в рамках представленной
классификации может быть представлено в виде связи следующей блок
схемы (см Рисунок 4):
45
Способ
реализации
угрозы
Уязвимость
компонентов
СТД
Источник
угрозы
Нарушитель
Внешний
Внутренний
Программноаппаратная
закладка
Конструктивно
втроенная
Автономная
Использование
существующих уязвимостей
компонентов СТД,
позволяющих:
Уязвимости ПО
Уязвимости BIOS,
Прошивок
Деструктивно
воздействовать на СЗИ
Уязвимости ОС
Вскрывать или
перехватывать пароли
В процессе
инициализации
Использовать уязвимости
сетевых протоколов и
каналов передачи данных
В незащищенном
режиме работы
процессора
Перехватывать и
модифицировать
образ ОС
Уязвимости, вызванные
программноаппаратными закладками
Уязвимости, вызванные
недостатками оргмер по
защите информации
BIOS
ПЗУ, содержащее
загрузчик ООС
В средствах обработки и
хранения оперативной
информации
В ОЗУ
В кеш-памяти, в
буферах ввода/
вывода
В ОЗУ
подключаемых
устройств
Вызывать отказ в
обслуживании
ресурсов СТД
Уязвимости сетевых
протоколов и каналов
передачи данных
Получать удаленный
НСД к ОС
Внедрение новых
уязвимостей в СТД на этапе
проектирования, разработки
и сопровождения
Деструктивное
действие
Тонкий клиент
Обходить СЗИ
Уязвимости
драйверов
аппаратных средств
Уязвимости
компонентов СТД в
результате сбоев в
работе, отказов
Объект
воздействия
Информация в средствах,
реализующих сетевое
взаимодействие, и каналах
данных в сети
В маршрутизаторах
Нарушение целостности
(уничтожение,
модификация,
дезинформация)
Воздействие на
микропрограммы и драйверы
устройств, обеспечивающих
загрузку ОС и СЗИ и их
функционирование
Воздействие на средства
управления и конфигурации
сети
Внедрение программноаппаратной закладки
Воздействие на СЗИ
Нарушение доступности
Нарушение функционирования
и отказы компонентов СТД (в
том числе, каналов передачи
данных)
Нарушение и отказы в
функционировании СЗИ
В других устройствах
коммутации
Уязвимости СЗИ
Рисунок 4 – Формальное представление угрозы НСД к обрабатываемой на
тонком клиенте информации
2.1.4 Угрозы безопасности образа ОС, загружаемого на тонкий клиент
Сформированный на основе приведенной выше классификации
перечень угроз информации, обрабатываемой на тонком клиенте, а также
сопоставление данных угроз с соответствующей категорией нарушителя
приведены ниже (Рисунок 5-8).
46
МПО
BIOS/UEFI
Угрозы микропрограммному и аппаратному
обеспечению:
модификации, изменения версии, аппаратного
сброса пароля BIOS
загрузки нештатной операционной системы
изменения режимов работы аппаратных
элементов компьютера
Н6
Н4
Н6
программного выведения из строя средств
хранения, обработки и (или) ввода/вывода/
передачи информации
Н2,
Н5
сброса состояния оперативной памяти путем
перезагрузки средств вычислительной
техники
Н4,
Н5,
Н6
изменения компонентов системы
физического устаревания аппаратных
компонентов
Н4
Н4
НИ
Аппаратное
обеспечение
Системное
ПО
Прикладное
ПО
ИС
Учётные
данные
пользователя
Сетевое ПО
СЗИ
Угрозы аутентификационной информации:
Н1,
Н4
восстановления аутентификационной
информации
Н2,
Н4
использования информации идентификации/
аутентификации, заданной по умолчанию
Н1,
Н4
несанкционированного изменения
аутентификационной информации
Н1,
Н4
Н1,
Н4
Н1,
Н4
несанкционированного доступа к
аутентификационной информации
обхода некорректно настроенных механизмов
аутентификации
удаления аутентификационной информации
Объекты ФС
Реестр
Рисунок 5 – Угрозы безопасности информации, обрабатываемой на тонком клиенте – Часть 1
47
Угрозы, основанные на некорректной/недостаточной
проверке входных данных:
использования альтернативных путей доступа
к ресурсам
использования слабостей кодирования
входных данных
некорректного использования функционала
программного обеспечения
неправомерного/некорректного
использования интерфейса взаимодействия с
приложением
сбоя в работе системы вследствие подачи на
входные интерфейсы данных
неподдерживаемого формата
Н1,
Н4
Н2,
Н5
Н2,
Н5
Н2,
Н5
Н2,
Н5
МПО
Угрозы в отношении системного и прикладного ПО:
Реестр
Н1,
Н4
использования механизмов авторизации для
повышения привилегий
Объекты ФС
Н1,
Н4
несанкционированного создания учётной
записи пользователя
Н1,
Н4
подделки записей журнала регистрации
событий
Сетевой узел
Системное
ПО
Прикладное
ПО
Сетевое ПО
Аппаратное
обеспечение
ИС
СЗИ
Объекты ФС
Учётные
данные
пользователя
Н1,
Н4
Н2,
Н5
Н3,
Н6
несанкционированного редактирования
реестра
повышения привилегий
анализа криптографических алгоритмов и их
реализации
Н1,
Н4
внедрения вредоносного кода, приводящего к
другим угрозам
Н2,
Н5
перебора всех настроек и параметров
приложения
Н4
Н3,
Н5
–
деструктивного изменения конфигурации/
среды окружения программ
наличия механизмов разработчика
нарушения технологического/
производственного процесса из-за временных
задержек, вносимых СЗИ
Рисунок 6 – Угрозы безопасности информации, обрабатываемой на тонком клиенте – Часть 2
48
Угрозы в отношении сетевых взаимодействий:
использования слабостей протоколов
сетевого/локального обмена данными
неправомерных действий в каналах связи
несанкционированного доступа к активному и
(или) пассивному сетевому оборудованию из
сети
обнаружения открытых портов и
идентификации привязанных к нему сетевых
служб
обнаружения хостов
определения типов объектов защиты
определения топологии вычислительной сети
передачи данных по скрытым каналам
перехвата данных, передаваемых по
вычислительной сети
Н1,
Н4
Н1,
Н2,
Н3
Н2,
Н5
Н1
Н1
Н1
Н1
Н2,
Н5
Н1
Системное
ПО
МПО
Сетевой узел
Сетевое ПО
Сетевой
трафик
Прикладное
ПО
Аппаратное
обеспечение
ИС
Н1
подмены содержимого сетевых ресурсов
Н1
подмены доверенного пользователя
(«имитация действий клиента»)
Н2
Н2
подмены субъекта сетевого доступа
получения предварительной информации об
объекте защиты
Н1,
Н4
усиления воздействия на вычислительные
ресурсы пользователей при помощи сторонних
серверов
Н1
скрытного включения вычислительного
устройства в состав бот-сети
Н1
перехвата одноразовых паролей в режиме
реального времени
Н4
Н1
заражения компьютера при посещении
неблагонадёжных сайтов
«фишинга»
Рисунок 7 – Угрозы безопасности информации, обрабатываемой на тонком клиенте – Часть 3
49
Угрозы специального воздействия:
Угрозы защищаемой информации:
доступа к защищаемым файлам с
использованием обходного пути
несанкционированной модификации
защищаемой информации
несанкционированного копирования
защищаемой информации
несанкционированного удаления защищаемой
информации
повреждения системного реестра
несанкционированного восстановления
удалённой защищаемой информации
утраты носителей информации
форматирования носителей информации
Н1,
Н4
Реестр
Н1,
Н4
Объекты ФС
Н1,
Н4
Аппаратное
обеспечение
Н1,
Н4
Н1,
Н4
Н1,
Н4
Н4
Н1,
Н4
НИ
Линии связи
Все активы
Все активы,
доступ к
которым
есть у
сотрудников
Н2,
Н4
Н1,
Н2,
Н4
физического выведения из строя средств
хранения, обработки и (или) ввода/вывода/
передачи информации
хищения средств хранения, обработки и (или)
ввода/вывода/передачи информации
неправомерного ознакомления с защищаемой
информацией путём просмотра информации с
экранов мониторов других пользователей и др.
механического повреждения линий связи
Н4, Н5,
между серверными и клиентскими
Н6
компонентами СТД
Н1,
Н2,
остальных видов специального воздействия
Н3
Н4
Угрозы со стороны персонала или непосредственно на
персонал:
подмены действия пользователя с помощью
методов социальной инженерии или
Н2
технических методов
Н2, Н4,
Н5, Н6
физического воздействия на сотрудников
Н4, Н5,
Н6
передачи конфиденциальной информации
третьим лицам со злым умыслом
Н4, Н5,
Н6
неумышленного действия пользователя
Рисунок 8 – Угрозы безопасности информации, обрабатываемой на тонком клиенте – Часть 4
50
2.2 Формирование перечня требований, необходимых для выполнения
при построении доверенной вычислительной среды
Исходя из мировых практик проектирования защитных систем, процесс
формирования требований для реализации построения ДВС на тонких
клиентах должен включать следующие этапы [32]:
1) принятие решения о необходимости обеспечения ИБ;
2) построение модели нарушителя и классификации угроз ИБ;
3) определение требований ИБ для обеспечения ДВС на основе
построенных моделей.
Таким
образом,
сформулировать
по
перечень
результатам
требований
обеспечивает защиту от наибольшего
второго
к
этапа
необходимо
ДВС, выполнение
количества
которых
актуальных
угроз
безопасности данных на тонких клиентах и повышает степень доверия
безопасности вычислительной среды. При этом необходимо отталкиваться от
функционала, который должна выполнять ДВС. К такому функционалу
относятся следующие пункты:
1. Обеспечение повышенного уровня защиты особо критичной, в том
числе, ключевой информации (включая защиту от копирования);
2. Разграничение прав доступа к загрузке ОС;
3. Разграничение прав доступа к обрабатываемым данным;
4. Контроль аутентичности данных, поступающих на тонкий клиент;
5. Обеспечение целостности кода ОС и применяемого ПО (в том числе
СЗИ);
6. Обеспечение замкнутой программной среды;
7. Наличие интерфейса взаимодействия с недоверенной средой.
В качестве исходного списка требований целесообразно использовать
требования Руководящего документа Гостехкомиссии в части построения АС
[43], поскольку данные требования широко используются на протяжении
многих лет при разработке средств защиты, на соответствие им проводятся
аттестация АС и сертификация СЗИ.
51
Следует
отметить,
что
были
выбраны
требования
к
автоматизированным системам поскольку для определения степени доверия
к вычислительной среде необходимо рассматривать свойства, присущие
автоматизированной системе (Таблица 4). Например, для полноты моделей
необходимо рассматривать пользователя.
Для определения необходимого к реализации списка требований
определим соответствующие веса, оставив при этом только те требования,
которые влияют на формирование доверия к вычислительной среде. Считаем,
что чем более широко применяется требование, тем его вес выше. Затем
нормируем полученные значения.
52
Таблица 4 – Требования, необходимые предъявляемые к АС, для обеспечения доверия к ВС
Классы АС
Вес
Подсистемы и требования
1Д 1Г 1В 1Б 1А 2Б 2А 3Б 3А 𝐰𝐰
1. Подсистема управления доступом
1.1. Идентификация, проверка подлинности и контроль доступа
субъектов:
− в систему
+
+
+
+ +
+
+ +
+ 0.11
− к терминалам, ЭВМ, узлам сети ЭВМ, каналам связи, внешним
+
+
+ +
+
- 0.06
устройствам
− к программам
+
+
+ +
+
- 0.06
1.2. Управление потоками информации
-
-
+
+
+
-
+
2.1. Регистрация и учет событий ИБ
+
+
+
+
+
+
+
+
+
0.11
2.3. Очистка освобождаемых областей оперативной памяти ЭВМ и
внешних накопителей
-
+
+
+
+
-
+
-
+
0.07
2.4. Сигнализация попыток нарушения защиты
-
-
+
+
+
-
-
-
-
0.04
+
+
0.05
2. Подсистема регистрации и учета
3. Криптографическая подсистема
+
0.04
4.1. Обеспечение целостности программных средств и
обрабатываемой информации
+
+
+
+
+
+
+
+
+
0.11
4.2. Физическая охрана средств вычислительной техники (СВТ) и
носителей информации
+
+
+
+
+
+
+
+
+
0.11
4.3. Наличие администратора защиты информации в АС
-
-
+
+
+
-
+
-
-
0.05
53
Подсистемы и требования
4.4. Периодическое тестирование СЗИ НСД
+
+
+
4.5. Наличие средств восстановления СЗИ НСД
+
+
+
Продолжение Таблицы 4
Вес
Классы АС
𝐰𝐰
+
+
+
+
+
+
0.11
+
+
+
+
+
+
0.11
Очевидно, что для обеспечения перечисленного функционала на тонких клиентах необходимо наличие комплекса
механизмов ИБ, позволяющих реализовать каждое требование, что в итоге обеспечит построение ДВС.
Для защищенной обработки особо критичной информации уже достаточно давно применяются отдельные
специализированные устройства, самостоятельно реализующие криптографические алгоритмы – токены и смарт-карты.
При этом разграничение доступа к зашифрованным контейнерам, хранящимся в памяти таких носителей,
осуществляется, как правило, с помощью PIN-кода. Защита от модификации реализуемых такими устройствами
алгоритмов обеспечивается на аппаратном уровне производителями и подтверждается соответствующей сертификацией.
Для обеспечения разграничения прав доступа к обрабатываемым данным, реализации механизма замкнутой
программной среды, обеспечения целостности ПО и безопасного взаимодействия с недоверенной средой на рынке
средств защиты в настоящее время достаточно полно представлены классы средств, как отечественных, так и
зарубежных, в том числе, имеющих сертификаты регуляторов ИБ. К таким средствам относятся и средства защиты от
несанкционированного доступа (Secret Net, Dallas Lock), и антивирусы, и хостовые системы обнаружения вторжений
(HIPS). Все перечисленное является программными средствами и функционирует поверх ОС независимо от наличия
жесткого диска в аппаратной конфигурации рабочей станции.
54
Определим выполнимость необходимых требований для аппаратных ТК существующими средствами и
механизмами ИБ (Таблица 5), а также весовые коэффициенты указанных требований (Таблица 6):
Таблица 5 – Степень реализации предъявляемых требований для ТК
Степень
Подсистемы и требования
реализации
Пояснение
1. Подсистема управления доступом
1.1. Идентификация, проверка
подлинности и контроль доступа
субъектов:
− в систему
+
Требование реализуется после загрузки образа на ТК и
передачи управления на ОС
− к терминалам, ЭВМ, узлам сети ЭВМ,
каналам связи, внешним устройствам
ЭВМ
-
Нет возможности идентифицировать субъекта до
загрузки ОС
− к программам
+
1.2. Управление потоками информации
+/-
Требование реализуется после загрузки образа на ТК и
передачи управления на ОС
Реализовано только для информационных потоков,
возникающих после загрузки образа на ТК и передачу
управления на ОС
55
Подсистемы и требования
Продолжение Таблицы 5
Степень
реализации
Пояснение
+/-
Реализовано только для событий ИБ, возникающих
после загрузки образа на ТК и передачу управления на
ОС
2. Подсистема регистрации и учета
2.1. Регистрация и учет
2.3. Очистка освобождаемых областей
оперативной памяти ЭВМ и внешних
накопителей
+
2.4. Сигнализация попыток нарушения
защиты
+/-
3. Криптографическая подсистема
+/-
Реализуется существующими механизмами ИБ
Реализовано только для событий ИБ, возникающих
после загрузки образа на ТК и передачу управления на
ОС
При
необходимости
реализации
механизмов
криптографической
подсистемы
возможно
использование либо сетевых аппаратных устройств,
либо программных СКЗИ, функционирующих в
рамках ОС
56
Подсистемы и требования
4. Подсистема обеспечения целостности
4.1. Обеспечение целостности
программной среды и СЗИ НСД и
обрабатываемой информации
4.2. Физическая охрана средств
вычислительной техники и носителей
информации
4.3. Наличие администратора (службы)
защиты информации в АС
4.4. Периодическое тестирование СЗИ
НСД
4.5. Наличие средств восстановления СЗИ
НСД
Степень
реализации
+/-
Продолжение Таблицы 5
Пояснение
Механизмы ИБ не позволяют проверить целостность
загружаемого по сети на ТК образа ОС. Целостность
программных средств (в том числе СЗИ)
гарантируется механизмами, функционирующими в
рамках ОС
+
+
Механизмы ИБ не зависят от аппаратной платформы
+
+
Степень реализации со значением «+/-» обозначает, что часть требований реализуется механизмами ИБ,
функционирующими в рамках ОС. Но в силу того, что гарантия корректности работы таких механизмов основывается на
доверии к той среде, в которой они работают (т.е. к ОС), нельзя быть уверенными в необходимом качестве реализации
соответствующих политик. По этой причине считаем, что данные требования не выполняются.
57
Таблица 6 – Весовые коэффициенты требований
Требование
Идентификация, проверка подлинности и контроль доступа субъектов в систему
Идентификация, проверка подлинности и контроль доступа субъектов к
программам
Очистка освобождаемых областей оперативной памяти ЭВМ и внешних
накопителей
Физическая охрана средств вычислительной техники и носителей информации
Наличие администратора защиты информации в АС
Периодическое тестирование СЗИ НСД
Выполнимость, 𝑅𝑅исх.𝑖𝑖
Регистрация и учет событий ИБ
Сигнализация попыток нарушения защиты
Криптографическая подсистема
Обеспечение целостности программных средств и обрабатываемой информации
0,11
0,05
Требования в полной мере
реализуются
существующими СЗИ:
𝑅𝑅исх.𝑖𝑖 = 1
Наличие средств восстановления СЗИ НСД
Управление потоками информации
Вес,
𝑤𝑤𝑖𝑖
0,06
0,11
0,05
0,11
0,11
Механизмы ИБ, реализующие
данные требования,
функционируют в рамках ОС;
доверие к ним определяется
доверием к ОС; СЗИ,
реализующих доверенную
загрузку на ТК не
представлено: 𝑅𝑅исх.𝑖𝑖 = 0
0,05
0,11
0,04
0,04
0,11
58
Требование
Идентификация, проверка подлинности и контроль доступа субъектов к
терминалам, ЭВМ, узлам сети ЭВМ, каналам связи, внешним устройствам ЭВМ
Продолжение Таблицы 6
Вес,
Выполнимость, 𝑅𝑅исх.𝑖𝑖
𝑤𝑤𝑖𝑖
Механизмов ИБ,
обеспечивающих реализацию
требования для ТК, не
представлено: 𝑅𝑅исх.𝑖𝑖 = 0
0,05
Таким образом, можно сделать вывод, что согласно определенным весовым коэффициентам требований по
формированию степени доверия к ВС на ТК, на сегодняшний день доля реализованных составляет только 60%: 𝑇𝑇𝑇𝑇исх =
0,6. С учетом полученных данных был сформирован список актуальных требований ИБ, которые должны выполняться
разработанными в рамках настоящего исследования алгоритмами и методами.
2.3 Выводы ко второй главе
Во второй главе приведены разработанные базовые модель нарушителя и классификация угроз безопасности
информации, обрабатываемой в системах терминального доступа, с учетом специфики используемых аппаратных
платформ и процесса сетевой загрузки ОС на ТК. Сформирован перечень требований, необходимых для выполнения при
обеспечении соответствующей степени доверия к ВС в рассматриваемых системах.
59
3
Глава.
Алгоритмы
и
методы
формирования
доверенной
вычислительной среды на тонких клиентах
Для обеспечения ДВС на тонких клиентах необходимо разработать
метод,
поэтапно
включающую
механизмов
ИБ
согласно
механизмам
относится
реализацию
сформированным
обеспечение
необходимых
требованиям.
доверенной
сетевой
базовых
К
таким
загрузки,
включающей контроль целостности загружаемого образа ОС и доверенную
аутентификацию всех участников информационного взаимодействия при
удаленной загрузке ОС на ТК. Помимо этого, для определения степени
доверия безопасности вычислительной среды на ТК должен быть разработан
метод оценки эффективности применяемой системы защиты информации.
Описание разработанных алгоритмов и методов приводится далее.
3.1 Доверенная загрузка операционной системы как основа построения
доверенной вычислительной среды
Согласно нормативным документам ФСТЭК, доверенная загрузка –
санкционированная загрузка штатной ОС, в рамках которой осуществляется
контроль целостности ПО и среды функционирования, и предоставление
доступа к информационным ресурсам в случае успешного завершения
проверок подлинности пользователя и загружаемой ОС [102]. Если
злоумышленнику удастся
несанкционированно
загрузить с
внешнего
носителя свою ОС, он получает полный доступ к файловой системе
пользователя. Кроме того, дополнительной угрозой является тот факт, что
пользователь может и не узнать о произошедшем инциденте – как правило,
система не оставляет следов на машине, с которой запускается.
В настоящее время на рынке информационной безопасности в
большинстве своем представлены средства защиты информации (СЗИ),
контролирующие загрузку операционной системы с жесткого диска и
предназначенные для применения на стационарных компьютерах. Такие
средства не могут быть использованы на бездисковых тонких клиентах,
60
поскольку реализованные в них механизмы контроля ОС, как правило, не
рассчитаны на сетевую загрузку и не учитывают специфики распределенных
терминальных систем.
В свою очередь, сам механизм защищенной загрузки ОС на
протяжении последних лет все активнее привлекает внимание разработчиков
встроенного программного обеспечения (далее - ПО) в целях защиты от
вредоносных программ типа «буткитов» и «руткитов». Целью таких
программ является реализация раннего старта, позволяющего изменить
программный код ОС и системных драйверов (например, установить
перехваты) [19]. К одной из самых популярных технологий, реализовавших
защищенную загрузку, относится Secure Boot, включаемый, начиная с версии
2.2, в модуль UEFI (Unified Extensible Firmware Interface – унифицированный
модульный интерфейс), пришедший на смену BIOS [20]. Как известно,
компания Microsoft также включила в свою сертификационную программу
для Windows 8 требования к производителям аппаратуры по реализации
механизма
защищенной
загрузки
UEFI.
Данный
механизм
должен
обеспечивать безопасную предзагрузочную среду и осуществлять защиту от
запуска неправомерного вредоносного кода из потенциально уязвимых
точек, проверяя электронную подпись загружаемых модулей (драйверов,
загрузчиков ОС и приложений) [21].
Необходимо отметить, что в такой реализации режим Secure Boot
достаточен для защищенной загрузки ОС только при условии, что
злоумышленник не может осуществить физический доступ к защищаемому
компьютеру, поскольку, в большинстве случаев несанкционированного
доступа (далее – НСД) есть возможность осуществления подмены
криптографических ключей. Кроме того, согласно спецификациям UEFI, в
режиме Secure Boot не предусмотрено механизмов создания доверительной
сети для ключей. Таким образом, данный режим должен быть активирован
непосредственно там, где будут использоваться компьютеры.
61
Важной особенностью решаемой в рамках данной работы задачи по
контролю целостности загружаемой ОС является тот факт, что сам образ
хранится на сервере и загрузка осуществляется по сети с использованием
протокола PXE. Описываемый выше стандарт UEFI также содержит
механизм сетевой загрузки по протоколу PXE. Но в случае обычной
реализации протокола, отправляя запрос на загрузку, клиент не может быть
уверенным, что запрос обслуживается подлинным ТС. Соответственно,
клиент не может достоверно знать, откуда он получает ОС и была ли
нарушена целостность образа в процессе передачи. Например, в результате
применения атаки «Man-in-the-middle» на сетевой протокол ТК может
получить вредоносный код вместе с загружаемым образом ОС. И хотя
разработчики свободно распространяемого ПО предлагают различные
механизмы, позволяющие нейтрализовать описанные угрозы при сетевой
загрузке [22], готовых средств на рынке информационной безопасности
представлено пока не было.
Таким образом, задача обеспечения такого базового механизма, как
безопасная загрузка ОС, являющегося важной частью всего процесса
обеспечения доверенной среды, для бездисковых рабочих станций, остается
нерешенной.
3.2 Метод загрузки и проверки целостности образа ОС на тонкий
клиент
Для обеспечения доверенной загрузки разрабатывалось решение,
позволяющее на аппаратном уровне реализовать механизмы контроля
целостности загружаемого по сети образа ОС и аутентификации всех
участвующих сторон.
3.2.1 Описание разрабатываемого модуля доверенной сетевой загрузки
Разрабатываемое
программного
модуля
решение
предполагает
доверенной
сетевой
создание
загрузки
аппаратно(АПМДСЗ),
предназначенного для работы именно на бездисковых ТК [103]. Такой
62
модуль позволяет разделить встроенное ПО, реализующее механизм
безопасной загрузки, и криптографические ключи. Кроме того, данный
способ персонифицирует загрузку ОС под конкретных пользователей в
соответствии с необходимыми им ПО и настройками.
Основные требования, предъявляемые к разрабатываемому решению,
состоят в следующем:
1) функционирование на аппаратных тонких клиентах, не имеющих в
своем составе жесткого диска;
2) реализация функции контроля целостности образа ОС, загружаемого
с терминального сервера;
3) реализация механизма разграничения прав доступа к процессу
загрузки тонкого клиента;
4) обеспечение целостности загрузчика ОС;
5) контроль аутентичности данных, поступающих на тонкий клиент;
6) независимость выбора загрузчика для ОС и, следовательно,
возможность загрузки ОС семейств Unix/Windows;
7) блокировка несанкционированной загрузки ОС с внешних съемных
носителей.
Для реализации разрабатываемого модуля доверенной загрузки
используется сетевая карта с поддержкой протокола PXE, при этом алгоритм,
реализующий метод загрузки, закладывается в её встроенном программном
обеспечении. Функция блокировки загрузки ОС с неразрешенных носителей
осуществляется путем запрета изменений конфигурации BIOS/UEFI без
получения привилегий административного доступа.
Для
обеспечения
контроля
целостности
загружаемого
образа
выделяются два основных объекта, неизменность которых необходимо
контролировать:
− загрузчик ОС размером 2-3 Кб, загружаемый в RAM-память на
первоначальном этапе и осуществляющий дальнейший процесс загрузки;
− сам образ ОС, передаваемый с сервера.
63
В самом процессе загрузки выделяется базовая точка доверия [36], на
которой будут основываться все остальные этапы. В качестве такой точки
выбран защищенный внешний носитель (далее – токен), в памяти которого
хранится загрузчик
ОС. На
таком внешнем носителе
размещается
собственный микроконтроллер – защищённый чип, имеющий специальную
сертифицированную защиту как на аппаратном, так и на программном
уровне, что позволяет успешно противостоять всем известным угрозам
безопасности самого носителя, методам взлома и клонирования. Доступ к
памяти
этого
устройства
предоставляется
только
после
успешной
аутентификации пользователя – введения пароля. В результате хранения
загрузчика на таком токене его целостность гарантирована. Данное решение
не накладывает никаких ограничений на то, ОС какого семейства будет при
этом загружаться на тонкий клиент.
Кроме
того,
использование
отдельного
защищенного
носителя
позволяет решить задачу по разграничению доступа: загрузка ОС на тонкий
клиент возможна только для пользователей, обладающих токеном и знающих
пароль. Для обеспечения взаимной аутентификации токена и тонкого клиента
предполагается реализация алгоритма, предусматривающего защиту от угроз
подмены каждого из участвующих в процессе компонентов (пользователя,
токена, тонкого клиента, сервера).
Учитывая вышесказанное, использование данного решения, в отличие
от механизма Secure Boot, делает угрозу непосредственного доступа
злоумышленника к тонкому клиенту неактуальной, поскольку у него не
будет возможности ни загрузиться с собственного носителя, ни заменить
сетевую карту на свою (алгоритм аутентификации обнаружит подмену).
Кроме того, разрабатываемый модуль – это достаточно гибкое решение, не
накладывающее ограничения ни на используемое оборудование, ни на тип
ОС. Администрирование системы с такими тонкими клиентами упрощается
за счет того, что администратору нужно работать только с защищенными
носителями пользователей.
64
Таким образом, основной задачей в предлагаемом решении является
разработка метода загрузки, обеспечивающего контроль целостности и
аутентичности передаваемого с сервера образа, и защищенного выполнения
каждого шага загрузки, исключающего реализацию угроз безопасности [103].
3.2.2 Анализ
существующих
способов
контроля
целостности
информации
Под угрозой нарушения целостности понимается любое нарушение
свойств сохранения правильности и полноты объекта [Ошибка! Закладка не
определена.104].
Когда
злоумышленники
преднамеренно
изменяют
информацию, говорится, что целостность информации нарушена. Основные
способы контроля целостности строятся на вычислении циклического
избыточного кода, бесключевых хэш-функций, ключевых хэш-функций [105]
и ЭП [106].
Несмотря на простоту реализации и высокую производительность
первого способа, необходимо отметить его основной недостаток: с точки
зрения вычислительной сложности легко найти исходный прообраз для
полученного значения функции, в результате чего равенство значений,
получаемых на этапе проверки, не гарантирует неизменности передаваемой
информации [107]. Данное свойство делает невозможным использование
указанного метода в системах с высокими требованиями к защищенности.
В отличие от них, применение однонаправленных хэш-функций
позволяет гарантировать стойкость используемого метода к обратному
преобразованию. Задача поиска коллизий (наличие нескольких прообразов
функции, дающих на выходе одно хэш-значение) является крайне тяжелой по
ресурсоемкости и производительности.
Но наряду с данным преимуществом у метода однонаправленной хэшфункции есть важная особенность: необходимость обеспечивать безопасное
хранение или передачу контрольного значения проверяющей стороной.
Относительно разрабатываемого решения очень важно, чтобы хэш-значение,
вычисляемое для образа операционной системы в момент формирования на
65
сервере, хранилось таким образом, чтобы исключить угрозу подмены. С
точки зрения аппаратной конфигурации тонкого клиента, единственным
доверенным местом для хранения контрольного значения ввиду отсутствия
жесткого диска является защищенная память токена.
Но такой вариант реализации метода контроля целостности вызывает
ряд сложностей: образ операционной системы, загружаемый по сети на
тонкий клиент, периодически может изменяться легитимным образом,
например, при установке обновлений администратором. В этом случае
контрольное значение в памяти токена должно быть перезаписано, поскольку
изменится и хэш-значение. Но при достаточно развитой структуре
организации,
предполагающей
наличие
нескольких
десятков
тонких
клиентов, использование подобного сценария крайне затрудняет работу
администратора.
Сравнение алгоритмов, построенных на перечисленных способах
контроля целостности, приводится в разделе 3.2.5.
3.2.3 Описание инфраструктуры открытого ключа
Альтернативный вариант контроля целостности передаваемого образа
– использование ИОК для вычисления электронной подписи. Основной
характеристикой ИОК является то, что все реализованные в ней сервисы
предоставляются с использованием технологии открытых ключей. То есть
ИОК
–
это
криптосистема, в которой для прямого и обратного
преобразования используются два разных ключа: открытый (ОК) и закрытый
(ЗК) [108]. Обязательным компонентом ИОК является доверенная сторона –
удостоверяющий центр (далее – УЦ), которая удостоверяет соответствие
открытого ключа закрытому и принадлежность их владельцу, выпуская при
этом сертификат и заверяя его своей ЭП. Основные принципы ИОК
представлены ниже (Рисунок 9):
66
Закрытый ключ известен только
его владельцу
Никто не доверяет друг другу,
но все доверяют УЦ;
УЦ подтверждает или опровергает
принадлежность открытого ключа
заданному лицу, которое владеет
соответствующим закрытым ключом
Рисунок 9 – Основные принципы ИОК
Таким образом, сторона, которой необходимо проверить ЭП, должна
для этого получить ОК стороны, поставившей подпись. При этом
проверяющей
стороне
(т.е.
тонкому
клиенту)
нужно
убедиться
в
подлинности открытого ключа (в т.ч. его принадлежности владельцу). При
этом терминальный сервер, формирующий подпись, должен обладать парой
(ЗК, ОК) для подписания образа.
В выдаваемом УЦ сертификате присутствует ОК пользователя и
идентифицирующие этого пользователя данные, а также другую служебную
информацию. Наряду с формированием сертификатов ОК к основным
задачам
УЦ
относятся
задачи
по
идентификации
пользователей,
аннулированию или отзыву сертификатов, формированию и актуализации
CRL (certificate revocation list, список отозванных сертификатов).
Сервер, выполняющий функции УЦ, должен располагаться строго
внутри контролируемой зоны организации и не иметь внешних подключений
либо полностью быть отключенным от сети. При этом обязательно должен
быть предусмотрен ресурс, доступный всем пользователям системы,
позволяющий проверять статус выданного сертификата (действителен или
отозван) в режиме реального времени. Как правило, в качестве такого
ресурса
используется
либо
сервер,
содержащий
список
отозванных
67
сертификатов (CRL), периодически обновляемый вручную администратором,
либо сервер, на котором работает служба онлайн-проверки статуса
сертификата (Online Certificate Status Protocol – OCSP). Во втором случае
информация о статусе сертификатов более актуальна, так как данная служба
ее получает напрямую из реестра УЦ, и ответ такой службы фиксирован и
имеет очень маленький объем по сравнению с достаточно большим CRL. Но
в этом случае сервер УЦ должен находиться в online-доступе и предоставлять
возможность обращения службе OCSP к своей базе, что порождает
возможность угрозы несанкционированного доступа и компрометации ключа
УЦ, которым подписываются все выдаваемые сертификаты. В таком случае
предполагается иерархическая архитектура удостоверяющих центров –
корневой, не подключенный в сеть организации, и подчиненный, выдающий
сертификаты пользователям и позволяющий подключение службы OCSP к
своей базе.
В разрабатываемом решении терминальный сервер обладает парой
ключей: закрытым и открытым, при этом факт владения открытым ключом и
факт того, что этот открытый ключ сопоставлен закрытому, подтверждается
сертификатом, выдаваемым УЦ.
При передаче образа ОС сервер подписывает его своим закрытым
ключом. В используемом алгоритме электронной подписи в качестве одного
из этапов также используется хэш-функция: на вход функции подписи
подается не сам образ, а его хэш-значение. Но принципиальное отличие
данного метода от метода простого хэширования состоит в том, что хэшзначение, вычисленное для ОС, не хранится постоянно на токене и его не
надо периодически обновлять в случае изменения ОС. Оно вычисляется
каждый раз на тонком клиенте от полученного образа и сравнивается с
результатом расшифрования ЭП с помощью ОК сервера (Рисунок 10):
68
Вычисление
хэш-функции
Данные, подписанные
электронной подписью
Хэш
Данные
?
=
Данные
Хэш
Хэш
Электронная подпись
Хэш
Расшифровка
подписи с помощью
открытого ключа
Рисунок 10 – Механизм проверки электронной подписи
Таким образом, если администратор внес изменения в загружаемый
образ (установил ПО или обновления), это не повлияет на успешность
проверки.
3.2.4 Реализация метода загрузки и проверки целостности образа ОС
Реализация
разработанного
метода
контроля
целостности
передаваемого образа [109] подразумевает формирование на стороне сервера
электронной подписи образа и передачу на тонкий клиент самого образа,
подписи и сертификата открытого ключа для осуществления проверки.
Но в этом случае возникает угроза реализации атаки Man-in-the-middle:
злоумышленник может перехватить передаваемый образ, подписать его
своим ключом и передать тонкому клиенту свой сертификат [110]. Для
нейтрализации данной угрозы предлагается хранить на внешнем ключевом
носителе сертификат открытого ключа УЦ, (или цепочку сертификатов в
случае иерархической структуры УЦ). При формировании сертификата
открытого ключа серверу, УЦ заверяет выдаваемый сертификат своим
закрытым ключом, что позволяет в момент верификации электронной
подписи переданного образа проверить также подлинность сертификата
сервера. Таким образом, компоненты, входящие в состав ИОК, необходимые
для реализации предлагаемого решения, указаны ниже (Рисунок 11):
69
Удостоверяющий центр
ЗК
ОК
Сертификат
УЦ
Самподписанный
Тонкий клиент
Сервер
ЗК
Сеть
организации
ОК
Сертификат
сервера
Подписан ЗК УЦ
ОК
ОС
ОК
Сертификат
сервера
Сертификат
УЦ
ЭП
ОК
Сертификат
УЦ
Защищенный
USB-носитель
Рисунок 11 – Компоненты ИОК для разрабатываемого метода загрузки и
проверки целостности образа ОС на ТК
В целях проверки ЭП на первом шаге вычисляется значение хэшфункции образа ОС, а на втором шаге происходят непосредственно
математические
преобразования,
предусмотренные
алгоритмом
ЭП,
подразумевающие проверку всех трех компонентов: хэш-функции, ЭП и ОК
подписывающей стороны. В случае положительного результата проверки ЭП
признается корректной, полученный образ – подлинным. В противном случае
считается, что в образ ОС были внесены изменения.
Компоненты ИОК, участвующие в методе:
− Удостоверяющий центр УЦ;
− Тонкий клиент ТК;
− Терминальный сервер ТС;
− Закрытый ключ сервера 𝑘𝑘𝑠𝑠 ;
− Сертификат открытого ключа сервера 𝑘𝑘𝑜𝑜 ;
− Сертификат открытого ключа Удостоверяющего центра 𝑘𝑘𝐶𝐶𝐴𝐴 ;
70
− Образ операционной системы 𝑂𝑂𝑂𝑂;
− ℎ хэш-функция;
− 𝑓𝑓 функция вычисления электронной подписи;
− 𝑣𝑣 функция проверки электронной подписи.
Метод загрузки и проверки целостности образа ОС:
Шаг 1. Инициализация протокола загрузки образа 𝑂𝑂𝑂𝑂 с терминального
сервера ТС после того, как токен подключили к тонкому клиенту ТК.
Шаг 2. Формирование запроса к ТС на получение образа 𝑂𝑂𝑂𝑂 и
сертификата открытого ключа 𝑘𝑘𝑜𝑜 сервера.
Шаг 3. Формирование на стороне сервера электронной подписи образа:
𝑓𝑓(ℎ(𝑂𝑂𝑂𝑂), 𝑘𝑘𝑠𝑠 ), где ℎ(𝑂𝑂𝑂𝑂) хэш-функция от образа 𝑂𝑂𝑂𝑂.
Шаг 4. Получение сертификата 𝑘𝑘𝑜𝑜 сервера, образа 𝑂𝑂𝑂𝑂, подписанного
закрытым ключом 𝑘𝑘𝑠𝑠 сервера.
Шаг 5. Проверка
целостности
образа
и
подлинности
подписи:
𝑣𝑣(ℎ(𝑂𝑂𝑂𝑂), 𝑘𝑘𝑜𝑜 );
Шаг 6. Обращение к токену за корневым сертификатом УЦ 𝑘𝑘𝐶𝐶𝐶𝐶 .
Шаг 7. Проверка подлинности сертификата открытого ключа сервера
𝑘𝑘𝑜𝑜 :
𝑣𝑣(ℎ(𝑘𝑘𝑜𝑜 ), 𝑘𝑘𝐶𝐶𝐶𝐶 ).
Шаг 8. В случае успешности обеих проверок образ 𝑂𝑂𝑂𝑂 загружается в
RAM-память и управление передается на него.
Еще одним важным требованием к функционалу разрабатываемого
решения
является
доверенная
аутентификация
всех
участвующих
компонентов: сервера, тонкого клиента, токена и пользователя.
При
этом
необходимо
понимать,
что
процесс
дальнейшей
аутентификации пользователя в ОС, а также для выполнения специальных
операций, предусмотренных в рамках процессов, требующих повышенного
уровня защиты, является обязательным этапом в данном решении. Несмотря
на
то,
что
добавление
требований
к
пользователю
по
хранению
дополнительных секретов усложняет его работу, альтернативный вариант
71
(передача образа ОС уже с осуществленной авторизацией) представляет
существенную угрозу несанкционированного доступа к информации [20].
3.2.5 Сравнение и анализ предлагаемого метода с существующими
методами контроля целостности
Для сравнения разработанного метода загрузки и проверки целостности
ОС на ТК с альтернативными методами необходимо определить формальные
критерии для алгоритмов, построенных на базе этих методов. Согласно
работе [111] оценка защищенности алгоритмов контроля целостности может
быть определена через способность ключевых критериев этих алгоритмов
обеспечить с определенной вероятностью отказ в несанкционированном
доступе (нарушении целостности) к защищаемым данным.
На основе анализа критериев алгоритмов контроля целостности
определим следующие вероятности:
а
𝑃𝑃НСД
– вероятность успешной атаки (НСД) на сам алгоритм
(математическое преобразование или криптографический примитив);
л
– вероятность НСД по причине компрометации локально
𝑃𝑃НСД
хранящихся контрольных значений;
к
– вероятность НСД по причине компрометации ключевой
𝑃𝑃НСД
информации.
Поскольку условия эксплуатации ТК в системе различны и напрямую
зависят от пользователей, работающих с ними, места расположения,
предпринимаемых организационных мер и т.п., атаки на ключевую
информацию и локально хранящиеся контрольные значения имеют разную
вероятность успеха для разных ТК. При этом реализация НСД к
защищаемым данным означает тот факт, что хотя бы на одном из ТК
механизм защиты отработал некорректно. Тогда вероятность НСД в силу
компрометации локально хранящихся контрольных значений определяется
следующим образом:
72
𝑛𝑛
л
= 1 − � 𝑃𝑃𝑖𝑖л ,
𝑃𝑃НСД
𝑖𝑖=1
где 𝑃𝑃𝑖𝑖л – вероятность корректной работы механизмов защиты
контрольных значений на 𝑖𝑖 -ом тонком клиенте, 𝑛𝑛 – количество тонких
R
R
клиентов в СТД.
Аналогично определяется вероятность НСД в силу компрометации
ключевой информации:
𝑛𝑛
к
𝑃𝑃НСД
= 1 − � 𝑃𝑃𝑖𝑖к ,
𝑖𝑖=1
где 𝑃𝑃𝑖𝑖к – вероятность корректной работы механизмов защиты ключевой
информации на 𝑖𝑖 -ом тонком клиенте.
R
Таким образом, вероятность НСД к защищаемым данным определяется
следующим образом:
𝑛𝑛
𝑛𝑛
𝑖𝑖=1
𝑖𝑖=1
а
𝑃𝑃НСД = 𝑃𝑃НСД
∗ �1 − � 𝑃𝑃𝑖𝑖л � ∗ �1 − � 𝑃𝑃𝑖𝑖к �.
Тогда оценка защищенности алгоритмов контроля целостности:
𝑛𝑛
𝑛𝑛
𝑖𝑖=1
𝑖𝑖=1
к
а
л
а
∗ 𝑃𝑃ЗАЩ
∗ 𝑃𝑃ЗАЩ
= �1 − 𝑃𝑃НСД
𝑃𝑃ЗАЩ = 𝑃𝑃ЗАЩ
� ∗ �� 𝑃𝑃𝑖𝑖л � ∗ �� 𝑃𝑃𝑖𝑖к �.
Проведем
сравнительный
анализ
показателей
защищенности
следующих алгоритмов, описание которых приведено в разделе 3.2.2
настоящей диссертационной работы:
1. Алгоритмы на основе вычисления циклического избыточного кода
(контрольных сумм).
2. Алгоритмы на основе вычисления бесключевых хэш-функций.
3. Алгоритмы на основе вычисления ключевых хэш-функций.
4. Алгоритмы на основе ИОК (вычисления ЭП).
к
а
л
Качественные оценки показателей защищенности 𝑃𝑃ЗАЩ
, 𝑃𝑃ЗАЩ
и 𝑃𝑃ЗАЩ
приведены ниже (Таблица 7):
73
Таблица 7 – Сравнительный анализ значений показателей защищенности от
НСД алгоритмов контроля целостности
Алгоритм Контрольные Бесключевые
Показа
тель
а
𝑃𝑃ЗАЩ
л
𝑃𝑃ЗАЩ
суммы
хэш-функции
Ключевые
хэшфункции
Электронная
подпись
Низкая*
Средняя
Высокая
Высокая
Низкая
Низкая
1
1
к
1
1
Средняя
Высокая
𝑃𝑃ЗАЩ
*Пояснения к оценочным значениям показателей приведены ниже.
Исходя
из
результатов
криптоанализа
наиболее
популярных
представителей из каждой группы алгоритмов (CRC32, MD5, SHA2, SHA3,
ГОСТ Р 34.11-2012, HMAC, ГОСТ 28147-89 в режиме имитовставки, ECDSA,
RSA, ГОСТ 34.10-2001, ГОСТ 34.10-2001), самой низкой сложностью атак по
нахождению коллизии или прообраза обладают алгоритмы по вычислению
контрольной суммы. Для тех алгоритмов бесключевых хэш-функций, что на
протяжении длительного времени находились под пристальным вниманием
криптоаналитиков (MD5, SHA2) сложность таких атак колеблется от 237 до
239 операций хэширования. Но в отношении ключевых хэш-функций и
алгоритмов электронной подписи показатель защищенности значительно
выше, поскольку к криптостойкости используемых хэш-функций также
добавляется стойкость алгоритмов шифрования.
Для параметра защищенности алгоритмов от НСД в результате
компрометации локально хранящихся контрольных значений в случае
алгоритмов ЭП и ключевой хэш-функции эта вероятность равно 1, поскольку
такого хранения не предусмотрено логикой алгоритма. Напротив, для
контрольных сумм и бесключевых хэш-функции необходимость иметь (и
регулярно обновлять) на стороне клиента значения для проверки значительно
снижают их показатель защищенности. Отсутствие же в данных алгоритмах
ключевых значений позволяет признать вероятность НСД к ним равной 0, в
отличие от ключевых хэш-функций (необходимость хранить симметричный
ключ, компрометация которого нарушает безопасность всей системы) и
74
алгоритмов ЭП (используемая ИОК позволяет защитить все остальные
компоненты системы в случае компрометации одного, но безопасность
закрытых ключей все же требуется соблюдать на высоком уровне).
Таким образом, на основе проведенного сравнения приводимых
алгоритмов
контроля
целостности
можно
сформировать
следующее
соотношение:
𝑃𝑃ЗАЩ_КС < 𝑃𝑃ЗАЩ_БКХ < 𝑃𝑃ЗАЩ_КХ < 𝑃𝑃ЗАЩ_ЭП .
В результате чего можно сделать вывод о наибольшей защищенности
от НСД алгоритма контроля целостности на основе ЭП, используемом в
реализации метода загрузки и проверки целостности ОС на ТК.
3.3 Алгоритм
аутентификации
участников
информационного
взаимодействия при удаленной загрузке операционной системы на
тонкий клиент
Согласно построенной ранее классификации угроз, одной из самых
распространенных проблем систем терминального доступа [101] является
непроработанный механизм аутентификации, в том числе слабая парольная
политика и недостаточная защита от подбора учетных данных (bruteforce).
Часто встречающийся недостаток механизма идентификации пользователей
— предсказуемый формат идентификаторов или раскрытие информации о
существующих в системе идентификаторах. Например, использование в
качестве имени пользователя различных комбинаций фамилии и имени
пользователя является распространенной и вполне оправданной практикой
как с точки зрения удобства администрирования систем, так и простоты
запоминания для самих пользователей. Кроме того, это вполне соответствует
принципу Керкгоффса – в подобном механизме в секрете должен держаться
только пароль, все остальное подразумевается известным злоумышленнику.
И, тем не менее, такое использование идентификаторов в сочетании с
различными находящимися в широком доступе средствами автоматизации
значительно повышает вероятность успеха атак на учетные записи
75
пользователей (например, словарная атака) и в качестве результата –
предоставление доступа в систему. Такое заключение дает повод задуматься
о механизме формирования идентификаторов, которые бы не осложняли
жизнь пользователей и администраторов, но соответствовали требованиям
безопасности.
Для защищенной обработки особо критичной информации уже
достаточно давно применяются токены и смарт-карты – специализированные
устройства, самостоятельно реализующие криптографические алгоритмы.
Факт обладания таким устройством уже является одним из факторов,
подтверждающих подлинность пользователя. В этом случае
вместо
предсказуемого имени пользователя используется идентификатор токена.
При
этом
разграничение
доступа
к
зашифрованным
контейнерам,
хранящимся в памяти таких носителей, осуществляется, как правило, с
помощью PIN-кода, что является вторым фактором аутентификации. Защита
от
модификации
реализуемых
такими
устройствами
алгоритмов
обеспечивается на аппаратном уровне производителями и подтверждается
соответствующей сертификацией.
Для реализации контроля аутентичности данных, поступающих на
тонкий клиент, необходимо ограничить круг источников (например,
доверенным
сервером).
Целостность
загружаемого
образа
ОС
и
разграничение доступа к процессу загрузки должны быть реализованы в
механизме
доверенной
сетевой
загрузки,
включающем
реализацию
защищенного протокола загрузки.
Таким образом, разрабатываемый алгоритм взаимной аутентификации
должен позволять реализовать следующие требования:
1) токен должен аутентифицировать тонкого клиента, т.е. тонкий клиент
должен доказать токену, что входит в состав системы;
2) тонкий клиент должен аутентифицировать токен, т.е. токен должен
доказать тонкому клиенту, что является легитимным носителем и был
выпущен администратором системы;
76
3) тонкий
клиент
должен
аутентифицировать
пользователя,
т.е.
пользователь должен доказать системе, что предъявленный токен
принадлежит ему и он является легитимным пользователем системы.
Поставленная задача осложняется тем фактом, что на практике, как
правило,
необходимо
предусматривать
работу
многопользовательской
системы терминального доступа (СТД) с терминальным сервером, хранящим
ОС, и парком аппаратных тонких клиентов (ТК) [27]. При этом на одном и
том же ТК могут работать разные пользователи и, соответственно, иметь
возможность
после
успешной
аутентификации
загружать
персонифицированный образ ОС с назначенными именно им правами
доступа.
Отдельно стоит заметить, что одним из основных предполагаемых
целевых использований разрабатываемого модуля являются государственные
информационные системы [112]. Это обусловлено наличием требований по
обеспечению доверенной загрузки операционной системы в нормативной
документации в таких системах [43,113]. В силу этого, дополнительным
требованием к реализации механизма аутентификации является соответствие
используемых
криптографических
алгоритмов
российским стандартам
(ГОСТ).
Исходя из результатов анализа угроз, рассматриваемых в отношении
компонентов, участвующих в процессе загрузки ОС [101], первым этапом
разрабатываемого алгоритма должна быть аутентификация СТД в лице ТК на
токене. Этот шаг выполняется в первую очередь, т.к. необходимо обеспечить
защиту
хранящейся
несанкционированного
на
токене
доступа
информации
(НСД)
со
(загрузчика
стороны
ОС)
от
потенциальных
нарушителей, если предположить, что ТК подключен в нелегитимную
систему. Только после этого пользователь, предварительно доказав владение
токеном, может предоставить СТД возможность проверить легитимность
загрузчика.
77
В качестве реализации аутентификации ТК на токене могут быть
применены следующие механизмы [114]:
− алгоритм аутентификации с использованием одноразовых паролей (OTP,
one time password);
− алгоритм аутентификации с использованием инфраструктуры открытых
ключей (PKI, public key infrastructure).
В следующих разделах приводится описание данных алгоритмов, их
плюсы и минусы. При этом подразумевается, что описываемые механизмы
аутентификации реализованы в модуле доверенной сетевой загрузки [109],
установленном в тонком клиенте.
3.3.1 Алгоритм
аутентификации
с
использованием
одноразовых
паролей
Данный алгоритм предполагает наличие как на токене, так и в ТК
списка одноразовых паролей, либо алгоритма генерации таких паролей.
Генерация паролей может осуществляться с использованием односторонней
хэш-функции (имеется в виду классическая криптографическая хэш-функция
с
односторонней
вычислимостью),
либо
алгоритмов
симметричного
шифрования [105]. Запись паролей на токен должна осуществляться при ее
инициализации администратором ИБ на его рабочем месте. При этом можно
выделить следующие требования к такому алгоритму:
− любой ТК из состава СТД, на котором пользователь хочет осуществить
загрузку ОС, должен предъявлять токену один и тот же пароль, т.к. очень сложно
и трудоемко организовывать техническую возможность хранить на токене
отдельные пароли для всех ТК;
− на любом ТК из состава СТД должен быть реализован алгоритм
генерации паролей с использованием закрытого ключа, т.к. нет технической
возможности хранить на ТК пароли для всех токенов.
В состав данных, с которыми работает алгоритм, входят:
− запрос токена – случайное число 𝑅𝑅;
78
− закрытый ключ тонкого клиента 𝐾𝐾;
− шифрограмма запроса токена на закрытом ключе тонкого клиента 𝐸𝐸𝐾𝐾 (𝑅𝑅);
− пароль пользователя для доступа к токену.
В качестве модулей, реализующих вычисления в рамках описываемого
алгоритма, используются:
− Модуль токена;
− АПМДСЗ [109].
Подобный алгоритм может быть реализован следующим образом:
Шаг 1. При первичной инициализации токена в его память сохраняется
запрос – случайное число 𝑅𝑅, и контрольный ответ, представляющий собой
шифрограмму данного случайного числа на закрытом ключе тонкого клиента
𝐾𝐾 – 𝐸𝐸𝐾𝐾 (𝑅𝑅). Также на токене хранится эталонное значение пароля
пользователя.
Шаг 2. При
прохождении
аутентификации
ТК
выводит
для
пользователя СТД на монитор форму авторизации с приглашением вставить
токен.
Шаг 3. Пользователь вставляет токен в usb-порт ТК.
Шаг 4. ТК запрашивает у токена записанное на него случайное число
𝑅𝑅.
Шаг 5. Токен предоставляет ТК случайное число 𝑅𝑅.
Шаг 6. ТК возвращает токену запрос, зашифрованный на своем
закрытом ключе 𝐾𝐾 - 𝐸𝐸𝐾𝐾 (𝑅𝑅).
Шаг 7. Токен сравнивает полученный ответ с контрольным и, в случае
их совпадения, аутентифицирует ТК.
Шаг 8. ТК выводит для пользователя СТД на монитор запрос на
введение пароля.
Шаг 9. Пользователь вводит пароль для доступа к загрузчику.
Шаг 10. ТК передает введенное пользователем значение пароля на
токен для сравнения с эталонным.
79
Шаг 11. Токен возвращает на ТК результат сравнения. В случае успеха
алгоритм аутентификации завершен, иначе ТК повторно запрашивает пароль
пользователя.
Шаг 12. После успешного завершения аутентификации ТК генерирует
новую пару из запроса и ответа {𝑅𝑅′ , 𝐸𝐸𝐾𝐾 (𝑅𝑅′ )}, которая записывается на токен
для использования в следующем сеансе аутентификации.
В результате все ТК в составе СТД должны использовать общий
закрытый ключ 𝐾𝐾 для генерации паролей, причем компрометация этого
закрытого ключа приведет к возможности НСД ко всем выпущенным с
данным ключом токенам.
3.3.2 Алгоритм
аутентификации
участников
информационного
взаимодействия при удаленной загрузке операционной системы на
тонкий клиент с использованием инфраструктуры открытых
ключей
Алгоритм взаимной аутентификации пользователя, токена, тонкого
клиента и терминального сервера с использованием инфраструктуры
открытых
ключей
(ИОК)
[115]
реализуется
следующим
образом.
Аутентификация токена в системе СТД производится за счет наличия на нем
собственного
закрытого
ключа
сертификата
открытого
ключа.
аутентификации
Генерация
и
соответствующего
ключей
осуществляется
непосредственно на токене в процессе персонализации, формирование и
выдача сертификатов выполняется удостоверяющим центром (УЦ). Ключи
хранятся в контейнере, доступ к которому предоставляется только после
введения пользователем корректного PIN-кода.
Терминальный
сервер
является
доверенным
компонентом
рассматриваемой СТД. Аутентификация СТД в лице тонкого клиента на
токене производится за счет наличия на ТС собственного закрытого ключа и
соответствующего
сертификата
открытого
ключа. Генерация
ключей
осуществляется также непосредственно на сервере при развертывании СТД,
сертификаты серверу формирует и выдает тот же УЦ.
80
При рассмотрении данного алгоритма предполагается, что ТК
расположены в пределах контролируемой зоны, что предусматривает
наличие организационных мер, направленных на предотвращение доступа
нарушителей
к
компонентам
СТД
и
предотвращение
модификации
аппаратного обеспечения ТК. При этом непосредственно информационное
взаимодействие токена, ТК и ТС защищается с использованием алгоритмов
шифрования и выработки имитовставки (ГОСТ 28147-89 [116]) на сеансовых
ключах.
Формирование сеансовых ключей должно осуществляться на ТС с
использованием криптопровайдера, реализующего алгоритмы ГОСТ, при
получении соответствующего запроса от ТК.
При этом сформированные ключи передаются на ТК по защищенном
каналу
связи:
сеансовые
ключи
защищаются
с
использованием
вспомогательных в соответствии с рекомендациями п. 5.2 RFC 4357 [117].
Генерация вспомогательных ключей производится на токене и на ТС
независимо после обмена сертификатами открытого ключа за счет
выполнения умножения точки эллиптической кривой (открытый ключ одной
из сторон) на число (закрытый ключ второй стороны) и вычисления хэшфункции полученного значения в соответствии со стандартом ГОСТ 34.112012 [106].
Аутентификация пользователя СТД при этом осуществляется за счет
проверки пароля при запросе доступе к загрузчику, хранящемуся на токене.
В качестве модулей, реализующих все функциональные вычисления в
рамках описываемого алгоритма, используются:
− Криптографический
модуль
токена
(с
обязательной
поддержкой
криптографических алгоритмов ГОСТ);
− Криптографический
модуль
терминального
сервера
криптопровайдер, также реализующий алгоритмы ГОСТ);
− АПМДСЗ [109].
В состав данных, с которыми работает алгоритм, входят:
(программный
81
− ключевая пара (открытый и закрытый ключи) токена;
− сертификат открытого ключа токена;
− ключевая пара (открытый и закрытый ключи) терминального сервера;
− сертификат открытого ключа терминального сервера;
− сертификат открытого ключа Удостоверяющего центра;
− пароль пользователя для доступа к контейнеру с ключевой парой токена.
Используемые обозначения:
− ЗК – закрытый ключ;
− ОК – открытый ключ;
− УЦ – удостоверяющий центр;
− ТК – тонкий клиент;
− ТС – терминальный сервер;
− ЭП – электронная подпись.
Алгоритм
взаимной
аутентификации
с
использованием
ИОК
представлен ниже (см. Рисунок 12).
Пользователь СТД
Пароль пользователя для
доступа к контейнеру с
ключами токена
1 2
20 21
Терминальный сервер
Токен
Криптографический
модуль токена
12; 15; 16; 17
•
•
•
•
ЗК, ОК токена
Сертификат ОК ТС
Сертификат ОК УЦ
Пароль пользователя
3
4
11
13
14
18
22
23
Криптографический
модуль, реализованный в
АПМДСЗ
10; 19; 24
Тонкий клиент
5
9
Криптографический
модуль терминального
сервера
6; 7; 8
• ЗК, ОК терминального
сервера
• Сертификат ОК ТС
• Сертификат ОК УЦ
Обозначения:
2
– действие №2 по передаче данных от одного функционального модуля к другому согласно алгоритму
6; 7; 8 – действия №6, 7, 8, выполняемые локально на указанном компоненте СТД согласно алгоритму
Рисунок 12 – Схема алгоритма взаимной аутентификации с использованием
ИОК
82
Шаг 1. ТК выводит для пользователя СТД на монитор форму
авторизации с приглашением вставить токен.
Шаг 2. Пользователь вставляет токен в usb-порт ТК.
Шаг 3. ТК передает токену запрос на считывание его идентификатора
и сертификата ОК аутентификации токена.
Шаг 4. Токен
передает
ТК
идентификатор
и
сертификат
ОК
аутентификации токена (данные передаются в открытом виде).
Шаг 5. ТК передает терминальному серверу запрос на генерацию
сеансовых ключей шифрования. В запрос включается сертификат ОК
аутентификации токена, полученный на шаге 4.
Шаг 6. ТС осуществляет проверку ЭП полученного сертификата ОК
токена
с
использованием
сертификата
ОК
УЦ,
который
хранится
непосредственно на сервере. Также ТС производит проверку актуального
статуса сертификата ОК токена. Если ЭП сертификата неверна, либо
сертификат был отозван, алгоритм переходит к шагу 9.
Шаг 7. ТС осуществляет генерацию случайных чисел 𝑅𝑅1 , 𝑅𝑅2 и
вспомогательных симметричных ключей шифрования 𝐾𝐾1 и 𝐾𝐾2 на основе
собственного закрытого ключа и открытого ключа токена в соответствии с
рекомендациями п. 5.2 RFC 4357.
Шаг 8. ТС осуществляет генерацию сеансовых ключей шифрования 𝐾𝐾𝑐𝑐
и выработки имитовставки 𝐾𝐾𝑖𝑖𝑖𝑖 для использования в соответствии со
стандартом ГОСТ 28147-89.
Шаг 9. ТС передает ответное сообщение на ТК. При успешном
выполнении шагов 6-8 в сообщение включаются:
− сертификат ОК терминального сервера;
− сеансовые ключи 𝐾𝐾𝑐𝑐 и 𝐾𝐾𝑖𝑖𝑖𝑖 для использования на ТК;
− блок данных для передачи на токен (подробнее см. шаг 14 данного
алгоритма).
При возникновении ошибок на шагах 6-8 в сообщение включается
только соответствующий код ошибки.
83
Шаг 10. При получении от ТС сообщения об успешной проверке
сертификата ОК токена, ТК сохраняет полученные сеансовые ключи. В
случае получения от ТС кода ошибки, ТК выводит на монитор пользователю
СТД соответствующее сообщение, посылает токену запрос на временную
блокировку и выполнение алгоритма аутентификации завершается.
Шаг 11. Если на шаге 10 получено сообщение об успешной проверке,
ТК передает на токен запрос на инициализацию протокола взаимной
аутентификации, содержащий сертификат ОК ТС, полученный от ТС на шаге
9.
Шаг 12. Токен осуществляет проверку ЭП полученного сертификата с
использованием ОК УЦ, который хранится на токене. Открытый ключ ТС
извлекается из сертификата и сохраняется в памяти токен.
Шаг 13. Токен формирует и передает в ТК ответное сообщение,
которое служит подтверждением того, что токен произвел проверку ЭП. Если
при выполнении шагов 11-12 возникла ошибка, токен включает в ответное
сообщение
код
ошибки
и
выполнение
алгоритма
аутентификации
завершается.
Шаг 14. Если на шаге 13 токен передает положительное ответное
сообщение, ТК передает на токен блок данных, полученных от ТС на шаге 9.
Блок данных представляет собой конкатенацию 𝑅𝑅1 ∥ 𝐸𝐸(𝐾𝐾𝑐𝑐 )𝐾𝐾1 ∥ 𝐼𝐼(𝐾𝐾𝑐𝑐 )𝐾𝐾1,𝑅𝑅1 ∥
𝑅𝑅2 ∥ 𝐸𝐸(𝐾𝐾𝑖𝑖𝑖𝑖 )𝐾𝐾2 ∥ 𝐼𝐼(𝐾𝐾𝑖𝑖𝑖𝑖 )𝐾𝐾2,𝑅𝑅2 , где
− 𝑅𝑅1 , 𝑅𝑅2 – случайные числа, сгенерированные на шаге 7;
− 𝐸𝐸(𝐾𝐾𝑐𝑐 )𝐾𝐾1 , 𝐸𝐸(𝐾𝐾𝑖𝑖𝑖𝑖 )𝐾𝐾2 – шифрограммы сеансовых ключей 𝐾𝐾𝑐𝑐 и 𝐾𝐾𝑖𝑖𝑖𝑖 на
вспомогательных ключах 𝐾𝐾1 и 𝐾𝐾2 , вычисленные в соответствии со стандартом
ГОСТ 28147-89 в режиме простой замены;
− 𝐼𝐼(𝐾𝐾𝑐𝑐 )𝐾𝐾1,𝑅𝑅1 , 𝐼𝐼(𝐾𝐾𝑖𝑖𝑖𝑖 )𝐾𝐾2,𝑅𝑅2 – значения имитовставки, вычисленной в
соответствии со стандартом ГОСТ 28147-89 в режиме выработки имитовставки,
на вспомогательных ключах 𝐾𝐾1 и 𝐾𝐾2 с использованием чисел 𝑅𝑅1 , 𝑅𝑅2 в качестве
84
векторов инициализации и сеансовых ключей 𝐾𝐾𝑐𝑐 и 𝐾𝐾𝑖𝑖𝑖𝑖 в качестве входных
данных.
Шаг 15. Токен извлекает из полученного сообщения значения 𝑅𝑅1 , 𝑅𝑅2 и
выполняет формирование вспомогательных ключей шифрования 𝐾𝐾1 и 𝐾𝐾2 на
основе собственного закрытого ключа и открытого ключа ТС, полученного
на шаге 11, в соответствии с рекомендациями п. 5.2 RFC 4357.
Шаг 16. Токен выполняет расшифровку сеансовых ключей 𝐾𝐾𝑐𝑐 и 𝐾𝐾𝑖𝑖𝑖𝑖 с
использованием вспомогательных.
Шаг 17. Токен
выполняет
подсчет
контрольных
значений
имитовставки в соответствии со стандартом ГОСТ 28147-89 и сравнение
полученных значений с контрольными. Если проверка имитовставки прошла
успешно, токен аутентифицирует ТК, а именно:
− сохраняет сеансовые ключи в памяти токена;
− инициализирует
протокол
защищенного
взаимодействия
с
использованием сеансовых ключей;
− предоставляет ТК доступ к загрузчику.
Шаг 18. Токен передает ТК ответное сообщение. В случае успешного
выполнения шагов 15-17 сообщение служит подтверждением успешной
аутентификация ТК на токене. В противном случае сообщение содержит код
ошибки, возникшей при выполнении шагов 15-17 данного алгоритма, и
выполнение алгоритма аутентификации завершается.
Шаг 19. В случае положительного ответного сообщения от токена
аутентификация
токена
на
ТК,
осуществляется
за
счет
проверки
имитовставки данного сообщения путем выполнения следующих действий:
− на ТК вычисляется контрольная имитовставка как результат шифрования
полученной шифрограммы на сеансовом ключе выработки имитовставки 𝐾𝐾𝑖𝑖𝑖𝑖 с
использованием алгоритма ГОСТ 28147-89 в режиме выработки имитовставки;
− производится сравнение полученной имитовставки с контрольной. В
случае если результат сравнения отрицательный, ТК прерывает выполнение
протокола и прекращает сеанс связи с токеном. Корректно вычисленная
85
имитовставка подтверждает факт наличия на токене сеансовых ключей, а,
следовательно, и закрытого ключа аутентификации токена.
Шаг 20. ТК выводит для пользователя СТД на монитор запрос на
введение пароля.
Шаг 21. Пользователь вводит пароль для доступа к загрузчику.
Шаг 22. ТК
передает
на
токен
значение
пароля,
введенного
пользователем, для сравнения.
Шаг 23. Токен сравнивает полученное значение пароля с эталонным.
Если сравнение положительно, алгоритм аутентификации успешно завершен
и осуществляется передача управления на АПМДСЗ. В случае если значения
паролей отличаются, токен сообщает об этом на ТК.
Шаг 24. Если на шаге 23 от токена получен отрицательный ответ по
проверке паролей, ТК выводит об этом сообщение на экран и запрашивает
пароль пользователя повторно (алгоритм переходит на шаг 20). В случае
введения пользователем неправильного пароля заданное количество раз
подряд ТК осуществляет блокирование токена. Разблокирование токена
должен осуществлять администратор информационной безопасности.
Поскольку
одной
из
важных
функциональных
особенностей
инфраструктуры открытого ключа является проверка сертификатов открытых
ключей на отозванность, все участвующие компоненты должны иметь
возможность получать такую информацию. Данный функционал может быть
реализован либо указанием в самом сертификате адреса сервера, на котором
расположен актуальный (как правило, выпускающийся ежедневно) список
отозванных сертификатов (CRL) из УЦ, либо организацией службы OCSP
(Online Certificate Status Protocol), которая выдает актуальную информацию о
статусе сертификата в реальном режиме, напрямую обращаясь в базу УЦ
[115]. Исходя из описания алгоритма, в проверке статуса сертификата
нуждаются криптомодули токена и ТС. Но если ТС может получить такую
информацию любым из указанных способов, находясь в доверенной сетевой
инфраструктуре, то токену, чтобы получить либо CRL, либо обратиться к
86
OCSP-серверу, необходимо аутентифицироваться в системе, что в итоге
приводит к замкнутому кругу. Таким образом, при реализации алгоритма
аутентификации следует учитывать, что токен не может распознать
ситуацию, когда предъявленный ему сертификат уже недействителен, и
необходимым требованием к безопасности в данном случае является
гарантированное уничтожение выведенных из обращения закрытых ключей
ТС и УЦ СТД при их смене.
3.3.3 Сравнение и анализ предлагаемых алгоритмов с существующими
алгоритмами аутентификации
Если сравнивать два предлагаемых алгоритма с точки зрения
выполнения
требований, предъявляемых при
постановке
задачи, то
аутентификация всех участвующих компонентов (токена, тонкого клиента и
терминального сервера) полноценно реализуется в обоих случаях. То же
относится и к требованию по применимости рассматриваемых алгоритмов в
ГИС в отношении реализации отечественной криптографии.
Однако, если смотреть на предлагаемые алгоритмы с точки зрения
многопользовательской
архитектуры
СТД,
в
которой
должна
быть
реализована аутентификация, то алгоритм с использованием одноразовых
паролей в недостаточной мере удовлетворяет требованиям безопасности. В
отличие от алгоритма, построенного на ИОК, использование общего
закрытого ключа, который должен храниться на всех ТК для возможности
аутентификации токенов, закладывает серьезную уязвимость. При этом
второй алгоритм изначально строится на асимметричной криптографии, т.е.
подразумевается, что закрытые ключи всех участников никогда не
передаются в процессе аутентификации.
Но необходимо отметить, что важным требованием к применению
алгоритма, построенного на ИОК, является обеспечение контрольных мер
против НСД
к самим тонким клиентам в целях предотвращения
модификации их программно-аппаратного обеспечения. Если же выполнение
данных мер считается невозможным, рассматриваемый алгоритм можно
87
усилить, добавив в схему дополнительный секрет, хранящийся в АПМДСЗ и
аутентифицирующий ТК в СТД до того, как ТС передаст свое ответное
сообщение с сеансовыми ключами.
Таким образом, к преимуществам алгоритма с одноразовыми паролями
можно отнести простоту реализации с технической точки зрения, но
существенными недостатками будут низкая масштабируемость системы и
недостаточный выдвигаемым требованиям уровень безопасности.
В свою очередь, к преимуществам алгоритма с использованием ИОК
относятся простота централизованного управления (в том числе, выдача
ключей
и
сертификатов),
использования,
высокий
масштабируемость
уровень
решения,
обеспечиваемой
простота
безопасности.
Но
существенным недостатком по сравнению с предыдущим алгоритмом
является необходимость развертывания ИОК, что, безусловно, несет
дополнительные эксплуатационные расходы.
Главной целью описываемого в настоящей статье метода является
аутентификация компонентов, участвующих в процессе загрузки ОС по сети
на тонкий клиент. Среди всех алгоритмов, реализованных в протоколах
удаленной аутентификации, можно выделить две группы:
− AAA (Authentication, Authorization, Accounting): TACACS, RADIUS и
DIAMETER;
− Kerberos.
Например, протокол аутентификации Remote Authentication Dial-in User
Service (RADIUS) [118] широко применяется как механизм аутентификации и
авторизации удалённых пользователей в условиях распределённой сетевой
инфраструктуры. В рамках данного протокола осуществляется проверка
подлинности
удаленного
пользователя
сервером
с
использованием
протоколов PAP, CHAP, EAP [119]. Но при этом доверие самому серверу
считается
безусловным.
Также
очень
популярным
механизмом
аутентификации является Kerberos, позволяющий взаимно удостоверить
подлинность клиента и сервера с использованием третьей стороны: центра
88
распределения ключей. В настоящее время разработано очень много
различных модификаций данного протокола, в том числе, построенных и на
асимметричной криптографии. Но при этом ни одну из реализаций без
внесения в нее серьезных изменений нельзя применить в схеме, когда
присутствует третий недоверенный компонент – токен. Кроме того, несмотря
на то, что Kerberos является устойчивым алгоритмом, в данном случае
присутствует формальный неблагоприятный момент – решение, построенное
на его использовании, нельзя сертифицировать по соответствующим
требованиям к средствам криптографической защиты и, как следствие,
теряется возможность его применения в ГИС.
Таким образом, использовать перечисленные существующие подходы в
рассматриваемой архитектуре терминального доступа не представляется
возможным.
В
качестве
одного
из
главных
функциональных
компонентов
рассматриваемый метод задействует защищенный usb-носитель – токен. Как
таковая, двухфакторная аутентификация с использованием usb-токенов уже
давно стала достаточно популярной. Но, как правило, в ее применении на
таком токене просто хранится ключевая пара, что позволяет сделать вторым
фактором аутентификации факт обладания таким токеном. Таким образом,
вторая
сторона
(например,
ОС)
обладает
возможностью
проверить
подлинность ключевой пары, реализуя непосредственно необходимые
вычисления.
Однако,
при
этом
не
закладывается
условие
подтверждения
подлинности ОС перед токеном – последний просто предоставляет доступ к
контейнеру с ключами, доверяя паролю пользователя. Но в рассматриваемом
в данной статье контексте токену (а, следовательно, и пользователю)
необходимо удостовериться, что с другой стороны подлинная СТД еще даже
до того, как произойдет загрузка ОС на тонкий клиент. Кроме того,
оказывается
недостаточным
просто
снабдить
ключами
участвующие
стороны: поскольку основное взаимодействие с пользователем со стороны
89
СТД осуществляет терминальный сервер (так как именно на нем хранится
загружаемый образ ОС), то необходимо предусматривать и организацию
защищенного обмена между сервером, АПМДCЗ и токеном, с которого
передается загрузчик.
Существует достаточно алгоритмов выработки общего секретного
ключа, в том числе достаточно часто присутствующих в сетевых протоколах
при клиент-серверной аутентификации. Одним из основных преимуществ
алгоритма
на
основе
ИОК
является
возможность
реализовать
аутентификацию на основе пар открытых и закрытых ключей и организовать
защищенный обмен всех участвующих сторон на основе вырабатываемых
вспомогательных ключей с использованием криптографических алгоритмов
ГОСТ, несмотря на то, что отечественного стандарта на асимметричную
криптографию в настоящий момент нет.
Формально
для
сравнения
разработанных
алгоритмов
с
существующими алгоритмами аутентификации можно выделить следующие
критерии:
1. Эффективность.
2. Вычислительная сложность.
3. Требования к памяти.
В отношении алгоритмов аутентификации вычислительная сложность
не является определяющим критерием по следующим причинам:
− небольшие объемы данных, требующих обработки в процессе
аутентификации;
− недостаточно частая повторяемость запуска алгоритма относительно
каждого клиента (только в процессе запроса доступа к информационным
ресурсам, но не в состоянии работы с ними).
В условиях отличий по эффективности данный критерий не влияет на
конечную
оценку
нецелесообразно.
алгоритма,
в
силу
чего
сравнение
по
нему
90
В
качестве
оценки
эффективности
алгоритма
удаленной
аутентификации целесообразно использовать параметр защищенности от
НСД, то есть качество решения основной задачи, стоящей перед алгоритмом
и его разработчиком. При этом требования к памяти имеет смысл
рассматривать в случаях существования соответствующих ограничений. В
данном контексте применяемых алгоритмов такие ограничения отсутствуют.
Объемы аутентификационной информации несравнимо меньше объемов
памяти на современных устройствах хранения данных.
Для
оценки
протекающие
в
защищенности
от
информационной
НСД
системе
рассмотрим
процессы,
во
удаленной
время
аутентификации.
1. Хранение информации (секрета) на стороне клиента (пользователя).
2. Хранение информации о клиенте (пользователе), используемой при
аутентификации, на стороне сервера.
3. Передача информации.
4. Проверка подлинности полученных данных и принятие решения по
аутентификации.
Каждый из перечисленных процессов потенциально уязвим. Согласно
приведенному ранее методу [111] определим вероятность неосуществления
НСД
следующим
образом
(считаем
события
возникновения
НСД
независимыми):
𝑃𝑃защ = �1 − 𝑃𝑃хрк � ∗ �1 − 𝑃𝑃хрс � ∗ �1 − 𝑃𝑃пер � ∗ �1 − 𝑃𝑃аут �, где
𝑃𝑃защ – вероятность осуществления процесса аутентификации без НСД,
𝑃𝑃хрк
–
вероятность
осуществления
НСД
за
счет
совершения
вредоносных действий на этапе хранения информации на стороне клиента
(примером таких действий может служить компрометация пароля),
𝑃𝑃хрс
–
вероятность
осуществления
НСД
за
счет
совершения
вредоносных действий на этапе хранения информации на стороне сервера,
91
𝑃𝑃пер
вероятность
–
осуществления
НСД
за
счет
совершения
вредоносных действий на этапе передачи информации (например, атака manin-the-middle),
𝑃𝑃аут
–
вероятность
осуществления
НСД
за
счет
совершения
вредоносных действий на этапе аутентификации.
В целях сравнительного анализа определим качественные показатели
для каждого из параметров в формуле для 𝑃𝑃защ : «высокая», «средняя»,
«низкая». Приведенные значения следует применять только в контексте
сравнения алгоритмов, проведенного ниже и не обязательно являются
абсолютной качественной характеристикой защищенности. Проведем анализ
алгоритмов
аутентификации
RADIUS
(как
основного
представителя
алгоритмов типа AAA), Kerberos и предложенного в рамках настоящей
работы алгоритма аутентификации на основе ИОК (Таблица 8):
Таблица 8 – Сравнительный анализ алгоритмов RADIUS, Kerberos и
алгоритма аутентификации на основе ИОК
Алгоритм
Пара
RADIUS
Kerberos
аутентификации на
метр
основе ИОК
𝑃𝑃хрк
𝑃𝑃хрс
𝑃𝑃пер
Высокая
В случае недоверенной
машины клиента
высокая вероятность
угрозы компрометации
всей системы
Высокая
Наличие общего секрета
создает ряд уязвимостей
для компрометации всей
системы
Высокая
В случае недоверенной
машины клиента
высокая вероятность
угрозы компрометации
всей системы
Низкая
Хранение ключей и
сертификатов
осуществляется в
защищенной памяти
сервера
(рассматривается
реализация Kerberos с
использованием
асимметричной
криптографии)
Высокая
Средняя
Наличие общего секрета В силу необходимости
Низкая
Пользователь хранит
пароль к токену,
хранение ключей и
сертификатов
осуществляется в
защищенной памяти
токена
Низкая
Хранение ключей и
сертификатов
осуществляется в
защищенной памяти
сервера
Средняя
Использование только
92
Пара
метр
RADIUS
Kerberos
создает угрозы,
хранения всех закрытых
связанные с анализом
ключей системы
трафика «Запрос клиента повышается ущерб от
потенциальной атаки на
– ответ сервера»
Kerberos-сервер, в
котором сосредоточена
вся критическая
информация для
системы
Пара
метр
𝑃𝑃аут
RADIUS
Kerberos
Средняя
В случае недоверенной
машины клиента
сложнее гарантировать
корректность работы
криптографических
преобразований на
стороне клиента
Средняя
В случае недоверенной
машины клиента
сложнее гарантировать
корректность работы
криптографических
преобразований на
стороне клиента
Алгоритм
аутентификации на
основе ИОК
частичной защиты от
нарушения целостности
передаваемых
критичных данных, так
как не реализован анализ
временных меток (по
сравнению с алгоритмом
Kerberos)
Продолжение Таблицы 8
Алгоритм
аутентификации на
основе ИОК
Низкая
Использование токена в
составе АПМДСЗ
Таким образом, в результате оценочного сравнения параметров
алгоритмов аутентификации можно сформировать следующее соотношение:
𝑅𝑅𝑅𝑅𝑅𝑅
𝐾𝐾𝐾𝐾𝐾𝐾𝐾𝐾
ИОК
𝑃𝑃защ
< 𝑃𝑃защ
< 𝑃𝑃защ
,
т.е. в силу того, что вероятности НСД по сформированных критериям у
алгоритма на основе ИОК ниже либо равны оценочным значениям тех же
критериев
у
алгоритмов
Kerberos
и
RADIUS,
общая
вероятность
осуществления процесса аутентификации без НСД в разработанном
алгоритме оценивается как более высокая.
3.4 Метод анализа эффективности системы защиты информации
Применение комплексных средств защиты, которые позволяют
выявлять
уязвимые
компоненты
используемых
АС
и
своевременно
определять угрозы ИБ, позволяет выделить и обеспечить защиту ключевых
активов, и, кроме того, осуществить анализ рисков с точки зрения процессов
93
компании.
При
этом
остается
актуальной
задача
по
определению
результативности и эффективности применяемой системы защиты. Основной
преследуемой при этом целью является получение качественных и
количественных оценок результатов внедряемых в рамках построения
системы
защитных
мер
(в
том
числе,
учитывая
экономическую
составляющую расходования выделяемых средств).
Согласно международному стандарту ISO 9000:2005 [120] под
эффективностью
понимается
степень
деятельности
достижения
запланированных
и
реализации
запланированной
результатов.
Анализ
эффективности используемой системы защиты дает возможность выявлять
как реальные, так и потенциальные уязвимости и недостатки в деятельности
по ИБ, своевременно и соразмерно реагировать на обнаруженные отклонения
от принятых политик, устраняя первопричины[121]. Кроме того, это
позволяет отслеживать влияние принимаемых мер на обеспечении ИБ и
определять, насколько эта деятельность сопутствует достижению целей
организации в целом.
Задача разработки метода анализа эффективности системы защиты
разбивается на три этапа:
1. Формализация процесса оценки эффективности системы защиты
[121,122].
2. Классификация угроз ИБ данных, защита которых обеспечивается с
использованием данной системы [123].
3. Разработка инструментов для оценки стойкости системы защиты
информации путем анализа рисков ИБ при имеющемся множестве угроз.
3.4.1 1 Этап: Формализация процесса оценки эффективности системы
защиты
Как показывает практика, в процессе оценки эффективности системы
защиты информации принято руководствоваться системой экспертных
оценок. Схематично сценарий реализации атаки представлен на Рисунке 13:
94
Нарушитель
Атака
Информация
Уязвимости
системы защиты
Система защиты
Рисунок 13 – Схема атаки на систему защиты
При этом необходимо принимать во внимание взаимосвязь факторов,
определяющих подверженность средств защиты информации (СЗИ) атаке
определенного типа, реализуемой нарушителем определенной категории с
использованием некоторой уязвимости системы защиты. Для дальнейшей
формализации введем определение используемых понятий.
Угроза – это потенциально возможное событие, явление или процесс,
которое посредством воздействия на компоненты информационной системы,
в том числе, системы защиты, может привести к нанесению ущерба [124].
Уязвимость – характеристика или свойство информационной системы
(в том числе системы защиты), которые могут быть использованы
нарушителем при проведении атак, являются причиной возникновения и
реализации угрозы ИБ [124].
Атака – действие нарушителя, позволяющее осуществить угрозу путём
использования уязвимостей системы защиты [124].
В контексте рассматриваемого процесса оценки эффективности СЗИ
будем считать, что нарушитель, осуществляя конкретную атаку на систему,
реализует при этом конкретную уязвимость данной системы. Таким образом,
установим
взаимно-однозначное
соответствие
между
понятиями
«Уязвимость» и «Атака» и дальше, при построении математической модели,
будем руководствоваться только вторым.
95
3.4.2 2
Этап:
Разработка
классификации
угроз
безопасности
информации, защищаемой с использованием данной системы
защиты
Исходя из рассматриваемой схемы атаки, построим классификацию
угроз безопасности информации, включающую:
1) модель предполагаемого нарушителя [125];
2) описание угроз, приводящих к нарушению конфиденциальности,
целостности и доступности информации;
3) соотношение классификации угроз с моделью нарушителя, в
результате чего получается матрица, содержащая различные варианты
реализации возможных атак.
На основе построения такой классификации угроз формируются
многокритериальные модели, идентифицирующие атаку, потенциального
нарушителя и систему защиты. Для того чтобы построить взаимосвязь между
рассматриваемыми объектами, построенные модели должны учитывать все
их
специфические
характеристики
(сложность
реализации
атак,
квалификацию нарушителя, специфику реализации системы защиты и т.п.).
3.4.3 3 Этап: Разработка математического аппарата для анализа
стойкости
средств
защиты
информации
по
отношению
к
выявленным угрозам
На
основе
построенной
классификации
угроз
осуществляется
определение критериев и инструментов для анализа стойкости применяемой
СЗИ по отношению к моделируемым атакам путем оценки возможных
рисков ИБ, в результате чего можно будет сделать вывод об их
эффективности.
Согласно международному стандарту ISO/IEC 27000 [104] под риском
понимается сочетание вероятности события и его последствий, а под
количественной оценкой риска – процесс присвоения значений вероятности и
последствий риска. Построим математическую модель, позволяющую
создать метрики для формализации данного процесса. Для этого введем
96
параметрические множества 𝐴𝐴, 𝐷𝐷 и 𝑆𝑆, где: 𝐴𝐴 ⊆ 𝐴𝐴1 × … × 𝐴𝐴𝑛𝑛 – множество
моделей атак (далее по тексту – атак), 𝐷𝐷 ⊆ 𝐷𝐷1 × … × 𝐷𝐷𝑚𝑚 – множество моделей
нарушителя, 𝑆𝑆 ⊆ 𝑆𝑆1 × … × 𝑆𝑆𝑙𝑙 – множество моделей средств защиты.
Соответственно, модель атаки представлена вектором 𝑎𝑎⃗ = (𝑎𝑎1 , … , 𝑎𝑎𝑛𝑛 ) ∈ 𝐴𝐴 ,
где 𝑎𝑎𝑖𝑖 ∈ 𝐴𝐴𝑖𝑖 (𝑖𝑖 = 1, 2, … , 𝑛𝑛), 𝐴𝐴𝑖𝑖 является множеством значений 𝑖𝑖-го параметра
модели атаки. Аналогичным образом векторами представлены модель
потенциального нарушители 𝑑𝑑⃗ = (𝑑𝑑1 , … , 𝑑𝑑𝑚𝑚 ) ∈ 𝐷𝐷, 𝑑𝑑𝑖𝑖 ∈ 𝐷𝐷𝑖𝑖 (𝑖𝑖 = 12, … , 𝑚𝑚), и
модель средства защиты 𝑠𝑠⃗ = (𝑠𝑠1 , … , 𝑠𝑠𝑙𝑙 ) ∈ 𝑆𝑆, 𝑠𝑠𝑖𝑖 ∈ 𝑆𝑆𝑖𝑖 (𝑖𝑖 = 1,2, … , 𝑙𝑙).
Для проведения количественно оценки риска определим следующие
функции:
− 𝐿𝐿: 𝑆𝑆 × 𝐴𝐴 → [0; 1] – функция, определяющая последствия риска через
значимость нанесенного ущерба от реализации атаки 𝑎𝑎⃗ на средство защиты 𝑠𝑠⃗;
− 𝑃𝑃: 𝐷𝐷 × 𝐴𝐴 → [0; 1] – функция, определяющая вероятность того, что
нарушитель 𝑑𝑑⃗ может выполнить атаку 𝑎𝑎⃗, обладая при этом достаточной
квалификацией и всеми необходимыми инструментами.
Тогда на основе этих функций для каждой атаки можно определить
понятие риска, являющегося функцией 𝐹𝐹: 𝐴𝐴 × 𝐷𝐷 × 𝑆𝑆 → [0; 1] от вероятности
возникновения
события,
повлекшего
угрозу,
и
значимости
ущерба,
следующим образом:
𝐹𝐹�𝑎𝑎⃗, 𝑑𝑑⃗, 𝑠𝑠⃗� = 𝐿𝐿(𝑠𝑠⃗, 𝑎𝑎⃗) ∗ 𝑃𝑃(𝑑𝑑⃗, 𝑎𝑎⃗),
где 𝐹𝐹 – значение риска, относящегося к атаке 𝑎𝑎⃗, реализуемой нарушителем 𝑑𝑑⃗
для взлома средства защиты 𝑠𝑠⃗.
Для определения функции 𝐿𝐿(𝑠𝑠⃗, 𝑎𝑎⃗) рассмотрим функцию 𝐿𝐿𝑞𝑞𝑞𝑞 : 𝑆𝑆𝑞𝑞 × 𝐴𝐴𝑟𝑟 →
𝑍𝑍+ , характеризующую, насколько параметр атаки 𝑎𝑎 и параметр средства
защиты 𝑠𝑠 влияют друг на друга (𝑍𝑍+ – множество неотрицательных целых
чисел). Функция 𝐿𝐿𝑞𝑞𝑞𝑞 определяется следующим образом:
97
0, если параметр 𝑠𝑠 ∈ 𝑆𝑆𝑞𝑞 СЗИ не позволяет применить атаку с
параметром 𝑎𝑎 ∈ 𝐴𝐴𝑟𝑟 ;
1, если нельзя однозначно определить применимость атаки с
𝐿𝐿𝑞𝑞𝑞𝑞 (𝑠𝑠, 𝑎𝑎) =
параметром 𝑎𝑎 ∈ 𝐴𝐴𝑟𝑟 к СЗИ с параметром 𝑠𝑠 ∈ 𝑆𝑆𝑞𝑞 без знания
значений других параметров;
2, если атака с параметром 𝑎𝑎 ∈ 𝐴𝐴𝑟𝑟 применима к СЗИ с
параметром 𝑠𝑠 ∈ 𝑆𝑆𝑞𝑞 .
Например, если в системе аутентификации, входящей в состав СЗИ, не
настроены требования к сложности пароля (использование специальных
символов, верхний и нижний регистры и т.д.), то атака «перебор по словарю»
на такую систему с высокой вероятностью завершится с успехом. Степень
взаимного влияния параметров системы защиты и атаки определяется на
основе экспертных оценок.
Тогда значение ущерба от реализации атаки 𝑎𝑎⃗ на средство защиты
𝑠𝑠⃗ ∈ 𝑆𝑆 определяется следующим образом:
где
𝐿𝐿(𝑠𝑠⃗, 𝑎𝑎⃗) = � ��𝐿𝐿𝑞𝑞𝑞𝑞 (𝑠𝑠, 𝑎𝑎)�,
�𝐿𝐿𝑞𝑞𝑞𝑞 �: 𝑆𝑆𝑞𝑞 × 𝐴𝐴𝑟𝑟 → [0; 1]
–
𝑎𝑎∈𝐴𝐴𝑟𝑟 𝑠𝑠∈𝑆𝑆𝑞𝑞
нормированная
функция,
определяемая
следующим образом:
�𝐿𝐿𝑞𝑞𝑞𝑞 (𝑠𝑠, 𝑎𝑎)� =
𝐿𝐿𝑞𝑞𝑞𝑞 (𝑠𝑠, 𝑎𝑎)
.
∑𝑠𝑠𝑖𝑖∈𝑆𝑆𝑞𝑞 𝐿𝐿𝑞𝑞𝑞𝑞 (𝑠𝑠𝑖𝑖 , 𝑎𝑎)
Таким образом подразумевается, что если реализации атаки 𝑎𝑎⃗
противоречит хотя бы один из параметров средства защиты 𝑠𝑠⃗, то функция
𝐿𝐿(𝑠𝑠⃗, 𝑎𝑎⃗) примет нулевое значение, т.е. даже при успешном исходе атака не
причинит никакого ущерба средству защиты. Например, если атака
подразумевает наличие удаленного доступа, а конкретное СЗИ с точки
зрения своего функционала не имеет подключения к сети, то такая атака не
может быть применима в данном случае, а ущерб от нее будет нулевым.
98
Аналогично определяется и функция 𝑃𝑃(𝑑𝑑⃗, 𝑎𝑎⃗), характеризующая
взаимное влияние параметров атаки 𝑎𝑎⃗ и нарушителя 𝑑𝑑⃗:
𝑃𝑃�𝑑𝑑⃗, 𝑎𝑎⃗� = � � ‖𝑃𝑃𝑡𝑡𝑡𝑡 (𝑑𝑑, 𝑎𝑎)‖ = � �
𝑎𝑎∈𝐴𝐴𝑟𝑟 𝑑𝑑∈𝐷𝐷𝑡𝑡
𝑎𝑎∈𝐴𝐴𝑟𝑟 𝑑𝑑∈𝐷𝐷𝑡𝑡
𝑃𝑃𝑡𝑡𝑡𝑡 (𝑑𝑑, 𝑎𝑎)
.
∑𝑑𝑑𝑖𝑖 ∈𝐷𝐷𝑡𝑡 𝑃𝑃𝑡𝑡𝑡𝑡 (𝑑𝑑𝑖𝑖 , 𝑎𝑎)
В качестве примера такого влияния можно рассмотреть следующий:
если предполагаемый нарушитель обладает информацией о применяемых
атрибутах в системе разграничения доступа, то увеличивается вероятность
успешной реализации атаки по повышению полномочий пользователя в
информационной системе.
Тогда функция 𝐹𝐹�𝑎𝑎⃗, 𝑑𝑑⃗, 𝑠𝑠⃗�, определяющая значение риска, примет вид:
𝐹𝐹�𝑎𝑎⃗, 𝑑𝑑⃗, 𝑠𝑠⃗� = 𝐿𝐿(𝑠𝑠⃗, 𝑎𝑎⃗) ∗ 𝑃𝑃�𝑑𝑑⃗, 𝑎𝑎⃗� = � ��𝐿𝐿𝑞𝑞𝑞𝑞 (𝑠𝑠, 𝑎𝑎)� ∗ � � ‖𝑃𝑃𝑡𝑡𝑡𝑡 (𝑑𝑑, 𝑎𝑎)‖.
Зададим
некоторое
𝑎𝑎∈𝐴𝐴𝑟𝑟 𝑠𝑠∈𝑆𝑆𝑞𝑞
пороговое
значение
𝑎𝑎∈𝐴𝐴𝑟𝑟 𝑑𝑑∈𝐷𝐷𝑡𝑡
𝑓𝑓𝑝𝑝 ,
подразумевающее
допустимый уровень риска. Таким образом, если 𝐹𝐹�𝑎𝑎⃗, 𝑑𝑑⃗, 𝑠𝑠⃗� > 𝑓𝑓𝑝𝑝 , то считаем,
что в результате атаки 𝑎𝑎⃗ ∈ 𝐴𝐴, реализованной нарушителем 𝑑𝑑⃗ ∈ 𝐷𝐷, может быть
нанесен ущерб средству защиты 𝑠𝑠⃗ ∈ 𝑆𝑆. Пороговое значение 𝑓𝑓𝑝𝑝 определяется
индивидуально в отношении каждой системы защиты с учетом критичности
защищаемой информации.
Таким образом, к отдельным средствам защиты (или группам средств)
может быть применимы разные атаки (классы атак). Тот же вывод можно
сделать и в отношении нарушителей. Обозначим за 𝑀𝑀𝐴𝐴 = {𝑎𝑎⃗ ∈ 𝐴𝐴: 𝐹𝐹�𝑎𝑎⃗, 𝑑𝑑⃗, 𝑠𝑠⃗� >
𝑓𝑓𝑝𝑝 , для 𝑠𝑠⃗ ∈ 𝑆𝑆, 𝑑𝑑⃗ ∈ 𝐷𝐷} – множество атак, которым подвержена система защиты,
состоящая из средств 𝑠𝑠⃗, в условиях, когда ей угрожают нарушители 𝑑𝑑⃗ при
заданном уровне риска 𝑓𝑓𝑝𝑝 . Таким образом, оценка эффективности системы
защиты определяется мощностью множества 𝑀𝑀𝐴𝐴 :
𝐸𝐸 = 𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐(𝑀𝑀𝐴𝐴 ),
а также способность системы противостоять атакам, входящим в это
множество. Чем больше значение 𝐸𝐸, тем менее эффективной считается
99
применяемая система защиты. Приемлемое значение эффективности (т.е.
мощности) вычисляется для каждой системы индивидуально экспертным
методом, с учетом полученных рисков, стоимости защищаемых активов и
затрат, необходимых на усовершенствование системы.
Необходимо отметить, что в данном методе оценки не учитывается
возможность сговора нарушителей, что соответствующим образом влияет на
их потенциал в отношении системы защиты.
Тем
не
производить
менее,
оценку
разработанный
в
результате
эффективности
применения
метод
позволяет
системы
защиты
информации, функционирующей в информационной системе, опираясь на
построение и анализ многокритериальных классификаций систем защиты,
угроз и потенциальных нарушителей. На основе этих классификаций
устанавливается
зависимость
между
возможностями
нарушителя,
особенностями системы защиты и сценариями реализации атаки. На выходе
получается критерий, позволяющий определить эффективность системы
защиты – множество атак, которым она может быть подвержена.
Достоинство разработанного математического аппарата определяется в
формализации подхода к анализу защищенности ИС. При соответствующем
уровне автоматизации и наличии проработанной базовой классификации
угроз
использование
сократить
время
представленного
специалиста,
метода
позволит
осуществляющего
аудит,
значительно
на
анализ
реализованных мер защиты информации. Полученный результат позволяет
моделировать эффект применения дополнительных средств и мер ИБ и
обосновать экономическую целесообразность деятельности по защите
информации.
3.4.4 Сравнение и анализ предлагаемого метода с существующими
методами оценки эффективности
Существующие методы анализа эффективности СЗИ можно разделить
на следующие основные группы [126,127]:
− детерминистические методы;
100
− методы многокритериальной оптимизации;
− логико-вероятностные методы;
− моделирование.
Детерминистический метод заключается в проверке на соответствие
определенным требованиям. Степень соответствия СЗИ определяет степень
его эффективности. Примером могут служить реализации такого метода в
стандартах РД ГТК по АС [43] и СТР-К [128].
Основой
методов
многокритериальной
оптимизации
является
агрегирование информации о частных показателях качества и последующий
выбор наилучшего варианта или в случае анализа защищенности оценки
расстояния между текущим вариантом и идеальным. В качестве примера
будем использовать метод смещенного идеала.
Логико-вероятностные
методы
основываются
на
определении
сценариев действий нарушителя, оценке вероятностей и ущерба от данных
действий.
Затем
выполняется
определение
количественных
или
качественных показателей рисков отдельных сценариев. Эффективность СЗИ
основывается
на
возможности
нейтрализовать
риски,
признанные
значимыми. Примером могeт служить нормативная база ФСТЭК в области
защиты персональных данных [129,130,131] и серия международных
стандартов NIST [132].
Моделирование
основывается
на
проведении
вычислительного
эксперимента (имитационное моделирование) или на попытке осуществить
НСД (физическое моделирование) в реальной системе или ее копии. В
качестве
примера
будем
рассматривать
физическое
моделирование
(тестирование на проникновение).
Предлагаемый в настоящей работе метод анализа эффективности СЗИ
можно отнести к логико-вероятностным методам.
Будем использовать следующие критерии оценки методов:
101
1. Полнота
воздействий.
и
Важно
непересекаемость
быть
рассматриваемых
уверенными,
что
были
вредоносных
рассмотрены
и
проанализированы все возможные потенциальные воздействия.
2. Детальность проработки сценариев действий нарушителей, что
позволяет снизить влияние ошибок при субъективных суждениях об
оцениваемых параметрах и повысить полноту рассматриваемых сценариев.
3. Четкость критериев, необходимая для полезной интерпретации
результатов анализа.
4. Физическая
обоснованность
результатов,
необходимая
для
сохранения связи между моделируемым объектом и моделью.
Нормативные документы в области защиты автоматизированных
систем предлагают набор требований, на основе степени выполнения
которых делается вывод о защищенности системы. В результате получаются
четкие критерии, однако отсутствует детальная проработка действий
нарушителя, сценариев, что в условиях постоянного появления новых угроз
безопасности дает низкую физическую обоснованность результатов анализа
защищенности.
Метод смещенного идеала хорошо решает задачу выбор средств
защиты при уже проведенном исследовании нарушителя и атак. Поэтому он
имеет в качестве недостатков низкую детализацию, полноту и физическую
обоснованность. В противовес к этому четкость критериев оказывается
проработанной на высоком уровне.
Нормативная база ФСТЭК в области защиты персональных данных и
стандарты NIST предполагают детальное рассмотрение перечня возможных
угроз, однако отсутствуют четкие предложения по достижению полноты.
Вследствие этого физическая обоснованность оказывается средней. Критерии
получаются в виде угроз, часто абстрактных, но не в виде конкретных
действий, что, тем не менее, может быть компенсировано проведением
дополнительных работ со стороны моделирующего эксперта.
102
Тестирование на проникновение является эффективным методом с
точки зрения физической обоснованности и четкости критериев, однако
гарантировать полноту не представляется возможным. Это влияет на
детализацию исследований.
Предлагаемый в рамках настоящего диссертационного исследования
метод анализа эффективности СЗИ подразумевает детальную проработку
атак непосредственно на СЗИ, что является отличительной чертой от
остальных методов. Введение многопараметрических моделей нарушителя,
атак и самих средств, образующих систему защиты, позволяет достичь
полноты,
непересекаемости
обоснованность
получается
и
четкости
также
высокой
критериев.
за
счет
Физическая
физической
обоснованности выбранных параметров.
Результаты оценочного сравнения проанализированных критериев для
указанных методов приведены ниже (Таблица 9):
103
Таблица 9 – Результаты оценочного сравнения методов оценки
защищенности СЗИ
Полнота и
Метод
непересекаемость
Методы оценки
согласно РД АС
Детальность
Четкость
Физическая
критериев обоснованность
Средняя
Низкая
Высокая
Низкая
Низкая
Средняя
Высокая
Низкая
Средняя
Высокая
Средняя
Средняя
Низкая
Средняя
Высокая
Высокая
Высокая
Высокая
Высокая
Высокая
Метод
смещенного
идеала
Методы оценки
согласно
ФСТЭК ПДн /
NIST
Тестирование на
проникновение
Метод анализа
эффективности
СЗИ
3.5 Метод повышения степени доверия безопасности вычислительной
среды на тонких клиентах, входящих в состав СТД
Как было определено выше, главным показателем степени доверия к
безопасности
вычислительной
гарантированность
корректного
среды
на
тонких
выполнения
клиентах
функций
ИБ.
является
Согласно
введенному определению, формируемая на тонких клиентах ДВС должна
включать все составные компоненты и механизмы защищенной СТД,
которые отвечают за реализацию политики безопасности, и обеспечивать
доверенное выполнение следующих функций: защиту конфиденциальности
обрабатываемых данных, разграничение прав доступа к информации и
выполнению операций, контроль аутентичности поступающих на обработку
данных, целостность кода собственных программных компонентов и
104
интерфейс взаимодействия с небезопасной средой. Все перечисленные
функции в зависимости от их реализации, делятся на два блока:
выполняемые средствами защиты, функционирующими в рамках ОС, и
выполняемые до передачи управления на загруженный с сервера образ.
Согласно стандартам Гостехкомиссии РФ, корректность реализации
механизмов
защиты
информации
определяется
в
процессе
оценки
эффективности применяемой системы защиты. Степень доверия при этом
оценивается
по
выполнению
требований,
указанных
в
Таблице
5.
Разработанные в рамках настоящей диссертационной работы алгоритмы и
методы позволяют реализовать часть механизмов ИБ, обеспечивающих
выполнение недостающие требования (см. п. 2.2) с учетом архитектуры ТК.
Для решения комплексной задачи повышения степени доверия безопасности
СТД и построения ДВС на тонких клиентах в рамках организации был
разработан соответствующий метод, который использует указанные выше
разработки в качестве недостающих ранее механизмов ИБ.
В качестве входных данных для метода необходимо определить
начальную степень доверия:
𝑛𝑛
𝑇𝑇𝑇𝑇исх = � 𝑤𝑤𝑖𝑖 ∙ 𝑅𝑅исх.𝑖𝑖 ,
𝑖𝑖=1
где 𝑇𝑇𝑇𝑇исх – исходная степень доверия;
𝑤𝑤𝑖𝑖 – вес параметра, определяемый в соответствии с Таблицей 6;
𝑅𝑅исх.𝑖𝑖 – значение параметра, характеризующего выполнение требований в
исходной системе, принимает значения 0 (не выполнено) или 1 (выполнено).
Для выполнения необходимых требований по безопасности в СТД в
целях повышения степени доверия вычислительной среды необходимо
реализовать следующие этапы:
Этап
1.
Разработка/корректировка
Политики
безопасности
организации, описывающей совокупность руководящих принципов, правил,
процедур и практических приемов в области безопасности, которыми
105
руководствуется организация в своей деятельности. На данном этапе
необходимо определить пороговое значение уровня доверия.
Этап 2. Внедрение разработанных режимных мер (организационных и
технических) на уровне организации, владеющей СТД.
Этап 3. Обеспечение наличия компонентов инфраструктуры открытых
ключей, включающей сервер удостоверяющего центра, сервис проверки
отозванности сертификатов (служба Online Certificate Status Protocol (OCSP)
или размещение в сети актуальных списков отозванных сертификатов (CRL,
Certificate Revocation List).
Этап 4. Генерация пар открытых и закрытых ключей, выпуск
сертификатов
открытых
ключей
для
всех
участников
сетевого
взаимодействия в рамках реализации аутентификации и процесса доверенной
загрузки ОС (сервер, токены пользователей). Сертификаты открытых ключей
сервера и токенов подписываются закрытым ключом УЦ.
Этап 5. Интеграция СЗИ (АПМДСЗ) в состав ТК, реализующих
функции ДВС до загрузки ОС в оперативно память ТК (включая реализацию
алгоритма аутентификации пользователя, тонкого клиента и сервера на
основе ИОК и метода доверенной загрузки ОС на ТК).
Этап 6. Интеграция программных СЗИ и настройка встроенных
механизмов ОС в целях реализации функций ДВС, включающих систему
разграничения доступа, замкнутую программную среду, антивирусную и
проактивную защиту.
Этап 7. Проверка эффективности применяемой системы защиты в
целях оценки степени доверия безопасности вычислительной среды на
тонких клиентах. В рамках данного этапа необходимо установить
периодичность (для плановой оценки) и условия (для внеплановой оценки)
проведения оценки эффективности.
Реализация
выполнение
включающую
перечисленных
указанных
этапов
действий,
поддержание
в
а
подразумевает
непрерывную
актуальном
состоянии
не
разовое
деятельность,
каждого
из
106
участвующих
безопасности,
перевыпуск
компонентов:
регулярный
пар
постоянная
актуализация
(рекомендуемая
периодичность
закрытых
и
открытых
ключей,
Политики
–
1
год)
поддержание
работоспособности службы OCSP, обновление используемых наложенных
программных средств, мониторинг событий безопасности и т.д.
После реализации указанных этапов необходимо произвести расчет
результирующую степень доверия по следующей формуле:
𝑛𝑛
𝑇𝑇𝑇𝑇рез = � 𝑤𝑤𝑖𝑖 ∙ 𝑅𝑅рез.𝑖𝑖 ,
𝑖𝑖=1
где 𝑇𝑇𝑇𝑇рез – результирующая степень доверия;
𝑤𝑤𝑖𝑖 – вес параметра;
𝑅𝑅рез.𝑖𝑖 – значение параметра, характеризующего выполнение требований в
защищенной системе; принимает значения 0 (не выполнено) или 1
(выполнено).
Если значение результирующего уровня доверия выше порогового
значения, то вычислительная среда считается доверенной.
По результатам периодического выполнения этапа 7 необходимо
сохранять исторические значения 𝑇𝑇𝑇𝑇рез . Если между плановыми процессами
оценки значение 𝑇𝑇𝑇𝑇рез определяется ниже порогового, то необходимо
увеличить частоту плановых оценок. Вычислить время до следующей
проверки можно по следующей формуле:
𝑇𝑇оц = 𝑘𝑘з
𝑇𝑇𝑇𝑇гр − 𝑇𝑇𝑇𝑇0
,
𝑎𝑎
где 𝑇𝑇оц – время от текущей оценки до следующей;
𝑇𝑇𝑇𝑇гр – граничное значение уровня доверия;
𝑇𝑇𝑇𝑇0 – текущее значение уровня доверия;
𝑘𝑘з – коэффициент запаса (𝑘𝑘з < 1), необходимый для компенсации на случай
отклонения зависимости уровня доверия от времени от линейной,
107
определяется статистически по результатам изменения периодичности
проведения оценки уровня доверия;
𝑎𝑎 – скорость падения уровня доверия, определяется следующей формулой:
𝑎𝑎 =
𝑇𝑇𝑇𝑇0 − 𝑇𝑇𝑇𝑇−1
𝑇𝑇′оц
где 𝑇𝑇𝑇𝑇−1 – значения уровня доверия при предыдущей оценке;
𝑇𝑇′оц – временной отрезок между прошлой и текущей оценкой уровня
доверия.
При нестабильности параметра 𝑎𝑎 допускается применение его
усреднения на несколько интервалов. Изменение периодичности проведения
оценки рекомендуется делать при выявлении падения текущего уровня
оценки ниже порогового.
При этом если предположить, что перечисленные в п. 2.2 требования
реализованы существующими механизмами ИБ в полной мере, то оценка
исходной степени доверия составит: 𝑇𝑇𝑇𝑇исх = 0,6. Полноценная реализация
разработанных в рамках настоящего диссертационного исследования
алгоритмов и методов позволит установить параметр 𝑅𝑅рез.𝑖𝑖 = 1 для
следующих требований:
− управление потоками информации;
− регистрация и учет событий ИБ;
− криптографическая подсистема;
− идентификация, проверка подлинности и контроль доступа субъектов
к терминалам, ЭВМ, узлам сети ЭВМ, каналам связи, внешним устройствам
ЭВМ;
− обеспечение целостности программных средств и обрабатываемой
информации.
Таким
образом,
при
заданных
значениях
весов
результирующая степень доверия составит 𝑇𝑇𝑇𝑇рез = 0,96.
𝑤𝑤𝑖𝑖
полученная
108
3.6 Выводы к третьей главе
В третьей главе приведен сравнительный анализ существующих
методов контроля целостности информации, описан метод загрузки и
проверки целостности образа ОС на ТК, а также прототип аппаратнопрограммного
модуля
доверенной
сетевой
загрузки
(АПМДСЗ),
реализующий разработанные в рамках диссертационного исследования
методы и алгоритмы. Приведено описание алгоритмов аутентификации
участников информационного взаимодействия при удаленной загрузке ОС на
ТК с использованием одноразовых паролей и с использованием ИОК,
приведено сравнение данных алгоритмов с существующими алгоритмами
аутентификации. Приведено описание метода анализа эффективности
системы защиты информации, а также метода повышения степени доверия
безопасности ВС на ТК на основе разработанных алгоритмов и методов.
4
Глава.
Разработка
прототипа
аппаратно-программного
модуля
доверенной сетевой загрузки и апробация разработанных алгоритмов
и методов на целевой системе терминального доступа
4.1 Разработка прототипа аппаратно-программного модуля доверенной
сетевой загрузки
4.1.1 Описание аппаратных компонентов
Для реализации и тестирования разработанных алгоритмов и методов
был создан прототип аппаратно-программного модуля, основной целевой
функцией которого является доверенная сетевая загрузка операционной
системы
на
тонкие
клиенты.
Микропрограмма
данного
модуля,
осуществляющая весь процесс загрузки образа и передачи на него
управления, включает в том числе разработанные алгоритм аутентификации
и метод контроля целостности ОС на основе ИОК.
На уровне аппаратного взаимодействия токена, АПМДСЗ и тонкого
клиента процесс загрузки осуществляется в следующем виде (Рисунок 14):
109
1) Загрузчик хранится на защищенной памяти внешнего носителя
(токена). Доступ к BIOS осуществляется только в режиме чтения и только с
полномочиями привилегированного пользователя – администратора ИБ (тем
самым обеспечивается защита BIOS от перезаписи), поэтому данный
компонент рассматривается как доверенный.
2) BIOS (загруженный в RAM) обращается к токену для получения
доступа к загрузчику.
3) BIOS загружает 512 байт минизагрузчика (MINI Boot Loader,
минимальный загрузчик размером 512 байт, предназначенный для загрузки
не самого образа ОС, а его стандартного загрузчика) в RAM.
4) Минизагрузчик обращается к защищенной памяти токена, откуда,
после успешной аутентификации пользователя (ввода пароля для доступа к
защищенной памяти), считывается основной загрузчик.
5) Целостность данного загрузчика гарантирована. Он загружается в
RAM, после чего обращается к сетевой карте и выполняет загрузку образа
ОС.
6) Происходит проверка целостности загруженного образа
7) Выполняется передача управления на проверенный образ ОС.
Защищенный
USB-носитель
Тонкий клиент
Сервер
BIOS
Загрузчик
RAM
Образ ОС
АПМДСЗ
Рисунок 14 – Взаимодействие токена, АПМДСЗ, сервера и тонкого клиента
110
Для реализации описываемого АПМДСЗ используется сетевая карта
Hewlett-Packard NC7770 (3Com) 3C996B-T BCM5701KHB (Рисунок 15) со
следующими характеристиками [133] (Таблица 10):
Таблица 10 – Характеристики сетевой карты
Технические характеристики:
Категория
Proliant
Подкатегория
Adapters
Поколение
PCI/PCI-X
Партийный номер
244948-B21
Скорость
10/100/1000Мбит/сек
Тип
Network Card
Рисунок 15 – Сетевая карта Hewlett-Packard NC7770
Выбор данной сетевой карты обусловлен поддержкой возможности
замены на ней проприетарных PXE ROM, с множеством дополнительных
функций, таких как DNS, HTTP, ISCSI.
Сетевая
карта
АМДСЗ
отображается
в
качестве
загрузочного
устройства в меню загрузки BIOS. Некоторые BIOS не показывают
конкретные устройства в меню загрузки, а вместо этого показывают общий
вариант, такие как "Загрузка с LAN". В этом случае используется опция
NONPNP_HOOK_INT19 сборки времени.
В
качестве
токена
для
защищенного
хранения
загрузчика
и
используемых в алгоритмах криптографических ключей и сертификатов
111
выбран
USB-токен
JaCarta
PKI
(Рисунок
16)
со
следующими
характеристиками (Таблица 11):
Таблица 11 - Характеристики JaCarta PKI
Характеристики JaCarta PKI
Микроконтроллер
Защищённый смарт-карточный чип
(AT90SC25672RCT), имеющий специальную
сертифицированную защиту и на аппаратном, и
на программном уровне (Secure by design), что
позволяет успешно противостоять всем
известным угрозам безопасности, методам взлома
и клонирования.
Размер EEPROM-памяти
на чипе
72 КБ
Объём доступной
EEPROM-памяти для
~46 КБ
хранения
пользовательских данных
Поддерживаемые
криптографические
алгоритмы
− AES, DES, 3DES, RSA
− криптография на эллиптических кривых
− аппаратная генерация ключей для RSA и
криптографии на эллиптических кривых;
− алгоритмы согласования ключей
− функции хэширования: SHA-1, SHA-224
(эллиптические кривые), SHA-256, SHA-384,
SHA-512;
− генератор
последовательностей
случайных
чисел.
112
Рисунок 16 – JaCarta PKI
Проприетарная прошивка используемой сетевой карты была заменена
на разработанную микропрограмму (PXE-код) с реализованными методами и
алгоритмами. PXE-код, прописанный в сетевой карте, получает специальный
загрузчик (Network Bootstrap Program) с TFTP-сервера в сети, после чего
передаёт ему управление. Загрузчик имеет доступ к программным
интерфейсам (API) PXE (Preboot, UDP, TFTP, UNDI) и, используя их,
загружает с сервера операционную систему согласно реализованным
алгоритмам и методам.
В память USB-токена JaCarta PKI был записан загрузчик ОС. Для
реализации
взаимной
аутентификации
токена,
тонкого
клиента
и
пользователя были сгенерированы пары закрытых/открытых ключей для
токена и терминального сервера. На открытые ключи были выданы
сертификаты удостоверяющим центром. В защищенной памяти JaCarta PKI
были записаны пара ключей (открытый закрытый), сертификат открытого
ключа токена, сертификат открытого ключа удостоверяющего центра (для
возможности
проверки
подписи
образа
ОС
и
самого
сертификата
терминального сервера, получаемого вместе с образом).
4.1.2 Программная реализация разработанных алгоритмов и методов
Микропрограмма, заменяемая проприетарную прошивку сетевой
карты, включает в себя следующие программные модули (Рисунок 17),
реализующие разработанные алгоритмы и методы:
1) Модуль инициации загрузки;
113
2) Модуль взаимной аутентификации USB-токена, пользователя и
тонкого клиента;
3) Модуль загрузки ОС в оперативную память тонкого клиента;
4) Модуль проверки целостности образа.
Модуль инициации
загрузки
Начало
Выход
Передача
управления на ОС
да
Модуль взаимной
аутентификации
Аутентификация
успешна?
Модуль проверки
целостности ОС
Модуль загрузки ОС
Проверка
успешна?
нет
да
Сообщение
об ошибке
нет
Рисунок 17 – Процесс загрузки и контроля целостности ОС
Для создания загружаемого образа ОС используются следующие
сторонние утилиты и библиотеки, написанные на языках C и Perl: catrom.pl,
diffsize.pl, disrom.pl, efifatbin.c, efirom.c, einfo.c, elf2efi.c, fixrom.pl, fnrec.pl,
geniso, genkeymap.pl, gensdsk, blob, get-pci-ids, hijack.c, iccfix.c, licence.pl,
mergerom.pl,
modrom.pl,
mucurses_test.c,
parserom.pl,
relicense.pl,
romcheck.pl,
niclist.pl,
nrv2b.c,
sortobjdump.pl,
padimg.pl,
swapdevids.pl,
symcheck.pl, zbin.c.
Для реализации Модуля инициации загрузки и Модуля загрузки ОС в
оперативную память тонкого клиента используются функции из библиотеки
iPXE версии 1.0.0.
В Модуле взаимной аутентификации USB-токена, пользователя и
тонкого клиента реализуются криптографические алгоритмы ГОСТ (ГОСТ
28147-89, ГОСТ 34.10-2012, ГОСТ 34.10-2012), RSA на языке C:
gost_28147.c, gost_34_10.c, gost_34_11.c, rca.c.
В Модуле проверки целостности образа используется алгоритм хэшфункции SHA-2 на ключе длиной 512 бит, реализация на языке C.
Для перепрошивки сетевой карты использовалась утилита flashrom,
позволяющая записывать новую микропрограмму через протокол SSH.
114
4.2 Апробация метода создания доверенной вычислительной среды на
тонких клиентах
В качестве объекта для апробации разрабатываемого метода создания
ДВС рассматривался медицинский центр, в состав вычислительной
инфраструктуры которого входит СТД с аппаратными тонкими клиентами в
качестве пользовательских рабочих мест.
Целью эксперимента являлось:
− выяснить, насколько разработанные алгоритмы и методы, а также
реализующий их АПМДСЗ соответствуют предъявляемым требованиям и
обеспечивают создание ДВС на тонких клиентах;
− определить, насколько эффективна концепция ДВС в рамках
обеспечения ИБ для СТД;
− экспертным методом определить состоятельность метода оценки
эффективности СЗИ;
− экспертным
способом
качественно
оценить
результативность
разработанного метода повышения степени доверия безопасности ВС на ТК.
4.3 Описание объекта исследования
В состав пользователей СТД медицинского центра входят:
− медицинский персонал, включающий заведующих отделениями и
врачей, осуществляющих прием пациентов;
− сотрудники
клинико-диагностической
лаборатории,
заносящие
результаты анализов и исследований в медицинские карты пациентов;
− административный персонал, включая сотрудников подразделений
маркетинга и рекламы, программ ДМС и др.;
− сотрудники
подразделения
информационных
технологий
и
безопасности.
Наряду с должностями системных администраторов в рассматриваемом
медицинском центре выделен отдельный сотрудник, занимающий должность
администратора информационной безопасности (администратор ИБ).
115
Информация, обрабатываемая
в рамках основной деятельности
медцентра, включает:
− персональные данные пациентов (в том числе, данные, составляющие
медицинскую тайну);
− персональные данные сотрудников и кандидатов на трудоустройство;
− информацию по собственным разрабатываемым препаратам;
− иную информацию, относящуюся к коммерческой тайне.
Все перечисленные категории данных относятся к конфиденциальной
информации.
Помимо
необходимые
меры
желания
руководства
медцентра
защиты
обрабатываемой
обеспечить
конфиденциальной
информации, некоторые категории данных попадают также под защиту
законодательства о персональных данных [129,130,131,134], об основах
охраны
здоровья
нормативных
[135],
актов
трудового
законодательства[136]
предъявляющих
[137],
требования
и
по
иных
мерам,
обязательным к применению для защиты обрабатываемой информации.
Таким образом, в случае, если для защиты данных будут применяться
средства
криптографической
защиты
информации,
они
должны
соответствовать требованиям Приказа ФСБ РФ №378 [131].
Исследуемая СТД состоит из рабочих мест пользователей (аппаратных
бездисковых
тонких
клиентов),
расположенных
в
территориально
распределенных клиниках, которые имеют доступ к сети Интернет. Тонкие
клиенты используются для удаленного подключения к ЦОД, в котором
расположено серверное оборудование: сервера приложений, сервера БД,
почтовый сервер, терминальный сервер. ЦОД территориально размещен в
отдельном
запираемом
серверном
помещении
на
территории
контролируемой зоны (КЗ). Функционал тонких клиентов позволяет
пользователю ввести учетные данные, подключиться к терминальному
серверу в ЦОД в целях загрузки ОС, осуществлять необходимые
подключения к остальным серверам в соответствии с должностными
обязанностями и назначенными полномочиями. Непосредственно в клиниках
116
защищаемые данные не хранятся и могут обрабатываться только при
подключении тонких клиентов к серверам в ЦОД. Схема подключения к
ЦОД изображена ниже (Рисунок 18):
Медицинский Центр
Медицинские
подразделения
ЦОД
LDAP
Пользователи
Медицинской ИС
Административные
подразделения
Внешний
Почтовый сервер
Пользователи
Административной ИС
Web-сервер
Центр обработки
вызовов
Удостоверяющий
центр
МИС
СУБД
Внутренний
Почтовый сервер
МИС
Датацентр
ServiceDesk
Файловые
серверы
1С
Приложение
1С
СУБД
CRM
Медицинская ИС
Административная ИС
Терминальные
серверы
Пользователи
ИСПДн «Медицина»
Интернет
Рисунок 18 – Схема взаимодейтсвия компонентов МИС
К основным предпосылкам, приводящим к возможности реализации
анализируемых угроз, относятся:
− на рабочих местах пользователей присутствует подключение к сети
Интернет;
− осуществляется передача защищаемой информации по открытым
каналам связи;
− осуществляется передача паролей по открытым каналам;
− отсутствуют средства защиты информации;
117
− защищаемая информация отображается на экранах пользователей
СТД;
− отсутствуют инструкции пользователей по работе с защищаемой
информацией, программным и аппаратным обеспечением;
− отсутствуют инструкции пользователей по работе с оборудованием;
− отсутствуют инструкции пользователей по работе с учетной
информацией;
− отсутствует обучение пользователей основам ИБ.
На объекте реализованы следующие защитные меры:
− в здании реализован пропускной режим, присутствует охрана;
− доступ в помещения ограничен, двери запираются на ключ;
− в кабинетах используются жалюзи на окнах, мониторы расположены
таким
образом,
чтобы
исключить
несанкционированный
просмотр
выводимой информации;
− для
аутентификации
пользователей
используется
встроенные
механизмы ОС (логин/пароль);
− доступ к сетевому оборудованию и внутренним каналам связи
ограничен (каналы связи убраны в короба, сетевое оборудование находится в
запираемом серверном шкафу);
−в
медицинском
центре
реализуются
программы
повышения
лояльности персонала.
В состав анализируемых активов медицинского центра входят:
− серверное
оборудование
приложений и баз данных);
− аппаратные тонкие клиенты;
− сетевое оборудование;
− средства защиты информации;
− внешние каналы связи;
− внутренние каналы связи;
(терминальные
серверы,
серверы
118
− конфиденциальная информация;
− персонал.
4.4 Построение классификации угроз для ОИ
В процессе построении модели нарушителя и классификации угроз для
Медицинского центра использовались базовые модели и классификации,
разработанные в рамках настоящего диссертационного исследования (Раздел
2.1). В силу того, что обрабатываемая на объекте исследования информация
не является актуальной и значимой для сотрудников спецслужб иностранных
государств,
будем
считать
нарушителя
Н3
не
актуальным
для
рассматриваемой системы.
Поскольку разрабатываемые в рамках настоящего исследования
методы создания ДВС направлены на защиту именно рабочих мест
пользователей, и в качестве начальных условий предполагалось, что защита
серверных компонентов СТД и внешних каналов связи за рамками
исследования, в предлагаемой классификации угроз не рассматриваются
угрозы, направленные на нарушение конфиденциальности, целостности,
доступности данных активов.
Используемые дополнительные обозначения и сокращения:
− МПО – микропрограммное обеспечение;
− BIOS - Basic Input / Output System;
− UEFI - Unified Extensible Firmware Interface;
− НИ – носитель информации;
− ФС – файловая система;
− СУ – сетевой узел.
В случае, когда в качестве объекта угрозы указаны составные
аппаратные или программные компоненты (МПО, ПО, реестр, ФС и др.),
данные объекты рассматриваются в отношении следующих активов: тонкие
клиенты,
сетевое
оборудование,
СЗИ.
Построенная
в
результате
119
проведенного обследования и анализа классификация угроз (с учетом
базовой модели угроз ФСТЭК [91]) представлена далее (Таблица 12):
120
Таблица 12 – Классификация угроз ИБ для ОИ
№
Угроза
Угрозы микропрограммному и аппаратному обеспечению:
Модификация, изменения версии, аппаратного сброса
1
пароля BIOS
2 Загрузка нештатной операционной системы
Изменение режимов работы аппаратных элементов
3
компьютера
Программное выведение из строя средств хранения,
4
обработки и (или) ввода/вывода/передачи информации
5 Изменение компонентов системы
Сброс состояния оперативной памяти путем перезагрузки
средств вычислительной техники
7 Физическое устаревания аппаратных компонентов
Угрозы аутентификационной информации:
6
8 Восстановление аутентификационной информации
9
Использование информации
идентификации/аутентификации, заданной по умолчанию
Объекты угрозы
МПО и аппаратное обеспечение
BIOS/UEFI
МПО BIOS/UEFI
МПО и аппаратное обеспечение
BIOS/UEFI
НИ, МПО, аппаратное обеспечение
ИС, ТК, системное ПО, прикладное
ПО, аппаратное обеспечение
Системное ПО, аппаратное
обеспечение
Аппаратное средство
Системное ПО, МПО, учётные
данные пользователя
СЗИ, системное ПО, сетевое ПО,
МПО
Наруши Актуаль
тель
ность
Н6
А
Н4
А
Н6
А
Н2, Н5
А
Н4
А
–
Н/А
Н4
А
Н1, Н4
А
Н2, Н4
А
121
№
Угроза
10
Несанкционированный доступ к аутентификационной
информации
11
Несанкционированное изменение аутентификационной
информации
12
Обход некорректно настроенных механизмов
аутентификации
Продолжение Таблицы 12
Наруши Актуал
Объекты угрозы
тель
ьность
Системное ПО, объекты ФС,
Н1, Н4
А
учётные данные пользователя,
реестр, НИ
Системное ПО, объекты ФС,
Н1, Н4
А
учётные данные пользователя,
реестр
Системное ПО, сетевое ПО
Системное ПО, МПО, учётные
данные пользователя
Угрозы, основанные на некорректной/недостаточной проверке входных данных:
СУ, объекты ФС, прикладное ПО,
14 Использование альтернативных путей доступа к ресурсам
системное ПО
Системное ПО, прикладное ПО,
15 Использование слабостей кодирования входных данных
сетевое ПО, МПО, реестр
Системное ПО, прикладное ПО,
Некорректное использование функционала программного
сетевое ПО, МПО, аппаратное
16
обеспечения
обеспечение
Неправомерное/некорректное использование интерфейса
Системное ПО, прикладное ПО,
17
взаимодействия с приложением
сетевое ПО, МПО, реестр
Сбой в работе системы вследствие подачи на входные
Системное ПО, прикладное ПО,
18
интерфейсы данных неподдерживаемого формата
сетевое ПО
13 Удаление аутентификационной информации
Н1, Н4
А
Н1, Н4
А
Н1, Н4
А
Н2, Н5
А
Н2, Н5
А
Н2, Н5
А
Н2, Н5
А
122
№
Угроза
Угрозы в отношении системного и прикладного ПО:
Использование механизмов авторизации для повышения
19
привилегий
20 Несанкционированное редактирование реестра
21
22
23
24
25
Несанкционированное создание учётной записи
пользователя
Несанкционированное повышение привилегий
Подделка записей журнала регистрации событий
Анализ криптографических алгоритмов и их реализации
Внедрение вредоносного кода, приводящего к другим
угрозам: несанкционированный доступ к данным,
выполнение нарушителем произвольного кода,
модификация содержимого буфера, системных реестров,
ячеек памяти, перенаправление запросов пользователя на
ресурс нарушителя, снижение объема системных
ресурсов и иные деструктивные воздействия на систему.
Деструктивное изменение конфигурации/среды
26
окружения программ
Объекты угрозы
Продолжение Таблицы 12
Наруши Актуал
тель
ьность
Системное ПО, прикладное ПО,
сетевое ПО
Системное ПО, использующее
реестр, реестр
Н1, Н4
А
Н1, Н4
А
Системное ПО
Н1, Н4
А
Системное ПО, сетевое ПО, ИС
Системное ПО
Системное ПО
Н2, Н5
Н1, Н4
–
А
А
Н/А
Системное ПО, прикладное ПО,
сетевое ПО
Н1, Н4
А
Системное ПО, прикладное ПО,
сетевое ПО, МПО, объекты ФС,
реестр
Н4
А
123
№
Угроза
27 Перебор всех настроек и параметров приложения
28 Наличие механизмов разработчика
Нарушение технологического/производственного
30 процесса из-за временных задержек, вносимых средством
защиты
Угрозы в отношении сетевых взаимодействий:
Использование слабостей протоколов
31
сетевого/локального обмена данными
32 Неправомерное действие в каналах связи
Несанкционированный доступ к активному и (или)
33
пассивному сетевому оборудованию из сети
Обнаружение открытых портов и идентификации
34
привязанных к нему сетевых служб
35 Обнаружение хостов
36 Определение типов объектов защиты
37 Определение топологии вычислительной сети
38 Передача данных по скрытым каналам
39 Перехват данных, передаваемых по вычислительной сети
Продолжение Таблицы 12
Наруши Актуал
Объекты угрозы
тель
ьность
Системное ПО, прикладное ПО,
Н2, Н5
А
сетевое ПО, МПО, реестр
ПО, техническое средство
–
Н/А
СЗИ
–
Н/А
Н1, Н4
А
–
Н/А
Н2, Н5
А
СУ, сетевое ПО, сетевой трафик
Н1
А
СУ, сетевое ПО, сетевой трафик
СУ, сетевое ПО, сетевой трафик
СУ, сетевое ПО, сетевой трафик
СУ, сетевое ПО, сетевой трафик
СУ, сетевой трафик
Н1
Н1
Н1
Н2, Н5
Н1
А
А
А
Системное ПО, сетевое ПО,
сетевой трафик
Сетевой трафик
Сетевое оборудование, МПО,
сетевое ПО
А
124
№
Угроза
40 Подмена содержимого сетевых ресурсов
41 Подмена субъекта сетевого доступа
Подмена доверенного пользователя («имитация действий
клиента»)
Получение предварительной информации об объекте
43
защиты
Усиление воздействия на вычислительные ресурсы
44
пользователей при помощи сторонних серверов
Заражение компьютера при посещении неблагонадёжных
45
сайтов
Скрытное включение вычислительного устройства в
46
состав бот-сети
47 Угроза «фишинга»
Перехват одноразовых паролей в режиме реального
48
времени
Угрозы защищаемой информации:
Доступ к защищаемым файлам с использованием
49
обходного пути
Несанкционированная модификация конфиденциальных
50
данных
42
Продолжение Таблицы 12
Наруши Актуал
Объекты угрозы
тель
ьность
Прикладное ПО, сетевое ПО,
Н1
А
сетевой трафик
Прикладное ПО, сетевое ПО,
Н2
А
сетевой трафик
СУ, сетевое ПО
Н1
А
Н2
А
Н1, Н4
А
СУ, сетевое ПО
Н4
А
СУ, сетевое ПО
Н1
А
ТК, сетевое ПО, сетевой трафик
Н1
А
Сетевое ПО
–
Н/А
Объекты ФС
Н1, Н4
А
Объекты ФС
Н1, Н4
А
СУ, сетевое ПО, сетевой трафик,
прикладное ПО
ИС, СУ, системное ПО, сетевое
ПО
125
№
Угроза
Несанкционированное копирование конфиденциальных
данных
Несанкционированное удаление конфиденциальных
52
данных
53 Повреждение системного реестра
Несанкционированное восстановление удалённой
54
конфиденциальных данных
55 Утрата носителей информации
56 Форматирование носителей информации
Угрозы специального воздействия:
Физическое выведение из строя средств хранения,
57
обработки и (или) ввода/вывода/передачи информации
Хищение средств хранения, обработки и (или)
58
ввода/вывода/передачи информации
Неправомерное ознакомление с защищаемой
информацией путём просмотра информации с экранов
59
мониторов других пользователей, с отпечатанных
документов, путём подслушивания разговоров и др.
Механическое повреждение линий связи между
60
серверными и клиентскими компонентами СТД
51
Объекты угрозы
Продолжение Таблицы 12
Наруши Актуал
тель
ьность
Объекты ФС, НИ
Н1, Н4
А
Объекты ФС, реестр
Н1, Н4
А
Объекты ФС, реестр
Н1, Н4
А
НИ
Н1, Н4
А
НИ
НИ
Н4
Н1, Н4
А
А
ТК, НИ
Н2, Н4
А
ТК, НИ
Н1, Н2,
Н4
А
Аппаратное обеспечение, НИ,
объекты ФС
Н4
А
Линии связи (ЛС)
–
Н/А
126
№
Угроза
Объекты угрозы
Продолжение Таблицы 12
Наруши Актуал
тель
ьность
Остальные виды специального воздействия (химическое,
акустическое, биологическое, радиационное,
Все активы
61
электромагнитное, электрическими импульсами,
электромагнитным излучением, магнитным полем)
Угрозы со стороны персонала или непосредственно на персонал:
Подмена действия пользователя с помощью методов
Все активы, доступ к которым
62
социальной инженерии или технических методов
есть у сотрудников
Все активы, доступ к которым
63 Физическое воздействие на сотрудников
есть у сотрудников
Все активы, доступ к которым
64 Неумышленные действия пользователя
есть у сотрудников
Передача конфиденциальной информации третьим лицам
Все активы, доступ к которым
65
со злым умыслом
есть у сотрудников
–
Н/А
Н2
А
Н2, Н4,
Н5, Н6
Н4, Н5,
Н6
Н4, Н5,
Н6
А
А
А
Угрозы, признанные неактуальными (Таблица 13):
Таблица 13 – Перечень неактуальных угроз
№ Название угрозы
Описание угрозы
Почему считается неактуальной
Возможность сброса пользователем
Перезагрузка
В СТД, использующих бездисковые
(нарушителем) состояния оперативной памяти
аппаратных и
(обнуления памяти) путём случайного или
тонкие клиенты, угроза не носит
6
программнокритичного характера.
намеренного осуществления перезагрузки
аппаратных СВТ
отдельных устройств, блоков или системы в целом
127
№
Название угрозы
Анализ
криптографически
24
х алгоритмов и их
реализации
Описание угрозы
Использование нарушителем потенциальных
слабостей в криптографических алгоритмах или
уязвимостей в реализующем их программноаппаратном обеспечении
Наличие
28 механизмов
разработчика
Возможность перехвата управления ПО за счёт
использования не удаленных разработчиками
отладочных механизмов
Перехват
одноразовых
48
паролей в режиме
реального времени
Возможность получения нарушителем управления
критическими операциями пользователя путём
перехвата одноразовых паролей, высылаемых
системой автоматически, и использования их для
осуществления неправомерных действий до того,
как истечёт их срок действия
Продолжение Таблицы 13
Почему считается неактуальной
На объекте используется оборудование,
системное и прикладное ПО известных
мировых и российских производителей, а
потенциальный нарушитель не
располагает необходимым
оборудованием для реализации данной
угрозы.
Заключение договоров на разработку
и/или модернизацию используемого
прикладного ПО, содержащих четкие
требования к его функциональности,
предусматривающих ответственность
разработчика за несоблюдение условий
договора.
Заключение соглашений о
конфиденциальности с разработчиками,
предусматривающих ответственность за
несанкционированное разглашение
конфиденциальной информации.
В системе не используется
аутентификация на основе одноразовых
паролей
128
№ Название угрозы
Описание угрозы
Возможность приведения системы в состояние
«отказ в обслуживании» или нарушения штатного
Нарушение
режима функционирования из-за временной
технологического/ задержки в системах реального времени, вносимой
производственного в процессы передачи и обработки
конфиденциальных данных средствами защиты
процесса из-за
30
информации, вызванной необходимостью
временных
обработки передаваемой/обрабатываемой
задержек,
информации на предмет выявления и
вносимых
средством защиты нейтрализации угроз ИБ в силу активности
внешних нарушителей, программные воздействия
которых обрабатываются СЗИ
Неправомерные
Внесение нарушителем изменений в работу
32 действия в каналах сетевых протоколов путём добавления или
связи
удаления данных из информационного потока
Механическое
Нарушение работоспособности СТД в связи с
повреждение ЛС
60
между серверами и повреждением линий связи
клиентами СТД
Нарушение функциональности оборудования СТД
в результате следующих видов специального
Остальные виды
воздействия: химическое, акустическое,
66 специального
биологическое, радиационное, электромагнитное,
воздействия
электрическими импульсами, электромагнитным
излучением, магнитным полем
Продолжение Таблицы 13
Почему считается неактуальной
Угроза относится к серверным
компонентам СТД и не рассматривается в
рамках данного исследования.
Не рассматривается в рамках данного
исследования.
Не рассматривается в рамках данного
исследования.
Актуальный нарушитель не располагает
необходимым оборудованием для
реализации данной угрозы.
129
4.5 Построение системы защиты клиентской части СТД
В силу того, что в цели проводимого эксперимента входила
апробация метода повышения степени доверия ВС на тонких клиентах,
при построении защитных мер (как технических, так и организационных)
использовались разработанные методы и средства (АПМДСЗ). При этом
учитывалось, что в рамках настоящего исследования серверный сегмент
СТД рассматривается как доверенный компонент.
Для обеспечения целостности, доступности и конфиденциальности
защищаемой информации, а также с учётом особенностей построения
СТД, в состав системы защиты должны входить следующие подсистемы
(Рисунок 19):
идентификации и аутентификации субъектов доступа и объектов доступа
целостности информационной системы и информации
управления доступом субъектов доступа к объектам доступа
ограничения программной среды
защиты машинных носителей информации
регистрации событий безопасности
антивирусной защиты (в т.ч. проактивной защиты)
контроля защищённости информации
доступности информации
защиты технических средств
выявления инцидентов и реагирования на них
Рисунок 19 – Подсистемы, входящие в состав системы защиты СТД
Медцентра
130
В состав средств и механизмов ИБ, реализующих функции
перечисленных подсистем проектируемой системы защиты клиентской
части СТД, вошли следующие:
1. АПМДСЗ, установленные на всех аппаратных тонких клиентах.
2. Средство антивирусной защиты (САВЗ), включающие HIPS.
3. Средство контроля и анализа защищённости (СКАЗ).
4. Встроенные механизмы разграничения доступа ОС (в том числе
пароль на BIOS).
5. Механизмы ограниченной программной среды (ОПС), встроенные
в ОС.
6. Межсетевой экран (МЭ).
7. Система обнаружения/предотвращения вторжений (IDS/IPS).
8. Компоненты инфраструктуры открытого ключа, включающие УЦ
и OCSP-сервер.
Также к проектируемой системе защиты относятся следующие
политики ИБ и организационные меры:
1. Парольная политика.
2. Политика разграничения доступа (в том числе, ограничение
доступа в КЗ).
3. Использование ПО от доверенных производителей
4. Меры технической защиты,
5. Обучение пользователей основам ИБ.
Перечисленные компоненты, в том числе, обеспечивают выполнение
всех требуемых функций ДВС, что гарантирует корректное исполнение
функций подсистем защиты программными средствами, работающими в
вычислительной среде тонких клиентов.
131
4.5.1 Идентификация
и
аутентификация
субъектов
доступа
и
объектов доступа.
Функции подсистемы реализуются в следующих компонентах:
− АПМДСЗ;
− встроенные механизмы аутентификации ИС, с которыми работает
пользователь;
− встроенные механизмы аутентификации ОС и системного ПО
сетевого оборудования.
Аутентификация пользователя, тонкого клиента и терминального
сервера до момента загрузки ОС осуществляется согласно алгоритму
взаимной аутентификации с использованием ИОК, реализованному в
АПМДСЗ и поддерживаемому на терминальном сервере. Пары закрытых и
открытых ключей для токена, входящего в состав АПМДСЗ, и
терминального сервера генерируются Администратором ИБ, задействуя
при этом УЦ для выдачи сертификатов открытых ключей. OCSP-сервер
включен в локальную сеть организации, в результате терминальный
сервер в режиме реального времени может получать актуальную
информацию о статусе сертификатов токенов пользователей.
Инициализация
токена
происходит
в
момент
его
выдачи
пользователю. При этом происходит генерация ключевой пары и пароля
на криптоконтейнер. В системе применяется парольная политика, не
допускающая использование паролей, не удовлетворяющих требованиям
по сложности (длина пароля, использование символов нижнего и верхнего
регистра, использование неалфавитных символов).
Для реализации защиты от атаки перебором паролей в АПМДСЗ
реализован механизм блокировки токена при достижении 10 неуспешных
попыток аутентификации (количество неуспешных попыток является
настраиваемым параметром). Разблокировка
Администратором ИБ.
токена осуществляется
132
Порядок смены аутентификационных данных пользователей и
остальных компонентов регламентирован в руководстве Администратора
ИБ.
Образ ОС, загружаемый в результате успешной аутентификации,
является персонифицированным и содержит настройки доступа под
конкретного
пользователя
в
соответствии
с
его
должностными
полномочиями.
При подключении пользователя к рабочим ИС (например, к
медицинской информационной системе) аутентификация осуществляется
встроенным механизмом ИС.
Для идентификации и аутентификации системных модулей ОС и
обновлений безопасности компонентов, входящих в состав СТД (в т.ч.
сетевого оборудования), до их установки используются встроенные
системы контроля обновлений в ОС и основном ПО оборудования при
помощи проверки электронной подписи устанавливаемого модуля.
4.5.2 Целостность информационной системы и информации.
Функции подсистемы реализуются в следующих компонентах:
− АПМДСЗ;
− встроенные механизмы аутентификации ОС и системного ПО
сетевого оборудования.
Контроль целостности образа ОС, загружаемого на ТК по сети с
терминального сервера, осуществляется в рамках метода доверенной
загрузки, реализованного в АПМДСЗ, с использованием ИОК.
Для контроля целостности системных модулей ОС и обновлений
безопасности компонентов, входящих в состав СТД (в т.ч. сетевого
оборудования), до их установки используются встроенные системы
контроля обновлений в ОС и основном ПО оборудования при помощи
проверки электронной подписи устанавливаемого модуля.
133
В состав необходимых организационно-технических мер входит
применение
пароля
администратора,
не
позволяющее
менять
установленные настройки BIOS и UEFI.
4.5.3 Управление доступом субъектов доступа к объектам доступа.
Функции подсистемы реализуются в следующих компонентах:
− АПМДСЗ;
− межсетевой экран;
− встроенные механизмы ОС, используемых ИС, СЗИ, системного
ПО сетевого оборудования.
Контроль подключаемых пользователями устройств осуществляется
средствами
САВЗ,
реализующими
автоматическое
сканирование
подключаемых внешних устройств и настройку правил работы со
съемными носителями информации для каждого пользователя.
Назначение
прав
доступа
пользователям
(в
том
числе
привилегированным) и запускаемому от их имени ПО осуществляется
Администратором
ИБ
в
соответствии
с
политикой
минимально
необходимых полномочий для выполнения должностных обязанностей,
что регламентируется в соответствующих Руководствах.
Технологии
беспроводного
доступа
пользователей
(и
привилегированных пользователей) к объектам доступа СТД запрещены
для использования.
Ремонт и обслуживание программных и технических компонентов
осуществляется только организациями, с которыми заключены договоры
подряда, включающие соглашение о конфиденциальности. Ремонтные
работы проводятся только в присутствии Сетевых администраторов или
Администратора ИБ.
134
4.5.4 Ограничение программной среды.
Функции по ограничению возможности установки (инсталляции) и
настройки дополнительного ПО, изменения настроек и удаления
системного и прикладного ПО, предусматривающие такие полномочия
только у привилегированных пользователей СТД, реализованы штатными
средствами ОС.
Перечень дополнительного ПО, разрешённого к инсталляции,
утверждается Администратором ИБ. Процесс установки (инсталляции) и
настройки дополнительного ПО, изменения настроек и удаления
системного
и
прикладного
ПО
регламентируется
в
Руководстве
Администратора ИБ.
4.5.5 Защита машинных носителей информации (МНИ).
В организации регламентируется:
− порядок учёта МНИ, используемых в СТД для аутентификации
(токены), хранения и обработки информации;
− контроль перемещения МНИ за пределы КЗ;
− порядок процедуры уничтожения (обезличивания) защищаемой
информации и МНИ;
− обязанности должностных лиц, имеющих физический доступ к
МНИ, в части обеспечения безопасности защищаемой информации.
Функции
гарантированного
уничтожения
(стирания)
конфиденциальной информации, хранящейся и обрабатываемой на МНИ,
реализуются встроенными средствами ОС.
4.5.6 Регистрация событий безопасности.
Функции
регистрации
событий
безопасности
реализуются
встроенными механизмами применяемых СЗИ, ОС и системного ПО
сетевого оборудования. Перечень событий безопасности, подлежащих
135
регистрации,
и
содержание
регистрируемой
информации
регламентируется Администратором ИБ и указывается в Руководстве.
4.5.7 Антивирусная защита (в т.ч. проактивная защита).
Функции
подсистемы
антивирусной
защиты
осуществляются
средствами САВЗ, агенты которого устанавливаются на рабочие места
пользователей (тонкие клиенты) и управляются централизованно с
использованием консоли удаленного управления.
4.5.8 Обнаружение/предотвращение вторжений
Функции
подсистемы
обнаружения
вторжений
реализуются
средствами системы IPS/IDS, реализующей следующие возможности в
отношении клиентских АРМ и сетевого оборудования:
− регулярное обновление сигнатур сетевых атак;
− контроль доступа приложений к сетевым сервисам;
− фильтрация html-трафика по URL-адресам;
− защита от сетевых компьютеров-роботов;
− обнаружение вирусов в трафике;
− получение актуальной информации о распространении атак и
уязвимостях
нулевого
дня
из
централизованной
базы
сигнатур
производителя;
− обнаружение и профилактика характерных известных атак в
сетевом трафике;
− обнаружение и профилактика уязвимостей, в том числе известных
уязвимостей, входящих в единую базу уязвимостей и эксплоитов (CVE) и
т.д.
Архитектура СТД в части подключения в сеть IPS/IDS-системы
обеспечивает анализ всей информации, попадающей в СТД как на
сетевом,
так
и
на
прикладном
уровнях.
Данная
возможность
обеспечивается за счёт использования технологии Port Mirroring (span-
136
port), которая позволяет дублировать весь трафик с выбранных портов или
VLAN сетей на порт-зеркало, в который подключается IPS/IDS-система.
Полномочиями
на
управление
(администрирование)
IPS/IDS-
системы обладает только Администратор ИБ. Порядок регулярного
обновления базы решающих правил и реагирования на инциденты
информационной безопасности регламентирован.
4.5.9 Контроль защищённости информации.
Функции по периодическому контролю и анализу защищённости
СТД осуществляются СКАЗ, агенты которого устанавливаются на рабочие
места пользователей (тонкие клиенты) и управляются централизованно с
использованием консоли удаленного управления:
СКАЗ позволяет реализовать следующие функции защиты:
− поиск уязвимостей в установленном ПО по базам известных
уязвимостей;
− контроль установки обновлений ПО, включая ПО СЗИ и
BIOS/UEFI;
− контроль правил генерации и смены паролей пользователей
(привилегированных пользователей);
− анализ сетевой активности;
− инвентаризация сети.
4.5.10 Защита технических средств.
Контроль и управление физическим доступом к техническим
компонентам, входящим в состав СТД, осуществляются Сетевыми
администраторами
и
Администратором
ИБ.
В
соответствующих
Руководствах должен быть также регламентирован доступ в серверные
помещения, обеспечивая их защиту от несанкционированного доступа.
Функции подсистемы выполняются организационными мерами,
среди которых:
137
− использование запираемых серверных шкафов;
− размещение серверного оборудования в специализированном
помещении с системой охраны;
− пропускной
режим
для
сотрудников
и
обслуживающих
организаций.
4.5.11 Выявление инцидентов и реагирование на них
Функции подсистемы реализуются в СЗИ, имеющих следующую
функциональность:
− обнаружение, идентификация и регистрация инцидентов;
− фильтрация журналов аудита с целью обнаружения инцидентов
нарушения информационной безопасности;
− своевременное информирование Администратора ИБ о возникших
инцидентах;
− предоставление информации для анализа инцидентов, в том числе
определения источников и причин возникновения инцидентов, а также
оценки их последствий.
Реагирование администратора на инциденты информационной
безопасности
осуществляется
посредством
консолей
управления,
присутствующих в используемых СЗИ. Исключительным доступом к
конфигурации и журналам средств мониторинга (в том числе действий
привилегированных пользователей) предоставлен только Администратору
ИБ. Правила и процедуры выявления инцидентов и реагирования на них
регламентированы в Руководстве Администратора ИБ. В отношении
функций, предусматривающих реакцию на инциденты, в Руководстве
фиксируется временной регламент, определяющий максимальное время
реагирования дифференцировано на критичные/некритичные инциденты.
138
4.6 Сопоставление применяемых СЗИ актуальным угрозам
В результате проектируемых мер всем актуальным угрозам из
построенной классификации соответствуют следующие защитные меры и
средства ИБ (Таблица 14):
Таблица 14 – Соответствие актуальных угроз и применяемых защитных
мер и средств
№
Угроза
СЗИ/меры защиты
Угрозы микропрограммному и аппаратному обеспечению:
- модификации, изменения версии,
Оргмеры, пароль на
1
аппаратного сброса пароля BIOS
BIOS/UEFI, СКАЗ
- загрузки нештатной операционной
Оргмеры, пароль на
2
системы
BIOS/UEFI, АПМДСЗ
- изменения режимов работы
Оргмеры, пароль на
3
аппаратных элементов компьютера
BIOS/UEFI
- программного выведения из строя
АПМДСЗ, СКАЗ
4 средств хранения, обработки и (или)
ввода/вывода/передачи информации
АПМДСЗ, СКАЗ, СВАЗ,
встроенные механизмы
контроля целостности,
использование
- изменения компонентов системы
5
программного и
аппаратного обеспечения
от доверенных
производителей
- физического устаревания аппаратных Оргмеры, обучение
7
компонентов
сотрудников
Угрозы аутентификационной информации:
- восстановления аутентификационной АПМДСЗ, парольная
8
информации
политика
- использования информации
АПМДСЗ, парольная
9 идентификации/аутентификации,
политика
заданной по умолчанию
- несанкционированного доступа к
АПМДСЗ
10
аутентификационной информации
139
Продолжение Таблицы 14
СЗИ/меры защиты
№ Угроза
- несанкционированного изменения
АПМДСЗ
11
аутентификационной информации
- обхода некорректно настроенных
АПМДСЗ
12
механизмов аутентификации
- удаления аутентификационной
АПМДСЗ
13
информации
Угрозы, основанные на некорректной/недостаточной проверке
входных данных:
САВЗ, встроенные
- использования альтернативных путей
механизмы разграничения
14
доступа к ресурсам
доступа, ОПС
САВЗ, встроенные
- использования слабостей
механизмы разграничения
15
кодирования входных данных
доступа, ОПС
- некорректного использования
САВЗ, встроенные
механизмы разграничения
16 функционала программного
обеспечения
доступа, ОПС
САВЗ, встроенные
механизмы разграничения
- неправомерного/некорректного
доступа, ОПС,
17 использования интерфейса
использование ПО от
взаимодействия с приложением
доверенных
производителей
САВЗ, встроенные
механизмы разграничения
- сбоя в работе системы вследствие
доступа, ОПС,
18 подачи на входные интерфейсы данных
использование ПО от
неподдерживаемого формата
доверенных
производителей
Угрозы в отношении системного и прикладного ПО:
- использования механизмов
СКАЗ, АПМДСЗ,
встроенные механизмы
19 авторизации для повышения
разграничения доступа
привилегий
АПМДСЗ, ОПС,
- несанкционированного
встроенные механизмы
20
редактирования реестра
разграничения доступа
140
№ Угроза
21
- несанкционированного создания
учётной записи пользователя
22
- повышения привилегий
23
- подделки записей журнала
регистрации событий
- внедрения вредоносного кода,
приводящего к другим угрозам:
несанкционированный доступ к
данным, выполнение нарушителем
произвольного кода, модификация
25 содержимого буфера, системных
реестров, ячеек памяти,
перенаправление запросов пользователя
на ресурс нарушителя, снижение
объема системных ресурсов и иные
деструктивные воздействия на систему.
- деструктивного изменения
26 конфигурации/среды окружения
программ
- перебора всех настроек и параметров
27
приложения
Продолжение Таблицы 14
СЗИ/меры защиты
АПМДСЗ, ОПС,
встроенные механизмы
разграничения доступа
СКАЗ, САВЗ, ОПС,
АПМДСЗ, встроенные
механизмы разграничения
доступа
СКАЗ, ОПС, встроенные
механизмы разграничения
доступа
САВЗ, ОПС, АПМДСЗ,
СКАЗ, встроенные
механизмы разграничения
доступа
АПМДСЗ, ОПС,
встроенные механизмы
разграничения доступа
СКАЗ, ОПС
СКАЗ, использование
программных и
- включения в проект не достоверно
аппаратных средств от
29
испытанных компонентов
доверенных
производителей
Угрозы в отношении сетевых взаимодействий:
СКАЗ, использование
программных и
- использования слабостей протоколов
аппаратных средств от
31
сетевого/локального обмена данными
доверенных
производителей
141
№
33
34
35
36
37
38
39
40
41
42
43
44
45
46
Продолжение Таблицы 14
Угроза
СЗИ/меры защиты
- несанкционированного доступа к
СКАЗ, САВЗ, встроенные
активному и (или) пассивному сетевому механизмы контроля
оборудованию из сети
целостности
- обнаружения открытых портов и
МЭ, IDS/IPS
идентификации привязанных к нему
сетевых служб
- обнаружения хостов
IDS/IPS
- определения типов объектов защиты
IDS/IPS
- определения топологии
IDS/IPS
вычислительной сети
САВЗ, ОПС, встроенные
- передачи данных по скрытым каналам механизмы разграничения
доступа
Оргмеры, меры
- перехвата данных, передаваемых по
технической защиты,
вычислительной сети
ограничение доступа в КЗ
АПМДСЗ, оргмеры, меры
- подмены содержимого сетевых
технической защиты,
ресурсов
ограничение доступа в КЗ
Оргмеры, обучение
- подмены субъекта сетевого доступа
пользователей основам ИБ,
САВЗ
- подмены доверенного пользователя
IDS/IPS
(«имитация действий клиента»)
IDS/IPS, меры
- получения предварительной
технической защиты,
информации об объекте защиты
ограничение доступа в КЗ
- усиления воздействия на
вычислительные ресурсы пользователей IDS/IPS, СКАЗ
при помощи сторонних серверов
- заражения компьютера при
IDS/IPS, САВЗ
посещении неблагонадёжных сайтов
- скрытного включения
вычислительного устройства в состав
IDS/IPS, САВЗ, СКАЗ
бот-сети
142
№ Угроза
47
- «фишинга»
Продолжение Таблицы 14
СЗИ/меры защиты
САВЗ, обучение
пользователей основам ИБ
Угрозы защищаемой информации:
- доступа к защищаемым файлам с
49
использованием обходного пути
50
- несанкционированной модификации
защищаемой информации
53
54
55
56
АПМДСЗ
АПМДСЗ, оргмеры, меры
технической защиты,
ограничение доступа в КЗ
АПМДСЗ, оргмеры, меры
- несанкционированного удаления
технической защиты,
защищаемой информации
ограничение доступа в КЗ
АПМДСЗ, оргмеры, меры
- повреждения системного реестра
технической защиты,
ограничение доступа в КЗ
АПМДСЗ, оргмеры, меры
- несанкционированного
технической защиты,
восстановления удалённой защищаемой ограничение доступа в КЗ,
информации
средства гарантированного
уничтожения информации
АПМДСЗ, оргмеры, меры
технической защиты,
ограничение доступа в КЗ,
- утраты носителей информации
обучение пользователей
основам ИБ
АПМДСЗ, оргмеры, меры
технической защиты,
- форматирования носителей
ограничение доступа в КЗ,
информации
обучение пользователей
основам ИБ
- несанкционированного копирования
51
защищаемой информации
52
АПМДСЗ, встроенные
механизмы разграничения
доступа, ОПС
143
№ Угроза
Угрозы специального воздействия:
57
58
59
62
63
64
65
Продолжение Таблицы 14
СЗИ/меры защиты
Оргмеры, меры
- физического выведения из строя
технической защиты,
средств хранения, обработки и (или)
ограничение доступа в КЗ,
ввода/вывода/передачи информации
обучение пользователей
основам ИБ
Оргмеры, меры
- хищения средств хранения, обработки технической защиты,
ограничение доступа в КЗ,
и (или) ввода/вывода/передачи
информации
обучение пользователей
основам ИБ
Оргмеры, меры
технической защиты,
- неправомерного ознакомления с
ограничение доступа в КЗ,
защищаемой информацией
обучение пользователей
основам ИБ
Угрозы со стороны персонала:
Обучение пользователей
- подмены действия пользователя с
основам ИБ, встроенные
помощью методов социальной
механизмы разграничения
инженерии или технических методов
доступа
Распределение атрибутов
безопасности между
Физическое воздействие на
несколькими доверенными
сотрудников
сотрудниками, режимные и
организационные меры
Обучение пользователей
основам ИБ, встроенные
Неумышленные действия пользователя
механизмы разграничения
доступа
Комплекс реализованных
режимных,
Передача конфиденциальной
организационных,
информации третьим лицам со злым
кадровых мер по подбору
умыслом
персонала и контролю их
лояльности
144
Из 57 актуальных угроз 24 закрываются в том числе с применением
АПМДСЗ в качестве СЗИ. При этом 5 актуальных угроз (в основном – в
отношении
аутентификационной
информации)
нейтрализуются
исключительно за счет функций АПМДСЗ.
4.7 Оценка
эффективности
применяемой
системы
защиты
информации
4.7.1 Построение параметрической модели системы защиты
После того, как предложена система защиты, представляющая собой
совокупность набора организационно-технических мер программных и
аппаратных СЗИ, определим эффективность применяемой системы с
использованием метода оценки, рассматриваемого в 3 разделе настоящего
исследования. Для этого определим параметрические множества моделей
атак 𝐴𝐴, нарушителя 𝐷𝐷 и средств защиты 𝑆𝑆.
Множество моделей атак 𝐴𝐴 ⊆ 𝐴𝐴1 × 𝐴𝐴2 × 𝐴𝐴3 (𝑛𝑛 = 3) определим
следующим образом:
− 𝐴𝐴1 описывает вид доступа при осуществлении атаки: 𝐴𝐴1 = {0, 1}
− 𝐴𝐴2
0 − непосредственный доступ
𝐴𝐴1 = �
1 − удаленный доступ
описывает
сложность
реализации
атаки
(необходимая
квалификация, применение дополнительных программных и аппаратных
средств и т.п.): 𝐴𝐴2 = {0, 1, 2}
0 − низкая
𝐴𝐴2 = � 1 − средняя
2 − высокая
− 𝐴𝐴3 описывает цель атаки: 𝐴𝐴3 = {0, 1}
Множество
0 − сбор информации
𝐴𝐴3 = �
1 − непосредственный ущерб
моделей
нарушителей
определим следующим образом:
𝐷𝐷 ⊆ 𝐷𝐷1 × 𝐷𝐷2 × 𝐷𝐷3 (𝑚𝑚 = 3)
145
− 𝐷𝐷1 описывает нарушителя с точки зрения доступа к объекту атаки:
𝐷𝐷1 = {0, 1}
0 − внешний
𝐷𝐷1 = �
1 − внутренний
− 𝐷𝐷2 описывает квалификацию нарушителя: 𝐷𝐷2 = {0, 1, 2}
0 − низкая
𝐷𝐷2 = � 1 − средняя
2 − высокая
− 𝐷𝐷3 описывает полномочия нарушителя в отношении объекта атаки:
𝐷𝐷3 = {0, 1, 2}
0 − отсутствуют
1 − непривилегированный пользователь
𝐷𝐷3 = �
2 − привилегированный пользователь (администратор)
Множество моделей средств защиты 𝑆𝑆 ⊆ 𝑆𝑆1 × 𝑆𝑆2 × 𝑆𝑆3 × 𝑆𝑆4 (𝑙𝑙 = 4)
определим следующим образом:
− 𝑆𝑆1 описывает тип применяемого средства защиты или защитной
меры: 𝑆𝑆1 = {0, 1, 2}
0 − организационно − техническая мера
1 − программное средство защиты
𝑆𝑆1 = �
2 − аппаратно − программное средство защиты
− 𝑆𝑆2 описывает тип СЗИ с точки зрения области применения:
𝑆𝑆2 = {0, 1, 2}
0 − организационно − техническая мера
𝑆𝑆2 = �
1 − клиентское СЗИ
2 − сетевое СЗИ
− 𝑆𝑆3 описывает пользователей, имеющих доступ к СЗИ: 𝑆𝑆3 =
{0, 1, 2, 3, 4}
0 − Администратор ИБ (АИБ)
1 − Сетевой администратор (СА)
2 − непривилегированный пользователь (НП)
𝑆𝑆3 =
⎨3 − сторонние подрядчики и обслуживающий персонал (СП)
⎪
4 − посторонние лица (ПЛ)
⎩
⎧
⎪
146
− 𝑆𝑆4 описывает наличие удаленного доступа к управлению СЗИ:
𝑆𝑆4 = {0, 1}
0 − нет
𝑆𝑆4 = �
1 − есть
Таким образом, множества 𝐴𝐴, 𝐷𝐷, и 𝑆𝑆 представляют собой матрицы
(Таблица 15):
Таблица 15 – Значения множеств 𝐴𝐴, 𝐷𝐷, и 𝑆𝑆
𝑨𝑨𝟏𝟏
𝑨𝑨𝟐𝟐
𝑨𝑨𝟑𝟑
𝑫𝑫𝟏𝟏
𝑫𝑫𝟐𝟐
𝑫𝑫𝟑𝟑
𝑺𝑺𝟏𝟏
𝑺𝑺𝟐𝟐
𝑺𝑺𝟑𝟑
𝑺𝑺𝟒𝟒
0
0
0
0
0
0
0
0
0
0
1
0
0
1
0
0
1
0
0
0
0
1
0
0
1
0
2
0
0
0
1
1
0
1
1
0
0
1
0
0
0
2
0
0
2
0
1
1
0
0
1
2
0
1
2
0
2
1
0
0
0
0
1
0
0
1
0
2
0
0
1
0
1
1
0
1
1
2
0
0
0
1
1
0
1
1
2
2
0
0
1
1
1
1
1
1
0
0
1
0
0
2
1
0
2
1
1
0
1
0
1
2
1
1
2
1
2
0
1
0
0
0
2
0
1
1
0
1
0
2
1
1
1
0
0
1
2
2
1
1
0
1
1
2
0
2
1
0
0
2
2
1
2
1
0
1
2
2
2
2
1
0
…
…
…
…
0
1
4
1
147
𝑨𝑨𝟏𝟏
𝑨𝑨𝟐𝟐
𝑨𝑨𝟑𝟑
𝑫𝑫𝟏𝟏
𝑫𝑫𝟐𝟐
1
1
4
1
2
1
4
1
Продолжение Таблицы 15
𝑺𝑺𝟏𝟏
𝑺𝑺𝟐𝟐
𝑺𝑺𝟑𝟑
𝑺𝑺𝟒𝟒
𝑫𝑫𝟑𝟑
0
2
4
1
1
2
4
1
2
2
4
1
Мощности описываемых множеств, соответственно, составляют:
|𝐴𝐴| = 12, |𝐷𝐷| = 18, и |𝑆𝑆| = 90. Для примера рассмотрим смысловые
значения некоторых из векторов:
𝑎𝑎⃗ = (1, 1, 0): атака, реализуемая удаленно со средней степенью
сложности (например, необходимо использовать специализированное ПО
и иметь среднюю квалификацию в области реализации атаки) с целью
сбора информации. К таким атакам относится, например, сканирование
сетевого оборудования и сетевых средств защиты (межсетевого экрана,
систем IPS/IDS) с целью определения открытых портов, версии прошивки,
запущенных служб и т.д. Собранная таким образом информация поможет
злоумышленнику сформировать нужный вектор дальнейшей атаки на
систему.
���⃗=
𝑑𝑑
(1,
0,
1):
внутренний
нарушитель,
имеющий
низкую
квалификацию, обладающий правами непривилегированного пользователя
в
системе.
К
такому
нарушителю
на
рассматриваемом
объекте
исследования можно отнести любого врача, использующего в качестве
рабочего места тонкий клиент.
𝑠𝑠��⃗= (2, 1, 0, 0): аппаратно-программное СЗИ, устанавливаемое
локально на клиентское рабочее место, доступ к настройке которого имеет
только Администратор ИБ, и не имеющее интерфейса для удаленного
148
управления.
К
таким
СЗИ
относится,
в
частности,
АПМДСЗ,
обеспечивающий доверенную загрузку на тонкие клиенты.
В рамках применения метода оценки эффективности необходимо
вычислить функцию 𝐹𝐹�𝑎𝑎⃗, 𝑑𝑑⃗, 𝑠𝑠⃗� через функции 𝐿𝐿(𝑠𝑠⃗, 𝑎𝑎⃗) и 𝑃𝑃(𝑑𝑑⃗, 𝑎𝑎⃗), которые, в
свою очередь, определяются через функции 𝐿𝐿𝑞𝑞𝑟𝑟 (𝑠𝑠, 𝑎𝑎) и 𝑃𝑃𝑡𝑡𝑡𝑡 (𝑑𝑑, 𝑎𝑎)
соответственно.
Конкретные значения функции 𝐿𝐿𝑞𝑞𝑞𝑞 определяются экспертным
методом и задаются матрицей (Таблица 16):
Таблица 16 – Значения функции Lqr
𝑨𝑨𝟐𝟐
0
1
0
1
1
1
1
1
0
2
1
1
1
𝑺𝑺𝟏𝟏
1
2
1
1
1
2
1
1
1
1
0
2
1
1
1
1
𝑺𝑺𝟐𝟐
2
1
1
1
2
1
1
0
0
0
1
1
0
1
1
1
1
1
1
𝑺𝑺𝟑𝟑
2
2
2
1
2
3
2
2
2
2
4
2
0
1
1
0
𝑺𝑺𝟒𝟒
2
2
1
2
1
Аналогично определяется функция 𝑃𝑃𝑡𝑡𝑡𝑡 (𝑑𝑑, 𝑎𝑎)
𝑳𝑳𝒒𝒒𝒒𝒒
𝑨𝑨𝟏𝟏
𝑨𝑨𝟑𝟑
2
0
1
2
2
0
2
2
2
2
2
2
2
2
0
2
2
2
2
1
2
1
2
2
1
2
2
1
1
1
2
1
1
2
0
1
2
1
2
2
1
2
и задается матрицей
(Таблица 17):
Таблица 17 – Значения функции 𝑃𝑃𝑡𝑡𝑡𝑡
𝑨𝑨𝟏𝟏
𝑨𝑨𝟐𝟐
𝑷𝑷𝒕𝒕𝒕𝒕 (𝒅𝒅, 𝒂𝒂)
0
1
0
0
2
1
0
𝑫𝑫𝟏𝟏
2
2
1
1
1
1
2
0
𝑫𝑫𝟐𝟐
1
1
2
1
2
2
2
0
𝑨𝑨𝟑𝟑
0
1
2
1
1
1
2
1
149
𝑫𝑫𝟑𝟑
1
2
0
1
2
2
2
1
2
2
1
2
1
1
2
2
2
2
2
2
2
2
1
2
2
1
2
0
1
2
2
2
1
2
2
1
2
1
1
2
Полученные значения функций 𝐿𝐿(𝑠𝑠⃗, 𝑎𝑎⃗) и 𝑃𝑃�𝑑𝑑⃗, 𝑎𝑎⃗� приведены в
Приложении 1 к настоящей работе.
После того, как были определены множества значений функций
𝐿𝐿(𝑠𝑠⃗, 𝑎𝑎⃗) и 𝑃𝑃�𝑑𝑑⃗, 𝑎𝑎⃗�, была вычислена функция 𝐹𝐹�𝑎𝑎⃗, 𝑑𝑑⃗, 𝑠𝑠⃗� = 𝐿𝐿(𝑠𝑠⃗, 𝑎𝑎⃗) ∗ 𝑃𝑃(𝑑𝑑⃗, 𝑎𝑎⃗),
определяющая уровень риска, связанного с атакой 𝑎𝑎⃗ ∈ 𝐴𝐴 в условиях, когда
она может быть реализована нарушителем 𝑑𝑑⃗ ∈ 𝐷𝐷 для взлома системы
защиты 𝑠𝑠⃗ ∈ 𝑆𝑆. Таким образом, для всех возможных сочетаний векторов
𝑎𝑎⃗, 𝑑𝑑⃗, и 𝑠𝑠⃗ (всего 19440 сочетаний) было получено значение риска 𝑓𝑓𝑝𝑝 ∈ 𝑍𝑍+
(множеству целых
положительных
чисел).
Текст программы
для
вычисления значений функции 𝐹𝐹�𝑎𝑎⃗, 𝑑𝑑⃗, 𝑠𝑠⃗� также приведен в Приложении 2.
Процент количества векторов, значение функции уровня риска для
которых является нулевым, составляет 65,92%.
Будем считать, что атаки 𝑎𝑎⃗, произведенные нарушителем 𝑑𝑑⃗ в
отношении СЗИ 𝑠𝑠⃗ являются:
− высокорискованными, если 𝐹𝐹�𝑎𝑎⃗, 𝑑𝑑⃗, 𝑠𝑠⃗� ≥ 2,24 ∗ 10−9 ;
− среднерискованными, если 2,24 ∗ 10−9 > 𝐹𝐹�𝑎𝑎⃗, 𝑑𝑑⃗, 𝑠𝑠⃗� ≥ 7,68 ∗ 10−11 ;
− низкорискованными, если 7,68 ∗ 10−11 > 𝐹𝐹�𝑎𝑎⃗, 𝑑𝑑⃗, 𝑠𝑠⃗� > 0;
− с ничтожным уровнем риска, если 𝐹𝐹�𝑎𝑎⃗, 𝑑𝑑⃗, 𝑠𝑠⃗� = 0.
По итогам анализа полученных значений можно сделать следующие
выводы:
1. Общее число высокорискованных атак �𝑎𝑎⃗, 𝑑𝑑⃗, 𝑠𝑠⃗� составляет 12,16%
от общего числа атак с ненулевым риском, среднерискованных – 68,21%,
низкорискованных – 19,63%.
150
В отношении нарушителей:
2. Высокорискованные
атаки
реализуются
следующими
нарушителями (Таблица 18):
Таблица 18 – Нарушители, реализующие основную часть
высокорискованных атак
% от числа
Вектор
высоко
Пример
Описание нарушителя
�𝒅𝒅⃗
рискованны
нарушителя
х атак
Внутренний нарушитель с
Администратор ИБ,
высокой квалификацией и
(1, 2, 2)
41,43
системный
привилегированным
администратор
доступом
Злоумышленник,
удаленно
(0, 2, 2)
4,46
Внешний нарушитель с
подключившийся к
высокой квалификацией и
СЗИ и успешно
привилегированным
эксплуатировавши
доступом
й уязвимость по
повышению
полномочий
Администратор ИБ,
системный
(1, 1, 2)
21,83
Внутренний нарушитель
администратор, в
со средней квалификацией
ряде случаев –
и привилегированным
сторонние
доступом
подрядчики,
обслуживающие
СЗИ
(1, 2, 1)
21,83
Внутренний нарушитель с
Сторонние
151
Вектор
�⃗
𝒅𝒅
% от числа
высоко
рискованны
х атак
% от числа
Вектор
высоко
�⃗
рискованных
𝒅𝒅
атак
(1, 1, 1)
10,42
Пример
нарушителя
Описание нарушителя
высокой квалификацией и
подрядчики,
непривилегированным
обслуживающие
доступом
СЗИ, пользователи
Продолжение Таблицы 18
Описание нарушителя
Пример
нарушителя
Внутренний нарушитель со
средней квалификацией и
непривилегированным
доступом
Необходимо заметить, что в случае, когда Администратор ИБ и
Системный администратор назначаются из числа особо доверенных лиц,
реализуются кадровые меры по подбору персонала и контролю их
лояльности, условия конфиденциальности включаются в договоры с
организацией, данных нарушителей принято считать неактуальными. Со
сторонними подрядчиками при этом также подписывается соглашение о
неразглашении
и
применяются
все
необходимые
организационно-
технические меры (в том числе принцип минимальных привилегий) в
процессе сопровождения жизненного цикла СЗИ. Таким образом, как
минимум 63% высокорискованных атак в отношении разрабатываемой
системы защиты считаются неактуальными.
3. Среднерискованные атаки в основном (77% атак) реализуются
следующими нарушителями (в дополнение к тем, что перечислены в
Таблица 19):
152
Таблица 19 – Нарушители, реализующие основную часть
среднерискованных атак
% от числа
Вектор
средне
Описание
Пример нарушителя
�𝒅𝒅⃗
рискованных
нарушителя
атак
Администратор ИБ,
системный
Внутренний
нарушитель с низкой
(1, 0, 2)
9,05
квалификацией и
привилегированным
доступом
администратор, в ряде
случаев – сторонние
подрядчики,
обслуживающие СЗИ,
пользователь,
сумевший реализовать
атаку по повышению
полномочий
Внутренний
(1, 2, 0)
9,05
нарушитель с высокой
квалификацией и
Разработчики СЗИ
отсутствием доступа
Внутренний
нарушитель с низкой
(1, 0, 1)
7,65
квалификацией и
Пользователи
непривилегированным
доступом
Внутренний
нарушитель со
(1, 1, 0)
7,65
средней
квалификацией и
отсутствием доступа
Пользователи,
разработчики СЗИ
153
Продолжение Таблицы 19
% от числа
Вектор
средне
Описание нарушителя Пример нарушителя
�⃗
рискованных
𝒅𝒅
атак
Злоумышленник,
удаленно
подключившийся к
СЗИ и успешно
Внешние нарушители с
(0, 2, x)
10,47
высокой квалификацией и эксплуатировавший
разными видами доступа
уязвимость по
повышению
полномочий и/или
иную уязвимость
По результатам анализа данных в Таблица 20, можно сделать
следующие выводы:
− 43,78% атак реализуются нарушителями, перечисленными выше и
считающимися неактуальными;
− 9,05% атак могут быть реализованы разработчиками СЗИ (закладка в
ПО, аппаратной прошивке, любая иная недекларированная возможность). В
случае применения сертифицированных либо разрабатываемых доверенными
производителями СЗИ, данный тип нарушителя также можно считать
неактуальным;
− 10,47%
атак
могут
быть
реализованы
любым
высококвалифицированным внешним нарушителем в случае выполнения ряда
условий (некорректным образом осуществлены настройки доступа к СЗИ, ПО
не обновляется и т.п.).
Таким образом, после внедрения в Медицинском центре ряда
организационных мер (обучение пользователей основам ИБ, внедрение
процессов, предусмотренных регламентами по ИБ и соответствующими
154
инструкциями), и с учетом уже существующих, можно считать
неактуальными:
− внутреннего
нарушителя
с
низкой,
средней
и
высокой
квалификациями и наличием прав привилегированного пользователя
(пользователей систем);
− внутреннего
нарушителя
с
низкой,
средней
и
высокой
квалификациями и отсутствием прав привилегированного пользователя
(технический и обслуживающий персонал, посетители медицинского
центра).
4. В отношении низкорискованных атак можно сказать следующее
− 28% данных атак могут быть реализованы внешним нарушителем с
разной квалификацией, но не имеющим доступа к СЗИ;
− 21,46% – могут быть реализованы тем же внешним нарушителем, если
ему удастся получиться непривилегированный доступ к СЗИ;
− 29,61% – могут быть реализованы внутренним нарушителем разной
квалификации,
не
имеющим
полномочий
в
системе
(уборщик,
обслуживающий персонал и т.п.);
− 10,46% – могут быть реализованы внутренним нарушителем разной
квалификации, имеющим непривилегированный доступ к СЗИ (пользователь).
5. В отношении типов атак:
Более 90% высокорискованных атак представлены следующими видами
(Таблица 20):
155
Таблица 20 – Основные виды высокорискованных атак
% от числа
Вектор
высоко
Описание атаки
Пример атаки
�⃗
𝒂𝒂
рискованных
атак
Атака на сетевые СЗИ
Атака, осуществляемая с с целью перехвата
непосредственным
передаваемых данных
доступом, с высокой
путем подключения к
(0, 2, 0)
32,01
сложностью реализации, локальной сети с
с целью сбора
использованием
информации
уязвимостей сетевого
оборудования
(0, 2, 1)
(0, 1, 1)
(0, 1, 0)
26,3
Атака, осуществляемая с
непосредственным
доступом, с высокой
Атака по
сложностью реализации, модификации версии
с целью причинения
BIOS
непосредственного
ущерба
13,89
Атака, осуществляемая с
непосредственным
доступом, со средней
Атака на сервер
сложностью реализации,
СКУД
с целью причинения
непосредственного
ущерба
11,91
Атака, осуществляемая с
непосредственным
доступом, со средней
сложностью реализации,
с целью сбора
информации
Сканирование
сетевого периметра
изнутри (путем
подключения в
локальную сеть) с
целью сбора
информации
156
% от числа
Вектор
высоко
Описание атаки
�⃗
𝒂𝒂
рискованных
атак
(1, 2, 1)
7,69
Продолжение Таблицы 20
Атака, осуществляемая
удаленно, с высокой
сложностью реализации,
с целью причинения
непосредственного
ущерба
Пример атаки
DDoS атака на
сетевые СЗИ,
имеющие внешние
интерфейсы
Таким образом, основная часть высококритичных атак (84%)
предполагает наличие у нарушителя непосредственного доступа к СЗИ.
Соответственно, принятых в рассматриваемом медицинском центре
организационно-технических мер (запираемое серверное помещение и
серверные шкафы, короба для каналов связи, видеонаблюдение и т.д.),
будет достаточно, чтобы данные угрозы считать неактуальными. В
частности, злоумышленник не сможет подключиться в локальную сеть
организации или пытаться вскрыть корпус оборудования, оставаясь
незамеченным.
Атаки, осуществляемые удаленно нарушителем с высокой и средней
квалификацией, представляют актуальную угрозу для рассматриваемой
системы защиты, поэтому дополнительными важными мерами для всего
срока эксплуатации являются:
− регулярный контроль уязвимостей и установка обновлений для
используемых программных и аппаратных средств;
− периодическое проведение тестов на проникновение в систему
(реализуется специалистами, имеющими соответствующую квалификацию).
157
6. Из
среднерискованных
атак,
помимо
вида
𝑎𝑎⃗ = (0, 1, 1),
формирующего 14,03%, интерес представляют следующие виды (Таблица
21):
Таблица 21 – Основные виды среднерискованных атак
% от числа
Вектор
средне
Описание атаки
Пример атаки
�⃗
рискованных
𝒂𝒂
атак
Атака, осуществляемая
удаленно, со средней
(1, 1, 0)
11,88
сложностью
реализации, с целью
Сканирование
сетевых ресурсов
сбора информации
Атака, осуществляемая
удаленно, со средней
сложностью
(1, 1, 1)
11,42
реализации, с целью
DoS-атака
причинения
непосредственного
ущерба
Атака, осуществляемая
удаленно, с высокой
(1, 2, 0)
6,97
сложностью
реализации, с целью
сбора информации
Попытки
эксплуатации
известных
уязвимостей СЗИ,
имеющих внешние
интерфейсы
Типы представленных в данной категории атак и их актуальность
рассмотрены в пункте выше.
158
Будем считать допустимым уровень риска 𝑓𝑓𝑝𝑝 = 7,47 ∗ 10−11 . В этом
случае система является подверженной всем высокорискованным и
среднерискованным атакам. Построим соответствующее множество 𝑀𝑀𝐴𝐴 :
𝑀𝑀𝐴𝐴 = � � 𝛼𝛼(𝑑𝑑⃗, 𝑠𝑠⃗),
𝑑𝑑⃗ ∈𝐷𝐷′ 𝑠𝑠⃗∈𝑆𝑆 ′
где 𝛼𝛼�𝑑𝑑⃗, 𝑠𝑠⃗� = {𝑎𝑎⃗ ∈ 𝐴𝐴: 𝐹𝐹�𝑎𝑎⃗, 𝑑𝑑⃗, 𝑠𝑠⃗� > 𝑓𝑓𝑝𝑝 } при заданном уровне риска 𝑓𝑓𝑝𝑝 =
7,47 ∗ 10−11 .
Тогда
эффективность
спроектированной
системы
защиты
составляет:
𝐸𝐸 = 𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐(𝑀𝑀𝐴𝐴 ) = 5305
(из 19440 всех векторов �𝑎𝑎⃗, 𝑑𝑑⃗, 𝑠𝑠⃗�). Чтобы оценить, какие именно атаки и
нарушители наиболее критичные с точки зрения эффективности системы
защиты, рассмотрим соответствующие вектора 𝑑𝑑⃗ и 𝑎𝑎⃗. На основе
проанализированных данных, актуальными нарушителями в отношении
разработанной системы защиты являются только внешние нарушители с
различной квалификацией и полученными в результате успешной
эксплуатации уязвимости различными уровнями доступа (Таблица 22):
Таблица 22 – Перечень актуальных нарушителей
�⃗
Вектор 𝒅𝒅
(0, 0, 0)
% реализуемых атак с
высоким уровнем риска
0
% реализуемых атак со
средним уровнем риска
0
(0, 1, 0)
0
0
(0, 2, 0)
0
1,51
(0, 0, 1)
0
0
(0, 1, 1)
0
2,70
(0, 2, 1)
0
4,67
(0, 0, 2)
0
1,51
(0, 1, 2)
0
4,67
159
(0, 2, 2)
4,47
4,29
Актуальными атаками при этом являются атаки, реализуемые
удаленно с разной степенью сложности с целью как сбора информации,
так и причинения непосредственного ущерба (Таблица 23):
Таблица 23 – Перечень актуальных атак
�⃗
% реализуемых атак с
Вектор 𝒂𝒂
высоким уровнем риска
(1, 0, 0)
0
% реализуемых атак со
средним уровнем риска
5,51
(1, 1, 0)
0
11,89
(1, 2, 0)
5,21
6,97
(1, 0, 1)
0
5,25
(1, 1, 1)
0,99
11,42
(1, 2, 1)
7,69
5,98
На основе полученных данных разработанная система защиты
информации для системы терминального доступа медицинского центра
оценивается как эффективная. Для нейтрализации выявленных актуальных
атак рекомендуемыми защитными мерами являются:
− регулярный контроль уязвимостей и установка обновлений для
используемых программных и аппаратных средств;
− периодическое проведение тестов на проникновение в систему
(реализуется специалистами, имеющими соответствующую квалификацию).
Таким образом, в результате проведенной работы согласно
разработанному Методу повышения степени доверия безопасности
вычислительной среды на тонких клиентах, входящих в состав СТД
Медицинского
центра,
была
спроектирована
система
защиты
конфиденциальной информации, включающая комплекс программных и
аппаратных средств защиты, технических и организационных мер. При
этом
гарантированность
механизмов
ИБ
корректной
обеспечивается
их
работы
спроектированных
выполнением
в
рамках
160
сформированной ДВС на тонких клиентах. Доверие к загружаемому по
сети
образу
ОС
определяется
в
результате
работы
алгоритмов
аутентификации и метода защищенной загрузки, реализованных в
АПМДЗ. При этом осуществляются все предъявляемые требования:
производится контроль выполнения субъектами определенных действий
над объектами (права доступа субъекту к ключевому контейнеру и на
загрузку образа выдаются только после успешной аутентификации);
обеспечивается
обеспечением
взаимодействие
СТД;
аутентификации)
с
критические
хранятся
в
аппаратным
данные
и
программным
(загрузчик
защищаемой
ОС,
памяти;
ключи
происходит
журналирование всех событий, касающихся ИБ, и анализ регистрационной
информации.
Функционал
остальных
подсистем
защиты
реализуется
в
программных СЗИ, отрабатывающих в рамках ДВС. Процесс оценки
эффективности
спроектированных
средств
защиты
позволяет
сформировать перечень потенциальных векторов атак, определить
соответствующий
уровень
риска
и
обеспечить
выполнение
компенсирующих организационных мер.
4.8 Выводы к четвертой главе
В четвертой главе приведено описание разработанного прототипа
АПМДСЗ,
включая
программную
реализацию
метода
контроля
целостности ОС в процессе сетевой загрузки на ТК. Приведены описание
и результаты апробации разработанных алгоритмов аутентификации,
метода контроля целостности загружаемой по сети ОС, метода анализа
эффективности системы защиты и метода повышения степени доверия
безопасности
ВС
на
ТК.
Приведены
характеристики
объекта
(медицинского центра), на котором осуществлялся проект по обеспечению
ИБ для СТД. Построена модель нарушителя и классификация угроз
161
информационной безопасности для выбранного объекта, рассмотрены
основные
предпосылки,
анализируемых
угроз,
приводящие
и
к
существующие
возможности
защитные
реализации
меры.
Для
рассматриваемого объекта создан проект системы защиты, в качестве
одного из основных механизмов включающий создание ДВС на ТК
пользователей.
Приведено
сопоставление
применяемых
средств
и
механизмов защиты выявленным угрозам. Для построенной системы
защиты сформирована параметрическая модель в соответствии с методом
оценки эффективности, проанализированы полученные результаты.
ЗАКЛЮЧЕНИЕ
На основе результатов, полученных в работе, можно сделать вывод,
что цель диссертации, сформулированная во введении, достигнута и
поставленные задачи решены. В работе был проведен тщательный анализ
методов построения доверенной вычислительной среды в отношении
объектов СТД, изучены особенности функционирования аппаратных
тонких клиентов и процесса обеспечения защиты обрабатываемой на них
информации.
В процессе исследования были решены следующие задачи:
1. Проведен анализ методов построения ДВС для объектов СТД.
2. Разработаны базовая модель нарушителя и классификация угроз
ИБ в СТД, учитывающие специфику аппаратной платформы и процесса
сетевой загрузки ОС.
3. Сформирован
перечень
требований,
необходимых
для
выполнения при построении ДВС среды на ТК.
4. Разработан метод загрузки и проверки целостности ОС на ТК.
5. Разработан
одноразовых паролей.
алгоритм
аутентификации
с
использованием
162
6. Разработан
алгоритм
аутентификации
участников
информационного взаимодействия при удаленной загрузке ОС на тонкий
клиент.
7. Разработан метод анализа эффективности системы защиты
информации.
Разработан метод повышения степени доверия безопасности ВС на
ТК.В рамках выполнения работы подана заявка на выдачу патента на
изобретение «Способ обеспечения доверенной загрузки ОС по сети на
бездисковый компьютер» (регистрационный номер заявки 2015139374 от
16.09.2015).
Разработан прототип аппаратно-программного модуля доверенной
сетевой загрузки, реализующий метод контроля целостности в процессе
сетевой загрузки ОС на тонкие клиенты. Проведено практическое
исследование разработанных алгоритмов и методов в целом, показана
эффективность
применение
предложенного
полученных
подхода,
результатов.
приведено
практическое
Теоретические
аспекты
диссертационного исследования нашли свое применение в учебных
процессах Университета ИТМО в материалах учебно-методической базы
по курсу «Экспертные системы комплексной оценки безопасности объекта
/ Технологии и методы комплексной защиты объектов», в публикациях, а
также в выступлениях на международных и отечественных конференциях,
отчетах по полученным грантам. Результаты диссертационной работы
внедрены в ООО «Акрибия. Проекты и сервис» и применены в рамках
проектной деятельности организации по обеспечению безопасности
информационных
систем.
Практическое
использование
результатов
работы подтверждено соответствующими актами внедрения (Приложение
3).
163
СПИСОК ЛИТЕРАТУРЫ
1. Dorothy, E. Denning. Cryptography and Data Security. – MA:
Addison-Wesley, Reading. – 1982. – 419 p.
2. David, K. Gifford. Cryptographic sealing for information secrecy and
authentication // Communications of the ACM. – 1982. – №25 (4). – P. 274286.
3. Критерии оценки доверенных компьютерных систем // Стандарт
Министерства обороны США, 1985.
4. Ruel, Torres Hernandez. ECPA and online computer privacy // Federal
Communications Law Journal. – 1988. – №41 (1). – P. 17-41.
5. Ронжин, А. Защита данных в информационных вычислительных
сетях. – М.: ИНКО "Ками". – 1991. – 128 с.
6. Диев, С. Математические модели сохранения целостности
информации в ЭВМ и телекоммуникационных сетях // Системы и средства
телекоммуникаций. – 1992. – № 5. – С. 18-33.
7. Щербаков, А. К вопросу о гарантированной реализации политики
безопасности в компьютерной системе // Безопасность информационных
технологий. – 1997. – № 1. – С. 15-25.
8. Бородакий, Ю., Добродеев А., Бутусов И. Доверенная среда –
основа
гарантированной
Информационная
безопасности!
безопасность.
–
[Электронный
2013.
–
№2.
ресурс]
–
//
Режим
доступа: http://www.itsec.ru/articles2/Oborandteh/doverennaya-sreda--osnovagarantirovannoy-bezopasnosti.
9. Конявский, В. А., Гадасин, В.А. Основы понимания феномена
электронного обмена информацией // Библиотека журнала «УЗИ», Кн. 2. –
Мн.: «Беллитфонд». – 2004. – 282 c.
10. Конявский, В. А. Управление защитой информации на базе СЗИ
НСД Аккорд. – М.: Радио и связь. – 1999. – 325 с.
164
11. Липаев, В. В. Надежность программного обеспечения (обзор
концепций) //Автоматика и телемеханика. – 1986. – № 10. – С. 5-31.
12. Конявский, В. А. Методы и аппаратные средства защиты
информационных технологий электронного документооборота: дис. докт.
техн. наук – Москва, 2005. – 360 с.
13. Окулесский, В., Потанин, С. Создание доверенной среды на
персональном компьютере [Электронный ресурс] // Информационная
безопасность.
Режим
–
доступа:
http://www.infosecurityrussia.ru/news/76906.
14. Конявский, В. А. Серебряная пуля для хакера (Окончание) //
Защита информации. INSIDE. – СПб, 2013. – № 5. – С. 69-73.
15. Чепанова, Е. Г., Лыдин, С. С. Облако ЦОДов, или Сон разума.
Сравнительный
анализ
представленных
на
рынке
решений
для
обеспечения доверенной загрузки ОС [Текст] // Защита информации.
Инсайд. – 2014. – № 3. – С. 56-68.
16. Алтухов, А. А. Концепция персонального устройства контроля
целостности
вычислительной
среды
[Текст]
//
Вопросы
защиты
информации. – 2014. – № 4. – С. 64-68.
17. Кравец, В. В. Доверенная вычислительная среда на планшетах
Dell. «МАРШ!» [Текст] // Вопросы защиты информации: Научнопрактический журнал/ФГУП «ВИМИ». – 2014. – № 4 (107). – С. 32-33
18. Каннер, А. М. Linux: о доверенной загрузке загрузчика ОС
[Текст] // Безопасность информационных технологий. – 2013. – №2. – С.
41-46.
19. Smith, Rod. Managing EFI Boot Loaders for Linux: Dealing with
Secure Boot [Электронный ресурс] // Персональный web-ресурс. – Режим
доступа:
свободный.
http://www.rodsbooks.com/efi-bootloaders/secureboot.html,
165
20. Wilkins, Richard, Richardson, Brian. UEFI Secure Soot in modern
computer security solutions [Текст]. – 2013. 10 p.
21. Манан, Вишал, ван дер Хуфен, Ари. Руководство по созданию
ключей безопасной загрузки и управлению ими в Windows 8.1
[Электронный
ресурс]
//
MSDN.
–
2014.
Режим
доступа:
загрузки
системы
–
https://msdn.microsoft.com/ru-ru/library/dn747883.aspx.
22. Голованов, С. Русаков, В. Атаки до
[Электронный
доступа:
ресурс]
//
Securelist.
2014
–
г.
–
Режим
https://securelist.ru/blog/issledovaniya/20151/ataki-do-zagruzki-
sistemy/.
23. Чижов, И.В. Организация защиты в системах терминального
доступа [Электронный ресурс] // Information Security / Информационная
безопасность.
–
2012.
–
№5.
–
Режим
доступа:
http://www.itsec.ru/articles2/Oborandteh/trete-dyhanie-terminalnogo-dostupa-ili-organizatsiya-zaschity-v-sistemah-terminalnogo-dostupa.-chast-1.
24. Счастный, Д. Ю. Привязка облака к земле [Текст] // Вопросы
защиты информации. – 2015. – № 1. – С. 45-47.
25. Акаткин, Ю.М., Конявский, В. А. Безопасный доступ к
корпоративным
облачным
приложениям
[Текст]
//
Information
Security/Информационная безопасность. – 2014. – № 1. – С. 23.
26. Конявский, В. А. Облако ЦОДов, или сон разума [Текст] //
Защита информации. INSIDE. – 2013. – № 5. – С. 36-37.
27. Balmer, Steven R. Analysis of Terminal Server Architectures for Thin
Clients in a High Assurance Network [Текст] // Center for Information Systems
Security Studies and Research (CISR) Faculty and Researcher Publications.
Proceedings of the 23rd National Information Systems Security Conference. –
2000. – 11 p.
28. Reynolds, G., Schwarzbacher, A. Th. Reducing IT Costs through the
Design and Implementation of a Thin Client Infrastructure in Educational
166
Environments [Текст] // IEE Irish Signals and Systems Conference. – Dublin,
2006. – P. 28-30.
29. Kohlenberg, T., Ben-Shalom, O., Dunlop, J., Rub, J. Evaluating ThinClient Security in a Changing Threat Landscape [Текст] // Intel Information
Technology. Business Solutions. – 2010. – P. 8.
30. Kelly, E. Thin Client 280 Success Secrets. – Emereo Publishing,
2014. – 206 p.
31. Счастный, Д. Ю., Конявская, С. В. Облако ЦОДов, или Сон
разума: о том, почему необходимо мыть руки перед едой, даже если они
«чистые» [Текст] // Защита информации, Inside. – 2014. – № 5. – С. 57–61.
32. Новиков, С.В., Зима, В.М., Андрушкевич, Д.В. Подход к
построению защищенных распределенных сетей обработки данных на
основе доверенной инфраструктуры [Текст] //Труды СПИИРАН. – 2015. –
№1 (38). – С. 34-57.
33. Каннер, А. М. Средство организации доверенного сеанса как
альтернатива
доверенной
вычислительной
среде
[Текст]
//
Информационные технологии управления в социально-экономических
системах. – 2010. – Выпуск 4. – С. 140-143.
34. Чугринов, А. В. Доверенные сеансы связи и Средства их
обеспечения. [Текст] // Information Security/Информационная безопасность.
2010. N 4 (август-сентябрь). С. 54-55.
35. Конявский, В. А. Доверенный сеанс связи. Развитие парадигмы
доверенных вычислительных систем - на старт, внимание, МАРШ! [Текст]
// Комплексная защита информации. Материалы XV международной научнопрактической конфереции (Иркутск, 1-4 июня 2010 г.). – М. – 2010.
36. Муха, М. Д. Система контроля целостности и аутентичности
образов
операционных
Комплексная
защита
систем,
загружаемых
информации.
по
Сборник
сети
[Текст]
материалов
//
XII
167
Международной конференции (13-16 мая 2008 г., Ярославль (Россия). –
Москва, 2008. – С. 139-140.
37. Муха, М. Д. Удаленная загрузка операционной системы Windows
CE на тонкие клиенты в терминальных системах [Текст] // Комплексная
защита
информации.
Сборник
материалов
XII
Международной
конференции (13-16 мая 2008 г., Ярославль (Россия). – Москва, 2008. – С.
141-142.
38. Конявская, С. В. Защита информации в системах терминального
доступа: [Электронный ресурс] // Information Security/Информационная
безопасность. – 2014. – № 3. – С. 53-54.
39. Alkassar, Ammar, Husseiki, Rani. Study on the Impact of Trusted
Computing on Identity and Identity Management [Текст] // Future of Identity in
the Information Society. – 2008. – 81 p.
40. Хабибуллин, И.В. Основные проблемные вопросы создания
доверенной программно-аппаратной среды для АСУ органов военного и
государственного управления [Текст] // Вопросы кибербезопасности. –
2014. – №3(4). – С. 14 – 19.
41. Information Technology Security Evaluation Criteria (ITSEC):
Preliminary Harmonised Criteria. Document COM (90) 314, Version 1.2.
Commission of the European Communities. – 1991.
42. Руководящий документ Гостехкомиссии России «Концепция
защиты средств вычислительной техники и автоматизированных систем от
несанкционированного доступа к информации». – М.: ГТК РФ. – 1992. –
12 с.
43. Руководящий
документ
Гостехкомиссии
России
«Автоматизированные системы. Защита от несанкционированного доступа
к информации. Классификация автоматизированных систем и требования
по защите информации». – М.: ГТК РФ. – 1992. – 29 с.
168
44. Руководящий документ Гостехкомиссии России «Средства
вычислительной техники защита от несанкционированного доступа к
информации.
Показатели
защищенности
от
несанкционированного
доступа к информации». – М.: ГТК РФ. – 1992. – 24 с.
45. Руководящий документ Гостехкомиссии России Безопасность
информационных
технологий.
Критерии
оценки
безопасности
информационных технологий. Часть 1. – М.: ГТК РФ. – 2002. – 56 с.
46. Руководящий документ Гостехкомиссии России «Защита от
несанкционированного доступа к информации». – М.: ГТК РФ. – 1999. –
11 с.
47. Руководящий документ Гостехкомиссии России «Руководство по
разработке профилей защиты и заданий по безопасности». – М.: ГТК РФ. –
2003. – 154 с.
48. Чепанова, Е. Г. Формирование критериев сравнения модулей
доверенной загрузки [Текст] // Вопросы защиты информации: Научнопрактический журнал ФГУП «ВИМИ». – 2014. – Выпуск 4 (107). – С. 6063.
49. Теплоухова,
О.А.
Уязвимости
механизмов
защиты
дистанционного банковского обслуживания [Текст] // Материалы научнопрактической
конференции
«Комплексная
безопасность
бизнеса
в
условиях экономической нестабильности» (Санкт-Петербург, март 2014 г.,
СПбГЭУ).
50. Жуков, Ю. Основы веб-хакинга. Нападение и защита [Текст]. –
СПб.: Питер, 2011. – 176 с.
51. ГОСТ Р ИСО/МЭК 15408-2-2002. Информационная технология.
Методы
и
средства
обеспечения безопасности. Критерии
оценки
безопасности информационных технологий. Часть 2. Функциональные
требования безопасности [Электронный ресурс]. – Режим доступа:
http://standartgost.ru/%D0%93%D0%9E%D0%A1%D0%A2%20%D0%A0%2
169
0%D0%98%D0%A1%D0%9E/%D0%9C%D0%AD%D0%9A%2015408-22002.
52. ГОСТ Р ИСО/МЭК 15408-3-2002. Информационная технология.
Методы
и
средства
обеспечения безопасности. Критерии
оценки
безопасности информационных технологий. Часть 3. Требования доверия
к
безопасности
[Электронный
ресурс].
Режим
–
доступа:
http://docs.cntd.ru/document/gost-r-iso-15408-3-2002.
53. Михалевич,
функционирования
И.Ф.
Проблемы
создания
автоматизированных
доверенной
систем
среды
управления
в
защищённом исполнении // Сборник докладов XII Всероссийского
совещания по проблемам управления ВСПУ-2014. Институт проблем
управления им. В.А. Трапезникова РАН. – 2014. – С. 9201-9207.
54. Петров, А. А. Компьютерная безопасность. Криптографические
методы защиты [Текст]. – М.: ДМК Пресс, 2008. – 448 с.
55. Зайцев, А.П., Голубятников, И.В., Мещеряков, Р.В., Шелупанов,
А.А. Программно-аппаратные средства обеспечения информационной
безопасности:
Учебное
пособие.
Издание
2-е
испр.
и
доп.
–
М.:Машиностроение-1, 2006. – 260 с.
56. Булахов,
Н.
Г.
Обнаружение
компьютерных
червей.
Статистическая модель цифровой информационной сети : научное издание
[Текст] / Н. Г. Булахов, В. Т. Калайда // Научная сессия ТУСУР-2008.
Томск : В-Спектр, 2008. – Ч. 1. – С. 39-41.
57. Szor, Peter. The Art of Computer Virus Research and Defense.
Pearson Education [Текст]. – 2005. – 744 p.
58. Никишин, А. Проактивная защита как она есть [Электронный
ресурс] // Портал компании «Лаборатория Касперского» «SECURELIST» –
Режим
доступа:
http://securelist.ru/wp-
content/blogs.dir/58/files/downloads/vlpdfs/wp_nikishin_proactive_ru.pdf.
170
59. Чижов, И. В. Третье дыхание терминального доступа, или
Организация защиты в системах терминального доступа. Часть 2. [Текст]
// Information Security/Информационная безопасность. – 2012. – № 6. – С. 2022.
60. Краснов, А.Г., Гатчин, Ю.А., Коробейников, А.Г. Управление
доступом к информационным ресурсам [Текст] // Учебное пособие. – СПб,
СПбГУ ИТМО, 2010. – 45 с.
61. Воройский, Ф. С. Информатика. Новый систематизированный
толковый словарь-справочник [Текст]. – 3-е изд. – М.: ФИЗМАТЛИТ,
2003. – 760 с.
62. Счастный, Д.Ю. Аппаратная защита терминальных сессий
[Текст]
//
Комплексная
защита
информации:
Cборник
мат.
X
Международной конференции (Суздаль, 4–7 апр. 2006 г.). – Минск, 2006. –
С. 135-136.
63. Пьянзин,
К.
Тонкие
клиенты
и
графический
интерфейс
[Электронный ресурс] // Журнал сетевых решений/LAN, – 1998. – № 02.
64. Панасенко, С.П. Принципы разработки серверных модулей
распределенных систем защиты информации. Части 1-4 // Вопросы
защиты информации. – 2010. – №2. – С. 43–62.
65. Анатольев, А.Г. Бездисковые рабочие станции. Удаленное
представление [Электронный ресурс] // Учебно-методические материалы
для
студентов
кафедры
АСОИУ.
–
Режим
доступа: http://www.4stud.info/networking/discless-workstation.html.
66. Nieh, Jason, Yang, S. Jae, Novik, Naomi. A Comparison of ThinClient Computing Architectures. Technical Report CUCS-022-00 [Текст] //
Network Computing Laboratory. – Columbia University, 2000. – 16 p.
67. Омельяненко, А. Технология «тонкий клиент» как инструмент
повышения эффективности инвестиций в ИТ-инфраструктуру [Текст] //
Финансовая газета. – 2005. – №37. – С. 11–12.
171
68. Richards, David. Linux Thin Client Networks Design and
Deployment [Текст]. – United Kingdom: Stratford Books, 2009. – 174 p.
69. Шпунт, Я. Переход на тонкие клиенты. Выгоды, затраты и
подводные камни [Текст] // Intelligent Enterprise/RE. – 2011. – №5(227). –
С. 54–55.
70. Домашняя страница проекта LTSP [Электронный ресурс]. –
Режим доступа: http://www.ltsp.org .
71. Официальный сайт проекта Edubuntu [Электронный ресурс]. –
Режим доступа: https://www.edubuntu.org.
72. Официальный сайт проекта DebianEdu [Электронный ресурс]. –
Режим доступа: https://wiki.debian.org/DebianEdu/.
73. Официальный сайт проекта ndiyo [Электронный ресурс]. –
Режим доступа: http://www.ndiyo.org.
74. Официальный сайт проекта Thinstation [Электронный ресурс]. –
Режим доступа: http://thinstation.github.io/thinstation.
75. Официальный сайт проекта WTware [Электронный ресурс]. –
Режим доступа: http://wtware.ru.
76. Официальный сайт проекта Windows Embedded [Электронный
ресурс]. – Режим доступа: https://www.microsoft.com/windowsembedded/enus/windows-embedded.aspx.
77. Официальный сайт проекта X.Org [Электронный ресурс]. –
Режим доступа: https://www.x.org/wiki/.
78. Официальный сайт проекта susestudio [Электронный ресурс]. –
Режим доступа: https://susestudio.com.
79. Чем отличаются тонкие клиенты? [Электронный ресурс] //
Терминальные
Решения.
–
Режим
доступа:
http://www.t-
sol.ru/articles/choose-thin-client.
80. Лэнс, Дж. Фишинг. Техника компьютерных преступлений
[Текст]// М.: НТ Пресс, 2010. – 320 c.
172
81. Фленов, М. Web-сервер глазами хакера [Текст]. – СПб: БХВПетербург, 2012. – 320 с.
82. Воронцов,
А.
Защита
ДБО:
традиционные
подходы
[Электронный ресурс] // Jet Info. – 2012 г. – №5. – Режим доступа:
http://www.jetinfo.ru/stati/zaschita-dbo-traditsionnye-podkhody.
83. Черепенин, С., Чубин, И. Загрузка бездисковых Linux-станций с
помощью
PXE
[Электронный
ресурс].
Режим
–
доступа:
http://www.opennet.ru/base/sys/pxe_diskless.txt.html, свободный. – Яз. рус.
(дата обращения 26.05.2015).
84. iPXE – open source boot firmware [Электронный ресурс]. – Режим
доступа: http://ipxe.org, свободный. – Яз. англ. (дата обращения
26.05.2015).
85. Полевой, М. Магия загрузки. Умный Gujin, новаторский
netboot.me и ванильный boot.kernel.org // Хакер. – 2010. – №134. – С. 84-88.
86. Велигура,
А.В.
О
выборе
методики
оценки
рисков
информационной безопасности [Текст] // Информационная безопасность. –
2010. – №7. – С.23–31.
87. Савельева, А.А. Модели и методы комплексной оценки
аппаратно-программных средств обеспечения конфиденциальности и
целостности информации: дис. канд. техн. наук. – 2011. – 123 с.
88. Куракин, А.С., Теплоухова, О.А. Алгоритм проведения анализа
защищенности
информационных
систем
персональных
данных
от
несанкционированного доступа [Текст] // Сборник научных трудов по
материалам международной научно-практической конференции «Научные
исследования и их практическое применение. Современное состояние и
пути развития 2012». Том 4. Технические науки. – Одесса: КУПРИЕНКО,
2012, – 96 с. – С. 48–50 (октябрь 2012).
89. ГОСТ Р 51583-2000 «Защита информации. Порядок создания
автоматизированных
систем
в
защищенном
исполнении.
Общие
173
положения». Разработан 5 ЦНИИИ МО РФ. Принят и введен в действие
Постановлением Госстандарта России от 6 апреля 2000 г. № 95-ст.
90. ГОСТ Р 51624-2000 «Защита информации. Автоматизированные
системы в защищенном исполнении». Разработан 5 ЦНИИИ МО РФ.
Принят и введен в действие Постановлением Госстандарта России от 30
июня 2000 г. 175-ст.
91. Базовая модель угроз безопасности персональных данных при их
обработке
в
информационных
системах
персональных
данных.
Утверждена Заместителем директора ФСТЭК России 15 февраля 2008 г.
92. Модель угроз и нарушителя безопасности персональных данных,
обрабатываемых в типовых информационных системах персональных
данных отрасли. Министерство связи и массовых коммуникаций
Российской Федерации. Введена 21 апреля 2010. – М.: 2010. – 42 с.
93. Методика
определения
актуальных
угроз
безопасности
персональных данных при их обработке в информационных системах
персональных
данных.
Федеральная
служба
по
техническому
и
экспортному контролю. Утверждена Заместителем директора ФСТЭК
России 14 февраля 2008 г.
94. ГОСТ Р ИСО/МЭК 31010-2011. Менеджмент риска. Методы
оценки риска. Национальный стандарт российской федерации. Введен в
действие 01.12.2012.
95. ГОСТ Р ИСО/МЭК 27005-2010 Информационная технология.
Методы и средства обеспечения безопасности. Менеджмент риска
информационной безопасности. Национальный стандарт российской
федерации. Введен в действие 01.12.2011.
96. Костечко, Н.Н., Лазуренко, И.П., Хади, Р.А. Модель нарушителя
в комплексах организации доступа к информации в компьютерных сетях //
Научная мысль Кавказа. Приложение. ISBN 5-87872-108-2. – Ростов-наДону, Издательство СКНЦ ВШ, 2004. – №6. – С. 131-136.
174
97. Дунин, В.С., Хохлов, Н.С. Модель угроз информационной
безопасности
комплексной
автоматизированной
интеллектуальной
системы «Безопасный город» / Вестник Воронежского Института МВД
России. – 2011. – № 4. – С. 7-12.
98. Методические
рекомендации
по
разработке
нормативных
правовых актов, определяющих угрозы безопасности персональных
данных,
актуальные
при
обработке
персональных
данных
в
информационных системах персональных данных, эксплуатируемых при
осуществлении
соответствующих
видов
деятельности.
Утверждены
руководством 8 Центра ФСБ России 31 марта 2015 года № 149/7/2/6-432.
99. Методический документ. Профиль защиты. Средства доверенной
загрузки уровня загрузочной записи шестого класса защиты. Утверждены
ФСТЭК России 30 декабря 2013 года.
100. Нестерук, Г. Ф., Молдовян, А. А., Осовецкий, Л. Г. и др. К
разработке модели адаптивной защиты информации [Текст] // Вопросы
защиты информации. – 2005. – № 3. – С. 11–16.
101. Теплоухова, О.А. Построение модели угроз защищенности
образа операционной системы, загружаемого по сети на тонкие клиенты в
системах
терминального
доступа
[Текст]
//
Сборник
трудов
III
Всероссийского конгресса молодых ученых. – СПб.: Университет ИТМО.
– 2014. – С. 151-156.
102. Гатчин, Ю.А., Теплоухова, О.А. Способы контроля целостности
образа операционной системы при удаленной загрузке на тонкие клиенты
в системах терминального доступа [Текст] // Электронный сборник
тезисов докладов II Всероссийского конгресса молодых ученых, СПбНИУ
ИТМО (Санкт-Петербург, апрель 2013). – 2013. – С. 52–53.
103. Гатчин,
Ю.А.,
Теплоухова,
О.А.
Разработка
решения,
реализующего контроль целостности операционной системы при сетевой
загрузке
на
тонкие
клиенты
[Текст]
//
Труды
Конгресса
по
175
интеллектуальным системам и информационным технологиям «IS&IT'14».
Научное издание в 4-х томах. – М.: Физматлит, 2014. – Т.3. – С. 243–248.
104. ГОСТ Р ИСО/МЭК 27000-2012. Информационная технология.
Методы и средства обеспечения безопасности. Системы менеджмента
информационной безопасности. Общий обзор и терминология. Утвержден
и введен в действие Приказом Федерального агентства по техническому
регулированию и метрологии от 1 декабря 2011 г. N 681-ст.
105. Алферов, А. П., Зубов, А. Ю., Кузьмин А. С., Черемушкин, А.
В. Основы криптографии: учебн. пособие [Текст]. – М.: Гелиос АРВ, 2005.
– 480 с.
106. ГОСТ
Р
34.11-2012
«Информационная
технология.
Криптографическая защита информации. Функция хеширования». Введ.
07.08.2012. – М.: Стандартинформ, 2012. – 29 с.
107. Гатчин, Ю.А., Теплоухова, О.А., Куракин, А.С. Алгоритм
контроля целостности деперсонализированных данных в ИСПДн [Текст] //
Научно-технический вестник информационных технологий, механики и
оптики. – 2013. – № 1(83). С. – 145–148.
108. Молдовян, А. А., Молдовян, Н. А. Введение в криптосистемы с
открытым ключом [Текст]. – СПб.: БХВ-Петербург, 2005. – 286 с.
109. Гатчин,
Ю.А.,
Теплоухова,
О.А.
Реализация
контроля
целостности образа операционной системы, загружаемого по сети на
тонкий клиент [Текст] // Научно-технический вестник информационных
технологий, механики и оптики. – 2015. – Т. 15. – № 6. С. – 1115–1121.
110. Черемушкин, А. В. Криптографические протоколы. Основные
свойства и уязвимости: учебное пособие для студ. учреждений высш.
проф. образования [Текст]. – М.: Издательский центр «Академия», 2009. –
272 с.
111. Горбенко, Ю. И., Олешко, И. В. Модели и методы оценки
защищенности механизмов многофакторной аутентификации [Текст] //
176
Восточно-Европейский журнал передовых технологий. – 2013. – Выпуск
№ 2 (66). Том 6. – С. 4-10.
112. Гатчин, Ю.А., Теплоухова, О.А. Реализация защищенного
подключения к государственным информационным системам на базе
тонкого клиента [Текст] // Международный технико-экономический
журнал. – 2015. – №5. – С. 55-62.
113. Об утверждении Требований о защите информации, не
составляющей государственную тайну, содержащейся в государственных
информационных системах: приказ ФСТЭК Рос. Федерации от 11 февраля
2013 г. №17: зарегистр. в Минюсте 31 мая 2013 г. // Рос. Газ. — 2013. — 26
июня.
114. Гатчин, Ю.А., Теплоухова, О.А. Алгоритм аутентификации
участников информационного взаимодействия при удаленной загрузке
операционной системы на тонкий клиент [Текст] // Научно-технический
вестник информационных технологий, механики и оптики. – 2016. – Т.16.
№3. – С. 497-505.
115. Горбатов, В.С. Полянская, О.Ю. Основы технологии PKI
[Текст]. – М.: Горячая линия – Телеком, 2004. – 248 с.
116. ГОСТ 28147-89. Системы обработки информации. Защита
криптографическая. Алгоритм криптографического преобразования. Введ.
01.07.1990. – М.: Госстандарт, 1989.
117. RFC 4357. Дополнительные криптографические алгоритмы для
использования совместно с ГОСТ 28147-89, ГОСТ 34.10-94, ГОСТ 34.102001 и ГОСТ 34.11-94. 2006 [Электронный ресурс] // Портал RFC-Base.org.
– Режим доступа: http://www.rfc-base.org/rfc-4357.html.
118. RFC 2865. Remote Authentication Dial In User Service (RADIUS).
– 2000 [Электронный ресурс] // Портал RFC-Base.org. – Режим доступа:
http://www.rfc-base.org/rfc-2865.html.
177
119. Dirk van der Walt. FreeRADIUS Beginner's Guide. Manage your
network resources with FreeRADIUS [Текст]. – М.: Книга по требованию,
2011. – 344 с.
120. ISO 9000:2005. Системы менеджмента качества. Основные
положения и словарь. М.: Технорматив, 2005. 37 с.
121. Гатчин, Ю.А., Теплоухова, О.А. Анализ эффективности
системы защиты информации [Текст] // Вестник компьютерных и
информационных технологи. – М.:ООО "Издательский дом "Спектр". –
2015. – №7. – С. 29-32.
122. Осовецкий, Л. Г., Шевченко, В. В. Оценка защищенности сетей
и систем [Текст] // Экспресс электроника. – 2002. – № 2–3. – С. 20-24.
123. Бондарь,
И.
В.
Методика
построения
модели
угроз
безопасности информации для автоматизированных систем [Текст] //
Вестник Сибирского государственного аэрокосмического университета
им. акад. М. Ф. Решетнева. – 2012. – № 3. – С. 7 –10.
124. Бирюков, А. А. Информационная безопасность: защита и
нападение [Текст]. – М.: ДМК Пресс, 2012. – 474 с.
125. Стефаров, А. П. Жуков, В. Г. Формирование типовой модели
нарушителя
правил
разграничения
доступа
в
автоматизированных
системах [Текст] // Изв. ЮФУ. Техн. науки. – 2012. – № 12. – С. 45 – 54.
126. Баутов, А. Эффективность защиты информации [Текст] / А.
Баутов // Открытые системы. – 2003. – №7. – С. 15-20.
127. Панин, О.А. Анализ эффективности интегрированных систем
безопасности: принципы, критерии, методы [Электронный ресурс] //
Системы
безопасности.
–
2006.
–
№2.
–
Режим
доступа:
http://www.secuteck.ru/articles2/kompleks_sys_sec/analiz_effektivnosti.
128. Специальные требования и рекомендации по технической
защите
конфиденциальной
информации
(СТР-К).
Разработаны
государственной технической комиссией ПРИ ПРЕЗИДЕНТЕ РФ. Ведены
178
в действие Решением Коллегии Гостехкомиссии России № 7.2/02.03.2001
г.
129. Об утверждении требований к защите персональных данных
при их обработке в информационных системах персональных данных
[Текст]: постан. Правительства Рос. Федерации от 1 ноября 2012 г. №1119
// Рос. Газ. – 2012/ – 7 ноября.
130. Об утверждении Состава и содержания организационных и
технических мер по обеспечению безопасности персональных данных при
их обработке в информационных системах персональных данных [Текст]:
приказ ФСТЭК Рос. Федерации от 18 февраля 2013 г. №21: зарегистр. в
Минюсте 14 мая 2013 г. // Рос. Газ. – 2013. – 22 мая.
131. Об утверждении Состава и содержания организационных и
технических мер по обеспечению безопасности персональных данных при
их обработке в информационных системах персональных данных с
использованием
средств
криптографической
защиты
информации,
необходимых для выполнения установленных Правительством Российской
Федерации требований к защите персональных данных для каждого из
уровней защищенности [Текст]: приказ ФСБ Рос. Федерации от 10 июля
2014 г. №378: зарегистр. в Минюсте 18 августа 2014 г.: рег. N33620 // Рос.
Газ. – 2014. – 17 сентября.
132. Singhal, A., Ou, X. Security Risk Analysis of Enterprise Networks
Using Probabilistic Attack Graphs (Текст). NIST InterAgency Report,
September 2011. 24 p.
133. Основные технические и эксплуатационные характеристики
JaCarta PKI/ГОСТ [Электронный ресурс] // Официальный сайт компании
"Аладдин
Р.Д.".
–
Режим
доступа:
http://www.aladdin-
rd.ru/catalog/jacarta/pki-gost/specification.
134. О персональных данных [Текст]: федер. закон Рос. Федерации
от 27 июля 2006 года №152-ФЗ: принят Гос. Думой Федер. Собр. Рос.
179
Федерации 8 июля 2006 г.: одобр. Советом Федерации Федер. Собр. Рос.
Федерации 14 июля 2006 г. //Рос. Газ. – 2006. – 29 июля.
135. Об основах охраны здоровья граждан в Российской Федерации
[Текст]: федер. закон Рос. Федерации от 21 ноября 2011 г. №323-ФЗ:
принят Гос. Думой Федер. Собр. Рос. Федерации 1 ноября 2011 г.: одобрен
Советом Федерации Федер. Собр. Рос. Федерации 9 ноября 2011 г. // Рос.
Газ. – 2011. – 23 ноября.
136. Трудовой кодекс Российской Федерации [Текст]: федер. закон
Рос. Федерации от 30.12.2001 №197-ФЗ: принят Гос. Думой Федер. Собр.
Рос. Федерации 21 декабря 2001 г.: одобрен Советом Федерации Федер.
Собр. Рос. Федерации 26 декабря 2001 г. // КонсультантПлюс
[Электронный
ресурс].
–
Режим
доступа:
http://www.consultant.ru/document/cons_doc_LAW_34683/, свободный. – Яз.
Рус.
137. Об информации, информационных технологиях и защите
информации [Текст]: федер. закон Рос. Федерации от 27 июля 2006 года
№149-ФЗ: принят Гос. Думой Федер. Собр. Рос. Федерации 8 июля 2006
г.: одобр. Советом Федерации Федер. Собр. Рос. Федерации 14 июля 2006
г. //Рос. Газ. – 2006. – 29 июля.
180
ПРИЛОЖЕНИЕ 1
�⃗, �𝒂𝒂⃗�
�⃗, �𝒂𝒂⃗) И 𝑷𝑷�𝒅𝒅
ЗНАЧЕНИЯ ФУНКЦИЙ �𝑳𝑳𝒒𝒒𝒒𝒒 (𝒔𝒔, 𝒂𝒂)�, ‖𝑷𝑷𝒕𝒕𝒕𝒕 (𝒅𝒅, 𝒂𝒂)‖, 𝑳𝑳(𝒔𝒔
Таблица 24 – Множество значений функции �𝐿𝐿𝑞𝑞𝑞𝑞 (𝑠𝑠, 𝑎𝑎)�
0
1
2
0
1
2
0
1
2
3
4
0
1
𝑺𝑺𝟏𝟏
𝑺𝑺𝟐𝟐
𝑺𝑺𝟑𝟑
𝑺𝑺𝟒𝟒
𝑨𝑨𝟏𝟏
0
0,2
0,4
0,4
0,2
0,4
0,4
0,142857
0,142857
0,142857
0,285714
0,285714
0,5
0,5
1
0,333333
0,333333
0,333333
0,333333
0,333333
0,333333
0,142857
0,142857
0,142857
0,285714
0,285714
0
1
0
0,333333
0,333333
0,333333
0,333333
0,333333
0,333333
0
0
0,2
0,4
0,4
0,2
0,25
𝑨𝑨𝟐𝟐
1
0,333333
0,333333
0,333333
0,333333
0,333333
0,333333
0,125
0,125
0,25
0,25
0,25
0,25
0,4
2
0,333333
0,333333
0,333333
0,333333
0,333333
0,333333
0,142857
0,142857
0,142857
0,285714
0,285714
0,4
0,5
Таблица 25 – Множество значений функции ‖𝑃𝑃𝑡𝑡𝑡𝑡 (𝑠𝑠, 𝑎𝑎)‖
0
1
0
1
2
0
1
2
𝑫𝑫𝟏𝟏
𝑫𝑫𝟐𝟐
𝑫𝑫𝟑𝟑
0
0
1
0,2
0,4
0,4
0,2
0,4
0,4
𝑨𝑨𝟏𝟏
1
0,5
0,5
0,25
0,25
0,5
0,25
0,25
0,5
0
0,5
0,5
0,333333
0,333333
0,333333
0,333333
0,333333
0,333333
𝑨𝑨𝟐𝟐
1
0,333333
0,666667
0,2
0,4
0,4
0,2
0,4
0,4
�⃗
Таблица 26 – Обозначения векторов �𝒂𝒂⃗, �⃗
𝒔𝒔 и 𝒅𝒅
№
1
2
3
4
5
6
7
8
9
𝑨𝑨𝟏𝟏
0
1
0
1
0
1
0
1
0
�⃗
Вектора 𝒂𝒂
𝑨𝑨𝟐𝟐
0
0
1
1
2
2
0
0
1
𝑨𝑨𝟑𝟑
0
0
0
0
0
0
1
1
1
№
1
2
3
4
5
6
7
8
9
𝑺𝑺𝟏𝟏
0
1
2
0
1
2
0
1
2
2
0,5
0,5
0
0,333333
0,666667
0
0,333333
0,666667
𝑨𝑨𝟑𝟑
0
0,333333
0,333333
0,333333
0,4
0,4
0,2
0,285714
0,285714
0,142857
0,142857
0,142857
0,5
0,5
𝑨𝑨𝟑𝟑
0
0,333333
0,666667
0,2
0,4
0,4
0,2
0,4
0,4
�⃗
Вектора 𝒔𝒔
𝑺𝑺𝟐𝟐
𝑺𝑺𝟑𝟑
0
0
0
0
0
0
1
0
1
0
1
0
2
0
2
0
2
0
1
0,2
0,4
0,4
0,2
0,4
0,4
0,285714
0,285714
0,142857
0,142857
0,142857
0,5
0,5
1
0,333333
0,666667
0,25
0,25
0,5
0,25
0,25
0,5
𝑺𝑺𝟒𝟒
0
0
0
0
0
0
0
0
0
181
Продолжение Таблицы 26
№
10
11
12
№
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
𝑨𝑨𝟏𝟏
1
0
1
�⃗
Вектора 𝒂𝒂
𝑨𝑨𝟐𝟐
1
2
2
𝑨𝑨𝟑𝟑
1
1
1
𝑫𝑫𝟏𝟏
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
�⃗
Вектора 𝒅𝒅
𝑫𝑫𝟐𝟐
0
0
1
1
2
2
0
0
1
1
2
2
0
0
1
1
2
2
𝑫𝑫𝟑𝟑
0
0
0
0
0
0
1
1
1
1
1
1
2
2
2
2
2
2
№
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
𝑺𝑺𝟏𝟏
0
1
2
0
2
0
1
2
0
1
2
0
1
2
0
1
2
0
1
2
0
1
2
0
1
2
0
1
2
0
1
2
0
1
2
0
1
2
0
1
2
0
�⃗
Вектора 𝒔𝒔
𝑺𝑺𝟐𝟐
𝑺𝑺𝟑𝟑
0
1
0
1
0
1
1
1
1
1
1
1
2
1
2
1
2
1
0
2
0
2
0
2
1
2
1
2
1
2
2
2
2
2
2
2
0
3
0
3
0
3
1
3
1
3
1
3
2
3
2
3
2
3
0
4
0
4
0
4
1
4
1
4
1
4
2
4
2
4
2
4
0
0
0
0
0
0
1
0
1
0
1
0
2
0
𝑺𝑺𝟒𝟒
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
1
1
1
1
1
1
182
Продолжение Таблицы 26
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
1
2
0
1
2
0
1
2
0
1
2
0
1
2
0
1
2
0
1
2
0
1
2
0
1
2
0
1
2
0
1
2
0
1
2
0
1
2
�⃗
Вектора 𝒔𝒔
2
0
2
0
0
1
0
1
0
1
1
1
1
1
1
1
2
1
2
1
2
1
0
2
0
2
0
2
1
2
1
2
1
2
2
2
2
2
2
2
0
3
0
3
0
3
1
3
1
3
1
3
2
3
2
3
2
3
0
4
0
4
0
4
1
4
1
4
1
4
2
4
2
4
2
4
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
�⃗, �𝒂𝒂⃗)
Таблица 27 – Множество значений функции 𝑳𝑳(𝒔𝒔
�⃗
№ вектора 𝒂𝒂
�⃗
№ вектора 𝒔𝒔
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
183
1
2
3
4
5
6
7
8
9
10
11
12
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1,21E-07
2,42E-07
2,42E-07
2,42E-07
4,84E-07
4,84E-07
1,21E-07
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1,8896E-07
3,7793E-07
3,7793E-07
3,7793E-07
7,5586E-07
7,5586E-07
1,8896E-07
3,7793E-07
3,7793E-07
1,8896E-07
3,7793E-07
3,7793E-07
3,7793E-07
7,5586E-07
7,5586E-07
1,8896E-07
3,7793E-07
3,7793E-07
1,8896E-07
3,7793E-07
3,7793E-07
3,7793E-07
7,5586E-07
7,5586E-07
1,8896E-07
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
3,46E-07
6,91E-07
6,91E-07
6,91E-07
1,38E-06
1,38E-06
3,46E-07
6,91E-07
6,91E-07
3,46E-07
6,91E-07
6,91E-07
6,91E-07
1,38E-06
1,38E-06
3,46E-07
6,91E-07
6,91E-07
1,73E-07
3,46E-07
3,46E-07
3,46E-07
6,91E-07
6,91E-07
1,73E-07
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
3,63E-08
1,45E-07
1,45E-07
1,45E-07
5,8E-07
5,8E-07
1,45E-07
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
5,67E-08
2,27E-07
2,27E-07
2,27E-07
9,07E-07
9,07E-07
2,27E-07
9,07E-07
9,07E-07
5,67E-08
2,27E-07
2,27E-07
2,27E-07
9,07E-07
9,07E-07
2,27E-07
9,07E-07
9,07E-07
5,67E-08
2,27E-07
2,27E-07
2,27E-07
9,07E-07
9,07E-07
2,27E-07
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1,04E-07
4,15E-07
4,15E-07
4,15E-07
1,66E-06
1,66E-06
4,15E-07
1,66E-06
1,66E-06
1,04E-07
4,15E-07
4,15E-07
4,15E-07
1,66E-06
1,66E-06
4,15E-07
1,66E-06
1,66E-06
5,18E-08
2,07E-07
2,07E-07
2,07E-07
8,29E-07
8,29E-07
2,07E-07
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
184
�⃗
№ вектора 𝒂𝒂
№ вектора �⃗𝒔𝒔
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
Продолжение Таблицы 27
1
2
3
4
5
6
7
8
9
10
11
12
2,42E-07
2,42E-07
4,84E-07
9,67E-07
9,67E-07
9,67E-07
1,93E-06
1,93E-06
4,84E-07
9,67E-07
9,67E-07
4,84E-07
9,67E-07
9,67E-07
9,67E-07
1,93E-06
1,93E-06
4,84E-07
9,67E-07
9,67E-07
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
3,7793E-07
3,7793E-07
3,7793E-07
7,5586E-07
7,5586E-07
7,5586E-07
1,5117E-06
1,5117E-06
3,7793E-07
7,5586E-07
7,5586E-07
3,7793E-07
7,5586E-07
7,5586E-07
7,5586E-07
1,5117E-06
1,5117E-06
3,7793E-07
7,5586E-07
7,5586E-07
3,0234E-07
6,0469E-07
6,0469E-07
6,0469E-07
1,2094E-06
1,2094E-06
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1,68E-06
1,68E-06
1,68E-06
1,68E-06
1,68E-06
1,68E-06
3,46E-07
3,46E-07
6,91E-07
1,38E-06
1,38E-06
1,38E-06
2,76E-06
2,76E-06
6,91E-07
1,38E-06
1,38E-06
6,91E-07
1,38E-06
1,38E-06
1,38E-06
2,76E-06
2,76E-06
6,91E-07
1,38E-06
1,38E-06
4,32E-07
8,64E-07
8,64E-07
8,64E-07
1,73E-06
1,73E-06
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
2,4E-06
2,4E-06
2,4E-06
2,4E-06
2,4E-06
2,4E-06
5,8E-07
5,8E-07
1,45E-07
5,8E-07
5,8E-07
5,8E-07
2,32E-06
2,32E-06
5,8E-07
2,32E-06
2,32E-06
1,45E-07
5,8E-07
5,8E-07
5,8E-07
2,32E-06
2,32E-06
5,8E-07
2,32E-06
2,32E-06
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
9,07E-07
9,07E-07
1,13E-07
4,54E-07
4,54E-07
4,54E-07
1,81E-06
1,81E-06
4,54E-07
1,81E-06
1,81E-06
1,13E-07
4,54E-07
4,54E-07
4,54E-07
1,81E-06
1,81E-06
4,54E-07
1,81E-06
1,81E-06
9,07E-08
3,63E-07
3,63E-07
3,63E-07
1,45E-06
1,45E-06
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
5,04E-07
1,01E-06
1,01E-06
1,01E-06
2,02E-06
2,02E-06
8,29E-07
8,29E-07
2,07E-07
8,29E-07
8,29E-07
8,29E-07
3,32E-06
3,32E-06
8,29E-07
3,32E-06
3,32E-06
2,07E-07
8,29E-07
8,29E-07
8,29E-07
3,32E-06
3,32E-06
8,29E-07
3,32E-06
3,32E-06
1,3E-07
5,18E-07
5,18E-07
5,18E-07
2,07E-06
2,07E-06
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
7,2E-07
1,44E-06
1,44E-06
1,44E-06
2,88E-06
2,88E-06
185
�⃗
№ вектора 𝒂𝒂
№ вектора �⃗𝒔𝒔
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
Продолжение Таблицы 27
1
2
3
4
5
6
7
8
9
10
11
12
0
0
0
0
0
0
0
0
0
0
0
0
1,51E-07
3,02E-07
3,02E-07
3,02E-07
6,05E-07
6,05E-07
1,51E-07
3,02E-07
3,02E-07
6,05E-07
1,21E-06
1,21E-06
1,21E-06
2,42E-06
0
0
0
0
0
0
0
0
0
0
0
0
8,4E-07
8,4E-07
8,4E-07
8,4E-07
8,4E-07
8,4E-07
4,2E-07
4,2E-07
4,2E-07
3,36E-06
3,36E-06
3,36E-06
3,36E-06
3,36E-06
3,0234E-07
6,0469E-07
6,0469E-07
3,0234E-07
6,0469E-07
6,0469E-07
6,0469E-07
1,2094E-06
1,2094E-06
3,0234E-07
6,0469E-07
6,0469E-07
3,0234E-07
6,0469E-07
6,0469E-07
6,0469E-07
1,2094E-06
1,2094E-06
3,0234E-07
6,0469E-07
6,0469E-07
6,0469E-07
1,2094E-06
1,2094E-06
1,2094E-06
2,4187E-06
8,4E-07
8,4E-07
8,4E-07
1,68E-06
1,68E-06
1,68E-06
1,68E-06
1,68E-06
1,68E-06
8,4E-07
8,4E-07
8,4E-07
1,68E-06
1,68E-06
1,68E-06
1,68E-06
1,68E-06
1,68E-06
8,4E-07
8,4E-07
8,4E-07
3,36E-06
3,36E-06
3,36E-06
3,36E-06
3,36E-06
4,32E-07
8,64E-07
8,64E-07
4,32E-07
8,64E-07
8,64E-07
8,64E-07
1,73E-06
1,73E-06
4,32E-07
8,64E-07
8,64E-07
2,16E-07
4,32E-07
4,32E-07
4,32E-07
8,64E-07
8,64E-07
2,16E-07
4,32E-07
4,32E-07
8,64E-07
1,73E-06
1,73E-06
1,73E-06
3,46E-06
1,2E-06
1,2E-06
1,2E-06
2,4E-06
2,4E-06
2,4E-06
2,4E-06
2,4E-06
2,4E-06
1,2E-06
1,2E-06
1,2E-06
1,2E-06
1,2E-06
1,2E-06
1,2E-06
1,2E-06
1,2E-06
6E-07
6E-07
6E-07
4,8E-06
4,8E-06
4,8E-06
4,8E-06
4,8E-06
0
0
0
0
0
0
0
0
0
0
0
0
4,54E-08
1,81E-07
1,81E-07
1,81E-07
7,26E-07
7,26E-07
1,81E-07
7,26E-07
7,26E-07
1,81E-07
7,26E-07
7,26E-07
7,26E-07
2,9E-06
0
0
0
0
0
0
0
0
0
0
0
0
2,52E-07
5,04E-07
5,04E-07
5,04E-07
1,01E-06
1,01E-06
5,04E-07
1,01E-06
1,01E-06
1,01E-06
2,02E-06
2,02E-06
2,02E-06
4,03E-06
3,63E-07
1,45E-06
1,45E-06
9,07E-08
3,63E-07
3,63E-07
3,63E-07
1,45E-06
1,45E-06
3,63E-07
1,45E-06
1,45E-06
9,07E-08
3,63E-07
3,63E-07
3,63E-07
1,45E-06
1,45E-06
3,63E-07
1,45E-06
1,45E-06
1,81E-07
7,26E-07
7,26E-07
7,26E-07
2,9E-06
1,01E-06
2,02E-06
2,02E-06
5,04E-07
1,01E-06
1,01E-06
1,01E-06
2,02E-06
2,02E-06
1,01E-06
2,02E-06
2,02E-06
5,04E-07
1,01E-06
1,01E-06
1,01E-06
2,02E-06
2,02E-06
1,01E-06
2,02E-06
2,02E-06
1,01E-06
2,02E-06
2,02E-06
2,02E-06
4,03E-06
5,18E-07
2,07E-06
2,07E-06
1,3E-07
5,18E-07
5,18E-07
5,18E-07
2,07E-06
2,07E-06
5,18E-07
2,07E-06
2,07E-06
6,48E-08
2,59E-07
2,59E-07
2,59E-07
1,04E-06
1,04E-06
2,59E-07
1,04E-06
1,04E-06
2,59E-07
1,04E-06
1,04E-06
1,04E-06
4,15E-06
1,44E-06
2,88E-06
2,88E-06
7,2E-07
1,44E-06
1,44E-06
1,44E-06
2,88E-06
2,88E-06
1,44E-06
2,88E-06
2,88E-06
3,6E-07
7,2E-07
7,2E-07
7,2E-07
1,44E-06
1,44E-06
7,2E-07
1,44E-06
1,44E-06
1,44E-06
2,88E-06
2,88E-06
2,88E-06
5,76E-06
186
�⃗
№ вектора 𝒂𝒂
№ вектора �⃗𝒔𝒔
78
79
80
81
82
83
84
85
86
87
88
89
90
1
2
3
4
5
6
7
8
9
10
11
12
2,42E-06
6,05E-07
1,21E-06
1,21E-06
6,05E-07
1,21E-06
1,21E-06
1,21E-06
2,42E-06
2,42E-06
6,05E-07
1,21E-06
1,21E-06
3,36E-06
1,68E-06
1,68E-06
1,68E-06
3,36E-06
3,36E-06
3,36E-06
3,36E-06
3,36E-06
3,36E-06
1,68E-06
1,68E-06
1,68E-06
2,4187E-06
6,0469E-07
1,2094E-06
1,2094E-06
6,0469E-07
1,2094E-06
1,2094E-06
1,2094E-06
2,4187E-06
2,4187E-06
6,0469E-07
1,2094E-06
1,2094E-06
3,36E-06
1,68E-06
1,68E-06
1,68E-06
3,36E-06
3,36E-06
3,36E-06
3,36E-06
3,36E-06
3,36E-06
1,68E-06
1,68E-06
1,68E-06
3,46E-06
8,64E-07
1,73E-06
1,73E-06
8,64E-07
1,73E-06
1,73E-06
1,73E-06
3,46E-06
3,46E-06
8,64E-07
1,73E-06
1,73E-06
4,8E-06
2,4E-06
2,4E-06
2,4E-06
4,8E-06
4,8E-06
4,8E-06
4,8E-06
4,8E-06
4,8E-06
2,4E-06
2,4E-06
2,4E-06
2,9E-06
7,26E-07
2,9E-06
2,9E-06
1,81E-07
7,26E-07
7,26E-07
7,26E-07
2,9E-06
2,9E-06
7,26E-07
2,9E-06
2,9E-06
4,03E-06
2,02E-06
4,03E-06
4,03E-06
1,01E-06
2,02E-06
2,02E-06
2,02E-06
4,03E-06
4,03E-06
2,02E-06
4,03E-06
4,03E-06
2,9E-06
7,26E-07
2,9E-06
2,9E-06
1,81E-07
7,26E-07
7,26E-07
7,26E-07
2,9E-06
2,9E-06
7,26E-07
2,9E-06
2,9E-06
4,03E-06
2,02E-06
4,03E-06
4,03E-06
1,01E-06
2,02E-06
2,02E-06
2,02E-06
4,03E-06
4,03E-06
2,02E-06
4,03E-06
4,03E-06
4,15E-06
1,04E-06
4,15E-06
4,15E-06
2,59E-07
1,04E-06
1,04E-06
1,04E-06
4,15E-06
4,15E-06
1,04E-06
4,15E-06
4,15E-06
5,76E-06
2,88E-06
5,76E-06
5,76E-06
1,44E-06
2,88E-06
2,88E-06
2,88E-06
5,76E-06
5,76E-06
2,88E-06
5,76E-06
5,76E-06
�⃗, �𝒂𝒂⃗�
Таблица 28 – Множество значений функции P�𝒅𝒅
�⃗
№ вектора 𝒅𝒅
1
2
3
4
5
6
7
�⃗
№ вектора 𝒂𝒂
Продолжение Таблицы 27
1
2
3
4
5
6
7
8
9
10
11
12
0
5,93E-05
0
0,000237
0
0,000237
0
2,31481E-05
4,62963E-05
4,62963E-05
9,25926E-05
9,25926E-05
0,000185185
4,62963E-05
0
2,84E-05
0
0,000228
0
0,000228
0
5,56E-06
2,22E-05
2,22E-05
8,89E-05
4,44E-05
0,000178
2,22E-05
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
9,26E-05
0
0,000185
0
0,00037
0
3,62E-05
7,23E-05
3,62E-05
7,23E-05
0,000145
0,000289
3,62E-05
0
4,44E-05
0
0,000178
0
0,000356
0
8,68E-06
3,47E-05
1,74E-05
6,94E-05
6,94E-05
0,000278
1,74E-05
0
0
0
0
0
0
0
0
0
0
0
0
0
0
187
�⃗
№ вектора 𝒂𝒂
№ вектора �𝒅𝒅⃗
8
9
10
11
12
13
14
15
16
17
18
Продолжение Таблицы 28
1
2
3
4
5
6
7
8
9
10
11
12
0,000237
0
0,000948
0
0,000948
0
0,000237
0
0,000948
0
0,000948
9,25926E-05
9,25926E-05
0,000185185
0,000185185
0,00037037
9,25926E-05
0,000185185
0,000185185
0,00037037
0,00037037
0,000740741
0,000228
0
0,00182
0
0,00182
0
0,000228
0
0,00182
0
0,00182
8,89E-05
8,89E-05
0,000356
0,000178
0,000711
4,44E-05
0,000178
0,000178
0,000711
0,000356
0,001422
0
0
0,000948
0
0,001896
0
0
0
0,001896
0
0,003793
0
9,26E-05
0,000185
0,00037
0,000741
0
0
0,00037
0,000741
0,001481
0,002963
0,000185
0
0,00037
0
0,000741
0
0,00037
0
0,000741
0
0,001481
7,23E-05
3,62E-05
7,23E-05
0,000145
0,000289
0,000145
0,000289
0,000145
0,000289
0,000579
0,001157
0,000178
0
0,000711
0
0,001422
0
0,000356
0
0,001422
0
0,002844
6,94E-05
3,47E-05
0,000139
0,000139
0,000556
6,94E-05
0,000278
0,000139
0,000556
0,000556
0,002222
0
0
0,00037
0
0,001481
0
0
0
0,001481
0
0,005926
0
3,62E-05
7,23E-05
0,000289
0,000579
0
0
0,000289
0,000579
0,002315
0,00463
188
ПРИЛОЖЕНИЕ 2
ТЕКСТ ПРОГРАММЫ ДЛЯ ВЫЧИСЛЕНИЯ ЗНАЧЕНИЙ ФУНКЦИИ
�⃗, �𝒅𝒅⃗, �⃗�
𝑭𝑭�𝒂𝒂
𝒔𝒔
import csv
import StringIO
sa = []
da = []
res = ''
with open('sa.csv', 'r') as csv_file:
for line in csv.reader(csv_file, delimiter=','):
sa.append(line)
with open('da.csv', 'r') as csv_file:
for line in csv.reader(csv_file, delimiter=','):
da.append(line)
for (s, sa_s) in enumerate(sa):
for (d, da_d) in enumerate(da):
for (a, sa_sa) in enumerate(sa_s):
res += `a+1` + ';' + `s+1` + ';' + `d+1` + ';' + `float(da_d[a]) *
float(sa_sa)` + '\n'
with open('res.csv', 'w') as csv_file:
csv_file.write(res)
print 'Done'
189
ПРИЛОЖЕНИЕ 3
АКТЫ ВНЕДРЕНИЯ РЕЗУЛЬТАТОВ ДИССЕРТАЦИОННОЙ РАБОТЫ
190