Cloud native

"Хорошо известно, что на одной карте невозможно показать всю земную поверхность без искажений. Обычная проекция Меркатора, используемая для карт мира, сильно искажает площади, преувеличивая их изображение на карте по мере приближения к Северному и Южному полюсам, а сами полюса картой в этой проекции вовсе не покрываются. Чтобы правильно показать на карте всю Землю целиком, нужно использовать набор карт, каждая из которых покрывает ограниченную область."

Стивен Хокинг, Леонард Млодинов, "Высший замысел" 

Cloud Native EPP - модная тема, о которой Гартнер последнее время много пишет применительно к EPP, в частности здесь. Если коротко, то по мнению аналитиков, on-premise EPP уже не отвечают требованиям современности, и нужен другой подход: решение не принимается на агенте, а вся телеметрия летит в облако и думающая логика, со всеми хайповыми технологиями - ML/DL/AI/etc - выносит вердикт, который реализует, в целом, достаточно примитивный агент. Причем в данном случае примитивность агента выставляется как его преимущество, заключающееся в большей легковесности. В целом, сценарий известный, будем называть его "Cloud EDR", откуда сразу понятно возникновение обсуждаемого тренда.

Не хочу вдаваться в детали, так как аналитика, где чуть ли не каждый абзац можно обсуждать, потянет не на одну заметку, но ситуация напоминает очередную попытку отстроить NextGen от "классического EPP", причем за "классический EPP" принимается нечто вроде сферического коня в вакууме, поскольку современные ЕРР уже давно не обладают приписываемыми им слабостями. В частности:

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

Но остановиться хочется на традиционном: как ни один подход не является панацеей, так и cloud native имеет недостатки, которые могут быть скомпенсированы только комбинацией с On-prem. 

1. Самая очевидная проблема только-облачных EPP - невозможность обеспечения защиты в условиях отсутствия Интернет. Даже за вычетом всех регуляторных сложностей с ПДн и трансграничной передачей, существуют закрытые сегменты, а так как атакующие уже давно умеют ходить через "воздушные зазоры", их компрометация - материальный риск, который EPP должен адресовать. Да и атаковать такую систему может оказаться проще: атакующему надо вывести из строя Интернет-шлюз и вся компания останется без защиты (например, атакующий имеет C&C в виде DNS-туннеля, тогда HTTP/S-канал можно смело отключать, или, еще проще - в локальном hosts записать FQDN Cloud-native думалки за лупбэками, или заблокировать на фаерволе - в общем, есть масса вариантов нарушения связи агента со своим облаком, причем, далеко не все из них можно решить самозащитой агента)
2. Скорость реакции. Всегда лучше сначала попытаться предотвратить угрозу (до сих пор встречаются люди, которые считают системы обнаружения, типа IDS, полной ерундой и верят только в IPS). Если мы хотим предотвращать, то мы должны работать в блокирующем режиме, т.е. например, блокировать запуск процесса, если он нехороший. Теперь представим что будет, если по каждому процессу мы будем отсылать телеметрию и ждать облачного вердикта в блокирующем режиме... - это нерабочий сценарий. Поэтому в случае с Cloud native мы имеем возможность работы только в асинхронном режиме, а следовательно, превентивные возможности радикально падают, так как зачастую в противоборстве с угрозой работает сценарий "кто первый встал, того и тапки"
3. Возможны инфраструктурные сложности в условиях больших сетей и тонких Интернет-каналов, так как "глупый" агент Cloud EDR,  не принимающий никакие решения на месте, генерит в разы больше телеметрии, чем "умный" EPP. Частичные потери телеметрии будут ухудшать детектирующие способности.

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