Security drift xuất hiện khi một hệ thống từng được harden đúng nhưng dần lệch khỏi baseline sau nhiều thay đổi vận hành: emergency fix, plugin mới, rule firewall mở tạm, account cũ chưa thu hồi, logging bị tắt hoặc service được bật lại để troubleshooting rồi không revert.
NIST SP 800-128 xem secure baseline, change control và monitoring là một vòng quản trị liên tục; monitoring cần phát hiện misconfiguration, component ngoài dự kiến và thay đổi trái phép so với baseline. NIST SP 800-70 Rev.5 năm 2026 cũng mô tả security checklist như công cụ để cấu hình, xác minh và phát hiện unauthorized configuration changes. Microsoft hiện khuyến nghị continuous configuration assessment vì manual changes và emergency modifications có thể tạo configuration drift theo thời gian. Nguồn: NIST SP 800-128, NIST SP 800-70 Rev.5 và Microsoft Cloud Security Benchmark — Posture Management.
Bối cảnh: baseline tốt nhưng security posture dần lệch
Giả sử website đã được hardening sau một security audit: SSH giới hạn source, admin account được review, PHP execution bị giới hạn, logging bật đầy đủ và firewall theo least privilege. Sáu tháng sau, website vẫn hoạt động bình thường nhưng một Managed Security Review phát hiện nhiều thay đổi nhỏ đã tích tụ thành security drift.
Những dấu hiệu thường gặp
- Firewall rule mở rộng hơn baseline nhưng không có change record.
- Service cũ được bật lại và vẫn listen sau maintenance.
- Tài khoản admin hoặc API credential không còn owner rõ ràng.
- Logging/alert rule bị tắt trong troubleshooting và chưa bật lại.
- Plugin/package mới làm thay đổi attack surface nhưng baseline chưa cập nhật.
- Exception tạm thời tồn tại lâu hơn thời hạn phê duyệt.
Investigation: so current state với approved baseline
Bước 1: xác định baseline còn hiệu lực
Baseline không phải snapshot bất biến mãi mãi. NIST định nghĩa baseline configuration là tập cấu hình đã được review và chấp thuận, dùng làm điểm chuẩn cho các thay đổi sau đó. Vì vậy trước khi gọi một khác biệt là drift, cần xác định baseline hiện hành, thời điểm phê duyệt và các change hợp lệ kể từ đó.
Nếu baseline quá cũ hoặc không phản ánh architecture hiện tại, review phải tách giữa legitimate evolution và uncontrolled drift.
Bước 2: diff theo control thay vì chỉ diff file
Security drift cần được xem ở nhiều lớp: network exposure, service/port, account/privilege, patch level, logging, backup, WAF rule, TLS, application config và credential ownership. Một file config không đổi không có nghĩa control vẫn hiệu lực nếu upstream dependency hoặc runtime state đã thay đổi.
Microsoft nhấn mạnh continuous assessment vì compute và cloud resources thay đổi thường xuyên qua patch, deployment và administrative modification; drift có thể xuất hiện ngay cả khi từng thay đổi riêng lẻ đều có lý do hợp lệ.
Bước 3: truy nguyên change nào tạo drift
Với mỗi deviation, cần map về change ticket, owner, maintenance window hoặc emergency action. Nếu không tìm thấy nguồn thay đổi, confidence về uncontrolled drift tăng. Nếu tìm thấy change hợp lệ nhưng baseline chưa được cập nhật, vấn đề nằm ở configuration governance.
Đọc thêm Managed Security Review, Continuous Security Improvement và Managed Security Report để chuẩn hóa review, evidence và action register.
Khi nào security drift trở thành finding?
Không phải mọi khác biệt với baseline đều là lỗi. Drift trở thành security finding khi deviation làm suy yếu control, tăng attack surface hoặc tồn tại ngoài change process đã chấp thuận.
- Deviation không có owner hoặc change record.
- Temporary exception đã hết hạn nhưng vẫn tồn tại.
- Control quan trọng như MFA, logging, firewall hoặc backup bị giảm hiệu lực.
- Exposure mới xuất hiện ngoài architecture dự kiến.
- Repeated drift xuất hiện lại sau nhiều review cycle.
Remediation: kéo current state về baseline hoặc re-baseline có kiểm soát
Sửa deviation có risk trước
- Đóng exposure hoặc rule mở rộng không còn cần thiết.
- Thu hồi account/credential không còn owner.
- Bật lại logging, monitoring hoặc protection bị tắt.
- Disable service/feature chỉ dùng tạm thời.
- Review exception và đặt expiry rõ ràng.
NIST SP 800-128 nhấn mạnh change control, security impact analysis và monitoring để giữ hệ thống bám approved baseline. Nếu current state là thay đổi hợp lệ và cần thiết cho business, không nên “rollback mù”; thay vào đó cần review, approve và re-baseline có kiểm soát.
Biến review định kỳ thành vòng kiểm soát
Managed Security Review nên so current state với baseline, xem backlog, recurring issue, expired exception, scope drift và evidence của remediation. Mục tiêu không phải tạo thêm checklist, mà phát hiện những thay đổi nhỏ trước khi chúng tích tụ thành attack path đáng kể.
Dùng Managed Security Review định kỳ làm nhịp review, còn Continuous Security Improvement làm vòng lặp current state → target state → gap → change → validation.
Validation sau khi xử lý security drift
| Kiểm tra | Kết quả mong đợi |
|---|---|
| Baseline diff | Deviation rủi ro đã được xử lý hoặc phê duyệt |
| Firewall/service exposure | Khớp architecture hiện hành |
| Accounts/privilege | Chỉ còn owner và quyền cần thiết |
| Logging/monitoring | Control hoạt động và tạo signal đúng |
| Exceptions | Có owner và expiry/review date |
| Change records | Drift hợp lệ được cập nhật vào baseline |
| Recurring drift | Giảm ở review cycle tiếp theo |
Bài học vận hành
- Hardening một lần không đảm bảo security posture giữ nguyên.
- Baseline chỉ có giá trị khi được monitoring và change control duy trì.
- Emergency change là nguồn drift phổ biến nếu thiếu rollback/review.
- Không phải mọi deviation đều cần rollback; một số cần re-baseline chính thức.
- Review định kỳ giúp phát hiện drift trước khi nó trở thành incident.
- Recurring drift thường phản ánh process/control gap chứ không chỉ lỗi cấu hình đơn lẻ.