Про стандарты безопасной разработки ФСТЭК

01.11.19 прошло совещание во ФСТЭК касательно обсуждения безопасной разработки

Выделен отдельный программный комитет ПК4 по безопасной разработке в составе ТК362.

Обсуждался проект стандарта "Руководство по безопасной разработке". Стандарт предлагает рекомендации по внедрению требований и процессам ГОСТ 56939.

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

Планируемые стандарты :
1. Руководство по безопасной разработке
2. Руководство по оценке безопасности разработки по
3. Руководство по статическому анализу
4. Руководство по динамическому анализу
5. Доверенный компилятор
6. Пересмотр ГОСТ 56939

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

Система непрерывной интеграции (CI) хоть и не упомянается в ГОСТ 56939, но является его хребтом.

Статический анализ и фаззинг должны быть подключены к CI конвееру

При сертификации лаборатория проверяет соответствие требованиям уровня доверия. Тоесть не полное соответствие ГОСТ

Все материалы с совещания:
https://vk.com/secdevops?w=wall-190263496_16

#law #dev

"Information Security
Management through
Reflexive Security" by CSA

Документ определяет понятие рефлексивной безопасности (Reflexive Security) как новый подход к управлению ИБ, основанный на принципах Agile и DevOps. Reflexive Security подчеркивает безопасность между организационными ролями, которая реагирует на внешние и внутренние угрозы гибким и динамичным способом. Reflexive Security призван стать новой стратегией управления информационной безопасностью, которая является динамичной, интерактивной, эффективной и целостной по сравнению с традиционными (СУИБ)

#law #report #dev #ops

Про стандартизацию ФСТЭК и сертификацию процессов безопасной разработки

Помните один из первых постов этого канала? https://t.iss.one/sec_devops/20 Отечественная стандартизация безопасной разработки продолжает набирать обороты. В пятницу ФСТЭК России опубликовал на regulation.gov Порядок сертификации процессов безопасной разработки программного обеспечения средств защиты информации :

https://regulation.gov.ru/Regulation/Npa/PublicView?npaID=143132

Главная идея, стоящая за проектом проста. Примирить требования регуляторики и Agile. Позволить разработчикам не отправлять каждый релиз на согласование в испытательную лабораторию, а доказав надежность своей CI/CD и пройдя её сертификацию, утверждать - что все продукты этой сертифицированной CI/CD заслуживают доверия.

Цитата из пояснительной записки к проекту:

"Сертификация процессов безопасной разработки программного обеспечения средств защиты информации является добровольной и позволит разработчикам и производителям сертифицированных средств защиты информации в случае проведения данной сертификации проводить испытания средств защиты информации, обусловленные внесением изменений в программное обеспечение средства защиты информации, самостоятельно без привлечения испытательной лаборатории. Что позволит сократить сроки проведения испытаний и затраты разработчиков и производителей сертифицированных средств защиты информации на проведение указанных испытаний средств защиты информации и, как следствие, снизить себестоимость средств защиты информации, применяемых в государственных информационных системах и на объектах критической информационной инфраструктуры."

Какое это имеет отношение к широкому рынку? Очень простое. Несмотря на определенные в документе границы (сертификация средств защиты), аналогичные подходы могут быть спроецированы и на обычные приложения. На компании не являющиеся разработчиками антивирусов, межсетевых экранов и иных специализированных средств.

В частности с февраля 2022 года Банк России в последней редакции своего Профиля защиты*, в разделе 7.4 рассказывает о требованиях к безопасности жизненного цикла. По мнению регулятора (оставим за скобками ряд правовых и технических нюансов) это позволяет избежать оценок соответствия или сертификации каждого релиза ДБО, т.е. по целям является аналогичным проекту ФСТЭК:

https://www.cbr.ru/content/document/file/132666/inf_note_feb_0422.pdf

*Профиль защиты является де-факто стандартом требований регулятора к банковским ДБО, личным кабинетам финансовых организаций, другим приложениям, связанным с финансовыми операциями (не являющимися средствами защиты по ФСТЭК России).

#dev #ops #law