Ризики ланцюга постачання вас заважають? Зберігайте спокій і будьте стратегічними!

Індустрія безпеки колективно втрачає розум, коли в програмному забезпеченні виявляються нові вразливості. OpenSSL не є винятком, і дві нові вразливості переповнили стрічки новин наприкінці жовтня та на початку листопада 2022 року. Виявлення та розкриття інформації є лише початком цього нескінченного циклу вразливостей. Постраждалі організації стикаються з виправленням, яке особливо болісно для тих, хто знаходиться на передовій ІТ. Керівники служби безпеки повинні підтримувати ефективну стратегію кібербезпеки, щоб допомогти відфільтрувати шум від нових вразливостей, розпізнати вплив на ланцюги поставок і відповідно захистити свої активи.

Атаки на ланцюги поставок не зникають

Приблизно за рік ми зазнали серйозних уразливостей у компонентах log4j, Spring Framework та OpenSSL. Експлуатація старих уразливостей також ніколи не припиняється через впровадження, які неправильно налаштовані або які використовують відомі вразливі залежності. У листопаді 2022 року громадськість дізналася про ан кампанія нападу на федеральну цивільну виконавчу владу (FCEB), що пояснюється фінансованою державою загрозою Ірану. Це федеральне утворення США використовувало інфраструктуру VMware Horizon, яка містила вразливість Log4Shell, яка послужила початковим вектором атаки. FCEB було вражено складним ланцюжком атак, який включав бічні переміщення, компрометацію облікових даних, компрометацію системи, збереження мережі, обхід захисту кінцевої точки та криптозлом.

Організації можуть запитати: «Навіщо взагалі використовувати OSS?» після інцидентів безпеки з уразливих пакетів, таких як OpenSSL або Log4j. Атаки на ланцюги поставок продовжують зростати, оскільки повторне використання компонентів має «хороший бізнес-сенс» для партнерів і постачальників. Ми розробляємо системи, змінюючи існуючий код, а не будуючи з нуля. Це робиться для того, щоб зменшити витрати на розробку, оперативно масштабувати та швидко виконати роботу. Програмне забезпечення з відкритим вихідним кодом (OSS) зазвичай вважається надійним через громадський контроль, який воно отримує. Однак програмне забезпечення постійно змінюється, і проблеми виникають через помилки кодування або зв’язані залежності. Нові проблеми також відкриваються завдяки еволюції методів тестування та експлуатації.

Усунення вразливостей ланцюга постачання

Організаціям потрібні відповідні інструменти та процеси для захисту сучасних дизайнів. Традиційні підходи, такі як управління вразливістю або оцінка на певний момент, самі по собі не можуть впоратися. Норми все ще можуть дозволяти ці підходи, що зберігає розрив між «безпечним» і «сумісним». Більшість організацій прагнуть отримати певний рівень зрілості DevOps. «Безперервний» і «автоматизований» є загальними рисами практик DevOps. Процеси безпеки не повинні відрізнятися. Керівники служби безпеки повинні зосереджуватися на етапах створення, доставки та виконання в рамках своєї стратегії безпеки:

• Безперервне сканування в CI/CD: Прагніть захистити конвеєри збірки (тобто, Shift-Left), але визнайте, що ви не зможете сканувати весь код і вкладений код. Успіх підходів зі зсувом вліво обмежується ефективністю сканера, кореляцією результатів сканування, автоматизацією рішень щодо випуску та завершенням сканування у вікнах випуску. Інструменти повинні допомогти визначити пріоритет ризику знахідок. Не всі знахідки є дієвими, а вразливості не можна використовувати у вашій архітектурі.

• Безперервно сканувати під час доставки: Відбувається компроміс компонентів і дрейф середовища. Програми, інфраструктуру та робочі навантаження слід сканувати під час доставки на випадок, якщо щось було скомпрометовано в цифровому ланцюжку поставок під час отримання з реєстрів або сховищ і початкового завантаження.

• Безперервно сканувати під час виконання: Безпека під час виконання є відправною точкою багатьох програм безпеки, а моніторинг безпеки лежить в основі більшості заходів із кібербезпеки. Однак вам потрібні механізми, які можуть збирати та корелювати телеметричні дані в усіх типах середовищ, включаючи хмарне середовище, середовище контейнерів і Kubernetes. Статистичні дані, зібрані під час виконання, повинні використовуватися для попередніх етапів створення та доставки. Ідентифікація та взаємодія служби

• Визначте пріоритетність уразливостей, виявлених під час виконання: Усім організаціям важко вистачити часу та ресурсів, щоб сканувати та виправляти все. Пріоритезація на основі ризиків є фундаментальною для роботи програми безпеки. Вплив в Інтернет є лише одним із факторів. Інший – серйозність уразливості, і організації часто зосереджуються на проблемах високого та критичного рівня, оскільки вони вважаються найбільш впливовими. Такий підхід все одно може витрачати цикли роботи команд інженерів і безпеки, оскільки вони можуть шукати вразливості, які ніколи не завантажуються під час виконання та які не можна використовувати. Використовуйте аналіз середовища виконання, щоб перевірити, які пакети фактично завантажуються в запущені програми та інфраструктуру, щоб знати фактичний ризик безпеки для вашої організації.

Ми створили вказівки щодо конкретного продукту щоб провести клієнтів через божевілля OpenSSL.

Остання вразливість OpenSSL і Log4Shell нагадують нам про необхідність готовності до кібербезпеки та ефективної стратегії безпеки. Ми повинні пам’ятати, що CVE-ID – це лише відомі проблеми загальнодоступного програмного чи апаратного забезпечення. Багато вразливостей залишаються непоміченими, зокрема недоліки домашнього коду або неправильні налаштування середовища. Ваша стратегія кібербезпеки має враховувати розподілені та різноманітні технології сучасного дизайну. Вам потрібна модернізована програма керування вразливістю, яка використовує аналітичну інформацію про час виконання, щоб визначити пріоритетність роботи з усунення для команд інженерів. Вам також потрібні можливості виявлення загроз і реагування, які корелюють сигнали в різних середовищах, щоб уникнути несподіванок.

Про автора

Майкл Ісбіцкі, директор зі стратегії кібербезпеки в Sysdig, досліджував і консультував з питань кібербезпеки більше п’яти років. Він розбирається в безпеці хмари, безпеці контейнерів, безпеці Kubernetes, безпеці API, тестуванні безпеки, мобільній безпеці, захисту додатків і безпечній безперервній доставці. Він керував незліченними організаціями по всьому світу в їхніх ініціативах із безпеки та підтримці їхнього бізнесу.

До свого дослідницького та консультаційного досвіду Майк засвоїв багато важких уроків на передовій ІТ-сфери, маючи понад 20 років досвіду практики та керівництва, зосередженого на безпеці додатків, управлінні вразливими місцями, корпоративній архітектурі та системній інженерії.