Ngoại lệ bảo mật đến hạn: ngân hàng cần quyết định gì?

Một thành phần phần mềm cần nâng cấp để xử lý điểm yếu bảo mật, nhưng việc nâng cấp chưa tương thích với ứng dụng đang vận hành. Nhóm kỹ thuật đề nghị hoãn, nghiệp vụ cần duy trì dịch vụ, còn đơn vị an toàn thông tin yêu cầu tăng kiểm soát trong thời gian chờ. Ngân hàng phê duyệt một ngoại lệ có thời hạn.

Đến ngày hết hạn, thay đổi chưa hoàn thành. Một đề nghị gia hạn được gửi đi với lý do quen thuộc: dịch vụ vẫn hoạt động và chưa ghi nhận sự cố. Quyết định lúc này cần dựa vào mức rủi ro hiện tại, bằng chứng về kiểm soát tạm thời và phương án xử lý tiếp theo. Việc chưa thấy sự cố chỉ là một phần thông tin.

Bài viết vận dụng nghiên cứu của ISACA về nợ bảo mật và tài liệu NIST vào quản lý ngoại lệ trong ngân hàng. Mục tiêu là giúp một quyết định tạm thời tiếp tục được kiểm soát trong suốt thời gian có hiệu lực, với người chịu trách nhiệm và điều kiện đánh giá lại rõ ràng.

1 Từ nghiên cứu về nợ bảo mật đến quản lý ngoại lệ

ISACA mô tả nợ bảo mật, tiếng Anh là security debt, là phần rủi ro tích lũy gắn với hệ thống cũ, trì hoãn khắc phục và thiếu nguồn lực bảo mật. Tài liệu “Security Debt: The Unseen Risk Undermining Cyber Resilience”, công bố ngày 03/03/2026, xem xét đồng thời mức tác động, thời gian tồn tại và tốc độ phát sinh vấn đề cùng loại. [1]

Đối chiếu với Khung an ninh mạng NIST CSF 2.0, ID.RA-06 đề cập lựa chọn, ưu tiên, lập kế hoạch, theo dõi và truyền đạt phương án ứng phó rủi ro; ID.RA-07 đề cập quản lý, đánh giá tác động, ghi nhận và theo dõi thay đổi cùng ngoại lệ. Đây là các kết quả tham chiếu, không phải một quy trình gia hạn ngoại lệ dành riêng cho ngân hàng. [2]

NIST IR 8286 Revision 1, ban hành tháng 12/2025, hướng dẫn kết nối thông tin rủi ro an ninh mạng với quản trị rủi ro doanh nghiệp, trong đó có sử dụng sổ đăng ký rủi ro. [3] Điều này giúp đặt vấn đề kỹ thuật vào bối cảnh mục tiêu kinh doanh và quyết định quản trị.

Từ các nguồn trên, Odin Lab đề xuất một nguyên tắc thực hành: mỗi ngoại lệ cần gắn với rủi ro cụ thể, người có thẩm quyền quyết định, kiểm soát có bằng chứng và thời điểm đánh giá lại. Hồ sơ, tình huống và cách triển khai bên dưới là đề xuất ứng dụng của Odin Lab.

2 Phân biệt ngoại lệ với chấp nhận rủi ro và nợ bảo mật

Trong phạm vi bài viết, ngoại lệ bảo mật là việc cho phép một sai lệch so với yêu cầu hoặc chuẩn nội bộ theo điều kiện đã xác định. Chấp nhận rủi ro là quyết định giữ lại một mức rủi ro sau khi đánh giá. Hai việc có thể đi cùng nhau, nhưng phê duyệt ngoại lệ cần làm rõ phần rủi ro được giữ lại.

Một ngoại lệ được quản lý tốt vẫn có thể chứa nợ bảo mật. Ngược lại, nợ bảo mật có thể phát sinh từ những tồn tại chưa từng được ghi nhận thành ngoại lệ. Vì vậy, mục tiêu quản trị là nhìn thấy và xử lý đúng phần phơi nhiễm, thay vì cố giảm số ngoại lệ bằng cách đổi tên hồ sơ.

Việc chấp nhận rủi ro phải nằm trong thẩm quyền và giới hạn của tổ chức. Một phê duyệt nội bộ không tự làm mất hiệu lực của nghĩa vụ pháp lý hoặc cam kết hợp đồng liên quan; những trường hợp đó cần được bộ phận có chức năng đánh giá riêng.

3 Tình huống OLB khi đề nghị gia hạn không còn giống quyết định ban đầu

Odin Lab Bank, gọi tắt là OLB, là ngân hàng giả lập phục vụ nghiên cứu và đào tạo. Các điều kiện và mốc thời gian dưới đây hoàn toàn là giả định minh họa.

OLB sử dụng một thành phần phần mềm cho dịch vụ tiếp nhận hồ sơ trực tuyến. Nhóm ứng dụng chưa thể nâng cấp ngay vì cần xử lý vấn đề tương thích. Sau khi đánh giá, người được phân cấp cho phép hoãn trong 30 ngày, kèm giới hạn kết nối, thu hẹp quyền quản trị, theo dõi dấu hiệu bất thường và kế hoạch kiểm thử nâng cấp. Mốc 30 ngày là giả định của tình huống, không phải thời hạn chuẩn từ ISACA hoặc NIST.

Trước khi hết hạn, chủ hệ thống đề nghị kéo dài thêm. Tuy nhiên, dịch vụ đã bổ sung kết nối phục vụ một nhóm đối tác mới. Phạm vi có thể tiếp cận thành phần phần mềm đã thay đổi, trong khi bằng chứng kiểm thử biện pháp hạn chế kết nối vẫn chỉ phản ánh phạm vi cũ.

OLB chưa có đủ căn cứ để coi mức rủi ro vẫn như lần phê duyệt trước. Nhóm ứng dụng cần cập nhật phạm vi và đánh giá tác động; an toàn thông tin cần kiểm tra hiệu lực của kiểm soát trong điều kiện mới; chủ dịch vụ cần xác nhận ảnh hưởng của các lựa chọn tiếp tục, hạn chế hoặc tạm ngừng chức năng liên quan.

Kết quả cần trình là một đề nghị quyết định mới có căn cứ. Nếu điều kiện đã thay đổi trước ngày hết hạn, OLB phải xem xét sớm hơn theo cơ chế đã thiết kế, thay vì chờ tới kỳ gia hạn.

4 Hồ sơ nào giúp ra quyết định

Odin Lab đề xuất một hồ sơ ngoại lệ ngắn, có liên kết tới tài liệu chi tiết. Hồ sơ cần đi qua đủ sáu nội dung sau để người phê duyệt hiểu mình đang quyết định điều gì.

Mỗi hồ sơ nên có mã duy nhất, mã hệ thống hoặc dịch vụ liên quan và liên kết tới công việc khắc phục. Có thể sử dụng công cụ quản lý dịch vụ CNTT hoặc sổ theo dõi hiện có; dữ liệu cần được liên kết để tránh phát sinh các danh sách độc lập khó đối soát.

Một hồ sơ đầy đủ chưa chứng minh kiểm soát hiệu quả. Với đề xuất hạn chế kết nối trong tình huống OLB, bằng chứng phù hợp có thể gồm xác nhận cấu hình được phê duyệt và kết quả kiểm tra các trường hợp được phép, bị chặn. Việc ghi tên một công cụ đang cài đặt chưa đủ trả lời các câu hỏi đó.

5 Đến hạn cần lựa chọn và ghi nhận kết quả

Trước ngày hết hiệu lực, chủ hồ sơ cập nhật tiến độ, phạm vi và đánh giá rủi ro. OLB đề xuất xem xét các hướng xử lý sau, tùy kết quả và phân cấp thực tế.

Đóng ngoại lệ khi việc khắc phục đã được kiểm chứng

Nhóm thực hiện cung cấp kết quả thay đổi và kiểm thử đáp ứng yêu cầu. Đơn vị được giao kiểm tra xác nhận trong phạm vi phù hợp, ghi lại rủi ro hoặc tồn tại còn lại. Hoàn thành tác vụ kỹ thuật và đóng ngoại lệ cần được liên kết với nhau bằng bằng chứng.

Phê duyệt tiếp tục có điều kiện khi còn cơ sở chấp nhận

Việc gia hạn cần nêu rõ điều gì đã thay đổi, vì sao kế hoạch trước chưa hoàn thành, kiểm soát hiện tại còn hiệu lực thế nào và mốc xử lý tiếp theo có khả thi không. Người có thẩm quyền đánh giá lại mức rủi ro, điều kiện áp dụng và phạm vi được phép tiếp tục.

Lịch sử gia hạn phải được giữ nguyên. Mỗi quyết định mới có ngày hiệu lực riêng, đồng thời hồ sơ vẫn thể hiện ngày phát hiện tồn tại và tổng thời gian chưa khắc phục.

Hạn chế phạm vi hoặc chuyển phương án vận hành

Nếu chưa thể khắc phục nhưng giữ nguyên phạm vi làm mức rủi ro vượt giới hạn cho phép, OLB có thể xem xét thu hẹp chức năng, giảm phạm vi tiếp cận hoặc chuyển sang phương án thay thế đã được đánh giá. Lựa chọn cần tính tới ảnh hưởng nghiệp vụ, dữ liệu và khả năng vận hành thực tế.

Báo cáo vượt cấp hoặc dừng phần hoạt động không đủ điều kiện

Khi vượt thẩm quyền hoặc vi phạm điều kiện của quyết định cũ, chủ hồ sơ phải báo cáo theo cơ chế đã xác định. Hệ thống nhắc hạn có thể cảnh báo và chuyển cấp; việc tự động ngắt một dịch vụ quan trọng chỉ phù hợp khi đã có thiết kế, thẩm quyền và kiểm thử tác động. Cần chuẩn bị trước để tránh lựa chọn vội giữa tiếp tục không kiểm soát và dừng dịch vụ đột ngột.

6 Theo dõi bằng chỉ số có thể diễn giải

ISACA đề xuất Chỉ số nợ bảo mật, tên tiếng Anh là Security Debt Index, gọi tắt là SDI. Chỉ số tổng hợp mức tác động, thời gian tồn tại và tốc độ phát sinh vấn đề cùng loại để hỗ trợ nhận biết xu hướng, bổ sung cho đánh giá rủi ro hiện có. [1]

Trong giai đoạn khởi động, Odin Lab đề xuất OLB ưu tiên các số liệu có thể truy về hồ sơ thay vì vội xây dựng một điểm tổng hợp. Bảng theo dõi có thể bắt đầu với bốn nhóm sau.

• Ngoại lệ đã hết hiệu lực mà chưa có kết quả đóng hoặc quyết định tiếp theo hợp lệ. Báo cáo tách khỏi nhóm đã được phê duyệt gia hạn.
• Tuổi tồn tại của vấn đề, tính từ mốc phát hiện đã thống nhất, cùng số lần gia hạn. Không đặt lại tuổi tồn tại sau mỗi lần phê duyệt.
• Ngoại lệ có kiểm soát tạm thời chưa được kiểm chứng hoặc kiểm chứng không đạt trong phạm vi hiện tại. Cần tách trạng thái chưa biết khỏi trạng thái không đạt.
• Dịch vụ phụ thuộc vào nhiều ngoại lệ và các tồn tại mới phát sinh trong kỳ. Khi tổng hợp, cần loại trùng một vấn đề xuất hiện ở nhiều nguồn và xem xét rủi ro cộng dồn trên cùng dịch vụ.

Nếu sử dụng tỷ lệ, báo cáo phải nêu mẫu số và thời điểm chốt dữ liệu. Ví dụ, tỷ lệ ngoại lệ có bằng chứng kiểm tra còn phù hợp chỉ có ý nghĩa khi đã thống nhất bằng chứng cần cập nhật theo chu kỳ nào hoặc sau thay đổi nào. Không nên đặt chung một thời hạn hiệu lực bằng chứng cho mọi loại kiểm soát.

7 Trách nhiệm cần được tách rõ

Chủ rủi ro chịu trách nhiệm theo dõi mức rủi ro đối với mục tiêu được giao và đề xuất cách xử lý. Người này có thể đồng thời là chủ dịch vụ, nhưng không mặc nhiên có thẩm quyền phê duyệt mọi mức rủi ro. Quyền quyết định cần theo phân cấp của tổ chức.

Nhóm kỹ thuật thực hiện khắc phục và vận hành kiểm soát được giao. An toàn thông tin đánh giá chuyên môn, hỗ trợ kiểm chứng và theo dõi theo chức năng. Quản lý rủi ro thực hiện phản biện, tổng hợp và báo cáo theo mô hình tổ chức. Kiểm toán nội bộ cung cấp đánh giá độc lập, không thay người quản lý phê duyệt ngoại lệ hằng ngày.

Để theo dõi được tới cùng, mỗi hành động cần có một người hoặc vai trò đầu mối cụ thể, thời hạn và kết quả mong đợi. Ghi chung “CNTT phối hợp xử lý” khó giúp người điều hành biết phải yêu cầu ai cập nhật khi hồ sơ sắp hết hạn.

8 Bắt đầu từ một nhóm ngoại lệ đang tồn tại

OLB có thể khởi động bằng một nhóm ngoại lệ cùng loại, chẳng hạn các tồn tại phần mềm cần nâng cấp. Trước hết, đối chiếu danh sách với nguồn phát hiện, loại trùng và bổ sung các trường còn thiếu. Hồ sơ chưa xác định được chủ rủi ro hoặc phạm vi phải được ưu tiên làm rõ.

Tiếp theo, chọn những trường hợp sắp hết hạn, gia hạn nhiều lần hoặc gắn với dịch vụ quan trọng để rà soát. Buổi xem xét cần có chủ dịch vụ, nhóm thực hiện và các chức năng đánh giá liên quan, với kết quả là quyết định cụ thể cho từng trường hợp và đầu việc có thời hạn.

Sau một chu kỳ, đánh giá chất lượng quyết định bằng khả năng truy xuất hồ sơ: có biết vì sao cho phép tiếp tục, kiểm soát đã được kiểm tra ra sao và vấn đề nào đã được khắc phục không? Kết quả này là cơ sở để điều chỉnh quy trình và cách báo cáo trước khi mở rộng.

Việc áp dụng công cụ tự động có thể bắt đầu từ nhắc hạn, phát hiện hồ sơ thiếu trường và liên kết bằng chứng. Quyết định giữ lại mức rủi ro cần được trao cho đúng thẩm quyền, với thông tin đủ để đánh giá.

Kết luận của Odin Lab

Ngoại lệ giúp tổ chức xử lý những tình huống chưa thể đáp ứng ngay một yêu cầu bảo mật. Giá trị của cơ chế này phụ thuộc vào việc ngân hàng còn nhìn thấy phần rủi ro tồn tại, kiểm chứng được điều kiện đã phê duyệt và đưa vấn đề trở lại bàn quyết định khi cần.

Trong tình huống OLB, thay đổi kết nối làm căn cứ phê duyệt cũ không còn đủ cho đề nghị gia hạn. Bước cần làm là đánh giá lại phạm vi, kiểm tra kiểm soát và lựa chọn cách tiếp tục phù hợp. Với một nhóm ngoại lệ hiện hữu, ngân hàng có thể bắt đầu ngay bằng ba câu hỏi: ai chịu trách nhiệm, bằng chứng nào còn phù hợp và quyết định tiếp theo phải có trước khi nào?

Nguồn tham khảo

[1] ISACA. Security Debt: The Unseen Risk Undermining Cyber Resilience. White paper, 03/03/2026. Tham khảo khái niệm nợ bảo mật và mô hình SDI. Đọc nguồn gốc.

[2] NIST. The NIST Cybersecurity Framework 2.0. 26/02/2024, trang 19, ID.RA-06 và ID.RA-07. Tham khảo kết quả quản lý phương án ứng phó và ngoại lệ. Đọc tài liệu.

[3] NIST. IR 8286 Revision 1, Integrating Cybersecurity and Enterprise Risk Management. 12/2025. Tham khảo cách kết nối thông tin rủi ro an ninh mạng với quản trị rủi ro doanh nghiệp. Đọc tài liệu.

Đọc tiếp tại Odin Lab

Sao lưu thành công, ngân hàng đã sẵn sàng phục hồi sau tấn công mạng?

Vì sao ngân hàng cần lồng ghép Zero Trust và Defense in Depth trong thực tế

Nghiên cứu & Ứng dụng · Odin Lab Bank