摘要
- Nissan 澳大利亚和新西兰的通知称，2023 年 12 月 5 日，一恶意第三方未经授权访问了 Nissan 的本地 IT 服务器，部分客户、员工及其他利益相关者的个人信息被窃取并在暗网上发布。该通知还解释称，Nissan 在事件响应期间使用的呼叫中心供应商 OracleCMS 遭遇了另一起数据泄露，导致为支持受影响人员而提供的摘要信息遭到曝光。
- 该事件之所以重要，是因为汽车数据不仅仅是营销数据。一家区域汽车企业及其金融部门可能持有姓名、联系方式、出生日期、身份证件详情、金融与保险信息、车辆关联信息、服务历史以及利益相关者记录。这些记录将出行、信用、家庭身份、经销商和售后支持连接在一起。
- 最核心的责任问题不在于 Nissan 是否遭受了攻击。犯罪分子对入侵和公开行为负有责任。问题在于谁控制着本地服务器安全、数据最小化、金融数据可及性、响应供应商的选择、客户通知、支持延续性以及可供受影响人员使用的证据。
- OracleCMS 事件改变了事态。它表明，当公司为了呼叫中心能解答问题而向供应商提供浓缩的泄露影响信息时，泄露响应本身可能制造第二个曝露面。原本旨在帮助客户的摘要变成了另一份需要保护的记录。
- 公开证据支持一个高可信度的结论：该事件暴露了区域数据治理的弱点和客户支持风险。但证据并不支持认定 Nissan 的全球生产系统、车辆安全系统或每一个国家子公司都因 2023 年 12 月的澳大利亚和新西兰事件而受到损害。
区域服务器是全球信任承诺的一部分
如果把 Nissan 事件仅仅当作一个与汽车制造商全球业务脱钩的本地小规模泄露，就最容易产生误解。公开事实是区域性的：Nissan 澳大利亚和新西兰的通知指出，受影响事件涉及 Nissan Motor Corporation 和 Nissan Financial Services 在澳大利亚和新西兰使用的本地 IT 服务器。但责任承诺更为广泛。客户在一个全球品牌下购买和融资车辆，与本地经销商打交道，与本国金融和保险业务互动，并期望自己在业务某个环节提供的数据能以整个品牌应有的严肃性得到治理。
Nissan 的公开通知是核心来源。其中提到，2023 年 12 月 5 日，一名恶意第三方未经授权访问了 Nissan 在澳大利亚和新西兰的 IT 服务器；Nissan 采取了措施以遏制泄露；并与全球事件响应团队及网络安全专家合作。通知称，部分客户、员工及其他利益相关者的个人信息被窃取并发布在暗网上。通知还告知受影响人员，由于无法使用现有联系方式联系到某些个人，因此该公开通知对这些人员同样适用。（Nissan 澳大利亚和新西兰网络事件通知）
这种官方措辞很重要，因为它界定了证据边界。该事件不仅仅是犯罪泄露网站上的一个说法。Nissan 公开承认了未经授权的访问、个人信息被窃取以及暗网发布。同时，该通知并未提供完整的取证报告。它没有公布初始访问方法、权限级别、受影响的数据库列表、各系统时间线、受影响的确切人数、按国家划分的损失类别、赎金要求、支付决策或已完成的补救路线图。这些局限应在分析中一并体现。
新南威尔士州政府身份支持 页面提供了另一个公共服务记录。该页面描述到，2023 年 12 月 5 日，一恶意第三方对 Nissan Motor Corporation 和 Nissan Financial Services 在澳大利亚和新西兰的本地 IT 服务器进行了未经授权的访问。（新南威尔士州身份支持 Nissan 数据泄露页面）这个州级支持页面并非对 Nissan 的技术审计。它之所以有用，是因为它表明该事件已进入受影响澳大利亚人所使用的身份支持渠道。
服务器的区域性本质并不会降低记录的敏感性。本地金融客户仍可能拥有难以更换的身份、信用和车辆记录。员工仍可能面临与雇佣相关信息的泄露。与经销商相关的利益相关者仍可能面临诈骗或冒充风险。区域数据系统并不因为不在全球总部就沦为二等系统。
汽车数据是一张关系图谱
汽车数据常被描述为客户信息，但这种说法过于单薄。一个汽车关联可能包括购车咨询、试驾、经销商谈判、服务预约、召回通知、保修索赔、道路救援、金融申请、保险产品、付款历史、投诉处理、置换、企业车队信息和家庭联系方式。区域金融部门可能比制造商的营销数据库掌握更丰富的身份和信用信息。一条服务记录可以将一个人与地点、车辆识别号码、经销商、保养规律和家庭习惯连接起来。
Nissan 澳大利亚的隐私与信用信息页面显示了数据表面的广泛性。该页面涵盖 Nissan Motor Co. Australia、Nissan Financial Services 以及信用报告政策，并说明了在车辆、金融及相关服务中的隐私处理方式。（Nissan 澳大利亚隐私与信用信息政策）金融服务联系页面则展示了围绕现有合同、赔付、投诉和外部争议解决的客户服务与争议解决环境。（Nissan Financial Services 联系页面）这些页面并非事件证据，但它们解释了泄露发生时所处的正常客户关系背景。
Nissan 的通知指出，该通知涵盖的业务包括 Nissan Financial Services、Nissan Insurance、Mitsubishi Motors Financial Services、Skyline Car Finance、Skyline Car Insurance、Renault Financial Services、Renault Insurance 和 Infiniti Financial Services。这是一个关键事实。即便一个人不认为自己是当前的 Nissan 品牌购车者，也可能受到影响。品牌和金融生态系统比车辆上的徽标更为广泛。
这种广度改变了通知的责任。一个简单的『Nissan 客户』标签，可能无法告诉个人 Nissan 为何持有该记录，是哪个业务名称收集的，涉及哪种金融或保险产品，或者该记录是与当前合同、过往合同、员工关系还是利益相关者接触有关。一位曾经的金融客户可能需要不同于当前车辆服务客户的建议。一名员工可能需要就业和身份支持。身份证件涉及的客户可能需要针对证件特定的步骤。
责任要点在于数据最小化和数据血统。Nissan 及其区域业务控制着哪些记录被收集、保留多长时间、存储在哪里、哪些系统可以访问它们、哪些供应商可以接收衍生摘要，以及事件发生后客户如何理解这种关系。受影响人员可以警惕诈骗，但他们无法从外部重建 Nissan 的保留图谱。
二次泄露暴露了响应层
OracleCMS 的泄露是使该事件特别具有启发性之处。Nissan 的通知称，作为事件响应的一部分，Nissan 建立了一个专门的呼叫中心，并将其外包给 OracleCMS。OracleCMS 收到了摘要信息，以帮助回答收到泄露通知信的人员提出的问题。后来，OracleCMS 自身遭遇了一次单独的数据泄露，于 2024 年 4 月 15 日发出警报，OracleCMS 持有的某些数据，包括 Nissan 提供的摘要信息，遭到泄露并在暗网上发布。
新南威尔士州政府独立的 OracleCMS 页面总结了公共服务观点：OracleCMS 报告了一次数据泄露，其中包括在 Nissan 澳大利亚和新西兰网络事件中泄露的信息，这些信息已在暗网上发布。该页面解释称，OracleCMS 是被用于建立 Nissan 泄露呼叫中心的供应商，并持有摘要信息以回答受影响个人的问题。（新南威尔士州身份支持 Nissan OracleCMS 数据泄露页面）
这并非一个脚注。它表明泄露响应会创造新的数据。为了帮助客户，公司可能会为每个人创建一份关于所发生情况的浓缩记录。与原始系统记录相比，这种摘要对呼叫中心坐席来说可能更容易使用。它可能包含人员、联系路径、通知组别、受影响类别、支持代码和响应话术。它很有用，因为它使支持变得切实可行。但它也很危险，因为它以更小、可移植的形式浓缩了泄露的含义。
因此，责任问题不仅仅是『第一个服务器是否受到保护？』它还包括『响应数据集是否受到保护？』公司应当清楚自己向事件响应供应商发送了哪些数据，是如何实现最小化的，保留多长时间，如何加密，谁可以访问，如何监控供应商系统，如何删除事件摘要，以及如果支持供应商后续遭遇泄露，公司将如何通知相关人员。
响应层还可能滋生出一种『滥用联络经济学』。攻击者和诈骗分子看重上下文。一个原始姓名和电子邮件地址可用于普通的网络钓鱼。而一份摘要，如果包含了该人收到了 Nissan 泄露通知信、某些类别已遭泄露、并持有一个支持代码，则可以为更具欺骗性的冒充提供支持。诈骗分子可以伪装成 Nissan、OracleCMS、政府身份支持服务部门、经销商、保险公司或金融机构代表。摘要对支持的有用性，正是它被滥用的原因所在。
这并不意味着将呼叫中心外包本质上是错误的。大规模的泄露可能需要区域办公室单独无法提供的应急能力。责任在于将支持供应商视为事件风险边界的一部分。泄露响应的采购应包括数据最小化规则、安全访问要求、供应商安全审查、保留期限、删除验证、监控、泄露报告义务，以及不要求来电者提供不必要敏感信息的脚本。
公开来源对规模的描述
Nissan 的官方通知以类别而非单一的总人数进行表述。通知称，部分客户、员工及其他利益相关者的个人信息被窃取并发布。SecurityWeek 在 2024 年 3 月报道称，Nissan 大洋洲公司正通知约 10 万名个人，并称该事件是在一次报道归因于 Akira 的勒索软件攻击之后发生的。（SecurityWeek 关于 Nissan 数据泄露的报道）The Record 类似地报道称，澳大利亚和新西兰约有 10 万人受影响，并将该事件置于汽车和金融数据泄露的更广泛历史背景中。（The Record 对 Nissan 澳大利亚和新西兰泄露事件的报道）
这些外部报道是有用的，但必须谨慎处理。官方通知是 Nissan 自身关于未经授权访问、暗网发布、支持安排和 OracleCMS 等声明的更有力证据。声誉良好的网络安全新闻对报道的规模和威胁行为者背景很有价值，但不应被转化为 Nissan 的官方承认，除非该来源引用了基础公司声明或提供了链接。Carsales 也报道称，Nissan 已确认数据遭到访问并被发布在暗网上，并敦促客户更改密码、尽可能启用多因素认证并避免可疑链接。（Carsales 关于 Nissan 本地数据被访问的报道）
公开记录并不允许提供一个完整的国别、类别损失表。然而，它确实支持一个强有力的结论：受影响的人口规模足够大，以至于需要公开的身份支持页面、专门的呼叫中心响应和广泛的媒体报道。当初始服务器访问被遏制时，身份和支持的负担并没有结束。
数据类别也比单一的总数更重要。Nissan 的通知称，人们应参考自己的通知信函，以了解具体哪些个人信息受到影响，并获取访问支持服务的唯一代码。这种设计表明存在个体差异。有些人可能仅涉及基本的联系方式。其他人则可能涉及更敏感的身份、金融或就业相关记录。一篇负责任的文章不应抹平这些差异。
Akira 背景有价值，但归因并非全貌
多份公开报告将 Nissan 大洋洲事件与 Akira 勒索软件关联起来。CISA 关于 Akira 勒索软件的联合咨询将 Akira 描述为一种使用双重勒索方法的勒索软件威胁，涉及数据窃取和加密，并根据执法部门和合作伙伴的报告提供了指标和缓解措施。（CISA 反勒索软件 Akira 咨询）该咨询并非一份 Nissan 的取证报告。它的相关性在于，它描述了公开报道中通常与该事件相关联的威胁模型。
负责任的措辞应有限度。可以说，公开报道将该事件与 Akira 勒索软件联系起来，且 CISA 的 Akira 咨询解释了更广泛的勒索软件模式。但从公开来源声称 CISA 在咨询中独立地将 Nissan 事件归因给 Akira，则是不恰当的，除非咨询本身确实如此。同样，用勒索软件的标签来替代 Nissan 特定的根本原因也是不恰当的。该标签并未告诉读者，在本案例中，初始访问是否涉及 VPN、凭证、未打补丁的软件、远程管理、钓鱼或供应商访问。
CISA 咨询对于控制措施仍然有用。它强调了诸如多因素认证、漏洞修复、网络分段、凭证卫生、监控、备份和事件响应等缓解措施。这些是一般性控制措施，并非表明 Nissan 缺少它们。它们界定了公共问责记录所需的证据：使用了哪条访问路径，哪些控制措施减缓或未能减缓攻击者，哪些数据存储是可及的，哪些系统被加密或数据被窃取，以及 Nissan 在遏制后如何验证环境。
澳大利亚的响应指南指向同一方向。澳大利亚网络安全中心的网络事件响应计划指南鼓励各组织在事件发生前准备好计划、角色、通信和剧本。（ACSC 网络事件响应计划指南）澳大利亚信息专员办公室的指南将组织引向 ACSC 的预防建议，强调了准备、员工意识、多因素认证和实用的安全措施。（OAIC 引用 ACSC 建议的指南）
教训不在于每个组织都能阻止每一个勒索软件行为者。教训在于，一家处理金融和车辆数据的公司应当能够展示哪些预防和响应控制措施到位了，哪些失败了，哪些奏效了，以及哪些发生了变更。勒索软件归因确定了攻击者的责任，但它并不能替代公司的控制证据。
通知成为身份支持工作流
Nissan 的通知指引受影响人员查阅信函中的详情及支持服务。新南威尔士州身份支持部门发布了针对 Nissan 事件和 OracleCMS 事件的页面。IDCARE 的公开数据泄露支持页面描述了其在支持受数据泄露影响的个人和组织方面的作用。（IDCARE 数据泄露支持）Scamwatch 则提供了更广泛的关于识别和避免诈骗的公共指南。（Scamwatch）
这些来源显示了客户受损的实际形态。受影响人员可能需要警惕冒充行为、联系银行或信贷提供方、更改密码、启用多因素认证、监控账户、在适当的时更换身份证件，并对提及该事件的来电或信息保持警惕。但客户并不了解完整的数据图谱。公司必须告知他们足够的信息，使这些措施具有针对性，而非仅仅是泛泛的焦虑。
通知的质量有多个维度。第一，准确性：通知应说明该人涉及了哪些数据类别，而不仅仅是『某些数据』受到影响。第二，完整性：如果后续供应商泄露重新暴露了第一次泄露的摘要，客户应当能够单独理解第二个事件。第三，可用性：支持代码、电话线路和在线资源不应要求个人披露不必要更多的敏感信息。第四，持续性：支持应持续足够长的时间，以覆盖延迟出现的诈骗和身份风险。第五，清晰性：官方渠道必须易于与诈骗渠道区分开来。
OracleCMS 的泄露引发了一个特殊的通知问题。受影响人员可能先收到一封关于 Nissan 事件的信函，随后又获知由于支持供应商遭到泄露，支持摘要也被发布。这可能会让人觉得泄露在重演。一份清晰的通知应将原始数据类别与摘要类别分开，说明是新的原始记录遭到暴露，还是之前暴露的摘要被曝光，并说明个人的风险态势发生了哪些变化。
这正是滥用联络经济学变得具体化的地方。掌握泄露摘要描述的诈骗分子可以使联络显得合理。因此，公司和支持机构应减少在电话或电子邮件脚本中重复敏感细节的程度，就具体的冒充场景向客户发出警告，并避免以训练人们向呼入来电者分享敏感数据的方式要求进行身份验证。
数据主权既是法律和实践问题，而不仅仅是地理问题
该事件也说明了为什么数据主权不仅仅是服务器位置。Nissan 受影响的业务在澳大利亚和新西兰运营；本地通知和新南威尔士州的支持页面将该事件置于澳大利亚和新西兰的客户背景中。但控制者是一个拥有区域子公司、金融产品、保险品牌、经销商和服务提供商的全球汽车集团。法律责任、运营访问和客户期望并不归入单一的国别标签。
Nissan 的全球投资者页面和综合报告材料展示了一个按全球区域、品牌、运营和风险主题组织的集团。（Nissan 业绩、报告和演示）（Nissan 综合报告页面）Nissan 2024 年综合报告传达了集团战略、治理和业务方向，但并未作为澳大利亚和新西兰事件的详细事后分析。（Nissan 2024 年综合报告 PDF）Nissan 新闻室关于综合报告的公告对了解发布背景很有用。（Nissan 综合报告发布）
这些全球材料不应被过度使用。它们并不能证明 2023 年 12 月区域服务器内部发生了什么。但它们确实显示了全球治理为何重要。一位与 Nissan Finance Australia 打交道的客户在泄露期间并不会去阅读全球治理文件。然而，该集团应当有一套针对区域数据清单、供应商监督、事件升级、隐私治理和事件后学习的共同准则。
数据主权在这里至少有四个层面。物理或基础设施所在地涉及数据存放的位置。法律所在地涉及适用哪些隐私、信用、消费者和雇佣规则。运营所在地涉及哪些区域团队和供应商可以访问数据。集团治理则涉及全球公司能否审视、质疑和改进区域业务所使用的控制措施。一个层面的泄露可能在其他层面造成损害。
OracleCMS 事件增加了第五个层面：响应所在地。即便原始 Nissan 记录存放在 Nissan 控制的区域环境中，响应过程却创建了一份由供应商持有的副本或摘要。该响应副本有其自己的所在地、控制措施、保留期限和泄露风险。一个仅绘制原始数据库而忽略响应数据集的数据主权计划是不完整的。
Nissan 控制了什么，又未能控制什么
Nissan 无法控制犯罪分子的入侵、窃取数据或发布数据的决定。这些行为属于攻击者。但 Nissan 确实控制着区域数据环境、保留数据的数量和敏感性、本地 IT 服务器的访问路径、监控、遏制、升级、客户通知、呼叫中心供应商的选择、提供给该供应商的摘要数据、支持持续时间以及公开解释。
OracleCMS 控制着其自身的系统及其所持摘要信息的安全。公共机构控制着身份支持建议、公共警告和监管处理。客户仅能控制收到通知后的防御性行动：警惕诈骗、更改密码、使用支持服务、监控账户以及在必要时更换证件。经销商和金融合作伙伴控制着他们自己的本地客户互动，但无法审计 Nissan 或 OracleCMS 受影响的系统。
这种责任分配很重要，因为在发生泄露后，公司有时会通过『保持警惕』的措辞，无意中将工作转移给受影响人员。『警惕诈骗』是必要的，但不够完整。它应当与公司控制的行动相结合：删除不必要的数据、确保响应供应商的安全、简化证件更换、创建清晰的支持渠道，并准确告知客户适用于他们的数据类别。
同样的原则也适用于内部。区域团队可能拥有日常系统，但全球治理应当掌握数据清单和供应商响应的最低标准。如果区域客户记录包括金融、保险、经销商和员工数据，那么集团应当知道哪些本地环境持有敏感的身份字段，以及哪些供应商可能在响应期间接收摘要。它还应当知道本地团队能多快地隔离系统，而不至于让客户无法获取服务或金融信息。
第二次曝光应改变事件响应剧本
大多数泄露响应剧本包括遏制、取证、法律审查、通知、客户支持和补救。Nissan 的经历则提出了另一个明确的步骤：响应数据风险评估。在组织向呼叫中心、邮递公司、身份支持合作伙伴或法律供应商提供数据集之前，它应将此数据集归类为新的泄露影响记录。摘要可能比原始数据存储更小，但它可能更加敏感，因为它说明了该人遭遇了什么。
响应数据风险评估应提出八个问题。正在传输哪些字段？供应商是否需要所有字段？这些字段在静态和传输中是否加密？哪些坐席可以查看？访问是否被记录？供应商能否导出这些字段？它们何时被删除？如果供应商遭泄露会发生什么？Nissan 的 OracleCMS 经历表明，这些问题并非理论上的。
该评估还应影响脚本设计。呼叫中心员工不应需要复述过多的敏感细节。如果客户询问哪些信息受到了影响，坐席可以引导客户查阅安全通知或基于代码的支持路径。如果涉及身份证件信息，坐席应经过培训，能够解释针对特定证件的支持，而不要求客户在风险渠道上重复完整的证件号码。如果供应商仅持有摘要类别，则它不应能够重建超出必要的信息。
公开记录并不能证明在 OracleCMS 遭泄露之前，Nissan 缺乏这种纪律。但记录确实证明，呼叫中心供应商持有的摘要信息遭到了泄露并发布。这一结果足以使响应数据治理成为一个现时的责任问题。
经销商和金融合作伙伴处于损害边界之内
公开通知聚焦于 Nissan 澳大利亚、Nissan 新西兰以及相关的金融和保险业务，而非逐家经销商的详细运营故障。但这不应让经销商成为盲区。汽车零售是一个分布式信任系统。客户往往首先与经销商互动，然后是金融部门、保险公司、服务部门、呼叫中心和制造商通知。如果泄露影响了金融或保险关系，个人可能不知道哪个实体持有记录，或者哪些一线员工可以回答问题。
经销商无法检查 Nissan 受影响的服务器。金融经纪人或服务顾问也无法知道哪类数据被盗，除非公司提供了准确的指导。然而，这些一线人员可能在中央支持热线之前就收到了客户询问。如果公司没有为他们配备清晰的脚本、转介规则和诈骗警示语，他们就变成了一个证据不完整的非正式支持渠道。这会增加回答不一致的风险，并使诈骗分子更容易利用混乱。
这就是为什么汽车网络中的泄露响应应包含一份经销商和合作伙伴沟通计划。该计划应规定员工可以说些什么，他们绝不能要求客户披露什么，如何引导人们获取官方支持，如何处理愤怒或焦虑的客户，以及如何报告疑似冒充尝试。它还应说明金融、保险、服务或销售记录是否在范围内，因为客户可能会向经销商询问金融记录，即便该经销商并不控制金融系统。
对于经销商网络而言，也有数据最小化的一课。如果制造商或金融部门持有通过经销商收集的记录，它应当清楚哪些源自经销商的数据仍保留在中央系统中，哪些副本仍留在经销商处，以及每份副本保留多长时间。如果客户在经销商处更新了联系方式，中央事件团队应当知道通知地址是否最新。如果无法联系到一位前客户，公司应当能够解释为何仍需保留该数据，以及还有哪些实际支持可用。
同样的逻辑也适用于车队和企业客户。车队联系人可能代表那些详细信息出现在车辆、金融或服务记录中的员工或司机。如果企业客户收到了泄露通知，它可能需要通知内部用户、更新采购记录、就诈骗问题警告司机，并与保险公司协调。Nissan 的公开通知并未提供单独的车队损害表，因此本文无法声称存在特定的车队效应。但可以指出治理责任：与车辆关联的数据往往属于比账户上名列首位的个人更广泛的圈子。
供应商安全不能在信函发出后才临时附加
OracleCMS 事件表明，响应供应商需要与事前技术供应商同等的严肃对待。许多公司在签订重大软件合同前都会进行安全审查，但泄露响应可能造成紧急采购压力。领导们希望呼叫中心尽快上线、信函寄出、身份支持服务接通、客户得到安抚。速度很重要。但如果速度绕过了安全审查，响应就可能在客户最脆弱的时候扩大数据表面。
更好的方法是在任何事件发生前就对响应供应商进行资格预审。组织应当清楚哪些呼叫中心、邮递、法律、取证、身份支持、翻译和通信供应商能够处理泄露数据；每家供应商需要哪些数据；数据可能在哪些国家进行处理；访问如何认证；记录如何删除；以及供应商如何报告其自身的安全事件。这并不能消除所有风险。但它使风险变得审慎可控，而非临时拼凑。
合同应将泄露摘要数据默认视为敏感信息。它应限制后续传输、禁止不必要的本地下载、要求日志记录、要求在明确规定期限后迅速删除，并赋予公司审计和事件通知的权利。如果供应商必须生成自己的记录，这些记录应继承相同的分类。一个支持代码、案件笔记或呼叫结果都可能泄露某人受到了泄露影响，并可能暗示所涉及的数据类型。这种背景信息对犯罪分子具有价值。
对于通过区域子公司运营的全球公司而言，供应商问题尤为重要。区域团队可能会选择具有本地知识和能力的本地供应商，而全球安全部门则设定最低标准。公司应避免两个有害的极端。一个极端是集中式延误，即总部批准每个供应商细节之前，本地响应无法推进。另一个极端是本地临场发挥，即在全球安全部门了解曝光情况之前，敏感泄露数据已被转移给供应商。正确的设计是，由集团标准治理的、预先准备好的区域供应商名册。
公开证据并未确切表明 Nissan 如何选择 OracleCMS 或商定了哪些控制措施。重点不在于从第二次泄露的存在推断出过失。重点在于认识到结构性教训。响应供应商并非置身泄露事外。一旦它收到个性化的泄露支持信息，就成为了泄露系统的一部分，也成为了问责记录的一部分。
指标应区分暴露、通知和支持
Nissan 的记录也表明，为何单一的头条指标是不够的。『受影响人数』只是第一个衡量标准。一份公共问责档案至少应区分四个数字：原始记录被窃取的人数、记录被公开的人数、随后通过 OracleCMS 曝光了泄露支持摘要的人数，以及获得了支持或身份证件援助的人数。这些数字可能重叠，但它们回答的是不同的问题。
暴露指标询问攻击者获得了什么。公开指标询问什么被放在暗网上或以其他方式披露。通知指标询问谁在什么时候可以联系上。支持指标询问谁得到了实际帮助。如果一家公司无法区分这些数字，它可能只知道泄露规模很大，却不清楚响应是否与损害相匹配。
个性化的通知至关重要，但汇总的公开指标也同样重要。客户、监管机构和合作伙伴需要知道，该事件主要涉及联系方式、身份证件、金融记录、员工数据、车辆关联信息还是泄露摘要记录。受影响人员需要针对自己的类别信息，而公众则需要足够的汇总轮廓来判断公司是否在改进正确的控制措施。如果金融数据占很大比重，那么围绕金融系统的访问和保留就应成为核心。如果支持摘要数据后来被发布，那么响应供应商的处理就应成为核心。如果无法联系到的大量前客户是显著问题，那么数据保留和联系方式卫生就应成为核心。
指标还有助于避免表演式的补救。公司可以宣布提升了安全水平，却不展示它是否减少了已发生的特定暴露。有用的指标将显示特权访问的减少、敏感字段的最小化、旧记录的删除、供应商访问审查、响应数据保留期限、客户支持等待时间、通知完成率以及泄露支持数据集的有据可查的删除。公众不需要所有的内部仪表盘，但需要足够的证据来看到补救措施是跟随实际损害而定，而非一个通用的网络安全检查清单。
更优的证据会是什么样
一个更强的公共问责档案将区分以下几个类别。
第一，事件范围证据：涉及哪些区域法律实体和系统，哪些客户群体在范围内，未经授权访问何时开始和结束，以及遏制何时完成。这些可以在高层次上陈述，而不泄露可被利用的技术细节。
第二，数据类别证据：身份字段、联系方式、金融信息、保险信息、车辆与服务关联数据、员工数据以及利益相关者记录应当分开。每位受影响人员应收到与自己相关的类别。
第三，响应供应商证据：公司应说明向呼叫中心供应商提供了哪些数据，为何需要这些数据，何时传输，保留多长时间，以及供应商泄露后发生了哪些变化。
第四，支持证据：公司应披露可用的支持渠道、资格、持续时间、身份证件援助、诈骗警示指南，以及无法联系到的人如何核实自己是否受影响。
第五，补救证据：公司应识别控制改进的类别，如访问加固、日志记录、分段、数据最小化、供应商安全审查、响应数据处理以及剧本变更。它无需发布对攻击者有用的细节，即可让利益相关者相信教训已得到落实。
最后，治理证据：Nissan 全球层面应当能展示一个区域事件如何改变了集团实践。Nissan 的全球投资者记录可能会笼统地讨论治理，但本次事件要求针对区域金融和响应供应商数据得出具体教训。
持久的教训
Nissan 澳大利亚和新西兰的网络事件应载入风险与问责记录，因为它展示了现代汽车企业如何持有超越车辆本身的数据。一台区域服务器可以承载金融和保险关系。一封泄露通知信可以变成一个支持数据集。一个呼叫中心可以成为一个二次曝光点。客户可能被要求管理诈骗和身份风险，却不拥有只有公司才持有的数据图谱。
攻击者对入侵和数据发布负责。OracleCMS 对其作为供应商所持数据的安全负责。Nissan 对其控制范围内的数据环境、响应设计和面向客户的证据负责。公共机构和支持机构帮助了受影响人员，但它们并不运营 Nissan 的系统。
对 Nissan 及类似公司的实际考验是明确的：了解每个区域业务持有哪些客户和利益相关者数据。尽量减少敏感字段和旧记录。将金融和保险数据视为高后果的身份数据。将泄露支持数据集设计为敏感记录，而非行政便利。在危机之前和期间审查响应供应商。为受影响人员提供类别特定的指导。发布足够的补救证据，以表明相同的路径和相同的支持数据暴露将更难以重演。
如今，汽车韧性已纳入了客户数据治理。一家汽车公司可以恢复服务器，却仍让客户陷入多年的身份焦虑。一条支持热线可以回答问题，却仍制造了一份必须加以防护的新记录。因此，Nissan 的案例不仅仅是关于 2023 年 12 月的一次入侵。它关乎这样一种责任：使围绕出行、信用和服务的数据，如同汽车品牌承诺的道路体验一样具有韧性。