სტატიკური სკანირების მიღმა: დააკვირდით არა მხოლოდ კოდს, არამედ ხაზსაც
თქვენ შექმენით თანამედროვე CI/CD pipelineთქვენი კოდი გაივლის SAST მდე SCA სკანირება. ყველაფერი მწვანეა. თუმცა, წარმოების პროცესში, მონაცემები მესამე მხარის სერვერზე გაჟონვას იწყებს. რა მოხდა? ეს თეორიული პრობლემა არ არის. ეს საკმაოდ გავრცელებულია. ტრადიციული AppSec ინსტრუმენტები, როგორიცაა SAST მდე SCA კოდის დონეზე მუშაობენ; ისინი აანალიზებენ სინტაქსს, დამოკიდებულების ხეებს და დაუცველობებს, მაგრამ არ აღრიცხავენ, თუ როგორ იქცევა თქვენი აპლიკაცია მისი განლაგების შემდეგ. სწორედ ეს არის ბრმა წერტილი.
ღია კოდის პაკეტმა ან დინამიურმა SDK-მ შეიძლება გამოიწვიოს ქსელის გაშვების დროს აქტივობის, გამავალი ტელემეტრიის, მყარი კოდირებული API ზარების ან ჩუმი მონაცემთა გაჟონვის ინიცირება. კოდის სკანირების ინსტრუმენტები ამას ვერ ხედავენ. სწორედ აქ ავსებს ღრმა პაკეტების შემოწმება (DPI) ამ ხარვეზს. კოდის შესაძლო მოქმედების გამოცნობის ნაცვლად, DPI პირდაპირ გიჩვენებთ, თუ რას აკეთებს.
დღეს, აპლიკაციების უსაფრთხოება კოდს სცდება. DPI-ს მეშვეობით გაშვების დროს დაკვირვება, რომელიც მჭიდროდ არის ინტეგრირებული თანამედროვე შეტევის ზედაპირის მართვასთან, აღარ არის არჩევითი. ეს ნებისმიერი AppSec სტრატეგიის კრიტიკული ნაწილია, რომელსაც სურს რეალური საფრთხეების რეალურ დროში აღმოჩენა და მათზე რეაგირება.
DPI-ს განმარტება: რას ნიშნავს ღრმა პაკეტების შემოწმება
დაივიწყეთ სახელმძღვანელოში მოცემული DPI განმარტება. AppSec-ის კონტექსტში, ღრმა პაკეტების შემოწმება ტრადიციული ქსელის მონიტორინგის ფარგლებს სცილდება. მხოლოდ სათაურების შემოწმების ნაცვლად, როგორიცაა წყარო, დანიშნულების ადგილი და პროტოკოლი, DPI ამოწმებს თითოეული პაკეტის რეალურ დატვირთვას, რათა გაიგოს, თუ რა ხდება აპლიკაციის ტრაფიკში.
იქ, სადაც ძირითადი ინსტრუმენტები მხოლოდ „ეს არის HTTP მოთხოვნა A სერვისიდან B სერვისამდე“ იდენტიფიცირებით მთავრდება, DPI უფრო ღრმად ჩადის:
- ის კითხულობს სრულ HTTP კონტენტს, მეთოდებს, პარამეტრებს და მონაცემებს.
- ის შიფრავს gRPC დატვირთვას რეალური მეთოდების გამოძახებებისა და მონაცემთა სტრუქტურების საჩვენებლად.
- ის აანალიზებს DNS მოთხოვნებს საეჭვო დომენების ან მოთხოვნის ნიმუშების აღმოსაჩენად.
ეს უფრო ღრმა შემოწმება საშუალებას გაძლევთ:
- მკაფიო ტექსტის საიდუმლოებების ან ავტორიზაციის მონაცემების აღმოჩენა.
- ჩაშენებული ექსფილტრაციის მცდელობების აღმოჩენა, დაშიფრული არხებითაც კი.
- არაავტორიზებული გარე კომუნიკაციის მცდელობების დაჭერა.
და რაც მთავარია, ეს არ არის მხოლოდ ქსელური ინსტრუმენტი. თანამედროვე AppSec სტრატეგიაში DPI ისეთივე მნიშვნელოვანია, როგორც სტატიკური ანალიზი. ის უსაფრთხოების გუნდებს აძლევს აპლიკაციის ქცევის გაშვების დროს მტკიცებულებებს, აფუძნებს ვარაუდებს რეალურ მონაცემებზე და ხელს უწყობს უფრო ზუსტ, ქცევაზე ორიენტირებულ შეტევის ზედაპირულ მართვას.
DPI-ის უნიკალური ღირებულება აპლიკაციის უსაფრთხოებისთვის
ღრმა პაკეტური შემოწმება (DPI) გთავაზობთ ხილვადობას, რომლის უზრუნველყოფაც სტატიკურ ხელსაწყოებს უბრალოდ არ შეუძლიათ, რადგან ის აკვირდება თქვენი აპლიკაციების რეალურ გაშვების დროს ქცევას.
ინსტრუმენტები, როგორიცაა SAST მდე SCA ისინი კოდისა და მეტამონაცემების სფეროში მოქმედებენ. ისინი აანალიზებენ სინტაქსს, დამოკიდებულების ხეებს და ცნობილ დაუცველობებს. თუმცა, ისინი ვერ ამჩნევენ, თუ რა ხდება თქვენი აპლიკაციის გაშვების შემდეგ: იმ მომენტს, როდესაც ლოგიკა რეალურ ტრაფიკად გარდაიქმნება და რისკები პოტენციურიდან რეალურში გადადის.
DPI ამოწმებს რეალურ ტრაფიკს. ის აანალიზებს ქსელის დატვირთვას და არა მხოლოდ სათაურებს, რაც საშუალებას გაძლევთ სრულად გააანალიზოთ აპლიკაციის დონის პროტოკოლები, როგორიცაა HTTP, gRPC და DNS. ეს საშუალებას გაძლევთ აღმოაჩინოთ ნიუანსირებული არასწორი ქმედებები, რომლებიც კოდის დონეზე უხილავია.
აი, რას ავლენს ღრმა პაკეტების შემოწმება AppSec-ში უნიკალურად:
პროტოკოლის ბოროტად გამოყენება შიდა კომუნიკაციებში
შესაძლოა, TLS გარედან აამოქმედოთ, მაგრამ რაც შეეხება სერვისიდან სერვისამდე ტრაფიკს? DPI ადგენს შემთხვევებს, როდესაც შიდა მიკროსერვისები უბრუნდებიან უბრალო ტექსტურ HTTP-ს, რეგულირებად გარემოშიც კი. სტატიკური ხელსაწყოები ამას ვერ ამჩნევენ, მაგრამ პაკეტების ღრმა შემოწმება ახერხებს.
C2 Beaconing კომპრომეტირებული მესამე მხარის პაკეტებიდან
კომპრომეტირებული npm, PyPI ან Maven პაკეტი შეიძლება შეიცავდეს ლოგიკას, რომელიც პერიოდულ პინგებს უგზავნის დისტანციურ C2 სერვერს. DPI აფიქსირებს ამ დაბალი სიხშირის, შაბლონურ ზარებს, თუნდაც დაშიფრულებს. ის აღნიშნავს საეჭვო დროის ინტერვალებს ან დომენებს თქვენი დამტკიცებული გამავალი ზარების სიის გარეთ.
მოულოდნელი გარე კავშირები
მაშინაც კი, თუ თქვენი აპლიკაცია მხოლოდ ცნობილ API-ებთან უნდა დაუკავშირდეს, დეველოპერმა შეიძლება დააკოდიროს საბოლოო წერტილი, ან მესამე მხარის ბიბლიოთეკამ დაამატოს ტელემეტრიული ზარები, რომლებიც თქვენ არ გადაგიმოწმებიათ. DPI საშუალებას გაძლევთ შეადაროთ რეალური ტრაფიკი გამოცხადებულ სერვისის საზღვრებს და დაუყოვნებლივ მონიშნოთ დარღვევები.
რატომ საკითხები:
DPI ვარაუდებს ფაქტებით ცვლის. „შეიძლება თუ არა ეს კოდი სარისკო იყოს?“-ის ნაცვლად, რისკი პაკეტებში ვლინდება. AppSec-ს რეაქტიულიდან პროაქტიულზე გადაჰყავთ:
- თქვენ აღარ იქნებით მხოლოდ CVE მონაცემთა ბაზებზე დამოკიდებული.
- თქვენ შეწყვეტთ იმის ვარაუდს, რომ ქსელის დონე უსაფრთხოა მხოლოდ იმიტომ, რომ კოდი ნორმალურად გამოიყურება.
თქვენ იწყებთ მართვას რეალური შეტევის ზედაპირი, არა თეორიული.
საბოლოო ჯამში, პაკეტების ღრმა შემოწმება გუნდებს საშუალებას აძლევს, ყურადღება გაამახვილონ რას აკეთებს აპლიკაცია, არა მხოლოდ ის, რაც დეველოპერებს განკუთვნილიაეს არის ქცევისადმი გაცნობიერებული თავდაცვა და თანამედროვე შეტევის ზედაპირის მართვა მოქმედებაში.
ბრმა წერტილები ტრადიციულ AppSec მეთოდებში
ტრადიციული AppSec ინსტრუმენტები, როგორიცაა SAST მდე SCA, ფოკუსირებულია კოდზე, სტრუქტურასა და ცნობილ დაუცველობებზე. ისინი საკმაოდ კარგად ახერხებენ დაუცველი შაბლონებისა და მოძველებული დამოკიდებულებების პოვნას, მაგრამ არ გააჩნიათ შესრულების ხედვა. ეს პრობლემაა. კონტექსტის გარეშე, თქვენ ვერ ამჩნევთ იმას, რასაც თქვენი კოდი აკეთებს.
გავრცელებული ბრმა წერტილები:
გამოუყენებელი დაუცველი კოდის გზები
დამოკიდებულება შეიძლება მოიცავდეს CVE, მაგრამ თუ ფუნქცია არასდროს გამოიძახება, გამოსწორება ხმაურად იქცევა. DPI ამოწმებს, გამოიყენება თუ არა სარისკო კოდის გზები.cisრედ. ეს წინასწარ არისcisელექტრონული შეტევის ზედაპირის მართვა.
დაბნეული ლოგიკიდან დამალული გამავალი ტრაფიკი
ზოგიერთი ღია კოდის პაკეტი იყენებს დინამიურ იმპორტს, რეფლექსიას ან დაშიფრულ დატვირთვას. ამ ინსტრუმენტებს შეუძლიათ გარე API ზარების ინიცირება ან მეტამონაცემების ამოღება. სტატიკური ინსტრუმენტები ხშირად ვერ ახერხებენ მათ გამოყენებას, მაგრამ პაკეტების ღრმა შემოწმება ავლენს გამავალ მოთხოვნებს და მათ დანიშნულების ადგილს.
დაშიფრული ტრაფიკი, რომელიც შემოწმებას არ ექვემდებარება
ისეთი პროტოკოლები, როგორიცაა gRPC TLS-ზე ან QUIC, მალავენ დატვირთვებს. სტატიკურ ხელსაწყოებს არ შეუძლიათ მათი გაშიფვრა. DPI-ს, ეტაპობრივი ან დაკვირვების აგენტებში გაშიფვრის გამოყენებით, შეუძლია ამ ნაკადების შემოწმება და პოლიტიკის დარღვევების ან საიდუმლო გაჟონვის მონიშვნა.
ქცევითი დრიფტი განლაგებულ კოდში
თქვენი აუდიტირებული კოდი შესაძლოა განსხვავებულად მუშაობდეს წარმოებაში გარემოს ცვლადების, ფუნქციების ფლაგების ან გაშვების დროს დატვირთული მოდულების გამო. DPI-ს გარეშე, თქვენ ვერ გაიგებთ, გახდება თუ არა შიდა API გარედან ხელმისაწვდომი ან გამოჩნდება თუ არაავტორიზებული კავშირები.
უფრო ფართო სურათი: სინტაქსი ≠ ქცევა
სუფთა კოდიდან მიღებული უსაფრთხოება მოძველებულია. თანამედროვე შეტევის ზედაპირის მართვა უნდა მოიცავდეს გაშვების დროს ქცევას. ღრმა პაკეტების შემოწმება არის ინსტრუმენტი, რომელიც ავსებს ამ ხილვადობის ხარვეზს და საშუალებას გაძლევთ გადაამოწმოთ უსაფრთხოების ვარაუდები რეალური ტრაფიკის მიმართ.
რეალური დარღვევის მაგალითები, სადაც DPI-მ გამოავლინა ის, რაც სტატიკურმა ხელსაწყოებმა გამოტოვეს
ღრმა პაკეტური შემოწმების (DPI) ინტეგრირება თქვენს AppSec-ში pipeline ჰიპოთეტური არ არის; ის რეალურ სამყაროში მომხდარ ინციდენტებს ეფუძნება, სადაც ქსელური ტრაფიკი ფარულ რისკებს ავლენს, რომელთა აღმოჩენა სტატიკური ანალიზით ვერ მოხერხდა.
კეისი: OpenTelemetry CVE‑2023‑43810
ოფიციალური CVE (CVE‑2023‑43810) მოიცავდა OpenTelemetry-ს, ფართოდ გამოყენებულ ღია კოდის ტელემეტრიულ ჩარჩოს. ავტომატური ინსტრუმენტაციის დროს, HTTP მეთოდის ეტიკეტები გენერირდებოდა შეუზღუდავი კარდინალით. თავდამსხმელებმა ეს გამოიყენა უკიდურესად გრძელი ან შემთხვევითი შემცველი ხელოვნური მოთხოვნების გაგზავნით. http_მეთოდი მნიშვნელობები, რაც იწვევს მეხსიერების ამოწურვას და სერვერებში მომსახურების უარყოფის პოტენციურ რისკს. datatracker.ietf.org+15nvd.nist.gov+15ntop.org+15.
მიუხედავად იმისა, რომ სტატიკური ანალიზის ხელსაწყოებმა OpenTelemetry პოტენციურად სარისკო დამოკიდებულებად აღნიშნეს, მათ არ შეეძლოთ გაშვების დროს ზემოქმედების შეფასება. ამის საპირისპიროდ, ღრმა პაკეტების შემოწმებისას დაფიქსირდა:
- უჩვეულოდ გრძელი HTTP მეთოდების სახელები რეალურ ტრაფიკში.
- მაღალი სიხშირის ან არასწორად ფორმირებული მეთოდის ნიმუშები მეხსიერების გამოყენებაში იზრდება.
- საეჭვო DNS ან HTTP მიმართულებები, როდესაც მოხდა ექსფილტრაცია ან DoS.
მხოლოდ DPI-მ მოგვაწოდა ექსპლოიტის გაშვებისას დამადასტურებელი საბუთი; სტატიკურ ინსტრუმენტს კი ეს არ შეეძლო. ეს აჩვენებს, თუ როგორ გარდაქმნის DPI ორაზროვან დამოკიდებულების შეტყობინებებს შეტევის ზედაპირის მართვისთვის ქმედით ინტელექტად.
მავნე ტელემეტრია ღია კოდის SDK-ებში
კიდევ ერთ გავრცელებულ სცენარში, ღია კოდის SDK-ები ჩადებენ ტელემეტრიის კოდს, რომელიც მომხმარებლის ან გარემოს მონაცემებს გარე სერვისებს უგზავნის, ზოგჯერ დაუდასტურებელი ან დაუმტკიცებელი სახით.
სტატიკურმა ხელსაწყოებმა შესაძლოა პოტენციური გამავალი ზარების არსებობა აღნიშნონ, მაგრამ მათ არ შეუძლიათ დაადასტურონ, ოდესმე განხორციელდება თუ არა ეს ზარები. თუმცა, DPI აფიქსირებს:
- SDK-დან გამავალი რეალურ დროში HTTP ან gRPC მოთხოვნები.
- კონვერტის შიგთავსი, მათ შორის სათაურები და დატვირთვა, რომელიც აჩვენებს გაგზავნილ მონაცემებს.
- დაუმტკიცებელი საბოლოო წერტილის დომენები, მაშინაც კი, როდესაც ტრაფიკი დაშიფრულია TLS-ის მეშვეობით.
DPI-ის დატვირთვის დონის ანალიზი ადასტურებს და აკავშირებს ტელემეტრიის ქცევას კონკრეტულ სერვისთან ან ბიბლიოთეკასთან. ეს ბუნდოვან გაფრთხილებებს წინასწარ გადააქცევს.cisელექტრონული შეტევის ზედაპირის მართვის მოქმედებები: ბლოკირება, განგაში ან აუდიტი.
რატომ არის ეს მნიშვნელოვანი
ეს მაგალითები ტრადიციულ AppSec-ში არსებულ კრიტიკულ ხარვეზს ხაზს უსვამს:
- SAST/SCA აფრთხილებს სარისკო დამოკიდებულებების ან დაუცველობების შესახებ, მაგრამ ვერ ადასტურებს გაშვების დროს გამოყენებას ან მათზე გავლენას.
- ღრმა პაკეტების შემოწმება, DPI განმარტების მეშვეობით, უზრუნველყოფს ფაქტობრივი ქცევის ხილვადობას, მაშინაც კი, როდესაც ტრაფიკი დაშიფრულია ან დაბნეულია.
ეს კომბინაცია გუნდებს საშუალებას აძლევს, ვარაუდებზე დაფუძნებული უსაფრთხოებიდან გადავიდნენ გაშვების დროზე ცნობიერ დაცვაზე. DPI რეალურ რისკს ავლენს, ამიტომ თქვენ შეგიძლიათ წინასწარ მართოთ თქვენი შეტევის ზედაპირი.cisიონი და ფოკუსირება იმაზე, რაც არის გამოსაყენებელი, არა მხოლოდ თეორიული.
DPI-ს ჩასმა CI/CD Pipeline
სად ჯდება თქვენს სამუშაო პროცესში ღრმა პაკეტების შემოწმება? CI/CD საქმე ეხება სიჩქარეს და დადასტურებულ მიწოდებას, მაგრამ დადასტურება არ შეიძლება შეჩერდეს კოდის ანალიზით. DPI თქვენი რამდენიმე ეტაპზეა გათვლილი. pipeline:
- Დადგმაგანათავსეთ სერვისები DPI აგენტებით ან გვერდითი მანქანებით, რომლებიც რეალურ დროში ტრაფიკს აღრიცხავენ.
- განლაგების შემდგომიგაშვებამდე, აპლიკაციის ქცევა რეალისტურ გარემოში მუდმივად აკონტროლეთ.
- უსაფრთხოების ვალიდაციადარწმუნდით, რომ სერვისები მხოლოდ დამტკიცებულ დანიშნულების ადგილებთან დაუკავშირდებიან დაშვებული პროტოკოლების გამოყენებით.
ინტეგრაციის მაგალითები დეველოპერებისთვის
- GitHub მოქმედებებიდაამატეთ თქვენს სამუშაო პროცესში დავალების ეტაპი, რომელიც განათავსებს სატესტო კონტეინერს ჩართული DPI-ით (მაგ., ისეთი ინსტრუმენტით, როგორიცაა Suricata ან ღრუბლოვანი DPI სერვისი) ინტეგრაციის ტესტების დროს თქვენი აპლიკაციიდან გამავალი ტრაფიკის მონიტორინგისთვის.
- GitLab CI: გამოიყენეთ ა მომსახურება: დეკლარაცია, რათა DPI კონტეინერი გაუშვათ თქვენი აპლიკაციის პარალელურად ეტაპობრივად და ტესტირების შემდეგ გააანალიზოთ ტრაფიკის ჟურნალები უცნობი დომენების ან უბრალო ტექსტის პროტოკოლების მონიშვნის მიზნით.
- Jenkinsდაამატეთ აწყობის შემდგომი ნაბიჯი, რომელიც ამუშავებს DPI ზონდს სატესტო სახელთა სივრცეში (მაგ., Kubernetes Job-ის ან Docker Compose-ის საშუალებით) და ჩაშალეთ აწყობა, თუ ტრაფიკი გადახრილია თქვენს მიერ გამოცხადებული მომსახურების კონტრაქტიდან.
რეალური დადგმის სცენარი
წარმოიდგინეთ, რომ თქვენი Node.js აპლიკაცია იმპორტირებს მესამე მხარის ანალიტიკის SDK-ს. ეტაპობრივად, DPI აფიქსირებს გამავალ ტრაფიკს api.untrusted-telemetry.com, დომენი, რომელიც არ არის ჩამოთვლილი თქვენი სერვისის დაშვებულთა სიაში. სტატიკურმა ხელსაწყოებმა ის ვერ დაიჭირეს, რადგან SDK იყენებდა დაბნეულ დინამიურ იმპორტს. თუმცა DPI-მ რეალურ დროში გამოავლინა პირდაპირი მოთხოვნა.
სწორედ აქ არის ჩადებული ღრმა პაკეტების შემოწმება CI/CD, თეორიას აღმოჩენად აქცევს. ის აწესებს გაშვების დროს დაფუძნებულ შეტევის ზედაპირის მართვას, სანამ თქვენი აპლიკაცია წარმოებაში გავა.
რეალური რისკის სცენარები, რომლებსაც მხოლოდ DPI დაიჭერს
ღრმა პაკეტების შემოწმება ავლენს ქცევაზე დაფუძნებულ რისკებს, რომელთა აღმოჩენა სტატიკურ ინსტრუმენტებს უბრალოდ არ შეუძლიათ, მათ შორის:
- ღია კოდის ტელემეტრია ჩუმად აგზავნის ანალიტიკას.
- მყარი კოდირებული API საბოლოო წერტილები კარიბჭის აღსრულების გვერდის ავლით.
- არასწორად კონფიგურირებული პროტოკოლები (მაგ., HTTP-ის გამოყენება, სადაც HTTPS საჭიროა).
- არაავტორიზებული მონაცემების ატვირთვა გარე API-ებისთვის.
ეს რისკები თქვენს საწყის კოდში არ არის; ისინი გაშვების დროს ჩნდება. დეველოპერის მაგალითი:
ეტაპობრივად, DPI ჟურნალებმა გამავალი POST აღნიშნეს. მოთხოვნა api.untrusted-telemetry.com. APM-ის მეშვეობით კორელაციამ მიუთითა ანალიტიკა. js მოდულში მომხმარებლის აქტივობის ტრეკერიეს არ დაფიქსირებულა SCA რადგან ბიბლიოთეკა იყენებდა დინამიურ იმპორტს და დაბნეულ ლოგიკას.
მხოლოდ DPI-მ, კვალის მეტამონაცემებთან ერთად, გამოავლინა წყარო და გუნდს საშუალება მისცა, წაეშალა შემაწუხებელი SDK. ეს არის რეალურ დროში ხილვადობა, რომელიც რეალურ კოდზეა მიბმული, რაც გადამწყვეტია გაშვების დროს მართული შეტევის ზედაპირის მართვისთვის.
კოდისა და ტრაფიკის გაერთიანება რეალური გაშვების დროის ანალიზისთვის
გაშვების დროის ჟურნალები შეზღუდულია, თუ მათი წყარომდე მიყვანა შეუძლებელია.
ღრმა პაკეტების შემოწმების დასტის ტრასებთან ან APM ინსტრუმენტებთან შერწყმა ხილვადობის ხარვეზის აღმოფხვრას უწყობს ხელს:
- DPI ჟურნალები აჩვენეთ „რა“, კავშირი დამყარდა, სად და რომელი პროტოკოლის გამოყენებით.
- APM ან ტრასირების მეტამონაცემები აჩვენებს „როგორ“ და „რატომ“, რომელმა ფუნქციამ ან მოდულმა გამოიწვია ეს ქცევა.
ეს რუკა ნედლ ტრაფიკს ქმედით ანალიზად აქცევს. მაგალითი:
„DPI-მ მონიშნა მოულოდნელი ტრაფიკი analytics.shadowvendor.io. APM-მა აჩვენა, რომ ზარი წარმოიშვა ანალიტიკა. js იმ მარკეტინგული SDK მოდული, რომელიც გამოიძახება ფუნქციის დროშის მეშვეობით მომხმარებლის რეგისტრაციის დროს.
ამ სიცხადით, თქვენ არა მხოლოდ ამჩნევთ რისკს; შეგიძლიათ წინასწარ გამოასწოროთ იგი.cisely. სწორედ ეს არის DPI-სა და დაკვირვებადობის შერწყმის ძალა შეტევის ზედაპირის ეფექტური, რეალურ დროში მართვისთვის.
DevSecOps-თან თავსებადი: Shift-მარცხენიდან Shift-Wire-მდე
"მარცხნივ გადაწევა”არის standardმაგრამ გუნდების უმეტესობას ავიწყდება მავთულის გადაწევა, პაკეტების ღრმა შემოწმებას შემუშავების ადრეულ ეტაპებზეც შეიტანს და არა მხოლოდ გაშვების ოპერაციებში.
აი, როგორ უჭერს მხარს DPI ამ ცვლილებას:
- წინასწარ განსაზღვრეთ მომსახურების კონტრაქტები: ჩამოთვალეთ დაშვებული მიმართულებები, პროტოკოლები და ქცევები. ეს არ არის მხოლოდ ქსელის წესები; ეს არის უსაფრთხოების მოლოდინები.
- გამოიყენეთ სინთეტიკური ტრაფიკი ეტაპობრივად: ჩაატარეთ ტესტები და შეაგროვეთ DPI ჟურნალები თქვენი კონტრაქტის მიმართ ფაქტობრივი ქცევის დასადასტურებლად.
- ქცევითი დრიფტის ადრეული აღმოჩენაფუნქციების დროშებმა, კონფიგურაციის ცვლილებებმა ან განახლებებმა შეიძლება გამოიწვიოს ტრაფიკის ახალი ნიმუშები. DPI ავლენს მათ წარმოებამდე.
ეს DPI-ს არა მხოლოდ რეაქტიულ მონიტორად, არამედ თქვენი AppSec ტესტირების პროაქტიულ ნაწილად აქცევს. pipelineეს არის ინსტრუმენტი დადასტურებისთვის, აღსრულებისა და ხილვადობისთვის, ისევე როგორც SAST or SCAადრეულ ეტაპზე ინტეგრირების შემთხვევაში, DPI აძლიერებს თქვენს უსაფრთხოების პოზიციას და ამცირებს შეტევის ზედაპირის მართვაში არსებულ ხარვეზს.
DPI-ით გაშვების დროის გათვალისწინებით შეტევის ზედაპირის მართვა
ტრადიციული შეტევის ზედაპირის მართვა (ASM) ეყრდნობა სტატიკურ ინვენტარიზაციას, დომენების სიებს, სერვისებს, საბოლოო წერტილებსა და დამოკიდებულებებს. მიუხედავად იმისა, რომ სასარგებლოა, ეს მოდელი ვარაუდობს, რომ აპლიკაცია იქცევა ზუსტად ისე, როგორც არის შექმნილი. ის არ ითვალისწინებს, თუ როგორ იცვლება პროგრამული უზრუნველყოფა დინამიურად წარმოებაში.
სწორედ აქ ერთვება საქმეში გაშვების დროს გათვალისწინებული შეტევის ზედაპირის მართვა.
ზედაპირის ფართობის კოდში ან კონფიგურაციებში არსებული მონაცემების მიხედვით მართვის ნაცვლად, ის მას თქვენი აპლიკაციის გაშვებისას ქცევის მიხედვით მართავს. ეს მიდგომა იყენებს პაკეტების ღრმა შემოწმებას შემდეგი მონაცემების დასადგენად:
- რომელი სერვისები რომელ დომენებთან აკავშირებენ?
- რა პროტოკოლები გამოიყენება?
- არღვევს თუ არა რომელიმე ტრაფიკი თქვენს მიერ განსაზღვრულ მოლოდინებს.
ეს არ არის თეორიული ექსპოზიცია, ეს არის რეალური, დაკვირვებული ქცევა.
ძირითადი განსხვავება:
- ტრადიციული ASM = „ეს სერვისი“ უნდა მხოლოდ X-თან დაკავშირება.”
- Runtime-aware ASM = „ეს სერვისი“ is ასევე მოულოდნელად უკავშირდება Y-სა და Z-ს.”
ინტეგრირებული DPI-ით, თქვენ მიიღებთ:
- არასწორი კონფიგურაციები.
- უსაფრთხოების პოლიტიკიდან გადახვევა.
- კოდში არ ჩანს მესამე მხარის ჩუმი ქცევები.
ქცევითი დაკვირვებისკენ ეს გადასვლა აუცილებელია თანამედროვე AppSec-ისთვის. ის უზრუნველყოფს, რომ თქვენი შეტევის ზედაპირის მართვა არ შემოიფარგლება მხოლოდ განზრახვების რუკებით; ეს ეხება გაშვების დროს მიმდინარე მოვლენების კონტროლს.
DPI თქვენს DevSecOps სტეკში
ღრმა პაკეტების შემოწმება არ ცვლის თქვენს ინსტრუმენტებს; ის აფართოებს მათ გაშვების დროის ცნობიერებით და წინასწარი შემოწმებით.cisიონი თქვენ შეგიძლიათ DPI-ს ინტეგრირება თქვენს სტეკში შემდეგი გზით:
- DPI მოვლენების SIEM პლატფორმებზე გადატანა ლოგებთან და ქცევით შეტყობინებებთან კორელაციის მიზნით.
- DPI მონაცემების DAST-ში შეტანა შეტევის გზების წარმართვისა და რეალურ სამყაროში გამოყენების სიმულირებისთვის.
- DPI აგენტების განლაგება თქვენს GitOps-ზე დაფუძნებულ გარემოში, როგორიცაა ეტაპობრივი ან საწარმოო Kubernetes კლასტერები, გამავალი ქცევის უწყვეტი დაკვირვების მიზნით.
DPI vs. Firewalls: რა განსხვავებაა?
მნიშვნელოვანია გვესმოდეს: DPI არ არის firewall.
- firewall აწესებს ორობით დეველოპერულ პროგრამებს.cisიონები: დაბლოკვა ან დაშვება წინასწარ განსაზღვრული წესების (მაგ., პორტების, IP მისამართების, პროტოკოლების) საფუძველზე.
- DPI, მეორე მხრივ, ამოწმებს ტრაფიკს კონტექსტური დაკვირვების უზრუნველსაყოფად. ის არა მხოლოდ ამბობს „ეს პაკეტი დაშვებულია“, არამედ აჩვენებს:
- რა გაიგზავნა?
- ვინ იყო მისი ინიციატორი?
- შეესაბამება თუ არა კონტენტი ან დანიშნულების ადგილი პოლიტიკას.
- რა გაიგზავნა?
მაგალითად:
- firewall-მა შეიძლება HTTPS ტრაფიკის გამოყენების უფლება მისცეს *.external.com.
- DPI-ს შეუძლია გამოავლინოს, რომ მესამე მხარის ანალიტიკური SDK უგზავნის მომხმარებლის ID-ებს track.external.com, დომენი, რომელიც არასდროს გადაგიხედავთ ან არ დაგიმტკიცებიათ.
სწორედ ეს დაკვირვებადობა იძლევა შეტევის ზედაპირის მართვის საშუალებას გაშვების დროის გათვალისწინებით, რაც სრულ სურათს გაძლევთ და არა მხოლოდ წვდომის კონტროლს.
თანამედროვე DevSecOps-ში DPI დინამიური ვალიდაციის ფენად იქცევა, რომელიც ამოწმებს, შეესაბამება თუ არა ქცევა განზრახვას და ადრეულ ეტაპზევე ავლენს რისკებს. pipeline მიწოდების შენელების გარეშე.
რეალურ დროში საფრთხის აღმოჩენა DPI-ს მეშვეობით
განლაგების შემდეგ, DPI წარმოადგენს გაშვების დროს დაცვის ძირითად ნაწილს:
- HTTPS-ის ან TLS-ის საშუალებით მონაცემთა ექსფილტრაციის აღმოჩენა.
- კომპრომეტირებული პაკეტებიდან შუქურის ქცევის იდენტიფიცირება.
- არაავტორიზებული API საბოლოო წერტილების მეშვეობით შიდა სერვისის ბოროტად გამოყენების გამოვლენა.
IP მისამართების დამბლოკავი firewall-ებისგან განსხვავებით, ღრმა პაკეტების შემოწმება აანალიზებს ქცევას. შეტევის ზედაპირის მართვის საშუალებით, თქვენ აღმოაჩენთ საფრთხეებს აპლიკაციის რეალური ქცევის საფუძველზე და არა მხოლოდ დაბლოკილი მისამართების საფუძველზე.
რატომ აღარ არის კოდის ხილვადობა საკმარისი
ინდუსტრიამ გადააჭარბა მხოლოდ სტატიკურ აპლიკაციებზე დაფუძნებულ AppSec-ს. SAST მდე SCA ისინი ცხრილის ფსონებია, მაგრამ ისინი ვერ ხედავენ გაშვების დროს. თანამედროვე რისკები მხოლოდ რეალურ დროში ვლინდება: პაკეტების ზარები სახლში, მოულოდნელი საბოლოო წერტილები ან პროტოკოლის პოლიტიკის დარღვევები. სტატიკური ხელსაწყოები ვერ პასუხობენ ამ კითხვებს. ღრმა პაკეტების შემოწმება ავსებს ამ ხარვეზს ფაქტობრივი ტრაფიკის შემოწმებით, ხოლო განმარტებითი DPI განსაზღვრავს მოსალოდნელ ქცევას. ეს შეტევის ზედაპირის მართვას ვარაუდებზე დაფუძნებულიდან მტკიცებულებებზე დაფუძნებულზე გადააქცევს. როდესაც სწრაფად აშენებთ და ხშირად ახორციელებთ განათავსებას, გჭირდებათ რეალურ დროში მავთულის ხილვადობა და არა მხოლოდ კოდის სკანირება.
DPI + Xygeni: Runtime-Aware AppSec პრაქტიკაში
პლატფორმების მსგავსად ქსიგენი პაკეტების ღრმა შემოწმება კიდევ უფრო გააფართოვეთ მისი თქვენს AppSec სტეკში ჩასმით, რომელიც გაშვების დროს იქნება გათვლილი და დეველოპერებისთვის მოსახერხებელი. საქმე მხოლოდ დაკვირვებადობას არ ეხება, საქმე ავტომატიზირებულ აღმოჩენასა და აღსრულებაშია.
როგორ მუშაობს ტექნიკურად:
- Xygeni მსუბუქ აგენტებს იყენებს ეტაპობრივ ან საწარმოო გარემოში ქსელის ქცევის აღსაწერად.
- ეს აგენტები ხელს უწყობენ ცენტრალიზებული ჟურნალი pipeline, რომელიც აკავშირებს ტრაფიკს სერვისებთან და კომპონენტებთან.
- Xygeni-ს ასევე შეუძლია ინტეგრირება არსებულ ქსელურ ინსტრუმენტებთან, მაგ., ღრუბლოვანი firewall-ის ჟურნალები, სერვისების ბადეები ან eBPF ინსტრუმენტაცია, DPI ხილვადობის გასაუმჯობესებლად თქვენი სტეკის დარღვევის გარეშე.
რეალური პოლიტიკა მოქმედებაში:
Xygeni აფიქსირებს, როდესაც სერვისი ცდილობს დაუკავშირდეს არადამტკიცებულ დომენს, რომელიც მისი მომსახურების კონტრაქტის გარეთაა ჩამოთვლილი. თუ ეს მოხდება ეტაპობრივი ვერსიის დროს, ის აღნიშნავს მოვლენას და თუ კონფიგურირებულია, ავტომატურად ბლოკავს განლაგებას.
ეს გაშვების დროის გათვალისწინებით გათვალისწინებული უკუკავშირის ციკლი თქვენი შეტევის ზედაპირის მართვას პოლიტიკაზე ორიენტირებულს და აღსრულებისთვის მზადს ხდის.
ერთად Xygeni + DPIთქვენ შეგიძლიათ:
- დაუცველობების კვალის დადგენა რეალური შესრულების გზებამდეCVE-ები კონტექსტუალიზებულია გამოყენების მიხედვით.
- დააფიქსირეთ პირდაპირი ტელემეტრია ან მონაცემთა გაჟონვარეალურ დროში გამავალი ტრაფიკი მის საწყის წერტილში არის მითითებული.
- ქსელური კონტრაქტების ავტომატურად აღსრულებამხოლოდ დამტკიცებული დანიშნულების ადგილები და პროტოკოლებია დაშვებული; სხვები დაბლოკილი ან დროშით მონიშნულია.
- დაადასტურეთ, რა გამორჩათ სტატიკური ხელსაწყოებიდანსტატიკური დროშები მოქმედებადი ხდება მხოლოდ იმ შემთხვევაში, თუ გაშვების დროს DPI დაადასტურებს მათ გამოყენებას.
რატომ არის ეს მნიშვნელოვანი: დეველოპერებს არ აქვთ დრო, რომ ცრუ დადებითი შედეგები აკონტროლონ. Xygeni უზრუნველყოფს რეალურ დროში, ქცევაზე დაფუძნებულ დადასტურებას DPI-ის ანალიზით, რომელიც პირდაპირ გავლენას ახდენს დეველოპერებზე.cisიონები, რომლებიც უზრუნველყოფენ თქვენს pipeline.
დასკვნითი აზრები: სწრაფი მიწოდება, მკაცრი მონიტორინგი
დეველოპერები სწრაფად მოძრაობენ და უსაფრთხოებაც ასევე უნდა იყოს სწრაფი. დაამატეთ თქვენს სისტემაში პაკეტების ღრმა შემოწმება. pipeline, რომელსაც მხარს უჭერს მკაფიოდ განსაზღვრული DPI პოლიტიკა და შეტევის ზედაპირის ძლიერი მართვა. სტატიკური სკანირება მნიშვნელოვანია, მაგრამ უფრო მნიშვნელოვანია ის, თუ რას აკეთებს თქვენი აპლიკაცია ქსელში. დაიცავით არა მხოლოდ ის, რაც დაწერეთ, არამედ ის, თუ როგორ იქცევა ის. ეს არის DevSecOps AppSec-ის მომავალი.
