云原生入侵检测趋势观察
[Blue Team]
什么是云原生
以下是云原生计算基金会（CNCF）对云原生的定义：
Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.
云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。
These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil.
这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。
趋势一：资产多样化
在IDC时代与企业上云初期，由于企业应用的部署环境均以linux/windows为主，因此反入侵产品多以解决主机安全为主要目标。这一阶段入侵检测方法论是在做"猫捉老鼠"式的单点对抗（一个例子是参照ATT&CK构建入侵检测模型），作为入侵检测一线实践者，我们看到各厂商的检测点大多围绕linux/windows的细节攻防点展开。
例如HIDS产品中这样的模型：
- 检测/etc/passwd /etc/shadow /etc/crontab的读写行为
- 检测windows注册表异常操作
- 检测powershell hidden执行异常指令
- 检测java应用通过wget/curl指令下载二进制文件并启动
云原生时代，企业的核心资产除主机(VM)外，还有容器(Docker、K8s)以及诸多云服务，"主机安全"只是其中一部分。例如容器安全厂商 twistlock 的资产管理与可视化维度：
反入侵需要cover的"资产"形态将变得复杂，资产梳理、监控、可视化、ACL将更加困难。
部分资产生命周期大幅缩短，甚至秒级释放，这些高弹性的环境使攻击者的持久化更加困难，实时的入侵检测与响应或变的不再必要。
趋势二：服务碎片化
自Pivotal公司的Matt Stine于2013年首次提出云原生（CloudNative）的概念以来，几乎所有云原生的定义都包含微服务。微服务架构将复杂应用按function切分，使服务解耦，内聚更强，变更更易。
在此场景下，审计与管控边界由"网关/主机"变成了"服务/API"，系统内部的原子服务间的通信将变得复杂，难以实施管控与审计。主机粒度的"微隔离"技术将不能满足应用级别的审计需求，安全边界将由业务定义。
Microservices "Death Star":
NeuVector K8s Pod粒度的流量审计:
趋势三：中间件井喷
容器作为云原生的基础设施，已经被各云厂商产品化。在这一过程中，各厂商serverless的实现标准、容器隔离方案、依赖的中间件以及需要用户承担的风险各不相同。
CNCF Cloud Native Landscape:
一个常见的攻击场景：企业在K8s集群中引入了不安全的第三方插件。攻击者进入Pod后，通过未授权访问或漏洞攻击第三方组件，并利用这些组件的高权限账户操纵K8s集群。
传统的入侵检测方案，从对漏洞和攻击面的角度出发，梳理出主流中间件及应用的攻击手法，希望尽可能覆盖已知漏洞的利用方式。面对云原生中间件的爆发，企业在构建应用时的依赖及其复杂，任何一个组织或厂商所掌握的"漏洞库"已经难以满足其客户需求，这对安全产品的漏洞/攻击面管理能力提出了更大挑战。
趋势四：基础设施默认安全
下图简要描述了企业应用在容器化的不同阶段，云上用户自担的安全责任区（深蓝色）、用户与厂商共担区间（浅蓝色）以及云厂商默认安全区间（灰色）的变化情况。
从传统的VM上直接部署业务，到VM+容器、VM自建K8s集群、再到购买云厂商提供的K8s托管服务、云厂商的轻量级容器服务以及serverless，随着业务容器化的程度加深，用户的"安全责任区"逐步上移，对基础设施的安全需求（也是安全产品的价值空间）逐步减小。
一种传统主机安全的入侵检测思路是"用底层日志解决上层问题"：
- 当流量层遭遇混淆对抗时，入侵检测能力下沉到端上用户态行为审计，这样就可以避免对每个web漏洞case by case的覆盖，降低同一维度对抗成本。
- 用户态行为遭遇对抗时，战场还可以继续深入到kernel层（如提权逃逸类的检测）。
在云厂商提供的服务中，随着底层基础设施用户不可触达，这种更深层次的对抗逐渐成为服务商的特权，第三方安全厂商将难以向云服务部署自己的探针，相反，云厂商将结合自身的服务架构赋予用户侧更强的安全能力，包括检测的下沉以及云原生的"检测-响应-修复"闭环流程。
结论：入侵检测"业务化"，行为分析将成为核心能力
无论是从云服务的普及还是microservice的复杂程度来看，API通信都行为将成为服务间交互的重要一环，越来越多本地无鉴权的API通信将从转向有鉴权的服务框架。反入侵对于底层资产的监控趋于复杂的同时，UEBA技术将在业务层发挥更重要的作用。
试想在云原生场景中，攻击者通过WEB漏洞入侵云厂商的弹性容器服务，容器内部没有常见的linux命令和依赖库（甚至在某些serverless场景下无法写文件），且容器逃逸问题已被云厂商默认解决，攻击者只能通过服务自身权限或窃取本地API通信凭证进行横向移动。在此情况下，对API访问行为的分析将成为反入侵的有效手段，它具有足够的可行性和通用性，是适合产品化的技术点。
事实上身份认证、鉴权、UEBA以及数据安全是一个整体设计，这一点零信任架构的已经给出了实践。其尝试对任何接入系统的人/事/物进行认证，构筑在认证之上的入侵检测，实体画像、行为分析会其是必不可少的部分。
从技术成熟度来看，用户画像及行为分析已经在搜索推荐和风控领域得到广泛的验证。借鉴这些赛道的经验，我们已经将图计算落地在检测和响应阶段，实现对安全事件链路更长、时间跨度更久的分析。在未来高度API化的场景中，基础攻防将进一步"业务"化，我们将看到端数据、API日志与威胁情报在更高维度的结合。
ref
- https://landscape.cncf.io/
- https://jimmysong.io/kubernetes-handbook/cloud-native
- https://www.twistlock.com/
- https://www.aquasec.com/