Разговор прост, но проблема, стоящая за ним, не так однозначна. Клиент приобрел серверы в 2017 году, и обычно они обновляются каждые пять-шесть лет. В целом, примерно в период с 2022 по 2023 год они должны были бы задуматься о покупке новых.
Исторически так бы и произошло. Но грянул COVID, и возникли ограничения цепочек поставок. Первоначальное уведомление об окончании срока службы, которое должно было поступить около 2023 года, было продлено: 2026 год для общих обновлений программного обеспечения и 2028 год для уязвимостей безопасности.
Это дало клиенту примерно десять лет жизни на этой серверной платформе, что означает, что для этой «малышки» скоро наступит «средняя школа», а это среда здравоохранения.
Как только COVID отступил, им следовало обновить оборудование тогда. Они этого не сделали. Перенесемся в настоящее: они попросили нас рассмотреть проект и спецификацию материалов, и теперь мы оказались в разгар беспрецедентного ограничения цепочек поставок, когда мы не можем доставить им оборудование из-за того, что происходит с производством AI-чипов и гиперскейлерами.
Это заняло бы восемь-десять месяцев. Кроме того, стоимость оказалась выше, чем в прошлом году, поскольку себестоимость (COGS) резко возросла.
Это ставит их в положение, когда покупка нового выходит за рамки их бюджета. Но даже если бы они могли себе это позволить, они все равно не получили бы оборудование, возможно, в течение года. Затем им пришлось бы заниматься фактическим развертыванием и миграцией. Это подводит их близко к 2028 году, когда заканчивается поддержка уязвимостей безопасности, и, безусловно, отодвигает их за пределы 2026 года для общих обновлений ПО.
И это даже не считая того, что поддержка операционных систем на этих серверах отстает из-за их возраста. Более новые версии VMware не поддерживаются, включая VCF 9, а Broadcom настоятельно призывает клиентов перейти на них. Таким образом, они оказались между молотом и наковальней без простых вариантов.
Технический директор (CTO) спросил: «Что нам делать? Не могу поверить, что вы это с нами делаете».
Больше всего я хочу им помочь. Но мы не можем помочь им так, как они хотят.
Мы много говорим о том, что возраст — плохой показатель риска, и это правда. Поэтому сейчас мы пытаемся провести дерискинг там, где это возможно, и ищем уязвимости, которые можно исправить. Затем есть вещи, которые мы не можем исправить или с которыми ничего не можем поделать. Для них мы должны изучить такие варианты, как покупка нового оборудования или переход в облако, когда мы не можем вовремя получить новое оборудование, и требования соответствия это позволяют.
Это ставит клиента в трудное положение, и здесь нет простых ответов. Поэтому, если нет простого ответа, следующий лучший шаг — уменьшить неопределенность.
Составьте инвентаризацию и определите степень воздействия
Реальность такова: вы не можете оценить риск, если не знаете свои активы, а в большинстве CMDB есть пробелы.
То, как вы получите эту инвентаризацию, зависит от того, что у вас уже есть. Если вы используете сканер уязвимостей, такой как Nessus, Qualys или Rapid7, у вас, вероятно, есть эти данные. Экспортируйте их в CSV, и половина оценки уже сделана.
Если у вас нет сканера, Greenbone OpenVAS бесплатен, с открытым исходным кодом и работает в Docker или на виртуальной машине. Один скан предоставит вам платформы хостов, сопоставленные CVE с оценками серьезности и структурированный вывод.
Если вы предпочитаете что-то более легкое, Nmap по-прежнему является стандартом. Вам нужно запустить его с обнаружением версий служб и выводом в формате XML против ваших собственных диапазонов сети. Таким образом, вы получите активные IP-адреса хостов, открытые порты и баннеры служб.
runZero предлагает бесплатный уровень и, как правило, лучше справляется с отпечатками устройств, чем Nmap, особенно в отношении таких вещей, как сетевые устройства и контроллеры хранения данных.
Любой из этих путей приведет вас к одному и тому же: структурированная инвентаризация, имена хостов, платформы, версии и достаточно деталей, чтобы найти, что уязвимо.
Теперь, окончание срока продажи (end of life) — это когда поставщик прекращает продавать продукт. Окончание поддержки (end of support) — это когда поставщик прекращает выпускать, например, исправления безопасности. Именно эта дата определяет ваше воздействие. Как только платформа пересекает эту черту, список CVE постоянно растет, а список исправлений прекращается.
Существует бесплатный ресурс endoflife.date. Это поддерживаемая сообществом база данных, охватывающая сотни платформ с датами жизненного цикла и общедоступным API. Для всего остального проверяйте страницы жизненного цикла поставщиков.
Результатом будет ваша инвентаризация с прикрепленными датами окончания поддержки и флажком на каждом активе, который пересек границу поддержки.
Для каждого помеченного актива следующий шаг — выяснить, что на самом деле можно использовать для атаки (exploitable). У вас может быть версия программного обеспечения, включенная в CVE, но она была усилена производителем оригинального оборудования (OEM) и на самом деле не является эксплуатируемой.
Если вы работаете с Nmap или проводите ручную инвентаризацию, вам нужно знать о двух базах данных: Национальная база данных уязвимостей NIST и Каталог известных эксплуатируемых уязвимостей CISA (KEV).
Разница между системой с 40 CVE и нулевыми записями KEV и системой с 12 CVE и 3 записями KEV — это разница между управляемым риском и активной опасностью. Возраст оборудования не говорит вам, с чем вы имеете дело, поэтому нам нужен профиль CVE.
Найди, оцени, исправь
Теперь мы используем взвешенную формулу для оценки каждого актива.
Формула, которую я использую: количество KEV, умноженное на 20, плюс наивысший CVSS, умноженный на 4, плюс количество месяцев после окончания поддержки, плюс бонусы за высокую чувствительность данных, подверженность воздействию интернета и активы, которые не могут быть обновлены до стандартов постквантовой криптографии. Настройте веса в соответствии с аппетитом вашей организации к риску.
Этот подход соответствует Системе категоризации уязвимостей CISA по категориям заинтересованных сторон (SSVC), которая ставит статус эксплуатации и контекст миссии выше общих оценок серьезности. Конкретные веса настраиваются. Принцип, согласно которому записи KEV перевешивают серьезность CVSS, а CVSS перевешивает возраст, остается неизменным.
Очередность, основанная на возрасте, ставила их в обратном порядке. Очередность, основанная на риске, ставит их в правильном порядке и разбивает на три группы.
- Уровень 1: требуется немедленное действие. Это активы, у которых истек срок поддержки и есть записи в каталоге KEV, особенно в регулируемых средах или при работе с конфиденциальными данными. У них есть известные и активно эксплуатируемые уязвимости, для которых исправления не предвидятся. В большинстве нормативных актов трудно защитить позицию принятия риска по ним без компенсирующих мер, таких как сегментация сети, WAF или IDS, и это должно включать устранение в рамках определенного графика.
- Уровень 2: управляемый риск с документацией. Это активы, у которых истек срок поддержки, есть количество CVE, но нет текущих записей KEV, или активы, у которых срок поддержки истекает в течение 12 месяцев. Задокументируйте позицию принятия риска: кто утвердил, на каких условиях и на какой срок. Отсутствие такой документации само по себе является замечанием в большинстве систем соответствия требованиям.
- Уровень 3: мониторинг. Это все, что остается в пределах окна поддержки, получает исправления, с управляемыми профилями. Это относится к графику планирования без немедленных действий. Ключевой момент здесь — убедиться, что даты окончания поддержки видны в календаре инфраструктуры, чтобы избежать превращения их в активы Уровня 1 из-за невнимательности.
Последний слой: NIST финализировала постквантовые криптографические стандарты в 2024 году, и не все устаревшее оборудование может поддерживать новые алгоритмы. Некоторые замены будут обусловлены требованиями криптографической миграции, независимо от профиля CVE.
Не игнорируйте постквантовую криптографию. Сбор сейчас, расшифровка позже — это реальность.
Что вы получаете в итоге
После завершения оценки у вас остаются три вещи, которые меняют характер обсуждения планирования.
Во-первых, у вас есть приоритетная очередь на обновление, упорядоченная по риску, а не по возрасту. Это отвечает на вопрос, куда тратить средства в первую очередь, и это обоснованный анализ.
Во-вторых, вы получаете задокументированную позицию принятия риска для всего, от обновления чего вы отказываетесь прямо сейчас. Это тот инструмент соответствия, которого не хватает большинству организаций. Он указывает актив, профиль воздействия, деловое обоснование и то, кто утвердил.
В-третьих, вы получаете последовательность обновлений, которую могут обосновать аудиторы, руководство и ваша собственная команда. В какой-то момент CISO, член совета директоров или аудитор спросит, почему та или иная система все еще работала. Ответ не может быть: «Ну, она еще не в средней школе». Ответ задокументирован, основан на оценке рисков и привязан к реальным данным.
Если вы хотите, чтобы очередь на обновление оставалась актуальной по мере обнаружения новых CVE и уязвимостей, вы можете развернуть платформу, такую как Wazuh, которая автоматически сопоставляет ваши активы с базами данных CVE. Тогда эта единовременная оценка превращается в периодический процесс, питаемый этим постоянным потоком.
Сегодня вы получаете отправную точку, которую любая команда может реализовать без внешних консультантов или значительного бюджета. Большинство компаний, которые проходят этот процесс, находят хотя бы один элемент картины, которого у них не было раньше, и этого обычно достаточно, чтобы изменить порядок очереди.
В условиях, когда бюджеты на обновление ограничены, а сроки растянуты, порядок очереди имеет первостепенное значение.
Эта статья публикуется в рамках сети экспертных авторов Foundry.
Хотите присоединиться?
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Mastin Bailey
