Meltdown и Spectre: когда нижний слой вычислений стал ИБ-повесткой
Что уязвимости в процессорах означают для руководителей и почему это меняет разговор об ИБ на уровне инфраструктуры.
В первые дни января 2018 года появились детали двух уязвимостей - Meltdown и Spectre, - которые затронули практически все современные процессоры, выпущенные за последние двадцать лет. Не конкретный продукт, не конкретная ОС, не конкретное приложение. Сам процессор.
Для людей, которые думают об ИТ на уровне бизнеса, это нетривиальный момент. До сих пор модель угроз строилась на допущении: если правильно настроен периметр, правильно написан код, правильно разграничены права - система защищена. Meltdown и Spectre говорят, что это допущение неполное.
Что произошло технически, коротко
Оба класса уязвимостей связаны с механизмом, который называется спекулятивным исполнением. Процессоры уже несколько десятилетий предугадывают, какой код будет выполнен следующим, и выполняют его заранее - чтобы не простаивать. Это повышает производительность. Исследователи обнаружили, что через этот механизм можно извлечь данные из памяти, к которой у вас формально нет доступа - в том числе из других виртуальных машин на том же физическом сервере.
Это не дыра в приложении. Это дыра в модели изоляции, которая считалась надёжной.
Почему это важно для бизнеса, а не только для ИТ
Облачные платформы работают на принципе разделения физических ресурсов между клиентами. Виртуальные машины разных компаний живут рядом на одном железе. Meltdown и Spectre в теории делают возможным чтение данных соседа - не с вероятностью 100%, не легко, но принципиально.
Это меняет не только технический разговор. Это меняет вопрос о том, что вообще означает "изоляция" в облаке - понятие, на котором держится весь разговор о соответствии требованиям при работе с чувствительными данными.
Отдельная история - патчи. Производители ОС и облачных платформ выпустили обновления быстро. Но часть патчей снижала производительность процессора на несколько процентов для определённых рабочих нагрузок. Для нагруженных систем это не абстрактная цифра.
Что это означает для инфраструктурных решений
Несколько выводов, которые имеет смысл проверить:
Первый - патч-менеджмент на уровне железа и прошивок. Большинство компаний наладили обновление ПО, но гораздо реже следят за обновлениями прошивок серверов и версий микрокода процессоров. После Meltdown/Spectre это отдельная строчка в процессе управления уязвимостями.
Второй - облачные провайдеры и прозрачность. Если компания хранит чувствительные данные в облаке, имеет смысл запросить у провайдера подтверждение того, что патчи применены и используются изолирующие механизмы нового поколения. Большинство крупных платформ это сделали, но лучше иметь документальное подтверждение.
Третий - собственные серверы. Если в компании есть on-premise инфраструктура, вопрос о своевременном обновлении прошивок и ОС становится острее. Это не задача "когда-нибудь потом".
Что изменилось в модели угроз
До сих пор в большинстве компаний модель угроз строилась снизу вверх: физическая безопасность дата-центра считается решённой проблемой, дальше работаем с сетью, ОС, приложениями и данными.
Meltdown и Spectre добавляют слой, который находится ниже ОС - архитектуру самого процессора. Это не повод для паники, но повод для пересмотра допущений. Если безопасность системы опирается на гарантии изоляции виртуальных машин - эти гарантии нужно верифицировать конкретнее, чем раньше.
Практические вопросы для проверки
Если вы руководитель и хотите понять, насколько ваша компания в порядке:
- Применены ли патчи ОС, связанные с Meltdown/Spectre, на всех серверах - включая on-premise и арендованные виртуальные машины?
- Обновлены ли прошивки серверного оборудования до версий с исправленным микрокодом?
- Если компания использует публичное облако - есть ли подтверждение от провайдера, что инфраструктура защищена?
- Зафиксировано ли влияние патчей на производительность критичных систем?
- Включены ли прошивки и микрокод в регулярный процесс управления уязвимостями?
Это не паника и не повод менять всю инфраструктуру. Это набор проверок, которые теперь стоит делать регулярно - потому что нижний слой вычислений тоже стал частью ИБ-повестки.