Odin Lab · Risk

Quản trị rủi ro CNTT: bắt đầu từ dịch vụ, không chỉ từ danh sách thiết bị

Odin Lab

Một danh sách tài sản đầy đủ vẫn chưa trả lời được dịch vụ nào sẽ ngừng và ai phải quyết định. Bắt đầu bằng bản đồ dịch vụ và một kịch bản cụ thể.

Muốn ưu tiên rủi ro CNTT, hãy bắt đầu từ dịch vụ cần bảo vệ, rồi nối mục tiêu với phụ thuộc, kiểm soát và bằng chứng. Danh sách thiết bị là đầu vào quan trọng, nhưng tự nó chưa chỉ ra điều gì đáng xử lý trước.

TÌNH HUỐNG ODIN LAB BANK · GIẢ LẬP

Trong một cuộc họp giả lập, IT báo các máy chủ đều hoạt động; bộ phận thanh toán lại cho biết khách hàng chưa hoàn thành chuyển tiền. Hai báo cáo không nhất thiết mâu thuẫn: chúng đang đo hai phạm vi khác nhau.

Mục tiêu: khách hàng hoàn thành được việc gì?

Với dịch vụ chuyển tiền, mục tiêu không chỉ là ứng dụng truy cập được. Cần hiểu giao dịch được xác thực, xử lý, ghi nhận và có trạng thái rõ ràng. Chủ dịch vụ xác định kết quả cần bảo vệ; IT giải thích các điều kiện kỹ thuật để đạt kết quả đó.

Rủi ro: viết thành một kịch bản có tác động

Thay cho “máy chủ có rủi ro”, thử viết: “Nếu thành phần xác thực không hoạt động và phương án thay thế chưa được kiểm chứng, khách hàng có thể không hoàn thành chuyển tiền dù hệ thống xử lý phía sau vẫn sẵn sàng.” Đây là giả thuyết phân tích, chưa phải sự cố đã xảy ra.

Kiểm soát: chọn biện pháp đúng với nguyên nhân

Thêm tài nguyên máy chủ không giải quyết được mọi phụ thuộc. Cần xem khả năng dự phòng của xác thực, quyền truy cập khi có sự cố, thứ tự khôi phục và cách kiểm tra đầu cuối. Chọn biện pháp sau khi biết điểm yếu, không bắt đầu bằng một danh sách công nghệ muốn mua.

Bằng chứng: biến nhận định thành điều có thể kiểm tra

Odin Lab đề xuất một bảng ngắn: dịch vụ; phụ thuộc; kịch bản; kiểm soát; bằng chứng gần nhất; khoảng trống. Bằng chứng có thể là kết quả kiểm thử phù hợp, nhật ký và xác nhận nghiệp vụ. “Có quy trình” chỉ chứng minh tài liệu tồn tại, chưa chứng minh quy trình hoạt động.

Trách nhiệm: tách người cung cấp dữ liệu và người chấp nhận rủi ro

IT sở hữu thông tin kỹ thuật và thực thi kiểm soát; chủ dịch vụ xác nhận tác động; chức năng rủi ro đặt câu hỏi và theo dõi; quyết định chấp nhận thuộc thẩm quyền đã phân công. Người viết báo cáo không tự động là người có quyền chấp nhận.

Quyết định: ưu tiên gì tiếp theo?

Trong tình huống giả lập, bước có giá trị trước mắt là kiểm chứng phụ thuộc xác thực và kiểm tra giao dịch đầu cuối. Chưa đủ căn cứ để kết luận phải thay toàn bộ nền tảng hoặc rằng mọi rủi ro đã được xử lý.

Công cụ áp dụng trong cuộc họp tiếp theo

  1. Chọn đúng một dịch vụ và một kết quả khách hàng mong đợi.
  2. Vẽ các phụ thuộc chính, ghi rõ phần chưa biết.
  3. Chọn một kịch bản khiến kết quả không đạt.
  4. Đối chiếu kiểm soát với bằng chứng hiện có.
  5. Chốt một hành động, một chủ sở hữu và thời điểm đánh giá lại.
Khung tham chiếu: NIST CSF 2.0 cho quản trị và ưu tiên rủi ro; COBIT 2019 cho governance/management objectives; ISO/IEC 27001:2022 cho hệ thống quản lý an toàn thông tin; và Thông tư 09/2020/TT-NHNN trong bối cảnh hoạt động ngân hàng tại Việt Nam.

Tham chiếu: NIST SP 1301 mô tả hồ sơ hiện tại và hồ sơ mục tiêu theo các kết quả an ninh mạng. Odin Lab vận dụng cách nhìn khoảng cách hiện tại–mục tiêu vào ví dụ này; bảng thực hành trên là đề xuất biên tập, không phải biểu mẫu bắt buộc của NIST và không bao phủ toàn bộ rủi ro CNTT.

Nguồn chính thức: NIST SP 1301

Hiểu bối cảnh Odin Lab Bank → Rà soát bằng checklist → Trao đổi phạm vi đánh giá

← Về trang chủ

Để lại một bình luận

Bình luận được duyệt trước khi hiển thị. Email không công khai. Vui lòng không gửi thông tin nội bộ, dữ liệu khách hàng hoặc thông tin nhạy cảm.