ശരിയായി പ്രവർത്തിക്കുന്ന AI സംവിധാനങ്ങൾ നിർമ്മിക്കാൻ, ആദ്യം അവയെ നിങ്ങൾ തന്നെ മനപ്പൂർവ്വം തകർക്കേണ്ടതുണ്ട്. ഒരു ധനകാര്യ സേവന ആപ്പിനെ ലക്ഷ്യമിട്ട്, സൈബർ ആക്രമണകാരികളുടെ രീതിയിൽ അതിൻ്റെ സുരക്ഷ പരിശോധിക്കുന്നതിനായി ഞങ്ങൾ ഒരു റെഡ് ടീമിംഗ് പരീക്ഷണം നടത്തിയിരുന്നു. സുരക്ഷയിൽ ഒട്ടും വിട്ടുവീഴ്ചയില്ലാത്ത LLM അധിഷ്ഠിത ആപ്ലിക്കേഷനുകൾ ഉപയോഗിക്കുന്ന ഏതൊരാളും അറിഞ്ഞിരിക്കേണ്ട പ്രധാനപ്പെട്ട കാര്യങ്ങളാണ് ഞങ്ങൾ ഇതിലൂടെ കണ്ടെത്തിയത്.
യഥാർത്ഥത്തിൽ ഒരു സൈബർ ആക്രമണകാരി സുരക്ഷാ വീഴ്ചകൾ കണ്ടെത്തുന്നതിനുമുമ്പ് തന്നെ അവ കണ്ടെത്തി പരിഹരിക്കാനായി, നിങ്ങളുടെ AI സംവിധാനത്തെ മനഃപൂർവം തകർക്കാൻ ശ്രമിക്കുന്ന പ്രവർത്തനരീതിയാണ് റെഡ് ടീമിംഗ്. ധനകാര്യ സേവന രംഗത്ത് ഇതിൻ്റെ പ്രാധാന്യം വളരെ ഉയർന്നതാണ്: കാരണം ഇവിടുത്തെ AI ആപ്ലിക്കേഷനുകൾ ഉപയോക്താക്കളുടെ വ്യക്തിഗത വിവരങ്ങൾ കൈകാര്യം ചെയ്യുകയും ഇടപാടുകൾ നടത്തുകയും ധനകാര്യ വിവരങ്ങൾ നൽകുകയും ചെയ്യുന്നുണ്ട്. ഇതിലൊരു പരാജയം ഉണ്ടായാൽ അത് കേവലം ഒരു മോശം ഉപഭോക്തൃ അനുഭവത്തിൽ ഒതുങ്ങുന്നില്ല; മറിച്ച് നിയമലംഘനങ്ങൾക്കും സാമ്പത്തിക നഷ്ടങ്ങൾക്കും ബ്രാൻഡിൻ്റെ വിശ്വസ്തത എന്നെന്നേക്കുമായി തകരുന്നതിനും കാരണമായേക്കാം.
ഞങ്ങളുടെ ലക്ഷ്യം സുരക്ഷാ വീഴ്ചകൾ നേരത്തെ തന്നെ കണ്ടെത്തുക, യഥാർത്ഥ സൈബർ ആക്രമണ ശൈലികൾ പരീക്ഷിക്കുക, ഒപ്പം റഗുലേറ്റർമാർ അതീവ ഗൗരവത്തോടെ കാണുന്ന AI സുരക്ഷാ മാനദണ്ഡങ്ങൾ പാലിച്ച് മുന്നോട്ട് പോകാൻ ആ സ്ഥാപനത്തെ സഹായിക്കുക എന്നതുമായിരുന്നു.
ഇവിടെ വ്യക്തമാക്കേണ്ട ഒരു പ്രധാന വ്യത്യാസമുണ്ട്: ജെയിൽബ്രേക്കിംഗ് എന്നത് അടിസ്ഥാന മോഡലിൻ്റെ സുരക്ഷാ ഫിൽട്ടറുകളെയാണ് ആക്രമിക്കുന്നത്; എന്നാൽ പ്രോംപ്റ്റ് ഇൻജക്ഷൻ ആക്രമിക്കുന്നത് ആപ്ലിക്കേഷനെത്തന്നെയാണ്. ഇതിനായി, ഡെവലപ്പർ നൽകയിട്ടിളുള്ള വിശ്വസനീയമായ പ്രോംപ്റ്റുകളോടൊപ്പം സുരക്ഷിതമല്ലാത്ത യൂസർ ഇൻപുട്ടുകൾ കൂടിയാണ് സൈബർ ആക്രമണകാരികൾ ഉപയോഗിക്കുന്നത്. പ്രോംപ്റ്റ് ഇൻജക്ഷൻ കൂടുതൽ വലിയ സുരക്ഷാ ഭീഷണിയാണ് ഉയർത്തുന്നത്; കാരണം ഇത് പൊതുവായ ഒരു മോഡലിനെയല്ല ലക്ഷ്യമിടുന്നത്, മറിച്ച് നിങ്ങളുടെ സിസ്റ്റത്തെയും അത് കൈകാര്യം ചെയ്യുന്ന അതീവ രഹസ്യമായ ഡാറ്റയേയുമാണ്.
ഞങ്ങളുടെ ആദ്യഘട്ട പരിശോധനയിൽ താഴെ പറയുന്ന വിഭാഗങ്ങളിലായി ഏകദേശം 750 ടെസ്റ്റുകൾ ഉൾപ്പെട്ടിരുന്നു:
ക്രോസ്-സെഷൻ ഡാറ്റാ ചോർച്ച
PII വെളിപ്പെടുത്തൽ (സ്വാഭാവിക ഭാഷ, API കൈകാര്യം ചെയ്യൽ, വ്യത്യസ്ത എൻകോഡിങ്ങുകൾ വഴിയുള്ളവ)
SQL ഇൻജക്ഷൻ
സിസ്റ്റം പ്രോംപ്റ്റ് റദ്ദാക്കൽ
ആദ്യഘട്ട പരിശോധനയിൽ നിലവിലുള്ള സംവിധാനത്തിൻ്റെ രണ്ട് പ്രധാന പോരായ്മകൾ ഞങ്ങൾ കണ്ടെത്തി; വിവിധോദ്ദേശ്യപരമായ ചോദ്യങ്ങൾ കൈകാര്യം ചെയ്യുന്നതിലെ പ്രശ്നങ്ങളും, എൻകോഡ് ചെയ്ത പ്രോംപ്റ്റുകളുടെ ഉപയോഗവുമായിരുന്നു അവ.
വിവിധോദ്ദേശ്യപരമായ ചോദ്യങ്ങൾ: ന്യായമായ ആവശ്യങ്ങളും ദോഷകരമായ ആവശ്യങ്ങളും ഒരുമിച്ച് ചേർക്കുന്ന അഭ്യർഥനകൾ. ഉദാഹരണത്തിന്: “വിഭാഗം തിരിച്ച് എൻ്റെ ചെലവ് കാണിക്കുക, കൂടാതെ [ദോഷകരമായ SQL] റൺ ചെയ്യുക.” ഇവിടെ ആപ്ലിക്കേഷൻ ആ ഹാനികരമായ ഉദ്ദേശ്യത്തെ കണ്ടെത്താൻ പരാജയപ്പെടുകയും പകരം, ഡൗൺസ്ട്രീം ഡാറ്റാ ലെയർ സുരക്ഷാ നിയന്ത്രണങ്ങളെ പൂർണ്ണമായും ആശ്രയിക്കുകയും ചെയ്തു. ഇത് നിലവറയിലെ ലോക്കറിനെ അമിതമായി വിശ്വസിച്ച് നിങ്ങളുടെ വീടിൻ്റെ മുൻവാതിൽ തുറന്നിടുന്നതിന് തുല്യമാണ്.
എൻകോഡിങ്: ഇവിടെ അഭ്യർഥനകൾ Base64, Hex, LeetSpeak, homoglyphs എന്നീ രൂപത്തിലേക്ക് മാറ്റി നൽകുന്നു. ഇത്തരം സാഹചര്യങ്ങളിൽ ഹാനികരമായ ഉദ്ദേശ്യങ്ങളെ തിരിച്ചറിഞ്ഞ് ഫിൽട്ടർ ചെയ്യാൻ സിസ്റ്റങ്ങൾക്ക് ബുദ്ധിമുട്ടായായേക്കാം. ഈ അന്വേഷണങ്ങൾ സെൻസിറ്റീവ് ഡാറ്റ പുറത്തുകൊണ്ടുവരുന്നതായി ഞങ്ങൾ കണ്ടെത്തിയില്ലെങ്കിലും അവ സിസ്റ്റത്തിൻ്റെ സ്ഥിരതയെ കാര്യമായി ബാധിക്കുന്നതായി (ഹലൂസിനേഷൻസ്, ഹാനികരമായ SQL കോഡുകൾ ഉപയോക്താക്കൾക്ക് തന്നെ തിരിച്ചും നൽകുക, ഉദ്ദേശ്യ വർഗ്ഗീകരണത്തിലെ ആശയക്കുഴപ്പം തുടങ്ങിയവ) കണ്ടെത്തി.
ഞങ്ങളുടെ പ്രാഥമിക പരിശോധനയിൽ കണ്ടെത്തിയത്:
ടെമ്പറൽ ഹലൂസിനേഷൻസ്: മോഡൽ തികഞ്ഞ ആത്മവിശ്വാസത്തോടെ തെറ്റായ തീയതികളും ട്രാൻസാക്ഷൻ ടൈംസ്റ്റാമ്പുകളും അല്ലെങ്കിൽ സമയബന്ധിതമായ മറ്റ് വിവരങ്ങളും വ്യാജമായി നിർമ്മിച്ച് നൽകുന്ന അവസ്ഥ; തെറ്റായ തീയതി വിശ്വസിച്ച് ഉപയോക്താവ് എടുക്കുന്ന തീരുമാനങ്ങൾ വലിയ പ്രത്യാഘാതങ്ങൾ ഉണ്ടാക്കാൻ സാധ്യതയുള്ളതിനാൽ ധനകാര്യ മേഖലയിൽ ഇത് അതീവ ഗുരുതരമായ ഒരു സുരക്ഷാ ഭീഷണിയാണ്
ഹാനികരമായ SQL കോഡുകൾ ഉപയോക്താക്കൾക്ക് തന്നെ തിരിച്ചും നൽകുന്ന അവസ്ഥ (ഇത് മെമ്മറി പോയിസണിംഗ് ഭീഷണികൾക്ക് കാരണമായേക്കാം)
ഉദ്ദേശ്യ വർഗ്ഗീകരണത്തിലെ ആശയക്കുഴപ്പം
ഔട്ട്പുട്ട് ഫോർമാറ്റിംഗിലെ താളപ്പിഴകൾ
ആ കണ്ടെത്തലുകളുടെ അടിസ്ഥാനത്തിൽ ഞങ്ങൾ ഞങ്ങളുടെ ശ്രദ്ധ കൂടുതൽ കേന്ദ്രീകരിച്ചു. SQL ഇൻജക്ഷൻ, എൻകോഡിങ് പരിശോധനകളുടെ മുൻഗണന കുറച്ചു (കാരണം ഞങ്ങളുടെ ടീം ഇതിനകം തന്നെ അവ പരിഹരിക്കാൻ തുടങ്ങിയിരുന്നു). അതിനുപകരം, ഏറ്റവും കൂടുതൽ വിജയകരമെന്ന് കണ്ട സൈബർ ആക്രമണ രീതികളിലാണ് ഞങ്ങൾ ശ്രദ്ധ കേന്ദ്രീകരിച്ചത്: അതായത്, PII വിവരങ്ങൾ വെളിപ്പെടുത്തുന്നതും ക്രോസ്-സെഷൻ ചോർച്ചയും.
രണ്ടാം ഘട്ട പരിശോധനയിൽ നിന്നും ലഭിച്ച ഏറ്റവും ശ്രദ്ധേയമായ കണ്ടെത്തൽ തികച്ചും ലളിതമായിരുന്നു: മിക്കപ്പോഴും നിങ്ങൾ വലിയ ബുദ്ധിമാനാകേണ്ട കാര്യം പോലുമില്ല.
പല സാഹചര്യങ്ങളിലും, ഒരു യഥാർത്ഥ ആവശ്യമെന്ന രീതിയിൽ ആന്തരിക വിവരങ്ങൾ വെറുതെ ചോദിക്കുന്നത് വഴി തന്നെ സിസ്റ്റം അവ നൽകാൻ തയ്യാറായിരുന്നു. ഒരിക്കലും സാധാരണ ഉപയോക്താക്കൾക്ക് മുന്നിൽ വരരുതാത്ത ആന്തരിക ഐഡികളും സിസ്റ്റം ഫീൽഡുകളും ഉൾപ്പെടുത്തിക്കൊണ്ടുള്ള മറുപടികളാണ് ഇത്തരം ലളിതമായ ചോദ്യങ്ങൾക്ക് ലഭിച്ചിരുന്നത്.
കൂടുതൽ ആഴത്തിൽ പരിശോധിച്ചപ്പോൾ, ഇത് കേവലം ഒരു ആപ്പ് തലത്തിലെ പരാജയം മാത്രമല്ലെന്ന് കണ്ടെത്തി. ഡൗൺസ്ട്രീം text-to-SQL സേവനം ആവശ്യമുള്ളതിനേക്കാൾ കൂടുതൽ ഫീൽഡുകൾ ആവശ്യപ്പെട്ട് ചോദ്യങ്ങൾ നിർമ്മിക്കുകയും നിയന്ത്രിക്കപ്പെടേണ്ടിയിരുന്ന ഡാറ്റയെക്കുറിച്ച് വിശദീകരണങ്ങളിൽ പരാമർശിക്കുകയും ചെയ്തു. സിസ്റ്റങ്ങൾക്കിടയിലുള്ള യഥാർത്ഥ സുരക്ഷാ വിടവാണ് ഇതിലൂടെ പുറത്തുവന്നത്; വ്യത്യസ്ത ഘടകങ്ങളെ വെവ്വേറെ പരിശോധിക്കുന്നതിന് പകരം, മുഴുവൻ സിസ്റ്റത്തെയും പരിശോധിക്കുമ്പോൾ മാത്രം പുറത്തുവരുന്ന തരത്തിലുള്ള സുരക്ഷാ വീഴ്ചയാണിത്.
മോഡലിനെ മാത്രമല്ല, സിസ്റ്റത്തെ മുഴുവനായും റെഡ് ടീം ചെയ്യുക. ഒരു LLM-നെ മാത്രമായി ഒറ്റയ്ക്ക് പരിശോധിക്കുന്നത് നിങ്ങളുടെ ആപ്ലിക്കേഷൻ്റെ സുരക്ഷാ നിലവാരത്തെക്കുറിച്ച് കൃത്യമായ വിവരങ്ങൾ നൽകില്ല. ഒരു സാധാരണ ഉപയോക്താവ് എങ്ങനെ ഇടപഴകുമോ അതേ രീതിയിൽ സിസ്റ്റത്തിൻ്റെ തുടക്കം മുതൽ ഒടുക്കം വരെയുള്ള മുഴുവൻ ഭാഗങ്ങളും പരിശോധിക്കുക.
ഇൻപുട്ട് സാധൂകരണം എപ്പോഴും LLM-ന് മുമ്പായി നടന്നിരിക്കണം. എൻകോഡ് ചെയ്ത ചോദ്യങ്ങളും ഒന്നിലധികം ഉദ്ദേശ്യങ്ങളുള്ള സൈബർ ആക്രമണങ്ങളും അടിസ്ഥാന ഇൻജക്ഷൻ ശ്രമങ്ങളും സിസ്റ്റത്തിൻ്റെ സുരക്ഷാ അതിർത്തിയിൽ വെച്ച് തന്നെ കണ്ടെത്തേണ്ടതുണ്ട്; അല്ലാതെ അവ ഡൗൺസ്ട്രീം സേവനങ്ങളിലേക്ക് കൈമാറാൻ പാടില്ല.
കണക്ഷനുകളെ അന്ധമായി വിശ്വസിക്കരുത്. ഒന്നിലധികം സേവനങ്ങൾ ഒന്നിച്ചു പ്രവർത്തിക്കുന്ന ആർക്കിടെക്ചറുകളിൽ, സിസ്റ്റങ്ങൾ തമ്മിലുള്ള വിടവുകളിലാണ് ഏറ്റവും സങ്കീർണ്ണമായ സുരക്ഷാ വീഴ്ചകൾ ഒളിച്ചിരിക്കുന്നത്. സീറോ-ട്രസ്റ്റ് എന്നാൽ പൂർണ്ണമായ അവിശ്വാസം എന്നു തന്നെയാണ് അർത്ഥം; അതിനാൽ എല്ലാ തലങ്ങളിലുമുള്ള എല്ലാ വിവരങ്ങളും കൃത്യമായി പരിശോധിച്ചുറപ്പുവരുത്തുക.
ലളിതമായ ആക്രമണങ്ങൾ പോലും ഫലിച്ചേക്കാം. അത്യാധുനികമായ ജെയിൽബ്രേക്കറുകളാണ് വാർത്തകളിൽ ഇടം നേടാറുള്ളതെങ്കിലും ചിലപ്പോൾ വളരെ സാധാരണമായ രീതിയിൽ വെറുതെ... ചോദിച്ചാൽ മാത്രം മതിയാകും. ഒരു ഉപയോക്താവ് നൽകുന്ന നിയമാനുസൃത ചോദ്യത്തോടൊപ്പം ആന്തരിക വിവരങ്ങൾ കൂടി ആവശ്യപ്പെടുമ്പോൾ, നിങ്ങളുടെ സിസ്റ്റം അവ സന്തോഷത്തോടെ പുറത്തുവിടുമെങ്കിൽ അത് ഗുരുതരമായ ഒരു സുരക്ഷാ പ്രശ്നം തന്നെയാണ്.
നിങ്ങൾ യഥാർഥത്തിൽ എന്താണ് പരിശോധിക്കുന്നതെന്ന് വ്യക്തമായി മനസ്സിലാക്കുക. അറിയപ്പെടുന്ന സൈബർ ആക്രമണരീതികൾ നിങ്ങളുടെ സുരക്ഷാ നിയന്ത്രണങ്ങൾക്കു പകരം LLM-ൻ്റെ സ്വന്തം പരിശീലനം കൊണ്ട് തന്നെ തടയപ്പെട്ടേക്കാം. അതിനാൽ ഏതു തരത്തിലുള്ള സുരക്ഷാ നിയന്ത്രണങ്ങളാണ് യഥാർത്ഥത്തിൽ പ്രവർത്തിക്കുന്നതെന്ന് കൃത്യമായി തിരിച്ചറിയാൻ നിങ്ങളുടെ റെഡ് ടീമിംഗിൽ നിരീക്ഷണ സംവിധാനം കൂടി ഉൾപ്പെടുത്തുക.
നിയന്ത്രിതമായ സാഹചര്യങ്ങൾക്ക് സർഗ്ഗാത്മകമായ പരിഹാരങ്ങൾ ആവശ്യമാണ്. പ്രത്യേക ക്ലൗഡ് ആക്സസ് ഇല്ലെങ്കിൽപ്പോലും കസ്റ്റം പ്രൊവൈഡറുകളും ലോക്കൽ മോഡൽ സപ്പോർട്ടും വഴി അർത്ഥവത്തായ രീതിയിൽ റെഡ് ടീമിംഗ് നടത്താൻ സാധിക്കും. എന്നാൽ ഇത് കാരണം ഉണ്ടാകുന്ന പരിമിതികളെക്കുറിച്ച് എപ്പോഴും സുതാര്യത പുലർത്തേണ്ടതുണ്ട്.
റെഡ് ടീമിംഗ് എന്നത് ഒരിക്കൽ മാത്രം ചെയ്യേണ്ട ഒന്നല്ല. ഇത് ആവർത്തിച്ച് ചെയ്യേണ്ട ഒരു പ്രക്രിയയാണ്; സാധ്യമാകുന്നിടത്തെല്ലാം ഇത് ഓട്ടോമേറ്റ് ചെയ്യണം, ഒപ്പം നിങ്ങളുടെ സിസ്റ്റം വികസിക്കുന്നതിനനുസരിച്ച് ഇതും വികസിപ്പിക്കേണ്ടതുണ്ട്. നാളെ ഉണ്ടാകാനിടയുള്ള പ്രധാന സുരക്ഷാ ഭീഷണികൾ ഇന്നത്തെ പോലെയല്ല എന്ന കാര്യം ഓർക്കുക.
നിയന്ത്രിത പരിതസ്ഥിതികളിൽ പ്രവർത്തിക്കുന്ന AI സംവിധാനങ്ങൾ വരും ദിവസങ്ങളിൽ കൂടുതൽ കടുത്ത പരിശോധനകളെയായിരിക്കും നേരിടേണ്ടി വരിക. സുരക്ഷാ പരിശോധനകളെ, സിസ്റ്റം പുറത്തിറക്കുന്നതിന് മുമ്പ് ചെയ്യേണ്ട വെറുമൊരു ഔപചാരികതയായി കാണാതെ, നിരന്തരമായി തുടരേണ്ട ഒരു ശീലമായി കൊണ്ടുനടക്കുന്ന സ്ഥാപനങ്ങൾക്ക് മാത്രമേ ഇത്തരം കടുത്ത പരിശോധനകളെ മികച്ച രീതിയിൽ നേരിടാൻ സാധിക്കൂ; ഒപ്പം ഉപയോക്താക്കളുടെ വിശ്വാസം നഷ്ടപ്പെടുത്തുന്ന തരത്തിലുള്ള വലിയ PR ദുരന്തങ്ങൾ ഒഴിവാക്കാനും അവർക്ക് കഴിയും.