RSAC 2024创新沙盒｜RAD Security：云原生异常行为检测和响应新方案

RAD Security是由Brooke Motta和Jimmy Mesta共同创立的云原生安全公司，其前身为Kubernetes 安全运营中心（KSOC）。于2022年2月15日正式宣布获得600万美元的种子资金，仅在去年一年中，投资回报率增长了3倍，且过去两年客户保留率达到100%。

在更名之前，公司专注于实时Kubernetes安全态势管理（KSPM）和云原生身份威胁检测和响应（ITDR）等Kubernetes安全运营业务。2024年3月12日，公司正式更名为RAD Security，并解释“RAD”代表其提供的安全得到广泛认可，而非单词缩写或暗示。随着其云原生工作负载指纹的发布，RAD Security正式转向云原生异常行为检测和响应业务。

如图2所示，RAD Security宣称通过对软件供应链、云原生基础设施、工作负载的云上正常行为建立指纹，通过与这些正常指纹的对比发现异常行为，以防御云原生在构建、部署、运行生命周期中的0 Day攻击。接下来，我们将从产品能力入手，了解RAD Security是如何检测和响应云原生异常行为以及防御0 Day攻击的。

RAD Security宣称发布了业内第一个实时KSPM工具，可以实现以秒为单位展示云原生基础设施的状态。在部署方面也比较便捷，支持以Helm方式在集群进行分钟级的部署。

如图3所示，实时KSPM工具主要是利用Kubernetes监控管理特性（通过Agent调用 Kubelet API查询集群资源）和Kubernetes 物料清单 (KBOM)工具，对集群内的组件、网络、策略、镜像、容器运行时等进行监控或扫描，结合漏洞风险从资产的维度上将风险链路可视化展示。至于安全闭环则采用AI工具生成修复建议为安全人员提供帮助。当然该工具也包含基于开放策略代理 (OPA)构建的动态准入控制器、生成用于运行容器的 SBOM、生成集群配置的KBOM、对照NSA和CIS指南的合规测试、跨多个集群生成报告等其他功能。

接下来，我们将从以下几个方面简单了解该工具：

1）Kubernetes 物料清单 (KBOM)

随着云原生技术的不断发展，大量的Kubernetes插件和工具随之产生，然而这些第三方生态往往隐藏着大量的危险，KBOM是KSOC发布的首个Kubernetes物料清单标准，旨在为Kubernetes集群提供安全概览。值得一提的是，RAD Security已经将KBOM的初版进行开源。

开源的KBOM是一个轻量级的CLI工具，与大家所熟知的SBOM有所不同：SBOM侧重于软件组件，提供了它们的详细清单、来源以及通常包含的许可信息；而KBOM则是专为解决Kubernetes环境的复杂性而设计的，支持将集群信息以JSON、YAML、XML等格式输出到命令窗口或文件中。输出的集群信息主要涉及以下内容：

• 资产发现

  除集群类型、集群规模、节点信息（如数量、架构、容器运行时、内核版本、操作系统等）外，也支持对Kubernetes环境中如Crossplane、Jenkins、CubeFS和Clusternet等第三方插件信息进行发现。

• 镜像扫描

  对仓库和集群中的镜像扫描能力，官方没有就具体技术细节进行公开，笔者猜测大致是结合CVE库对容器镜像进行扫描，标记含有漏洞的危险镜像。

• 自定义资源（CRD）分析

  对 Kubernetes 集群中CRD进行识别和分析。结合CVE库对已识别的CRD进行分析，针对有漏洞的CRD资源进行危险标记，并将与 Clusternet API 相关的危险CRD资源进行高危提示。

2）可视化的威胁向量

如图4所示，将KBOM发现的镜像CVE信息、RBAC危险权限和Kubernetes错误配置等大量信息，以集群为起点逐层对资产的风险信息可视化展示，以帮助安全运营人员消除集群安全盲点。

如图5所示，从官方的宣传中我们发现，RAD Security期望威胁向量能够给出Kubernetes 漏洞优先级，从海量的云原生安全告警中找出真正需要修复的漏洞。截至目前，从官方查询出来的资料来看，该特性仅能提供参考，最终的优先级还是需要人工判断，宣传成分居多。结合漏洞可利用性验证技术和漏洞危害等级对漏洞优先级排序方案是业内比较认可的方案之一，RAD Security的排序效果显然和后者存在一定差距。

3) 利用AI工具生成错误配置建议

该工具支持利用AI工具对发现的威胁向量生成修复建议，在威胁向量页面选择“使用AI修复所有问题”按钮后，如图6所示，这里的AI直接使用了OpenAI GPT-4，输入威胁向量的具体信息即可得到修复建议。AI应用于安全响应也早有先例，这里就不再赘述。

2023 年针对Kubernetes的四次重大攻击中有3次都依赖于过于宽松的RBAC（基于角色的访问控制）策略。Redhat最近的一项调查显示，使用Kubernetes的团队中有58%在过去12个月内因错误的RBAC策略而出现安全事件。RAD Security认为云原生ITDR是缓解Kubernetes RBAC攻击的有效方法。

RAD Security的云原生ITDR解决方案集成了Cloud IAM和RBAC、基于AI的查询引擎AccessIQ以及Kubernetes RBAC洞察力，旨在识别恶意云原生身份资源，并对恶意身份进行删除、阻止或者调整等闭环处理。

云原生ITDR与如CIEM (云基础设施授权管理)、KIEM（Kubernetes基础设施授权管理）等传统的RBAC安全工具不同的是：CIEM专注于Cloud IAM，KIEM仅专注于Kubernetes RBAC的状态，这些RBAC安全工具旨在增强身份状态并实施强化策略。而云原生ITDR不仅关注权限本身，还通过行为审计进一步关注权限是否被账号绑定或使用零信任机制给出风险账号和权限等。具体对比如图7所示：

通过RAD Security官网介绍，我们可以知道，原生ITDR是在实时KSPM的基础上增加了RBAC的管理能力，其大体的功能如下：

1) 身份风险评分

如图8所示，RAD Security通过判断同一容器的RBAC权限是否遵循最小化原则，权限是否被账号使用、是否产生威胁向量（即运行时事件、含有CVE镜像的容器、错误的权限配置等信息）等信息对存在的身份风险事件进行优先级排序。

2) RBAC准入控制器

同实时KSPM一致，该工具也依赖OPA对RBAC资源的使用进行准入控制。如图9所示，该事件触发了“账号口令仅能挂载至与API Server通信的Pod”策略。

3) RBAC权限风险修复建议

RAD Security支持对有风险的RBAC配置提供修复建议，这和实时KSPM中的利用AI为错误配置提供修改建议并无差异。如图10所示，对权限过大的策略提供最小化权限修改建议。

云原生工作负载指纹是使用eBPF技术为云正常行为建立的“安全”基线，也被称为“RAD安全标准”。RAD Security宣称云原生工作负载指纹能够避免软件供应链0Day攻击，接下来我们一起来看看。

首席技术官兼联合创始人Jimmy指出：“开发团队将经过验证的、干净的运行时指纹与在其环境中运行的相同镜像进行比较，他们就有真正的机会防御下一次零日攻击。”的确如此，攻击行为繁多且未知，我们只需关注安全行为，其他行为则可被定义为攻击。该方案借助eBPF技术实现，通过使用eBPF Hook内核的Kprobe和Tracepoint探针，实现调用链路追踪，将所有合理的调用链路生成基线，这些基线就是行为白名单，是该运行负载的安全行为标准，适用于任何使用该镜像的场景，如图11所示，一旦建立了基线，任何偏离基线的调用行为均会被识别和阻止，这样便能够有效发现并防止0Day攻击。

如图12所示，与CWPP 或运行时安全工具等传统方案不同的是，传统工具要么事后检测，要么基于规则比对，均无法对未知攻击进行防护，而云原生工作负载指纹可以借助eBPF技术在内核调用层进行行为对比和执行响应。既然是内核之上的调用链路，自然能够涵盖所有运行负载，也就自然能够涵盖供应链软件了。

RAD Security主要发布了3款产品， 融合Kubernetes 物料清单和AI能力的实时KSPM、补充RBAC管理能力的ITDR、基于eBPF技术的云原生工作负载指纹。笔者认为除了利用eBPF技术识别云行为并建立基线行为外，其他并无多少创新性，具体原因如下：

• 业界很早就发布诸多Kubernetes相关的最佳实践列表，这与Kubernetes 物料清单并无二致；

• 借助Kubernetes强大服务能力管理整个集群并不是难事，更别说RBAC资源；

• GPT全网火热后，AI技术应用于安全产品早已不是新鲜事。

• 基于eBPF技术做调用链路追踪虽早有成熟实践，然而通过eBPF捕获详细的调用链路，加上建立各种应用程序的行为白名单，将这一方案应用到云场景防护中的思路目前在业界的其他产品中还没有类似的实现宣传，故这一方案具备一定的创新性。

值得注意的是，2023年的洞见RSA《洞见RSA 2023：基于零信任构建云原生安全底座》系列分析文章中，绿盟科技也表述了“在内核级别去做云场景下的零信任”的思路，我们也验证了基于eBPF做内核层响应的可行性，笔者认为云原生工作负载指纹存在以下问题：

1) 指纹的更新如何跟上正常业务需求？

庞大的工具和产品集覆盖难度大：CNCF产品概览表里的产品和工具数不胜数，即使是强制采用BOM清单相信需要建立指纹的工具和产品数量也不容小觑，且官方软件的行为也不能完全信任，需要做大量的调用链安全判断。

工具和产品的更新迭代快，响应时间很难得到保障：每一处逻辑的改变都可能改变调用链路，调用链路的行为指纹都需要更新，行为指纹更新大都存在滞后性，可能影响环境正常业务。

2) 如何确保云原生工作负载指纹生效前所获取行为链路是真实的？

因为云原生工作负载指纹是基于eBPF技术做的调用链路，得到的调用信息存在篡改的可能，假如在云原生工作负载指纹生效前该环境的hook已被劫持，那所有的白名单机制也随之失效。

针对第一个问题，笔者认为使用AI技术会有所缓解，但第二个问题现阶段还缺乏有效的解决方案。

参考文献

[1] https://rad.security/blog/ksoc-our-story

[2] https://rad.security/blog/reimagining-cloud-native-detection-response-ksocs-evolutionary-shift-to-rad-security

[3] https://github.com/ksoclabs/kbom

[4] https://rad.security/blog/ksoc-releases-the-first-kubernetes-bill-of-materials-kbom-standard?__hstc=216745097.ef213c81ef307dec9e8a8e173d09b53d.1712806289050.1713750069828.1713752117280.17&__hssc=216745097.36.1713752117280&__hsfp=591268629https://rad.security/blog/ksoc-releases-the-first-kubernetes-bill-of-materials-kbom-standard?__hstc=216745097.ef213c81ef307dec9e8a8e173d09b53d.1712806289050.1713750069828.1713752117280.17&__hssc=216745097.36.1713752117280&__hsfp=591268629

[5] https://rad.security/kubernetes-vulnerability-prioritization

[6] https://rad.security/blog/how-to-protect-yourself-from-the-new-kubernetes-attacks-in-2023?__hstc=216745097.ef213c81ef307dec9e8a8e173d09b53d.1712806289050.1713170965066.1713230039726.10&__hssc=216745097.1414.1712826584740&__hsfp=591268629&_gl=1*qxas47*_ga*MjAyMzkxNjEwNi4xNzEyODA2Mjcz*_ga_0S6823H107*MTcxMzI1MTE3OS4xNC4wLjE3MTMyNTExODIuNjAuMC4xNDEzNjA0NDY.

[7] https://www.redhat.com/en/resources/state-kubernetes-security-report-2023

[8] https://rad.security/blog/itdr-best-practices-in-cloud-native-security-identity-threat-detection-and-response?__hstc=216745097.ef213c81ef307dec9e8a8e173d09b53d.1712806289050.1713768772546.1713771515130.20&__hssc=216745097.1125711259.1713771515130&__hsfp=591268629&_gl=1*6voq1o*_ga*MjAyMzkxNjEwNi4xNzEyODA2Mjcz*_ga_0S6823H107*MTcxMzc3MTUxMi4yNi4xLjE3MTM3NzIxODUuMzguMC41ODYzMTIzNjU.

[9]  https://blog.nsfocus.net/rsa-2023-2/