72 giờ đầu sau sự cố bảo mật: Kịch bản ứng phó cho doanh nghiệp

Không hệ thống nào an toàn tuyệt đối. Câu hỏi thực tế với mọi doanh nghiệp không phải là “liệu có bị tấn công không” mà là “khi bị tấn công, chúng ta phản ứng tốt đến đâu”. Hai doanh nghiệp gặp cùng một loại sự cố có thể chịu thiệt hại chênh nhau hàng chục lần — khác biệt nằm ở những gì diễn ra trong 72 giờ đầu tiên.

Con số 72 giờ không ngẫu nhiên: đây cũng là thời hạn doanh nghiệp phải thông báo vi phạm dữ liệu cá nhân cho cơ quan chức năng theo quy định về bảo vệ dữ liệu cá nhân tại Việt Nam (tương tự GDPR ở châu Âu). Bài viết này đưa ra một kịch bản ứng phó theo từng mốc thời gian mà doanh nghiệp có thể dùng làm khung tham chiếu khi xây dựng quy trình của riêng mình.

Trước khi sự cố xảy ra: bốn thứ phải chuẩn bị sẵn

Mọi kịch bản ứng phó đều vô nghĩa nếu được viết ra *trong lúc* sự cố. Bốn thứ tối thiểu cần chuẩn bị trước:

• Kế hoạch ứng phó sự cố (IR plan) một trang. Không cần tài liệu 50 trang — cần một trang mà ai cũng tìm được trong 2 phút: ai là chỉ huy sự cố, gọi ai theo thứ tự nào, tiêu chí phân loại mức độ, và các bước đầu tiên cho từng loại sự cố phổ biến.
• Kênh liên lạc ngoài băng (out-of-band). Nếu kẻ tấn công đã ở trong email và chat nội bộ, mọi trao đổi ứng phó qua các kênh đó đều bị theo dõi. Chuẩn bị sẵn một nhóm trên nền tảng độc lập (ví dụ Signal) với danh sách liên hệ in sẵn.
• Backup offline và đã được kiểm tra phục hồi. Ransomware hiện đại chủ động tìm và mã hóa/xóa backup nối mạng trước khi phát động. Backup chỉ có giá trị khi có ít nhất một bản ngoại tuyến (offline/immutable) và đã được diễn tập phục hồi thật — backup chưa từng restore thử là backup chưa tồn tại.
• Danh sách liên hệ bên ngoài. Đơn vị ứng cứu sự cố đã thỏa thuận trước (ký sẵn NDA và điều khoản kích hoạt), đầu mối cơ quan chức năng, luật sư, và đơn vị bảo hiểm nếu có bảo hiểm an ninh mạng.

Giờ 0–4: Phát hiện, kích hoạt và đánh giá ban đầu

Sự cố có thể được phát hiện từ nhiều nguồn: cảnh báo hệ thống giám sát, khách hàng báo dữ liệu bị lộ, nhân viên nhận được email tống tiền, hoặc tệ nhất — màn hình đòi tiền chuộc. Trong những giờ đầu tiên:

1. Kích hoạt quy trình và chỉ định chỉ huy sự cố. Một người ra quyết định cuối cùng, một người ghi chép nhật ký (ai làm gì, lúc nào — quan trọng cho cả điều tra lẫn nghĩa vụ pháp lý), các thành viên còn lại thực thi.
2. Chuyển trao đổi sang kênh ngoài băng ngay khi nghi ngờ email/chat nội bộ bị xâm nhập.
3. Cô lập — không tắt máy. Ngắt kết nối mạng của các máy nghi nhiễm (rút cáp, tắt Wi-Fi, cô lập VLAN) nhưng giữ nguyên nguồn điện. Bộ nhớ RAM chứa bằng chứng quý giá nhất về kẻ tấn công — tắt nguồn là xóa sạch nó.
4. Đánh giá phạm vi ban đầu. Hệ thống nào bị ảnh hưởng? Có dấu hiệu dữ liệu bị trích xuất ra ngoài không? Sự cố còn đang diễn ra hay đã dừng? Đừng kỳ vọng câu trả lời chính xác ngay — nhưng cần bức tranh sơ bộ để quyết định mức độ huy động.

Giờ 4–24: Khoanh vùng, ngăn chặn và thu thập bằng chứng

1. Bảo toàn log trước khi chúng bị ghi đè. Sao chép log từ máy chủ, firewall, VPN, hệ thống xác thực, cloud (CloudTrail, audit log...) sang nơi lưu trữ độc lập. Nhiều hệ thống chỉ giữ log vài ngày — đây là cuộc chạy đua với thời gian.
2. Vô hiệu hóa các đường truy cập của kẻ tấn công. Đặt lại mật khẩu các tài khoản nghi bị chiếm (bắt đầu từ tài khoản đặc quyền), thu hồi toàn bộ phiên đăng nhập và token đang hoạt động, khóa các khóa API bị lộ, rà soát các quy tắc chuyển tiếp email và tài khoản mới được tạo bất thường.
3. Xác định đường xâm nhập ban đầu. Phishing? Lỗ hổng chưa vá trên hệ thống công khai? Credentials bị lộ? VPN không có MFA? Chưa trả lời được câu hỏi này thì chưa thể yên tâm rằng việc ngăn chặn đã triệt để.
4. Đánh giá tác động đến dữ liệu cá nhân. Loại dữ liệu nào bị truy cập, của bao nhiêu người, có dữ liệu nhạy cảm không — thông tin này quyết định nghĩa vụ thông báo ở mốc tiếp theo.

Giờ 24–72: Nghĩa vụ thông báo và xử lý triệt để

Khi bức tranh sự cố đã rõ hơn, ba luồng công việc chạy song song:

• Thông báo cơ quan chức năng. Nếu sự cố liên quan đến vi phạm dữ liệu cá nhân, quy định hiện hành yêu cầu thông báo trong vòng 72 giờ kể từ khi phát hiện. Việc thông báo đúng hạn — kể cả khi thông tin chưa đầy đủ — thể hiện thiện chí tuân thủ và luôn tốt hơn việc che giấu rồi bị phát hiện sau.
• Truyền thông với khách hàng và đối tác. Nguyên tắc: nói những gì đã xác minh, không suy đoán, không hứa những điều chưa chắc, và đưa ra hành động cụ thể khách hàng nên làm (đổi mật khẩu, cảnh giác email giả mạo nhân danh công ty). Một thông báo chủ động, trung thực giữ được niềm tin tốt hơn nhiều so với việc khách hàng biết tin từ báo chí.
• Xử lý triệt để (eradication). Vá lỗ hổng là đường xâm nhập ban đầu, quét tìm và gỡ bỏ backdoor/webshell/tài khoản ẩn mà kẻ tấn công để lại, củng cố cấu hình các hệ thống liên quan. Chỉ sau bước này mới bắt đầu khôi phục.

Sau 72 giờ: Khôi phục và rút kinh nghiệm

Khôi phục theo thứ tự ưu tiên nghiệp vụ, từ backup sạch, kèm giám sát tăng cường — kẻ tấn công thường quay lại trong vài tuần đầu sau sự cố. Khi vận hành đã ổn định, tổ chức buổi rút kinh nghiệm không đổ lỗi (blameless post-mortem): dòng thời gian sự cố, điều gì hoạt động tốt, điều gì không, và danh sách hành động củng cố có thời hạn. Sự cố đắt giá nhất là sự cố không học được gì.

Năm sai lầm khiến sự cố tồi tệ hơn

• Tắt nguồn máy nhiễm — xóa bằng chứng trong RAM, mất khả năng điều tra nguyên nhân gốc.
• Khôi phục quá sớm — restore hệ thống khi chưa vá đường xâm nhập, kẻ tấn công quay lại ngay bằng cửa cũ; hoặc restore từ backup đã nhiễm.
• Trao đổi ứng phó trên hệ thống bị xâm nhập — kẻ tấn công đọc được toàn bộ kế hoạch đối phó và đi trước một bước.
• Che giấu thông tin — bỏ qua nghĩa vụ thông báo, phủ nhận với khách hàng. Khi sự thật lộ ra (hầu như luôn vậy), thiệt hại uy tín nhân lên gấp bội và kéo theo trách nhiệm pháp lý.
• Mỗi người một hướng — không có chỉ huy sự cố, kỹ thuật viên tự ý 'sửa' hệ thống làm hỏng bằng chứng, nhiều người cùng ra quyết định mâu thuẫn nhau.

Bảng tóm tắt: 72 giờ đầu trong một trang