Heartbleed: когда чужой код становится вашей проблемой
Уязвимость в OpenSSL показала, насколько бизнес зависит от невидимых компонентов, которые никто не контролирует и за которые никто не отвечает.
7 апреля 2014 года была раскрыта уязвимость Heartbleed в библиотеке OpenSSL. OpenSSL - это программный компонент, который обеспечивает шифрование трафика на огромном количестве серверов по всему миру. Уязвимость позволяла читать содержимое памяти сервера - потенциально включая ключи шифрования, пароли и данные пользователей.
Масштаб реакции был соразмерен масштабу проблемы: крупнейшие сервисы экстренно выпускали патчи, рекомендовали пользователям менять пароли, отзывали сертификаты. Для большинства владельцев бизнеса всё это выглядело как "технический кризис где-то в интернете". На самом деле это был урок об устройстве современных ИТ-систем - и об ответственности, которую бизнес несёт за компоненты, о существовании которых он не знает.
Что такое OpenSSL и почему это касается всех
OpenSSL - открытая библиотека, созданная и поддерживаемая небольшим сообществом разработчиков. Она бесплатная. Она используется в серверном программном обеспечении, операционных системах, сетевых устройствах. По различным оценкам, в момент обнаружения Heartbleed около двух третей защищённых веб-серверов в мире использовали эту библиотеку.
Если на вашем сайте есть HTTPS - почти наверняка в цепочке компонентов, которые это обеспечивают, есть что-то, что использовало или использует OpenSSL. Ваша компания не принимала решение об использовании OpenSSL. Ваш подрядчик, возможно, тоже не принимал - он просто использовал серверное ПО, которое содержит OpenSSL внутри.
Это и есть суть проблемы: современные системы построены на слоях зависимостей, которые формируют риск цепочки поставок ПО, который большинство организаций никогда не картографировали. Более ранний случай с вредоносом Flame показал, как канал доставки обновлений сам становится частью атаки.
Проблема невидимых компонентов
После Heartbleed многие организации обнаружили, что не могут быстро ответить на вопрос: "Используем ли мы уязвимую версию OpenSSL, и где именно?" Не потому что небрежны, а потому что OpenSSL был где-то в глубине стека - в операционной системе, в сторонней библиотеке, в программном обеспечении балансировщика нагрузки.
Это не уникальная история про OpenSSL. Современный веб-сервис может содержать сотни сторонних компонентов - библиотек, фреймворков, утилит. Большинство из них никогда не аудировались с точки зрения безопасности теми, кто их использует. Большинство обновляются нерегулярно.
Heartbleed показал, что уязвимость в одном небольшом компоненте, который не замечает никто, может поставить под угрозу всё, что построено поверх него.
Что меняется в управлении ИТ после этого
Правильная реакция на Heartbleed - не просто "обновить OpenSSL и двигаться дальше". Это повод пересмотреть, как организация управляет своими зависимостями.
Инвентаризация компонентов. Знаете ли вы, какое стороннее программное обеспечение и библиотеки используются в ваших системах? Кто отвечает за их обновление? Есть ли процесс отслеживания публикаций об уязвимостях?
Процесс реагирования. Если завтра обнаружится уязвимость в компоненте, который вы используете, - как быстро вы об этом узнаете? Кто принимает решение о срочности обновления? Кто его реализует?
Ответственность на стороне подрядчиков. Если ваши системы поддерживает внешняя компания - прописано ли в договоре, что они обязаны реагировать на критические уязвимости в разумные сроки?
Вопросы для разговора с ИТ-командой
После истории с Heartbleed есть смысл задать несколько практических вопросов:
- Какие сторонние компоненты и библиотеки используются в наших ключевых системах?
- Кто отвечает за мониторинг уязвимостей в этих компонентах?
- Каков процесс реагирования, если критическая уязвимость обнаружена в выходные?
- Когда последний раз проводилось обновление серверного ПО и зависимостей?
Это не технические вопросы в том смысле, что они не требуют от вас технических знаний для оценки ответов. Они требуют только того, чтобы у команды были ответы вообще.