Mùa “Proof of Concept” sắp đến

Ba dấu hiệu nhà cung cấp dịch vụ an ninh mạng của bạn có thể đang đánh lừa hệ thống

Bằng chứng về khái niệm mùa đang đến
Đối với những bạn đã tham dự Hội nghị RSA vào tháng 2023, tôi chắc chắn rằng hàng loạt email, cuộc gọi điện thoại và yêu cầu gặp mặt trên LinkedIn của nhà cung cấp đang diễn ra. Mặc dù tôi cá rằng nhiều nhà cung cấp đang cầu xin các cuộc họp cung cấp các sản phẩm hoặc dịch vụ không nằm trong tầm ngắm của bạn cho năm 2024-XNUMX, nhưng có thể có một số nhà cung cấp mà bạn muốn thử nghiệm để xem liệu họ có thể mang lại kết quả tốt hơn không những gì bạn hiện đang sử dụng. Đối với những nhà cung cấp đó, sau cuộc họp giới thiệu bắt buộc, một số cuộc thảo luận kỹ thuật hoặc thậm chí là cuộc gọi tham khảo khách hàng, bạn sẽ được cung cấp Bằng chứng về Khái niệm (đôi khi còn được gọi là Bằng chứng về Giá trị). Truyền thống lâu đời này cho phép bạn “Tự kiểm tra sản phẩm.”  

Trong PoC, nhà cung cấp cố gắng chỉ cho bạn cách sản phẩm của họ ngăn chặn nhiều cuộc tấn công hơn, phát hiện nhiều email lừa đảo hơn, phát hiện nhiều trang web độc hại hơn và những thứ tương tự để xác thực tuyên bố tiếp thị của họ. Mục đích đằng sau việc cung cấp PoC hoàn toàn hợp lý và sẽ giúp người mua tránh mua các sản phẩm có khả năng bán quá mức. Nhưng thật không may, thường thì các sản phẩm dường như hoạt động tốt trong PoC lại không mang lại kết quả tương tự sau khi được triển khai hoàn toàn trong môi trường của người mua. 

Làm sao có thể? Trong gần 20 năm xây dựng, bán hàng và tiếp thị của tôi an ninh mạng sản phẩm, tôi đã thấy gần như mọi cách mà các nhà cung cấp cố gắng đánh lừa các PoC này. Dưới đây là ba dấu hiệu cho thấy PoC của bạn có thể thấp hơn bảng trên.

 

“Chúng tôi cung cấp tất cả dữ liệu trong môi trường của mình, vì vậy bạn không phải lo lắng về điều đó.”

Thực tế là kiểm tra kỹ lưỡng an ninh mạng các sản phẩm dựa trên một số loại mối đe dọa bên ngoài hoặc một lượng lớn dữ liệu nội bộ để đào tạo các mô hình học máy có thể rất cồng kềnh. Vì không có chuyên viên bảo mật nào đồng ý hoặc nên đồng ý thử nghiệm một sản phẩm không xác định trong môi trường sản xuất của họ, nên họ sẽ cần một môi trường thử nghiệm mạnh mẽ hợp lý để đưa sản phẩm mới này vào thử nghiệm. Với yêu cầu này, sẽ rất hấp dẫn khi chấp nhận đề nghị của nhà cung cấp để tiến hành thử nghiệm bằng cách sử dụng dữ liệu của họ trong môi trường của nhà cung cấp. Nếu bạn nghĩ về nó trong một phút, điều này giống như yêu cầu học sinh viết câu hỏi cho bài kiểm tra cuối kỳ của họ. Bạn có nghĩ rằng thử nghiệm trong môi trường của nhà cung cấp với dữ liệu của họ có thể làm sai lệch kết quả có lợi cho họ không? Tất nhiên rồi. Mặc dù không ai muốn PoC của họ mất nhiều thời gian hơn một mùa khúc côn cầu NHL, nhưng bạn sẽ cần cung cấp dữ liệu để kiểm tra sản phẩm đúng cách. Một số nhà cung cấp có thể từ bỏ việc sử dụng một số công cụ mô phỏng các cuộc tấn công, điều này là hợp lý, miễn là bạn, với tư cách là khách hàng tiềm năng, có quyền lựa chọn sử dụng chúng hay không. Cách tốt nhất để giảm thiểu độ dài của PoC là chọn tối đa hai hoặc ba trường hợp sử dụng bạn đang nhắm mục tiêu và cung cấp dữ liệu cần thiết cho riêng các trường hợp sử dụng đó. Lý tưởng nhất là các sản phẩm bạn thử nghiệm sẽ giúp việc tích hợp các sản phẩm tạo dữ liệu trong môi trường của bạn trở nên dễ dàng. 

 

“Chúng ta đang thử nghiệm phiên bản nào? Đó là khá nhiều sản phẩm GA của chúng tôi. Bạn không thể nói sự khác biệt.”

Khi tôi bước vào ngành an ninh mạng và chuẩn bị cho PoC, chúng tôi đã yêu cầu các khách hàng tiềm năng thiết lập một máy chủ đáp ứng các yêu cầu tối thiểu của chúng tôi. Sau đó, tôi sẽ cài đặt sản phẩm trên máy theo cách thủ công để những người tham gia PoC có thể xem phiên bản nào của sản phẩm mà chúng tôi sẽ sử dụng để thử nghiệm. 

Trong thế giới ngày nay, nơi SaaS là ​​tiêu chuẩn, việc biết phiên bản của sản phẩm bạn đang thử nghiệm có thể giống như một chuyến đi xuống hố sâu. Đáng buồn thay, tôi đã nghe những câu chuyện kinh dị từ các học viên khi họ tham gia PoC với một nhà cung cấp và kết quả thật tuyệt vời, vì vậy họ đã ký hợp đồng mua sản phẩm. Nhanh chóng chuyển tiếp một hoặc hai tháng, và các học viên và ban quản lý đã vô cùng thất vọng. Sản phẩm được cài đặt trong môi trường của họ không giống như những gì họ đã thử nghiệm. Các tính năng bị thiếu, các tích hợp mà họ đã sử dụng không được tìm thấy và câu chuyện từ nhà cung cấp là, "Phiên bản đó sẽ sớm ra mắt." Trong một số trường hợp, tôi thấy không có vấn đề gì khi sử dụng phiên bản sản phẩm chưa được phát hành cho PoC miễn là nhà cung cấp minh bạch với khách hàng tiềm năng. Thật không may, khi khách hàng cảm thấy như nhà cung cấp đang cố che giấu điều gì đó với họ, thì mối quan hệ khách hàng/nhà cung cấp lẽ ra phải hợp tác có thể ngay lập tức trở nên gây gổ. 

 

“Chúng tôi chưa bao giờ bỏ lỡ một mối đe dọa nào trong PoC.”

Năm 1941, Ted Williams, còn được gọi là Mảnh vỡ lộng lẫy, đã có một mùa giải kỳ diệu trên đĩa, kết thúc mùa giải của anh ấy với Boston Red Sox với tỷ lệ đánh bóng trung bình đáng kinh ngạc là 406 và tỷ lệ phần trăm cơ bản là 553. Nhiều nhà sử học bóng chày cho rằng Ted Williams là tay đập thuần túy nhất từng chơi trò chơi này. Cho đến nay, không có người đánh bóng nào trong AL hoặc NL làm lu mờ mức trung bình 400 trong năm. Vì vậy, Ted Williams phải làm gì với một blog về PoC an ninh mạng? Vấn đề là không có gì, dù là sản phẩm an ninh mạng hay người đánh bóng giỏi nhất từng chơi trò chơi, luôn luôn hoàn hảo. Bạn có thể kiểm tra một sản phẩm dựa trên một tập hợp các vectơ đe dọa cụ thể và sản phẩm có thể xác định tất cả chúng không? Tuyệt đối. Nó có thể làm điều đó liên tục với các mối đe dọa mới trong hai ngày, 5, 10 hoặc thậm chí 100 ngày không? Nhưng chắc chắn như tôi biết rằng trong mùa giải năm 1941 đó, Ted Williams đã ra đòn 27 lần, sẽ có ngày chiếc xe mới sáng bóng của bạn an ninh mạng sản phẩm bỏ lỡ một mối đe dọa mà bạn nghĩ rằng nó sẽ phát hiện ra.  

Trong PoC, nếu kết quả thô từ thử nghiệm sản phẩm không có sẵn ngay lập tức hoặc bạn nhận thấy những người từ nhà cung cấp đang làm việc trong dự án mà bạn chưa từng gặp, hãy cảnh báo. Bạn đang chứng kiến ​​một nhóm bán hàng kêu gọi trợ giúp từ các nhà phát triển, nhà nghiên cứu mối đe dọa của intel hoặc kỹ sư phần mềm đang làm việc trong quá trình triển khai của bạn, cố gắng tìm ra lý do tại sao họ bỏ lỡ các mối đe dọa hoặc một tính năng không hoạt động. Một lần nữa, lỗi phần mềm có thể xuất hiện trong PoC không? Tuyệt đối. Khi họ làm như vậy, bạn có thể tìm thấy các nhà phát triển và kỹ sư đang gỡ lỗi mã trực tiếp không – chắc chắn rồi. Chìa khóa ở đây là sự minh bạch. Các nhà cung cấp có đạo đức sẽ thẳng thắn với bạn nếu và khi một khiếm khuyết xuất hiện. Họ cũng sẽ giải thích lý do tại sao một mối đe dọa, nếu có, lại bị bỏ sót trong PoC. Hãy nhớ rằng, khi chạy PoC sản phẩm, bạn nên so sánh kết quả với những gì bạn hiện đang sử dụng và các sản phẩm khác mà bạn đang thử nghiệm, chứ không phải một hệ thống hoang đường liên tục phát hiện 100% các mối đe dọa. Bạn đang tìm kiếm kết quả tốt hơn đáng kể, không phải sự hoàn hảo. 

 

PoC cho mọi người

Với rất nhiều sản phẩm trên thị trường khẳng định khả năng, lợi ích và kết quả tương tự, gần như không thể xác định được sản phẩm nào sẽ hoạt động tốt nhất cho bạn nếu không chạy PoC. Do đó, tôi là một người hâm mộ PoC vì khi được vận hành công bằng, nó sẽ mang lại cho các sản phẩm cạnh tranh cơ hội đối đầu trong thế giới thực. 

Hãy để sản phẩm tốt nhất giành chiến thắng.

Di chuyển về đầu trang