Сделать безопасно и сертифицировано — ЗАО «ПМ» на DevCon...

Сделать безопасно и сертифицировано

М.А. Авдюнин

А.О. Босенко

Опыт создания приложенийдля государственных органов

РФ

Содержание презентации

Пара слов о безопасной разработке

С чего мы начинали

Вопросы сертификации

Сделать безопасно, сделать сертифицировано

Стандарты документирования

Основные этапыразработкиМодель жизненного цикла ПО – структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач на протяжении жизненного цикла.

Стадия – часть процесса создания ПО, ограниченная определенным временными рамками и заканчивающаяся выпуском конкретного продукта, определяемого заданными для данной стадии требованиями.

Основные стадии жизненного цикла ПО (waterfall model):

Формирование требований

Проектирование

Реализация

Тестирование

Внедрение

Эксплуатация и сопровождение

Software Development Lifecycle (SDLC )

Безопасный код

Функции защиты Защищенные функции

КриптографияAccess Control List

Data Execution Prevention

Address space layout randomization

Минимальные привилегии Защиты от

переполнения

Проверка входных данных

Контроль входных данных

Безопасныйкод≠ безопасная разработка

Адресная арифметика

plTwo = 0x00A02010;

pbOne = (BYTE*)(plTwo + 1);

Небезопасные функции

Strcmp, strcpy …

Неопределенное поведениеstd::printf("%d %d", i,++i);

a[i] = ++i ;

Цель безопасной разработки — повышение качества продукта, защита пользователей:

Сокращение количества уязвимостей

Уменьшение критичности уязвимостей

Снижение риска реализации уязвимостей

= Безопасная разработка цикл безопасной разработки

!Безопасная разработка

Безопасная разработка — это:

Практический подход

Определение и упреждение угроз

Решение проблем безопасности на ранних стадиях

Безопасная реализация (безопасный код)

Безопасность после выпуска ПО

Подходык безопасной разработке

Microsoft SDL OSSA (Oracle Software Security Assurance)

cSDL (Cisco SDL)

vSDL (VMware SDL)

Microsoft SDLИстория развития

Результат — Практики MS SDL

Подготовительный этап. Обучение мерам

безопасности

Практика 1. Обучение основам


Первый этап. Разработка требований

Практика 2. Задание требований


Практика 3. Создание контрольных

условий качества и панели ошибок

Практика 4. Оценка рисков

безопасности и конфиденциальности

Второй этап. Проектирование

Практика 5. Задание требований

проектирования

Практика 6. Уменьшение количества

возможных направлений атак

Практика 7. Моделирование рисков

Третий этап. Реализация

Практика 8. Использование

утвержденных инструментов

Практика 9. Отказ от небезопасных

функций

Практика 10. Статический анализ

Четвертый этап. Проверка

Практика 11. Динамический анализ

программы

Практика 12. Нечеткое тестирование

(фаззинг)

Практика 13. Проверка модели рисков и

возможных направлений атак

Пятый этап. Выпуск

Практика 14. Планирование

реагирования на инциденты

Практика 15. Окончательная

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

Практика 16. Сертификация и

архивация релиза

Пост-SDL. Реагирование

Практика 17. Реагирование

Тестирование на проникновение

Анализ трафика и конфигурационный анализ

Анализ кода приложений

Комплексный подход

Центр мониторинга ИБ

Этапы осознания проблемыи цели работ

Исходные условия

Инструменты (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 документа

Плюсыиминусы стандартов

Достоинства:

Общий язык для всех участников разработки

Максимально полное описание ПО/АС

Недостатки:

Применяемые стандарты морально устарели

В них не отражены отдельные современные тенденции оформления программ и программной документации

Стандарты предполагают многократное дублирование фрагментов программной документации

Как следовать стандартам?

Программируем на лету

Главное — функционал, документация вторична

Всё по ГОСТам

Обычно по настоятельной просьбе заказчика готовится утверждённый договором и ТЗ полный комплект документов, в будущем способный пройти нормоконтроль

Используем стандарты с умом

Если заказчика волнует порядок и организация документации, имеет смысл в общих чертах следовать стандартам, учитывая современные тенденции и практическую целесообразность

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

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

Описание модулей ПО

Перечень интерфейсов и перечень команд для каждого интерфейса, в том числе для интерфейса связи и пользователя, включая заявление об их полноте

Описание интерфейсов пользователя, всех меню и диалогов

Список, значение и действие всех команд, получаемых от клавиатуры, мыши и других устройств ввода информации

Описание реализованной методики идентификации ПО и самих идентификационных признаков

Описание хранимых или передаваемых наборов данных

Описание реализованных методов защиты ПО и данных

Характеристики требуемых системных и аппаратных средств, если эта информация не приведена в руководстве пользователя

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

Вопросы?

Сделать безопасно и сертифицировано — ЗАО «ПМ» на DevCon...

Software

Transcript of Сделать безопасно и сертифицировано — ЗАО «ПМ» на DevCon...