基于风险的测试如何改变受监管机构的安全运作
对于许多组织而言，网络安全保障渗透测试仍遵循着一个熟悉的过程。系统需要进行年度测试，因此有人提出要求。随后制定了范围、进行了审核并获得批准，发出采购订单，并安排了测试、交付和报告，同时对任何发现情况也进行了重新测试。一年后，这一周期又会再次开始，适用于大多数系统。.
每一项步骤本身都有其意义。综合起来，它们形成了一种缓慢、资源密集且最重要的还缺乏风险控制的流程。测试是在采购部门允许的情况下进行的，而不是在保证体系能够带来最大价值的情况下进行的；而系统所接受的测试深度往往与该系统对组织的至关重要性几乎没有关系。.
在 Resillion，我们一直在与公共部门组织合作，以改变这种状况。我们拥有将来自我们业务各方面的专业知识相结合的经验，以及悠久的创新和持续改进传统，而这项工作正是基于这些经验而开展的。这些成果展示了在将保障措施设计为围绕风险而非采购日程的方案时，能够取得哪些成果。.
难以维护的保证
我们的一个客户所在的业务运营在英国监管最为严格的环境中。其网络安全措施由行业监管机构根据其安全评估原则进行评估，这些原则要求组织必须表现出 他们的保函活动是否有效，以及是否与风险相称。.
现行的测试模式使得情况变得更加复杂。大多数系统都需要进行年度测试，而每次测试都要经过八个独立的审核和批准步骤。客户的员工花了大量时间管理项目，而不是管理风险。此外，系统关键性的确切程度与所接受的测试深度之间并没有任何记录化的联系，因此比例性依赖于解释而非证据。.
这不是特定于组织的难题。在 GovAssure 下工作的中央政府部门、根据 NIS 法规运营的关键国家基础设施运营商以及准备实施英国网络安全与抗灾法案的组织都面临着同样的问题：你能否证明你的保障措施与风险相匹配？
让风险主导范围
我们与客户共同设计了一种基于风险的持续保障模式。其核心是评估每个系统的关键性和风险的测算工具，并利用这一评估来确定测试的范围、深度和频率。.
这一切之所以成为可能，是因为我们结合了很少能结合在一起的三个 Resillion 专长领域。 网络保障测试团队 带来了对攻击者如何攻击关键系统以及如何进行测试的深入了解。 质量工程 该团队带来了其在软件交付方面的持续测试经验，即测试被嵌入到每个变更之中，而不是在项目结束时进行安排。 治理、风险与合规 (GRC) 专家们为审计师和监管机构带来了必要的风险评估和监管见解，使其能够为每一项决策提供合理的依据。.
我们在联合研讨会上制定了评估标准，将客户的利益相关方与三个团队汇聚在一起。这些标准与监管原则以及客户自身的风险承受能力保持一致，以便每个范围界定决策都能基于已商定的透明基础进行决策。在采用该工具之前，我们对一系列此前已测试过的系统进行了测试，以确认其输出结果准确无误，并获得客户的认可。.
我们随后将这一变革作为一套由四个阶段组成的九个工作流的结构化方案交付。我们首先了解了当前的状况：梳理资产清单，分析多年来的历史数据，以发现哪些风险真正集中在哪些方面。接下来，我们设计了一套预先批准的范围，以便能够在无需每次重复审批的情况下快速动用测试。我们随后将该模型融入日常运营之中，并将测试与运营流程相结合。 DevSecOps 生命周期 这样一来，重大变更就能自动触发保障措施，并持续支持补救措施，直至最终实现全面关闭。最后，我们建立了指标和治理体系，以持续支持这一变革，同时贯穿始终进行变更管理，确保新模式能够成为组织运作的惯例。.
效率不影响独立性
精简保障工作的普遍担忧在于，效率可能会以牺牲客观性为代价。我们设计了该模型是为了加强独立性，而非削弱它。范围是由商定的风险标准确定的，而非由测试人员确定，因此没有人会对结果有任何利益冲突。发现结果在不经过任何滤镜的情况下根据标准严谨性评估方法进行报告。在支持补救措施时，我们会由另一位顾问重新进行验证测试，因此我们永远不会认可我们自己的建议。.
结果
结果非常显著。我们的客户现在消费的金额比以前多出了 减少60% 人的工作时间 关于测试工作的安排。已完成审查和批准步骤。 从八个减少到两个 按参与情况计算，且治理结构完全完好，以及从请求开始测试的平均时间 缩短了从六周到两周的时间。.
同样重要的是，测试的优先级基于关键性因素，并根据其对项目价值的提升程度进行安排。这意味着，除了每年进行周期性测试之外，在重大变更发生后也不再进行测试。此外，测试从风险评估到范围、结果和验证修复的整个过程都具有可追溯性，为监管机构提供了有效的保障流程的清晰证据。.
缩短测试时间
审批步骤从每项服务缩减至 2 项
请求开始测试后的交付时间缩短至2周
为什么这对公共部门来说很重要
对于公共部门和受监管机构而言，效益远不止在于效率。.
第一个问题是，审计和保证的证据变得更加容易验证。当每个测试都能溯源到一份记录化的风险评估中时，向审计师和监管机构证明其合理性就变得无关紧要了，而只需展示记录即可。.
第二点是，关键系统应该得到应有的关注。基于风险的范围界定方法将测试工作集中在最重要的系统中，而不是将其均匀分布在整个项目上。.
第三点是释放了稀缺的内部资源。公共部门的安全和采购团队往往面临压力，而通过将参与过程从八个审批步骤缩减到两个，就可以让那些最需要这项服务的群体获得更多帮助，而不会影响到关键的控制措施。.
最后，保证服务能够跟上变化的步伐。将测试与开发生命周期相结合意味着，在新风险出现时即进行评估，而不是在后续的计划测试中进行评估。.
入门指南
正在考虑类似旅程的组织不妨先问自己几个简单的问题：他们是否制定了统一且可记录的流程来评估每个系统的关键性？他们能否将每个测试的范围与这一评估联系起来？常规测试通常会经过多少个审批步骤？哪些步骤真正能有效管控风险？而当重大变更发生时，它是否会引发保障措施，还是等待下一个年度周期？如果答案不确定，那么就有机会重新获得价值和时间。.
我们随后将这一方法应用到了其他 Resillion 客户身上，取得了类似的效率提升。有效的保证取决于协议标准、治理体系和证据的可信度，以及技术测试的力度。一旦这些条件具备，组织就可以更明智地测试产品，减少管理项目的时间，并为董事会和监管机构提供所需的信心。.
要了解基于风险的持续保障模式如何适用于您的组织，请联系 Resillion网络保障团队.
