Kích hoạt Incident Response quá sớm có thể làm đội vận hành quá tải; kích hoạt quá muộn lại làm tăng thời gian attacker tồn tại trong hệ thống. Vì vậy website cần có tiêu chí activation rõ ràng để phân biệt một alert kỹ thuật, một sự cố vận hành và một security incident cần điều phối chính thức.
Điểm khởi đầu không phải là “có lỗi hay không”, mà là: có bằng chứng hợp lý cho thấy tính bí mật, toàn vẹn hoặc khả dụng của website đang bị đe dọa hay đã bị xâm phạm không?
Incident Response nên được kích hoạt khi nào?
Một quy tắc thực tế là kích hoạt khi có đủ confidence rằng sự kiện cần nhiều hơn một thao tác khắc phục thông thường: cần triage có owner, cần bảo toàn evidence, containment, phối hợp nhiều bên hoặc theo dõi recovery.
Dấu hiệu compromise có confidence cao
Những trường hợp như webshell được xác minh, redirect độc hại, tài khoản admin không rõ nguồn gốc, file core/plugin bị sửa trái phép, credential bị sử dụng bất thường hoặc malware được xác nhận thường đủ mạnh để kích hoạt quy trình.
Ảnh hưởng đến dữ liệu hoặc quyền truy cập đặc quyền
Nếu có khả năng attacker đã truy cập dữ liệu nhạy cảm, chiếm admin account, hosting panel, database, SSH/SFTP, API key hoặc secret thì incident cần được nâng mức ưu tiên ngay cả khi website vẫn hoạt động bình thường.
Attack đang tiếp diễn hoặc phạm vi chưa rõ
Khi dấu hiệu tấn công còn tiếp diễn, có persistence hoặc chưa xác định được asset nào bị ảnh hưởng, việc xử lý rời rạc dễ làm mất dấu vết. Đây là lúc cần incident owner và một timeline chung.
Alert chưa chắc đã là incident
Security Monitoring có thể phát ra nhiều alert hợp lệ nhưng không phải alert nào cũng chứng minh compromise. Ví dụ một spike request có thể đến từ bot hợp lệ, rule WAF mới hoặc campaign marketing.
Trước khi activation, nên dùng Security Alert Triage để xác minh signal, context và confidence. Nếu đã cần điều phối chính thức, chuyển sang Incident Triage.
Thiết kế tiêu chí activation theo impact và confidence
Một decision matrix đơn giản nên dùng ít nhất hai trục: confidence rằng đây là hành vi bảo mật thật và impact tiềm năng lên website, dữ liệu hoặc hoạt động kinh doanh.
High confidence + high impact
Kích hoạt ngay. Ví dụ admin compromise, webshell hoạt động, data exposure có bằng chứng hoặc attacker đang sửa nội dung/payment flow.
High confidence + low impact
Vẫn có thể mở incident nhưng mức severity thấp hơn. Ví dụ một tài khoản test bị compromise nhưng không có quyền quan trọng. Mục tiêu là containment và xác minh không có lateral movement.
Low confidence + high impact
Không nên bỏ qua. Đây là trường hợp cần triage nhanh và thu thêm evidence. Ví dụ WAF/log cho thấy dấu hiệu khai thác vào khu vực payment nhưng chưa chứng minh thành công.
Low confidence + low impact
Giữ ở monitoring/alert queue, thu thêm context và tránh làm gián đoạn hệ thống chỉ vì một tín hiệu yếu.
Severity P1–P4 hỗ trợ activation như thế nào?
Activation trả lời “có mở Incident Response hay không”; severity trả lời “ưu tiên ở mức nào”. Hai quyết định liên quan nhưng không phải một.
Sau activation, áp dụng Severity P1–P4 cho sự cố website để xác định escalation, nhịp cập nhật và thời gian phản ứng phù hợp.
Những trigger nên được định nghĩa trước
- Malware, backdoor hoặc webshell được xác minh.
- Admin/hosting/SSH account bị chiếm hoặc xuất hiện tài khoản đặc quyền không rõ nguồn gốc.
- File hoặc database bị thay đổi trái phép có impact đáng kể.
- Credential, API key, private key hoặc secret có dấu hiệu bị lộ.
- Data exfiltration hoặc truy cập dữ liệu trái phép có evidence.
- DDoS hoặc abuse làm ảnh hưởng availability ở mức nghiêm trọng.
- Compromise ở dependency, plugin/theme hoặc supply chain có khả năng lan rộng.
- Attack vẫn tiếp diễn sau mitigation ban đầu.
Khi nào chưa nên thực hiện containment mạnh?
Kích hoạt Incident Response không đồng nghĩa phải lập tức tắt website. Quyết định containment cần cân bằng giữa nguy cơ thiệt hại tiếp tục, availability và nhu cầu bảo toàn evidence. CISA nhấn mạnh việc lựa chọn containment strategy cần xem xét evidence preservation và service availability.
Nếu cần cô lập hệ thống, xem cách cô lập website bị xâm nhập mà không phá hủy evidence.
Checklist activation trong 10–15 phút đầu
- Ghi lại alert/signal ban đầu, timestamp và nguồn phát hiện.
- Xác minh asset, account hoặc component liên quan.
- Đánh giá confidence và impact sơ bộ.
- Chỉ định incident owner nếu vượt ngưỡng activation.
- Phân loại severity ban đầu.
- Giữ nguyên evidence cần thiết trước thay đổi lớn.
- Bắt đầu xác định phạm vi ảnh hưởng.
Tiêu chí tốt phải có thể kiểm thử
Activation rule nên được đưa vào tabletop exercise hoặc review định kỳ. Nếu mỗi người hiểu “incident nghiêm trọng” theo một cách khác nhau thì rule chưa đủ rõ. Sau mỗi sự cố, cập nhật trigger dựa trên những gì đã học được.
Khung này phù hợp với hướng tiếp cận của NIST SP 800-61 Rev. 3: Incident Response là một phần của quản trị rủi ro liên tục, không chỉ là phản ứng khi hệ thống đã bị phá hỏng.