AI ऐप्लिकेशन्स को सुरक्षित करनामध्यमपाठ 1368 मिनट का पाठ

किसी AI फ़ीचर की थ्रेट मॉडलिंग

बनाने से पहले, डेटा का फ़्लो ड्रा करें, निशान लगाएं कि भरोसा कहाँ बदलता है, और पूछें कि क्या गलत हो सकता है। AI फ़ीचर्स के लिए यहाँ एक व्यावहारिक तरीका दिया गया है।

✦ ट्यूटर से पूछें🧪 लैब · 35 min📝 पाठ का टेस्ट
पाठ वीडियो में

60 सेकंड में

किसी AI फ़ीचर की थ्रेट मॉडलिंग

बनाने से पहले, डेटा का फ़्लो ड्रा करें, निशान लगाएं कि भरोसा कहाँ बदलता है, और पूछें कि क्या गलत हो सकता है। AI फ़ीचर्स के लिए यहाँ एक व्यावहारिक तरीका दिया गया है।

1/4
आसान शब्दों में
स्कूल ट्रिप से पहले, शिक्षक बैठकर पूछते हैं: कोई बच्चा कहाँ खो सकता है? अगर बारिश हो जाए तो क्या होगा? फ़र्स्ट-एड बॉक्स किसके पास है? थ्रेट मॉडलिंग भी यही प्लानिंग है, जो सॉफ़्टवेयर के लिए कुछ गलत होने से पहले की जाती है।
थ्रेट मॉडलिंग यह सोचने का एक व्यवस्थित तरीका है कि किसी सिस्टम में क्या गड़बड़ हो सकती है, और उसके बारे में क्या करना है। डिज़ाइन के समय यह सबसे सस्ता पड़ता है, जब प्लान बदलने में पूरा कोड दोबारा लिखने के बजाय बस एक मीटिंग का खर्च आता है। इसका एक आसान वर्शन चार सवाल पूछता है: हम क्या बना रहे हैं? क्या गलत हो सकता है? हम इसके बारे में क्या करेंगे? क्या हमने अच्छा काम किया?

स्टेप 1: डेटा फ़्लो ड्रा करें

फ़ीचर के हर हिस्से को और हर उस तीर को ड्रा करें जहाँ डेटा जाता है। किसी AI फ़ीचर के लिए, उन हिस्सों को भी शामिल करें जिन्हें लोग भूल जाते हैं: system prompt, retrieval store, tool calls, logs और model provider।
Data-flow sketch: support bot for an online shoptext
[Customer browser]
      |  question
======|================= trust boundary: internet -> our app
      v
[App server] --reads--> [Order DB]
      |  system prompt + question + retrieved help pages
======|================= trust boundary: our app -> model provider
      v
[Model API] --proposes tool call--> [App server]
                                        |
======|================= trust boundary: model output -> our actions
                                        v
                               [Refund tool]  [Logs]
ट्रस्ट बाउंड्री ऐसी कोई भी रेखा होती है जहाँ डेटा उन हिस्सों के बीच जाता है जो एक-दूसरे पर अलग तरह से भरोसा करते हैं। AI फ़ीचर्स में एक अतिरिक्त बाउंड्री होती है जो सबसे ज़्यादा मायने रखती है: मॉडल क्या सुझाव देता है और आपका कोड वास्तव में क्या करता है, इसके बीच।

स्टेप 2: एसेट्स के नाम तय करें

एसेटउदाहरणकिससे नुकसान होगा
डेटाऑर्डर हिस्ट्री, पते, अंदरूनी हेल्प पेजएक ग्राहक किसी दूसरे का डेटा देख लेता है
पैसेरिफ़ंड, आपका मॉडल API बिलफ़र्ज़ी रिफ़ंड, बहुत भारी बिल
एक्शन्सरिफ़ंड टूल, ईमेल भेजना, ऑर्डर बदलनाबॉट कुछ ऐसा कर देता है जिसके लिए किसी ने नहीं कहा था
भरोसा और प्रतिष्ठाऐसे जवाब जिनका ग्राहक स्क्रीनशॉट लेकर शेयर कर देते हैंबॉट किसी फ़र्ज़ी ऑफ़र का वादा कर देता है या कुछ आपत्तिजनक कह देता है

स्टेप 3: STRIDE, AI फ़ीचर्स के अनुसार

STRIDE छह तरह के खतरों की एक जानी-मानी चेकलिस्ट है। हर एक का अपना एक AI वर्शन होता है।
खतरापारंपरिक अर्थAI फ़ीचर में
Spoofingकिसी और का रूप धारण करनाकिसी दस्तावेज़ का टेक्स्ट सिस्टम या एडमिन होने का दावा करता है; कोई यूज़र दावा करता है "मैं मैनेजर हूँ"
Tamperingडेटा या कोड बदलनानॉलेज बेस में ज़हरीले (poisoned) हेल्प पेज; बदला हुआ prompt template
Repudiationयह मुकर जाना कि आपने कुछ किया थाइस बात का कोई रिकॉर्ड न होना कि किस prompt और किस खोजे गए टेक्स्ट की वजह से रिफ़ंड हुआ
Information disclosureडेटा लीक होनाबॉट किसी दूसरे यूज़र का ऑर्डर, system prompt या कोई गोपनीय दस्तावेज़ दिखा देता है
Denial of serviceसर्विस को अनुपलब्ध कर देनाबहुत बड़े इनपुट्स, एजेंट लूप्स, या बहुत भारी खर्च जो पूरे बजट को खत्म कर दे
Elevation of privilegeवे अधिकार पाना जो आपके पास नहीं होने चाहिएकोई यूज़र मॉडल से ऐसा टूल कॉल करवा लेता है जिसे वह खुद सीधे कॉल नहीं कर सकता (एक confused deputy)

स्टेप 4: अब्यूज़ केस लिखें

एक अब्यूज़ केस हमलावर के नज़रिए से लिखी गई यूज़र स्टोरी होती है। यह बातचीत को ठोस बनाए रखती है।
  • "एक ग्राहक के रूप में, मैं किसी दूसरे ग्राहक का ऑर्डर नंबर टाइप करता हूँ और कर्मचारी होने का दावा करता हूँ, ताकि मैं उनका पता देख सकूँ।"
  • "एक बाहरी व्यक्ति के रूप में, मैं छिपे हुए निर्देशों के साथ एक प्रोडक्ट रिव्यू पोस्ट करता हूँ, ताकि बॉट दूसरे यूज़र्स से फ़र्ज़ी UPI ID पर पेमेंट करने को कहे।"
  • "एक बॉट ऑपरेटर के रूप में, मैं एक मुफ़्त चैटबॉट पर हज़ारों लंबे सवालों की स्क्रिप्ट चलाता हूँ, ताकि दुकान के खर्चे पर मुझे मुफ़्त में मॉडल का इस्तेमाल मिल सके।"

स्टेप 5: कंट्रोल्स, ज़िम्मेदार लोग और फ़ॉलो-अप

  1. 1

    प्राथमिकता तय करें

    हर अब्यूज़ केस के लिए: इसकी कितनी संभावना है, और यह कितना बुरा हो सकता है? सबसे बुरे से शुरू करें।
  2. 2

    कंट्रोल्स चुनें

    कोड और डेटा एक्सेस में कंट्रोल्स को प्राथमिकता दें: परमिशन चेक्स, लिमिट्स, मंज़ूरी।
  3. 3

    ज़िम्मेदारी सौंपें

    हर कंट्रोल के लिए एक व्यक्ति और एक तारीख तय की जाती है।
  4. 4

    टेस्ट्स में बदलें

    हर अब्यूज़ केस एक टेस्ट केस बन जाता है जिसे आप दोबारा चला सकते हैं।
  5. 5

    दोबारा समीक्षा करें

    नया टूल, नया डेटा सोर्स, नया मॉडल या नए यूज़र्स: थ्रेट मॉडल को अपडेट करें।
नोट
MITRE ATLAS AI सिस्टम्स के खिलाफ इस्तेमाल होने वाली रणनीतियों और तकनीकों का एक सार्वजनिक नॉलेज बेस है, बिल्कुल MITRE ATT&CK की तरह। जब आप पूछते हैं "क्या गलत हो सकता है?", तो इसे विचारों की एक सूची की तरह इस्तेमाल करें, ताकि आपको सिर्फ अपनी याददाश्त पर निर्भर न रहना पड़े।
सावधान रहें
ऐसा थ्रेट मॉडल जो सिर्फ़ स्लाइड डेक में पड़ा रहे और कभी अपडेट न हो, किसी काम का नहीं होता। इसे छोटा रखें, कोड या डिज़ाइन डॉक्स के साथ रखें, और जब फ़ीचर बदले तो इसे भी बदलें।
यह करके देखें। ऊपर दिए गए डेटा-फ़्लो स्केच को देखें। एक ज़हरीला हेल्प पेज कहाँ से अंदर आएगा? रिफ़ंड करवाने के लिए वह किस तीर के रास्ते आगे बढ़ेगा?

और देखें और पढ़ें

MITRE ATLASMITRE · readingNIST AI Risk Management FrameworkNIST · reading

लैब

कागज़ पर या किसी डॉक्यूमेंट में, एक छोटे AI सपोर्ट बॉट के लिए एक पेज का थ्रेट मॉडल।

~35 min

समस्या

फ़ीचर: साड़ियों की एक छोटी ऑनलाइन दुकान के लिए चैट सपोर्ट बॉट। यह दुकान के हेल्प पेजों से सवालों के जवाब देता है, लॉग-इन किए हुए ग्राहक के ऑर्डर का स्टेटस देख सकता है, और ₹500 तक का रिफ़ंड जारी कर सकता है।

  1. डेटा फ़्लो ड्रा करें। इसमें ब्राउज़र, ऐप सर्वर, ऑर्डर डेटाबेस, हेल्प पेज, मॉडल API, रिफ़ंड टूल और लॉग्स शामिल करें। हर ट्रस्ट बाउंड्री पर निशान लगाएं।
  2. एसेट्स की सूची बनाएं: डेटा, पैसे, एक्शन्स, प्रतिष्ठा।
  3. छह अक्षरों में से हर एक के लिए एक STRIDE खतरा लिखें।
  4. "एक … के रूप में, मैं …, ताकि …" के रूप में तीन अब्यूज़ केस लिखें।
  5. अपने शीर्ष तीन खतरों को चुनें और प्रत्येक के लिए एक कंट्रोल और ज़िम्मेदार व्यक्ति तय करें।

आपका काम तब पूरा होगा जब

कठिन सवाल

उत्तर देखने से पहले ख़ुद जवाब देने की कोशिश करें। अगर आप इनके जवाब दे सकते हैं, तो आप पाठ समझ गए हैं।

Q1जब मॉडल और आपके टूल्स दोनों आपके अपने सिस्टम के अंदर चलते हैं, तो उनके बीच ट्रस्ट बाउंड्री क्यों बनाई जाए?दिखाएं

क्योंकि मॉडल का आउटपुट ऐसे टेक्स्ट से तय होता है जिस पर आपका कंट्रोल नहीं होता: यूज़र के मैसेज, रीट्रिव किए गए डॉक्युमेंट्स, प्रॉडक्ट रिव्यू। इसलिए मॉडल द्वारा सुझाया गया टूल कॉल असल में किसी हमलावर की रिक्वेस्ट हो सकता है। टूल के कोड को पहचान, ओनरशिप और लिमिट्स खुद चेक करनी चाहिए, ठीक वैसे ही जैसे वह इंटरनेट से आने वाली किसी रिक्वेस्ट के लिए करता।

Q2आपके थ्रेट मॉडल में यह कंट्रोल दिया गया है "सिस्टम प्रॉम्प्ट बॉट को बताता है कि कभी भी ₹500 से ज़्यादा का रिफ़ंड न करे"। इसमें क्या गड़बड़ी है, और इसका हल क्या है?दिखाएं

यह मॉडल से की गई एक रिक्वेस्ट है, कोई कंट्रोल नहीं। मॉडल को बातों में बहकाया जा सकता है, या इंजेक्ट किए गए टेक्स्ट से उसे धोखा दिया जा सकता है। इसका हल रिफ़ंड टूल के अंदर एक चेक लगाना है: ₹500 से ज़्यादा या ऑर्डर वैल्यू से ज़्यादा की किसी भी रकम को रिजेक्ट करें, और कन्फ़र्म करें कि ऑर्डर लॉग-इन किए गए यूज़र का ही है। बेहतर यूज़र एक्सपीरियंस के लिए प्रॉम्प्ट वाली लाइन रखी जा सकती है, लेकिन यही चीज़ आपको सुरक्षित नहीं रखती।

जारी रखने के लिए कृपया साइन इन करें।

अक्सर पूछे जाने वाले सवाल

थ्रेट मॉडल बनाने में कितना समय लगता है?

एक छोटे फ़ीचर के लिए, सही लोगों के साथ एक घंटा बैठकर एक उपयोगी पहला वर्शन बनाना अक्सर काफी होता है। किसी बड़े प्लेटफ़ॉर्म के लिए ज़्यादा समय चाहिए। एक छोटा मॉडल जिसका वास्तव में इस्तेमाल हो, उस बेहतरीन मॉडल से कहीं बेहतर है जिसे कोई पढ़ता ही नहीं।

मीटिंग में कौन-कौन होना चाहिए?

कोई ऐसा जो डिज़ाइन जानता हो, कोई जो कोड लिखता हो, कोई सिक्योरिटी टीम से, और सबसे अच्छा होगा कि प्रोडक्ट या सपोर्ट टीम से भी कोई हो जो जानता हो कि असली यूज़र्स कैसा व्यवहार करते हैं। सपोर्ट स्टाफ़ को अक्सर पहले से ही अब्यूज़ केस पता होते हैं।

क्या हमें किसी खास टूल की ज़रूरत है?

नहीं। व्हाइटबोर्ड, शेयर्ड डॉक्यूमेंट या पेन और कागज़ भी काम करता है। बड़े सिस्टम्स के लिए टूल्स मदद कर सकते हैं, लेकिन टूल से ज़्यादा महत्वपूर्ण सोच होती है।

MITRE ATLAS और MITRE ATT&CK में क्या अंतर है?

ATT&CK सामान्य IT सिस्टम्स के खिलाफ हमलावरों के तौर-तरीकों की सूची बनाता है। ATLAS खास तौर पर AI और मशीन लर्निंग सिस्टम्स पर होने वाले हमलों पर ध्यान देता है। किसी AI फ़ीचर के लिए आप अक्सर दोनों का इस्तेमाल करेंगे, क्योंकि मॉडल के आस-पास का ऐप अभी भी सामान्य IT ही होता है।

पाठ का टेस्ट

5 सवाल। पास होने और इस पाठ को पूरा करने के लिए 3 सही होने चाहिए (60%)।

टेस्ट देने और अपनी प्रोग्रेस सेव करने के लिए साइन इन करें