Khối lượng phần mềm đang tăng, hoạt động phát hiện lỗ hổng đang tăng tốc và thời gian tạo mã khai thác đang rút ngắn, trong đó AI có thể đẩy nhanh một số tác vụ tấn công. Vì vậy, quản lý lỗ hổng không thể chỉ dựa vào số lượng CVE hoặc điểm CVSS. Doanh nghiệp cần ưu tiên theo khả năng bị khai thác, mức phơi nhiễm trong sản xuất và tác động đối với hoạt động kinh doanh.
Theo phân tích của The New Stack, AI có thể tạo ra tác động đáng chú ý đối với quản lý lỗ hổng phần mềm. Công việc này lâu nay ít được xem là vấn đề chiến lược. AI làm giới hạn của quy trình quét, chấm điểm và chuyển danh sách cho đội phát triển bộc lộ rõ hơn.
Vấn đề không chỉ nằm ở số lỗ hổng. Khối lượng phần mềm đang mở rộng và thời gian cần để tạo mã khai thác đang rút ngắn. Các cuộc tấn công có AI hỗ trợ còn có thể kết hợp nhiều điểm yếu thành đường xâm nhập khó dự đoán bằng rà soát thủ công. Khoảng cách giữa số lỗ hổng được phát hiện và số lỗ hổng có thể điều tra, khắc phục một cách có ý nghĩa vì thế ngày càng lớn.
Doanh nghiệp không nên chỉ hỏi mình có bao nhiêu CVE. Câu hỏi cần đặt ra là lỗ hổng nào tạo ra rủi ro đáng kể trong chính môi trường của mình.
Mức độ nghiêm trọng không đồng nghĩa với rủi ro
CVE xác định một lỗ hổng đã được công khai, còn CVSS mô tả mức độ nghiêm trọng về kỹ thuật và tác động tiềm tàng. Hai tín hiệu này không tự cho biết lỗ hổng có thể bị khai thác trong một môi trường cụ thể hay mức thiệt hại mà tổ chức có thể phải chịu.
Điểm CVSS không nhất thiết cho biết mã khai thác đã tồn tại hay chưa, lỗ hổng có đang bị lợi dụng ngoài thực tế hay không, thành phần dễ tổn thương có lộ ra bên ngoài hay không hoặc đường mã liên quan có thực sự được chạy trong môi trường cụ thể hay không.
| Tín hiệu | Cho biết điều gì | Không tự xác định được |
|---|---|---|
| CVE | Lỗ hổng đã được nhận diện | Rủi ro đối với từng tổ chức |
| CVSS | Mức nghiêm trọng kỹ thuật | Khả năng khai thác thực tế |
| Bối cảnh vận hành | Mức phơi nhiễm của hệ thống | Cần kết hợp thêm tình báo mối đe dọa |
Nội dung đánh giá rủi ro theo bối cảnh
Hai doanh nghiệp có thể cùng chứa một CVE nhưng đối mặt với mức rủi ro hoàn toàn khác nhau. Ở doanh nghiệp thứ nhất, thành phần dễ tổn thương có thể nằm sau nhiều lớp bảo vệ, không kết nối trực tiếp với bên ngoài và không có đường thực thi liên quan. Ở doanh nghiệp thứ hai, thành phần đó có thể chạy trong một ứng dụng sản xuất kết nối internet và phục vụ quy trình kinh doanh trọng yếu.
CVE giống nhau, nhưng rủi ro không giống nhau.
Nếu chỉ dựa vào điểm nghiêm trọng tĩnh, đội bảo mật có thể đóng nhiều phát hiện nhưng chưa chắc đã giảm phần phơi nhiễm có khả năng gây hậu quả lớn nhất. Khi đó, tổ chức đang đo khối lượng hoạt động thay vì mức giảm rủi ro thực chất.
AI đang thay đổi tốc độ khai thác lỗ hổng
Khối lượng phần mềm đang tăng và hoạt động phát hiện lỗ hổng đang tăng tốc. Ở phía tấn công, AI có thể đẩy nhanh những tác vụ trước đây cần nhiều công sức thủ công. Khi khối lượng mã tăng và thời gian tạo mã khai thác giảm, quy trình phân loại lỗ hổng thủ công khó theo kịp tốc độ thay đổi của môi trường.
Ngay cả khi mật độ lỗ hổng trên mỗi dòng mã giảm, tổng khối lượng phần mềm lớn hơn vẫn có thể làm phạm vi phơi nhiễm tăng. Phần mềm hiện đại cũng phụ thuộc nhiều vào thành phần mã nguồn mở, khiến doanh nghiệp phải theo dõi và bảo vệ nhiều mã hơn.
Ở phía phát triển, sản lượng mã là một phần của khối lượng phần mềm đang mở rộng, vì vậy việc đánh giá chất lượng không thể chỉ dựa vào số lượng đầu ra. Trong bảo mật, nguyên tắc tương tự áp dụng cho CVE: phát hiện nhiều hơn không đồng nghĩa với hiểu rủi ro tốt hơn.
Doanh nghiệp vì thế không thể tiếp tục phụ thuộc vào quy trình phân loại thủ công kéo dài và tuần tự. Quản lý lỗ hổng phải dựa nhiều hơn vào bối cảnh vận hành, theo dõi liên tục và tự động hóa.
Giảm rủi ro ngay từ nền tảng phần mềm
Quản lý lỗ hổng nên bắt đầu trước khi phần mềm được triển khai. Nền tảng được gia cố, kiểm tra mã và đánh giá cấu hình có thể giảm số điểm yếu đi vào môi trường, thay vì chuyển toàn bộ gánh nặng sang đội xử lý sau triển khai.
Ảnh nền và thư viện ngôn ngữ đã được tuyển chọn hoặc gia cố có thể thu hẹp phạm vi lỗ hổng trước khi ứng dụng được đưa vào sử dụng. Với mã do doanh nghiệp tự phát triển, đội kỹ thuật có thể dùng kiểm thử bảo mật ứng dụng tĩnh và quét mã có AI hỗ trợ. Điểm yếu cấu hình có thể được nhận diện bằng các yêu cầu bảo mật như Hướng dẫn triển khai kỹ thuật bảo mật, thường được gọi tắt là STIG.
Lỗ hổng chỉ là một mặt của an toàn phần mềm. Một hệ thống có thể chứa ít CVE nhưng vẫn được cấu hình nguy hiểm. Quyền truy cập quá rộng, thiết lập xác thực yếu hoặc sai sót cấu hình khác có thể giúp kẻ tấn công đặt chân vào hệ thống rồi di chuyển sang các tài nguyên kế cận.
Quét theo STIG đánh giá cấu hình dựa trên các yêu cầu bảo mật đã thiết lập. Công cụ hoạt động như một danh mục kiểm tra tự động, có thể phát hiện và trong một số trường hợp khắc phục điểm yếu cấu hình. Mục tiêu là làm cho phần mềm an toàn nhất có thể trước khi vấn đề trở thành gánh nặng xử lý của một đội khác.
Quét những gì thực sự chạy trong môi trường sản xuất
Môi trường sản xuất phản ánh phần mềm, cấu hình và đường truy cập đang tồn tại trong vận hành. Quét kho mã hoặc kho ảnh trước triển khai vẫn hữu ích, nhưng kết quả đó không thay thế việc quan sát liên tục các thành phần thực sự đang chạy.
Môi trường sản xuất, ảnh phần mềm và cấu hình đều có thể thay đổi sau khi triển khai. Lỗ hổng mới cũng có thể được công bố trong thời gian hệ thống đang hoạt động. Vì vậy, kết quả quét trước triển khai chỉ thể hiện rủi ro được dự đoán tại một thời điểm.
Đội bảo mật cần quét môi trường sản xuất, phân tích khả năng tiếp cận và bổ sung bối cảnh vận hành. Ở cấp mạng, khả năng tiếp cận cho biết hệ thống có mở ra bên ngoài hay không. Ở cấp phần mềm, câu hỏi quan trọng là đường mã chứa lỗ hổng có thực sự được thực thi không. Câu trả lời có thể làm thay đổi thứ tự khắc phục.
Thứ tự khắc phục cần dựa trên khả năng tiếp cận mạng, đường mã thực sự được thực thi và cấu hình của hệ thống đang được đánh giá.
Ưu tiên theo khả năng bị khai thác và tác động kinh doanh
Sau khi xác định những gì đang chạy, doanh nghiệp cần kết hợp tình báo mối đe dọa với mức phơi nhiễm, khả năng tiếp cận và vai trò kinh doanh của hệ thống. Cách đánh giá này trả lời lỗ hổng nào phải được sửa trước trong môi trường cụ thể và vì sao.
Danh mục lỗ hổng đã biết bị khai thác của CISA, thường được gọi là KEV, xác định các lỗ hổng có hoạt động khai thác thực tế. Hệ thống chấm điểm dự báo khai thác EPSS ước tính khả năng một lỗ hổng bị khai thác trong một khoảng thời gian nhất định.
Các tín hiệu này có thể được kết hợp với những yếu tố sau:
- Mức độ phơi nhiễm trong môi trường sản xuất.
- Khả năng tiếp cận qua mạng và đường thực thi mã.
- Cấu hình của thành phần hoặc hệ thống liên quan.
- Tác động đối với quy trình kinh doanh.
- Thời gian lỗ hổng tồn tại trong trạng thái phơi nhiễm.
Mô hình đó khác với việc chuyển cho lập trình viên một bảng tính chứa hàng nghìn CVE được sắp xếp theo điểm nghiêm trọng. Khi khối lượng phần mềm mở rộng và hoạt động phát hiện lỗ hổng tăng nhanh, đội bảo mật càng cần dựa vào bối cảnh để xác định thứ tự ưu tiên.
Mục tiêu là quản lý rủi ro liên tục
Mục tiêu của quản lý lỗ hổng không phải là duy trì một bảng điều khiển không còn phát hiện. Mục tiêu là liên tục xác định và giảm những điểm phơi nhiễm có khả năng bị khai thác và gây tác động lớn nhất đối với tổ chức.
Cách tiếp cận này gồm nhiều lớp:
- Xây dựng nền tảng phần mềm an toàn.
- Quét mã do doanh nghiệp tự phát triển.
- Gia cố và kiểm tra cấu hình.
- Xác định thành phần đang chạy trong sản xuất.
- Kiểm tra khả năng tiếp cận qua mạng và phần mềm.
- Bổ sung tình báo về hoạt động khai thác.
- Ưu tiên khắc phục theo mức phơi nhiễm và tác động thực tế.
Thời hạn khắc phục không nên giống nhau cho mọi phát hiện. Từng nhóm lỗ hổng có thể cần khoảng xử lý khác nhau tùy vào khả năng bị khai thác và vai trò của hệ thống liên quan.
Đội bảo mật cần biết cánh cửa nào đang mở, kẻ tấn công có thể tiếp cận cánh cửa nào, cánh cửa nào dẫn tới tài sản quan trọng và cánh cửa nào tạo ra rủi ro lớn nhất ngay lúc này.
AI khiến mô hình quản lý lỗ hổng dựa trên bảng tính khó duy trì hơn. Khác biệt cốt lõi nằm ở việc doanh nghiệp chỉ đếm lỗ hổng hay quản lý khả năng bị tấn công bằng dữ liệu từ chính môi trường vận hành.
Hãy rà soát quy trình ưu tiên lỗ hổng để bảo đảm đội kỹ thuật đang xử lý rủi ro đáng kể nhất, không chỉ những mục có điểm CVSS cao nhất.
