VCyber Twin

Detection Reality Index · Vol.2

Đo trên IBM QRadar · tháng 7/2026

Bản tiếng Anh gốc: Detection Reality Index Vol.2 (IBM QRadar)

Đo thật, không khai báo, trên một SIEM doanh nghiệp thật

IBM QRadar thực sự phát hiện được gì: chạy lại, bấm giờ, lặp lại được

Chúng tôi chạy lại ba kỹ thuật ATT&CK thật trên một hệ thống IBM QRadar 7.3.3 đang chạy và đo xem cảnh báo có thực sự bật lên hay không, chứ không xem có luật hay không. QRadar bắt được kỹ thuật ồn ào trong 5,4 giây. Dò quét mạng và mã hóa tệp kiểu ransomware cho ra 0 cảnh báo, và lý do nằm ở phần không ai đưa lên slide.

5,4s

MTTD cho tấn công dò mật khẩu SSH (T1110.001), đo trên QRadar, không phải ước lượng

Cảnh báo cho dò quét mạng và mã hóa tệp kiểu ransomware, dù cả hai đều chạy thật

100%

Lặp lại được: dữ liệu sự kiện Ariel gốc và bộ công cụ tấn công được lưu kèm báo cáo này

Một câu CISO nên mang về

"Chúng ta có QRadar" và "QRadar sẽ bắt được vụ này" là hai khẳng định khác nhau. Trên hệ thống này, QRadar phát hiện kỹ thuật ồn ào rất nhanh, nhưng hoàn toàn không thấy các kỹ thuật lặng lẽ, vì đường ống telemetry từ máy chủ chưa bao giờ gửi các sự kiện đó đi. Anh chị không chọn khoảng hở này. Cấu hình mặc định đã chọn thay anh chị.

Kết quả: 3 kỹ thuật chạy lại trên QRadar đang hoạt động

Kỹ thuật ATT&CK	Kết quả	MTTD	Lý do (đo được, không giả định)
T1110.001 Brute Force: Password Guessing hydra, SSH, 5×7 cặp tài khoản/mật khẩu, 0 cặp hợp lệ	CÓ CẢNH BÁO	5.39 s	sshd ghi `"Failed password"` vào authpriv → rsyslog → QRadar. QRadar tự phân loại sự kiện ("User failed to login to SSH, incorrect password"), tách đúng IP thật của máy tấn công (192.168.99.50), nguồn log LinuxServer @ victim-ubuntu. 7 sự kiện.
T1046 Network Service Discovery quét TCP bằng nmap, cổng 1 đến 1000	BỎ LỌT	không có	Lần quét đã chạy và thấy cổng 22 mở. QRadar nhận 0 sự kiện từ lần quét này. Quét cổng không sinh ra syslog nào trên máy chủ, và không có cảm biến mạng (NIDS) nào đẩy dữ liệu vào QRadar. Không có gì để phát hiện vì không có gì được gửi tới.
T1486 Data Encrypted for Impact 6 tệp bị đổi tên thành .LOCKED	BỎ LỌT	không có	Sáu tệp đã bị mã hóa/đổi tên thật. QRadar nhận 0 sự kiện. Telemetry toàn vẹn tệp (auditd/FIM) không hoạt động trên máy chủ, nên việc mã hóa không để lại dấu vết nào trong syslog. Console không thể hiển thị thứ nó chưa bao giờ nhận được.

Đây không phải lời chê QRadar. QRadar phát hiện mọi thứ thực sự được đưa vào nó, và phát hiện nhanh. Hai ca bỏ lọt là do telemetry không được thu thập: đó là chuyện đường ống dữ liệu và cấu hình, không phải điểm yếu của sản phẩm. Phân biệt này chính là điều cần nói: khả năng phát hiện do những gì đi tới SIEM quyết định, và phần lớn các đội chưa từng đo điều đó trên hệ thống của chính mình.

Một lát cắt tương ứng, chạy trên môi trường thử của chúng tôi

Chúng tôi chạy lát cắt tương ứng khi có yêu cầu. Anh chị chọn kỹ thuật mà mình thực sự lo ngại. Chúng tôi chạy lại kỹ thuật đó trên môi trường thử, với một bản dựng khớp với hệ thống của anh chị, rồi gửi lại bản kết quả một trang: cái gì bật cảnh báo, luật nào, thời gian phát hiện đo được, cái gì im lặng và vì sao.

Việc này chạy trong lab của chúng tôi. Không có gì chạm vào môi trường của anh chị, không ai được cấp quyền truy cập, không dữ liệu nào rời khỏi phía anh chị, và không cần ký gì để nhận kết quả.

Mỗi lần chỉ chạy một yêu cầu, nên bắt đầu sớm hay muộn tùy vào việc đang có gì trên môi trường thử. Nếu kết quả hữu ích, bước tiếp theo là một hợp đồng có trả phí; nếu không, anh chị chỉ mất một email.

support@atkvn.com hoặc dùng biểu mẫu

VCyber Twin

Detection Reality Index · Vol.2

Phương pháp · Bằng chứng · Ý nghĩa

Ba sự thật khó nghe

1. "Có luật" không có nghĩa là phát hiện được.

QRadar bật cảnh báo cho đúng một kỹ thuật, kỹ thuật sinh ra log xác thực. Mọi kỹ thuật nằm ngoài đường ống log (dò quét, mã hóa tệp) đều không tạo ra gì, dù SIEM mạnh đến đâu.

2. Telemetry và cấu hình quyết định độ phủ, và cấu hình mặc định để lại những khoảng hở anh chị không hề chọn.

auditd không hoạt động và không có cảm biến mạng. Hai nhóm tấn công hoàn toàn vô hình, không phải do phần phân tích, mà vì sự kiện chưa bao giờ tới nơi. Một con số phần trăm độ phủ trên slide không thấy được điều này.

3. Chỉ có chạy lại mới cho biết sự thật về hệ thống của chính mình.

Cách duy nhất để biết một kỹ thuật có bật cảnh báo trên QRadar của anh chị hay không là chạy nó và quan sát. Phép đo này làm đúng việc đó, và datasheet của nhà cung cấp thì không bao giờ làm.

Chúng tôi đo thế nào (công khai)

SIEM: IBM QRadar CE 7.3.3, máy ảo đang chạy.
Máy tấn công: Kali → Máy nạn nhân: Ubuntu (rsyslog *.* @@qradar:514, TCP).
Với mỗi kỹ thuật: đánh dấu T0, thực hiện hành động thật, rồi truy vấn API Ariel của QRadar trong khung thời gian đo, ghi lại CÓ CẢNH BÁO (QID nào, MITRE, nguồn, MTTD) hoặc BỎ LỌT.
MTTD = thời điểm sự kiện đầu tiên được QRadar đánh chỉ mục − thời điểm bắt đầu tấn công (các máy đồng bộ NTP; giữa các máy có thể lệch ± vài giây).
Cách đo này giống hệt logic của connector QRadar trong VCyber Twin, cũng là công cụ chúng tôi trỏ vào SIEM của chính khách hàng.

Bằng chứng gốc (phần Vol.1 còn thiếu)

T1110.001 → ALERTED QID : "User failed to login to SSH, incorrect password" src : 192.168.99.50 log : LinuxServer @ victim-ubuntu MTTD: 5.39 s (7 events) T1046 nmap scan → QRadar rows: 0 T1486 ransomware → QRadar rows: 0

Mọi con số ở đây đều có dữ liệu sự kiện Ariel được lưu lại và bộ công cụ tấn công đi kèm, chạy lại được khi cần. Không có số liệu nhập tay.

Ý nghĩa nếu đơn vị anh chị đang chạy QRadar

Báo cáo độ phủ của anh chị nói hệ thống đã được bảo vệ trước các kỹ thuật này. Hai trong ba kỹ thuật không để lại dấu vết nào trên console. Cách sửa không phải là thêm luật, mà là đo xem cái gì thực sự bật cảnh báo, bịt các khoảng hở telemetry (auditd, phát hiện qua mạng), rồi đo lại. Chạy lại → khoảng hở → tinh chỉnh → chạy lại.

Lấy con số của riêng anh chị: Detection Reality Check

Chúng tôi dựng một bản sao số (digital twin) tách biệt của SIEM của anh chị (QRadar / Splunk / Wazuh), chạy lại một bộ kỹ thuật cố định, và giao cho anh chị con số của chính anh chị: cái gì bật cảnh báo, cái gì im lặng, nhanh đến đâu, kèm kế hoạch sửa theo thứ tự ưu tiên. Bản sao được tách biệt; dữ liệu của anh chị không bao giờ rời khỏi môi trường của anh chị. Làm việc không đồng bộ, do người sáng lập trực tiếp làm, không cần họp trực tuyến.

Giới hạn, nói thẳng. Một hệ thống, một cấu hình telemetry, không suy rộng được thành "mọi QRadar". Hai ca bỏ lọt là do telemetry không được thu thập (sửa được bằng auditd hoặc một cảm biến mạng), không phải "QRadar không làm được". Báo cáo do chính nhà cung cấp viết; phương pháp để mở cho mọi người soi xét; các con số là phép đo thật trên một SIEM đang chạy, không phải khảo sát.

VCyber Twin

Detection Reality Index · Vol.2.1

Cập nhật: chúng tôi đã bịt khoảng hở và đo lại

Nửa còn lại của vòng lặp: chạy lại → khoảng hở → tinh chỉnh → chạy lại

Chúng tôi sửa hai điểm mù và chạy lại các cuộc tấn công: cả hai giờ đều bật cảnh báo

Vol.2 tìm ra hai kỹ thuật mà QRadar không hề thấy. Một lần kiểm tra thực tế chưa xong khi mới nói "anh chị có khoảng hở": nó phải chỉ ra khoảng hở nào và chứng minh cách sửa. Chúng tôi bịt phần telemetry trên chính môi trường thử QRadar 7.3.3 đang chạy đó rồi chạy lại. Cả hai điểm mù giờ đều có cảnh báo, và việc bịt chúng làm lộ ra phát hiện đáng chú ý nhất của cả đợt đo.

3,3s

MTTD cho dò quét mạng (T1046) sau khi thêm cảm biến mạng. Trước đó: 0 cảnh báo.

2 / 2

Điểm mù chuyển từ BỎ LỌT sang PHÁT HIỆN khi QRadar được cấp đúng telemetry

0 trên 51.937

Số luật bật cảnh báo cho lần quét cổng khi đã nạp đủ bộ luật ET, cho tới khi thêm vào một luật đúng

Phát hiện quan trọng hơn mọi con số MTTD ở đây

Chúng tôi nạp cho cảm biến mạng 51.937 luật phát hiện rồi chạy lại lần quét cổng. Số luật bật lên: 0. Thêm một luật ngưỡng viết riêng cho việc này, lần quét hiện cảnh báo sau 3,3 giây. Số luật đã nạp không phải là độ phủ. "Đã bật 51.937 luật" và "lần quét đã bị phát hiện" là hai khẳng định không liên quan gì đến nhau, cho tới khi anh chị chạy lại kỹ thuật đó và quan sát.

Đo lại: cùng môi trường thử, đã bịt telemetry

Kỹ thuật ATT&CK	Vol.2	Cách sửa đã áp dụng	Vol.2.1	MTTD
T1046 Network Service Discovery	BỎ LỌT	Thêm cảm biến mạng (Suricata) trên phân đoạn bị quét → cảnh báo được chuyển tiếp tới QRadar qua syslog.	CÓ CẢNH BÁO	3.27 s
T1486 Data Encrypted for Impact	BỎ LỌT	Bật ghi audit thao tác ghi tệp trên máy chủ (auditd + luật watch) → sự kiện syscall được chuyển tiếp tới QRadar.	CÓ CẢNH BÁO	gần thời gian thực*

* Sự kiện ghi tệp của T1486 được QRadar đánh chỉ mục dưới dạng telemetry syscall từ máy chủ. Trên môi trường thử bản Community Edition này, MTTD chính xác tới dưới một giây bị chi phối bởi độ trễ nạp dữ liệu của nền tảng (khoảng 60 đến 90 giây mới tìm kiếm được) cộng với độ lệch đồng hồ giữa các máy, không phải bởi logic phát hiện. Kết quả được ghi là "phát hiện được, gần thời gian thực tại cảm biến". Một QRadar có bản quyền/production sẽ bấm giờ việc này chính xác.

Điều này chứng minh gì về phương pháp

Giá trị không nằm ở câu "SIEM của anh chị kém", mà ở vòng lặp khép kín: đo cái gì thực sự bật cảnh báo, gọi đúng tên khoảng hở (thiếu cảm biến, audit bị tắt), bịt nó, rồi đo lại để xác nhận cảnh báo giờ đã đến nơi. Đó là kế hoạch khắc phục dựa trên bằng chứng, không phải một con số phần trăm độ phủ trên slide.

Bằng chứng gốc (lặp lại được)

T1046 nmap → ALERTED sid : 9000001 "Port Scan Detected" src : 192.168.99.50 → .20:443 MTTD: 3.27 s (QRadar-indexed) T1486 file-encrypt → ALERTED audisp-syslog SYSCALL openat key : ransom_write (log source: LinuxServer @ victim-ubuntu)

Nói thẳng. Đây là các bản sửa trên một môi trường thử, một cấu hình, và là kỹ thuật phát hiện tiêu chuẩn (một cảm biến mạng; audit trên máy chủ), không phải mẹo của sản phẩm. Đưa chúng ra để thấy lần kiểm tra thực tế tự khép vòng lặp của nó: nó chỉ ra chỗ nào đang mù, rồi chứng minh điều gì giúp chỗ đó nhìn thấy. Chạy lại → khoảng hở → tinh chỉnh → chạy lại.

Nếu anh chị muốn chạy việc này trên bản dựng của mình

Con số này đến từ môi trường thử của chúng tôi, và nó mô tả bản dựng đó, không phải hệ thống đang chạy của anh chị. Nếu anh chị muốn chạy đúng việc này trên một bản dựng SIEM mà anh chị quan tâm, toàn bộ các bậc làm việc đã được viết ra kèm giá, gồm cả những việc chúng tôi sẽ không làm.

Cách làm việc với chúng tôi · support@atkvn.com

Bậc đầu tiên trên thang đó miễn phí và chỉ cần một hostname, một cửa ngõ công khai mà anh chị đã có sẵn nhận định về nó. Anh chị không cần là chủ của hostname đó. Bậc này đo mật mã chứ không đo khả năng phát hiện, nhưng anh chị không tốn gì để xem chúng tôi viết thế nào, và trang mẫu đã được công bố.