ეს მესამე ეპიზოდია სტატიების სერია პროგრამული უზრუნველყოფის მიწოდების ჯაჭვის ყველაზე გავრცელებული ტიპის შეტევების შესახებ: ისინი, რომლებიც ბოროტად იყენებენ საჯარო რეესტრს ღია პროგრამული კომპონენტები. წინა ეპიზოდში ანალიზის შემდეგმავნე პაკეტების ანატომია: რა ტენდენციებია?„იმის გათვალისწინებით, თუ როგორ ნერგავენ ბოროტი აქტორები მავნე ქცევას ახალ ან არსებულ გამოქვეყნებულ კომპონენტებში, ჩვენ მზად ვართ ჩავიცვათ ხანძარსაწინააღმდეგო ჟილეტები და შევისწავლოთ, თუ როგორ შეგვიძლია წარმატებით დავბლოკოთ ამ გზით მოწოდებული მავნე პროგრამული უზრუნველყოფა, ან, ალტერნატიულად, გავუმკლავდეთ პოტენციურად სერიოზულ კიბერინციდენტს, რადგან არასწორი მიდგომა ავირჩიეთ.“
უსაფრთხოების შესახებ ინფორმირებული სპეციალისტების უმეტესობას აქვს წარმოდგენა, თუ როგორ გაუმკლავდეს ამ საფრთხეს. ჩვენ გვსმენია, რომ უსაფრთხოების მენეჯერები ყოყმანის გარეშე ამბობდნენ, რომ SCA ინსტრუმენტები უკვე გეუბნებიან, როდის არის პაკეტის ვერსია მავნე პროგრამა. ან რომ ისინი დამოკიდებულნი არიან ცნობილ, მაღალრეიტინგულ პროგრამულ კომპონენტებზე, სადაც ნებისმიერი მავნე პროგრამა სწრაფად აღმოჩენილი და წაშლილი იქნება. ისინი იყენებენ ღია მცირე/პატჩ ვერსიებს დაუცველობის ავტომატურად გამოსასწორებლად და ეს არის სწორი, რეკომენდებული გზა ღია კოდის დამოკიდებულებების რისკის შესამცირებლად, შემდეგი წესების დაცვით:ადრეული პლასტირი, ხშირად პლასტირი”პრინციპი.
ამ ეპიზოდში განვიხილავთ, თუ რატომ არის ეს იდეები არასწორი და როგორ უწყობს ხელს ასეთი მცდარი წარმოდგენები ამ შეტევის მექანიზმის პოპულარობას და ორგანიზაციების წინაშე არსებულ უზარმაზარ რისკს. დასასრულს, განვიხილავთ, თუ რა მუშაობს და რა არის ჩართული ძალისხმევა და რესურსები.
გავრცელებული მცდარი წარმოდგენები
პროგრამული უზრუნველყოფის უსაფრთხოების სფეროში ჩვენი მოგზაურობისას, ჩვენ ვნახეთ თავდასხმის ტექნიკის ევოლუცია და უსაფრთხოების შესახებ ცნობისმოყვარე ადამიანების იდეების ფართო სპექტრი. ორგანიზაციები ხშირად არასწორად ესმით, თუ რა მუშაობს ამ საფრთხის წინააღმდეგ, ამიტომ პირველ რიგში განვიხილავთ, თუ რა არ მუშაობს, რაც ქვემოთ, არასრულყოფილ, მცდარი წარმოდგენების სიაშია შეჯამებული.
მცდარი წარმოდგენა #1: SCA ინსტრუმენტები უკვე აფიქსირებენ მავნე კომპონენტებს
მართლაც! მაგრამ ფაქტის შემდეგ... როდესაც, სავარაუდოდ, უკვე გვიანია, თუ ელემენტი გამოყენებული იყო პროგრამული უზრუნველყოფის აწყობაში და ბოროტმოქმედმა პირებმა უკვე მოიპოვეს პოზიცია დეველოპერში ან CI/CD ჰოსტი. შესაძლოა, საიდუმლოებები ამოღებულიყო, დამატებითი მავნე პროგრამები გადმოწერილი და დაინსტალირებულიყო და შესაძლოა, მოწინააღმდეგემ გვერდითი მიმართულებით გადაინაცვლა და სხვაგან უკვე მოიპოვა წვდომა.
პროგრამული უზრუნველყოფის შემადგენლობის ანალიზი (SCA) ინსტრუმენტები შექმნილია პოტენციურად ცნობილი დაუცველობების იდენტიფიცირებისთვის. თანამედროვე ინსტრუმენტები შესანიშნავად ასრულებენ სამუშაოს სიგნალ-ხმაურის თანაფარდობის გაზრდით, რაც განსაზღვრავს, არის თუ არა დაუცველობა რეალურად ხელმისაწვდომი ან ექსპლუატაციადი. თუმცა, ისინი უსარგებლოა ახალი მავნე პროგრამების წინააღმდეგ. წარმოიდგინეთ მავნე კომპონენტი, როგორც ნულოვანი დღის დაუცველობა: მხოლოდ მაშინ, როდესაც მისი მავნე ქცევა აღმოჩენილია, კომპონენტი იტყობინება შენახვის რეესტრს, რომელიც უსაფრთხოების ჯგუფის მიერ განხილვის შემდეგ დადასტურებულია, როგორც მავნე და ამოღებულია რეესტრიდან. [1].
ამ დროს, მსოფლიო (მათ შორის SCAs) იცის, რომ კომპონენტის (ან არსებული კომპონენტის ზოგიერთი ვერსიის) ინსტალაცია ან გამოყენება არ არის კარგი. თუმცა, ეს მაშინ ხდება, როდესაც კომპონენტი რეესტრიდან მიუწვდომელია.კარგია იმის ცოდნა, რომ მესამე მხარის კომპონენტებში ან თუნდაც იმ კომპონენტებში, რომლებიც რეესტრის მიერ მავნედ იყო კლასიფიცირებული, რომ დაუცველები ვარ, მაგრამ სამწუხაროდ SCA ან საერთო აუდიტის ინსტრუმენტები ამ კონტექსტში არ დაგვეხმარება. თუ ეს არ არის SCA/audit ინსტრუმენტს შეუძლია წინასწარ იცოდეს, რომ კომპონენტი მავნეა, სანამ ის თქვენს ორგანიზაციაში გამოყენებული იქნება..
გახსოვდეთ, რომ მავნე ღია კოდის კომპონენტების წინააღმდეგ ნებისმიერმა გადაწყვეტამ ისინი უნდა აღმოაჩინოს. ფრენის დროს, კომპონენტის რეესტრში გამოქვეყნებისა და თქვენს ორგანიზაციაში მისი პირველად გამოყენების დროის შუალედში. ეს მოიცავს გარდამავალ კომპონენტებსაც.
მცდარი წარმოდგენა #2: ინსტალაციის სკრიპტების კონტროლი შექმნის დროს ხელს უშლის ღია კოდის კომპონენტების მავნე ქცევას
სხვადასხვა პაკეტის მენეჯერი გთავაზობთ სკრიპტების გაშვების შესაძლებლობას (შედის კომპონენტის tarball-ში) [2]), ლეგიტიმური მიზეზების გამო, როგორიცაა სხვადასხვა პლატფორმაზე საჭირო ელემენტების კომპილაცია, კოდის გენერირება ან ტესტების გაშვება და ყველამ უნდა ვიცოდეთ, რომ მათი ბოროტად გამოყენება შეიძლება მავნე აქტორების მიერ, თუ tarball-ში შედის მავნე სკრიპტები, ან თუ თავდამსხმელს შეუძლია კარგი სკრიპტის ნაცვლად მავნე სკრიპტის გაშვება.
ამის ცოდნით, ჩვენ შეგვიძლია პაკეტების მენეჯერის კონფიგურაცია ისე, რომ უგულებელვყოთ სკრიპტები. მაგალითად, NPM-ის შემთხვევაში –იგნორირების სკრიპტები დროშა (ან კონფიგურაციის თვისება .npmrc ფაილი) ინსტალაციის დროს სკრიპტებს გამოტოვებს. ამან შეიძლება გარკვეული პრობლემები შექმნას, რადგან სკრიპტების გაშვება მრავალ ეკოსისტემაში ხშირია: ზოგიერთი პაკეტის მენეჯერი სკრიპტის შესრულების გამორთვის უფლებასაც კი არ იძლევა (მინიშნება: მოთხოვნა „რომელი პაკეტის მენეჯერები არ იძლევიან ინსტალაციის სკრიპტების შესრულების გამორთვის საშუალებას?„თქვენს საყვარელ ხელოვნურ ინტელექტში). თუმცა, ეს ზოგადად არ იცავს (ჩვენ უნდა დავარწმუნოთ, რომ გამოტოვების გამორთვის კონფიგურაცია ყველგან არის).
და როდესაც მავნე ქცევა არა ინსტალაციის სკრიპტებში, არამედ გაშვების დროს შესასრულებელ პროგრამულ უზრუნველყოფაშია, მხოლოდ ეს ვარიანტი არ გვიცავს.
მცდარი წარმოდგენა #3: ვერსიის დამაგრება ხელს უშლის მავნე კომპონენტების ინსტალაციას
არსებობს კომპრომისი ადრეულ და ხშირ პატჩებს შორის. ღია ვერსიები (პაკეტების მენეჯერისთვის უსაფრთხოების შესწორებების შემთხვევაში ახალი განახლებების ავტომატურად ინსტალაციის უფლების მიცემა) და ვერსიის დამაგრება (პროგრამული უზრუნველყოფის ყველა პირდაპირი და გარდამავალი დამოკიდებულების ქონა ფიქსირებულ ვერსიაში). უსაფრთხოების პრინციპები ჯიუტი და ზოგჯერ წინააღმდეგობრივია, როგორც ეს ხდება „ადრეული პატჩი, ხშირად პატჩი“-ს შემთხვევაში და „განახლებას მსუბუქად არ უნდა მივუდგეთ“ზოგიერთი პაკეტის მენეჯერი ავტომატურად განახლებებს სერვერის დიაპაზონებით, რეკომენდებული გზით ახორციელებს. შესანიშნავია, თუ თქვენც გსურთ მავნე განახლებების მიღება! დიახ, კომპონენტები უნდა განახლდეს უსაფრთხოების შესწორებების მისაღებად, რომლებიც რაც შეიძლება მალე აღმოფხვრის დაუცველობებს, მაგრამ... არასოდეს მისცეთ პაკეტის მენეჯერს ამის ავტომატურად გაკეთების უფლება.
მცდარი წარმოდგენა #4: სანდო კომპონენტების გამოყენება უსაფრთხოა. ნებისმიერი მავნე ვერსია დაუყოვნებლივ მოიძებნება, გამოვლინდება და წაიშლება.
რატომ არის კომპონენტი სანდო? შესაძლოა იმიტომ, რომ ის ძალიან პოპულარულია, ბევრი ეძებს დაუცველობებს, დიდი რაოდენობით კონტრიბუტორი ჰყავს მოვლა-პატრონობისთვის და მრავალი ძირითადი შემკეთებელი, რომლებიც გულმოდგინედ ამოწმებენ ყველაფერს. pull requestsრეალობა საკმაოდ განსხვავებულია. ზოგიერთ აუცილებელ კომპონენტს ერთი, ანაზღაურების გარეშე დეველოპერი ინარჩუნებს. ფართოდ გამოყენებულ ჩარჩოებს აქვთ რამდენიმე რეგულარული კონტრიბუტორი, სწრაფად შემცირებული რაოდენობით commits თითო მომხმარებლად (პოპულარულ პროექტებს ჰყავთ კონტრიბუტორების გრძელი ჯგუფი, რომლებიც ასრულებენ გარკვეულ დრაივ-ბაი-ს) commit და აღარასდროს დაბრუნდები). და ერთი მომვლელით პოპულარული პროექტები უხვადაა.
წარმოიდგინეთ, რომ ამბობთ „ოჰ, ჩვენ ვიყენებთ Spring Boot / Angular / React / PyTorch / ოფიციალურ Docker-ის სურათებს, ამიტომ რისკი, რომელზეც თქვენ საუბრობთ, საკმაოდ დაბალია.“ შესაძლოა, ეს სიმართლეა, ჩვენ, უსაფრთხოების მომწოდებლები, მუდმივად ვშიშობთ და ვვერთებით განვითარების გუნდებს საკამათო რისკის შესამცირებლად, ეს სისულელეა. შესაძლოა, ცდუნებას აჰყვეთ და გადახვიდეთ რისკის მიღების აბზაცზე (შემდეგ ნაწილში) და ყველაფერი დამთავრდეს. სამწუხაროდ, ყველაზე პოპულარული კომპონენტები ცუდი აქტორების სამიზნეა და, მაგალითად, პოპულარული PyTorch-ის ბიბლიოთეკას თავს დაესხნენ. წარსულში.
„დაუყოვნებლივ აღმოჩენილი, გამჟღავნებული და ამოღებული“. საჯარო რეესტრიდან ახალი მავნე კომპონენტის ამოღებას დღეები სჭირდება. რეესტრები სიფრთხილით ეკიდებიან კომპონენტის ვერსიის წაშლას, თუმცა ეს ყველაფერი სასიკეთოდ ხდება. ჩვენი გამოცდილებით, ჩვენი მხრიდან შეტყობინების შემდეგ, რეესტრს დაზარალებული ვერსიის წასაშლელად საშუალო დრო 39 საათი სჭირდება, რაც დღე-ნახევარზე მეტია. არსებობს მავნე კომპონენტები, რომელთა ამოღებამდე ერთი კვირა რჩება რეესტრში ჩვენი საწყისი შეტყობინების შეტანიდან. ზოგიერთ შემთხვევაში, კომპონენტი იშლება მხოლოდ მას შემდეგ, რაც დაზარალებული ან ინციდენტებზე რეაგირების კომპანია შეატყობინებს კომპონენტთან დაკავშირებულ ინციდენტს.
რა არ მუშაობს მავნე კომპონენტების წინააღმდეგ
ნებისმიერი არასპეციფიკური მიდგომა სავალალოდ ჩავარდება. ეს დანამდვილებით შეიძლება ითქვას, რომ თქვენ არ იღებთ ეფექტურ საპასუხო ზომებს ამ საფრთხესთან დაკავშირებული რისკის წინააღმდეგ.
ტრადიციული SCA ინსტრუმენტები გაწვდით ინფორმაციას ცნობილი მავნე პროგრამების შესახებ, მაგრამ აქვთ დიდი ექსპოზიციის ფანჯარა. თუ ისინი პროაქტიულად არ ახორციელებენ მავნე პროგრამების აღმოჩენას მავნე კომპონენტების იძულებითი დაბლოკვით, ისინი არ მუშაობენ ამ საფრთხის წინააღმდეგ.
ინსტალაციის სკრიპტების გამორთვა შეიძლება დაგეხმაროთ, მაგრამ ის ყველგან უნდა იყოს ამოქმედებული, სადაც კომპონენტის ინსტალაციაა საჭირო. იგივე ეხება ვერსიის დამაგრებას, რადგან ვერსიების უსაფრთხო საწყისი მდგომარეობიდან სამუდამოდ დამაგრება შეუძლებელია.
იმის დაშვება, რომ პოპულარული კომპონენტები საკმარის ყურადღებას იპყრობენ, რომ მათზე არასასურველი ქცევა არ შეიძლება განვითარდეს მიწოდების ჯაჭვის შეტევის დროს თითქმის მყისიერი აღმოჩენის გარეშე, რათა თავიდან იქნას აცილებული ნებისმიერი ზიანი, გულუბრყვილო და სარისკოა. არ გინდათ ზღვარზე ცხოვრება, არა?
თუ ამ ეტაპზე გაჩერდებით, მაშინ რისკის მიღება ერთადერთი, რისი გაკეთებაც შეგიძლიათ: ეს დეcisინფორმაცია, რომელიც უნდა იყოს დოკუმენტირებული თქვენს საფრთხის მოდელში/რისკის შეფასებაში, მათ შორის რისკის მიღების დასაბუთება და მისი პოტენციური შედეგები. ცნობიერების ამაღლება მენეჯმენტისა და სხვა შესაბამისი მხარეებისთვის ამის შესახებ ინფორმაციის მიწოდებით. ზოგიერთი კონტიგენტი შეიძლება დაიგეგმოს, როდესაც თქვენს პროგრამულ უზრუნველყოფაში დაინსტალირდება ან შედის მავნე კომპონენტი, მაგრამ ეს რთულია, რადგან თავდამსხმელებს მრავალი გზა აქვთ გასავლელი. მავნე კომპონენტის გამოყენებაზე დაფუძნებული მიწოდების ჯაჭვის შეტევის დეტალები მკვეთრად შეცვლის ინციდენტის საჯაროდ გამჟღავნებას, რაც, სავარაუდოდ, სავალდებულოა თქვენი ორგანიზაციის მარეგულირებელი ჩარჩოს მიხედვით. თქვენ ასევე შეგიძლიათ მიმართოთ კომპენსაციის კონტროლი or გადაცემის რისკი მაგ. დაზღვევით.
თუმცა, არსებობს კონტროლის მექანიზმები, რომლებიც საფრთხეს უპასუხებენ და გასათვალისწინებელია, თუ რისკის მიღებით კმაყოფილი არ ხართ. გთხოვთ, განაგრძოთ კითხვა.
რა მუშაობს მავნე კომპონენტების გამოყენებით თავდასხმების წინააღმდეგ
მყარი ვერსიის დამუშავება
ვერსიის კონტროლირებადი და ინფორმირებული ცვლილებებით დამაგრება საუკეთესო გზაა, რათა დაბალანსდეს დაუცველობების მოხსნის აუცილებლობა მავნე პროგრამების მიღების გარეშე. თუმცა, გახსოვდეთ მცდარი წარმოდგენა #3: მხოლოდ ვერსიის დამაგრება საკმარისი არ არის ახალი ვერსიებიდან მომავალი მავნე კოდის დასაბლოკად, რადგან მომავალში დაგჭირდებათ ვერსიების განახლება ნებისმიერი პირდაპირი ან ირიბი დამოკიდებულების შემთხვევაში. ამ მომენტში გჭირდებათ საკმარისად ძლიერი მტკიცებულება, რომ ყველა შეცვლილი ვერსია არ შეიცავს მავნე პროგრამას.
Დროული გაფრთხილება
მავნე კომპონენტების პრობლემის მოგვარების ერთ-ერთი მიდგომაა ადრეული გაფრთხილების სისტემა (აქ დასახელებულია, როგორც მავნე პროგრამების ადრეული გაფრთხილება ან MEW), სადაც გამოქვეყნებული ახალი ვერსიები (ახალი ან არსებული კომპონენტებისთვის) გაანალიზებულია დეტექციის სისტემის მიერ, რომელმაც საკმარისი მტკიცებულებების აღმოჩენის შემთხვევაში შეიძლება ახალი ვერსია კლასიფიცირდეს, როგორც პოტენციურად მავნე.
ავტომატიზაცია აქ აუცილებელია, რადგან შეუძლებელია ყველა ახალი კომპონენტის ხელით გადახედვა მიმდინარე გამოქვეყნების სიჩქარით. ამიტომ, აღმოჩენის სისტემამ უნდა გააერთიანოს სხვადასხვა ტექნიკა, შესაძლოა, მათ შორის სტატიკური, დინამიური და შესაძლებლობების ანალიზი, მომხმარებლის რეპუტაცია და მტკიცებულებები, რომლებიც გამომდინარეობს კომპონენტის მეტამონაცემებსა და tarball-ის შინაარსს შორის შეუსაბამობებიდან, ან tarball-სა და წყაროს საცავს შორის, საიდანაც, სავარაუდოდ, კომპონენტი მოდის.
არსებობს ბნელი ზონა გამოქვეყნების დროსა და კომპონენტის შინაარსის ძრავის მიერ ანალიზის პერიოდს შორის, თუმცა ეს არ უნდა აღემატებოდეს რამდენიმე წუთს. სქემის შეცვლა შესაძლებელია, მაგალითად, ახალი კომპონენტების ანალიზის დალოდებით, სანამ მათ ინსტალაციას და პროგრამული უზრუნველყოფის აწყობაში გამოყენებას დაუშვებთ. pipelines, ან საჭიროების შემთხვევაში მათი მოთხოვნისამებრ ანალიზი. მოცემულ ვერსიაში კომპონენტი უცვლელია. [3], ამიტომ მისი ანალიზი მხოლოდ ერთხელ არის საჭირო.
სრული ავტომატიზაცია შეუძლებელია და საჭიროა უსაფრთხოების შემოწმება პოტენციურად მავნე კომპონენტების აღმოსაჩენად. უფრთხილდით ციფრული პანაცეის მომხრეებსხელოვნური ინტელექტი და მანქანური სწავლება საკმარისად განვითარებული არ არის, რომ საბოლოო სიტყვა თქვან საეჭვო კომპონენტში მავნე პროგრამის არსებობის დადასტურებისას. რა თქმა უნდა, მანქანური სწავლება მნიშვნელოვან როლს ასრულებს აღმოჩენის სისტემაში შემავალი კომპონენტის კლასიფიკაციაში შეგროვებული ნედლი მტკიცებულებებიდან, მაგრამ მას შემდეგ, რაც კომპონენტი „კარანტინში მოექცევა“, საბოლოო სიტყვა ეკისრება მავნე კომპონენტებთან მუშაობის გამოცდილების მქონე უსაფრთხოების გუნდის მიერ ხელით განხილვას. ეს ადასტურებს ნებისმიერ პოტენციურ მავნე პროგრამას ან ხელახლა კლასიფიკაციას უკეთებს მას, როგორც უსაფრთხოს. დროის დიაპაზონი კი საათების დიაპაზონია.
რეესტრი აგზავნის შეტყობინებას მავნე ვერსიის/კომპონენტის შესახებ; შემდეგ რეესტრი ახორციელებს თავის მიმოხილვას დასადასტურებლად და ახორციელებს საჯარო გამჟღავნებას და რეესტრიდან ამოღებას. ზოგიერთი რეესტრი ინახავს უსაფრთხოების შენახვის პაკეტს. აქ დროის დიაპაზონი არის გამოქვეყნებიდან დღეები ან კვირები, რაც არის „დრო იცხოვრე'ან'ექსპოზიციის ფანჯარა' მავნე კომპონენტების უმეტესობისთვის.
შესაძლებელია თუ არა იმის გაგება, არის თუ არა კომპონენტის ვერსია მავნე?
ასე რომ, ადრეული გაფრთხილებისთვის, ჩვენ უნდა გავცეთ დამაკმაყოფილებელი პასუხი ამ კითხვას: როგორ შემიძლია გავიგო, რომ ბიბლიოთეკა ან პაკეტი (არ) არის მავნე? როგორ შევაგროვო საკმარისი მტკიცებულება მავნე ქცევის შესახებ? შესაძლებელია, მაგრამ რთულია, რადგან მოწინააღმდეგეები დიდ გამომგონებლობას იყენებენ აღმოჩენის თავიდან ასაცილებლად. არსებობს სხვადასხვა მიდგომა, თითოეულს თავისი დადებითი და უარყოფითი მხარეები.
სტატიკური ანალიზი შეუძლია შეამოწმოს ყველა შესრულების გზა, შეამოწმოს თავდამსხმელების მიერ გამოყენებული ტექნიკა კომპონენტის გაშვების გარეშე და შეასრულოს წინასწარი დამუშავების ამოცანები, როგორიცაა დეზორიენტაცია ან გაშიფვრა. როდესაც თავდამსხმელები ცდილობენ დამალონ თავიანთი ზიანი, ზუზუნის მცდელობები მართლაც მავნე პროგრამის მტკიცებულებაა (თუმცა გაითვალისწინეთ, რომ ლეგიტიმური კომპონენტები აფერხებენ კოდს ინტელექტუალური საკუთრების შესანარჩუნებლად, რაც ეწინააღმდეგება „ღია წყაროებიდან„“). მხოლოდ უმცირესობაშია ძლიერი დაბნეულობის მქონე, მაღალტექნოლოგიური შეტევები, რომლებიც „სენდბოქსინგს“ საჭიროებენ, თუმცა ასეთი ძლიერი დაბნეულობა მავნე მოქმედების ნიშანია. გაითვალისწინეთ, რომ ტრადიციული SAST ინსტრუმენტები შექმნილი იყო უნებლიე დაუცველობებისთვის და არა მავნე განზრახვისთვის, როგორიცაა „უკანა კარები“.
დინამიური ანალიზი კომპონენტს ამუშავებს და ამოწმებს პასუხს გაშვების დროის ინსტრუმენტული დამუშავებით, როგორც წესი, sandboxed გარემოს უზრუნველყოფით. გარკვეულ პირობებში გამოწვეული მავნე ქცევა შეიძლება შეუმჩნეველი დარჩეს: გთხოვთ გაითვალისწინოთ, რომ მავნე პროგრამამ შეიძლება გამოიყენოს თავის არიდების ტექნიკა, როგორიცაა ვირტუალიზაცია/Sandbox-ის გადახვევა გააქტიურება მხოლოდ მაშინ, როდესაც ის შემოწმების ქვეშ არ არის და ასევე ნებისმიერი სტატიკური ანალიზის ძრავისთვის მავნე აქტივობის მანიშნებელი ნიშანია.
შესაძლებლობების ანალიზი განიხილავს კომპონენტის ფუნქციებს: სად უკავშირდება ის, რომელ ფაილებზე აქვს წვდომა, რომელი ბრძანებები ან პროგრამები მუშაობს, ტერმინალი ან მოწყობილობის შეყვანა/გამოსვლა შესრულდება ან რომელი სისტემური ზარებია გამოძახებული. ქცევის ეს ანაბეჭდი შეიძლება შედარებული იყოს (არსებული კომპონენტისთვის) სხვადასხვა ვერსიებს შორის, ამიტომ, როდესაც მოულოდნელი ქცევა გამოვლინდება, ამ მტკიცებულებამ შეიძლება გააჩინოს ეჭვი ახალ ვერსიაში პოტენციურად მავნე აქტივობის შესახებ. ეს მიდგომა მიჰყვება ტრიაჟის ნაბიჯებს, რომლებსაც უსაფრთხოების ანალიტიკოსები იყენებენ პოტენციური მავნე პროგრამების წინაშე: შემოწმება, რომელიც იყენებს სიმები ან მსგავსი ინსტრუმენტები. ეს მიდგომა აფიქსირებს მავნე ქცევას გამშვები პირობების მიუხედავად და მუშაობს მაშინ, როდესაც საწყისი კოდი არ არის ხელმისაწვდომი.
კონტექსტის ანალიზი აგროვებს ინფორმაციას იმის შესახებ, თუ როგორ და ვის მიერ იქნა გამოქვეყნებული კომპონენტი. ბოროტმოქმედთა კამპანიები ხშირად იყენებენ ახალ მომხმარებლის ანგარიშ(ებ)ს, რომლებიც არ ექვემდებარება რაიმე მკაცრ შემოწმების პროცესს. წარსული აქტივობის თვალყურის დევნებამ შეიძლება მოგვცეს ინფორმაცია ძირითადი მომხმარებლის შესახებ, ძირითადად იმ ანომალიების აღმოჩენის შესახებ, რომლებიც შეიძლება პოტენციურ კომპრომეტირებაზე მიანიშნებდეს. რეპუტაციის მოპოვება ძალიან რთულია და დაკარგვაც ძალიან ადვილია! მომხმარებელი, რომელსაც წარსული აქტივობა არ აქვს, ნეიტრალურია, მაგრამ კარმა ბოროტმოქმედს მისდევს. ჰაკტივისტები, ანუ ჩვეულებრივი მომხმარებლები, რომლებსაც გამომცემლობის სერთიფიკატები მოპარეს, ყურადღებით უნდა იყვნენ თვალყურის დევნებულნი.
კიდევ ერთი კონტექსტური ინფორმაციაა ნებისმიერი შეუსაბამობა კომპონენტის tarball-ის შესაქმნელად სავარაუდოდ გამოყენებულ წყაროს საცავსა და თავად tarball-ის შინაარსს შორის. ასევე კარგი პრაქტიკის დაცვა, როგორიცაა წყაროს საცავში თეგების ან რელიზების შექმნა, რომლებიც შეესაბამება საჯარო რეესტრში გამოქვეყნებული კომპონენტის ვერსიებს. როდესაც წყაროს საცავი კონკრეტულ... commit თუ მას აქვს გამოშვების ტეგი და შემდეგ მოულოდნელად ერთი ვერსია ვერ მოჰყვება მას, ეს მხოლოდ და მხოლოდ იმის ძლიერი მტკიცებულებაა, რომ კომპონენტი შეიძლება დაბინძურებული იყოს: შესაძლოა, ბოროტმოქმედმა კომპრომეტირება გაუკეთა კომპონენტის გამოსაქვეყნებლად გამოყენებულ ანგარიშს, მაგრამ არ აქვს ჩაწერის ნებართვა საწყისი კოდის საცავში). ბევრი შეტევა რუტინულად აღმოჩენილია ამ წესების გამოყენებით: მაგალითად, ლეჯერის შეტევა ამ მიმართულებით ადვილად შეიძლება აღმოჩენილიყო. შესაბამისად, კონტექსტური ანალიზი ავლენს ასეთ ანომალიებს გამოქვეყნების პროცესში.
დამოკიდებულების firewalling
განსხვავებული მიდგომაა თქვენს პროგრამულ უზრუნველყოფაში გამოყენებული ყველა დამოკიდებულების გრაფიკისთვის კომპონენტების ყოვლისმომცველი თეთრი სიის ქონა, ამიტომ ნებისმიერ აწყობაში pipeline თქვენს ორგანიზაციაში გაშვებული მხოლოდ დამტკიცებული კომპონენტების ვერსიების ინსტალაცია და გამოყენებაა შესაძლებელი. „Firewall„“ იძულებით ამოქმედდება შიდა რეესტრის გამოყენებით, სადაც განთავსებულია კომპონენტების დაშვებული ვერსიების tarball ფაილები (ქეშირებული ან პროქსირებული). გთხოვთ გაითვალისწინოთ, რომ არცერთი თეთრი სია არ იმუშავებს, თუ არ გაქვთ ტექნოლოგია ნებისმიერი ახალი ვერსიის შედარებით უსაფრთხოდ კლასიფიკაციისთვის, რათა მისი თეთრ სიაში დამატება შესაძლებელი იყოს.
გთხოვთ გაითვალისწინოთ, რომ ადრეული გაფრთხილება (ახალი ვერსიის გამოქვეყნებისთანავე რაც შეიძლება მალე სწრაფი აღმოჩენა) უნდა იყოს შერწყმული ამ ინფორმაციის პროაქტიულად გამოყენების რაიმე გზასთან, რათა დაიბლოკოს კომპონენტი, რომელიც გავლენას ახდენს აწყობაზე. pipelines ან დეველოპერების მანქანები [4]ჩვენ ამას „დამოკიდებულების firewalling„: კარანტინის მექანიზმი ავტომატური აწყობის მავნე პაკეტებისგან დასაცავად. შიდა პაკეტები და სურათების რეესტრები კარგია ორგანიზაციების გარე ბოროტებისგან დასაცავად, მაგრამ კარანტინის ეფექტურობისთვის საკმარისად ძლიერი მტკიცებულებებია საჭირო.
Runtime Sandboxing
გამოქვეყნების დროს აღმოჩენის ალტერნატიული მიდგომაა ქცევის ანალიზი გაშვების დროს. იდეა მდგომარეობს პროგრამული უზრუნველყოფიდან მოსალოდნელი ქცევის დაფიქსირებაში და ნებისმიერი აღმოჩენილი ანომალიის აღმოჩენაში (ან დაბლოკვაში). ამ ტიპის მოქმედების პრობლემა მდგომარეობს იმაში, რომ საჭიროა გაშვების დროის მონიტორინგის ან დაბლოკვის ინსტრუმენტების გამოყენება და ეს პერსპექტიული იდეაა, რომელიც დაემატება მავნე კომპონენტების მავნებლებისგან დაცვის მექანიზმების არსენალს.
ყოვლისმომცველი სტრატეგიის შემუშავება
რეკომენდებული სტრატეგია უნდა აერთიანებდეს პროგრამული უზრუნველყოფის შემუშავების პროცესში სხვადასხვა ტექნიკას, ვერსიის განახლებების კონტროლის აღებით, შემომავალი მავნე კომპონენტების დაბლოკვით. ჩვენ უნდა გავითვალისწინოთ ვერსიის დამაგრება, რათა თავიდან ავიცილოთ ავტომატური ინფიცირება განახლებული ვერსიებით, რათა მივიღოთ მნიშვნელოვანი დაუცველობების გამოსწორება; ვერსიის განახლების დროს პირდაპირი და არაპირდაპირი დამოკიდებულებების სწრაფი და ეფექტური შეფასება, რათა გვქონდეს საკმარისი მტკიცებულება იმისა, რომ ისინი არ არიან მავნე პროგრამებით დატვირთული. პროგრამული უზრუნველყოფის ბილდები, რომლებიც ცნობილ მავნე კომპონენტებზეა დამოკიდებული, უნდა დაიბლოკოს. და ყველა მათგანი უნდა იყოს აღსრულებული.
შესაძლებლობის შემთხვევაში, გამოიყენეთ ვერსიის დაფიქსირება, რადგან ეს აწყობის პროცესს უფრო რეპროდუცირებადს ხდის. ვერსიის დაფიქსირება კონტროლირებადი, ხელით დამტკიცებული ვერსიის ცვლილებებითდა დამხმარე ტექნოლოგიის დახმარებით, უნდა შეაფასოს, მოაქვს თუ არა განახლება მავნე პროგრამას ან აზიანებს თუ არა პროგრამულ უზრუნველყოფას და შეუთავსოს დაუცველობების გამოსწორების განახლება მავნე პროგრამის ინფექციის თავიდან აცილებას. ინსტრუმენტული გამოყენება აქ დაგეხმარებათ (1) იმ დაუცველობების პრიორიტეტულობის განსაზღვრით, რომლებიც ნამდვილად მნიშვნელოვანია (მიწვდომელი და ექსპლუატაციადი, თავდამსხმელების სამიზნედ მოქცევის მაღალი რისკით), (2) სამიზნე ვერსიების შერჩევით, რომლებიც თავსებადია კომპონენტების მიმდინარე გამოყენებასთან და არ აზიანებს პროგრამულ უზრუნველყოფას, (3) სამიზნე ვერსიების შერჩევით, რომლებიც არ შეიცავს მავნე ქცევას და (4) ვერსიის განახლების სწრაფი გაკეთებით პირდაპირი და არაპირდაპირი დამოკიდებულებებისთვის, მანიფესტ ფაილებში ცვლილებების შეთავაზებით, რომელთა სწრაფად დამტკიცებაც შესაძლებელია. (3) ეტაპზე საჭიროა კონკრეტული ინფორმაცია მავნე კომპონენტების შესახებ მათი გამოქვეყნების დრომდე რაც შეიძლება ახლოს.
დამოკიდებულებების განახლების ეს პროცესი უნდა იყოს აღსრულდა მდე დავადგინე, ყველა ადგილას. პროცესი უნდა იყოს დოკუმენტირებული და ყველა ჩართული მხარე უნდა იყოს გადამზადებული, რადგან ხშირად პროგრამული უზრუნველყოფის შემუშავება და შექმნა/განლაგება გარედან ხდება. CI/CD pipelines შესაბამისად უნდა შეიცვალოს, რათა ავტომატიზაციამ არ დაუშვას მავნე არაპირდაპირი დამოკიდებულების შეღწევა კონსტრუქციაში: guardrails რეკომენდებული გზაა აწყობის დაბლოკვა, თუ დამოკიდებულებაში პოტენციური მავნე პროგრამის საკმარისი მტკიცებულება არსებობს.
თუ თქვენს ორგანიზაციას აქვს შიდა რეესტრი, რომელიც მოქმედებს როგორც უსაფრთხოების პროქსი კომპონენტის დაშვებული ვერსიების შესანახი, თქვენ უნდა მიიღოთ ინფორმაცია მავნე კომპონენტების შესახებ (სხვა კრიტერიუმებთან ერთად), რათა შეამოწმოთ მოთხოვნილი კომპონენტი, სანამ მას დაშვებულთა სიაში დაამატებთ.
ღია კოდის პროგრამული უზრუნველყოფის უსაფრთხოდ გამოყენება ადვილი არ არის და მავნე პროგრამების ფაქტორი სრულად უნდა იქნას გათვალისწინებული, მსგავსი ძალისხმევა კი დაუცველობების მართვაში უნდა დაიხარჯოს.
ერთი ბოლო შენიშვნა: წყაროს წარმომავლობაკომპონენტის შექმნის დროს გენერირებული პროგრამული ატესტაციების სახით, კიდევ ერთი მნიშვნელოვანი ნაწილია არტეფაქტის (კომპონენტის tarball) წყაროებთან და შექმნის პროცესთან მიკვლევადობის მცდელობაში, რომელმაც ის შექმნა. გაითვალისწინეთ, რომ წყაროს სნეპშოტ + შექმნის გარემოსა და მასთან დაკავშირებულ პროგრამულ არტეფაქტს (ხელმოწერილია სანდო შექმნის სისტემის მიერ) შორის ეს კავშირი თავისთავად არ უშლის ხელს, რომ კომპონენტი არ შეიცავდეს მავნე ქცევას, მაგრამ ართულებს მავნე პროგრამების შეყვანას. ხოლო წარმომავლობის დადასტურების ღია კოდის კომპონენტების მოხმარების საერთო მოთხოვნად ქცევას დიდი დრო დასჭირდება და მხოლოდ ახლახან დაემატა NPM-სამ სანდო აწყობისა და განლაგების სისტემების ხელშეუხებლობა ან აწყობაში ნებისმიერი ხელშეშლის აღმოჩენის უზრუნველყოფა სულ სხვა ამბავია, რომელიც ამ პოსტის ფარგლებს სცილდება.
შემდგომი მოსმენით
შემდეგი ეპიზოდი ღია კოდის მავნე პაკეტები: Xygeni-ს მიდგომა წარმოგიდგენთ სტრატეგიას, რომელსაც Xygeni-ში ვიყენებთ ჩვენი მავნე პროგრამების ადრეული გაფრთხილება (MEW) სისტემა. საჯარო პაკეტსა და სურათების რეესტრებში ახალი პაკეტების ვერსიები სკანირდება და მტკიცებულებები მიიღება სტატიკური, დინამიური, შესაძლებლობებისა და კონტექსტუალური ანალიზის კომბინაციის გამოყენებით. მტკიცებულებები, მომხმარებლის რეპუტაციასთან და საწყისი კოდის საცავების ცვლილებების ისტორიასთან ერთად, საშუალებას იძლევა კომპონენტის სრულად ავტომატიზირებული კლასიფიკაციის მაღალი რისკის და სავარაუდოდ მავნე კატეგორიებად. სისტემა სწავლობს პაკეტებიდან შეგროვებული წარსული მტკიცებულებებიდან, რათა ცრუ დადებითი შედეგები მინიმუმამდე დაიყვანოს.
გამოწერილი ორგანიზაციები იღებენ გამაფრთხილებელ შეტყობინებას მათ მიერ გამოყენებული კომპონენტების შესახებ, პირდაპირ ან ირიბად, როდესაც მავნე ვერსია კატეგორიზებულია. შემდეგ ჩვენი ანალიტიკოსები ატარებენ ხელით ანალიზს, რომელიც ადასტურებს ან უარყოფს კლასიფიკაციას. დადასტურებული მავნე პროგრამების შემთხვევაში, საჯარო რეესტრს ეცნობება, რათა მან შეძლოს საკუთარი ანალიზის ჩატარება და, როგორც წესი, წაშალოს მავნე ვერსია ან მიიღოს დამატებითი ზომები, როგორიცაა შესაბამისი მომხმარებლის ანგარიშის დაბლოკვა ან წაშლა.
ჩვენ ავხსნით, თუ როგორ ვეხმარებით NPM-ს, PyPI-ს, GitHub-ს და ღია კოდის ეკოსისტემის სხვა ძირითად ინფრასტრუქტურებს, შეამცირონ გამოქვეყნებული ახალი მავნე კომპონენტის აქტიური ყოფნის დრო მანამ, სანამ ის არ დადასტურდება, როგორც მავნე პროგრამა და არ წაიშლება რეესტრიდან. ასევე, როგორ შეუძლიათ ორგანიზაციებს ისარგებლონ MEW სისტემით, რათა გაცილებით უკეთესი დაცვა ჰქონდეთ ღია კოდის კომპონენტებთან დაკავშირებული პროგრამული უზრუნველყოფის მიწოდების ჯაჭვის შეტევებისგან.
- [1] ნებისმიერ შემთხვევაში, კომპონენტის მომხმარებლებმა უნდა შეამოწმონ, არის თუ არა კომპონენტის tarball ქეშირებული ან რეგისტრირებული სადმე, მაგალითად, შიდა რეესტრში, რათა პრობლემა აღმოიფხვრას.
- [2] შეფუთული კომპონენტი მოიცავს მანიფესტს, რომელიც აცხადებს მის შინაარსს და მეტამონაცემებს, წყაროს ან კომპილირებულ კოდს, ინსტალაციის სკრიპტებს და დამატებით ელემენტებს, როგორიცაა სატესტო ნაკრებები, შეფუთვის ფორმატის მიხედვით და, როგორც წესი, შეკუმშული ფორმით. ამას ეწოდება „კომპონენტის tarball“.
- [3] მაშინაც კი, თუ მავნე აქტორს შეუძლია გამოქვეყნებული კომპონენტის შეცვლა თავად რეესტრში დარღვევის გამო, ჩვეულებრივი კრიპტოგრაფიული დაიჯესტი ანალიზის დასრულების შემდეგ tarball-ში ნებისმიერი ცვლილების აღმოჩენას შეძლებს.
- [4] გახსოვდეთ, რომ ზოგიერთი მავნე კომპონენტი ინსტალაციის დროს მუშაობს, ამიტომ მას შეუძლია გავლენა მოახდინოს დეველოპერის კვანძებზე, რომლებიც უნებლიეთ გაუშვებენ „npm install X“-ს, როდესაც X მავნე კომპონენტია.
