किसी बड़े भाषा मॉडल (LLM) से क्लाइंट का मटीरियल पढ़ने के लिए कहने से पहले, अपने अधिकृत टेस्ट के लिए एक सीमित वर्कफ़्लो बनाएँ। एक बड़ा भाषा मॉडल (LLM) अपने इनपुट में मौजूद पैटर्न से टेक्स्ट बनाता है। पेनिट्रेशन टेस्ट में, यह सामान्य विश्लेषण को तेज़ कर सकता है, लेकिन यह तय नहीं कर सकता कि कोई दावा सही है, अनुमत है, या क्लाइंट को देने के लिए तैयार है।
सिम्युलेटेड — एंगेजमेंट का उदाहरण:
रेडवुड पेमेंट्स के लिए एक एग्रीमेंट के तहत किए जा रहे असेसमेंट के दौरान, एक टेस्टर LLM को स्कैन टेक्स्ट देता है जिसमें एक गंभीर वल्नरेबिलिटी (सुरक्षा खामी) का पता चलता है। मॉडल CVE और बिज़नेस पर पड़ने वाले असर के साथ एक अच्छी तरह से तैयार की गई फाइंडिंग (निष्कर्ष) बनाता है। टेस्टर रॉ स्कैन आउटपुट और टारगेट वर्शन की जाँच करता है, पाता है कि CVE लागू नहीं होता है, और रिपोर्ट क्लाइंट तक पहुँचने से पहले उस फाइंडिंग को हटा देता है।
इसका उपयोगी नतीजा सिर्फ़ तेज़ी से टेक्स्ट लिखना नहीं है। बल्कि यह ठोस सबूत, सटीक रिपोर्ट और क्लाइंट का भरोसा है। LLM का हर योगदान एंगेजमेंट के दायरे में रहता है और किसी फाइंडिंग या क्लाइंट को दी जाने वाली चीज़ में बदलाव करने से पहले इंसानी जाँच के दौर से गुज़रता है। आइए, रेडवुड पेमेंट्स के वर्कफ़्लो में इन जाँच के चरणों को शामिल करें:
वेरिफिकेशन गेट (जाँच का चरण) वह बिंदु है जहाँ टेस्टर, LLM के आउटपुट को इस्तेमाल करने से पहले उसे मुख्य सबूतों से मिलाता है। मुख्य सबूतों में मंज़ूर किए गए टूल का आउटपुट, टाइमस्टैम्प, कमांड, स्क्रीनशॉट और टारगेट की वेरिफ़ाई की गई जानकारी शामिल होती है। भले ही LLM ने जानकारी को व्यवस्थित किया हो या भाषा तैयार की हो, दावे की ज़िम्मेदारी टेस्टर की ही होती है।
LLM का इस्तेमाल सीमित मदद के लिए करें। यह रेकॉन (recon) नोट्स का सारांश बना सकता है, स्कैन के नतीजों को छाँट सकता है, वेरिफ़ाई किए गए नतीजे को समझा सकता है और रिपोर्ट का टेक्स्ट तैयार कर सकता है। इसे एक्सप्लॉइट (exploits) नहीं बनाने चाहिए, अधिकृत दायरे (scope) को नहीं बढ़ाना चाहिए, या मंज़ूर किए गए टारगेट पर किसी कमज़ोरी के होने के सबूत की जगह नहीं लेनी चाहिए। हम हर मंज़ूर किए गए टचपॉइंट पर ज़रूरी जाँच-पड़ताल कर सकते हैं:
LLM की गलतियों से पेंटेस्ट (pentest) में खास तरह का नुकसान हो सकता है क्योंकि अच्छी तरह से लिखे गए शब्दों से बिना सबूत वाले दावे भी भरोसेमंद लग सकते हैं। मनगढ़ंत CVE, गलत गंभीरता (severity), फ़ॉल्स पॉज़िटिव, स्कोप क्रीप और डेटा लीक - इन सबके लिए अलग-अलग तरह से जाँच करने की ज़रूरत होती है। किसी संभावित समस्या के बारे में अलर्ट करना तभी फ़ायदेमंद होता है जब टेस्टर उसे मौजूद सबूतों के आधार पर दोबारा करके दिखा सके या गलत साबित कर सके।
सबसे पहले सबूत LLM ड्राफ़्ट को एक वर्किंग नोट की तरह समझें। कोई फ़ाइंडिंग (खोज) तभी रिपोर्ट करने लायक बनती है जब उसके सबूत, स्कोप, असर और संदर्भ टेस्टर की समीक्षा में सही साबित हों।
क्लाइंट का डेटा एक अलग दायरा बनाता है। स्कैन आउटपुट, लॉग, ऑथेंटिकेशन मटीरियल और पर्सनल डेटा में ऐसी जानकारी हो सकती है जिसे क्लाइंट ने कभी किसी बाहरी सर्विस के लिए मंज़ूरी नहीं दी हो। उस मटीरियल को हटा दें या रोक कर रखें, जब तक कि लिखित मंज़ूरी में उस खास सर्विस और इस्तेमाल का ज़िक्र न हो। हम हर तरह की विफलता (failure mode) को उस आदत से जोड़ सकते हैं जिससे वह जुड़ी है: