Log4Shell: если вы не знаете свои зависимости, вы не знаете свою поверхность атаки
Уязвимость Log4Shell показала, что большинство компаний не представляют, какие библиотеки работают внутри их систем.
В начале декабря 2021 года была опубликована информация об уязвимости в библиотеке Log4j - широко распространённом инструменте для логирования в Java-приложениях. Уязвимость получила название Log4Shell и максимальный рейтинг критичности. Она позволяла злоумышленнику выполнить произвольный код на уязвимой системе, просто отправив специально сформированную строку.
Техническая сторона уязвимости интересна специалистам. Для руководителя важно другое: реакция большинства компаний на эту новость была одинаковой - "а у нас есть Log4j?"
И это вопрос, на который во многих компаниях не было ответа.
Почему так сложно ответить на простой вопрос
Log4j - это библиотека. Она не устанавливается отдельно и не видна в интерфейсах. Она входит в состав других продуктов и фреймворков как зависимость. Приложение использует фреймворк, фреймворк использует Log4j - и то, что Log4j присутствует внутри, может не знать никто, кроме разработчиков, которые писали это приложение.
Сложность в том, что современные программные продукты строятся на десятках и сотнях библиотек с открытым кодом. Это нормально и это экономически разумно - не изобретать каждый раз колесо. Но это означает, что поверхность атаки компании включает не только то, что она написала сама, но и всё, что вошло в её системы через зависимости.
Что такое SBOM и почему о нём говорят
SBOM - Software Bill of Materials - это список компонентов программного обеспечения. По аналогии с составом продуктов питания на упаковке: что именно входит в этот продукт.
До Log4Shell понятие SBOM существовало в основном в узких кругах специалистов по безопасности и в регулируемых отраслях. После Log4Shell оно попало в повестку даже у компаний, которые далеки от профессиональной кибербезопасности. Потому что без понимания состава своих систем невозможно ответить на вопрос "затронула ли нас эта уязвимость?"
Исполнительный указ президента США в мае 2021 года уже включал требования к SBOM для программного обеспечения, поставляемого федеральным ведомствам. Log4Shell ускорил этот разговор.
Что это значит для обычной компании
Я не призываю немедленно строить полный реестр всех зависимостей всех систем. Это большая работа, и для многих компаний она избыточна.
Но несколько вещей имеет смысл сделать:
Понять, кто отвечает за реакцию на критические уязвимости. Не "ИТ-отдел вообще", а конкретный человек, который получит информацию об уязвимости и будет координировать проверку и устранение.
Иметь инвентаризацию ключевых систем. Не обязательно детальную на уровне библиотек. Но понимание: какие системы критически важны для бизнеса, кто их поддерживает, как с ними связаться в случае инцидента.
Договориться с поставщиками коммерческого ПО. Если компания использует покупное или заказное программное обеспечение - вопрос "как быстро вы уведомляете об уязвимостях и как быстро выпускаете патчи?" должен быть в контракте или хотя бы в переписке.
Не откладывать обновления. Многие критические уязвимости имеют патч в момент публикации. Компании, которые обновляют зависимости регулярно, уязвимы короткое время. Компании, которые не обновляются годами, живут с рисками, о которых могут не знать.
Что остаётся после шума
Log4Shell остынет как тема через несколько месяцев. Появятся другие уязвимости. Принцип не изменится: каждая используемая библиотека, каждый компонент с открытым кодом - это часть поверхности атаки. Не знать об этом - не значит быть в безопасности. Это значит не знать о своём риске.
Безопасность программного обеспечения - это не только то, что написала ваша команда. Это всё, на чём стоит то, что написала ваша команда.