Отчет: Цепочка поставок в энергетическом секторе зависит от противников

По оценкам, 90% программных продуктов, используемых для управления энергосистемой США, содержат “вклады” в код российских или китайских разработчиков. Выводы фирмы по управлению киберрисками Fortress Information Security выявляют новые пробелы в цепочке поставок и указывают на острую необходимость в более надежных стратегиях защиты от коварных угроз, которые таятся в глобальной цепочке поставок программного обеспечения, сказал POWER.

Вывод вытекает из недавнего исследования, проведенного Fortress, компанией, специализирующейся на обеспечении безопасности цепочки поставок критически важной инфраструктуры. Начиная с 2022 года, фирма изучила примерно 900 видов программного обеспечения, используемого энергетическими компаниями, включая ИТ-продукты, используемые для управления сетями, а также продукты операционных технологий (OT), которые используются для мониторинга и управления физическими процессами и оборудованием.

“Сюда входят продукты крупных известных поставщиков, такие как фидерные терминалы, хроматографы, сетевые коммутаторы, реле управления и маршрутизаторы”, – говорится в отчете Fortress, опубликованном 5 декабря. “Исследователи извлекли 392 файла, в которых использовалось множество дополнительных инструментов для встроенного программного обеспечения и бинарного анализа. Затем на основе этих файлов они смогли создать 224 спецификации программного обеспечения (SBOM). Они рассматривали в основном открытый исходный код ”. Отмечается в нем.

Из 7 918 рассмотренных компонентов Fortress 13% были предоставлены российскими и китайскими разработчиками. Однако фирма обнаружила, что 90% продуктов, используемых для управления энергосистемой США, содержат компоненты от разработчиков, которые идентифицируются как российские или китайские. Исследователи также обнаружили вклады Кубы, Ирана и Северной Кореи.

Чтобы внести ясность, “исследователи считали компоненты, внесшие вклад, поступающими из России, Китая или любой другой страны, только в том случае, если создатели указывали страну своего происхождения”, – говорит Фортресс. “В список этой страны были внесены только те разработчики, которые идентифицировали себя на платформе разработки программного обеспечения как выходцы из какой-либо страны. На платформах нет информации, указывающей на то, что код является результатом проекта, санкционированного государством”. В то время как Fortress видит “четкую корреляцию между повышенной уязвимостью некоторых материалов и страной происхождения”, ее эксперты “пока не могут установить, является ли страна происхождения причиной более высокого числа”, признается в отчете.

Тем не менее, исследование показывает, что программное обеспечение с кодом российского или китайского производства, изученное Fortress Research, “в 2,25 раза более подвержено уязвимостям”, отмечается в отчете. “Возможно, еще большую тревогу вызывает то, что программное обеспечение в три раза чаще имеет критические уязвимости — уязвимости, которые легче всего использовать и с большей вероятностью приведут к повреждению оборудования”.

Давние уязвимости

программное обеспечение, встроенное непосредственно в аппаратное обеспечение, которое обеспечивает низкоуровневый контроль над конкретным оборудованием устройства — показывает наибольшее количество уязвимостей, в среднем 620 уязвимостей на продукт. “Согласно отчету, в встроенном ПО,но в операционных системах было столько же критических уязвимостей, причем 12% были критическими”, — отмечается в нем. “В целом, примерно 7% всех уязвимостей были критическими — уязвимостями, которые должны быть приоритетными для устранения”.

В другом потенциально тревожном выводе отчета говорится о том, что уязвимости, встроенные в программное обеспечение, выполняющее критически важные операции и компоненты, не привлекают немедленного внимания поставщиков или поставщиков коммунальных услуг. Хотя уязвимостям, как правило, семь лет, средний возраст критических уязвимостей составляет почти три года. Между тем, только 10% компонентов ответственны за 92% наиболее критических уязвимостей, говорится в отчете. “Два компонента, glibc и linux_kernal, были ответственны примерно за 40% этих потенциальных уязвимостей”.

Отчет Log4J и SolarWinds выходит на фоне того, что действенные усилия по смягчению последствий кибербезопасности демонстрируют “замедление” по сравнению с темпами, набранными после кризисов, высокоразвитых атак на национальные государства более трех лет назад. “Эти два фактора, атака и уязвимость, во многом определяли киберполитику исполнительной власти. Но поскольку мы люди, мы склонны забывать о кризисе”, – сказал Сантос.

Хотя нормативные акты заставили ИТ-отделы сосредоточиться на безопасности программного обеспечения, “за последние пару лет ничего не произошло”, – отметил он. “Сейчас давление спало, регулирующие органы замедляются, они чувствуют давление производителей программного обеспечения и уступают ему”, – сказал он. “И конечным результатом является то, что наша сеть не так безопасна, как должна быть, учитывая, что мы знаем, что наши противники могут использовать can, спрятанный глубоко внутри программного обеспечения, для выполнения своих задач”, – сказал он. “Мы опубликовали отчет, потому что нам нужно продолжать напоминать людям, что это большая проблема”.

По словам Сантоса, ключевое решение может заключаться в точном выявлении проблемных компонентов. Фирма была непреклонна в своей пропаганде всеобщего внедрения SBOM как наиболее эффективного способа пролить свет на уязвимости в продукте. “В нашем исследовании мы показали, что если вы исправите 10 компонентов — если мы сможем исправить эти компоненты, сделать их безопасными, обновить программное обеспечение, используемое в полевых условиях, — вы устраните 70% уязвимостей”, – сказал он. “Это самое дешевое решение, но оно все равно недешевое, так что это должны быть инвестиции”. 

Однако, кроме того, Fortress предполагает, что кибербезопасность должна быть ключевым критерием закупок, хотя это потребует большей определенности от федерального правительства. “Америке необходимо регулирование платформ разработки программного обеспечения — либо со стороны промышленности, либо из Вашингтона”, – говорится в нем.

SBOM: “Список ингредиентов’ программного обеспечения

SBOM – это, по сути, “список ИТ-компонентов программного обеспечения”, – объяснил Сантос. “Программное обеспечение больше не кодируется — оно собирается, как Lego из кубиков” из каталогов. Блоки, например, содержат базу данных или экран входа в систему, сказал он. “Итак, SBOM – это список компонентов Lego в нашем программном обеспечении”.

Процесс составления “списка ингредиентов” сложен, учитывая различный вклад в программный продукт. Ссылаясь на технологические исследования и консалтинговую фирму Gartner, в отчете отмечается, что, по оценкам, “от 40% до 80%” строк в коде нового программного проекта поступают от третьих сторон, таких как среда выполнения, библиотеки и специалисты по разработке компонентов и программного обеспечения.

Появление искусственного интеллекта (ИИ), который автоматизирует создание программного обеспечения, ставит новые задачи “по маркировке и пониманию того, что содержится в программном обеспечении”, – сказал Сантос. Однако еще больший риск могут представлять более старые версии программного обеспечения, которые могут включать непонятные компоненты, сказал он.

Ключевая причина, по которой SBOM стали важнейшим средством смягчения последствий кибербезопасности, заключается в том, что они могут обеспечить прозрачность того, из чего состоит программное обеспечение. По словам Сантоса, SBOM также помогли командам безопасности отслеживать и смягчать ущерб от атак, таких как атака SolarWinds 2020 года и более поздние атаки программ-вымогателей в программных приложениях MOVEit.

Тем не менее, организации изо всех сил пытаются внедрить SBOM. По данным Gartner, только 5% организаций внедрили SBOM, хотя, по прогнозам Gartner, к 2025 году 60% организаций могут “санкционировать и стандартизировать SBOM” в практике разработки программного обеспечения. По словам Fortress, “эти цифры все еще сильно отстают”. Фирма отмечает: “Требуется всего лишь черный ход в одной компании, в одном критически важном секторе, чтобы дать злоумышленникам доступ к системам, обслуживающим критически важные службы, такие как электросеть”.

По словам Сантоса, в энергетическом секторе “то, что мешает всерьез” внедрять SBOM, имеет две причины. Одна из них заключается в том, что “коммунальные предприятия сейчас находятся под огромным давлением затрат”, – сказал он. В то же время разработчики программного обеспечения сопротивлялись СБОМ. Сантос предполагает, что это может быть связано с опасениями по поводу затрат и ответственности. “По моим оценкам, поставщикам потребуется 40 миллиардов долларов на исправление программного обеспечения”, – сказал он.

Некоторые утилиты используют программное обеспечение 10-летней давности, и это создает круговую дилемму с вопросами о том, “чья работа – это исправлять это”, – сказал он. “Старое оборудование по-прежнему остается уязвимым, и производители отказываются его чинить. Итак, теперь, по умолчанию, это проблема утилиты, но им действительно трудно с этим справиться, потому что вам нужно по-настоящему разобраться в программном обеспечении, а это очень дорого ”.

Что необходимо: совместные усилия для повышения прозрачности

В США федеральные структуры , такие как Агентство по кибербезопасности и инфраструктурной безопасности (CISA), поддерживают SBOM как важнейший инструмент предотвращения кибератак. Двухпартийная комиссия по соляриям киберпространства в 2020 году призвала федеральное правительство требовать СБОМ для программного обеспечения, которое оно закупает, а в 2021 году Белый дом издал распоряжение 14028, согласно которому правительственные учреждения должны иметь СБОМ для программного обеспечения, приобретаемого начиная с 2024 года.

Однако промышленность жаждет большей определенности, предполагает Fortress. “Решение Конгресса в 2022 году исключить формулировку из Закона о разрешении национальной обороны (NDAA), которая требовала бы от производителей программного обеспечения включать SBOM в продукты, предлагаемые федеральным агентствам, безусловно, запутало картину”, – говорится в нем.

Наблюдается определенный прогресс.   10 августа CISA обратилась к сообществу разработчиков с открытым исходным кодом с просьбой поделиться идеями о том, как защитить код от их сообщества. “Мы надеемся подготовить отчет на основе этих предложений, который может быть опубликован позже в этом году”, – отмечает Fortress.

CISA также работает над созданием “Общей формы самоаттестации защищенного программного обеспечения для государственных поставщиков”, документа, который, по словам Fortress, потребует от производителей программного обеспечения, поставляющих продукты федеральному правительству, гарантировать внедрение конкретных методов обеспечения безопасности. Эта мера будет означать, что “производители программного обеспечения должны будут либо пообещать, что продукты проходят тестирование, либо установить конкретные сроки проведения тестирования”, – поясняют в фирме.

Fortress предполагает, что после разработки разумного и надежного стандарта все стороны могут сотрудничать с правительством для разработки “разумных механизмов обеспечения соблюдения”. В нем отмечается: “Если отрасль предпримет шаги по добровольному требованию SBOM и форм аттестации, тем меньше правительству придется их санкционировать”.

Тем не менее, на данный момент сотрудничество частного сектора и отраслевые решения остаются неотъемлемой частью. “Сообщество разработчиков программного обеспечения оказало бы всем нам большую услугу, если бы объединило усилия для обеспечения безопасности использования кода на платформах. Особенно когда эти компании пытаются избежать выплаты 40 миллиардов долларов ”, – говорится в сообщении фирмы.

“Никто не хочет создавать ситуацию, когда нам понадобится помощь индустрии программного обеспечения, но нам нужно, чтобы индустрия программного обеспечения нашла решения вместо борьбы с законодательством SBOM, что, по сообщениям, делали их лоббисты до того, как положение SBOM было исключено из NDAA”.

Author: admin