ઓપન સોર્સ દૂષિત પેકેજો સામે રક્ષણ: શું કામ કરે છે (નથી)

આ ત્રીજો એપિસોડ છે લેખોની શ્રેણી સૌથી પ્રચલિત પ્રકારના સોફ્ટવેર સપ્લાય ચેઇન હુમલાઓ વિશે: જે જાહેર રજિસ્ટ્રીનો દુરુપયોગ કરે છે ખુલ્લા સ્ત્રોત સોફ્ટવેર ઘટકો. પાછલા એપિસોડમાં વિશ્લેષણ કર્યા પછી “દૂષિત પેકેજોનું શરીરરચના: વલણો શું છે?"ખરાબ કલાકારો નવા અથવા હાલના પ્રકાશિત ઘટકોમાં દૂષિત વર્તન કેવી રીતે દાખલ કરે છે, અમે અમારા અગ્નિશામક જેકેટ્સ પહેરવા અને આ રીતે પહોંચાડાયેલા દૂષિત સોફ્ટવેરને સફળતાપૂર્વક કેવી રીતે અવરોધિત કરી શકીએ છીએ તેની તપાસ કરવા માટે તૈયાર છીએ, અથવા વૈકલ્પિક રીતે, સંભવિત ગંભીર સાયબર ઘટનાનો સામનો કેવી રીતે કરી શકીએ છીએ કારણ કે અમે ખોટો અભિગમ અપનાવ્યો હતો."

મોટાભાગના સુરક્ષા-જાગૃત વ્યાવસાયિકો પાસે આ ખતરાને કેવી રીતે હેન્ડલ કરવું તે અંગે વિચારો હોય છે. અમે સુરક્ષા મેનેજરોને ખચકાટ વિના કહેતા સાંભળ્યા છે કે SCA ટૂલ્સ તમને પહેલાથી જ કહે છે કે પેકેજ વર્ઝન ક્યારે માલવેર છે. અથવા તેઓ જાણીતા, ખૂબ જ સમીક્ષા કરાયેલા સોફ્ટવેર ઘટકો પર આધાર રાખે છે, જ્યાં કોઈપણ માલવેર તાત્કાલિક શોધી કાઢવામાં આવશે અને દૂર કરવામાં આવશે. તેઓ આપમેળે નબળાઈ સુધારાઓ મેળવવા માટે ઓપન માઇનોર/પેચ વર્ઝનનો ઉપયોગ કરે છે, અને તે ઓપન સોર્સ ડિપેન્ડન્સી પર જોખમ ઘટાડવાનો યોગ્ય, ભલામણ કરેલ રસ્તો છે, "વહેલા પેચ કરો, વારંવાર પેચ કરો”સિદ્ધાંત. 

આ એપિસોડમાં, આપણે સમીક્ષા કરીશું કે આ વિચારો શા માટે ખોટા છે, અને આવી ગેરમાન્યતાઓ આ હુમલાની પદ્ધતિની લોકપ્રિયતામાં અને સંગઠનો અનુભવી રહેલા ભારે જોખમમાં કેવી રીતે ફાળો આપી રહી છે. આપણે શું કામ કરે છે, અને તેમાં કયા પ્રયત્નો અને સંસાધનો સામેલ છે તે સાથે સમાપ્ત કરીશું.

સામાન્ય ગેરસમજો

સોફ્ટવેર સુરક્ષા સાથેની અમારી સફર દરમિયાન, અમે હુમલાની તકનીકોનો વિકાસ અને સુરક્ષા પ્રત્યે સભાન લોકોના વિચારોની વિશાળ શ્રેણી જોઈ. સંસ્થાઓ ઘણીવાર આ ખતરા સામે શું કામ કરે છે તે અંગે ગેરસમજ કરે છે, તેથી પહેલા આપણે તપાસ કરીશું કે શું કામ કરતું નથી, નીચેની સંપૂર્ણ ગેરસમજોની સૂચિમાં સંક્ષિપ્ત, નહીં.

ગેરસમજ #1: SCA સાધનો પહેલાથી જ દૂષિત ઘટકોની જાણ કરે છે

ખરેખર! પરંતુ હકીકત પછી… જ્યારે કદાચ સોફ્ટવેર બિલ્ડમાં તત્વનો ઉપયોગ કરવામાં આવ્યો હોય તો ખૂબ મોડું થઈ ગયું હોય, અને ખરાબ કલાકારોએ ડેવલપરમાં પગપેસારો કરી લીધો હોય અથવા CI/CD હોસ્ટ. રહસ્યો કાઢી નાખવામાં આવ્યા હશે, વધારાના માલવેર ડાઉનલોડ અને ઇન્સ્ટોલ કરવામાં આવ્યા હશે, અને કદાચ વિરોધી બાજુ તરફ ગયો હશે અને પહેલાથી જ બીજે ક્યાંક પ્રવેશ મેળવી લીધો હશે. 

સોફ્ટવેર કમ્પોઝિશન વિશ્લેષણ (SCA) ટૂલ્સ સંભવિત જાણીતી નબળાઈઓને ઓળખવા માટે ડિઝાઇન કરવામાં આવ્યા હતા. આધુનિક ટૂલ્સ સિગ્નલ-અવાજ ગુણોત્તરમાં વધારો કરીને, નબળાઈ ખરેખર પહોંચી શકાય તેવી છે કે શોષણ કરી શકાય તેવી છે તે નક્કી કરીને ઉત્તમ કાર્ય કરે છે. પરંતુ નવા માલવેર સામે તે નકામા છે. દૂષિત ઘટકને શૂન્ય-દિવસની નબળાઈ તરીકે વિચારો: જ્યારે તેનું દૂષિત વર્તન શોધી કાઢવામાં આવે છે, ત્યારે જ ઘટક હોલ્ડિંગ રજિસ્ટ્રીને જાણ કરવામાં આવે છે, જે સુરક્ષા ટીમ દ્વારા સમીક્ષા પછી દૂષિત તરીકે પુષ્ટિ થાય છે અને રજિસ્ટ્રીમાંથી દૂર કરવામાં આવે છે. [1]. 

તે સમયે, વિશ્વ (સહિત SCAs) જાણે છે કે ઘટક (અથવા હાલના ઘટકના કેટલાક સંસ્કરણો) ઇન્સ્ટોલ કરવું અથવા તેનો ઉપયોગ કરવો એ સારી બાબત નથી. પરંતુ આ ત્યારે થાય છે જ્યારે ઘટક રજિસ્ટ્રીમાંથી ઉપલબ્ધ ન હોય. એ જાણવું સારું છે કે મારી પાસે તૃતીય-પક્ષ ઘટકોમાં નબળાઈઓ છે, અથવા તો એવા ઘટકો પણ છે જેને રજિસ્ટ્રી દ્વારા દૂષિત તરીકે વર્ગીકૃત કરવામાં આવ્યા છે, પરંતુ કમનસીબે SCA અથવા સામાન્ય ઓડિટ સાધનો આ સંદર્ભમાં મદદ કરતા નથી. જ્યાં સુધી SCA/ઓડિટ ટૂલ ખરેખર અગાઉથી જાણી શકે છે કે કોઈ ઘટક તમારા સંગઠનમાં ઉપયોગમાં લેવાય તે પહેલાં તે દૂષિત છે..

યાદ રાખો, દૂષિત ઓપન-સોર્સ ઘટકો સામેના કોઈપણ ઉકેલમાં તેમને શોધવા આવશ્યક છે ઉડતી વખતે, જ્યારે ઘટક રજિસ્ટ્રીમાં પ્રકાશિત થાય છે અને જ્યારે ઘટક (સંસ્કરણ) તમારી સંસ્થામાં પ્રથમ વખત ઉપયોગમાં લેવાય છે તે વચ્ચે. અને તેમાં ટ્રાન્ઝિટિવ ઘટકોનો સમાવેશ થાય છે.  

ગેરસમજ #2: બિલ્ડ સમયે ઇન્સ્ટોલેશન સ્ક્રિપ્ટ્સને નિયંત્રિત કરવાથી ઓપન-સોર્સ ઘટકોમાંથી દૂષિત વર્તન અટકાવે છે.

વિવિધ પેકેજ મેનેજરો સ્ક્રિપ્ટો ચલાવવાની ક્ષમતા પ્રદાન કરે છે (ઘટક ટારબોલમાં સમાવિષ્ટ) [2]), કાયદેસર કારણોસર, જેમ કે વિવિધ પ્લેટફોર્મ પર જરૂરી વસ્તુઓનું સંકલન કરવું, કોડ જનરેટ કરવો અથવા પરીક્ષણો ચલાવવા, અને આપણે બધાએ જાણવું જોઈએ કે જો દૂષિત સ્ક્રિપ્ટો ટારબોલમાં શામેલ કરવામાં આવે, અથવા જો હુમલાખોર સારી સ્ક્રિપ્ટને બદલે દૂષિત સ્ક્રિપ્ટ ચલાવી શકે તો ખરાબ કલાકારો દ્વારા તેનો દુરુપયોગ થઈ શકે છે.

આ જાણીને, આપણે સ્ક્રિપ્ટોને અવગણવા માટે પેકેજ મેનેજરને ગોઠવી શકીએ છીએ. ઉદાહરણ તરીકે, NPM સાથે સ્ક્રિપ્ટોને અવગણો ધ્વજ (અથવા માં રૂપરેખાંકન ગુણધર્મ .npmrc ફાઇલ) ઇન્સ્ટોલેશન દરમિયાન સ્ક્રિપ્ટ્સને છોડી દે છે. આનાથી કેટલીક સમસ્યાઓ થઈ શકે છે કારણ કે ઘણી ઇકોસિસ્ટમ્સમાં સ્ક્રિપ્ટો ચલાવવી સામાન્ય છે: કેટલાક પેકેજ મેનેજરો સ્ક્રિપ્ટ એક્ઝેક્યુશનને અક્ષમ કરવાની પણ મંજૂરી આપતા નથી (સંકેત: પ્રોમ્પ્ટ “કયા પેકેજ મેનેજરો ઇન્સ્ટોલ સ્ક્રિપ્ટોના અમલીકરણને અક્ષમ કરવાની મંજૂરી આપતા નથી?"તમારા મનપસંદ AI માં"). પરંતુ આ સામાન્ય રીતે રક્ષણ આપતું નથી (આપણે સ્કીપ ડિસેબલ ગોઠવણી દરેક જગ્યાએ લાગુ કરવાની જરૂર છે). 

અને જ્યારે દૂષિત વર્તણૂક ઇન્સ્ટોલ સ્ક્રિપ્ટ્સમાં નહીં પરંતુ રનટાઇમ પર ચલાવવા માટેના સોફ્ટવેરમાં હોય છે, ત્યારે આ વિકલ્પ ફક્ત આપણને સુરક્ષિત રાખતો નથી. 

ગેરસમજ #3: વર્ઝન પિનિંગ દૂષિત ઘટકોને ઇન્સ્ટોલ થવાથી અટકાવે છે

વહેલા પેચિંગ અને વારંવાર પેચિંગ વચ્ચે એક સમજૂતી છે ખુલ્લા સંસ્કરણો (સુરક્ષા સુધારાઓ માટે ઉપલબ્ધ હોય ત્યારે પેકેજ મેનેજરને આપમેળે નવા અપડેટ્સ ઇન્સ્ટોલ કરવા દેવા) અને વર્ઝન પિનિંગ (એક નિશ્ચિત સંસ્કરણ પર સોફ્ટવેર માટે બધી સીધી અને સંક્રમિત અવલંબન ધરાવતા). સુરક્ષા સિદ્ધાંતો હઠીલા અને ક્યારેક વિરોધાભાસી છે, જેમ કે "પેચ વહેલા, પેચ વારંવાર" અને "અપગ્રેડિંગને હળવાશથી ન લેવું જોઈએ". કેટલાક પેકેજ મેનેજરો ભલામણ કરેલ રીતે સર્વર રેન્જ સાથે ઓટોમેટિક અપડેટ્સ બનાવે છે. જો તમે પણ દૂષિત અપડેટ્સ પ્રાપ્ત કરવા માંગતા હોવ તો સરસ! હા, શક્ય તેટલી વહેલી તકે નબળાઈઓને બંધ કરતી સુરક્ષા સુધારાઓ પ્રાપ્ત કરવા માટે ઘટકોને અપડેટ કરવા આવશ્યક છે, પરંતુ ... પેકેજ મેનેજરને ક્યારેય આ આપમેળે કરવા દો નહીં.

ગેરસમજ #૪: વિશ્વસનીય ઘટકોનો ઉપયોગ સલામત છે. કોઈપણ દૂષિત સંસ્કરણ તાત્કાલિક મળી આવશે, જાહેર કરવામાં આવશે અને દૂર કરવામાં આવશે.

કોઈ ઘટક પર શા માટે વિશ્વાસ કરવામાં આવે છે? કદાચ એટલા માટે કે તે ખૂબ જ લોકપ્રિય છે, ઘણા લોકો નબળાઈઓ શોધી રહ્યા છે, જાળવણી માટે મોટી સંખ્યામાં ફાળો આપનારાઓ છે, બહુવિધ મુખ્ય જાળવણીકારો છે જે ખંતપૂર્વક બધાની સમીક્ષા કરે છે. pull requests. વાસ્તવિકતા તદ્દન અલગ છે. કેટલાક આવશ્યક ઘટકો એક જ, ચૂકવણી ન કરતા ડેવલપર દ્વારા જાળવવામાં આવે છે. વ્યાપકપણે ઉપયોગમાં લેવાતા ફ્રેમવર્કમાં થોડા નિયમિત ફાળો આપનારાઓ, ઝડપથી ઘટતી સંખ્યા સાથે commitજાળવણીકર્તા દીઠ (લોકપ્રિય પ્રોજેક્ટ્સમાં ફાળો આપનારાઓની લાંબી પૂંછડી હોય છે જે કેટલાક ડ્રાઇવ-બાય કરે છે) commit અને ક્યારેય પાછા નહીં આવે). અને એક જ જાળવણીકાર સાથેના લોકપ્રિય પ્રોજેક્ટ્સ ભરપૂર છે.

કલ્પના કરો કે તમે કહો છો "ઓહ, અમે સ્પ્રિંગ બૂટ / એંગ્યુલર / રિએક્ટ / પાયટોર્ચ / ઓફિશિયલ બેઝ ડોકર ઈમેજીસનો ઉપયોગ કરી રહ્યા છીએ, તેથી તમે જે જોખમ વિશે વાત કરી રહ્યા છો તે ખૂબ ઓછું છે." કદાચ એ સાચું છે, આપણે સુરક્ષા વિક્રેતાઓ હંમેશા ડરાવતા રહીએ છીએ, અને ચર્ચાસ્પદ જોખમ ઘટાડવા માટે વિકાસ ટીમોમાં દખલ કરવી એ બકવાસ છે. તમે જોખમ સ્વીકૃતિ ફકરા (આગળના વિભાગમાં) પર જવા માટે લલચાઈ શકો છો અને બધું થઈ ગયું છે. કમનસીબે, સૌથી વધુ લોકપ્રિય ઘટકો ખરાબ અભિનેતાઓ માટે લક્ષ્ય છે, અને ઉદાહરણ તરીકે, લોકપ્રિય પાયટોર્ચ લાઇબ્રેરી પર હુમલો થયો હતો ભૂતકાળ માં.

"તાત્કાલિક મળી, જાહેર કરવામાં અને દૂર કરવામાં".  જાહેર રજિસ્ટ્રીમાંથી નવા દૂષિત ઘટકને દૂર કરવામાં દિવસો લાગે છે. રજિસ્ટ્રીઓ સારા માટે ઘટક સંસ્કરણને દૂર કરવામાં સાવચેત રહે છે. અમારો અનુભવ એ છે કે એકવાર અમારી તરફથી જાણ કરવામાં આવે પછી, અસરગ્રસ્ત સંસ્કરણને દૂર કરવા માટે રજિસ્ટ્રીનો સરેરાશ સમય 39 કલાક છે, દોઢ દિવસથી વધુ. એવા દૂષિત ઘટકો છે જે રજિસ્ટ્રીમાં અમારી પ્રારંભિક રિપોર્ટિંગ પછી દૂર કરતા પહેલા એક અઠવાડિયા હોય છે. અને કેટલાક કિસ્સાઓમાં, પીડિત અથવા ઘટના પ્રતિભાવ કંપની ઘટકને લગતી ઘટનાની જાણ કરે તે પછી જ ઘટક દૂર કરવામાં આવે છે. 

દૂષિત ઘટકો સામે શું કામ કરતું નથી

કોઈપણ અચોક્કસ અભિગમ ખરાબ રીતે નિષ્ફળ જશે. આ ચોક્કસ છે કે, તમે આ ખતરા સાથે સંકળાયેલા જોખમ માટે અસરકારક પ્રતિકારક પગલાં આપી રહ્યા નથી. 

પરંપરાગત SCA ટૂલ્સ તમને જાણીતા માલવેર વિશે જણાવે છે પરંતુ તેમની પાસે મોટી એક્સપોઝર વિન્ડો હોય છે. જ્યાં સુધી તેઓ દૂષિત ઘટકોને ફરજિયાત અવરોધિત કરીને માલવેર શોધ સક્રિય રીતે ન કરે, ત્યાં સુધી તેઓ આ ખતરા સામે કામ કરતા નથી. 

ઇન્સ્ટોલેશન સ્ક્રિપ્ટોને અક્ષમ કરવાથી મદદ મળી શકે છે, પરંતુ જ્યાં પણ ઘટક ઇન્સ્ટોલ કરવાની જરૂર હોય ત્યાં તેને લાગુ કરવાની જરૂર છે. વર્ઝન પિનિંગ સાથે પણ એવું જ છે, કારણ કે વર્ઝનને સુરક્ષિત પ્રારંભિક સ્થિતિમાંથી કાયમ માટે પિન કરી શકાતા નથી.

એવું માની લેવું કે લોકપ્રિય ઘટકો પર પૂરતું ધ્યાન આપવામાં આવે છે કે સપ્લાય ચેઇન હુમલામાં કોઈપણ નુકસાનને રોકવા માટે લગભગ તાત્કાલિક શોધ કર્યા વિના તેમને અણધાર્યા વર્તનથી ઇન્જેક્ટ કરી શકાતા નથી, તે નિષ્કપટ અને જોખમી છે. તમે ધાર પર રહેવા માંગતા નથી, ખરું ને?

જો તમે આ બિંદુએ રોકાઈ જાઓ છો, તો પછી જોખમ સ્વીકૃતિ તમે ફક્ત આ જ કરી શકો છો: આ એક ડી છેcisજોખમ સ્વીકારવાના તર્ક અને તેના સંભવિત પરિણામો સહિત, તમારા ધમકી મોડેલ/જોખમ મૂલ્યાંકનમાં દસ્તાવેજીકરણ કરવાની જરૂર છે. મેનેજમેન્ટ અને અન્ય સંબંધિત પક્ષોને તેની જાણ કરીને જાગૃતિ ફેલાવો. કેટલાક આકસ્મિક જ્યારે તમારા સોફ્ટવેરમાં કોઈ દૂષિત ઘટક ઇન્સ્ટોલ કરવામાં આવે અથવા તેનો સમાવેશ થાય ત્યારે તેનું આયોજન કરી શકાય છે, પરંતુ આ મુશ્કેલ છે કારણ કે હુમલાખોરો પાસે ઘણા રસ્તાઓ અનુસરવા પડે છે. દૂષિત ઘટકના ઉપયોગ પર આધારિત સપ્લાય ચેઇન હુમલાની વિગતો ઘટનાના જાહેર ખુલાસામાં ધરખમ ફેરફાર કરશે, જે કદાચ તમારી સંસ્થાના નિયમનકારી માળખા હેઠળ ફરજિયાત છે. તમે આ મુદ્દાને પણ સંબોધી શકો છો વળતર નિયંત્રણો or ટ્રાન્સફર જોખમ દા.ત. વીમા સાથે.

જોકે, એવા નિયંત્રણો છે જે જોખમને સંબોધિત કરે છે અને જો તમે જોખમ સ્વીકૃતિથી સંતુષ્ટ ન હોવ તો તેનો વિચાર કરવો જોઈએ. કૃપા કરીને આગળ વાંચો.

દૂષિત ઘટકોનો ઉપયોગ કરીને હુમલાઓ સામે શું કામ કરે છે?

સોલિડ વર્ઝન હેન્ડલિંગ

નિયંત્રિત અને માહિતીપ્રદ વર્ઝન બમ્પ્સ સાથે વર્ઝન પિનિંગ એ માલવેર પ્રાપ્ત કર્યા વિના નબળાઈઓને દૂર કરવાની જરૂરિયાતને સંતુલિત કરવાનો માર્ગ છે. પરંતુ ગેરસમજ #3 યાદ રાખો: ફક્ત વર્ઝન પિનિંગ નવા સંસ્કરણોમાંથી આવતા દૂષિત કોડને અવરોધિત કરવા માટે પૂરતું નથી, કારણ કે તમારે ભવિષ્યમાં કોઈપણ પ્રત્યક્ષ કે પરોક્ષ નિર્ભરતામાં વર્ઝન અપડેટ કરવાની જરૂર પડશે. તે ક્ષણે તમારે એટલા મજબૂત પુરાવાની જરૂર છે કે બધા સંશોધિત સંસ્કરણોમાં માલવેર નથી.

પ્રારંભિક ચેતવણી

દૂષિત ઘટકોની સમસ્યાનો એક અભિગમ પ્રારંભિક ચેતવણી પ્રણાલી છે (અહીં નામ આપવામાં આવ્યું છે માલવેરની વહેલી ચેતવણી અથવા MEW), જ્યાં પ્રકાશિત થયેલા નવા સંસ્કરણો (નવા અથવા હાલના ઘટકો માટે) નું વિશ્લેષણ શોધ એન્જિન દ્વારા કરવામાં આવે છે, જે જ્યારે પૂરતા પુરાવા મળે છે ત્યારે નવા સંસ્કરણને સંભવિત દૂષિત તરીકે વર્ગીકૃત કરી શકે છે. 

અહીં ઓટોમેશન આવશ્યક છે, કારણ કે વર્તમાન પ્રકાશન દરે બધા નવા ઘટકોની મેન્યુઅલી સમીક્ષા કરવી અશક્ય છે. તેથી શોધ એન્જિનને વિવિધ તકનીકોને જોડવાની જરૂર છે, જેમાં કદાચ સ્ટેટિક, ડાયનેમિક અને ક્ષમતા વિશ્લેષણ, વપરાશકર્તા પ્રતિષ્ઠા અને ઘટક મેટાડેટા અને ટારબોલ સામગ્રી વચ્ચે અથવા ટારબોલ અને સ્ત્રોત ભંડાર વચ્ચેની વિસંગતતાઓમાંથી આવતા પુરાવાનો સમાવેશ થાય છે જ્યાં ઘટક માનવામાં આવે છે.

ત્યાં છે ડાર્ક ઝોન પ્રકાશન સમય અને એન્જિન ઘટક સામગ્રીનું વિશ્લેષણ કરે તે વચ્ચેનો સમય, પરંતુ તે થોડી મિનિટોથી વધુ ન હોવો જોઈએ. આ યોજનામાં ફેરફાર કરી શકાય છે, ઉદાહરણ તરીકે, નવા ઘટકોનું વિશ્લેષણ થાય ત્યાં સુધી રાહ જોઈને તેમને ઇન્સ્ટોલ કરવાની અને સોફ્ટવેર બિલ્ડમાં ઉપયોગ કરવાની મંજૂરી આપીને. pipelines, અથવા જરૂર પડે ત્યારે માંગ પર તેનું વિશ્લેષણ કરો. આપેલ સંસ્કરણ પરનો ઘટક અપરિવર્તનશીલ છે [3], તેથી તેનું વિશ્લેષણ ફક્ત એક જ વાર કરવાની જરૂર છે.