Ứng phó sự cố: đọc log, dòng thời gian, ngăn chặn và phục hồi

Sự cố bảo mật (Security incident) là sự kiện ảnh hưởng hoặc đe dọa các mục tiêu ở bài 1 (bí mật, toàn vẹn, sẵn sàng). Ví dụ: lúc 09:00 có người báo tài khoản nhận lệ phí trên website khác bản đã duyệt.

Quy trình ứng phó chuẩn (theo NIST) gồm các giai đoạn:

1. Chuẩn bị: có log, có bản sao lưu, biết ai quyết định việc gì.
2. Phát hiện và phân tích: xác định chuyện gì đã xảy ra, ảnh hưởng đến đâu.
3. Ngăn chặn (Ngăn chặn sự cố (Containment)), loại bỏ nguyên nhân, phục hồi.
4. Rà soát sau sự cố: rút kinh nghiệm, sửa điều kiện gây ra sự cố.

Các giai đoạn đan xen: thông tin thanh toán sai gây thiệt hại từng phút, nên phải vừa ngăn chặn vừa tìm nguyên nhân, không chờ biết hết mọi thứ.

Sai lầm phổ biến nhất khi điều tra là kết luận sớm. Hãy ghi hai cột riêng:

Mỗi điều cần ghi kèm nguồn và thời điểm quan sát. Chỉ xếp một điều vào cột "đã biết" khi có bằng chứng.

Nhật ký hệ thống (Log) là bản ghi sự kiện có thời gian. Đây là log giả định để luyện đọc:

08:40:12 recovery_requested account=admin result=pending
08:42:10 login_attempt account=admin result=failed
08:47:03 content_updated page=payment actor=editor-demo
09:00:00 report_received topic=wrong_payment_details

• Dòng 1: có yêu cầu khôi phục, trạng thái pending. Không có dòng "thành công" thì chưa khẳng định đã đặt lại xong.
• Dòng 2: một lần đăng nhập thất bại, không phải thành công.
• Dòng 3: tài khoản editor-demo sửa trang thanh toán. Đây là danh tính hệ thống ghi nhận, chưa phải người thật.
• Dòng 4: thời điểm nhận báo cáo, không phải lúc nội dung bắt đầu sai.

Sắp các sự kiện theo giờ thành Dòng thời gian (Timeline):

Lưu ý khi dùng log: các hệ thống có thể dùng múi giờ khác nhau, đồng hồ có thể lệch, và không phải hành động nào cũng được ghi. "Không thấy trong log" khác với "đã chứng minh không xảy ra".

Việc đầu tiên là giảm thiệt hại đang tiếp diễn. Với số tài khoản sai, người dùng có thể tiếp tục chuyển tiền sai, nên người có thẩm quyền có thể tạm gỡ trang thanh toán, đăng thông báo ở kênh đã xác minh, hoặc liên hệ trực tiếp người đã chuyển.

Song song, giữ bằng chứng trước khi sửa: chụp hoặc lưu bản nội dung sai, URL, thời gian, log liên quan, và bản đã duyệt. Nếu sửa ngay mà không lưu bản trước, việc tìm nguyên nhân sẽ khó hơn nhiều.

Không thử lại thao tác nguy hiểm trên hệ thống thật chỉ để "xem có lỗi không": việc đó có thể gây thay đổi thêm và làm nhiễu bằng chứng.

Sửa lại số tài khoản đúng chỉ phục hồi hậu quả. Nếu kẻ tấn công vẫn còn phiên đang mở hoặc quyền thừa, họ sửa lại được. Phải làm cả hai nhóm việc:

• Phục hồi: đưa nội dung về bản đã duyệt. Nếu dùng Bản sao lưu (Backup), kiểm tra bản sao ở thời điểm nào; khôi phục bản cũ có thể làm mất các cập nhật hợp lệ xảy ra sau đó.
• Đóng đường vào: đổi mật khẩu các tài khoản liên quan, thu hồi mọi phiên, bật hoặc kiểm tra MFA, gỡ quyền thừa, kiểm tra đường khôi phục.
• Theo dõi: bật cảnh báo thay đổi nội dung và đăng nhập lạ để phát hiện nếu tái diễn.

Rà soát sau sự cố

Viết báo cáo ngắn: chuyện gì xảy ra, dòng thời gian có căn cứ, đã làm gì, điều gì còn chưa xác định, và cần cải thiện gì. Một báo cáo nói rõ "đã khôi phục nội dung; chưa đủ log để kết luận đường vào ban đầu" hữu ích hơn một nguyên nhân phỏng đoán.

Câu "đã sửa số tài khoản nên website an toàn" bỏ qua quyền, phiên, và điều kiện gây ra sự cố. Một trường được sửa đúng không chứng minh cả hệ thống an toàn.