云安全

从云上攻防态势分析展望云服务安全架构设计框架发展

本文主要是记录笔者基于近期对云上攻防态势的分析思考和展望云服务安全架构设计框架的未来发展趋势，观点仅代表个人。

云上攻防态势分析

近期，笔者详细分析了近几年所有公开的云厂商漏洞报告[1]发现，头部云厂商的云服务都存在不少漏洞，其中AWS、GCP、Azure被公开披露的云服务漏洞最多。
01

其中最易受攻击的云服务类型主要集中以下几种类型：
02

  • k8s/容器：AWS CloudShell, AWS ECR Public, AWS ECS, AWS EKS, Azure ACI, Azure Function Apps, Azure Service Fabric, Azure CloudShell, GCP Anthos Service Mesh, GCP Cloud Shell, GCP GKE
  • 数据库：AWS RDS, Azure Cosmos DB, Azure Database for PostgreSQL, GCP Cloud SQL, IBM Cloud Database for PostgreSQL, Aliyun ApsaraDB RDS for PostgreSQL, Aliyun AnalyticDB for PostgreSQL
  • 数据管理：AWS AppSync, AWS Glue, Azure Cognitive Search, Azure Synapse Analytics, Azure Data Factory, GCP Dataflow
  • CI/CD：AWS CodeStar, Azure DevOps, Azure Service Fabric Explorer, GCP CloudBuild
  • 计算：Azure Red Hat Update Appliance, GCP GCE, GCP GCD, GCP OS Login
  • IAM：AWS IAM, Azure AD, Azure ADFS, GCP IAM

由此可见，大量基于k8s/容器等新技术构建的云服务是攻击者/安全研究者最青睐的攻击/研究对象，其次就是近年来针对基于开源数据库软件构建的云数据库和数据管理服务的攻击趋势明显上升，此外针对CI/CD云服务的供应链攻击也在显著增多，还有针对最常见的云上IAM服务的攻击依然普遍存在。

进一步分析发现云服务面临的主要攻击类型如下：
03

  • 越权攻击:
    • Azure  Cosmos DB Notebook的forwardingId存在越权问题可导致RCE漏洞（CosMiss）
    • GoldenSAML攻击主要针对联邦认证机制中使用的SAML  Response的伪造
    • 利用assume  role提权至Glue服务账号再结合其内部API的不安全配置获得其他使用了Glue服务的租户账号权限
    • 利用AWS  AppSync服务的confused deputy问题实现跨租户资源访问
    • 利用AWS  ECR Public服务的未公开API跨租户越权修改容器镜像
    • 利用Azure  PostgreSQL权限配置不当实现本地提权及通过数据库备份功能证书校验逻辑不严实现跨账号数据库认证绕过
    • 利用GCP  CloudBuild服务的Service Account账号的token（metatdata  API中获取）实现IAM的提权，即利用云服务的默认过多的IAM权限实现IAM的低权限提升
    • 利用GCP的各种服务特性实现IAM权限提升，即间接提权方式
    • 利用云服务的跨账号默认IAM权限配置不当，如允许修改资源arn，实现跨租户资源获取
    • 在Azure  Synapse Spark功能中利用filesharemount.sh脚本的条件竞争问题对任意文件执行chown操作从而实现本地提权
  • 注⼊攻击:
    • AWS  SageMaker Jupyter Notebook Instance  Takeover（利用XSS->CSRF->安全恶意扩展->访问Metadata->获取AWS认证token）
    • Azure  Synapse pipelines and Azure Data Factory默认使用的第三方适配Amazon  Redshift的ODBC连接器驱动存在命令注入漏洞（CVE-2022-29972）导致RCE可获取Azure服务敏感信息和跨租户数据
    • Google  Cloud Shell – Command Injection
    • 利用AWS  PostgreSQL的log_fdw扩展的路径穿越漏洞实现任意本地文件读取泄露RDS服务的内部认证凭据
    • 利用CSTI和存储型XSS获得Azure  Service Fabric Explorer服务的用户管理员权限（CVE-2022-35829）
    • 利用Google  Cloud Shell校验逻辑不当借助Theia IDE实现Cloud Shell命令注入可绕过安全校验直接访问Cloud  Shell底层VM实例的metadata
    • 利用Kudo提供的SCM面板的CSRF攻击多个Azure  Web服务
    • 通过commit  message修改Azure DevOps流水线执行过程中的环境变量可导致软件供应链攻击
    • 通过SSH公钥注入获取GCE访问权限
  • 云原⽣攻击:
    • Azure  Container Instances (ACI)服务跨账号容器接管
    • PostgreSQL服务帐户可以访问其他 RDS（MySQL、SQL Server 等）的 Docker 映像
    • 利用AWS的ECS服务的Task  Definition新建容器并通过EC2的metadata API获取临时AK/SK提权
    • 利用Azure  Serverless Function容器中本地进程提权实现容器逃逸
    • 利用Google-managed  Anthos Service Mesh的Istio控制面支持多集群部署通过新建恶意的GKE集群并部署Google-managed  ASM导致RCE可直接访问Google-managed ASM底层VM实例的metadata
    • 利用k8s  TLS Bootstapping机制进行提权
    • 利用具有CAP_NET_RAW  Linux  capability和hostNetwork=true的容器通过中间人劫持K8S集群的云宿主机node节点上的Metadata服务实现本地提权或者容器逃逸
    • 通过AWS  ECS Task Definition可以获取敏感信息（Task Definition类似于k8s的kubeconfig文件）
    • 阿里云PostgreSQL服务因不安全配置导致容器逃逸可造成跨租户数据库的未授权访问
  • 信息泄露:
    • AWS:  Lightsail object storage access keys logged
    • GCP:  Exfiltrate data via the logs of GCP Org policy
    • NotLegit:  Azure App Service vulnerability exposed hundreds of source code repositories
    • S3漏洞利用（计算资源中列权限、过度依赖IAM防止数据泄露、非公开的桶中包含公开的存储对象）
    • 滥用AWS  VPC服务的TrafficMirror特性获取东西向流量中的敏感信息
  • 开源组件攻击:
    • AWS  CloudShell Terminal（Cloud9）命令注入漏洞（CVE-2019-0542）
    • AWS:  In-band key negotiation issue in the AWS S3 Crypto SDK for golang  (CVE-2020-8912 and CVE-2020-8911)
    • Azure:  Cloudshell terminal escape (CVE-2019-0542)
    • Dataflow服务的JMX  RMI端口未授权访问导致RCE并借助使用host网络的容器可直接访问GCE的metadata
  • 防御绕过:
    • 利用AWS  API Gateway服务可以绕过IP黑名单的限制
    • 利用未公开的私有API绕过CloudTrail的日志记录

通过分析以上针对云服务的攻击类型可以总结出云服务面临的主要威胁类型（STRIDE）如下所示：

04

根据识别出来的云服务面临的主要威胁，站在云服务安全架构设计的角度来看导致这些安全威胁的根因应该包括以下几个方面：

  • 网络连接：突破云服务所在的网络隔离直接攻击云服务
    • 传统的网络隔离边界：防火墙、路由器、交换机、VPN
    • VPC：peering、endpoint、traffic mirror
    • 云专线：混合云、多云网络
    • 安全组
  • 部署模式：利用云服务部署架构的特性打破租户隔离实现跨租户资源获取
    • 物理多租：单租户独享
    • 逻辑多租：多租户共享
  • 资源负载：利用部署云服务的资源负载的逃逸漏洞突破资源隔离
    • k8s/容器逃逸
    • 虚拟机逃逸
    • 物理机CPU/芯片侧信道攻击
  • 权限配置：利用云服务的权限策略配置问题突破权限隔离
    • IAM账号：AWS Landing Zone
    • IAM策略：ABAC
    • 委托代理：Confused Deputy
    • 联邦认证：AWS STS security tokens、SAML
  • 服务功能：利用云服务自身功能特性和漏洞造成资源滥用、权限提升、信息泄漏
    • 传统的Web漏洞：SSRF、XXE、XSS、CSRF、CSTI
    • 云服务功能滥用：API Gateway、CloudShell Terminal、云函数、云WAF、云CDN、云存储桶
    • 未公开API滥用
  • 应用数据：不安全的应用数据保护导致信息泄漏
    • 云日志服务：CloudTrail
    • 数字证书不当传输与保存：Azure AD、Cloud SQL Auth Proxy
    • 数据明文传输与保存：VPC TrafficMirror

业界云服务安全架构设计方法论

云安全公司Wiz近期发布了一个专门针对云服务租户隔离框架PEACH，结合其在云安全领域的研究成果系统地提出了云服务安全架构设计方法论[3]。

Wiz认为典型的云服务漏洞引发的跨租户攻击模式如下：
05
应用PEACH框架构建安全的云服务架构的核心原则包括：

  • 减少云服务应用接口的复杂性
  • 增强租户间资源访问的隔离性
  • 提高租户间资源的冗余度

具体分两步走：

第一步，对云服务应用进行威胁建模

06
1) 首先找出云服务应用的所有外部接口。
2) 然后对每个接口执行以下分析：
07
2.1) 确定输入类型（即输入的不受信任的数据）和接口的各个组件。
2.2) 绘制接口的设计图，包括以下元素：
08
  • 注意用户输入类型，可能会变形以滥用接口。
  • 跟踪数据从用户输入经过的每个存储或处理它的组件的流程。
  • 区分共享和复制组件。
  • 添加安全边界，将每个复制组件与其他租户分开。
2.3) 评估每个组件的复杂度级别。
2.4) 根据以下准则确定接口的隔离级别：
  • 使用了哪些安全边界类型？
    • 资源隔离
    • 数据隔离
    • 网络隔离
    • 身份隔离
  • 它们彼此独立吗？
    • 共享组件
    • 复制组件
  • 它们如何加固？（参见第二步）
    • 权限加固
    • 加密加固
    • 认证加固
    • 网络加固
    • 环境清理
2.5) 在实施表中总结发现的威胁。
09
2.6) 通过询问来确定数据流的每个阶段可能出现的潜在漏洞：
  • 组件的攻击面是什么？
  • 什么样的恶意用户输入可能导致滥用？

2.7) 如果隔离级别在复杂性和情境因素（包括合规性、数据敏感度和预算考虑）方面被确定为不足，则根据需要修改设计，通过减少复杂性，增强隔离性，增加资源冗余度来提高隔离级别。

第二步，基于P.E.A.C.H.五个方面实施云服务安全加固

  • 权限加固（Privilege hardening）：
    • 在服务环境中，租户和主机通常具有最小的权限，遵循最小特权原则。
    • 特别地，除非经过租户明确批准，否则每个租户不得读取或写入其他租户的数据，每个主机也不能读取或写入其他主机的数据
    • 在执行操作之前，需要验证权限。
  • 加密加固（Encryption hardening）：
    • 属于每个租户的数据（静态数据和传输数据）都使用唯一于该租户的密钥进行加密，而不管架构如何。
    • 与每个租户的活动相关的日志由租户和控制平面之间共享的秘密进行加密。
  • 认证加固（Authentication hardening）：
    • 每个租户与控制平面之间的通信（双向）使用唯一于每个租户的密钥或证书进行身份验证。
    • 验证身份、验证密钥，并阻止使用自签名密钥。
  • 网络加固（Connectivity hardening）：
    • 默认情况下，除非经过租户明确批准（例如便于数据库复制），否则阻止所有主机之间的互联互通；主机不能连接服务环境中的其他主机，除了控制平面使用的主机（即集线器和分支配置）。
    • 除非经过租户明确批准，否则主机不接受来自其他主机的传入连接请求，除了控制平面使用的主机（以防攻击者设法克服自己受损主机上的连接限制）。
    • 租户不能随意访问任何外部资源（服务环境内部和Internet上的资源），只能与租户预先批准或明确批准的资源进行通信。
  • 环境清理（Hygiene）：环境中的不必要的数据或者信息可能为攻击者提供线索或快速收益，特别是那些已经成功攻破一个或多个安全边界的攻击者，这会进一步促进侦察和横向移动。因此，供应商可以在设计阶段消除以下类型的数据，并定期扫描部署环境中遗忘的数据或者信息：
    • 机密信息：接口和数据存储（以及虚拟化或容器化情况下的底层主机）不包含任何密钥或凭据，这些凭据将允许对其他租户环境进行身份验证或解密其他租户的后端通信或日志。
    • 软件：主机实例和数据存储（以及底层主机）不包含任何内置软件或源代码，这些软件或源代码可能会促进侦察或横向移动。
    • 日志：每个租户的日志对其他租户隐藏并不可访问；每个租户可访问的日志不包含与其他租户活动有关的任何信息。

新型云服务安全架构设计框架

应该说PEACH框架是一个不错的云服务安全架构设计框架，但是细究下来也存在一些不足：

  • 过度隔离：为了提高资源冗余度添加太多重复组件和安全边界也可能会导致云服务环境整体复杂度的增加，从而可能引入新的漏洞。
  • 过度依赖人的分析经验：云服务安全架构师需要具备丰富的攻防经验，了解各种云服务接口类型和相应的加固方案，过度依赖架构师的经验会导致不同能力的架构师对于风险消减的最终效果差异较大。

因此，结合云上攻防态势分析的结果和PEACH框架的核心思想，笔者提出了一种新型的云服务安全架构设计框架（LSSA）。

第一步，将云服务按照关键架构元素进行梳理10

  • 网络连接：梳理出云服务各组件与底层资源、及与其他服务的网络连接方式。
  • 部署模式：梳理出云服务资源的部署方式，如逻辑多租或者物理多租。
  • 资源负载：梳理出云服务应用运行的工作负载，如虚拟主机、容器、或者裸金属主机等。
  • 权限配置：梳理出云服务自身及各组件间的身份认证与鉴权方式及相应的配置。
  • 服务功能：梳理出云服务自身业务的各种功能特性，如面向互联网的API网关、云存储桶、云函数等。
  • 应用数据：梳理出云服务应用处理和保存的各类租户及云服务自身的数据类型，如租户日志、云服务数字证书等。

第二步，针对每一个关键架构元素进行风险识别和安全加固

首先，根据历史上公开的云服务漏洞整理出每一个关键架构元素的威胁知识库：
11
Picture1
然后，对照威胁知识库针对每一个关键架构元素按照以下核心原则识别潜在风险并进行相应的安全加固。
  • 最小权限（Least Privilege）：确保云服务自身及各组件间的身份认证与鉴权始终保持满足业务需要的最小权限。
  • 增强隔离（Improve Separation）：从资源隔离（裸金属、虚拟机、容器）、网络隔离（专线、VPC、安全组）、身份隔离（IAM、MTLS、数字证书、联邦认证、委托授权、零信任鉴权）、架构隔离（专属集群、专属region、专属AZ、物理多租）、数据隔离（传输与存储加密、一租户一密）等方面增强租户间的隔离水平。
  • 默认简单（Simplify by default）：云服务接口的功能设计要默认简单，每一个对外接口尽可能只做一件事，正如Unix哲学及其实现“一个程序只做一件事，并做好”。
  • 假定失馅（Assume Breach）：在审视每一个关键架构元素的风险时，要思考如果当前的架构元素被攻击者控制后最坏情况下能造成哪些重大影响（也就是爆炸半径），影响当前的云服务架构元素？其他的云服务架构元素？还是其他的云服务？

参考

安全建设

态势感知的前世今生（之一）

本系列文章将分为几篇介绍一下态势感知的发展历程和行业实践。

起源与定义

态势感知的概念起源于军事理论，早在春秋时期著名的兵书《孙子兵法》中就有提到“知己知彼、百战不殆”，这估计也是最早把对敌情态势的感知作为克敌制胜的关键因素的观点了。

第一次世界大战期间“空战之父”德国的王牌飞行员Oswald Boelcke也曾经提到类似的说法：

the importance of gaining an awareness of the enemy before the enemy gained a similar awareness, and devised methods for accomplishing this.（先敌一步掌握对方的态势并设计出相应的实现方法至关重要）

第二次世界大战期间德国空军飞行员Erich Alfred Hartmann发明了著名的SDAR空战战术理论（即See-Decide-Attack-Reverse），首先通过观察敌人决定如何继续攻击，然后才进行正式攻击，接着脱离接触并重新评估局势进行下一轮的观察。

越南战争期间美国空军上校John Boyd结合空战中的经验和教训总结形成了著名的OODA模型（即Observe-Orient-Decide-Act），通过观察、调整、决定、行动，反复推进并以此形成循环，该模型在美国空军中获得迅速推广。

1995年前美国空军首席科学家Mica Endsley仿照人类的认知过程建立并结合空军战术理论正式发表了关于“态势感知”的第一个理论模型（Endsley模型），该模型将态势感知分为三个阶段，即态势感知、态势理解、态势预测。此后，态势感知开始广泛应用于医疗救援、交通、航空、执法、网络安全等其他领域。

随着计算机网络的发展以及网络安全复杂性的凸显，“网络安全态势感知（Cyber Security Situation Awareness，CSSA）”也越来越得到重视并逐渐成为网络安全领域不可或缺的重要组成部分之一。如今，比较主流的网络安全态势感知的定义主要来自于Endsley提出的，即态势感知是对目标网络空间中的安全威胁进行感知，应用适当的评估、评价、推理分析机制理解攻击意图，并以此预测未来的安全态势。

行业实践

有了以上对态势感知发展历程和主流定义的基本了解，可以通过几个行业实践来深入理解一下如何构建网络安全态势感知体系。

美国国家态势感知体系

导读：美国国家态势感知体系以管治为核心，以各自构建、独立管理、信息共享、统一协调、常态化呈现为策略。

美国国家态势感知体系主要由国土安全部（DHS/CISA）负责的联邦政府网络态势感知体系和国家安全局（NSA/CSS）负责的军事网络态势感知体系构成，两者独立构建和运作，但通过情报共享机制由国家情报总监办公室（ODNI）协调汇总所有情报机构的态势信息生成总统每日内参（PDB）提交给美国总统和少数政府高层官员作为国家战略决策的重要输入之一。

pdb

国土安全部通过国家网络空间安全保护系统（NPS），也称ENISTEIN系统，构建了联邦政府的网络态势感知体系。

  • 管理组织：由国土安全部负责统筹管理。
  • 实施阶段：共分为三个阶段进行实施，即2003-2005年的EINSTEIN 1（E1），2005-2008年的EINSTEIN 2（E2），2010-2012年的EINSTEIN 3 Accelerated（E3A）。
  • 落地进展：E1/E2已在76个政府机构落地，28个政府机构暂未实施；E3A Email已在78个政府机构落地，8个政府机构正在进行中或延期中，18个政府机构暂未实施；E3A DNS已在82个政府机构落地，5个政府机构正在进行中或延期中，17个政府机构暂未实施。
  • 度量指标：主要有三个度量指标，即潜在恶意行为安全事件平均通知时间、及时告警受潜在恶意行为影响的机构的百分比、被EINSTEIN系统检测或阻断的国家级APT攻击安全事件的百分比。
  • 法案标准：美国政府制定了一系列法案支撑国家态势感知体系的构建和运作，包括《国土安全法案（HSA）》、《情报改革和恐怖主义预防法案（IRTPA）》、《联邦政府信息安全管理法案（FISMA）》、《总统每日内参（PDB）》、《结构化威胁信息表达标准（STIX）》、《自动化威胁信息交换协议（TAXII）》。
  • 关键能力：有四个主要的关键能力，即入侵检测、入侵防御、安全分析、信息共享。
  • 核心技术：构建关键能力的核心技术包括DFI/DPI/DCI技术、智能安全分析（LRA）、DNS Sinkhole、主动防御（TUTELAGE项目）、自动化威胁指标共享（AIS）。
  • 人员编制：在2008-2017年9年间从最初的4人发展到127人，随后人员编制逐年增加，2018年152人，2019年139人，2020年169人，2021年176人。
  • 项目预算：在2008-2017年9年间合计投入了27.88亿美元，随后每年保持约4亿美元的年度预算投入，其中运营预算是建设预算的3.3倍。

cnci

欧洲金融行业态势感知体系

导读：欧洲金融行业态势感知体系以市场驱动为核心，以构建统一的威胁情报共享计划为策略。

欧洲通过建立市场驱动的泛欧金融基础设施欧洲网络韧性委员会（ECRB）的网络信息和情报共享计划（CIISI-EU）构建了泛欧金融行业的态势感知和威胁情报共享体系。

  • 管理组织：由CIISI-EU秘书处负责统筹管理。
  • 组织成员：该计划成员包括泛欧金融基础设施（SWIFT）、中央银行、关键服务提供商、欧盟网络安全局（ENISA）、欧洲刑警组织（EUROPOL）等。
  • 落地进展：该计划总共历经了约2年的时间从专项工作组成立（2019年2月）到项目正式转运营（2020年12月），其中包括需求收集及规划设计，第三方威胁情报服务商的识别、评估、选择和采购，规则与流程制定，中心化情报共享平台构建，组织成员接入系统的部署等。
  • 度量改进：为了确保该计划的持续运作和运营，分别从成员组织间的信任与开放度、成员组织的主动参与率、成员组织的高级管理层的参与度、计划的意义与价值评估、计划的创新发展评估几个指标进行度量和改进。
  • 政策标准：该计划制定和发布了若干政策标准，包括《Terms of Reference》、《Community Rulebook》、《信息交换协议（TLP）》、《结构化威胁信息表达标准（STIX）》、《恶意信息与情报共享标准（MISP）》、《MoSCoW信息分享框架》。
  • 关键能力：主要包括威胁情报种子、中心化情报共享平台（MISP）、信息与情报共享、战略级情报分析、报告呈现、告警通知、定期可信任成员间线上/线下会议、战略信任关系等。
  • 情报类型：根据态势感知与威胁情报呈现对象的不同主要有三类情报，包括面向董事会的战略性情报、面向CISO或安全主管的运营性情报、面向安全运营工程师的战术性情报。

ecrb

参考

安全建设

关于BIS的《信息安全控制：网络安全条目》的解读及影响分析

本文主要是对美国商务部工业和安全局（BIS）于2022年5月26日发布的《Information Security Controls: Cybersecurity Items》的详细解读及该细则发布后对中国政府和企业的影响分析。

0x00 背景介绍

his

1996年7月，在美国的主导下以西方国家为主的33个国家在奥地利维也纳签署了《瓦森纳协定》（简称“瓦协”Wassenaar Arrangement），决定从1996年11月1日起实施新的控制清单和信息交换规则。其中包含两份控制清单：一份是军民两用商品和技术清单，涵盖了先进材料、材料处理、电子器件、计算机、电信与信息安全、传感与激光、导航与航空电子仪器、船舶与海事设备、推进系统等9大类；另一份是军品清单，涵盖了各类武器弹药、设备及作战平台等共22类。

2004年，美国商务部工业和安全局（BIS）发布了出口管制条例（EAR）的许可例外的国家分组的附件《Supplement No.1 to Part 740-COUNTRY GROUPS》，第一次将中国（China(PRC)）列为D:1（国家安全）、D:3（生物化学）、D:4（导弹技术）组中，从而限制涉及国家安全、生物化学、导弹技术领域的商品或技术出口到中国。

cn1

2013年，《瓦森纳协定》将网络安全条目纳入出口管制的范围之中，其中包含了对“入侵软件”的定义，具体包括：

  • 提供入侵软件的命令与分发平台的软硬件
  • 支撑命令与分发平台的开发、部署、使用的技术
  • 用于入侵软件自身开发的技术

2014年，BIS刷新了出口管制条例（EAR）的许可例外的国家分组的附件《Supplement No.1 to Part 740-COUNTRY GROUPS》，开始将中国也列为D:5（美国武器禁运国家）组中。

cn2

2015年5月20日，BIS针对《瓦森纳协定》中关于网络安全条目的出口管制规定的适配和对于美国工业界的影响发布了建议规则，并公开向美国各界征求意见。

2017年12月，经过美国的提议和协商《瓦森纳协定》综合了美国各界的反馈建议和BIS的建议规则最终同意了对原先的网络安全条目的出口管制项做了部分调整和修正，具体体现在三个方面：

  • 对恶意软件的行为的定义做了更加清晰的描述，强调了可被用来进行“命令与控制”的软硬件需要被出口管制；
  • 在“入侵软件”的开发技术中，用于“漏洞披露”和“网络事件响应”的技术可被出口管制豁免
  • 在“入侵软件”的生成、命令与控制、交付技术中，仅用于提供基础软件的更新与升级可被出口管制豁免。

2018年8月13日，美国总统签署生效了《出口控制改革法案》（ECRA），从法律上赋予了BIS发布和维护《信息安全管控：网络安全条目》细则的权力。

2021年10月21日，BIS基于2017年《瓦森纳协定》中关于网络安全条目的出口管制项的修正结论，发布了《信息安全管控：网络安全条目》细则暂行版建立了一个新的许可例外即授权网络安全出口许可例外（ACE）并向美国各界征求意见，并计划2022年1月19日生效。

ci1

2022年1月12日，BIS根据美国各界对《信息安全管控：网络安全条目》细则暂行版的反馈建议延迟其生效时间至2022年3月7日，并同意提供额外的细则实施指导和FAQ。

ci2

2022年5月26日，BIS发布了《信息安全管控：网络安全条目》细则最终版并生效执行。

ci3

0x01 细则内容

（a）范围

授权网络安全出口许可例外（ACE）授权本节（b）段规定的“网络安全条目”的出口、再出口和转让（国内），包括视为出口和再出口，但须受本节（c）段规定的约束。

本许可例外下被视为出口和再出口的物项均需要被授权，但本节第（c）(1)段所述的被视为向E:1和E:2组的国家，及本节（c）(2)段所述的某些“政府最终用户”，并受本节（c）(4)段所述的最终用途限制的约束的出口或再出口除外。即使ACE不适用于某些特定场景，其他许可例外也可能适用。例如，许可例外GOV（第740.11节）授权向美国政府机构和人员出口某些产品；许可例外TMP（第740.9（a）(1)条)授权在某些情况下出口、再出口和转让（在国家）贸易工具。

（b）定义

以下术语和定义仅用于授权网络安全出口许可例外（ACE）。

（1）网络安全条目（Cybersecurity Items）：是ECCN 4A005、4D001.a（用于4A005或4D004）、4D004、4E001.a（用于4A005、4D001.a (用于4A005或4D004）或4D004), 4E001.c、5A001.j、5B001.a（用于5A001.j）、5D001.a（用于5A001.j）,5D001.c（用于5A001.j或5B001.a (用于5A001.j）)和5E001.a（用于5A001.j或5D001.a (用于5A001.j）)。

（2）数字组件（Digital Artifacts）：是在信息系统上被找到或发现的条目（例如，“软件”或“技术”），这些条目可以显示与该信息系统的使用、危害或其他影响有关的过去或现在行为。

（3）最惠待遇网络安全最终用户

具体包括：
（i）美国子公司；
（ii）银行和其他金融服务提供者；
（iii）保险公司；
（iv）提供医疗或以其他方式进行医学实践的民间卫生和医疗机构，包括医学研究。

（4）政府最终用

就本节而言，主要是指提供任何政府职能或服务的国家、区域或地方部门、机构或实体，包括代表该实体行事的实体或个人。本术语不包括本节第（b）（3）段中列出的任何“最惠待遇网络安全最终用户”。此术语包括但不限于：
（i）国际政府组织；
（ii）政府经营的研究机构；
（iii）高敏感政府最终用户；
（iv）低敏感政府最终用户；
（v）完全或部分由政府或政府授权机构的所经营或拥有的公共事业机构（包括电信服务提供商和互联网服务提供商）；
（vi）完全或部分由政府或政府授权机构的所经营或拥有的交通枢纽和服务（例如：航空公司和机场、船舶和港口、铁路和火车站、公共汽车、卡车和公路）；
（vii）完全或部分由政府或政府授权机构的所经营或拥有的涉及制造、分销，或提供《瓦塞纳协定》军用清单中规定的物品或服务的零售或批发公司。

（5）就本条而言，“部分由政府或政府授权机构经营或拥有”是指外国政府或政府授权机构实际拥有或控制（直接或间接）外国实体25%或更多的有表决权证券，或外国政府或政府授权机构有权任命外国实体董事会过半数的董事成员。

（c）约束

授权网络安全出口许可例外（ACE）不授权以下场景中的“网络安全条目”的出口和再出口、或（国内）转让：

（1）出口至《Supplement No.1 to Part 740-COUNTRY GROUPS》国家分组清单中的E:1或E:2组的国家。

（2）出口至《Supplement No.1 to Part 740-COUNTRY GROUPS》国家分组清单中的D:1、D:2、D:3、D:4或者D:5组的国家的“政府最终用户”，但是排除以下的情况：

（i）数字组件（Digital Artifacts）（特指与涉及由“最惠待遇网络安全最终用户”拥有或运营的信息系统的网络安全事件有关的数字组件），向同时列在D组和A:6组的国家的警察或者司法机构提供用于刑事或民事调查或起诉的网络安全事件；

（ii）“网络安全条目”，向同时列在D组和A:6组的国家的国家计算机安全事件应急响应小组提供用于应对网络安全事件、“漏洞披露”，或用于刑事或民事调查或起诉的网络安全事件。

（3）本节（c）（1）和（c）（2）段中的约束也适用于与“漏洞披露”和“网络事件响应”有关的活动，包括出口、再出口和转让（国内）。

注解：就本节（c）（1）和（c）（2）而言，ECCN 4E001.a和4E001.c中已经排除了“漏洞披露”和“网络事件响应”。

（4）出口至《Supplement No.1 to Part 740-COUNTRY GROUPS》国家分组清单中的D:1组或D:5组国家的“非政府最终用户”，但是排除以下的情况：

（i）向任何“最惠待遇网络安全最终用户”提供ECCN 4A005、4D001.a（适用于4A005或4D004）、4D004、4E001.a（适用于4A005, 4D001.a (适用于4A005或4D004）或4D004)和4E001.c中定义的“网络安全条目”。

（ii）“漏洞披露”或“网络事件响应”。

（iii）被视为出口。

（5）如果出口商、再出口商或转售商在出口、再出口或转让（国内）时“知道”或“有理由知道”（包括视为出口和再出口）”网络安全条目”将用于在未经信息系统所有者、经营者或管理员（包括此类系统内的信息和流程）授权的情况下影响信息或信息系统的机密性、完整性或可用性。

0x02 影响分析

导读：对中国政府最终用户及中国非政府最终用户的影响分析

根据BIS在2022年5月26日发布的《信息安全管控：网络安全条目》细则最终版中描述的授权网络安全出口许可例外（ACE），可以整理出以下的ACE例外的申请流程和典型应用场景。

inf1

if2

从以上分析可知，自2022年5月26日起，对中国政府最终用户及中国非政府最终用户的影响主要体现在以下几个方面：

  • 出口和再出口、或（国内）转让给已被列入实体清单中的中国政府或非政府企业最终用户的的“网络安全条目”或“数字组件”即使用于“漏洞披露”、“网络事件响应”也需要优先遵从实体清单中的管控要求。
  • 出口和再出口、或（国内）转让给中国政府最终用户的“网络安全条目”、“数字组件”即使用于“漏洞披露”、“网络事件响应”也不允许ACE例外，换句话说，中国政府最终用户将无法直接获得美国软件供应商提供的涉及“入侵软件”的“网络安全条目”或“数字组件”的漏洞披露以及网络事件响应相关的信息，对于非“入侵软件”的基础软件的漏洞信息获取和更新升级暂无影响。
  • 出口和再出口、或（国内）转让给中国非政府最终用户的“网络安全条目”、“数字组件”用于“漏洞披露”、“网络事件响应”允许ACE例外，亦即，中国非政府最终用户仍旧可以直接获取来自于美国软件供应商提供的涉及“入侵软件”的“网络安全条目”或“数字组件”的漏洞披露以及网络事件响应相关的信息，对于非“入侵软件”的基础软件的漏洞信息获取和更新升级暂无影响。

0x03 FAQ

一、该细则是不是美国近期针对中国的进一步出口管制制裁？

从BIS的出口管制条例实施的历史背景可以看出，BIS早在2004年和2014年就分别将中国加入了D:1、D:3、D:4及D:5组的国家分组中并实施严格的出口管制；此次细则的发布其实是对自2013年《瓦森纳协定》将网络安全条目纳入出口管制的范围之中以来对美国工业界出口所造成的负面影响和合规成本上升后的一定程度上的松绑和微调，以及对执行过程中一些模糊问题的明确、调整和修正。实际上，并没有看出明显的针对中国的进一步出口管制制裁。

二、中国政府和企业还能否收到海外的漏洞信息？

参见上文中的分析，涉及“入侵软件”的“网络安全条目”或“数字组件”定义中的软件和技术，中国政府将无法直接获得美国软件供应商的漏洞披露以及网络事件响应相关的信息，但是中国非政府企业仍旧可以直接获取来自于美国软件供应商的漏洞披露以及网络事件响应相关的信息；此外，对于非“入侵软件”的基础软件的漏洞信息暂无影响。

三、中国政府和企业正在使用的美国软件公司的基础软件还能否正常更新和升级？

纵观BIS细则全文和历史脉络，该细则并没有涉及基础软件的更新和升级，只是明确强调了在“入侵软件”的生成、命令与控制、交付技术中，仅用于提供基础软件的更新与升级可被出口管制豁免。也就是说，中国政府和企业正在使用的非“入侵软件”的基础软件（如Windows、office、oracle等）的正常更新和升级不在该细则的管控范围内，因此暂时不受任何影响。

四、对于中国非政府企业的跨境安全研究和合作及漏洞奖励计划有什么影响？

对于已被列入实体清单中的中国非政府企业会存在一定的影响，因为BIS在2022年5月26日发布的《信息安全管控：网络安全条目》细则最终版优先遵从实体清单的管控要求。

faq

对于暂未被列入实体清单中的中国非政府企业在获取海外安全研究者或公司的漏洞信息或网络安全事件响应信息暂无影响。

0x04 附录

术语解释

网络安全条目（Cybersecurity Items）

来源：https://www.bis.doc.gov/index.php/documents/pdfs/2872-cyber-tools-le-ace-faqs-final-version-nov-2021/file

The Category 4 ‘cybersecurity items’ related to “intrusion software” (which is defined in Section 772.1 of the EAR) are identified by the following ECCNs, summarized as follows:

  • 4A005 : Systems and equipment specially designed or modified for the generation, command and control, or delivery of “intrusion software”, and components of those systems or equipment that are themselves specially designed or modified to have these capabilities.
  • 4D004 : “Software” specially designed or modified for the generation, command and control, or delivery of “intrusion software”.
  • 4E001.c : “Technology” for the “development” of “intrusion software”.
    Note: 4E001.c does not apply to “vulnerability disclosure” or to “cyber incident response”
  • 4D001.a (for 4A005 or 4D004) : “Software” specially designed or modified for the “development” or “production” of items controlled by ECCN 4A005 or 4D004.
  • 4E001.a : “Technology” (which may include “source code”) for the “development”, “production” or “use” of items controlled by ECCN 4A005, 4D004 or 4D001.a (for 4A005 or 4D004).
    Note: 4E001.a does not apply to “vulnerability disclosure” or to “cyber incident response”

Meanwhile, the Category 5 – Part 1 ‘cybersecurity items’ related to IP network communications surveillance are identified by the following ECCNs, summarized as follows:

  • 5A001.j : Systems and equipment specially designed or modified to have all (not just some) of the functional characteristics and technical capabilities listed in ECCN sub-paragraphs j.1 (5A001.j.1.a., .b, .c) and j.2 (5A001.j.2.a, .b), and components of those systems or equipment that are themselves specially designed or modified to have all these characteristics.
  • 5B001.a (for 5A001.j) : Test, inspection and production equipment specially designed for the “development” or “production” of items controlled by ECCN 5A001.j, and components or accessories (of the test, inspection and production equipment) that are themselves specially designed or modified as such.
  • 5D001.a (for 5A001.j) : “Software” specially designed or modified for the “development”, “production” or “use” of items controlled by ECCN 5A001.j.
  • 5D001.c. (for 5A001.j or 5B001.a (for 5A001.j)) : “Software” specially designed or modified to provide characteristics, functions or features of items controlled by ECCN 5A001.j or 5B001.a (for 5A001.j).
  • 5E001.a (for 5A001.j or 5D001.a (for 5A001.j)) : “Technology” (which may include “source code”) for the “development”, “production” or “use” (beyond mere operation) of items controlled by ECCN 5A001.j or 5D001.a (for 5A001.j).

参考链接

安全建设

关于大型互联网企业DevSecOps体系构建的总结与思考

最近几年随着软件供应链攻击和数据安全事件的频繁出现，企业面临着重大的软件供应链安全和数据泄露风险，这间接促使了越来越多的企业开始关注DevSecOps，并且期望借此来解决相关的安全风险。

在开始今天的分享之前，先简单介绍一下DevSecOps的定义，这里主要采用援引于DoD（美国国防部）的一段定义，即DevSecOps实际上是一种旨在统一软件开发、安全、运维运营的有组织的软件工程文化和实践。

DevSecOps is an organizational software engineering culture and practice that aims at unifying software development (Dev), security (Sec) and operations (Ops).

devsecops

由于DevSecOps理念是将安全防御思维贯穿到整个软件开发和运维运营阶段，这就使得DevSecOps体系的构建变成一个可能的解决数据安全和供应链安全的有效途径。今天的这篇文章主要来谈谈大型互联网企业DevSecOps体系构建的总结和思考，为了方便读者理解笔者将会以一个虚拟的公司Parana来做说明。

组织与文化

导读：正如DoD的定义中所讲，DevSecOps不是指具体的技术或者工具平台而是一种软件工程文化和实践，因此对于期望构建DevSecOps体系的企业来说首先需要建设这样的组织和文化。

早在2002年Parana公司的创始人就开始在全公司top-down推广SOA（service-oritented architecture）文化[1]：

  • 所有团队必须通过服务接口公开他们的数据和功能
  • 团队间必须通过这些接口相互通信
  • 不允许其他形式的进程间通信：不允许直接链接、不允许直接读取另一个团队的数据存储、不允许共享内存模型、不允许任何后门；唯一允许的通信是通过网络上的服务接口调用
  • 每个团队可以根据自己的需求使用任何技术来实现
  • 所有服务接口，无一例外，都必须从头开始设计为可外部化的，也就是说，团队必须进行规划和设计，以便能够将接口暴露给外界的开发人员

此外，Parana公司的理念是Two-Pizza团队[2]，即每个团队是一个不超过两个Pizza可以喂饱人数的最小独立组织。团队越小，协作越好。而协作非常重要，因为软件发布的速度比以往任何时候都快。团队交付软件的能力可能是组织在竞争中脱颖而出的一个因素。设想一下需要发布新产品功能或需要修复错误的情况，往往都希望这尽快发生，这样就可以有更短的上市时间。 这样的理念在某种意义上也非常契合DevSecOps的内在逻辑，每个应用的开发运维运营团队应该是一个整体而不是割裂的组织，这样既减少了跨组织间的沟通成本也大大提升了软件交付的敏捷性及软件运行的安全性。

通过在公司top-down推行SOA企业文化和Two-Pizza团队组织形态，Parana公司具备了构建DevSecOps体系的基础，每个Two-Pizza团队类似于军队中的最小作战单元（班），“麻雀虽小但五脏俱全”，每个团队中基本上都配备了以下角色。

  • 软件开发工程师：负责软件架构和开发
  • 技术项目经理：负责软件立项、周边协作及项目管理
  • 软件支持工程师：负责软件测试、运维和运营

流程与工具

导读：有了相应的组织和文化，接下来就是如何通过流程和工具将DevSecOps的理念固化下来，并持续运作。本节将从计划、开发、编译与测试、发布与交付、部署与运维、监控与反馈几个阶段进行介绍。

一、计划阶段

Parana公司在计划阶段要求每个软件项目立项后需要在应用服务安全评估系统中进行注册，该系统会根据《数据分类分级要求》、《数据分级处理标准》、《TOP威胁风险库》等生成应用服务风险评估问卷，通过回答问卷系统会自动根据问卷结果生成应用服务等级（Red、Orange、Yellow、Green），不同的级别对应着不同的安全要求，如：

  • Red/Orange：需要有授权的安全评估人员完成应用服务的威胁建模分析并提交相应的修复方案，且必须在上线前完成内部的渗透测试
  • Yellow/Green：研发团队可以自行进行威胁建模分析，不强制上线前需要完成渗透测试，但是必须提交应用服务的应急响应计划和关键业务联系人以备出现安全事件后可以及时响应和跟进修复

对于威胁建模能力的构建，Parana公司建立了安全BP威胁评估培训与分层授权（Security Certifier Training）机制。简而言之，就是在每个业务研发团队中培养具备威胁建模分析能力的研发人员。通过绩效考核权重（提升安全能力在研发工作中的正向考核权重）、业务主管推荐（提升安全能力在业务考核中的负向考核权重）鼓励研发人员主动申请成为威胁建模分析专员，再举行定期的安全技术培训、考试及威胁建模实战演练选出合格的威胁建模分析专员进入专家池，且对专家池中的人员每年进行能力复核和刷新，后续主要依赖专家池中的人员对Red/Orange级别的应用进行威胁建模分析和评估。

二、开发阶段

Parana公司主要依赖零信任网关（midway-auth）和基于FIDO协议的硬件token的多因素认证（MFA）确保仅合法的内部研发人员可以接入到公司内的源代码开发平台；另外通过统一权限管理平台（Bindle）动态管理研发人员与所有artifacts的访问权限确保仅授权的人员可以访问指定的内部artifacts，主要包括：

  • Permission Groups: 包含操作内部特定系统的权限组
  • Codes: 源代码
  • Packages: 包含多个代码文件的代码包
  • VersionSets: 包含所需依赖关系的代码包集合，类似于docker镜像
  • Environments: 包含微服务安装、配置、启动所需的所有信息的集合，类似于k8s的pods
  • Hostclasses: 服务部署和运行的主机组，类似于k8s的nodes

公司通过内部Code Review平台强制要求研发的每个commit在push之前都需要人工进行Peer Review，防止潜在恶意代码进入主干代码。为了实现开发的默认安全，降低已知安全风险，Parana公司花了很大力气提升开发阶段的公共安全能力：

  • 公共安全组件：加解密模块、统一认证鉴权模块、凭据管理模块
  • 默认安全的开发框架：内置了隐私敏感数据脱敏、凭据管理、常见漏洞默认防御能力的适配各种开发语言的应用开发框架
  • 分层分级的数据仓库服务：满足不同分类分级数据安全要求的统一存储服务，可供开发团队按需选择，最大限度地降低因研发团队自行设计开发而导致的安全风险

公司禁止直接使用或者引用外部代码仓或者依赖库，使用前必须先引入内部代码仓，具体体现在以下几点：

  • 遵循”谁引入、谁负责“的原则，确定内部owner
  • 引入前需要确保符合公司开源软件许可政策
  • 引入时同步三方依赖的名称、版本等信息至软件物料清单系统（SBOM）进行持续的漏洞监控
  • 持续监控指定版本的三方依赖的漏洞信息，并及时通知三方依赖的内部owner更新升级

三、编译与测试阶段

Parana公司在代码每次编译阶段都需要经过IAST/SAST/DAST的安全测试，重要应用代码上线前还需要经过专门的渗透测试。

  • 使用自研和商用的SAST（静态应用安全测试）和DAST（动态应用安全测试）对自研代码进行安全扫描和测试
  • 使用安全组件分析（SCA）工具扫描代码中依赖的所有三方开源组件识别已知漏洞使用流水线自动触发二方及三方依赖库版本升级、自动化测试
  • 此外，根据应用服务安全风险评估的等级在上线前完成专门的应用服务渗透测试

四、发布与交付阶段

Parana公司的所有应用服务源代码最终都会被编译成VersionSets（即包含了所需依赖关系的代码包集合，类似于docker镜像）进行发布并交付，所有过程都是由编译引擎（Brazil）自动完成的（无人工介入），从而确保了VersionSets的完整性。研发团队自身或者其他团队需要使用这个应用只需要在自己的流水线上consume这个VersionSets即可[3]。以上这个过程，也可以使用持续交付平台（Pipelines）通过配置流水线自动化完成整个交付过程：代码push-》编译-》测试-》部署。

五、部署与运维阶段

Parana公司使用自动化部署平台[4]（Apollo）将包含微服务安装、配置、启动所需的所有信息的集合的Environments自动化部署到应用服务运行的主机组Hostclasses上。

  • 部署服务
  • 无停机部署
  • 健康追踪
  • 版本化的artifacts和回滚

上述这些过程同样可以通过Pipelines实现自动化安全配置（Security Config）、工作负载（workload）加固与扫描、安全补丁与漏洞修复。

六、监控与反馈阶段

Parana公司通过默认安全的开发框架引导应用服务自身进行应用、性能等日志收集与异常监控，针对潜在的安全异常要求研发团队通过公共的数据收集与融合组件（Sushi）统一上报到安全运营中心处理，同时会持续对开发人员的角色及职责与被访问代码仓关联度行为进行分析以识别潜在的软件供应链和内部威胁者（Insider Threat）等风险。

实践与安全

导读：DevSecOps流程的各个阶段中也面临着一些常见的威胁类型，本节将重点讲讲Parana公司的应对策略和落地措施。

sec

综上，我们较详细地解读了Parana公司是如何构建自己的DevSecOps体系，相信对于希望构建此类体系的企业来说有一定的借鉴意义。
secops

参考

[1] https://apievangelist.com/2012/01/12/the-secret-to-amazons-success-internal-apis/

[2] https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/two-pizza-teams.html

[3] https://gist.github.com/terabyte/15a2d3d407285b8b5a0a7964dd6283b0

[4] https://www.allthingsdistributed.com/2014/11/apollo-amazon-deployment-engine.html

[5] AWS re:Invent 2015: DevOps at Amazon: A Look at Our Tools and Processes (DVO202): https://www.youtube.com/watch?v=esEFaY0FDKc

[6] DevOps Culture at Amazon: https://www.youtube.com/watch?v=mBU3AJ3j1rg

[7] Automating safe, hands-off deployments: https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/

云安全

云上攻防二三事（续）

云上攻防系列其实早在几年前笔者就公开分享过一些思路，有兴趣的可以看看Red Teaming for Cloud（云上攻防）。

众所周知，云计算领域是一个融合众多软件技术及架构的领域因此也面临着各式各样的安全威胁，作为聚焦云上攻防的蓝军从业人员（Red Team）不仅需要掌握传统领域的渗透技能，也需要积极拓展思路，切忌画地为牢。

本文是通过对近期国外TOP3云厂商已公开攻击方法的洞察分析后的阶段性总结提炼。

AWS

GCP

Azure

小结

目前云上攻击的主要思路集中在以下几个层面：

  • 突破网络隔离：传统的网络隔离边界（防火墙、路由器、交换机、VPN）、VPC（peering、endpoint、traffic mirror）、云专线（混合云、多云网络）、安全组等；
  • 突破资源隔离：虚拟机逃逸、容器逃逸、物理机CPU/芯片侧信道攻击等；
  • 突破权限隔离：IAM账号（AWS Landing Zone）、IAM策略（ABAC）、委托代理、联邦认证（AWS STS security tokens、SAML）等；
  • 突破架构隔离：物理多租（单租户独享）、逻辑多租（多租户共享）等。

参考

安全建设

关于如何更好地呈现红蓝对抗价值的思考

虽然红蓝对抗机制和蓝军团队建设的经验和思考笔者已经通过不同渠道（博客、公众号、公开演讲等）多次分享了，但是今天这篇文章主要是谈一谈关于如何更好地呈现红蓝对抗的价值。

众所周知，近几年由于国家政府的重视红蓝对抗已经开始在国内各大组织和企业内蓬勃发展，但是笔者发现国内在运用红蓝对抗的价值呈现上还是有待提高的。纵观当前国内的情况，大家更重视这种形式的直接结果，如发现了几个漏洞之类的，却似乎很少公开提及如何将红蓝对抗更深次的价值呈现出来，这既包括横向上对防守团队的防御体系建设的促进，也包括纵向上对管理层的红蓝对抗价值呈现的理解。

笔者近年来一直在从事红蓝对抗机制和团队的建设，也在平时的工作中经常思考如何更好将红蓝对抗结果的价值呈现最大化，负责过蓝军建设的同学一定会或多或少被问到过类似的问题，即“红蓝对抗对企业到底有多大价值？如何量化体现？”。

一般的红蓝对抗的流程会在复盘阶段的《红蓝演练行动报告》和《复盘总结报告》中呈现红蓝对抗的结果价值，按照笔者的经验大多数情况下这两个报告一般会包括如下几方面内容：

  • 攻击过程与时间线
  • 发现的关键漏洞和修复建议
  • 发现的关键安全问题和改进建议

但是这些仅仅反映了单次红蓝演练行动中发现或者暴露的问题，而大多数情况下最终会被体现为演练过程中发现了哪些漏洞的问题。对于处于红蓝对抗演练初级或者早期阶段的企业或者组织来说，或许比较能给管理层带来短暂的震撼和重视，但是经历了多次演练后就可能会面临一些“漏洞审美疲劳”的问题，诸如：

  • 蓝军发现的这些漏洞是已知漏洞
  • 蓝军的这些攻击方式是已知攻击路径
  • 蓝军发现的这些安全问题是已知问题，且并不关键

那么如何避免由于将红蓝对抗的结果呈现单纯漏洞化而导致非蓝军人员或者管理层片面地以为红蓝对抗就是找漏洞的误解，笔者认为应该从红蓝对抗的本质出发，我们都知道以攻促防是红蓝对抗的本质，因此需要蓝军从业人员懂得从方法论设计、根因分析模型、数据量化分析等维度来深度呈现红蓝对抗的价值。

首先我们来看看国外同行是如何从这几个维度来实践的。

方法论设计

洛克希德马丁的Kill-Chain模型就是典型的红蓝对抗的方法论，其将攻击者的思考逻辑抽象成具体的攻击步骤，指导攻击者实施攻击，同时也帮助防守者理解攻击思维。

kill-chain

根因分析模型

MITRE的ATT&CK则是一个标准的根因分析模型，遵循Kill-Chain方法论通过解构攻击过程中具体的TTPs让不从事攻击的人员也可以理解攻击者思维及具体的攻击过程从而做到“知己知彼”。

attck

数据量化分析

FireEye的攻击生命周期模型是利用数据思维量化分析攻击过程中最容易被攻击者青睐的TOP攻击点从而为防守者提供防御投入的数据依据。
fe
fe2
通过研究和学习以上国外同行在红蓝对抗价值呈现的经验并结合自身的经历，笔者这几年也提出并实践了一套红蓝对抗价值呈现模型即红蓝对抗飞轮模型，并尝试将实战红蓝对抗演练行动解构成多个单点的攻击技术点，再通过数据统计方法挖掘防御的薄弱点，最后结合业界最佳实践提出针对性的防御体系改进建议。

红蓝对抗飞轮模型

红蓝对抗飞轮模型即实施红蓝对抗行动，从每次行动中梳理攻击路径，将攻击路径中的攻击技术点映射到MITRE的ATT&CK矩阵（也可以是组织或者企业内部自建的ATT&CK矩阵）中的TTPs上，根据映射后的攻击TTPs识别相应的安全问题，按照FireEye的攻击生命周期模型统计多次行动中的TTPs的使用频率或次数总结出共性安全问题，最后针对数据量化分析后的共性问题结合业界最佳实践提出改进建议。
fw

0x00 实施红蓝对抗、发现攻击路径

00

0x01 映射攻击TTPs、识别安全问题

01

0x02 统计共性问题

fw2
02

0x03 改进防御体系

03

根据该模型，我们便可以建立起一个包含了方法论设计、根因分析模型及数据量化分析为一体的红蓝对抗价值呈现体系。利用这一套体系建立起横向和纵向的价值呈现标准和语言，用数据量化体现红蓝对抗的价值。