OSSTMM 中 RAV 的计算似乎作为一种安全指标非常有用，但它们能否成为符合新 ISO 27001:2013 和 ISO 31000 的风险评估方法的基础？
ISO 27001:2013 风险评估要求与 ISO 31000 保持一致，因此我认为我们可以专注于 ISO 31000。
ISO 31000 建立了以下阶段：
我认为 OSSTMM 测试可以与风险识别（发现、识别和描述风险的过程）相匹配。
风险分析阶段（理解风险性质和确定风险级别的过程）和风险评估（将风险分析结果与风险标准进行比较以确定风险和/或其大小是否可接受或可容忍的过程）可以配合攻击面和RAV的计算。
风险处理阶段可能是一个额外的阶段，在该阶段使用 OSSTMM 中的漏洞分类，我们选择降低风险的相关控制（攻击面，RAV）。
这种匹配是否适合您？
是否可以使用 OSSTMM、攻击面和 RAV 计算作为符合 ISO 31000 的风险评估方法？
ISO 31000 或 ISO 27001:2013 中是否存在任何基本要求使得无法使用 RAV 作为其风险评估方法？
我只有 ISO 27001 合规性的审核和审查经验，但没有 31000 的经验，所以我的答案将集中在这一方面。总而言之，答案是：
首先，应该注意的是，ISO 对风险评估方法没有要求。ISO 标准通常定义组织应该做什么而不是如何去做。所以你是对的，你可以使用 OSSTMM、攻击面和 RAV 计算作为风险评估的方法。
例如在 ISO 27001:2013 中，我们可以在第 8.2 章“信息安全风险评估”中看到：
考虑到 6.1.2 a) 中建立的准则，组织应按计划的时间间隔或在提议或发生重大变更时执行信息安全风险评估。
组织应保留信息安全风险评估结果的文件化信息。”
第 6.1.2 章中的标准是：
6.1.2 信息安全风险评估
组织应定义和应用信息安全风险评估过程：
a) 建立和维护信息安全风险标准，包括：
1) 风险接受准则；和
2) 执行信息安全风险评估的准则；
b) 确保重复的信息安全风险评估产生一致、有效和可比较的结果；
c) 识别信息安全风险：
1) 应用信息安全风险评估过程来识别与信息安全管理体系范围内信息的机密性、完整性和可用性丧失相关的风险；和
2) 识别风险所有者；
d) 分析信息安全风险：
1) 评估如果 6.1.2 c) 1) 中确定的风险成为现实可能导致的潜在后果；
2) 评估 6.1.2 c) 1) 中确定的风险发生的现实可能性；和
3) 确定风险等级；
e) 评估信息安全风险：
1) 将风险分析结果与 6.1.2 a) 中建立的风险准则进行比较；和
2) 对分析的风险进行风险处理的优先级。
现在正如您提到的，这里的重要部分是概率/可能性因素。ISO 27001:2013 规定，用于风险评估的方法必须：
2) 评估6.1.2 c) 1) 中确定的风险发生的现实可能性；
OSSTMM v3 将 RAV 描述为a scale measurement of the attack surface. 它并非旨在衡量风险，而是用作比传统风险计算更加详细和实用的操作指标，例如：
风险 = 威胁 x 漏洞 x 资产
OSSTMM 故意避免可能性因素，因为它非常有偏见，不一定是客观的。那么 RAV 不能按原样用于执行概率风险评估，这确实是 ISO 标准的要求，那么您的第二个问题的答案是否定的。
然而，根据我的经验，公司倾向于调整他们正在使用的风险评估方法/框架，例如 OSSTMM 或任何其他方法（例如 Octave、NIST 框架、TRA 等），以适应他们的特定环境和需求。
因此，最后，您必须将可能性因子集成到 OSSTMM/RVA 中，才能将其用作符合 ISO 27001 的 RA 方法。它不必很复杂，ISO 也没有说明你必须如何去做。
附带说明一下，一个典型的建议是将每个部门的方法与全球/标准公司风险评估方法保持一致，特别是在计算方法方面，因为它基本上使管理层更容易在同质的基础上评估风险。如果您不这样做，并且在您的公司内使用不同的方法，您将不得不协调结果，有时会将苹果与香蕉进行比较。
出于这个原因，我不建议使用 OSSTMM RAV 作为风险评估的方法。它过于具体和可操作，无法与公司其他地方的其他风险进行有效匹配和比较。