Безопасность сервисов Дмитрий Истомин, директор по развитию Уральского центра систем безопасности.

Презентация:



Advertisements
Похожие презентации
Создание безопасных Веб-приложений Алексей Кирсанов ведущий разработчик компании «Битрикс»
Advertisements

Стандарт ISO Общие критерии оценки безопасности информационных технологий.
Лекция 4 - Стандарты информационной безопасности: «Общие критерии» 1. Введение 2. Требования безопасности к информационным системам 3. Принцип иерархии:
ОБЕСПЕЧЕНИЕ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ СЛОЖНЫХ ИНФОРМАЦИОННЫХ СИСТЕМ М.В. Большаков Институт проблем информационной безопасности МГУ им. М.В. Ломоносова.
Канадские критерии безопасности Созданы в 1993г. Цель разработки Единая шкала критериев Единая шкала критериев Основа для разработки спецификаций безопасных.
Представление предметной области. Методы представления предметной области. Модель сущность-связь. Инфологическое описание предметной области.
Коробочное решение для защиты электронного документооборота Андрей ШАРОВ Электронные Офисные Системы 2007.
Технологии и продукты Microsoft в обеспечении ИБ Лекция 2. Моделирование угроз ИБ: различные подходы.
Основные концепции Общих критериев оценки безопасности информационных технологий Шеин Анатолий Васильевич Цнииатоминформ Минатома России.
8.4. Функциональные требования к IT-продукту. Требования, приведенные в "Федеральных критериях", определяют состав и функциональные возможности ТСВ. Требования,
Подготовил : Суфианов Андрей Управление рисками в IT безопасности Научно-практическая конференция "Бизнес-образование как инструмент устойчивого развития.
Ранжирование функциональных требований. Критерии ранжирования функциональных требований широта сферы применения; степень детализации; функциональный.
Южный федеральный университет Технологический Институт Южного Федерального Университета в г. Таганроге Факультет информационной безопасности Кафедра Безопасности.
«Безопасность облаков - опыт оператора связи». 2 Создана фокус группы по облачным вычислениям МСЭ-Т.
Определение достаточности защиты информации М. Левашов 28 МАЯ 2009Г.
Требования к доверенной третьей стороне в интегрированной информационной системе Евразийского экономического союза.
Основные процессы, функции и задачи КСЗИ. Задачи обеспечение надёжной защиты, находящейся в системе информации, т.е. исключение случайного и преднамеренного.
ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ СТАВРОПОЛЬСКИЙ ГОСУДАРСТВЕННЫЙ АГРАРНЫЙ УНИВЕРСИТЕТ.
1 Критерии и классы защищенности средств вычислительной техники и автоматизированных систем Подготовила: студентка гр.И-411 Сартакова Е.Л.
ИНФОРМАЦИОННАЯ БЕЗОПАСНОСТЬ ОФИСА ИНФОРМАЦИОННАЯ БЕЗОПАСНОСТЬ ОФИСА Антивирусные РЕШЕНИЯ Антивирусные РЕШЕНИЯ План обеспечения соответствия как механизм.
Транксрипт:

Безопасность сервисов Дмитрий Истомин, директор по развитию Уральского центра систем безопасности

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

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

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

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

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

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

Модель угроз

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

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

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

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

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

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

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

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

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

Спасибо за внимание!