TL; DR: Nghe có vẻ kỳ lạ, nhưng việc nhìn thấy một vài kết quả dương tính giả do máy quét bảo mật báo cáo có lẽ là một dấu hiệu tốt và chắc chắn tốt hơn là không thấy. Hãy giải thích tại sao.
Giới thiệu
Những mặt tích cực giả đã xuất hiện phần nào bất ngờ trong cuộc sống của chúng ta trong những năm gần đây. tất nhiên, tôi đang đề cập đến đại dịch COVID-19, đại dịch đòi hỏi các chiến dịch thử nghiệm lớn để kiểm soát sự lây lan của vi rút. Đối với hồ sơ, dương tính giả là kết quả có vẻ dương tính (đối với COVID-19 trong trường hợp của chúng tôi), trong đó thực tế là âm tính (người đó không bị nhiễm bệnh). Thông thường hơn, chúng ta nói về báo động giả.
Trong bảo mật máy tính, chúng ta cũng thường xuyên phải đối mặt với các lỗi dương tính giả. Hãy hỏi nhóm bảo mật đằng sau bất kỳ SIEM nào thách thức hoạt động lớn nhất của họ là gì và rất có thể là các trường hợp dương tính giả sẽ được đề cập. Một báo cáo gần đây ước tính rằng có tới 20% tất cả các cảnh báo mà các chuyên gia bảo mật nhận được là dương tính giả, khiến nó trở thành một nguồn mệt mỏi lớn.
Tuy nhiên, câu chuyện đằng sau dương tính giả không đơn giản như nó có thể xuất hiện lúc đầu. Trong bài viết này, chúng tôi sẽ ủng hộ rằng khi đánh giá một công cụ phân tích, việc nhìn thấy tỷ lệ dương tính giả vừa phải là một dấu hiệu khá tốt về hiệu quả.
Chính xác thì chúng ta đang nói về cái gì?
Với phân tích tĩnh trong bảo mật ứng dụng, mối quan tâm hàng đầu của chúng tôi là bắt tất cả các lỗ hổng thực sự bằng cách phân tích mã nguồn.
Dưới đây là hình dung để nắm bắt rõ hơn sự phân biệt giữa hai khái niệm cơ bản của phân tích tĩnh: độ chính xác và nhớ lại. Kính lúp đại diện cho mẫu đã được xác định hoặc chọn bởi công cụ phát hiện. Bạn có thể tìm hiểu thêm về cách đánh giá hiệu suất của quy trình thống kê tại đây.
Hãy xem điều đó có nghĩa là gì từ quan điểm kỹ thuật:
bằng cách giảm xác thực giả, chúng tôi cải thiện độ chính xác (tất cả các lỗ hổng được phát hiện thực sự đại diện cho một vấn đề bảo mật). bằng cách giảm âm tính giả, chúng tôi cải thiện khả năng thu hồi (tất cả các lỗ hổng bảo mật hiện có đều được xác định chính xác). ở mức thu hồi 100%, công cụ phát hiện sẽ không bao giờ bỏ sót lỗ hổng. với độ chính xác 100%, công cụ phát hiện sẽ không bao giờ đưa ra cảnh báo sai.
Nói một cách khác, mục tiêu của máy quét lỗ hổng là đặt hình tròn (trong kính lúp) càng gần hình chữ nhật bên trái (các yếu tố có liên quan) càng tốt.
Vấn đề là câu trả lời hiếm khi rõ ràng, có nghĩa là phải đánh đổi.
Vì vậy, điều gì là mong muốn hơn: tối đa hóa độ chính xác hoặc thu hồi?
Cái nào tệ hơn, quá nhiều dương tính giả hay quá nhiều âm tính giả?
Để hiểu lý do tại sao, chúng ta hãy xem xét cả hai thái cực: hãy tưởng tượng rằng một công cụ phát hiện chỉ cảnh báo người dùng của nó khi xác suất một đoạn mã nhất định có chứa lỗ hổng bảo mật cao hơn 99,999%. Với ngưỡng cao như vậy, bạn có thể gần như chắc chắn rằng một cảnh báo thực sự là một tích cực thực sự. Nhưng có bao nhiêu vấn đề bảo mật sẽ không được chú ý vì tính chọn lọc của máy quét? Nhiều.
Ngược lại, điều gì sẽ xảy ra nếu công cụ được điều chỉnh để không bao giờ bỏ sót lỗ hổng (tối đa hóa việc thu hồi)? Bạn đoán nó: bạn sẽ sớm phải đối mặt với hàng trăm hoặc thậm chí hàng nghìn cảnh báo sai. Và có một mối nguy hiểm lớn hơn.
Như Aesop đã cảnh báo chúng ta trong truyện ngụ ngôn The Boy Who Cried Wolf, bất kỳ ai chỉ lặp lại những tuyên bố sai lầm sẽ không được lắng nghe. Trong thế giới hiện đại của chúng ta, sự hoài nghi sẽ thành hiện thực chỉ bằng một cú nhấp chuột đơn giản để hủy kích hoạt các thông báo bảo mật và khôi phục sự yên bình, hoặc chỉ bỏ qua chúng nếu việc hủy kích hoạt không được phép. Nhưng hậu quả ít nhất cũng có thể gay cấn như trong truyện ngụ ngôn.
Công bằng mà nói, sự mệt mỏi khi tỉnh táo có lẽ là lý do số một khiến việc phân tích tĩnh không thành công thường xuyên. Các cảnh báo sai không chỉ là nguồn gây ra lỗi của toàn bộ chương trình bảo mật ứng dụng mà còn gây ra nhiều thiệt hại nghiêm trọng hơn, chẳng hạn như kiệt sức và bỏ phiếu.
Tuy nhiên, bất chấp tất cả các tệ nạn được gán cho chúng, bạn sẽ nhầm khi nghĩ rằng nếu một công cụ không mang bất kỳ tích cực giả nào, thì nó phải mang lại câu trả lời dứt khoát cho vấn đề này.
Làm thế nào để học cách chấp nhận những kết quả tích cực sai
Để chấp nhận những kết luận sai lầm, chúng ta phải đi ngược lại bản năng cơ bản thường đẩy chúng ta đến những kết luận sớm. Một thí nghiệm suy nghĩ khác có thể giúp chúng ta minh họa điều này.
Hãy tưởng tượng rằng bạn được giao nhiệm vụ so sánh hiệu suất của hai máy quét bảo mật A và B.
Sau khi chạy cả hai công cụ trên điểm chuẩn của bạn, kết quả như sau: máy quét A chỉ phát hiện các lỗ hổng hợp lệ, trong khi máy quét B báo cáo cả lỗ hổng hợp lệ và không hợp lệ. Tại thời điểm này, ai lại không muốn đưa ra kết luận sớm? Bạn phải là một người quan sát đủ khôn ngoan để hỏi thêm dữ liệu trước khi quyết định. Dữ liệu có lẽ sẽ tiết lộ rằng một số bí mật hợp lệ do B báo cáo đã bị A im lặng bỏ qua.
Bây giờ bạn có thể thấy ý tưởng cơ bản đằng sau bài viết này: bất kỳ công cụ, quy trình hoặc công ty nào tuyên bố rằng chúng hoàn toàn không có kết quả dương tính giả sẽ có vẻ đáng ngờ. Nếu thực sự là như vậy, khả năng rất cao là một số yếu tố liên quan đã bị bỏ qua một cách âm thầm.
Việc tìm kiếm sự cân bằng giữa độ chính xác và khả năng thu hồi là một vấn đề tinh tế và đòi hỏi rất nhiều nỗ lực điều chỉnh (bạn có thể đọc cách các kỹ sư GitGuardian đang cải thiện độ chính xác của mô hình). Không chỉ vậy, việc thỉnh thoảng thấy nó bị lỗi cũng là điều hoàn toàn bình thường. Đó là lý do tại sao bạn nên lo lắng về việc không có dương tính giả nào hơn là chỉ thấy một vài kết quả.
Nhưng cũng có một lý do khác tại sao dương tính giả trên thực tế cũng có thể là một tín hiệu thú vị: bảo mật không bao giờ là “toàn màu trắng hoặc toàn màu đen”. Luôn luôn có một giới hạn mà “chúng tôi không biết”, và
nơi mà sự giám sát và phân loại của con người trở nên cần thiết.
“Do bản chất của phần mềm chúng tôi viết, đôi khi chúng tôi nhận được kết quả dương tính giả. Khi điều đó xảy ra, các nhà phát triển của chúng tôi có thể điền vào biểu mẫu và nói,” Này, đây là một kết quả dương tính giả. Đây là một phần của trường hợp thử nghiệm. Bạn có thể bỏ qua điều này. ”- Nguồn.
Có một sự thật sâu sắc hơn: an ninh không bao giờ là “tất cả các màu trắng hoặc tất cả các màu đen”. Luôn luôn có một ranh giới mà “chúng ta không biết”, và nơi mà sự giám sát và phân loại của con người trở nên cần thiết. Nói cách khác, nó không chỉ là về những con số thô, nó còn là về cách chúng sẽ được sử dụng. Những mặt tích cực giả rất hữu ích theo quan điểm đó: chúng giúp cải thiện các công cụ và tinh chỉnh các thuật toán để ngữ cảnh được hiểu và cân nhắc tốt hơn. Nhưng giống như một tiệm cận, con số 0 tuyệt đối không bao giờ có thể đạt được.
Tuy nhiên, có một điều kiện cần thiết để biến những gì có vẻ giống như một lời nguyền thành một vòng tròn đạo đức. Bạn phải đảm bảo rằng dương tính giả có thể được gắn cờ và kết hợp trong thuật toán phát hiện dễ dàng nhất có thể cho người dùng cuối. Một trong những cách phổ biến nhất để đạt được điều đó là chỉ cần cung cấp khả năng loại trừ các tệp, thư mục hoặc kho lưu trữ khỏi chu vi được quét.
Tại GitGuardian, chúng tôi chuyên về phát hiện bí mật. Chúng tôi đã thúc đẩy ý tưởng để nâng cao bất kỳ phát hiện nào với nhiều ngữ cảnh nhất có thể, dẫn đến chu kỳ phản hồi nhanh hơn nhiều và giảm bớt công việc nhiều nhất có thể.
Nếu một nhà phát triển cố gắng cam kết một bí mật với ggshield phía máy khách được cài đặt dưới dạng móc cam kết trước, thì việc cam kết sẽ bị dừng lại trừ khi nhà phát triển gắn cờ đó là một bí mật cần bỏ qua. Từ đó, bí mật được coi là dương tính giả và sẽ không kích hoạt cảnh báo nữa mà chỉ xuất hiện trên máy trạm cục bộ của anh ta. Chỉ thành viên nhóm bảo mật có quyền truy cập vào bảng điều khiển GitGuardian mới có thể gắn cờ dương tính giả cho toàn bộ nhóm (bỏ qua toàn cầu).
Nếu một bí mật bị rò rỉ được báo cáo, chúng tôi cung cấp các công cụ để giúp nhóm bảo mật nhanh chóng điều động chúng. Ví dụ: playbook tự động chữa lành tự động gửi thư đến nhà phát triển đã cam kết bí mật. Tùy thuộc vào cấu hình playbook, các nhà phát triển có thể được phép tự giải quyết hoặc bỏ qua sự cố, giảm bớt khối lượng công việc còn lại cho nhóm bảo mật.
Đây chỉ là một vài ví dụ về cách chúng tôi đã học cách điều chỉnh các quy trình phát hiện và khắc phục xung quanh dương tính giả, thay vì ám ảnh về việc loại bỏ chúng. Trong thống kê, nỗi ám ảnh này thậm chí còn có một cái tên: nó được gọi là overfitting, và nó có nghĩa là mô hình của bạn quá phụ thuộc vào một bộ dữ liệu cụ thể. Thiếu đầu vào trong thế giới thực, mô hình sẽ không hữu ích trong cài đặt sản xuất.
Sự kết luận
Các kết quả dương tính giả gây ra tình trạng mệt mỏi khi cảnh báo và các chương trình bảo mật bị trật bánh thường xuyên đến mức chúng ngày nay được nhiều người coi là điều ác thuần túy. Đúng là khi xem xét một công cụ phát hiện, bạn muốn có độ chính xác tốt nhất có thể, và việc có quá nhiều kết quả dương tính giả gây ra nhiều vấn đề hơn là không sử dụng bất kỳ công cụ nào ngay từ đầu. Điều đó đang được nói, không bao giờ bỏ qua tỷ lệ thu hồi.
Tại GitGuardian, chúng tôi đã thiết kế một kho vũ khí rộng rãi gồm các bộ lọc phát hiện chung để cải thiện tỷ lệ thu hồi của công cụ phát hiện bí mật của chúng tôi.
Từ góc độ thống kê thuần túy, có tỷ lệ dương tính giả thấp là một dấu hiệu khá tốt, có nghĩa là ít khuyết tật lọt qua lưới.
Khi kiểm soát, dương tính giả không phải là xấu. Chúng thậm chí có thể được sử dụng để làm lợi thế của bạn vì chúng chỉ ra nơi có thể thực hiện các cải tiến, cả về mặt phân tích hoặc về mặt khắc phục.
Hiểu tại sao một thứ gì đó được hệ thống coi là “hợp lệ” và có cách thích ứng với nó là chìa khóa để cải thiện bảo mật ứng dụng của bạn. Chúng tôi cũng tin rằng đây là một trong những lĩnh vực mà sự hợp tác giữa các nhóm bảo mật và phát triển thực sự tỏa sáng.
Lưu ý cuối cùng, hãy nhớ: nếu một công cụ phát hiện không báo cáo bất kỳ kết quả dương tính giả nào, hãy chạy. Bạn đang gặp rắc rối lớn.
Lưu ý – Bài viết này được viết và đóng góp bởi Thomas Segura, người viết nội dung kỹ thuật tại GitGuardian.
.
