Q002 — Threat, Vulnerability và Risk khác nhau như thế nào?

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

Vì sao một lỗ hổng Critical chưa chắc đã là một rủi ro Critical?

Trong Q001, chúng ta bắt đầu quản trị rủi ro bằng một câu hỏi rất cơ bản: Chúng ta đang cố đạt được hoặc bảo vệ điều gì?

Khi objective đã rõ, câu hỏi tiếp theo là: Điều gì có thể ảnh hưởng đến mục tiêu đó?

Đây cũng là lúc ba khái niệm rất thường gặp trong Technology Risk xuất hiện: Threat, Vulnerability và Risk.

Chúng thường được đặt cạnh nhau trong báo cáo security, vulnerability dashboard, audit finding hay risk register. Nhưng trong thực tế, chúng không phải là ba cách gọi khác nhau của cùng một vấn đề.

Một threat không phải là risk. Một vulnerability cũng không phải là risk. Và việc một hệ thống có nhiều vulnerabilities nghiêm trọng không tự động có nghĩa rằng business risk của hệ thống đó cũng cao tương ứng.

Điểm khác biệt nằm ở context và objective.

1. Threat — Điều gì có khả năng gây hại?

Threat có thể hiểu đơn giản là một nguồn, tác nhân hoặc sự kiện có khả năng gây ra hậu quả bất lợi.

Trong môi trường công nghệ, threat có thể là cyber attacker, malware, insider misuse, hardware failure, mất điện, lỗi nhà cung cấp, human error hoặc một sự kiện tự nhiên.

Threat trả lời câu hỏi: Điều gì có thể gây ra vấn đề?

Ví dụ, một nhóm tấn công mạng có khả năng khai thác các hệ thống Internet-facing là một threat. Việc mất kết nối với một nhà cung cấp cloud cũng có thể là threat đối với dịch vụ phụ thuộc vào nhà cung cấp đó.

Nhưng chỉ biết rằng threat tồn tại vẫn chưa đủ để đánh giá risk.

2. Vulnerability — Điểm yếu nào có thể bị khai thác?

Vulnerability là một điểm yếu, thiếu sót hoặc điều kiện có thể làm tăng khả năng threat gây ra hậu quả.

Trong CNTT, vulnerability có thể là một phần mềm chưa vá, cấu hình sai, weak authentication, quyền truy cập quá rộng, network segmentation không phù hợp, quy trình manual dễ sai hoặc một dependency không có redundancy.

Vulnerability trả lời câu hỏi: Threat có thể tác động thông qua điểm yếu nào?

Một critical CVE trên máy chủ Internet-facing là vulnerability. Một privileged account không có MFA cũng là vulnerability. Một dịch vụ trọng yếu chỉ chạy trên một infrastructure component duy nhất cũng có thể là một điểm yếu về resilience.

Nhưng vulnerability vẫn chưa phải là risk. Đây là một nhầm lẫn rất phổ biến.

Hãy hình dung một căn nhà.

Trong khu phố có một tên trộm. Đó là Threat. Một cửa sổ tầng một bị quên khóa. Đó là Vulnerability.

Nhưng Risk là gì? Chúng ta chưa thể trả lời chỉ từ hai thông tin trên.

Nếu căn nhà đang bỏ trống, không có tài sản đáng giá, có camera và có thêm nhiều lớp bảo vệ bên trong, hậu quả có thể hạn chế. Ngược lại, nếu cửa sổ đó dẫn thẳng vào phòng chứa tài sản quan trọng, cùng một tên trộm và cùng một cửa sổ mở có thể tạo ra một mức risk hoàn toàn khác.

Điều quyết định không chỉ là threat hay vulnerability. Điều quan trọng là chúng có thể ảnh hưởng tới điều gì mà chúng ta cần bảo vệ.

3. Risk — Nếu điều đó xảy ra thì mục tiêu bị ảnh hưởng như thế nào?

Đây là điểm cần chuyển từ tư duy kỹ thuật sang tư duy quản trị.

Risk không chỉ mô tả một lỗi kỹ thuật. Risk phải cho chúng ta biết một uncertainty hoặc event có thể ảnh hưởng như thế nào đến objective.

Vì vậy, khi nhìn thấy một vulnerability, câu hỏi quản trị quan trọng nhất không phải chỉ là: “Severity của vulnerability này là bao nhiêu?”

Mà phải hỏi thêm: “So what?”

Nếu vulnerability bị khai thác thì business service nào bị ảnh hưởng? Dữ liệu gì có thể mất? Giao dịch nào có thể gián đoạn? Nghĩa vụ pháp lý nào có thể bị vi phạm? Khách hàng bị ảnh hưởng đến mức nào? Và cuối cùng, objective nào của tổ chức có thể không đạt được?

Đó mới là risk.

4. Từ technical finding đến một risk scenario

Một cách thực dụng, có thể hình dung chuỗi logic như sau: Objective / Asset → Threat → Vulnerability → Risk Event → Business Impact → Controls → Residual Risk → Decision.

Điểm quan trọng là không nhảy thẳng từ Vulnerability sang Risk Rating.

Ví dụ, thay vì ghi “Máy chủ chưa vá critical vulnerability”, đây mới chủ yếu là một technical finding.

Một risk scenario hữu ích hơn có thể được diễn đạt: Do một máy chủ Internet-facing phục vụ dịch vụ thanh toán còn tồn tại vulnerability có khả năng bị khai thác, threat actor có thể compromise hệ thống, dẫn đến gián đoạn giao dịch, truy cập trái phép dữ liệu hoặc các hậu quả khác đối với dịch vụ.

Điều này cũng giải thích vì sao một tổ chức có thể có hàng nghìn vulnerabilities nhưng không có nghĩa là có hàng nghìn risks có mức độ quan trọng ngang nhau.

Một vulnerability đơn lẻ trên thành phần trọng yếu, Internet-facing, không có compensating control và nằm trên critical transaction path đôi khi cần được ưu tiên hơn hàng trăm hoặc hàng nghìn vulnerabilities khác.

5. Critical Vulnerability chưa chắc bằng Critical Risk

Đây là một trong những điểm thực hành quan trọng nhất.

Giả sử Odin Lab Bank phát hiện cùng một critical vulnerability trên hai máy chủ.

Máy chủ thứ nhất là một test server nằm trong môi trường biệt lập, không Internet-facing, không chứa dữ liệu khách hàng thật, access được giới hạn và có thể rebuild nhanh.

Máy chủ thứ hai nằm trong transaction path của một digital banking service, Internet-facing, xử lý dữ liệu nhạy cảm và có yêu cầu availability cao.

Technical severity của vulnerability có thể giống nhau. Nhưng business risk không giống nhau.

Ở môi trường test, likelihood hoặc impact có thể thấp hơn đáng kể. Trong môi trường production, cùng vulnerability có thể dẫn tới service disruption, failed transactions, data exposure, incident response costs, regulatory obligations và reputational impact.

Nói cách khác: Technical severity mô tả mức nghiêm trọng của vulnerability. Risk assessment phải mô tả mức độ exposure của tổ chức.

Đây cũng là lý do dashboard vulnerability chỉ trả lời được một phần câu hỏi. “Chúng ta có bao nhiêu Critical?” là một thông tin hữu ích cho vận hành security.

Nhưng đối với risk management, câu hỏi tốt hơn là: “Những critical vulnerabilities nào đang tạo ra risk exposure lớn nhất đối với các business services quan trọng?”

6. Controls làm thay đổi risk như thế nào?

Hai systems có cùng threat và cùng vulnerability vẫn có thể có mức residual risk khác nhau vì controls khác nhau.

Một Internet-facing server chưa vá vulnerability là một chuyện. Nhưng nếu server đó có network segmentation, Web Application Firewall, restricted privileges, EDR, monitoring, hardened configuration và một compensating control được kiểm thử thường xuyên, risk exposure có thể khác đáng kể so với một server không có các lớp bảo vệ này.

Đó cũng là lý do Chu trình Odin không dừng ở Risk. Sau Risk là Assess, Response & Control, Responsibility và Evidence trước khi đi tới quyết định.

Không chỉ hỏi “Chúng ta có control không?”, mà phải hỏi: Control có thực sự làm giảm risk không, và evidence nào chứng minh điều đó?

7. Risk Register không nên trở thành danh sách lỗi CNTT

Một risk register rất dễ bị biến thành danh sách: “Windows chưa patch”, “Firewall hết support”, “Server cấu hình chưa chuẩn”, “Database chưa mã hóa”.

Những vấn đề này có thể rất quan trọng, nhưng bản thân chúng thường là vulnerability, issue hoặc finding, chưa phải một risk statement hoàn chỉnh.

Một risk statement tốt hơn phải giúp người đọc hiểu ba điều: điều gì có thể xảy ra, tại sao điều đó có thể xảy ra, và mục tiêu nào có thể bị ảnh hưởng.

Ví dụ: Do hệ điều hành của một thành phần Internet-facing không còn được vendor hỗ trợ, các vulnerabilities mới có thể không còn bản vá phù hợp, làm tăng khả năng hệ thống bị compromise và gây gián đoạn dịch vụ hoặc truy cập trái phép dữ liệu.

Khi viết theo cách này, risk register bắt đầu trở thành một công cụ hỗ trợ management decision thay vì chỉ là nơi lưu technical findings.

8. Ai chịu trách nhiệm cho Risk?

Threat có thể được phát hiện bởi SOC. Vulnerability có thể được quản lý bởi Infrastructure hoặc Security Team. Control có thể thuộc Technology Owner.

Nhưng business risk phát sinh từ những vấn đề đó không nhất thiết chỉ thuộc về IT.

Nếu một risk có thể ảnh hưởng tới dịch vụ thanh toán, dữ liệu khách hàng, revenue hay regulatory compliance, Business/Service Owner phải tham gia đánh giá impact và chấp nhận residual risk ở mức phù hợp với thẩm quyền.

Đây là lý do trong Odin Method, Responsibility là một bước riêng. Risk phải có Risk Owner. Control phải có Control Owner. Action phải có Action Owner. Và quyết định chấp nhận risk phải thuộc đúng authority.

9. Từ Vulnerability Management đến Risk-based Vulnerability Management

Nếu chỉ quản lý theo severity, một đội công nghệ có thể bị kéo vào cuộc đua giảm số lượng Critical và High mà không chắc đã giảm được risk quan trọng nhất.

Một cách tiếp cận risk-based hơn cần bổ sung context: asset criticality, business service, Internet exposure, exploitability, threat intelligence, existing controls, data sensitivity, business impact và recovery capability.

Mục tiêu không phải bỏ CVSS hay technical severity. Mục tiêu là đặt chúng vào đúng chỗ.

CVSS giúp hiểu technical severity. Risk assessment giúp hiểu business exposure. Management decision giúp quyết định chúng ta cần làm gì trước.

10. Từ Risk đến Value

Nếu mục tiêu của risk management là loại bỏ mọi risk, cách an toàn nhất có thể là không thay đổi gì: không cloud, không API, không mobile banking, không AI và không triển khai công nghệ mới.

Nhưng một tổ chức không thể phát triển bằng cách tránh toàn bộ uncertainty.

Quản trị rủi ro trưởng thành không hỏi: “Làm sao để không có risk?” Mà hỏi: “Chúng ta cần hiểu và kiểm soát risk đến mức nào để có thể theo đuổi opportunity này một cách có chủ đích?”

Ví dụ, nếu Odin Lab Bank muốn đưa một workload lên cloud, câu hỏi không nên chỉ là “Cloud có risk không?”. Câu hỏi cần thiết hơn là workload nào phù hợp, dữ liệu nào được phép, threat scenarios nào đáng quan tâm, vulnerabilities nào thực sự tạo exposure, controls nào cần có, evidence nào chứng minh controls hiệu quả và residual risk cuối cùng có nằm trong appetite hay không.

Đó chính là tư duy Turn Risk into Value.

Kết luận

Threat, Vulnerability và Risk liên quan chặt chẽ nhưng không phải là một.

Threat cho chúng ta biết điều gì có thể gây hại. Vulnerability cho chúng ta biết điểm yếu nào có thể bị khai thác hoặc kích hoạt. Risk trả lời câu hỏi quan trọng hơn: nếu điều đó xảy ra, objective nào của tổ chức có thể bị ảnh hưởng và mức exposure đó có chấp nhận được hay không?

Sự khác biệt tưởng như chỉ là thuật ngữ nhưng lại ảnh hưởng trực tiếp đến cách tổ chức prioritise, allocate resources và ra quyết định.

Một vulnerability dashboard tốt giúp chúng ta biết mình có những điểm yếu gì. Một risk management process tốt phải giúp chúng ta biết: Điểm yếu nào thực sự quan trọng, tại sao nó quan trọng, cần làm gì với nó và ai phải quyết định.

Đó là bước chuyển từ quản lý lỗi công nghệ sang quản trị rủi ro công nghệ.

TURN RISK INTO VALUE.

Tài liệu tham khảo

NIST SP 800-30 Rev.1 — Guide for Conducting Risk Assessments.

ISO/IEC 27005:2022 — Information security, cybersecurity and privacy protection — Guidance on managing information security risks.

ISO 31000:2018 — Risk Management — Guidelines.

ISACA — COBIT 2019.