Jeff Williams, Người sáng lập OWASP và Người sáng lập & CTO của Contrast Security – Loạt phỏng vấn

Jeff Williams, Người sáng lập OWASP và Người sáng lập & CTO của Contrast Security, được coi là một trong những nhân vật có ảnh hưởng nhất trong lĩnh vực bảo mật ứng dụng hiện đại. Trong vài thập kỷ qua, ông đã giúp định hình cách các tổ chức tiếp cận phát triển phần mềm bảo mật, quản lý lỗ hổng và bảo vệ ứng dụng tại thời điểm chạy. Williams đã đóng vai trò trung tâm trong việc xây dựng OWASP từ một sáng kiến tình nguyện nhỏ thành một quỹ bảo mật phi lợi nhuận được công nhận toàn cầu, đóng góp vào các dự án nổi bật như OWASP Top Ten, WebGoat, ESAPI, ASVS và XSS Prevention Cheat Sheet. Trước khi thành lập Contrast Security vào năm 2014, ông cũng đã thành lập Aspect Security, một trong những công ty đầu tiên chuyên về tư vấn bảo mật ứng dụng, đào tạo, kiểm tra thâm nhập và thực hành phát triển bảo mật cho các tổ chức doanh nghiệp.

OWASP là một quỹ phi lợi nhuận tập trung vào việc cải thiện bảo mật phần mềm thông qua các dự án mã nguồn mở, cộng tác toàn cầu, giáo dục và tiêu chuẩn ngành. Được thành lập vào năm 2001, tổ chức này đã trở thành một trong những cơ quan có thẩm quyền nhất trong lĩnh vực bảo mật ứng dụng, với hàng trăm chương địa phương, hàng nghìn người đóng góp và các tài nguyên được采用 rộng rãi bởi các nhà phát triển, chuyên gia bảo mật, doanh nghiệp và chính phủ trên toàn thế giới. OWASP nổi tiếng với các dự án như OWASP Top Ten, xác định các rủi ro bảo mật ứng dụng web quan trọng nhất, cùng với nhiều khuôn khổ bảo mật, công cụ kiểm tra, dự án tài liệu và sáng kiến đào tạo. Tổ chức này hoạt động với triết lý trung lập về nhà cung cấp, khiến cho các tài nguyên giáo dục và hướng dẫn bảo mật của họ có thể truy cập miễn phí cho cộng đồng công nghệ toàn cầu.

Contrast Security là một công ty bảo mật ứng dụng tập trung vào việc bảo vệ phần mềm từ bên trong ứng dụng đang chạy thay vì chỉ dựa vào các công cụ quét bên ngoài. Nền tảng của công ty sử dụng công nghệ đo lường thời gian chạy để cung cấp khả năng hiển thị thời gian thực về lỗ hổng, tấn công, API, phụ thuộc mã nguồn mở và hành vi ứng dụng trên môi trường phát triển và sản xuất. Các dịch vụ của họ bao gồm các lĩnh vực như Kiểm tra bảo mật ứng dụng tương tác (IAST), Phát hiện và Phản ứng ứng dụng (ADR), Bảo vệ tự bảo vệ ứng dụng tại thời điểm chạy (RASP) và phân tích thành phần phần mềm. Contrast Security đã định vị mình xung quanh việc tích hợp bảo mật trực tiếp vào các quy trình DevSecOps hiện đại, cho phép các nhà phát triển, nhóm AppSec và nhóm vận hành bảo mật xác định và khắc phục lỗ hổng nhanh hơn trong khi vẫn duy trì các chu kỳ giao hàng phần mềm nhanh chóng.

Sau khi giúp định hình bảo mật ứng dụng hiện đại thông qua công việc của bạn với Dự án Bảo mật Ứng dụng Web Mở (OWASP), khoảng trống nào trong ngành công nghiệp đã dẫn bạn đến việc thành lập Contrast Security, và làm thế nào luận điểm ban đầu đó đã được giữ vững khi các thách thức bảo mật phát triển?

Ngành công nghiệp đang bị nhấn chìm trong các phát hiện tĩnh lý thuyết và không thể tập trung vào các vấn đề thực sự quan trọng. Các nhóm bảo mật có máy quét tạo ra các danh sách chờ đợi lớn mà không biết được lỗ hổng nào có thể tiếp cận, khai thác hoặc đang bị tấn công trong sản xuất. Chúng tôi đã thành lập Contrast dựa trên một ý tưởng đơn giản: các quyết định bảo mật nên đến từ việc quan sát trực tiếp các ứng dụng đang chạy, không phải từ việc đoán từ bên ngoài.

Cuối cùng, tôi hy vọng ngành công nghiệp sẽ tiến bộ đến mức chúng ta có thể thoát khỏi vòng quay tìm kiếm vấn đề, sửa chữa và tìm kiếm thêm mãi mãi. Tôi hy vọng chúng ta có thể bắt đầu tạo ra phần mềm có kiến trúc bảo mật mạnh mẽ và có lý lẽ thực sự rằng nó có các biện pháp phòng thủ phù hợp cho các mối đe dọa dự kiến. Sự kết hợp giữa bảo mật thời gian chạy và AI có tiềm năng, nhưng chúng ta còn vài năm nữa.

Bạn đã mô tả sự xuất hiện của “lỗ hổng cấp Mythos.” Điều gì định nghĩa lớp rủi ro mới này và tại sao chúng lại khó được phát hiện bởi các công cụ bảo mật thông thường?

Lỗ hổng cấp Mythos là những khiếm khuyết xuất hiện từ sự phức tạp của các ngăn xếp phần mềm hiện đại. Sự tương tác giữa hành vi khuôn khổ, phụ thuộc và mẫu kiến trúc quá phức tạp đến mức các nhà phát triển thường không hiểu đầy đủ. Các công cụ thông thường vẫn được tối ưu hóa cho các mẫu và sự kiện quan sát tương đối đơn giản. Lỗ hổng kiểu Mythos thường yêu cầu hiểu biết về hành vi ứng dụng, luồng thực thi và ngữ cảnh thời gian chạy ở mức độ sâu hơn.

Tại sao các loại lỗ hổng hoàn toàn không tạo ra cảnh báo trong môi trường Trung tâm Vận hành Bảo mật (SOC) hiện đại và điều đó tiết lộ gì về cách các nhóm bảo mật hiện đo lường rủi ro?

Đa số các SOC được xây dựng xung quanh các sự kiện quan sát được: nhật ký, chữ ký, lưu lượng mạng, hoạt động điểm cuối. Nhưng nhiều cuộc tấn công lớp ứng dụng không bao giờ tạo ra tín hiệu có ý nghĩa trong các hệ thống đó. Nhà phát triển không biết có lỗ hổng và không thêm bất kỳ nhật ký nào sẽ tiết lộ khai thác. Vì vậy, hầu hết các cuộc khai thác ứng dụng đều hoàn toàn vô hình trong nhật ký. Các nhóm SOC chỉ có thể phản ứng với những gì họ có thể thấy. Vì vậy, khi lớp ứng dụng và API trở nên ngày càng quan trọng, điều quan trọng là phải đảm bảo rằng chúng ta thiết bị chúng với các cảm biến bảo mật có thể phát hiện và báo cáo hành vi异常.

Kiến trúc ứng dụng hiện đại như microservices, API và hệ thống không máy chủ đã phát triển nhanh chóng. Những kiến trúc này đang vượt qua các phương pháp bảo mật dựa trên phát hiện hiện tại ở đâu?

Các kiến trúc này đã phá vỡ mô hình biên giới cũ. Các yêu cầu hiện đang đi qua hàng chục dịch vụ, hàm tạm thời, API, hàng đợi và phụ thuộc bên thứ ba trước khi hoàn thành một giao dịch. Hầu hết các hệ thống phát hiện vẫn chỉ thấy các mảnh ghép thay vì toàn bộ đường dẫn thực thi. Họ có thể kiểm tra các gói hoặc nhật ký, nhưng họ không thể hiểu ý định, luồng dữ liệu hoặc liệu mã nguy hiểm có thực sự được thực thi. Bảo mật là về ngữ cảnh, vì vậy chúng ta cần xây dựng một mô hình, một bản sao kỹ thuật số của cơ sở hạ tầng ứng dụng của chúng ta, cho phép chúng ta (hoặc các tác nhân AI) suy luận về những gì chúng ta thấy đang xảy ra.

OWASP Top Ten tiếp tục nhấn mạnh các vấn đề như thiết kế không an toàn và các thành phần dễ bị tấn công. Tại sao những rủi ro này vẫn tồn tại mặc dù có sự nhận thức và công cụ rộng rãi?

Sự nhận thức không sửa đổi các khuyến khích hoặc sự phức tạp. Hầu hết các tổ chức vẫn đo lường thành công bằng thể tích quét, đóng vé hoặc danh sách kiểm tra tuân thủ thay vì giảm phơi nhiễm thực tế.

Đồng thời, chuỗi cung ứng phần mềm đã bùng nổ về quy mô. Các nhà phát triển lắp ráp ứng dụng từ hàng nghìn thành phần mà họ không viết và chắc chắn không đánh giá về bảo mật. Các nhóm bảo mật bị choáng ngợp khi cố gắng phân loại các rủi ro lý thuyết và không thể tập trung vào 1-2% thực sự quan trọng. Không có bằng chứng thời gian chạy, việc ưu tiên bị phá vỡ. Và với sự xuất hiện của các mô hình AI mạnh mẽ và các công cụ hỗ trợ, khối lượng đang tăng lên theo cấp số nhân.

Làm thế nào các tổ chức nên suy nghĩ lại sự phụ thuộc của họ vào nhật ký và cảnh báo khi một số lỗ hổng quan trọng nhất không để lại tín hiệu quan sát được?

Nhật ký là bằng chứng về những gì ứng dụng chọn báo cáo, không nhất thiết là bằng chứng về những gì thực sự xảy ra. Đó là một sự phân biệt nguy hiểm. Các tổ chức cần chuyển từ quan sát gián tiếp sang quan sát trực tiếp. Thay vì hy vọng một cuộc khai thác tạo ra một dấu vết có thể phát hiện, các hệ thống bảo mật nên xác định hành vi dễ bị tấn công và hành vi khai thác tại thời điểm chạy. Nếu mã nguy hiểm được thực thi, hệ thống nên biết ngay lập tức – cho dù có một mục nhập nhật ký hay không.

Bạn đã đề xuất khả năng hiển thị thời gian chạy như một giải pháp. Khả năng hiển thị thời gian chạy thực sự trông như thế nào trong thực tế và nó thay đổi cách các nhóm bảo mật hoạt động hàng ngày như thế nào?

Khả năng hiển thị thời gian chạy thực sự có nghĩa là hiểu ứng dụng thực sự đang làm gì trong sản xuất:哪些 tuyến đường được暴露,哪些 thư viện đang hoạt động, dòng chảy dữ liệu nhạy cảm ở đâu, mã nào được thực thi và liệu một cuộc tấn công có đạt được chức năng dễ bị tấn công hay không. Về mặt hoạt động, nó thay đổi bảo mật từ một cuộc săn lùng phản ứng thành một kỷ luật chính xác. Các nhóm ngừng theo đuổi danh sách chờ đợi lỗ hổng lớn và bắt đầu tập trung vào tỷ lệ nhỏ các điểm yếu có thể tiếp cận, quan trọng và đang bị nhắm mục tiêu tích cực. Điều đó cải thiện đáng kể tỷ lệ tín hiệu trên tiếng ồn và tốc độ phản hồi. Trung bình, chỉ 38% thư viện mã nguồn mở được đóng gói trong một ứng dụng thực sự được tải vào bộ nhớ và thực thi. Và không tất cả mã trong tập con này được sử dụng. Vì vậy, một điều đơn giản mà bảo mật thời gian chạy cho phép là tập trung vào mã thực sự chạy, không phải tất cả các thư viện và hàm không sử dụng đi kèm với ứng dụng.

Làm thế nào bảo mật dựa trên công cụ đo lường so với các phương pháp truyền thống như SAST, DAST hoặc giám sát biên về hiệu quả và khả năng mở rộng?

Các công cụ truyền thống suy đoán rủi ro từ bên ngoài. Công cụ đo lường quan sát thực tế bằng cách quan sát mã thực tế khi nó chạy. Công cụ đo lường có thể thấy các đường dẫn thực thi thực tế, hành vi khuôn khổ, ngữ cảnh xác thực, luồng dữ liệu và thành công khai thác trong thời gian thực. Nó loại bỏ các danh mục lớn các kết quả dương tính giả và暴露 các lỗ hổng mà các công cụ biên giới hoàn toàn bỏ lỡ.
Ở quy mô, sự chính xác đó trở nên quan trọng. Các tổ chức không thể phân loại thủ công hàng triệu phát hiện lý thuyết nữa. Bằng chứng thời gian chạy đang trở thành bộ lọc duy nhất bền vững. Thời gian chạy hoạt động trong thời gian thực, vì vậy nó là một sự phù hợp tốt hơn với các đường ống phát triển và CI/CD so với quét và phân loại. Và thời gian chạy là liên tục, vì vậy bạn không bị giới hạn ở một điểm nhìn thời gian của bảo mật.

Khi các hệ thống AI và ứng dụng tự động trở nên phổ biến hơn, các lỗ hổng vô hình này có trở nên nguy hiểm hơn không, và các nhóm nên chuẩn bị như thế nào?

AI làm cho các lỗ hổng vô hình trở nên nguy hiểm hơn vì nó tăng tốc cả hai bên của vấn đề. Các nhà phát triển đang tạo ra phần mềm nhanh hơn, và các kẻ tấn công đang tìm và khai thác điểm yếu nhanh hơn. Nhưng hầu hết các chương trình bảo mật vẫn phụ thuộc vào các quy trình có con người trong vòng lặp mà không thể hoạt động ở tốc độ AI. Các nhóm nên chuẩn bị theo hai cách. Đầu tiên, xây dựng các biện pháp phòng thủ thời gian chạy mạnh mẽ có thể phát hiện, chặn và chứa các cuộc tấn công trong sản xuất trong khi các lỗ hổng đang được sửa. Điều đó cung cấp cho các tổ chức sự che chắn. Thứ hai, sử dụng AI và tự động hóa để viết mã an toàn hơn ngay từ đầu – với thiết kế tốt hơn, kiểm tra, xem xét và xác minh. Nếu không, chúng ta chỉ đang tạo ra rủi ro nhanh hơn chúng ta có thể quản lý.

Nếu bạn đang tư vấn cho một lãnh đạo Trung tâm Vận hành Bảo mật (SOC) hiện đại ngày nay, những bước cụ thể đầu tiên họ nên thực hiện để đóng khoảng trống khả năng hiển thị này trước khi nó dẫn đến một sự vi phạm lớn là gì?

Đầu tiên, chấp nhận rằng telemetry biên giới alone là không đủ cho bảo mật ứng dụng hiện đại. Trên thực tế, nó là không thể thấy hoặc dừng lại nhiều cuộc tấn công ứng dụng và API tại biên giới. SOC cần có khả năng hiển thị bên trong các ứng dụng đang chạy, không chỉ là cơ sở hạ tầng lưu trữ chúng. Thứ hai, ưu tiên bằng chứng thời gian chạy hơn các phát hiện lý thuyết. Tập trung vào các lỗ hổng trong mã hoạt động, xác định các đường tấn công hoạt động, và các dịch vụ暴露 thực sự đang thực thi trong sản xuất. Cuối cùng, thống nhất bảo mật ứng dụng và kỹ thuật phát hiện. SOC tương lai không thể coi ứng dụng là các hộp đen không thể xuyên thủng nữa. Ứng dụng hiện là bề mặt tấn công chính và chúng cần có khả năng hiển thị thời gian chạy hạng nhất.

Cảm ơn bạn vì cuộc phỏng vấn tuyệt vời, độc giả muốn tìm hiểu thêm có thể truy cập OWASP hoặc Contrast Security.