
Những thay đổi trong hệ thống đánh giá SCS — Các biện pháp ứng phó sự cố được đánh giá “sau khi xảy ra” hơn là “trước khi xảy ra”
Tác giả của bài viết này
Chủ tịch kiêm Tổng giám đốc điều hành (CEO)
Takaaki Kanetsuki
Lời mở đầu
Vào tháng 3 năm 2026, Bộ Kinh tế, Thương mại và Công nghiệp cùng Văn phòng Điều phối An ninh Mạng Quốc gia thuộc Văn phòng Nội các đã công bố “Chính sách xây dựng hệ thống đánh giá các biện pháp an ninh nhằm tăng cường chuỗi cung ứng”, và trên cơ sở đó, các chi tiết về “Hệ thống đánh giá SCS” do IPA vận hành đang dần được làm rõ. Chắc hẳn có không ít doanh nghiệp đã bắt đầu xem xét việc đạt được mức ★3 và ★4 theo yêu cầu từ các đối tác kinh doanh.
Khi đọc kỹ các yêu cầu và tiêu chí đánh giá đã được công bố, chúng ta có thể nhận ra một thông điệp rõ ràng từ cơ chế này. Đó là, không chỉ “liệu có thể ngăn chặn được các cuộc tấn công hay không” mà cả “liệu có thể khôi phục hoạt động sau khi bị tấn công hay không” đều được đặt ra một cách trực diện ngay từ mức tối thiểu ★3.
Trong bài viết này, dựa trên các yêu cầu của hệ thống đánh giá SCS, chúng tôi sẽ phân tích lý do tại sao việc “quay trở lại” lại quan trọng, cũng như những điều doanh nghiệp cần chuẩn bị.
Cấu trúc cơ bản của hệ thống đánh giá SCS
Hệ thống đánh giá SCS là hệ thống đánh giá theo từng cấp độ, bằng số lượng dấu ★, mức độ các biện pháp bảo mật của các doanh nghiệp trong chuỗi cung ứng.
★3 | ★4 | |
|---|---|---|
Các mối đe dọa dự kiến | Các cuộc tấn công mạng phổ biến lợi dụng các lỗ hổng bảo mật đã được công nhận rộng rãi | Các cuộc tấn công gây ảnh hưởng lớn đến chuỗi cung ứng và các bên thứ ba |
Số lượng yêu cầu | 26件 | 43件 |
Hệ thống đánh giá | Tự đánh giá đã được các chuyên gia bảo mật xác nhận | Đánh giá của bên thứ ba (bao gồm thẩm định tại hiện trường và kiểm chứng kỹ thuật) |
Thời hạn hiệu lực | 1年 | 3年 |
Điểm đáng chú ý là cấu trúc của các nhóm yêu cầu chính. Các yêu cầu được chia thành 7 nhóm chính sau đây, tương ứng với 6 chức năng của NIST CSF (Khung An ninh mạng): quản trị, xác thực, phòng thủ, phát hiện, ứng phó và phục hồi.
Hoàn thiện hệ thống quản trị
Quản lý đối tác (quản trị)
Xác định (nhận diện) rủi ro
Phòng thủ trước các đòn tấn công, v.v. (Phòng thủ)
Phát hiện các hành vi tấn công, v.v. (phát hiện)
Xử lý sự cố (Các biện pháp ứng phó)
Khôi phục sau sự cố (phục hồi)
Nói cách khác, ngay từ giai đoạn thiết kế hệ thống, “phòng ngừa” chỉ là một trong bảy loại, trong khi “xử lý” và “khôi phục” được xác định là hai loại lớn độc lập. Các biện pháp chỉ tập trung vào phòng ngừa sẽ không thể đáp ứng được các tiêu chuẩn yêu cầu của hệ thống này.
Tại sao chỉ “trước khi xảy ra” là chưa đủ?
Nguyên nhân sâu xa là “ không thể ngăn chặn xâm nhập 100% ”.
★3 coi “các cuộc tấn công mạng thông thường khai thác các lỗ hổng đã được biết đến rộng rãi” là mối đe dọa tiềm tàng.Các cuộc tấn công khai thác lỗ hổng đã biết trên thiết bị VPN hoặc bộ định tuyến, hay việc lây nhiễm ransomware qua email, dù có thể giảm thiểu xác suất xảy ra bằng các biện pháp phòng vệ như cập nhật bản vá hoặc xác thực đa yếu tố, nhưng không thể loại bỏ hoàn toàn. Từ góc độ của đối tác kinh doanh, điều họ quan tâm không phải là “Công ty của quý vị có bị tấn công hay không”, mà là “Khi bị tấn công, quý vị có thể ngăn chặn thiệt hại lan rộng sang phía chúng tôi và khôi phục nguồn cung cấp nhanh chóng đến mức nào ”.
Trên thực tế, tiêu chí đạt mức ★3 nêu rõ rằng “khi xảy ra sự cố, các thủ tục tối thiểu cần thiết để báo cáo và chia sẻ thông tin với các bên liên quan trong và ngoài công ty, bao gồm cả đối tác kinh doanh, đã được xác định và thực hiện”, trong khi mức ★4 đề ra các biện pháp tăng cường khả năng phục hồi của chuỗi cung ứng, bao gồm “các nỗ lực nhằm đảm bảo hoạt động kinh doanh liên tục”.Từ góc độ toàn bộ chuỗi cung ứng, việc ngừng hoạt động của một công ty sẽ dẫn đến tình trạng ngừng cung ứng theo hiệu ứng domino, do đó, khả năng phục hồi (resilience) tất yếu trở thành mối quan tâm trọng tâm trong quá trình đánh giá.
Các bước chuẩn bị cho việc “trở lại” cần thực hiện khi đạt mức ★3
Nếu nghĩ rằng “chắc hẳn yêu cầu để khôi phục hệ thống sẽ bắt đầu từ cấp độ cao nhất là ★4”, bạn sẽ bị bất ngờ. Khi xem xét kỹ các yêu cầu đối với cấp độ ★3, ta thấy rằng cần phải có những chuẩn bị cụ thể liên quan đến việc ứng phó sự cố và khôi phục hệ thống.
(1) Xây dựng quy trình ứng phó sự cố gồm 5 bước (Số 6-1-1-1)
Ở mức ★3, yêu cầu phải xây dựng quy trình ứng phó sự cố bao gồm 5 bước sau đây.
① Báo cáo phát hiện → ② Hành động ban đầu → ③ Điều tra và xử lý → ④ Khôi phục → ⑤ Báo cáo cuối cùng
Điểm đáng chú ý là trong quy trình này, bước “④ Phục hồi” đã được đưa vào một cách rõ ràng. “Xử lý sự cố” không chỉ dừng lại ở việc khống chế sự cố, mà còn được định nghĩa là quá trình đưa hoạt động trở lại bình thường.
(2) Hoàn thiện hệ thống báo cáo và liên lạc (Số 6-1-1-2 đến 6-1-1-6)
Xây dựng danh sách các đầu mối liên lạc trong và ngoài công ty, bao gồm các cơ quan có liên quan và các bộ, ngành có thẩm quyền, cũng như các kênh báo cáo và chia sẻ thông tin
Làm rõ vai trò và trách nhiệm của CISO và các bộ phận phụ trách an ninh khi xảy ra sự cố
Kiểm tra hệ thống ít nhất một lần mỗi năm
Hoàn thiện mẫu báo cáo
Chia sẻ nội bộ các trường hợp sự cố và biện pháp ứng phó (ít nhất 1 lần/năm và khi xảy ra sự cố nghiêm trọng)
Ngoài ra, trong phân loại quản lý đối tác, việc quy định “vai trò và trách nhiệm của công ty và đối tác khi xảy ra sự cố” (Số 2-1-4-1) đối với các đối tác chia sẻ thông tin mật là yêu cầu ★3. Quá trình khôi phục không chỉ diễn ra riêng tại công ty mà cần được thiết kế trên cơ sở sự phối hợp trong chuỗi cung ứng.
(3) Sao lưu làm nền tảng cho việc khôi phục (Số 4-3-4)
Mặc dù được xếp vào danh mục “phòng thủ”, nhưng trên thực tế, sao lưu có thể được coi là một yêu cầu nhằm phục hồi hệ thống. Yêu cầu ở mức ★3 bao gồm 3 điểm sau đây.
Thực hiện sao lưu theo quy định về đối tượng sao lưu, tần suất sao lưu và thời hạn lưu trữ
Sao lưu từ xa các thông tin mật quan trọng
Xây dựng hướng dẫn khôi phục dữ liệu cho từng đối tượng sao lưu
Chỉ “sao lưu đơn thuần” là chưa đủ; việc có sẵn tài liệu hướng dẫn khôi phục cũng là yêu cầu bắt buộc đạt mức ★3. Vấn đề lớn nhất trong quá trình khôi phục sau khi bị tấn công bởi ransomware là những trường hợp “có bản sao lưu nhưng chưa có quy trình khôi phục rõ ràng” hoặc “bản sao lưu cũng bị mã hóa”, và việc lưu trữ tại địa điểm từ xa cùng việc xây dựng tài liệu hướng dẫn chính là những yêu cầu phản ánh bài học kinh nghiệm đó.
(4) Xác định mức độ khôi phục mục tiêu (Số 7-1-1-1)
Trong Nhóm lớn 7 “Phục hồi sau sự cố”, đối với các hệ thống quan trọng đối với việc duy trì hoạt động kinh doanh, sau khi xác định mức độ phục hồi mục tiêu của hoạt động dựa trên kịch bản tấn công mạng, việc xây dựng các biện pháp nhằm khôi phục hoạt động lên mức độ đó được yêu cầu đạt ★3. Trong tiêu chí đánh giá, hai ví dụ về các biện pháp được nêu ra như sau:
Duy trì hoạt động nhờ hệ thống: Xây dựng hệ thống dự phòng thông qua các thiết bị dự phòng và môi trường đám mây, v.v.
Duy trì hoạt động bằng nhân lực: Chuẩn bị thông tin liên lạc của đối tác và nhiều phương thức liên lạc khác nhau để sẵn sàng liên lạc và thực hiện công việc qua điện thoại, fax, v.v.
Việc “tiếp tục hoạt động bằng nhân lực” được nêu ra một cách trực tiếp là một điều đáng chú ý. Cho đến khi hệ thống được khôi phục hoàn toàn, việc cung ứng và liên lạc vẫn không bị gián đoạn, ngay cả khi phải sử dụng các phương pháp thủ công — đây chính là hình ảnh thực tế của “sự phục hồi” trong bối cảnh chuỗi cung ứng.
(5) Giáo dục và đào tạo dành cho toàn thể nhân viên (Số 4-2-2)
Việc giáo dục và huấn luyện về cách ứng phó khi xảy ra sự cố cũng là yêu cầu cấp ★3. Đối tượng áp dụng không chỉ bao gồm các thành viên ban lãnh đạo và nhân viên chính thức mà còn cả nhân viên tạm thời và nhân viên được điều động từ các đơn vị khác; các hoạt động này phải được thực hiện khi tiếp nhận nhân viên mới và ít nhất một lần mỗi năm, đồng thời phải lưu trữ hồ sơ và tiến hành kiểm tra nội dung hàng năm. Không chỉ dừng lại ở việc soạn thảo quy trình, mà còn cần có bằng chứng chứng minh rằng tổ chức có khả năng “hành động linh hoạt”.
★4: Yêu cầu “chứng minh khả năng trở lại”
Ở cấp độ ★4, yêu cầu để trở lại sẽ được nâng lên một bậc, từ “kế hoạch” sang “chứng minh”.
Thử nghiệm RPO và RTO (Số 7-1-1-2)
Đối với các hệ thống quan trọng đối với việc duy trì hoạt động kinh doanh, cần phải đáp ứng các yêu cầu sau đây.
Lưu trữ bản sao lưu để có thể khôi phục hệ thống về thời điểm mục tiêu (RPO)
Cần xác nhận rằng việc khôi phục bản sao lưu có thể được thực hiện đúng theo hướng dẫn khôi phục và trong thời gian khôi phục mục tiêu (RTO)
Nói cách khác, yêu cầu không chỉ dừng lại ở kế hoạch trên giấy mà còn phải xác nhận được rằng “thực tế có thể khôi phục lại trong thời gian quy định”. Đối với các doanh nghiệp chưa tiến hành diễn tập khôi phục, đây sẽ là rào cản thực tiễn trong việc đạt được chứng nhận ★4.
Các yêu cầu liên quan hỗ trợ công tác ứng phó và khắc phục sự cố
Ở ★4, các điều kiện tiên quyết hỗ trợ việc trở lại cũng được mở rộng.
Thu thập và lưu trữ nhật ký cần thiết cho việc điều tra (Số 4-4-3-1): Lưu trữ nhật ký của tường lửa, máy chủ proxy và máy chủ xác thực trong vòng 6 tháng. Nếu không thể xác định được “điều gì đã xảy ra” khi sự cố xảy ra, sẽ không thể đưa ra quyết định khôi phục an toàn.
Định nghĩa mức độ sự cố (Số 5-2-1): Xác định và phổ biến mức độ sự cố cùng phạm vi áp dụng của từng mức độ, đồng thời phân tích và xác định mức độ tương ứng khi nhận được cảnh báo. Đây là cơ sở để xác định thứ tự ưu tiên trong việc ứng phó và khôi phục theo mức độ nghiêm trọng.
Hệ thống giám sát và phân tích các cuộc tấn công mạng (Số 1-2-2): Xây dựng “hệ thống cho phép xác định phương án ứng phó khi sự cố xảy ra” dựa trên việc phát hiện các dấu hiệu báo trước.
“Công tác chuẩn bị khôi phục” cũng nằm trong phạm vi kiểm tra thực địa
Quá trình đánh giá là điều không thể bỏ qua. Trong phần “Các nội dung cần xác minh tại cuộc kiểm tra thực tế xếp hạng ★4”, chính sách xây dựng hệ thống đã nêu ra 3 điểm sau đây:
Hệ thống và quy trình quản lý lỗ hổng bảo mật
Quy trình xử lý sự cố an ninh
Chuẩn bị khôi phục theo các yêu cầu về duy trì hoạt động kinh doanh
Trong số 3 ví dụ được nêu ra, có 2 ví dụ liên quan đến giai đoạn “sau khi sự cố xảy ra”. Có thể hiểu một cách tự nhiên rằng, phía thẩm định sẽ xem xét dựa trên bằng chứng để đánh giá “liệu công ty này có thể phục hồi sau sự cố hay không” trước khi xem xét tính toàn diện của các thiết lập phòng thủ.
Gợi ý cho thực tiễn — Xây dựng các biện pháp dựa trên việc tính ngược từ thời điểm “trở lại”
Đối với các doanh nghiệp đang xem xét việc áp dụng Hệ thống đánh giá SCS, thay vì lần lượt giải quyết các yêu cầu trong danh sách từ trên xuống, cách tiếp cận hiệu quả hơn là tính ngược lại từ câu hỏi: “Khi hoạt động của công ty bị gián đoạn, cần bao nhiêu ngày và phải khôi phục đến mức độ nào thì mới không gây phiền hà cho đối tác?”. Cụ thể, chúng tôi khuyến nghị nên suy nghĩ theo trình tự sau đây.
Xác định các hệ thống và hoạt động quan trọng đối với việc duy trì hoạt động kinh doanh — Những yếu tố nào, nếu ngừng hoạt động, sẽ ảnh hưởng đến chuỗi cung ứng?
Thiết lập mức khôi phục mục tiêu, RPO và RTO — Xác định thời gian ngừng hoạt động có thể chấp nhận được dựa trên mối quan hệ với khách hàng
Xây dựng và kiểm chứng quy trình sao lưu và khôi phục — Kiểm tra xem liệu có thể khôi phục dữ liệu đúng như mục tiêu đã đề ra hay không
Xây dựng quy trình xử lý gồm 5 bước và hệ thống đường dây báo cáo — Thiết kế bao gồm việc báo cáo cho các đối tác kinh doanh và các cơ quan quản lý có thẩm quyền
Tăng cường nhận thức thông qua giáo dục và đào tạo — Liệu tất cả mọi người có thể trả lời được câu hỏi “Khi phát hiện ra điều gì, nên báo cáo cho ai?” hay không
Thứ tự này bao quát trực tiếp các yêu cầu cốt lõi từ ★3 đến ★4. Điều này không có nghĩa là các biện pháp phòng thủ (quản lý bản vá, xác thực đa yếu tố, bảo vệ ranh giới mạng, v.v.) là không cần thiết, nhưng nếu xem phòng thủ như một phương tiện nhằm “giành thêm thời gian để khôi phục hệ thống và giảm tần suất sự cố”, thì thứ tự ưu tiên đầu tư sẽ trở nên rõ ràng hơn.
Và thế là Incident Lake

Như đã phân tích ở trên, những điểm khó khăn trong việc ứng phó với sự cố mà hệ thống đánh giá SCS đề cập đến chính là “tốc độ” – tức là việc thực hiện suôn sẻ 5 giai đoạn từ báo cáo phát hiện đến phản ứng ban đầu, điều tra, khôi phục và báo cáo cuối cùng – cũng như “tính chính xác trong ghi chép và truyền đạt” – tức là việc cung cấp các báo cáo nhất quán cho các bên liên quan trong và ngoài công ty, bao gồm cả đối tác kinh doanh và các cơ quan quản lý, trong thời hạn quy định.
Chúng tôi sẽ liên kết các cảnh báo được phát hiện với mức độ sự cố để đánh giá, xác định hệ thống và đối tác nào bị ảnh hưởng, đồng thời lập báo cáo sơ bộ và báo cáo cuối cùng theo mẫu quy định, đồng thời lưu giữ các tài liệu này làm bằng chứng để trình bày trong các đợt kiểm tra, đánh giá và thẩm định hàng năm. Thành thật mà nói, việc vận hành toàn bộ quy trình này chỉ bằng nhân lực và các cuộc trao đổi qua chat là có giới hạn.
Incident Lake là nền tảng quản lý sự cố hỗ trợ quy trình này. Nền tảng này tự động hóa toàn bộ quy trình, từ việc báo cáo khi sự cố xảy ra cho đến khi hệ thống hoạt động trở lại, cũng như việc lập và quản lý báo cáo, giúp nhân viên phụ trách có thể dành thời gian tập trung vào nhiệm vụ cốt lõi là “ngăn chặn thiệt hại và khôi phục dịch vụ”. Do các bản ghi chép về quá trình xử lý được lưu trữ nguyên vẹn, điều này cũng góp phần chuẩn bị đầy đủ các bằng chứng cần thiết cho việc xác nhận của chuyên gia ★3 và kiểm tra thực địa ★4.
Chính vì hiện nay “năng lực ứng phó và khắc phục sự cố” đã được các đối tác đánh giá một cách minh bạch thông qua Hệ thống đánh giá SCS, nên chúng tôi khuyến nghị quý vị nên chuyển đổi cơ chế báo cáo và ghi chép sự cố sang hình thức không phụ thuộc vào nỗ lực cá nhân.
Hiện tại, các nội dung cụ thể hơn về việc triển khai Hệ thống đánh giá SCS đang được xem xét và hoàn thiện trong năm tài chính 2026. Quý vị vui lòng tham khảo các tài liệu công bố của IPA và Bộ Kinh tế, Thương mại và Công nghiệp để cập nhật thông tin mới nhất.
Tham khảo
Bộ Kinh tế, Thương mại và Công nghiệp: “Chính sách xây dựng hệ thống đánh giá các biện pháp an ninh nhằm tăng cường chuỗi cung ứng” (ngày 27 tháng 3 năm 2026)
Hệ thống đánh giá SCS: Các yêu cầu và tiêu chí đánh giá ★3 và ★4
*Bài viết này dựa trên thông tin công khai tính đến tháng 8 năm 2026.
Tác giả của bài viết này
Chủ tịch kiêm Tổng giám đốc điều hành (CEO)
Takaaki Kanetsuki
Công ty Cổ phần SIGQ – Giám đốc Điều hành
Tốt nghiệp chương trình sau đại học tại Đại học Tsukuba, chuyên ngành cơ sở dữ liệu và hệ thống phân tán.
Kỹ sư chuyên xử lý dữ liệu vận hành – loại thông tin phi cấu trúc và thời gian thực – vốn là yếu tố không thể thiếu trong kỷ nguyên trí tuệ nhân tạo (AI).
Gia nhập Công ty Cổ phần Money Forward ngay sau khi tốt nghiệp. Tham gia công tác quản lý và phát triển tại các môi trường phát triển trong và ngoài nước, bao gồm cả thời gian được điều động đến chi nhánh tại Việt Nam.
Gia nhập Công ty Cổ phần Plaid vào năm 2022 và phụ trách mảng Kỹ thuật Nền tảng (Platform Engineering). Tham gia phát triển hệ thống dữ liệu phân tán quy mô lớn.
Năm 2024, thành lập Công ty Cổ phần SIGQ.
Danh sách các bài viết hữu ích


