Разработка программного обеспечения в России должна стать безопасной!
Содержание данной статьи проверено и подтверждено:
Музалевский Федор Александрович
Ведущий эксперт компьютерно-технического направленияИдея о том, что разработка программного обеспечения в России должна стать безопасной, звучала в различных новостных агентствах и публикациях по кибербезопасности. Но оправдано ли такое мнение или это просто мимолетная тенденция?
В рамках данной статьи мы углубимся в причины информационного шума и исследуем обоснованность утверждений.
Текущее состояние разработки ПО в России
Россия активно развивает свою ИТ-индустрию, вкладывая значительные средства в инициативы, направленные на содействие инновациям и предпринимательству.
Быстрые темпы цифровизации повлекли за собой увеличение числа кибератак и утечек конфиденциальных данных, не оставив без внимания отечественный сектор разработки программного обеспечения (далее – ПО).
Все это вызвало вопросы о его способности обеспечить безопасность своих продуктов.
Почему проблема безопасности По особенно актуальна сейчас?
Несколько причин привели к росту беспокойства относительно безопасности отечественного ПО, а именно:
- Отсутствие регулирования: в отличие от других стран, в России до сих пор отсутствует комплексная нормативная база для безопасной разработки программного обеспечения, что делает отрасль в значительной степени саморегулируемой
- Кадровый голод: страна сталкивается с нехваткой квалифицированных специалистов по кибербезопасности
- Увеличение числа хакерских взломов: в преобладающем большинстве российских компаний, занимающихся разработкой ПО, не уделяют достаточного внимания тестированию безопасности, что приводит к появлению уязвимостей и умышленно оставленных программных закладок в конечном продукте
Собственный опыт аудита процессов разработки программного обеспечения позволил сформировать следующую статистику по компаниям, занимающимся производством программного обеспечения:
Если внимательно посмотреть на данные цифры, то можно увидеть, что все тесты, разработанные в рамках данных проектов, в большинстве случаев, направлены на верификацию функциональных требований, определенных в техническом задании. Все это говорит о том, что тестирование продукта на реальную безопасность в данных компаниях не проводилось.
Результаты статического и динамического анализа исходных кодов таких продуктов ожидаемо оказались неутешительными. Распределение обнаруженных уязвимостей по типам дефектов CWE, уровню их опасности и их классам представлены на рисунках (рис. 1, рис. 2, рис.3)
Наиболее популярными типами дефектов в IT-продуктах стали:
- СWE-113 – Непринятие мер по обработке последовательностей CRLF в заголовках HTTP Headers
- CWE-117 – Неправильная обработка выходных данных для журналов регистрации
- CWE-327 – Использование криптографических алгоритмов, содержащих дефекты или риски
В список наиболее опасных уязвимостей попали следующие CWE:
- СWE-113 – Непринятие мер по обработке последовательностей CRLF в заголовках HTTP Headers
- CWE-352 – Межсайтовая фальсификация запросов
- СWE-601 – Переадресация URL на ненадежный сайт
- CWE-798 – Использование жестко закодированных учетных данных
Стоит отметить, что данный перечень дефектов был выявлен в отечественном ПО. Причем уровень их опасности не опускался ниже среднего.
7% выявленных CWE достигали критического уровня, а 21% дефектов имели высокий уровень опасности.
Все это действительно говорит о низком уровне зрелости жизненного цикла разработки ПО в Российских компаниях.
Какие шаги по популяризации безопасной разработки ПО приняты государством?
Для решения проблем, связанных с выявлением и устранением уязвимостей в отечественном ПО на всех его этапах жизненного цикла, государством предприняты следующие шаги:
- 2016 год
Вступил в силу ГОСТ 56939-2016, содержащий требования к процессам безопасной разработки программного обеспечения на каждом из его этапов жизненного цикла - 2019 год
Введен в действие ГОСТ 58412-2019, описывающий основные угрозы безопасности информации, которые могут появиться в процессе разработки программного обеспечения - 2022 год
Банк России дополнил Профиль защиты разделом 7.4, в котором изложены требования к безопасной разработке и тестированию программных продуктов в процессе их жизненного цикла - 2023 год
Разработана концепция разработки безопасного программного обеспечения на единой цифровой платформе Российской Федерации «ГосТех» - 2024 год
Вступил в силу приказ ФСТЭК России № 240, который определят порядок сертификации процессов безопасной разработки по СЗИ на соответствие требованиям стандарта ГОСТ Р 56939-2024
Преимущества безопасной разработки программного обеспечения
Ранее разработчикам финансовых приложений необходимо было проводить повторную Оценку соответствия по требованиям ОУД4 при внесении любых изменений в функции безопасности программных продуктов.
В случае с СЗИ, аналогом такой процедуры являлась Сертификация, необходимость прохождения которой, появлялась при внесении любых новых изменений в ПО. Такой продуктовый подход к проверкам безопасности приводил к существенной задержке выпуска новых версий программных продуктов.
Новый порядок позволяет оценить или сертифицировать процессы безопасной разработки программного обеспечения в организации.
Применение процессного подхода дает возможность сэкономить на независимых проверках безопасности, связанных с выпуском любых обновлений в программных продуктах.
Теперь компании могут выполнять их самостоятельно в рамках жизненного цикла безопасной разработки программного обеспечения. Это существенно снижает риски инцидентов, связанных с ошибками и уязвимостями в программных продуктах.
Сравнение результатов анализа исходных кодов в компаниях с нулевым и средним уровнем развития процессов безопасной разработки программного обеспечения говорит само за себя.
Наш анализ показывает, что компании со средним уровнем зрелости процессов безопасной разработки имеют более низкую плотность уязвимостей кода.
Также следует отметить факт того, что уровень опасности выявленных дефектов СWE не превышает средних значений.
Распределения обнаруженных уязвимостей по типам дефектов CWE, уровню опасности и их классам представлены на рисунках (рис. 4, рис. 5, рис.6).
Наиболее популярными типами дефектов программного обеспечения стали:
- CWE-476 – Разыменование указателя NULL
- СWE-570 – Выражение всегда False
Результаты статистики показывают, что даже средний уровень зрелости процессов безопасной разработки ПО позволяет существенно сократить количество брешей и уязвимостей в конечном продукте.
Все это лишний раз подчеркивает важность внедрения мер безопасности в жизненный цикл разработки программного обеспечения.
Что нужно сделать, чтобы снизить число уязвимостей в программном продукте?
Для того, чтобы снизить общее число уязвимостей в разрабатываемом продукте необходимо внедрить культуру безопасности в команде программистов, которая включает в себя регулярное обучение и повышение квалификации в области безопасного кодирования с применением лучших международных практик, а также внутренних регламентов, правил и стандартов компании.
В случае разработки NET приложений разработчик обязан знать и руководствоваться требованиями Microsoft при обеспечении их безопасности.
Если в компании ведется разработка веб-приложений ему необходимо знать следующие лучшие практики безопасного кодирования:
- Mozilla
- Guidelines
- Кодирование должно осуществляться в соответствии с принятыми в обществе стандартами (именование процедур, функций, переменных, параметров и пр.)
- Должны использоваться программные фреймворки, которые согласованы к применению с руководителем разработки и главным архитектором
До применения библиотек с открытым исходным кодом должен осуществляться контроль наличия известных уязвимостей, лицензионных ограничений.
В процессе разработки ПО необходимо использовать инструменты статического и динамического анализа кода.
Такие инструменты помогают аналитикам автоматически выявлять потенциальные уязвимости и ошибки в исходных кодах программы, что позволяет разработчикам исправлять их еще до того, как программный продукт будет выпущен.
Кроме того, регулярное проведение экспертного «Code Review» с участием специалистов по информационной безопасности помогает своевременно выявлять проблемы, которые могли быть упущены автоматическими инструментами. Такой подход обеспечивает дополнительный уровень проверки и способствует повышению качества и безопасности кода.
Code Review позволяет выявить следующие потенциальные проблемы:
- Программные ошибки, которые не только мешают нормальному функционированию приложений (например, зависания, синие экраны смерти, утрата данных), но и создают возможности для злоумышленников
- Расширение функционала приложений в ущерб безопасности, что часто происходит из-за стремления к быстроте и удобству
- Внедрение функций, позволяющих обходить защитные механизмы (разработчики могут оставлять такие функции для упрощения тестирования и отладки, но иногда забывают отключить их в окончательной версии)
- Программные «закладки», которые намеренно добавляются в исходный код или обновления ПО для получения несанкционированного доступа к данным или совершения других вредоносных действий (такие «закладки» могут быть внедрены злоумышленником из команды разработчиков или разработчиками сторонних библиотек)
- Скрытые уязвимости, логические ошибки, архитектурные недочеты, утечки памяти и перерасход ресурсов
- «Мертвый» код — это код, который может быть выполнен, но его результаты не оказывают влияния на работу программного обеспечения и остаются неиспользованными
Инструменты статического анализа исходных кодов помогают предотвратить появление следующих уязвимостей:
- Отсутствующие или недостаточные механизмы аутентификации и авторизации, включая многофакторную аутентификацию
- Внедрение кода (SQL Injection, OS Commanding и другие)
- Недостатки криптографической защиты информации
- Уязвимости в логике приложений, которые могут быть использованы злоумышленниками для реализации атак
- Уязвимости, позволяющие проводить атаки на пользователей/клиентов приложений (Cross-Site Scripting, Cross-Site Request Forgery, и другие)
- Раскрытие защищаемой информации
После завершения разработки и перед выпуском программного продукта необходимо проводить тестирование на проникновение.
Такое тестирование позволяет выявить ряд уязвимостей, которые могли быть пропущены на предыдущих этапах.
Безопасная разработка ПО — вектор развития ИБ в России
Регулярное обновление используемых библиотек и фреймворков также играет ключевую роль в снижении числа уязвимостей, так как устаревшие компоненты могут содержать известные уязвимости. Внедрение системы мониторинга и логирования событий безопасности в среде разработки программного обеспечения позволяет оперативно реагировать на инциденты безопасности.
Снижение числа уязвимостей в программном продукте является комплексной задачей, которая требует системного подхода и вовлеченности всей команды, задействованной в разработке программного продукта.
Внедренные процессы безопасной разработки помогают создавать более защищенное программное обеспечение.
Обновление Российского законодательства также говорит нам о том, что безопасность должна стать неотъемлемой частью производства отечественного программного обеспечения, а не добавляться в последнюю очередь, что позволит значительно снизить риски и повысить доверие пользователей к отечественным продуктам.
Подписывайтесь на канал ИТ. Право. Безопасность в Telegram
