0-CTI 論文閱讀分析：當威脅情報自動化真正卡住時，問題可能不是模型，而是根本還沒有資料可教
論文基本資訊
- 論文標題：Towards a scalable AI-driven framework for data-independent Cyber Threat Intelligence Information Extraction
- 作者：Emanuele Antonioni、Marco Sensi、Matteo Poggiali、Mauro Conti、Mauro Dragoni
- 來源：arXiv
- 年份：2025
- arXiv：https://arxiv.org/abs/2501.06239
- 主題：CTI、Information Extraction、Zero-shot Learning、STIX、Entity Extraction、Relation Extraction、Low-resource NLP
如果最近這幾篇 sectools.tw 一路從 Transparent CTI 的 ontology-driven extraction、AZERG 的 STIX entity / relationship extraction、Instantiating Standards 的 standard-driven TTP extraction，寫到 ThreatPilot 與 Operationalising Cyber Risk Management 這種更下游的 operationalization，你大概會慢慢發現同一個老問題一直沒真正消失：大家都想把 CTI 自動化，但真正高品質、可直接訓練的標註資料其實一直很少。
而這篇 0-CTI 值得接著讀的原因，就在它不是再往下游多補一個 rule generation 或 control mapping，而是回頭正面處理這個更上游、也更現實的瓶頸：如果沒有夠大的標註資料集，CTI information extraction 還能不能做？而且能不能不是只能做一點點 demo，而是做成可擴展、可模組化、還能對齊 STIX 的框架？
本文由 AI 產生、整理與撰寫。
這篇論文想解的，不是「模型夠不夠強」，而是「CTI extraction 為什麼總卡在資料」
CTI extraction 的論文很多，但裡面有一個很常被輕描淡寫帶過的結構性問題：這類任務高度仰賴專家標註，可是專家時間昂貴、資料格式異質、威脅語言變化又快，最後就會形成一個很尷尬的局面——大家都知道自動化有價值，卻常常沒有足夠資料讓它真的長大。
作者要處理的，就是這個 low-resource 現實。論文的核心主張很直接：
CTI IE 不該只在「有資料可訓練」時才成立；真正可落地的框架，必須連在缺資料時也能先動起來。
這個立場很值得寫。因為它把問題從「哪個模型又在某資料集多了幾分」拉回更務實的地方：真實世界很多組織根本沒有自己的大規模標註集，但還是得從 threat report、blog、advisory、incident write-up 裡抽出可用知識。
0-CTI 的核心：同一套框架，同時支援 supervised 與 zero-shot
0-CTI 最有意思的地方，不是它單點模型有多新，而是它把整個問題設計成一個可在不同資料成熟度下切換的模組化框架。作者強調，這套系統同時支援：
- Supervised learning：當你有資料時，可以走較傳統、較穩定的訓練路徑。
- Zero-shot learning：當你沒資料、或資料極少時，也能先啟動 entity / relation extraction。
這個設計的含義其實比表面大很多。它代表作者不是把 zero-shot 當成一個華麗備胎，而是當成 CTI extraction 的第一級 operational mode：先讓系統能在資料稀缺環境下工作，再視情況逐步往 supervised 過渡。
對很多想把 CTI 自動化放進實際流程的團隊來說，這種 framing 很對。因為現實通常不是「一開始就有完整標註資料」，而比較像：
- 先用 dataless / zero-shot 撐起最初版本
- 再從人工修正中逐步累積標註
- 最後才有機會往 supervised pipeline 過渡
換句話說，0-CTI 真正碰到的是 adoption curve，而不只是 model leaderboard。
它做的不是鬆散抽取，而是對齊 cyber ontology 與 STIX
如果只是一般 IE，這篇 paper 其實沒那麼特別；但作者把目標鎖在 cyber ontology of named entities and relationships，而且明確把輸出往 STIX 對齊，這就讓它的位置變得清楚很多。
這點之所以重要，是因為最近不少 CTI 自動化研究都在試圖解同一件事，只是站的位置不同：
- Transparent CTI 在解的是：輸出能不能更可驗證、被 ontology 與 SHACL 接住。
- AZERG 在解的是：threat report 到 STIX entities / relationships 的自動轉換。
- 0-CTI 則是在更前面補一句：如果你連大規模標註都沒有，這條路要怎麼起跑？
也就是說，這篇的價值不在於它把 STIX 做得比 AZERG 更完整，而在於它把 data availability 直接拉進 CTI engineering 討論中心。這很務實，也很接近很多組織真的會撞到的牆。
作者的方法重點：整份 CTI 文本進來，抽 entity 與 relation，再整理成標準化知識
根據摘要，0-CTI 的整體流程可以理解成三層：
- 完整處理 CTI report text sequence，而不是只看零碎句子。
- 抽 named entities 與其 relationships，形成 cyber ontology 結構。
- 將輸出對齊 STIX，讓結果比較接近可交換、可整合的 threat knowledge。
這種設計雖然看起來樸實，但其實打中兩個很常見的痛點。
第一個痛點是：很多資安文本抽取任務只在句子級做實驗，到了真實長報告就容易掉 context。 作者特別強調處理完整文字序列，等於是在說 CTI 任務不能假設所有關鍵線索都剛好落在單句裡。
第二個痛點是：很多抽取結果雖然「看起來有抽到」，但最後沒辦法穩定轉成 threat intelligence system 能吃的格式。 0-CTI 至少從設計上就把 STIX alignment 放進來，避免停在只對論文自己有用的中間 schema。
這篇最值得記住的一句話：它想把 CTI extraction 從 dataset-bound 拉成 data-independent
作者把這套框架的關鍵賣點寫得很清楚：fully dataless operation。這當然不代表完全不需要知識，而是說它不必高度依賴人工標註資料，仍可透過 zero-shot 方法完成 entity 與 relation extraction。
這個方向很重要，因為它等於在挑戰一個 CTI NLP 領域的隱性前提：如果沒有足夠 annotation，很多 extraction system 根本不值得談部署。
0-CTI 的回答則是：至少在框架層，這件事不必非黑即白。你可以：
- 先在零標註或極少標註場景啟動
- 再隨組織資料成熟度升級成 supervised 模式
- 讓同一條 pipeline 在不同資源條件下延續，而不是每次重做一套
對真正想做長期 CTI automation 的團隊來說，這比單次 benchmark 漂亮很多。因為它談的是系統生命週期，而不是只談 paper-time score。
結果怎麼看？重點不是單一分數，而是雙模式都成立
從摘要可知，作者最強調的兩個結果是：
- 在 supervised 模式下，entity extractor 超越既有 state-of-the-art
- 在 zero-shot 模式下，entity 與 relation extraction 也能成立
這組訊息的真正意義，不只是「它兩邊都做了」，而是它同時證明兩件事：
- 當你有資料時，這套框架不是只能湊合用，性能仍有競爭力。
- 當你沒資料時，它也不是完全無法工作，至少還有可啟動的 dataless path。
這很像把 CTI extraction 做成一條比較完整的 maturity ladder。以往很多研究只會在其中一階很亮眼：不是 supervised 很強，就是 zero-shot 很靈活。0-CTI 值得注意的地方，是它嘗試把這兩階接成同一條路。
為什麼這篇剛好接得上 753–757，但又不會撞題？
因為最近那幾篇雖然都繞著 CTI extraction / operationalization 在走，但重點其實各不相同：
- 753 Transparent CTI：強調可驗證、ontology-driven、structured outputs。
- 754 AZERG：強調 threat report → STIX entity / relationship 的四段式抽取。
- 755 Instantiating Standards：強調對齊 ATT&CK / standard，而不是只背資料集。
- 756 ThreatPilot：強調 procedure intelligence 與 downstream Sigma / command generation。
- 757 Operationalising Cyber Risk Management：強調 incident → ATT&CK → controls → metrics 的治理閉環。
而 0-CTI 補的正好是另一個還沒被這串文章正面講透的問題：在那一整條 pipeline 的最前面，如果沒有好資料，整個自動化要怎麼起步？
所以它不是重做 STIX，也不是重做 ATT&CK mapping，而是把 discussion 往更上游拉回 data bottleneck。這個角度我覺得剛好，而且比再補一篇相似的 extraction F1 paper 有意思得多。
它的現實價值：不是每個團隊都養得起專家標註
CTI 自動化裡最容易被忽略的一件事，就是資料成本本身其實也是安全成本。你要做高品質標註，往往需要真的懂攻擊語言、懂 TTP、懂 malware / infrastructure / tooling 關聯的人；而這些人通常正是最稀缺、也最昂貴的那群。
所以 0-CTI 這種 dataless / low-resource 取向的價值，不只是學術上的方便，而是很直接的現實含義：
- 讓小團隊也有可能先做起來
- 讓新場景不必等完整標註集才啟動
- 讓不同資料成熟度的組織可共用同一條技術路線
這其實比很多單純追求最高分的論文更接近 deployment thinking。
當然，這條路也有很明顯的風險
- Zero-shot 的上限通常不會和 domain-specific supervised model 一樣高，尤其在關係抽取這種語意邊界很細的任務上。
- Data-independent 不等於 ontology-independent，schema 設計、標準對齊與 prompt / label semantics 仍然很關鍵。
- 真實 CTI 報告的格式髒亂度很高，包含表格、log、code block、縮寫、樣本雜訊與 vendor-specific language，zero-shot 對這些輸入的穩定性仍值得懷疑。
- 能抽出來，不代表能直接 operationalize，後面仍然有 normalization、deduplication、cross-report resolution 與 analyst validation 等工程債。
但這些風險並不讓這篇失去價值，反而更突顯它真正踩中的點：CTI automation 的困難，不只是模型能力，也包括資料條件本身。
總結
0-CTI 真正值得看的地方，不在於它又做出一個新的 CTI extraction pipeline，而在於它把一個很多人都知道、卻很少正面當主題處理的問題拉到台前：如果沒有足夠標註資料，CTI information extraction 還能不能規模化？
它給出的答案不是浪漫的「LLM 會自己搞定一切」，而是一個更工程化、也更可信的方向：同一套模組化框架，同時支援 supervised 與 zero-shot，讓 CTI extraction 不再只能活在 data-rich 條件下。
如果說最近 sectools.tw 這串文章，一路在把 CTI 自動化從 結構化抽取、標準對齊、procedure operationalization 推到 controls 與 metrics 閉環，那 0-CTI 補上的，就是那條線最前面那個常被忽略、但其實最卡脖子的問題：沒有資料時，第一步怎麼跨出去。
對真正在做 CTI pipeline 的人來說，這篇的價值很直接。它提醒我們，真正成熟的威脅情報自動化，不只要問模型懂不懂，也得問：這套系統是不是能在資料還沒長好之前，就先開始產生價值。