Зачем нужен сильный фокус на защиту устройств

Вспомним основную идею ZT по защите админок - в админку можно попасть только предоставив сертификат, который лежит в защищенном хранилище на устройстве. Это означает, что поверхность атаки сильно снижается и составляет а) конечные устройства б) межмашинные взаимодействия (когда один сервис стучится в апи другого сервиса). 

Получается, для того, чтобы злоумышленнику получить доступ к данным админки, проще всего взломать ноутбук сотрудника. Наша задача наоборот - это предотвратить.

Меры по защите устройств

На начальном этапе мы должны соблюсти самый минимум:

1. Базовые требования к настройке ОС

2. Установка и работоспособность агентов

Пишем требования к настройке ОС. Фиксируем в них необходимость локскрина, шифрования диска, отключение ненужных сервисов и так далее. Статус исполнения этих требований проверяем с помощью агента на устройстве. Простейший вариант - osquery. Osquery позволит нам в постоянном режиме отслеживать статус защищенности наших устройств. Также он легко интегрируется с SIEM, для потенциального обогащения данными.

Помимо osquery нам нужен какой-то агент, собирающий логи с устройства, в идеале EDR агент. Это позволит детектировать атаки на устройство и также оперативно реагировать на них, в том числе отключать скомпрометированному устройству доступы к админкам.

Поверх базового минимума можно докручивать любые свои контроли, главное - обеспечить доставку статусов по этим контролям в единое место, в котором мы будем видеть общий статус защищенности нашего парка устройств.

Интеграция в ZT

Рассмотрим поподробнее, как связана защищенность устройств и доступ к данным. Вот мы раскатили osquery, установили EDR, складываем логи в SIEM. Нам остается написать сервис, назвать его “Системой Принятия Решений” (СПР) , в котором будет происходить основная логика. В нем будут содержаться требования по доступу к админкам, которые будут сопоставляться с текущим статусом устройства. 

Схема работы будет выглядеть так - каждый HTTP запрос от конечного устройства приходит на прокси, прокси в свою очередь запрашивает у СПР можно ли пускать это устройство. В любой момент времени статус устройства может измениться - например, появилось новое RCE в браузере, а обновления еще не установлены. В этот момент СПР меняет статус устройства на незащищенный,  и пользователю вместо данных в админке показывается заглушка, сообщающая о необходимости обновиться. После обновления данные через osquery достинут СПР, и статус устройства снова сменится на зеленый. Для разных админок можно выставить разные требования - к некритичным, например, пускать даже необновленные устройства, к особо критичным - добавить дополнительные требования.

Как можно видеть из схемы Device inventory и База с данными о защищенности устройств разнесены. Сделано это потому, что зачастую система инвентаризации устройств плохо расширяема или медленно адаптируется под динамичные требования по функционалу. Поэтому для скорости разработки можно развернуть свою систему, в которую данные об инвентаризации будут синхронизироваться из единой Device inventory, а уже статус по выполнению требований - из osquery и других агентов.

Задачи по инвентаризации и агентам - сложный и трудоемкий процесс, который разумно выделить в отдельный проект и передать отдельным людям. Также в этой задаче важны коммуникации - нужно максимально широко оповещать пользователей о внедрении новых технологий и о необходимости соблюдения требований. Особое внимание следует уделить договоренностям с руководителями, получению от них одобрения и поддержки. Эти меры значительно снизят трение при переходе на новую схему доступа и сильно помогут повышению общей защищенности парка устройств.

Дополнительные меры по защите устройств.

Выше мы обсудили задачу-минимум по построению защищенного парка устройств и интеграции его в Zerotrust. В качестве факультатива хочу поделиться дополнительными мероприятиями, которые выведут защищенность защищенность ноутбуков и, отчасти, пользователей, на новый уровень.

Red-Purple Teaming

Выделенные люди должны постоянно мониторить новые вектора атак и проверять их на практике. Новые средства доставки, закрепления, подходы к социальной инженерии - все это должно проводиться регулярно, и, совместно с командой Security Operations Centre, нужно оценивать какие из векторов были замечены, а какие нет. По всем пропущенным векторам нужно выстраивать контроли, эти контроли должны валидироваться. 

Дополнительный мониторинг

Зачастую Red Teaming находит вектора, которые плохо либо вообще не детектируются доступными средствами защиты. Для решения этой проблемы необходимо либо а) дописывать конкретные правила мониторинга, если это возможно б) создавать собственный софт, или брать опенсорсный.

Примеры задач, которые плохо детектируются антивирусами но регулярно используются в атаках:

• Добавление ssh  ключа  в authorized keys

• Запуск бинаря с флешки. 

• Большинство методов закрепления на macOS

Для задач выше существуют готовые решения, либо не так сложно написать своих маленьких демонов. 

Понятно, что тема защиты устройств значительно шире, но так как вектор атаки через компрометацию ноутбука для нас очень важен, необходимость внимания к этой теме трудно переоценить.

Предыдущие статьи:

1. Zerotrust по-пацански

2. Zerotrust по-пацански #2. Как сделать устройство доверенным