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

1. Разработка и обновление ГОСТов по безопасной разработке, статическому и динамическому анализу, безопасной компиляции и др. Во-первых, ГОСТы станут более разнообразными. Во-вто- рых, нужно обратить особое внимание на ГОСТ по безопасному компилятору 5 . Весьма вероятно, что через некоторое время весь код на языках С/С++, пред- полагаемый для использования в сер- тифицируемых СЗИ, нужно будет соби- рать именно им. 2. Разработка и обновление требова- ний безопасности и профилей защиты. Уже разработаны требования к системам защиты от DDoS. Разрабатываются тре- бования к средствам контейнеризации, на очереди явно требования к средствам виртуализации, СУБД и DLP, а также уточнение существующих профилей. Назревает вопрос о создании требова- ний к средам выполнения кодов, напи- санных на интерпретируемых (управ- ляемых) языках программирования. ФСТЭК очень активно ведет эти работы, опираясь на технологическую экспертизу ИСП РАН и привлекая экспертные сообщества. Всем понятно, что требо- вания должны быть живыми, впрочем это не означает, что они должны быть мягкими. 3. Средства автоматизации и стан- дартизации определения ширины и глу- бины поверхности атаки в процессе безопасной разработки продуктов и их сертификации. Это очень ожидаемая вещь: вы приносите двухгигабайтный комплекс исполняемых файлов, назы- ваемый СЗИ, заводится "волшебный ящик", прогоняются основные сценарии и автоматически вырисовываются карты того, какие модули в действительности составляют СЗИ, что с чем взаимодей- ствует, какие участки кода покрыты, куда утекали помеченные данные, эври- стики их изменений, цикломатическая сложность кода. И по этой красивой схеме нужно работать, а потом и идти на сертификацию. Лучше развивать все эти процессы уже сейчас, поскольку автоматизированная система гаранти- рованно отрисует (и подпишет цифровой подписью) большую поверхность атаки, чем любой эксперт, особенно если он лично заинтересован в скорейшем завершении процесса сертификации в ущерб качеству. 4. Стандартизация использования системных компонент (ядра, системное ПО, компоненты виртуализации и кон- тейнеризации, компоненты сборочной системы). Тут, в общем, все понятно, за это кто-то должен отвечать, то есть либо вы, либо разработчик операцион- ной системы, в которой вы работаете. Если вы хотите взять, например, оттуда Lua, а в сертифицированном дистрибу- тиве операционной системы его нет, значит, вы должны фаззить Lua сами, ведь за каждый компонент должен кто- то отвечать. Поэтому чем компонентов будет меньше, чем они будут более стандартизованы, тем будет проще. Осо- бое внимание следует уже сейчас обра- тить на функционирование Центра ана- лиза ядра Линукс, в работе которого уже принимают участие все основные отечественные разработчики СЗИ. Уже в среднесрочной перспективе успешное прохождение сертификационных испы- таний СЗИ, имеющего в своем составе ядро, не покрытое объемом практик анализа, сопоставимым с результатами работы Центра, представляется мало- выполнимым. 5. Обеспечение целостности резуль- татов работы анализаторов с помощью цифровых подписей. Это тоже очень важный момент, чтобы отчеты не просто выпадали из анализатора, а подписы- вались: чтобы, к примеру, нельзя было вручную убрать 100 тыс. срабатываний, оставив только тысячу. И это вопрос самого ближайшего будущего. 6. Стандартизация материалов серти- фикационных испытаний, уход от "бумажной" безопасности в сторону реальной. Сейчас явно наблюдается движение в этом направлении и есть успехи. Что немаловажно – этот вектор горячо поддерживается в первую оче- редь самими регуляторами, ведь глав- ное – это суть, а не кипа написанных бумаг. l 42 • ТЕХНОЛОГИИ 5 https://fstec.ru/en/component/attachments/download/3014 Ваше мнение и вопросы присылайте по адресу is@groteck.ru , . 14–16 ФЕВРАЛЯ 2023 31 ЯНВАРЯ - 3 МАРТА 2023 www.tbforum.ru — Реклама