5 bước phối hợp ứng phó sự cố an ninh mạng giữa doanh nghiệp và MSP

Năm bước này không phải những giai đoạn tách biệt tuyệt đối. Trong thực tế, điều tra và cô lập có thể diễn ra song song; một tài khoản bị chiếm quyền cũng có thể cần được vô hiệu hóa ngay khi có đủ căn cứ.

Điểm quan trọng nhất là doanh nghiệp và nhà cung cấp phải biết ai được quyền làm gì trước khi sự cố xảy ra. Doanh nghiệp muốn xây dựng trước quy trình nội bộ cũng có thể tham khảo Incident Response Guide dành cho doanh nghiệp do IPSIP Việt Nam chia sẻ.

1.Quy trình ứng phó sự cố khẩn cấp giữa doanh nghiệp và MSP nên diễn ra như thế nào?

Theo NIST SP 800-61 Rev.3, ứng phó sự cố khẩn cấp cần được tích hợp vào hoạt động quản trị rủi ro an ninh mạng của tổ chức, thay vì chỉ là một quy trình kỹ thuật được kích hoạt sau khi hệ thống đã bị tấn công.

Khi xảy ra xâm nhập hoặc ransomware, quá trình phối hợp có thể được tổ chức thành năm bước chính:

Đây là một khung vận hành, không phải thời gian biểu cố định. Không nên tự đặt những quy tắc như “15 phút phải cô lập xong” hay “30 phút phải phục hồi” nếu SLA, kiến trúc hệ thống và mức độ sự cố không hỗ trợ các mốc đó.

1.1 Bước 1: Xác minh và tuyên bố sự cố an ninh mạng

Việc đầu tiên không phải là xóa mã độc, mà là xác định cảnh báo có đủ nghiêm trọng để kích hoạt quy trình ứng phó hay không.

Một số dấu hiệu thường cần được chuyển cấp sớm gồm:

• xuất hiện thông báo đòi tiền chuộc;

• nhiều tệp bị mã hóa hoặc đổi phần mở rộng;

• EDR phát hiện tiến trình độc hại;

• tài khoản đặc quyền đăng nhập bất thường;

• tài khoản dịch vụ thực hiện hành động ngoài hành vi thông thường;

• thông tin xác thực có dấu hiệu bị đánh cắp;

• xuất hiện script hoặc PowerShell đáng ngờ;

• có dấu hiệu di chuyển từ máy này sang máy khác trong mạng;

• xuất hiện hành vi leo thang đặc quyền;

• lưu lượng truyền dữ liệu ra ngoài bất thường;

• hệ thống backup hoặc công cụ bảo mật bị vô hiệu hóa.

Ngay khi kích hoạt quy trình, cần ghi nhận ít nhất:

• thời điểm phát hiện;

• người hoặc hệ thống phát hiện;

• tài sản bị ảnh hưởng;

• tài khoản liên quan;

• dấu hiệu quan sát được;

• dịch vụ kinh doanh chịu ảnh hưởng;

• những hành động đã thực hiện;

• log và cảnh báo hiện có;

• người đang chịu trách nhiệm điều phối.

Ai nên điều phối sự cố?

Một sự cố nghiêm trọng nên có một đầu mối điều phối chính.

Người này không nhất thiết phải là chuyên gia phân tích mã độc giỏi nhất. Nhiệm vụ quan trọng hơn là giữ cho toàn bộ quá trình có cấu trúc:

ai điều tra → ai cô lập → ai phê duyệt → ai cập nhật ban lãnh đạo → ai làm việc với MSP/MSSP → ai ghi nhận quyết định.

Nếu thiếu đầu mối rõ ràng, nhiều kỹ sư có thể cùng tập trung phân tích một mẫu mã độc trong khi không ai nhớ khóa tài khoản đang bị kẻ tấn công sử dụng.

1.2 Bước 2: Kích hoạt hotline và cơ chế chuyển cấp với MSP/MSSP

Một hotline ứng cứu sự cố hiệu quả không đơn giản là một số điện thoại lưu trong danh bạ.

Nó phải nằm trong một cơ chế chuyển cấp đã được thống nhất và kiểm tra trước.

Doanh nghiệp và MSP/MSSP nên chuẩn bị:

• đầu mối chính;

• đầu mối dự phòng;

• người trực ngoài giờ;

• email hoặc hệ thống ticket khẩn cấp;

• thông tin khách hàng hoặc hợp đồng;

• cách phân loại mức độ sự cố;

• người có quyền yêu cầu cô lập;

• người có quyền thay đổi firewall hoặc network;

• người có quyền vô hiệu hóa tài khoản;

• kênh liên lạc dự phòng.

Khi liên hệ MSP/MSSP cần cung cấp thông tin gì?

Thông báo ban đầu nên trả lời được:

1. Hệ thống hoặc tổ chức nào đang gặp sự cố?

2. Ai là người liên hệ chính?

3. Sự cố được phát hiện lúc nào?

4. Hệ thống hoặc tài khoản nào bị ảnh hưởng?

5. Dấu hiệu quan sát được là gì?

6. Hoạt động kinh doanh đang bị ảnh hưởng ra sao?

7. Có dấu hiệu ransomware, đánh cắp tài khoản hoặc di chuyển giữa các hệ thống không?

8. Đội nội bộ đã thực hiện những hành động nào?

9. Những log hoặc cảnh báo nào đang có?

10. Doanh nghiệp cần nhà cung cấp hỗ trợ việc gì ngay?

Một thông báo kiểu “server bị hack, kiểm tra giúp” thường không đủ để nhà cung cấp bắt đầu xử lý hiệu quả.

MSP và MSSP không mặc nhiên có cùng trách nhiệm

Nếu MSP đang quản lý server, backup và network, điều đó không đồng nghĩa họ được giao nhiệm vụ phân tích mã độc, điều tra số hoặc ứng cứu an ninh mạng chuyên sâu.

Ngược lại, MSSP hoặc SOC có thể phát hiện và phân tích mối đe dọa nhưng lại không có quyền khởi động lại máy chủ production hoặc thay đổi cấu hình mạng.

Doanh nghiệp cần xác định trước:

Đối với môi trường cần theo dõi sự kiện bảo mật liên tục, SOC 24/7 của IPSIP Việt Nam có thể bổ sung năng lực giám sát, phân tích cảnh báo và phối hợp xử lý trong phạm vi dịch vụ được hai bên thống nhất.

1.3 Bước 3: Cô lập hệ thống bị xâm nhập nhưng không phá hủy bằng chứng

Khi đã có dấu hiệu hệ thống bị chiếm quyền, mục tiêu của việc cô lập là hạn chế phạm vi ảnh hưởng.

Nói đơn giản, doanh nghiệp cần ngăn kẻ tấn công sử dụng một thiết bị đã chiếm được để tiếp tục truy cập sang những hệ thống khác.

1.3.1 Cách cô lập thiết bị bị tấn công

Tùy kiến trúc và công cụ đang sử dụng, biện pháp có thể gồm:

• sử dụng tính năng cô lập mạng của EDR;

• tách thiết bị khỏi mạng;

• ngắt Wi-Fi hoặc kết nối mạng của thiết bị bị ảnh hưởng;

• chặn kết nối tới hạ tầng độc hại đã được xác định;

• vô hiệu hóa tài khoản bị chiếm quyền;

• thu hồi phiên đăng nhập hoặc token;

• tạm thời giới hạn quyền truy cập;

• hạn chế lưu lượng giữa các phân đoạn mạng;

• áp dụng quy tắc firewall có kiểm soát.

1.3.2 Cô lập không đồng nghĩa với tắt máy

Đây là một trong những điểm dễ xử lý sai nhất.

Không nên mặc định rằng cứ xuất hiện ransomware là phải tắt nguồn toàn bộ server ngay lập tức.

Tắt máy có thể làm mất dữ liệu tạm thời trong bộ nhớ, thông tin về tiến trình đang chạy, kết nối đang hoạt động và những bằng chứng hữu ích cho quá trình điều tra.

Nguyên tắc nên là:

ưu tiên cô lập nếu có thể → bảo toàn bằng chứng → điều tra → chỉ thực hiện thay đổi không thể đảo ngược khi có lý do rõ ràng.

1.3.3 Không xóa dấu vết trước khi biết chuyện gì đã xảy ra

Trong một sự cố nghiêm trọng, cần thận trọng trước những hành động như:

• format ổ đĩa;

• cài lại hệ điều hành ngay;

• xóa sạch thiết bị;

• xóa log;

• xóa hàng loạt tệp đáng ngờ mà không ghi nhận;

• reset hàng loạt tài khoản mà không lưu lại thông tin;

• xóa máy ảo trước khi thu thập dữ liệu cần thiết.

Không phải hệ thống nào cũng cần được sao chụp phục vụ điều tra số một cách đầy đủ.

Nhưng doanh nghiệp nên xác định đâu là nguồn bằng chứng quan trọng trước khi thực hiện những hành động không thể đảo ngược.

1.4 Bước 4: Điều tra phạm vi, loại bỏ nguyên nhân và phục hồi có kiểm soát

Cô lập chỉ giúp kiểm soát sự lan rộng. Nó chưa chứng minh kẻ tấn công đã bị loại khỏi môi trường.

1.4.1 Xác định phạm vi bị xâm nhập

Doanh nghiệp và MSP/MSSP cần phối hợp trả lời:

• Điểm xâm nhập ban đầu là gì?

• Hệ thống đầu tiên bị chiếm quyền là hệ thống nào?

• Tài khoản nào đã bị đánh cắp?

• Kẻ tấn công có leo thang đặc quyền không?

• Có di chuyển giữa các hệ thống không?

• Hệ thống nào còn cơ chế giúp kẻ tấn công duy trì quyền truy cập?

• Có dấu hiệu dữ liệu bị đưa ra ngoài không?

• Hạ tầng backup có bị truy cập không?

• Phiên đăng nhập Cloud có bị chiếm quyền không?

• Còn hệ thống nào bị ảnh hưởng nhưng chưa được phát hiện?

Nguồn dữ liệu phục vụ điều tra có thể đến từ:

• EDR/XDR;

• SIEM;

• firewall;

• hệ thống quản lý danh tính;

• email security;

• nhật ký Cloud;

• VPN;

• proxy;

• WAF;

• log thiết bị;

• dữ liệu mạng.

1.4.2 Đổi mật khẩu chưa chắc đã đủ

Nếu kẻ tấn công đã chiếm được phiên đăng nhập hoặc token, chỉ đổi mật khẩu chưa chắc đã chấm dứt quyền truy cập hiện tại.

Do đó, xử lý tài khoản có thể cần kết hợp:

đổi mật khẩu + thu hồi phiên đăng nhập + thu hồi token + rà soát MFA + kiểm tra tài khoản đặc quyền, tùy nền tảng và bằng chứng thực tế.

1.4.3 Phải xử lý nguyên nhân chứ không chỉ triệu chứng

Nếu chỉ xóa tệp ransomware nhưng lỗ hổng ban đầu vẫn còn, kẻ tấn công vẫn có thể quay trở lại.

Biện pháp xử lý có thể bao gồm:

• loại bỏ cơ chế duy trì quyền truy cập;

• xử lý mã độc;

• vá lỗ hổng đã bị khai thác;

• thay đổi thông tin xác thực và secret bị lộ;

• xóa tài khoản trái phép;

• sửa cấu hình sai;

• rà soát truy cập từ xa;

• tăng cường bảo vệ các tài sản liên quan.

1.4.4 Khi nào có thể khôi phục từ backup?

Không phải ngay khi server có vẻ “sạch”.

Trước khi phục hồi, cần xác minh:

• bản sao lưu còn nguyên vẹn không;

• bản sao được tạo trước hay sau thời điểm bị xâm nhập;

• mã độc hoặc cơ chế duy trì truy cập có nằm trong backup không;

• tài khoản dùng cho hệ thống backup có bị compromise không;

• điểm xâm nhập ban đầu đã được xử lý chưa;

• mạng phục hồi đã được phân đoạn phù hợp chưa;

• hệ thống giám sát đã được kích hoạt trở lại chưa.

Nếu sự cố là ransomware, doanh nghiệp cần lưu ý gì?

Ransomware hiện đại không nhất thiết chỉ diễn ra theo kiểu:

mã độc chạy → dữ liệu bị mã hóa → khôi phục backup.

Một cuộc tấn công có thể đã diễn ra trước đó qua nhiều giai đoạn:

xâm nhập ban đầu → đánh cắp tài khoản → leo thang đặc quyền → di chuyển sang hệ thống khác → đánh cắp dữ liệu → triển khai ransomware.

Vì vậy, thông báo đòi tiền chuộc thường chỉ là phần dễ nhìn thấy nhất.

Doanh nghiệp cần đánh giá:

• phạm vi dữ liệu bị mã hóa;

• tài khoản bị chiếm quyền;

• hoạt động di chuyển giữa các hệ thống;

• quyền đặc quyền;

• dấu hiệu dữ liệu bị đưa ra ngoài;

• truy cập từ xa;

• tính toàn vẹn của backup;

• cơ chế duy trì quyền truy cập;

• các hệ thống chưa bị mã hóa nhưng có thể đã bị xâm nhập.

CISA cũng lưu ý rằng một sự cố ransomware có thể là dấu hiệu của một cuộc xâm nhập đã tồn tại từ trước. Doanh nghiệp nên xem lại dữ liệu từ EDR, IDS/IPS, antivirus và các nguồn log để tìm dấu vết ở những giai đoạn trước của cuộc tấn công.

Doanh nghiệp có thể tham khảo thêm Sổ tay ứng phó sự cố ransomware để bổ sung cho quy trình nội bộ.

Không khôi phục quá sớm

Nếu kẻ tấn công vẫn còn quyền truy cập hoặc cơ chế duy trì trong hệ thống, máy chủ vừa được phục hồi có thể nhanh chóng bị xâm nhập trở lại.

Không mặc định trả tiền chuộc

Quyết định liên quan tới tiền chuộc cần có sự tham gia của ban lãnh đạo, pháp chế, bộ phận tuân thủ, chuyên gia ứng phó sự cố và những bên liên quan phù hợp.

Thanh toán không nên được xem là một bước kỹ thuật mặc định trong quy trình xử lý ransomware.

1.5 Bước 5: Giám sát sau phục hồi và đánh giá hậu sự cố

Server hoạt động trở lại không có nghĩa sự cố đã kết thúc.

NIST SP 800-61 Rev.3 nhấn mạnh việc tích hợp ứng phó sự cố vào quản trị rủi ro an ninh mạng liên tục, nhằm cải thiện khả năng chuẩn bị, phát hiện, xử lý và phục hồi sau các sự cố tương lai.

Sau khi hệ thống được phục hồi, SOC/MSP/MSSP nên tăng cường theo dõi:

• dấu hiệu tấn công xuất hiện trở lại;

• đăng nhập tài khoản bất thường;

• truy cập từ xa mới;

• leo thang đặc quyền;

• lưu lượng ra ngoài bất thường;

• cơ chế duy trì truy cập còn sót lại;

• hành vi tương tự trên các tài sản khác.

Đánh giá sau sự cố cần trả lời những gì?

Ít nhất cần làm rõ:

• Kẻ tấn công vào hệ thống bằng cách nào?

• Thời điểm xâm nhập đầu tiên là khi nào?

• Cảnh báo đầu tiên xuất hiện lúc nào?

• Cảnh báo có được chuyển cấp đúng không?

• Thời gian khoanh vùng thực tế là bao lâu?

• Ai có quyền cô lập hệ thống?

• Có bước nào bị chậm vì chờ phê duyệt không?

• Nhà cung cấp có đủ dữ liệu để điều tra không?

• Log có được lưu đủ không?

• Backup có sử dụng được không?

• Đội IT và MSP/MSSP phối hợp có rõ ràng không?

• Kênh liên lạc khẩn cấp có hoạt động không?

• Quy trình và SLA cần điều chỉnh ở đâu?

Việc phân tích nguyên nhân không nhằm tìm một cá nhân để quy trách nhiệm. Mục tiêu là xác định điểm kiểm soát hoặc quy trình nào cần thay đổi để sự cố tiếp theo được phát hiện và xử lý tốt hơn.

2.MSP, MSSP và đội IT nội bộ nên chia trách nhiệm như thế nào?

Không có một ma trận trách nhiệm duy nhất áp dụng cho mọi doanh nghiệp, nhưng phạm vi của từng bên phải được thống nhất trước.

Điểm cần nhớ là phạm vi trong hợp đồng phải khớp với kỳ vọng khi sự cố thật sự xảy ra.

Đừng đợi đến khi server bị mã hóa mới phát hiện MSP chỉ có trách nhiệm “giám sát và thông báo”, nhưng không được quyền cô lập tài sản hay tham gia điều tra.

3.Kênh liên lạc khẩn cấp cũng có thể đã bị xâm nhập

Nếu doanh nghiệp nghi ngờ kẻ tấn công đã kiểm soát:

• email doanh nghiệp;

• Microsoft 365;

• Active Directory;

• nền tảng cộng tác nội bộ;

thì tiếp tục thảo luận toàn bộ phương án xử lý trên chính những hệ thống này có thể làm lộ kế hoạch của đội ứng cứu.

Do đó, kế hoạch ứng phó nên có sẵn một kênh liên lạc dự phòng đã được xác minh trước.

Kênh này cũng không nên được sử dụng tùy tiện để gửi mật khẩu, khóa bí mật hoặc thông tin xác thực nhạy cảm.

4.Doanh nghiệp Việt Nam cần lưu ý gì về tuân thủ khi xử lý sự cố trong năm 2026?

Tính đến tháng 9/2026, hành lang pháp lý về an ninh mạng tại Việt Nam đã có những thay đổi đáng kể mà doanh nghiệp cần xem xét khi xây dựng quy trình xử lý sự cố.

Luật An ninh mạng số 116/2025/QH15

Luật An ninh mạng số 116/2025/QH15 – Cổng Thông tin điện tử Chính phủ được ban hành ngày 10/12/2025 và có hiệu lực từ 01/07/2026.

Vì vậy, xử lý sự cố không nên chỉ được nhìn như việc “IT tự xử khi hệ thống bị hack”. Đối với các tổ chức và hệ thống thuộc phạm vi áp dụng tương ứng, kế hoạch ứng phó cần gắn với quản trị hệ thống, phân công trách nhiệm, giám sát, bằng chứng và yêu cầu tuân thủ.

Nghị định 331/2026/NĐ-CP

Nghị định 331/2026/NĐ-CP – Biện pháp bảo vệ an ninh mạng đối với hệ thống thông tin quy định tiêu chí xác định cấp độ hệ thống thông tin, cùng các biện pháp, trách nhiệm và nghĩa vụ bảo đảm an ninh mạng theo từng cấp độ.

Với doanh nghiệp, điều này củng cố nhu cầu phải biết rõ:

hệ thống nào quan trọng → ai là chủ sở hữu → ai được cô lập → ai được phục hồi → nhà cung cấp nào chịu trách nhiệm.

Nghị định 332/2026/NĐ-CP

Khi lựa chọn MSSP hoặc đơn vị hỗ trợ ứng cứu, Nghị định 332/2026/NĐ-CP về hoạt động kinh doanh sản phẩm, dịch vụ an ninh mạng là văn bản đáng lưu ý.

Nghị định được ban hành ngày 19/08/2026, quy định các loại sản phẩm, dịch vụ an ninh mạng và điều kiện đối với doanh nghiệp kinh doanh những dịch vụ thuộc phạm vi điều chỉnh.

Vì vậy, doanh nghiệp không chỉ nên hỏi:

Mà cần đánh giá phạm vi dịch vụ, năng lực thực tế và các điều kiện pháp lý áp dụng đối với loại hình dịch vụ mình đang mua.

Nếu sự cố liên quan đến dữ liệu cá nhân

Doanh nghiệp cũng cần đánh giá nghĩa vụ áp dụng theo Luật Bảo vệ dữ liệu cá nhân số 91/2025/QH15 – Cổng Thông tin điện tử Chính phủ, có hiệu lực từ 01/01/2026, cùng các quy định chuyên ngành liên quan.

Không nên tự áp một thời hạn thông báo duy nhất cho tất cả sự cố khi chưa xác định:

• loại dữ liệu;

• vai trò của tổ chức;

• phạm vi ảnh hưởng;

• ngành nghề;

• hệ thống liên quan;

• quy định chuyên ngành áp dụng.

5.IPSIP Việt Nam đồng hành cùng doanh nghiệp trong xử lý sự cố thông qua Managed Services

Một quy trình xử lý sự cố hiệu quả không bắt đầu từ khoảnh khắc ransomware xuất hiện.

Nó bắt đầu trước đó, khi doanh nghiệp và đối tác đã thống nhất cách giám sát, trách nhiệm của từng bên, cơ chế chuyển cấp, kênh liên lạc và quyền xử lý.

Trong mô hình Managed Services, vai trò của nhà cung cấp không nên chỉ dừng ở việc nhận ticket khi hệ thống gặp lỗi. Giá trị lớn hơn nằm ở khả năng kết nối bối cảnh vận hành hạ tầng với hoạt động giám sát an ninh mạng và quy trình xử lý sự cố.

Thông qua SOC 24/7 và các năng lực Managed Services liên quan, IPSIP Việt Nam có thể phối hợp với đội IT nội bộ theo một mô hình trong đó:

• IT nội bộ giữ kiến thức về hệ thống, nghiệp vụ và quyền quyết định.

• Managed Services bổ sung năng lực vận hành và bối cảnh hạ tầng.

• SOC/MSSP bổ sung khả năng giám sát và phân tích dấu hiệu an ninh mạng.

• Quy trình xử lý sự cố kết nối các bên trong quá trình cô lập, điều tra, phục hồi và hậu kiểm.

Điều đó không có nghĩa doanh nghiệp giao toàn bộ quyền kiểm soát hệ thống cho nhà cung cấp.

Đội IT nội bộ vẫn cần giữ:

• quyền sở hữu hệ thống;

• ưu tiên kinh doanh;

• quản trị;

• thẩm quyền quyết định;

• giám sát nhà cung cấp.

Trong khi đối tác Managed Services có thể bổ sung:

• khả năng giám sát;

• nguồn lực vận hành;

• chuyên môn kỹ thuật;

• phân tích an ninh mạng;

• cơ chế chuyển cấp;

• hỗ trợ xử lý theo phạm vi dịch vụ đã thống nhất.

Một cách thực tế để đánh giá mức sẵn sàng là tổ chức diễn tập tình huống giữa đội IT và nhà cung cấp:

Nếu câu trả lời vẫn là “lúc đó sẽ tính”, quy trình chưa thực sự sẵn sàng.

👉 Liên hệ IPSIP Việt Nam để trao đổi cơ hội hợp tác và xây dựng mô hình Managed Services, SOC cũng như cơ chế phối hợp xử lý sự cố phù hợp với hạ tầng, đội IT và mức độ rủi ro thực tế.

🎉 Ưu đãi dành cho khách hàng mới: Giảm 15% chi phí khi đăng ký các dịch vụ an ninh mạng tại IPSIP Việt Nam trong thời gian diễn ra chương trình. Liên hệ để được tư vấn giải pháp phù hợp với nhu cầu bảo mật và tối ưu ngân sách đầu tư. 

Nguồn tham khảo

NIST SP 800-61 Rev.3 – Incident Response Recommendations and Considerations for Cybersecurity Risk Management

CISA #StopRansomware Guide – Ransomware and Data Extortion Response Checklist

Luật An ninh mạng số 116/2025/QH15 – Cổng Thông tin điện tử Chính phủ

Nghị định 331/2026/NĐ-CP – Biện pháp bảo vệ an ninh mạng đối với hệ thống thông tin

Nghị định 332/2026/NĐ-CP – Hoạt động kinh doanh sản phẩm, dịch vụ an ninh mạng

Nghị định 333/2026/NĐ-CP – Hoạt động bảo đảm an ninh thông tin mạng của doanh nghiệp

Luật Bảo vệ dữ liệu cá nhân số 91/2025/QH15 – Cổng Thông tin điện tử Chính phủ