Підприємства можуть слідувати детальним рекомендаціям і застосовувати наявні виправлення та застосовувати найкращі методи у відповідь на log4j. Але на другому кроці вони мають загальний погляд на процеси, пов’язані з ланцюгами постачання програмного забезпечення.
Зрештою, навіть Log4Shell, незалежно від того, наскільки значущим для безпеки є проміжок, є «лише» несправним компонентом у ланцюжку постачання програмного забезпечення», — каже Удо Шнайдер, європейський проповідник безпеки Інтернету речей у Trend Micro.
Log4Shell – чи знаєте ви свій ланцюг поставок програмного забезпечення?
Звичайно, критична загроза, яку створює вразливість Log4Shell, вимагає негайної реакції. Але на другому кроці компаніям, як правило, доводиться задавати собі питання про процеси, пов’язані з ланцюгами постачання програмного забезпечення та задокументованими (?) залежностями.
Уразливість Log4Shell, про яку стало відомо кілька днів тому, у всіх на вустах і тримає експертів з безпеки в усьому світі напоготові. BSI говорить про «надзвичайно критичну загрозливу ситуацію», оскільки вразлива бібліотека Log4J є, так би мовити, «стандартом журналу» в середовищах Java. Відповідно, він також використовується в тисячах додатків та Інтернет-сервісів. Крім того, уразливістю легко зловживати, і в багатьох випадках її можна використати віддалено, що зрештою дозволяє довільне виконання команд. Справжній кошмар з точки зору кібербезпеки! Організації можуть слідувати нашим докладним рекомендаціям і застосовувати наявні виправлення та застосовувати найкращі практики для негайного реагування. Але на другому кроці вони мають загальний погляд на процеси, пов’язані з ланцюгами постачання програмного забезпечення. Зрештою, навіть Log4Shell, незалежно від того, наскільки важливою для безпеки є вразливість, є «лише» несправним компонентом у ланцюжку постачання програмного забезпечення.
Log4Shell несправний будівельний блок
Щоб зрозуміти ланцюжки постачання програмного забезпечення та їх контекст, допоможе поглянути на «реальний» світ, наприклад, виробництво електронних виробів. Так звані «переліки матеріалів» (BOM – Bill of Material) для вузлів є звичним явищем. Якщо ви розглядаєте одну друковану плату як збірку, відповідний список деталей містить список усіх використаних компонентів, таких як резистори, конденсатори, діоди, мікросхеми та багато іншого. Для кожного компонента також зберігаються точні параметри, виробники, ціни, джерела постачання та, зрештою, також серійні номери або принаймні інформація про партію.
Якщо є інформація від виробника одного з компонентів про те, що певні компоненти партії не відповідають заданим значенням температури, можна точно відстежити, які плати (кожна з власним серійним номером) а) постраждали та б ) чи є потреба в діях. Якщо необхідно вжити відповідних заходів, інформація про те, які вузли зазнали впливу (на основі серійного номера), звичайно, буде дуже корисною. Зрештою, ця процедура продовжується з «зборками» майже за бажанням ... доки врешті-решт ви не отримаєте масивні установки, такі як LHC у CERN. Навіть з такою великою машиною відмова крихітного компонента SMD може призвести до відмови всієї машини. Якщо, наприклад, стає відомо про дефектні партії, ви, зрештою, повинні мати можливість перевірити кожен окремий встановлений резистор.
Перелік матеріалів програмного забезпечення (SBOM)
Саме так працюють ланцюги поставок програмного забезпечення, тобто SBOM» — і, зокрема, повертаючись до Log4Shell: чи можете ви швидко сказати, чи впливає на вас ця прогалина? З вашим власним програмним забезпеченням, яке використовує Log4J, на запитання можна швидко відповісти. Часто навіть такі служби SCM, як GitHub або GitLab, пропонують такі функції напряму. Але як щодо тимчасових залежностей? Чи використовує Log4J стороння бібліотека, яку ви використовуєте? Або ще гірше – чи використовує бібліотека, якою ви користуєтеся, бібліотеку, яка, у свою чергу, залежить від (тощо) бібліотеки, яка використовує Log4J? Чи покладається придбане програмне забезпечення постачальника послуг на Log4J? Чи використовує хмарний сервіс Log4J?
Вміст SBOM (Зображення: Trend Micro).
Питання за питаннями, які потребують відповідей, які вимагають від вас боротьби з SBOM. Log4Shell чітко показує проблеми, які виникають, коли ланцюжок постачання програмного забезпечення не документується. Але не обманюйте себе. Log4Shell, безумовно, зараз є найгіршим сценарієм. Але навіть із простими «несправностями», які не мають прямого відношення до безпеки, питання про те, чи постраждали ви, є важливим!
Залежності документів
По суті, SBOM — це документування залежностей. Це можуть бути залежності у формі програмного забезпечення (компонентів), а також послуги, ліцензії, сервери та багато іншого. Особливо коли йдеться про моделювання програмних залежностей, з часом з’явилися два формати обміну: CycloneDX і SPDX. Обидва дозволяють описувати різні компоненти програмного забезпечення, включаючи можливі залежності:
Але описової мови недостатньо. Швидше, конкретне середовище також має бути описано та постійно оновлюватися. Звичайно, ці описи можна створити вручну - і іноді, наприклад, коли в залежності від зовнішніх служб немає іншого вибору. Однак, коли справа доходить до створення описів програмного забезпечення, ручні зусилля не мають сенсу. Тут створення та підтримка цих описів має відбуватися повністю автоматично як частина конвеєра CI/CD. В основному є два підходи: інтеграція в процес збірки та сканування артефактів збірки.
Інтеграція CI/CD – процес створення
Створення SBOM під час процесу збірки (Зображення: Trend Micro).
І CycloneDX, і SPDX мають інструменти, які можна інтегрувати безпосередньо в процес збірки. Вони витягують безпосередньо «біля джерела» (перехідні) залежності. Це можуть бути бібліотеки, виконувані файли, а також контейнери або шари контейнерів. Пряма інтеграція також дає змогу відстежувати залежності, які існують, наприклад, лише під час самої збірки, але не в готовому продукті.
Інтеграція CI/CD – створення артефакту
Навіть якщо вам не дозволено безпосередньо втручатися в процес збірки, існують інструменти для CycloneDX і SPDX, які сканують кінцевий результат «після». Це означає, що ці інструменти витягують залежності, наприклад, із програми Java та документують їх. Оскільки ці інструменти завжди бачать лише кінцевий результат, цілком можливо, що деякі залежності просто не помічаються, оскільки їх більше не можна вивести з кінцевого результату.
Моніторинг вразливостей
Створення SBOM після процесу збірки (Зображення: Trend Micro).
Для компаній, які зацікавлені лише в моніторингу вразливостей, багато з цих інструментів також пропонують пряму кореляцію з базами даних уразливостей. Це означає, що вихідні дані містять не лише знайдені компоненти, а й список вразливостей. Це можна порівняти, наприклад, з інтеграцією snyk, Trend Micro Application Security або Trend Micro Container Security у конвеєр CI/CD.
Відстеження залежностей OWASP
Якщо відстеження та документування ліцензій, запасів або ступеня розповсюдження також відіграють важливу роль, доступні інші рішення (додатково). У цьому середовищі інструмент відстеження залежностей OWASP (Open Web Application Security Project), безумовно, є одним із найкращих. Як рішення з відкритим вихідним кодом, воно зазвичай інтегрується в конвеєри CI/CD і отримує туди дані SBOM — або через дані CycloneDX/SPDX (вручну, API), або безпосередньо з процесу збірки. Крім того, Dependency Track автоматично зберігає дані про вразливості з різних баз даних про вразливості та постійно корелює дані з (історичних) збірок і вразливостей. Збіги відповідно відображаються на інформаційній панелі або повідомляються безпосередньо через чат та інтеграцію CI/CD або, за бажанням, пересилаються до інструментів для автоматичного виправлення.
Інтеграція Dependency Track (Зображення: https://github.com/DependencyTrack/dependency-track )
Dependency Track — це база даних, за допомогою якої можна легко відповісти на запитання: «Де на мене впливає Log4Shell». Ця відповідь містить не лише поточні версії програмного забезпечення, а й описи старих версій. Тому можливим висновком може бути те, що поточна версія не впливає на компанію (оскільки вона достатньо виправлена), але це стосується 34 старіших версій. Якщо тепер ви також відстежуєте інформацію про кількість встановлених версій, це майже ідеальні дані для обґрунтованої оцінки ризику.
Висновок щодо Log4j, Log4Shell і ланцюжків поставок
Нарешті, важливо вміти відповісти на запитання, поставлені на початку: чи використовуємо ми (безпосередньо чи в нашому ланцюжку постачання програмного забезпечення) Log4J? Якщо так, то якою мірою (версія, дистрибутив) на нас впливає Log4Shell? Зусилля, необхідні для відповіді на це запитання, є індикатором того, якою мірою ви маєте розуміння свого ланцюжка поставок програмного забезпечення та чи варто використовувати інструменти, щоб допомогти.
Що стосується інструментів, важливо уточнити, чи йдеться «тільки» про питання «чи мене це стосується». У цьому випадку допоможуть такі інструменти, як snyk або параметри, інтегровані в GitHub і GitLab. З іншого боку, якщо потрібне більш повне уявлення, існують інші рішення для захоплення та каталогізації програмних артефактів. Вони є як комерційними, так і безкоштовними. З табору з відкритим кодом Dependency Track, безумовно, є найпоширенішим тут.
Зрештою, однак, слід зазначити, що прогалини в безпеці є важливим аргументом для управління ланцюгом поставок програмного забезпечення, але, звичайно, не єдиним!
Більше на TrendMicro.com
Про Trend Micro Як один із провідних світових постачальників ІТ-безпеки, Trend Micro допомагає створити безпечний світ для обміну цифровими даними. Завдяки більш ніж 30-річному досвіду в галузі безпеки, глобальним дослідженням загроз і постійним інноваціям Trend Micro пропонує захист для компаній, державних установ і споживачів. Завдяки нашій стратегії безпеки XGen™ наші рішення отримують переваги від поєднання методів захисту між поколіннями, оптимізованих для передових середовищ. Інформація про мережеві загрози забезпечує кращий і швидший захист. Оптимізовані для хмарних робочих навантажень, кінцевих точок, електронної пошти, Інтернету речей і мереж, наші підключені рішення забезпечують централізовану видимість у всьому підприємстві для швидшого виявлення загроз і реагування.