金融网络安全风险管理指南（三）：数据泄露成本估算的场景分类

网络事件的影响或后果可能是重大而复杂的。由于对人员、技术体系结构、技术运营、业务流程、客户影响和法规风险的破坏性影响，以及与恢复正常业务相关的无数因素，成本可能会累积。在关于最近备受瞩目的数据泄露事件的报告中描述的回应，让我们得以一瞥衡量实际影响的不同组织方法。这一报告揭示了高昂的成本，其范围远远超出了受影响企业的初步考虑范围。经济影响难以衡量，随着事件特征和行业背景的变化，并且可能会在很长一段时间内持续下去。成本是非常真实的，而且可能是巨大的。

风险量化

在尝试计算数据泄露的真实成本时，也许要考虑的最重要方面是选择适当的度量单位的重要性。这种选择不取决于哪种货币定义货币单位;相反，这取决于什么应算作成本。大多数运营风险管理策略将损失定义为在没有发生数据泄露事件的情况下不会花费的资金。即使有这些明确定义的标准，根据费用的分类方式，也可能不允许包括由数据泄露产生的费用，因为组织已将一定数量的美元分配给不依赖于任何单个事件的运营费用。例如，大多数金融机构都具有24-7全天候运营的技术事件响应能力。在网络安全漏洞之后，技术人员可能会完全投入到事件响应，恢复和取证活动中。

例如，24-7全天候运营工作通常是相同的员工在负责连续业务运营。由于他们无论如何都会在工作，因此这些人被视为开展业务的成本，而不是任何个人数据泄露事件的边际成本的一部分。举一个更有争议的例子，考虑到大多数金融机构会为受数据泄露影响的客户购买身份盗窃保护保险。在一些机构中，与这种客户身份盗窃保护相关的成本不被视为由数据泄露事件造成的运营损失，而是作为客户善意归类于总分类账。这些例子和其他类似的例子导致许多从事网络安全工作的人声称，数据泄露的真实成本通常被低估了。

也就是说，网络安全专业人士一直感到惊讶的是，金融机构声称直接归因于网络安全漏洞的损失相对较小。这可能反映了银行有时可能将运营损失记录为仅因数据泄露而产生的直接费用的方式。只有当发票仅以从损失中收回为依据时才记录这些发票，例如将资金转入客户的帐户或支付供应商发票以快速交付硬件或软件。

相比之下，与现有员工应急配置相关的成本是基本的“银行运营”成本。该术语在行业中用于与“银行变更”成本区分开来。银行运行成本包括稳定且可预测的费用，例如支持当前运营的房地产设施，电力，照明和办公用品。银行变更成本包括具有特定可交付成果的项目，旨在增强金融服务或加强当前的运营控制。当需要工作来管理银行的员工的技能被转移以从紧急情况中恢复时，该成本仍被归类为运营费用。此外，即使专门从事项目工作的员工（如软件工程师）被转移到调查网络事件中，这些费用也会被计划项目的项目超支所吸收。因此，尽管不是严格的银行运营成本，但在财务会计中，它们仍然与网络安全事件无关。

网络安全成本计算通常不考虑项目的延期，因为从事数据泄露事件响应工作的人没有从事技术创新。他们不考虑将帐户转移到另一家银行的客户造成的业务损失。这些是机会成本，错过了可能已经实现或可能没有实现的新业务 - 而不是门外的钱。这些度量单位不太可能直接归因于特定的数据泄露（如下图所示）。

实践中的数据泄露影响分析

关于计算数据泄露的成本，要理解的第二个最重要的方面是，任何答案充其量只是一个估计。数据泄露的成本最终将取决于业务影响，这是一个在实际发生数据泄露事件之前难以估计的因素。几十年来，信用风险专业人士一直在收集有关过去客户行为的历史数据，以确定向客户提供的信贷可能无法偿还的指标。信用违约后果是使用具有数字货币价值的交易的财务影响来计算的。网络安全风险事件本质上是高度可变的，其后果不仅限于受影响的交易。此外，它们甚至可能不是根据受影响的交易计算的。当受影响的交易集未知或可能不可知时，网络安全漏洞调查的分析中通常存在时间延迟因素。同样，金融机构通常因“无卡”信用卡欺诈而遭受损失，并且通常无法知道客户的身份验证信息是否因任何给定的数据泄露事件而受到损害。

事实是，业务损失计算依赖于资产价值和市场价值等有形资产，而网络安全漏洞的成本与受影响的计算机资产的成本或市场数据流等网络服务的成本没有直接关系。网络安全事件可能会导致系统运行突然中断，无法通过立即更换受影响的资产或服务来修复。即使实物资产或服务可以立即更换，也必须对其进行配置并集成到财务系统中，以减轻数据泄露的影响。这种反应必须是预先计划的，如果存在，也记入日常运营费用，不被视为任何给定数据泄露成本的一部分。

在理论上估计数据泄露的可能成本的关键是分析依赖于技术的业务系统与网络风险事件进行比较。确定数据泄露影响的系统方法的先决条件是业务系统清单。这允许确定如何使用系统来实现潜在网络攻击者的目标，并允许构建可能的网络风险事件的完整列表。有了这样的列表，可以分析事件的个体和模式，以了解人员，流程和技术的实际变化，并从那里估计这种情况的潜在影响。此信息应提示选择用于损失估算的度量单位，然后可以确定数据泄露成本估算，如下图所示。

估计的数据泄露影响计算

场景创建

当然，并非每个可能的技术滥用或破坏都应被视为潜在的网络安全事件，网络安全独有的一些风险分类是合适的。国际清算银行（BIS）巴塞尔委员会关于《稳健运营风险的指南》指导银行在识别现有和潜在的重大运营风险时，考虑对具有类似根本原因的事件进行汇总分析。它具体指以下损失类别：

• 员工行为导致的内部欺诈

• 由于无关联罪犯造成的外部欺诈

• 雇佣措施和工作场所安全

• 客户、产品和商业惯例

• 对有形资产的损害

• 业务中断和系统故障

• 执行、交付和流程管理，包括未经授权的访问和交易对手绩效

网络安全事件可能是任何这些损失类别中风险的根本原因，方案选择应考虑根据此列表中的事件类型可能导致重大损失的所有业务流程。BIS 指南还指示银行汇总报告根本原因类别。这允许比较跨业务部门和机构观察到的风险，以进行资本配置。ISACA 的控制流程“对齐、计划和组织流程：“管理风险”（APO012） 建议使用一系列通用场景来定义一组更相关和自定义的场景，从而实现整体企业目标的自上而下视图，并考虑最相关和最可能的风险场景。

使用 BIS 类别作为场景选择的工具的好处是提供完整性标准，以确保考虑各种各样的网络安全风险事件，至少在某种程度上是这样。网络安全损失在被认定为网络安全损失而不是被归类为欺诈时，传统上被归入更一般的“业务中断和系统故障”或“执行、交付和流程管理”风险类别。该列表于2003年发布，此后监管机构非常明确地表明，网络安全应被视为顶级风险。金融机构通常将单个损失事件分为多个类别，以便在经营实体之间进行比较。

请注意，在运营风险的上下文中，“场景”一词是一个艺术术语。运营风险评估通常在类别级别定义风险事件，例如由于电信欺诈而导致的资金被盗。虽然这些类别有助于在较高层次上了解最严重的影响可能在哪里，但在详细定义假设事件之前，不可能准确识别受影响的系统或使用受影响系统的数据来估计损失。估计任何运营风险事件（包括网络安全漏洞）成本的实用方法是使用风险类别和业务目标来确定可能影响金融机构的最可能的风险事件类别，然后定义一个现实和可能的场景，可用于深入研究每个系统以量化潜在影响。场景是对风险事件之前、期间和之后的活动的描述。

下图提供了一个系统化场景创建方法的示例。网络安全风险事件的范围按前面介绍的威胁类别进行组织。每个目标都与两组变量相关联：（1）可用于实现目标的技术，以及（2）可以使用该技术实现目标的访问配置文件。然后将对手本身划分为具有不同访问模式的社区。请注意，在这个简单的细分中，没有假设访问仅限于授权使用，只是承认不同的访问配置文件与可用于实现对手目标的技术环境相关联。这些信息可用于确定可能导致的情况，这种情况应被评估为固有风险，因为它是敌对目标实现的后果，就好像管理控制没有限制目标的实现一样。这与假设没有控制措施不同，而是认识到尽管可能有控制措施，但对手可能以某种方式能够实现目标。

网络安全场景创建示例方法

暂且不提在部署控制的情况下是否可能发生攻击的问题，这样可以让知识自由地确定潜在影响，而无需明确批评网络安全专业人员必须依靠的技术控制操作人员来完成分析。也就是说，对对手成功的潜在后果进行简单评估有助于确定进一步分析的优先顺序，因为应该对可能实现更具破坏性后果的潜在技术进行更多的审查。在运行中仅允许系统访问的情况下，对后果的估计允许确定旨在估计财务影响的进一步情景开发工作的优先级，并可用于比较不同开发阶段的替代情景。

请注意，尽管我们的示例必然受到限制，但在实践中，此分析应包括所有系统，并且只有在系统在潜在对手社区中提供价值和访问配置文件差异的情况下，才应缩小技术范围。如果对手更改了配置文件（即，具有第三方访问权限的攻击者在攻击过程中获得了内部访问权限），则该场景的潜在影响将扩展到包括可通过内部场景访问的影响。这同样适用于具有最终用户访问权限与特权访问权限的内部用户。在任何场景的开发中，都应考虑攻击者跨越访问级别之间界限的能力。

上图总结了成功攻击的影响，考虑了对一般风险类别“网络安全”中的一组事件缺乏预防性控制：“资金盗窃”、“信息盗窃”和“中断”。网络安全的历史告诉我们，由于超出管理层控制范围的技术或系统漏洞，任何给定的控制都有可能不起作用，因此图中的每一行都断言网络安全风险类别中实际发生的事件存在一些不确定的概率。撇开目前对概率的实际估计不谈，重要的是要了解上图足以解释网络安全风险的存在。如果没有就这一事实达成共识，利益相关者就很难认真对待影响估计，因此必须在场景开发参与者之间解决，然后才能继续下一步计算数据泄露可能带来的成本。

参考及来源：https://link.springer.com/book/10.1007/978-1-4842-4194-3

相关阅读：

金融网络安全风险管理指南（一）：威胁分析

金融网络安全风险管理指南（二）：脆弱性分析