Журнал "Information Security/ Информационная безопасность" #2, 2022

На стратегическом уровне процессы технологического развития можно выстраивать, опираясь на концепцию "физтеховского треугольника" "образо- вание – разработка – инновации". При создании информационных систем, в частности на уровне непосредственной разработки СЗИ, требуется следовать принципу эшелонированной обороны. И в самом ее фундаменте, когда ата- кующим пройдены все остальные уровни защиты – организационные, админи- стративные, наложенные – находится безопасность разработки. Надежность последнего рубежа, а значит, и всей киберобороны в целом определяется тем, насколько хорошо спроектирована и реализована ваша система. Роль и место безопасной разработки в современном процессе сертификации Необходимость развивать процессы безопасной разработки в отечественных компаниях очевидна, и эта позиция все- цело поддерживается государством в лице ФСТЭК России. Обратим внима- ние на два очень важных документа: 1. Приказ № 76 "Требования по без- опасности информации..." 1 , раздел IV, п. 17, устанавливает, что "тестирование, испытания по выявлению уязвимостей и недекларированных возможностей, а также анализ скрытых каналов прово- дятся изготовителем в ходе приемочных испытаний средства и испытательной лабораторией в ходе сертификационных испытаний средства". 2. Приказ № 121 "О внесении измене- ний в положение о системе сертифика- ции..." 2 , п. 12, усиливает и конкретизи- рует требование формулировкой "…при проверке организации производства про- граммных и программно-технических средств защиты информации проверяет- ся внедрение заявителем процедур без- опасной разработки программного обес- печения в соответствии с требованиями по безопасности информации, на соот- ветствие которым проводятся сертифи- кационные испытания". Эти формулировки принципиально важны! В соответствии с ними заявитель обязан тестировать разрабатываемые СЗИ, подлежащие серийному производ- ству, теми же методиками, практиками и инструментами и в том же объеме, которыми лаборатория будет его прове- рять. Что это значит? Это значит, что пара- дигма "отдадим собранный полгода назад комплект бинарных файлов в лабораторию, они там что-то пофаззят, и испытания пройдены", системно боль- ше не работает. Конечно, мир не меняет- ся моментально, некоторые из разра- ботчиков-лицензиатов, пока еще пытаю- щиеся идти упомянутым путем, вполне возможно, сертификаты получат, но точно не все и, возможно, не с первой попытки: глубина экспертизы и количе- ство замечаний и отрицательных заключений со стороны участников про- цесса сертификации, выполняющих контролирующие функции (органы по сертификации, федеральный регулятор) стремительно нарастает. Можно сделать вывод: если у разработчика не реализо- ван процесс безопасной разработки, отдавать код в испытательную лабора- торию бесполезно. В то же время актуальная норматив- но-правовая база содержит и позитив- ные стимулы для развития процессов безопасной разработки. Артефакты, подтверждающие корректное выполне- ние требуемых практик, полученные раз- работчиком в ходе процессов создания СЗИ в парадигме безопасной разработ- ки, допускается переиспользовать в сер- тификационных испытаниях, что, как правило, приводит к существенному сокращению их сроков. Практики и методики безопасной раз- работки должны реализовываться в соот- ветствии с регламентирующими доку- ментами. В настоящий момент требова- ния к количественным и качественным характеристикам SDL- и сертификацион- ных процессов задаются положением о системе сертификации, требованиями доверия и методикой ВУ и НДВ. Стоит упомянуть и ГОСТ Р 56939–2016 "Защита информации. Разработка безопасного программного обеспечения" 3 , но важно понимать, что, будучи концептуально правильным, он тем не менее носит рекомендательный характер. Ориенти- роваться на этот ГОСТ при подготовке продукта к сертификационным испыта- ниям не совсем верно, поскольку в ряде вопросов (например, аспекты статиче- ского и динамического анализа) он гораз- до более узок, чем требования и мето- дики регулятора, а в каких-то иных он, наоборот, описывает практики, не под- лежащие проверке в ходе сертифика- ционных испытаний (например, обучение персонала методикам и практикам без- опасной разработки). 40 • ТЕХНОЛОГИИ Безопасная разработка и сертификация: две стороны одной медали се мы видим, что происходит в мире в последние месяцы. Неправомерное давление на нашу страну усиливается на всех уровнях – экономическом, технологическом – и проявляется в форме разнопланового силового воздействия, в том числе кибератаках, проводимых различными акторами, вплоть до APT-группировок. О некоторых атаках – успешных и неуспешных – мы знаем, а о некоторых не узнаем никогда. Поскольку угроза безопасности информационной инфраструктуры носит комплексный характер, то и бороться с ней можно только комплексными методами. В Дмитрий Пономарев, технический директор ООО НТЦ “Фобос-НТ”, сотрудник ИСП РАН 1 https://fstec.ru/tekhnicheskaya-zashchita-informatsii/dokumenty-po-sertifikatsii/120-normativnye-dokumenty/2126-vypiska-iz-tre- bovanij-po-bezopasnosti-informatsii-utverzhdennykh-prikazom-fstek-rossii-ot-2-iyunya-2020-g-n-76 2 https://fstec.ru/en/component/attachments/download/3096 3 https://docs.cntd.ru/document/1200135525

RkJQdWJsaXNoZXIy Mzk4NzYw