Security Monitoring Baseline không phải một threshold cố định. Nó là một record có version mô tả trạng thái và hành vi kỳ vọng của website trong một observation window đủ đại diện, có owner, known exceptions và rule rõ cho việc cập nhật. Baseline tốt giúp trả lời: đây là thay đổi hợp lệ, deviation cần theo dõi hay anomaly cần escalation?
Nếu không có baseline, monitoring thường rơi vào hai cực: alert quá nhiều vì mọi thay đổi đều bị coi là bất thường, hoặc threshold quá rộng khiến tín hiệu quan trọng bị bỏ qua. Ngược lại, nếu “học lại baseline” mỗi khi có anomaly chưa giải thích, hệ thống có thể biến hành vi xấu thành trạng thái bình thường mới.
Baseline nên được hiểu như thế nào?
Website thay đổi theo giờ, ngày, chiến dịch, deployment, backup, maintenance và workload. Vì vậy baseline nên là một tập profile/range theo context thay vì một con số duy nhất. Request rate ngày làm việc có thể khác cuối tuần; CPU lúc backup có thể khác low-traffic window; admin login trong ca trực có thể khác login lúc 02:00 từ nguồn chưa từng thấy.
Baseline vận hành mô tả website chạy bình thường thế nào. Baseline bảo mật tập trung vào những trạng thái có giá trị phát hiện: account hợp lệ, component hợp lệ, file kỳ vọng, cron kỳ vọng, network/service kỳ vọng, traffic profile và các control đang hoạt động. Hai loại liên quan nhưng không giống nhau.
Baseline Record: cấu trúc tối thiểu nên có
| Field | Mục đích |
|---|---|
| Baseline ID / version | Biết đang so với version nào và rollback được |
| Asset / scope | Website, WordPress, server, CDN/WAF, DNS nào nằm trong baseline |
| Observation window | Khoảng dữ liệu dùng để học trạng thái kỳ vọng |
| Owner | Ai chịu trách nhiệm review/approve |
| Signal profile | Expected range, trend hoặc known state |
| Known exceptions | Backup, deploy, campaign, maintenance, cron hợp lệ |
| Change reason | Vì sao baseline được cập nhật |
| Validation | Detection test nào đã chạy sau update |
| Next review | Khi nào baseline phải được review lại |
Những signal nên có trong baseline website
Account và quyền truy cập
Ghi danh sách account đặc quyền, role/capability, nguồn đăng nhập thường gặp, khung giờ làm việc, MFA/session behavior và quy trình tạo/thu hồi account. Với WordPress, các thay đổi Administrator nên đối chiếu với monitoring đăng nhập và tài khoản Admin.
Plugin, theme, core và file quan trọng
Baseline cần inventory version, active/inactive state, nguồn cài đặt, owner và expected change path. Với file, phân biệt vùng ổn định, vùng thay đổi có kiểm soát và vùng generated/cache. Khi cần theo dõi sâu, dùng File Integrity Monitoring và component monitoring.
WP-Cron và scheduled activity
Inventory event, callback, schedule, plugin/owner và expected execution window. Cron mới không có owner hoặc callback trỏ tới artefact lạ là deviation cần điều tra; cron thay đổi theo plugin update hợp lệ có thể là known change nhưng vẫn cần record.
Traffic, WAF và endpoint profile
Theo dõi request rate, endpoint distribution, status code, source pattern, WAF rule hit, challenge/rate-limit và trend theo thời gian. Không dùng một request/giây threshold cho mọi site; baseline phải phản ánh business traffic và known event.
Resource và service state
CPU, RAM, disk, I/O, process, connection và worker utilization cần được đặt trong context workload. Resource saturation chỉ đáng escalation khi deviation đủ lớn hoặc correlate với traffic/process/security event khác.
Để chọn signal trước khi xây baseline, xem Website Security Signals.
Baseline Matrix mẫu
Các giá trị dưới đây là field mẫu để điền bằng dữ liệu thật của hệ thống, không phải ngưỡng chuẩn cho mọi website.
| Signal | Observation window | Expected profile | Known exception | Escalation rule |
|---|---|---|---|---|
| Request rate | 7–30 ngày hoặc đủ chu kỳ | P50/P95 theo giờ/ngày | Campaign, crawl, deploy | Deviation kéo dài + signal khác |
| Admin login | Theo ca làm việc | Account/source/time profile | On-call, remote work | Nguồn mới + privilege/config change |
| File change | Qua release cycle | Path/change owner dự kiến | Deploy/auto-update | Change ngoài window hoặc không owner |
| CPU/RAM/I/O | Qua peak + maintenance | Distribution theo workload | Backup/import | Saturation kéo dài + error/traffic anomaly |
| WAF rule hit | Đủ chu kỳ traffic | Rule/profile theo route | Campaign/bot hợp lệ | Trend mới + origin impact |
Cách xây baseline từng bước
- Khóa scope: website, WordPress, server, WAF/CDN và DNS nào nằm trong monitoring.
- Chọn signal có owner: chỉ lấy signal mà khi deviation xuất hiện có người và action rõ.
- Thu observation window đủ đại diện: phải đi qua workload, maintenance và business cycle chính.
- Ghi known exceptions: backup, deploy, campaign, cron, change window.
- Định nghĩa expected profile: dùng range, trend, state hoặc distribution phù hợp thay vì một threshold duy nhất.
- Kiểm thử detection: tạo một thay đổi hợp lệ có kiểm soát để xác minh telemetry và alert path hoạt động.
- Approve baseline version: có owner, change reason và next review.
Thu baseline trong bao lâu?
Không có thời gian cố định cho mọi website. Điều quan trọng là observation window phải bao phủ các chu kỳ quyết định: peak/low traffic, backup, maintenance, deploy, business day/weekend và event định kỳ. Một site ổn định có thể hình thành baseline hữu ích nhanh hơn hệ thống có seasonal traffic hoặc nhiều campaign.
Nếu window chưa đủ để đại diện, baseline nên được đánh dấu PROVISIONAL thay vì coi là production truth.
Khi nào baseline phải cập nhật?
Review sau thay đổi kiến trúc hoặc vận hành có thể làm expected state thay đổi: cài/gỡ plugin/theme, đổi hosting, thêm CDN/WAF, đổi login/SSO, đổi cron, DNS, cache layer, backup architecture hoặc campaign traffic lớn.
Không cập nhật baseline chỉ vì alert nhiều. Trước hết phải xác định alert đến từ legitimate change, threshold chưa tốt, telemetry lỗi hay anomaly thật. Chỉ khi change hợp lệ đã được xác nhận mới đưa nó vào expected state mới.
Change Gate: khi nào được “học lại” baseline?
| Điều kiện | PASS | FAIL |
|---|---|---|
| Change có owner | Có ticket/deploy/change record | Không biết ai thay đổi |
| Reason hợp lệ | Architecture/business change rõ | Chỉ vì muốn giảm alert |
| Evidence | Signal mới khớp legitimate change | Anomaly chưa giải thích |
| Detection test | Anomaly test vẫn được phát hiện | Tuning làm mất detection |
| Rollback | Giữ baseline version trước | Không thể quay lại profile cũ |
Baseline Record mẫu
Đây là worksheet để điền bằng dữ liệu thật; không phải evidence đã được thu sẵn.
baseline_id: BL-YYYY-NNN
asset: example.com
version: v1
status: provisional|approved|retired
window_start_utc: ...
window_end_utc: ...
owner: ...
signals:
- name: request_rate
expected_profile: ...
known_exceptions: ...
escalation_rule: ...
- name: admin_login
expected_profile: ...
known_exceptions: ...
change_reason: initial|architecture-change|incident-review
approved_by: ...
validation_test: ...
rollback_to: ...
next_review: ...
Baseline liên quan thế nào tới threshold và false positive?
Threshold là rule quyết định khi nào signal tạo alert; baseline cung cấp context để đặt threshold. Thiết kế tốt thường kết hợp threshold tuyệt đối, deviation so với baseline và correlation nhiều signal.
Ví dụ login admin từ nguồn mới có thể là medium; nếu ngay sau đó xuất hiện plugin mới và file change thì severity phải tăng. Đây là bước nối sang thiết kế rule, threshold và severity. Khi false positive tăng, xem cách giảm cảnh báo sai.
PASS/FAIL cho một baseline vận hành được
- PASS: baseline có version, owner, observation window, expected profile, known exceptions, change gate và detection test.
- FAIL: baseline là vài threshold không có context, không biết source data có đầy đủ hay không, hoặc tự học lại từ anomaly chưa điều tra.
- ROLLBACK: nếu tuning làm alert quality xấu hơn hoặc bỏ sót anomaly test, quay về version trước và mở lại change review.
Những lỗi cần tránh
- Dùng một baseline cho mọi website.
- Không ghi maintenance/change window.
- Không version baseline sau thay đổi lớn.
- Tự động học lại khi anomaly chưa được điều tra.
- Chỉ baseline traffic mà bỏ account, file, component, cron và resource.
- Không kiểm telemetry health nên baseline được xây trên dữ liệu thiếu.
- Không có rollback nên không biết tuning nào làm detection suy giảm.
Nguồn tham khảo
- NIST Cybersecurity Framework 2.0.
- WP-CLI: wp core verify-checksums.
- WordPress Plugin Handbook: Cron.
- WordPress: Roles and Capabilities.
Kết luận
Security Monitoring Baseline chỉ có giá trị khi nó là một versioned operating record, không phải bảng threshold tĩnh. Baseline phải có owner, observation window, expected profile, known exceptions, change gate, detection test và rollback. Làm được vậy, monitoring mới giảm false positive mà không phải đánh đổi khả năng phát hiện anomaly thật.