31 октября 2024 года

Это самая жёсткая позиция правительства в отношении безопасности программного обеспечения, которая предупреждает производителей: устраняйте опасные методы программирования, иначе вас могут обвинить в халатности.
Федеральное правительство предупреждает об опасных методах разработки программного обеспечения. Агентство по кибербезопасности и защите инфраструктуры США (CISA) и Федеральное бюро расследований (ФБР) публикуют жёсткие предупреждения о нарушениях базовых мер безопасности, которые продолжают затрагивать критически важную инфраструктуру.

В недавнем отчёте, опубликованном совместно CISA и ФБР, о недостаточных мерах обеспечения безопасности продуктов производители программного обеспечения предупреждаются о нежелательности использования небезопасных для памяти языков программирования, таких как C и C++.
«Разработка новых линеек продуктов для использования в критически важной инфраструктуре или [национальных критически важных функциях] NCF на языке, небезопасном для памяти (например, C или C++), когда есть доступные альтернативные языки, безопасные для памяти, которые можно использовать, несет в себе угрозу и значительно повышает риск для национальной безопасности, национальной экономической безопасности, здоровья и безопасности населения», — говорится в отчёте.

Три категории

В отчете говорится, что плохие практики разделены на три категории:

• Свойства продукта, которые описывают наблюдаемые качества программного продукта, связанные с безопасностью.

• Функции безопасности, которые описывают функциональные возможности безопасности, поддерживаемые продуктом.

• Организационные процессы и политики, описывающие действия, предпринимаемые производителем программного обеспечения для обеспечения прозрачности в вопросах безопасности.
  В отчёте говорится, что он предназначен для производителей программного обеспечения, которые разрабатывают программные продукты и сервисы, в том числе локальное программное обеспечение, облачные сервисы и программное обеспечение как услугу (SaaS), используемые для поддержки критически важной инфраструктуры или NCF.

Избегайте плохих практик, следуйте рекомендациям

Кроме того, в отчёте также содержится призыв ко всем производителям программного обеспечения избегать этих вредных для безопасности продуктов методов. «Следуя рекомендациям, приведённым в этом руководстве, производители покажут клиентам, что они берут на себя ответственность за безопасность клиентов, что является ключевым принципом «Безопасность по умолчанию», — говорится в отчёте.
«Это руководство, безусловно, является продолжением более ранних заявлений правительства США по этому вопросу, сделанных в 2022 году, в которых поставщиков технологий и пользователей корпоративных решений призывали переходить на языки, безопасные для памяти», — сказал Брэд Шиммин, аналитик Omdia.

«К счастью, ни этот документ, ни правительство США не призывают к немедленному переходу с C/C++ на Rust — это лишь один из примеров, — сказал он. — В документе CISA «Безопасность по умолчанию» признаётся, что разработчики программного обеспечения просто не могут массово переносить свои кодовые базы таким образом».
Это руководство, хотя и является добровольным, представляет собой самую жёсткую позицию CISA в отношении базовых методов обеспечения безопасности. Оно предупреждает компании о том, что является небрежной практикой разработки программного обеспечения, когда речь идёт о критически важной инфраструктуре.

Часы тикают

Однако для производителей программного обеспечения время идёт. У компаний есть время до 1 января 2026 года, чтобы составить планы по обеспечению безопасности памяти.
«Для существующих продуктов, написанных на небезопасных для памяти языках, отсутствие опубликованной дорожной карты по обеспечению безопасности памяти к 1 января 2026 года опасно и значительно повышает риск для национальной безопасности, национальной экономической безопасности, а также здоровья и безопасности населения», — говорится в отчёте.
Кроме того, к этой же дате из учётных записей администраторов должны быть удалены пароли по умолчанию. Эти сроки свидетельствуют о переходе от рекомендаций к ожидаемым стандартам.
В отчёте также говорится, что в дорожной карте по обеспечению безопасности памяти производитель должен указать приоритетный подход к устранению уязвимостей в компонентах кода, отвечающих за безопасность памяти (например, код, взаимодействующий с сетью, или код, выполняющий важные функции, такие как криптографические операции).
«Производители должны продемонстрировать, что дорожная карта по обеспечению безопасности памяти приведёт к значительному и приоритетному сокращению уязвимостей, связанных с безопасностью памяти, в продуктах производителя, а также продемонстрировать, что они прилагают разумные усилия для соблюдения дорожной карты по обеспечению безопасности памяти», — говорится в отчёте.
«Есть две веские причины, по которым компании продолжают поддерживать масштабный код на COBOL и Fortran. Это затраты и риски, — сказал Шиммин в интервью The New Stack. — Перенести миллионы строк кода просто невозможно с финансовой точки зрения, и ни одна ответственная организация не стала бы так рисковать».
Тем не менее, согласно отчёту, критически важная инфраструктура по-прежнему страдает от «исключительно рискованных» методов, таких как:

• Пароли по умолчанию.

• Уязвимости с прямым внедрением SQL

• Отсутствие базового обнаружения вторжений

• Отсутствие многофакторной аутентификации
  
  

Открытый исходный код

Что касается программного обеспечения с открытым исходным кодом, в отчёте говорится, что особое внимание следует уделять уязвимостям в программах с открытым исходным кодом. Другие рекомендации включают:

• Компании должны поддерживать спецификации программного обеспечения (SBOM).

• Требуется кэшировать зависимости, а не извлекать их из общедоступных источников.

• Необходимо ответственно подходить к проектам с открытым исходным кодом, от которых они зависят.

«Производители программного обеспечения должны ответственно относиться к потреблению и вносить устойчивый вклад в развитие программного обеспечения с открытым исходным кодом, от которого они зависят», — говорится в отчёте.
В отчете также содержится призыв к большей прозрачности, в котором говорится, что:

• Компании должны публиковать политики раскрытия уязвимостей.

• Требуется выдавать CVE для всех критических уязвимостей.

• Должно предоставлять четкую документацию о проблемах безопасности.

• Ожидается, что журналы безопасности будут храниться шесть месяцев.

Это хорошо

Наконец-то хорошо, что CISA рекомендует компаниям, на попечении которых находится критически важное программное обеспечение, создать чёткий план действий на случай атаки к началу 2026 года, — сказал Шиммин. Это хорошо, потому что у отрасли будет больше времени, чтобы найти более эффективные способы обеспечения безопасности наших критически важных программных активов, — сказал он.
“Эти средства, вероятно, будут связаны с производством оборудования, поддерживающим (?) потенциальные векторы атак, и разработчиками языков программирования, предлагающими такие вещи, как предложение Safe C ++), которое требует создания надмножества для C ++, которое решает проблемы безопасности памяти без принудительного переписывания основного кода”, - сказал он.

Бумажный тигр?

«CISA накладывает ограничения на небезопасные приложения, созданные на C/C++ или ассемблере. Поскольку до истечения срока осталось менее 15 месяцев, пользователи и поставщики будут вынуждены соблюдать требования, поскольку многие критически важные государственные системы по-прежнему используют C/C++», — Хольгер Мюллер, аналитик Constellation Research, рассказал The New Stack. «Теперь все будут следить за поставщиками и разработчиками, чтобы понять, смогут ли они уложиться в этот срок. Через несколько месяцев мы увидим, является ли этот приказ CISA бумажным тигром, зубастым тигром или в значительной степени соответствующим стандартным правилам. Время покажет».

Переход к безопасности памяти

По словам Тима Макнамары, основателя Accelerant.dev и автора «Rust в действии», компании определённо стремятся создавать более безопасное программное обеспечение. Отрасль отказывается от небезопасных методов, и это здоровый сдвиг.
«Однако в документе по-прежнему остаётся достаточно лазеек для сохранения статус-кво, — сказал Макнамара в интервью The New Stack. — Похоже, что авторы явно опасаются превысить свои полномочия. Обратите внимание, что в тексте используются такие термины, как «настоятельно рекомендуем», «должны» и «разумные усилия».
Кроме того, требования документа также довольно мягкие, сказал Макнамара. Новое программное обеспечение должно быть написано на языке программирования, безопасном для памяти. Производителей программного обеспечения, выпускающих текущие продукты, просят разработать «безопасную для памяти дорожную карту» к 2025 году.
«Эта дорожная карта — это план производителя по сокращению количества ошибок в системе безопасности памяти с течением времени, — сказал Макнамара. — Есть также важные исключения. Дорожные карты не требуются для продуктов, срок службы которых истекает в 2030 году, несмотря на то, что многие программы работают гораздо дольше, чем предполагалось».
Макнамара отметил, что в 2007 году MITRE опубликовала отчёт под названием «Непростительные уязвимости», в котором на первом месте была проблема безопасности памяти. Однако эти ошибки не считаются халатностью при разработке программного обеспечения. «Я не вижу других областей, где допустимо не применять известные решения для устранения серьёзных проблем с безопасностью», — сказал он.
Тем не менее, «будет интересно посмотреть, как отрасль отреагирует на приглашение к комментарию, особенно с учётом того, что в промежутке между этим событием пройдут выборы, — сказал Макнамара. — Будем надеяться, что опасения не перерастут в политические споры».
CISA открыла период общественного обсуждения своего руководства до 16 декабря 2024 года. Пожалуйста, посетите Федеральный реестр, чтобы оставить комментарии.