დაუცველობის სკანირება და უსაფრთხო განვითარება. Ნაწილი 1

როგორც მათი პროფესიული საქმიანობის ნაწილი, დეველოპერებს, პენტესტერებს და უსაფრთხოების პროფესიონალებს უწევთ გამკლავება ისეთ პროცესებთან, როგორიცაა დაუცველობის მენეჯმენტი (VM), (უსაფრთხო) SDLC.
ამ ფრაზების ქვეშ არის გამოყენებული პრაქტიკისა და ხელსაწყოების სხვადასხვა ნაკრები, რომლებიც გადახლართულია, თუმცა მათი მომხმარებლები განსხვავდებიან.

ტექნოლოგიურმა პროგრესმა ჯერ არ მიაღწია იმ დონეს, რომ ერთმა ინსტრუმენტმა შეცვალოს ადამიანი ინფრასტრუქტურისა და პროგრამული უზრუნველყოფის უსაფრთხოების ანალიზისთვის.
საინტერესოა იმის გაგება, თუ რატომ არის ეს ასე და რა პრობლემების წინაშე დგას ადამიანი.

Процессы

დაუცველობის მართვის პროცესი შექმნილია ინფრასტრუქტურის უსაფრთხოებისა და პაჩების მართვის მუდმივი მონიტორინგისთვის.
Secure SDLC პროცესი ("უსაფრთხო განვითარების ციკლი") შექმნილია აპლიკაციის უსაფრთხოების შესანარჩუნებლად განვითარებისა და ექსპლუატაციის დროს.

ამ პროცესების მსგავსი ნაწილია Vulnerability Assessment პროცესი - მოწყვლადობის შეფასება, დაუცველობის სკანირება.
მთავარი განსხვავება VM-სა და SDLC-ში სკანირებას შორის არის ის, რომ პირველ შემთხვევაში, მიზანია იპოვოთ ცნობილი დაუცველობა მესამე მხარის პროგრამულ უზრუნველყოფაში ან კონფიგურაციაში. მაგალითად, Windows-ის მოძველებული ვერსია ან ნაგულისხმევი საზოგადოების სტრიქონი SNMP-ისთვის.
მეორე შემთხვევაში, მიზანია აღმოაჩინოს დაუცველობა არა მხოლოდ მესამე მხარის კომპონენტებში (დამოკიდებულებებში), არამედ, პირველ რიგში, ახალი პროდუქტის კოდში.

ეს იწვევს განსხვავებებს ინსტრუმენტებსა და მიდგომებში. ჩემი აზრით, აპლიკაციაში ახალი დაუცველობის პოვნა ბევრად უფრო საინტერესოა, რადგან ეს არ ეხება ვერსიის თითის ანაბეჭდს, ბანერის შეგროვებას, პაროლის უხეში ძალის და ა.შ.
აპლიკაციის დაუცველობის მაღალი ხარისხის ავტომატიზირებული სკანირება მოითხოვს ალგორითმებს, რომლებიც ითვალისწინებენ აპლიკაციის სემანტიკას, მის დანიშნულებას და კონკრეტულ საფრთხეებს.

ინფრასტრუქტურის სკანერი ხშირად შეიძლება შეიცვალოს ტაიმერით, როგორც ეს ავლეონოვი. საქმე იმაშია, რომ წმინდა სტატისტიკურად, შეგიძლიათ თქვენი ინფრასტრუქტურა დაუცველად ჩათვალოთ, თუ არ განაახლეთ, ვთქვათ, ერთი თვის განმავლობაში.

ინსტრუმენტები

სკანირება, ისევე როგორც უსაფრთხოების ანალიზი, შეიძლება შესრულდეს შავი ყუთის ან თეთრი ყუთის სახით.

შავი ყუთი

შავი ყუთის სკანირებით, ხელსაწყოს უნდა შეეძლოს სერვისთან მუშაობა იმავე ინტერფეისით, რომლითაც მომხმარებლები მუშაობენ მასთან.

ინფრასტრუქტურის სკანერები (Tenable Nessus, Qualys, MaxPatrol, Rapid7 Nexpose და ა.შ.) ეძებენ ღია ქსელის პორტებს, აგროვებენ „ბანერებს“, იდენტიფიცირებენ დაინსტალირებული პროგრამული უზრუნველყოფის ვერსიებს და ეძებენ მათ ცოდნის ბაზას ამ ვერსიებში დაუცველობის შესახებ ინფორმაციისთვის. ისინი ასევე ცდილობენ აღმოაჩინონ კონფიგურაციის შეცდომები, როგორიცაა ნაგულისხმევი პაროლები ან საჯარო წვდომა მონაცემებზე, სუსტი SSL შიფრები და ა.შ.

ვებ აპლიკაციების სკანერებს (Acunetix WVS, Netsparker, Burp Suite, OWASP ZAP და ა.შ.) ასევე შეუძლიათ ამოიცნონ ცნობილი კომპონენტები და მათი ვერსიები (მაგ. CMS, Frameworks, JS ბიბლიოთეკები). სეირნობის ძირითადი საფეხურები არის ცოცხალი და დაბნეულობა.
სეირნობისას მცოცავი აგროვებს ინფორმაციას არსებული აპლიკაციის ინტერფეისებისა და HTTP პარამეტრების შესახებ. შეცდომის დროს, ყველა აღმოჩენილი პარამეტრი ჩანაცვლებულია მუტაციური ან გენერირებული მონაცემებით, რათა მოხდეს შეცდომის პროვოცირება და დაუცველობის გამოვლენა.

ასეთი აპლიკაციის სკანერები მიეკუთვნება DAST და IAST კლასებს - შესაბამისად დინამიური და ინტერაქტიული აპლიკაციების უსაფრთხოების ტესტირება.

თეთრი ყუთი

თეთრი ყუთის სკანირებით, უფრო მეტი განსხვავებაა.
როგორც VM პროცესის ნაწილი, სკანერებს (Vulners, Incsecurity Couch, Vuls, Tenable Nessus და ა.შ.) ხშირად ეძლევათ წვდომა სისტემებზე ავტორიზებული სკანირების შესრულებით. ამრიგად, სკანერს შეუძლია ჩამოტვირთოთ დაინსტალირებული პაკეტის ვერსიები და კონფიგურაციის პარამეტრები პირდაპირ სისტემიდან, ქსელის სერვისის ბანერებიდან მათი გამოცნობის გარეშე.
სკანირება უფრო ზუსტი და სრულყოფილია.

თუ ვსაუბრობთ აპლიკაციების whitebox სკანირებაზე (CheckMarx, HP Fortify, Coverity, RIPS, FindSecBugs და ა.შ.), მაშინ ჩვეულებრივ ვსაუბრობთ სტატიკური კოდის ანალიზზე და შესაბამისი SAST კლასის ხელსაწყოების გამოყენებაზე - Static Application Security Testing.

პრობლემები

სკანირებასთან დაკავშირებით ბევრი პრობლემაა! მათ უმეტესობასთან პირადად მიწევს გამკლავება, როგორც შენობის სკანირებისა და განვითარების უსაფრთხო პროცესების სერვისის მიწოდების ნაწილი, ასევე უსაფრთხოების ანალიზის სამუშაოების ჩატარებისას.

გამოვყოფ პრობლემების 3 ძირითად ჯგუფს, რასაც სხვადასხვა კომპანიის ინჟინრებთან და ინფორმაციული უსაფრთხოების სამსახურის ხელმძღვანელებთან საუბარიც ადასტურებს.

ვებ აპლიკაციის სკანირების პრობლემები

1. განხორციელების სირთულე. სკანერები უნდა იყოს განლაგებული, კონფიგურირებული, მორგებული თითოეული აპლიკაციისთვის, გამოყოფილი იყოს სატესტო გარემო სკანირებისთვის და დანერგილი იყოს CI/CD პროცესში, რათა იყოს ეფექტური. წინააღმდეგ შემთხვევაში, ეს იქნება უსარგებლო ფორმალური პროცედურა, მხოლოდ ცრუ პოზიტივის გაცემა
2. სკანირების ხანგრძლივობა. სკანერები, თუნდაც 2019 წელს, ცუდ საქმეს აკეთებენ ინტერფეისების დუბლიკატით და შეუძლიათ ათასობით გვერდის სკანირება 10 პარამეტრით თითოეული დღის განმავლობაში, განსხვავებულად განიხილონ, თუმცა მათზე პასუხისმგებელია ერთი და იგივე კოდი. ამავდროულად, გადაწყვეტილება წარმოებაში განლაგების შესახებ განვითარების ციკლის ფარგლებში უნდა იქნას მიღებული სწრაფად.
3. ცუდი რეკომენდაციები. სკანერები იძლევა საკმაოდ ზოგად რეკომენდაციებს და ყოველთვის არ არის შესაძლებელი, რომ დეველოპერმა სწრაფად გაიგოს მათგან, როგორ შეამციროს რისკის დონე და რაც მთავარია, საჭიროა თუ არა ამის გაკეთება ახლავე, თუ ჯერ კიდევ არ არის საშინელი.
4. დესტრუქციული გავლენა აპლიკაციაზე. სკანერებს შეუძლიათ მარტივად შეასრულონ DoS შეტევა აპლიკაციაზე და ასევე შეუძლიათ შექმნან დიდი რაოდენობით ერთეულები ან შეცვალონ არსებული (მაგალითად, შექმნან ათიათასობით კომენტარი ბლოგზე), ასე რომ თქვენ დაუფიქრებლად არ უნდა აწარმოოთ სკანირება პროდუქტში.
5. დაუცველობის გამოვლენის ცუდი ხარისხი. სკანერები, როგორც წესი, იყენებენ დატვირთვების ფიქსირებულ მასივს და ადვილად გამოტოვებენ დაუცველობას, რომელიც არ ჯდება მათ ცნობილ აპლიკაციის ქცევაში.
6. სკანერს არ ესმის აპლიკაციის ფუნქციები. თავად სკანერებმა არ იციან რა არის "ინტერნეტ ბანკი", "გადახდა", "კომენტარი". მათთვის არის მხოლოდ ბმულები და პარამეტრები, ასე რომ, ბიზნეს ლოგიკის დაუცველობის უზარმაზარი ფენა რჩება სრულიად გამოვლენილი, ისინი ვერ გამოიცნობენ ორმაგ ჩამოწერას, სხვა ადამიანების მონაცემებს პირადობის მოწმობის მიხედვით ან ბალანსის ამოღებას დამრგვალებით.
7. გვერდის სემანტიკის გაუგებრობა სკანერის მიერ. სკანერები ვერ კითხულობენ FAQ-ს, ვერ ცნობენ კაპჩებს, ისინი თავად ვერ გამოიცნობენ, როგორ დარეგისტრირდნენ და შემდეგ ხელახლა შეხვიდეთ, რომ თქვენ არ შეგიძლიათ დააჭიროთ "გამოსვლას" და როგორ მოაწეროთ მოთხოვნებს პარამეტრების მნიშვნელობების შეცვლისას. შედეგად, აპლიკაციის უმეტესობა შეიძლება საერთოდ დარჩეს დაუსკანირებული.

წყარო კოდის სკანირების საკითხები

1. ცრუ დადებითი. სტატიკური ანალიზი რთული ამოცანაა, რომელიც ბევრ კომპრომისს მოიცავს. ხშირად თქვენ უნდა შესწიროთ სიზუსტე და ძვირადღირებული საწარმოს სკანერებიც კი აძლევენ ცრუ პოზიტივის დიდ რაოდენობას.
2. განხორციელების სირთულე. სტატიკური ანალიზის სიზუსტისა და სისრულის გასაზრდელად აუცილებელია სკანირების წესების დახვეწა და ამ წესების დაწერა შეიძლება ძალიან შრომატევადი იყოს. ზოგჯერ უფრო ადვილია ყველა ადგილის პოვნა კოდში რაიმე სახის შეცდომით და მათი გამოსწორება, ვიდრე ასეთი შემთხვევების გამოვლენის წესის დაწერა.
3. დამოკიდებულების მხარდაჭერის ნაკლებობა. დიდი პროექტები დამოკიდებულია ბიბლიოთეკების და ჩარჩოების დიდ რაოდენობაზე, რომლებიც აფართოებენ პროგრამირების ენის შესაძლებლობებს. თუ სკანერის ცოდნის ბაზაში არ არის ინფორმაცია საშიში ადგილების („ნიჟარების“) შესახებ ამ ჩარჩოებში, ეს გახდება ბრმა წერტილი და სკანერი უბრალოდ ვერც კი გაიგებს კოდს.
4. სკანირების ხანგრძლივობა. კოდში დაუცველობის პოვნა რთული ამოცანაა ალგორითმების თვალსაზრისითაც. ამიტომ, პროცესი შეიძლება გადაიდო და მოითხოვოს მნიშვნელოვანი გამოთვლითი რესურსები.
5. დაბალი დაფარვა. რესურსების მოხმარებისა და სკანირების ხანგრძლივობის მიუხედავად, SAST ინსტრუმენტების დეველოპერებს მაინც უწევთ კომპრომისების გამოყენება და არა ყველა მდგომარეობის ანალიზი, რომელშიც პროგრამა შეიძლება იყოს.
6. გამრავლების პოვნა. კონკრეტული ხაზისა და ზარის დასტაზე მითითება, რომელიც დაუცველობას იწვევს, შესანიშნავია, მაგრამ სინამდვილეში, ხშირად სკანერი არ იძლევა საკმარის ინფორმაციას გარე დაუცველობის შესამოწმებლად. ბოლოს და ბოლოს, ხარვეზი შეიძლება იყოს მკვდარ კოდშიც, რომელიც მიუწვდომელია თავდამსხმელისთვის.

ინფრასტრუქტურის სკანირების საკითხები

1. არასაკმარისი ინვენტარი. დიდ ინფრასტრუქტურებში, განსაკუთრებით გეოგრაფიულად განცალკევებულ ინფრასტრუქტურებში, ხშირად ყველაზე რთულია იმის გარკვევა, თუ რომელი ჰოსტების სკანირება ხდება. სხვა სიტყვებით რომ ვთქვათ, სკანირების ამოცანა მჭიდრო კავშირშია აქტივების მართვის ამოცანასთან.
2. ცუდი პრიორიტეტიზაცია. ქსელური სკანერები ხშირად აწარმოებენ ბევრ შედეგს ხარვეზებით, რომლებიც პრაქტიკაში არ არის გამოსაყენებელი, მაგრამ ფორმალურად მათი რისკის დონე მაღალია. მომხმარებელი იღებს ანგარიშს, რომლის ინტერპრეტაცია რთულია და გაუგებარია, რა უნდა გამოსწორდეს პირველ რიგში
3. ცუდი რეკომენდაციები. სკანერის ცოდნის ბაზა ხშირად შეიცავს მხოლოდ ძალიან ზოგად ინფორმაციას დაუცველობის შესახებ და როგორ გამოსწორდეს ის, ამიტომ ადმინისტრატორებს მოუწევთ Google-ით შეიარაღება. სიტუაცია ოდნავ უკეთესია whitebox სკანერებით, რომლებსაც შეუძლიათ გამოასწორონ კონკრეტული ბრძანება
4. ხელნაკეთი. ინფრასტრუქტურას შეიძლება ჰქონდეს მრავალი კვანძი, რაც ნიშნავს, რომ არსებობს პოტენციურად ბევრი ხარვეზი, რომელთა შესახებ მოხსენებები უნდა იყოს გაანალიზებული და ხელით გაანალიზებული ყოველი გამეორებისას.
5. ცუდი გაშუქება. ინფრასტრუქტურის სკანირების ხარისხი პირდაპირ დამოკიდებულია მოწყვლადობისა და პროგრამული უზრუნველყოფის ვერსიების შესახებ ცოდნის ბაზის ზომაზე. სადაც, მონაცვლეობითბაზრის ლიდერებსაც კი არ აქვთ ყოვლისმომცველი ცოდნის ბაზა და უფასო გადაწყვეტილებების მონაცემთა ბაზაში არის უამრავი ინფორმაცია, რაც ლიდერებს არ აქვთ.
6. პრობლემები პაჩთან დაკავშირებით. ყველაზე ხშირად, ინფრასტრუქტურის დაუცველობის შესწორება არის პაკეტის განახლება ან კონფიგურაციის ფაილის შეცვლა. აქ დიდი პრობლემა ის არის, რომ სისტემა, განსაკუთრებით მემკვიდრეობითი, შეიძლება არაპროგნოზირებად მოიქცეს განახლების შედეგად. სინამდვილეში, თქვენ მოგიწევთ ინტეგრაციის ტესტების ჩატარება წარმოებაში ცოცხალ ინფრასტრუქტურაზე.

Მიღწევები

როგორ შეიძლება რომ იყოს?
მე უფრო დეტალურად განვიხილავ მაგალითებს და როგორ გავუმკლავდეთ ამ ბევრ პრობლემას შემდეგ ნაწილებში, მაგრამ ახლა მე აღვნიშნავ ძირითად სფეროებს, რომლებშიც შეგიძლიათ მუშაობა:

1. სხვადასხვა სკანირების ხელსაწყოების აგრეგაცია. მრავალჯერადი სკანერის სწორი გამოყენებით, შესაძლებელია ცოდნის ბაზის მნიშვნელოვანი ზრდა და გამოვლენის ხარისხი. თქვენ შეგიძლიათ იპოვოთ კიდევ უფრო მეტი დაუცველობა, ვიდრე ინდივიდუალურად გაშვებული ყველა სკანერის ჯამი, ხოლო თქვენ შეგიძლიათ უფრო ზუსტად შეაფასოთ რისკის დონე და გააკეთოთ მეტი რეკომენდაცია
2. SAST და DAST ინტეგრაცია. შესაძლებელია DAST დაფარვისა და SAST სიზუსტის გაზრდა მათ შორის ინფორმაციის გაზიარებით. წყაროდან შეგიძლიათ მიიღოთ ინფორმაცია არსებული მარშრუტების შესახებ, ხოლო DAST-ის დახმარებით შეგიძლიათ შეამოწმოთ, ჩანს თუ არა დაუცველობა გარედან
3. Machine Learning™. 2015 წელს ი განუცხადა (და მეტი) სტატისტიკის გამოყენების შესახებ, რათა სკანერებს ჰაკერების ინტუიცია მისცეს და დააჩქაროს ისინი. ეს ნამდვილად საკვებია მომავალში უსაფრთხოების ავტომატური ანალიზის განვითარებისთვის.
4. IAST ინტეგრაცია ავტოტესტებთან და OpenAPI-სთან. CI/CD მილსადენის ფარგლებში შესაძლებელია სკანირების პროცესის შექმნა, რომელიც დაფუძნებულია ინსტრუმენტებზე, რომლებიც მუშაობენ როგორც HTTP პროქსი და ფუნქციური ტესტები, რომლებიც მუშაობენ HTTP-ზე. OpenAPI/Swagger-ის ტესტები და კონტრაქტები მისცემს სკანერს გამოტოვებულ ინფორმაციას მონაცემთა ნაკადების შესახებ, შესაძლებელს გახდის აპლიკაციის სკანირებას სხვადასხვა შტატებში.
5. სწორი კონფიგურაცია. თითოეული აპლიკაციისა და ინფრასტრუქტურისთვის, თქვენ უნდა შექმნათ შესაფერისი სკანირების პროფილი, ინტერფეისების რაოდენობის და ბუნების, გამოყენებული ტექნოლოგიების გათვალისწინებით.
6. სკანერის პერსონალიზაცია. ხშირად, აპლიკაციის სკანირება შეუძლებელია სკანერის შეცვლის გარეშე. მაგალითად არის გადახდის კარიბჭე, სადაც ყველა მოთხოვნა უნდა იყოს ხელმოწერილი. კარიბჭის პროტოკოლთან კონექტორის ჩაწერის გარეშე, სკანერები დაუფიქრებლად ამოწმებენ მოთხოვნებს არასწორი ხელმოწერით. ასევე აუცილებელია სპეციალიზებული სკანერების დაწერა კონკრეტული ტიპის ხარვეზებისთვის, მაგ დაუცველი პირდაპირი ობიექტის მითითება
7. Რისკების მართვა. სხვადასხვა სკანერების გამოყენება და ინტეგრაცია გარე სისტემებთან, როგორიცაა აქტივების მენეჯმენტი და საფრთხეების მენეჯმენტი, საშუალებას მისცემს გამოიყენონ მრავალი პარამეტრი რისკის დონის შესაფასებლად, რათა მენეჯმენტმა მიიღოს ადეკვატური სურათი განვითარების ან ინფრასტრუქტურის უსაფრთხოების ამჟამინდელი მდგომარეობის შესახებ.

თვალყური ადევნეთ და მოდით, ხელი შევუშალოთ დაუცველობის სკანირებას!

წყარო: www.habr.com