Сделать безопасно и сертифицировано — ЗАО «ПМ» на DevCon 2015
•Télécharger en tant que PPTX, PDF•
0 j'aime•521 vues
Сертификация приложений по требованиям федеральных и отраслевых регуляторов, требованиям компаний (если они есть) — необходимое условие разработки и поставки коробочного решения. Требования потребителей и пользователей современных технологий по функционалу и удобству развиваются значительно быстрее эволюции ограничений. В результате, исследования практической защищенности, если и рассматриваются, то вне темы сертификации, что порождает двойной объем работ и сложности в управлении проектами. Презентация, подготовленная сотрудниками компании «Перспективный Мониторинг» для конференции DevCon 2015, содержит информацию о том, какие практики безопасной разработки позволяют удовлетворить как требования сертификации, так и потребности практической безопасности. Рассматриваются тонкие моменты на стыке этих задач, вопросы, в которых можно опереться на мировой опыт, а также планы регуляторов по развитию требований сертификации. В докладе представлен опыт ЗАО «ПМ» по внедрению безопасной разработки в проекты создания и развития линейки средств защиты информации для сетевого оборудования, мобильных платформ и рабочих станций, подлежащих сертификации по требованиям регуляторов.
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à Сделать безопасно и сертифицировано — ЗАО «ПМ» на DevCon 2015
Similaire à Сделать безопасно и сертифицировано — ЗАО «ПМ» на DevCon 2015 (20)
Сделать безопасно и сертифицировано — ЗАО «ПМ» на DevCon 2015
- 1. Сделать безопасно и сертифицировано М.А. Авдюнин А.О. Босенко Опыт создания приложений для государственных органов РФ
- 2. Содержание презентации Пара слов о безопасной разработке С чего мы начинали Вопросы сертификации Сделать безопасно, сделать сертифицировано Стандарты документирования
- 3. Основные этапы разработки Модель жизненного цикла ПО – структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач на протяжении жизненного цикла. Стадия – часть процесса создания ПО, ограниченная определенным временными рамками и заканчивающаяся выпуском конкретного продукта, определяемого заданными для данной стадии требованиями. Основные стадии жизненного цикла ПО (waterfall model): Формирование требований Проектирование Реализация Тестирование Внедрение Эксплуатация и сопровождение
- 4. Software Development Lifecycle (SDLC )
- 5. Безопасный код Функции защиты Защищенные функции КриптографияAccess Control List Data Execution Prevention Address space layout randomization Минимальные привилегии Защиты от переполнения Проверка входных данных Контроль входных данных Безопасный код ≠ безопасная разработка
- 6. Цель безопасной разработки — повышение качества продукта, защита пользователей: Сокращение количества уязвимостей Уменьшение критичности уязвимостей Снижение риска реализации уязвимостей Безопасная разработка = цикл безопасной разработки
- 7. Безопасная разработка! Безопасная разработка — это: Практический подход Определение и упреждение угроз Решение проблем безопасности на ранних стадиях Безопасная реализация (безопасный код) Безопасность после выпуска ПО
- 8. Подходы к безопасной разработке Microsoft SDL OSSA (Oracle Software Security Assurance) cSDL (Cisco SDL) vSDL (VMware SDL)
- 9. Microsoft SDL История развития Результат — Практики MS SDL Подготовительный этап. Обучение мерам безопасности Практика 1. Обучение основам безопасности Первый этап. Разработка требований Практика 2. Задание требований безопасности Практика 3. Создание контрольных условий качества и панели ошибок Практика 4. Оценка рисков безопасности и конфиденциальности Второй этап. Проектирование Практика 5. Задание требований проектирования Практика 6. Уменьшение количества возможных направлений атак Практика 7. Моделирование рисков Третий этап. Реализация Практика 8. Использование утвержденных инструментов Практика 9. Отказ от небезопасных функций Практика 10. Статический анализ Четвертый этап. Проверка Практика 11. Динамический анализ программы Практика 12. Нечеткое тестирование (фаззинг) Практика 13. Проверка модели рисков и возможных направлений атак Пятый этап. Выпуск Практика 14. Планирование реагирования на инциденты Практика 15. Окончательная проверка безопасности Практика 16. Сертификация и архивация релиза Пост-SDL. Реагирование Практика 17. Реагирование
- 10. Содержание презентации Пара слов о безопасной разработке С чего мы начинали Вопросы сертификации Сделать безопасно, сделать сертифицировано Стандарты документирования
- 11. Тестирование на проникновение Анализ трафика и конфигурационный анализ Анализ кода приложений Комплексный подход Центр мониторинга ИБ Этапы осознания проблемы и цели работ
- 12. Исходные условия Инструменты (nmap, nessus, metaspliot, burp, intercepter…) Методики и практики (OWASP, PTES…) Ресурсы и блоги (exploit-db.com, securitylab.ru, nmap.org, packetstormsecurity.com, twitter) Личный опыт участников процесса (исследователи/аналитики) Желание попробовать что-то новое
- 13. К чему мы пришли? • Обучение MS SDL • Анализ рисков • Построение поверхности атак • Моделирование угроз • Статический анализ • Динамический анализ • Актуализация поверхности атак и модели угроз • Тестирование на проникновение • Мониторинг уязвимостей
- 14. Центр мониторинга Система мониторинга уязвимостей сторонних компонентов ПО Мониторинг уязвимостей Сбор и анализ информации по уязвимостям компонентов ПО Выявление актуальных угроз в ПО и оборудовании Система обработки Регистрация уязвимостей, идентификация, оповещение Отслеживание жизненного цикла уязвимостей в ПО, история Визуализация управления уязвимостямиИсточники • Информационные системы • Компоненты ПО Серверы АРМ Аналитика уязвимостей ПО Интернет Степень уязвимости Январь-май 2015, шт Критическая 65 Высокая 165 Средняя 72 Низкая 2 По результатам исследованиям в трёх продуктах
- 15. Центр Мониторинга ЗАО «ПМ»
- 17. Содержание презентации Пара слов о безопасной разработке С чего мы начинали Вопросы сертификации Сделать безопасно, сделать сертифицировано Стандарты документирования
- 18. Сертификация — СЗИ (ФСТЭК России) СКЗИ (ФСБ России) ПО АСУ ТП (Минэнерго России) ПО атомных станций (Росатом) Медицинские ИС (Минздрав России) ПО средств связи (Минкомсвязь России) ПО искусственного интеллекта … 18 — одна из форм подтверждения соответствия объектов требованиям технических регламентов, положениям стандартов или условиям договоров. Когда нужна сертификация ПО?
- 19. Требования законодательства/регулятора Отраслевые стандарты Корпоративные стандарты Добровольное желание организации 19 Требования к сертификации на примере сертификации СЗИ
- 20. Классификация видов ИС с точки зрения требований к информационной безопасности
- 21. В процессе сертификации участвуют: Федеральный орган по сертификации (ФСТЭК России) Орган по сертификации Заявитель Испытательная лаборатория 21 Сертификация СЗИ (ФСТЭК)
- 22. Оформление Заявки на сертификацию Оформление Решения на проведение сертификации Заключение Договора на проведение сертификационных испытаний Подготовка исходных данных Проведение сертификационных испытаний Оформление Протоколов сертификационных испытаний и Технических заключений Заключение Договора о проведении экспертизы результатов сертификационных испытаний в Органе по сертификации Экспертиза результатов сертификационных испытаний Оформление Сертификата 22 Этапы сертификации СЗИ (ФСТЭК)
- 23. Контроль состава и содержания документа- ции Контроль исходного состояния ПО Статический анализ исходных текстов программ Динамичес- кий анализ исходных текстов программ Отчетность Контроль отсутствия НДВ Процесс сертификации на примере НДВ
- 24. Содержание презентации Пара слов о безопасной разработке С чего мы начинали Вопросы сертификации Сделать безопасно, сделать сертифицировано Стандарты документирования
- 26. Сертификация и безопасная разработка?
- 27. Своевременное начало сотрудничества с экспертной организацией позволит выполнить максимальное число её требований на начальных этапах разработки, что, в свою очередь даст возможность: Упростить процесс полу- чения сертификата Ускорить его Сократить общий срок раз- работки, избежав отдель- ного этапа сертификации Сертификация и безопасная разработка!
- 28. Разработка и сертификация Разработка, затем сертификация vs Разработка и сертификация
- 29. Для прохождения сертификации разработчик СКЗИ должен предоставить экспертной организации сопроводительные материалы, которые стоит готовить в ходе всего жизненного цикла разработки. Обычно они включают: Описание архитектуры ПО Функциональную схему Алгоритмы наиболее значимых процедур и функций Перечень всех модулей и их значение Перечень всех процедур, функций, констант и переменных и их назначение Все исходные тексты с комментариями Средства разработки для работы с исходными текстами ПО Конфигурационные файлы для средств разработки Средства компиляции, методика и порядок сборки итогового проекта ПО Схемы тестирования сертифицируемого оборудования и всех заявленных функциональных возможностей на сертифицируемом оборудовании Сертификация СКЗИ (ФСБ)
- 30. Содержание презентации Пара слов о безопасной разработке С чего мы начинали Вопросы сертификации Сделать безопасно, сделать сертифицировано Стандарты документирования
- 31. Стандарты документирования Цель документирования – аккумуляция, сохранение и передача технических сведений о программном продукте для участников процесса разработки ПО. Для достижения этой цели документация должна быть: Понятной Информативной Удобной для всех участников процесса разработки Для соответствия этим требованиям существуют Стандарты.
- 32. Стандарты ГОСТ 34.ххх «Стандарты информационной технологии» — 6 документов ГОСТ 19.ххх «Единая система программной документации» (ЕСПД) — 30 документов ГОСТ для автоматизированных систем в защищенном исполнении (Р 51583-2014, Р 51624-2000) ГОСТ Р ИСО (9127-94, 15910-2002, 12207-99) ГОСТ 2.ххх «Единая система конструкторской документации» — 64 документа
- 33. Плюсы и минусы стандартов Достоинства: Общий язык для всех участников разработки Максимально полное описание ПО/АС Недостатки: Применяемые стандарты морально устарели В них не отражены отдельные современные тенденции оформления программ и программной документации Стандарты предполагают многократное дублирование фрагментов программной документации
- 34. Как следовать стандартам? Программируем на лету Главное — функционал, документация вторична Всё по ГОСТам Обычно по настоятельной просьбе заказчика готовится утверждённый договором и ТЗ полный комплект документов, в будущем способный пройти нормоконтроль Используем стандарты с умом Если заказчика волнует порядок и организация документации, имеет смысл в общих чертах следовать стандартам, учитывая современные тенденции и практическую целесообразность
- 35. Документация и сертификация Документация, подаваемая заявителем для прохождения процедуры добровольной сертификации программного обеспечения должна отображать следующую информация о ПО: Официальное название ПО Описание структуры программного обеспечения, выполняемых им функций, в том числе последовательность обработки данных Описание метрологически значимых функций и параметров ПО, существенных для их работы Описание реализованных в ПО вычислительных алгоритмов, а также их блок-схемы Описание модулей ПО Перечень интерфейсов и перечень команд для каждого интерфейса, в том числе для интерфейса связи и пользователя, включая заявление об их полноте Описание интерфейсов пользователя, всех меню и диалогов Список, значение и действие всех команд, получаемых от клавиатуры, мыши и других устройств ввода информации Описание реализованной методики идентификации ПО и самих идентификационных признаков Описание хранимых или передаваемых наборов данных Описание реализованных методов защиты ПО и данных Характеристики требуемых системных и аппаратных средств, если эта информация не приведена в руководстве пользователя
Notes de l'éditeur
- Основные этапы жизненного цикла ПО всегда одни и те же. Не стоит ли их регламентировать, чтобы писать безопасный код?
- Вот не одни мы так подумали.
- Многим программистам кажется, что безопасная разработка — это безопасный код. На самом деле, это не так, безопасная разработка — это безопасный код и много чего ещё.
- Безопасная разработка — это в первую очередь цикл безопасной разработки
- Куча умных людей сидела, сидела и родила аж несколько концепций безопасной разработки, Майкрософт не единственная
- Майкрософт прошёл длинный путь, но нам не нужно его повторять, квинтессенция SDL — практики — может внедрить каждый. Да и не только может. Внедрение практик безопасной разработки — необходимость. Как мы пришли к осознанию этого расскажет мой коллега, Андрей Босенко.
- Добрый день, уважаемые коллеги! Меня зовут Босенко Андрей, я исследователь компании «Перспективный мониторинг».
- Естественно, все виды работ, которые мы проводит, служат какой-либо цели: Например, тестирование на проникновение, это самый быстрый способ проверить фактический уровень защищённости какой-либо информационной системы/программного продукта и т.д. Однако, в данном случае, не обеспечивается полнота покрытия. Если конечно пентест не длится несколько месяцев Анализ трафика и анализ конфигураций, это один из наиболее безболезненных видов исследований, однако он может потребовать предварительной подготовки и более длителен по времени нежели тестирование на проникновение. С определенного момента и по достижении/получении определённого опыта в перечень работ также добавился анализ кода приложений. Такой вид работ подразумевает относительно длительное время исследований и как правило подразумевает детальное изучение продукта. Комплексный подход, как правило характерен для поиска максимально количества уязвимостей и обеспечения полноты покрытия. Сюда же могут быть добавлены работы, например, по оценке соответствия требованиям каких-либо НПА, или, например, по разработке на основе результатов исследований моделей угроз и нарушителя или технического задания на модернизацию/улучшение. Логическим продолжением всех этих работ было создание Центра мониторинга ИБ. Как уже говорилось ранее, на определённых этапах мы поняли, что для поддержания уровня защищенности нам необходим непрерывный мониторинг состояния защищенности, и что немаловажно информации о новых угрозах/уязвимостях/векторах атак и т.д. Хочу отметить, что применительно к группе компаний Инфотекса, все эти работы проводились параллельно с работами по сертификации продуктов.
- Естественно, мы начинали эти работы не с чистого листа, и изначально это были: Свободно распространяемые инструментальные средства проведения разных типов исследований (сюда входят всевозможные сканеры, средства эксплуатации уязвимостей) Методики и практики для проведения исследований (конечно со временем мы начали разрабатывать и собственные методики для различных работ и исследований продуктов/протоколов/служб/типовых ИС и т.д., но изначально в качестве основы и подхода были использованы такие методики как owasp, ptes Очень много полезной информации мы подчерпнули, да и сейчас узнаём из специализированных ресурсов и личных блогов по безопасности. Теперь мониторинг таких источников у нас поставлен на постоянную основу, но об этом я расскажу чуть позже. Немаловажным является уже имеющийся личный опыт у участников процесса, причём это может быть как знание и умение работать с каким-либо конкретным инструментом/ фреймворком/ средством или системой защиты, так и знание нормативной документации и правил формирования моделей угроз/нарушителя. Ну и последнее условие, это желание и заинтересованность всех участников процесса попробовать для себя что-то новое или, например, выступить не со стороны защиты, а со стороны нападения.
- Продолжая тему выступления моего коллеги, я бы хотел рассказать, как мы пришли к тому, что безопасная разработка — это правильно и внедрение практик SDL для нас необходимо. Также мы коснёмся темы сертификации разрабатываемого ПО. Итак, с чего мы начинали. Где-то в 2011 году в группе компаний Инфотекс было создано подразделение для реализации вопросов «практической ИБ» и исследования продуктов и сервисов группы компаний. Естественно, в поле интересов попали и продукты Инфотекс подлежащие сертификации по требованиям безопасности. С того момента, и по настоящее время мы фактически специализируемся на следующих направлениях: Тестирование на проникновение (внешнее, внутреннее) Анализ трафика и анализ конфигураций Анализ кода приложений (статический, динамический) Комплексный аудит ИБ Создание Центра мониторинга ИБ Последний пункт является своего рода агрегацией всех накопленных за это время знаний и опыта по всем направления.
- Ещё одной интересной функцией созданного Центра мониторинга является мониторинг уязвимостей, возникающих в компонентах программного обеспечения. Суть состоит в том, что какой-либо продукт группы компаний разбивается на компоненты, ставится на контроль в Центре мониторинга и для них непрерывно осуществляется поиск новых уязвимостей или угроз. Для достижения этой цели, были решены следующие задачи: Сформирован постоянно пополняемый перечень источников информации об уязвимостях в компонентах, куда вошли как всем известные ресурсы, такие как CVEDetail, Securitylab, rapid7 и т.д., так и различные форумы (их ветки), хакерские сообщества, твиттер аккаунты и т.д. Автоматизирован процесс получения информации из источников и регистрация вновь найденных публикаций об уязвимостях и оповещение об этом разработчиков ПО Отслеживание жизненного цикла уязвимости, тут особо интересны сообщения от авторов компонентов о фиксе данной уязвимости. Я уже говорил, что все перечисленные работы ведутся в том числе, и для продуктов подлежащих обязательной сертификации, поэтому перейдём к тебе сертификации.
- Естественно, все виды работ, которые мы проводит, служат какой-либо цели: Например, тестирование на проникновение, это самый быстрый способ проверить фактический уровень защищённости какой-либо информационной системы/программного продукта и т.д. Однако, в данном случае, не обеспечивается полнота покрытия. Если конечно пентест не длится несколько месяцев Анализ трафика и анализ конфигураций, это один из наиболее безболезненных видов исследований, однако он может потребовать предварительной подготовки и более длителен по времени нежели тестирование на проникновение. С определенного момента и по достижении/получении определённого опыта в перечень работ также добавился анализ кода приложений. Такой вид работ подразумевает относительно длительное время исследований и как правило подразумевает детальное изучение продукта. Комплексный подход, как правило характерен для поиска максимально количества уязвимостей и обеспечения полноты покрытия. Сюда же могут быть добавлены работы, например, по оценке соответствия требованиям каких-либо НПА, или, например, по разработке на основе результатов исследований моделей угроз и нарушителя или технического задания на модернизацию/улучшение. Логическим продолжением всех этих работ было создание Центра мониторинга ИБ. Как уже говорилось ранее, на определённых этапах мы поняли, что для поддержания уровня защищенности нам необходим непрерывный мониторинг состояния защищенности, и что немаловажно информации о новых угрозах/уязвимостях/векторах атак и т.д. Хочу отметить, что применительно к группе компаний Инфотекса, все эти работы проводились параллельно с работами по сертификации продуктов.
- Так, когда же может потребоваться сертификация. Основных вариантов тут несколько: требования законодательства РФ (законы, постановления правительства) приказы регулятора (например, ФСТЭК, ФСБ) отраслевые стандарты (например, приказы отраслевых министерств) внутрикорпоративные стандарты (например, РЖД или ) или добровольное желание организации Таким образом, если для выполнения мер по защите информации любым из вышеперечисленных пунктов установлено применение сертифицированных средств, необходима сертификация.
- Так, когда же может потребоваться сертификация. Основных вариантов тут несколько: требования законодательства РФ (законы, постановления правительства) приказы регулятора (например, ФСТЭК, ФСБ) отраслевые стандарты (например, приказы отраслевых министерств) внутрикорпоративные стандарты (например, РЖД или ) или добровольное желание организации Таким образом, если для выполнения мер по защите информации любым из вышеперечисленных пунктов установлено применение сертифицированных средств, необходима сертификация.
- Так откуда же берутся требования по сертификации средств защиты информации, в том числе программных. Глобально вся информация в нашей стране делится на ту, к который доступ не может быть ограничен и к которой может. На данном слайде изображена классификация информационных систем в зависимости от вида обрабатываемой информации. К каждой из этих видов информационных систем применяется свой набор регулирующих нормативно-правовых актов и требований. В некоторых ИС набор требований схож, как например в государственных информационных системах и информационных системах персональных данных. Зелёным выделены те виды информационных систем, в которых требования к наличию сертифицированных средств наиболее часты. Красным выделены информационные системы обрабатывающие сведения, отнесённые к государственной тайне, их мы рассматривать не будем.
- Процесс сертификации, представляет из себя определённую последовательность действий, которые должны выполнить организации.
- Заявитель (организация - разработчик, изготовитель или поставщик СрЗИ) должен иметь ЛИЦЕНЗИЮ ФСТЭК России на соответствующий вид деятельности. Фактически все этапы проведения сертификационных испытаний можно разделить на 3 большие группы, а именно: Оформление Заявки на сертификацию (основными моментами тут являются подготовка заявки, выбор испытательной лаборатории и назначении органа по сертификации, согласовании программы и методики испытаний и т.д.) Само проведение сертификационных испытаний Оформление сертификата На каждом из этих этапов существует строго определённая последовательность действий, которую должны выполнить вовлечённые в процесс лица.
- Для примера рассмотрим, достаточно распространённую систему сертификации, на отсутствие НДВ. Недекларированные возможности - функциональные возможности ПО, не описанные или не соответствующие описанным в документации, при использовании которых возможно нарушение конфиденциальности, доступности или целостности обрабатываемой информации Данный контроль состоит из 4 или 5 пунктов, которые необходимо выполнить. Четыре пункта являются обязательными, в свою очередь Динамический анализ исходных текстов является необходимым если контроль НДВ проводится на 2-й и выше уровень контроля. (3.3.1.) Контроль состава и содержания документации В состав документации, представляемой, заявителем должны входить: Спецификация (ГОСТ 19 . 202-78), содержащая сведения о составе ПО и документации на него; Описание программы (ГОСТ 19.402-78) содержащее основные сведения о составе (с указанием контрольных сумм файлов, входящих в состав ПО), логической структуре и среде функционирования ПО, а также описание методов, приемов и правил эксплуатации средств технологического оснащения при создании ПО; Пояснительная записка (ГОСТ 19.404-79), содержащая основные сведения о назначении компонентов, входящих в состав ПО, параметрах обрабатываемых наборов данных (подсхемах баз данных), формируемых кодах возврата, описание используемых переменных, алгоритмов функционирования и т.п.; Описание применения (ГОСТ 19.502-78) содержащее сведения о назначении ПО, области применения, применяемых методах, классе решаемых задач, ограничениях при применении, минимальной конфигурации технически средств, среде функционирования и порядке работы. Исходные тексты программ (ГОСТ 19.401-78), входящих в состав ПО. Для ПО импортного производства состав документации может отличаться от требуемого, однако, содержание должно соответствовать требованиям указанных ГОСТ. (3.3.2.) Контроль исходного состояния ПО Контроль заключается в фиксации исходного состояния ПО и сравнении полученных результатов с приведенными в документации. Результатами контроля исходного состояния ПО должны быть рассчитанные уникальные значения контрольных сумм загрузочных модулей и исходных текстов программ, входящих в состав ПО. Контрольные суммы должны рассчитываться для каждого файла, входящего в состав ПО. (3.3.3.) Статический анализ исходных текстов программ Статический анализ исходных текстов программ должен включать следующие технологические операции: контроль полноты и отсутствия избыточности исходных текстов ПО на уровне файлов; контроль полноты и отсутствия избыточности исходных текстов ПО на уровне функциональных объектов (процедур); контроль связей функциональных объектов (модулей, процедур, функции) по управлению; контроль связей функциональных объектов (модулей, процедур, функций) по информации; контроль информационных объектов различных типов (например, локальных переменных, глобальных переменных, внешних переменных и т.п.); формирование перечня маршрутов выполнения функциональных объектов (процедур, функций); контроль соответствия исходных текстов ПО его объектному (загрузочному) коду. (3.3.4.) Динамический анализ исходных текстов программ Динамический анализ исходных текстов программ должен включать следующие технологические операции: контроль выполнения функциональных объектов (процедур, функций); сопоставление фактических маршрутов выполнения функциональных объектов (процедур, функций) и маршрутов, построенных в процессе проведения статического анализа. (3.3.5.) Отчетность По окончании испытаний оформляется отчет (протокол), содержащий результаты: контроля исходного состояния ПО; контроля полноты и отсутствия избыточности исходных текстов контролируемого ПО на уровне файлов; контроля полноты и отсутствия избыточности исходных текстов контролируемого ПО на уровне функциональных объектов (процедур); контроля связей функциональных объектов (модулей, процедур, функций) по управлению; контроля связей функциональных объектов (модулей, процедур, функций) по информации; контроля информационных объектов различных типов (например, локальных переменных, глобальных переменных, внешних переменных и т.п.); формирования перечня маршрутов выполнения функциональных объектов (процедур, функций); контроля выполнения функциональных объектов (процедур, функции); сопоставления фактических маршрутов выполнения функциональных объектов (процедур, функций) и маршрутов, построенных в процессе проведения статического анализа; контроля соответствия исходных текстов ПО его объектному (загрузочному) коду.
- Но как связаны безопасная разработка и сертификация? Возможно ли совместить SDL и требования регуляторов?
- Многим кажется, что сертификация несовместима с требованиями SDL. Так ли это?
- Некоторые понимают, что без сертификации никуда и пытаются впихнуть её между какими-то из этапов SDL. Правильно ли это?
- Не совсем. Сертификация должна проникать в разработку на всех её этапах. На примере сертификации СКЗИ. В ходе сертификации СКЗИ проходит проверку в экспертной организации для получения положительного заключение 8-го Центра ФСБ о выполнении требований по безопасности. Сертификация занимает достаточно длительное время и требует подготовительной работы со стороны разработчика. Своевременное начало сотрудничества с экспертной организацией позволит выполнить максимальное количество её требований на начальных этапах разработки, что позволит упростить и ускорить процесс получения сертификата.
- Понятно, что гораздо проще готовить все эти материалы по ходу работ, совмещая требования регуляторов с требования практик безопасной разработки, а не делать эти работы последовательно.
- Понятно, что гораздо проще готовить все эти материалы по ходу работ, совмещая требования регуляторов с требования практик безопасной разработки, а не делать эти работы последовательно.
- Другой вопрос, который так же стоит учитывать в ходе цикла безопасной разработке ПО, предполагаемого для сертификации — это документирование
- Почему документирование — это важно?
- Стандарты Требования к составу и содержанию эксплуатационной документации на автоматизированную систему приведены в ГОСТ серии 34. Требования к составу и содержанию эксплуатационной документации на программное обеспечение приведены в ГОСТ серии 19. Есть спец ГОСТ для автоматизированных систем в защищенном исполнении. ГОСТ Р 51583-2014 «Защита информации. Порядок создания автоматизированных систем в защищенном исполнении. Общие положения», ГОСТ Р 51624-2000 "Защита информации. Автоматизированные системы в защищенном исполнении. Общие положения". ЕСПД – комплекс государственных стандартов, устанавливающих правила разработки и оформления программ и программной документации. Стандарты позволяют вносить в комплект документации на ПП дополнительные виды, исходя из требований заказчика, допустимы некоторые изменения как в структуре, так и в содержании установленных видов ПД. Стандарты ЕСПД носят рекомендательный характер (в соответствии с Законом РФ "О стандартизации" эти стандарты становятся обязательными на контрактной основе – т.е. при ссылке на них в договоре на разработку/(поставку ПП).