3. Какой он – безопасный сервис? Сервис – это автоматизация бизнес-процесса. Безопасный сервис – это безопасная автоматизация бизнес-процесса. Безопасный сервис – это безопасная автоматизация безопасного бизнес-процесса. Безопасно = риски приемлемы VS Безопасно = функционально! Безопасно для кого? Владелец или пользователь?
9. Как сделать сервис безопасным? Пример методики разработки: Secure Development Lifecycle Стадии: 1. Формирование требований (Reqiurements) 2. Проектирование ( Design ) 3. Реализация ( Implementation) 4. Проверка ( Verification ) 5. Выпуск ( Release) 6. Поддержка ( Response )
10.
11. ISO 15408 Common Criteria Сервис – это автоматизация бизнес-процесса. Безопасный сервис – это безопасная автоматизация бизнес-процесса. Безопасный сервис – это безопасная автоматизация безопасного бизнес-процесса. Безопасное состояние – риски приемлемы.
Рассматриваем широкое понятие сервиса. Сервис – это …, то есть любая автоматизированная система – сервис, отдельно стоящее ПО, клиент-сервер, web- приложение, SaaS. Кто формирует требования, владелец или пользователь? Пример: заказ такси. Возможность отмены заказа. Два уровня – безопасность процесса и его реализации. Кто должен заниматься?
Деньги – банки, любые платные сервисы Время – транспорт, такси Здоровье – доставка лекарств Личные данные – почта, CRM , календарь, электронная очередь
Анализ процессов – это тоже трудоемкая задача. Нужны специфические специалисты. Кроме того, необходимо решать противоречия безопасности пользователя и владельца.
Для построения безопасного сервиса необходимо сначала определить функциональную схему
Модель угроз определяет список (исчерпывающий!) угроз, приводящих к рискам информационной безопасности. Например, можно использовать модель STRIDE для построения МУ. Согласно страйд, угрозы сервиса делятся на 6 типов: S – возможность залогиниться под чужой учеткой. Например, авторизация по IP- адресу. На каждом шаге необходимо следить за отсутствием таких возможностей. T – Насколько правильно распределены права к ресурсам. Например – возможность админа поменять данные R – отказ от платежа I – временные данные хранятся в папке, куда есть доступ D – DDoS E – возможность поднять уровень прав.
На каждую выделенную красную букву необходимо разрабатывать контрмеры, или принять угрозу. Принять угрозу, и не рассмотреть ее – это разные вещи!
На этапе проектирования – модель угроз (тестирование архитектуры). НА этапе реализации – тестирование кода ( fuzzing) .
Кроме того, чтобы сделать приложение безопасным, необходимо убедить в этом пользователей. Тех, которые заинтересованы в этом. Для этого необхъодимо понимать, а что ожидает пользователь и подстраиваться под его требования.