updated 02102025
@ -0,0 +1,542 @@
|
|||||||
|
#cyber_security #machine_learning
|
||||||
|
# Phân Loại Lỗ Hổng Tự Động
|
||||||
|
|
||||||
|
## Giới Thiệu
|
||||||
|
|
||||||
|
Trong bối cảnh hiện nay, việc quản lý lỗ hổng bảo mật đang trở nên ngày càng phức tạp do khối lượng lớn các CVE (Common Vulnerabilities and Exposures) được công bố hàng ngày. Các tổ chức thường phải đối mặt với thách thức trong việc ưu tiên và xử lý các lỗ hổng này một cách hiệu quả, bởi vì không phải tất cả các lỗ hổng đều có mức độ nguy hiểm và ảnh hưởng như nhau. Việc xác định lỗ hổng nào cần được vá trước, lỗ hổng nào có thể tạm thời trì hoãn, đòi hỏi sự phân tích kỹ lưỡng và nhanh chóng từ các đội ngũ bảo mật.
|
||||||
|
|
||||||
|
Để giải quyết vấn đề này, dự án đề xuất một pipeline end-to-end tự động, bắt đầu từ việc pipeline sử dụng dữ liệu **mockup mô phỏng** scanner (Nessus/OpenVAS/Qualys), NVD, ExploitDB và vendor patch. Dữ liệu thu thập được sẽ được enrich với ngữ cảnh về tài sản (asset context) như hệ điều hành, phần mềm đang sử dụng và mức độ quan trọng của tài sản đó trong hệ thống. Tiếp theo, pipeline sử dụng kết hợp các mô hình học máy cùng với các quy tắc (rule-based) để phân loại và ưu tiên lỗ hổng một cách chính xác. Đặc biệt, hệ thống cung cấp khả năng giải thích mô hình thông qua SHAP (SHapley Additive exPlanations), giúp người dùng hiểu rõ nguyên nhân và cơ sở của các quyết định phân loại. Cuối cùng, kết quả được tích hợp trực tiếp vào nền tảng Splunk, hỗ trợ hiển thị và quản lý dễ dàng trong các bảng điều khiển.
|
||||||
|
|
||||||
|
Động lực thực hiện dự án xuất phát từ nhu cầu giảm tải cho các SOC analyst, giúp họ không còn phải xử lý thủ công khối lượng lớn thông tin lỗ hổng mà có thể tập trung vào các lỗ hổng quan trọng nhất. Việc tự động hóa và minh bạch trong quá trình triage lỗ hổng sẽ tăng tốc độ phản ứng, nâng cao hiệu quả bảo mật tổng thể, đồng thời hỗ trợ quyết định patch hoặc mitigate nhanh chóng và chính xác hơn, góp phần bảo vệ hệ thống và dữ liệu của tổ chức một cách tốt nhất.
|
||||||
|
|
||||||
|
[Github Repo](https://github.com/cyberp01/autonomous_vulnerability_triage)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Mục Tiêu Dự Án
|
||||||
|
|
||||||
|
### Bối Cảnh Bài Toán
|
||||||
|
Trong môi trường an ninh mạng ngày càng phức tạp, các tổ chức phải xử lý hàng ngàn lỗ hổng mới phát sinh mỗi ngày. Việc phân loại và ưu tiên các lỗ hổng này thủ công không chỉ tốn thời gian mà còn dễ dẫn đến sai sót, làm giảm hiệu quả phản ứng bảo mật. Do đó, cần một giải pháp tự động hóa, chính xác và minh bạch để hỗ trợ các chuyên gia bảo mật trong việc triage lỗ hổng.
|
||||||
|
|
||||||
|
### Mục Tiêu Nghiệp Vụ
|
||||||
|
- **Giảm tải công việc thủ công:** Giúp các SOC analyst và đội ngũ bảo mật giảm bớt khối lượng công việc xử lý lỗ hổng.
|
||||||
|
- **Tăng tốc độ phản ứng:** Rút ngắn thời gian từ khi lỗ hổng được phát hiện đến khi được xử lý hoặc ưu tiên.
|
||||||
|
- **Minh bạch trong quyết định:** Cung cấp giải thích rõ ràng cho các phân loại và ưu tiên, tạo sự tin tưởng và dễ dàng kiểm tra lại.
|
||||||
|
|
||||||
|
### Mục Tiêu Kỹ Thuật
|
||||||
|
- **Sinh dữ liệu mockup mô phỏng ingest từ nhiều nguồn (scanner, NVD, ExploitDB, vendor patch, asset CMDB).**
|
||||||
|
- **Feature Engineering nâng cao:** Trích xuất đặc trưng quan trọng từ dữ liệu thô, bao gồm ngữ cảnh tài sản và thông tin môi trường.
|
||||||
|
- **Mô hình học máy kết hợp rule-based:** Áp dụng các thuật toán ML cùng với các quy tắc chuyên môn để phân loại chính xác các lỗ hổng.
|
||||||
|
- **Explainability:** Sử dụng SHAP để giải thích các quyết định của mô hình, giúp người dùng hiểu rõ hơn về nguyên nhân phân loại.
|
||||||
|
- **Tích hợp với Splunk:** Đưa kết quả trực tiếp vào Splunk để hỗ trợ quản lý và hiển thị thông tin hiệu quả.
|
||||||
|
|
||||||
|
### Phạm Vi và Ngoài Phạm Vi
|
||||||
|
- **Phạm vi:** Tự động phân loại và ưu tiên lỗ hổng bảo mật dựa trên dữ liệu thu thập được, tích hợp giải thích và hiển thị trong Splunk.
|
||||||
|
- **Ngoài phạm vi:** Tự động vá lỗi, phân tích sâu về exploit hoặc tấn công, và các hoạt động phản ứng sự cố nâng cao.
|
||||||
|
|
||||||
|
### KPIs Mong Đợi
|
||||||
|
- Tăng ít nhất 50% tốc độ xử lý lỗ hổng so với phương pháp thủ công.
|
||||||
|
- Đạt độ chính xác phân loại trên 85% theo đánh giá chuyên gia.
|
||||||
|
- Giảm thiểu sai sót trong việc ưu tiên lỗ hổng xuống dưới 10%.
|
||||||
|
- Mức độ hài lòng của người dùng với giải thích mô hình trên 4/5.
|
||||||
|
|
||||||
|
### Rủi Ro và Cách Giảm Thiểu
|
||||||
|
- **Dữ liệu đầu vào không đầy đủ hoặc sai lệch:** Thiết lập quy trình kiểm tra và làm sạch dữ liệu trước khi xử lý.
|
||||||
|
- **Mô hình không chính xác hoặc thiên lệch:** Kết hợp rule-based để kiểm soát và điều chỉnh, cập nhật mô hình định kỳ.
|
||||||
|
- **Khó hiểu giải thích mô hình:** Đào tạo người dùng và cải tiến giao diện hiển thị giải thích.
|
||||||
|
- **Vấn đề bảo mật dữ liệu:** Áp dụng các biện pháp mã hóa, kiểm soát truy cập và tuân thủ chính sách bảo mật.
|
||||||
|
|
||||||
|
### Deliverables
|
||||||
|
- Pipeline sinh dữ liệu mockup và xử lý.
|
||||||
|
- Mô hình học máy và rule-based phân loại.
|
||||||
|
- Module giải thích mô hình bằng SHAP.
|
||||||
|
- Kết quả xuất ra Splunk (lookup/demo dashboard).
|
||||||
|
- Tài liệu & UI Gradio demo.
|
||||||
|
|
||||||
|
### Cột Mốc
|
||||||
|
- Hoàn thiện thu thập và làm sạch dữ liệu.
|
||||||
|
- Xây dựng và huấn luyện mô hình.
|
||||||
|
- Phát triển module giải thích và tích hợp Splunk.
|
||||||
|
- Kiểm thử và đánh giá hiệu năng.
|
||||||
|
- Triển khai và đào tạo người dùng.
|
||||||
|
|
||||||
|
### Human-in-the-Loop
|
||||||
|
Phiên bản hiện tại **chưa implement** Human-in-the-Loop. Mới dừng ở bước cung cấp explainability và xuất dữ liệu ra Splunk để analyst review. Phiên bản sau sẽ bổ sung.
|
||||||
|
|
||||||
|
### Bảo Mật Dữ Liệu
|
||||||
|
Toàn bộ dữ liệu nhạy cảm được xử lý tuân thủ các quy định bảo mật, sử dụng mã hóa khi lưu trữ và truyền tải, đồng thời kiểm soát quyền truy cập nghiêm ngặt để đảm bảo an toàn thông tin trong toàn bộ pipeline.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Tổng Quan Kiến Trúc
|
||||||
|
|
||||||
|
Pipeline phân loại lỗ hổng tự động được thiết kế theo kiến trúc module hóa, giúp quản lý và phát triển dễ dàng, đồng thời đảm bảo tính mở rộng và khả năng bảo trì cao. Dưới đây là mô tả tổng quan các thành phần chính và luồng dữ liệu trong hệ thống.
|
||||||
|
|
||||||
|
### Các Thành Phần Chính
|
||||||
|
|
||||||
|
- **1. Data Generation (Tạo Dữ Liệu):**
|
||||||
|
Thu thập dữ liệu đầu vào từ nhiều nguồn bao gồm dữ liệu giả lập (mockup) scanner như Nessus/OpenVAS/Qualys, dữ liệu từ NVD, ExploitDB, vendor patch và thông tin tài sản (CMDB). Mục tiêu là tổng hợp dữ liệu thô đa dạng, phong phú và có ngữ cảnh để làm nền tảng cho các bước tiếp theo.
|
||||||
|
|
||||||
|
- **2. Feature Engineering (Trích Xuất Đặc Trưng):**
|
||||||
|
Xử lý và chuyển đổi dữ liệu thô thành các đặc trưng có ý nghĩa cho mô hình học máy. Bao gồm việc làm sạch dữ liệu, chuẩn hóa, mã hóa các thuộc tính, kết hợp thông tin ngữ cảnh tài sản (hệ điều hành, phần mềm, mức độ quan trọng) và các biến số đặc trưng khác.
|
||||||
|
|
||||||
|
- **3. Model Training (Huấn Luyện Mô Hình):**
|
||||||
|
Sử dụng các thuật toán học máy kết hợp với các quy tắc chuyên môn (rule-based) để xây dựng mô hình phân loại và ưu tiên lỗ hổng. Mô hình được huấn luyện trên dữ liệu đã được trích xuất đặc trưng, đảm bảo độ chính xác và khả năng tổng quát hóa cao.
|
||||||
|
|
||||||
|
- **4. Explainability (Giải Thích Mô Hình):**
|
||||||
|
Áp dụng phương pháp SHAP (SHapley Additive exPlanations) để giải thích các quyết định của mô hình. Giúp người dùng hiểu rõ nguyên nhân, các đặc trưng ảnh hưởng đến kết quả phân loại, tăng tính minh bạch và tin cậy của hệ thống.
|
||||||
|
|
||||||
|
- **5. Splunk Integration (Tích Hợp Với Splunk):**
|
||||||
|
Kết quả phân loại và giải thích được xuất ra dưới dạng lookup hoặc dashboard trong Splunk. Hỗ trợ hiển thị trực quan, quản lý và theo dõi lỗ hổng dễ dàng cho các SOC analyst và đội ngũ bảo mật.
|
||||||
|
|
||||||
|
### Luồng Dữ Liệu Tổng Quan
|
||||||
|
|
||||||
|
Dữ liệu đầu vào từ các nguồn mockup scanner, NVD, ExploitDB, vendor patch và CMDB sẽ được tập hợp và làm sạch trong bước Data Generation. Sau đó, dữ liệu thô này được chuyển sang bước Feature Engineering để trích xuất và chuẩn hóa các đặc trưng quan trọng. Các đặc trưng này được đưa vào mô hình học máy kết hợp rule-based để phân loại và ưu tiên lỗ hổng. Kết quả phân loại cùng với giải thích chi tiết từ SHAP sẽ được gửi tới Splunk để hiển thị và quản lý.
|
||||||
|
|
||||||
|
![[Pasted image 20251002150719.png]]
|
||||||
|
### Mô Tả Sơ Đồ Pipeline
|
||||||
|
|
||||||
|
- **Input Mock Data & External Sources:** Dữ liệu đầu vào đa dạng từ scanner giả lập và các nguồn dữ liệu công khai.
|
||||||
|
- **Data Generation:** Thu thập, tổng hợp và làm sạch dữ liệu thô.
|
||||||
|
- **Feature Engineering:** Chuẩn hóa và trích xuất đặc trưng quan trọng cho mô hình.
|
||||||
|
- **Model Training:** Huấn luyện mô hình kết hợp rule-based để phân loại lỗ hổng.
|
||||||
|
- **Explainability (SHAP):** Giải thích kết quả mô hình giúp người dùng hiểu quyết định phân loại.
|
||||||
|
- **Splunk Integration:** Xuất kết quả và giải thích lên Splunk để hiển thị và quản lý.
|
||||||
|
- **SOC Analyst & Security Team:** Người dùng cuối sử dụng kết quả để ra quyết định xử lý lỗ hổng.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Các Bước Trong Pipeline
|
||||||
|
|
||||||
|
### Bước 1: Tạo Dữ Liệu
|
||||||
|
|
||||||
|
Bước đầu tiên trong pipeline là sinh dữ liệu mockup mô phỏng môi trường thực tế, giúp kiểm thử toàn bộ quy trình xử lý và huấn luyện mô hình phân loại lỗ hổng. Việc này được thực hiện chi tiết trong file `1_gen_vuln_mock_enriched.py` với các đặc điểm nổi bật sau:
|
||||||
|
|
||||||
|
#### 1. Sinh Dữ Liệu Mockup Theo PoC Plan
|
||||||
|
- **Quy mô dữ liệu:** Sinh ra khoảng **50.000 bản ghi findings** (vulnerability findings), **5.000 CVE** (unique), và **1.000 assets** (tài sản).
|
||||||
|
- **Đa dạng nguồn enrichment:** Dữ liệu được tổng hợp và enrich từ nhiều nguồn mô phỏng như NVD (National Vulnerability Database), ExploitDB, Vendor Patch, và CMDB (asset inventory).
|
||||||
|
|
||||||
|
#### 2. Ẩn Danh Thông Tin Nhạy Cảm (Anonymization)
|
||||||
|
- Để đảm bảo an toàn dữ liệu mô phỏng, các trường như **IP**, **hostname**, **owner** đều được ẩn danh hóa bằng **HMAC-SHA256 kết hợp SALT** (`MOCK_SALT`). Việc này giúp đảm bảo không lộ thông tin thật, đồng thời giữ được tính nhất quán khi join dữ liệu giữa các bảng.
|
||||||
|
|
||||||
|
#### 3. Các File Output Sinh Ra
|
||||||
|
- `assets.csv`: Thông tin asset dạng CMDB (asset_id, ip, hostname, owner, environment, asset_criticality, internet_exposed, last_patch_date, os, network_zone, business_service).
|
||||||
|
- `nvd_enriched.csv`: Danh sách CVE với các trường enrich như CVSS v3/v2, EPSS, KEV, ngày công bố và cập nhật.
|
||||||
|
- `exploitdb_enriched.csv`: Mapping CVE → exploit (tỷ lệ khoảng 8% CVE có exploit), kèm ngày exploit, nguồn exploit.
|
||||||
|
- `vendor_patch_enriched.csv`: Trạng thái patch/mã vendor cho từng CVE, ngày cập nhật.
|
||||||
|
- `nessus_enriched.csv`: Khoảng 50.000 findings đã enrich đầy đủ thông tin asset, CVE, trạng thái, điểm số, v.v.
|
||||||
|
- `_metadata.json`: Metadata về quá trình sinh dữ liệu, seed, số lượng asset/CVE/findings, và các cảnh báo validation.
|
||||||
|
|
||||||
|
| File/Dataset | Ý nghĩa trong PoC | Vai trò trong ML Triage và Rule Based | Nguồn tương ứng ngoài thực tế |
|
||||||
|
|----------------------------|-------------------------------|-------------------------------------------------|------------------------------------------|
|
||||||
|
| `assets.csv` (CMDB-like) | Danh sách asset (máy chủ, service, ứng dụng) | Cung cấp context để đánh giá rủi ro: asset_criticality, internet_exposed, zone ảnh hưởng trực tiếp tới priority_score. Dùng để enrich CVE findings → triage theo risk thực tế (ví dụ: CVE trên asset prod, internet-facing nguy hiểm hơn). | CMDB (Configuration Management Database): ServiceNow CMDB, AWS Config, Qualys Asset Inventory, Tanium, v.v. |
|
||||||
|
| `nessus_enriched.csv` | Kết quả quét lỗ hổng gắn với asset và CVE | Dataset chính để huấn luyện ML model. Priority_score là synthetic label (ground truth giả lập) để train supervised model. incident_happened là proxy binary label để kiểm thử classification. | Scanner output: Tenable Nessus, Greenbone OpenVAS, Qualys VMDR. Trong thực tế sẽ mapping findings ↔ CMDB ↔ NVD ↔ TI. |
|
||||||
|
| `nvd_enriched.csv` | Thông tin chuẩn hóa về CVE | Là nguồn gốc baseline severity (CVSS), input quan trọng cho cả rule-based (CVSS cutoff) và ML features (continuous). EPSS & KEV flag bổ sung chỉ báo threat intel chính thống. | NVD (National Vulnerability Database), FIRST EPSS, CISA KEV Catalog |
|
||||||
|
| `exploitdb_enriched.csv` | Ghi nhận CVE có PoC exploit công khai hay không | Là feature trọng yếu để phân biệt CVE “có thể bị khai thác” vs chỉ lý thuyết. Feature này giúp tăng explainability (SHAP cho thấy exploit_exists tăng priority). | ExploitDB, Metasploit Framework, GitHub public PoC repos |
|
||||||
|
| `vendor_patch_enriched.csv`| Trạng thái xử lý CVE từ vendor | Cho phép mô hình kết hợp patch cycle vào triage. Rule-based: CVE unpatched + critical asset thường ưu tiên cao. ML: vendor_status là feature categorical. | Vendor advisories / security bulletins: Microsoft MSRC, Oracle CPU, RedHat advisories, Cisco PSIRT, v.v. |
|
||||||
|
|
||||||
|
#### 4. Quy Tắc Sinh Dữ Liệu & Phân Phối
|
||||||
|
- **CVE IDs:** Sinh 5.000 mã CVE duy nhất dạng CVE-YYYY-NNNNN, phân bổ năm từ 2015–2024.
|
||||||
|
- **CVSS v3:** Điểm nguy cơ CVSS v3 được sinh từ phân phối **Beta (skewed right)** để mô phỏng thực tế nhiều CVE điểm thấp, ít CVE điểm cao. Giá trị được clip trong khoảng 0.1–10.
|
||||||
|
- **Exploit Exists:** Với mỗi CVE, trường exploit_exists được gán theo phân phối **Bernoulli p=0.08** (8% có exploit công khai).
|
||||||
|
- **Asset Criticality:** Mức độ quan trọng asset (1–5) sinh theo phân phối có trọng số: `[0.4, 0.25, 0.2, 0.1, 0.05]` (phần lớn asset có criticality thấp).
|
||||||
|
- **Internet Exposed:** Tài sản có exposed ra internet với xác suất **12%** (Bernoulli p=0.12).
|
||||||
|
- **Patch Date:** Ngày last_patch/patch_date được sinh từ phân phối **exponential** với mean=60 ngày, đảm bảo không vượt quá ngày hiện tại.
|
||||||
|
- **External TI Score:** Điểm threat intelligence ngoài tính theo công thức: `exploit_exists*80 + int(log(ref_count+1)*10)` với ref_count ~ Poisson(1).
|
||||||
|
- **Priority Score:** Điểm ưu tiên tổng hợp (label) tính theo công thức:
|
||||||
|
```
|
||||||
|
priority_score = 0.4*cvss_v3*10 + 0.25*external_ti_score + 0.2*asset_criticality*10 + exploit_exists*20 + noise
|
||||||
|
```
|
||||||
|
Trong đó, noise là giá trị ngẫu nhiên [-5, 5]. Giá trị priority_score được clip trong khoảng 0–100.
|
||||||
|
|
||||||
|
#### 5. Validation & Kiểm Tra Chất Lượng Dữ Liệu
|
||||||
|
- **Kiểm tra số lượng CVE:** Đảm bảo đúng số lượng 5.000 CVE sinh ra.
|
||||||
|
- **Kiểm tra ngày tháng:** Tất cả các trường ngày (publish_date, patch_date, exploit_date, scan_date, v.v.) đều đảm bảo không vượt quá thời điểm hiện tại.
|
||||||
|
- **Kiểm tra phạm vi giá trị:** Giá trị CVSS nằm trong [0, 10], EPSS trong [0, 1], priority_score trong [0, 100].
|
||||||
|
- **Cảnh báo validation:** Nếu phát hiện bất kỳ giá trị nào vượt phạm vi hoặc bất thường, thông tin cảnh báo sẽ được ghi vào `_metadata.json` để tiện kiểm tra lại.
|
||||||
|
|
||||||
|
#### 6. Output Metadata
|
||||||
|
- File `_metadata.json` chứa các thông tin sau:
|
||||||
|
- Seed sinh dữ liệu (đảm bảo reproducibility).
|
||||||
|
- Số lượng asset, CVE, findings đã sinh.
|
||||||
|
- Thời gian sinh dữ liệu.
|
||||||
|
- Các cảnh báo validation nếu có.
|
||||||
|
|
||||||
|
![[Pasted image 20251002151131.png]]
|
||||||
|
![[Pasted image 20251002151154.png]]
|
||||||
|
![[Pasted image 20251002151212.png]]
|
||||||
|
![[Pasted image 20251002151229.png]]
|
||||||
|
![[Pasted image 20251002151244.png]]
|
||||||
|
|
||||||
|
>**Tóm Lại:** Bước 1 đảm bảo pipeline có một bộ dữ liệu mô phỏng lớn, đầy đủ ngữ cảnh, đa chiều và đã được kiểm tra chất lượng, phù hợp cho các bước feature engineering, huấn luyện mô hình và kiểm thử end-to-end.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Bước 2: Kỹ Thuật Trích Xuất Đặc Trưng
|
||||||
|
|
||||||
|
Bước 2 trong pipeline thực hiện việc trích xuất, chuẩn hóa và biến đổi dữ liệu đầu vào thành các đặc trưng (features) phù hợp để huấn luyện mô hình học máy. Toàn bộ quy trình này được cài đặt trong file `2_feature_engineering.py` với các bước chi tiết như sau:
|
||||||
|
|
||||||
|
#### 1. Đầu Vào: Các File Output Từ Bước 1
|
||||||
|
Các file dữ liệu đầu vào bao gồm:
|
||||||
|
- `assets.csv`: Thông tin tài sản (asset) từ CMDB.
|
||||||
|
- `nvd_enriched.csv`: Dữ liệu CVE đã enrich từ NVD.
|
||||||
|
- `exploitdb_enriched.csv`: Thông tin exploit liên quan đến CVE.
|
||||||
|
- `vendor_patch_enriched.csv`: Trạng thái patch của vendor cho từng CVE.
|
||||||
|
- `nessus_enriched.csv`: Danh sách findings đã enrich, làm nền tảng chính cho feature engineering.
|
||||||
|
- `_metadata.json`: Metadata về quá trình sinh dữ liệu, dùng để kiểm tra tính nhất quán.
|
||||||
|
|
||||||
|
#### 2. Validation: Kiểm Tra Dữ Liệu Đầu Vào
|
||||||
|
Trước khi xử lý, script thực hiện kiểm tra chất lượng dữ liệu:
|
||||||
|
- **Kiểm tra schema:** Đảm bảo mỗi file có đủ các cột cần thiết, không bị thiếu trường quan trọng.
|
||||||
|
- **Kiểm tra ngày tháng:** Xác thực các cột ngày tháng (publish_date, patch_date, scan_date, v.v.) đúng định dạng và không vượt quá thời điểm hiện tại.
|
||||||
|
- **Kiểm tra phạm vi giá trị:** Đảm bảo các trường số như CVSS, EPSS, priority_score, asset_criticality… nằm trong phạm vi hợp lệ.
|
||||||
|
- **Ghi log và cảnh báo:** Các lỗi hoặc cảnh báo được ghi lại để tiện kiểm tra, đảm bảo dữ liệu đầu vào sạch và đáng tin cậy.
|
||||||
|
|
||||||
|
#### 3. Gộp Dữ Liệu (Merge Datasets)
|
||||||
|
Dữ liệu từ các nguồn khác nhau được gộp (merge) lại để tạo bảng tổng hợp đầy đủ ngữ cảnh cho từng finding:
|
||||||
|
- **Gộp theo asset_id và cve_id:** Sử dụng nessus_enriched làm bảng chính, lần lượt merge thông tin từ assets, nvd, exploitdb, vendor.
|
||||||
|
- **Kiểm tra missing:** Ghi nhận nếu có bản ghi bị thiếu thông tin sau khi merge (ví dụ: không tìm thấy asset hoặc CVE tương ứng).
|
||||||
|
- **Kết quả:** Một bảng findings enriched, mỗi dòng là một finding đầy đủ ngữ cảnh asset, CVE, exploit, patch, v.v.
|
||||||
|
|
||||||
|
#### 4. Feature Engineering: Tạo Các Đặc Trưng Phái Sinh
|
||||||
|
Từ bảng tổng hợp, script tạo thêm nhiều cột đặc trưng (derived features) giúp mô hình học tốt hơn:
|
||||||
|
|
||||||
|
| Tên đặc trưng | Mô tả | Công thức / Cách tính | Vai trò trong ML Triage & Rule-based |
|
||||||
|
|---|---|---|---|
|
||||||
|
| `days_since_publish` | Số ngày kể từ khi CVE được công bố | `now - publish_date` | Đo tuổi đời CVE, CVE càng lâu nhưng chưa vá → rủi ro tồn đọng. |
|
||||||
|
| `days_since_last_modified` | Số ngày từ lần cập nhật cuối của CVE | `now - last_modified` | Giúp đánh giá CVE còn “sống” (được cập nhật) hay đã “ổn định”. |
|
||||||
|
| `days_since_exploit` | Số ngày từ khi exploit công khai | `now - exploit_date` | Xác định tốc độ khai thác, hỗ trợ triage nhanh các CVE mới bị exploit. |
|
||||||
|
| `days_since_scan` | Số ngày kể từ lần scan gần nhất | `now - scan_date` | Cho thấy dữ liệu có còn “fresh” hay không, giúp xác định độ tin cậy của finding. |
|
||||||
|
| `days_since_last_seen` | Số ngày từ lần thấy finding gần nhất | `now - last_seen` | Xác định lỗ hổng còn tồn tại trên asset hay không |
|
||||||
|
| `days_since_first_found` | Số ngày từ khi finding đầu tiên được phát hiện | `now - first_found` | Đánh giá thời gian tồn tại của finding trong môi trường |
|
||||||
|
| `days_since_vendor_update` | Số ngày kể từ khi vendor cập nhật thông tin/patch | `now - vendor_update_date` | Dùng để tính patch lag; đo mức độ phản ứng vendor |
|
||||||
|
| `risk_score_context` | Điểm rủi ro kết hợp ngữ cảnh tài sản và độ nghiêm trọng CVE | `asset_criticality * cvss_v3_base` | Ưu tiên lỗ hổng trên tài sản quan trọng dù CVSS trung bình |
|
||||||
|
| `exploit_exposed` | Cờ nhị phân: asset exposed + CVE có exploit công khai | `internet_exposed * exploit_exists` | Nếu =1 → rủi ro cao (exploit + public exposure) |
|
||||||
|
| `cve_age` | Tuổi của CVE (ngày kể từ công bố) | `days_since_publish` | CVE càng lâu mà chưa vá → cho thấy quản lý kém hoặc vendor chưa vá → tăng rủi ro. |
|
||||||
|
| `patch_lag` | Độ trễ giữa ngày công bố CVE và ngày vendor cập nhật | `days_since_vendor_update - days_since_publish` | Đánh giá vendor phản ứng chậm; hỗ trợ phân công patch |
|
||||||
|
| `severity_cvss_ratio` | Tỷ lệ giữa severity_label score và CVSS v3 | `severity_score / (cvss_v3_base + 0.1)` | Phát hiện chênh lệch giữa label severity và điểm CVSS (ví dụ severity cao nhưng CVSS thấp). |
|
||||||
|
| `severity_ordinal` | Chuyển severity label (Low/Medium/High/Critical) sang số | `map: Low=1, Medium=2, High=3, Critical=4` | Dùng để mô hình dễ xử lý hơn so với text, đồng thời hỗ trợ rule-based mapping với ngưỡng số. |
|
||||||
|
|
||||||
|
#### 5. Tách Dữ Liệu Thành Feature Matrix Và Labels
|
||||||
|
- **Feature matrix X:** Chọn các cột đặc trưng đã chuẩn hóa và phái sinh, bao gồm cả số (numeric) và phân loại (categorical), ví dụ: asset_criticality, cvss_v3_base, epss_score, environment, network_zone, vendor_status, scan_tool, v.v.
|
||||||
|
- **Labels:**
|
||||||
|
- `priority_score`: Nhãn cho bài toán regression (dự đoán điểm ưu tiên).
|
||||||
|
- `incident_happened`: Nhãn cho bài toán classification (dự đoán có xảy ra sự cố hay không).
|
||||||
|
|
||||||
|
#### 6. Xử Lý Missing Values (Giá Trị Thiếu)
|
||||||
|
- **Numeric:** Các giá trị thiếu trong feature số (ví dụ: ngày tháng không có, patch_lag thiếu…) được thay bằng median hoặc giá trị mặc định.
|
||||||
|
- **Categorical:** Các trường phân loại thiếu sẽ được OneHotEncoder xử lý với tùy chọn `handle_unknown="ignore"`, đảm bảo pipeline không lỗi khi gặp giá trị mới.
|
||||||
|
|
||||||
|
#### 7. Preprocessing Pipeline: Chuẩn Hóa & Mã Hóa
|
||||||
|
- **MinMaxScaler:** Áp dụng cho toàn bộ các cột số để đưa giá trị về khoảng [0,1], giúp mô hình học ổn định hơn.
|
||||||
|
- **OneHotEncoder:** Mã hóa các cột phân loại (environment, network_zone, os, business_service, vendor_status, scan_tool, finding_state) thành vector nhị phân.
|
||||||
|
- **ColumnTransformer & Pipeline:** Kết hợp các bước trên thành một pipeline hoàn chỉnh, giúp tái sử dụng dễ dàng khi huấn luyện và dự đoán.
|
||||||
|
- **Lưu pipeline:** Pipeline preprocessing được lưu vào file `preprocess.pkl` để dùng lại ở các bước sau (huấn luyện, inference, giải thích).
|
||||||
|
|
||||||
|
#### 8. Train/Test Split: Chia Dữ Liệu Huấn Luyện & Kiểm Thử
|
||||||
|
- **Tỷ lệ:** 80% training, 20% testing.
|
||||||
|
- **Stratify:** Chia dữ liệu đảm bảo tỷ lệ nhãn `incident_happened` (0/1) giống nhau ở cả train và test, giúp đánh giá mô hình công bằng hơn.
|
||||||
|
- **Kết quả:** Sinh ra các file:
|
||||||
|
- `X_train.csv`, `X_test.csv`: Ma trận đặc trưng cho train/test.
|
||||||
|
- `y_train_priority.csv`, `y_test_priority.csv`: Nhãn regression (priority_score).
|
||||||
|
- `y_train_incident.csv`, `y_test_incident.csv`: Nhãn classification (incident_happened).
|
||||||
|
|
||||||
|
#### 9. Outputs: File Sinh Ra Sau Bước 2
|
||||||
|
- `X_train.csv`, `X_test.csv`: Feature matrix đã chuẩn hóa, sẵn sàng cho huấn luyện.
|
||||||
|
- `y_train_priority.csv`, `y_test_priority.csv`: Nhãn điểm ưu tiên.
|
||||||
|
- `y_train_incident.csv`, `y_test_incident.csv`: Nhãn sự cố.
|
||||||
|
- `preprocess.pkl`: Pipeline tiền xử lý (chuẩn hóa, mã hóa).
|
||||||
|
- `feature_schema.json`: Tài liệu schema đặc trưng đầu vào, giải thích ý nghĩa từng cột, loại dữ liệu, phạm vi giá trị.
|
||||||
|
|
||||||
|
#### 10. Kết Quả Đạt Được
|
||||||
|
- **Dữ liệu đã chuẩn hóa, sạch, đầy đủ ngữ cảnh và đặc trưng phái sinh.**
|
||||||
|
- **Sẵn sàng để huấn luyện mô hình học máy hoặc rule-based.**
|
||||||
|
- **Pipeline tiền xử lý giúp tái sử dụng nhất quán cho inference và explainability.**
|
||||||
|
- **File schema giúp kiểm soát chất lượng, giải thích và tích hợp với các hệ thống khác.**
|
||||||
|
|
||||||
|
> **Tóm lại:** Bước 2 đảm bảo dữ liệu đầu vào cho mô hình được xử lý bài bản, đầy đủ ngữ cảnh thực tế, giúp mô hình học tốt hơn và kết quả phân loại lỗ hổng sát với thực tiễn doanh nghiệp.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Bước 3: Huấn Luyện Mô Hình
|
||||||
|
|
||||||
|
Bước 3 là giai đoạn trung tâm của pipeline, nơi các mô hình học máy được huấn luyện để tự động phân loại và ưu tiên lỗ hổng, đồng thời so sánh hiệu quả với baseline rule-based truyền thống. Toàn bộ quy trình này được thực hiện trong file `3_train_model.py` với các bước chính như sau:
|
||||||
|
|
||||||
|
#### 1. Đầu Vào: Dữ Liệu & Pipeline Tiền Xử Lý
|
||||||
|
- **Feature matrix và nhãn**:
|
||||||
|
- `X_train.csv`, `X_test.csv`: Ma trận đặc trưng (features) cho tập huấn luyện và kiểm thử.
|
||||||
|
- `y_train_priority.csv`, `y_test_priority.csv`: Nhãn regression (priority_score) — điểm ưu tiên cần dự đoán.
|
||||||
|
- `y_train_incident.csv`, `y_test_incident.csv`: Nhãn classification (incident_happened) — dự đoán sự cố có xảy ra không.
|
||||||
|
- **Pipeline tiền xử lý**:
|
||||||
|
- `preprocess.pkl`: Pipeline chuẩn hóa và mã hóa đã lưu từ bước 2, đảm bảo xử lý nhất quán dữ liệu đầu vào cho mô hình.
|
||||||
|
|
||||||
|
#### 2. Rule-based Baseline Triage
|
||||||
|
- **Mục tiêu**: Xây dựng baseline bằng các quy tắc đơn giản dựa trên kiến thức chuyên môn để làm tham chiếu cho hiệu quả của mô hình học máy.
|
||||||
|
- **Cách thực hiện**:
|
||||||
|
- **Priority (Regression)**:
|
||||||
|
- Ước lượng điểm ưu tiên bằng công thức: `priority_pred = cvss_v3_base * 10`.
|
||||||
|
- Nếu `cvss_v3_base >= 9` và `asset_criticality >= 4` thì đảm bảo điểm tối thiểu là 80 (clip trong [0, 100]).
|
||||||
|
- Tính các metrics: RMSE, MAE, R2.
|
||||||
|
- **Incident (Classification)**:
|
||||||
|
- Dự đoán incident_happened = 1 nếu `exploit_exists == 1` **và** `internet_exposed == 1`, ngược lại là 0.
|
||||||
|
- Đánh giá bằng các metrics: accuracy, precision, recall, F1-score, ROC-AUC.
|
||||||
|
|
||||||
|
#### 3. Huấn Luyện Mô Hình Regression (Dự Đoán Priority Score)
|
||||||
|
- **Mục tiêu**: Dự đoán điểm ưu tiên (priority_score) của từng finding dựa trên các đặc trưng đã chuẩn hóa.
|
||||||
|
- **Các mô hình sử dụng**:
|
||||||
|
- **LightGBMRegressor**: Mô hình boosting hiện đại, tối ưu cho dữ liệu tabular, cho phép kiểm soát overfitting tốt.
|
||||||
|
- **RandomForestRegressor**: Mô hình ensemble truyền thống, mạnh mẽ với dữ liệu nhiều chiều và ít cần tuning.
|
||||||
|
- **Quy trình**:
|
||||||
|
1. Huấn luyện cả hai mô hình trên tập train (`X_train`, `y_train_priority`), dự đoán trên tập test (`X_test`).
|
||||||
|
2. Tính các metrics đánh giá: RMSE (root mean squared error), MAE, R2.
|
||||||
|
3. So sánh kết quả, chọn mô hình có RMSE thấp nhất làm best model cho regression.
|
||||||
|
|
||||||
|
#### 4. Huấn Luyện Mô Hình Classification (Dự Đoán Incident)
|
||||||
|
- **Mục tiêu**: Dự đoán xác suất hoặc khả năng xảy ra sự cố (incident_happened) dựa trên đặc trưng của finding.
|
||||||
|
- **Các mô hình sử dụng**:
|
||||||
|
- **LightGBMClassifier**: Mô hình boosting cho classification, tối ưu hiệu suất và khả năng tổng quát hóa.
|
||||||
|
- **RandomForestClassifier**: Mô hình ensemble mạnh mẽ, phù hợp với dữ liệu nhiều chiều.
|
||||||
|
- **Quy trình**:
|
||||||
|
1. Huấn luyện cả hai mô hình trên tập train (`X_train`, `y_train_incident`), dự đoán trên tập test (`X_test`).
|
||||||
|
2. Tính các metrics: accuracy, precision, recall, F1-score, ROC-AUC.
|
||||||
|
3. So sánh kết quả, chọn mô hình có F1-score cao nhất (nếu bằng thì ưu tiên accuracy) làm best model cho classification.
|
||||||
|
|
||||||
|
#### 5. So Sánh & Lựa Chọn Mô Hình Tốt Nhất
|
||||||
|
- **Regression**: Chọn model có RMSE thấp nhất trên tập test.
|
||||||
|
- **Classification**: Chọn model có F1-score cao nhất (ưu tiên metric cân bằng precision/recall).
|
||||||
|
- **So sánh với rule-based**: Metrics của mô hình học máy được đặt cạnh baseline rule-based để đánh giá mức cải thiện (lift) so với phương pháp truyền thống.
|
||||||
|
|
||||||
|
#### 6. Xuất Artifacts (Lưu Mô Hình & Báo Cáo)
|
||||||
|
- **Các file output**:
|
||||||
|
- `model_priority.pkl`: Mô hình ML tốt nhất cho bài toán regression (dự đoán priority_score).
|
||||||
|
- `model_incident.pkl`: Mô hình ML tốt nhất cho bài toán classification (dự đoán incident_happened).
|
||||||
|
- `metrics_report.json`: Báo cáo chi tiết các metrics của rule-based baseline, regression, classification (bao gồm thông tin về hyperparameters, số lượng mẫu train/test, số lượng đặc trưng, v.v.).
|
||||||
|
- `predictions_lgbm.csv` và `predictions_rf.csv`: Dùng để phân tích residual và so sánh mô hình, hỗ trợ cho việc visualize trên Splunk sau này.
|
||||||
|
|
||||||
|
#### 7. Ý Nghĩa & Vai Trò Của Bước Này Trong Pipeline
|
||||||
|
- **Đây là bước quyết định khả năng tự động hóa phân loại và ưu tiên lỗ hổng**:
|
||||||
|
- Các mô hình học máy được huấn luyện trên dữ liệu có ngữ cảnh, giúp dự đoán sát thực tế hơn so với rule-based cứng nhắc.
|
||||||
|
- Việc so sánh với baseline giúp kiểm soát chất lượng, đảm bảo mô hình thực sự mang lại giá trị bổ sung.
|
||||||
|
- **Các mô hình và pipeline tiền xử lý được lưu lại dưới dạng artifacts**:
|
||||||
|
- Đảm bảo có thể tái sử dụng nhất quán ở các bước inference, explainability, tích hợp Splunk, hoặc tái huấn luyện sau này.
|
||||||
|
- **Bước này là cầu nối giữa dữ liệu và ứng dụng thực tế**:
|
||||||
|
- Kết quả mô hình sẽ được dùng trực tiếp trong các hệ thống quản lý lỗ hổng, dashboard Splunk, hoặc tích hợp vào các quy trình SOC tự động.
|
||||||
|
|
||||||
|
> **Tóm lại:** Bước 3 giúp chuyển hóa dữ liệu đã chuẩn hóa thành các mô hình thông minh, tự động hóa và tối ưu hóa quá trình triage lỗ hổng, đồng thời đảm bảo kiểm soát chất lượng qua so sánh với rule-based baseline và lưu trữ đầy đủ artifacts phục vụ các bước sau trong pipeline.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Bước 4: Giải Thích Mô Hình
|
||||||
|
|
||||||
|
Bước 4 trong pipeline tập trung vào việc **giải thích các quyết định của mô hình học máy** thông qua phương pháp SHAP (SHapley Additive exPlanations). Điều này giúp tăng tính minh bạch, hỗ trợ các SOC analyst hiểu rõ lý do vì sao một lỗ hổng được ưu tiên hoặc phân loại là nguy hiểm, đồng thời chuẩn bị dữ liệu explainability để tích hợp vào Splunk.
|
||||||
|
|
||||||
|
#### 1. Đầu Vào
|
||||||
|
- **Dữ liệu kiểm thử:**
|
||||||
|
- `X_test.csv`: Ma trận đặc trưng của tập kiểm thử.
|
||||||
|
- **Pipeline tiền xử lý:**
|
||||||
|
- `preprocess.pkl`: Pipeline chuẩn hóa và mã hóa đã lưu từ bước 2.
|
||||||
|
- **Mô hình học máy:**
|
||||||
|
- `model_priority.pkl`: Mô hình regression dự đoán điểm ưu tiên (priority_score).
|
||||||
|
- `model_incident.pkl`: Mô hình classification dự đoán khả năng xảy ra sự cố (incident_happened).
|
||||||
|
|
||||||
|
#### 2. Quy Trình Giải Thích (theo file `4_explainability.py`)
|
||||||
|
1. **Load dữ liệu & mô hình:**
|
||||||
|
- Đọc `X_test.csv` và pipeline `preprocess.pkl`.
|
||||||
|
- Nạp hai mô hình đã huấn luyện: regression và classification.
|
||||||
|
|
||||||
|
2. **Tiền xử lý dữ liệu:**
|
||||||
|
- Sử dụng pipeline để biến đổi `X_test` thành ma trận đặc trưng đầy đủ, đồng nhất với đầu vào của mô hình.
|
||||||
|
|
||||||
|
3. **Dự đoán kết quả:**
|
||||||
|
- Mô hình regression dự đoán điểm ưu tiên (priority_score) cho từng finding.
|
||||||
|
- Mô hình classification dự đoán xác suất xảy ra sự cố (incident_happened).
|
||||||
|
|
||||||
|
4. **Tính toán SHAP values với TreeExplainer:**
|
||||||
|
- Áp dụng `shap.TreeExplainer` cho cả hai mô hình (regression và classification).
|
||||||
|
- Đối với classification, lấy SHAP values của class dương tính (xảy ra sự cố).
|
||||||
|
|
||||||
|
5. **Lấy top_features (10 đặc trưng quan trọng nhất):**
|
||||||
|
- Với mỗi sample, lấy 10 đặc trưng có giá trị SHAP lớn nhất (tác động mạnh nhất đến dự đoán).
|
||||||
|
- Kết quả là một dict mapping sample_id → {feature: shap_value, ...}.
|
||||||
|
|
||||||
|
6. **Xuất kết quả explainability:**
|
||||||
|
- **File JSON:**
|
||||||
|
- `shap_priority.json`: Giải thích cho mô hình regression, gồm dự đoán và top_features của mỗi sample.
|
||||||
|
- `shap_incident.json`: Giải thích cho mô hình classification, gồm xác suất dự đoán và top_features.
|
||||||
|
- **Biểu đồ tổng quan:**
|
||||||
|
- `shap_summary_priority.png`: Biểu đồ SHAP tổng hợp cho regression.
|
||||||
|
- `shap_summary_incident.png`: Biểu đồ SHAP tổng hợp cho classification.
|
||||||
|
|
||||||
|
#### 3. Ý Nghĩa & Vai Trò Trong Cyber Security
|
||||||
|
- **Minh bạch mô hình:**
|
||||||
|
- SHAP cho phép analyst thấy rõ đặc trưng nào (ví dụ: CVSS, asset_criticality, exploit_exists, internet_exposed, patch_lag, v.v.) tác động mạnh nhất đến quyết định của mô hình cho từng lỗ hổng.
|
||||||
|
- **Hỗ trợ phân tích và kiểm chứng:**
|
||||||
|
- Analyst có thể kiểm tra, xác thực lý do tại sao một finding được ưu tiên cao/thấp hoặc bị gắn nhãn nguy hiểm, từ đó tự tin hơn khi ra quyết định xử lý.
|
||||||
|
- **Chuẩn bị tích hợp Splunk:**
|
||||||
|
- Các file JSON giải thích (shap_priority.json, shap_incident.json) và biểu đồ summary sẽ được ingest vào Splunk, hiển thị trực quan trên dashboard, tăng giá trị sử dụng thực tiễn.
|
||||||
|
- **Tăng độ tin cậy và tuân thủ:**
|
||||||
|
- Giải thích rõ ràng giúp đáp ứng yêu cầu về minh bạch khi ứng dụng AI/ML trong lĩnh vực an ninh mạng, đặc biệt với các tổ chức cần audit hoặc tuân thủ quy định.
|
||||||
|
|
||||||
|
![[Pasted image 20251002151409.png]]
|
||||||
|
![[Pasted image 20251002151420.png]]
|
||||||
|
|
||||||
|
|
||||||
|
> **Tóm lại:** Bước 4 giúp pipeline không chỉ tự động hóa phân loại mà còn giải thích được lý do từng quyết định, tăng độ tin cậy và khả năng kiểm soát, đồng thời mở đường cho việc tích hợp sâu vào các hệ thống quản trị lỗ hổng như Splunk.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Bước 5: Tích Hợp Với Splunk
|
||||||
|
|
||||||
|
Bước này thực hiện xuất dữ liệu kết quả dự đoán và giải thích của mô hình thành **lookup file chuẩn** để ingest vào Splunk, phục vụ phân tích, dashboard và tự động hóa trong quy trình SOC.
|
||||||
|
|
||||||
|
#### 1. Đầu Vào
|
||||||
|
- **X_test.csv**: Ma trận đặc trưng của tập kiểm thử (test set), bao gồm đầy đủ các trường ngữ cảnh về asset, CVE, đặc trưng kỹ thuật, v.v.
|
||||||
|
- **shap_priority.json**: File giải thích SHAP cho mô hình dự đoán điểm ưu tiên (priority_score), chứa prediction và top_features cho từng bản ghi.
|
||||||
|
- **shap_incident.json**: File giải thích SHAP cho mô hình phân loại incident (incident_happened), chứa prediction (nguy cơ sự cố) và top_features.
|
||||||
|
|
||||||
|
#### 2. Các Bước Xử Lý Trong Script (`5_export_lookup.py`)
|
||||||
|
Quy trình thực hiện như sau:
|
||||||
|
|
||||||
|
1. **Load dữ liệu X_test**
|
||||||
|
- Đọc file `X_test.csv` (bằng pandas), reset lại chỉ số dòng để gán id cho từng bản ghi.
|
||||||
|
|
||||||
|
2. **Load SHAP explainability (priority + incident)**
|
||||||
|
- Đọc hai file `shap_priority.json` và `shap_incident.json`.
|
||||||
|
- Với mỗi bản ghi (id), lấy prediction (giá trị dự đoán) và danh sách các top_features (10 đặc trưng quan trọng nhất, dạng tên đặc trưng).
|
||||||
|
|
||||||
|
3. **Merge dữ liệu dự đoán + top_features vào từng bản ghi**
|
||||||
|
- Với mỗi dòng của X_test, bổ sung thêm các trường:
|
||||||
|
- `pred_priority_score`: Giá trị dự đoán điểm ưu tiên từ mô hình regression.
|
||||||
|
- `top_features_priority`: Danh sách tên 10 đặc trưng có ảnh hưởng lớn nhất đến dự đoán priority_score (theo SHAP).
|
||||||
|
- `pred_incident_risk`: Giá trị dự đoán xác suất/sự kiện incident từ mô hình classification.
|
||||||
|
- `top_features_incident`: Danh sách 10 đặc trưng ảnh hưởng lớn nhất đến dự đoán incident.
|
||||||
|
- Các trường này được lấy từ hai file SHAP tương ứng theo id (index của X_test).
|
||||||
|
|
||||||
|
4. **Thêm timestamp export_time**
|
||||||
|
- Thêm trường `export_time` (giá trị UTC ISO format) vào đầu bảng để trace thời gian export dữ liệu, phục vụ audit và kiểm soát version.
|
||||||
|
|
||||||
|
5. **Xuất file CSV `vuln_prioritization_lookup.csv`**
|
||||||
|
- Ghi toàn bộ dataframe đã enrich ra file `lookup/vuln_prioritization_lookup.csv`.
|
||||||
|
- Mỗi dòng là một finding (finding_id hoặc index), chứa đầy đủ các trường gốc từ X_test (asset_id, cve_id, các đặc trưng kỹ thuật), trường dự đoán, trường explainability (top_features), và trường timestamp.
|
||||||
|
|
||||||
|
#### 3. File Output và Vai Trò
|
||||||
|
- **File xuất ra:**
|
||||||
|
- `lookup/vuln_prioritization_lookup.csv`
|
||||||
|
- **Vai trò:**
|
||||||
|
- Đây là **lookup chuẩn** để ingest vào Splunk (qua Data Inputs hoặc Lookup Editor).
|
||||||
|
- Cho phép analyst, dashboard, hoặc các playbook tự động truy vấn, join, phân tích thông tin dự đoán và giải thích cho từng finding.
|
||||||
|
- Có thể dùng trực tiếp trong SPL với lệnh `| inputlookup vuln_prioritization_lookup.csv`.
|
||||||
|
|
||||||
|
#### 4. Ý Nghĩa Trong SOC/Splunk
|
||||||
|
- **Lookup này là cầu nối giữa pipeline ML và các quy trình vận hành thực tế của SOC:**
|
||||||
|
- Analyst có thể **tra cứu nhanh** priority_score, nguy cơ incident và lý do (top_features) cho từng lỗ hổng/asset.
|
||||||
|
- Dễ dàng **join với bảng CMDB, log scan thực tế** (Nessus/OpenVAS), hoặc các bảng asset khác để phân tích sâu.
|
||||||
|
- **Dashboard Splunk** có thể sử dụng lookup này để:
|
||||||
|
- Hiển thị top 10 asset/CVE nguy hiểm nhất theo priority_score.
|
||||||
|
- Drilldown vào từng finding để xem chi tiết top_features ảnh hưởng đến quyết định của mô hình.
|
||||||
|
- Kết hợp các trường explainability để giải thích lý do tại sao một finding được đánh giá cao/thấp.
|
||||||
|
- **Tự động hóa workflow**: Có thể trigger playbook SOAR, gửi cảnh báo, mở ticket tự động dựa trên ngưỡng priority_score hoặc sự xuất hiện của các feature nguy hiểm trong top_features.
|
||||||
|
- **Minh bạch & audit**: Mỗi quyết định của mô hình đều trace được thời điểm export, lý do (giải thích SHAP), phục vụ kiểm tra lại/audit khi cần.
|
||||||
|
|
||||||
|
![[Pasted image 20251002151500.png]]
|
||||||
|
![[Pasted image 20251002151510.png]]
|
||||||
|
![[Pasted image 20251002151517.png]]
|
||||||
|
|
||||||
|
> **Tóm lại:**
|
||||||
|
> Lookup file này giúp đưa kết quả ML/Explainability vào Splunk một cách thực dụng, minh bạch và có thể hành động. Analyst và dashboard có thể sử dụng trực tiếp, join với các nguồn dữ liệu khác, phục vụ phân tích, ra quyết định, và tự động hóa quy trình vận hành SOC.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Cài Đặt & Sử Dụng
|
||||||
|
|
||||||
|
### Yêu Cầu Môi Trường
|
||||||
|
- Python >= 3.9
|
||||||
|
- Các thư viện trong `requirements.txt`
|
||||||
|
- Splunk Enterprise (tùy chọn cho bước 5)
|
||||||
|
- Cần export biến môi trường `MOCK_SALT` trước khi chạy pipeline
|
||||||
|
|
||||||
|
### Các Bước Cài Đặt
|
||||||
|
```bash
|
||||||
|
git clone <repo>
|
||||||
|
cd autonomous_vulnerability_triage
|
||||||
|
python3 -m venv .venv
|
||||||
|
source .venv/bin/activate
|
||||||
|
pip install -r requirements.txt
|
||||||
|
```
|
||||||
|
|
||||||
|
### Chạy Toàn Bộ Pipeline
|
||||||
|
```bash
|
||||||
|
MOCK_SALT="my_secure_salt" python run_pipeline.py
|
||||||
|
```
|
||||||
|
|
||||||
|
### Chạy UI Demo Với Gradio
|
||||||
|
```bash
|
||||||
|
MOCK_SALT="my_secure_salt" python ui_pipeline.py
|
||||||
|
```
|
||||||
|
---
|
||||||
|
|
||||||
|
## Giao Diện Người Dùng Với Gradio
|
||||||
|
|
||||||
|
- Dự án cung cấp UI demo sử dụng **Gradio** trong file `ui_pipeline.py`.
|
||||||
|
- UI gồm nhiều tab:
|
||||||
|
- **README.md**: hiển thị tài liệu dự án
|
||||||
|
- **Step 1 → Step 5**: chạy từng bước pipeline, hiển thị output ngay trong giao diện
|
||||||
|
- Mỗi step có phần **Wiki** giải thích, nút **Run**, và hiển thị kết quả (DataFrame preview, metrics, biểu đồ SHAP).
|
||||||
|
- Giúp developer hoặc analyst dễ dàng tương tác, quan sát kết quả từng bước mà không cần đọc log.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Cải Tiến Trong Tương Lai
|
||||||
|
|
||||||
|
- **Human-in-the-loop**: Cho phép analyst review, gắn nhãn lại, mô hình học thêm từ feedback.
|
||||||
|
- **Realtime Ingestion**: Hỗ trợ ingest dữ liệu thật từ Splunk hoặc scanner thay vì mockup.
|
||||||
|
- **Model Tuning**: Tự động tối ưu hyperparameter, thử nghiệm nhiều thuật toán hơn (XGBoost, CatBoost).
|
||||||
|
- **Explainability Dashboard**: Xây dựng dashboard trực quan hơn, highlight feature impact trong Splunk hoặc UI.
|
||||||
|
- **Automation Playbook**: Tích hợp với SOAR để tự động patch hoặc mitigate dựa trên prediction.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Phụ Lục
|
||||||
|
|
||||||
|
### A. Cấu Trúc Thư Mục Dự Án
|
||||||
|
```
|
||||||
|
autonomous_vulnerability_triage/
|
||||||
|
├── 1_gen_vuln_mock_enriched.py # Bước 1: Sinh dữ liệu mockup
|
||||||
|
├── 2_feature_engineering.py # Bước 2: Feature Engineering
|
||||||
|
├── 3_train_model.py # Bước 3: Huấn luyện mô hình
|
||||||
|
├── 4_explainability.py # Bước 4: SHAP explainability
|
||||||
|
├── 5_export_lookup.py # Bước 5: Xuất lookup Splunk
|
||||||
|
├── run_pipeline.py # Script chạy toàn pipeline end-to-end
|
||||||
|
├── ui_pipeline.py # Giao diện demo bằng Gradio
|
||||||
|
├── data/ # Thư mục dữ liệu (raw + processed)
|
||||||
|
├── models/ # Lưu trữ mô hình và metrics
|
||||||
|
├── explain/ # Kết quả SHAP và biểu đồ
|
||||||
|
├── lookup/ # Lookup file export cho Splunk
|
||||||
|
├── docs/ # Tài liệu (bao gồm poc_plan.txt)
|
||||||
|
└── requirements.txt # Danh sách thư viện cần cài
|
||||||
|
```
|
||||||
|
|
||||||
|
### B. Các File Output Chính & Ý Nghĩa
|
||||||
|
| File/Dataset | Ý nghĩa trong PoC | Vai trò trong ML Triage & Rule-Based | Nguồn tương ứng ngoài thực tế |
|
||||||
|
|--------------|------------------|--------------------------------------|--------------------------------|
|
||||||
|
| `assets.csv` | Thông tin tài sản từ CMDB mockup | Cung cấp ngữ cảnh asset: criticality, zone, service | CMDB, Asset Inventory |
|
||||||
|
| `nvd_enriched.csv` | Thông tin CVE + CVSS/EPSS/KEV | Đặc trưng chính cho risk scoring | NVD (National Vulnerability Database) |
|
||||||
|
| `exploitdb_enriched.csv` | CVE mapping sang exploit | Đặc trưng về khả năng khai thác | ExploitDB |
|
||||||
|
| `vendor_patch_enriched.csv` | Trạng thái patch từ vendor | Đặc trưng về patch lag, vendor status | Advisory từ vendor |
|
||||||
|
| `nessus_enriched.csv` | Findings mô phỏng từ scanner | Bảng chính để join dữ liệu | Nessus/OpenVAS/Qualys |
|
||||||
|
| `_metadata.json` | Metadata sinh dữ liệu | Đảm bảo reproducibility | N/A (internal validation) |
|
||||||
|
| `X_train.csv`, `X_test.csv` | Feature matrix cho training/test | Input cho mô hình ML | Generated (feature engineering) |
|
||||||
|
| `y_train_priority.csv`, `y_test_priority.csv` | Nhãn regression | Đánh giá mô hình priority score | Label tổng hợp PoC |
|
||||||
|
| `y_train_incident.csv`, `y_test_incident.csv` | Nhãn classification | Đánh giá mô hình incident | Label tổng hợp PoC |
|
||||||
|
| `model_priority.pkl`, `model_incident.pkl` | Mô hình ML đã huấn luyện | Dự đoán triage tự động | Artifact ML pipeline |
|
||||||
|
| `metrics_report.json` | Báo cáo metrics | So sánh ML vs rule-based | N/A |
|
||||||
|
| `shap_priority.json`, `shap_incident.json` | Explainability cho từng sample | Hiểu top features ảnh hưởng | SHAP output |
|
||||||
|
| `shap_summary_priority.png`, `shap_summary_incident.png` | Biểu đồ SHAP summary | Visualization explainability | SHAP plots |
|
||||||
|
| `vuln_prioritization_lookup.csv` | Lookup ingest vào Splunk | Dashboard, alert, join SOC workflow | Splunk Lookup |
|
||||||
|
| `predictions_lgbm.csv`, `predictions_rf.csv` | Kết quả sau khi training model | Để phân tích residual và so sánh mô hình | N/A |
|
||||||
|
|
||||||
|
### C. Tham Khảo
|
||||||
|
- [NVD - National Vulnerability Database](https://nvd.nist.gov/)
|
||||||
|
- [ExploitDB](https://www.exploit-db.com/)
|
||||||
|
- [Splunk Documentation](https://docs.splunk.com/)
|
||||||
|
- [SHAP Documentation](https://shap.readthedocs.io/)
|
||||||
166
content/SOC/Target Conceptual Architecture của SOC.md
Normal file
@ -0,0 +1,166 @@
|
|||||||
|
|
||||||
|
#cyber_security #soc
|
||||||
|
|
||||||
|
## **1. Giới thiệu chung**
|
||||||
|
|
||||||
|
Ở phần này, mình sẽ cùng bạn tìm hiểu một sơ đồ kiến trúc tổng thể của SOC (Security Operations Center – Trung tâm vận hành an ninh mạng) được gọi là **Target Conceptual Architecture**. Nghe có vẻ “hàn lâm”, nhưng thực chất đây chỉ là bức tranh toàn cảnh cho thấy các thành phần của một SOC hiện đại kết nối và làm việc với nhau như thế nào.
|
||||||
|
|
||||||
|
**Tóm tắt:**
|
||||||
|
|
||||||
|
Bài viết sẽ lần lượt giải thích từng thành phần trong kiến trúc, cách chúng liên kết, vị trí của SIEM, và vai trò của lớp hạ tầng nền tảng.
|
||||||
|
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
|
||||||
|
## **2. Tổng quan Target Conceptual Architecture**
|
||||||
|
|
||||||
|
**Tóm tắt:**
|
||||||
|
|
||||||
|
Đây là một bản thiết kế mô tả SOC từ góc nhìn “từ trên xuống” (high level). Mục tiêu là cho thấy **luồng dữ liệu**, **các khối chức năng** và **cách chúng giao tiếp với nhau**.
|
||||||
|
|
||||||
|
![[Pasted image 20250809101420.png]]
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### **2.1 Luồng dữ liệu và các thành phần chính**
|
||||||
|
|
||||||
|
Luồng dữ liệu trong kiến trúc này có thể hình dung như một **quy trình sản xuất**:
|
||||||
|
|
||||||
|
1. **Thu thập nguyên liệu** – Dữ liệu từ hệ thống nội bộ (On-Premise) và đám mây riêng (Private Cloud).
|
||||||
|
|
||||||
|
2. **Làm giàu thông tin** – Sử dụng TIP (Threat Intelligence Platform – Nền tảng tình báo mối đe dọa) để bổ sung ngữ cảnh, thông tin mối đe dọa.
|
||||||
|
|
||||||
|
3. **Phân tích sâu** – Sử dụng Security Analytics (Phân tích bảo mật) bao gồm tương quan sự kiện (Correlation), EDR (Endpoint Detection and Response – phát hiện và phản hồi điểm cuối), Threat Hunting (săn tìm mối đe dọa).
|
||||||
|
|
||||||
|
4. **Tự động xử lý** – Automation & Orchestration (SOAR – tự động hóa và điều phối) để thực thi các hành động.
|
||||||
|
|
||||||
|
5. **Quản lý & báo cáo** – Case Management (Quản lý sự cố) và CSOC Portal (Cổng thông tin SOC) hiển thị báo cáo, dashboard, tìm kiếm.
|
||||||
|
|
||||||
|
6. **Thực thi** – Enforcement áp dụng biện pháp bảo vệ trên hệ thống mạng, bảo mật, Active Directory.
|
||||||
|
|
||||||
|
**Ghi nhớ:**
|
||||||
|
|
||||||
|
Dòng chảy dữ liệu cơ bản là:
|
||||||
|
**Data Sources → TIP → Security Analytics → SOAR → Enforcement / CSOC Portal**
|
||||||
|
(Case Management kết nối với SOAR để quản lý sự cố).
|
||||||
|
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
|
||||||
|
## **3. Vai trò của từng khối trong kiến trúc**
|
||||||
|
|
||||||
|
### **3.1 Hạ tầng nền tảng (Infrastructure)**
|
||||||
|
|
||||||
|
**Tóm tắt:**
|
||||||
|
Đây là lớp nền móng đảm bảo toàn bộ SOC hoạt động trơn tru và an toàn.
|
||||||
|
|
||||||
|
**Chi tiết:**
|
||||||
|
|
||||||
|
- **LDAP/MFA/SSO**: Xác thực tập trung, đăng nhập một lần, bảo mật đa yếu tố.
|
||||||
|
|
||||||
|
- **NTP**: Đồng bộ thời gian giữa tất cả thiết bị, cực quan trọng cho việc tương quan log.
|
||||||
|
|
||||||
|
- **Email**: Gửi cảnh báo và thông báo sự cố.
|
||||||
|
|
||||||
|
- **Endpoint Security**: Bảo vệ máy trạm và server, cung cấp dữ liệu đầu vào cho SIEM.
|
||||||
|
|
||||||
|
- **Collaboration**: Công cụ trao đổi nội bộ như Teams, Slack.
|
||||||
|
|
||||||
|
- **Configuration/Software Management**: Quản lý cấu hình và cập nhật hệ thống.
|
||||||
|
|
||||||
|
- **Backup**: Lưu trữ dự phòng dữ liệu và cấu hình quan trọng.
|
||||||
|
|
||||||
|
- **Network & Network Security**: Đảm bảo kết nối và bảo mật luồng dữ liệu.
|
||||||
|
|
||||||
|
- **Compute & Storage**: Nguồn tài nguyên tính toán và lưu trữ log.
|
||||||
|
|
||||||
|
- **Workstation/VDI**: Nơi analyst thao tác.
|
||||||
|
|
||||||
|
**Ví dụ thực tế:**
|
||||||
|
|
||||||
|
Nếu NTP (đồng bộ thời gian) bị lệch 5 phút giữa các máy, SIEM có thể coi một chuỗi tấn công là các sự kiện rời rạc, khiến analyst bỏ lỡ mối liên hệ.
|
||||||
|
|
||||||
|
**Ghi nhớ:**
|
||||||
|
|
||||||
|
Hạ tầng yếu → SOC hoạt động kém hiệu quả, dễ mất dữ liệu hoặc xử lý sai.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### **3.2 Nguồn dữ liệu (Data Sources)**
|
||||||
|
|
||||||
|
Bao gồm log và sự kiện từ hệ thống On-Premise và Private Cloud. Đây là nguyên liệu đầu vào của SOC.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### **3.3 Nền tảng tình báo mối đe dọa (TIP)**
|
||||||
|
|
||||||
|
TIP nhận dữ liệu từ nhiều nguồn tình báo (TI feeds), phân tích sandbox, và nguồn nội bộ/ngoại bộ để làm giàu dữ liệu sự cố.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### **3.4 Phân tích bảo mật (Security Analytics)**
|
||||||
|
|
||||||
|
Chứa SIEM và các module nâng cao:
|
||||||
|
|
||||||
|
- **Correlation**: Ghép nối sự kiện từ nhiều nguồn.
|
||||||
|
|
||||||
|
- **EDR**: Phát hiện và phản hồi điểm cuối.
|
||||||
|
|
||||||
|
- **Threat Hunting**: Chủ động tìm kiếm mối đe dọa.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### **3.5 Tự động hóa và điều phối (SOAR)**
|
||||||
|
|
||||||
|
SOAR nhận kết quả phân tích từ SIEM, tự động chạy playbook để xử lý hoặc gửi lệnh thực thi.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### **3.6 Quản lý sự cố (Case Management)**
|
||||||
|
|
||||||
|
Ghi nhận, theo dõi, và điều phối xử lý các sự cố bảo mật.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### **3.7 Thực thi (Enforcement)**
|
||||||
|
|
||||||
|
Áp dụng hành động bảo vệ trên hạ tầng: chặn IP, khóa tài khoản AD, thay đổi cấu hình mạng…
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### **3.8 Cổng thông tin SOC (CSOC Portal)**
|
||||||
|
|
||||||
|
Giao diện tập trung cho analyst theo dõi báo cáo, dashboard, tìm kiếm, và kiểm tra tuân thủ.
|
||||||
|
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
|
||||||
|
## **4. SIEM nằm ở đâu trong kiến trúc này?**
|
||||||
|
|
||||||
|
SIEM nằm **bên trong khối Security Analytics**, ở phần **Correlation** và **Threat Hunting**. Nó là công cụ trung tâm thu thập, lưu trữ, tìm kiếm log, phân tích và tạo cảnh báo.
|
||||||
|
|
||||||
|
So sánh nhanh:
|
||||||
|
|
||||||
|
|**Thành phần**|**Chức năng chính**|
|
||||||
|
|---|---|
|
||||||
|
|SIEM|Thu thập, lưu trữ, tìm kiếm, phân tích log|
|
||||||
|
|Security Analytics|Gồm SIEM + các phân tích nâng cao (EDR, Hunting)|
|
||||||
|
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
|
||||||
|
## **5. Chốt lại kiến thức**
|
||||||
|
|
||||||
|
- **Hạ tầng nền tảng** là móng của SOC, không ổn định thì các khối khác khó hoạt động chính xác.
|
||||||
|
|
||||||
|
- **SIEM** chính là một phần của Security Analytics, tập trung vào thu thập và phân tích log.
|
||||||
|
|
||||||
|
- **Luồng dữ liệu SOC** cơ bản: Data Sources → TIP → Security Analytics → SOAR → Enforcement/Portal.
|
||||||
|
|
||||||
|
- **Case Management** đóng vai trò quản lý toàn bộ vòng đời sự cố, kết nối với SOAR.
|
||||||
|
|
||||||
|
![[Pasted image 20250809101716.png]]
|
||||||
43
content/index.md
Normal file
@ -0,0 +1,43 @@
|
|||||||
|
---
|
||||||
|
title: Hi I'm Patrick!
|
||||||
|
---
|
||||||
|
## About me
|
||||||
|
|
||||||
|
I’m a cybersecurity engineer with 5+ years of experience building and operating Security Operations Centers (SOC) for banking and enterprise environments. My core expertise lies in designing SIEM/SOAR systems (especially Splunk), automating incident response, and building scalable security workflows using Python and REST APIs.
|
||||||
|
|
||||||
|
I currently manage high-volume log pipelines (2TB+/day), lead SOAR optimization initiatives, and develop AI-powered playbooks to reduce alert fatigue and accelerate triage. My automation efforts have helped reduce incident response time by up to 80% and cut manual workload by 60%.
|
||||||
|
|
||||||
|
I'm passionate about pushing security operations forward with AI, and currently exploring:
|
||||||
|
- LLM-powered triage bots
|
||||||
|
- AI Agents for SOC
|
||||||
|
- Smart alert classification using ML
|
||||||
|
|
||||||
|
As a trusted team player with hands-on technical depth, I aim to contribute to high-impact security teams and build resilient, intelligent defense systems.
|
||||||
|
|
||||||
|
[Linkedin](https://www.linkedin.com/in/minhnhat19061999/)
|
||||||
|
[Github](https://github.com/cyberp01)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## My blogs
|
||||||
|
|
||||||
|
**Personal Projects**
|
||||||
|
- [[Autonomous Vulnerability Triage & Risk Scoring]]
|
||||||
|
|
||||||
|
**SOC**
|
||||||
|
- [[Target Conceptual Architecture của SOC]]
|
||||||
|
|
||||||
|
**Incident Responses**
|
||||||
|
- [[Computer Security Incident Handling Guide (NIST SP 800-61 Revision 2)]]
|
||||||
|
|
||||||
|
**Machine Learning for CyberSecurity**
|
||||||
|
- [[Splunk Machine Learning Toolkit (MLTK) for Cyber]]
|
||||||
|
- [[Machine Learning for Cyber > Unit 1 - Introduction]]
|
||||||
|
- [[Machine Learning for Cyber > Unit 2 - Datasets and Features]]
|
||||||
|
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
_– Patrick (NhatNTM)–_
|
||||||
BIN
content/resources/Pasted image 20250809101420.png
Normal file
|
After Width: | Height: | Size: 187 KiB |
BIN
content/resources/Pasted image 20250809101716.png
Normal file
|
After Width: | Height: | Size: 270 KiB |
BIN
content/resources/Pasted image 20251002150719.png
Normal file
|
After Width: | Height: | Size: 50 KiB |
BIN
content/resources/Pasted image 20251002151131.png
Normal file
|
After Width: | Height: | Size: 199 KiB |
BIN
content/resources/Pasted image 20251002151154.png
Normal file
|
After Width: | Height: | Size: 74 KiB |
BIN
content/resources/Pasted image 20251002151212.png
Normal file
|
After Width: | Height: | Size: 230 KiB |
BIN
content/resources/Pasted image 20251002151229.png
Normal file
|
After Width: | Height: | Size: 154 KiB |
BIN
content/resources/Pasted image 20251002151244.png
Normal file
|
After Width: | Height: | Size: 107 KiB |
BIN
content/resources/Pasted image 20251002151409.png
Normal file
|
After Width: | Height: | Size: 113 KiB |
BIN
content/resources/Pasted image 20251002151420.png
Normal file
|
After Width: | Height: | Size: 136 KiB |
BIN
content/resources/Pasted image 20251002151500.png
Normal file
|
After Width: | Height: | Size: 650 KiB |
BIN
content/resources/Pasted image 20251002151510.png
Normal file
|
After Width: | Height: | Size: 677 KiB |
BIN
content/resources/Pasted image 20251002151517.png
Normal file
|
After Width: | Height: | Size: 100 KiB |
@ -8,7 +8,7 @@ import * as Plugin from "./quartz/plugins"
|
|||||||
*/
|
*/
|
||||||
const config: QuartzConfig = {
|
const config: QuartzConfig = {
|
||||||
configuration: {
|
configuration: {
|
||||||
pageTitle: "Quartz 4",
|
pageTitle: "PATRICK> NHAT.NTM",
|
||||||
pageTitleSuffix: "",
|
pageTitleSuffix: "",
|
||||||
enableSPA: true,
|
enableSPA: true,
|
||||||
enablePopovers: true,
|
enablePopovers: true,
|
||||||
@ -29,27 +29,27 @@ const config: QuartzConfig = {
|
|||||||
},
|
},
|
||||||
colors: {
|
colors: {
|
||||||
lightMode: {
|
lightMode: {
|
||||||
light: "#faf8f8",
|
light: "#f9f9fa", // Màu nền chính của trang (background)
|
||||||
lightgray: "#e5e5e5",
|
lightgray: "#dedede", // Màu viền nhẹ, đường kẻ phân cách, border
|
||||||
gray: "#b8b8b8",
|
gray: "#b0b0b0", // Màu liên kết trong graph view, đường nối giữa các node
|
||||||
darkgray: "#4e4e4e",
|
darkgray: "#444444", // Màu chữ chính trong nội dung (paragraph, text)
|
||||||
dark: "#2b2b2b",
|
dark: "#1c1c1e", // Màu tiêu đề (h1, h2, h3...), icon, text quan trọng
|
||||||
secondary: "#284b63",
|
secondary: "#007aff", // Màu link thường, node hiện tại trong graph, button
|
||||||
tertiary: "#84a59d",
|
tertiary: "#d6b745", // Màu hover state, node đã thăm trong graph, accent color (vàng)
|
||||||
highlight: "rgba(143, 159, 169, 0.15)",
|
highlight: "rgba(0, 122, 255, 0.1)", // Màu nền cho link nội bộ (internal link background)
|
||||||
textHighlight: "#fff23688",
|
textHighlight: "#ffcc00aa", // Màu nền cho text được highlight/đánh dấu
|
||||||
},
|
},
|
||||||
darkMode: {
|
darkMode: {
|
||||||
light: "#161618",
|
light: "#1c1c1e", // Màu nền chính của trang (background) - dark theme
|
||||||
lightgray: "#393639",
|
lightgray: "#2c2c2e", // Màu viền nhẹ, đường kẻ phân cách, border - dark theme
|
||||||
gray: "#646464",
|
gray: "#636366", // Màu liên kết trong graph view, đường nối giữa các node - dark theme
|
||||||
darkgray: "#d4d4d4",
|
darkgray: "#e5e5e7", // Màu chữ chính trong nội dung (paragraph, text) - dark theme
|
||||||
dark: "#ebebec",
|
dark: "#f2f2f7", // Màu tiêu đề (h1, h2, h3...), icon, text quan trọng - dark theme
|
||||||
secondary: "#7b97aa",
|
secondary: "#0a84ff", // Màu link thường, node hiện tại trong graph, button - dark theme
|
||||||
tertiary: "#84a59d",
|
tertiary: "#d6b745", // Màu hover state, node đã thăm trong graph, accent color (vàng)
|
||||||
highlight: "rgba(143, 159, 169, 0.15)",
|
highlight: "rgba(10, 132, 255, 0.15)", // Màu nền cho link nội bộ (internal link background) - dark theme
|
||||||
textHighlight: "#b3aa0288",
|
textHighlight: "#ffd60a99", // Màu nền cho text được highlight/đánh dấu - dark theme
|
||||||
},
|
}
|
||||||
},
|
},
|
||||||
},
|
},
|
||||||
},
|
},
|
||||||
@ -68,7 +68,7 @@ const config: QuartzConfig = {
|
|||||||
}),
|
}),
|
||||||
Plugin.ObsidianFlavoredMarkdown({ enableInHtmlEmbed: false }),
|
Plugin.ObsidianFlavoredMarkdown({ enableInHtmlEmbed: false }),
|
||||||
Plugin.GitHubFlavoredMarkdown(),
|
Plugin.GitHubFlavoredMarkdown(),
|
||||||
Plugin.TableOfContents(),
|
Plugin.TableOfContents({ maxDepth: 4 }),
|
||||||
Plugin.CrawlLinks({ markdownLinkResolution: "shortest" }),
|
Plugin.CrawlLinks({ markdownLinkResolution: "shortest" }),
|
||||||
Plugin.Description(),
|
Plugin.Description(),
|
||||||
Plugin.Latex({ renderEngine: "katex" }),
|
Plugin.Latex({ renderEngine: "katex" }),
|
||||||
|
|||||||
@ -6,12 +6,7 @@ export const sharedPageComponents: SharedLayout = {
|
|||||||
head: Component.Head(),
|
head: Component.Head(),
|
||||||
header: [],
|
header: [],
|
||||||
afterBody: [],
|
afterBody: [],
|
||||||
footer: Component.Footer({
|
footer: () => null,
|
||||||
links: {
|
|
||||||
GitHub: "https://github.com/jackyzha0/quartz",
|
|
||||||
"Discord Community": "https://discord.gg/cRFFHYye7t",
|
|
||||||
},
|
|
||||||
}),
|
|
||||||
}
|
}
|
||||||
|
|
||||||
// components for pages that display a single page (e.g. a single note)
|
// components for pages that display a single page (e.g. a single note)
|
||||||
@ -41,7 +36,6 @@ export const defaultContentPageLayout: PageLayout = {
|
|||||||
Component.Explorer(),
|
Component.Explorer(),
|
||||||
],
|
],
|
||||||
right: [
|
right: [
|
||||||
Component.Graph(),
|
|
||||||
Component.DesktopOnly(Component.TableOfContents()),
|
Component.DesktopOnly(Component.TableOfContents()),
|
||||||
Component.Backlinks(),
|
Component.Backlinks(),
|
||||||
],
|
],
|
||||||
|
|||||||