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

Много тестов не бывает, поскольку любое современное ПО, даже без учета нюансов аппаратной составляющей, ОС, компонентов среды разработки и исполнения, имеет объем кодовой базы и ее сложность, не подлежащие фор- мальному доказательству безошибоч- ности в условиях ограничения реаль- ных технологий и ресурсов. С другой стороны, чем шире тест-сьют, чем более он автоматизирован, тем больше вероятность своевременного нахожде- ния проблем, что, в свою очередь, приводит к сокращению Time-to-Market, снижению числа потенциальных рек- ламаций и нагрузки на группы техпод- держки. Разработчики, не обладающие воз- можностями для организации качествен- ного производства, хватающие любые контракты с целью заработать денег в парадигме "после нас хоть потоп" и не планирующие оказывать реальную тех- ническую поддержку (что прямо требу- ется основными нормативными доку- ментами ФСТЭК России и не только), окажутся в заведомо невыгодных усло- виях и уступят место на рынке ответ- ственным производителям. Реализация Неслучайно мировые ИТ-гиганты неукоснительно следуют практикам без- опасной разработки. Они занимаются промышленным производством ПО, и SDL-подход, можно сказать, стал частью ДНК их инженерных команд. Каким образом лучшие практики рас- пространить в России? Рассмотрим опыт разработчиков рос- сийской среды исполнения Java на базе проекта с открытым исходным кодом OpenJDK. Отечественные инженеры внедрили концепцию жизненного цикла безопасной разработки с момента соз- дания программного продукта Axiom JDK. Команда уже четверть века рабо- тает над улучшением Java-технологий, в том числе в центрах разработки Oracle и Sun, и сегодня входит в число лидеров SDL-разработки в России. На технологиях Java работает подав- ляющее большинство критически важ- ных государственных, банковских и промышленных систем. Одна из идей, лежащих у истоков российского дистрибутива среды исполнения Java в концепции SDL by Design, – создать надежный продукт, обеспеченный высоким уровнем доверия потребите- ля, вниманием к процессам тестиро- вания и качеству при каждом обнов- лении. SDL позволяет воплотить эту идею и сократить расходы на процес- сы, необходимые для поддержания качества. Итак, какие этапы необходимо пройти инженерной команде, чтобы внедрить в разработку принципы SDL? 1. Убедить руководство: заручиться поддержкой и бюджетом Первый (или нулевой) этап предпола- гает определение бюджета и убеждение руководства в необходимости проведения данных мероприятий. Хорошо, когда ини- циатива изначально исходит от руково- дителей компании, но это бывает нечасто. Хорошим аргументом может стать ощу- тимый размер убытков в случае обнару- жения уязвимостей после выпуска изде- лия в промышленную эксплуатацию. Экс- перты из LLVM Project приводят 2 следую- щую оценку: если стоимость исправления бага на этапе разработки около $25, то после релиза она может быть порядка $16 000, то есть в 640 раз выше. При проработке плана действий необходимо учесть особенности SDL- процесса в парадигме ФСТЭК России: l выявление уязвимостей и недеклари- рованных возможностей, статический и динамический анализ в первую очередь в отношении тех компонентов решения, которые находятся на поверхности атаки; l опора на технологическую и методоло- гическую поддержку ИСП РАН, разработки которого востребованы в России и в мире. В числе его сотрудников – все пять россий- ских ревьюверов gcc-компилятора. Помимо компетенций в технологиях классической продуктовой безопасности ИСП РАН входит в шестерку исследовательских центров в сфере искусственного интеллекта, ото- бранных в 2021 г. в рамках проекта "Искус- ственный интеллект" национального про- екта "Цифровая экономика". Он сконцент- рирован на анализе безопасности техно- логий искусственного интеллекта; l активное взаимодействие с сообще- ством – привлечение участников сообщества к развитию методик и тре- бований разработки и анализа СЗИ, создание информационных ресурсов для обучения компаний. 2. Получить и проработать требования к продукту для сертификации по SDL На этом этапе проводятся переговоры с представителями лаборатории. Их результатом является получение и про- работка требований, создание форма- лизованного списка действий по дора- ботке изделия с целью удовлетворения требований по безопасному функцио- нированию, проведению испытаний, под- тверждающих состоятельность дорабо- танного функционала, и выполнению регулярных испытаний, обеспечивающих поддержание высокого стандарта каче- ства и защищенности для каждой новой версии изделия. Список требований согласуется с регулятором. Например, при подготовке к внедре- нию SDL и сертификации для Axiom JDK обсуждались и прорабатывались требования и тесты для проверки сле- дующих механизмов: l обеспечения независимости экзем- пляров виртуальных машин; l обеспечения верификации байт-кода на соответствие спецификации языка Java; l обеспечения проверок безопасности операций во время выполнения кода; l обеспечения разграничения и контро- ля доступа приложений Java к внешним по отношению к виртуальной машине Java-ресурсам; l обеспечения контроля целостности исполняемого кода; l предоставления администратору ВМ возможности определения событий, под- лежащих записи в журнал аудита; l выделения/удаления памяти, коррект- ность его работы при разных сценариях. 3. Сформировать команду для поддержания SDL-процесса Для внедрения SDL-практик в команду разработки из 5–15 сотрудников необхо- димы 1–2 выделенных специалиста по информационной безопасности и про- цессам SDL. Обычно они ведут проект самостоятельно и взаимодействуют с 5–7 техническими экспертами, сосре- доточенными на разработке и сопро- вождении программного изделия. Эксперты привлекаются для разре- шения вопросов, требующих опыта и глу- бокой экспертизы по конкретному направлению. Специалисту по защите информации и SDL, пришедшему извне, чаще всего сложно быстро разобраться в структуре большого проекта, понять архитектурные и функциональные реше- ния, взаимодействие компонентов внут- ри программного продукта, тонкости процесса сборки, разные режимы функ- ционирования и т.д. Например, при разборе логов стати- ческого анализатора необходимы посто- янные консультации с разработчиком, хорошо разбирающимся в коде подле- жащего анализу программного компо- нента. На этапе внедрения тестов с сани- тайзерами будет полезна помощь тести- ровщика. С фаззингом – понадобится участие ведущих разработчиков для выбора поверхности атаки и DevOps- инженеров – при подготовке и сборке фаззинг-цели. Приглашая в команду специалиста, отвечающего за инженерный центр без- опасности и внедрение SDL, стоит обра- тить внимание на следующие компетен- ции кандидата: l минимально Junior по SDL/DevSecOps должен обладать следующим набором знаний на базовом уровне: С/C++, рабо- та с Linux, информационная безопас- ность, а также опционально – базовые знания языка/стека технологий для кон- кретного изделия/проекта, на котором нужно внедрять SDL; l специалист уровня Security Champion имеет хорошее понимание C/C++, рабо- ты сетевых протоколов, механизмов • 39 Безопасная разраБотка www.itsec.ru 2 https://llvm.org/devmtg/2020-09/slides/Using_the_clang_static_ananalyzer_to_find_bugs.pdf