Методы оценки безопасности. ПАСЗИ

1.

Методы оценки безопасности
ПАСЗИ

2.

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

3.

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

4.

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

5.

Аппаратно-программные
(смешанные) средства
Реализуют те же функции, что аппаратные и программные
средства в отдельности, и имеют промежуточные свойства.
ViPNet Coordinator HW1000
Электронный замок "Соболь"
5

6.

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

7.

Различия между аппаратнопрограммными и программными СЗИ
на примере СЗИ от НСД
7

8.

Аппаратно-программный комплекс
шифрования «Континент». Версия 3.9.
8

9.

Программный СОВ «Kaspersky
Industrial CyberSecurity for Networks»
9

10.

Классы защищенности
Класс защищенности информационной системы (первый
класс (К1), второй класс (К2), третий класс (К3))
определяется в зависимости от уровня значимости
информации (УЗ), обрабатываемой в этой
информационной системе, и масштаба информационной
системы.
Уровень значимости информации определяется степенью
возможного ущерба для обладателя информации и
оператора от нарушения конфиденциальности
целостности или доступности информации.
УЗ = [(конфиденциальность, степень ущерба)
(целостность, степень ущерба) (доступность, степень
ущерба)]
10

11.

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

12.

Уровни значимости
Информация имеет высокий уровень значимости (УЗ 1), если хотя бы
для одного из свойств безопасности информации (конфиденциальности,
целостности, доступности) определена высокая степень ущерба.
Информация имеет средний уровень значимости (УЗ 2), если хотя бы
для одного из свойств безопасности информации (конфиденциальности,
целостности, доступности) определена средняя степень ущерба и нет ни
одного свойства, для которого определена высокая степень ущерба.
Информация имеет низкий уровень значимости (УЗ 3), если для всех
свойств безопасности информации (конфиденциальности, целостности,
доступности) определены низкие степени ущерба.
12

13.

Соответствие между уровнями
доверия и системами различных типов
13

14.

Соответствие между классами защиты
межсетевых экранов и системами
различных классов
14

15.

Соответствие между классами СОВ и
системами различных классов
15

16.

Состав мер защиты информации и их базовые наборы
для соответствующего КЗ АСУ изложены в Приложении
2 приказа ФСТЭК от 14 марта 2014 г. N 31:
1. Идентификация и аутентификация (ИАФ)
2. Управление доступом (УПД)
3. Ограничение программной среды (ОПС)
4. Защита машинных носителей (ЗНИ)
5. Аудит безопасности (АУД)
6. Антивирусная защита (АВЗ)
7. Предотвращение вторжение (компьютерных атак) (СОВ)
8. Обеспечение целостности (ОЦЛ)
9. Обеспечение доступности (ОДТ)
10. Защита технических средств и систем (ЗТС)
11. Защита информационной (автоматизированной) системы и ее компонентов
(ЗИС)
12. Реагирование на компьютерные инциденты (ИНЦ)
13. Управление конфигурацией (УКФ)
14. Управление обновлениями программного обеспечения (ОПО)
15. Планирование мероприятий по обеспечению безопасности (ПЛН)
16. Обеспечение действий в нештатных ситуациях (ДНС)
17. Информирование и обучение персонала (ИПО)
16

17.

Состав мер защиты информации и их базовые наборы для
ИСПДН изложены в приказе ФСТЭК от 18 февраля 2013 г. N 21
идентификация и аутентификация субъектов доступа и объектов доступа (ИАФ);
управление доступом субъектов доступа к объектам доступа (УПД);
ограничение программной среды (ОПС);
защита машинных носителей информации, на которых хранятся и (или) обрабатываются
персональные данные (далее - машинные носители персональных данных) (ЗНИ);
5. регистрация событий безопасности (РСБ);
6. антивирусная защита (АВЗ);
7. обнаружение (предотвращение) вторжений (СОВ);
8. контроль (анализ) защищенности персональных данных (АНЗ);
9. обеспечение целостности информационной системы и персональных данных (ОЦЛ);
10. обеспечение доступности персональных данных (ОДТ);
11. защита среды виртуализации (ЗСВ);
12. защита технических средств (ЗТС);
13. защита информационной системы, ее средств, систем связи и передачи данных (ЗИС);
14. выявление инцидентов (одного события или группы событий), которые могут привести к
сбоям или нарушению функционирования информационной системы и (или) к
возникновению угроз безопасности персональных данных (далее - инциденты), и
реагирование на них (ИНЦ);
15. управление конфигурацией информационной системы и системы защиты персональных
17
данных (УКФ).
1.
2.
3.
4.

18.

Состав мер защиты информации и их базовые наборы для
ГИС изложены в приказе ФСТЭК от 11 февраля 2013 г. N 17
1. Идентификация и аутентификация (ИАФ)
2. Управление доступом (УПД)
3. Ограничение программной среды (ОПС)
4. Защита машинных носителей (ЗНИ)
5. Регистрация событий безопасности (РСБ)
6. Антивирусная защита (АВЗ)
7. Обнаружение вторжений (СОВ)
8. Контроль (анализ) защищенности информации (АНЗ)
9. Обеспечение целостности информационной системы и информации
(ОЦЛ)
10. Обеспечение доступности (ОДТ)
11. Защита среды виртуализации (ЗСВ)
12. Защита технических средств (ЗТС)
13. Защита информационной системы, ее средств, систем связи и передачи
данных (ЗИС)
18

19.

Состав мер защиты информации и их базовые наборы для
КИИ изложены в приказе ФСТЭК от 25 декабря 2017 г. N 239
1. идентификация и аутентификация (ИАФ);
2. управление доступом (УПД);
3. ограничение программной среды (ОПС);
4. защита машинных носителей информации (ЗНИ);
5. аудит безопасности (АУД);
6. антивирусная защита (АВЗ);
7. предотвращение вторжений (компьютерных атак) (СОВ);
8. обеспечение целостности (ОЦЛ);
9. обеспечение доступности (ОДТ);
10. защита технических средств и систем (ЗТС);
11. защита информационной (автоматизированной) системы и ее компонентов (ЗИС);
12. планирование мероприятий по обеспечению безопасности (ПЛН);
13. управление конфигурацией (УКФ);
14. управление обновлениями программного обеспечения (ОПО);
15. реагирование на инциденты информационной безопасности (ИНЦ);
16. обеспечение действий в нештатных ситуациях (ДНС);
17. информирование и обучение персонала (ИПО).
19

20.

Взаимосвязь между содержанием ПЗ, ЗБ и ОО
20

21.

Оценочные уровни доверия
1-5 компоненты семейства доверия
21

22.

Оценочный уровень доверия 1
ОУД1 предоставляет базовый уровень доверия
посредством анализа функций безопасности с
использованием для понимания режима безопасности
функциональной
спецификации,
спецификации
интерфейсов и руководств.
22

23.

Оценочный уровень доверия 2
ОУД2 также обеспечивает доверие посредством списка конфигурации ОО и
свидетельства безопасных процедур поставки. Этот ОУД представляет значимое
увеличение доверия по сравнению с ОУД1, требуя тестирование и анализ
уязвимостей разработчиком, а также независимое тестирование, основанное на
более детализированных спецификациях ОО.
23

24.

Оценочный уровень доверия 3
ОУД3
также
обеспечивает
доверие
посредством
использования контроля среды
разработки,
управления
конфигурацией
ОО
и
свидетельства
безопасных
процедур поставки. Этот ОУД
представляет
значимое
увеличение
доверия
по
сравнению с ОУД2, требуя
более
полного
покрытия
тестированием
функций
и
механизмов безопасности и/или
процедур безопасности, что
дает некоторую уверенность в
том, что в ОО не будут внесены
искажения во время разработки.
24

25.

Оценочный уровень доверия 4
ОУД4 также обеспечивает
доверие
посредством
использования
контроля
среды
разработки
и
дополнительного управления
конфигурацией ОО, включая
автоматизацию,
и
свидетельства
безопасных
процедур поставки. Этот ОУД
представляет
значимое
увеличение
доверия
по
сравнению с ОУД3, требуя
более детальное описание
проекта,
подмножество
реализации и улучшенные
механизмы и/или процедуры,
что дает уверенность в том,
что в ОО не будут внесены
искажения
во
время
разработки или поставки.
25

26.

Оценочный уровень доверия 5
ОУД5 также обеспечивает доверие
посредством использования контроля
среды разработки и всестороннего
управления конфигурацией ОО,
включая
автоматизацию,
и
свидетельства безопасных процедур
поставки. Этот ОУД представляет
значимое увеличение доверия по
сравнению
с
ОУД4,
требуя
полуформальное описание проекта,
полную
реализацию,
более
структурированную
(и,
следовательно,
лучше
анализируемую) архитектуру, анализ
скрытых каналов и улучшенные
механизмы и/или процедуры, что
дает уверенность в том, что в ОО не
будут внесены искажения во время
разработки.
26

27.

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

28.

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

29.

Оценочные уровни доверия
Классы

30.

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

31.

Класс ADO. Поставка и эксплуатация
Класс "Поставка и эксплуатация" содержит требования правильной
поставки, установки, генерации и запуска ОО
31

32.

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

33.

Класс AGD. Руководства
Класс "Руководства" предоставляет требования к содержанию
"Руководства администратора" и "Руководства пользователя". Для
безопасного администрирования и использования ОО необходимо
описать все аспекты, относящиеся к безопасному применению ОО.
33

34.

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

35.

Класс ALC. Поддержка жизненного
цикла
Поддержка жизненного цикла
является аспектом
установления дисциплины и
контроля в процессе уточнения
ОО во время его разработки и
сопровождения. Уверенность в
соответствии ОО требованиям
безопасности к ОО больше,
если анализ безопасности и
формирование свидетельств
выполняют на регулярной
основе как неотъемлемую часть
деятельности при разработке и
сопровождении.
35

36.

Класс ATE. Тестирование
Класс "Тестирование" включает в себя четыре семейства: "Покрытие" (ATE_COV), "Глубина"
(ATE_DPT), "Функциональное тестирование" (ATE_FUN) и "Независимое тестирование"
(например, функциональное тестирование, выполняемое оценщиками, ATE_IND). Тестирование
помогает установить, что функциональные требования безопасности ОО выполнены.
Тестирование обеспечивает доверие к тому, что ОО удовлетворяет, по меньшей мере,
функциональным требованиям безопасности ОО, хотя оно и не может установить, что ОО не
обладает большими возможностями, чем определено спецификациями. Тестирование также
может быть направлено на внутреннюю структуру ФБО, например тестирование подсистем и
модулей на соответствие их спецификациям.
36

37.

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

38.

Класс AGD. Руководства
Класс AVA связан с наличием пригодных для использования скрытых
каналов и с возможностью неправильного применения или
конфигурирования ОО, а также с возможностью преодоления вероятностных
или перестановочных механизмов безопасности и использованием
уязвимостей, вносимых при разработке или эксплуатации ОО.
38

39.

Сравнение
САВЗ Б4 и САВЗ Б5
39

40.

4 типа САВЗ:
● тип «А» – предназначенные для централизованного администрирования
средствами антивирусной защиты, установленными на компонентах
информационных систем. САВЗ данного типа не применяются
самостоятельно и предназначены для использования только совместно со
средствами антивирусной защиты типов «Б» и (или) «В».
● тип «Б» – предназначенные для применения на серверах информационных
систем;
● тип «В» – предназначенные для применения на автоматизированных
рабочих местах информационных систем;
● тип «Г» – предназначенные для применения на автономных
автоматизированных рабочих местах.
40

41.

Схема подключения САВЗ типа «Б»
41

42.

Сравнение ПЗ САВЗ
ИТ.САВЗ.Б4.ПЗ
ИТ.САВЗ.Б5.ПЗ
ОУД
Оценочный уровень доверия 3 (ОУД3),
усиленный компонентами ACM_CAP.4
"Поддержка генерации, процедуры
приемки", ADV_IMP.2 "Реализация ФБО",
ADV_LLD.1 "Описательный проект
нижнего уровня", ALC_FLR.1 "Базовое
устранение недостатков", ALC_TAT.1
"Полностью определенные
инструментальные средства разработки",
AVA_VLA.3 "Умеренно стойкий" и
расширенный компонентами
ALC_UPV_EXT.1 "Процедуры обновления
БД ПКВ" и AMA_SIA_EXT.3 "Анализ
влияния обновлений на безопасность
САВЗ".
Оценочный уровень доверия 2 (ОУД2),
усиленный компонентом ALC_FLR.1
"Базовое устранение недостатков" и
расширенный компонентами
ALC_UPV_EXT.1 "Процедуры
обновления БД ПКВ" и
AMA_SIA_EXT.3 "Анализ влияния
обновлений на безопасность САВЗ".
42

43.

Сравнение ПЗ САВЗ
ИТ.САВЗ.Б4.ПЗ
ИТ.САВЗ.Б5.ПЗ
Требования доверия к безопасности ОО
Помимо требований к Б5:
Требуется уникальная маркировка и
идентификация
Полное отображение представления
реализации ФБО
Описательный проект нижнего уровня
Разработчик должен идентифицировать и
задокументировать выбранные опции
инструментальных средств разработки,
обусловленные реализацией.
Разработчик должен выполнить и
задокументировать анализ поставляемых
материалов ОО по поиску путей,
которыми пользователь может нарушить
ПБО.
Разработчик должен
задокументировать процедуры
устранения недостатков.
Разработчик должен разработать и
реализовать процедуру
представления обновлений для
проведения внешнего контроля
Анализ влияния обновлений на
безопасность КП ПАВ
43

44.

44

45.

Виды тестов
1) ПО разворачивают на чистую систему, на которой не было раньше установлено данное
ПО, так как Работа на железе отличается от работы в vm, среди тестовых машин могут
и должны быть как физические, так и виртуальные среды.
2) Проверку статических характеристик файлов антивируса это проверка таких
параметров работы антивируса как детектор, декодер, сигнатурного, поведенческого и
эвристического анализа.
3) Лечение и детектирование разнообразных угроз. Создается тестовый вредоносный
файл. Тестировщик подает его антивирусу для проверки.
4) Деинсталляция это процесс удаления программного продукта с диска, с компьютера.
Программа деинсталляции удаляет оставленные записи, восстанавливает системные
настройки
5) Повторная инсталляция – процесс удаления и повторной инсталляции программы с
последующей его настройкой
6) Проверка системы обновления ПО
7) Зачастую вредоносные программы содержат в себе функции, предназначенные для
подавления или нарушения работы антивирусной защиты системы. В таких условиях
современные антивирусные продукты должны уметь надежно себя защищать, т.е.
обладать самозащитой. Это позволяет им выстоять в случае наиболее сложных атак,
когда вредоносная программа пытается различными методами нарушить их работу, и
далее удалить инфекцию штатными средствами.
45

46.

Способы идентификации
уязвимостей в САВЗ, содержащихся в
БД ФСТЭК
Чтобы идентифицировать уязвимости в САВЗ, необходимо провести тестирования. Выделяют 2
типа: Методика тестирования ИБ организации и Методика тестирования на проникновение.
Тестирование по методу “черного ящика” предполагает отсутствие у тестирующей стороны
каких-либо знаний о конфигурации и внутренней структуре объекта испытаний. При этом против
объекта испытаний реализуются все известные типы атак и проверяется устойчивость системы
защиты в отношении этих атак. Используемые методы тестирования имитируют действия
потенциальных злоумышленников, пытающихся взломать систему защиты. Основным средством
тестирования в данном случае являются сетевые сканеры, располагающие базами данных
известных уязвимостей.
Метод “белого ящика” предполагает составление программы тестирования на основании знаний
о структура и конфигурации объекта испытаний. В ходе тестирования проверяется наличие и
работоспособность механизмов безопасности, соответствие состава и конфигурации системы
защиты требованиям безопасности. Выводы о наличии уязвимостей делаются на основании
анализа конфигурации используемых средств защиты и системного ПО, а затем проверяются на
практике. Основным инструментом тестирования в данном случае являются средства анализа
защищенности системного уровня, хостовые сканеры и списки проверки.
46

47.

Сравнение МЭ Б4 и МЭ Б5
47

48.

5 типов МЭ:
Тип А — межсетевые экраны уровня сети
Тип Б — межсетевые экраны уровня логических границ сети
Тип В — межсетевые экраны уровня узла
Тип Г — межсетевые экраны, используемые на серверах,
обслуживающих веб-приложения и службы
Тип Д — межсетевые экраны используемые в системах управления
технологическими и производственными процессами
48

49.

Сравнение ПЗ МЭ
ИТ.МЭ.Б4.ПЗ
ИТ.МЭ.Б5.ПЗ
ОУД
Оценочный уровень доверия 3 (ОУД3),
усиленный компонентами ADV_FSP.4
«Полная функциональная спецификация»,
ADV_IMP.2 «Полное отображение
представления реализации ФБО», ADV_TDS.3
«Базовый модульный проект», ALC_CMC.4
«Поддержка генерации, процедуры приемки и
автоматизация», ALC_FLR.1 «Базовое
устранение недостатков», ALC_TAT.1
«Полностью определенные инструментальные
средства разработки», AVA_VAN.5
«Усиленный методический анализ»,
расширенный компонентами
ADV_IMP_EXT.3 «Реализация ОО»,
ALC_FPU_EXT.1 «Процедуры обновления
программного обеспечения межсетевого
экрана» и AMA_SIA_EXT.3 «Анализ влияния
обновлений на безопасность межсетевого
экрана».
Оценочный уровень доверия 2 (ОУД2),
усиленный компонентами ADV_IMP.2
«Полное отображение представления
реализации ФБО», ADV_TDS.3 «Базовый
модульный проект», ALC_FLR.1 «Базовое
устранение недостатков», AVA_VAN.4
«Методический анализ уязвимостей»,
расширенный компонентами
ADV_IMP_EXT.3 «Реализация ОО»,
ALC_TAT_EXT.0 «Определение
инструментальных средств разработки»,
ALC_FPU_EXT.1 «Процедуры обновления
программного обеспечения межсетевого
экрана» и AMA_SIA_EXT.3 «Анализ
влияния обновлений на безопасность
межсетевого экрана»
49

50.

ИТ.МЭ.Б4.ПЗ
ИТ.МЭ.Б5.ПЗ
Функции безопасности
Помимо функций Б5:
1. контроль и фильтрация;
1. преобразование сетевых адресов;
2. идентификация
2. маскирование наличия МЭ;
3. приоритизация
аутентификация;
информационных
потоков;
4. взаимодействие
и
3. регистрация
событий
безопасности (аудит);
с
другими
средствами защиты информации
4. обеспечение
бесперебойного
функционирования
и
восстановление;
5. тестирование
и
контроль
целостности;
6. управление
(администрирование).
50

51.

ИТ.МЭ.Б4.ПЗ
ИТ.МЭ.Б5.ПЗ
Функциональные требования безопасности
Помимо функций Б5:
1. требования
к
преобразованию
сетевых адресов;
аутентификации субъектов МЭ;
2. требования к маскированию МЭ;
3. требования
к
приоритизации
4. требования к взаимодействию МЭ с
информации.
средствами
2. требования
защиты
к
регистрации
событий безопасности (аудиту);
3. требования
информационных потоков;
другими
1. требования к идентификации и
к
обеспечению
бесперебойного
функционирования
МЭ
и
восстановлению;
4. требования к тестированию и
контролю целостности ПО МЭ;
5. требования к управлению МЭ.
51

52.

ИТ.МЭ.Б4.ПЗ
ИТ.МЭ.Б5.ПЗ
Состав функциональных требований безопасности
Помимо функций Б5:
возможность
осуществлять
политику
фильтрации пакетов с учетом управляющих
команд от взаимодействующих с МЭ средств
защиты
информации
других
видов;
возможность осуществлять проверку каждого
пакета по таблице состояний для определения
того, не противоречит ли состояние пакета
ожидаемому состоянию;
возможность
осуществлять
проверку
использования пользователями отдельных
команд, для которых администратором МЭ
установлены
разрешительные
или
запретительные атрибуты безопасности;
возможность
осуществлять
проверку
использования сетевых ресурсов, содержащих
мобильный код, для которого администратором
МЭ
установлены
разрешительные
или
запретительные атрибуты безопасности;
возможность осуществлять фильтрацию
сетевого трафика для отправителей
информации, получателей информации и
всех операций передачи контролируемой
МЭ информации к узлам информационной
системы и от них;
возможность обеспечения МЭ фильтрации
для всех операций перемещения через МЭ
информации к узлам информационной
системы и от них;
возможность осуществлять фильтрацию,
основанную
на
следующих
типах
атрибутов
безопасности
субъектов:
сетевой адрес узла отправителя; сетевой
адрес узла получателя; интерфейс МЭ (на
уровне сетевого адреса), через который
проходит
пакет;
возможность
осуществлять фильтрацию, основанную на
следующих типах атрибутов безопасности
информации: сетевой протокол, который
используется
для
взаимодействия;
атрибуты, указывающие на фрагментацию
пакетов;
52

53.

ИТ.МЭ.Б4.ПЗ
ИТ.МЭ.Б5.ПЗ
Состав функциональных требований безопасности
Помимо функций Б5:
возможность осуществлять фильтрацию,
основанную на атрибутах: разрешенные/
запрещенные протоколы прикладного
уровня;
возможность
разрешать
информационный поток, основываясь на
результатах проверок;
возможность
запрещать
информационный поток, основываясь на
результатах проверок;
возможность осуществлять фильтрацию
пакетов с учетом управляющих команд
от взаимодействующих с МЭ средств
защиты информации других видов,
основанную на атрибутах, указывающих
на признаки нарушения безопасности в
информации сетевого трафика;
возможность
явно
разрешать
информационный поток, базируясь
на
устанавливаемых
администратором МЭ наборе правил
фильтрации,
основанном
на
идентифицированных атрибутах;
возможность
явно
запрещать
информационный поток, базируясь
на
устанавливаемых
администратором МЭ наборе правил
фильтрации,
основанном
на
идентифицированных атрибутах;
возможность блокирования всех
информационных
потоков,
проходящих
через
нефункционирующий
или
функционирующий некорректно МЭ;
53

54.

ИТ.МЭ.Б4.ПЗ
ИТ.МЭ.Б5.ПЗ
Состав функциональных требований безопасности
возможность
разрешать
информационный поток, если значения
атрибутов
безопасности,
установленные взаимодействующими
средствами защиты информации для
контролируемого сетевого трафика,
указывают на отсутствие нарушений
безопасности информации;
возможность
запрещать
информационный поток, если значения
атрибутов
безопасности,
установленные взаимодействующими
средствами защиты информации для
контролируемого сетевого трафика,
указывают на наличие нарушений
безопасности информации;
возможность
осуществлять
фильтрацию при импорте (перехвате)
информации сетевого трафика из-за
пределов МЭ;
возможность регистрации и учета
выполнения проверок информации
сетевого трафика;
возможность читать информацию из
записей
аудита
уполномоченным
администраторам;
возможность выбора совокупности
событий, подвергающихся аудиту, из
совокупности событий, в отношении
которых возможно осуществление
аудита;
возможность
оповещения
уполномоченных лиц о критичных
видах событий безопасности, в том
числе – сигнализация о попытках
нарушения
правил
межсетевого
экранирования;
54

55.

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

56.

ИТ.МЭ.Б4.ПЗ
ИТ.МЭ.Б5.ПЗ
Политики безопасности
Помимо функций Б5:
Политика
безопасности-3
Должна
осуществляться возможность предоставлять
разрешительные (запретительные) атрибуты
безопасности
для
используемых
пользователями отдельных команд.
Политика безопасности-1 Должно обеспечиваться
блокирование передачи защищаемой информации,
сетевых запросов и трафика, несанкционированно
исходящих из информационной системы и (или)
входящих в информационную систему, путем
фильтрации информационных потоков.
Политика
безопасности-4
Должна Политика безопасности-2 Должно осуществляться
обеспечиваться интерпретация управляющих присвоение информации состояния соединения
сигналов от средств защиты информации и только допустимых значений.
блокирование соответствующего трафика.
Политика безопасности-3 Должно осуществляться
Политика
безопасности-8
Должны разграничение доступа к управлению МЭ и
обеспечиваться
идентификация
и параметрами
МЭ
на
основе
ролей
аутентификация субъектов межсетевого уполномоченных лиц.
взаимодействия
до
передачи
МЭ
Политика безопасности-4 Должна обеспечиваться
информационного потока получателю.
возможность управления работой МЭ и
параметрами МЭ со стороны администраторов
МЭ.
56

57.

ИТ.МЭ.Б4.ПЗ
ИТ.МЭ.Б5.ПЗ
Политики безопасности
Политика
безопасности-11
Должны
обеспечиваться
запрет
прямого
взаимодействия
узлов
через
МЭ,
возможность проверки разрешительных
или
запретительных
атрибутов
информации (в заголовках пакетов
протоколов прикладного уровня, в поле
данных пакетов протоколов прикладного
уровня).
Политика
безопасности-12
Должна
обеспечиваться приоритизация контроля
и фильтрации разных информационных
потоков, а также выделения ресурсов,
доступных для разных информационных
потоков, обрабатываемых одновременно
(в течение определенного периода
времени).
Политика
безопасности-5
Должны
обеспечиваться
идентификация
и
аутентификация администраторов МЭ.
Политика
безопасности-6
Должны
обеспечиваться механизмы регистрации о
возможных нарушениях безопасности.
Политика
безопасности-7
Должны
обеспечиваться механизмы распределения
собственных ресурсов, а также установки
безопасного
состояния
ФБО
или
предотвращения их перехода в опасное
состояние
после
сбоев,
прерывания
функционирования или перезапуска
57

58.

Цели безопасности ИТ.МЭ.Б5.ПЗ
Взаимодействие МЭ с отдельными типами средств ЗИ ОО должен обеспечивать
возможность взаимодействия с отдельными типами средств защиты информации и
интерпретацию результатов их работы при осуществлении фильтрации пакетов данных и
блокирования соответствующего трафика.
Управление атрибутами безопасности команд пользователей ОО должен обеспечивать
возможность предоставлять разрешительные (запретительные) атрибуты безопасности для
используемых пользователями отдельных команд.
Посредничество в передаче информации сетевого трафика ОО должен обеспечивать
возможность запрета прямого взаимодействия узлов через МЭ, возможность проверки
разрешительных или запретительных атрибутов информации (в заголовках пакетов
протоколов прикладного уровня, в поле данных пакетов протоколов прикладного уровня).
Приоритизация ОО должен обеспечивать возможность приоритизации контроля и
фильтрации разных информационных потоков, а также выделения ресурсов, доступных для
разных
информационных
потоков,
определенного периода времени)
обрабатываемых
одновременно
(в
течение
58

59.

Способы идентификации
уязвимостей в МЭ, содержащихся в
БД ФСТЭК
Чтобы идентифицировать уязвимости в МЭ, необходимо провести тестирования. На данный
момент не существует методологии, нацеленной именно на специализированное тестирование
межсетевых экранов. Выделяют 2 типа: Методика тестирования ИБ организации и Методика
тестирования на проникновение.
Тестирование по методу “черного ящика” предполагает отсутствие у тестирующей стороны какихлибо знаний о конфигурации и внутренней структуре объекта испытаний. При этом против объекта
испытаний реализуются все известные типы атак и проверяется устойчивость системы защиты в
отношении этих атак. Используемые методы тестирования имитируют действия потенциальных
злоумышленников, пытающихся взломать систему защиты. Основным средством тестирования в
данном случае являются сетевые сканеры, располагающие базами данных известных уязвимостей.
Метод “белого ящика” предполагает составление программы тестирования на основании знаний о
структура и конфигурации объекта испытаний. В ходе тестирования проверяется наличие и
работоспособность механизмов безопасности, соответствие состава и конфигурации системы
защиты требованиям безопасности. Выводы о наличии уязвимостей делаются на основании анализа
конфигурации используемых средств защиты и системного ПО, а затем проверяются на практике.
Основным инструментом тестирования в данном случае являются средства анализа защищенности
системного уровня, хостовые сканеры и списки проверки.
59

60.

Функциональные компоненты, на
которых основаны ФТБ ОО
60

61.

Отличие от ИТ.МЭ.Б5.ПЗ:
1. Защита ФБО (FPT)
FPT_RCV.1 Ручное восстановление FPT_RCV.1.1 После [назначение: список сбоев, прерываний обслуживания]
ФБО должны перейти в режим аварийной поддержки, который предоставляет возможность возврата МЭ к
безопасному состоянию. Зависимости: AGD_OPE.1 «Руководство пользователя по эксплуатации».
FPT_TST.1 Тестирование ФБО
FPT_TST.1.1 ФБО должны выполнять пакет программ самотестирования [выбор: при запуске, периодически в
процессе нормального функционирования, по запросу уполномоченного пользователя, при условиях
[назначение: условия, при которых следует предусмотреть самотестирование]] для демонстрации правильного
выполнения [выбор: [назначение: части ФБО], ФБО].
FPT_TST.1.2 ФБО должны предоставить уполномоченным пользователям возможность верифицировать
целостность [выбор: [назначение: данных частей ФБО], данных ФБО].
FPT_TST.1.3 ФБО должны предоставить уполномоченным пользователям возможность верифицировать
целостность хранимого выполняемого кода ФБО. Зависимости: отсутствуют.
2. Использование ресурсов (FRU)
FRU_PRS_EXT.3 Приоритизация информационных потоков
FRU_PRS_EXT.3.1 ФБО должны осуществлять приоритизацию информационных потоков на основе
установленных приоритетов значений атрибутов информационных потоков [выбор: субъект, тип передаваемых
данных, [иные атрибуты информационных потоков, используемые для приоритизации]] и заданной функции
определения приоритета информационного потока на основе приоритетов значений атрибутов
информационного потока.
FRU_PRS_EXT.3.2 ФБО должны обеспечить обработку информационных потоков [выбор: контроль,
фильтрация, [назначение: иные процессы]] и (или) доступ к [выбор: полоса пропускания, [назначение: иные
управляемые ресурсы]] на основе приоритизации информационных потоков. Зависимости: FMT_MSA.1
Управление атрибутами безопасности; FMT_MTD.1 Управление данными функциональных возможностей
61
безопасности.

62.

Сравнение СКН Б4 и СКН Б5
62

63.

Сравнение ПЗ СКН
ИТ.СКН.Б4.ПЗ
ИТ.СКН.Б5.ПЗ
ОУД
Оценочный уровень доверия 3 (ОУД3),
усиленный компонентами ADV_IMP.2
«Полное отображение представления
реализации ФБО», ADV_TDS.3 «Базовый
модульный проект», ADV_FSP.4 «Полная
функциональная спецификация»,
ALC_TAT.1 «Полностью определенные
инструментальные средства разработки»,
ALC_CMC.4 «Поддержка генерации,
процедуры приемки и автоматизация»,
ALC_FLR.1 «Базовое устранение
недостатков», AVA_VAN.4 «Методический
анализ уязвимостей», расширенный
компонентом AMA_SIA_EXT.3 «Анализ
влияния обновлений на безопасность
средства контроля съемных машинных
носителей информации».
Оценочный уровень доверия 2 (ОУД2),
усиленный компонентом ALC_FLR.1
«Базовое устранение недостатков»,
расширенный компонентом
AMA_SIA_EXT.3 «Анализ влияния
обновлений на безопасность средства
контроля съемных машинных носителей
информации».
63

64.

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

65.

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

66.

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

67.

ИТ.СКН.Б5.ПЗ
Функциональные компоненты, на которых основаны
функциональные требования безопасности объекта оценки.
67

68.

ИТ.СКН.Б4.ПЗ
Отличия от ИТ.СКН.Б5.ПЗ:
FAU_ARP.1 Сигналы нарушения безопасности FAU_ARP.1.1 ФБО должны
предпринять [информирование администратора СКН], [назначение: список
других действий] при обнаружении возможного нарушения безопасности.
Замечания по применению: Разработчик ЗБ, кроме информирования
администратора СКН, может перечислить и другие действия при обнаружении
возможного нарушения безопасности. В этом случае разработчику ЗБ
необходимо будет четко определить содержание, последовательность и
результаты таких действий.
Защита Функций безопасности объекта (FPT)
FPT_ITT.1 Базовая защита внутренней передачи данных ФБО
FPT_ITT.1.1 ФБО должны защитить данные средства контроля съемных
машинных носителей информации от несанкционированной модификации при их
передаче между программным обеспечением управления средствами контроля
съемных машинных носителей информации и программным обеспечением
взаимодействия с подключаемыми съемными машинными носителями
информации.
68

69.

ИТ.СКН.Б5.ПЗ
В 5 классе защиты есть класс доверия обновления СКН, которого нет в 4 классе:
1. AMA_SIA_EXT.3 Анализ влияния обновлений на безопасность средства
контроля съемных машинных носителей информации Элементы действий
заявителя
2. AMA_SIA_EXT.3.1D Заявитель должен представить материалы анализа
влияния обновлений на безопасность средства контроля съемных машинных
носителей информации
69

70.

Запрет порта для СКН
Настройка политик безопасности
Заходим в приложение и выбираем порт.
Запрещаем его подключения.
70

71.

Сравнение ОС Б4 и ОС Б5
71

72.

3 типа ОС:
1. Операционная система общего назначения (тип “А”) - операционная
система,
предназначенная
для
функционирования
на
средствах
вычислительной техники общего назначения (АРМ, серверы, смартфоны,
планшеты, телефоны и иные);
2. Встраиваемая операционная система (тип “Б”) - операционная система,
встроенная (прошитая) в специализированные технические устройства,
предназначенные для решения заранее определенного набора задач;
3. Операционная система реального времени (тип “В”) - операционная система,
предназначенная для обеспечения реагирования на события в рамках
заданных временных ограничений при заданном уровне функциональности.
72

73.

Сравнение ПЗ ОС
ИТ.ОС.Б4.ПЗ
ИТ.ОС.Б5.ПЗ
ОУД
Оценочный уровень доверия 3 (ОУД3),
усиленный компонентами ADV_FSP.4 "Полная
функциональная спецификация", ADV_IMP.2
"Полное отображение представления реализации
ФБО", ADV_TDS.3 "Базовый модульный
проект", ALC_CMC.4 "Поддержка генерации,
процедуры
приемки
и
автоматизация",
ALC_FLR.1 "Базовое устранение недостатков",
ALC_TAT.1
"Полностью
определенные
инструментальные
средства
разработки",
AVA_VAN.5 "Усиленный методический анализ",
расширенный компонентами ADV_IMP_EXT.3
"Реализация ОО", ALC_FPU_EXT.1 "Процедуры
обновления
программного
обеспечения
операционной
системы",
ALC_LCD_EXT.3
"Определенные
разработчиком
сроки
поддержки", AMA_SIA_EXT.3 "Анализ влияния
обновлений на безопасность операционной
системы", AMA_SIA_EXT.6 "Анализ влияния
внешних модулей уровня ядра на безопасность
операционной системы" и AVA_CCA_EXT.1
"Анализ скрытых каналов".
Оценочный уровень доверия 2 (ОУД2),
усиленный
компонентами
ADV_IMP.2
"Полное
отображение
представления
реализации ФБО", ADV_TDS.3 "Базовый
модульный проект", ALC_FLR.1 "Базовое
устранение
недостатков",
AVA_VAN.4
"Методический
анализ
уязвимостей",
расширенный
компонентами
ADV_IMP_EXT.3
"Реализация
ОО",
ALC_TAT_EXT.0
"Определение
инструментальных средств разработки",
ALC_FPU_EXT.1 "Процедуры обновления
программного обеспечения операционной
системы", ALC_LCD_EXT.3 "Определенные
разработчиком
сроки
поддержки",
AMA_SIA_EXT.3
"Анализ
влияния
обновлений на безопасность операционной
системы", AMA_SIA_EXT.6 "Анализ влияния
внешних
модулей
уровня
ядра
на
безопасность операционной системы" и
AVA_CCA_EXT.1
"Анализ
скрытых
73
каналов".

74.

ИТ.ОС.Б4.ПЗ
ИТ.ОС.Б5.ПЗ
Состав функциональных требований
1. возможность
данных
защиты
аудита
от
несанкционированного
раскрытия
идентификация и аутентификация пользователей до выполнения
любых действий по доступу в информационную систему;
2. идентификация и аутентификация администраторов до
выполнения действий по управлению ОС;
3. возможность
идентификации
субъекта
доступа
путем
предъявления физического устройства идентификации до
разрешения действия, выполняемого от имени этого субъекта
доступа;
4. возможность задания политики дискреционного и (или) ролевого
управления доступом для установленного множества операций,
выполняемых субъектами доступа по отношению к объектам
доступа;
5. возможность реализации дискреционного и (или) ролевого
управления доступом на основе списков управления доступом
(матрицы управления доступом) и (или) ролей;
6. возможность
автоматического
запуска
прикладного
программного обеспечения при старте СВТ;
7. возможность исключения непосредственного взаимодействия
пользователей прикладного программного обеспечения с ОС;
8. возможность со стороны администратора управлять атрибутами
безопасности;
9. возможность со стороны администратора управлять параметрами
функций безопасности операционной системы, данными аудита;
10. возможность
со
стороны
администратора
управлять
выполнением функций безопасности ОС;
1.
Помимо функций Б5:
при
их
передаче;
1. возможность передавать
данные аудита для
внешнего хранения
74

75.

ИТ.ОС.Б4.ПЗ
ИТ.ОС.Б5.ПЗ
Состав функциональных требований
11. поддержка определенных ролей для ОС и их ассоциации с пользователями ОС;
12. защита хранимой аутентификационной информации от неправомерного доступа
к ней и раскрытия;
13. постоянный контроль и проверка правомочности обращений субъектов доступа
к объектам доступа;
14. возможность предоставления надежных меток времени при проведении аудита
безопасности;
15. возможность включения и исключения событий в совокупность событий,
подвергающихся аудиту, предоставляемая администратору;
16. возможность предоставления администратору всей информации аудита в
понятном для него виде;
17. возможность защиты хранимых записей регистрации событий безопасности ОС
(аудита) от несанкционированного удаления и предотвращения модификации
записей аудита;
18. возможность регистрации (аудита) событий безопасности, которые в
соответствии с национальным стандартом Российской Федерации ГОСТ Р
ИСО/МЭК 15408-2-2013 "Информационная технология. Методы и средства
обеспечения безопасности. Критерии оценки безопасности информационных
технологий. Часть 2. Функциональные компоненты безопасности" включены в
базовый уровень аудита;
19. возможность выполнения действий, направленных на сохранение данных
журнала регистрации событий безопасности ОС и обеспечивающих непрерывность
процесса аудита, если журнал регистрации событий безопасности ОС превысит
определенный администратором размер;
75
20. возможность полнотекстовой регистрации привилегированных команд (команд,
управляющих системными функциями).

76.

ИТ.ОС.Б4.ПЗ
ИТ.ОС.Б5.ПЗ
Политика безопасности
Помимо функций Б5:
В политике 8 добавляется:
● Должны обеспечиваться автоматический
запуск
прикладного
программного
обеспечения при старте СВТ, а также
ограничение доступа пользователя ОС к
интерактивным
интерфейсам
операционной системы.
И появляется политика:
10. Должна обеспечиваться защита данных
аудита от несанкционированного раскрытия
при их передаче к другому доверенному
продукту ИТ.
1.
2.
3.
4.
5.
Должны осуществляться идентификация и
аутентификация
пользователей
ОС
до
выполнения любых действий по доступу в
информационную систему или по управлению
ОС.
Должна
осуществляться
идентификация
субъектов доступа по физическим устройствам.
В ОО для управления доступом субъектов
доступа к объектам доступа в ОС (объектам
файловой системы, устройствам и (или) иным
объектам доступа) должно быть реализовано
дискреционное и (или) ролевое управление
доступом.
Должна осуществляться возможность задания
правил управления доступом, разрешающих или
запрещающих доступ субъектов доступа к
объектам доступа, а также определяющих
разрешенные типы доступа с использованием
атрибутов безопасности объектов доступа и
субъектов доступа на основе реализованных в
ОС
методов
управления
доступом
(дискреционный, ролевой).
Должны
обеспечиваться
возможности
генерирования надежных меток времени.
76

77.

ИТ.ОС.Б4.ПЗ
ИТ.ОС.Б5.ПЗ
Политика безопасности
6. Должны обеспечиваться возможности по
управлению работой ОС и параметрами ОС со
стороны администраторов.
7. Должна быть обеспечена регистрация
возможных событий безопасности. Механизмы
регистрации
должны
предоставлять
администратору возможность ознакомления с
информацией о произошедших событиях.
8. Должен обеспечиваться автоматический
запуск прикладного программного обеспечения
при старте СВТ.
9. Должны обеспечиваться контроль и проверка
правомочности обращений субъектов доступа к
объектам доступа.
77

78.

Способы идентификации
уязвимостей в ОС
Чтобы идентифицировать уязвимости в ОС, необходимо провести тестирование и
анализ, а также сравнить полученные данные с Базой данных угроз безопасности
информации ФСТЭК.
Тестирование является проактивным средством безопасности. Тестовый
инструментарий включает:
● автоматические средства сканирования;
● средства тестирования и оценки;
● тестирование проникновением.
Большая часть технических уязвимостей выявляется в автоматическом режиме
при помощи сетевых и хостовых сканеров, которые способны одновременно
выполнять тысячи проверок.
Что может включать в себя тестирование:
1. Фаззинг
2. Реверс-инжиниринг (паттерн, шаблоны)
78

79.

Функциональные компоненты, на
которых основаны ФТБ ОО
Идентификатор компонента требований
Название компонента требований
FAU_GEN.1
Генерация данных аудита
FAU_SEL.1
Избирательный аудит
FAU_SAR.1
Просмотр аудита
FAU_STG.1
Защищенное хранение журнала аудита
FAU_STG.3
Действия в случае возможной потери
данных аудита
FAU_STG.4
Предотвращение
аудита
FDP_ACC.1
Ограниченное управление доступом
FDP_ACF.1
Управление доступом, основанное на
атрибутах безопасности
FDP_RSP_EXT.3
Ограничение доступа пользователя к
интерактивным
интерфейсам
операционной системы
потери
данных
79

80.

FIA_IFD_EXT.1
Идентификация
субъектов
физическим устройствам
доступа
по
FIA_UAU.2
Аутентификация
пользователя
до
любых
действий
FIA_UID.2
Идентификация
пользователя
до
любых
действий
FMT_MOF.1
Управление режимом выполнения функций
безопасности
FMT_MSA.1
Управление атрибутами безопасности
FMT_MTD.1
Управление данными функций безопасности
FMT_SMF.1
Спецификация функций управления
FMT_SMR.1
Роли безопасности
FPT_MTR_EXT.1
Монитор обращений
FPT_APW_EXT.1
Защита
хранимой
информации
FPT_STM.1
Надежные метки времени
аутентификационной
Помимо основных функциональных компонентов в 4 классе есть:
FPT_ITC.1
Конфиденциальность экспортируемых данных ФБО при передаче
80

81.

Тестирование (ATE)
То есть для Б4 необходимо не только выборочное, но и глубинное
тестирование, которое проводится экспертами. Для Б5 проводится
тестирование с учётом умеренного потенциала нападения. А для Б4 - с
высоким потенциалом нападения.
81

82.

Экспертное тестирование
82