Недавний отчет CISA подчеркивает необходимость уделяя особое внимание безопасности программного обеспечения, которая находится в центре внимания команд кибербезопасности.
Вот восемь худших практик обеспечения безопасности программного обеспечения, с которых следует начинать свою стратегию AppSec.
Использование языков, небезопасных для памяти
Одной из худших практик обеспечения безопасности является использование компьютерных языков, небезопасных для памяти, включая C и C++, в приложениях, предназначенных для критической инфраструктуры на предприятиях, в правительстве, образовании и других местах, говорится в отчете.
Для существующих продуктов, написанных на языках, небезопасных для памяти, компании должны поддерживать опубликованную дорожную карту безопасности памяти, которая описывает «приоритетный подход производителя к устранению уязвимостей безопасности памяти в приоритетных компонентах кода, написанных на языках, небезопасных для памяти», - говорится в отчете. «Производители должны продемонстрировать, что дорожная карта безопасности памяти приведет к значительному, приоритетному сокращению уязвимостей безопасности памяти в продуктах производителя, и показать, что они прилагают разумные усилия, чтобы следовать дорожной карте безопасности памяти».
Уязвимости кода, небезопасного для памяти, должны быть уменьшены в краткосрочной перспективе - и устранены в долгосрочной, - говорится в отчете, - такими методами, как написание новых компонентов кода на языках, безопасных для памяти, и одновременное внедрение аппаратных средств или средств управления компилятором для уменьшения уязвимостей, связанных с безопасностью памяти.
Оставляя дверь открытой для вредоносных SQL-инъекций
Другой распространенной угрозой безопасности, говорится в отчете, является «включение пользовательского ввода непосредственно в необработанное содержимое строки запроса базы данных SQL» в приложениях, используемых для критически важной инфраструктуры или функций. Чтобы устранить эти предотвратимые угрозы, производители программного обеспечения должны создавать свои приложения «таким образом, чтобы систематически предотвращать внедрение уязвимостей SQL-инъекций, например, путем последовательного обеспечения использования параметризованных запросов, подготовленных операторов или последовательного использования библиотеки объектно-реляционного отображения (ORM), которая автоматически генерирует параметризованные запросы».
Возможность прямой инъекции команд
Включение пользовательского ввода непосредственно в необработанное содержимое командной строки операционной системы особенно опасно и уязвимо, когда используется для критической инфраструктуры или функций, говорится в отчете. Чтобы устранить эти угрозы, производители программного обеспечения должны систематически предотвращать уязвимости, связанные с инъекциями команд, «последовательно обеспечивая четкое разграничение вводимых команд и содержимого самой команды; используя встроенные библиотечные функции вместо выполнения команды, когда это возможно; и используя ограничительные списки разрешений, которые допускают только буквенно-цифровые символы и символы подчеркивания для санации пользовательского ввода».
Оставляйте пароли по умолчанию в коде
Трудно представить, но многим компаниям и пользователям до сих пор приходится объяснять, что поддержание более безопасной инфраструктуры начинается с простого процесса отказа от паролей по умолчанию. А ведь это важная рекомендация отчета CISA, подчеркивающая ее актуальность и сегодня.
Производители программного обеспечения должны гарантировать отсутствие паролей по умолчанию в продукте, предоставляя случайные, уникальные для каждого экземпляра начальные пароли для продукта, говорится в отчете, а также требуя установки приложения только после того, как пользователь создаст надежный пароль для начала процесса. Производители программного обеспечения также могут предоставлять ограниченные по времени установочные пароли, которые отключаются по завершении процесса установки и требуют настройки надежного пароля или более надежных подходов к аутентификации, таких как MFA, устойчивый к фишингу.
Неактивное участие в сообществах разработчиков открытого ПО
При использовании программного обеспечения с открытым исходным кодом предприятия должны быть вовлечены в сообщества, стоящие за этими приложениями, отмечается в отчете. Согласно CISA, компании должны «ответственно относиться к потреблению и устойчивому вкладу в программное обеспечение с открытым исходным кодом, от которого они зависят», чтобы гарантировать, что они следят за его безопасностью и безопасностью и вносят в них свой вклад. Это включает в себя принятие разумных мер по оценке и обеспечению безопасности зависимого программного обеспечения с открытым исходным кодом путем ведения спецификации программного обеспечения (SBOM) для критически важных приложений. SBOM должны вестись в стандартном для отрасли машиночитаемом формате с описанием всех зависимостей программного обеспечения первых и третьих сторон, как с открытым исходным кодом, так и проприетарного. Затем SBOM должны быть предоставлены всем заказчикам, говорится в отчете.
Компании, использующие приложения с открытым исходным кодом, должны выполнять и другие действия, в том числе запускать средства сканирования безопасности на каждом выбранном компоненте ПО с открытым исходным кодом, включая его зависимости и переходные зависимости, а также на каждой последующей версии при ее обновлении, говорится в сообщении CISA. Предприятия должны «выбирать проекты программного обеспечения с открытым исходным кодом, которые хорошо поддерживаются, и - при необходимости - вносить вклад в текущее обслуживание проекта для поддержания ожидаемого стандарта качества».
Использование устаревших и неэффективных криптографических алгоритмов
Предприятия и организации, эксплуатирующие критически важную инфраструктуру с использованием известных небезопасных или устаревших криптографических алгоритмов, с самого начала увеличивают риски и уязвимости своей безопасности, говорится в отчете. Чтобы избежать подобных ситуаций, пользователи должны использовать современные криптографические алгоритмы, способные обеспечить защиту всех конфиденциальных данных при передаче и в состоянии покоя, обеспечивая более надежную защиту и пресекая пути распространения угроз. Это означает отказ от использования и удаление ссылок на известные небезопасные или устаревшие алгоритмы, такие как Transport Layer Security (TLS) 1.0/1.1, MD5, SHA-1 и Data Encryption Standard (DES). Вместо этого организациям следует поддерживать стандартизированные постквантовые криптографические алгоритмы.
Пропуск многофакторной аутентификации по умолчанию
Неиспользование MFA в программном обеспечении опасно и значительно повышает риски для организаций, говорится в отчете. Производители программного обеспечения должны изначально включать и поддерживать MFA в своих приложениях, включая MFA, устойчивую к фишингу, и позволять администраторам требовать MFA для пользователей в своей организации, если это применимо.
Несвоевременная публикация и поддержка отчетов CVE
Чтобы предотвратить широкое распространение угроз безопасности и уязвимостей среди пользователей коммерческих приложений, производители программного обеспечения должны своевременно публиковать отчеты Common Vulnerabilities and Exposures (CVE), в которых описываются и предлагаются решения для всех критических или высокозначимых уязвимостей, о которых сообщается для их продуктов, говорится в отчете CISA. Этот важный шаг позволит лучше защитить пользователей и уменьшить угрозы безопасности для других пользователей.
Переосмыслите безопасность программного обеспечения с нуля
Советы и примеры, приведенные в последнем отчете CISA, дают предприятиям много пищи для того, чтобы кардинально исправить и избежать некоторых из худших методов обеспечения безопасности, которые используются каждый день по разным причинам. Возможно, они не знают, что пропускают важные шаги в области безопасности и делают свои организации уязвимыми. Возможно, они не знают о новых и передовых политиках безопасности, которые они не применяют.
