Журнал "Information Security/ Информационная безопасность" #3, 2023
ГОСТы, которые дополнительно раз- вивают и дополняют нормы безопас- ной разработки. Дополнительно, на мой взгляд, нужно описать регламенты и методологию тестирования на про- никновение. Владимир Высоцкий, Solar appScreener: Безопасная разработка – процесс непрерывный. К сожалению, суще- ствующая на данный момент норма- тивная база не покрывает все про- цессы обеспечения безопасного жиз- ненного цикла разработки ПО. Недо- статочно проработан перечень веро- ятных ситуаций в части возможных угроз и мер реагирования. Кроме того, я считаю, что, если бы нормативные документы писались для широкого круга читателей и простым языком, они были бы широко используемыми и, как следствие, было бы больше безопасного ПО. Дмитрий Евдокимов, Luntry: Самое интересное – обеспечение гиб- кости в условиях быстрого развития тех- нологий. Так появляются технологии, которые дают большее преимущество, чем то, что описано в документах, кото- рые, как все знают, обновляются редко. Возьмем пример из контейнерной без- опасности: текущие документы ничего не говорят о distroless-образах, специа- лизированных ОС для контейнеров, хотя с их помощью можно достичь более высокого уровня безопасности и надеж- ности. Екатерина Вайц, МГТУ им. Н.Э. Баумана: Самыми актуальными моментами являются добавление в методики тре- бований по проведению фаззинг-тести- рования и компонентного анализа заимствованного кода. Однозначно стоит детальнее описать требования к методам и критериям опре- деления поверхности атаки (в том числе и автоматизированными средствами), а также требования по написанию маши- ночитаемых аннотаций на всех этапах создания ПО, включая подробное опи- сание условий по сборке. Сергей Трандин, Базальт СПО: "Изюминка" действующей нормативки: основная часть проверок возложена на разработчика, он должен иметь лицен- зию на разработку средств защиты. Проверка продукта выполняется на этапе разработки, а не после передачи про- дукта в испытательную лабораторию. Такой подход позволяет обеспечивать устойчивый жизненный цикл сертифи- цированных продуктов. Ждем норма- тивных документов, регулирующих про- цессы безопасной разработки. Надо добавить требования к процессу без- опасной разработки. Лука Сафонов, Синклит: Если говорим об AppSec, самым актуаль- ным была и остается методика ВУ и НДВ ФСТЭК России. Марк Коренберг, Айдеко: На мой взгляд, самое интересное – это автома- тизация всех процессов SDL. В требования регуляторов необхо- димо добавить конкретности и одно- значности, ведь некоторые требования можно интерпретировать на разный лад. Я бы хотел, чтобы в нормативке были описаны не только сами требования, но и цели, которые они преследуют (какую проблему или задачу решают). Хотелось бы также видеть, как требования связа- ны с моделью угроз. Роман Карпов, Axiom JDK: Мы бы отметили статическое и дина- мическое тестирование. Очень удобно то, что есть профили сертификации раз- ных групп программных комплексов (ПО). Надеемся, что скоро появятся про- фили для баз данных и связующего ПО. Сергей Сергеев, КСБ-СОФТ: Сегодня важность безопасной разра- ботки признается на государственном уровне, принят ряд нормативных доку- ментов. Но, на наш взгляд, в законода- тельстве есть пробелы. Что мы предлагаем? Распространить требования методики ВУ и НДВ на при- кладное ПО для ЗОКИИ, чтобы разра- ботчики понимали метрики и могли оце- нить объем исследований по выявлению уязвимостей. Применять практики SDL на этапах создания (модернизации) ГИС, чтобы операторы были уверены в каче- стве и безопасности используемых про- дуктов. Валерий Богдашов, R-Vision: Как показывает практика, у многих разработчиков есть необходимость в анализе компонент Open Source, в частности интерпретаторов языков. Это достаточно ресурсоемко и сложно, но является хорошей практикой для прин- ципа Security in Depth (защиты в глубину) и позволяет привести продукты к единым решениям. Оксана Новослугина, СПб ИАЦ: Очень интересен, на мой взгляд, закон об экспериментальных правовых режи- мах в сфере цифровых инноваций, кото- рый позволит тестировать новые про- дукты и технологии в условиях специ- ального нормативного регулирования. Так называемые регуляторные песоч- ницы (также распространено название цифровые "песочницы", поскольку соз- даваться они будут именно в сфере цифровых технологий) появились непо- средственно после вступления в силу закона № 258-ФЗ. Думаю, в дальнейшем будет понятно, по какому принципу пред- лагается определять законодательные положения, которые смогут не соблю- даться при тестировании технологий в рамках "песочниц", и на какие нюансы установленного порядка введения и дей- ствия экспериментальных правовых режимов следует обратить особое вни- мание как разработчикам новых про- дуктов и технологий, так и их потенци- альным потребителям. Полагаю, что при внедрении ИИ необходимо будет вносить изменения в нормативные акты, связан- ные с авторским правом, определением причинения вреда и гражданско-право- вой ответственности. Думаю, возникает потребность в актуализации ГОСТов серии 34 в связи с изменившимися тех- нологиями и практиками создания про- граммного обеспечения. Владимир Пономарев, Гарда Технологии: Самое интересное – это динамика развития технической части требований в последние годы. Происходит качественный переход от формальной сертификации к выстраи- ванию действительно полноценного про- цесса безопасной разработки. Мы наблюдаем это непосредственно, напри- мер участвуя в анализе безопасности популярных компонент Open Source под эгидой ИСП РАН и ФСТЭК России. Ждем новой версии методики для тре- бований доверия в этом году. Роман Борзов, Андрей Кузнецов, Фобос-НТ: Системный подход и ответственное отношение к разработке СЗИ является ключевым фактором, который прививает разработчикам современная норматив- ная документация. На наш взгляд, сле- дует добавить системное обновление нормативной документации, задать периодичность актуализации стека тех- нологий и уточнение требований к СЗИ во взаимодействии с разработчиками и регуляторами. l • 55 Безопасная разраБотка www.itsec.ru Ваше мнение и вопросы присылайте по адресу is@groteck.ru
Made with FlippingBook
RkJQdWJsaXNoZXIy Mzk4NzYw