Риски цепочки поставок подвели вас? Сохраняйте спокойствие и будьте стратегическими!

Индустрия безопасности коллективно сходит с ума, когда обнаруживаются новые уязвимости в программном обеспечении. OpenSSL не является исключением, и две новые уязвимости заполонили новостные ленты в конце октября и начале ноября 2022 года. Обнаружение и раскрытие — это только начало этого бесконечного цикла уязвимостей. Пострадавшие организации сталкиваются с необходимостью восстановления, что особенно болезненно для тех, кто находится на переднем крае ИТ. Лидеры безопасности должны поддерживать эффективную стратегию кибербезопасности, чтобы помочь отфильтровать часть шума о новых уязвимостях, распознать влияние на цепочки поставок и соответствующим образом защитить свои активы.

Атаки на цепочки поставок никуда не денутся

Примерно за год мы столкнулись с серьезными уязвимостями в компонентах, включая Лог4дж, Spring Frameworkи OpenSSL. Эксплуатация старых уязвимостей также никогда не прекращается из-за неправильно настроенных реализаций или использующих известные уязвимые зависимости. В ноябре 2022 года общественность узнала о кампания нападения на федеральную гражданскую исполнительную власть (FCEB), связанный с иранской угрозой, спонсируемой государством. Эта федеральная организация США использовала инфраструктуру VMware Horizon, содержащую уязвимость Log4Shell, которая послужила исходным вектором атаки. FCEB подвергся сложной цепочке атак, которая включала боковое перемещение, компрометацию учетных данных, компрометацию системы, сохраняемость сети, обход защиты конечных точек и криптоджекинг.

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

Устранение уязвимостей цепочки поставок

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

• Непрерывное сканирование в CI/CD: Стремитесь защитить конвейеры сборки (например, сдвиг влево), но признайте, что вы не сможете сканировать весь код и вложенный код. Успех подходов со сдвигом влево ограничен эффективностью сканера, корреляцией выходных данных сканера, автоматизацией решений о выпуске и завершением сканирования в окнах выпуска. Инструментарий должен помочь расставить приоритеты по риску результатов. Не все результаты можно принять, а уязвимости в вашей архитектуре могут оказаться непригодными для эксплуатации.

• Непрерывно сканировать во время доставки: Произошла компрометация компонентов и дрейф среды. Приложения, инфраструктура и рабочие нагрузки должны сканироваться во время доставки на случай, если что-то было скомпрометировано в цифровой цепочке поставок при получении из реестров или репозиториев и начальной загрузке.

• Непрерывно сканировать во время выполнения: Безопасность во время выполнения является отправной точкой многих программ безопасности, а мониторинг безопасности лежит в основе большинства усилий по обеспечению кибербезопасности. Однако вам нужны механизмы, которые могут собирать и сопоставлять данные телеметрии во всех типах сред, включая облачные среды, контейнеры и среды Kubernetes. Информация, собранная во время выполнения, должна учитывать более ранние этапы сборки и доставки. Взаимодействие с идентификацией и услугами

• Приоритизируйте уязвимости, обнаруженные во время выполнения: Всем организациям не хватает времени и ресурсов, чтобы все проверить и исправить. Приоритизация на основе рисков имеет основополагающее значение для работы программы безопасности. Воздействие Интернета — это лишь один из факторов. Другой — серьезность уязвимости, и организации часто сосредотачиваются на проблемах высокой и критической серьезности, поскольку считается, что они оказывают наибольшее влияние. Этот подход все еще может привести к потере циклов инженеров и специалистов по безопасности, поскольку они могут гоняться за уязвимостями, которые никогда не загружаются во время выполнения и которые нельзя использовать. Используйте аналитику времени выполнения, чтобы проверить, какие пакеты на самом деле загружаются в работающие приложения и инфраструктуру, чтобы узнать реальную угрозу безопасности для вашей организации.

Мы создали руководство по конкретному продукту чтобы провести клиентов через недавнее безумие OpenSSL.

Последняя уязвимость OpenSSL и Log4Shell напоминают нам о необходимости обеспечения готовности к кибербезопасности и эффективной стратегии безопасности. Мы должны помнить, что CVE-ID — это всего лишь известные проблемы в общедоступном программном или аппаратном обеспечении. О многих уязвимостях не сообщается, особенно о недостатках в собственном коде или неправильных конфигурациях среды. Ваша стратегия кибербезопасности должна учитывать распределенные и разнообразные технологии современного дизайна. Вам нужна модернизированная программа управления уязвимостями, которая использует аналитические данные во время выполнения для определения приоритетов работы по исправлению для инженерных групп. Вам также нужны возможности обнаружения угроз и реагирования, которые сопоставляют сигналы в разных средах, чтобы избежать неожиданностей.

Об авторе

Майкл Исбитски, директор по стратегии кибербезопасности в Sysdig, занимается исследованиями и консультированием по вопросам кибербезопасности более пяти лет. Он разбирается в облачной безопасности, безопасности контейнеров, безопасности Kubernetes, безопасности API, тестировании безопасности, мобильной безопасности, защите приложений и безопасной непрерывной доставке. Он руководил бесчисленным количеством организаций по всему миру в их инициативах по обеспечению безопасности и поддержке их бизнеса.

Прежде чем заняться исследованиями и консультированием, Майк усвоил много тяжелых уроков на переднем крае ИТ благодаря более чем 20-летнему опыту практической работы и руководящей работы в области безопасности приложений, управления уязвимостями, корпоративной архитектуры и системной инженерии.