Безопасность сервисов

Содержание

Слайд 2

Содержание

Какой он – безопасный сервис?
Бизнес-процессы, показатели, безопасное состояние.
Когда и зачем думать про

Содержание Какой он – безопасный сервис? Бизнес-процессы, показатели, безопасное состояние. Когда и
безопасность?
Как сделать сервис безопасным с минимумом затрат?
Никак! SDL. Цикл разработки
Оценка рисков
Как сделать так, чтобы мне поверили?
Безопасность на уровне требований и проектирования.

Пример оформления ссылки | Дополнительная ссылка

Слайд 3

Какой он – безопасный сервис?

Сервис – это автоматизация бизнес-процесса.
Безопасный сервис – это

Какой он – безопасный сервис? Сервис – это автоматизация бизнес-процесса. Безопасный сервис
безопасная автоматизация бизнес-процесса.
Безопасный сервис – это безопасная автоматизация безопасного бизнес-процесса.
Безопасно = риски приемлемы VS Безопасно = функционально!
Безопасно для кого? Владелец или пользователь?

Слайд 4

Когда нужно думать о безопасности?

Когда нужно думать о безопасности?

Слайд 5

Как сделать безопасный сервис
без затрат?
Никак

Как сделать безопасный сервис без затрат? Никак

Слайд 6

Модель сервиса

 

Структурные элементы: хранилища данных, посредники, процессы и границы доверия
Информационные потоки

Модель сервиса Структурные элементы: хранилища данных, посредники, процессы и границы доверия Информационные потоки

Слайд 7

Модель угроз

STRIDE model:
S – Spoofing of Identity – подмена идентификатора.
T – Tampering

Модель угроз STRIDE model: S – Spoofing of Identity – подмена идентификатора.
with Data – случайное/преднамеренное искажение данных
R – Repudiation – отказ от авторства
I – Information Disclosure – утечка информации
D – Denial of Service – блокирование доступа
E – Elevation of Privilege – првышение прав доступа

Слайд 8

Модель угроз

Модель угроз

Слайд 9

Как сделать сервис безопасным?

Пример методики разработки: Secure Development Lifecycle
Стадии:
1. Формирование требований (Reqiurements)
2.

Как сделать сервис безопасным? Пример методики разработки: Secure Development Lifecycle Стадии: 1.
Проектирование (Design)
3. Реализация (Implementation)
4. Проверка (Verification)
5. Выпуск (Release)
6. Поддержка (Response)

Слайд 10

У меня все безопасно.
Как мне поверят?

Пользователь хочет быть уверен в том,

У меня все безопасно. Как мне поверят? Пользователь хочет быть уверен в
что:
Архитектура безопасна (функциональные требования)
Реализация заслуживает доверия (требования доверия)
Что влияет:
Личный опыт и опыт близкого круга людей
Экспертная оценка

Слайд 11

ISO 15408 Common Criteria

Сервис – это автоматизация бизнес-процесса.
Безопасный сервис – это безопасная

ISO 15408 Common Criteria Сервис – это автоматизация бизнес-процесса. Безопасный сервис –
автоматизация бизнес-процесса.
Безопасный сервис – это безопасная автоматизация безопасного бизнес-процесса.
Безопасное состояние – риски приемлемы.

Слайд 12

У меня все безопасно.
Как мне поверят?

У меня все безопасно. Как мне поверят?

Слайд 13

Требования безопасности

Функциональные требования налагаются на те функции, которые предназначены для поддержания безопасности

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

Слайд 14

Требования безопасности

Класс – наиболее общее группирование требований безопасности. Все составляющие класса имеют

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

Слайд 15

Требования безопасности. Пример

Класс FIA – требования к функциям установления и верификации заявленного

Требования безопасности. Пример Класс FIA – требования к функциям установления и верификации
идентификатора пользователя
Семейство FIA_SOS – требования к механизмам, которые реализуют определенную метрику качества для предоставляемых секретов и генерируют секреты, удовлетворяющие определенной метрике.
Компоненты:
FIA_SOS.1 "Верификация секретов" содержит требование, чтобы ФБО верифицировали, отвечают ли секреты определенной метрике качества.
FIA_SOS.2 "Генерация секретов ФБО" содержит требование, чтобы ФБО были способны генерировать секреты, отвечающие определенной метрики качества.

Слайд 16

ОУД

Оценочные уровни доверия (ОУД) - это предопределенные пакеты требований доверия. ОУД является

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

Слайд 18

Итоговая оценка

Итоговая оценка
Имя файла: Безопасность-сервисов.pptx
Количество просмотров: 216
Количество скачиваний: 1