Chấm điểm và báo cáo

Mọi công thức và số mặc định ở đây là đề xuất, chốt ở P0 cùng chủ dự án (Q26 cho SLA). Nguyên tắc bất biến: điểm phải giải thích được, mỗi finding lưu đủ thành phần để giao diện hiện "vì sao".

13 phút đọcCập nhật 03/10/2026access-hub-scanner, docs/06-scoring-and-reporting.md

1. Điểm của một finding

1.1 Mức nghiêm trọng gốc S (0 đến 10)

Lấy theo thứ tự, dừng ở nguồn đầu tiên có giá trị:

1. CVSS do distro công bố cho đúng gói đó (Red Hat, SUSE công bố điểm riêng, có thể khác NVD vì cách đóng gói).
2. CVSS của NVD (Primary), ưu tiên 4.0 nếu có, nếu không 3.1.
3. CVSS của CNA (Secondary trong dữ liệu NVD).
4. Nhãn mức độ của distro quy đổi: critical 9,5; high 8,0; medium 5,5; low 3,0; negligible 1,0.
5. Không có gì: 5,0 kèm cờ score_unknown (hiển thị rõ, không giấu).

Finding loại kiểm tra cấu hình dùng mức trong 05: critical 9,5; high 8,0; medium 5,5; low 3,0; info 0. Finding bí mật và dữ liệu cá nhân dùng cùng thang với mức do scanner tính (mục 1.6).

1.2 Hệ số

Hệ số	Giá trị	Nguồn
f_exploit	1,5 nếu CVE thuộc KEV; nếu không 0,7 + 0,6 x p với p là bách phân vị EPSS (0 đến 1); thiếu EPSS thì 1,0	KEV, EPSS
f_exposure	1,2 nếu máy là target của một PublicIp (quan hệ đa hình target_type, target_id trong app/Models/PublicIp.php) hoặc có tag internet-facing; 1,0 nếu không. Sau giai đoạn P5: 1,2 thêm khi gói cung cấp dịch vụ đang nghe trên địa chỉ không phải loopback (cần ánh xạ cổng sang gói, Q17)	Server, PublicIp, tag
f_env	prod 1,1; uat, dr 1,0; test, dev 0,8 (giá trị của enum App\Enums\Environment, cột Server.environment)	Server

1.3 Công thức

risk = min(100, round(S x 10 x f_exploit x f_exposure x f_env))

1.4 Mức ưu tiên

Ưu tiên	Điều kiện
P1	Thuộc KEV, hoặc risk >= 90
P2	risk >= 70
P3	risk >= 40
P4	Còn lại

Ví dụ:

Trường hợp	S	f_exploit	f_exposure	f_env	risk	Ưu tiên
CVSS 7,5, EPSS bách phân vị 0,97, máy prod có Public IP	7,5	1,282	1,2	1,1	100	P1
CVSS 9,8, EPSS bách phân vị 0,20, máy uat nội bộ	9,8	0,82	1,0	1,0	80	P2
CVSS 5,3, EPSS bách phân vị 0,50, máy prod nội bộ	5,3	1,0	1,0	1,1	58	P3
CVSS 6,5 nhưng thuộc KEV, máy test	6,5	1,5	1,0	0,8	78	P1 (KEV)

Trạng thái no_fix và wont_fix không đổi risk (rủi ro vẫn là rủi ro) nhưng đổi SLA (mục 2).

1.4b Ghi chú về tên ưu tiên

Mức ưu tiên P1 đến P4 của finding là khác với giai đoạn P0 đến P10 của lộ trình (12). Trong tài liệu, giai đoạn luôn được gọi kèm chữ "giai đoạn" hoặc đứng trong cột P của bảng yêu cầu.

1.5 Lưu và cập nhật

Nơi tính: secmatch gửi các đầu vào thuộc dữ liệu lỗ hổng (S, nguồn, epss, kev); Access Hub tính f_exposure, f_env, risk, priority và SLA, vì Access Hub giữ thuộc tính máy và cài đặt công ty. Nhờ vậy secmatch không cần đồng bộ thuộc tính Server (07 mục 5).

Finding lưu S, nguồn của S, vector CVSS, epss, epss_percentile, kev, kev_due_date, từng hệ số, risk, priority, scored_at. Điểm tính lại khi: DB đổi (EPSS hằng ngày, KEV), thuộc tính máy đổi (môi trường, tag, Public IP). Chỉ phát sự kiện finding.rescored khi ưu tiên đổi, để không gây bão sự kiện hằng ngày từ EPSS.

1.6 Finding bí mật và dữ liệu cá nhân

• S lấy từ severity do scanner tính theo ma trận 14 mục 2.3 (bí mật) và 5.4 (dữ liệu cá nhân), quy đổi theo mục 1.1.
• f_exploit = 1,0 (không có EPSS, KEV cho loại này). Mức phơi nhiễm trên máy đã nằm trong severity; f_exposure của máy (Public IP, tag internet-facing) và f_env vẫn áp dụng.
• Finding confidence = low có risk tối đa 39 (không vượt ưu tiên P4) cho đến khi người dùng xác nhận.
• Bí mật cùng fingerprint c trên nhiều máy là nhiều finding (mỗi máy một), giao diện gom thành một dòng "cùng bí mật trên N máy" và hiện risk lớn nhất.
• Ví dụ: khóa AWS (lớp A) trong .env nằm ở thư mục public của máy prod có Public IP: critical (9,5), risk = min(100, 9,5 x 10 x 1,0 x 1,2 x 1,1) = 100, ưu tiên P1. Mật khẩu chung trong tệp 0600 của chủ sở hữu trên máy dev: info, ưu tiên P4.

2. SLA

Ưu tiên	Hạn mặc định	Ghi chú
P1	7 ngày	CVE thuộc KEV hiển thị thêm dueDate của CISA để tham khảo
P2	30 ngày
P3	90 ngày
P4	180 ngày

• Đồng hồ SLA chạy từ first_seen_at. Với no_fix, đồng hồ bắt đầu khi bản sửa xuất hiện (fix_available_at).
• wont_fix: không có hạn, chỉ đóng bằng gỡ gói, nâng phiên bản phát hành, hoặc ngoại lệ.
• Ngoại lệ còn hiệu lực dừng đồng hồ. Hết hạn ngoại lệ thì đồng hồ chạy tiếp từ chỗ dừng.
• Ưu tiên tăng (ví dụ CVE vào KEV): hạn mới là min(hạn cũ, thời điểm tăng + hạn của ưu tiên mới).
• Cảnh báo: khi còn 20% thời gian, và khi quá hạn. Cấu hình hạn theo công ty có trần theo gói (Q10).
• Bí mật: đồng hồ SLA chạy như lỗ hổng có bản sửa (khắc phục luôn khả thi: xoay vòng và gỡ). Dữ liệu cá nhân: cùng bảng, công ty chỉnh riêng được.

3. Điểm máy và điểm công ty

• Điểm máy = risk lớn nhất trong các finding đang mở (không tính finding đang có ngoại lệ). Kèm số finding P1, P2 để xếp thứ tự khi bằng điểm. Lý do dùng giá trị lớn nhất: kẻ tấn công chỉ cần một lỗ hổng.
• Chỉ số công ty = round(0,5 x P90(điểm máy) + 0,5 x trung bình(điểm máy)) trên các máy đã quét trong 7 ngày. Kèm độ phủ (máy đã quét / máy có Access Hub Agent / tổng Server), vì chỉ số tốt trên độ phủ thấp là gây hiểu nhầm. Đây là con số tóm tắt cho lãnh đạo, giao diện luôn hiện kèm phân bố.

4. Thống kê, xu hướng, MTTR

Bảng security_stats_daily (theo công ty, có company_id, 08) được job ban đêm của Access Hub ghi từ security_findings:

Chỉ số	Định nghĩa
open_by_priority	Số finding đang mở theo P1 đến P4
open_by_severity	Theo nhãn mức độ gốc
opened, resolved	Số finding mở mới, đóng trong ngày
overdue	Số finding quá hạn SLA
accepted, false_positive	Số finding đang có ngoại lệ theo loại
kev_open	Số finding đang mở thuộc KEV
servers_scanned, servers_stale	Số máy có báo cáo trong 48 giờ, số máy có Agent mà quá 48 giờ không có báo cáo
mttr_seconds_by_priority	MTTR 30 ngày gần nhất
sla_compliance	Tỷ lệ finding đóng đúng hạn trong 30 ngày
checks_pass_rate_by_group	Tỷ lệ pass theo nhóm AHS-SSH, AHS-NET, ...
secrets_open_by_severity	Số finding bí mật đang mở theo mức độ
secrets_reused	Số bí mật (fingerprint c) có trên từ 2 máy
pii_files_by_type	Số tệp có dữ liệu cá nhân theo loại detector, theo ngưỡng số lượng
content_coverage	Số máy đã xong baseline, tỷ lệ tệp hợp lệ đã quét

MTTR = trung bình (và trung vị) của resolved_at - first_seen_at trên các finding đóng trong cửa sổ, chỉ tính resolved_reason thuộc package_updated, package_removed, check_passed, content_removed, file_deleted. Không tính advisory_changed (distro đổi dữ liệu), server_deleted, scope_left, out_of_scope, fingerprint_reset vì không phải khắc phục thật. MTTR của bí mật đo thời gian tới khi giá trị biến khỏi đĩa, không chứng minh đã xoay vòng ở nhà cung cấp; giao diện ghi rõ.

Giữ lịch sử theo hạn mức gói security_history_days (Q10, Q20).

5. Dashboard trong Access Hub

5.1 Tổng quan bảo mật của công ty (HUB-SEC-5)

• Ô số: finding P1, P2 đang mở; số KEV đang mở; số quá hạn SLA; số máy chưa quét 48 giờ; ngày của DB lỗ hổng (cảnh báo khi cũ).
• Xu hướng 30, 90, 365 ngày: số finding mở theo ưu tiên (cột chồng), đường MTTR.
• Máy dễ tổn thương nhất: 10 máy có điểm máy cao nhất, kèm số P1, P2, môi trường, nút sang tab Bảo mật của máy.
• Theo mức độ: phân bố theo ưu tiên và theo nhãn mức độ gốc.
• Theo gói: 10 gói nguồn ảnh hưởng nhiều máy nhất (số máy, ưu tiên cao nhất, có bản sửa không).
• Theo CVE: 10 CVE ảnh hưởng nhiều máy nhất, nhãn KEV, EPSS.
• Ngoại lệ sắp hết hạn trong 14 ngày.
• Tỷ lệ đạt theo nhóm kiểm tra cấu hình.
• Bí mật: số đang mở theo mức độ, top 10 máy, bí mật dùng lại trên nhiều máy (chỉ người có security.secrets.view mở được danh sách).
• Dữ liệu cá nhân: số tệp và số bản ghi theo loại, máy có nhiều dữ liệu cá nhân nhất (chỉ người có security.pii.view mở được chi tiết).
• Độ phủ quét nội dung: máy đã xong baseline, máy tắt quét nội dung cục bộ.
• Độ phủ: máy đã quét so với máy có Agent và tổng Server.

Bộ lọc theo máy dùng ô chọn tìm kiếm bất đồng bộ có phân trang, không tải sẵn toàn bộ danh sách (quy ước đã có của dự án cho bảng mở như máy chủ, người dùng).

5.2 Danh sách finding (HUB-SEC-6)

Lọc theo ưu tiên, mức độ, trạng thái, KEV, có bản sửa, máy, tag, môi trường, gói, CVE, loại (lỗ hổng hoặc kiểm tra), quá hạn. Sắp xếp theo risk, hạn SLA, ngày phát hiện. Mọi trường lọc là cột thường có chỉ mục (không mã hóa, theo ENC-2 chỉ bí mật mới mã hóa).

5.3 Tab Bảo mật trên trang máy chủ (HUB-SEC-4)

Điểm máy, finding của máy (lỗ hổng, cấu hình, bí mật, dữ liệu cá nhân theo quyền), kết quả kiểm tra cấu hình, danh sách gói (tra qua secmatch), cổng nghe so với dự kiến, thời điểm quét cuối, phiên bản scanner, trạng thái reboot_required, độ phủ quét nội dung (baseline, lượt cuối dừng vì lý do gì). Từ giai đoạn P6: dịch vụ, phần mềm ngoài gói, tệp đáng chú ý.

5.4 Hướng dẫn khắc phục (SFR-39)

Mỗi finding lỗ hổng có hướng dẫn văn bản: lệnh gợi ý để người dùng tự chạy (ví dụ sudo apt-get install --only-upgrade openssl, sudo dnf update openssl), mã advisory, liên kết advisory của distro. Không có nút "Sửa ngay", không có API thực thi (ADR 0003).

6. Ngoại lệ (chấp nhận rủi ro)

Thuộc tính	Quy tắc
Loại	accepted_risk, false_positive, compensating_control
Phạm vi	Một finding; một mã lỗ hổng trên một máy; một mã lỗ hổng (có thể kèm gói) trên một tag hoặc toàn công ty; một mã kiểm tra trên máy hoặc tag; với finding nội dung: một mã detector cộng mẫu đường dẫn (glob) trên máy, tag hoặc công ty, hoặc một fingerprint (ví dụ khóa thử nghiệm dùng chung có chủ đích)
Lý do	Bắt buộc, tối thiểu 20 ký tự; mã phiếu (ticket) tùy chọn
Hạn	Bắt buộc. Mặc định 90 ngày, tối đa 365 ngày. Không có ngoại lệ vĩnh viễn
Người duyệt	Có quyền security.exceptions.approve, khác người yêu cầu. Gói cá nhân (một người dùng, users = 1 trong PlanCatalog cho Free, Pro, Expert) không thể có người thứ hai: cho tự duyệt, bắt buộc lý do và hạn, gắn cờ self_approved hiển thị trên báo cáo
Trạng thái	pending sang approved hoặc rejected; approved sang expired (tự động) hoặc revoked
Hiệu lực	Finding khớp phạm vi chuyển sang accepted hoặc false_positive, dừng SLA, không tính vào điểm máy. Finding mới khớp phạm vi (ví dụ máy mới vào tag) cũng được áp, ghi rõ ngoại lệ nào
Hết hạn	Finding mở lại, SLA chạy tiếp, thông báo cho người yêu cầu và người duyệt 14 ngày trước và khi hết hạn
Audit	Tạo, duyệt, từ chối, thu hồi qua AuditRecorder hiện có

Có dùng lại engine ApprovalWorkflow hiện có (nhiều bước, SLA duyệt) hay luồng hai người đơn giản: Q14.

7. Xuất báo cáo (HUB-SEC-9)

• CSV, XLSX: danh sách finding, ngoại lệ, kết quả kiểm tra, theo bộ lọc hiện tại, qua cơ chế xuất xếp hàng hiện có (QueuesApiExport, ExportRequest, lệnh dọn tệp xuất định kỳ).
• PDF (giai đoạn P7): báo cáo tóm tắt cho lãnh đạo (chỉ số công ty, xu hướng, top máy, top CVE, SLA, ngoại lệ). Cần chọn thư viện dựng PDF, là thay đổi phụ thuộc của Access Hub nên phải được duyệt.
• Tệp xuất mang company_id, chỉ người cùng công ty có quyền security.view tải được, hết hạn theo chính sách xuất hiện có. Tệp ghi nguồn dữ liệu và ngày DB (yêu cầu ghi công ở 03 mục 4).

8. Thống kê cho nền tảng (ẩn danh, HUB-SEC-12)

Nhân viên nền tảng không xem dữ liệu khách hàng. Bảng platform_security_stats_daily không có cột company_id, chỉ chứa số tổng hợp:

• Số công ty bật quét (chỉ con số), tổng số máy đã quét, phân bố máy theo distro và phiên bản.
• Phân bố finding theo ưu tiên trên toàn nền tảng.
• CVE phổ biến: chỉ hiện CVE ảnh hưởng ít nhất k công ty (k mặc định 5, Q13), kèm số công ty và số máy làm tròn.
• Số ngoại lệ false_positive theo (vuln_id, ecosystem, package_key) khi đạt ngưỡng k, để cải thiện dữ liệu.
• Sức khỏe hệ thống: tuổi DB, tỷ lệ báo cáo lỗi, độ trễ so khớp lại.
• Nội dung: số finding theo họ detector và mức độ, số máy có bí mật mức cao, phân bố mức phơi nhiễm, tỷ lệ máy xong baseline, phân bố lý do dừng lượt nội dung; chỉ khi đạt ngưỡng k. Không đường dẫn, fingerprint, preview.

Không tên công ty, không tên máy, không IP, không hostname, không drill-down. Job tính thống kê chạy trong ngữ cảnh hệ thống, chỉ ghi ra số đã gộp; kiểm thử khẳng định bảng không có định danh công ty và ngưỡng k được áp.