Сертификация и безопасная разработка!

Сделать безопасно и
сертифицировано
Опыт создания приложений
для государственных органов РФ
М.А. Авдюнин
А.О. Босенко
Содержание презентации
Пара слов о безопасной разработке
С чего мы начинали
Вопросы сертификации
Сделать безопасно, сделать сертифицировано
Стандарты документирования
Основные этапы разработки
Модель жизненного цикла ПО – структура, определяющая последовательность
выполнения и взаимосвязи процессов, действий и задач на протяжении жизненного
цикла.
Стадия – часть процесса создания ПО, ограниченная определенным временными
рамками и заканчивающаяся выпуском конкретного продукта, определяемого
заданными для данной стадии требованиями.
Основные стадии жизненного цикла ПО (waterfall model):
Формирование требований
Проектирование
Реализация
Тестирование
Внедрение
Эксплуатация и сопровождение
Software Development Lifecycle (SDLC )
Безопасный код ≠ безопасная разработка
Безопасный код
Функции защиты
Data Execution
Prevention
Минимальные
привилегии
Access Control List
Криптография
Защищенные функции
Защиты от
переполнения
Контроль
входных
данных
Проверка входных данных
Address space layout randomization
Безопасная разработка = цикл
безопасной разработки
Цель безопасной разработки — повышение качества продукта, защита пользователей:
Сокращение количества уязвимостей
Уменьшение критичности уязвимостей
Снижение риска реализации уязвимостей
Безопасная разработка!
Безопасная разработка — это:
Практический подход
Определение и упреждение угроз
Решение проблем безопасности на ранних
стадиях
Безопасная реализация (безопасный код)
Безопасность после выпуска ПО
Подходы к безопасной разработке
cSDL (Cisco SDL)
vSDL (VMware SDL)
Microsoft SDL
OSSA (Oracle Software Security Assurance)
Microsoft SDL
История развития
Результат — Практики MS SDL
Практика 9. Отказ от небезопасных
функций
Подготовительный этап. Обучение мерам
безопасности
Практика 1. Обучение основам
безопасности
Первый этап. Разработка требований
Практика 2. Задание требований
безопасности
Практика 3. Создание контрольных
условий качества и панели ошибок
Практика 4. Оценка рисков
безопасности и конфиденциальности
Второй этап. Проектирование
Практика 10. Статический анализ
Четвертый этап. Проверка
Практика 11. Динамический анализ
программы
Практика 12. Нечеткое тестирование
(фаззинг)
Практика 13. Проверка модели рисков и
возможных направлений атак
Пятый этап. Выпуск
Практика 14. Планирование
реагирования на инциденты
Практика 5. Задание требований
Практика 15. Окончательная
проектирования
проверка безопасности
Практика 6. Уменьшение количества
возможных направлений атак
Практика 16. Сертификация и
архивация релиза
Практика 7. Моделирование рисков
Пост-SDL. Реагирование
Третий этап. Реализация
Практика 17. Реагирование
Практика 8. Использование
утвержденных инструментов
Содержание презентации
Пара слов о безопасной разработке
С чего мы начинали
Вопросы сертификации
Сделать безопасно, сделать сертифицировано
Стандарты документирования
Этапы осознания проблемы
и цели работ
Тестирование на проникновение
Анализ трафика и конфигурационный анализ
Анализ кода приложений
Комплексный подход
Центр мониторинга ИБ
Исходные условия
Инструменты (nmap, nessus, metaspliot, burp,
intercepter…)
Методики и практики (OWASP, PTES…)
Ресурсы и блоги (exploit-db.com, securitylab.ru,
nmap.org, packetstormsecurity.com, twitter)
Личный опыт участников процесса
(исследователи/аналитики)
Желание попробовать что-то новое
К чему мы пришли?
•
Обучение MS SDL
•
Динамический анализ
•
Анализ рисков
•
•
Построение поверхности атак
Актуализация поверхности атак
и модели угроз
•
Моделирование угроз
•
Тестирование на
проникновение
•
Статический анализ
•
Мониторинг уязвимостей
Центр мониторинга
Система мониторинга уязвимостей сторонних компонентов ПО
Степень
уязвимости
Январь-май
2015, шт
Критическая
65
Высокая
165
Средняя
72
Низкая
2
Сбор и анализ информации по
уязвимостям компонентов ПО
Мониторинг
уязвимостей
Выявление актуальных угроз в ПО и
оборудовании
По результатам исследованиям в трёх
продуктах
АРМ
Аналитика
уязвимостей ПО
Регистрация уязвимостей,
идентификация, оповещение
Система
обработки
Интернет
Серверы
Источники
• Информационные
системы
• Компоненты ПО
Отслеживание жизненного цикла
уязвимостей в ПО, история
Визуализация управления уязвимостями
Центр Мониторинга ЗАО «ПМ»
Безопасная разработка
и сертификация
Сертификация
Содержание презентации
Пара слов о безопасной разработке
С чего мы начинали
Вопросы сертификации
Сделать безопасно, сделать сертифицировано
Стандарты документирования
Сертификация —
— одна из форм подтверждения соответствия объектов
требованиям технических регламентов, положениям
стандартов или условиям договоров.
Когда нужна сертификация ПО?
СЗИ (ФСТЭК России)
СКЗИ (ФСБ России)
ПО АСУ ТП (Минэнерго
России)
ПО атомных станций
(Росатом)
Медицинские ИС
(Минздрав России)
…
ПО средств связи
(Минкомсвязь России)
ПО искусственного
интеллекта
18
Требования к сертификации на примере
сертификации СЗИ
Требования законодательства/регулятора
Отраслевые стандарты
Корпоративные стандарты
Добровольное желание организации
19
Классификация видов ИС с точки зрения требований
к информационной безопасности
Сертификация СЗИ (ФСТЭК)
В процессе сертификации участвуют:
Федеральный орган по сертификации
(ФСТЭК России)
Орган по сертификации
Заявитель
Испытательная лаборатория
21
Этапы сертификации СЗИ (ФСТЭК)
Оформление Заявки на сертификацию
Оформление Решения на проведение сертификации
Заключение Договора на проведение сертификационных
испытаний
Подготовка исходных данных
Проведение сертификационных испытаний
Оформление Протоколов сертификационных испытаний и
Технических заключений
Заключение Договора о проведении экспертизы результатов
сертификационных испытаний в Органе по сертификации
Экспертиза результатов сертификационных испытаний
Оформление Сертификата
22
Процесс сертификации на примере НДВ
Контроль
состава и
содержания
документации
Контроль
исходного
состояния
ПО
Статический
анализ
исходных
текстов
программ
Динамический анализ
исходных
текстов
программ
Контроль отсутствия НДВ
Отчетность
Содержание презентации
Пара слов о безопасной разработке
С чего мы начинали
Вопросы сертификации
Сделать безопасно, сделать сертифицировано
Стандарты документирования
Сертификация или безопасная
разработка?
Сертификация и безопасная разработка?
Сертификация и безопасная разработка!
Своевременное начало сотрудничества с
экспертной
организацией
позволит
выполнить максимальное число её
требований
на
начальных
этапах
разработки, что, в свою очередь даст
возможность:
Упростить процесс получения сертификата
Ускорить его
Сократить общий срок разработки, избежав отдельного этапа сертификации
Разработка, затем сертификация
vs
Разработка и сертификация
Разработка и
сертификация
Сертификация СКЗИ (ФСБ)
Для прохождения сертификации разработчик СКЗИ должен предоставить
экспертной организации сопроводительные материалы, которые стоит
готовить в ходе всего жизненного цикла разработки.
Обычно они включают:
Описание архитектуры ПО
Функциональную схему
Алгоритмы наиболее значимых процедур и функций
Перечень всех модулей и их значение
Перечень всех процедур, функций, констант и переменных и их назначение
Все исходные тексты с комментариями
Средства разработки для работы с исходными текстами ПО
Конфигурационные файлы для средств разработки
Средства компиляции, методика и порядок сборки итогового проекта ПО
Схемы тестирования сертифицируемого оборудования и всех заявленных функциональных возможностей на сертифицируемом оборудовании
Содержание презентации
Пара слов о безопасной разработке
С чего мы начинали
Вопросы сертификации
Сделать безопасно, сделать сертифицировано
Стандарты документирования
Стандарты документирования
Цель документирования – аккумуляция, сохранение и
передача технических сведений о программном
продукте для участников процесса разработки ПО.
Для достижения этой цели документация должна быть:
Понятной
Информативной
Удобной для всех участников процесса
разработки
Для соответствия
Стандарты.
этим
требованиям
существуют
Стандарты
ГОСТ 34.ххх «Стандарты информационной
технологии» — 6 документов
ГОСТ 19.ххх «Единая система программной
документации» (ЕСПД) — 30 документов
ГОСТ для автоматизированных систем в защищенном
исполнении (Р 51583-2014, Р 51624-2000)
ГОСТ Р ИСО (9127-94, 15910-2002, 12207-99)
ГОСТ 2.ххх «Единая система конструкторской
документации» — 64 документа
Плюсы и минусы стандартов
Достоинства:
Общий язык для всех участников разработки
Максимально полное описание ПО/АС
Недостатки:
Применяемые стандарты морально устарели
В них не отражены отдельные современные тенденции
оформления программ и программной документации
Стандарты предполагают многократное дублирование
фрагментов программной документации
Как следовать стандартам?
Программируем на лету
Главное — функционал, документация вторична
Всё по ГОСТам
Обычно по настоятельной просьбе заказчика готовится
утверждённый договором и ТЗ полный комплект
документов, в будущем способный пройти нормоконтроль
Используем стандарты с умом
Если заказчика волнует порядок и организация
документации, имеет смысл в общих чертах следовать
стандартам, учитывая современные тенденции и
практическую целесообразность
Документация и сертификация
Документация, подаваемая заявителем для прохождения процедуры добровольной
сертификации программного обеспечения должна отображать следующую
информация о ПО:
Официальное название ПО
Описание структуры программного обеспечения, выполняемых им функций, в том
числе последовательность обработки данных
Описание метрологически значимых функций и параметров ПО, существенных для их
работы
Описание реализованных в ПО вычислительных алгоритмов, а также их блок-схемы
Описание модулей ПО
Перечень интерфейсов и перечень команд для каждого интерфейса, в том числе для интерфейса связи и
пользователя, включая заявление об их полноте
Описание интерфейсов пользователя, всех меню и диалогов
Список, значение и действие всех команд, получаемых от клавиатуры, мыши и других устройств ввода информации
Описание реализованной методики идентификации ПО и самих идентификационных признаков
Описание хранимых или передаваемых наборов данных
Описание реализованных методов защиты ПО и данных
Характеристики требуемых системных и аппаратных средств, если эта информация не приведена в руководстве пользователя
Спасибо за внимание!
Вопросы?