风险的漏洞管理

漏洞管理与合规相辅相成。正如遵循特定监管标准有助于有效管理漏洞,有效管理漏洞也有助于规避可致违规的安全事件。

风险的漏洞管理风险的漏洞管理
但鉴于不同监管机构标准不同,既有效且合规的漏洞管理对不同组织机构而言可能意味着不同的东西。但有一个例外:风险!所有标准都强调了风险!具体有:

PCI DSS 要求 6.1 声明:公司企业必须 “设立漏洞发现过程,并为新发现的安全漏洞赋予风险评分。”
GDPR 第 32 条要求:实现 “恰当的技术性或组织性措施以确保适合风险情况的安全水平。”
HIPAA 安全规则强制要求:“评估电子健康信息的机密性、完整性和可用性所面临的潜在风险与漏洞。”
GLBA 安全规定要求:公司企业须 “识别并评估客户信息风险,评估当前风险控制安全措施的有效性。”

很多监管标准都要求评估风险并以此做出恰当响应才能达成并维持合规,以上几条不过摘录一二而已。在漏洞管理语境下,如 PCI DSS 要求 6.1 所述,合规就意味着基于风险给漏洞排序并修复。
但由于漏洞对各家公司意义不同,要做到按风险管理漏洞并不容易。准确评估首先要确定:
漏洞武器化的概率有多高;
如果武器化,对特定公司的影响是什么。
想要确定这几个变量,以下建议可供参考:

1. 了解资产情况

可能影响关键资产的漏洞绝对要优先修复。对大多数企业而言,关键资产包括但不局限于适用于一个或多个安全合规要求的那些。比如说,受 HIPAA 管辖的公司企业就要特别关注含有个人健康信息的资产;PCI DSS 辖下公司应重视支付卡数据;GDPR 监管下的公司企业还要将用户数据也纳入重点关注对象。
识别出关键资产后,还要确定并记录下其存储、处理、管理和可能被破坏的方式。与这些资产相关联的技术有哪些?怎么连接的?哪些用户可以出于哪种目的访问这些资产?哪些人可能会想破坏/泄露这些资产?为什么?这些资产一旦被破坏/泄露,会造成什么后果?此类问题的答案有助于识别、分类和排序可能影响这些资产的潜在漏洞。

2. CVSS评分不代表一切

排序修复动作时最常犯的一个错误,是将通用漏洞评分系统 (CVSS) 的分数等同于风险值。尽管 CVSS 评分能反映出漏洞本质和漏洞武器化后的可能行为方式,但这些都是标准化的,并不能反映出上述两个决定漏洞特定风险值的变量——武器化概率和针对公司的特定潜在影响。
事实上,2014 年针对 CVSS 评分的研究就发现,“仅根据 CVSS 评分高低修复漏洞,无异于随机拣取漏洞修复。” 该研究还发现,尽管漏洞的 CVSS 评分似乎与其武器化概率并无关联,但有其他因素与之相关,包括:是否存在漏洞利用概念验证代码,深网论坛、暗网市场等非法在线社区是否提到该漏洞利用代码等。
鉴于绝大多数通用漏洞与暴露 (CVE) 从未武器化,该研究的结论具有一定实际意义。高 CVSS 评分的 CVE 只有在恶意黑客能武器化的时候才是真正的威胁。但要武器化漏洞,黑客首先得确定武器化方法,而这通常都需要概念验证 (POC) 代码。使用或开发 POC 代码的过程往往包含大量试错。若不在深/暗网和其他非法在线社区中与别的黑客交流,多数黑客一般是搞不定的。
换句话说,无论 CVSS 评分是高是低,评估漏洞时都需要将是否存在 POC 代码和相关黑客讨论作为重要风险因素加以考量。

3. 风险评估框架

出于修复排序目的的风险评估过程优化可以考虑采用评估框架。现成的风险评估框架有很多,其中一些还是特定监管机构强制要求或建议采用的,这些现成的框架都能帮助安全团队更有效地评估、排序和管理不同风险。
但无论采用哪种框架,都需要根据公司特定环境和风险因素加以实现。也就是说,你需要统计资产,评估资产被黑的潜在影响, 判断漏洞武器化概率。无论有没有应用漏洞风险评估框架,缺了上述信息都无法准确评估漏洞对公司的特定风险。
除此之外,还需谨记:虽然合规不应是安全项目的最终目标,但各个合规要求都强调风险必然是有原因的。有效管理漏洞,尤其是合理排序修复动作,只有基于风险才是可行的。


来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/31560522/viewspace-2652655/,如需转载,请注明出处,否则将追究法律责任。

转载于:http://blog.itpub.net/31560522/viewspace-2652655/

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
### 回答1: Swagger是一种用于描述API的工具,它可以使用OpenAPI规范来描述API的结构和功能。Swagger可以帮助开发人员更快地设计、测试和使用API,因此被广泛使用。 然而,如果没有适当的安全措施,Swagger可能会导致接口泄露漏洞。这意味着,攻击者可能会利用Swagger文档中提供的信息来攻击API或获取敏感信息。 为了避免这种风险,应该采取以下措施: 1. 不要在Swagger文档中包含敏感信息,例如API密钥或数据库连接字符串。 2. 在生产环境中禁用Swagger文档。 3. 在API请求中使用身份验证和授权措施。 4. 定期扫描API以检测漏洞。 总之,在使用Swagger时应该格外注意保护API的安全性,以防止接口泄露漏洞的发生。 ### 回答2: Swagger接口泄露漏洞是指在使用Swagger API文档工具时,由于配置不当或者误操作导致接口文档信息泄露的安全漏洞。Swagger是一种开源的API文档工具,允许开发者在接口开发过程中生成和维护接口文档,是很多项目中常用的工具之一。 然而,由于缺乏相应的安全设置,Swagger接口文档可能未经授权地暴露给了攻击者,从而可能导致以下风险: 1. 敏感信息泄露:攻击者可以通过Swagger文档了解API的实现细节、参数和数据模型等敏感信息,进而构造恶意请求或获取关键数据。 2. 接口滥用和误用:未经授权地访问Swagger文档可以让攻击者对接口进行滥用和误用,例如频繁请求接口导致资源浪费或服务器过载。 3. 威胁建模和攻击预测:攻击者通过获取Swagger文档可以对API进行分析和建模,从而更好地进行攻击预测和制定针对性的攻击策略。 为了防止Swagger接口泄露漏洞,我们可以采取以下几个措施: 1. 鉴权和访问控制:通过合适的身份验证和访问控制机制,仅允许授权用户或系统访问Swagger接口文档,避免未经授权的泄露风险。 2. API密钥管理:为每个合法用户或系统提供唯一的API密钥,用于限制对Swagger接口文档的访问权限,并及时禁用或回收泄露的API密钥。 3. 敏感信息过滤:在Swagger文档中剔除敏感信息,例如数据库密码、密钥等,确保只有必要的接口信息对外可见。 4. 定期审查和更新:定期审查Swagger接口文档的访问权限和配置,及时更新和修复可能存在的漏洞,确保接口文档的安全性。 综上所述,Swagger接口泄露漏洞可能导致敏感信息泄露、接口滥用和误用、威胁建模和攻击预测等风险,为了减少这些安全风险,我们应该合理设置访问权限、管理API密钥、过滤敏感信息,并定期审查和更新接口文档的配置。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值