让情报成为组织的结构化知识资产

01 · 语义建模与本体工程

当多个团队各自扩展STIX对象时，"同名不同义"会很快摧毁数据的可交换性。语义治理的目标是让每个字段在组织内有唯一、显式、共享的含义。

1.1 三个治理层次

1.2 STIX扩展的纪律

• 先查后用：扩展自定义字段前，先查STIX 2.1标准对象与既有社区扩展（STIX 2.1原生支持Extension机制），重复造轮子会切断与外部工具的互操作。
• 命名空间隔离：组织自定义扩展使用唯一命名空间（如x-organization-前缀），并登记到内部资产目录。
• 向下兼容：扩展字段的增改不破坏既有对象的解析；破坏性变更走版本化迁移。
• 文档即契约：每个扩展字段须有一行语义定义（含义、取值范围、示例），无文档字段视为无效字段。

02 · 知识图谱与实体解析

多源情报的最大浪费是"同一个东西被记了十遍，彼此不知"。实体解析（Entity Resolution）就是把分散记录归并到同一实体的过程，它是知识图谱可用性的生命线。

2.1 构建流水线

2.2 三类核心实体解析规则

score = 0
if sha256(cert_i) == sha256(cert_j):          score += 40  # 同证书：强信号
if registrant_email_i == registrant_email_j:  score += 25  # 同注册邮箱：强信号
if ns_overlap(i, j) >= 2:                     score += 15  # NS重合
if passive_dns_overlap(i, j) >= 0.6:          score += 10  # 解析集合重合
if asn(i) == asn(j) and is_small_asn(asn_i):  score +=  5  # 小众ASN同居
# 纪律：任一弱信号单独不触发合并；
# 总分≥60进"待研判"队列；≥80方生成自动归并候选，仍留人工复核期

2.3 时间版本化的价值

• "当时视图"：复盘某次事件时，可查询"事发当时我们的情报库显示了什么"，避免用今天的知识评判当时的决策——这是审计与培训的关键能力。
• 基础设施生命周期研究：同一IP从"恶意"到"资产复用"的状态变迁带时间戳，支撑第4页复活检测的准确性。
• 归因可信度演化：威胁主体归因结论随证据变化，版本化保留结论演化链。

2.4 图谱存储选型要点

属性图与RDF三元组库是两条主流路线：属性图（以Neo4j为代表）查询直观、工程生态成熟，OpenCTI等情报平台即采用属性图内核；RDF库在跨本体推理与标准化语义互操作上更强，适合已有OWL本体积累的组织。选型判据：STIX"对象—关系"模型能否无损映射、时态查询性能、团队技能栈——避免为技术路线之争牺牲交付进度。

03 · 外部知识库融合

内部情报库不是孤岛——与权威外部知识库对齐，才能回答"这个TTP属于谁""这个漏洞正在被谁利用"。

04 · 数据血缘与审计：每句话都有出处

"这条情报是谁、在什么时间、基于什么证据、以什么置信度给出的"——血缘（Lineage）是情报可信度的基础设施。本课题采用W3C PROV模型（PROV-O，2013年成为W3C推荐标准）作为血缘表达的参考框架：实体（Entity）、活动（Activity）、代理（Agent）三元组足以覆盖"来源→加工→产物"全链。

4.1 血缘最小记录集

{
  "@context": "http://www.w3.org/ns/prov#",
  "id": "dimiao:intel/indicator-8e2e2d2b",
  "type": "Entity",
  "wasGeneratedBy":   { "type": "Activity", "id": "dimiao:act/enrich-2026-09-01" },
  "wasDerivedFrom":   { "type": "Entity",   "id": "dimiao:raw/urlhaus-batch-0901" },
  "wasAttributedTo":  { "type": "Agent",    "id": "dimiao:agent/osint-adapter-07" }
}

05 · 隐私工程：共享中的最小化与去标识化

第3页确立了"共享前四问"，本页给出技术工具箱。核心原则：情报价值与隐私暴露的权衡必须由显式设计决定，而不是默认全给。

5.1 工具箱

5.2 遥测情报的"上下文剥离"标准

从内部遥测提取的IOC（第3页）共享时执行默认剥离：只带走"恶意证据"，不带"受害者画像"。具体规则：

• 保留：IOC值、类型、首次/末次所见时间、命中次数、研判结论；
• 剥离：用户名、主机名、内网IP、组织架构信息、业务系统名称；
• 例外：事件响应协同等确需完整上下文的双边共享，须附TLP:AMBER级别并按协议约定使用范围。

5.3 双轨分级映射示例（TLP × 组织保密制度）

注：上表为示例映射，组织应按自身保密制度细化并版本化维护；双轨并存时一律"最严优先"，映射关系由数据管家（§6.2）负责维护。

5.4 法定与监管留存要求对照

注：条文为公开文本要点转述；法规全文可在国家法律法规数据库（flk.npc.gov.cn）检索核对。

5.5 个人信息删除权对情报库的影响

《个人信息保护法》第四十七条规定了个人信息处理者应当主动删除或依申请删除个人信息的情形。情报库中的间接个人信息（如遥测日志中的用户标识）应建立删除权响应流程：核实请求主体与信息范围→评估情报证据价值与法定留存义务→在主库、备份与衍生数据中同步处置→留存处置记录。实践要点：遥测类情报优先以聚合形式保留（§5.2上下文剥离），从架构上减少删除权触发面；删除权与法定留存义务（如《网络安全法》第二十一条网络日志留存要求）冲突时依就高原则执行并书面记录依据；具体适用以组织法务评估为准。

06 · 情报资产目录与治理角色

6.1 情报资产目录

把情报库当作资产管理：每类情报对象登记责任人、来源清单、更新频率、有效期策略、共享级别、保留期限六个属性，形成可检索的资产目录。目录的价值：①新成员快速理解"库里有什么"；②合规审计时直接回答"我们持有哪些数据、为何持有"；③数据清理有依据（到期数据按目录策略处置而非永久堆积）。工具层面，可采用Apache Atlas等开源数据治理组件承载目录与血缘登记。

6.2 治理角色分工（RACI简化）

注：角色可一人多岗；小团队中数据管家通常由资深分析师兼任，但"审批自己产的共享"这类职责冲突须用双人复核机制对冲。

07 · 治理度量指标

本节参考来源（第6页）

以下均为真实可查的标准、项目或学术来源。