Hướng Dẫn Tra Cứu Hiệu Quả: 3GPP, GSMA PRD, CVE/CWE

Tài liệu đồng hành với “Lộ Trình Toàn Diện…” — tập trung vào KỸ NĂNG ĐỌC/TRA CỨU 3 loại nguồn xuất hiện xuyên suốt roadmap, áp dụng nguyên tắc Top-Down ở Phần 10.4 nhưng ở mức cụ thể hơn: cấu trúc từng hệ thống tài liệu, cách điều hướng, và cách 3 nguồn này LIÊN HỆ với nhau.

Vì Sao Cần Hiểu Cả 3 Nguồn Cùng Lúc

Ba nguồn này không độc lập — chúng tạo thành một “stack” thông tin, mỗi tầng trả lời một câu hỏi khác nhau cho CÙNG một vấn đề kỹ thuật:

┌─────────────────────────────────────────────────────────┐
│ 3GPP (TS/TR)                                              │
│   → "Giao thức/kiến trúc ĐƯỢC ĐỊNH NGHĨA như thế nào?"    │
│   → Định nghĩa KHÔNG GIAN CÁC LỰA CHỌN hợp lệ             │
└───────────────────────┬────────────────────────────────-─┘
                         │ GSMA PROFILE / RESTRICT
                         ▼
┌─────────────────────────────────────────────────────────┐
│ GSMA PRD (FS.xx, IR.xx, NG.xx...)                         │
│   → "Trong không gian lựa chọn đó, NÊN dùng option nào    │
│      để AN TOÀN trên interconnect thực tế?"               │
│   → Thu hẹp + bổ sung khuyến nghị mà 3GPP để "optional"   │
└───────────────────────┬─────────────────────────────────-┘
                         │ IMPLEMENTATION có thể SAI/THIẾU cả 2 tầng trên
                         ▼
┌─────────────────────────────────────────────────────────┐
│ CVE/CWE (NVD, GitHub Security Advisory...)                │
│   → "implementation THỰC TẾ đã làm SAI ở đâu so với       │
│      2 tầng trên — theo PATTERN lỗi nào (CWE)?"           │
└─────────────────────────────────────────────────────────┘

Một finding tốt thường ĐI NGƯỢC chuỗi này: bắt đầu từ CVE/lab (tầng dưới) → tra GSMA xem có khuyến nghị nào đã bị bỏ qua (tầng giữa) → tra 3GPP xem option nào trong spec gốc dẫn đến tình huống này (tầng trên). Đây chính là thứ tự “diff approach” đã nêu ở Phần 10.4 của roadmap, áp dụng cho 3 nguồn cụ thể.

Phần A — 3GPP: Cấu Trúc & Cách Tra Cứu

A.1 — Hệ Thống Series (Số Hiệu 2 Chữ Số Đầu)

Mọi spec 3GPP có dạng XX.YYY — XX là series, quyết định LOẠI nội dung:

Series 25/26/27/34/35/37 (radio 3G, codec, terminal/AT command, conformance testing, multi-RAT) tồn tại nhưng ít liên quan trực tiếp đến hướng signaling-security của roadmap — có thể bỏ qua trừ khi một case cụ thể dẫn tới đó.

A.2 — Số Hiệu & Version: Đọc Đúng “Phiên Bản Nào”

• Format đầy đủ: 3GPP TS 29.272 V17.5.0 — 29.272 là số spec (series 29, spec 272), V17.5.0 là version.
• Version V x.y.z: x = major version, thường tương ứng với số Release (vd V17.x.x ≈ Release 17); y = thay đổi kỹ thuật (technical changes — tăng mỗi khi có Change Request làm thay đổi nội dung); z = thay đổi biên tập (editorial only).
• XX.9YY vs XX.8YY/30.xxx: spec dạng XX.9YY là spec “chính thức” được các Organizational Partner (ETSI…) transpose thành standard của họ — đây là loại spec roadmap đang dùng (29.272, 33.501…). Spec dạng XX.8YY hoặc 30.xxx/50.xxx thường là TR nghiên cứu khả thi (feasibility study) hoặc tài liệu làm việc nội bộ — đọc các TR này hữu ích để hiểu TẠI SAO một thiết kế được chọn (thường có phần “threat analysis” mà spec chính thức không có).

Tip thực tế: khi tìm hiểu một cơ chế security mới (vd SUCI), tìm thêm TR nghiên cứu liên quan (thường cùng series, số 8xx, vd TR 33.8xx cho các study về 5G security) — TR thường giải thích các phương án ĐÃ BỊ LOẠI và lý do, đây là thông tin KHÔNG có trong TS chính thức nhưng cực hữu ích để hiểu threat model.

A.3 — Cấu Trúc Bên Trong Một TS (“Anatomy”)

Pattern chung (áp dụng nguyên tắc Top-Down ở Phần 10.4, cụ thể hóa theo clause):

Clause 1 — Scope                  : phạm vi, đọc lướt 1 lần
Clause 2 — References             : DANH SÁCH spec khác cần đọc cùng — quan trọng,
                                     đây là "bản đồ" cho A.5 (cross-reference)
Clause 3 — Definitions/Abbreviations : tra khi gặp viết tắt lạ, không cần đọc trước
Clause 4+ — Nội dung chính, tùy loại spec:

• Spec dạng protocol (29-series): Clause 4 thường là tổng quan/kiến trúc liên quan; Clause 5 = procedures (sequence diagram — đọc TRƯỚC theo 10.4); Clause 6 = message/AVP/IE definitions (bảng tra cứu — đọc SAU, khi cần); Clause 7+ = error handling; Annex thường chứa state machine hoặc ví dụ message encode đầy đủ — đừng bỏ qua Annex.
• Spec dạng kiến trúc (23-series): Clause 4 = reference architecture (vẽ NF + reference point); Clause 5/6 = procedures theo từng NF; Annex = deployment scenario cụ thể (vd roaming models — tương tự cách NG.113 mô tả Model 1-4 đã thấy ở roadmap 6.8).
• Spec security (33-series): thường tổ chức theo “miền bảo mật” (security domain) — TS 33.501 có Clause 5 = yêu cầu theo domain, Clause 6 = primary authentication (AKA), Clause 9 = security cho SBA (NDS), và Annex chứa công thức key derivation + chi tiết OAuth2 (Annex E) — đây chính là Annex đã dùng ở roadmap 6.8.

A.4 — Change Request (CR): “CVE Của Chính Bản Spec”

CR là cách spec được sửa đổi SAU KHI đã publish. Mỗi CR có category:

Tại sao quan trọng cho security research: tìm CR category A hoặc C cho TS 33.501/29.5xx với từ khóa liên quan (“SEPP”, “N32”, “AKA”…) thường lộ ra lỗ hổng ở MỨC SPEC đã được phát hiện và sửa SAU lần publish ban đầu của Release đó — về bản chất, đây là “CVE cho chính tiêu chuẩn”, chỉ khác là không có ID dạng CVE-YYYY-NNNNN. Tra CR portal qua 3GPP TSG meeting documents, lọc theo spec number.

A.5 — Cross-Reference Navigation & CVD Của 3GPP

• Cross-reference: khi spec A ghi “xem [B] clause X.Y” — đi THẲNG đến clause đó của spec B, không browse toàn bộ B. 3GPP spec được viết với giả định người đọc nhảy qua-lại theo reference, không đọc tuyến tính.
• 3GPP cũng có trang Coordinated Vulnerability Disclosure (CVD) riêng (mục trong navigation chính của 3gpp.org) — đây là kênh dành cho lỗ hổng ở MỨC TIÊU CHUẨN (vd một cơ chế trong TS 33.501 có flaw thiết kế), khác với GSMA CVD (Phần 7.5 roadmap, dành cho lỗ hổng interconnect/operator-level) và GitHub Security Advisory (dành cho implementation cụ thể, Phần C dưới). Ba kênh CVD này nhắm vào 3 TẦNG khác nhau của sơ đồ ở đầu tài liệu — chọn kênh theo TẦNG mà finding thuộc về.

A.6 — Map Nhanh: Spec Đã Dùng Trong Roadmap → Series

Phần B — GSMA PRD: Cấu Trúc & Cách Tra Cứu

GSMA không có một hệ thống số hiệu DUY NHẤT như 3GPP — mỗi working group của GSMA có tiền tố (prefix) riêng cho PRD (Permanent Reference Document) của mình. Hiểu prefix = biết NGAY tài liệu thuộc nhóm nào và nên đọc với “lăng kính” nào.

B.1 — Hệ Thống Prefix PRD

Nguyên tắc đọc theo prefix: FS.xx luôn là góc nhìn “đâu là rủi ro và nên filter/hardening thế nào” — đọc SAU khi đã hiểu giao thức từ 3GPP. IR.xx/NG.xx là góc nhìn “interop” — định nghĩa MINIMUM SET các tính năng 3GPP mà 2 bên phải hỗ trợ để hoạt động cùng nhau, đọc khi cần biết “trong thực tế, operator nào cũng PHẢI hỗ trợ tối thiểu gì”.

B.2 — FASG (FS.xx) Chi Tiết: Pattern Chung & Bổ Sung Cho Roadmap

Một tài liệu FS.xx thường có pattern: mô tả threat/risk (theo từng vector cụ thể) → category/mức độ (đặc biệt FS.11 có category 1/2/3 cho SS7, đã dùng ở roadmap 6.2) → khuyến nghị implementation (filter rule, config cụ thể).

Phát hiện mới đáng chú ý cho roadmap 6.8 (5G SBA/SEPP): FS.34 quy định cụ thể việc PLMN ID phải được gắn với public key certificate cho N32-f traffic — đây là tài liệu CỤ THỂ HƠN cho phần “SEPP filtering theo PLMN ID” mà roadmap 6.8 đã đề cập ở mức nguyên tắc. Khi làm lab SEPP/N32, nên đọc FS.34 SONG SONG với TS 33.501 — FS.34 sẽ chỉ rõ “operator THẬT cấu hình thế nào” cho phần mà TS 33.501 chỉ định nghĩa “CÓ THỂ làm gì”.

B.3 — IR/NG Quan Trọng Khác (Bổ Sung Context)

• IR.21 — “roaming database”: mỗi operator publish thông tin kỹ thuật (địa chỉ signaling point, GT, danh sách dịch vụ hỗ trợ…) để operator khác biết cách kết nối khi roaming. Đây là tài liệu operator nào cũng có và là nguồn OSINT hợp pháp phổ biến nhất trong nghiên cứu interconnect — biết IR.21 tồn tại giúp hiểu tại sao nhiều thông tin “nội bộ” về numbering/routing của operator lại công khai được.
• IR.34 — IPX provider guidelines: định nghĩa Service Community trên IPX (xem B.1, NG.137) — đọc cùng BGP/RPKI (roadmap 6.7) để hiểu IPX vận hành ra sao ở layer routing.
• IR.65/IR.88/IR.92, NG.113/NG.114 — bộ “roaming + service profile” cho IMS/VoLTE (4G) và tương đương cho 5G (VoNR) — hữu ích khi case liên quan Cx/Dx hoặc khi mở rộng lab SIP (6.5) sang ngữ cảnh roaming.

B.4 — Cách Truy Cập

• Công khai: rất nhiều PRD (gồm một số FS.xx, hầu hết IR.xx/NG.xx mới) có thể tải PDF trực tiếp từ gsma.com/newsroom/wp-content/uploads/ hoặc qua trang “Future Networks” / “Networks” resource — không cần membership.
• Infocentre (member-only): catalog ĐẦY ĐỦ, bao gồm phiên bản mới nhất và một số FS.xx nhạy cảm hơn có thể giới hạn truy cập. Nếu một PRD cần không tìm được bản công khai, đây là lý do — không phải tài liệu không tồn tại.
• Tip tra cứu: tìm tên PRD + “GSMA PRD” + số hiệu trên search engine thường ra trực tiếp link PDF từ gsma.com/newsroom cho các bản công khai.

B.5 — GSMA CVD (Cross-Reference Roadmap 7.5)

GSMA CVD là kênh phù hợp khi finding ảnh hưởng đến một KHUYẾN NGHỊ trong PRD (vd: “filter rule trong FS.11 category 2 không đủ để chặn variant mới của SRI4SM”) — khác với finding chỉ ảnh hưởng MỘT implementation cụ thể (→ GitHub Security Advisory, Phần C) hoặc một FLAW trong chính 3GPP spec (→ 3GPP CVD, Phần A.5). Ba kênh CVD (3GPP / GSMA / GitHub-vendor) tương ứng CHÍNH XÁC 3 tầng của sơ đồ ở đầu tài liệu.

Phần C — CVE / NVD / CWE: Cấu Trúc & Cách Khai Thác

C.1 — Anatomy Của Một CVE Record

Format: CVE-YYYY-NNNNN (năm công bố + số thứ tự, số chữ số có thể >4).

Một record hiện đại (CVE schema 5.x) gồm các “container”:

• CNA container — do CNA gốc cung cấp: description, references (link advisory/patch/PoC), affected (sản phẩm + version range), problemTypes (= CWE), và (tùy CNA) metrics (= CVSS do CNA tự chấm).
• ADP container (Authorized Data Publisher) — bên THỨ BA (chủ yếu là NVD) bổ sung THÊM vào record gốc: CVSS (nếu CNA chưa chấm hoặc NVD chấm lại), CPE (Common Platform Enumeration — định danh sản phẩm/version chuẩn hóa để search).

Điểm mấu chốt: CVE record GỐC (CNA container) và phần NVD bổ sung (ADP container) là 2 lớp riêng, xuất bản KHÔNG đồng thời — xem C.3.

C.2 — Cấu Trúc CNA (CVE Numbering Authority) — Cập Nhật

                    CISA  ──┐
                             ├── TL-Root CNA (cấp cao nhất)
                    MITRE ──┘    (ENISA đang được onboard để thành TL-Root thứ 3,
                                   mục tiêu 2026-2027)
                       │
                MITRE = Primary CNA + CNA-LR (CNA of Last Resort
                       — gán CVE khi không CNA nào claim scope)
                       │
        ┌──────────────┼──────────────────┐
   Root CNA theo       Root CNA theo      ... CNA thường (vendor,
   miền (vd CISA       vùng (vd JPCERT/CC     OSS project, CERT...)
   ICS Root cho        cho khu vực Asia-
   industrial/medical) Pacific)
                       │
                  GitHub = CNA

Tại sao quan trọng: GitHub LÀ một CNA. Open5GS, free5GC, FreeDiameter, Osmocom đều host trên GitHub — khi maintainer của các project này xử lý 1 security report, GitHub Security Advisory chính LÀ record CNA gốc, xuất hiện NGAY khi advisory được publish, KHÔNG cần chờ MITRE/NVD đồng bộ. → Với roadmap 7.5 (CVD qua GitHub Security Advisory), advisory đó tự nó ĐÃ LÀ nguồn CNA chính thức, không phải “bước trung gian” trước CVE “thật”.

Lưu ý bối cảnh (tính đến giữa 2026): chương trình CVE/CWE do MITRE vận hành theo hợp đồng với CISA — hợp đồng này đã được gia hạn nhiều lần kể từ 2025 và tình trạng tài trợ dài hạn vẫn đang được thảo luận (một CVE Foundation độc lập đã được thành lập như phương án dự phòng). Điều này KHÔNG thay đổi cách đọc một CVE record, nhưng giải thích lý do nên không phụ thuộc DUY NHẤT vào cve.org/nvd.nist.gov — luôn có phương án dự phòng là advisory trực tiếp từ CNA (GitHub Security Advisory, vendor PSIRT).

C.3 — NVD Enrichment Lag: Tip Thực Tế Cho Phần 7.3 (CVSS)

NVD KHÔNG tạo CVE record — NVD bổ sung CVSS + CPE cho record đã có sẵn từ CNA. Quy trình này có độ trễ, và từ 2024-2025 NVD có backlog đáng kể do thiếu nhân sự — nhiều CVE record ở trạng thái “Awaiting Analysis” (chưa có CVSS/CPE từ NVD) trong thời gian dài, kể cả với CVE đã được CNA publish đầy đủ.

Ý nghĩa cho workflow research (roadmap 7.3/7.5):

1. Khi tra một CVE liên quan Open5GS/free5GC/FreeDiameter và thấy NVD chưa có CVSS — đừng coi là “chưa nghiêm trọng”. Kiểm tra GitHub Security Advisory của repo đó — advisory thường tự có severity rating (và có thể có CVSS riêng do maintainer/GitHub tự động chấm).
2. Nếu CẢ HAI đều thiếu CVSS — đây CHÍNH LÀ tình huống Phần 7.3 mô tả: tự chấm theo metric, dùng calculator first.org, và submit CVSS đó kèm CVD report — việc bổ sung CVSS còn thiếu cũng là một dạng đóng góp được CNA/NVD đánh giá tốt.

C.4 — CWE: Hierarchy, Không Phải Danh Sách Phẳng

CWE tổ chức theo 4 cấp từ trừu tượng → cụ thể: Pillar → Class → Base → Variant. Một CWE-ID cụ thể (vd CWE-787, “Out-of-bounds Write”) nằm trong một “cây” — có parent (pattern rộng hơn, vd liên quan CWE-119 “Improper Restriction of Operations within Bounds of a Memory Buffer”) và có thể có children (variant cụ thể hơn).

Cách khai thác: trên trang cwe.mitre.org của một CWE-ID, mục “Relationships” cho thấy parent/children — đi LÊN để hiểu pattern rộng (hữu ích khi so sánh 2 CVE có vẻ “khác nhau” nhưng cùng root pattern), đi XUỐNG khi cần phân loại CHÍNH XÁC hơn cho report của mình (Phần 7.4). Mục “Related Attack Patterns” link sang CAPEC (Common Attack Pattern Enumeration) — CAPEC mô tả CÁCH một CWE thường bị KHAI THÁC trong thực tế, là input trực tiếp cho bước “exploitability assessment” ở Phần 7.2.3 của roadmap.

C.5 — Search Strategy Cho Research Telecom Security

Phần D — Workflow Thực Tế: Kết Hợp 3 Nguồn Cho Một Topic Mới

Ví dụ cụ thể cho topic 5G SBA/SEPP/N32 (roadmap 6.8) — thứ tự đi qua 3 nguồn:

1. LAB (10.1): dựng Open5GS/free5GC 2-PLMN, capture N32-c/N32-f
   → gặp field/message lạ (vd "PRINS", "apiRoot" trong N32-f)

2. 3GPP (Phần A):
   - TS 29.573 (series 29) — định nghĩa protocol N32, message format
   - TS 33.501 (series 33), Annex E — security requirement + OAuth2
   - Đọc Clause 2 (References) → map sang spec liên quan khác nếu cần
     (vd TS 29.510 cho NRF discovery)

3. GSMA (Phần B):
   - FS.34 — PLMN ID ↔ certificate binding cho N32-f (đào sâu phần
     "SEPP filtering" mà TS 33.501 chỉ định nghĩa ở mức khả năng)
   - FS.36 — bức tranh tổng 5G interconnect security
   - NG.113 — roaming model (Model 1-4) cho business context

4. CR check (A.4):
   - Search CR cho TS 33.501 + "N32"/"SEPP", category A hoặc C
   - CR sửa lỗi liên quan (nếu có) = "lịch sử lỗ hổng cấp spec"

5. CVE/Implementation (Phần C):
   - GitHub Security Advisory cho free5GC/Open5GS — search "SEPP"/"N32"
   - Nếu có CVE → tra CWE (C.4) → so sánh pattern với CR ở bước 4
     (lỗi implementation hay lỗi spec đã biết?)

6. Document (10.5): finding nằm ở TẦNG nào trong sơ đồ đầu tài liệu
   (spec / khuyến nghị GSMA / implementation)?
   → quyết định kênh CVD phù hợp (A.5 / B.5 / GitHub)

Bước 6 là điểm mấu chốt: cùng MỘT hiện tượng (vd “SEPP chấp nhận N32-f traffic sai PLMN”) có thể thuộc 3 tầng khác nhau — (a) implementation bug nếu spec + FS.34 đã nói rõ nhưng code không check → GitHub Advisory; (b) gap trong FS.34 nếu khuyến nghị hiện tại chưa đủ chặt → GSMA CVD; (c) flaw trong chính TS 33.501 nếu cơ chế PRINS có vấn đề thiết kế → 3GPP CVD. PHÂN LOẠI đúng tầng quyết định kênh báo cáo — đây là bước hay bị bỏ qua nhất khi mới viết CVD đầu tiên.

Bảng Tổng Hợp: Entry Point Cho Mỗi Nguồn

Lời Kết

Ba nguồn — và các kênh CVD/advisory tương ứng (3GPP CVD, GSMA CVD, GitHub Security Advisory/vendor PSIRT, CR portal, NVD) — không phải các thứ tách biệt cần học riêng, mà là MỘT sơ đồ duy nhất (đầu tài liệu) nhìn từ 3 góc. Áp dụng đúng vòng lặp Setup→Baseline→Break→Analyze→Document (Phần 10.3 của roadmap) cho một topic mới, đi qua 3 nguồn theo thứ tự ở Phần D, sẽ tự nhiên hình thành thói quen “định vị finding đúng tầng” TRƯỚC khi viết report — bước hay bị bỏ qua nhất khi mới bắt đầu CVD.