04.04.24 выступал на конференции, название доклада - "За границами управления уязвимостями", а основная цель как раз напрямую касается так много склоняемой "результативной безопасности". Продолжительность доклада была 15 минут, поэтому есть ненулевой риск, что мне не удалось разъяснить все, но есть этот блог, где все время мира мое, цели вписываться в какие-либо рамки нет, и есть возможность прояснить все. Презентация доступна в моем канале.
Слайд 2 отражает основную цель доклада - изменить отношение к проблеме Управления уязвимостями. Дело в том, что как бы усердно мы не занимались этим процессом, достичь состояния их отсутствия невозможно, т.е. даже если мы могли бы инвестировать в этот процесс бесконечное количество ресурсов, гарантии отсутствия уязвимостей мы бы все равно не получили. Управление уязвимостями, как и любой другой превентивный контроль безопасности, решает задачу на какой-то процент, а далее выходит на плато результатвиности, и сколько бы мы не инвестировали туда ресурсов, дополнительной ценности это не даст. Поэтому, нужно придумывать новые решения, а для создания нового, надо начать думать по-новому, изменить свой взгляд на вещи. Забегу вперед, сказав, контроли, которые я буду рассматривать далее далеко не новы, однако, им стоит выделить больший приоритет за счет сокращения безрезультатного стремления обнаружить и запатчить все уязвимости.
Расширение функциональных требований неизбежно ведет к увеличению сложности систем, что, конечно же, приводит к ошибкам, поэтому количество уязвимостей во времени напоминает энтропию.
График X-Force значительно более наглядный, показывает, что с экспоненциальным ростом уязвимостей мы имеем очевидный рост эксплоитов и уязвимостей нулевого дня. Лично меня задело, что зеродеев достаточно много - 3%. С учетом того, что я не различаю недокументированные возможности и уязвимости, и на то есть основания, с андоками дела обстоят хуже, они точно из области "я не знаю что я не знаю".
Весь классический цикл управления уязвимостями, где мы в основном фокусируемся на Выявлении и Исправлении - это вершина айсбега проблемы, поскольку, по факту, наши методы выявления не гарантируют выявления, а исправление тоже возможно лишь в некоторых случаях. Давайте посмотрим на это немного детальнее.
Согласно ГОСТ Р 56546-2015 "Защита информации. УЯЗВИМОСТИ ИНФОРМАЦИОННЫХ СИСТЕМ. Классификация уязвимостей информационных систем" выделяют следующие уязвимости:
- уязвимость кода - уязвимость, появившаяся в процессе разработки программного обеспечения
- уязвимость конфигурации - уязвимость, появившаяся в процессе задания конфигурации (применения параметров настройки) программного обеспечения и технических средств информационной системы
- уязвимость архитектуры - уязвимость, появившаяся в процессе проектирования информационной системы
- организационная уязвимость - уязвимость, появившаяся в связи с отсутствием (или недостатками) организационных мер защиты информации в информационной системе и(или) несоблюдени ем правил эксплуатации системы защиты информации информационной системы, требований организационно-распорядительных документов по защите информации и(или) несвоевременном выполнении соответствующих действий должностным лицом (работником) или подразделением, ответственным за защиту информации
- многофакторная уязвимость - уязвимость, появившаяся в результате наличия нескольких недостатков различных типов
Уявимость кода можно обнаружить сканером или с помощью системы инвентаризации (контроль версий). Однако, с уязвимостями нулевого дня (тем более с закладками) ситуация не решается никак. В моей практике был только один случай, когда в рамках анализа защищенности аудиторы нашли и успешно проэксплуатировали зеродей, очевидно, это исключение, вероятность результативности аудита для обнаружения зеродея невелика.
Многофакторная уязвимость - это стечение обстоятельств, в соответствии с Теорией вероятностей вероятность попадания в точку равна нулю, поэтому обнаружение такой уязвимости крайне маловероятно.
Как видите, есть вопросы. По факту мы не имеем эффективных инструментов выявления уязвимостей. Никакая совокупность технических средств не гарантирует, что все уязвимости найдены
Переходим к устранению, и здесь ситуация еще хуже. Уязвимость кода, даже при наличии обновления от производителя, далеко не всегда можно исправить быстро, да и исправить вообще. Чем глубже закопан компонент тем больше тестов на регресс требуется, как минимум, это долго, а исправления на зеродеи отсутствуют по определению.
Исправление архитектурных уязвимостей - это проект, сравнимый по трудоемкости с разработкой и внедрением системы. Если мы считаем Управление уязвимостями операционной работой, то устранение в рамках проектов автоматически выпадает из рассмотрения.
Организационные уязвимости тоже исправляются в рамках проекта, но, на практике, как правило, организационные упущения не являются следствием ошибок, но следствием каких-либо ресурсных ограничений. Поэтому, исправление организационной уязвимости, скорее всего, повлечет за собой удорожание процесса, на что никто не пойдет, и уязвимость не будет исправлена, поскольку ее эксплуатация имеет вероятность и в большинстве случаев менеджеры предпочтут принять связанный риск.
Если посмотреть на общую картину, то несложно заметить, что все типы уязвимостей мы либо не умеем выявлять, либо не можем исправлять. Самая хорошая ситуация с конфигурацией: уязвимости конфигурации просто выявить и просто исправить. Поэтому, чем больше наша безопасность определяется конфигацией, тем больше шансов результативно управлять такой безопасностью. Запомним это!
Мы рассмотрели более-менее объективные причины невозможности выявления и устранения всех уязвимостей, но есть еще и необъективные, которые будем собирательно называть "разгильдяйство". Разгильдяйство возможно по отношению ко всем типам уязвимостей, но вполне наглядная демонстрация - эксплуатация уязвимостей кода в инцидентах MDR. Сложившаяся ситуация с неисправленем уязвимостей выводит технику T1210 на первое место по популярности: если ее встречаемость принять за 100%, то у всех на слуху Фишинг составит только 99,33%, а, практически, вездесущая Манипуляция с УЗ не превысит 88%.
Я думаю у меня получилось быть убедительным, чтобы показать неэффективность популярных подходов к управлению уязвимостями, и надо что-то предложить.
С 2016 года мы говорим о Threat hunting-е, как подходе, расширяющем "классические" методы управления угрозами: мы отступаем от предотвращения на обнаружение, а с обнаружения на активный поиск угроз (Threat hunting). Такое отступление возможно, поскольку наша задача не предотвратить все угрозы, но предотвратить ущерб, и поэтому нам допустимо смириться с тем, что наша инфраструктура скомпрометирована, планировать мероприятия по безопасности с позиции "Assume breach".
Катализатором "Assume breach" стало понимание неэффективности автоматического предотвращения и обнаружения. Беря во внимание неэффективность в современных условиях обнаружения и исправления уязвимостей, пришло время анонсировать подход "Assume vulnerable" . В случае "Assume vulnerable" мы не стремимся достичь недостижимого - обнаружить и исправить все уязвимости, а знаем точно, что у нас уязвимости есть и все контроли безопасности планируем в рамках этого допущения. При этом, Assume vulnerable не отрицает необходимость "классических" сканеров уязвимостей, однако, и не требует их наличия, тем более, что в процессе постоянного усложнения систем полагаться на результаты этих сканеров выглядит все менее разумным.
В случае Assume vulnerable мы руководствуемся тем же принципом: задача не исправить все уязвимости, но не допустить ущерб, т.е. либо сделать уязвимость неэксплуатируемой, либо так, чтобы, эксплуатируя эту уязвимость, атакующий не смог развить атаку до реализации ущерба. На самом деле Assume breach == Assume vulnerable, поскольку, если я предполагаю, что взломан - это означает, что я должен и предполагать и то, что у меня есть уязвимость (иначе, как бы меня сломали). Assume vulnerable – это более проактивный вариант концепции Assume breach, так как если мне удастся стать неэксплуатируемым, то до взлома дело не дойдет.
Изображение Т-1000 - это моя попытка демонстрации большей перспективности принципа Assume vulnerable перед классическим превентивным не иметь уязвимостей: Т-1000 уязвим, однако эксплуатация этих его "жидких" слабостей не приводит к ущербу и после любых неприятностей он восстанавливается "как новенький" . Итак, Assume vulnerable смещает приоритет наших усилий на а) затруднение эксплуатации, б) затруднение развития, если уязвимость была проэксплуатирована.
Безусловно, какие-то запчасти классического подхода к управлению уязвимостями абсолютно необходимы - это инвентаризация активов. Какие бы контроли безопасности в какой бы парадигме мы не планировали, нам надо понимать объект защиты и как выглядит атака на него.
Я не люблю термин "управление уязвимостями", так как он сбивает фокус с главного - недопущения ущерба, или недопущения атаки, на второстепенное - недопущение уязвимостей, что неправильно, так как если мои уязвимости неэксплуатируемы или не ведут к ущербу, то у меня нет необходимости ими управлять. Более правильная альтернатива в этом случае - Управление поверхностью атаки. Видимо, вендоры сканеров уязвимостей тоже поняли свою ограниченность и сбой приоритетов, и теперь именуют себя системами управления поверхностью атаки (attack surface management, ASM). А вот понимать как выглядит атака, какова модель нарушителя и как он будет действовать, в общем понимать "поверхность атаки" - надо. Для наибольшей ценности результата любой работы, эту работу надо приоритезировать. Так и в управлении поверхностью атаки правильнее начать с сетевого периметра.
Примитивное, но, вместе с тем, вполне эффективное решение для управления поверхностью атаки можно сделать самостоятельно, где-то за неделю. Его общая схема приведена на слайде 16. Фактически, это сканеры, записывающие результаты, а также утащенные банеры сервисов в базу, к которой приделан веб-интерфейс. Как минимум, можно понимать какие службы по каким портам торчат на периметре, из банеров можно извлечь версии служб и по базе посмотреть есть ли для них уязвимости и эксплоиты.
Управлять поверхностью атаки нужно и во внутренней сети, и здесь нам поможет непрерывный пентест (continuous pentest). Привычный сценарий - проверка оперативной готовности команды мониторинга, но также, анализируя отчет пентестеров, мы понимаем как они пробивались, как повышались, как перемещались горизонтально - эти знания позволят нам предложить контроли, затрудняющие в будущем действия атакующих. Элементарный пример, аудиторы, проэксплуатировав apache использую bash для RCE - давайте сделаем так, чтобы bash и других интерпретаторов там не было, атакующие легко перемещаются горизонтально - давайте займемся контролем сетевого доступа и разрешим только минимально необходимый трафик.
Как отмечали выше - приоритезация - залог результативности. В Assume vulnerable мы предполагаем, что уязвимость у нас есть и она эксплуатируется, и здесь нам поможет CISA KEV. Для планирования своих работ мы берем KEV, проецируем ее на наши активы, получаем уязвимости с которыми нам надо работать. Далее мы анализируем критичность актива, модель нарушителя и как он будет развиваться, потенциальные последствия развития атаки, и придумываем контроли безопасности чтобы развитие атаки не приводило к ущербу. Также, неплохим критерием для приоритезации работ будет статистика KEV для конкретного используемого ПО, так как если какой-нибудь Oracle всю свою историю был дырявым, то логично предположить сохранение его лидерства. При этом, вы заметили, что для начала описанных работ мне совсем не требуется упражнение по сканированию, чтобы узнать о наличии у меня KEV, я сразу работаю в допущении, что KEV у меня есть, потому, что если KEV нет сегодня это не значит, что ее, с такими же последствиями, не появится завтра, тем более, с учетом истории KEV для конкретного ПО, поэтому усилия по построению следующих эшелонов моей безопасности точно не пропадут даром.
Что еще полезно поделать для повышения эшелонированности своей безопасности в рамках концепции Assume vulnerable? Схемы информационных потоков – покажут куда может потенциально развиваться атакующий. Контроль сетевого доступа – это то, что обеспечит соблюдение работы принципа минимума полномочий в соответствии со схемами информационных потоков. А вообще, в перспективе надо двигаться в сторону аутентификации любого взаимодействия, что я на слайде назвал собирательным термином "Zero trust".
Схемы информационных потоков - хорошее упражнение при проектировании информационной системы (ИС). Схема показывает какие сетевые взаимодействия требуются для полноценного функционирования ИС. На базе этой схемы станет понятно, как имеющимися возможностями по сегментации сети можно обеспечить принцип минимума полномочий.
Сетевые политики k8s - штатный механизм обеспечения принципа assume vulnerable. Немаловажно, что сетевые политики - декларативны, и это как раз тот случай, когда мы имеем дело с конфигурацией, которой удобно управлять.
На слайде 22 я собрал основные мысли из всей презентации, основной посыл которой пришло время строить безопасность с позиции Assume vulnerable.
