Chuyển từ đếm số lượng CVE sang quản lý lỗ hổng dựa trên rủi ro trong kỷ nguyên AI

Trí tuệ nhân tạo (AI) đang thu hẹp nhanh chóng khoảng thời gian giữa việc phát hiện lỗ hổng và khai thác chủ động, buộc các đội ngũ kỹ thuật phải thay đổi căn bản cách quản lý nợ bảo mật. Khi khối lượng phần mềm mở rộng và tự động hóa tấn công ngày càng tinh vi, việc theo dõi truyền thống bằng bảng tính cho các Lỗ hổng và Phơi nhiễm Chung (CVE) không còn cung cấp bức tranh chính xác về rủi ro của tổ chức.

Điều gì đã xảy ra

Mô hình quản lý lỗ hổng truyền thống hầu như không thay đổi trong nhiều năm: quét mã, xác định CVE, gán điểm mức độ nghiêm trọng thông qua Hệ thống Chấm điểm Lỗ hổng Chung (CVSS), và chuyển danh sách cho các nhà phát triển để khắc phục. Cách tiếp cận này giả định rằng mức độ nghiêm trọng kỹ thuật tương quan trực tiếp với rủi ro kinh doanh. Tuy nhiên, bối cảnh hiện tại cho thấy khoảng cách ngày càng lớn giữa số lượng lỗ hổng mà các đội bảo mật có thể xác định và số lượng họ có thể điều tra và sửa chữa một cách có ý nghĩa.

Khoảng cách này đang nới rộng vì AI thúc đẩy cả sản xuất phần mềm lẫn sự tinh vi của các cuộc tấn công. Mặc dù mật độ lỗ hổng trên mỗi dòng mã có thể giảm, nhưng khối lượng phần mềm khổng lồ được tạo ra làm tăng tổng thể mức độ phơi nhiễm. Đồng thời, kẻ tấn công sử dụng AI để tự động hóa các tác vụ trước đây đòi hỏi nỗ lực thủ công đáng kể, kết hợp các lỗ hổng theo những cách khó lường để tạo ra các đường dẫn tấn công mới. Kết quả là các tổ chức bị ngập trong dữ liệu nhưng thiếu hụt ngữ cảnh, dẫn đến tình trạng mà một số chuyên gia gọi là "kịch bản CVE" (CVE theater), nơi các đội đo lường hoạt động thay vì giảm thiểu rủi ro thực tế.

Vấn đề cốt lõi là một CVE chỉ báo hiệu sự tồn tại của một lỗi đã được công bố, nhưng không cho biết liệu lỗi đó có thể bị khai thác trong một môi trường cụ thể hay không. Hai tổ chức có thể cùng gặp phải một CVE, nhưng nếu một bên đặt thành phần dễ bị tổn thương phía sau nhiều lớp bảo mật mà không có sự tiếp xúc bên ngoài, trong khi bên kia chạy nó trong một ứng dụng sản xuất hướng tới internet, thì hồ sơ rủi ro của họ hoàn toàn khác nhau. Việc đối xử bình đẳng với cả hai sẽ lãng phí nguồn lực kỹ thuật vào các mục rủi ro thấp trong khi bỏ ngỏ các mối đe dọa nghiêm trọng chưa được giải quyết.

Cơ chế hoạt động

Để lấp đầy khoảng cách này, các chương trình bảo mật phải chuyển từ chấm điểm mức độ nghiêm trọng tĩnh sang đánh giá rủi ro liên tục và có ngữ cảnh. Điều này bắt đầu bằng việc giảm bớt dấu vết lỗ hổng trước khi triển khai bằng cách sử dụng các hình ảnh cơ sở đã được củng cố (hardened base images) và các thư viện ngôn ngữ được chọn lọc. Mã nội bộ (first-party code) được bảo vệ thông qua Kiểm thử Bảo mật Ứng dụng Tĩnh (SAST) và quét hỗ trợ bởi AI, trong khi các điểm yếu cấu hình được giải quyết bằng các khung như Hướng dẫn Triển khai Kỹ thuật Bảo mật (STIGs). Các danh sách kiểm tra tự động này xác định các vấn đề như đặc quyền quá mức hoặc xác thực yếu, vốn có thể nguy hiểm ngang với các lỗ hổng mã.

Quan trọng nhất, trọng tâm chuyển sang quét những gì thực sự đang chạy trong môi trường sản xuất, vì các registry và repository chỉ phản ánh rủi ro cảm nhận. Môi trường sản xuất thay đổi liên tục, do đó cần có khả năng hiển thị liên tục. Các công cụ thực hiện phân tích khả năng truy cập (reachability analysis) để xác định xem một đường dẫn mã dễ bị tổn thương có thực sự được thực thi hay không và hệ thống có thể truy cập từ bên ngoài hay không. Ngữ cảnh môi trường này cho phép các đội phân biệt giữa các lỗ hổng lý thuyết và những lỗ hổng gây ra mối đe dọa tức thì, có thể hành động được.

Cuối cùng, ưu tiên khắc phục được thiết lập bằng cách kết hợp các tín hiệu tình báo mối đe dọa, chẳng hạn như danh mục Lỗ hổng Đã Biết Khai Thác (KEV) của CISA và Hệ thống Chấm điểm Dự đoán Khai thác (EPSS), với dữ liệu phơi nhiễm trong môi trường sản xuất. Điều này tạo ra một mô hình động trả lời câu hỏi lỗ hổng nào nên được sửa trước, trong môi trường cụ thể này, và tại sao, thay vì phụ thuộc vào một danh sách tĩnh sắp xếp theo điểm CVSS.

Chi tiết chính

• AI đẩy nhanh quá trình phát triển mã khai thác, rút ngắn thời gian giữa công bố lỗ hổng và tấn công chủ động.
• Điểm CVSS đo lường mức độ nghiêm trọng kỹ thuật nhưng không tính đến mức độ phơi nhiễm môi trường hoặc khả năng bị khai thác.
• "Kịch bản CVE" xảy ra khi các đội ưu tiên đóng số lượng lớn các phát hiện mà không giảm thiểu rủi ro hậu quả.
• Quét môi trường sản xuất cung cấp nguồn sự thật về những gì thực sự được triển khai và đang chạy.
• Phân tích khả năng truy cập xác định xem các đường dẫn mã dễ bị tổn thương có được thực thi và hệ thống có thể truy cập từ bên ngoài hay không.
• Các nguồn tình báo mối đe dọa như KEV và EPSS giúp ước tính khả năng bị khai thác trong một khoảng thời gian nhất định.

Tại sao điều này quan trọng

Đối với các kỹ sư phần mềm và lãnh đạo kỹ thuật, sự chuyển dịch này có nghĩa là rời xa việc khắc phục thụ động, dựa trên khối lượng để hướng tới một cách tiếp cận chiến lược hơn, dựa trên rủi ro. Mô hình cũ trao cho các nhà phát triển một bảng tính chứa hàng nghìn CVE là không bền vững trong bối cảnh mối đe dọa do AI thúc đẩy. Nó dẫn đến mệt mỏi cảnh báo và phân bổ sai nguồn lực, nơi các lỗi nghiêm trọng bị chôn vùi dưới tiếng ồn. Bằng cách tập trung vào ngữ cảnh, các đội có thể giảm tải nhận thức cho các nhà phát triển và đảm bảo rằng nỗ lực khắc phục nhắm vào những lỗi thực sự quan trọng đối với doanh nghiệp.

Hơn nữa, cách tiếp cận này đồng bộ hóa các mục tiêu bảo mật với thực tế vận hành. Hiểu rõ cửa nào đang mở, cửa nào kẻ tấn công có thể tiếp cận, và cửa nào dẫn đến các tài sản quan trọng cho phép ra quyết định tốt hơn. Nó biến bảo mật từ một nút thắt cổ chai thành một quy trình cải tiến liên tục. Như Russ Andersson lưu ý, "Chúng ta cần biết cửa nào đang mở, cửa nào kẻ tấn công có thể tiếp cận, cửa nào dẫn đến nơi quan trọng, và cửa nào đại diện cho rủi ro lớn nhất ngay lúc này."

Bạn có thể làm gì

• Thay thế việc ưu tiên dựa trên CVSS tĩnh bằng các mô hình rủi ro bao gồm dữ liệu phơi nhiễm sản xuất và khả năng truy cập.
• Triển khai quét môi trường sản xuất liên tục để duy trì khả năng hiển thị về những gì thực sự đang chạy trong môi trường của bạn.
• Sử dụng các hình ảnh cơ sở đã được củng cố và thư viện được chọn lọc để giảm dấu vết lỗ hổng ban đầu của ứng dụng.
• Tích hợp các luồng tình báo mối đe dọa như CISA KEV và EPSS để đánh giá khả năng bị khai thác chủ động.
• Tự động hóa các kiểm tra cấu hình bằng STIGs để xác định và khắc phục các điểm yếu bảo mật trong cài đặt và đặc quyền.
• Thiết lập kỷ luật thời gian bằng cách xác định các cửa sổ khắc phục khác nhau cho các lỗ hổng dựa trên mức độ rủi ro thực tế của chúng.