Q005 — Một kiểm soát tốt phải làm thay đổi rủi ro như thế nào?

Odin Lab | ODIN 101 — Digital Trust & Resilience
Banking Technology • Risk • GRC • Audit • Resilience • AI

Có Control chưa đủ; Control phải thực sự làm giảm Risk.

Trong Q001, chúng ta bắt đầu từ mục tiêu. Q002 giúp phân biệt Threat, Vulnerability và Risk. Q003 tập trung vào cách mô tả một rủi ro rõ ràng. Q004 trả lời câu hỏi: Rủi ro này quan trọng đến mức nào?

Bây giờ chúng ta đi tiếp một bước: Chúng ta sẽ làm gì với rủi ro đó?

Đó là bước Control — Kiểm soát trong Odin Risk Management Method.

Đây cũng là nơi rất nhiều tổ chức dễ rơi vào một suy nghĩ quen thuộc: có policy, có firewall, có backup, có MFA, có DR site, có quy trình — vậy là Risk đã được kiểm soát?

Chưa chắc.

Bởi vì việc một Control tồn tại không đồng nghĩa với việc nó đang thực sự làm giảm Risk. Câu hỏi quan trọng hơn phải là:

Control này đã làm thay đổi Risk như thế nào?

1. Control tồn tại chưa chắc đã có giá trị

Hãy bắt đầu bằng một ví dụ rất quen thuộc. Một hệ thống có backup hàng ngày. Backup job chạy xanh. Dashboard không có lỗi. Nghe có vẻ yên tâm.

Nhưng nếu chưa từng restore thử, chúng ta vẫn chưa biết dữ liệu có thực sự sử dụng được khi cần hay không.

Tương tự: có firewall chưa chắc rule đã phù hợp; có MFA chưa chắc mọi tài khoản quan trọng đều được áp dụng; có DR site chưa chắc dịch vụ có thể phục hồi trong thời gian yêu cầu; có quy trình chưa chắc người thực hiện biết phải làm gì khi sự cố thật sự xảy ra.

Một Control chỉ thực sự có giá trị khi nó làm giảm khả năng Risk xảy ra, giảm mức độ hậu quả, hoặc giúp tổ chức phục hồi tốt hơn khi Risk xảy ra.

Risk Management không nên dừng ở câu “Chúng ta có Control rồi”, mà phải đi tiếp: Control đó có tác dụng gì đối với Risk?

2. Bắt đầu từ Risk, không bắt đầu từ danh sách Control

Một cách làm khá phổ biến là lấy một danh sách controls rồi hỏi: “Cái nào chúng ta đã có?”. Cách này hữu ích khi rà soát compliance. Nhưng nếu mục tiêu là quản trị Risk, thứ tự nên khác.

Tại Odin Lab, tôi sử dụng logic: Objective → Risk → Assess → Control.

Tức là phải hiểu trước mục tiêu nào đang cần bảo vệ, Risk scenario là gì, nguyên nhân nằm ở đâu, hậu quả là gì và Risk hiện tại quan trọng đến mức nào. Sau đó mới hỏi: Control nào thực sự có thể làm thay đổi Risk này?

Ví dụ, nếu nguyên nhân là một dịch vụ phụ thuộc vào một hạ tầng duy nhất, việc tổ chức thêm khóa đào tạo awareness cho nhân viên gần như không giải quyết đúng vấn đề. Nhưng redundancy, alternate path hoặc failover có thể tác động trực tiếp hơn.

Một Control tốt không phải là Control “hay”. Nó phải là Control đúng với Risk đang cần xử lý.

3. Control có thể tác động vào Risk ở đâu?

Trong Q003, chúng ta đã dùng cấu trúc: Nguyên nhân → Rủi ro → Hậu quả. Control cũng có thể tác động vào ba điểm này.

Tác động vào nguyên nhân. Ví dụ nguyên nhân là privileged account chưa có MFA. Control phù hợp có thể là bắt buộc MFA hoặc sử dụng PAM, nhằm giảm khả năng credential bị sử dụng trái phép.

Tác động vào khả năng Risk xảy ra. Ví dụ một hệ thống có thể mất availability. Redundancy, replication hoặc automatic failover có thể làm giảm khả năng service interruption.

Tác động vào hậu quả. Có những Risk không thể ngăn hoàn toàn. Khi đó Control có thể tập trung vào giảm hậu quả. DDoS vẫn có thể xảy ra, nhưng traffic filtering, capacity, rate limiting và recovery procedure có thể giúp giảm mức độ gián đoạn.

Ở góc nhìn thực hành, chúng ta thường gặp ba nhóm: Preventive — Phòng ngừa, Detective — Phát hiện và Corrective / Recovery — Khắc phục và phục hồi. Một Risk quan trọng thường cần nhiều lớp Control, chứ không chỉ một biện pháp đơn lẻ.

4. Case Odin Lab Bank: Digital Payment Service

Hãy quay lại Risk scenario chúng ta đã dùng trong Q003 và Q004:

Bởi vì dữ liệu tại site dự phòng chưa được kiểm thử đầy đủ sau thay đổi, dữ liệu có thể không ở trạng thái sử dụng được khi cần chuyển đổi, dẫn đến dịch vụ thanh toán không phục hồi trong thời gian yêu cầu và làm gián đoạn giao dịch khách hàng.

Bây giờ câu hỏi là: Control nào thực sự giúp giảm Risk này?

Có thể có nhiều biện pháp: replication monitoring, automated consistency check, backup verification, scheduled restore test, recovery runbook, DR exercise, change control yêu cầu retest sau thay đổi lớn, automatic failover tại các thành phần phù hợp và emergency access được kiểm soát.

Nhưng mỗi Control có một mục đích khác nhau. Replication monitoring giúp phát hiện bất thường sớm. Restore test giúp kiểm tra dữ liệu có thực sự sử dụng được hay không. DR exercise kiểm tra khả năng phục hồi end-to-end. Change control giúp giảm khả năng một thay đổi mới làm suy giảm recovery capability.

Điểm quan trọng không phải là có bao nhiêu Controls, mà là mỗi Control phải được nối rõ với Risk mà nó đang xử lý.

5. Một Control tốt phải có mục tiêu, thiết kế và bằng chứng

Có một cách rất đơn giản để kiểm tra chất lượng của Control. Đừng chỉ hỏi “Control này là gì?”, hãy hỏi thêm: Control này nhằm đạt điều gì?

Ví dụ, thay vì chỉ ghi “Backup”, hãy xác định: Mục tiêu kiểm soát là bảo đảm dữ liệu quan trọng có thể được phục hồi trong thời gian và mức mất dữ liệu được chấp nhận.

Khi mục tiêu đã rõ, ta mới biết backup hiện tại có đủ hay không.

Tương tự, thay vì chỉ ghi “MFA”, nên hiểu mục tiêu là giảm khả năng chỉ cần credential bị lộ là người không được phép có thể truy cập tài khoản quan trọng.

Sau đó cần kiểm tra thêm hai lớp. Thứ nhất, Control có được thiết kế đúng không? Ví dụ backup chạy mỗi ngày nhưng Business yêu cầu RPO là 15 phút; Control có thể vận hành đúng như thiết kế nhưng thiết kế ban đầu vẫn chưa đủ.

Thứ hai, Control có thực sự vận hành không? Ví dụ policy yêu cầu MFA cho privileged accounts nhưng một phần tài khoản vẫn đang được miễn MFA. Thiết kế đúng nhưng vận hành chưa đầy đủ.

Đó là lý do sau bước Control trong Odin Method là Evidence — Bằng chứng. Backup cần restore result. MFA cần configuration và authentication log. DR cần recovery test result. Access review cần approval record. Monitoring cần alert history và response ticket.

Một Control tốt không chỉ hoạt động. Nó phải có thể chứng minh rằng nó đang hoạt động.

6. Không phải càng nhiều Control càng tốt

Một suy nghĩ khá tự nhiên là: nhiều Control hơn thì ít Risk hơn. Không phải lúc nào cũng đúng.

Quá nhiều Controls có thể tạo thêm chi phí, độ phức tạp, manual work, false alert, delay và thậm chí Risk mới. Ví dụ, một quy trình change có quá nhiều lớp approval có thể giúp giảm một số sai sót nhưng lại khiến emergency patch bị chậm. Một security control quá chặt cũng có thể khiến người dùng tìm cách bypass.

Mục tiêu không phải là càng nhiều Control càng tốt, mà là đủ Control để đưa Risk về mức chấp nhận được với chi phí và độ phức tạp hợp lý.

Trong số rất nhiều Controls, cũng cần xác định đâu là Key Controls — Kiểm soát trọng yếu. Đó là những Control nếu thất bại thì Risk có thể tăng lên đáng kể.

Ví dụ với recovery risk, replication monitoring, restore test và DR exercise có thể là Key Controls. Mỗi Key Control cần có Control Owner rõ ràng, biết Control xử lý Risk nào, mục tiêu là gì, Control chạy khi nào, bằng chứng ở đâu, điều gì được coi là failure và ai phải hành động khi Control không hoạt động.

7. Sáu câu hỏi của Odin cho một Control

1. Control này đang xử lý Risk nào?
2. Nó tác động vào nguyên nhân, khả năng xảy ra hay hậu quả?
3. Mục tiêu của Control là gì?
4. Control được thiết kế có đủ để đạt mục tiêu không?
5. Bằng chứng nào cho thấy Control đang thực sự hoạt động?
6. Sau Control, mức Risk còn lại có chấp nhận được không?

Nếu chưa trả lời được sáu câu này, rất khó khẳng định rằng Control đang thực sự quản lý Risk.

Kết nối với Odin Risk Management Method

Trong Odin Method: Objective → Risk → Assess → Control → Evidence → Responsibility → Decision & Monitor → Learn.

Q005 tập trung vào bước Control. Nhưng Control không đứng một mình. Nó phải xuất phát từ một Risk đã được mô tả rõ, được lựa chọn dựa trên Assessment, tạo ra Evidence, có người chịu trách nhiệm và cuối cùng giúp tổ chức đánh giá Residual Risk để đưa ra Decision.

Một Control tốt không được đánh giá bằng việc nó tồn tại. Nó được đánh giá bằng việc nó làm thay đổi Risk như thế nào.

Kết luận

Một firewall chưa phải là quản trị rủi ro. Một policy chưa phải là quản trị rủi ro. Một backup chưa phải là quản trị rủi ro. Một DR site cũng chưa phải là quản trị rủi ro.

Chúng chỉ thực sự có giá trị khi chúng ta hiểu: Risk nào đang được kiểm soát, Control tác động vào phần nào của Risk, Control có thực sự hoạt động không, bằng chứng là gì và Risk còn lại có chấp nhận được không.

Vì vậy, thay vì chỉ hỏi “Chúng ta có Control chưa?”, hãy hỏi:

Control này đã làm thay đổi Risk như thế nào?

Đó là bước chuyển từ quản lý danh sách kiểm soát sang quản trị rủi ro thực sự.

TURN RISK INTO VALUE.

Đọc tiếp trong ODIN 101

← Q004: Đánh giá rủi ro thế nào để không biến thành trò chấm điểm?

Bắt đầu từ Q001: Quản trị rủi ro thực sự bắt đầu từ đâu?

Đọc tiếp → Q006: Làm thế nào để chứng minh một Control thực sự hoạt động?

Xem toàn bộ ODIN 101 — Digital Trust & Resilience →

Tài liệu tham khảo

ISACA — CRISC Exam Content Outline.

ISO 31000:2018 — Risk Management — Guidelines.

ISO/IEC 27001 và ISO/IEC 27002.

NIST Cybersecurity Framework 2.0.