文/secdragon
介绍
之前工作中要做类似的事情，想要把安全领域做一个互斥并穷尽的拆分，方式与此书的内容很像，便顺便挑了有帮助的内容写一下这个读书笔记。
作者简介：Sounil Yu是JupiterOne公司的首席执行官和研究主管。他创建了网络防御矩阵和DIE Triad，这些都在重塑网络安全的方法。他是FAIR研究所的董事会成员，曾担任YL Ventures的驻场CISO和美国银行的首席安全科学家。在美国银行之前，他曾帮助几个财富100强公司和联邦政府机构改善信息安全。Sounil拥有20多项授权专利，被安全杂志评为2020年安全领域最具影响力的人物之一，被SC Awards评为2021年年度影响力人物，被Black Unicorn Awards评为2021年十大CISO。
好的矩阵图是相互排斥和共同穷尽（mutually exclusive and collectively exhaustive ,MECE）的。网络防御矩阵是网络安全领域的一个MECE代表，它结合了NIST网络安全框架的五个不同功能（识别、防护、检测、响应和恢复）和五个不同的资产类别（设备、网络、应用、数据、用户）。网络防御矩阵让我们对企业的整个网络安全环境有一个高层次的了解，并让我们看到任何特定的网络安全产品在该企业中的位置。
一旦我们在战略层面上知道我们需要做什么，矩阵就可以帮助我们将问题划分为不同的组成部分，并在战术层面上加以解决，网络防御矩阵不是最适合在战术层面上使用的框架。其他框架（如MITRE的ATT&CK框架）在细节水平上更适合。
下面表格是对各个资产的解释：
资产类别 | 示例 |
设备 | 工作站、服务器、手机、平板电脑、物联网、容器、主机、计算、外围设备、存储设备、网络设备、网络摄像机、基础设施等等。这个类别包括这些设备的操作系统和固件，以及其他原生或固有的软件。这里包括像交换机和路由器这样的网络设备，因为这些设备本身需要与它们创建的通信路径分开考虑。 |
网络 | 通信通道、连接和协议，使流量在设备和应用之间流动。注意，这不是指实际的基础设施（如路由器、交换机），而是指路径本身和这些路径中使用的协议。这意味着DNS、BGP、电子邮件过滤和网络过滤等领域也属于这一类别。这一类包括VPCs、VPNs和CDNs。 |
应用 | 设备上的软件代码和应用程序，与操作系统/固件分开。这一类包括无服务器功能、API和微服务。 |
数据 | 驻留在（静态数据）上的信息，通过（动态数据）传输，或由（使用中数据）上述资源处理。这类信息包括数据库、S3 bucket、存储块和文件。 |
用户 | 使用上述资源的人和他们的相关身份。 |
并非所有资产类别对一个的企业都同等重要。经常听到有人说，数据是最重要的资产，或者说，所有的资产都是关于应用的。在一个特定的企业中，这些话可能有一定的道理，但安全从业者如果忽视或淡化整个网络资产类别，就会带来很大的危险。在网络防御矩阵中，试图将所有的资产类别视为同等重要，这不是因为它们一定是，而是因为它们都提供了攻击面，在考虑整体安全环境时需要进行适当的检查和考虑。
举个例子：我们可以有最安全的设备，运行没有漏洞的应用，在隔离的网络上，有完全加密的数据，但如果这些资产是由一个有高度特权的管理员管理的，他点击了收到的每一封钓鱼邮件，那么其他东西有多安全就不重要了。
矩阵左侧 | 矩阵右侧 |
识别、保护 | 检测、响应、恢复 |
● 着重于事件前 ● 涉及风险管理 ● 与安全工程相一致 ● 专注于防止入侵行为 ● 需要结构意识 ○ 分析状态 ○ 清点资产 ● 发现弱点 | ● 着重于事件后 ● 涉及事件管理 ● 与安全操作相一致 ● 专注于驱逐入侵者 ● 需要了解情况 ○ 分析事件 ○ 调查状态变化 ● 针对弱点收集利用的证据 |
在左侧，我们需要对我们的环境有结构性的认识。结构性的认识始于对你有哪些资产、这些资产的状态以及这些资产之间的关系的理解。状态信息包括这些资产有多重要，它们是如何配置的，它们是如何暴露的，以及它们是如何被保护的。
当一个弱点被成功利用时就会发生事件，我们就处于右侧，需要通过分析环境中最近发生的日志来了解我们的资产是否受到损害。
CIS Controls是一个著名的安全控制框架，这是与安全矩阵的映射，详情可见https://tttang.com/archive/1474/
网络防御矩阵提供了一个结构，我们可以用来向利益相关者解释，我们在某些方面做得很好，但在其他方面仍需要进一步投资。它提供了一个现成的结构来叙述故事的两面性，向利益相关者展示哪里的安全是强大的，哪里需要额外投资。
02 路线图
当我们寻求制定一个安全路线图时，我们通常需要回答三个问题：
我们现在的安全状况如何？
我们应该有多安全？
我们如何从这里走到那里？
我们现在的安全状况如何？
我们将现有的安全能力组合映射到矩阵上，产生类似于下图的东西，如果组织由许多子公司或部门组成，每个子组织都可以将其能力映射到矩阵中，我们可以结合这些映射来确定我们整个组织的共同技术能力。
我们应该有多安全？
参考现有的成熟框架、合规要求或企业内部根据现有风险制定的一些要求，制定目标。
ATT&CK到5个资产类别的映射
我们如何从这里走到那里？
安全产品（解决方案）对应解决的问题（★越多代表做这部分能力的厂商越多）：
03 安全和业务的合作
安全团队和业务伙伴之间的合作
在宏观层面上，识别和保护的许多安全功能和子功能主要由资产所有者负责。只有在安全事件发生后，安全团队才会介入，承担检测和响应功能的主要责任，结束后交还给资产所有者进行恢复。
IDENTIFY合作
深入到IDENTIFY的子功能，并使用简化的RACI（负责任的、可问责的、咨询的、知情的）框架，下表更详细地显示了这些责任应该如何在安全团队和资产所有者之间进行分配。
IDENTIFY子项 | 责任人 | 被咨询 |
● 资产盘点 | Owner | 安全 |
● 身份/证书/密钥/令牌/IP地址/DNS管理 | Owner | 安全 |
● 优先次序/分类 | Owner | 安全 |
● 漏洞发现/攻击面管理 | 安全 | Owner |
● 威胁评估 | 安全 | Owner |
1、资产盘点
根据资产类别的不同，我们通常会把这种盘点称为其他的东西，如数据目录、用户目录或应用注册表，无论资产类别如何，资产所有者在盘点自己的资产方面发挥主要作用是最有意义的，安全团队是盘点的受益者。
2、身份管理
身份的概念通常只与USER资产类别相关联。然而，如果我们更广泛地思考身份问题，我们会发现每个资产都有某种身份，而且这种身份需要在资产的整个生命周期内得到适当的管理。
1.设备：设备证书管理
2.网络：IP地址管理、DNS和DHCP管理
3.应用：API密钥管理，SSL/TLS证书管理
4.数据：校验和、散列值
5.用户：用户名/密码，MFA令牌
管理这些身份的责任应该始终与资产所有者保持一致。
● 安全团队不应该管理IP地址，这是网络团队的工作。
● 安全团队不应该管理应用程序的SSL/TLS证书，这是业务线或应用开发团队的工作。
● 安全团队不应该管理和发布用户身份（如MFA令牌）。让人力资源部门发布和管理这些MFA令牌会更有效率。
3、确定优先次序
对于用户资产类别，企业的组织结构图通过提供一个组织架构图完成这个功能。同样，对于应用程序，使用应用程序的业务线将确定哪些是重要的，更需要受到保护。
显然，要做到这一点，他们需要从数据所有者那里得到信息，了解哪些数据是最重要的、最敏感的，需要得到好的保护；同样，有一整类安全工具被设计来做这种标签。但这是一种非常低效的方式，数据应该由创建它的人进行分类，这样就可以从一开始就进行保护，如果试图在数据创建和存储之后再进行优先排序和保护，则是低效和无效的。
4、漏洞发现
安全团队负责发现漏洞，但需要征求资产所有者的意见，以协调漏洞扫描和沟通结果，对严重程度进行评分。
5、威胁评估
此外，安全团队通常是与资产所有者进行威胁建模演练的推动者。理想情况下，资产所有者应将威胁建模作为其总体设计流程的正常组成部分，但在实践中，这是安全团队的责任，以确保威胁建模作为工作的一部分。
PROTECT合作
在PROTECT中，有许多不同的子功能。这些活动可以归纳为修复、加固和制定政策。
修复漏洞、加固和打补丁需要由资产所有者来完成，他最有资格确保这些重要的功能是以对业务流程干扰最小的方式来完成。
安全的作用是制定政策：定义资产所有者在修复和打补丁时必须遵循的规则，例如他们必须在多快的时间内处理高危漏洞。就像一个监管机构，安全将制定规则并监督它们，但实际工作要由资产所有者来做。
在这里，一个常见的分歧发生在用户资产类别上，修复这个漏洞意味着要做安全意识培训。人力资源部门负责所有类型的员工培训，他们邀请主题专家，安排课程，并确保员工参加。安全正确的角色应该与其他所有资产类别一样：制定政策。这意味着要定义培训的内容和目标，并规定培训的频率。
— | 设备 | 网络 | 应用 | 数据 | 人员 |
定义政策 | ○设备使用政策 ○基线、标准 | ○网络访问策略 | ○SaaS使用政策 ○应用开发政策 | ○分级分类指南 | ○使用手册 |
修复/补救 | ○打补丁 | ○修改ACL | ○修复bug ○打补丁 | ○加密 ○更改权限 | ○培训和宣传 |
最低权限/控制访问/职责分工 | ○活动目录/LDAP/RADIUS ○管理员权限的划分 | ○VPN ○NAC ○防火墙，VLANs | ○双向TLS，API密钥 ○用户认证 ○开发/测试/生产分离 | ○数据库活动监控 | ○IAM，访问审查 ○SoD，角色和责任 |
凭证管理 | ○凭证保存 | ○凭证保存 ○TACACS | ○凭证保存 ○API密钥管理 | ○密钥管理系统、HSMs | ○密码管理器 ○多因素认证 |
允许/拒绝名单 | ○基于签名的(A/V) ○基于行为的(HIPS) | ○默认拒绝ACL ○默认允许ACL | ○RASP | ○HMACs ○DLP | ○黑名单 ○完整的ID检查 |
加固 | ○配置加固 | ○关闭通信路径 ○TLS加密 | ○编码安全 ○代码模糊化 | ○AES加密 | ○培训和宣传 |
最少的功能 | ○不必要的服务删除 | ○单一数据包认证（SPA） | ○微服务 ○容器 | ○差异化的隐私 | ○N/A |
隔离/遏制 | ○虚拟化、沙盒化 | ○Walled garden（一种控制用户访问基于网络的内容和服务的环境。） | ○容器CRD（删除系统定义和策略中未批准的所有文件 | ○Rights management system（它使信息发布者能够控制接收者可以做什么，以防止知识产权被盗，阻止未经授权的分享/盗版） | ○隔离 |
审计/日志事件 | ○A/V、HIPS、登录和其他事件日志 | ○VPN、NAC、防火墙、DNS、DHS、DHCP日志 | ○应用程序日志 ○认证日志 | ○数据库日志、数据库活动日志 | ○用户活动日志 |
变更管理 | ○文件完整性监控 | ○网络变更管理工具 | ○版本/发行控制 | ○完整性监控 | ○Manager 1:1s |
漏洞/攻击缓解 | ○EMET, ASLR, DEP | ○IPS | ○Web App Firewall | — | — |
DETECT和RESPOND合作
在DETECT和RESPOND功能期间，大部分的责任都与安全团队相关，一个安全事件发生时，安全团队需要有权力在需要时破门或打破玻璃来灭火。理想情况下，这些权力是提前建立的，这样当事件发生时，安全团队就不需要协商进入，而是有能力不受阻碍地执行其反应功能。
RECOVER合作
最后，当我们谈到RECOVER的功能时，安全团队应该退居幕后，再次交给资产所有者处理。安全团队可以进行事后审查并编写事件报告；但是，实际的恢复活动最好由资产所有者处理。
04 使用Cyber Defense Matrix进行投资和技术合理化
网络防御矩阵可以用来发现投资机会和新的创业想法。2020年和2021年，作者有幸与YL风险投资公司合作，该公司是一家专注于以色列种子期网络安全创业公司的风险投资公司，在我们进行的实际投资中测试矩阵的价值。我们能够发现市场上的差距，以及填补这些差距的可能的技术和市场方法。这些初创公司是否会在商业上取得成功，到目前为止还有待观察，但根据作者目前收到的反馈，网络防御矩阵所产生的方法似乎是有效的。
该用例也可用于技术合理化工作。作为从业人员，我们经常感到自己拥有多余的、重叠的能力，相对于我们的安全预算而言，这些能力似乎是浪费的。该用例有助于发现市场上的差距，也可用于了解我们在哪些方面有机会减少技术投入，并为我们的技术更新战略提供信息。
Finding Gaps
假设我们可以用字母A到Z来描述一套通用的能力，如图所示，对于任何给定的资产类别，可能很难找到一组供应商能够集体提供A-Z的全套功能。
原因有三：
●原因一：供应商倾向于提供只解决特定问题的点式解决方案（例如，供应商1为DEVICES提供能力D，但没有能力E）。
●原因二：我们可能认识到对某项能力的需求（例如，应用的能力D），甚至可能有一些本地化/内部工具来解决这个问题，但也许由于缺乏商业可行性（例如，无法扩展，小众买家群体等），我们没有看到它成为商业化的产品。
●原因三：我们可能根本没有意识到能力差距的存在（例如，能力Q），它正在等待被发现或发明，通常是因为出现了一类新技术（例如，量子计算）。
通过网络防御矩阵不能发现原因3的差距，但矩阵确实有助于发现原因一和原因二的差距。
技术合理化
原因一差距会导致发生合并或收购的情况，这些公司需要其他产品来填补其产品中没有的能力，以便能够提供一整套能力。例如，如果您是一家大型供应商，目前在您的DEVICE-PROTECT能力组合中拥有F、G、I和J。势必要寻找一个能提供H功能的供应商（很可能是一家初创公司）。
从买方的角度来看，注意到我们有点状产品的地方，如图中圈出的字母所示，也有助于我们了解随着时间的推移，哪里有很大的潜在重叠能力，因为大型供应商建立或收购点状产品中的能力。例如，如果我们有一个提供APP识别能力D的点产品供应商，那么我们的A、C和/或E能力的大型供应商之一很可能会建立或获得类似的能力D，从而产生重叠。
如果有限的预算迫使我们放弃一个供应商，拥有这种宏观观点可以帮助技术合理化工作，以确定哪些确切的能力将被丢失。
寻找投资机会
通过原因二发现的差距，我们看到其他资产类别的能力，则出现了可能的投资机会，让我们假设能力A是 "资产盘点或可见性"，能力B是 "优先级或分类"。那么，我们希望看到在所有五个资产类别中都有一种能力可以做到A和B。然而，我们往往找不到在所有五个资产类别中提供这些能力的供应商 。
例如，在数据资产类别中，我们可以很容易地找到数据库资产和数据分类工具。但其他资产类别是否也有类似的工具？在DEVICE资产类别中，我们经常能找到DEVICE资产盘点工具，但我们可能很难找到DEVICE优先级工具。同样地，我们可能很难捕捉到完整的人员名单，包括承包商（清单），以及了解哪些人员是最重要的（优先级/分类）。
当 "你看到的就是全部 "时，这些能力的差距往往不明显。我们认为我们有一套完整的所需能力，但是，当我们看到相对于其他资产类别的能力时，能力差距就会立即显现。当我们的数字环境中出现新的资产子类别（如物联网、API、5G等）时，其中一些差距变得尤为明显。
大卫-爱普斯丹在他的《范围》一书中指出，经济、科学和社会中的棘手问题往往是由局外人解决的，他将这一现象归结为局外人有能力进行不同的类比，当考虑一个棘手问题的可能解决方案时，这些类比有助于浮现出非显而易见的解决方案。通常，这种方法的主要挑战是想出最相关的类比。
幸运的是，网络防御矩阵提供了一个现成的结构，以结合相关的类比。一个资产类别的解决方案为其他资产类别，甚至是同一资产类别中的可能解决方案提供了一个指导。
例如，我们看到从试图控制入站网络流量的防火墙到控制出站网络流量的 "下一代 "防火墙的演变。这种模式目前正在电子邮件安全中重复。安全电子邮件网关最初处理入站电子邮件流量，而 "下一代 "安全电子邮件网关现在提供对出站电子邮件流量的控制。对于终端设备、应用程序API或数据存储，会有什么类似的情况？在其他资产类别中发现这些相似之处，为建立可以推向市场的新的能力类别提供了大量的机会。尽管这个发现过程可能不会产生目前在商业上可行的想法，但网络防御矩阵提供了一个基础，让人们了解如何使用一个系统的过程来考虑广泛的潜在需要的能力。
05 最新的安全概念适应变化
在某些方面，像网络防御矩阵这样的网络安全模型类似于科学理论，它应该能够解释我们现在所知道的世界，同时也能容纳和解释新的发展或发现。同样，网络防御矩阵需要证明其在新的安全技术、架构和方法出现时的持续相关性。它需要显示这些新产品、能力和设计如何仍然适合矩阵提供的模型。下面将介绍一些我们在市场上经常遇到的流行语，并说明网络防御矩阵如何解释这些术语，并就如何在更广泛的背景下看待这些流行语提出新的见解。
零信任和安全访问服务边缘
为了理解零信任和安全访问服务边缘（SASE）如何映射到网络防御矩阵，在我们开始接受零信任之前，先来了解一下之前的访问模式。
过去，我们在网络周边保护企业，就像城堡一样，我们的资产被护城河包围，形成了一个信任边界。如图所示，通过以网络为中心的网关，如防火墙或虚拟专用网络连接，控制对该信任边界内的资产的访问（TO列），一旦进入该信任边界，就会授予信任，给予内部人员授权（AuthZ），以访问信任边界内的所有其他资产。
零信任设计原则主张，在授予对任何资源的访问权时，不应默认可信。相反，每个资源都有自己的信任边界，如下图所示，网络访问不取决于网络位置，而是取决于提交的身份认证：设备证书、用户名和密码以及2FA令牌。来自设备A和用户E的身份认证在被授予对网络G的访问权之前由访问代理处理。
在零信任设计中，我们从不默认信任请求访问的实体，我们希望通过检查关于用户的三类属性来验证用户的可信度。
结构属性。例如，用户名/密码、指纹、多因素令牌。
环境属性。例如，他们何时何地登录，他们的工作是什么，他们在做什么项目，等等。
行为属性。例如，关于他们在网络中的去向和他们试图访问的应用程序的数据。
使用这些属性，我们可以验证用户的身份，并给它一个值得信任的分数。关于用户的结构属性映射到USER-IDENTIFY，行为和环境属性是补充验证。 结构特征往往可以被伪造（通过账户接管）或颠覆（在内部威胁的情况下）。
目前的行业解决方案类别被称为零信任网络访问（ZTNA）或软件定义边界（SDP）。授予零信任网络访问的访问代理映射到网络防御矩阵的NETWORK-PROTECT。
对其他类型资源的访问代表了其他形式的零信任访问。例如，零信任应用访问（ZTAA）利用了相同的身份认证，但用于访问应用程序，如下图所示。这些应用程序可以是内部的应用程序或SaaS应用程序。
下图显示了以 DEVICE 为中心的资源的零信任访问形式，通常是通过SSH或RDP等协议，或通过远程浏览器隔离（RBI）解决方案。由于这些DEVICE资产经常作为其他资源的网关，它们可能允许进入其他信任边界，但为了坚持零信任的思想，这些信任的链接应该被明确定义。
根据不同的用例，已经将零信任访问代理映射到网络防御矩阵的三个方框中（DEVICE-PROTECT、NETWORK-PROTECT和APP-PROTECT）。
我们自然可以期待市场上出现以数据为中心的访问代理，这就是我们现在看到的新兴市场类别，如 Data Access Security Brokers或者Secure Data Access Platforms。
随着这些不同形式的零信任被映射到网络防御矩阵中，零信任的概念可以很容易地被全面应用到其他资产类别中。
扩展检测与响应和管理检测与响应
攻击者不会有固定的路线，正如约翰-兰伯特曾经说过的那样，他们以图形的方式思考，并利用任何可以访问的资产来实现他们的目标。这些资产并不严格限于一种资产类别，如果攻击者可以在入侵端点设备后转向SaaS应用，或者在网络上建立一个不受监控的系统，那么我们需要的工具也可以在这个广泛的资产范围内追踪攻击者，需要能够在多个资产类别中进行横向分析的工具。
以前，我们会发现特定资产的检测工具，如终端/设备检测和响应（EDR），网络检测和响应（NDR），以及用户行为分析（UBA）。
网络检测能力最初来自于一个较早的类别，即网络流量分析（NTA），它通常消耗网络流量日志来发现网络中的恶意活动，这些能力将映射到网络防御矩阵中，如下图所示。
然而，这些能力是独立运作的，并没有将这些独立资产类别的可疑事件联系起来。随着来自云资产（IaaS/PaaS和SaaS）的数据的增加，以及通过安全协调和自动响应（SOAR）系统推动响应行动的能力，出现了扩展检测和响应（XDR）：
正如网络防御矩阵所显示的，当我们转向检测和响应的功能时，我们更加依赖人去执行这些功能，尽管销售XDR解决方案的供应商声称他们的产品可以取代人，但如果没有知识和技能的人员，他们根本无法有效运作。
云安全
"云 "的定义通常与它的物理名称一样模糊不清，它可以指任何数量的资产，但一般来说，云安全能力更容易定义，并围绕两个参考框架映射到网络防御矩阵。
● 确保我们建立的应用程序的安全
● 保护他人建立的应用程序的安全
我们构建的应用程序通常利用主要公共云供应商的基础设施即服务（IaaS）和平台即服务（PaaS）产品，如亚马逊网络服务（AWS）、微软Azure和谷歌云平台（GCP）。在考虑IaaS/PaaS背景下的云安全时，我们寻求确保我们建立的应用程序以及部署在其上的IaaS/PaaS服务的安全。由他人建立的应用程序通常被描述为软件即服务（SaaS）产品，如Salesforce、Dropbox、Zoom、Microsoft Office 365和Google Workspace。
当考虑到SaaS背景下的云安全时，我们试图保护他人建立的应用程序和我们自己的数据。无论是IaaS/PaaS还是SaaS安全，都需要与底层供应商共同承担，这限制了我们可以直接看到和控制的东西。此外，每种云安全的技术能力、所需的技能组合和治理流程都是不同的。然而，我们想要实现目标的模式通常是相同的：
● IDENTIFY：资产盘点，并按照最佳实践进行配置，没有额外的暴露。
● PROTECT：如果有任何问题，我们希望能够很容易地解决它们。我们还希望确保环境被正确使用和正确访问。
● DETECT和RESPOND：如果在这个环境中发生了入侵，那么我们希望有能力发现并处理这样的事件。
关于 "云 "的检测和响应能力，以前在XDR的主题下讨论过，所以我在此不再重复。然而，IDENTIFY和PROTECT下的能力值得特别注意，因为它们产生了一套全新的流行语，在映射到网络防御矩阵时，可以更容易理解。
云安全态势管理（CSPM）和SaaS安全态势管理
云中安全漏洞最常见的原因是客户的错误配置。因此，我们看到大量解决这一问题的解决方案也就不足为奇了。云安全态势管理（CSPM）和SaaS安全态势管理（SSPM）的安全类别解决了这个问题的空间。CSPM有时被描述为解决SaaS部分的问题，但最常见的是，它只关注IaaS/PaaS配置的安全。SSPM专门关注SaaS应用，对更多种类的SaaS应用有更深入的配置支持。
对于CSPM和SSPM，主要功能是寻找配置缺陷，这与IDENTIFY的功能相对应。其中一些工具声称要修复这些缺陷，在这种情况下，它们也会映射到保护的功能，但许多CSPM和SSPM解决方案实际上并没有修复缺陷，而只是提供如何修复的指导。
下表显示了各种云资源如何与CSPM和SSPM的网络防御矩阵的资产类别相对应。
— | IaaS/Paas(CSPM) | SaaS(SSPM) |
设备 | 容器、计算机、主机 | N/A |
网络 | VPCs, VPNs, CDNs, DNS | N/A |
应用 | 微服务、无服务函数 | 例如，Salesforce, Office365Data |
数据 | 数据存储、数据库、文件 | 例如，Box、Dropbox、Google DriveUsers |
用户 | 账户、用户角色 | N/A |
云工作负载保护平台（CWPP）和SaaS DLP
除了确保云资源的正确配置外，我们还希望确保云资源的正确使用。对于IaaS/PaaS，这通常涉及一种称为云工作负载保护平台（CWPP）的技术能力 ，即虚拟机、容器或无服务器功能中运行应用程序工作负载的内容。
尽管名称中含有 "保护 "一词，但一些CWPP解决方案只执行识别功能，即捕获工作负载中存在的漏洞。还有一些解决方案能够通过CI/CD来消除这些漏洞，在这种情况下，这些CWPP能力也将映射到保护功能。资产类别映射是DEVICES（用于虚拟机）和APPLICATIONS（用于容器和无服务器功能）的组合。
对于SaaS，与使用有关的主要问题是围绕着企业数据的泄露，因此，解决这一问题的主要能力是SaaS 数据丢失防护（SaaS DLP）功能 SaaS DLP功能在云访问安全代理（CASB）产品的功能套件中可用，但有些产品通过SaaS提供商提供的各种API钩子在SaaS应用中自然运行。
云基础设施授权管理（CIEM）和SaaS访问管理
除了确保我们的云资源得到正确的配置和使用外，我们还希望确保访问得到正确的管理。云基础设施授权管理（CIEM）的产品类别，也被称为云身份治理，帮助我们管理权限和权利，以便我们能够遵守最小特权的原则，并限制IaaS和PaaS环境中任何受损账户的爆炸半径。
在SaaS领域也出现了类似的功能；然而，由于SaaS应用种类繁多（相对于三大IaaS/PaaS供应商而言），对于大多数供应商来说，在广泛的SaaS应用中管理权利和权限的能力是难以支持的，因此，这一领域的大多数供应商只涵盖最流行的SaaS应用。
CIEM和SaaS访问管理解决方案都声称涵盖人类和非人类身份，但目前这些解决方案的主要优势在于管理人类身份的权限和权利，因此，它们目前存在的能力与USER-IDENTIFY相对应。对于IaaS/PaaS，这三类能力映射到网络防御矩阵，如下图所示：
另一个新的类别已经出现，称为云原生应用保护平台（CNAPP），它结合了CSPM、CWPP和CIEM的能力，这对于这些能力之间的自然相邻关系是有意义的。在SaaS安全领域还没有出现类似的融合，但最终可能会出现。
网络资产攻击面管理（ASM）
攻击面管理（ASM）使我们能够获得对环境结构的认知，特别是与暴露在攻击者面前的内容。通常是通过外部扫描和内部数据汇总获得的。这两种方法相辅相成，可以很好地验证两种来源的发现。理想情况下，通过外部扫描发现的攻击面将与通过内部数据来源了解的攻击面相匹配。
攻击面的发现、优先级和监测在IDENTIFY下进行。修复任何问题都在PROTECT之下；然而，目前大多数ASM能力只做识别相关的活动。与ASM相关的资产类别根据厂商和他们发现资产及其相关攻击面的具体技术而有所不同，但大多数侧重于设备、网络和应用。
最近定义的网络资产攻击面管理（CAASM）类别对资产的构成有更广泛的看法，并打算管理一切。然而，如果没有一个规范性的清单，我们可能会遗漏考虑某个资产。这就是网络防御矩阵可以再次发挥作用的地方，它提供了一个我们关心的资产的全面清单。这些资产包括组织直接拥有的五种资产，但也包括我们的供应商、客户和雇员拥有的资产。
此外，与这些资产相关的攻击面不应该被孤立地看待。它们是联系在一起的，但往往以我们不容易理解的方式联系在一起。
CAASM类别中的能力，如果做得好的话，应该汇总多维网络防御矩阵中定义的所有资产的信息，并将它们连接在一起，使我们能够了解这些资产及其相关的攻击面是如何相互关联的。
本文所有内容仅供参考
声明：本文来自快手安全应急响应中心，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
