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 года. Пожалуйста, посетите Федеральный реестр, чтобы оставить комментарии.
Комментарии (40)
kompilainenn2
07.11.2024 12:43А "Правительство США" нельзя было в заголовке написать? Кликбейт наше все?
seregadomain
07.11.2024 12:43Из заголовка я решил, что речь про Россию и не понял что будет с ПО под астра линукс сэ
Nelman86
07.11.2024 12:43Это все равно, что говорить парикмахерам какими ножницами они должны стричь клиентов))) Маразм в правительствах по всему миру только обостряется)
kamaz1
07.11.2024 12:43А я кстати говорю... Ну т.е. я говорю "ножницами а не машинкой", но если бы я предпочитал конкретный тип ножниц, то и их бы просил, почему нет.
drafterleo
07.11.2024 12:43Следующая стадия - приносить инструменты с собой. Дальше - стричься самому (цирюлю, кстати, себя машинкой).
Moog_Prodigy
07.11.2024 12:43Я решил парадокс брадобрея методом выворачивания наизнанку - брадобрей\цирюльник может брить и стричь самого себя, но больше никого. Ну и нормально.
brotchen
07.11.2024 12:43Вы ж не правительство. Вот если правительство будет говорить, чем вас стричь...
drafterleo
07.11.2024 12:43Но при этом государство через СанПиН обязывает парикмахеров дезинфицировать инструментарий:
9.17. Для предупреждения распространения парентеральных гепатитов, ВИЧ-инфекции, туберкулеза, а также других инфекционных и паразитарных заболеваний, проводится дезинфекция рабочих инструментов по режимам, эффективным в отношении возбудителей этих инфекций.
9.17.1. Зажимы, бигуди, колпаки и сетки для химической завивки волос, шапочки для мелирования моют под проточной водой с моющими средствами.
9.17.2. Расчески, щетки, ножницы для стрижки волос моют под проточной водой, дезинфицируют в бактерицидных излучателях, зарегистрированных в установленном порядке и имеющих инструкцию по применению, или в растворах дезинфицирующих средств.
9.17.3. Съемные ножи электрических бритв протирают дважды (с интервалом 15 минут) тампоном, смоченным 70° этиловым спиртом.
brotchen
07.11.2024 12:43Всегда есть какой-то баланс между свободой и регулированием.
P.S. Мне кажется, или этот СанПиН не выполняется в большинстве парикмахерских?
Kelbon
07.11.2024 12:43интересно через сколько лет "внезапно" выяснится, что кто то финансово заинтересованный и связанный с неким языком rust проталкивал эти идеи
WondeRu
07.11.2024 12:43Угу, там и Microsoft с C# и Oracle с Java трутся где-то рядом
drafterleo
07.11.2024 12:43Угу, там и Microsoft с C# и Oracle с Java трутся где-то рядом
А на чём они написаны?
KanuTaH
07.11.2024 12:43Ну, одни дегенераты уже доигрались с "зелёным переходом", сделав свое производство неконкурентоспособным, удачи и этим с такими начинаниями, бгг.
P.S. А когда подобные баги на "безопасных языках" встанут на поток, бюрократы напишут
очередные бумажкисоставят очередные дорожные карты по переходу на очередные "чудо-языки", которые, конечно же, уж в этот-то раз точно решат все проблемы на свете.
kenomimi
07.11.2024 12:43Скорее всего, это очередная диверсионная деятельность. Как тот закон о коровьем выхлопе, например, который фактически похоронил животноводство вряде стран... А учитывая, что за США инициативы повторяют многие страны - так вообще красиво выходит: у себя мы строгий закон приняли, но в одобреных барином конторах следить за его исполнением не будем, зато за всеми остальными следить будем пристально, блокируя их работу.
rukhi7
07.11.2024 12:43мне вообще иногда кажется что весь этот зоопарк языков развели или разводят специально чтобы отучить весь мир от исходных С/С++. На них продолжит только микрософт работать так как ему можно, он очень давно работает на них, ему можно доверять. И микрософт будет всем остальным ИДЕ написанные на С++ продавать недорого. Как говорил один мой американский коллега: "У нас много работы, мы всем нужны. Все замечательно."
Ведь Си-подобный псевдо код у них даже в стандартах получил распространение.
johnfound
07.11.2024 12:43Такая регуляция хуже самой глючной программы. От этого ПО будет еще глючнее. Намного.
rukhi7
07.11.2024 12:43автомобиль тоже средство повышенной опасности, надо тоже запретить, куда смотрит правительство?
NickDoom
07.11.2024 12:43Мдас… хорошо хоть не приказали, на сколько дюймов погружать управляющие стержни в активную зону. Сложно управлять тем, в чём ни хрена не разбираешься :-D
Но я вот не берусь сказать, «как надо», потому что управляемая система слишком сложна для того, чтобы её одной барской указивкой улучшить. Даже будь на месте «барина» — я. Интересное дело получается, потому что дурак с инициативой свою инициативу протолкнёт, а понимающий человек — нет, потому что осознаёт адскую сложность этого всего. А они такие «мы сотворим ритуал обеспечения безопасности и всё станет безопасно». Менору надо или своя есть?
Тут не всякая комиссия поможет, тут целый институт нужен. Причём не сертификаты раздающий и не за соблюдением ритуалов следящий, а реально работающий над предметом. Откуда у них вообще эта больная идея, что основную опасность представляют промахи индекса мимо массива? Основная опасность — неверная модель объекта управления. Большинство техногенных катастроф из-за того, что идеально написанный код управляет совсем не тем, чем он, как он думает, он управляет.
Ну прямо как они сами, чесслово.
boldape
07.11.2024 12:43А я поддерживаю, они не говорят что использовать, а говорят что НЕ использовать и почему. Ничто не мешает, в теории конечно, собраться комитету по стандартизации це и це++ и принять измения в языке которые сделают их хотя бы безопасней чем сейчас, а в идеале достаточно безопасными. И внезапно, тогда никто не будет против использования этих языков. Это прекрасный анальный зонд в головы представителей комитета который показывает чем именно им нужно заняться на следующих митингах и самое прекрасное в этой истории они уже начали этим заниматься.
Изменения в стандартах вокруг безопасности памяти + жёсткие требования по дорожным картам заставят вендоров наконец то перейти с це++11 сразу на какой нибудь це++29, а иначе тюрьма. Это ли не благо?
KanuTaH
07.11.2024 12:43Изменения в стандартах вокруг безопасности памяти + жёсткие требования по дорожным картам заставят вендоров наконец то перейти с це++11 сразу на какой нибудь це++29, а иначе тюрьма. Это ли не благо?
Повышение безопасности кода еще можно было бы назвать "благом" (причем понятие "безопасности" - это не только и не столько "безопасность памяти", но и всякие RCE в результате insecure deserialization, command injection, чем особенно славятся всякие "безопасные по памяти" скриптовые языки и т.п., да и банальных ошибок в логике работы типа TOCTOU тоже хватает), но само по себе требование "перейти с це++11 на язык X", пусть даже в роли X выступает условный "це++29" - это, честно говоря, не выглядит как благо, а выглядит как чисто формальная подмена цели средством, и не факт, что годным.
P.S. Не удивлюсь, если все вообще сведется к наличию правильно оформленной бумажки с дорожной картой класса "ишак, шах или Ходжа" "у кого надо", обладатель бумажки сможет брать заказы у барина, а остальные желающие - нет. И это в лучшем случае, я вон выше не просто так вспомнил про "зеленый переход", а другой коллега - про "закон о коровьем выхлопе".
P.P.S. Чтобы не быть голословным, приведу небольшой пример. Вот некий гражданин решил переписать стандартную юниксовую утилиту
whoamiна "безопасном языке раст". Безопасность памяти и все такое. Но внезапно сбылось это. Причем если бы этот гражданин писал на C, и просто взял бы описание этой структуры из системного хедера вместо использования своей доморощенной структуры, то ничего подобного бы не произошло.
AquariusStar
А на чём писать тогда операционные системы, драйвера, программировать микроконтроллеры?
drafterleo
Думаю, за Rust не заржавеет )).
slinkinone
ИМХО, но язык пока не прошёл проверку временем.
alexac
На расте без использования unsafe большую часть этого кода писать не получится. А unsafe снимает все гарантии безопасного использования памяти. Какой тогда смысл кроме использования более хайпового языка?
Берем современный C++, выключаем исключения и rtti, обмазываем абстракциями использующими RAII. Бьем по рукам за использование сырых указателей без причины, запрещаем использовать UB, про любой референс задаем вопрос "кто владеет объектом и когда его удаляет?", и получается отличный безопасный для памяти код.
Free_ze
Это неправда.
Впрочем, если развенуть это высказывание, то будет много кода без
unsafe. Чем меньше уязвимая поверхность кодовой базы, тем лучше.Контроля заимствований и лайфтаймов для ссылок - нет. Запрета на алиасинг памяти - нет. Весь код - потенциально небезопасен. Чтобы с этим всем выжить, выход один:
Отказываемся от автоматизации в пользу когнитивной нагрузки и неизбежных багов.
alexac
Правда. Unsafe позволяет разыменовывать сырой указатель. В этот момент любые гарантии памяти исчезают напрочь, потому что для сырых указателей borrow-checker не работает и не должен.
Думать о владении и времени жизни нужно всегда, если речь не идет о языке с GC. Да и там иногда приходится. Это вопрос дизайна и архитектуры. Вот только, без контроля со стороны компилятора, можно просто заложить в код инварианты, которые обеспечивают корректность, соблюдать их, и делать только те действия, которые корректны с точки зрения этих инвариантов. А с контролем, зачастую нужно отрефакторить весь код так, чтобы весьма консервативный и ограниченный компилятор согласился с тем, что с доступом к памяти в нем, на самом деле, все в порядке.
Контроль заимствований и времени жизни — это прекрасно. Но как только появляется долгоживущий стейт, на который нужны референсы из нескольких мест, не дай бог еще и циклические (а на низком уровне, на самом деле, этого весьма дохрена) все превращается в сражение с компилятором и переписывание всего вокруг, пока не получится сделать то, что без контроля заимствований и времени жизни просто работает.
AnthonyMikh
А можете привести конкретные примеры?
Free_ze
Внутри unsafe-контекста borrow-checker продолжает работать для ссылок, например. То есть потенциально небезопасная работа будет ограничена непосредственно этим, скажем, сырым указателем, а прочий код будет под контролем, невзирая на окружающий
unsafe.То есть идеоматичный код придется писать в обоих случаях.
playermet
Вот бы еще средний программист всегда знал, где у него UB возникают. Все равно что запертить допускать баги. Причем сразу в asm, и заодно необходимость в выскоуровневых языках отпадает.
sse
На D и Ada
KanuTaH
D и Ada существуют уже давно, и, если бы у них были какие-то действительно весомые преимущества перед мейнстримными языками (а не какие-то "сферические в вакууме") с точки зрения, так сказать, конечного разработчика, то индустрия бы давно их широко использовала без всяких там указивок от американских бюрократов. Но этого не случилось - Ada еще кое-как используется, да и то в основном теми, кто пишет софт для американского Минобороны (ведь это именно оно профинансировало его создание в свое время, так что деваться некуда), а D вообще "забытый ныне язык, некогда подававший надежды".
gev
Rust, Haskell, Idris, Agda...