Патч-менеджмент: Shellshock показал, где у нас прорехи
Shellshock вскрыл слабое место в процессе управления патчами. Ввели жёсткий регламент по CVSS и автоматизировали уведомления через RSS-фиды NVD.
Shellshock и серия критических CVE в 2014 году выявили слабость в процессах управления патчами в инфраструктуре клиентов
Когда мы разбирали Shellshock, стало неудобно. Не из-за самой уязвимости - с патчингом справились быстро. Неудобно стало из-за другого: мы поняли, что работали реактивно. Кто-то прочитал про CVE-2014-6271 в твиттере, написал в чат, дальше понеслось. Системного процесса, который бы подсветил уязвимость раньше или хотя бы одновременно - не было.
Это неприятное открытие, если ты ведёшь чужую инфраструктуру по договору managed-сопровождения.
Что конкретно сломалось
Посмотрели честно на то, как выглядел наш «процесс» до Shellshock. Он выглядел примерно так:
- Новость попадала к нам случайно - через HackerNews, рассылки Red Hat, слак с коллегами, иногда через клиента, который сам увидел раньше нас.
- Оценка приоритета делалась на глазок: «серьёзное» или «подождёт». Никакого формального критерия не было.
- Сроки тоже были на глазок. Что-то патчили на следующий день, что-то откладывалось на плановое обслуживание через неделю.
Для большинства уязвимостей это работало - потому что большинство уязвимостей не критические, и неделя задержки ничего не меняет. Но Shellshock с оценкой CVSS 10.0 и активной эксплуатацией в первые сутки - это другая история. Там счёт шёл на часы.
Новый регламент
После разбора полётов договорились о правилах, которые теперь фиксируем письменно:
- CVSS 9.0 и выше - патч применяется в течение 24 часов с момента появления пакета от дистрибутива. Исключений нет. Если пакет не вышел - временное смягчение (отключение уязвимого компонента, сетевые ограничения) до появления патча.
- CVSS 7.0-8.9 - 72 часа. В это окно входит оценка применимости: уязвимость может быть критической по CVSS, но не эксплуатируемой в конкретной конфигурации клиента.
- CVSS ниже 7.0 - плановое обслуживание, без экстренного реагирования.
CVSS как метрика не идеальна - она не учитывает, есть ли у вас уязвимый компонент вообще, открыт ли вектор атаки наружу, насколько ценны данные на сервере. Но она объективна и общепринята. Лучше формальный критерий, который иногда оказывается избыточным, чем никакого.
Отдельно зафиксировали: CVSS - это вход в процесс, но не конец оценки. Инженер, который берёт уязвимость в работу, обязан проверить, применима ли она к конфигурации клиента, и задокументировать вывод. «CVE-2014-6271, bash, CGI не используется, вектор не применим, патч ставим планово» - это нормальный вывод.
Автоматизация уведомлений
Следующий вопрос - как узнавать о новых CVE раньше, чем они попадают в твиттер. У NVD (National Vulnerability Database) есть RSS-фиды по разным критериям, в том числе фид уязвимостей с оценкой CVSS выше заданного порога.
Написали небольшой скрипт, который:
- Каждый час забирает RSS-фид
https://nvd.nist.gov/feeds/xml/cve/в XML-формате. - Парсит записи, фильтрует по CVSS >= 7.0.
- Смотрит на ключевые слова в описании - список технологий, которые реально присутствуют в инфраструктуре клиентов: bash, apache, nginx, openssl, kernel, openssh, php, mysql, postgresql, windows, и т.д.
- При совпадении отправляет письмо дежурному инженеру с заголовком CVE, оценкой и ссылкой на NVD.
Скрипт простой, примерно 80 строк на Python. Запускается через cron. Никаких баз данных, никакой подписки - просто RSS и почта. Первый вариант занял вечер, второй (с фильтрацией по ключевым словам) - ещё один вечер.
Не коммерческое решение, не продукт - но для наших нужд достаточно. Главное, что теперь про Shellshock мы бы узнали не из твиттера.
Что показала проверка
Прогнали скрипт в режиме «а что было бы, если бы он работал раньше». По CVE за последние три месяца - там несколько позиций с CVSS 7+ по OpenSSL, bash и ядру Linux, которые мы либо узнали с задержкой, либо узнали вовремя, но только потому что повезло.
Это примерно то, чего и ожидали. Не катастрофа, но повод зафиксировать: процесс нужен, случайность - не процесс.
Что не решено
Регламент сроков и автоматические уведомления - это реакция. Но Shellshock поднял ещё один вопрос: а знаем ли мы точно, что установлено на серверах клиентов? Если завтра выйдет критическая CVE по конкретной версии пакета - есть ли у нас инвентаризация, которая скажет, на каких серверах этот пакет стоит?
Честный ответ: частично. У части клиентов есть Zabbix с мониторингом, из которого можно вытащить версии. У части - только базовое наблюдение, без детального инвентаря программного обеспечения.
Это следующая задача. Но не на эту неделю.