Оглавление

1. Актуальность защиты информации. Предпосылки кризиса систем защиты информации (СЗИ).

Современные требования к СЗИ..............................................................................................................5
2. Парадигма поддержки доверия (ГОСТ 15408). Цикл поддержки доверия. Приемка ОО. Мониторинг
ОО. Переоценка. Класс AMA - Поддержка доверия. План поддержки доверия. Отчет о категорировании
компонентов ОО. Свидетельство поддержки доверия. Анализ влияния на безопасность................6
3. Анализ проблемы защиты информации (ЗИ) на предприятии. Системно-концептуальный подход.
Условия реализации Концепции защиты информации в Российской Федерации. Надежность
информации. Характер сохраняемой тайны. Виды защищаемой информации. Цели ЗИ:
конфиденциальность, целостность и доступность.................................................................................7
4. Обзор оценочных уровней доверия (ОУД1 - ОУД7). Примерное соответствие классам «Оранжевой
книги», Европейских критериев и РД ГТК РФ....................................................................................10
5. Факторы, воздействующие на информацию (ГОСТ 51275-99). Внешние, внутренние, объективные и
субъективные...........................................................................................................................................12
6. Подходы и принципы обеспечения информационной безопасности. Системность, комплексность,
непрерывность защиты, гибкость управления и применения, открытость алгоритмов и механизмов
защиты, разумная достаточность, простота применения защитных мер и средств. Структуризация
методов обеспечения ИБ по уровням: носителей информации, средствам взаимодействия с носителем,
представления информации и содержания информации....................................................................13
7. Основные функции типовой системы защиты информации компьютерной системы (СЗИ КС).
Политика безопасности. Разграничение и управление доступом: дискреционная и мандатная модели.
Идентификация. Аутентификация. Авторизация. Аудит....................................................................14
8. Парольные системы. Методы компрометации паролей и защиты от нее. Количественная оценка
стойкости парольных систем.................................................................................................................15
9. Аудит безопасности компьютерных систем: регистрация потенциально опасных событий в
компьютерной системе, необходимость, требования, политика аудита............................................16
10. Дискреционное управление доступом (DAC). Дискреционная политика безопасности. Матрица
доступа: О-С-М, О-С-М-П, изолированная программная среда. Основные свойства: произвольность
управления доступом. Достоинства и недостатки. Области применения.........................................17
11. Мандатное управление доступом (MAC). Мандатная политика безопасности. Метки безопасности:
структура, назначение полей. Основные свойства: принудительность управления доступом, правила
NRU и NWD, основная теорема безопасности. Достоинства и недостатки в сравнении с дискреционной
моделью. Области применения..............................................................................................................18
12. Ролевое управление доступом (RBAС). Основные понятия. Статическое и динамическое разделение
обязанностей............................................................................................................................................19
13. Развитие стандартов по информационной безопасности (TCSEC, ITSEC, FCITS, CTCPEC, СС И РД
ГТК РФ). Задачи стандартов и основные понятия. Взаимодействие между производителями,
потребителями и экспертами по квалификации продуктов информационных технологий............20
14. Стандарты «Радужной серии». оранжевая книга (TCSEC). Цели создания. Таксономия требований
по безопасности компьютерных систем: политика безопасности, повторное использования объектов,
анализ скрытых каналов, прямое взаимодействие с ядром безопасности, подотчетность,
гарантированность, документация. Классификация трастовых компьютерных систем. Красная, розовая
и желтая книги.........................................................................................................................................21
15. Европейские (гармонизированные) критерии безопасности информационных технологий (ITSEC).
Функциональная мощность: классы-шаблоны F-C1, F-C2, F-B1. F-B2, F-B3, F-IN, F-AV, F-DI, F-DC, F-
DX. Адекватность (эффективность и корректность): таксономия критериев адекватности, уровни
адекватности (Е0 - Е6). Уровни безопасности......................................................................................23

1
16. Федеральные критерии безопасности информационных технологий (FCITS). Цели разработки.
Понятие профиля защиты (ПЗ). Таксономия функциональных требований, требований к технологии
разработки и процессу квалификационного анализа ИТ-продукта...................................................24
17. Канадские критерии безопасности компьютерных систем (CTCPEC). Таксономия функциональных
критериев и критериев адекватности реализации системы безопасности информации. Уровни
адекватности Т0-Т7.................................................................................................................................26
18. Концепция защиты от НСД к информации (РД ГТК РФ). Два направления - АС и СВТ. Модель
нарушителя: уровни возможностей.......................................................................................................27
 Классы защищенности автоматизированных систем.................................................................28
19. Классификация автоматизированных систем (АС) и требования по защите информации (РД ГТК
РФ). Система классификации защищенных АС. Основные подсистемы СЗИ (связь функций и классов
АС): управления доступом, регистрации и учета, криптоподсистема, сохранения целостности.
Организационные мероприятия по защите информации от НСД......................................................29
20. Показатели и классы защищенности средств вычислительной техники (СВТ) (РД ГТК РФ).
Классификация защищенных СВТ. Дискреционный и мандатный принцип контроля доступа. Очистка
памяти. Изоляция модулей. Маркировка документов. Защита ввода и вывода на отчуждаемый
физический носитель информации. Сопоставление пользователя с устройством. Идентификация и
аутентификация. Регистрация. Взаимодействие пользователя с КСЗ. Надежное восстановление.
Целостность КСЗ.....................................................................................................................................30
21. Межсетевые экраны (МЭ) (РД ГТК РФ). Классификация МЭ. Связь классов с показателями:
управление доступом, идентификация и аутентификация, регистрация, администрирование
(идентификация, аутентификация, регистрация), простота использования, целостность, восстановление,
тестирование, руководство администратора, тестовая и конструкторская (проектная) документация.
Связь классов с уровнями базовой эталонной модели сетей..............................................................33
22 Требования по безопасности информации, устанавливающие уровни доверияк средствам
технической защиты информации и средствам обеспечения безопасностиинформационных технологий
(Приказ ФСТЭК России № 76 от 2 июня 2020 г.,выписка).................................................................34
23. Испытания программных средств на наличие компьютерных вирусов (ГОСТ Р 51188-98). Виды
вирусов и методы испытаний.................................................................................................................36
24. Антивирусные средства защиты информации (РД ГТК РФ). Показатели защищенности и требования
по защите от вирусов. Виды вирусов. Классификация АВС. Характеристика основных подсистем:
контроля целостности; блокирования внедрения; обнаружения; удаления; обеспечения
гарантированности свойств; регистрации.............................................................................................37
25. Специальные защитные знаки (СЗЗ) (РД ГТК РФ). Классификация по возможности подделки,
идентифицируемости и стойкости защитных свойств. Применение на объектах различной категории.
...................................................................................................................................................................39
26. Методология оценки безопасности ИТ (ГОСТ 15408). Области применения стандарта «Общие
критерии».................................................................................................................................................40
27. Контекст оценки безопасности информационных технологий: разработка ОО, процесс оценки,
эксплуатация (ГОСТ 15408)...................................................................................................................41
28. Планирование обработки инцидентов и средства управления непрерывностью бизнеса.........43
29. Последовательность формирования требований и спецификаций (ГОСТ 15408): среда безопасности,
цели безопасности, требования безопасности ИТ и краткая спецификация ОО..............................44
30. Обеспечение непрерывности бизнеса. Основные стандарты по управлению непрерывностью
бизнеса. Стратегии управления непрерывностью бизнеса. Особенности внедрение в культуру
организации..............................................................................................................................................45
31. Представление требований безопасности: классы, семейства, компоненты, элементы (ГОСТ 15408).
Виды связей и зависимостей между компонентами, разрешенные операции с элементами..........47
32. Методологи (уровни) рассмотрения вопросов информационной безопасности (ИБ). Предприятие как
объект информатизации (категории), АС и СВТ. Состав типовой комплексной системы защиты
2
информации на предприятии (КСЗИ): СКУД, ОТ, ОПС, ПЭШ, КС. Уровни секретности (ГТ: С, СС, ОВ)
и конфиденциальности (К: служебная, коммерческая и общедоступная) информации. Политика
безопасности предприятия. (то же что и 50.)........................................................................................48
33. Источники требований безопасности (ГОСТ 15408). Виды оценок: ПЗ, ЗБ, ОО. Поддержка доверия.
...................................................................................................................................................................50
34. Управление инцидентами информационной безопасности. Цели и задачи. Структура системы
управления инцидентами. Первая оценка и вторая оценка, подтверждение инцидента и реагирование на
инциденты (немедленное, контролируемое, последующее реагирование). Стандартные антикризисные
действия и средства управления событиями........................................................................................51
35. Особенности профиля защиты (ПЗ) (ГОСТ 15408). Структура ПЗ: введение, описание ОО. среда
безопасности ОО, цели безопасности, требования безопасности ОО, замечания по применению,
обоснование.............................................................................................................................................52
36. Менеджмент риска информационной безопасности (ГОСТ 27005). Алгоритм менеджмента риска в
системе управления информационной безопасностью. Что такое оценка, обработка, принятие,
коммуникация, мониторинг и пересмотр рисков?...............................................................................55
37. Особенности задания по безопасности (ЗБ) (ГОСТ 15408). Структура ЗБ: введение, описание ОО,
среда безопасности ОО, цели безопасности, требования безопасности ИТ, краткая спецификация ОО,
утверждения о соответствии ПЗ, обоснование.....................................................................................56
38. Основные мероприятия по аудиту информационной безопасности организаций и систем.
Международные правовые аспекты, стандарты и руководства по основам аудита информационной
безопасности............................................................................................................................................59
39. Особенности функциональных требований безопасности ИТ-продуктов (ГОСТ 15408).
Представление функциональных требований. Структура класса. Структура семейства (ранжирование,
управление, аудит). Структура компонента (подчиненность по иерархии, зависимости - прямые,
косвенные, выбираемые, операции - итерация, назначение, выбор, уточнение). Функциональный
элемент.....................................................................................................................................................62
40. Процессный подход к обеспечению информационной безопасности (ГОСТ 27001). Особенности
перехода от линейной модели управления качеством процессов и систем к замкнутой циклической
модели менеджмента качества...............................................................................................................66
41. Парадигма функциональных требований (ГОСТ 15408). Виды объектов оценки и политик
безопасности. Функции безопасности: стойкость, область действия, интерфейс, типы ПФБ. ФБО
единого, локального и распределенного ОО. Виды пользователей. Роли. Ресурсы. Сущности: активные
и пассивные. Атрибуты безопасности. Данные ОО: пользователя и ФБО. Аутентификационные данные
и секреты..................................................................................................................................................71
42. Оценка информационной безопасности предприятия. Основные аспекты стандартизации систем и
процессов управления информационной безопасностью (ГОСТ 27001, СоbiT, NIST)...................74
43. Обзор классов функциональных требований (ГОСТ 15408)........................................................76
44. Угрозы безопасности информации. Критерии классификация угроз безопасности информации.
Основные методы реализации угроз информационной безопасности. Модель нарушителя..........78
45. Парадигма доверия в стандарте (ГОСТ 15408). Основные принципы стандарта. Значимость
уязвимостей. Причины возникновения уязвимостей. Подход к доверию в стандарте. Роль оценки.82
46. Национальная безопасность РФ, государственная информационная политика, виды безопасности,
проблемы информационных войн, концепция национальной безопасности. Что такое концепция
национальной безопасности?.................................................................................................................83
47. Представление требований доверия к безопасности (ГОСТ 15408). Структура класса, семейства,
компонента, элемента и оценочных уровней доверия.........................................................................84
48. Причины, виды и каналы утечки информации. ГОСТ Р 50922-96. Характеристика видов утечки
информации: разглашение информации, несанкционированный доступ, получение защищаемой
информации разведками. Характеристика каналов утечки информации: электромагнитный,
акустический (виброакустический), визуальный и информационный..............................................86
3
49. Обзор классов и семейств доверия (ГОСТ 15408).........................................................................87
50. Методологи (уровни) рассмотрения вопросов информационной безопасности (ИБ). Предприятие как
объект информатизации (категории), АС и СВТ. Состав типовой комплексной системы защиты
информации на предприятии (КСЗИ): СКУД, ОТ, ОПС, ПЭШ, КС. Уровни секретности (ГТ: С, СС, ОВ)
и конфиденциальности (К: служебная, коммерческая и общедоступная) информации. Политика
безопасности предприятия. (то же что и 32).........................................................................................90
51. Структура системы аттестации по требованиям безопасности информации.............................92
52. Порядок проведения аттестации объектов информатизации по требованиям безопасности
информации.............................................................................................................................................93
53. Виды лицензируемой деятельности в области защиты информации..........................................93
(Федеральный закон № 99-ФЗ от 04.05.2011г.)....................................................................................93
54. Классификация информационных систем персональных данных (ИСПДн) по уровням
защищенности. Состав и содержание мер по обеспечению безопасности персональных данных,
необходимых для обеспечения каждого из уровней защищенности персональных данных (Приказ
ФСТЭК №21 от 18 февраля 2013 г.)......................................................................................................94
54.1 Страшная таблица. Тыкните, чтобы свернуть и продолжить жить счастливой и беззаботной
жизнью. Открывать на свой страх и риск….................................................................................................95
55 Государственные информационные системы (ГИС). Классы защищенности ГИС. Состав мер защиты
информации и их базовые наборы для соответствующего класса защищенности информационной
системы (Приказ ФСТЭК №17 от 11 февраля 2013 г.)......................................................................103
56. Категорирование объектов критической информационной инфраструктуры (КИИ) (Федеральный
закон №187-ФЗ от 26 июля 2017 г., Постановление Правительства № 127 от 8 февраля 2018 г.).103

4
1. Актуальность защиты информации. Предпосылки кризиса систем защиты
информации (СЗИ). Современные требования к СЗИ.
Актуальность защиты информации обуславливается ростом количества
информационных систем, а также интенсивностью их внедрения на предприятия и в
государственные органы. Как следствие, количество преступлений, проведенных с
помощью программных средств, таких как хищение, изменение и уничтожение
важной информаций, неуклонно растет. Отсюда возникает необходимость в защите
информации.
Основные предпосылки кризиса систем защиты информации (СЗИ):
1. Эксплуатация современных компьютеров стала в разы легче, что негативно сказалось
на компьютерной квалификации пользователей, что в свою очередь облегчает работу
злоумышленникам. Также необходимо отметить повсеместную информатизацию и
распространение глобальной сети Internet, из-за чего злоумышленники могут
работать по всему миру.
2. Распространение программного обеспечения, которое не удовлетворяет даже
минимальным требованиям безопасности (наличие изъянов в организации средств
безопасности, а также недокументированных возможностей)
3. Современные приложения не просто обрабатывают данные, а интерпретируют
интегрированные в них инструкции специального языка программирования, по сути
являясь отдельной машиной. Это увеличивает возможности злоумышленников по
созданию средств внедрения в чужие системы и затрудняет защиту, также требуется
контроль на уровне виртуальной машины или интерпретатора.
4. Разрыв между теорией и практикой. Как следствие, существующие системы защиты
информации основаны на уже проведенных атаках, что предопределяет их
поведение.
5. Необходимость в обоснований требований безопасности, создание нормативной базы,
устанавливающей обязательный уровень безопасности.
Современные требования к СЗИ:
1. Управление доступом должно учитывать современные формы представления
информации, а системы защиты должны обеспечивать безопасность на уровне
информационных ресурсов, а не отдельных документов или сообщений;
2. Идентификация и аутентификация на глобальном уровне, в связи с развитием сетей и
Internet;
3. От защиты требуются новые функции, а именно механизмы, обеспечивающие
безопасность системы в условиях возможного появления в виде программ,
осуществляющих деструктивные действия, компьютерных вирусов и
автоматизированных средств взлома;
4. Системы безопасности должны по мере возможности сохранять совместимость с
популярными в настоящее время системами.

5
2. Парадигма поддержки доверия (ГОСТ 15408). Цикл поддержки доверия. Приемка
ОО. Мониторинг ОО. Переоценка. Класс AMA - Поддержка доверия. План
поддержки доверия. Отчет о категорировании компонентов ОО. Свидетельство
поддержки доверия. Анализ влияния на безопасность.
Парадигма поддержки доверия – понятие, которое применяется после оценки и
сертификации объекта оценки. Она применяется для получения уверенности в том,
что объект оценки по прежнему будет отвечать своему заданию по безопасности
после изменений в объекте оценки или его среде. К этим изменениям относятся:
обнаружение новых угроз, уязвимостей, изменения в требованиях пользователя,
исправление ошибок, обнаруженных в сертифицированном объекте оценки,
обновления функциональных возможностей объекта оценки.
Цикл поддержки доверия состоит из нескольких фаз:
1) Приёмка – фаза, когда планы и процедуры разработчика по поддержке доверия
устанавливаются, а затем их правильность подтверждается оценщиком.
2) Мониторинг – фаза, когда разработчик предоставляет свидетельство о том, что
доверие к объекту оценки поддерживается в соответствии с установленными
планами и процедурами, затем это свидетельство независимо проверяется
оценщиком.
3) Переоценка – завершающая фаза, когда обновленная версия ОО представляется на
рассмотрение, для переоценки, основанной на изменениях, которым подверглась
сертифицированная версия ОО.

Одним из способов вынесения заключения о поддержке доверие является

переоценка ОО. Термин «переоценка» здесь означает оценку новой версии ОО,
учитывающую все относящиеся к безопасности изменения, произведенные в
сертифицированной ранее версии ОО, при которой повторно используют результаты
предыдущей оценки, оставшиеся актуальными. Однако во многих случаях вряд ли будет
практично выполнять переоценку каждой новой версии ОО для дальнейшей поддержки
доверия. Поэтому главная цель класса АМА — определить совокупность требований,
которые могут применяться, чтобы убедиться в поддержке установленного доверия к
ОО, не требуя во всех случаях формальной переоценки новых версий ОО.
План поддержки доверия (ПД) определяет основную линию поведения при
поддержке доверия в зависимости от результатов оценки и проведения категорирования
компонентов ОО, процедуры, выполняемые разработчиком по мере изменений в ОО или
его среде для обеспечения поддержки доверия, которое было установлено в
сертифицированном ОО, распространяется на один цикл поддержки доверия, пределы
изменений, которые могут быть сделаны в ОО без необходимости переоценки.
Конкретный применяемый подход зависим: от схемы, но следующие типы изменений,
вероятно, обязательно приведут к переоценке, находясь тем не менее за пределами плана
ПД:
а) значительное изменение задания по безопасности (т. е. значительные изменения
среды безопасности, целей безопасности, функциональных требований безопасности или
любое повышение требований доверия);
б) значительное изменение внешних интерфейсов ФБО, отнесенных к категории
обеспечивающих осуществление ПВО;

6
 в) значительное изменение подсистем ФБО, отнесенных к категории
обеспечивающих осуществление ПВО (для случаев, когда требования доверия включают
в себя ADV H LD. 1 или иерархичные компоненты)
Отчет о категорировании компонентов ОО распространяется на все представления
ФБО на поддерживаемом уровне доверия. Отчет о категорировании компонентов ОО
также идентифицирует:
а) любые аппаратные, программно-аппаратные и программные компоненты, которые
являются внешними по отношению к ОО (например, аппаратные или программные
платформы) и удовлетворяют требованиям безопасности ИТ, определенным в ЗБ;
б) любые инструментальные средства разработки, модификация которых будет
влиять на требуемое доверие к тому, что ОО удовлетворяет своему ЗБ.
Свидетельство поддержки доверия
Необходимо убедиться в том, что доверие к ОО поддерживается разработчиком в
соответствии с планом ПД. Это достигается путем подготовки свидетельства, которое
демонстрирует поддержку доверия к ОО и независимо проверяется оценщиком. Эта
проверка, называемая «аудит поддержки доверия» (аудит ПД), будет, как правило,
применяться периодически в фазе мониторинга цикла поддержки доверия к ОО.
Назначение анализа влияния на безопасность состоит в том, чтобы убедиться в
поддержке доверия к ОО посредством проводимого разработчиком анализа влияния на
безопасность всех изменений, воздействующих на ОО после его сертификации. Эти
требования могут применяться в фазе мониторинга или переоценки. Анализ влияния на
безопасность, проводимый разработчиком, основывается на отчете о категорировании
компонентов ОО: изменения в осуществляющих ИБО компонентах ОО могут повлиять
на доверие к тому, что ОО продолжает отвечать своему ЗБ после изменений. Поэтому
все такие изменения требуют анализа их влияния на безопасность, чтобы показать, что
они не нарушают доверия к ОО.

3. Анализ проблемы защиты информации (ЗИ) на предприятии. Системно-

концептуальный подход. Условия реализации Концепции защиты информации в
Российской Федерации. Надежность информации. Характер сохраняемой тайны.
Виды защищаемой информации. Цели ЗИ: конфиденциальность, целостность и
доступность.
Представление информации в закодированном виде недостаточно для защиты
информации. Поэтому специалисты по ИБ пришли к выводу, что защита
информации должна быть целой системой непрерывных мероприятий по защите
информации. Также системность должна быть способна решить все проблемы
отдельно взятой АС или несколько АС, расположенных на некой территории.
Концептуальность подхода предполагает разработку единой концепции как полной
совокупности научно обоснованных взглядов и решений для целенаправленной
организации защиты информации.
Условия реализации Концепции защиты информации в Российской Федерации
• сохранение и укрепление российской государственности и политической стабильности
в обществе;

7
• сохранение и развитие демократических институтов общества, обеспечение прав и
свобод граждан, укрепление законности и правопорядка;
• обеспечение достойной роли России в мировом сообществе;
• обеспечение территориальной целостности страны;
• обеспечение прогрессивного социально-экономического развития России;
• сохранение национальных культурных ценностей и традиций.

Надежность информации – интегрированный показатель, который характеризует

качество информации со следующих точек зрения:
1) физическая целостность
2) доверие к информации
3) безопасность информации
4) уверенность в том, что переданные пользователем данные не будет
распространяться
Характер сохраняемой тайны
Тайна бывает:

 государственной (ГТ),
 коммерческой
 служебной.
К ГТ относят сведения в военной области, в области науки, экономики, внешней
политики, разведданные.
секретно: к секретным сведениям следует относить все иные сведения из числа
сведений, составляющих государственную тайну. Ущербом безопасности
Российской Федерации в этом случае считается ущерб, нанесённый интересам
предприятия, учреждения или организации в военной, внешнеполитической,
экономической, научно-технической и другим сферам.
совершенно секретные: к совершенно секретным сведениям следует относить
сведения в области военной экономической, научно-технической,
распространение которых может нанести ущерб интересам министерства или
отрасли экономики Российской Федерации в одной или нескольких из
перечисленных областей.
особой важности: к сведениям особой важности следует относить сведения в,
распространение которых может нанести ущерб интересам Российской Федерации
в одной или нескольких из перечисленных областей.
Коммерческая тайна - конфиденциальная информация, позволяющая ее
обладателю при существующих или возможных обстоятельствах увеличить
доходы, избежать неоправданных расходов, сохранить положение на рынке
товаров, работ, услуг или получить иную коммерческую выгоду.
Служебная тайна — защищаемая по закону конфиденциальная информация,
ставшая известной в государственных органах и органах местного
самоуправления только на законных основаниях и в силу исполнения их
представителями служебных обязанностей, а также служебная информация о
8
 деятельности государственных органов, доступ к которой ограничен федеральным
законом или в силу служебной необходимости.
Виды защищаемой информации
Информация бывает двух видов – открытая и с ограниченным доступом.
Информация с ограниченным доступом делится на гостайну и конфиденциальную
информацию. К конфиденциальной относятся такие виды информации, как
коммерческая тайна, служебная тайна, персональные данные и другие.
Конфиденциальность, целостность, доступность
Конфиденциальность – доступ к информации могут получить только легальные
пользователи.
Целостность – защищаемая информация может быть изменена только законными и
имеющими соответствующие полномочия пользователями, а также информация
внутренне непротиворечива и отражает реальное положение вещей.
Доступность – гарантирующая беспрепятственный доступ к защищаемой информации
для законных пользователей.

9
4. Обзор оценочных уровней доверия (ОУД1 - ОУД7). Примерное соответствие
классам «Оранжевой книги», Европейских критериев и РД ГТК РФ.
Оценочный уровень доверия – это уровень доверия к реализации требований по защите.
В Общих критериях определено 7 оценочных уровней доверия, упорядоченных по
возрастанию по шкале от 1 до 7. Эта шкала позволяет нам оценить соотношение
уровня доверия к необходимым для этого уровня затратам.
ОУД1 Предусматривает: функциональное тестирование.
Применим: когда требуется некоторая уверенность, что объект оценки работает
безукоризненно, а угрозы безопасности не считаются серьезными.
Достигается: посредством анализа функциональной спецификации, спецификации
интересов, эксплуатационной документации в сочетании с независимым
тестированием.
ОУД2 Предусматривает: структурное тестирование и доступ к части проектной
документации и результатам тестирования разработчиком.
Применим: когда разработчикам или пользователям требуется независимо получаемый
умеренный уровень доверия при отсутствии доступа к полной документации по
разработке.
Достигается: в дополнение к ОУД1 предписывается анализ проекта верхнего уровня.
ОУД3 Предусматривает: систематическое тестирование и проверку.
Применим: когда необходимо достичь максимально возможного доверия при
использовании обычных методов разработки.
Достигается: в дополнении к ОУД2 добавлено требование, которое предписывает
разработчику создавать акт об испытаниях с учетом особенностей проекта верхнего
уровня.
ОУД4 Предусматривает: систематическое проектирование, тестирование и просмотр.
Применим: когда необходимо достичь доверия, максимально возможного при
следовании общепринятой практике коммерческой разработки.
Достигается: ОУД3 + анализ функциональной спецификации, полной спецификации
интерфейсов, эксплуатационной документации, независимого анализа уязвимостей и
т.д. Это самый экономически целесообразный продукт для существующих типов
продуктов.
ОУД5 Предусматривает: полуформальное проектирование и тестирование.
Применим: когда нужен высокий уровень доверия и строгий подход к разработке, не
влекущий излишних затрат.
Достигается: ОУД4 + формальная модель политики безопасности ОО и полуформальное
представление функциональной спецификации и проекта верхнего уровня,
полуформальная демонстрация соответствия меду ними, а также модульная
структура проекта ОО.
ОУД6 Предусматривает: полуформальную верификацию проекта.
Применим: когда необходимо достичь высокое доверие путем применения специальных
методов проектирования в строго контролируемой среде разработки при
производстве высококачественных изделий ИТ и при защите ценных активов от
значительных рисков.
Достигается: структурированное представление реализации, полуформальное
представление проекта нижнего уровня, иерархическая структура проекта ОО и т.д.
ОУД7 Предусматривает: формальную верификацию проекта.

10
Применим: к разработке изделий ИТ для использования в ситуациях чрезвычайно
высокого риска или там, где высокая ценность активов оправдывает повышенные
затраты.
Достигается: формальное представление функциональной спецификации и проекта
верхнего уровня и формальная демонстрация соответствия между ними, модульная,
иерархическая и простая структура проекта ОО, добавление представления
реализации как основы акта об испытаниях и т.д.
Примерное соответствие классам «Оранжевой книги», Европейских критериев и РД ГТК
РФ
Вид информации(по вертикали)
Классы защищенности(по горизонтали)

Читаем таблицу кароч, АС, СВТ, МЭ, СЗЗ и ПО – это все руководящие документы
гостехкомиссии (РД ГТК) РФ, TCSEC – Оранжевая книга, ITSEC – Европейские
критерии, CC – Common Criteria или по нашему Общие критерии (ГОСТ 15408)

11
5. Факторы, воздействующие на информацию (ГОСТ 51275-99). Внешние,
внутренние, объективные и субъективные.
Основные положения (то, что нужно написать в первую очередь)

 Выявление и учет факторов, влияющих на ИС – это важные мероприятия

для планирования защиты информации
 Полнота и достоверность выявленных факторов, воздействующих на
информации достигаются путем рассмотрения всего множества возможных
факторов.
 Выявление факторов, воздействующих на защищаемую информацию,
должно осуществляться с учетом следующих требований:
 достаточности проверки
 гибкости классификации

 Классификация факторов, воздействующих на безопасность защищаемой

информации

Факторы, воздействующие или могущие воздействовать на безопасность

защищаемой информации и подлежащие учету при организации защиты информации:

1) по признаку отношения к природе возникновения подразделяют на:

 объективные;
 субъективные.

2) По отношению к ОИ факторы, воздействующие на безопасность защищаемой

информации, подразделяют на:
 внутренние;
 внешние.

3) В соответствии с признаками классификации подразделяют на:

 подклассы;
 группы;
 подгруппы;
 виды;
 подвиды.
 Объективные и субъективные факторы, воздействующие на безопасность
защищаемой информации
Внутренние объективные: к ним могут относиться различные явления, возникшие
внутри ИС, например: паразитные излучения, сопутствующие передачи информации
Внутренние субъективные: когда кто-то из внутреннего персонала ИС
непреднамеренно или специально нарушил конфиденциальность информации.
Например, когда какой-то д*****б обменивается секреткой по открытым каналам
связи.
Внешние объективные: когда различные природные либо техногенные факторы
нарушают связь.

12
Внешние субъективные: когда враги пытаются снять связь различными методами
(прослушка, врезка в провода и т.д)

6. Подходы и принципы обеспечения информационной безопасности. Системность,

комплексность, непрерывность защиты, гибкость управления и применения,
открытость алгоритмов и механизмов защиты, разумная достаточность, простота
применения защитных мер и средств. Структуризация методов обеспечения ИБ по
уровням: носителей информации, средствам взаимодействия с носителем,
представления информации и содержания информации.
- Принцип системности предполагает необходимость учета всех слабых и
уязвимых мест АСОИ, и других факторов.
- Принцип комплексности предполагает согласование работы разнородных
систем защиты информации (СЗИ).
- Принцип непрерывности защиты учитывает то, что защита информации не есть
разовое мероприятие, а непрерывный целенаправленный процесс.
- Принцип гибкости управления и применения системы защиты предполагает
возможность варьировать уровень защищенности автоматизированной системы
(АС).
- Принцип открытости означает, что знание алгоритма защиты не должно дать
возможность злоумышленнику для взлома.
- Принцип разумной достаточности говорит о том, что достаточно минимальной
приемлемой защиты. Абсолютно защищённой системы все равно не бывает.
- Принцип простоты применения защитных мер и средств говорит о том, что
механизмы защиты должны быть интуитивно понятны и просты в использовании.

Данные уровни были введены исходя из того, что:

1) Во-первых, информация для удобства манипулирования чаще всего фиксируется

на некотором материальном носителе, которым может быть бумага, дискета или
что-нибудь в этом роде.

2) Во-вторых, если способ представления информации таков, что она не может быть
непосредственно воспринята человеком, возникает необходимость в
преобразователях информации в доступный для человека способ представления
(например, для чтения информации с дискеты необходим компьютер,
оборудованный дисководом соответствующего типа).

3) В-третьих, как уже было отмечено, информация может быть охарактеризована

способом своего представления или тем, что еще называется языком в обиходном
смысле (язык жестов, язык символов и т.п., все это способы представления
информации).

4) В-четвертых, человеку должен быть доступен смысл представленной информации,

ее семантика.

13
7. Основные функции типовой системы защиты информации компьютерной
системы (СЗИ КС). Политика безопасности. Разграничение и управление доступом:
дискреционная и мандатная модели. Идентификация. Аутентификация.
Авторизация. Аудит.

Политика безопасности (Security Policy). Совокупность норм и правил,

обеспечивающих эффективную защиту системы обработки информации от заданного
множества угроз безопасности.
Дискреционное управление доступом (Discretionary Access Control) — управление
доступом, осуществляемое на основании заданного администратором множества
разрешенных отношений доступа.
Мандатное управление доступом (Mandatory Access Control) — управление
доступом, основанное на совокупности правил предоставления доступа, определенных
на множестве атрибутов безопасности субъектов и объектов.

 Идентификация. Аутентификация. Авторизация.

Идентификация — это процесс опознания, определения объекта по его свойствам.

(мы указываем свой логин для входа)

Аутентификация — это процесс подтверждения подлинности объекта (мы

указываем свой пароль).

Авторизация — это процесс проверки прав на доступ и предоставление доступа —

после того как объект/пользователь/компьютер/сервис был идентифицирован или
аутентифицирован, он может запросить доступ к каким-либо ресурсам.( мы пытаемся
открыть файл)

Чаще всего сегодня используется двухфакторная аутентификация, где в качестве

первого фактора выступает обычный многоразовый пароль.

А вот второй фактор может быть разным, в зависимости от того, какие способы
аутентификации применяются в данном случае:
 одноразовый пароль или PIN-код
 магнитные карты, смарт-карты, сертификаты с цифровой подписью
 биометрические параметры: голос, сетчатка глаза, отпечатки пальцев

Аудит (и как синоним аудиторская проверка)* — процедура независимой проверки и

оценки отчётности, данных учёта и деятельности организации, а также системы,
процесса, проекта или продукта.

14
8. Парольные системы. Методы компрометации паролей и защиты от нее.
Количественная оценка стойкости парольных систем.
Под парольной системой будем понимать программно-аппаратный комплекс,
реализующий системы идентификации и аутентификации пользователей.

Основными компонентами парольной системы являются:

• интерфейс пользователя;
• интерфейс администратора;
• модуль сопряжения с другими подсистемами безопасности;
• база данных учетных записей.
Наиболее распространенные методы аутентификации основаны на применении
многоразовых или одноразовых паролей. Эти методы включают следующие
разновидности способов аутентификации:
• по хранимой копии пароля или его свертке (хэш-коду);
• по некоторому проверочному значению;
• без непосредственной передачи информации о пароле проверяющей стороне;
• с использованием пароля для получения криптографического ключа.
Таблица 1 – Параметры количественной оценки стойкости пароля.

15
9. Аудит безопасности компьютерных систем: регистрация потенциально опасных
событий в компьютерной системе, необходимость, требования, политика аудита.
Процедура аудита применительно к ОС заключается в регистрации в специальном
журнале, называемом журналом аудита или журналом безопасности, событий, которые
могут представлять опасность для ОС. Пользователи системы, обладающие правом
чтения журнала аудита, называются аудиторами.

Необходимость включения в защищенную ОС функций аудита обусловлена

следующими обстоятельствами:
- Обнаружение попыток вторжения поможет при планировании безопасности в будущем
- Администратору ОС нужно знать о функционировании ОС в недавнем прошлом, для
обеспечения такой информации и нужен аудит
- ОС не сможет сама отличить попытку взлома от непреднамеренных действий законных
пользователей. Поэтому эта задача возлагается на аудиторов.
К числу событий, которые могут представлять опасность для ОС, обычно относят
следующие:
• вход или выход из системы;
• операции с файлами (открыть, закрыть, переименовать, удалить);
• обращение к удаленной системе;
• смену привилегий или иных атрибутов безопасности (режима доступа, уровня
благонадежности пользователя и т. п.).

Если фиксировать в журнале аудита все события, объем регистрационной информации

будет расти слишком быстро, что затруднит ее эффективный анализ. Необходимо
предусмотреть выборочное протоколирование как в отношении пользователей, так и в
отношении событий.
Требования к аудиту. Подсистема аудита ОС должна удовлетворять следующим
требованиям.
1. Добавлять записи в журнал аудита может только ОС, чтобы пользователи не могли
компрометировать друг друга.
2. Редактировать или удалять отдельные записи в журнале аудита не может ни один
субъект доступа, в том числе и сама ОС.
3. Просматривать журнал аудита могут только пользователи, обладающие
соответствующей привилегией.
4. Очищать журнал аудита могут только пользователи-аудиторы. После очистки журнала
в него автоматически вносится запись о том, что журнал аудита был очищен, с указанием
времени очистки журнала и имени пользователя, очистившего журнал. ОС должна
поддерживать возможность сохранения журнала аудита перед очисткой в другом файле.
5. При переполнении журнала аудита ОС аварийно завершает работу («зависает»). После
перезагрузки работать с системой могут только аудиторы. ОС переходит к обычному
режиму работы только после очистки журнала аудита.
Политика аудита — это совокупность правил, определяющих, какие события должны
регистрироваться в журнале аудита. Для обеспечения надежной защиты ОС в журнале
аудита должны обязательно регистрироваться следующие события:
• попытки входа/выхода пользователей из системы;
• попытки изменения списка пользователей;
• попытки изменения политики безопасности, в том числе и политики аудита.

16
10. Дискреционное управление доступом (DAC). Дискреционная политика
безопасности. Матрица доступа: О-С-М, О-С-М-П, изолированная программная
среда. Основные свойства: произвольность управления доступом. Достоинства и
недостатки. Области применения.
Произвольное управление доступом — это метод ограничения доступа к объектам,
основанный на учете личности субъекта или группы, в которую субъект входит.
Произвольность управления состоит в том, что некоторое лицо (обычно владелец
объекта) может по своему усмотрению давать другим субъектам или отбирать у них
права доступа к объекту.
Текущее состояние прав доступа описывается матрицей, доступа в строках которой
перечислены субъекты, а в столбцах — объекты.
Реализует управление доступом – монитор ссылок.
Дискреционное разграничение доступа к объектам (Discretionary Access Control — DAC)
характеризуется следующим набором свойств:
• все субъекты и объекты компьютерной системы должны быть однозначно
идентифицированы;
• для любого объекта компьютерной системы определен пользователь-владелец;
• владелец объекта обладает правом определения прав доступа к объекту со стороны
любых субъектов компьютерной системы;
• в компьютерной системе существует привилегированный пользователь, обладающий
правом полного доступа к любому объекту (или правом становиться владельцем любого
объекта).
Последнее свойство определяет невозможность существования в компьютерной системе
потенциально недоступных объектов, владелец которых отсутствует.

К достоинствам дискреционного разграничения доступа относятся относительно простая

реализация (проверка прав доступа субъекта к объекту производится в момент открытия
этого объекта в процессе субъекта) и хорошая изученность (в наиболее
распространенных операционных системах универсального назначения типа Microsoft
Windows и Unix применяется именно эта модель разграничения доступа).
Недостатки дискреционного разграничения доступа. Прежде всего, к ним относится
статичность разграничения доступа — права доступа к уже открытому субъектом
объекту в дальнейшем не изменяются независимо от изменения состояния компьютерной
системы.
При использовании дискреционного разграничения доступа не существует возможности
проверки, не приведет ли разрешение доступа к объекту для некоторого субъекта к
нарушению безопасности информации в компьютерной системе.
Изолированная программная среда – это расширение DAC. При изолированной
программной среде также учитываются процессы, к которым имеет доступ объект.

17
11. Мандатное управление доступом (MAC). Мандатная политика безопасности.
Метки безопасности: структура, назначение полей. Основные свойства:
принудительность управления доступом, правила NRU и NWD, основная теорема
безопасности. Достоинства и недостатки в сравнении с дискреционной моделью.
Области применения.
Мандатное разграничение доступа (Mandatory Access Control — MAC). К основным
характеристикам этой модели относится следующее:
• все субъекты и объекты компьютерной системы должны быть однозначно
идентифицированы;
• имеется линейно упорядоченный набор меток конфиденциальности и соответствующих
им уровней (степеней) допуска (нулевая метка или степень соответствуют
общедоступному объекту и степени допуска к работе только с общедоступными
объектами);
• каждому объекту компьютерной системы присвоена метка конфиденциальности;
• каждому субъекту компьютерной системы присваивается степень допуска;
• в процессе своего существования каждый субъект имеет свой уровень
конфиденциальности, равный максимуму из меток конфиденциальности объектов, к
которым данный субъект получил доступ;
• в компьютерной системе существует привилегированный пользователь, имеющий
полномочия на удаление любого объекта системы;
• понизить метку конфиденциальности объекта может только субъект, имеющий доступ
к данному объекту и обладающий специальной привилегией;
• право на чтение информации из объекта получает только тот субъект, чья степень
допуска не меньше метки конфиденциальности данного объекта (правило «не читать
выше»);
• право на запись информации в объект получает только тот субъект, чей уровень
конфиденциальности не больше метки конфиденциальности данного объекта (правило
«не записывать ниже»).
Основной целью мандатного разграничения доступа к объектам является
 предотвращение утечки информации из объектов с высокой меткой
конфиденциальности в объекты с низкой меткой конфиденциальности
(противодействие созданию каналов передачи информации «сверху вниз»).
Для мандатного разграничения доступа к объектам компьютерной системы формально
доказано следующее важное утверждение: если начальное состояние компьютерной
системы безопасно и все переходы из одного состояния системы в другое не нарушают
правил разграничения доступа, то любое последующее состояние компьютерной
системы также безопасно.
К другим достоинствам мандатного разграничения доступа относятся:

18
• более высокая надежность работы самой компьютерной системы, так как при
разграничении доступа к объектам контролируется и состояние самой системы, а не
только соблюдение установленных правил;
• большая простота определения правил разграничения доступа по сравнению с
дискреционным разграничением (эти правила более ясны для разработчиков и
пользователей компьютерной системы).
Отметим недостатки мандатного разграничения доступа к объектам компьютерной
системы:
• сложность программной реализации, что увеличивает вероятность внесения ошибок и
появления каналов утечки конфиденциальной информации;
• снижение эффективности работы компьютерной системы, так как проверка прав
доступа субъекта к объекту выполняется не только при открытии объекта в процессе
субъекта, но и перед выполнением любой операции чтения из объекта или записи в
объект;
• создание дополнительных неудобств работе пользователей компьютерной системы,
связанных с невозможностью изменения информации в неконфиденциальном объекте,
если тот же самый процесс использует информацию из конфиденциального объекта (его
уровень конфиденциальности больше нуля).

12. Ролевое управление доступом (RBAС). Основные понятия. Статическое и

динамическое разделение обязанностей.
Управление доступом на основе ролей (англ. Role Based Access Control, RBAC) —
развитие политики избирательного управления доступом, при этом права доступа
субъектов системы на объекты группируются с учётом специфики их применения,
образуя роли.
Формирование ролей призвано определить чёткие и понятные
для пользователей компьютерной системы правила разграничения доступа. Ролевое
разграничение доступа позволяет реализовать гибкие, изменяющиеся динамически в
процессе функционирования компьютерной системы правила разграничения доступа.
Такое разграничение доступа является составляющей многих современных
компьютерных систем. Как правило, данный подход применяется в системах
защиты СУБД, а отдельные элементы реализуются в сетевых операционных системах.
Ролевой подход часто используется в системах, для пользователей которых чётко
определён круг их должностных полномочий и обязанностей.
Технология управления доступом на основе ролей достаточно гибка и сильна,
чтобы смоделировать как избирательное управление доступом (DAC)[4], так
и мандатное управление доступом(MAC)
При статическом разделении накладывается ограничение таким образом, что
исполнение какой либо определённой роли запрещает приписывание ему множества
других ролей.
При динамическом разделении пользователь не может исполнять две роли
одновременно. То есть в определённый момент времени пользователь исполняет одну
роль и, пока он не закончит её исполнять, он не перейдёт к исполнению другой.

19
13. Развитие стандартов по информационной безопасности (TCSEC, ITSEC, FCITS,
CTCPEC, СС И РД ГТК РФ). Задачи стандартов и основные понятия.
Взаимодействие между производителями, потребителями и экспертами по
квалификации продуктов информационных технологий.
Стандарт оценки безопасности компьютерных систем (TCSEC) "Оранжевая книга".
«Критерии безопасности компьютерных систем» («Trusted Computer System Evaluation
Criteria») состоит из рейтингов «уровней доверия», где более высокие уровни строятся на
более низких, за счет последовательного ужесточения требований к безопасности и
проверке.
Стандарт безопасности информационных технологий ITSEC (Information Technology
Security Evaluation Criteria) оценивает два основных атрибута защитных механизмов
систем: функциональность и гарантии. При оценке функциональности защитных
механизмов системы, проводится проверка и оценка предоставляемых субъектам
сервисов. Гарантии, с другой стороны, это степень доверия защитным механизмам, их
эффективность и возможность работы согласованным образом.
«Федеральные критерии безопасности информационных технологий» (Federal Criteria
for Information Technology Security) разрабатывались как одна из составляющих
«Американского федерального стандарта по обработке информации», призванного
заменить «Оранжевую книгу». Был создан для разработки универсального пакета
требований безопасности и должен согласовать между собой требования и стандарты,
принятые в различных странах.
«Канадские критерии» (Canadian Trusted Computer Product Evaluation Criteria;
CTCPEC) разрабатывались для использования в качестве национального стандарта
безопасности компьютерных систем. Ориентированной в основном на разработку и
сертификацию многопользовательских операционных систем и требующей
определенной интерпретации для других применений, «Канадские критерии» были
изначально нацелены на широкий диапазон компьютерных систем.
Common Criteria (CC), является международным стандартом оценки степени
защищенности продуктов. СС гибче уровней доверия TCSEC и по структуре ближе
ITSEC, чем TCSEC. СС включает две концепции: профиля защиты (Protection Profile, PP)
— требования к безопасности разбиваются на группы, которые легко определять и
сравнивать; объекта защиты (Security Target, ST) — предоставляет набор требований к
защите, которые могут быть подготовлены с помощью PP.
Руководящие документы Гостехкомиссии Российской Федерации. Основным
критерием классификации служит протокольный уровень, на котором осуществляется
фильтрация информации. Чем выше уровень, тем больше информации на нем доступно
и, следовательно, тем более тонкую и надежную фильтрацию можно организовать.

20
14. Стандарты «Радужной серии». оранжевая книга (TCSEC). Цели создания.
Таксономия требований по безопасности компьютерных систем: политика
безопасности, повторное использования объектов, анализ скрытых каналов, прямое
взаимодействие с ядром безопасности, подотчетность, гарантированность,
документация. Классификация трастовых компьютерных систем. Красная, розовая
и желтая книги.
Оранжевая книга
Цель разработки
«Критерии безопасности компьютерных систем» были разработаны Министерством обороны США в
1983 году с целью определения требований безопасности, предъявляемых к аппаратному,
программному и специальному обеспечению компьютерных систем и выработки соответствующей
методологии анализа политики безопасности, реализуемой в компьютерных системах военного
назначения.
Согласно «Оранжевой книге», безопасная компьютерная система — это система, поддерживающая
управление доступом к обрабатываемой в ней информации такое, что только соответствующим образом
уполномоченные пользователи или процессы, действующие от их имени, получают возможность
читать, писать, создавать и удалять информацию.
Таксономия требований и критериев «Оранжевой книги»
В «Оранжевой книге» предложены три категории требований безопасности — политика безопасности,
аудит и корректность, в рамках которых сформулированы шесть базовых требований безопасности.
Политика безопасности
Требование 1. Политика безопасности.
Система должна поддерживать точно определенную политику безопасности. Возможность
осуществления субъектами доступа к объектам должна определяться на основании их идентификации и
набора правил управления доступом.
Требование 2. Метки
С объектами должны быть ассоциированы метки безопасности, используемые в качестве атрибутов
контроля доступа. Для реализации нормативного управления доступом система должна обеспечивать
возможность присваивать каждому объекту метку или набор атрибутов, определяющих степень
конфиденциальности объекта и/или режимы доступа к этому объекту.
Аудит (подотченость)
Требование 3. Идентификации и аутентификация
Все субъекты должны иметь уникальные идентификаторы. Контроль доступа должен осуществляться
на основании результатов идентификации субъекта и объекта доступа, подтверждения подлинности их
идентификаторов (аутентификации) и правил разграничения доступа. Данные, используемые для
идентификации и аутентификации должны быть защищены от несанкционированного доступа,
модификации и уничтожения.
Требование 4. Регистрация и учет
Для определения степени ответственности пользователей за действия в системе, все происходящее в
ней события, имеющие значение с точки зрения безопасности, должны отслеживаться и
регистрироваться в защищенном протоколе.
Корректность
Требование 5. Контроль корректности функционирования средств зашиты
Все средства зашиты должны находиться под контролем средств, проверяющих корректность их
функционирования. Основной принцип контроля корректности состоит в том, что средства контроля
должны быть полностью независимы от средств защиты.
Требование 6. Непрерывность зашиты
Все средства защиты должны быть защищены от несанкционированного вмешательства и/или
отключения, причем эта защита должна быть постоянной и непрерывной в любом режиме
функционирования системы защиты и компьютерной системы в целом.
Гарантии. ТСВ обеспечивает ее собственную работу и защиту от внешнего воздействия. Тестирование
ТСВ должно выполняться согласно документации для обеспечения гарантии того, что нет явных путей
обхода системы защиты неавторизованным пользователем или иного расстройства системы защиты.
21
Документация должна включать:
 описание реализованных механизмов защиты, их взаимодействия и руководство пользователя по
их использованию;
 руководство для администратора системы на гарантирование системы защиты;
 документацию по тестам, включающую описание того, как механизмы безопасности должны
тестироваться и как интерпретировать результаты тестов;
 документацию по проекту, описывающую философию системы защиты и того, как эта
философия реализована.

Анализ скрытых каналов

Должно быть проведено исследование наличия в компьютерной системе скрытых каналов. Каждый
обнаруженный в аппаратных, программных или специальных средствах системы скрытый канал утечки
информации должен быть документирован.
Максимальная пропускная способность каждого скрытого канала должна быть указана в документации.

Повторное использование объектов

Контроль за повторным использованием объектов позволяет обеспечить безопасное использование
разделяемых объектов, одновременно или последовательно доступных нескольким процессам.
Контроль должен предотвращать сохранение в разделяемых объектах остаточной информации после
завершения их использования одним процессом и перед предоставлением доступа к ним другому
процессу.

Ядро безопасности {Trusted Computing Base. TCB). Совокупность аппаратных, программных и

специальных компонент ВС, реализующих функции защиты и обеспечения безопасности.
Прямое взаимодействие с ТСВ обеспечивает возможность непосредственного конфиденциального
взаимодействия между пользователем и ТСВ. Требования ранжируются в зависимости от гибкости
механизмов, обеспечивающих прямое взаимодействие с ТСВ.
«Оранжевая книга» предусматривает четыре группы критериев, которые соответствуют различной
степени защищенности: от минимальной (группа D) до формально доказанной (группа А). Уровень
безопасности возрастает при движении от группы D к группе А, а внутри группы — с возрастанием

номера класса.
• Группа D. Минимальная защита

• Группа С. Дискреционная защита

Группа С характеризуется наличием произвольного управления доступом и регистрацией действий
субъектов.

• Группа В. Мандатная защита

22
Основные требования этой группы — нормативное управление доступом с использованием меток
безопасности, поддержка модели и политики безопасности, а также наличие спецификаций на функции
ТСВ. Для систем этой группы монитор взаимодействий должен контролировать все события в системе.
• Группа А. Верифицированная защита
Данная группа характеризуется применением формальных методов верификации корректности
работы механизмов управления доступом (произвольного и нормативного). Требуется
дополнительная документация, демонстрирующая, что архитектура и реализация ТСВ отвечают
требованиям безопасности.

Радужная серия
NCSC-TG-011 Безопасная сетевая интерпретация среды (TNI) 1 августа 1990 Красная книга
Оранжевая книга учитывает односистемную безопасность, но сети являются комбинацией систем, и
каждая сеть нуждается в обеспечении безопасности, не требуя при этом полного доверия от всех и
каждой подключенных к ней систем. Красная книга учитывает аспекты оценки безопасности для сети и
сетевых компонентов. Она учитывает изолированные локальные (LAN) сети и глобальные сети (WAN).
NCSC-TG-013 Программная документация RAMP 1989 Розовая книга
NCSC-TG-022 Восстановление в доверенных системах 30 декабря 1991 Жёлтая книга

15. Европейские (гармонизированные) критерии безопасности информационных

технологий (ITSEC). Функциональная мощность: классы-шаблоны F-C1, F-C2, F-
B1. F-B2, F-B3, F-IN, F-AV, F-DI, F-DC, F-DX. Адекватность (эффективность и
корректность): таксономия критериев адекватности, уровни адекватности (Е0 - Е6).
Уровни безопасности.
«Европейские критерии» рассматривают следующие задачи средств информационной безопасности:
 защита информации от несанкционированного доступа с целью обеспечения конфиденциально-
сти;
 обеспечение целостности информации посредством защиты от ее несанкционированной модифи-
кации или уничтожения;
 обеспечение работоспособности систем с помощью противодействия угрозам отказа в обслужи-
вании.
Набор функций безопасности может специфицироваться с использованием ссылок на заранее
определенные классы-шаблоны. В «Европейских критериях» таких классов десять. Пять из них (F-C1,
F-C2, F-B1. F-B2, F-B3) соответствуют классам безопасности «Оранжевой книги» с аналогичными
обозначениями.
Класс F-IN предназначен для систем с высокими потребностями в обеспечении целостности, что
типично для систем управления базами данных. Его описание основано на концепции «ролей»,
соответствующих видам деятельности пользователей, и предоставлении доступа к определенным
объемам только посредством доверенных процессов. Должны различаться следующие виды доступа:
чтение, запись, добавление, удаление, создание. переименование и выполнение объектов
КЛАСС F-AV характеризуется повышенными трe6oваниями к обеспечению работоспособности. Это
существенно, например, для систем управления технологическими процессами. В требованиях этого
класса указывается, что система должна восстанавливаться после отказа отдельного аппаратного
компонента таким образом, чтобы все критически важные функции постоянно оставались доступными.
Класс F-DI ориентирован на распределенные системы обработки информации. Перед началом обмена и
при получении данных стороны должны иметь возможность провести идентификацию участников
взаимодействия и проверить ее подлинность. Должны использоваться средства контроля и исправления
ошибок. В частности, при пересылке данных должны обнаруживаться все случайные или намеренные
искажения адресной и пользовательской информации. Знание алгоритма обнаружения искажений не
должно позволять злоумышленнику производить нелегальную модификацию передаваемых данных.
Должны обнаруживаться попытки повторной передачи ранее переданных сообщений.
23
Класс F-DC уделяет особое внимание требованиям к конфиденциальности передаваемой информации.
Информация по канатам связи должна передаваться в зашифрованном виде. Ключи шифрования
должны быть защищены от несанкционированного доступа.
Класс F-DX предъявляет повышенные требования и к целостности и к конфиденциальности
информации. Его можно рассматривать как объединение классов F-DI и F-DC с дополнительными
возможностями шифрования и защиты от анализа трафика. Должен быть ограничен доступ к ранее
переданной информации, которая, в принципе может способствовать проведению криптоанализа.
Для того чтобы удовлетворить требованиям конфиденциальности, целостности и работоспособности,
необходимо реализовать соответствующий набор функций безопасности, таких, как идентификация и
аутентификация, управление доступом, восстановление после сбоев и т. п. Чтобы средства защиты
можно было признать эффективными, требуется определенная степень уверенности в правильности их
выбора и надежности функционирования. Для решения этой проблемы в «Европейских критериях»
впервые вводится понятие адекватности (assurance) средств защиты.

Адекватность включает в себя два аспекта: эффективность, отражающую соответствие средств

безопасности решаемым задачам, и корректность, характеризующую процесс их разработки и
функционирования.
Общая оценка уровня безопасности системы складывается из функциональной мощности средств
защиты и уровня адекватности их реализации. «Европейские критерии» определяют семь уровней
адекватности -— от Е0 до Е6 (в порядке её возрастания). Уровень Е0 обозначает минимальную
адекватность (аналог уровня D «Оранжевой книги»). При проверке адекватности анализируется весь
жизненный цикл системы от начальной фазы проектирования до эксплуатации и сопровождения.
Уровни адекватности от Е1 до Е6 выстроены по нарастанию требований тщательности контроля.
Так, на уровне Е1 анализируется лишь общая архитектура системы, а адекватность средств защиты
подтверждается функциональным тестированием. На уровне ЕЗ к анализу привлекаются исходные
тексты программ и схемы аппаратного обеспечения. На уровне Е6 требуется формальное описание
функций безопасности, общей архитектуры, а также политики безопасности.
Степень безопасности системы определяется самым слабым из критически важных механизмов
защиты. В «Европейских критериях» определены три уровня безопасности — базовый, средний и
высокий. Безопасность считается базовой, если средства защиты способны противостоять отдельным
случайным атакам. Безопасность считается средней, если средства защиты способны противостоять
злоумышленникам, обладающим ограниченными ресурсами и возможностями. Наконец, безопасность
можно считать высокой, если есть уверенность, что средства защиты могут быть преодолены только
злоумышленником с высокой квалификацией, набор возможностей и ресурсов которого выходит за
рамки разумного.

16. Федеральные критерии безопасности информационных технологий (FCITS).

Цели разработки. Понятие профиля защиты (ПЗ). Таксономия функциональных
требований, требований к технологии разработки и процессу квалификационного
анализа ИТ-продукта.
"Федеральные критерии безопасности информационных технологий" разрабатывались как одна из
составляющих "Американского федерального стандарта по обработке информации", призванного
заменить "Оранжевую книгу".
Главной целью создания "Федеральных критериев" являлось определение универсального и открытого
для дальнейшего развития набора основных требований безопасности, предъявляемых к современным
информационным технологиям.
Стандарт определяет обоснованный и структурированный подход к разработке требований
безопасности, предъявляемых к продуктам информационных технологий с учетом областей их
применения.
Стандарт является обобщением основных принципов обеспечения безопасности информационных
технологий, разработанных в 80-е годы, и обеспечивает преемственность по отношению к ним с целью
сохранения достижений в области защиты информации.
24
"Федеральные критерии" содержат положения, относящиеся только к отдельным продуктам
информационных технологий. Вопросы построения систем обработки информации из набора ИТ-
продуктов не являются предметом рассмотрения этого документа.

Профиль защиты
Ключевым понятием концепции информационной безопасности "Федеральных критериев" является
понятие "профиля защиты" (Protection Profile). Профиль защиты - это нормативный документ, который
регламентирует все аспекты безопасности ИТ-продукта в виде требований к его проектированию,
технологии разработки и квалификационному анализу. Как правило, один профиль защиты описывает
несколько близких по структуре и назначению ИТ-продуктов.
Профиль защиты состоит из следующих пяти разделов: описание, обоснование, функциональные
требования к ИТ-продукту, требования к технологии разработки ИТ-продукта, требования к процессу
квалификационного анализа ИТ-продукта.
Описание профиля содержит классификационную информацию, необходимую для его идентификации в
специальной картотеке. Обоснование содержит описание среды эксплуатации, предполагаемых угроз
безопасности и методов использования ИТ-продукта. Кроме того, этот раздел содержит подробный
перечень задач по обеспечению безопасности, решаемых с помощью данного профиля. Эта информация
дает возможность определить, в какой мере данный профиль пригоден для применения в той или иной
ситуации.

Функциональные требования
Раздел функциональных требований к ИТ-продукту содержит описание функциональных возможностей
средств защиты ИТ-продукта и определяет условия, в которых обеспечивается безопасность в виде
перечня угроз, которым успешно противостоят предложенные средства защиты.

Раздел требований к технологии разработки ИТ-продукта охватывает все этапы его создания, начиная
от разработки проекта и заканчивая вводом готовой системы в эксплуатацию. Раздел содержит
требования как к самому процессу разработки, так и к условиям, в которых она проводится, к
используемым технологическим средствам, а также к документированию этого процесса.

Раздел требований к процессу квалификационного анализа ИТ-продукта регламентирует порядок

проведения квалификационного анализа в виде методики исследований и тестирования ИТ-продукта.

Функциональные требования "Федеральных критериев" разделены на восемь классов и определяют все

аспекты функционирования ядра безопасности (Trusted Computing Base, TCB). Под ядром безопасности
понимается совокупность аппаратных, программных и специальных компонент вычислительной
системы, реализующих функции защиты и обеспечения безопасности. Таксономия классов
функциональных требований приведена на рис.1.

25
6.4 Требования к технологии разработки ИТ-продукта
Основное назначение требований к технологии разработки ИТ-продукта - обеспечить адекватность
условий разработки функциональным требованиям, выдвинутым в соответствующем разделе профиля
защиты, и установить ответственность разработчика за корректность реализации этих требований.
Таксономия требований к технологии разработки ИТ-продукта приведена на рис.2.

6.5 Требования к процессу квалификационного анализа ИТ-продукта

Требования к процессу квалификационного анализа ИТ-продукта призваны обеспечить надежность и
корректность этого процесса. Раздел содержит три группы требований, регламентирующих анализ,
контроль и тестирование ИТ-продукта. Таксономия требований этого раздела приведена на рис.3.

17. Канадские критерии безопасности компьютерных систем (CTCPEC).

Таксономия функциональных критериев и критериев адекватности реализации
системы безопасности информации. Уровни адекватности Т0-Т7.
Функциональные критерии разделяются на четыре группы: критерии конфиденциальности,
целостности, работоспособности и аудита. Угрозы несанкционированного доступа к информации
предотвращаются с помощью средств, требования к которым содержатся в разделе критериев
конфиденциальности. Угрозам несанкционированного изменения информации или ее искажения
противостоят средства защиты, функциональные требования к которым задаются критериями
целостности.

26
 Таксономия функциональных критериев «Канадских критериев»

Таксономия критериев адекватности

Внутри каждой труппы критериев определены уровни безопасности, отражающие возможности средств
защиты по решению задач данного раздела. Ранжирование по уровням производится на основании
мощности используемых методов защиты и класса отражаемых угроз соответствующего типа. Уровни с
большим номером обеспечивают более полную функциональность и более высокую степень
безопасности.
Согласно «Канадским критериям», политика безопасности представляет собой множество правил,
регламентирующих обработку, хранение и использование информации. Критерии адекватности
рассматриваются без разделения на подгруппы и определяют требования к процессу проектирования и
разработки компьютерной системы.
«Канадские критерии» определяют степень безопасности компьютерной системы как совокупность
функциональных возможностей используемых средств защиты, характеризующуюся частными показа-
телями обеспечиваемого уровня безопасности, и одного обобщенного параметра — уровня
адекватности реализации политики безопасности.
Адекватность реализации определяется тем, насколько точно и последовательно средства защиты
реализуют принятую в компьютерной системе политику безопасности. Согласно "Канадским
критериям", политика безопасности представляет собой множество правил, регламентирующих
обработку, хранение и использование информации. Критерии адекватности рассматриваются без
разделения на подгруппы и определяют требования к процессу проектирования и разработки
компьютерной системы. Уровень адекватности (от 0 до 7) присваивается всей системе в целом, причем
более высокий уровень означает более полную и корректную реализацию политики безопасности.

27
18. Концепция защиты от НСД к информации (РД ГТК РФ). Два направления - АС
и СВТ. Модель нарушителя: уровни возможностей.
Руководящие документы ГТК предлагают две группы критериев безопасности - показатели
защищенности средств вычислительной техники (СВТ) от НСД и критерии защищенности
автоматизированных систем (АС) обработки данных. Первая группа позволяет оценить степень
защищенности отдельно поставляемых потребителю компонентов ВС, а вторая рассчитана на полно-
функциональные системы обработки данных.

 Показатели защищенности СВТ от НСД

Данный руководящий документ устанавливает классификацию СВТ по уровню защищенности от
НСД к информации на базе перечня показателей защищенности и совокупности описывающих их
требований. Под СВТ понимается совокупность программных и технических элементов систем
обработки данных, способных функционировать самостоятельно или в составе других систем.
Данные показатели содержат требования защищенности СВТ от НСД к информации и применяются к
общесистемным программным средствам и операционным системам. Конкретные перечни показателей
определяют классы защищенности СВТ и описываются совокупностью требований. Совокупность всех
средств защиты составляет комплекс средств защиты (КСЗ).
Установлено семь классов защищенности СВТ от НСД к информации. Самые низкие требования
предъявляются к системам, соответствующим седьмому классу самые высокие — к первому.

 Требования к защищенности aвтоматизированных систем

Данные требования являются составной частью критериев защищенности автоматизированных систем
обработки информации от НСД. Требования сгруппированы вокруг peaлизующих их подсистем защиты.
В отличие от остальных стандартов, отсутствует раздел содержащий требования по обеспечению
работоспособности системы, но присутствует раздел, посвященный криптографическим средствам.

 Классы защищенности автоматизированных систем

Документы ГТК устанавливают девять классов защищенности АС от НСД, каждый из которых
характеризуется определенной совокупностью требовании к средствам защит. Классы подразделяются
на три группы, отличающиеся спецификой обработки информации в АС. Группа АС определяется на
основании следующих признаков:
 наличие в АС информации различного уровня конфиденциальности,

28
  уровень полномочий пользователей АС на доступ к конфиденциальной информации,
 режим обработки данных в АС (коллективный или индивидуальный).
В пределах каждой группы соблюдается иерархия классов защищенности АС.
Третья группа включает АС, в которых работает один пользователь, допущенный ко всей информации
АС. размещенной на носителях одного уровня конфиденциальности. Группа содержит два класса —3Б
и 3А.
Вторая группа включает АС, в которых пользователи имеют одинаковые полномочия доступа ко всей
информации, обрабатываемой и/или хранимой в АС на носителях различного уровня
конфиденциальности. Группа содержит два класса — 2Б и 2А.
Первая группа включает многопользовательские АС, в которых одновременно обрабатывается и/или
хранится информация разных уровней конфиденциальности. Не все пользователи имеют равные права
доступа. Группа содержит пять классов — 1Д, 1Г. 1В, 1Б и 1А.

19. Классификация автоматизированных систем (АС) и требования по защите

информации (РД ГТК РФ). Система классификации защищенных АС. Основные
подсистемы СЗИ (связь функций и классов АС): управления доступом, регистрации
и учета, криптоподсистема, сохранения целостности. Организационные
мероприятия по защите информации от НСД.
Классификация распространяется на все действующие и проектируемые АС учреждений, организаций
и предприятий, обрабатывающие конфиденциальную информацию.
Система классификации защищенных АС.
Основными этапами классификации АС являются:
– разработка и анализ исходных данных;
– выявление основных признаков АС, необходимых для классификации;
– сравнение выявленных признаков АС с классифицируемыми;
– присвоение АС соответствующего класса защиты информации от НСД.
Необходимыми исходными данными для проведения классификации конкретной АС являются:
– перечень защищаемых информационных ресурсов АС и их уровень конфиденциальности;
– перечень лиц, имеющих доступ к штатным средствам АС, с указанием их уровня полномочий;
– матрица доступа или полномочий субъектов доступа по отношению к защищаемым
информационным ресурсам АС;
– режим обработки данных в АС.
Выбор класса АС производится заказчиком и разработчиком с привлечением специалистов по
защите информации. К числу определяющих признаков, по которым производится группировка
АС в различные классы, относятся:
– наличие в АС информации различного уровня конфиденциальности;
– уровень полномочий субъектов доступа АС на доступ к конфиденциальной информации;
– режим обработки данных в АС - коллективный или индивидуальный.
Устанавливается девять классов защищенности АС от НСД к информации. Каждый класс
характеризуется определенной минимальной совокупностью требований по защите. Классы
подразделяются на три группы, отличающиеся особенностями обработки информации в АС.
Третья группа включает АС, в которых работает один пользователь, допущенный ко всей
информации АС, размещенной на носителях одного уровня конфиденциальности. Группа
содержит два класса - 3Б и 3А. Вторая группа включает АС, в которых пользователи имеют
одинаковые права доступа (полномочия) ко всей информации АС, обрабатываемой и (или)
хранимой на носителях различного уровня конфиденциальности. Группа содержит два класса - 2Б
и 2А. Первая группа включает многопользовательские АС, в которых одновременно
обрабатывается и (или) хранится информация разных уровней конфиденциальности. Не все
пользователи имеют право доступа ко всей информации АС. Группа содержит пять классов - 1Д,
1Г, 1В, 1Б и 1А.

Основные подсистемы СЗИ (связь функций и классов АС):

29
 управления доступом, регистрации и учета, криптоподсистема,
сохранения целостности.
1. Подсистема управления доступом: 1.1 Идентификация, проверка подлинности и контроль
доступа субъектов:
– в систему к терминалам, ЭВМ, узлам сети ЭВМ, каналам связи, внешним устройствам ЭВМ,
– к программам,
– к томам, каталогам, файлам, записям, полям записей.
2. Подсистема регистрации и учета: 2.1 Регистрация и учет: – входа (выхода) субъектов доступа
в (из) систему(ы) (узел сети) – выдачи печатных (графических) выходных документов – запуска
(завершения) программ и процессов (заданий, задач) – доступа программ субъектов доступа к
защищаемым файлам, включая их создание и удаление, передачу по линиям и каналам связи –
доступа программ субъектов доступа к терминалам, ЭВМ, узлам сети ЭВМ, каналам связи,
внешним устройствам ЭВМ, программам, томам, каталогам, файлам, записям, полям записей –
изменения полномочий субъектов доступа создаваемых защищаемых объектов доступа 2.2 Учет
носителей информации 2.3 Очистка освобождаемых областей оперативной памяти ЭВМ и
внешних накопителей 2.4 Сигнализация попыток нарушения защиты
3. Криптографическая подсистема: 3.1. Шифрование конфиденциальной информации 3.2.
Шифрование информации, принадлежащей различным субъектам доступа
4. Подсистема обеспечения целостности:
4.1. Обеспечение целостности программных средств и обрабатываемой информации 4.2. Физическая
охрана средств вычислительной техники и носителей информации 4.3. Наличие администратора
(службы) защиты информации в АС 4.4. Периодическое тестирование СЗИ НСД 4.5. Наличие
средств восстановления СЗИ НСД 4.6. Использование сертифицированных средств защиты
Организационные мероприятия по защите информации от НСД.
Организация защиты от утечки по техническим каналам секретной речевой (акустической)
информации
К таким мероприятиям относятся:
- Категорирование помещений предприятия, используемых для обсуждения информации,
составляющей государственную тайну.
- Проведение специальной проверки выделенных помещений, а также размещенных в них технических
средств иностранного производства с целью выявления возможно внедренных в них электронных
устройств перехвата информации (закладок).
- Выполнение организационно-режимных мероприятий по допуску и охране выделенных помещений.
- Установка в выделенных помещениях технических средств сертифицированных по требованиям
безопасности информации.
- Исключение использования в выделенных помещениях радиотелефонов, оконечных устройств
сотовой связи.
- Выполнение требований по звукоизоляции и виброакустической защите ограждающих конструкций
выделенных помещений, их систем вентиляции и кондиционирования. Повышение звукоизоляции
ограждающих конструкций помещений.
Аттестация проводится организацией, имеющей соответствующую лицензию ФСТЭК России.
В целях защиты информации, обрабатываемой всеми видами основных технических средств и систем

20. Показатели и классы защищенности средств вычислительной техники (СВТ)

(РД ГТК РФ). Классификация защищенных СВТ. Дискреционный и мандатный
принцип контроля доступа. Очистка памяти. Изоляция модулей. Маркировка
документов. Защита ввода и вывода на отчуждаемый физический носитель
информации. Сопоставление пользователя с устройством. Идентификация и
аутентификация. Регистрация. Взаимодействие пользователя с КСЗ. Надежное
восстановление. Целостность КСЗ.
КСЗ – комплекс средств защиты Перечень показателей по классам защищенности СВТ (от 6 до 1): "-" –
нет требований к данному классу; "+" – новые или дополнительные требования, "=" – требования
совпадают с требованиями к СВТ предыдущего класса.
30
Седьмой класс присваивают СВТ, к которым предъявлялись требования по защите от НСД к
информации, но при оценке защищенность СВТ оказалась ниже уровня требований шестого
класса.
Классификация защищенных СВТ. Устанавливается семь классов защищенности СВТ от
НСД к информации. Самый низкий класс – седьмой, самый высокий – первый. Классы
подразделяются на четыре группы, отличающиеся качественным уровнем защиты: – первая группа
содержит только один седьмой класс; – вторая группа характеризуется дискреционной защитой и
содержит шестой и пятый классы; – третья группа характеризуется мандатной защитой и содержит
четвертый, третий и второй классы; – четвертая группа характеризуется верифицированной
защитой и содержит только первый класс. Выбор класса защищенности СВТ для
автоматизированных систем, создаваемых на базе защищенных СВТ, зависит от грифа секретности
обрабатываемой в АС информации, условий эксплуатации и расположения объектов системы.
Дискреционный и мандатный принцип контроля доступа. Дискреционный принцип
контроля доступа. КСЗ должен контролировать доступ наименованных субъектов (пользователей)
к наименованным объектам (файлам, программам, томам и т.д.). Для каждой пары (субъект –
объект) в СВТ должно быть задано явное и недвусмысленное перечисление допустимых типов
доступа (читать, писать и т.д.), т.е. тех типов доступа, которые являются санкционированными для
данного субъекта (индивида или группы индивидов) к данному ресурсу СВТ (объекту). КСЗ
должен содержать механизм, претворяющий в жизнь дискреционные правила разграничения
доступа. Контроль доступа должен быть применим к каждому объекту и каждому субъекту
(индивиду или группе равноправных индивидов). Механизм, реализующий дискреционный
принцип контроля доступа, должен предусматривать возможности санкционированного изменения
ПРД, в том числе возможность санкционированного изменения списка пользователей СВТ и
списка защищаемых объектов. Права изменять ПРД должны предоставляться выделенным
субъектам (администрации, службе безопасности и т.д.). Мандатный принцип контроля доступа.
Для реализации этого принципа должны сопоставляться классификационные метки каждого
субъекта и каждого объекта, отражающие их место в соответствующей иерархии. Посредством
этих меток субъектам и объектам должны назначаться классификационные уровни (уровни
уязвимости, категории секретности и т.п.), являющиеся комбинациями иерархических и
неиерархических категорий. Данные метки должны служить основой мандатного принципа
31
разграничения доступа. КСЗ при вводе новых данных в систему должен запрашивать и получать от
санкционированного пользователя классификационные метки этих данных. При
санкционированном занесении в список пользователей нового субъекта должно осуществляться
сопоставление ему классификационных меток. Внешние классификационные метки (субъектов,
объектов) должны точно соответствовать внутренним меткам (внутри КСЗ). В СВТ должен быть
реализован диспетчер доступа, т.е. средство, осуществляющее перехват всех обращений субъектов
к объектам, а также разграничение доступа в соответствии с заданным принципом разграничения
доступа. При этом решение о санкционированности запроса на доступ должно приниматься только
при одновременном разрешении его и дискреционными, и мандатными ПРД. Таким образом,
должен контролироваться не только единичный акт доступа, но и потоки информации.
Очистка памяти. При первоначальном назначении или при перераспределении внешней
памяти КСЗ должен затруднять субъекту доступ к остаточной информации. При
перераспределении оперативной памяти КСЗ должен осуществлять ее очистку.
Изоляция модулей. При наличии в СВТ мультипрограммирования в КСЗ должен
существовать программно-технический механизм, изолирующий программные модули одного
процесса (одного субъекта), от программных модулей других процессов (других субъектов) - т.е. в
оперативной памяти ЭВМ программы разных пользователей должны быть защищены друг от
друга.
Маркировка документов. При выводе защищаемой информации на документ в начале и
конце проставляют штамп N 1 и заполняют его реквизиты в соответствии с Инструкцией N 0126-
87.
Защита ввода и вывода на отчуждаемый физический носитель
информации. КСЗ должен различать каждое устройство ввода-вывода и каждый канал связи
как произвольно используемые или идентифицированные ("помеченные"). При вводе с
"помеченного" устройства (вывода на "помеченное" устройство) КСЗ должен обеспечивать
соответствие между меткой вводимого (выводимого) объекта (классификационным уровнем) и
меткой устройства. Такое же соответствие должно обеспечиваться при работе с "помеченным"
каналом связи. Изменения в назначении и разметке устройств и каналов должны осуществляться
только под контролем КСЗ.
Сопоставление пользователя с устройством. КСЗ должен обеспечивать вывод
информации на запрошенное пользователем устройство как для произвольно используемых
устройств, так и для идентифицированных (при совпадении маркировки). Идентифицированный
КСЗ должен включать в себя механизм, посредством которого санкционированный пользователь
надежно сопоставляется выделенному устройству.
Идентификация и аутентификация. Регистрация. Идентификация и аутентификация
КСЗ должен требовать от пользователей идентифицировать себя при запросах на доступ. КСЗ
должен подвергать проверке подлинность идентификации – осуществлять аутентификацию. КСЗ
должен располагать необходимыми данными для идентификации и аутентификации. КСЗ должен
препятствовать доступу к защищаемым ресурсам неидентифицированных пользователей и
пользователей, подлинность идентификации которых при аутентификации не подтвердилась.
Регистрация: КСЗ должен быть в состоянии осуществлять регистрацию следующих событий: –
использование идентификационного и аутентификационного механизма; – запрос на доступ к
защищаемому ресурсу (открытие файла, запуск программы и т.д.); – создание и уничтожение
объекта; – действия по изменению ПРД. Для каждого из этих событий должна регистрироваться
следующая информация: – дата и время; – субъект, осуществляющий регистрируемое действие; –
тип события (если регистрируется запрос на доступ, то следует отмечать объект и тип доступа); –
успешно ли осуществилось событие (обслужен запрос на доступ или нет). КСЗ должен содержать
средства выборочного ознакомления с регистрационной информацией.
Взаимодействие пользователя с КСЗ. Надежное восстановление. Взаимодействие
пользователя с КСЗ: Для обеспечения возможности изучения, анализа, верификации и
модификации КСЗ должен быть хорошо структурирован, его структура должна быть модульной и
четко определенной. Интерфейс пользователя и КСЗ должен быть определен (вход в систему,
запросы пользователей и КСЗ и т.п.). Должна быть обеспечена надежность такого интерфейса.
Каждый интерфейс пользователя и КСЗ должен быть логически изолирован от других таких же

32
 интерфейсов. Надежное восстановление: КСЗ должен предусматривать процедуры восстановления
после сбоев и отказов оборудования должны обеспечивать восстановление свойств КСЗ.

21. Межсетевые экраны (МЭ) (РД ГТК РФ). Классификация МЭ. Связь классов с
показателями: управление доступом, идентификация и аутентификация,
регистрация, администрирование (идентификация, аутентификация, регистрация),
простота использования, целостность, восстановление, тестирование, руководство
администратора, тестовая и конструкторская (проектная) документация. Связь
классов с уровнями базовой эталонной модели сетей.
МЭ представляет собой локальное или комплексное средство , реализующее контроль за информацией,
поступающей в АС и/или выходящей из АС, и обеспечивает защиту АС посредством фильтрации
информации. Классификация МЭ. Устанавливается пять классов защищенности МЭ. Каждый
класс характеризуется определенной минимальной совокупностью требований по защите
информации. Самый низкий класс защищенности - пятый, применяемый для безопасного
взаимодействия АС класса 1Д с внешней средой, четвертый - для 1Г, третий - 1В, второй - 1Б,
самый высокий - первый, применяемый для безопасного взаимодействия АС класса 1А с внешней
средой. Для АС класса 3Б, 2Б должны применяться МЭ не ниже 5 класса. Для АС класса 3А, 2А в
зависимости от важности обрабатываемой информации должны применяться МЭ следующих
классов: – при обработке информации с грифом “секретно” - не ниже 3 класса; – при обработке
информации с грифом “совершенно секретно” - не ниже 2 3 класса; – при обработке информации
с грифом “особой важности” - не ниже 1 класса. Связь классов с показателями: "-" – нет
требований к данному классу; "+" – новые или дополнительные требования, "=" – требования
совпадают с требованиями к СВТ предыдущего класса.

Связь классов с уровнями базовой эталонной модели сетей. Связь наблюдается в управлении
доступом:
Для 5го класса: МЭ должен обеспечивать фильтрацию на сетевом уровне. Решение по
фильтрации может приниматься для каждого сетевого пакета независимо на основе, по крайней мере,
сетевых адресов отправителя и получателя или на основе других эквивалентных атрибутов.
Для 4го класса: Как и в 5ом, но дополнительно МЭ должен обеспечивать:
 Фильтрацию пакетов служебных протоколов, служащих для диагностики и управления
работой сетевых устройств;
 Фильтрацию с учетом входного и выходного сетевого интерфейса как средство проверки
подлинности сетевых адресов;
 Фильтрацию с учетом любых значимых полей сетевых пакетов.

33
  МЭ должен обеспечивать идентификацию и аутентификацию всех субъектов прикладного
уровня.
Для 3го класса: Как и в 4ом, но дополнительно МЭ должен обеспечивать:
 Фильтрацию на транспортном уровне запросов на установление виртуальных соединений.
При этом, по крайней мере, учитываются транспортные адреса отправителя и получателя;
 Фильтрацию на прикладном уровне запросов к прикладным сервисам. При этом, по
крайней мере, учитываются прикладные адреса отправителя и получателя;
 Фильтрацию с учетом даты/времени.
Для 2го класса: Как и для 3го, но дополнительно МЭ должен обеспечивать:
 Возможность сокрытия субъектов (объектов) и/или прикладных функций защищаемой
сети;
 Возможность трансляции сетевых адресов.
~Для регистрации все то же, что и для 3-го, но дополнительно МЭ должен обеспечивать:
 Дистанционную сигнализацию попыток нарушения правил фильтрации;
 Регистрацию и учет запрашиваемых сервисов прикладного уровня;
 Программируемую реакцию на события в МЭ.
Для 1го класса: Как и для 2го, но дополнительно МЭ должен обеспечивать идентификацию и
аутентификацию всех субъектов прикладного уровня.

Идентификация — это процесс опознания, определения объекта по его свойствам.

(мы указываем свой логин для входа)
Аутентификация — это процесс подтверждения подлинности объекта (мы
указываем свой пароль).

22 Требования по безопасности информации, устанавливающие уровни доверия к

средствам технической защиты информации и средствам обеспечения безопасности
информационных технологий (Приказ ФСТЭК России № 76 от 2 июня 2020 г.,
выписка).
Для дифференциации требований по безопасности информации к средствам устанавливается 6
уровней доверия. Самый низкий уровень – шестой, самый высокий – первый.
Средства, соответствующие 6 уровню доверия, применяются в значимых объектах критической
информационной инфраструктуры 3 категории*, в государственных информационных системах 3
класса защищенности**, в автоматизированных системах управления производственными и
технологическими процессами 3 класса защищенности***, в информационных системах персональных
данных при необходимости обеспечения 3 и 4 уровня защищенности персональных данных****.
Средства, соответствующие 5 уровню доверия, применяются в значимых объектах критической
информационной инфраструктуры 2 категории*, в государственных информационных системах 2
класса защищенности**, в автоматизированных системах управления производственными и
технологическими процессами 2 класса защищенности***, в информационных системах персональных
данных при необходимости обеспечения 2 уровня защищенности персональных данных****.
Средства, соответствующие 4 уровню доверия, применяются в значимых объектах критической
информационной инфраструктуры 1 категории*, в государственных информационных системах 1
класса защищенности**, в автоматизированных системах управления производственными и
технологическими процессами 1 класса защищенности***, в информационных системах персональных
данных при необходимости обеспечения 1 уровня защищенности персональных данных****, в
информационных системах общего пользования II класса*****.
5. При проведении сертификации средства защиты информации должно быть подтверждено
соответствие средства настоящим Требованиям.
Устанавливается следующее соответствие классов средств защиты информации и средств
вычислительной техники уровням доверия:
34
 средства защиты информации 6 класса должны соответствовать 6 уровню доверия;
средства защиты информации 5 класса должны соответствовать 5 уровню доверия;
средства защиты информации 4 класса и средства вычислительной техники 5 класса должны
соответствовать 4 уровню доверия.
6. Средство соответствует уровню доверия, если оно удовлетворяет требованиям к разработке и
производству средства, проведению испытаний средства, поддержке безопасности средства,
приведенным в таблице 1.
Таблица 1
N Наименование требования к уровню доверия Уровень доверия
п/п 6 5 4
1. Требования к разработке и производству
средства:
1.1. требования к разработке модели безопасности +
средства
1.2. требования к проектированию архитектуры + = =
безопасности средства
1.3. требования к разработке функциональной + + +
спецификации средства
1.4. требования к проектированию средства + = =
1.5. требования к разработке проектной + + +
(программной) документации
1.6. требования к средствам разработки, + = =
применяемым для создания средства
1.7. требования к управлению конфигурацией + + +
средства
1.8. требования к разработке документации по + = +
безопасной разработке средства
1.9. требования к разработке эксплуатационной + = =
документации
2. Требования к проведению испытаний средства:
2.1. требования к тестированию средства + + +
2.2. требования к испытаниям по выявлению + + +
уязвимостей и недекларированных
возможностей средства
2.3. требования к проведению анализа скрытых +
каналов в средстве
3. Требования к поддержке безопасности средства:
3.1. требования к устранению недостатков средства + + +
3.2. требования к обновлению средства + + +
3.3. требования к документированию процедур + = =
устранения недостатков и обновления средства
3.4. требования к информированию об окончании + = =
производства и (или) поддержки безопасности
средства

Обозначение "+" в строке требования к уровню доверия указывает на наличие требований,

предъявляемых к соответствующему уровню доверия.
Обозначение "=" означает, что требования к уровню доверия совпадают с требованиями,
предъявляемыми к предыдущему уровню доверия.
Отсутствие обозначения "+" или "=" означает, что требования к уровню доверия не
предъявляются.
35
23. Испытания программных средств на наличие компьютерных вирусов (ГОСТ Р
51188-98). Виды вирусов и методы испытаний.
4 ПОРЯДОК ПРОВЕДЕНИЯ ИСПЫТАНИЙ ПРОГРАММНЫХ СРЕДСТВ НА НАЛИЧИЕ
КОМПЬЮТЕРНЫХ ВИРУСОВ
4.1 Испытания ПС на наличие KB следует проводить на специально оборудованном программно-
аппаратном испытательном стенде.
4.2 Предприятие, проводящее проверку ПС на наличие KB, должно поддерживать испытательный стенд
в работоспособном состоянии и не допускать проникновения KB в программы и данные до начала
проведения испытаний.
4.3 Организация, проводящая проверку ПС на наличие KB, должна определить и зафиксировать в
программе испытаний цель и объем испытаний, а также свои обязательства, касающиеся мер защиты
проверяемых ПС от их заражения KB с учетом требований ГОСТ 19.301.
4.4 Меры по защите проверяемых ПС от заражения KB могут включать в себя:
- разработку и выполнение комплекса мероприятий по профилактике, ревизии и вакцинированию
используемых ПС;
- подготовку должностных лиц, отвечающих за проведение испытаний ПС;
- разработку и выбор способов применения программно-технических средств для обнаружения KB в
ПС;
- взаимодействие организаций, заказывающих и проводящих испытания ПС;
- контроль за проведением испытаний ПС;
- оценку эффективности применяемых антивирусных средств;
- совершенствование системы мероприятий по защите ПС от KB на основе современных достижений
информационной технологии;
- установление административной ответственности должностных лиц за выполнение требований
защиты ПС от KB;
- назначение ответственных должностных лиц и определение их полномочий, относящихся к
организации и проведению мероприятий по защите ПС от КВ.
4.5 Организация, выполняющая проверку ПС на наличие KB, должна обеспечить весь процесс проверки
необходимыми вычислительными техническими и программными средствами, а также назначить
специально обученных сотрудников для проведения испытаний.
4.6 Организация, выполняющая проверку ПС на наличие KB, должна назначить постоянного
представителя, который получает определенные полномочия и несет постоянную ответственность за
выполнение требований, установленных настоящим стандартом.
4.7 В состав технических средств испытательного стенда должны входить:
- совместимые ПЭВМ;
- необходимые элементы телекоммуникационных сетей;
- каналы связи.
4.8 Конкретный набор технических компонентов испытательного стенда должен быть таким, чтобы
были обеспечены условия воспроизведения всех необходимых внешних воздействий на ПС в
процессе проведения испытаний.

ГОСТ Р 51188-98
Перед началом испытаний состав технических средств, используемых для проведения проверок ПС на
наличие KB, должен быть согласован с организацией, заказывающей эти проверки. При этом
согласование должно быть оформлено соответствующим актом.
4.9 Наряду с компонентами, указанными в 4.7, в состав испытательного стенда могут входить
соответствующие аппаратные антивирусные средства.
4.10 Состав и функциональное назначение программных средств испытательного стенда определяются
системой защиты, применяемой при проведении испытаний ПС на наличие КВ.
4.16 Проверка ПС на наличие KB в общем случае включает в себя:
- поиск вирусоподобных фрагментов кодов ПС;
- моделирование ситуаций, предположительно способных вызвать активизацию KB;
- анализ особенностей взаимодействия компонентов ПС с окружающей операционной средой;
- отражение результатов проверки в соответствующей документации.

36
5 МЕТОДЫ ПРОВЕДЕНИЯ ИСПЫТАНИЙ ПРОГРАММНЫХ СРЕДСТВ НА НАЛИЧИЕ
КОМПЬЮТЕРНЫХ ВИРУСОВ
5.1 При испытаниях ПС на наличие KB используют две основные группы методов обнаружения KB и
защиты программ от них: программные и аппаратно-программные. К программным методам
относятся:
- сканирование – сканирование всех файлов на вирусы;
- обнаружение изменений – когда контролируются изменения в файлах;
- эвристический анализ – анализ процессов и действий, выполняемых программой;
- резидентные «сторожа» - тоже проверка, только в реальном времени;
- вакцинирование ПС – лечение заражённых файлов, путём удаления вирусного кода.
Аппаратно-программные методы основаны на реализации любого (любых) из указанных выше
программных методов защиты ПС от KB с помощью специальных технических устройств.
Виды КВ
Червь – вредоносная программа, целью которой является забить компьютер всяким мусором
Троянская программа (Троян, Троянский конь) – эта программа полностью оправдывает свое
название. Она проникает в другие программы и скрывается там до момента, когда программа-хозяин
будет запущена. До запуска хозяйской программы вирус не может нанести вред. Чаще всего троянский
конь используется для удаления, изменения или кражи данных. Самостоятельно размножатся троян не
может.
Программа-блокировщик (баннер) – эти программы блокируют доступ к операционной системе.
Загрузочные вирусы – поражают загрузочный сектор винчестера (жесткого диска). Их целью является
существенное замедление процесса загрузки операционной системы.
Шпионское ПО – программы, пересылающие данные пользователя сторонним лицам без его ведома.
Шпионы занимаются тем, что изучают поведение пользователя и его излюбленные места в интернете, а
затем демонстрируют рекламу, которая однозначно будет ему интересна.
Руткит – программные средства, которые позволяют злоумышленнику беспрепятственно проникать в
программное обеспечение жертвы, а затем полностью скрыть все следы своего пребывания.
Полиморфные вирусы – вирусы, которые маскируются и перевоплощаются. Во время работы они
могут менять собственный код.

24. Антивирусные средства защиты информации (РД ГТК РФ). Показатели

защищенности и требования по защите от вирусов. Виды вирусов. Классификация
АВС. Характеристика основных подсистем: контроля целостности; блокирования
внедрения; обнаружения; удаления; обеспечения гарантированности свойств;
регистрации.
Антивирусные средства классифицируются на четыре типа: «А», «Б», «В» и «Г».
тип «А» – средства антивирусной защиты, предназначенные для
централизованного администрирования средствами антивирусной защиты,
установленными на компонентах информационных систем;
тип «Б» – средства антивирусной защиты, предназначенные для применения на
серверах информационных систем;
тип «В» – средства антивирусной защиты, предназначенные для применения на
автоматизированных рабочих местах информационных систем;
тип «Г» – средства антивирусной защиты, предназначенные для применения на
автономных автоматизированных рабочих местах.
Средства антивирусной защиты типа «А» не могут применяться в
информационных системах самостоятельно. Они предназначены для использования
только совместно со средствами антивирусной защиты типов «Б» и «В».
Также антивирусные средства защиты могут классифицироваться по классам. Всего
существует шесть классов защиты. АВС классов: 1,2 и 3 применяются для обеспечения
безопасности информации, содержащей государственную тайну. Защита информации, не
содержащей государственную тайну может осуществляться АВС 4-ой группы. Защита 1
37
и 2 уровня защиты информационных систем персонального доступа выполняется АВС 4
и 5 групп соответственно, А 3 и 4 уровня – АВС 6-ого класса. Требования к АВС
различных классов описаны в РД «СВТ, Защита от НСД, показатели защищенности от
НСД».
Требования к АВС первой группы
Перечень показателей по классам защищенности АВС первой группы приведен в
таблице № 1. Обозначения: "-" - нет требований к данному классу;
"+" - новые или дополнительные требования к данному классу;
"=" - требования к данному классу совпадают с требованиями предыдущего класса;
Таблица 1
Показатели защищенности А6 А5 А4 АЗ А2 А1

Обнаружение + + + + + +
Удаление + + = = = =
Восстановление + + + = + =
Блокирование - - - + + +
Регистрация + = = + = =
Администрирование + + = + + +
Гарантированность свойств + + + + + +
Документация + = = + = =
Виды вирусов
Вирус (программа-вирус) - исполняемый программный код или интерпретируемый
набор инструкций
Активный вирус - вирус, программный код или часть программного кода которого
находится в оперативной или виртуальной памяти и периодически выполняется.
Известный вирус - вирус, информация о котором содержится в АВС.
Полиморфный вирус - вирус, который обладает способностью полностью или частично
изменять свой код при каждой репликации.
Файловый вирус - вирус, который внедряется в файловую структуру и распространяется
вместе с файлами.
Вирус-спутник - разновидность файлового вируса, который не внедряется явно в
файловую структуру, но использует имя существующей программы, изменяя его или
создавая дополнительный файл с тем же именем, но с другим расширением.
Загрузочный вирус - вирус, в котором реализован алгоритм внедрения в загрузочные
секторы дисков и распространения на этапе загрузки со сменных (отчуждаемых)
носителей данных.
Шифро-вирус - вирус, в котором реализован алгоритм изменения своего исполняемого
кода методами маскирования (шифрования).
Комбинированный вирус - вирус, в котором реализована комбинация различных
алгоритмов внедрения, распространения и маскировки.
Стелс-вирус - вирус, в котором реализован алгоритм обеспечивающий активное
противодействие процедуре его обнаружения с помощью соответствующего
изменения выполнения функций операционной системы.
Макрокомандный вирус - вирус, объектом-источником которого является
интерпретируемая последовательность инструкций.
Классификация вирусов

38
В настоящее время известно более 5000 программных вирусов, их можно
классифицировать по следующим признакам:
 Среде обитания
 Способу заражения среды обитания
 Воздействию
 Особенностям алгоритма
В зависимости от среды обитания вирусы можно разделить на сетевые, файловые,
загрузочные и файлово-загрузочные.
По способу заражения вирусы делятся на резидентные и нерезидентные. Резидентный
вирус при заражении (инфицировании) компьютера оставляет в оперативной памяти
свою резидентную часть, которая потом перехватывает обращение операционной
системы к объектам заражения и внедряется в них, оставаясь активными вплоть до
выключения компьютера. Нерезидентные вирусы не заражают память компьютера и
являются активными ограниченное время.
По степени воздействия вирусы можно разделить на следующие виды:
¨ неопасные; опасные вирусы; очень опасные.
По особенностям алгоритма работы вирусы делятся на резидентные, стелс-вирусы, поли
морфные вирусы и вирусы, использующие нестандартные приемы.

Контроль целостности – АВС должно обладать свойством проверять целостность

имеющихся файлов и программ, на наличие изменений в их коде, по вызову оператора.
Блокирование внедрения – АВС должно обладать возможность блокировать вирусные
воздействия по всем каналам связи, а также блокировать вредоносную задачу (сеанс)
Обнаружения – АВС должно обеспечивать выполнение периодических проверок
физических носителей, томов и каталогов, оперативной памяти, на факт наличия КВ, по
запросу оператора или самостоятельно. В соответствии с классом защиты АВС должно
находить установленное число известных, неизвестных вирусов, а также находить не более
определённого числа ложных заражений.
Удаления – АВС должно обеспечивать возможность удаления инфицированных файлов и
программ, а также их переименования и копирования в целевой каталог.
Обеспечения гарантированности свойств – АВС должно обладать возможностью
периодического обновления, для поддержания своей эффективной работы. Также АВС
должно обладать временной эффективностью обработки заражённых объектов.
Регистрации – АВС должно обладать возможность создания отчётов по результатам
проверки, в понятном для человека формате, в котором указываются дата проверки, объект
проверки, тип события и результат проверки.

25. Специальные защитные знаки (СЗЗ) (РД ГТК РФ). Классификация по

возможности подделки, идентифицируемости и стойкости защитных свойств.
Применение на объектах различной категории.
Специальный защитный знак; СЗЗ - Сертифицированное и зарегистрированное в
установленном порядке изделие, предназначенное для контроля
несанкционированного доступа к объектам защиты путем определения подлинности
и целостности СЗЗ, путем сравнения самого знака или композиции "СЗЗ-подложка"
по критериям соответствия.]
Классификация по:
-Возможности подделки определяется технологией изготовления СЗЗ:
А1 - СЗЗ изготовлен с использованием отечественных НОУ-ХАУ технологий;
39
 А2 - СЗЗ изготовлен с использованием зарубежных НОУ-ХАУ технологий;
А3 - СЗЗ изготовлен без использования НОУ-ХАУ технологий.
-Идентифицируемости определяется уровнем сложности сигнальной информации в
знаке:
В1 - целостность и подлинность могут быть определены с применением
специальных технических средств контроля
В2 - без применения технических средств контроля или с использованием серийно-
выпускаемых технических средств;
В3 - целостность и подлинность могут быть определены визуально без применения
технических средств и специальных методик контроля.
-Стойкости защитных свойств СЗЗ подразделяются на две группы:
С1 - в технических условиях на СЗЗ задано изменение его внешнего вида и хотя бы
одного характерного признака при несанкционированных воздействиях на СЗЗ или
нарушении условий его эксплуатации;
С2 - в технических условиях на СЗЗ задано изменение только его внешнего вида при
несанкционированных воздействиях на СЗЗ или нарушении условий его
эксплуатации.
Применение на различных обьектах:
Все СЗЗ делятся на 18 классов.
1–6 (1-2 - 1 кат. и ОВ, 3-4 - 2 кат. и СС, 5-6 - 3 кат. и С) Для защиты информации,
отнесенной к государственной тайне
7–12 допускается только для защиты объектов 3 категории (Cлуж. и Коммер. Тайны)
13–18 для Общедоступной Информации.

26. Методология оценки безопасности ИТ (ГОСТ 15408). Области применения

стандарта «Общие критерии».
Гост Р15408 делится на 3 части
1- Введение и общая модель
2- Функциональные требования безопасности
3- Требования доверия к безопасности

ОК(CC) – Общие критерии, исторически сложившееся название, часто используемое во всех частях
настоящего стандарта вместо его официального названия "Критерии оценки безопасности
информационных технологий".
Настоящий стандарт, состоящий из трех частей, определяет критерии, за которыми исторически
закрепилось название "Общие критерии" (ОК). ОК предназначены для использования в качестве
основы при оценке характеристик безопасности продуктов и систем информационных технологий
40
 (ИТ). Устанавливая общую базу критериев, стандарт делает результаты оценки безопасности ИТ
значимыми для более широкой аудитории.
ОК дают возможность сравнения результатов независимых оценок безопасности. Результаты оценки
помогут потребителям решить, являются ли продукты или системы ИТ достаточно безопасными
для их предполагаемого применения, и приемлемы ли прогнозируемые риски при их
использовании.
ОК полезны в качестве руководства как при разработке продуктов или систем с функциями
безопасности ИТ, так и при приобретении коммерческих продуктов и систем с такими функциями.
При оценке такой продукт или систему ИТ называют объектом оценки (ОО).
ОК направлены на защиту информации от несанкционированного раскрытия, модификации или потери
возможности ее использования. Категории защиты, относящиеся к этим трем типам нарушения
безопасности, обычно называют конфиденциальностью, целостностью и доступностью
соответственно.

ОК предназначен для потребителей, разработчиков, оценщиков и прочих лиц.

Основные термины и определения ОК:
ОО (TOE) – Объект оценки (Подлежащие оценке продукт ИТ или система с руководствами
администратора и пользователя).
ПЗ (PP) – Профиль защиты (Независимая от реализации совокупность требований безопасности для
некоторой категории ОО, отвечающая специфическим запросам потребителя).
ЗБ (ST) – Задание по безопасности.
ПБО (TSP) – Политика безопасности ОО.
Класс (class): Группа семейств, объединенных общим назначением.

Процесс оценки ОО может проводиться параллельно с разработкой или следом за ней. Основными
исходными материалами для оценки ОО являются:
а) совокупность свидетельств, характеризующих ОО, включая прошедшее оценку ЗБ в качестве
основы оценки ОО;
б) ОО, безопасность которого требуется оценить;
в) критерии, методология и система оценки.

Ожидаемым результатом оценки является подтверждение удовлетворения объектом оценки

требований безопасности, изложенных в его ЗБ, а также один или несколько отчетов,
документирующих выводы оценщика относительно ОО, сделанные в соответствии с критериями
оценки. Такие отчеты, помимо разработчика, будут полезны также реальным и потенциальным
потребителям продукта или системы, представленной как объект оценки.

27. Контекст оценки безопасности информационных технологий: разработка ОО,

процесс оценки, эксплуатация (ГОСТ 15408).

Контекст оценки безопасности ИТ предполагает право заказчика требовать

реализацию средств контроля для противостояния угрозам данным. Также продукты ИТ
могут подлежать оценке в качестве составной части оценки безопасности системы ИТ.
Если так, то список оцененных продуктов необходимо указать в каталоге оцененных
продуктов. Аттестующий систему ИТ имеет полномочия владельца информации для
вынесения окончательной оценки, подтверждающей способность ИТ обеспечивать
сочетание контрмер безопасности. Формы и степень строгости оценки зависят от
необходимых по мнению аттестующего мер.

Разработка ОО Этот процесс основан на уточнении требований безопасности,

сведенных в краткую спецификацию в составе задания по безопасности. Каждый
последующий уровень уточнения представляет декомпозицию проекта с его

41
дополнительной детализацией. Наименее абстрактным представлением является
непосредственно реализация ОО.

Процесс оценки ОО, как показано на рисунке 4.4, может проводиться параллельно
с разработкой или следом за ней. Основными исходными материалами для оценки ОО
являются:
а) совокупность свидетельств, характеризующих ОО, включая прошедшее оценку
ЗБ в качестве основы оценки ОО;
б) ОО, безопасность которого требуется оценить;
в) критерии, методология и система оценки.

42
 Эксплуатация ОО – дело потребителя, однако в процессе эксплуатации могут
обнаружиться ошибки или уязвимости. В этом случае ОО необходимо обновить,
исправив существующие ошибки, и снова подвергнуть оценке. В некоторых случаях
необязательно оценивать по новой весь ОО, достаточно провести оценку изменений,
добавленных в обновленную версию ОО. Пусть и в ОК существует класс поддержки
доверия (АТА, или как там его), детальное описание процесса переоценки выходит за
рамки ОК.

28. Планирование обработки инцидентов и средства управления непрерывностью

бизнеса.
Организация должна установить документированные процедуры
реагирования на разрушительный инцидент, а также работы и восстановления
деятельности в течение заранее определенного периода времени.
Планы непрерывности бизнеса должны содержать:
a) определенные функции и ответственность сотрудников и команд, обладающих
полномочиями в течение и после инцидента;
b) процесс инициирования ответных мер;
c) информацию о незамедлительных действиях по устранению последствий
разрушительного инцидента, в которой уделено особое внимание: благополучию людей;
стратегическим, тактическим и оперативным вариантам реагирования на разрушения
(нарушения); предотвращению дальнейшей потери или недоступности приоритетных
видов деятельности;
d) способы поддержки связи с персоналом и связанными с ними людьми;
e) способы продолжения или восстановления организацией приоритетных видов
деятельности в рамках заранее установленного периода времени;
f) информацию по взаимодействию со СМИ после инцидента;
g) процесс сворачивания ответных мер после окончания инцидента.
В качестве средства управления непрерывностью бизнеса выступает система
менеджмента непрерывности бизнеса (СМНБ). СМНБ – часть общей системы
менеджмента, которая направлена на установление, внедрение, осуществление,
управление, анализ, поддержку и постоянное улучшение непрерывности бизнеса.
Для начала необходимо определить внешние и внутренние факторы, которые
влияют на выполнение организацией поставленных целей и достижение результатов её
СМНБ. Затем необходимо рассмотреть законодательные и нормативные требования.
Далее должна быть доступна документированная информация по области применения
СМНБ. Следующим шагом будет определение рисков и благоприятных возможностей
для обеспечения уверенности в том, что СМНБ может достигнуть ожидаемых
результатов.
После этого Организация должна планировать, внедрять и контролировать
процессы, необходимые в соответствии с требованиями СМНБ и выполнять следующие
действия:
a) установить необходимые критерии для процессов;
b) осуществить контроль над процессами в соответствии с критериями
c) хранить документацию, подтверждающую, что процессы выполнены в
соответствии с запланированными действиями.

43
29. Последовательность формирования требований и спецификаций (ГОСТ 15408):
среда безопасности, цели безопасности, требования безопасности ИТ и краткая
спецификация ОО.
Цель безопасности (security objective): Изложенное намерение противостоять
установленным угрозам и/или удовлетворять установленной политике безопасности
организации и предположениям.
Среда безопасности включает в себя законы, политики безопасности организаций, опыт,
специальные навыки и знания, имеющие отношение к безопасности. Таким образом, она
определяет контекст предполагаемого применения ОО. Среда безопасности включает
также угрозы безопасности, присутствие которых в этой среде установлено или
предполагается.
При установлении среды безопасности автор ПЗ или ЗБ должен принять во внимание:
a) физическую среду ОО в той ее части, которая определяет все аспекты
эксплуатационной среды ОО, касающиеся его безопасности, включая известные
мероприятия, относящиеся к физической защите и персоналу;
b) активы, которые требуют защиты элементами ОО и к которым применяются
требования или политики безопасности; они могут включать в себя активы, к которым
это относится непосредственно, например файлы и базы данных, а также активы,
которые косвенно подчинены требованиям безопасности, например, данные авторизации
и собственно реализации ИТ;
c) предназначение ОО, включая тип продукта и предполагаемую сферу его
применения.
Цели безопасности
Результаты анализа среды безопасности могут затем быть использованы для
установления целей безопасности, которые направлены на противостояние
установленным угрозам, а также проистекают из установленной политики безопасности
организации и сделанных предположений. Цели безопасности должны быть согласованы
с установленными целями применения или предназначением ОО как продукта, а также
со всеми известными сведениями о физической среде ОО.
Смысл определения целей безопасности заключается в том, чтобы соотнести их со всеми
поставленными ранее вопросами безопасности и декларировать, какие аспекты
безопасности связаны непосредственно с ОО, а какие - с его средой. Такое разделение
основано на совокупном учете инженерного опыта, политики безопасности,
экономических факторов и решения о приемлемости рисков.
Требования безопасности ИТ
Требования безопасности ИТ являются результатом преобразования целей безопасности
в совокупность требований безопасности для ОО и требований безопасности для среды,
которые, в случае их удовлетворения, обеспечат для ОО способность достижения целей
его безопасности.
В ИСО/МЭК 15408 представлены две различные категории требований безопасности -
функциональные требования и требования доверия.
Функциональные требования предъявляются к тем функциям ОО, которые
предназначены для поддержания безопасности ИТ и определяют желательный
безопасный режим функционирования ОО. Функциональные требования определены в
ИСО/МЭК 15408-2. Примерами функциональных требований являются требования к

44
идентификации, аутентификации, аудиту безопасности, неотказуемости источника
(невозможности отказа от факта отправления сообщения).

Если ОО содержит функции безопасности, которые реализуются вероятностными или

перестановочными механизмами (например, паролем или хэш-функцией), то
требования доверия могут определять, что заявленный минимальный уровень стойкости
согласуется с целями безопасности. При этом специфицированный уровень стойкости
будет выбираться из следующих: базовая стойкость функции безопасности (СФБ),
средняя СФБ, высокая СФБ. От каждой такой функции потребуется соответствие
минимальному уровню стойкости или, по меньшей мере, дополнительно определенной
специальной метрике.
Степень доверия к заданной совокупности функциональных требований может меняться;
это, как правило, выражается через возрастание уровня строгости, задаваемого
компонентами доверия. ИСО/МЭК 15408-3 определяет требования доверия и шкалу
оценочных уровней доверия (ОУД), формируемых с использованием этих компонентов.
Требования доверия предъявляются к действиям разработчика, представленным
свидетельствам и действиям оценщика. Примерами требований доверия являются
требования к строгости процесса разработки, поиску потенциальных уязвимостей и
анализу их влияния на безопасность.
Краткая спецификация ОО, предусмотренная в составе ЗБ, определяет отображение
требований безопасности для ОО. В ней обеспечивается высокоуровневое определение
функций безопасности, заявляемых для удовлетворения функциональных требований, и
мер доверия, предпринимаемых для удовлетворения требований доверия.
Требования безопасности ИТ проистекают только из целей безопасности ОО и целей
безопасности его среды, относящихся к ИТ.

30. Обеспечение непрерывности бизнеса. Основные стандарты по управлению

непрерывностью бизнеса. Стратегии управления непрерывностью бизнеса.
Особенности внедрение в культуру организации.
Управление непрерывностью бизнеса (Business Continuity Management или
BCM) - бизнес-процесс, отвечающий за управление рисками, которые могут серьезно
повлиять на бизнес. BCM защищает интересы ключевых заинтересованных сторон,
репутацию, бренд и деятельность по созданию ценности. Процесс BCM включает в себя
снижение рисков до приемлемого уровня и планирование способов восстановления
бизнес-процессов в случае нарушения бизнеса. BCM устанавливает цели, охват и
требования по отношению к Управлению непрерывности ИТ-услуг
Для обеспечения непрерывности деятельности организации необходимо:
 определять ключевые, критически важные для деятельности ресурсы организации;
 проводить оценку рисков и факторов влияния;
 разрабатывать на основе информации о рисках стратегические и тактические
планы, а также процедуры и методы контроля и определять сферы
ответственности;
 внедрять контрольные процедуры и организовывать эффективное взаимодействие
между ответственными сотрудниками;
 осуществлять мониторинг и оптимизировать процесс обеспечения непрерывности
деятельности организации.

45
Успешное проведение процесса обеспечения непрерывности деятельности организации,
как правило, позволяет получить ощутимый положительный результат во многих сферах
деятельности.
Основными стандартами по обеспечению непрерывности бизнеса являются ГОСТы
серии 12700, международный стандарт ISO 22301.
Результаты Анализа влияния на бизнес и Оценки рисков являются основой для
построения Стратегии непрерывности услуг в соответствии с потребностями бизнеса.
Большинство организаций должны соблюдать баланс уменьшения рисков и
формирования механизмов восстановления. Как бы хорошо ни проводились действия по
уменьшению рисков, невозможно исключить их все. Поэтому всегда необходимо
внедрять механизмы восстановления в интеграции с процессом Управления
доступностью, так как именно доступность услуг пострадает в первую очередь при
возникновении неприятных для бизнеса событий.
Опции восстановления в рамках ITSCM, которые должны быть учтены при
формировании стратегии:
 переход на ручную работу для некоторых типов услуг может стать хорошей
альтернативой на короткий период до восстановления услуги
 взаимные соглашения являются еще одной опцией для восстановления.
Предполагают заключение соглашений между организациями, использующими
похожие технологии.
 постепенное восстановление (Gradual Recovery) - способ восстановления, также
известный как "холодное резервирование". Предусматривается восстановление
услуги в течение более чем 72 часов
 промежуточное восстановление (Intermediate Recovery) - способ
восстановления, также известный как "теплое резервирование". Предусматривается
восстановление услуги в течение 24 - 72 часов.
 быстрое восстановление (Fast Recovery) - способ восстановления.
Предусматривается восстановление услуги за короткий промежуток времени,
обычно менее 24 часов. При быстром восстановлении обычно используется
выделенный стационарный резервный центр с компьютерными системами и ПО,
сконфигурированными для работы услуг.
 немедленное восстановление (Immediate recovery) - способ восстановления,
также известный как "горячее резервирование". Предусматривается
восстановление услуги без прерывания услуги. Немедленное восстановление
обычно использует технологии зеркалирования, балансировки загрузки и
разделения площадок установки оборудования
Стратегия обеспечения непрерывности должна включать в себя все рассмотренные
выше способы восстановления. Различные услуги, используемые организацией,
требуют различных подходов к восстановлению и уменьшению рисков сбоя. Какая
бы опция ни выбиралась, она должна быть экономически эффективной. Главное
правило - чем дольше бизнес может обходиться без услуги, тем дешевле должно быть
решение по обеспечению ее непрерывности.

46
31. Представление требований безопасности: классы, семейства, компоненты,
элементы (ГОСТ 15408). Виды связей и зависимостей между компонентами,
разрешенные операции с элементами.

Представление требований безопасности

ОК определяют совокупность конструкций, объединяемых в содержательные
наборы требований безопасности известной пригодности, которые затем могут быть
использованы при установлении требований безопасности к перспективным продуктам и
системам. Взаимосвязь различных конструкций для выражения требований описана
ниже и иллюстрируется на рисунке 4.6.

Семейство K Компонент Пакеты

Наборы функциональных
требований или требований
Компонент доверия для многократного
использования.
Дополнительный источник
Компонент требований для ПЗ и ЗБ

Профиль
Класс А Семейство J Компонент защиты
Возможные источники
Компонент Требований безопасности
Семейство I Компонент для ПЗ
…..

Компонент Компонент
….. Задание по
Компонент Каталоги требований безопасности
безопасности Возможные источники
Дополнительные
Требований безопасности
требования
для ЗБ
безопасности,
не входящие в ОК

Рисунок 4.6 – Организация и структура требований

Организация требований безопасности в ОК в виде иерархии класс –
семейство – компонент призвана помочь потребителям отыскать конкретные
требования безопасности.
Функциональные требования и требования доверия представлены в ОК в едином
стиле и используют одинаковую структуру и терминологию.
Термин "класс" применяется для наиболее общего группирования требований
безопасности. Все составляющие класса имеют общую направленность, но различаются
по охвату целей безопасности.
Составляющие класса называются семействами.
Семейство – это группа наборов требований безопасности, имеющих общие цели
безопасности, но различающихся акцентами или строгостью.
Составляющие семейства называются компонентами.
Компонент описывает специфический набор требований безопасности, который
является наименьшим выбираемым набором требований безопасности для включения в
структуры, определенные в ОК. Совокупность компонентов, входящих в семейство,
может быть упорядочена для представления возрастания силы или возможностей
требований безопасности, имеющих общее назначение. Они могут быть также
упорядочены частично, для представляя связанных неиерархических наборов.
Упорядочение не применимо в случае, когда в семействе имеется только один
компонент.
47
 Компоненты составлены из отдельных элементов.
Элемент – это выражение требований безопасности на самом нижнем уровне. Он
является тем неделимым требованием безопасности, которое может быть
верифицировано при оценке.
Зависимости между компонентами
Между компонентами могут существовать зависимости. Зависимости возникают,
когда компонент не самодостаточен и предполагает наличие другого компонента.
Зависимости могут существовать между функциональными компонентами, между
компонентами доверия, а также между функциональными компонентами и
компонентами доверия.
Описание зависимостей компонента является частью определения компонента в
ОК. Чтобы обеспечить полноту требований к ОО, следует удовлетворить, где это
необходимо, зависимости всех компонентов при их включении в ПЗ и ЗБ.
Разрешенные операции на компонентах
Компоненты ОК можно использовать точно так, как они сформулированы в ОК,
или же можно их конкретизировать, применяя разрешенные операции для выполнения
определенной политики безопасности или для противостояния определенной угрозе. Для
каждого компонента ОК идентифицируются и определяются все разрешенные
операции: назначения и выбора, условия применения операции к компоненту и
возможные результаты применения операции. Операции итерации и уточнения могут
выполняться для любого компонента. Указанные четыре операции определены
следующим образом:
а) итерация, позволяющая неоднократно использовать компонент при
различном выполнении в нем операций;
б) назначение, специфицировать параметр, устанавливаемый при
использовании компонента;
в) выбор, специфицировать пункты, которые выбираются из перечня,
приведенного в компоненте;
г) уточнение, осуществлять дополнительную детализацию при использовании
компонента.

32. Методологи (уровни) рассмотрения вопросов информационной безопасности

(ИБ). Предприятие как объект информатизации (категории), АС и СВТ. Состав
типовой комплексной системы защиты информации на предприятии (КСЗИ):
СКУД, ОТ, ОПС, ПЭШ, КС. Уровни секретности (ГТ: С, СС, ОВ) и
конфиденциальности (К: служебная, коммерческая и общедоступная) информации.
Политика безопасности предприятия. (то же что и 50.)

Как и информационные технологии, информационные системы могут функционировать и с

применением технических средств, и без такого применения. Это вопрос экономической
целесообразности.
Возрастание объёмов информации в информационной системе организаций, потребность в
ускорении и более сложных способах ее переработки вызывают крайне важность
автоматизации работы информационной системы, ᴛ.ᴇ. автоматизации обработки
информации.
Автоматизированная система (АС) − это система, состоящая из персонала и
комплекса средств автоматизации его деятельности, реализующая информационную
технологию выполнения установленных функций.
48
 Элементы автоматизированной системы
 Персонал.
 Данные — часть компьютерной системы (КС).
 Алгоритмы обработки — КС.
 Программно-аппаратная среда (средства вычислительной техники (СВТ)) — КС.

Средство Вычислительной Техники (далее СВТ) — совокупность

программных и технических элементов систем обработки данных, способных
функционировать самостоятельно или в составе других систем.
Не следует путать определение Автоматизированная Система (далее АС) и СВТ. Это
неравнозначные определения. СВТ является лишь одной из составляющих АС частей.
Следовательно, концепция безопасности предусматривает существование двух
относительно самостоятельных и имеющих отличие направлений в проблеме защиты
информации от несанкционированного доступа (НСД): направление, связанное с СВТ, и
направление, связанное с АС. Отличие двух направлений порождено тем, что СВТ
разрабатываются и поставляются на рынок лишь как элементы, из которых в дальнейшем
строятся функционально ориентированные АС. Помимо пользовательской информации
при создании АС появляются такие отсутствующие при разработке СВТ характеристики
АС, как полномочия пользователей, модель нарушителя, технология обработки
информации.
Комплексная защита информационных ресурсов предприятия – это система мер по
их хранению, шифрованию, мониторингу доступа к ним и их обмена.
Она обеспечивает:
защиту информации от различного рода вирусных и хакерских угроз;
сохранность данных при физической утрате и поломках информационных носителей;
безопасность доступа к хранимым ресурсам;
восстановление информационной системы в случае повреждений.
Хранится конфиденциальная информация на специальном секретном и удаленном
сервере. Доступ к ней контролируется и определяется только руководством предприятия
(ограничивается или разрешается определенным сотрудникам).

Система контроля и управления доступом (СКУД) — совокупность программно-

аппаратных технических средств безопасности, имеющих целью ограничение и
регистрацию входа-выхода объектов (людей, транспорта) на заданной территории через
«точки прохода»: двери, ворота, КПП. Пример – турникет в институте.
Охранно-пожарная сигнализация (ОПС). Система позволяет обнаруживать очаги пожара
на ранних стадиях, быстро оповещать людей об опасности. Система также позволяет
предотвращать проникновение нарушителей в помещения.

ПЭШ - противодействие экономическому шпионажу

КС- компьютерная система, автоматизация систем безопасностей – создание узлов
управления и т.п.
ОТ(охранное телевидение) - Для обеспечения безопасности объекта, пожалуй, одним из
наиболее эффективных методов является видеонаблюдение. Данные системы нашли
применение в разных направлениях: от офисов до крупных предприятий, фиксируя и
собирая информацию о сотрудниках и посетителях. Достоинства системы – возможность

49
расширения, подключение дополнительных видеокамер и устройств, а также интеграция с
другими системами (охранная сигнализация, контроль доступа и другие).
Гос тайна и конфед. информация.

Степень секретности сведений, составляющих государственную тайну, соответствует

степени тяжести ущерба, который может быть нанесён государственной безопасности
вследствие разглашения указанных сведений. Устанавливаются три степени секретности
сведений, составляющих государственную тайну, и соответствующие этим
степеням грифы секретности: «особой важности», «совершенно секретно» и
«секретно». Использование перечисленных грифов секретности для засекречивания
сведений, не отнесенных к государственной тайне, не допускается.

К общедоступной информации относятся общеизвестные сведения и иная информация,

доступ к которой не ограничен.
Коммерческая тайна – конфиденциальность информации, позволяющая ее обладателю
при существующих или возможных обстоятельствах увеличить доходы, избежать
неоправданных расходов, сохранить положение на рынке товаров, работ, услуг или
получить иную коммерческую выгоду.
Информация составляет служебную или коммерческую тайну в случае, когда
информация имеет действительную или потенциальную коммерческую ценность в силу
неизвестности ее третьим лицам, к ней нет свободного доступа на законном основании и
обладатель информации принимает меры к охране ее конфиденциальности. Сведения,
которые не могут составлять служебную или коммерческую тайну, определяются законом
и иными правовыми актами.

Политика информационной безопасности организации -совокупность руководящих

принципов, правил, процедур и практических приёмов в области безопасности, которые
регулируют управление, защиту и распределение ценной информации.

33. Источники требований безопасности (ГОСТ 15408). Виды оценок: ПЗ, ЗБ, ОО.
Поддержка доверия.

Виды оценок
Оценка ПЗ
Оценка ПЗ выполняется согласно критериям оценки ПЗ, содержащимся в части 3
настоящего стандарта. Целью такой оценки является продемонстрировать, что профиль

50
полон, непротиворечив, технически грамотен и пригоден для использования при
изложении требований к ОО, предполагаемому для оценки.
Оценка ЗБ
Оценка ЗБ для ОО выполняется согласно критериям оценки ЗБ, содержащимся в
части 3 настоящего стандарта. Такая оценка имеет две цели: во-первых,
продемонстрировать, что ЗБ является полным, непротиворечивым, технически
грамотным и, следовательно, пригодным для использования в качестве основы для
оценки соответствующего ОО; во-вторых, в случае, когда в ЗБ имеется утверждение о
соответствии некоторому ПЗ, – продемонстрировать, что ЗБ должным образом отвечает
требованиям этого ПЗ.
Оценка ОО
Оценка ОО производится согласно критериям оценки, содержащимся в части 3
настоящего стандарта, с использованием в качестве основы ЗБ, прошедшего оценку.
Цель такой оценки – продемонстрировать, что ОО отвечает требованиям безопасности,
содержащимся в ЗБ.
Поддержка доверия
Поддержка доверия к ОО осуществляется в соответствии с критериями оценки из
части 3 настоящего стандарта с использованием предварительно оцененного ОО в
качестве основы. Цель состоит в том, чтобы убедиться, что доверие к ОО, установленное
ранее, поддерживается, и что ОО будет продолжать отвечать требованиям безопасности
после внесения изменений в него или в его среду.

34. Управление инцидентами информационной безопасности. Цели и задачи.

Структура системы управления инцидентами. Первая оценка и вторая оценка,
подтверждение инцидента и реагирование на инциденты (немедленное,
контролируемое, последующее реагирование). Стандартные антикризисные
действия и средства управления событиями.

Цели:
1) события ИБ должны быть обнаружены и эффективно обработаны, в частности,
определены как относящиеся или не относящиеся к инцидентам ИБ*;
2) идентифицированные инциденты ИБ должны быть оценены, и реагирование на них
должно быть осуществлено наиболее целесообразным и результативным способом;
3) воздействия инцидентов ИБ на организацию и ее бизнес-операции необходимо
минимизировать соответствующими защитными мерами, являющимися частью процесса
реагирования на инцидент, иногда наряду с применением соответствующих элементов
плана(ов) обеспечения непрерывности бизнеса;
4) из инцидентов ИБ и их менеджмента необходимо быстро извлечь уроки. Это
делается с целью повышения шансов предотвращения инцидентов ИБ в будущем,
улучшения внедрения и использования защитных мер ИБ, улучшения общей системы
менеджмента инцидентов ИБ
Первая оценка и предварительное решение
В группе обеспечения эксплуатации системы менеджмента инцидентов ИБ
принимающее лицо должно подтвердить получение заполненной формы отчета, ввести
ее в базу данных событий/инцидентов ИБ и проанализировать данную форму отчета.
Далее должностное лицо должно попытаться получить любые уточнения от
сообщившего лица о событии ИБ и собрать требуемую дополнительную информацию,
считающуюся доступной, как от сообщившего о событии лица, так и из любого другого
51
места. Затем представитель группы обеспечения эксплуатации должен провести оценку
для определения, подходит ли это событие под категорию инцидента ИБ или является
ложным. Если событие ИБ определяется как ложное, необходимо заполнить форму
отчета и передать в ГРИИБ для записи в базу данных и дальнейшего анализа, а также
создать копии для сообщившего о событии лица и его/ее местного руководителя.
Вторая оценка и подтверждение инцидента информационной безопасности
Вторая оценка и подтверждение инцидента ИБ или какое-либо другое решение
относительно того, надо ли отнести событие ИБ к инциденту ИБ, должны входить в
обязанности ГРИИБ.
Если все еще остается какая-либо неопределенность относительно аутентичности
инцидента ИБ или полноты полученной информации, то сотрудник ГРИИБ должен
провести вторую оценку для определения реальности или ложности инцидента ИБ. Если
инцидент ИБ определен как "ложный", необходимо заполнить отчет о событии ИБ,
добавить его в базу данных событий/инцидентов ИБ и передать руководителю ГРИИБ.
Копии отчета необходимо передать группе обеспечения эксплуатации, лицу,
сообщившему о событии, и его/ее местному руководителю.

Другие типы возможных "антикризисных действий" включают в себя (но не

ограничиваются) активизацией:
- средств пожаротушения и процедур эвакуации;
- средств предотвращения наводнения и процедур эвакуации;
- средств предотвращения взрыва бомбы и соответствующих процедур эвакуации;
- работы специалистов по расследованию фактов мошенничества в информационных
системах;
- работы специалистов по расследованию технических атак.

35. Особенности профиля защиты (ПЗ) (ГОСТ 15408). Структура ПЗ: введение,
описание ОО. среда безопасности ОО, цели безопасности, требования безопасности
ОО, замечания по применению, обоснование.
ПЗ определяет независимую от конкретной реализации совокупность требований ИТ для
некоторой категории ОО. Такие ОО предназначены для удовлетворения общих запросов потребителей в
безопасности ИТ. Поэтому потребители могут выразить свои запросы в безопасности ИТ, используя
существующий или формируя новый ПЗ, без ссылки на какой-либо конкретный ОО. (см. рис. 1)
Введение ПЗ
Введение ПЗ должно содержать информацию управления документооборотом и обзорную
информацию, необходимые для работы с реестром ПЗ:
а) идентификация ПЗ должна обеспечить маркировку и описательную информацию,
необходимые, чтобы идентифицировать, каталогизировать, регистрировать ПЗ и ссылаться на него;
б) аннотация ПЗ должна дать общую характеристику ПЗ в описательной форме. Она
должна быть достаточно подробной, чтобы потенциальный пользователь ПЗ мог решить, представляет
ли ПЗ для него интерес.
Описание ОО
Эта часть ПЗ должна содержать описание ОО, служащее цели лучшего понимания его
требований безопасности и дающее представление о типе продукта и основных характерных
особенностях ИТ применительно к ОО.
Описание ОО предоставляет контекст для оценки. Информация, содержащаяся в описании ОО,
будет использована в процессе оценки для выявления противоречий

52
 Рисунок 1 – Содержание профиля защиты

Среда безопасности ОО
Изложение среды безопасности ОО должно содержать описание аспектов безопасности среды,
в которой предполагается использовать ОО, и ожидаемый способ его применения. Это изложение
должно включать следующее.
а) Описание предположений, содержащее аспекты безопасности среды, в которой ОО будет
использоваться или предполагается к использованию.
б) Описание угроз, включающее все те угрозы активам, против которых требуется защита
средствами ОО или его среды. Заметим, что необходимо приводить не все угрозы, которые могут
встретиться в среде, а только те из них, которые влияют на безопасную эксплуатацию ОО.
в) Описание политики безопасности организации, идентифицирующее и, при
необходимости, объясняющее все положения политики безопасности организации или правила,
которым должен подчиняться объект оценки.
Цели безопасности
Изложение целей безопасности должно определять цели безопасности как для ОО, так и для
его среды. Цели безопасности должны учитывать все установленные аспекты среды безопасности.
Цели безопасности должны отражать изложенное намерение противостоять всем установленным
угрозам и быть подходящими для этого, а также охватывать все предположения безопасности и
установленную политику безопасности организации. Должны быть идентифицированы категории целей
безопасности, приведенные ниже. Если при этом противостояние угрозе или проведение политики

53
безопасности частично возлагается на ОО, а частично на его среду, соответствующая цель безопасности
должна повторяться в каждой категории.
Требования безопасности ИТ
В этой части ПЗ подробно определяются требования безопасности ИТ, которые должны
удовлетворяться ОО или его средой. Требования безопасности ОО должны быть изложены следующим
образом.
а) При изложении требований безопасности ОО должны быть определены
функциональные требования и требования доверия, которым должны удовлетворять ОО и
свидетельства поддержки его оценки для достижения целей безопасности ОО.
б) Необязательное изложение требований безопасности для среды ИТ должно определять
требования безопасности ИТ, которым должна отвечать среда ИТ этого ОО. Если безопасность ОО не
зависит от среды ИТ, то эта часть ЗБ может быть опущена.
в) А также общие условия в равной степени относятся к выражению функциональных
требований и требований доверия как для ОО, так и для его среды ИТ.
Обоснование
В этой части ПЗ представляется свидетельство, используемое при оценке ПЗ. Это
свидетельство поддерживает утверждения, что ПЗ является полной и взаимосвязанной совокупностью
требований, и что соответствующий ему ОО обеспечит эффективный набор контрмер безопасности ИТ
в определенной среде безопасности. Обоснование должно включать следующее.
а) Логическое обоснование целей безопасности, демонстрирующее, что изложенные цели
безопасности сопоставлены со всеми идентифицированными аспектами среды безопасности ОО и
пригодны для их охвата.
б) Логическое обоснование требований безопасности, демонстрирующее, что
совокупность требований безопасности (ОО и его среды) пригодна для достижения целей безопасности
и сопоставима с ними

36. Менеджмент риска информационной безопасности (ГОСТ 27005). Алгоритм

менеджмента риска в системе управления информационной безопасностью. Что
такое оценка, обработка, принятие, коммуникация, мониторинг и пересмотр
рисков?

Оценка риска.
Оценка риска часто проводится за две (или более) итерации. Сначала проводится
высокоуровневая оценка для идентификации потенциально высоких рисков, служащих
основанием для дальнейшей оценки. Следующая итерация может включать дальнейшее
углубленное рассмотрение потенциально высоких рисков. В тех случаях, когда
полученная информация недостаточна для оценки риска, проводится более детальный
анализ, возможно, по отдельным частям сферы действия, и, возможно, с использованием
иного метода.
Оценка риска основывается на понимании риска, полученном при анализе риска,
и используется при принятии решений о будущих действиях.
Обработка риска.
Эффективность обработки риска зависит от результатов оценки риска. Обработка
риска может не обеспечить сразу же приемлемый уровень остаточного риска. В этой
ситуации потребуется, если необходимо, еще одна итерация оценки риска с
измененными параметрами контекста (например, критериев оценки риска, принятия
риска и влияния), за которой последует очередная процедура обработки риска

54
 Входные данные. Наличие плана обработки риска и оценки остаточного риска
является необходимым условием решения руководства организации о принятии риска.

Действие. Должно быть принято решение о принятии рисков и установлена

ответственность за это решение, что должно быть официально зарегистрировано

коммуникация риска (risk communication): Обмен информацией о риске или

совместное использование этой информации лицом, принимающим решение, и другими
причастными сторонами.

Мониторинг и переоценка риска информационной безопасности

Должны подвергаться мониторингу и переоценке риски и их факторы (т. е.
ценность активов, влияние, угрозы, уязвимости, вероятность возникновения) с целью
определения любых изменений в контексте организации на ранней стадии, и должно
поддерживаться общее представление о всей картине риска.

37. Особенности задания по безопасности (ЗБ) (ГОСТ 15408). Структура ЗБ:

введение, описание ОО, среда безопасности ОО, цели безопасности, требования
безопасности ИТ, краткая спецификация ОО, утверждения о соответствии ПЗ,
обоснование.

Краткий обзор
ЗБ содержит требования безопасности ИТ для конкретного ОО и специфицирует функции
безопасности и меры доверия, предлагаемые объектом оценки для удовлетворения установленных
требований.
ЗБ для ОО является основой для соглашения между разработчиками, оценщиками и, где
необходимо, потребителями по характеристикам безопасности ОО и области применения оценки. Круг
лиц, заинтересованных в ЗБ, не ограничивается только ответственными за разработку ОО и его оценку,
но может включать также ответственных за управление, маркетинг, продажу, инсталляцию,
конфигурирование, функционирование и использование ОО.
55
 В ЗБ разрешено включать требования из одного или нескольких ПЗ или утверждать о
соответствии им.
Содержание ЗБ представлено на рисунке В.1, который рекомендуется использовать при
создании структурной схемы ЗБ.
Введение ЗБ
Введение ЗБ должно содержать информацию для управления документооборотом и обзорную
информацию:
а) идентификация ЗБ должна обеспечить маркировку и описательную информацию,
необходимые, чтобы контролировать и идентифицировать ЗБ и ОО, к которому оно относится;
б) аннотация ЗБ должна дать общую характеристику ЗБ в описательной форме. Она должна
быть достаточно подробной, чтобы потенциальный потребитель ОО мог решить, представляет ли ОО
для него интерес.;
в) утверждение о соответствии ОК должно изложить каждое поддающееся оценке утверждение
о соответствии ОО Общим критериям,

Рисунок В.1. – Содержание задания по безопасности

Описание ОО
Эта часть ЗБ должна содержать описание ОО, служащее цели лучшего понимания его
требований безопасности и дающее представление о типе продукта или системы. Область и
ограничения применения ОО должны быть описаны в общих терминах, как в отношении физической

56
(аппаратные и/или программные компоненты/модули), так и логической его организации (характерные
возможности ИТ и безопасности, предлагаемые объектом оценки).
Описание ОО предоставляет контекст для оценки. Информация, содержащаяся в описании ОО,
будет использована в процессе оценки для выявления противоречий. Если ОО представляет собой
продукт или систему, основной функцией которых является безопасность, то эту часть ЗБ разрешается
использовать для более подробного описания контекста возможного применения ОО.
Среда безопасности ОО
Изложение среды безопасности ОО должно содержать описание аспектов безопасности среды,
в которой предполагается использовать ОО, и ожидаемый способ его применения. Это изложение
должно включать следующее.
а) Описание предположений, содержащее аспекты безопасности среды, в которой ОО будет
использоваться или предполагается к использованию
б) Описание угроз, содержащее все те угрозы активам, против которых требуется защита
средствами ОО или его среды. Заметим, что необходимо приводить не все угрозы, которые могут
встретиться в среде, а только те из них, которые влияют на безопасную эксплуатацию ОО.
в) Описание политики безопасности организации, идентифицирующее и, при необходимости,
объясняющее все положения политики безопасности организации или правила, которым должен
подчиняться объект оценки. Для представления любого положения политики, позволяющего
использовать его для установления четких целей безопасности, могут понадобиться объяснения и
интерпретации.
Цели безопасности
Изложение целей безопасности должно определять цели безопасности как для ОО, так и для
его среды. Цели безопасности должны учитывать все установленные аспекты среды безопасности.
Цели безопасности должны отражать изложенное намерение противостоять всем установленным
угрозам и быть подходящими для этого, а также охватывать все предположения безопасности и
установленную политику безопасности организации. Должны быть идентифицированы категории целей
безопасности, приведенные ниже. Если при этом противостояние угрозе или проведение политики
безопасности частично возлагается на ОО, а частично на его среду, соответствующая цель безопасности
должна повторяться в каждой категории.
Требования безопасности ИТ
В этой части ЗБ подробно определяются требования безопасности ИТ, которые должны
удовлетворяться ОО или его средой. Требования безопасности ОО должны быть изложены следующим
образом.
а) При изложении требований безопасности ОО должны быть определены функциональные
требования и требования доверия, которым должны удовлетворять ОО и свидетельства поддержки его
оценки для достижения целей безопасности ОО. Требования безопасности ОО должны излагаться
следующим образом.
б) Необязательное изложение требований безопасности для среды ИТ должно определять
требования безопасности ИТ, которым должна отвечать среда ИТ этого ОО. Если безопасность ОО не
зависит от среды ИТ, то эта часть ЗБ может быть опущена.
Отметим, что, хотя требования безопасности среды, не относящиеся к ИТ, часто бывают
полезны на практике, не требуется, чтобы они являлись формальной частью ЗБ, поскольку они не
связаны непосредственно с реализацией ОО.
в) Перечисленные ниже общие условия в равной степени относятся к выражению
функциональных требований и требований доверия как для ОО, так и для его среды ИТ.
Краткая спецификация ОО
Краткая спецификация ОО должна определить отображение требований безопасности для ОО.
Эта спецификация должна предоставить описание функций безопасности и мер доверия к ОО, которые
отвечают требованиям безопасности ОО. Следует отметить, что информация о функциях безопасности,
являющаяся частью краткой спецификации ОО, в некоторых случаях может быть идентична
информации, предоставляемой для ОО частью требований семейства ADV_FSP.
Краткая спецификация ОО включает следующее.
а) Изложение функций безопасности ОО, которое должно охватывать все функции
безопасности ИТ и определять, каким образом эти функции удовлетворяют функциональным
требованиям безопасности ОО.

57
 б) Изложение мер доверия, которое должно специфицировать меры доверия к ОО, заявленные
для удовлетворения изложенных требований доверия.
Утверждения о соответствии ПЗ
В ЗБ могут быть сделаны утверждения, что ОО соответствует требованиям одного или,
возможно, нескольких ПЗ. Для любых сделанных утверждений о соответствии ПЗ, ЗБ должно включать
изложение утверждения о соответствии ПЗ, содержащее объяснение, строгое обоснование и любые
другие вспомогательные материалы, необходимые для того, чтобы иметь достаточные основания для
данного утверждения.
Содержание и представление в ЗБ целей и требований для ОО может зависеть от того, делаются
ли для ОО утверждения о соответствии ПЗ. Влияние на ЗБ утверждения о соответствии ПЗ может быть
сведено в итоге к одному из следующих вариантов.
а) Если утверждение о соответствии ПЗ не делается, то следует привести полное описание
целей и требований безопасности ОО, как определено в данном приложении.
б) Если в ЗБ утверждается только соответствие требованиям какого-либо ПЗ без
необходимости их дальнейшего уточнения, то ссылки на ПЗ достаточно, чтобы определить и строго
обосновать цели и требования безопасности ОО
в) Если в ЗБ утверждается о соответствии требованиям какого-либо ПЗ, и требования
этого ПЗ нуждаются в дальнейшем уточнении, то в ЗБ должно быть показано, что требования по
уточнению ПЗ удовлетворены. Такая ситуация обычно возникает, если ПЗ содержит незавершенные
операции.
г) Если в ЗБ утверждается соответствие требованиям какого-либо ПЗ, но последний
расширяется путем добавления дополнительных целей и требований, то в ЗБ должны быть
определены эти дополнения с учетом того, что ссылки на ПЗ может быть достаточно для определения
целей и требований безопасности ПЗ.
д) Случай, когда в ЗБ утверждается о частичном соответствии ПЗ, не приемлем для
оценки в рамках ОК.
Обоснование
В этой части ЗБ представляется свидетельство, используемое при оценке ЗБ. Это свидетельство
поддерживает утверждения, что ЗБ является полной и взаимосвязанной совокупностью требований, и
что соответствующий ему ОО обеспечит эффективный набор контрмер безопасности ИТ в
определенной среде безопасности, а краткая спецификация ОО согласуется с требованиями.
Обоснование также демонстрирует, что все утверждения о соответствии ПЗ справедливы. Обоснование
должно включать следующее.
а) Логическое обоснование целей безопасности, демонстрирующее, что изложенные цели
безопасности сопоставимы со всеми идентифицированными аспектами среды безопасности ОО и
пригодны для их охвата.
б) Логическое обоснование требований безопасности, демонстрирующее, что совокупность
требований безопасности (ОО и его среды) пригодна для достижения целей безопасности и
сопоставлена с ними.
в) Логическое обоснование краткой спецификации ОО, показывающее, что функции
безопасности и меры доверия к ОО пригодны, чтобы отвечать требованиям безопасности ОО.
г) Логическое обоснование утверждений о соответствии ПЗ, объясняющее любые различия
между целями и требованиями безопасности ЗБ и любого ПЗ, соответствие которому утверждается

38. Основные мероприятия по аудиту информационной безопасности организаций и

систем. Международные правовые аспекты, стандарты и руководства по основам
аудита информационной безопасности.

АУДИТ КРАТКО
Аудит представляет собой независимую экспертизу отдельных областей функционирования
организации, проводимую по инициативе ее руководства или акционеров, либо в соответствии с планом
проведения внутреннего аудита.
Основными целями проведения аудита безопасности являются:
 анализ рисков, связанных с возможностью осуществления угроз безопасности в
отношении ресурсов ИС;
58
  оценка текущего уровня защищенности ИС;
 локализация узких мест в системе защиты ИС;
 оценка соответствия ИС существующим стандартам в области информационной
безопасности;
 выработка рекомендаций по внедрению новых и повышению эффективности
существующих механизмов безопасности ИС.
Работы по аудиту безопасности ИС включают в себя ряд последовательных этапов:
 Инициирование обследования
 Сбор информации
 Анализ полученных данных
 Выработка рекомендаций
 Подготовка отчета по результатам обследования

СТАНДАРТЫ КРАТКО
Результатом проведения аудита, в последнее время, все чаще становится сертификат,
удостоверяющих соответствие обследуемой ИС требованиям признанного международного стандарта.
В настоящей статье рассмотрено несколько стандартов и программ сертификации, имеющих
практическое значение.
Международные стандарты ISO17799 и ISO15408 служат основой для проведения любых работ в
области информационной безопасности, в том числе и аудита. ISO17799 сосредоточен на вопросах
организации и управления безопасностью, в то время как ISO15408 определяет детальные требования,
предъявляемые к программно-техническим механизмам защиты информации.
Спецификация SysTrust в настоящее время достаточно широко используется аудиторскими
компаниями, традиционно выполняющими финансовый аудит для своих клиентов и предлагающих
услугу ИТ аудита в качестве дополнения к финансовому аудиту.
Немецкий стандарт «BSI\IT Baseline Protection Manual» является наиболее содержательным
руководством по обеспечению безопасности ИТ и представляет несомненную практическую ценность
для всех специалистов, занимающихся вопросами информационной безопасности.
Практические стандарты и руководства по обеспечению информационной безопасности,
разрабатываемые в рамках проекта SCORE, ориентированы на технических специалистов и
являются в техническом плане наиболее совершенными.
Программа сертификации Интернет сайтов по требованиям информационной безопасности и
соответствующая спецификация «SANS/GIAC Site Certification», совсем недавно предложенная
институтом SANS, безусловно, заслуживает внимания в связи с неизменно возрастающей
актуальностью вопросов защиты ИС организаций от атак со стороны сети Интернет и увеличением
доли соответствующих работ при проведении аудита безопасности.

МОЖНО ПОЧИТАТЬ ДЛЯ ОТВЕТА

Аудит представляет собой независимую экспертизу отдельных областей функционирования
организации. Различают внешний и внутренний аудит. Внешний аудит – это, как правило, разовое
мероприятие, проводимое по инициативе руководства организации или акционеров. Внутренний аудит
представляет собой непрерывную деятельность, которая осуществляется на основании «Положения о
внутреннем аудите» и в соответствии с планом, подготовка которого осуществляется подразделением
внутреннего аудита и утверждается руководством организации.
Целями проведения аудита безопасности являются:
 анализ рисков, связанных с возможностью осуществления угроз безопасности в
отношении ресурсов ИС
 оценка текущего уровня защищенности ИС;
 локализация узких мест в системе защиты ИС;
 оценка соответствия ИС существующим стандартам в области информационной
безопасности;
 выработка рекомендаций по внедрению новых и повышению эффективности
существующих механизмов безопасности ИС.
Этапы работ по проведению аудита безопасности информационных систем

59
 Работы по аудиту безопасности ИС включают в себя ряд последовательных этапов, которые в
целом соответствуют этапам проведения комплексного ИТ аудита АС, который включает в себя
следующее:
 Инициирование процедуры аудита
 Сбор информации аудита
 Анализ данных аудита
 Выработка рекомендаций
 Подготовка аудиторского отчета
Инициирование процедуры аудита
Аудит проводится не по инициативе аудитора, а по инициативе руководства компании, которое
в данном вопросе является основной заинтересованной стороной. Поддержка руководства компании
является необходимым условием для проведения аудита.
Аудит представляет собой комплекс мероприятий, в которых помимо самого аудитора,
оказываются задействованными представители большинства структурных подразделений компании. На
этапе инициирования процедуры аудита должны быть определены границы проведения обследования.
Одни информационные подсистемы компании не являются достаточно критичными и их можно
исключить из границ проведения обследования. Другие подсистемы могут оказаться недоступными для
аудита из-за соображений конфиденциальности.

Сбор информации аудита

Этап сбора информации аудита, является наиболее сложным и длительным. Это связано с
отсутствием необходимой документации на информационную систему и с необходимостью плотного
взаимодействия аудитора со многими должностными лицами организации.
Компетентные выводы относительно положения дел в компании с информационной
безопасностью могут быть сделаны аудитором только при условии наличия всех необходимых
исходных данных для анализа. Получение информации об организации, функционировании и текущем
состоянии ИС осуществляется аудитором в ходе специально организованных интервью с
ответственными лицами компании, путем изучения технической и организационно-распорядительной
документации, а также исследования ИС с использованием специализированного программного
инструментария.
Анализ данных аудита
Используемые аудиторами методы анализа данных определяются выбранными подходами к
проведению аудита, которые могут существенно различаться.
Первый подход, самый сложный, базируется на анализе рисков.
Второй подход, самый практичный, опирается на использование стандартов информационной
безопасности.
Третий подход, наиболее эффективный, предполагает комбинирование первых двух.
Выработка рекомендаций
Рекомендации, выдаваемые аудитором по результатам анализа состояния ИС, определяются
используемым подходом, особенностями обследуемой ИС, состоянием дел с информационной
безопасностью и степенью детализации, используемой при проведении аудита.
Подготовка отчетных документов
Аудиторский отчет является основным результатом проведения аудита. Его качество
характеризует качество работы аудитора. Структура отчета может существенно различаться в
зависимости от характера и целей проводимого аудита. Однако определенные разделы должны
обязательно присутствовать в аудиторском отчете. Он должен, по крайней мере, содержать описание
целей проведения аудита, характеристику обследуемой ИС, указание границ проведения аудита и
используемых методов, результаты анализа данных аудита, выводы, обобщающие эти результаты и
содержащие оценку уровня защищенности АС или соответствие ее требованиям стандартов, и, конечно,
рекомендации аудитора по устранению существующих недостатков и совершенствованию системы
защиты.

Стандарты, используемые при проведении аудита безопасности информационных систем

Результатом проведения аудита, в последнее время, все чаще становится сертификат,
удостоверяющих соответствие обследуемой ИС требованиям признанного международного стандарта.

60
Наличие такого сертификата позволяет организации получать конкурентные преимущества, связанные с
большим доверием со стороны клиентов и партнеров.
Значение международных стандартов ISO17799 и ISO15408 трудно переоценить. Эти
стандарты служат основой для проведения любых работ в области информационной безопасности, в
том числе и аудита. ISO17799 сосредоточен на вопросах организации и управления безопасностью, в то
время как ISO15408 определяет детальные требования, предъявляемые к программно-техническим
механизмам защиты информации.
ISO 17799: Code of Practice for Information Security Management
Наиболее полно критерии для оценки механизмов безопасности организационного уровня
представлены в международном стандарте ISO 17799: Code of Practice for Information Security
Management (Практические правила управления информационной безопасностью), принятом в 2000
году. ISO 17799 был разработан на основе британского стандарта BS 7799.
ISO 17799 может использоваться в качестве критериев для оценки механизмов безопасности
организационного уровня, включая административные, процедурные и физические меры защиты.
ISO 15408: Common Criteria for Information Technology Security Evaluation
Наиболее полно критерии для оценки механизмов безопасности программно-технического
уровня представлены в международном стандарте ISO 15408: Common Criteria for Information
Technology Security Evaluation (Общие критерии оценки безопасности информационных технологий),
принятом в 1999 году.
Общие критерии оценки безопасности информационных технологий (далее «Общие критерии»)
определяют функциональные требования безопасности (security functional requirements) и требования к
адекватности реализации функций безопасности (security assurance requirements).
При проведении работ по аудиту безопасности, данные требования могут использоваться в качестве
руководства и критериев для анализа уязвимостей ИС.
SysTrust
По существу, аудит в области информационных технологий, хотя и не имеет никакого
отношения к финансовому аудиту, часто является дополнением к нему в качестве коммерческой услуги,
предлагаемой аудиторскими фирмами своим клиентам. Отвечая потребностям бизнеса, Американским
Институтом Сертифицированных Публичных Бухгалтеров (American Institute of Certified Public
Accountants (AICPA)) и Канадским Институтом Общественных Бухгалтеров (Canadian Institute of
Chartered Accountants (CICA)) разработали
стандарт SysTrust для проведения ИТ аудита, который является дополнением к финансовому
аудиту. SysTrust позволяет финансовым аудиторам расширить область своей деятельности, путем
использования простого и понятного набора требований для оценки надежности и безопасности ИС.
BSI\IT Baseline Protection Manual
Немецкий стандарт "Руководство по обеспечению безопасности ИТ базового уровня" (IT
Baseline Protection Manual) разрабатывается Агенством Информационной Безопасность Германии (BSI -
Bundesamt für Sicherheit in der Informationstechnik (German Information Security Agency).
Этот документ является, пожалуй, самым содержательным руководством по информационной
безопасности и по многим параметрам превосходит все остальные стандарты. Он имеется в свободном
доступе в сети Интернет. В нем содержаться подробные руководства по обеспечению информационной
безопасности применительно к различным аспектам функционирования ИС и различным областям ИТ.
Практические стандарты SCORE и программа сертификации SANS/GIAC Site
Certification
SCORE (Security Consensus Operational Readiness Evaluation) является совместным проектом
института SANS и Центра безопасности Интернет (Center for Internet Security(CIS)). Профессионалы-
практики в области информационной безопасности из различных организаций объединились в рамках
проекта SCORE с целью разработки базового (минимально необходимого) набора практических
стандартов и руководств по обеспечению безопасности для различных операционных платформ.

61
39. Особенности функциональных требований безопасности ИТ-продуктов (ГОСТ
15408). Представление функциональных требований. Структура класса. Структура
семейства (ранжирование, управление, аудит). Структура компонента
(подчиненность по иерархии, зависимости - прямые, косвенные, выбираемые,
операции - итерация, назначение, выбор, уточнение). Функциональный элемент.

Функциональные компоненты безопасности

Этот раздел определяет содержание и форму представления функциональных требований настоящего
стандарта и предоставляет руководство по организации требований для новых компонентов,
включаемых в ЗБ. Функциональные требования объединены в классы, семейства и компоненты.
Структура класса
Рисунок 2.1 иллюстрирует структуру функционального класса в виде диаграммы. Каждый
функциональный класс содержит имя класса, представление класса и одно или несколько

Функциональный
класс
Имя класса

Представление класса

Функциональные
функциональных семейств.
Рисунок 2.1 – Структура функционального класса
Имя класса: Имя класса содержит информацию, необходимую для идентификации функционального
класса и отнесения его к определенной категории. Каждый функциональный класс имеет
уникальное имя. Информация о категории состоит из краткого имени, состоящего из трех букв
латинского алфавита. Краткое имя класса используется при задании кратких имен семейств этого
класса.
Представление класса: Представление класса обобщает участие семейств класса в достижении целей
безопасности. Определение функциональных классов не отражает никакую формальную
таксономию в спецификации требований. Представление класса содержит рисунок, описывающий
все семейства этого класса и иерархию компонентов в каждом семействе, как объясняется в
подразделе 2.2.
Структура семейства
Рисунок 2.2 иллюстрирует структуру функционального семейства в виде диаграммы.
Функциональное
семейство
Имя семейства

Характеристика

Ранжирование

Управление

Аудит

Компоненты
Рисунок 2.2 – Структура функционального семейства
Имя семейства: Имя семейства содержит описательную информацию, необходимую, чтобы
идентифицировать и категорировать функциональное семейство. Каждое функциональное
семейство имеет уникальное имя. Информация о категории состоит из краткого имени,
62
 включающего семь символов. Первые три символа идентичны краткому имени класса, далее
следуют символ подчеркивания и краткое имя семейства в виде XXX_YYY. Уникальная краткая
форма имени семейства предоставляет основное имя ссылки для компонентов.
Характеристика семейства: Характеристика семейства– это описание функционального семейства, в
котором излагаются его цели безопасности и общее описание функциональных требований. Более
детально они описаны ниже:
а) цели безопасности семейства характеризуют задачу безопасности, которая может быть решена с
помощью ОО, включающего компонент из этого семейства;
б) описание функциональных требований обобщает все требования, которые включены в компонент
(компоненты). Описание ориентировано на разработчиков ПЗ, ЗБ и функциональных пакетов,
которые хотели бы определить, соответствует ли семейство их конкретным требованиям.
Ранжирование компонентов: Функциональные семейства содержат один или несколько компонентов,
каждый из которых может быть выбран для включения в ПЗ, ЗБ и функциональные пакеты. Цель
этого раздела состоит в том, чтобы предоставить пользователям информацию для выбора
подходящего функционального компонента, как только семейство идентифицировано как
необходимая или полезная часть их требований безопасности.
В этом пункте описания функционального семейства описаны имеющиеся компоненты и их логическое
обоснование. Детализация компонентов производится в описании каждого компонента. Связи
между компонентами в пределах функционального семейства могут быть иерархическими и
неиерархическими. Компонент иерархичен (т.е. выше по иерархии) по отношению к другому
компоненту, если он предлагает большую безопасность. Описания семейств содержат графическое
представление иерархии компонентов, объясняемое в подразделе 2.2.
Управление: Требования управления содержат информацию для разработчиков ПЗ/ЗБ, учитываемую
при определении действий по управлению для данного компонента. Требования управления
детализированы в компонентах класса "Управление безопасностью" (FMT). Разработчик ПЗ/ЗБ
может выбрать какие-либо из имеющихся требований управления или включить новые, не
указанные в настоящем стандарте. В последнем случае следует представить необходимую
информацию.
Аудит: Требования аудита содержат события, потенциально подвергаемые аудиту, для их отбора
разработчиками ПЗ/ЗБ при условии включения требований из класса FAU "Аудит безопасности" в
ПЗ/ЗБ. Эти требования включают относящиеся к безопасности события применительно к
различным уровням детализации, поддерживаемым компонентами семейства FAU_GEN
"Генерация данных аудита безопасности". Например, запись аудита какого-либо механизма
безопасности может включать на разных уровнях детализации действия, которые раскрываются в
следующих терминах.
- "Минимальный": успешное использование механизма безопасности.
- "Базовый": любое использование механизма безопасности, а также информация о текущих
значениях атрибутов безопасности.
- "Детализированный": любые изменения конфигурации механизма безопасности, включая
параметры конфигурации до и после изменения.
Следует учесть, что категорирование событий, потенциально подвергаемых аудиту, всегда иерархично.
Например, если выбрана базовая генерация данных аудита, то все события, идентифицированные
как потенциально подвергаемые аудиту и поэтому входящие как в минимальную, так и в базовую
запись, следует включить в ПЗ/ЗБ с помощью соответствующей операции назначения, за
исключением того случая, когда событие более высокого уровня имеет более высокий уровень
детализации, чем событие более низкого уровня, и может просто заменить его. Когда желательна
детализированная генерация данных аудита, все идентифицированные события, потенциально
подвергаемые аудиту (для минимального, базового и детализированного уровня), следует включить
в ПЗ/ЗБ.
Правила управления аудитом более подробно объяснены в классе FAU.
Структура компонента
Рисунок 2.3 иллюстрирует структуру функционального компонента
Рисунок 2.3 – Структура функционального компонента
Компонент

Идентификация
63
Функциональные
Идентификация компонента: Идентификация компонента включает описательную информацию,
необходимую для идентификации, категорирования, записи и реализации перекрестных ссылок
компонента. Для каждого функционального компонента представляется следующее.
Уникальное имя. Имя отражает предназначение компонента.
Краткое имя. Уникальная краткая форма имени функционального компонента. Это краткое имя служит
как основное имя ссылки для категорирования, записи и реализации перекрестных ссылок
компонента. Оно отражает класс и семейство, которым компонент принадлежит, а также номер
компонента в семействе.
Список иерархических связей. Список других компонентов, для которых этот компонент иерархичен, и
вместо которых он может использоваться при удовлетворении зависимостей от перечисленных
компонентов.
Функциональные элементы: Каждый компонент включает набор элементов. Каждый элемент
определяется отдельно и является самодостаточным.
Функциональный элемент – это функциональное требование безопасности, дальнейшее разделение
которого не меняет значимо результат оценки. Он является наименьшим функциональным
требованием безопасности, идентифицируемым и признаваемым в настоящем стандарте.
При формировании ПЗ, ЗБ и/или пакетов не разрешается выбирать только часть элементов компонента.
Для включения в ПЗ, ЗБ или пакет необходимо выбирать всю совокупность элементов компонента.
Вводится уникальная краткая форма имени функционального элемента. Например, имя FDP_IFF.4.2
читается следующим образом: F – функциональное требование, DP – класс "Защита данных
пользователя", _IFF – семейство "Функции управления информационными потоками", .4 – 4-ый
компонент "Частичное устранение неразрешенных информационных потоков", .2 – 2-ой элемент
компонента.
Зависимости: Зависимости среди функциональных компонентов возникают, когда компонент не
самодостаточен и нуждается либо в функциональных возможностях другого компонента, либо во
взаимодействии с ним для поддержки собственного выполнения.
Каждый функциональный компонент содержит полный список зависимостей от других
функциональных компонентов и компонентов доверия. Некоторые компоненты могут иметь список
"Нет зависимостей". Компоненты из списка, могут, в свою очередь, иметь зависимости от других
компонентов. Список, приведенный в компоненте, показывает прямые зависимости, т.е. содержит
ссылки только на те функциональные компоненты, которые заведомо необходимы для обеспечения
выполнения рассматриваемого компонента. Косвенные зависимости, определяемые собственными
зависимостями компонентов из списка, прослежены в приложении А к этой части стандарта.
Отметим, что в некоторых случаях зависимость выбирается из нескольких предлагаемых
функциональных компонентов, причем каждый из них достаточен для удовлетворения зависимости
(см., например, FDP_UIT.1).
Список зависимостей идентифицирует минимум функциональных компонентов или компонентов
доверия, необходимых для удовлетворения требований безопасности, ассоциированных с данным
компонентом. Компоненты, которые иерархичны по отношению к компоненту из списка, также
могут быть использованы для удовлетворения зависимости.
Зависимости между компонентами, указанные в этой части стандарта, обязательны. Их необходимо
удовлетворить в ПЗ/ЗБ. В некоторых особых ситуациях эти зависимости удовлетворить
невозможно. Тогда разработчик ПЗ/ЗБ, обязательно обосновав, почему данная зависимость
неприменима, может не включать соответствующий компонент в пакет, ПЗ или ЗБ.
Разрешенные операции с функциональными компонентами
При определении требований в ПЗ, ЗБ или функциональном пакете функциональные компоненты могут
либо использоваться полностью в соответствии с разделами 3-13 этой части стандарта, либо быть
дополнительно конкретизированы для достижения специфической цели безопасности. Однако
отбор и конкретизация этих функциональных компонентов усложнены тем обстоятельством, что
необходимо учитывать имеющиеся зависимости данного компонента. Поэтому такая конкретизация
строго ограничена принятым набором операций.
К каждому функциональному компоненту могут быть применены разрешенные операции. Не все
операции разрешены на всех функциональных компонентах.
Разрешенные операции выбираются из следующего набора:
– итерация: позволяет несколько раз использовать компонент с различным выполнением операций;
– назначение: позволяет специфицировать заданный параметр;
64
– выбор: позволяет специфицировать один или несколько элементов из списка;
– уточнение: позволяет добавить детали.
Итерация: Там, где необходимо охватить различные аспекты одного и того же требования (например,
идентифицировать несколько типов пользователей), разрешается повторное использование одного
и того же компонента из этой части стандарта, позволяющее охватить каждый аспект.
Назначение: Некоторые элементы функциональных компонентов содержат параметры или
переменные, которые дают возможность разработчику ПЗ/ЗБ специфицировать политику или
совокупность величин для включения в ПЗ/ЗБ, чтобы выполнить специфическую цель
безопасности. Эти элементы однозначно идентифицируют каждый такой параметр и ограничения
на значения, которые может принимать этот параметр.
Любой аспект элемента, допустимые значения которого могут быть однозначно описаны или
перечислены, может быть представлен параметром. Параметр может быть атрибутом или правилом,
которое сводит требование к определенному значению или диапазону значений. Например, элемент
функционального компонента, направленный на достижение определенной цели безопасности,
может установить, что некоторую операцию следует выполнять неоднократно. В этом случае
назначение установит число возможных повторений (или диапазон для него), которое будет
использоваться для данного параметра.
Выбор: Это – операция выбора одного или нескольких элементов из списка, позволяющая ограничить
область применения элемента компонента.
Уточнение: Для всех элементов функционального компонента разработчику ПЗ/ЗБ разрешается
ограничить множество допустимых реализаций путем определения дополнительных деталей для
достижения целей безопасности. Уточнение элемента заключается в добавлении этих
специфических деталей.
Например, если для конкретного ОО требуется объяснение смысла терминов "субъект" и "объект" в
рамках ЗБ, то эти термины подвергаются операции уточнения.
Подобно другим операциям, уточнение не налагает совершенно новые требования. Исходя из целей
безопасности, уточнение предполагает проработку деталей, интерпретацию или развитие
требований, правил, значений или условий. Уточнение должно лишь ограничивать совокупность
возможных функций или механизмов для реализации требования, но никогда не расширять ее.
Уточнение не позволяет создать новые требования и поэтому не увеличивает список зависимостей,
связанных с компонентом. Разработчику ПЗ/ЗБ необходимо быть внимательным, чтобы
существующие зависимости прочих требований от уточняемого требования были по-прежнему
удовлетворены.

40. Процессный подход к обеспечению информационной безопасности (ГОСТ

27001). Особенности перехода от линейной модели управления качеством процессов
и систем к замкнутой циклической модели менеджмента качества.

«Процессный подход»

Последнее десятилетие все большее распространение получил так назы-

65
66
67
68
69
41. Парадигма функциональных требований (ГОСТ 15408). Виды объектов оценки
и политик безопасности. Функции безопасности: стойкость, область действия,
интерфейс, типы ПФБ. ФБО единого, локального и распределенного ОО. Виды
пользователей. Роли. Ресурсы. Сущности: активные и пассивные. Атрибуты
безопасности. Данные ОО: пользователя и ФБО. Аутентификационные данные и
секреты.

Совокупность всех функций безопасности ОО, которые направлены на

осуществление ПБО, определяется как функции безопасности объекта оценки (ФБО).
ФБО объединяют функциональные возможности всех аппаратных, программных и
программно-аппаратных средств ОО, на которые как непосредственно, так и косвенно
возложено осуществление безопасности.
Монитор обращений – это концепция абстрактной машины, которая
осуществляет политику управления доступом ОО. Механизм проверки правомочности
обращений – реализация концепции монитора обращений, обладающая следующими
свойствами: защищенностью от проникновения; постоянной готовностью; простотой,
достаточной для проведения исчерпывающего анализа и тестирования. ФБО могут

70
состоять из механизма проверки правомочности обращений и/или других функций
безопасности, необходимых для эксплуатации ОО.
ОО может быть единым продуктом, включающим аппаратные, программно-
аппаратные и программные средства.
Напротив, ОО может быть распределенным продуктом, который состоит из
нескольких разделенных частей. Каждая из этих частей ОО обеспечивает выполнение
конкретного сервиса для ОО и связана с другими частями ОО через внутренний канал
связи. Этот канал может быть всего лишь шиной процессора, а может являться сетью,
внутренней для ОО.
Если ОО состоит из нескольких частей, то каждая его часть может иметь
собственное подмножество ФБО, которое обменивается данными ФБО и пользователей
через внутренние каналы связи с другими подмножествами ФБО. Это взаимодействие
названо внутренней передачей ОО. В этом случае отдельные части ФБО совместно
формируют объединенные ФБО, которые осуществляют ПБО для этого ОО.
Интерфейсы ОО могут быть локализованы в конкретном ОО или же могут
допускать взаимодействие с другими продуктами ИТ по внешним каналам связи.
Внешние взаимодействия с другими продуктами ИТ могут принимать две формы.
а) Политика безопасности "удаленного доверенного продукта ИТ" и ПБО
рассматриваемого ОО скоординированы и оценены в административном порядке. Обмен
информацией в этом случае назван передачей между ФБО, поскольку он
осуществляется между ФБО заведомо доверенных продуктов.
б) Удаленный продукт ИТ, обозначенный на рисунке 1.2 как "недоверенный
продукт ИТ", может не быть оценен, вследствие чего его политика безопасности
неизвестна. Обмен информацией в этом случае назван передачей за пределы области
действия ФБО, так как этот удаленный продукт ИТ не имеет ФБО (или характеристики
его политики безопасности неизвестны).
Совокупность взаимодействий, которые могут происходить с ОО или в пределах
ОО и подчинены правилам ПБО, относится к области действия функций безопасности
(ОДФ). ОДФ включает определенную совокупность взаимодействий между субъектами,
объектами и операциями в пределах ОО, но не предполагает охвата всех ресурсов ОО.
Совокупность интерфейсов, как интерактивных (человеко-машинный интерфейс),
так и программных (интерфейс программных приложений), через которые могут быть
получены доступ к ресурсам при посредничестве ФБО или информация от ФБО,
называется интерфейсом ФБО (ИФБО). ИФБО определяет границы возможностей
функций ОО, которые предоставлены для осуществления ПБО.
Пользователи не включаются в состав ОО; поэтому они находятся вне ОДФ.
Однако пользователи взаимодействуют с ОО через ИФБО при запросе услуг, которые
будут выполняться ОО. Существует два типа пользователей, учитываемых в
функциональных требованиях безопасности этой части стандарта: люди-пользователи и
внешние объекты ИТ. Среди людей-пользователей далее различаются локальные люди-
пользователи, взаимодействующие непосредственно с ОО через устройства ОО (такие,
как рабочие станции), и удаленные люди-пользователи, взаимодействующие с ОО через
другой продукт ИТ.
Период взаимодействия между пользователем и ФБО называется сеансом
пользователя. Открытие сеансов пользователей может контролироваться на основе ряда
условий, таких как аутентификация пользователя, время суток, метод доступа к ОО,
число параллельных сеансов, разрешенных пользователю, и т.д.

71
 В этой части стандарта используется термин уполномоченный, чтобы обозначить
пользователя, который обладает правами и/или привилегиями, необходимыми для
выполнения операций. Поэтому термин уполномоченный пользователь указывает на то,
что пользователю разрешается выполнять данную операцию в соответствии с ПБО.
Для выражения требований разделения административных обязанностей
соответствующие функциональные компоненты безопасности (из семейства FMT_SMR),
приведенные в этой части стандарта, явно устанавливают обязательность
административных ролей. Роль – это заранее определенная совокупность правил,
устанавливающих допустимые взаимодействия между пользователем и ОО. ОО может
поддерживать определение произвольного числа ролей. Например, роли, связанные с
операциями безопасности ОО, могут включать роли "Администратор аудита" и
"Администратор учета пользователей".
ОО содержит ресурсы, которые могут использоваться для обработки и хранения
информации. Основной целью ФБО является полное и правильное осуществление ПБО
для ресурсов и информации, которыми управляет ОО.
Ресурсы ОО могут структурироваться и использоваться различными способами.
Тем не менее, в этой части стандарта проводится специальное разграничение,
позволяющее специфицировать желательные свойства безопасности. Все сущности,
которые могут быть созданы на основе ресурсов, характеризуются одним из двух
способов. Сущности могут быть активными, т.е. являться причиной действий, которые
происходят в пределах ОО, и инициировать операции, выполняемые с информацией.
Напротив, сущности могут быть пассивными, т.е. являться источником или местом
хранения информации.
Активные сущности названы субъектами. В пределах ОО могут существовать
несколько типов субъектов:
в) действующие от имени уполномоченного пользователя и подчиненные всем
правилам ПБО (например, процессы UNIX);
г) действующие как особый функциональный процесс, который может, в свою
очередь, действовать от имени многих пользователей (например, функции, которые
характерны для архитектуры клиент/сервер);
д) действующие как часть собственно ОО (например, доверенные процессы).
В этой части стандарта рассматривается осуществление ПБО для всех типов
субъектов, перечисленных выше.
Пассивные сущности (т.е. контейнеры информации) названы объектами в
функциональных требованиях безопасности этой части стандарта. Объекты являются
предметом операций, которые могут выполняться субъектами. В случае, когда субъект
(активная сущность) сам является предметом операции (например, при установлении
связи между процессами), над субъектом могут производиться действия, как над
объектом.
Объекты могут содержать информацию. Это понятие требуется, чтобы
специфицировать политики управления информационными потоками в соответствии с
классом FDP.
Пользователи, субъекты, информация и объекты обладают определенными
атрибутами, которые содержат информацию, позволяющую ОО функционировать
правильно. Некоторые атрибуты, такие как имена файлов, могут предназначаться только
для информирования (т.е. для повышения дружественности ОО пользователю), в то
время как другие, типа различных параметров управления доступом, могут существовать
исключительно для осуществления ПБО. Эти последние обобщенно названы
72
"атрибутами безопасности". В дальнейшем слово "атрибут" используется в этой
части стандарта как сокращение для словосочетания "атрибут безопасности", если иное
не оговорено. Вместе с тем, независимо от предназначения информации атрибута могут
потребоваться средства управления этим атрибутом в соответствии с ПБО.
Данные в ОО подразделяются на данные пользователя и данные ФБО. На рисунке
1.3 показана их взаимосвязь. Данные пользователя – это информация, содержащаяся в
ресурсах ОО, которая может использоваться пользователями в соответствии с ПБО и не
предназначена специально для ФБО. Например, содержание сообщения электронной
почты является данными пользователя. Данные ФБО – это информация, используемая
ФБО при осуществлении ПБО. Допустимо воздействие пользователей на данные ФБО,
если это предусмотрено ПБО. Примерами данных ФБО являются атрибуты
безопасности, аутентификационные данные, списки управления доступом.
Имеются отдельные ПФБ, такие как ПФБ управления доступом и ПФБ
управления информационными потоками, которые применяются при защите данных.
Действия механизмов, реализующих ПФБ управления доступом, основаны на атрибутах
субъектов, объектов и операций в пределах области действия. Эти атрибуты
используются в совокупности правил, управляющих операциями, которые субъектам
разрешено выполнять на объектах.
Функционирование механизмов, реализующих ПФБ управления
информационными потоками, основано на атрибутах субъектов и информации в
пределах области действия и совокупности правил, по которым выполняются операции
субъектов на информации. Атрибуты информации, которые могут быть ассоциированы с
атрибутами места хранения (или не ассоциированы с ними, как в случае многоуровневой
базы данных) остаются с информацией при ее перемещении.
Два специфических типа данных ФБО, рассматриваемых в этой части стандарта,
могут, хотя и необязательно, совпадать. Это аутентификационные данные и секреты.
Аутентификационные данные используются, чтобы верифицировать заявленный
идентификатор пользователя, обращающегося к ОО за услугами. Самая
распространенная форма аутентификационных данных – пароль, который необходимо
хранить в секрете, чтобы механизм безопасности был эффективен. Однако не все формы
аутентификационных данных необходимо хранить в секрете. Биометрические
опознавательные устройства (такие как считыватели отпечатка пальца или сканеры
сетчатки глаза) полагаются не на предположение, что аутентификационные данные
хранятся в секрете, а на то, что данные являются неотъемлемым свойством пользователя,
которое невозможно подделать.
Термин "секрет", используемый в функциональных требованиях этой части
стандарта по отношению к аутентификационным данным, применим и к другим типам
данных, которые необходимо хранить в тайне при осуществлении определенной ПФБ.
Например, стойкость механизма доверенного канала, в котором применена криптография
для сохранения конфиденциальности передаваемой через канал информации, зависит от
надежности способа сохранения в секрете криптографических ключей от
несанкционированного раскрытия.
Следовательно, некоторые, но не все аутентификационные данные необходимо
хранить в секрете и некоторые, но не все секреты используются как
аутентификационные данные. Рисунок 1.4 показывает эту взаимосвязь секретов и
аутентификационных данных. На этом рисунке указаны типы данных, которые часто
относятся к аутентификационным данным и секретам.

73
42. Оценка информационной безопасности предприятия. Основные аспекты
стандартизации систем и процессов управления информационной безопасностью
(ГОСТ 27001, СоbiT, NIST).

Организатор (заказчик) оценки ИБ формирует цель оценки (совершенствование

объекта оценки, определение соответствия объекта оценки установленным критериям и
т.д.) и определяет критерий оценки, объект и область оценки. Под организатором
оценки понимается лицо или организация, являющиеся внутренними или внешними по
отношению к оцениваемому объекту оценки, которые организуют проведения оценки и
предоставляют финансовые и другие ресурсы, необходимые для ее проведения.
Организатор должен обеспечить доступ группы оценки (руководитель группы оценки,
оценщик) к активам объекта оценки для изучения, к персоналу для проведения опросов,
к инфраструктуре, необходимой во время оценивания. Хотя руководство объекта оценки
напрямую не имеет никаких конкретных обязанностей по проведению оценивания,
осознание важности оценки имеет очень большое значение. Это особенно актуально в
том случае, когда организатор оценки не является членом руководства объекта оценки.
По завершении оценки организатор передает отчетные документы по оценке
заинтересованным сторонам для использования их в соответствии с заявленной целью
оценки.
Аналитик оценки ИБ выбирает способ оценки ИБ, модель оценки и определяет
методическое и информационное обеспечение оценки, т.е. методики, данные для оценки.
Аналитик оценки анализирует результаты оценки и формирует отчет и рекомендации по
результатам оценки ИБ.
Руководитель группы оценки и оценщик измеряют и оценивают свидетельства
оценки, предоставленные владельцами активов, и формируют результаты оценки.
Руководитель группы должен распределить ответственность между членами группы за
оценивание конкретных процессов, подразделений, областей или видов деятельности
объекта оценки. Такое распределение должно учитывать потребность в независимости,
компетентности специалистов по оценке и результативном использовании ресурсов.
Мероприятия по измерению и оцениванию выполняются исключительно
руководителем группы оценки и оценщиком, входящими в группу оценки. Другой
персонал (представитель объекта оценки, технический эксперт) может участвовать в
работе группы оценки для обеспечения специализированных знаний или консультаций.
Они могут обсуждать с оценщиком формулировки суждений, но не будут нести
ответственность за окончательную оценку.
На рисунке 4 показаны роли процесса оценки ИБ и основные функции,
выполняемые ролями.

74
Рисунок 4 — Роли процесса оценки ИБ и их функции
Важным аспектом при определении контекста оценки является вид оценки:
независимая или самооценка. В зависимости от вида оценки различается отношение
ролей процесса оценки и объекта оценки.
Независимая оценка достигается путем проведения оценки группой оценки,
члены которой независимы от объекта оценки. Организатор оценки может относиться к
той же организации, к которой относится объект оценки, но не обязательно к
оцениваемому объекту оценки. Степень независимости может варьироваться в
соответствии с целью и областью оценки. В случае внешнего организатора оценки
предполагается наличие взаимного соглашения между организатором оценки и
организацией, к которой относится объект оценки. Представитель объекта оценки
принимает участие в формировании свидетельств оценки, обеспечивает взаимодействие
группы оценки с владельцами активов. Их участие в проведении оценки дает
возможность определить и учесть особенности объекта оценки, обеспечить
достоверность результатов оценки.
Самооценка выполняется организацией с целью оценки собственной СОИБ.
Организатор самооценки обычно входит в состав объекта оценки, как и члены группы
оценки.

75
 Область оценки может включать, например, один или несколько процессов
объекта оценки, например, организатор может сосредоточить внимание на одном или
нескольких критических процессах и/или защитных мерах. Выбор объекта оценки
должен отражать намеченное использование организатором выходных данных оценки.
Например, если выходные данные предназначены для использования при
совершенствовании деятельности по обеспечению ИБ, то область оценки должна
соответствовать области намеченных работ по совершенствованию. Область оценки
может быть любой: от отдельного процесса до всей организации. В контексте оценки
должно быть представлено подробное описание объекта оценки, включающее размеры
объекта оценки, область применения продуктов или услуг объекта оценки, основные
характеристики (например, объем, критичность, сложность и качество) продуктов или
услуг объекта оценки.
К ограничениям оценки можно отнести возможную недоступность основных
активов, используемых в обычной деловой деятельности организации; недостаточный
временной интервал, выделенный для проведения оценивания; необходимость
исключения определенных частей объекта оценки из-за стадии жизненного цикла. Кроме
того, могут быть наложены ограничения на количество и вид данных, которые должны
быть собраны и изучены.
Содержание контекста оценки должно быть согласовано руководителем группы
оценки с организатором и уполномоченным представителем объекта оценки и
задокументировано до начала процесса оценки. Фиксирование контекста оценки важно,
так как он содержит исходные элементы процесса оценки.
Во время выполнения оценки могут происходить изменения в контексте
оценки. Изменения должны быть одобрены организатором оценки и уполномоченным
представителем объекта оценки. Если эти изменения оказывают влияние на временной
график и ресурсы проведения оценки, то планирование оценки должно быть
соответствующим образом пересмотрено.

43. Обзор классов функциональных требований (ГОСТ 15408).

Источники: ГОСТ Р ИСО 15408-2-2002
1) Класс FAU: Аудит безопасности
Аудит безопасности включает распознавание, запись, хранение и анализ информации, связанной с
действиями, относящимися к безопасности (например, с действиями, контролируемыми ПБО).
Получаемые в результате записи аудита могут быть проанализированы, чтобы определить, какие
относящиеся к безопасности действия происходили, и кто из пользователей является ответственным за
них.
2) Класс FCO: Связь
Этот класс содержит два семейства, связанные с обеспечением идентификаторов сторон, участвующих
в обмене данными: идентификатора отправителя переданной информации (доказательство отправления)
и идентификатора получателя переданной информации (доказательство получения). Эти семейства
обеспечивают, что отправитель не сможет отрицать факт отправления сообщения, а получатель не
сможет отрицать факт его получения.
3) Класс FCS: Криптографическая поддержка
ФБО могут использовать криптографические функциональные возможности для содействия
достижению некоторых, наиболее важных целей безопасности. К ним относятся (но ими не
ограничиваются) следующие цели: идентификация и аутентификация, неотказуемость сообщения,
доверенный маршрут, доверенный канал, разделение данных. Этот класс используется, когда ОО имеет
криптографические функции, которые могут быть реализованы аппаратными, программно-
аппаратными и/или программными средствами.

76
Класс FCS состоит из двух семейств: FCS_CKM "Управление криптографическими ключами" и
FCS_COP "Криптографические операции". В семействе FCS_CKM рассматриваются аспекты
управления криптографическими ключами, тогда как в семействе FCS_COP рассматривается
практическое применение этих криптографических ключей.
4) Класс FDP: Защита данных пользователя
Этот класс содержит семейства, определяющие требования к функциям безопасности ОО и политикам
функций безопасности ОО, связанным с защитой данных пользователя. FDP разбит на четыре группы
семейств, перечисленные ниже, которые применяются к данным пользователя в пределах ОО во время
их импорта, экспорта и хранения, а также к атрибутам безопасности, которые прямо связаны с данными
пользователя.
5) Класс FIA: Идентификация и аутентификация
Семейства в этом классе содержат требования к функциям установления и верификации заявленного
идентификатора пользователя.
Идентификация и аутентификация требуются для обеспечения ассоциации пользователей с
соответствующими атрибутами безопасности (такими, как идентификатор, группы, роли, уровни
безопасности или целостности).
Однозначная идентификация уполномоченных пользователей и правильная ассоциация атрибутов
безопасности с пользователями и субъектами необходимы для осуществления принятых политик
безопасности. Семейства этого класса связаны с определением и верификацией идентификаторов
пользователей, определением их полномочий на взаимодействие с ОО, а также с правильной
ассоциацией атрибутов безопасности с каждым уполномоченным пользователем. Эффективность
требований других классов (таких, как "Защита данных пользователя", "Аудит безопасности") во
многом зависит от правильно проведенных идентификации и аутентификации пользователей.
6) Класс FMT: Управление безопасностью
Этот класс предназначен для спецификации управления некоторыми аспектами ФБО: атрибутами
безопасности, данными и отдельными функциями. Могут быть установлены различные роли
управления, а также определено их взаимодействие, например, распределение обязанностей.
Класс позволяет решать следующие задачи:
а) Управление данными ФБО, которые включают, например, предупреждающие сообщения.
б) Управление атрибутами безопасности, которые включают, например, списки управления
доступом и перечни возможностей.
в) Управление функциями из числа ФБО, которое включает, например, выбор функций, а также
правил или условий, влияющих на режим выполнения ФБО.
г) Определение ролей безопасности.
7) Класс FPR: Приватность
Этот класс содержит требования приватности. Эти требования предоставляют пользователю защиту от
раскрытия его идентификатора и злоупотребления этим другими пользователями.
8) Класс FPT: Защита ФБО
Этот класс содержит семейства функциональных требований, которые связаны с целостностью и
управлением механизмами, реализованными в ФБО, не завися при этом от особенностей ПБО, а также к
целостности данных ФБО, не завися от специфического содержания данных ПБО. В некотором смысле,
семейства этого класса дублируют компоненты из класса FDP "Защита данных пользователя"; они
могут даже использовать одни и те же механизмы. Однако класс FDP специализирован на защите
данных пользователя, в то время как класс FPT нацелен на защиту данных ФБО. Фактически,
компоненты из класса FPT необходимы для обеспечения требований невозможности нарушения и
обхода политик ФБ данного ОО.
9) Класс FRU: Использование ресурсов
Этот класс содержит три семейства, которые поддерживают доступность требуемых ресурсов, таких как
вычислительные возможности и/или объем памяти. Семейство "Отказоустойчивость" предоставляет
защиту от недоступности ресурсов, вызванной сбоем ОО. Семейство "Приоритет обслуживания"
обеспечивает, чтобы ресурсы выделялись наиболее важным или критичным по времени задачам и не
могли быть монополизированы задачами с более низким приоритетом. Семейство "Распределение
ресурсов" устанавливает ограничения использования доступных ресурсов, предотвращая
монополизацию ресурсов пользователями
10) Класс FTA: Доступ к ОО
Этот класс определяет функциональные требования к управлению открытием сеанса пользователя.
77
 11) Класс FTP: Доверенный маршрут/канал
Семейства этого класса предоставляют требования как к доверенному маршруту связи между
пользователями и ФБО, так и к доверенному каналу связи между ФБО и другими доверенными
продуктами ИТ. Доверенные маршруты и каналы имеют следующие общие свойства:
– маршрут связи создается с использованием внутренних и внешних каналов коммуникаций (в
соответствии с компонентом), которые изолируют идентифицированное подмножество данных и
команд ФБО от остальной части данных пользователей и ФБО;
– использование маршрута связи может быть инициировано пользователем и/или ФБО (в
соответствии с компонентом);
– маршрут связи способен обеспечить доверие тому, что пользователь взаимодействует с
требуемым ФБО или ФБО – с требуемым пользователем (в соответствии с компонентом).
Здесь доверенный канал – это канал связи, который может быть инициирован любой из связывающихся
сторон и обеспечивает неотказуемые характеристики, связанные с идентификаторами сторон канала.
Доверенный маршрут предоставляет пользователям средства для выполнения функций путем
обеспечения прямого взаимодействия с ФБО. Доверенный маршрут обычно желателен при начальной
идентификации и/или аутентификации пользователя, но может быть также желателен и в другие
моменты сеанса пользователя. Обмены по доверенному маршруту могут быть инициированы
пользователем или ФБО. Гарантируется, что ответы пользователя с использованием доверенного
маршрута будут защищены от модификации или раскрытия недоверенными приложениями.

44. Угрозы безопасности информации. Критерии классификация угроз безопасности

информации. Основные методы реализации угроз информационной безопасности.
Модель нарушителя.

Источники: Гайкович В.Ю, "Основы безопасности информационных технологий"

Угрозы безопасности информации, АС и субъектов информационных отношений

Под угрозой (вообще) обычно понимают потенциально возможное событие, действие (воздействие),
процесс или явление, которое может привести к нанесению ущерба чьим-либо интересам.
Угрозой интересам субъектов информационных отношений будем называть потенциально
возможное событие, процесс или явление, которое посредством воздействия на информацию или
другие компоненты АС может прямо или косвенно привести к нанесению ущерба интересам
данных субъектов.
В силу особенностей современных АС, перечисленных выше, существует значительное число
различных видов угроз безопасности субъектов информационных отношений.
Нарушением безопасности (или просто нарушением) будем называть реализацию угрозы безопасности.
В настоящей работе предпринята попытка возможно более полного охвата угроз безопасности
субъектов информационных отношений. Однако следует иметь в виду, что научно-технический
прогресс может привести к появлению принципиально новых видов угроз и что изощренный ум
злоумышленника способен придумать новые способы преодоления систем безопасности, НСД к
данным и дезорганизации работы АС.

Классификация угроз безопасности

Все множество потенциальных угроз по природе их возникновения разделяется на два класса:
естественные (объективные) и искусственные (субъективные)
Естественные угрозы - это угрозы, вызванные воздействиями на АС и ее элементы объективных
физических процессов или стихийных природных явлений, независящих от человека.
Искусственные угрозы - это угрозы АС, вызванные деятельностью человека. Среди них, исходя из
мотивации действий, можно выделить:
непреднамеренные (неумышленные, случайные) угрозы, вызванные ошибками в проектировании АС и
ее элементов, ошибками в программном обеспечении, ошибками в действиях персонала и т.п.;
преднамеренные (умышленные) угрозы, связанные с корыстными устремлениями людей
(злоумышленников).

78
Источники угроз по отношению к АС могут быть внешними или внутренними (компоненты самой АС -
ее аппаратура, программы, персонал).

Основные непреднамеренные искусственные угрозы

Основные непреднамеренные искусственные угрозы АС (действия, совершаемые людьми случайно, по

незнанию, невнимательности или халатности, из любопытства, но без злого умысла):
1) неумышленные действия, приводящие к частичному или полному отказу системы или разрушению
аппаратных, программных, информационных ресурсов системы (неумышленная порча
оборудования, удаление, искажение файлов с важной информацией или программ, в том числе
системных и т.п.);
2) неправомерное отключение оборудования или изменение режимов работы устройств и программ;
3) неумышленная порча носителей информации;
4) запуск технологических программ, способных при некомпетентном использовании вызывать потерю
работоспособности системы (зависания или зацикливания) или осуществляющих необратимые
изменения в системе (форматирование или реструктуризацию носителей информации, удаление
данных и т.п.);
5) нелегальное внедрение и использование неучтенных программ (игровых, обучающих,
технологических и др., не являющихся необходимыми для выполнения нарушителем своих
служебных обязанностей) с последующим необоснованным расходованием ресурсов (загрузка
процессора, захват оперативной памяти и памяти на внешних носителях);
6) заражение компьютера вирусами;
7) неосторожные действия, приводящие к разглашению конфиденциальной информации, или делающие
ее общедоступной;
8) разглашение, передача или утрата атрибутов разграничения доступа (паролей, ключей шифрования,
идентификационных карточек, пропусков и т.п.);
9) проектирование архитектуры системы, технологии обработки данных, разработка прикладных
программ, с возможностями, представляющими опасность для работоспособности системы и
безопасности информации;
10) игнорирование организационных ограничений (установленных правил) при работе в системе;
11) вход в систему в обход средств защиты (загрузка посторонней операционной системы со сменных
магнитных носителей и т.п.);
12) некомпетентное использование, настройка или неправомерное отключение средств защиты
персоналом службы безопасности;
13) пересылка данных по ошибочному адресу абонента (устройства);
14) ввод ошибочных данных;
15) неумышленное повреждение каналов связи.

Основные преднамеренные искусственные угрозы

Основные возможные пути умышленной дезорганизации работы, вывода системы из строя,

проникновения в систему и несанкционированного доступа к информации:
1) физическое разрушение системы (путем взрыва, поджога и т.п.) или вывод из строя всех или
отдельных наиболее важных компонентов компьютерной системы (устройств, носителей важной
системной информации, лиц из числа персонала и т.п.);
2) отключение или вывод из строя подсистем обеспечения функционирования вычислительных систем
(электропитания, охлаждения и вентиляции, линий связи и т.п.);
3) действия по дезорганизации функционирования системы (изменение режимов работы устройств или
программ, забастовка, саботаж персонала, постановка мощных активных радиопомех на частотах
работы устройств системы и т.п.);
4) внедрение агентов в число персонала системы (в том числе, возможно, и в административную
группу, отвечающую за безопасность);
5) вербовка (путем подкупа, шантажа и т.п.) персонала или отдельных пользователей, имеющих
определенные полномочия;
6) применение подслушивающих устройств, дистанционная фото- и видеосъемка и т.п.;

79
7) перехват побочных электромагнитных, акустических и других излучений устройств и линий связи, а
также наводок активных излучений на вспомогательные технические средства, непосредственно не
участвующие в обработке информации (телефонные линии, сети питания, отопления и т.п.);
8) перехват данных, передаваемых по каналам связи, и их анализ с целью выяснения протоколов
обмена, правил вхождения в связь и авторизации пользователя и последующих попыток их
имитации для проникновения в систему;
9) хищение носителей информации (магнитных дисков, лент, микросхем памяти, запоминающих
устройств и целых ПЭВМ);
10) несанкционированное копирование носителей информации;
11) хищение производственных отходов (распечаток, записей, списанных носителей информации и
т.п.);
12) чтение остаточной информации из оперативной памяти и с внешних запоминающих устройств;
13) чтение информации из областей оперативной памяти, используемых операционной системой (в том
числе подсистемой защиты) или другими пользователями, в асинхронном режиме используя
недостатки мультизадачных операционных систем и систем программирования;
14) незаконное получение паролей и других реквизитов разграничения доступа (агентурным путем,
используя халатность пользователей, путем подбора, путем имитации интерфейса системы и т.д.) с
последующей маскировкой под зарегистрированного пользователя ("маскарад");
15) несанкционированное использование терминалов пользователей, имеющих уникальные физические
характеристики, такие как номер рабочей станции в сети, физический адрес, адрес в системе связи,
аппаратный блок кодирования и т.п.;
16) вскрытие шифров криптозащиты информации;
17) внедрение аппаратных спецвложений, программных "закладок" и "вирусов" ("троянских коней" и
"жучков"), то есть таких участков программ, которые не нужны для осуществления заявленных
функций, но позволяющих преодолевать систему защиты, скрытно и незаконно осуществлять
доступ к системным ресурсам с целью регистрации и передачи критической информации или
дезорганизации функционирования системы;
18) незаконное подключение к линиям связи с целью работы "между строк", с использованием пауз в
действиях законного пользователя от его имени с последующим вводом ложных сообщений или
модификацией передаваемых сообщений;
19) незаконное подключение к линиям связи с целью прямой подмены законного пользователя путем
его физического отключения после входа в систему и успешной аутентификации с последующим
вводом дезинформации и навязыванием ложных сообщений.

Следует заметить, что чаще всего для достижения поставленной цели злоумышленник использует не
один, а некоторую совокупность из перечисленных выше путей.

Неформальная модель нарушителя в АС

Нарушитель - это лицо, предпринявшее попытку выполнения запрещенных операций (действий) по

ошибке, незнанию или осознанно со злым умыслом (из корыстных интересов) или без такового
(ради игры или удовольствия, с целью самоутверждения и т.п.) и использующее для этого
различные возможности, методы и средства.
Злоумышленником будем называть нарушителя, намеренно идущего на нарушение из корыстных
побуждений.
Неформальная модель нарушителя отражает его практические и теоретические возможности,
априорные знания, время и место действия и т.п. Для достижения своих целей нарушитель должен
приложить некоторые усилия, затратить определенные ресурсы. Исследовав причины нарушений,
можно либо повлиять на сами эти причины (конечно если это возможно), либо точнее определить
требования к системе защиты от данного вида нарушений или преступлений.
В каждом конкретном случае, исходя из конкретной технологии обработки информации, может быть
определена модель нарушителя, которая должна быть адекватна реальному нарушителю для данной
АС.
При разработке модели нарушителя определяются:
предположения о категориях лиц, к которым может принадлежать нарушитель;
предположения о мотивах действий нарушителя (преследуемых нарушителем целях);
80
предположения о квалификации нарушителя и его технической оснащенности (об используемых для
совершения нарушения методах и средствах);
ограничения и предположения о характере возможных действий нарушителей.
По отношению к АС нарушители могут быть внутренними (из числа персонала системы) или внешними
(посторонними лицами). Внутренним нарушителем может быть лицо из следующих категорий
персонала:
пользователи (операторы) системы;
персонал, обслуживающий технические средства (инженеры, техники);
сотрудники отделов разработки и сопровождения ПО (прикладные и системные программисты);
технический персонал, обслуживающий здания (уборщики, электрики, сантехники и другие
сотрудники, имеющие доступ в здания и помещения, где расположены компоненты АС);
сотрудники службы безопасности АС;
руководители различных уровней должностной иерархии.
Посторонние лица, которые могут быть нарушителями:
клиенты (представители организаций, граждане);
посетители (приглашенные по какому-либо поводу);
представители организаций, взаимодействующих по вопросам обеспечения жизнедеятельности
организации (энерго-, водо-, теплоснабжения и т.п.);
представители конкурирующих организаций (иностранных спецслужб) или лица, действующие по их
заданию;
лица, случайно или умышленно нарушившие пропускной режим (без цели нарушить безопасность АС);
любые лица за пределами контролируемой территории.
Можно выделить три основных мотива нарушений: безответственность, самоутверждение и корыстный
интерес.
При нарушениях, вызванных безответственностью, пользователь целенаправленно или случайно
производит какие-либо разрушающие действия, не связанные тем не менее со злым умыслом. В
большинстве случаев это следствие некомпетентности или небрежности.
Некоторые пользователи считают получение доступа к системным наборам данных крупным успехом,
затевая своего рода игру "пользователь - против системы" ради самоутверждения либо в
собственных глазах, либо в глазах коллег.
Нарушение безопасности АС может быть вызвано и корыстным интересом пользователя системы. В
этом случае он будет целенаправленно пытаться преодолеть систему защиты для доступа к
хранимой, передаваемой и обрабатываемой в АС информации. Даже если АС имеет средства,
делающие такое проникновение чрезвычайно сложным, полностью защитить ее от проникновения
практически невозможно.
Всех нарушителей можно классифицировать следующим образом.
По уровню знаний об АС :
знает функциональные особенности АС, основные закономерности формирования в ней массивов
данных и потоков запросов к ним, умеет пользоваться штатными средствами;
обладает высоким уровнем знаний и опытом работы с техническими средствами системы и их
обслуживания;
обладает высоким уровнем знаний в области программирования и вычислительной техники,
проектирования и эксплуатации автоматизированных информационных систем;
знает структуру, функции и механизм действия средств защиты, их сильные и слабые стороны.
По уровню возможностей (используемым методам и средствам):
применяющий чисто агентурные методы получения сведений;
применяющий пассивные средства (технические средства перехвата без модификации компонентов
системы);
использующий только штатные средства и недостатки систем защиты для ее преодоления
(несанкционированные действия с использованием разрешенных средств), а также компактные
магнитные носители информации, которые могут быть скрытно пронесены через посты охраны;
применяющий методы и средства активного воздействия (модификация и подключение
дополнительных технических средств, подключение к каналам передачи данных, внедрение
программных закладок и использование специальных инструментальных и технологических
программ).
По времени действия:
81
в процессе функционирования АС (во время работы компонентов системы);
в период неактивности компонентов системы (в нерабочее время, во время плановых перерывов в ее
работе, перерывов для обслуживания и ремонта и т.п.);
как в процессе функционирования АС, так и в период неактивности компонентов системы.
По месту действия:
без доступа на контролируемую территорию организации;
с контролируемой территории без доступа в здания и сооружения;
внутри помещений, но без доступа к техническим средствам АС;
с рабочих мест конечных пользователей (операторов) АС;
с доступом в зону данных (баз данных, архивов и т.п.);
с доступом в зону управления средствами обеспечения безопасности АС.
Могут учитываться следующие ограничения и предположения о характере действий возможных
нарушителей:
работа по подбору кадров и специальные мероприятия затрудняют возможность создания коалиций
нарушителей, т.е. объединения (сговора) и целенаправленных действий по преодолению
подсистемы защиты двух и более нарушителей;
нарушитель, планируя попытки НСД, скрывает свои несанкционированные действия от других
сотрудников;
НСД может быть следствием ошибок пользователей, администраторов, эксплуатирующего и
обслуживающего персонала, а также недостатков принятой технологии обработки информации и
т.д.
Определение конкретных значений характеристик возможных нарушителей в значительной степени
субъективно. Модель нарушителя, построенная с учетом особенностей конкретной предметной
области и технологии обработки информации, может быть представлена перечислением нескольких
вариантов его облика. Каждый вид нарушителя должен быть охарактеризован значениями
характеристик, приведенных выше.

45. Парадигма доверия в стандарте (ГОСТ 15408). Основные принципы стандарта.

Значимость уязвимостей. Причины возникновения уязвимостей. Подход к доверию
в стандарте. Роль оценки.

Парадигма поддержки доверия – понятие, которое применяется после оценки и

сертификации объекта оценки. Она применяется для получения уверенности в том,
что объект оценки по прежнему будет отвечать своему заданию по безопасности
после изменений в объекте оценки или его среде. К этим изменениям относятся:
обнаружение новых угроз, уязвимостей, изменения в требованиях пользователя,
исправление ошибок, обнаруженных в сертифицированном объекте оценки,
обновления функциональных возможностей объекта оценки.
Цикл поддержки доверия состоит из нескольких фаз:
1) Приёмка – фаза, когда планы и процедуры разработчика по поддержке доверия
устанавливаются, а затем их правильность подтверждается оценщиком.
2) Мониторинг – фаза, когда разработчик предоставляет свидетельство о том, что
доверие к объекту оценки поддерживается в соответствии с установленными
планами и процедурами, затем это свидетельство независимо проверяется
оценщиком.
3) Переоценка – завершающая фаза, когда обновленная версия ОО представляется на
рассмотрение, для переоценки, основанной на изменениях, которым подверглась
сертифицированная версия ОО.

82
Основные принципы состоят в том, что необходимо чётко формулировать угрозы
безопасности и положения политики безопасности на предприятии, а достаточность
предложенных мер должна быть продемонстрирована.
Значимость уязвимостей. Гост 15408 предполагает, что существуют нарушители,
которые будут пытаться нарушить политику безопасности, для собственной выгоды.
В связи с этим, ГОСТ 15408 предлагает предпринять ряд превентивных шагов:
А) Предпринять активные действия для выявления, а затем удаления и нейтрализации
всех уязвимостей, которые могут появиться
Б) Снизить возможный ущерб в случае появления уязвимостей
В) Отследить попытки использования оставшихся уязвимостей злоумышленниками.
Причины возникновения уязвимостей.
Уязвимости возникают из-за недостатков:
А) Требований, т.е. продукт или ИТ система могут обладать требуемыми от них
функциями, но могут содержать уязвимости, делающие их непригодными к
использованию.
Б) Проектирования, т.е. продукт или ИТ система не отвечают спецификации или
уязвимости являются следствием некачественных проектных решения
В) Эксплуатации, т.е. ИТ продукт или система, разработаны в полном соответствии с
корректными спецификациями, но уязвимости возникают в результате неадекватного
управления.
Доверие в 15408.
Доверие – основа уверенности в том, что ИТ продукт или система отвечают целям
безопасности. В ГОСТ 15408 доверие обеспечивается активным исследованием, т.е.
процессом, когда оцениваются свойства продукта или системы ИТ для определения
его свойств безопасности.
Роль оценки.
Оценка – способ достижения доверия к ИТ продукту или системе, который проверяется
в соответствии с ГОСТ 15408. Методы оценки включают в себя:
а) анализ и проверку процессов и процедур:
b) проверку того, что процессы и процедуры действительно применяются;
c) анализ соответствия между представлениями проекта ОО;
d) анализ соответствия каждого представления проекта ОО требованиям:
e) верификацию доказательств;
f) анализ руководств:
g) анализ разработанных функциональных тестов и полученный результатов:
h) независимое функциональное тестирование,
i) анализ уязвимостей. включающий в себя предположения о недостатках;
j) тестирование проникновения.

46. Национальная безопасность РФ, государственная информационная политика,

виды безопасности, проблемы информационных войн, концепция национальной
безопасности. Что такое концепция национальной безопасности?

Национальная безопасность — состояние защищенности личности, общества и

государства от внутренних и внешних угроз, при котором обеспечиваются реализация
конституционных прав и свобод граждан РФ, достойные качество и уровень их жизни,
суверенитет, независимость, государственная и территориальная целостность,
устойчивое социально-экономическое развитие РФ
83
Государственная информационная политика — комплекс политических, правовых,
экономических, социально-культурных и организационных мероприятий
государства, направленный на обеспечение конституционного права граждан на
доступ к информации
Выделяют следующие виды безопасности: экологическая, национальная,
промышленная, пожарная, информационная, экономическая, военная, внутренняя и
внешняя.
Информационная война – действия, предпринятые для достижения информационного
превосходства, путем нанесения ущерба информации, информационным процессам и
системам противника, при одновременной защите своей информации.
Основные черты информационной войны – навязывание чуждых целей, средствами
ведения войны являются различные средства передачи информации, объектом такой
войны является сознание, как индивидуальное, так и массовое.
Концепция национальной безопасности Российской Федерации - система взглядов на
обеспечение в Российской Федерации безопасности личности, общества и
государства от внешних и внутренних угроз во всех сферах жизнедеятельности. В
Концепции сформулированы важнейшие направления государственной политики
Российской Федерации.
Основным документом, определяющим национальную безопасность РФ, является «СТРАТЕГИЯ
НАЦИОНАЛЬНОЙ БЕЗОПАСНОСТИ РОССИЙСКОЙ ФЕДЕРАЦИИ» (Указ Президента РФ от31
декабря 2015 г. N683),а также нормативные документы: Военная доктрина Российской Федерации;
Морская доктрина Российской Федерации; Доктрина информационной безопасности Российской
Федерации(от 5декабря 2016 г. No646) и т.д.

47. Представление требований доверия к безопасности (ГОСТ 15408). Структура

класса, семейства, компонента, элемента и оценочных уровней доверия.

ГОСТ Р ИСО/МЭК 15408 Часть 3

Наиболее общую совокупность требований доверия называют "классом".
Каждый класс содержит "семейства" доверия, которые разделены на
"компоненты" доверия, содержащие, в свою очередь, "элементы"
доверия. Классы и семейства используют для обеспечения
таксономии классифицируемых требований доверия, в то время
как компоненты применяют непосредственно для
спецификации требований доверия в ПЗ/ЗБ.
Иерархическая структура представления требований доверия: класс-
семейство-компонент-элемент:
Структура класса: Имя класса, Представление класса, Семейство
доверия
Представление класса - Каждый класс доверия имеет вводный
подраздел, в котором изложены состав и назначение класса.
Структура семейства доверия: Имя семейства, Цели, Ранжирование
компонентов, Замечания по применению, Компоненты доверия.
Цели — этот пункт представляет назначение семейства доверия. В нем
изложены цели, для достижения которых предназначено
семейство, особенно связанные с парадигмой доверия ИСО/МЭК
15408. Описание целей для семейства доверия представлено в
общем виде.
Ранжирование компонентов - Каждое семейство доверия содержит
один или несколько компонентов доверия. Этот пункт семейства
доверия содержит описание имеющихся компонентов и
объяснение их отличительных признаков. Его основная цель
84
 состоит в указании различий между компонентами при принятии решения о том, что семейство
является необходимой или полезной частью требований доверия для ПЗ/ЗБ.
Замечания по применению семейства доверия содержит дополнительную информацию о семействе.
Эта информация предназначена непосредственно для пользователей семейства доверия (например,
разработчиков ПЗ и ЗБ, проектировщиков OO, оценщиков).

Структура компонента
доверия:

1) идентификация компонента содержит описательную информацию, необходимую для идентификации,

категорирования, регистрации и ссылок на компонент.
2) Необязательный подпункт целей компонента доверия содержит конкретные цели этого компонента.
Для компонентов доверия, которые имеют этот подпункт, он включает в себя конкретное
назначение данного компонента и подробное разъяснение целей.
3) Необязательный подпункт замечаний по применению компонента доверия содержит
дополнительную информацию для облегчения использования компонента.
4)Зависимости среди компонентов доверия возникают, если компонент не самодостаточен, а зависит от
наличия другого компонента. В отдельных ситуациях указанные в компонентах зависимости могут
быть неприменимы. Разработчик ПЗ/ЗБ может отказаться от удовлетворения зависимости,
представив обоснование, по каким причинам данная зависимость неприменима.
5) Элемент доверия - требование безопасности, при дальнейшем разделении которого значимый
результат оценки не изменяется. Элемент является наименьшим требованием безопасности,
распознаваемым в настоящем стандарте.

Каждый элемент доверия принадлежит к одному из трех типов:

1) элементы действий разработчика, определяющие действия, которые должны выполняться
разработчиком.
2) элементы содержания и представления свидетельств, определяющие требуемые свидетельства и
отражаемую в них информацию, а также, при необходимости, - конкретные характеристики,
которыми должны обладать либо ОО, либо данные свидетельства доверия.
3) элементы действий оценщика, определяющие действия, которые должны выполняться
оценщиком.

Структура ОУД: Имя ОУД, Цели, Замечания по применению, Компоненты доверия.

Цели – назначение ОУД

Замечания по применению - Необязательный пункт замечаний по
применению ОУД содержит информацию, представляющую интерес
для пользователей ОУД (например, для разработчиков ПЗ и ЗБ,
проектировщиков OO, планирующих использование этого ОУД,
оценщиков).
Компоненты доверия - Для каждого ОУД выбран набор компонентов
доверия.
Более высокий уровень доверия, чем предоставляемый данным ОУД,
может быть достигнут:
a) включением дополнительных компонентов доверия из других семейств
доверия;
b) заменой компонента доверия иерархичным компонентом из этого же
семейства доверия.

85
48. Причины, виды и каналы утечки информации. ГОСТ Р 50922-96.
Характеристика видов утечки информации: разглашение информации,
несанкционированный доступ, получение защищаемой информации разведками.
Характеристика каналов утечки информации: электромагнитный, акустический
(виброакустический), визуальный и информационный.

В связи с тем, что информация является предметом собственности, то неизбежно

возникает проблема угрозы безопасности этой информации, заключающейся в
неконтролируемом ее распространении, в хищении, несанкционированном уничтожении,
искажении, передаче, копировании, блокировании доступа к информации.
Следовательно, возникает проблема защиты информации от утечки и
несанкционированных воздействий на информацию и ее носители, а также
предотвращения других форм незаконного вмешательства в информационные ресурсы и
информационные системы.
Понятие “Защита информации” становится основополагающим (ключевым) понятием и
рассматривается как процесс или деятельность, направленная на предотвращение
утечки защищаемой информации, а также по предотвращению различного рода
несанкционированных воздействий (НСВ) на информацию и ее носители. Значимость
защиты информации увеличивается в связи с возрастанием возможностей
иностранных разведок за счет совершенствования технических средств разведки,
приближения этих средств к объектам разведки (носителям информации) вследствие
развертывания инспекционной деятельности, создания совместных предприятий и
производств, сокращения закрытых для иностранцев зон и городов. С развитием
конкуренции в среде свободного предпринимательства крупномасштабной задачей в
области “Защита информации” становится борьба с промышленным и
экономическим шпионажем, распространению которого способствует
широкомасштабное применение для обработки информации средств вычислительной
техники (особенно персональных ЭВМ), созданием вычислительных сетей, систем, баз
данных, многочисленных средств передачи информации. Промышленный шпионаж
ведется в основном с целью завоевания рынков сбыта, исключения технологических
прорывов конкурентов, срыва переговоров по контрактам, перепродажи фирменных
секретов и т.д. По мере ослабления противостояния между Востоком и Западом
промышленный шпионаж в работе многих разведок, в том числе и ЦРУ США,
становится приоритетным направлением наряду с политической разведкой.
Разглашение информации — Несанкционированное доведение защищаемой
информации до лиц, не имеющих права доступа к этой информации.
Несанкционированный доступ — доступ к информации в нарушение должностных
полномочий сотрудника, доступ к закрытой для публичного доступа информации со
стороны лиц, не имеющих разрешения на доступ к этой информации
Каналы утечки информации
К электромагнитным относятся каналы утечки информации, возникающие за счёт
различного вида побочных электромагнитных излучений и наводок (ПЭМИН) ТСПИ ( под
техническими средствами приема, обработки, хранения и передачи информации(ТСПИ)
понимают технические средства, непосредственно обрабатывающие
конфиденциальнуюинформацию.):

– излучений элементов ТСПИ;

– излучений на частотах работы высокочастотных (ВЧ) генераторов ТСПИ;
86
– излучений на частотах самовозбуждения усилителей низкой частоты (УНЧ) ТСПИ.
ТСПИ - это технические средства приёма, обработки, хранения и передачи информации
Акустический канал утечки информации - Это регистрация информативного звукового
сигнала из контролируемого помещения и дальнейшая трансляция его любым доступным
способом. Закладные устройства для снятия и передачи акустической информации (ЗУ)
можно классифицировать по способу регистрации и способу трансляции.
По способу регистрации ЗУ: с помощью микрофона; с помощью пьезокристаллического
датчика; используя модуляцию отраженного луча от светоотражающих поверхностей.
По способу передачи: с помощью проводных линий; с помощью радиоканала; с помощью
оптического канала.
Визуальный канал утечки информации реализовывается непосредственным
восприятием глазом человека окружающей обстановки путем применения специальных
технических средств, расширяющих возможности органа зрения по видению в условиях
недостаточной освещенности, при удаленности объектов наблюдения и недостаточности
углового разрешения. Это и обычное подглядывание из соседнего здания через бинокль,
и регистрация излучения различных оптических датчиков в видимом или ИК-диапазоне,
которое может быть модулировано полезной информацией. При этом очень часто
осуществляют документирование зрительной информации с применением
фотопленочных или электронных носителей. Наблюдение дает большой объем ценной
информации, особенно если оно сопряжено с копированием документации, чертежей,
образцов продукции и т. д. В принципе, процесс наблюдения сложен, так как требует
значительных затрат сил, времени и средств.
Характеристики всякого оптического прибора (в т. ч. глаза человека) обусловливаются
такими первостепенными показателями, как угловое разрешение, освещенность и
частота смены изображений. Большое значение имеет выбор компонентов системы
наблюдения.
Информационный канал — среда передачи сообщения в документированном
(текстовом) виде, а канал связи служит для обмена информацией, представленной в
речевой (звуковой, символьной и т.п.) форме. Во время передачи по каналу связи
(информационному каналу) передаваемый сигнал и сообщение, содержащее
конфиденциальную информацию, могут быть подвергнуты определенному воздействию.
На сигнал воздействуют помехи, он может искажаться при передаче по каналу связи.
Воздействие на сообщение может представлять собой попытки овладения содержащейся
в нем информацией со стороны злоумышленника (противника, недоброжелателя,
конкурента).

49. Обзор классов и семейств доверия (ГОСТ 15408).

Класс АСМ: Управление конфигурации.

Управление конфигурацией (УК) помогает обеспечить сохранение целостности ОО устанавливая и
контролируя определенный порядок процессов уточнения и модификации ОО и предоставления
связанной с ними и информации. УК предотвращает несанкционированную модификацию,
добавление или уничтожение составляющих ОО, обеспечивая тем самым доверие, что оцениваются
именно те ОО и документация, которые подготовлены к распространению.

Автоматизация УК (ACM_AUT). Семейство "Автоматизация управления конфигурацией

устанавливает уровень автоматизации, используемый для управления элементами конфигурации.
Возможности УК (АСМ_САР). Семейство "Возможности управления конфигурацией" определяет
характеристики системы управления конфигурацией.
87
Область УК (ACM_SCP). Семейство "Область управления конфигурацией" указывает на те
элементы ОО, для которых необходим контроль со стороны системы управления конфигурацией.

Класс ADO: Поставка и эксплуатация

Класс доверия ADO "Поставка и эксплуатация" определяет требования к мерам, процедурам и
стандартам применяемым для безопасной поставки, установки и эксплуатации ОО, обеспечивая,
чтобы безопасность ОО не нарушалась во время его распространения, установки и эксплуатации.
Поставка (ADO_DEL). Семейство "Поставка" распространяется на процедуры, используемые для
поддержки безопасности во время передачи ОО пользователю при первоначальной поставке и
последующим модификациях.

Установка, генерация и запуск (ADO_IGS). Семейство "Установка, генерация и запуск"

предусматривает, чтобы копия ОО была конфигурирована и активизирована администратором так,
чтобы показать те же самые свойства защиты, что и у оригинала ОО. Процедуры установки,
генерации и запуска обеспечивают уверенность в том, что администратор будет осведомлен о
параметрах конфигурации ОО и об их способности повлиять на ФБО
Класс ADV: Разработка
Класс доверия ADV "Разработка" определяет требования для пошагового уточнения ФБО. начиная с
краткой спецификации ОО в ЗБ и до фактической реализации. Каждое из получаемых
представлений ФБО содержит информацию, помогающую оценщику решить, были ли выполнены
функциональные требования к ОО.

Функциональная спецификация (ADV_FSP)

Функциональная спецификация описывает ФБО и должна быть полным и точным отображением
функциональных требований безопасности ОО. Функциональная спецификация также детализирует
внешний интерфейс ОО.
Проект верхнего уровня (ADV_HLD). Проект верхнего уровня - проектная спецификация самого
высокого уровня, уточняющая функциональную спецификацию ФБО в основных составляющих
частях ФБО. Проект верхнего уровня идентифицирует базовую структуру ФБО, а также основные
элементы аппаратных, программных и программно-аппаратных средств.
Представление- реализаций (AOV_IMP). Представление реализации - наименее абстрактное
представление ФБО. Оно фиксирует детализированное внутреннее содержание ФБО на уровне
исходного текста, аппаратных схем и т.п.
Внутренняя структура ФБО (ADV_INT). Требования к внутренней структуре ФБО определяют
необходимое внутреннее структурирование ФБО.

Проект нижнего уровня (ADV_LLD). Проект нижнего уровня -детализированная проектная

спецификация, уточняющая проект верхнего уровня до уровня детализации, который может быть
использован как основа для программирования и/или проектирования аппаратуры.
Соответствие представлений (ADV_RCR). Соответствие представлений -демонстрация отображения
между всеми смежными парами имеющихся представлений ФБО, от краткой спецификации ОО до
наименее абстрактного из имеющихся представлений ФБО.
Моделирование политики безопасности (ADV_SPM). Модели политики безопасности -
структурированные представления политик безопасности ПБО, используемые для обеспечения
повышенного доверия к тому, что функциональная спецификация соответствует политикам
безопасности из ПБО и, в конечном счете, функциональным требованиям безопасности ОО.

Класс AGD: Руководства

Класс доверия AGD "Руководства" определяет требования, направленные на обеспечение понятности.
достаточности и законченности эксплуатационных документов, представляемых разработчиком.
Данные документы, содержащие две категории информации (для пользователей и
администраторов), являются важным фактором безопасной эксплуатации ОО.
Руководство администратора (AGD_ADM). Руководство администратора - основное средство,
имеющееся в распоряжении разработчика, для предоставления администраторам ОО детальной и
точной информации о том, как осуществлять администрирование ОО безопасным способом и
эффективно использовать привилегии ФБО и функции защиты.
88
Руководство пользователя (AGD_USR)
Класс ALC: Поддержка жизненного цикла
Класс доверия ALC "Поддержка жизненного цикла" определяет требования доверия посредством
принятия для всех этапов разработки ОО четко определенной модели жизненного цикла, включая
политики и процедуры устранения недостатков, правильное использование инструментальных
средств и методов, а также меры безопасности среды разработки.

Безопасность разработки (ALC_OVS). Семейство "Безопасность разработки" охватывает

физические, процедурные, относящиеся к персоналу и другие меры безопасности, используемые
применительно к среде разработки.
Устранение недостатков (ALC_FLR)
Определение жизненного цикла (ALC_LCD)
Инструментальные средства и метода (АLС_ТАТ)

Класс АРЕ: Оценка профиля защиты

Цепь оценки ПЗ - продемонстрировать, что ПЗ является полным, непротиворечивым, технически
правильным и поэтому пригоден для изложения требовании к одному или нескольким
оцениваемым ОО. Такой ПЗ может быть приемлем для включения в реестр ПЗ.
Класс ASE: Оценка задания по безопасности
Цель оценки ЗБ - продемонстрировать, что ЗБ является полным, непротиворечивым, технически
правильным и поэтому пригодно для использования в качестве основы по и оценке
соответствующего ОО.
Класс ATE: Тестирование
Класс доверия ATE устанавливает требования к тестированию, которое демонстрирует, что ФБО
удовлетворяют функциональным требованиям безопасности ОО.
Покрытие (ATE_COV). Семейство "Покрытие" устанавливает полноту функциональных тестов,
выполненных разработчиком для ОО. Оно связано со степенью тестирования функций
безопасности ОО.
Глубина (АТЕ_СРТ)
Семейство "Глубина" устанавливает уровень детализации, на котором разработчик проверяет ОО.
Функциональное тестирование (ATE_FUN). Семейства "Функциональное тестирование"
устанавливает, что ФБО действительно демонстрируют свойства, необходимые для удовлетворения
требований соответствующего ЗБ.
Независимое тестирование (ATE_IND). Семейство "Независимое тестирование" определяет
степень выполнения функционального тестирования ОО кем-либо, кроме разработчика (например,
третьей стороной). Это семейство повышает ценность тестирования добавлением тестов,
дополняющих тесты разработчика.
Класс AVA: Оценка уязвимостей
Класс доверия AVA "Оценка уязвимостей" определяет требования, направленные на идентификацию
уязвимостей, которые могут быть активизированы. Особое внимание уделено уязвимостям которые
вносятся при проектировании, эксплуатации, неправильном применении или неверной
конфигурации ОО.
Анализ скрытых каналов (AVA_CCA). Семейство "Анализ скрытых каналов" направлено на
выявление и анализ непредусмотренных коммуникационных каналов, которые могут применяться
для нарушения предписанной ПВО.
Неправильное применение (AVA_MSU). Семейство "Анализ неправильного применения" позволяет
выяснить, способен ли администратор или пользователь, используя руководства, определить, что
ОО конфигурирован или эксплуатируется небезопасным способом.
Стоимость функций безопасности ОО (AVA_SOF). Анализ стойкости направлен на функции
безопасности ОО, которые реализованы с помощью вероятностного или перестановочного
механизма (например, пароля или хэш-функции). Для каждой из указанных функций безопасности
может быть заявлен уровень или специальная метрика стойкости. Анализ стойкости функций
проводят для принятия решения, отвечают ли такие функции сделанным заявлениям.
Анализ уязвимостей (AVA_VLA)

89
 Анализ уязвимостей заключается в идентификации недостатков, которые могли быть внесены на
различных этапах разработки. В результате определяются тесты проникновения, позволяющие
получить всю совокупность необходимой информации относительно:
1) полноты ФБО (противостоят ли ФБО всем ожидаемым угрозам)
2) зависимостей между всеми функциями безопасности.
Потенциальные уязвимости оценивают посредством тестирования проникновения, позволяющего
сделать заключение, могут ли они в действительности быть использованы для нарушения
безопасности ОО.

50. Методологи (уровни) рассмотрения вопросов информационной безопасности

(ИБ). Предприятие как объект информатизации (категории), АС и СВТ. Состав
типовой комплексной системы защиты информации на предприятии (КСЗИ):
СКУД, ОТ, ОПС, ПЭШ, КС. Уровни секретности (ГТ: С, СС, ОВ) и
конфиденциальности (К: служебная, коммерческая и общедоступная) информации.
Политика безопасности предприятия. (то же что и 32)

Как и информационные технологии, информационные системы могут функционировать и с

применением технических средств, и без такого применения. Это вопрос экономической
целесообразности.
Возрастание объёмов информации в информационной системе организаций, потребность в
ускорении и более сложных способах ее переработки вызывают крайне важность
автоматизации работы информационной системы, ᴛ.ᴇ. автоматизации обработки
информации.
Автоматизированная система (АС) − это система, состоящая из персонала и
комплекса средств автоматизации его деятельности, реализующая информационную
технологию выполнения установленных функций.

Элементы автоматизированной системы

 Персонал.
 Данные — часть компьютерной системы (КС).
 Алгоритмы обработки — КС.
 Программно-аппаратная среда (средства вычислительной техники (СВТ)) — КС.

Средство Вычислительной Техники (далее СВТ) — совокупность

программных и технических элементовсистем обработки данных, способных
функционировать самостоятельно или в составе других систем.
Не следует путать определение Автоматизированная Система (далее АС) и СВТ. Это
неравнозначныеопределения. СВТ является лишь одной из составляющих АС частей.
Следовательно, концепциябезопасности предусматривает существование двух относител
ьно самостоятельных и имеющих отличие направлений в проблеме защиты информации
от несанкционированного доступа (НСД): направление, связанное с СВТ, и направление,
связанное с АС. Отличие двух направлений порождено тем, что СВТразрабатываются и
поставляются на рынок лишь как элементы,из которых в дальнейшем строятся
функционально ориентированные АС. Помимо пользовательской информации при
создании АС появляютсятакие отсутствующие при разработке СВТ характеристики АС,
как полномочия пользователей, модель нарушителя, технология обработки информации.
Комплексная защита информационных ресурсов предприятия – это система мер по
их хранению, шифрованию, мониторингу доступа к ним и их обмена.
Она обеспечивает:
90
защиту информации от различного рода вирусных и хакерских угроз;
сохранность данных при физической утрате и поломках информационных носителей;
безопасность доступа к хранимым ресурсам;
восстановление информационной системы в случае повреждений.
Хранится конфиденциальная информация на специальном секретном и удаленном
сервере. Доступ к ней контролируется и определяется только руководством предприятия
(ограничивается или разрешается определенным сотрудникам).

Система контроля и управления доступом (СКУД) — совокупность программно-

аппаратных технических средств безопасности, имеющих целью ограничение и
регистрацию входа-выхода объектов (людей, транспорта) на заданной территории через
«точки прохода»: двери, ворота, КПП. Пример – турникет в институте.
Охранно-пожарная сигнализация (ОПС). Система позволяет обнаруживать очаги пожара
на ранних стадиях, быстро оповещать людей об опасности. Система также позволяет
предотвращать проникновение нарушителей в помещения.

ПЭШ - противодействие экономическому шпионажу

КС- компьютерная система, автоматизация систем безопасностей – создание узлов
управления и т.п.
ОТ(охранное телевидение) - Для обеспечения безопасности объекта, пожалуй, одним из
наиболее эффективных методов является видеонаблюдение. Данные системы нашли
применение в разных направлениях: от офисов до крупных предприятий, фиксируя и
собирая информацию о сотрудниках и посетителях. Достоинства системы – возможность
расширения, подключение дополнительных видеокамер и устройств, а также интеграция с
другими системами (охранная сигнализация, контроль доступа и другие).
Гос тайна и конфед. информация.

Степень секретности сведений, составляющих государственную тайну, соответствует

степени тяжести ущерба, который может быть нанесён государственной безопасности
вследствие разглашения указанных сведений. Устанавливаются три степени секретности
сведений, составляющих государственную тайну, и соответствующие этим
степеням грифы секретности: «особой важности», «совершенно секретно» и
«секретно». Использование перечисленных грифов секретности для засекречивания
сведений, не отнесенных к государственной тайне, не допускается.

К общедоступной информации относятся общеизвестные сведения и иная информация,

доступ к которой не ограничен.
Коммерческая тайна – конфиденциальность информации, позволяющая ее обладателю
при существующих или возможных обстоятельствах увеличить доходы, избежать
неоправданных расходов, сохранить положение на рынке товаров, работ, услуг или
получить иную коммерческую выгоду.
Информация составляет служебную или коммерческую тайну в случае, когда
информация имеет действительную или потенциальную коммерческую ценность в силу
неизвестности ее третьим лицам, к ней нет свободного доступа на законном основании и
обладатель информации принимает меры к охране ее конфиденциальности. Сведения,
которые не могут составлять служебную или коммерческую тайну, определяются законом
и иными правовыми актами.

91
Политика информационной безопасности организации -совокупность руководящих
принципов, правил, процедур и практических приёмов в области безопасности, которые
регулируют управление, защиту и распределение ценной информации.

51. Структура системы аттестации по требованиям безопасности информации.

АТТЕСТАЦИЯ ОБЪЕКТОВ ИНФОРМАТИЗАЦИИ (ОИ) – комплекс организационно-

технических мероприятий, в результате которых посредством специального документа –
«Аттестата соответствия» – подтверждается, что объект соответствует требованиям
стандартов или иных нормативно-технических документов по безопасности
информации.
Кому нужна аттестация ОИ?
Организациям и предприятиям, обрабатывающим информацию, доступ к которой
ограничен в соответствии с законодательством Российской Федерации.
Предприятиям и организациям, которым необходима независимая оценка соответствия
объекта информатизации требованиям нормативных документов по безопасности
информации.
Аттестация бывает:
Добровольная и Обязательная
Добровольная
Проводится по инициативе владельца информации или ОИ и может служить для
подтверждения соответствия ОИ требованиям безопасности информации,
установленным нормативными правовыми актами РФ, а также иными документами (в
том числе национальными или международными отраслевыми стандартами и т.д).
Обязательная
Проводится для ОИ в случаях, установленных федеральными законами, актами
Президента и Правительства РФ, нормативными правовыми актами уполномоченных
федеральных органов исполнительной власти. Сегодня аттестация носит обязательный
характер для ОИ, предназначенных для обработки сведений, составляющих
государственную тайну, а также для государственных и муниципальных
информационных систем.
Кем может проводиться аттестация
Добровольная
Организациями, имеющими лицензии ФСТЭК России на деятельность по технической
защите конфиденциальной информации.
Обязательная
Проводится для информатизации, предназначенных для обработки сведений,
составляющую государственную тайну, проводится организациями, имеющими аттестат
аккредитации органа по аттестации и соответствующие лицензии ФСТЭК России на
осуществление мероприятий и оказание услуг в области защиты государственной тайны
(в части технической защиты информации).
Аттестация объектов информатизации, предназначенных для обработки сведений
конфиденциального характера, проводится организациями, имеющими лицензию
ФСТЭК России на деятельность по технической защите конфиденциальной информации.

92
52. Порядок проведения аттестации объектов информатизации по требованиям
безопасности информации.
АТТЕСТАЦИЯ ОБЪЕКТОВ ИНФОРМАТИЗАЦИИ (ОИ) – комплекс
организационно-технических мероприятий, в результате которых посредством
специального документа – «Аттестата соответствия» – подтверждается, что объект
соответствует требованиям стандартов или иных нормативно-технических документов
по безопасности информации.
ЭТАПЫ:
1. Подача заявления на аттестацию в орган по аттестации или в организацию – лицензиат
ФСТЭК России.
2. Рассмотрение заявки.
3. Предварительное ознакомление с объектом информатизации.
4. Разработка программ и методики аттестационных испытаний.
5. Заявителем пишется согласие ПиМ
6. Проведение аттестационных испытаний
7. Разработка отчетной документации
8. Оформление, выдача, регистрация аттестата соответствия.

53. Виды лицензируемой деятельности в области защиты информации.

(Федеральный закон № 99-ФЗ от 04.05.2011г.)
Для целей настоящего Федерального закона используются следующие основные понятия:
1) лицензирование - деятельность лицензирующих органов по предоставлению, переоформлению
лицензий, аннулированию, продлению срока действия лицензий, формированию и ведению реестра
лицензий, формированию государственного информационного ресурса, а также по предоставлению в
установленном порядке информации по вопросам лицензирования;
93
 2) лицензия - специальное разрешение на право осуществления юридическим лицом или
индивидуальным предпринимателем конкретного вида деятельности (выполнения работ, оказания
услуг, составляющих лицензируемый вид деятельности), которое подтверждается записью в реестре
лицензий; (в ред. Федерального закона от 27.12.2019 N 478-ФЗ)
3) лицензируемый вид деятельности - вид деятельности, на осуществление которого на
территории Российской Федерации требуется получение лицензии; (в ред. Федерального закона от
04.03.2013 N 22-ФЗ)
4) лицензирующие органы - уполномоченные федеральные органы исполнительной власти и (или)
их территориальные органы, осуществляющие лицензирование;
В ст.12 Федерального закона перечислены виды деятельности, на которые требуется лицензия. В
контексте информационной безопасности лицензия требуется на следующие виды деятельности:
 Разработка, производство, распространение шифровальных (криптографических) средств,
информационных систем и телекоммуникационных систем, защищенных с использованием
шифровальных (криптографических) средств, выполнение работ, оказание услуг в области
шифрования информации, техническое обслуживание шифровальных (криптографических)
средств, информационных систем и телекоммуникационных систем, защищенных с
использованием шифровальных (криптографических) средств (за исключением случая, если
техническое обслуживание шифровальных (криптографических) средств, информационных
систем и телекоммуникационных систем, защищенных с использованием шифровальных
(криптографических) средств, осуществляется для обеспечения собственных нужд юридического
лица или индивидуального предпринимателя);
 Разработка, производство, реализация и приобретение в целях продажи специальных
технических средств, предназначенных для негласного получения информации;
 Деятельность по выявлению электронных устройств, предназначенных для негласного
получения информации (за исключением случая, если указанная деятельность осуществляется для
обеспечения собственных нужд юридического лица или индивидуального предпринимателя);
 Разработка и производство средств защиты конфиденциальной информации;
 Деятельность по технической защите конфиденциальной информации.

54. Классификация информационных систем персональных данных (ИСПДн) по

уровням защищенности. Состав и содержание мер по обеспечению безопасности
персональных данных, необходимых для обеспечения каждого из уровней
защищенности персональных данных (Приказ ФСТЭК №21 от 18 февраля 2013 г.).
8. В состав мер по обеспечению безопасности персональных данных, реализуемых в рамках
системы защиты персональных данных с учетом актуальных угроз безопасности персональных данных
и применяемых информационных технологий, входят:
 Идентификация и аутентификация субъектов доступа и объектов доступа;
 Управление доступом субъектов доступа к объектам доступа;
 Ограничение программной среды;
 Защита машинных носителей информации, на которых хранятся и (или) обрабатываются
персональные данные (далее - машинные носители персональных данных);
 Регистрация событий безопасности;
 Антивирусная защита;
 Обнаружение (предотвращение) вторжений;
 Контроль (анализ) защищенности персональных данных;
 Обеспечение целостности информационной системы и персональных данных;
 Обеспечение доступности персональных данных;
 Защита среды виртуализации;
 Защита технических средств;
 Защита информационной системы, ее средств, систем связи и передачи данных;

94
  Выявление инцидентов (одного события или группы событий), которые могут привести к сбоям
или нарушению функционирования информационной системы и (или) к возникновению угроз
безопасности персональных данных (далее - инциденты), и реагирование на них;
 Управление конфигурацией информационной системы и системы защиты персональных
данных.
О, а ща будет невъебически огромная таблица, ток вы не пугайтесь :)

СОСТАВ И СОДЕРЖАНИЕ МЕР ПО ОБЕСПЕЧЕНИЮ БЕЗОПАСНОСТИ ПЕРСОНАЛЬНЫХ

ДАННЫХ, НЕОБХОДИМЫХ ДЛЯ ОБЕСПЕЧЕНИЯ КАЖДОГО ИЗ УРОВНЕЙ
ЗАЩИЩЕННОСТИ ПЕРСОНАЛЬНЫХ ДАННЫХ

54.1 Страшная таблица. Тыкните, чтобы свернуть и продолжить жить счастливой и

беззаботной жизнью. Открывать на свой страх и риск…
Уровни
Условное защищенност
обозначение и
Содержание мер по обеспечению безопасности персональных данных персональных
и номер
меры данных

4 3 2 1

I. Идентификация и аутентификация субъектов доступа и объектов доступа (ИАФ)

Идентификация и аутентификация пользователей, являющихся работниками

ИАФ.1 + + + +
оператора

Идентификация и аутентификация устройств, в том числе стационарных,

ИАФ.2 + +
мобильных и портативных

Управление идентификаторами, в том числе создание, присвоение,

ИАФ.3 + + + +
уничтожение идентификаторов

Управление средствами аутентификации, в том числе хранение, выдача,

ИАФ.4 инициализация, блокирование средств аутентификации и принятие мер в + + + +
случае утраты и (или) компрометации средств аутентификации

ИАФ.5 Защита обратной связи при вводе аутентификационной информации + + + +

Идентификация и аутентификация пользователей, не являющихся

ИАФ.6 + + + +
работниками оператора (внешних пользователей)

II. Управление доступом субъектов доступа к объектам доступа (УПД)

Управление (заведение, активация, блокирование и уничтожение) учетными

УПД.1 + + + +
записями пользователей, в том числе внешних пользователей

Реализация необходимых методов (дискреционный, мандатный, ролевой или

УПД.2 иной метод), типов (чтение, запись, выполнение или иной тип) и правил + + + +
разграничения доступа

Управление (фильтрация, маршрутизация, контроль соединений,

однонаправленная передача и иные способы управления) информационными
УПД.3 + + + +
потоками между устройствами, сегментами информационной системы, а
также между информационными системами

Разделение полномочий (ролей) пользователей, администраторов и лиц,

УПД.4 + + + +
обеспечивающих функционирование информационной системы

95
 Назначение минимально необходимых прав и привилегий пользователям,
УПД.5 администраторам и лицам, обеспечивающим функционирование + + + +
информационной системы

Ограничение неуспешных попыток входа в информационную систему

УПД.6 + + + +
(доступа к информационной системе)

Предупреждение пользователя при его входе в информационную систему о

том, что в информационной системе реализованы меры по обеспечению
УПД.7
безопасности персональных данных, и о необходимости соблюдения
установленных оператором правил обработки персональных данных

Оповещение пользователя после успешного входа в информационную

УПД.8
систему о его предыдущем входе в информационную систему

Ограничение числа параллельных сеансов доступа для каждой учетной

УПД.9
записи пользователя информационной системы

Блокирование сеанса доступа в информационную систему после

УПД.10 установленного времени бездействия (неактивности) пользователя или по его + + +
запросу

Разрешение (запрет) действий пользователей, разрешенных до

УПД.11 + + +
идентификации и аутентификации

Поддержка и сохранение атрибутов безопасности (меток безопасности),

УПД.12
связанных с информацией в процессе ее хранения и обработки

Реализация защищенного удаленного доступа субъектов доступа к объектам

УПД.13 + + + +
доступа через внешние информационно-телекоммуникационные сети

Регламентация и контроль использования в информационной системе

УПД.14 + + + +
технологий беспроводного доступа

Регламентация и контроль использования в информационной системе

УПД.15 + + + +
мобильных технических средств

Управление взаимодействием с информационными системами сторонних

УПД.16 + + + +
организаций (внешние информационные системы)

УПД.17 Обеспечение доверенной загрузки средств вычислительной техники + +

III. Ограничение программной среды (ОПС)

Управление запуском (обращениями) компонентов программного

обеспечения, в том числе определение запускаемых компонентов, настройка
ОПС.1
параметров запуска компонентов, контроль за запуском компонентов
программного обеспечения

Управление установкой (инсталляцией) компонентов программного

обеспечения, в том числе определение компонентов, подлежащих установке,
ОПС.2 + +
настройка параметров установки компонентов, контроль за установкой
компонентов программного обеспечения

Установка (инсталляция) только разрешенного к использованию

ОПС.3 +
программного обеспечения и (или) его компонентов

Управление временными файлами, в том числе запрет, разрешение,

ОПС.4
перенаправление записи, удаление временных файлов

96
 IV. Защита машинных носителей персональных данных (ЗНИ)

ЗНИ.1 Учет машинных носителей персональных данных + +

ЗНИ.2 Управление доступом к машинным носителям персональных данных + +

Контроль перемещения машинных носителей персональных данных за

ЗНИ.3
пределы контролируемой зоны

Исключение возможности несанкционированного ознакомления с

содержанием персональных данных, хранящихся на машинных носителях, и
ЗНИ.4
(или) использования носителей персональных данных в иных
информационных системах

Контроль использования интерфейсов ввода (вывода) информации на

ЗНИ.5
машинные носители персональных данных

Контроль ввода (вывода) информации на машинные носители персональных

ЗНИ.6
данных

ЗНИ.7 Контроль подключения машинных носителей персональных данных

Уничтожение (стирание) или обезличивание персональных данных на

машинных носителях при их передаче между пользователями, в сторонние
ЗНИ.8 + + +
организации для ремонта или утилизации, а также контроль уничтожения
(стирания) или обезличивания

V. Регистрация событий безопасности (РСБ)

Определение событий безопасности, подлежащих регистрации, и сроков их

РСБ.1 + + + +
хранения

Определение состава и содержания информации о событиях безопасности,

РСБ.2 + + + +
подлежащих регистрации

Сбор, запись и хранение информации о событиях безопасности в течение

РСБ.3 + + + +
установленного времени хранения

Реагирование на сбои при регистрации событий безопасности, в том числе

РСБ.4 аппаратные и программные ошибки, сбои в механизмах сбора информации и
достижение предела или переполнения объема (емкости) памяти

Мониторинг (просмотр, анализ) результатов регистрации событий

РСБ.5 + +
безопасности и реагирование на них

Генерирование временных меток и (или) синхронизация системного времени

РСБ.6
в информационной системе

РСБ.7 Защита информации о событиях безопасности + + + +

VI. Антивирусная защита (АВЗ)

АВЗ.1 Реализация антивирусной защиты + + + +

Обновление базы данных признаков вредоносных компьютерных программ

АВЗ.2 + + + +
(вирусов)

VII. Обнаружение вторжений (СОВ)

СОВ.1 Обнаружение вторжений + +

97
СОВ.2 Обновление базы решающих правил + +

VIII. Контроль (анализ) защищенности персональных данных (АНЗ)

Выявление, анализ уязвимостей информационной системы и оперативное

АНЗ.1 + + +
устранение вновь выявленных уязвимостей

Контроль установки обновлений программного обеспечения, включая

АНЗ.2 + + + +
обновление программного обеспечения средств защиты информации

Контроль работоспособности, параметров настройки и правильности

АНЗ.3 функционирования программного обеспечения и средств защиты + + +
информации

Контроль состава технических средств, программного обеспечения и средств

АНЗ.4 + + +
защиты информации

Контроль правил генерации и смены паролей пользователей, заведения и

АНЗ.5 удаления учетных записей пользователей, реализации правил разграничения + +
доступа, полномочий пользователей в информационной системе

IX. Обеспечение целостности информационной системы и персональных данных (ОЦЛ)

Контроль целостности программного обеспечения, включая программное

ОЦЛ.1 + +
обеспечение средств защиты информации

Контроль целостности персональных данных, содержащихся в базах данных

ОЦЛ.2
информационной системы

Обеспечение возможности восстановления программного обеспечения,

ОЦЛ.3 включая программное обеспечение средств защиты информации, при
возникновении нештатных ситуаций

Обнаружение и реагирование на поступление в информационную систему

незапрашиваемых электронных сообщений (писем, документов) и иной
ОЦЛ.4 + +
информации, не относящихся к функционированию информационной
системы (защита от спама)

Контроль содержания информации, передаваемой из информационной

системы (контейнерный, основанный на свойствах объекта доступа, и (или)
ОЦЛ.5 контентный, основанный на поиске запрещенной к передаче информации с
использованием сигнатур, масок и иных методов), и исключение
неправомерной передачи информации из информационной системы

Ограничение прав пользователей по вводу информации в информационную

ОЦЛ.6
систему

Контроль точности, полноты и правильности данных, вводимых в

ОЦЛ.7
информационную систему

Контроль ошибочных действий пользователей по вводу и (или) передаче

ОЦЛ.8 персональных данных и предупреждение пользователей об ошибочных
действиях

X. Обеспечение доступности персональных данных (ОДТ)

ОДТ.1 Использование отказоустойчивых технических средств

ОДТ.2 Резервирование технических средств, программного обеспечения, каналов

передачи информации, средств обеспечения функционирования
98
 информационной системы

Контроль безотказного функционирования технических средств,

ОДТ.3 обнаружение и локализация отказов функционирования, принятие мер по +
восстановлению отказавших средств и их тестирование

Периодическое резервное копирование персональных данных на резервные

ОДТ.4 + +
машинные носители персональных данных

Обеспечение возможности восстановления персональных данных с

ОДТ.5 резервных машинных носителей персональных данных (резервных копий) в + +
течение установленного временного интервала

XI. Защита среды виртуализации (ЗСВ)

Идентификация и аутентификация субъектов доступа и объектов доступа в

ЗСВ.1 виртуальной инфраструктуре, в том числе администраторов управления + + + +
средствами виртуализации

Управление доступом субъектов доступа к объектам доступа в виртуальной

ЗСВ.2 + + + +
инфраструктуре, в том числе внутри виртуальных машин

ЗСВ.3 Регистрация событий безопасности в виртуальной инфраструктуре + + +

Управление (фильтрация, маршрутизация, контроль соединения,

однонаправленная передача) потоками информации между компонентами
ЗСВ.4
виртуальной инфраструктуры, а также по периметру виртуальной
инфраструктуры

Доверенная загрузка серверов виртуализации, виртуальной машины

ЗСВ.5
(контейнера), серверов управления виртуализацией

Управление перемещением виртуальных машин (контейнеров) и

ЗСВ.6 + +
обрабатываемых на них данных

ЗСВ.7 Контроль целостности виртуальной инфраструктуры и ее конфигураций + +

Резервное копирование данных, резервирование технических средств,

ЗСВ.8 программного обеспечения виртуальной инфраструктуры, а также каналов + +
связи внутри виртуальной инфраструктуры

Реализация и управление антивирусной защитой в виртуальной

ЗСВ.9 + + +
инфраструктуре

Разбиение виртуальной инфраструктуры на сегменты (сегментирование

ЗСВ.10 виртуальной инфраструктуры) для обработки персональных данных + + +
отдельным пользователем и (или) группой пользователей

XII. Защита технических средств (ЗТС)

Защита информации, обрабатываемой техническими средствами, от ее утечки

ЗТС.1
по техническим каналам

Организация контролируемой зоны, в пределах которой постоянно

размещаются стационарные технические средства, обрабатывающие
ЗТС.2
информацию, и средства защиты информации, а также средства обеспечения
функционирования

ЗТС.3 Контроль и управление физическим доступом к техническим средствам, + + + +

средствам защиты информации, средствам обеспечения функционирования, а
99
 также в помещения и сооружения, в которых они установлены, исключающие
несанкционированный физический доступ к средствам обработки
информации, средствам защиты информации и средствам обеспечения
функционирования информационной системы, в помещения и сооружения, в
которых они установлены

Размещение устройств вывода (отображения) информации, исключающее ее

ЗТС.4 + + + +
несанкционированный просмотр

Защита от внешних воздействий (воздействий окружающей среды,

ЗТС.5 нестабильности электроснабжения, кондиционирования и иных внешних
факторов)

XIII. Защита информационной системы, ее средств, систем связи и передачи данных (3ИС)

Разделение в информационной системе функций по управлению

(администрированию) информационной системой, управлению
ЗИС.1 +
(администрированию) системой защиты персональных данных, функций по
обработке персональных данных и иных функций информационной системы

Предотвращение задержки или прерывания выполнения процессов с высоким

ЗИС.2
приоритетом со стороны процессов с низким приоритетом

Обеспечение защиты персональных данных от раскрытия, модификации и

навязывания (ввода ложной информации) при ее передаче (подготовке к
ЗИС.3 + + + +
передаче) по каналам связи, имеющим выход за пределы контролируемой
зоны, в том числе беспроводным каналам связи

Обеспечение доверенных канала, маршрута между администратором,

ЗИС.4 пользователем и средствами защиты информации (функциями безопасности
средств защиты информации)

Запрет несанкционированной удаленной активации видеокамер, микрофонов

ЗИС.5 и иных периферийных устройств, которые могут активироваться удаленно, и
оповещение пользователей об активации таких устройств

Передача и контроль целостности атрибутов безопасности (меток

ЗИС.6 безопасности), связанных с персональными данными, при обмене ими с
иными информационными системами

Контроль санкционированного и исключение несанкционированного

использования технологий мобильного кода, в том числе регистрация
ЗИС.7 событий, связанных с использованием технологий мобильного кода, их
анализ и реагирование на нарушения, связанные с использованием
технологий мобильного кода

Контроль санкционированного и исключение несанкционированного

использования технологий передачи речи, в том числе регистрация событий,
ЗИС.8 связанных с использованием технологий передачи речи, их анализ и
реагирование на нарушения, связанные с использованием технологий
передачи речи

Контроль санкционированной и исключение несанкционированной передачи

видеоинформации, в том числе регистрация событий, связанных с передачей
ЗИС.9
видеоинформации, их анализ и реагирование на нарушения, связанные с
передачей видеоинформации

ЗИС.10 Подтверждение происхождения источника информации, получаемой в

процессе определения сетевых адресов по сетевым именам или определения
100
 сетевых имен по сетевым адресам

Обеспечение подлинности сетевых соединений (сеансов взаимодействия), в

ЗИС.11 + +
том числе для защиты от подмены сетевых устройств и сервисов

Исключение возможности отрицания пользователем факта отправки

ЗИС.12
персональных данных другому пользователю

Исключение возможности отрицания пользователем факта получения

ЗИС.13
персональных данных от другого пользователя

Использование устройств терминального доступа для обработки

ЗИС.14
персональных данных

Защита архивных файлов, параметров настройки средств защиты

ЗИС.15 информации и программного обеспечения и иных данных, не подлежащих + +
изменению в процессе обработки персональных данных

Выявление, анализ и блокирование в информационной системе скрытых

ЗИС.16 каналов передачи информации в обход реализованных мер или внутри
разрешенных сетевых протоколов

Разбиение информационной системы на сегменты (сегментирование

ЗИС.17 информационной системы) и обеспечение защиты периметров сегментов + +
информационной системы

Обеспечение загрузки и исполнения программного обеспечения с машинных

ЗИС.18 носителей персональных данных, доступных только для чтения, и контроль
целостности данного программного обеспечения

ЗИС.19 Изоляция процессов (выполнение программ) в выделенной области памяти

ЗИС.20 Защита беспроводных соединений, применяемых в информационной системе + + +

XIV. Выявление инцидентов и реагирование на них (ИНЦ)

Определение лиц, ответственных за выявление инцидентов и реагирование на

ИНЦ.1 + +
них

ИНЦ.2 Обнаружение, идентификация и регистрация инцидентов + +

Своевременное информирование лиц, ответственных за выявление

ИНЦ.3 инцидентов и реагирование на них, о возникновении инцидентов в + +
информационной системе пользователями и администраторами

Анализ инцидентов, в том числе определение источников и причин

ИНЦ.4 + +
возникновения инцидентов, а также оценка их последствий

ИНЦ.5 Принятие мер по устранению последствий инцидентов + +

Планирование и принятие мер по предотвращению повторного

ИНЦ.6 + +
возникновения инцидентов

XV. Управление конфигурацией информационной системы и системы защиты персональных данных

(УКФ)

Определение лиц, которым разрешены действия по внесению изменений в

УКФ.1 конфигурацию информационной системы и системы защиты персональных + + +
данных

101
 Управление изменениями конфигурации информационной системы и
УКФ.2 + + +
системы защиты персональных данных

Анализ потенциального воздействия планируемых изменений в

конфигурации информационной системы и системы защиты персональных
данных на обеспечение защиты персональных данных и согласование
УКФ.3 + + +
изменений в конфигурации информационной системы с должностным лицом
(работником), ответственным за обеспечение безопасности персональных
данных

Документирование информации (данных) об изменениях в конфигурации

УКФ.4 + + +
информационной системы и системы защиты персональных данных

55. Государственные информационные системы (ГИС). Классы защищенности

ГИС. Состав мер защиты информации и их базовые наборы для соответствующего
класса защищенности информационной системы (Приказ ФСТЭК №17 от 11
февраля 2013 г.).
Новыми документами ФСТЭК России установлены четыре класса защищенности ГИС,
определяющие уровни защищенности содержащейся в ней информации. Самый низкий класс -
четвертый, самый высокий - первый. Класс защищенности ГИС (первый класс К1, второй класс К2,
третий класс К3, четвертый класс К4) определяется в зависимости от уровня значимости
информации (УЗ), обрабатываемой в этой ГИС, и масштаба ГИС (федеральный, региональный,
объектовый).

Таблица классов защищенности ГИС:

Уровень значимости Масштаб информационной системы

информации Федеральный Региональный Объектовый
УЗ 1 К1 К1 К1

УЗ 2 К1 К2 К2

УЗ 3 К2 К3 К3

УЗ 4 К3 К3 К4

Система мер защиты информации в ГИС состоит из следующих элементов:

 Защита технических средств;
 Защита связи и передачи данных;
 Защита среды виртуализации;
 Защита машинных носителей;
 Идентификация и аутентификация;
 Управление доступом;
 Ограничение программной среды;
 Регистрация событий безопасности;
 Антивирусная защита;
 Обнаружение вторжений;

102
  Анализ защищенности;
 Обеспечение целостности информационной системы и информации;
 Обеспечение доступности информации.

Состав мер защиты информации и их базовые наборы для соответствующего класса защищенности ГИС
приведен в таблице (на прмере меры по идентификации и аутентификации).

Классы защищенности
Меры защиты информации в ГИС
ГИС
3 2 1
Идентификация и аутентификация субъектов доступа и объектов доступа (ИАФ)
ИАФ. идентификация и аутентификация пользователей,
+ + +
1 являющихся работниками оператора;
ИАФ. идентификация и аутентификация устройств (в том числе
+ +
2 стационарных, мобильных и портативных);
ИАФ. управление идентификаторами, в том числе создание,
+ + +
3 присвоение, уничтожение идентификаторов;
управление средствами аутентификации, в том числе
ИАФ. хранение, выдача, инициализация, блокирование средств АУ
+ + +
4 и принятие мер в случае утраты (компрометации) средств
АУ;
ИАФ. защита обратной связи при вводе аутентификационной
+ + +
5 информации;
ИАФ. идентификация и аутентификация внешних пользователей
+ + +
6 (не являющихся работниками оператора).

56. Категорирование объектов критической информационной инфраструктуры

(КИИ) (Федеральный закон №187-ФЗ от 26 июля 2017 г., Постановление
Правительства № 127 от 8 февраля 2018 г.).
Критическая информационная инфраструктура — объекты критической
информационной инфраструктуры, а также сети электросвязи, используемые для
организации взаимодействия таких объектов.
Объекты критической информационной инфраструктуры — информационные
системы, информационно-телекоммуникационные сети, автоматизированные системы
управления субъектов критической информационной инфраструктуры.
Субъекты критической информационной инфраструктуры — государственные
органы, государственные учреждения, российские юридические лица и (или)
индивидуальные предприниматели, которым на праве собственности, аренды или на
ином законном основании принадлежат информационные системы (ИС),
информационно-телекоммуникационные сети (ИТС), автоматизированные системы
управления (АСУ), функционирующие в сфере здравоохранения, науки, транспорта,
связи, энергетики, банковской сфере и иных сферах финансового рынка, топливно-
энергетического комплекса, в области атомной энергии, оборонной, ракетно-
космической, горнодобывающей, металлургической и химической промышленности,
российские юридические лица и (или) индивидуальные предприниматели, которые
обеспечивают взаимодействие указанных систем или сетей.
103
 Значимый объект критической информационной инфраструктуры — объект
критической информационной инфраструктуры, которому присвоена одна из категорий
значимости и который включен в реестр значимых объектов критической
информационной инфраструктуры.
Компьютерный инцидент — факт нарушения и (или) прекращения
функционирования объекта критической информационной инфраструктуры, сети
электросвязи, используемой для организации взаимодействия таких объектов, и (или)
нарушения безопасности обрабатываемой таким объектом информации, в том числе
произошедший в результате компьютерной атаки.
1. Категорирование объекта критической информационной инфраструктуры
представляет собой установление соответствия объекта критической информационной
инфраструктуры критериям значимости и показателям их значений, присвоение ему
одной из категорий значимости, проверку сведений о результатах ее присвоения.

2. Категорирование осуществляется исходя из:

1) социальной значимости;

2) политической значимости;

3) экономической значимости;

4) экологической значимости;

5) значимости объекта критической информационной инфраструктуры для

обеспечения обороны страны, безопасности государства и правопорядка.
3. Устанавливаются три категории значимости объектов критической
информационной инфраструктуры - первая, вторая и третья (по убыванию значимости,
первая – наивысшей значимости, третья – наименьшей).
Важное примечание: может получиться так, что у субъекта КИИ вообще не будет
объектов КИИ, подлежащих категорированию (т.е. они будут обозначены, как «без
категории»). Однако надо учитывать, что «Перечень объектов КИИ» согласовывается с
отраслевым регулятором (например, с Министерством энергетики, Банком России и пр.)
и перечень объектов КИИ отправляется во ФСТЭК.

104