XÁC ĐỊNH CÁC MÁY CHỦ CÓ THỂ ĐANG BỊ TẤN CÔNG HOẶC SỬ DỤNG TRÁI PHÉP TRÊN ORACLE DATABASE VÀ MICROSOFT SQL SERVER
1. Mục tiêu
- Thu thập các dấu hiệu tấn công trên từng máy chủ CSDL: đăng nhập thất bại, lỗi SQL, truy cập bị từ chối và vi phạm chính sách bảo mật (SQL injection, OS command injection…).
- Tổng hợp các dấu hiệu theo Server IP bằng báo cáo và dashboard để xếp hạng máy chủ theo mức độ nghi vấn.
- Dùng Active Threat Analytics để điều tra sâu các case theo máy chủ, phân biệt tấn công thật với hoạt động hợp lệ (dương tính giả).
- Xác định máy chủ nào cần ưu tiên điều tra và đề xuất hành động xử lý.
2. Nguyên lý hoạt động
Hình 1: Nguyên lý xác định máy chủ bị tấn công: gom bằng chứng theo Server IP, phân tích bằng dashboard, correlation alert và Active Threat Analytics, rồi đối chiếu để điều tra
3. Mô hình triển khai và chuẩn bị
3.1. Thành phần hệ thống
Thành phần | Tên máy / IP | Vai trò |
| Guardium Collector (đồng thời là Central Manager) | <IP_GUARDIUM> | Thu thập, phân tích, cảnh báo, chạy Active Threat Analytics |
| Oracle Database 19c trên Oracle Linux (service orcl) | oracledb01 / <IP_ORACLE> | Máy chủ bị tấn công giả lập, S-TAP Linux |
| Microsoft SQL Server trên Windows Server | SQLDB01 / <IP_MSSQL> | Máy chủ đối chứng (chỉ bị dò mật khẩu), S-TAP Windows |
| Nguồn tấn công giả lập | Chính oracledb01 và SQLDB01 | sqlplus chạy trên oracledb01, sqlcmd chạy trên SQLDB01, kết nối qua IP và cổng nên Client IP trùng Server IP |
3.2. Các chỉ báo phát hiện
Chỉ báo | Nơi Guardium ghi nhận | Dấu hiệu tấn công |
| Failed Login | Exception, Exception Type ID = LOGIN_FAILED (ORA-01017, MSSQL 18456) | Dò mật khẩu (brute-force), dò tên tài khoản |
| SQL Error | Exception, Exception Type ID = SQL_ERROR | Dò cấu trúc CSDL: truy vấn đối tượng không tồn tại, câu lệnh sai cú pháp |
| Truy cập bị từ chối | SQL_ERROR với mã lỗi quyền (ORA-01031, ORA-00942; MSSQL 229, 15247) | Thử đọc đối tượng hoặc chạy lệnh chưa được cấp quyền |
| Policy Violation | Policy violation log (rule có action ALERT hoặc LOG ONLY) | Câu lệnh khớp mẫu tấn công hoặc rule tự định nghĩa đang cài trong lab |
| Case ATA | Active Threat Analytics | Vi phạm lặp lại vượt ngưỡng (Threat finder) hoặc hoạt động bất thường so với hành vi nền (Outlier mining) của cùng một nguồn |
- Oracle trả ORA-00942 cả khi bảng không tồn tại lẫn khi user không có quyền trên bảng, nên cần đọc kèm tên đối tượng và DB User để phân biệt dò cấu trúc với truy cập trái phép.
4. Cấu hình Guardium
4.1. Cài thêm policy mẫu Basic Data Security Policy
Policy mẫu Basic Data Security Policy có sẵn các access rule phát hiện mẫu tấn công phổ biến; policy mẫu ở chế độ chỉ đọc nên phải clone trước khi cài.
Bước 1: Truy cập Protect → Security Policies → Policy Builder for Data, tích Include templates, chọn Basic Data Security Policy và nhấn Clone, đặt tên POL_BASIC_DATA_SECURITY.
Bước 1: Truy cập Protect → Security Policies → Policy Builder for Data, tích Include templates, chọn Basic Data Security Policy và nhấn Clone, đặt tên POL_BASIC_DATA_SECURITY.
Hình 2: POL_BASIC_DATA_SECURITY sau khi clone từ policy mẫu
Bước 2: Mở POL_BASIC_DATA_SECURITY và kiểm tra 11 rule theo bảng dưới. Các rule phát hiện mẫu tấn công có action ALERT PER MATCH, Severity HIGH và tích Continue to next rule; các rule ghi log giữ nguyên.
Rule có sẵn trong policy mẫu | Phát hiện |
| Cross-Site Scripting (XSS) | Mã script được ghi vào dữ liệu |
| SQL Injection - Tautology | Biểu thức luôn đúng chèn vào điều kiện WHERE/HAVING |
| SQL Injection - Side channel | Kỹ thuật dò dữ liệu dựa trên thời gian phản hồi |
| SQL Injection - Denial Of Service | Hàm làm CSDL xử lý rất lâu để gây quá tải |
| OS Command Injection | Chuỗi gọi lệnh hệ điều hành trong câu SQL |
| Log Violation on more than 5 failed login in one minute | Từ 5 lần đăng nhập sai trong 1 phút (LOG ONLY) |
| Log Violation on Risk-indicative Error Messages | Lỗi trả về thuộc group Risk-indicative Error Messages (LOG ONLY) |
| Data Exfiltration | Một phiên lấy trên 5000 bản ghi (LOG ONLY) |
| Các rule còn lại | Ghi log che giá trị cho admin và lệnh quản trị; bỏ qua phiên tải nặng (từ 500 lệnh/phút) |
Hình 3: Các rule có sẵn trong POL_BASIC_DATA_SECURITY (clone từ policy mẫu)
Bước 3: Mở POL_PROTECT_SENSITIVE_DATA, tích Continue to next rule cho LOG_SENSITIVE_ACCESS và kiểm tra DET_BRUTE_FORCE, DET_SQL_ERROR_BURST đã bật sẵn Continue to next rule. Các rule này đứng trước rule của policy mẫu; nếu không bật, câu lệnh trên bảng nhạy cảm và các lỗi đăng nhập, lỗi SQL dừng ở POL_PROTECT_SENSITIVE_DATA và không tới được policy mẫu.
Bước 4: Cài lại POL_PROTECT_SENSITIVE_DATA bằng Install and override, sau đó chọn POL_BASIC_DATA_SECURITY, nhấn Install → Install last. Không dùng Install and override cho policy mẫu vì thao tác này gỡ toàn bộ policy đang cài, kể cả POL_PROTECT_SENSITIVE_DATA.
Bước 5: Kiểm tra thứ tự cài đặt: POL_PROTECT_SENSITIVE_DATA đứng thứ 1 (Installation order = 1, 21 rule), POL_BASIC_DATA_SECURITY đứng thứ 2 (Installation order = 2, 11 rule), như mục Currently Installed Policies trong Policy Installation.
Bước 4: Cài lại POL_PROTECT_SENSITIVE_DATA bằng Install and override, sau đó chọn POL_BASIC_DATA_SECURITY, nhấn Install → Install last. Không dùng Install and override cho policy mẫu vì thao tác này gỡ toàn bộ policy đang cài, kể cả POL_PROTECT_SENSITIVE_DATA.
Bước 5: Kiểm tra thứ tự cài đặt: POL_PROTECT_SENSITIVE_DATA đứng thứ 1 (Installation order = 1, 21 rule), POL_BASIC_DATA_SECURITY đứng thứ 2 (Installation order = 2, 11 rule), như mục Currently Installed Policies trong Policy Installation.
Hình 4: POL_PROTECT_SENSITIVE_DATA và POL_BASIC_DATA_SECURITY cùng được cài đặt theo thứ tự 1, 2
4.2. Tạo báo cáo và dashboard theo máy chủ
Bước 1: Tại Reports → Report Configuration Tools → Query-Report Builder, tạo bốn query gom nhóm theo Server IP:
- Q_SRV_THREAT_SUMMARY (domain Exceptions): chọn cột Server IP và Exception Type ID, tích ô Count để Guardium gom nhóm; sắp xếp theo Count giảm dần; hiển thị dạng biểu đồ cột. Mỗi dòng là số lần đăng nhập sai hoặc lỗi SQL của một máy chủ.
- Q_SRV_FAILED_LOGINS (domain Exceptions): các cột Server IP, Client IP, DB User Name, Service Name, tích Count; điều kiện Exception Type ID = LOGIN_FAILED; sắp xếp theo Count giảm dần.
- Q_SRV_SQL_ERRORS (domain Exceptions): các cột Exception Timestamp, Server IP, Client IP, DB User Name, Exception Description, SQL string that caused the Exception; điều kiện Exception Type ID = SQL_ERROR; sắp xếp theo Exception Timestamp giảm dần.
- Q_SRV_POLICY_VIOLATIONS (domain Policy Violations): các cột Server IP, Access Rule Description, Category Name, Severity Description, Client IP, DB User Name, tích Count; sắp xếp theo Count giảm dần.
Trong domain Exceptions, Server IP, Client IP, DB User Name và Service Name nằm ở entity Client/Server; Exception Timestamp, Exception Type ID, Exception Description và SQL string that caused the Exception nằm ở entity Exception. Trường Exception Type ID chỉ hiển thị với tài khoản có role admin.
Bước 2: Tạo dashboard tại My Dashboards → Create New Dashboard, đặt tên Server Threat Overview, sau đó mở từng query và chọn Add to Dashboard.
Bước 2: Tạo dashboard tại My Dashboards → Create New Dashboard, đặt tên Server Threat Overview, sau đó mở từng query và chọn Add to Dashboard.
Hình 5: Dashboard Server Threat Overview
Ảnh dùng khoảng thời gian khác lúc kiểm thử (từ 14:17, riêng Q_SRV_POLICY_VIOLATIONS từ 21:17) nên Q_SRV_FAILED_LOGINS còn gồm 25 lần đăng nhập sai của OPS_TEST trên SQLDB01 từ các lần kiểm thử khác. Số liệu đúng khung giờ kiểm thử xem ở mục 6.1 (Hình 12).
4.3. Cảnh báo khi một máy chủ bị dò mật khẩu từ nhiều nguồn
DET_BRUTE_FORCE đếm theo từng Client IP nên bỏ sót trường hợp nhiều nguồn cùng nhắm vào một máy chủ, mỗi nguồn chỉ thử vài lần để lọt dưới ngưỡng. Exception rule cũng không đếm riêng theo máy chủ được: dấu chấm (.) không áp dụng cho Server IP, mọi lựa chọn của trường này (mọi máy chủ, IP + mask, group) dùng chung một bộ đếm. Vì vậy dùng correlation alert: Guardium chạy định kỳ một query gom nhóm theo Server IP và so ngưỡng trên từng dòng, mỗi máy chủ một bộ đếm.
Bước 1: Trong Query-Report Builder, tạo query Q_SRV_LOGIN_ALERT (domain Exceptions): cột Server IP (Value) và Exception Timestamp với Field Mode = Max, tích Count; điều kiện Exception Type ID = LOGIN_FAILED.
Bước 1: Trong Query-Report Builder, tạo query Q_SRV_LOGIN_ALERT (domain Exceptions): cột Server IP (Value) và Exception Timestamp với Field Mode = Max, tích Count; điều kiện Exception Type ID = LOGIN_FAILED.
- Alert Builder chỉ liệt kê query có ít nhất một trường thời gian và cột Count. Exception Timestamp để ở chế độ Value sẽ tách mỗi thời điểm thành một dòng có Count gần bằng 1, làm mất gom nhóm theo máy chủ, nên phải chọn Max. Nếu query không hiện trong danh sách, thử chuyển Field Mode sang Min.
Hình 6: Query Q_SRV_LOGIN_ALERT dùng cho correlation alert
Bước 2: Truy cập Protect → Database Intrusion Detection → Alert Builder, nhấn New và khai báo theo bảng dưới, sau đó nhấn Save.
Trường | Giá trị | Ý nghĩa |
| Name | ALR_SRV_LOGIN_FAILED | |
| Description | Server received 10 or more failed logins within 10 minutes | Hiện ở cột Access Rule Description khi alert ghi vi phạm |
| Severity | HIGH | |
| Run Frequency | 10 | Chạy query mỗi 10 phút |
| Active; Log Policy Violation | Tích cả hai | Bật alert; ghi kết quả vào domain Policy Violations để xem chung với vi phạm của policy |
| Query | Q_SRV_LOGIN_ALERT | |
| Accumulation Interval | 10 | Query xét dữ liệu 10 phút gần nhất |
| Log full query results | Tích | |
| Column | Count of Exceptions | Cột Count của query, dùng để so ngưỡng |
| Threshold; Alert condition | 10; >= | Cảnh báo khi một máy chủ có từ 10 lần đăng nhập sai |
| Threshold Evaluated | per line | So ngưỡng cho từng dòng, tức là từng máy chủ |
| Threshold Used | As absolute limit | Ngưỡng là số tuyệt đối |
| Receivers | Tùy chọn (MAIL, Syslog…) | Gửi thông báo ra ngoài |
- Ngưỡng 10 cao hơn ngưỡng 5 của DET_BRUTE_FORCE vì máy chủ nhận lỗi từ mọi nguồn, kể cả người dùng hợp lệ gõ nhầm mật khẩu.
- Correlation alert không tức thời: cảnh báo xuất hiện chậm tối đa bằng Run Frequency (10 phút).
- Vi phạm do correlation alert ghi vào Policy Violations có Server IP, Client IP, DB User Name = N/A vì alert không gắn với một phiên kết nối, cột Access Rule Description hiện Description của alert; máy chủ cụ thể xem ở Q_SRV_FAILED_LOGINS.
Hình 7: Correlation alert ALR_SRV_LOGIN_FAILED trong Alert Builder
Bước 3: Truy cập Setup → Tools and Views → Anomaly Detection, tích Active on Startup và khởi động tiến trình. Anomaly Detection là tiến trình chạy các correlation alert. Nếu cần gửi thông báo qua email hoặc syslog, bật thêm Alerter tại Setup → Tools and Views → Alerter.
5. Sinh traffic kiểm thử
Kịch bản có đối chứng: oracledb01 nhận đủ bốn loại dấu hiệu, SQLDB01 chỉ bị dò mật khẩu. Các lệnh chạy ngay trên máy chủ CSDL nhưng luôn kết nối qua IP và cổng để S-TAP ghi nhận được.
5.1. Kịch bản 1 – Dò mật khẩu trên oracledb01 và SQLDB01
Dùng tài khoản HACKER_SIM không tồn tại để không làm khóa tài khoản thật. Mỗi lần đăng nhập là một kết nối mới qua listener/TCP; dùng vòng lặp để thử 10 lần liên tiếp.
Oracle (bash trên oracledb01):for i in $(seq 1 10); do
sqlplus -L -S hacker_sim/"Sai#2026"@//<IP_ORACLE>:1521/orcl </dev/null
done
SQL Server (PowerShell trên SQLDB01):
1..10 | ForEach-Object {
sqlcmd -S <IP_MSSQL>,1433 -U hacker_sim -P "Sai#2026" -No -Q "SELECT 1" }
- Tùy chọn -L của sqlplus chỉ thử đăng nhập một lần rồi thoát, -S bỏ phần banner, </dev/null để lệnh không dừng chờ nhập.
Hình 8: Đăng nhập sai bằng HACKER_SIM trên oracledb01, SQLDB01 và các vi phạm ghi nhận trong Q_SRV_POLICY_VIOLATIONS
Đánh giá: Guardium ghi nhận đủ 10 lần đăng nhập sai trên mỗi máy chủ; DET_BRUTE_FORCE, rule đăng nhập sai của policy mẫu và ALR_SRV_LOGIN_FAILED đều phát hiện đúng. Vi phạm của correlation alert không gắn Server IP (dòng N/A) nên cần Q_SRV_FAILED_LOGINS để xác định máy chủ bị dò.
5.2. Kịch bản 2 – Dò cấu trúc CSDL
Đăng nhập oracledb01 bằng INTERN_TEST, chạy lần lượt các câu lệnh lỗi sau, tổng cộng 14 câu trong vòng 5 phút để vượt ngưỡng của DET_SQL_ERROR_BURST:
Oracle:sqlplus intern_test/"<MK_INTERN_TEST>"@//<IP_ORACLE>:1521/orcl
SQL> SELECT * FROM retail.customers_backup;
SQL> SELECT * FROM retail.users;
-- tương tự với customers_old, staff, payments, invoices, accounts
SQL> SELECT full_name FORM retail.customers;
SQL> SELECT * FROM retail.customers WHERE;
SQL> SELECT * FROM retail.orders WHERE id = ;
SQL> SELECT full_name FROM retail.customers ORDER full_name;
-- tương tự với customers_bak, suppliers
SQL> SELECT * FROM retail.products WHERE price >;
Hình 9: Q_SRV_SQL_ERRORS ghi nhận 14 lỗi SQL của INTERN_TEST trên oracledb01 và vi phạm DET_SQL_ERROR_BURST
Đánh giá: Guardium ghi nhận đủ 14 lỗi SQL và DET_SQL_ERROR_BURST phát hiện đúng hành vi dò cấu trúc. Rule chỉ sinh một vi phạm mức MED cho cả đợt, nên muốn biết bảng nào bị dò phải xem Q_SRV_SQL_ERRORS.
5.3. Kịch bản 3 – Thử leo thang đặc quyền
Oracle (tiếp tục phiên INTERN_TEST):SQL> CREATE USER test_user01 IDENTIFIED BY "<MK_TEST_USER01>";
SQL> GRANT DBA TO intern_test;
Hình 10: CREATE USER và GRANT DBA bị từ chối (ORA-01031), vi phạm DET_PRIV_ESCALATION
Đánh giá: Oracle từ chối cả hai lệnh nhưng DET_PRIV_ESCALATION vẫn cảnh báo mức HIGH. Báo cáo chỉ ghi 1 vi phạm cho hai lệnh; hai dòng ORA-01031 trong Q_SRV_SQL_ERRORS (Hình 5) là câu GRANT và một câu bắt đầu bằng "SELEC…".
5.4. Kịch bản 4 – Mẫu SQL injection
Trong phiên INTERN_TEST, chạy câu truy vấn có điều kiện luôn đúng (tautology) trên bảng retail.customers:
SQL> SELECT customer_id, full_name, phone FROM retail.customers WHERE customer_id = '1' OR '1'='1';
Hình 11: Vi phạm SQL Injection - Tautology của INTERN_TEST trên oracledb01 (dòng dưới là DET_SQLI_PATTERN của NT SERVICE\SQLTELEMETRY trên SQLDB01)
Đánh giá: Câu tautology chạy thành công, trả về toàn bộ 60 dòng thay vì 1 dòng; Guardium phát hiện bằng cả DET_SQLI_PATTERN, SQL Injection - Tautology của policy mẫu và DET_MASS_EXTRACTION. Hạn chế: policy chỉ cảnh báo, không chặn; muốn chặn cần S-GATE TERMINATE cho nguồn vi phạm.
6. Phân tích và xác định máy chủ bị tấn công
6.1. Phân tích dấu hiệu theo máy chủ
Mở dashboard Server Threat Overview, chọn khoảng thời gian bao trùm lúc kiểm thử (Hình 12 dùng khoảng 16:55 – 19:57 ngày 07/10/2026) và so sánh số exception, vi phạm giữa các máy chủ.
Hình 12: Số exception theo máy chủ (Q_SRV_THREAT_SUMMARY) và các vi phạm policy (Q_SRV_POLICY_VIOLATIONS)
- DET_SQLI_PATTERN trên SQLDB01 thuộc NT SERVICE\SQLTELEMETRY, dịch vụ thu thập số liệu (CEIP) có sẵn của SQL Server có truy vấn nội bộ khớp regex của rule, nên là dương tính giả. Trong vận hành thật, loại tài khoản này khỏi rule bằng điều kiện DB User Not In Group (group tài khoản dịch vụ tin cậy).
Đánh giá: Dashboard tách rõ hai máy chủ: oracledb01 có đủ đăng nhập sai, lỗi SQL và nhiều loại vi phạm trong cùng khung giờ nên được ưu tiên điều tra trước; SQLDB01 chỉ bị dò mật khẩu, vi phạm SQL injection duy nhất là dương tính giả.
6.2. Điều tra chi tiết máy chủ nghi vấn
Lọc ba báo cáo chi tiết (Q_SRV_FAILED_LOGINS, Q_SRV_SQL_ERRORS, Q_SRV_POLICY_VIOLATIONS) theo Server IP = <IP_ORACLE> để trả lời các câu hỏi điều tra:
Câu hỏi | Trường dữ liệu | Kết quả trên oracledb01 |
| Ai tấn công? | Client IP, DB User Name, Source Program | Client IP <IP_ORACLE> (chạy tại chỗ); HACKER_SIM dò mật khẩu, INTERN_TEST thực hiện các bước sau |
| Khi nào? | Exception Timestamp, Timestamp | 18:39 – 19:55 ngày 07/10/2026, ngoài giờ làm việc |
| Làm gì? | SQL string that caused the Exception, Access Rule Description | Truy vấn 9 bảng không tồn tại, 5 câu sai cú pháp, CREATE USER, GRANT DBA, câu tautology |
| Kết quả? | Exception Description | Đăng nhập và lệnh đặc quyền bị từ chối (ORA-01017, ORA-01031); câu tautology trả về toàn bộ 60 dòng |
Đánh giá: Ba báo cáo chi tiết trả lời đủ ai, khi nào, làm gì trên oracledb01: INTERN_TEST dò cấu trúc, thử leo thang và chạy được câu tautology ngoài giờ, cần khóa tài khoản này. Hạn chế: Client IP trùng Server IP do lệnh chạy tại chỗ.
6.3. Phân tích bằng Active Threat Analytics
Active Threat Analytics (ATA) gom các sự kiện bảo mật theo nguồn (máy chủ, IP, user) thành observation rồi tương quan thành case mức High / Medium / Low. Case được tạo bởi Threat finder (dựa trên vi phạm policy) hoặc Outlier mining (dựa trên hoạt động bất thường so với hành vi nền).
a) Điều kiện để ATA tạo case- Threat finder: với rule trong policy tự tạo hoặc clone, case chỉ được mở khi rule có Severity HIGH, action ALERT PER MATCH, đã được gắn ngưỡng và số vi phạm trong 1 giờ vượt ngưỡng đó. Gắn ngưỡng trên CLI của Collector, sau đó kiểm tra lại:
grdapi list_rules_with_threshold
- Outlier mining cần 14 ngày học hành vi nền nên case dạng bất thường (ví dụ Possible data leak) chỉ xuất hiện sau giai đoạn này; case từ Threat finder (SQL injection, brute force) xuất hiện sớm hơn.
Bước 1: Truy cập Protect → Uncover Threat Vectors → Active Threat Analytics, chọn khoảng thời gian bao trùm thời điểm kiểm thử.
Bước 2: Đọc phần tổng quan: số case theo mức độ (Cases) và số nguồn có case đang mở (Sources with open cases: Databases, DB Users, OS Users).
Bước 3: Ở danh sách case, xem cột Threat Category, Severity, Observations, Source (Server, Database, DB User) và Period. Ban đầu chỉ có 2 case Brute-force attack mức Low, mỗi máy chủ một case (Hình 14); chưa có case SQL injection vì rule SQL Injection - Tautology chưa được gắn ngưỡng. Sau khi gắn ngưỡng (phần a) và chạy lại câu tautology, ATA mở thêm case 3 SQL Injection - Tautology mức High (phần c).
Bước 2: Đọc phần tổng quan: số case theo mức độ (Cases) và số nguồn có case đang mở (Sources with open cases: Databases, DB Users, OS Users).
Bước 3: Ở danh sách case, xem cột Threat Category, Severity, Observations, Source (Server, Database, DB User) và Period. Ban đầu chỉ có 2 case Brute-force attack mức Low, mỗi máy chủ một case (Hình 14); chưa có case SQL injection vì rule SQL Injection - Tautology chưa được gắn ngưỡng. Sau khi gắn ngưỡng (phần a) và chạy lại câu tautology, ATA mở thêm case 3 SQL Injection - Tautology mức High (phần c).
Hình 13: Danh sách case trên Active Threat Analytics: SQL Injection - Tautology (High) và 2 case Brute-force attack (Low)
Hình 14: Database Behavioral Analytics của oracledb01 và SQLDB01: mỗi máy chủ một case Brute-force attack mức Low
Bước 4: Mở case bằng biểu tượng trang ở cột Case #: xem Observations, các link SQL Report, Full SQL Report, SQL Exceptions Report, danh sách Policy rule violations và bảng so sánh mức hoạt động của case với mức trung bình của nguồn (ví dụ case 3 ở Hình 15).
- Case dương tính giả: ghi lý do bằng Add comment, đóng case bằng Actions → Close case hoặc chọn Add to exclusion list.
Bước 5: Chuyển sang phần Exploration để trả lời Where (máy chủ, database), When (giờ làm việc hay ngoài giờ), What (case tương tự, đối tượng nhạy cảm bị truy cập), Who (user, máy client) và How (ứng dụng sử dụng); ví dụ phần Where của case 3 ở Hình 16.
c) Case SQL Injection - Tautology sau khi gắn ngưỡng- Loại và mức độ: SQL Injection - Tautology, mức High; nguồn là DB User INTERN_TEST trên database ORCL của máy chủ <IP_ORACLE>.
- Observations: "User executed 9 tautological expressions", tức 9 lần vi phạm trong 1 giờ, vượt ngưỡng 3 nên case được tạo.
- Policy rule violations: liệt kê từng câu vi phạm kèm thời điểm, Client IP và Full SQL String. Câu lệnh đã được Guardium chuẩn hóa, các giá trị thay bằng dấu ? (WHERE customer_id = ? OR ?=?).
- Source activities: INTERN_TEST chưa được Risk Spotter xác định là user rủi ro; ATA gợi ý thêm user này vào nhóm Watchlist để theo dõi chặt hơn.
Hình 15: Tổng quan case 3 – SQL Injection - Tautology của INTERN_TEST trên oracledb01
Ở phần Where của tab Exploration, ATA cho biết máy chủ <IP_ORACLE> có 2 database Oracle (dữ liệu từ 04/10/2026) và đây là case SQL Injection - Tautology đầu tiên trên database này kể từ 06/10/2026.
Hình 16: Phân tích theo vị trí (Where) của case 3
Đánh giá: ATA tạo đúng case Brute-force (Low) cho mỗi máy chủ và case SQL Injection - Tautology (High) cho INTERN_TEST. Case 1 trên SQLDB01 còn ghi RETAIL_APP, OPS_TEST đăng nhập sai rồi chạy SQL, cần xác minh. Hạn chế: rule clone phải gắn ngưỡng mới sinh case.
