OpenCTI平台中可观测类型显示问题的技术解析

问题背景

在OpenCTI平台的安全运营过程中，Decay规则(衰减规则)是一个重要的功能模块，它允许管理员根据预定义的规则自动调整指标的可信度或重要性随时间的变化。然而，在最新版本中发现了一个影响用户体验的显示问题——在Decay规则界面中，可观测类型(Observable types)没有正确显示翻译后的功能名称，而是直接展示了技术名称。

问题现象

具体表现为两个主要场景：

1. Decay规则概览页面：当用户导航至"设置 > 自定义 > Decay规则"并点击某个规则时，在规则概览中，可观测类型的显示使用了技术名称而非用户友好的功能名称。

2. 规则创建表单：在创建新Decay规则的界面中，类型选择器中的标签同样使用了技术名称而非翻译后的功能名称。

技术分析

这个问题本质上属于国际化(i18n)和本地化(l10n)范畴的显示问题。OpenCTI平台作为一个国际化支持良好的系统，通常会维护两套命名体系：

1. 技术名称：用于系统内部标识和代码引用，通常是英文且保持不变的
2. 功能名称：面向用户的友好名称，会根据用户语言设置显示相应的翻译

从技术实现角度看，这个问题可能源于：

1. 前端组件直接引用了可观测类型的技术名称，而没有通过平台的翻译服务进行转换
2. Decay规则模块可能缺少对可观测类型名称的翻译映射配置
3. 或者是在数据传递过程中，翻译层被意外绕过

对比验证

值得注意的是，同样的可观测类型在CSV订阅源(CSV feeds)界面中显示正常，能够正确展示翻译后的功能名称。这一对比表明：

1. 平台已经具备完整的可观测类型翻译能力
2. 问题特定存在于Decay规则模块的实现中
3. 解决方案可以参考CSV订阅源界面的实现方式

解决方案建议

针对这个问题，开发团队可以采取以下修复措施：

1. 前端修复：确保所有可观测类型的显示都通过平台的翻译服务进行渲染
2. 数据层修复：在API响应中直接包含翻译后的名称，减轻前端负担
3. 统一组件：考虑复用CSV订阅源界面中已经正常工作的显示组件

影响评估

虽然这个问题不会影响系统功能，但会对非技术用户造成一定的理解障碍：

1. 安全分析师可能不熟悉某些可观测类型的技术名称
2. 影响规则配置的准确性和效率
3. 在多语言环境中造成一致性问题

总结

OpenCTI平台中的这个显示问题虽然看似简单，但它反映了国际化支持在复杂系统中的重要性。良好的用户体验不仅需要功能完整，还需要在各个模块间保持一致的展示方式。通过修复这个问题，可以提升平台的整体易用性和专业性，特别是在多语言环境下的表现。