使用CVSS漏洞评分系统解决API安全问题

一零零八六

知道您使用的 API 中存在安全漏洞是一回事。了解风险的严重程度以及导致环境违规的可能性是另一回事。
了解漏洞评分系统 （CVSS）

通用漏洞评分系统 （CVSS） 是一个公共信息存储库，可根据已知软件漏洞的严重性和范围为其分配分数。分数的目的是帮助开发人员、IT 管理员和其他利益相关者轻松确定哪些漏洞需要紧急关注，哪些漏洞不那么重要。
“它旨在为软件漏洞提供开放和通用的标准严重等级”，国家基础设施咨询委员会
分数基于三个主要指标：基本、时间和环境：


通过同时评估这些指标，CVSS 为每个漏洞分配总分。


CVSS 分数计算中最重要的一组指标是基本类别中的指标：

• 攻击媒介：漏洞被利用的手段。
  
• 攻击复杂性：难以实现为利用此漏洞而必须存在的条件。
  
• 所需权限：攻击者必须拥有的特权级别才能利用此漏洞。
  
• 用户交互：要求攻击者以外的人类用户参与利用易受攻击的组件。
  
• 范围：受漏洞影响的资源数量（换句话说，漏洞是仅影响应用程序或环境的一部分，还是影响多个部分）。
  
• 机密性：漏洞带来风险的机密信息量的影响。
  
• 完整性：漏洞破坏环境完整性和运行状况的程度。
  
• 可用性：漏洞可能导致资源不可用的程度。
  

例如，考虑一个 API 漏洞，Internet 上的任何用户都可以利用该漏洞来访问高度敏感的数据或对关键系统造成完全中断。这种类型的漏洞将获得较高的CVSS分数，因为它易于利用，其范围以及它带来的机密性和可用性风险。Log4Shell中臭名昭着的远程执行代码（RCE）漏洞就是一个例子，cvSS得分为10/10。
另一方面，只有在非常特定的环境配置下特权用户才能利用的 API 漏洞将获得相对较低的 CVSS 分数。如果漏洞不会将关键信息置于风险之中，或者只会影响系统的非关键组件，那么漏洞也会如此。
其他“通用”服务计划指标

在计算 CVSS 分数时，时间和环境指标被视为非强制性的，但它们通常用于为分数计算提供额外的上下文。
在时间类别中，这些附加计算因素包括：

• 漏洞利用代码成熟度：评估漏洞被现实世界的威胁参与者利用的可能性。
  
• 修正级别：修正风险的难度。
  
• 报告可信度：安全研究人员对其漏洞评估准确性的信心水平。
  

环境组类别中还有非强制性指标：

• 保密要求：利用漏洞是否需要保密信息。
  
• 完整性要求：在利用期间环境完整性丢失的风险。可用性要求：在攻击期间环境可用性丢失的风险。
  
• 修改攻击媒介：是否可以修改环境以启用攻击。
  
• 修改攻击复杂性：当可以修改环境以简化漏洞利用时。
  
• 所需的已修改权限：攻击者是否可以修改权限以利用他们原本无权利用的漏洞。
  
• 修改用户交互：攻击者是否可以操纵用户交互以简化攻击。
  
• 修改范围：攻击者是否可以将攻击范围扩展到其影响的基本组件之外。
  
• 修改的机密性：是否可以修改攻击以访问其他机密信息。
  
• 修改的完整性：修改环境时，此漏洞利用是否会以其他方式影响环境的完整性。
  
• 修改后的可用性：此漏洞利用是否会对已修改环境中的环境可用性造成更大的中断。
  

环境指标允许分析师根据不同的环境配置（即不同类型的操作系统、软件库、访问控制框架等）考虑漏洞可能被利用的方式以及漏洞可能产生的影响来调整分数。
全景中的漏洞评估评分

Panoptica使用来自通用漏洞评分系统（CVSS）的数据不仅识别API漏洞，而且还对其进行评分和评估，以提供对威胁严重性的深入可见性。
您可以在网络上访问 CVSS 分数。但是使用全景，无需在浏览器中查找此信息。全景显示 CVSS 数据，以及全景网络发现的 API 漏洞信息。
对于每个图像，您将看到漏洞列表以及分数：


除了显示分数之外，Panoptica 还会对其进行分解，以便您知道为什么漏洞会收到分数。


此数据基于 CVSS 分数，但远不止于此。全景图还标识了环境中使用的变量，以提供最准确的分数评估。
例如，Panoptica会根据您的配置考虑攻击复杂性等因素。如果攻击复杂性较低，则漏洞得分会更高。更复杂的攻击，因此更难执行，将获得较低的分数。


再举一个例子，以攻击媒介为例，它确定了如何利用给定的漏洞。如果您的配置中存在攻击媒介，则与无法在您的环境中实际执行攻击相比，漏洞将获得更高的分数。
同样，如果攻击者根据您的配置可以使用执行攻击所需的权限，则攻击分数会更高。
总的来说，Panoptica依靠八个变量来确定每个API在设置中的易受攻击程度。
有了这些信息，您可以自己做出有关如何处理每个漏洞的明智决策。对于得分较高的漏洞，您可能希望通过阻止易受攻击的请求来紧急采取行动。得分较低的漏洞可能不需要立即采取措施。
赢得 API 安全之战

了解您的环境中存在哪些 API 安全漏洞只是成功的一半 - 如果那样的话。真正重要的是获得确定给定漏洞严重程度所需的可见性和清晰度。
通过利用 CVSS 数据并对您的环境进行自定义评估，Panoptica 提供量身定制的漏洞评分，以帮助您尽可能有效地应对环境中可能出现的任何风险。
用于容器和库伯内特的全新 MITRE ATT&CK 安全框架

MITRE 组织发布了用于容器的 ATT&CK 矩阵。该发布标志着一个研究项目的高潮，该项目调查了ATT&CK矩阵中容器相关技术的可行性。基于广泛的社区反馈和贡献（我很乐意参与其中），创建并发布了一个新的 ATT&CK 容器矩阵。


在思科，我们正在努力支持和促进这项工作。几个月前，我们得出的结论是，用于评估 Kubernetes 集群安全级别的现有框架不足以满足真正的需求和威胁。通用的库伯内特斯风险评估框架基于流行的独联体库伯内特斯基准。该框架由一套全面的测试组成，涵盖了所有 Kubernetes 元素的配置安全最佳实践。然而，该框架并没有解决其他不基于安全错误配置的攻击媒介。恶意攻击可能从多个元素开始，这些元素超出了安全配置错误的范围。但是，还有其他业务要素推动了新框架的发展。流行的托管 Kubernetes 服务（例如，AWS EKS、Azure AKS 或谷歌的 GKE）不提供对由 CIS 基准测试的集群元素的访问，因此很难评估这些服务的安全状态。
这些考虑因素促使我们制定了一个新的风险评估框架，以验证是否涵盖了所有其他攻击方法、步骤和阶段。此外，使ATT&CK矩阵成为一个很好的候选者是因为它只基于在真实攻击中使用的战术和技术，使其非常具体（即使不是排他性的）。
Kubernetes正迅速成为云原生容器编排的行业标准，但同时它也非常复杂，并不是每个人都能很好地理解它。最重要的是，通过快速部署和不断更改来管理其安全性涉及许多不同的角色协同工作，这有其明显的优势，但可能会使事情变得更加复杂。在处理其核心如此先进的技术时尤其如此。而且，尽管存在左移运动，但事实证明，并非所有开发人员都完全意识到这就是他们正在使用的内容！这一切都使得管理库伯内特的安全性变得困难。
了解 Kubernetes 安全性首先要了解如何破坏 Kubernetes。因此，安全团队需要全面了解保护组织 Kubernetes 集群安全所涉及的每个角色，就像原始的 MITRE ATT&CK® 矩阵一样，评估所有攻击阶段并审查可在恶意攻击中实施的每种策略和技术。
ATT&CK®矩阵提供了如何执行攻击的技术细节，并解释了攻击者通过执行上述技术步骤要实现的目标。这种组合对于帮助不同技术角色之间的协作至关重要，每个角色自然有不同的视角，因此需要不同的细节才能采取行动。因此，该模型考虑了：

• 战术 – 攻击媒介，攻击者的最终目标
  
• 技术和子技术 - 用于实现所述目标的方法
  
• 描述对手如何使用相关技术实现这些策略的记录在案的攻击
  
• 补救建议
  

参考：techblog

尔等的帅爹

回个帖子，下班咯~

一条心

不错 支持一个了

程少骏

我了个去，顶了