“Bạn biết, và bạn có thể hành động. Tại sao bạn không làm?”
Đây là câu hỏi bạn không muốn bị hỏi. Và ngày càng nhiều, đó là câu hỏi mà các nhà lãnh đạo buộc phải trả lời sau một sự cố.
Trong nhiều năm, nhiều đội ngũ điều hành và ban giám đốc đã coi một lượng lớn lỗ hổng tồn đọng là một thực tế khó chịu nhưng có thể chấp nhận được: “chúng tôi đã chấp nhận rủi ro.” Nếu bạn từng thấy một báo cáo hiển thị hàng nghìn (hoặc hàng chục nghìn) CVE ở mức High và Critical đang mở, bạn có lẽ cũng đã nghe những lý lẽ thông thường từ những người muốn phớt lờ: chúng tôi có những ưu tiên khác, việc này sẽ mất nhiều năm phát triển, làm sao bạn biết những CVE này thực sự là Critical, chúng tôi vẫn đang ưu tiên, chúng tôi sẽ xử lý.
Trong thế giới cũ, câu chuyện đó, dù không tốt, nhưng thường có thể vượt qua. Việc exploitation chậm hơn, thủ công hơn và đòi hỏi kỹ năng vận hành cao hơn. Ngay cả những kẻ tấn công tinh vi nhất cũng có những hạn chế. Các tổ chức dựa vào những hạn chế đó như một phần ngầm của mô hình rủi ro: “Nếu nó thực sự tồi tệ như bạn nói, chúng tôi đã bị tấn công rồi.”
Thế giới đó đã qua rồi.
AI đã giảm đáng kể chi phí exploitation
Hiện tại, chúng ta đang chứng kiến các threat actor sử dụng hệ thống AI tác tử để đẩy nhanh toàn bộ quy trình tấn công: reconnaissance, vulnerability discovery, exploit development và tốc độ hoạt động. Anthropic đã công khai chi tiết việc ngăn chặn một chiến dịch gián điệp mạng mà trong đó kẻ tấn công đã sử dụng Claude theo những cách làm tăng đáng kể tốc độ và quy mô của chúng, và họ đã cảnh báo rõ ràng rằng khả năng này có thể cho phép các nhóm ít kinh nghiệm hơn thực hiện công việc mà trước đây đòi hỏi nhiều kỹ năng và nhân lực hơn.
Với tư cách là các nhà lãnh đạo bảo mật, chúng ta biết rằng AI cho phép kẻ tấn công di chuyển nhanh hơn. Nhưng giờ đây, tự động hóa biến một danh sách tồn đọng thành một vũ khí. Trong mô hình cũ, việc có 13.000 lỗ hổng High trong môi trường production có thể được biện minh là một vấn đề phân loại. Trong mô hình mới, kẻ tấn công có thể chuyển từ việc phát hiện chuỗi tấn công sang xác thực và exploitation trong thời gian ít hơn đáng kể. “Chúng tôi đang xử lý danh sách tồn đọng” không còn là một chiến lược mà trở thành một lời bao biện.
Câu nói nguy hiểm nhất trong phòng họp ban giám đốc
“Đừng lo, CISO đã xử lý rồi.”
Tôi đã trải nghiệm thực tế đằng sau câu nói đó. Các CISO có thể xây dựng chương trình, thiết lập ưu tiên, báo cáo số liệu và thúc đẩy remediation đa chức năng, nhưng ở nhiều doanh nghiệp, vấn đề vulnerability về cấu trúc lớn hơn trách nhiệm của bất kỳ một giám đốc điều hành nào. Đó là một vấn đề hệ thống: các legacy dependencies, hạn chế về release velocity, môi trường production dễ bị tổn thương và nguồn lực kỹ thuật hạn chế. Ban giám đốc không thể ủy quyền quyền quản trị.
Các vụ kiện theo quy tắc Caremark của Delaware thường được trích dẫn trong các cuộc thảo luận về giám sát của ban giám đốc: ban giám đốc phải có các hệ thống báo cáo được thiết kế để đưa ra các rủi ro quan trọng và phải thực sự tương tác với những gì các hệ thống đó báo cáo. Mục đích không phải để dọa các giám đốc bằng lý thuyết pháp lý – mà là để đưa ra quan điểm quản trị thực tế rằng nếu báo cáo của bạn nói “chúng tôi có hàng nghìn lỗ hổng nghiêm trọng đang mở,” thì công việc của ban giám đốc là thực hiện giám sát.
Ban giám đốc nên yêu cầu gì (và CISO nên trả lời như thế nào)
Nếu bạn là thành viên ban giám đốc, bạn nên tìm kiếm sự thật trong hoạt động. Hãy tập trung vào khả năng phục hồi của công nghệ công ty bạn, không chỉ là compliance. Và nếu bạn là một nhà lãnh đạo bảo mật, bạn nên tạo ra các hệ thống vận hành cung cấp điều đó. Đây là những câu hỏi mà các nhóm có thể sử dụng để vượt qua các lớp vỏ bọc an ninh mạng hình thức:
- Chương trình quản lý vulnerability của chúng ta trông như thế nào từ đầu đến cuối?
- Hiện tại có bao nhiêu vulnerabilities (đặc biệt là Critical và High) tồn tại trong sản phẩm của chúng ta?
- Mất bao lâu để hoàn tất remediation các lỗ hổng Critical và High mới trong quý vừa qua? Năm vừa qua?
- Nếu một 0-day mới được phát hiện trong sản phẩm bán chạy nhất của chúng ta ngày hôm nay, sẽ mất bao lâu trước khi chúng ta có thể thông báo cho khách hàng rằng nó an toàn?
- Chi phí tiền tệ của danh sách lỗ hổng tồn đọng hiện tại của chúng ta là bao nhiêu? (Nhân số giờ công cần để sửa với chi phí kỹ thuật tổng thể, và bạn sẽ có một con số mà ban giám đốc có thể quản lý.)
Đây là cách bạn biến danh sách tồn đọng trở nên đủ rõ ràng để ban lãnh đạo ngừng ẩn mình sau những khái niệm trừu tượng.
“Patch nhanh hơn” không phải là câu trả lời đầy đủ
Nhiều tổ chức phản ứng với áp lực từ ban giám đốc bằng cách hứa hẹn sẽ patch nhanh hơn. Điều đó có ích, cho đến khi nó làm hỏng môi trường production.
Nếu việc patch khẩn cấp chắc chắn gây ảnh hưởng đến khách hàng (và ở một số môi trường thì đúng là như vậy), bạn sẽ bị buộc phải đối mặt với một sự đánh đổi khủng khiếp: chấp nhận rủi ro hoặc chấp nhận downtime. Doanh nghiệp hiện đại cần một mô hình giảm tần suất và phạm vi ảnh hưởng của remediation khẩn cấp, chứ không phải chỉ đơn thuần là đẩy nhanh cùng một quy trình mong manh.
Thực tế chuỗi cung ứng: trách nhiệm pháp lý đang thay đổi
Chúng ta đang thấy trách nhiệm pháp lý thay đổi khi các cơ quan quản lý và tòa án tập trung vào vệ sinh chuỗi cung ứng phần mềm và operational resilience.
Tại EU, Đạo luật An ninh mạng (CRA) hiện đã có hiệu lực, với các nghĩa vụ chính sẽ có hiệu lực vào tháng 12 năm 2027. Nhiều tổ chức sẽ phải đối mặt với những kỳ vọng cao hơn về xử lý vulnerability, các thực tiễn secure-by-design và accountability trong suốt vòng đời phần mềm.
Trong lĩnh vực dịch vụ tài chính, DORA (Digital Operational Resilience Act) đã có hiệu lực, mang lại các yêu cầu quản lý rủi ro ICT và operational resilience hài hòa trên toàn EU.
Chúng ta cũng đang chứng kiến động thái này diễn ra ở Mỹ, nơi các yêu cầu bồi thường do sơ suất được đưa ra trong các class action lawsuits chống lại các công ty, với các nguyên đơn cáo buộc thiếu sự cẩn trọng dẫn đến các data breaches.
Bạn có thể giảm danh sách tồn đọng ngay từ khâu thiết kế
Trong kỷ nguyên exploitation được AI tăng tốc, “managed risk” quá thường xuyên có nghĩa là giả định kẻ tấn công sẽ tiếp tục di chuyển với tốc độ của ngày hôm qua.
Các ban giám đốc nên ngừng chấp nhận giả định đó. Các CISO nên ngừng giả vờ rằng “patch faster” hoặc có được sự risk acceptance là đủ. Và các tổ chức nên đầu tư vào việc giảm thiểu vulnerability exposure ngay từ nguồn để báo cáo kiểm toán tiếp theo không phải là một bảng tính các accepted risks, mà là bằng chứng về một attack surface đang thu hẹp.
Quảng cáo một chút, đây là nơi cách tiếp cận của Chainguard được thiết kế để thay đổi cách tính toán: bắt đầu với các thành phần phần mềm secure-by-default giúp giảm thiểu vulnerabilities ngay từ đầu và giảm vulnerability accrual theo thời gian. Điều đó có nghĩa là ít critical findings xuất hiện trong môi trường của bạn hơn, ít chu kỳ emergency patch hơn và ít operational disruption hơn khi CVE có hồ sơ cao tiếp theo hits.
Bằng cách giảm thiểu vulnerability backlog và remediation toil một cách có cấu trúc, các nhóm có thể chuyển hướng thời gian engineering từ zero-ROI firefighting thành high-ROI innovation thực sự thúc đẩy competitive advantage và revenue.
Bởi vì khi việc đổ lỗi bắt đầu sau một breach, và ai đó hỏi tại sao công ty lại chọn sống chung với 13.000 lỗ hổng High trong môi trường production, câu trả lời duy nhất có thể bảo vệ được là: chúng tôi không làm vậy. Chúng tôi đã thay đổi hệ thống.
Để biết thêm những quan điểm nóng hổi và lời khuyên thực tế từ – và dành cho – các nhà lãnh đạo engineering và security, hãy đăng ký theo dõi Unchained hoặc liên hệ để tìm hiểu thêm về Chainguard.
Lưu ý: Bài viết này được viết và đóng góp bởiQuincy Castro, CISO, Chainguard.
