deep packet inspection - အဓိပ္ပါယ်ဖွင့်ဆိုချက် dpi - တိုက်ခိုက်မှုမျက်နှာပြင်စီမံခန့်ခွဲမှု

Deep Packet Inspection နှင့် AppSec ဆုံတွေ့ခြင်း- Code တွင် မမြင်နိုင်သော အန္တရာယ်များကို ရှာဖွေခြင်း

မာတိကာ

မဖြစ်မနေဖတ်သင့်သောပို့စ်များ

စိတ်ဝင်စားဖွယ်ကောင်းသော နောက်ဆုံးပို့စ်များ

Static Scanning ထက်ကျော်လွန်၍- ကုဒ်ကိုသာမဟုတ်ဘဲ ဝါယာကြိုးကိုကြည့်ပါ

မင်းက ခေတ်မီတဲ့အိမ်တစ်လုံးကို တည်ဆောက်ခဲ့တယ် CI/CD pipelineသင့်ကုဒ်ကို ခွင့်ပြုပါသည် SAST နှင့် SCA စကင်ဖတ်နေတယ်။ အရာအားလုံးက အစိမ်းရောင်ပါ။ ဒါပေမယ့် ထုတ်လုပ်မှုမှာ ဒေတာတွေက ပြင်ပဆာဗာတစ်ခုဆီ ပေါက်ကြားလာပါတယ်။ ဘာဖြစ်သွားတာလဲ။ ဒါက သီအိုရီဆိုင်ရာ ပြဿနာ မဟုတ်ပါဘူး။ အဖြစ်များပါတယ်။ ရိုးရာ AppSec ကိရိယာတွေလို SAST နှင့် SCA ကုဒ်အဆင့်မှာ အလုပ်လုပ်ပါတယ်။ သူတို့က syntax၊ dependency tree တွေနဲ့ vulnerabilities တွေကို ခွဲခြမ်းစိတ်ဖြာပေမယ့် သင့်အက်ပ်ကို ဖြန့်ကျက်ပြီးတာနဲ့ ဘယ်လိုလုပ်ဆောင်လဲဆိုတာကို မဖမ်းယူပါဘူး။ အဲဒါက မျက်ကွယ်ပြုထားတဲ့နေရာပဲ။

open-source package သို့မဟုတ် dynamic SDK သည် runtime network activity၊ outbound telemetry၊ hardcoded API calls သို့မဟုတ် silent data leaks များကို စတင်နိုင်သည်။ Code scanning tools များသည် ၎င်းကို မမြင်နိုင်ပါ။ ဤနေရာတွင် deep packet inspection (DPI) သည် ကွက်လပ်ကို ဖြည့်ဆည်းပေးပါသည်။ code ဘာလုပ်နိုင်သည်ကို ခန့်မှန်းမည့်အစား DPI သည် ၎င်းဘာလုပ်သည်ကို wire ပေါ်တွင် ပြသသည်။

ယနေ့ခေတ်တွင် အပလီကေးရှင်းလုံခြုံရေးသည် ကုဒ်ထက်ကျော်လွန်ရမည်။ ခေတ်မီတိုက်ခိုက်မှုမျက်နှာပြင်စီမံခန့်ခွဲမှုနှင့် တင်းကျပ်စွာပေါင်းစပ်ထားသော DPI မှတစ်ဆင့် Runtime observability သည် ရွေးချယ်နိုင်ခြင်းမရှိတော့ပါ။ ၎င်းသည် တကယ့်ခြိမ်းခြောက်မှုများကို အချိန်နှင့်တပြေးညီ ထောက်လှမ်းတုံ့ပြန်လိုသော မည်သည့် AppSec ဗျူဟာ၏ အရေးကြီးသော အစိတ်အပိုင်းတစ်ခုဖြစ်သည်။

DPI ၏ အဓိပ္ပါယ်ဖွင့်ဆိုချက်- Deep Packet Inspection ဆိုသည်မှာ အဘယ်နည်း။

စာအုပ်ထဲက DPI ဆိုတဲ့ အဓိပ္ပာယ်ဖွင့်ဆိုချက်ကို မေ့လိုက်ပါ။ AppSec ရဲ့ ရှုထောင့်အရ deep packet inspection ဆိုတာ ရိုးရာ network monitoring ထက် ကျော်လွန်သွားခြင်းကို ဆိုလိုပါတယ်။ source, destination နဲ့ protocol လိုမျိုး header တွေကိုပဲ စစ်ဆေးမယ့်အစား DPI က application traffic အတွင်းမှာ ဘာတွေဖြစ်နေလဲဆိုတာ နားလည်ဖို့ packet တစ်ခုချင်းစီရဲ့ တကယ့် payload ကို စစ်ဆေးပါတယ်။

အခြေခံကိရိယာများသည် “ဤသည်မှာ ဝန်ဆောင်မှု A မှ ဝန်ဆောင်မှု B သို့ HTTP တောင်းဆိုမှုတစ်ခုဖြစ်သည်” ကို ဖော်ထုတ်ရာတွင် ရပ်တန့်သွားသည့်နေရာတွင် DPI သည် ပိုမိုနက်ရှိုင်းစွာ တူးဖော်ထားသည်-

  • ၎င်းသည် HTTP အကြောင်းအရာအပြည့်အစုံ၊ နည်းလမ်းများ၊ parameters များနှင့် data များကို ဖတ်သည်။
  • ၎င်းသည် gRPC payloads များကို decode လုပ်၍ method calls များနှင့် data structures များကို ပြသသည်။
  • ၎င်းသည် သံသယဖြစ်ဖွယ်ဒိုမိန်းများ သို့မဟုတ် မေးမြန်းမှုပုံစံများအတွက် DNS မေးမြန်းချက်များကို ခွဲခြမ်းစိတ်ဖြာသည်။

ဤပိုမိုနက်ရှိုင်းသော စစ်ဆေးခြင်းသည် သင့်အား အောက်ပါတို့ကို လုပ်ဆောင်နိုင်စေသည်-

  • ရှင်းလင်းသော စာသားလျှို့ဝှက်ချက်များ သို့မဟုတ် အထောက်အထားများကို ထောက်လှမ်းပါ။
  • ကုဒ်ဝှက်ထားသော ချန်နယ်များမှတစ်ဆင့်ပင် ထည့်သွင်းထားသော စိမ့်ဝင်မှုကြိုးပမ်းမှုများကို ရှာဖွေပါ။
  • ခွင့်ပြုချက်မရှိဘဲ ပြင်ပဆက်သွယ်ရေးကြိုးပမ်းမှုများကို ဖမ်းယူပါ။

ပြီးတော့ အရေးကြီးတာက ဒါက ကွန်ရက်ချိတ်ဆက်မှုကိရိယာတစ်ခုတင် မဟုတ်ပါဘူး။ ခေတ်မီ AppSec ဗျူဟာတစ်ခုမှာ DPI ဟာ static analysis လိုပဲ အရေးကြီးပါတယ်။ ဒါက လုံခြုံရေးအဖွဲ့တွေကို application behavior ရဲ့ runtime အထောက်အထားကို ပေးစွမ်းပြီး တကယ့်ဒေတာနဲ့ အခြေခံယူဆချက်တွေကို ပေးစွမ်းကာ ပိုမိုတိကျပြီး behavior-driven attack surface management ကို အားကောင်းစေပါတယ်။

အပလီကေးရှင်းလုံခြုံရေးအတွက် DPI ၏ထူးခြားသောတန်ဖိုး

နက်ရှိုင်းသောပက်ကက်စစ်ဆေးခြင်း (DPI) ၎င်းသည် သင့်အပလီကေးရှင်းများ၏ တကယ့် runtime အပြုအမူကို စောင့်ကြည့်သောကြောင့် static tools များ မပေးနိုင်သော မြင်သာမှုကို ပေးစွမ်းသည်။
တူရိယာများ SAST နှင့် SCA ကုဒ်နှင့် metadata နယ်ပယ်တွင် လုပ်ဆောင်ကြသည်။ ၎င်းတို့သည် syntax၊ dependency tree များနှင့် သိရှိထားသော အားနည်းချက်များကို ခွဲခြမ်းစိတ်ဖြာကြသည်။ သို့သော် သင့် application စတင်လည်ပတ်သည်နှင့် ဘာတွေဖြစ်လာမလဲဆိုတာကို သူတို့မမြင်နိုင်ကြပေ- logic သည် live traffic အဖြစ်သို့ ပြောင်းလဲသွားချိန်နှင့် အန္တရာယ်များသည် အလားအလာမှ တကယ့်အခြေအနေသို့ ပြောင်းလဲသွားချိန်။
DPI သည် တိုက်ရိုက်အသွားအလာကို စစ်ဆေးသည်။ ၎င်းသည် header များကိုသာမက network payload များကိုပါ ပိုင်းခြားစိတ်ဖြာပြီး HTTP၊ gRPC နှင့် DNS ကဲ့သို့သော application-layer protocol များကို အပြည့်အဝ အသေးစိတ် ခွဲခြမ်းစိတ်ဖြာနိုင်စေပါသည်။ ၎င်းသည် code level တွင် မမြင်ရသော သိမ်မွေ့သော မသင့်လျော်သော အပြုအမူများကို ရှာဖွေတွေ့ရှိနိုင်စေပါသည်။
AppSec မှာ deep packet inspection က ဘာတွေထူးခြားစွာဖော်ပြနေလဲဆိုတာ ဒီမှာပါ။

ပြည်တွင်းဆက်သွယ်ရေးတွင် ပရိုတိုကော အလွဲသုံးစားမှု
ပြင်ပကနေ TLS ကို အကောင်အထည်ဖော်နိုင်ပေမယ့် service-to-service traffic ကော။ DPI က ထိန်းညှိထားတဲ့ပတ်ဝန်းကျင်မှာတောင် internal microservices တွေက plaintext HTTP ကို ​​ပြန်သုံးတဲ့ကိစ္စတွေကို ဖော်ထုတ်ပေးပါတယ်။ static tools တွေက မသိရှိနိုင်ပေမယ့် deep packet inspection ကတော့ မသိရှိနိုင်ပါဘူး။

ခြိမ်းခြောက်ခံရသော ပြင်ပအဖွဲ့အစည်းပက်ကေ့ဂျ်များမှ C2 Beaconing
အန္တရာယ်ရှိသော npm၊ PyPI သို့မဟုတ် Maven package တွင် remote C2 server သို့ ပုံမှန် ping များပေးပို့သည့် logic ပါဝင်နိုင်သည်။ DPI သည် ဤနိမ့်သောကြိမ်နှုန်း၊ ပုံစံရှိသောခေါ်ဆိုမှုများနှင့် encrypted ခေါ်ဆိုမှုများကိုပင် ထောက်လှမ်းသည်။ ၎င်းသည် သံသယဖြစ်ဖွယ်အချိန်အပိုင်းအခြားများ သို့မဟုတ် သင်ခွင့်ပြုထားသော outbound list ပြင်ပရှိ domain များကို အလံပြသည်။

မမျှော်လင့်ထားသော ပြင်ပချိတ်ဆက်မှုများ
သင့်အက်ပ်သည် သိရှိထားသော API များနှင့်သာ စကားပြောသင့်သည့်တိုင် developer သည် endpoint တစ်ခုကို hardcode လုပ်နိုင်သည်၊ သို့မဟုတ် third-party library သည် သင်မစစ်ဆေးထားသော telemetry call များကို ထည့်သွင်းနိုင်သည်။ DPI သည် သင့်အား live traffic ကို ကြေငြာထားသော ဝန်ဆောင်မှုနယ်နိမိတ်များနှင့် နှိုင်းယှဉ်ပြီး ချိုးဖောက်မှုများကို ချက်ချင်း flag လုပ်နိုင်သည်။

အဘယ်ကြောင့်အရေးပါ:
DPI က ခန့်မှန်းချက်တွေကို အချက်အလက်တွေနဲ့ အစားထိုးပါတယ်။ “ဒီကုဒ်က အန္တရာယ်ရှိနိုင်လား” ဆိုတာကို မသုံးဘဲ၊ အန္တရာယ်ဟာ packet တွေထဲမှာ ပေါ်လာတာကို မြင်ရပါတယ်။ AppSec ကို reactive ကနေ proactive ကို ပြောင်းလိုက်ပါတယ်။

  • CVE database တွေကိုပဲ မှီခိုနေတာ ရပ်လိုက်ပါ။
  • ကုဒ်က အဆင်ပြေတယ်လို့ ထင်ရရုံနဲ့ network layer က လုံခြုံတယ်လို့ မယူဆတော့ပါဘူး။

မင်းစတင်စီမံခန့်ခွဲတယ် တကယ့်တိုက်ခိုက်မှုမျက်နှာပြင်သီအိုရီဆိုင်ရာ မဟုတ်ပါဘူး။
အဆုံးစွန်အားဖြင့်၊ deep packet inspection သည် အဖွဲ့များအား အာရုံစိုက်နိုင်စေသည်- အက်ပ်က ဘာလုပ်နေတာလဲdeveloper တွေတင်မကဘူး ရည်ရွယ်။အဲဒါက အပြုအမူကို သတိပြုပြီး ကာကွယ်ရေးနဲ့ ခေတ်မီတဲ့ တိုက်ခိုက်ရေးမျက်နှာပြင်စီမံခန့်ခွဲမှု လှုပ်ရှားမှု၌တည်၏။

ရိုးရာ AppSec နည်းလမ်းများရှိ မျက်ကွယ်ပြုထားသောနေရာများ

ရိုးရာ AppSec ကိရိယာများ၊ ဥပမာ SAST နှင့် SCAကုဒ်၊ ဖွဲ့စည်းပုံနှင့် လူသိများသော အားနည်းချက်များကို အာရုံစိုက်ပါ။ ၎င်းတို့သည် မလုံခြုံသော ပုံစံများနှင့် ခေတ်မမီတော့သော မှီခိုမှုများကို ရှာဖွေရာတွင် ကောင်းမွန်သော အလုပ်တစ်ခု လုပ်ဆောင်နိုင်သော်လည်း runtime view မရှိပါ။ ၎င်းသည် ပြဿနာတစ်ခုဖြစ်သည်။ အကြောင်းအရာမရှိပါက သင့်ကုဒ်၏ အဓိပ္ပာယ်ကို သင်လွတ်သွားပါလိမ့်မည်။ .
အဖြစ်များသော မျက်ကွယ်နေရာများ-

အသုံးမပြုသော အားနည်းချက်ရှိသော ကုဒ်လမ်းကြောင်းများ

မှီခိုမှုတွင် ပါဝင်နိုင်သည် CVEဒါပေမယ့် function ကို ဘယ်တော့မှ မခေါ်ဆောင်ဘူးဆိုရင် remediation က noise ဖြစ်လာပါတယ်။ DPI က အန္တရာယ်ရှိတဲ့ code path တွေ အလုပ်လုပ်မလုပ်ကို အတည်ပြုပါတယ်။cised. အဲဒါက ကြိုတင်ပါ။cise တိုက်ခိုက်မှု မျက်နှာပြင် စီမံခန့်ခွဲမှု။

ရှုပ်ထွေးသောယုတ္တိဗေဒမှ ဖုံးကွယ်ထားသော ထွက်သွားသည့်အသွားအလာ

အချို့သော open-source package များသည် dynamic imports၊ reflection သို့မဟုတ် encrypted payloads များကို အသုံးပြုကြသည်။ ၎င်းတို့သည် external API calls များကို စတင်နိုင်သည် သို့မဟုတ် exiltrate metadata များကို အသုံးပြုနိုင်သည်။ static tools များသည် ၎င်းတို့ကို မကြာခဏ လွတ်သွားတတ်သော်လည်း deep packet inspection သည် outbound requests များနှင့် ၎င်းတို့၏ ဦးတည်ရာများကို ဖော်ပြသည်။

စစ်ဆေးခြင်းမှ လွတ်မြောက်သော ကုဒ်ဝှက်ထားသော ယာဉ်ကြော

TLS သို့မဟုတ် QUIC ပေါ်ရှိ gRPC ကဲ့သို့သော protocol များသည် payload များကို ဝှက်ထားသည်။ static tool များသည် ၎င်းတို့ကို decrypt မလုပ်နိုင်ပါ။ staging သို့မဟုတ် observability agent များတွင် decryption ပါရှိသော DPI သည် ဤ stream များကို စစ်ဆေးနိုင်ပြီး မူဝါဒချိုးဖောက်မှုများ သို့မဟုတ် လျှို့ဝှက် leak များကို flag လုပ်နိုင်သည်။

ဖြန့်ကျက်ထားသော ကုဒ်တွင် အပြုအမူဆိုင်ရာ ရွေ့လျားမှု

သင့်စစ်ဆေးထားသော ကုဒ်သည် ပတ်ဝန်းကျင်ပြောင်းလဲမှုများ၊ အင်္ဂါရပ်အလံများ သို့မဟုတ် runtime-loaded မော်ဂျူးများကြောင့် ထုတ်လုပ်မှုတွင် ကွဲပြားစွာပြုမူနိုင်သည်။ DPI မရှိပါက၊ အတွင်းပိုင်း API သည် ပြင်ပမှဝင်ရောက်အသုံးပြုနိုင်ခြင်း ရှိ၊ မရှိ သို့မဟုတ် ခွင့်ပြုချက်မရှိသော ချိတ်ဆက်မှုများ ပေါ်လာခြင်း ရှိ၊ မရှိ သင်မသိနိုင်ပါ။

ပိုကြီးတဲ့ပုံ- syntax ≠ အပြုအမူ

သန့်ရှင်းသောကုဒ်မှ လုံခြုံရေးသည် ခေတ်နောက်ကျနေပြီဟု ယူဆပါ။ ခေတ်မီတိုက်ခိုက်မှုမျက်နှာပြင်စီမံခန့်ခွဲမှုတွင် runtime အပြုအမူပါဝင်ရမည်။ Deep packet inspection သည် ထိုမြင်သာမှုကွာဟချက်ကို ပိတ်ပေးသည့်ကိရိယာဖြစ်ပြီး လုံခြုံရေးယူဆချက်များကို တကယ့်အသွားအလာနှင့် နှိုင်းယှဉ်၍ အတည်ပြုနိုင်စေပါသည်။

DPI က Static Tools တွေ ဘာတွေလွတ်သွားလဲဆိုတာကို ဖော်ထုတ်ခဲ့တဲ့ တကယ့်ချိုးဖောက်မှု ဥပမာတွေ

သင့်ရဲ့ AppSec ထဲကို deep packet inspection (DPI) ကို ပေါင်းစပ်အသုံးပြုခြင်း pipeline ၎င်းသည် ယူဆချက်သက်သက်မဟုတ်ပါ။ ၎င်းသည် ကွန်ရက်အသွားအလာက static analysis မှ မထောက်လှမ်းနိုင်သော ဖုံးကွယ်ထားသောအန္တရာယ်များကို ဖော်ထုတ်သည့် လက်တွေ့ကမ္ဘာဖြစ်ရပ်များတွင် အခြေခံထားသည်။

ကိစ္စရပ်- OpenTelemetry CVE‑2023‑43810

တရားဝင် CVE (CVE‑2023‑43810) တွင် ကျယ်ကျယ်ပြန့်ပြန့်အသုံးပြုသော open-source telemetry framework တစ်ခုဖြစ်သည့် OpenTelemetry ပါဝင်သည်။ auto-instrumentation အတွင်း HTTP method label များကို unbound cardinality ဖြင့် ထုတ်လုပ်သည်။ တိုက်ခိုက်သူများသည် အလွန်ရှည်လျားသော သို့မဟုတ် ကျပန်းဖြစ်သော crafted request များပေးပို့ခြင်းဖြင့် ၎င်းကို အခွင့်ကောင်းယူခဲ့ကြသည်။ http_နည်းလမ်း တန်ဖိုးများကြောင့် မှတ်ဉာဏ်ကုန်ခန်းခြင်းနှင့် ဆာဗာများတွင် ဝန်ဆောင်မှုငြင်းပယ်ခံရနိုင်ခြေကို ဖြစ်ပေါ်စေသည် datatracker.ietf.org+15nvd.nist.gov+15ntop.org+15.

static analysis tools များက OpenTelemetry ကို အန္တရာယ်ရှိနိုင်သော မှီခိုမှုအဖြစ် အလံပြထားသော်လည်း၊ ၎င်းတို့သည် runtime သက်ရောက်မှုကို မအကဲဖြတ်နိုင်ခဲ့ပေ။ ဆန့်ကျင်ဘက်အနေဖြင့်၊ deep packet inspection မှ တွေ့ရှိခဲ့သည်-

  • တိုက်ရိုက်အသွားအလာတွင် ပုံမှန်မဟုတ်ဘဲ ရှည်လျားသော HTTP እንደምအမည်များ။
  • ကြိမ်နှုန်းမြင့်မားခြင်း သို့မဟုတ် ပုံပျက်နေသော နည်းလမ်းပုံစံများသည် မှတ်ဉာဏ်အသုံးပြုမှုတွင် မြင့်တက်လာသည်။
  • exfiltration သို့မဟုတ် DoS ဖြစ်ပွားချိန်တွင် သံသယဖြစ်ဖွယ် DNS သို့မဟုတ် HTTP ဦးတည်ရာများ။

DPI သာလျှင် exploit ၏ runtime အထောက်အထားကို ပေးစွမ်းနိုင်ခဲ့ပြီး static tool မှာ မပေးစွမ်းနိုင်ခဲ့ပေ။ ဤသည်မှာ DPI သည် မရှင်းလင်းသော dependency alerts များကို attack surface management အတွက် actionable intelligence အဖြစ်သို့ မည်သို့ပြောင်းလဲပေးသည်ကို ပြသနေပါသည်။

Open-Source SDK များတွင် အန္တရာယ်ရှိသော Telemetry

နောက်ထပ်အဖြစ်များသော အခြေအနေတစ်ခုတွင်၊ open-source SDK များသည် အသုံးပြုသူ သို့မဟုတ် ပတ်ဝန်းကျင်ဒေတာကို ပြင်ပဝန်ဆောင်မှုများသို့ ပေးပို့သည့် telemetry ကုဒ်ကို ထည့်သွင်းထားပြီး၊ တစ်ခါတစ်ရံတွင် မှတ်တမ်းတင်ထားခြင်း သို့မဟုတ် အတည်မပြုထားခြင်း မရှိပါ။

Static tools များသည် ဖြစ်နိုင်ခြေရှိသော outbound call များ ရှိနေခြင်းကို flag လုပ်ကောင်း flag လုပ်နိုင်သော်လည်း ထို call များ ဖြစ်ပေါ်လာခြင်း ရှိ၊ မရှိကို အတည်မပြုနိုင်ပါ။ သို့သော် DPI သည် အောက်ပါတို့ကို ထောက်လှမ်းသည်-

  • SDK မှ ထွက်ခွာသွားသော အချိန်နှင့်တပြေးညီ HTTP သို့မဟုတ် gRPC တောင်းဆိုမှုများ။
  • ပေးပို့နေသော ဒေတာကို ပြသသည့် headers နှင့် payload အပါအဝင် envelope contents။
  • TLS မှတစ်ဆင့် ဒေတာအသွားအလာကို ကုဒ်ဝှက်ထားလျှင်ပင် အတည်မပြုရသေးသော endpoint domain များ။

DPI ရဲ့ payload-level analysis က telemetry အပြုအမူကို သတ်မှတ်ထားတဲ့ service ဒါမှမဟုတ် library တစ်ခုဆီ အတည်ပြုပြီး ဆက်စပ်ပေးပါတယ်။ ဒါက မရေမရာ သတိပေးချက်တွေကို pre-warning အဖြစ် ပြောင်းလဲပေးပါတယ်။cisတိုက်ခိုက်မှု မျက်နှာပြင် စီမံခန့်ခွဲမှု လုပ်ဆောင်ချက်များ- ပိတ်ဆို့ခြင်း၊ သတိပေးခြင်း သို့မဟုတ် စာရင်းစစ်ခြင်း။

ဘာကြောင့် ဒါတွေက အရေးကြီးတာလဲ

ဤဥပမာများသည် ရိုးရာ AppSec တွင် အရေးကြီးသော ကွာဟချက်ကို မီးမောင်းထိုးပြသည်-

  • SAST/SCA အန္တရာယ်ရှိသော မှီခိုမှုများ သို့မဟုတ် အားနည်းချက်များအကြောင်း သတိပေးသော်လည်း runtime အသုံးပြုမှု သို့မဟုတ် သက်ရောက်မှုကို သက်သေမပြနိုင်ပါ။
  • DPI အဓိပ္ပာယ်ဖွင့်ဆိုချက်မှတစ်ဆင့် နက်ရှိုင်းသောပက်ကက်စစ်ဆေးခြင်းသည် အသွားအလာကို ကုဒ်ဝှက်ထားသည့်အခါ သို့မဟုတ် မှုန်ဝါးစေသည့်အခါတွင်ပင် တကယ့်အပြုအမူကို မြင်သာစေပါသည်။

ဤပေါင်းစပ်မှုသည် အဖွဲ့များအား ယူဆချက်အခြေပြုလုံခြုံရေးမှ runtime-aware ကာကွယ်ရေးသို့ ရွေ့လျားနိုင်စေပါသည်။ DPI သည် တကယ့်အန္တရာယ်ကို ပေါ်လွင်စေသောကြောင့် သင်၏တိုက်ခိုက်မှုမျက်နှာပြင်ကို ကြိုတင်စီမံခန့်ခွဲနိုင်သည်cisအိုင်ယွန်နှင့် ဘာကိုအာရုံစိုက်သနည်း အသုံးချနိုင်သောသီအိုရီသက်သက်မဟုတ်ပါ။

DPI ထည့်သွင်းခြင်း CI/CD Pipeline

deep packet inspection က သင့်ရဲ့ workflow မှာ ဘယ်နေရာတွေမှာ ကိုက်ညီမှုရှိလဲ။ CI/CD မြန်နှုန်းနှင့် အတည်ပြုထားသော ပေးပို့မှုအကြောင်းဖြစ်သော်လည်း၊ အတည်ပြုခြင်းသည် ကုဒ်ခွဲခြမ်းစိတ်ဖြာမှုတွင် ရပ်တန့်၍မရပါ။ DPI သည် သင်၏အဆင့်များစွာတွင် ပါဝင်သည်။ pipeline:

  • စင်တိုက်ရိုက်အသွားအလာကို ဖမ်းယူသည့် DPI အေးဂျင့်များ သို့မဟုတ် ဘေးတွဲယာဉ်များဖြင့် ဝန်ဆောင်မှုများကို ဖြန့်ကျက်ပါ။
  • ဖြန့်ကျက်ပြီးနောက်: တိုက်ရိုက်မထုတ်လွှင့်မီ လက်တွေ့ပတ်ဝန်းကျင်တွင် အက်ပ်၏ အပြုအမူကို အဆက်မပြတ် စောင့်ကြည့်ပါ။
  • လုံခြုံရေး အတည်ပြုခြင်းခွင့်ပြုထားသော ပရိုတိုကောများကို အသုံးပြု၍ ဝန်ဆောင်မှုများသည် အတည်ပြုထားသော ဦးတည်ရာများနှင့်သာ ဆက်သွယ်ကြောင်း သေချာပါစေ။

 ဆော့ဖ်ဝဲရေးသားသူများအတွက် ပေါင်းစပ်မှု ဥပမာများ

  • GitHub လုပ်ဆောင်ချက်များပေါင်းစည်းမှုစမ်းသပ်မှုများအတွင်း သင့်အက်ပ်မှ အထွက်အသွားအလာကို စောင့်ကြည့်ရန် DPI ဖွင့်ထားသော (ဥပမာ Suricata သို့မဟုတ် cloud DPI ဝန်ဆောင်မှုကဲ့သို့သော tool ဖြင့်) စမ်းသပ်ကွန်တိန်နာတစ်ခုကို ဖြန့်ကျက်သည့် သင်၏ workflow တွင် job step တစ်ခုကို ထည့်ပါ။
  • GitLab CI: a ကိုသုံးပါ။ ဝန်ဆောင်မှုများ: staging လုပ်နေစဉ်အတွင်း သင့်အက်ပ်နှင့်အတူ DPI container တစ်ခုကို run ရန်နှင့် မသိသော domain များ သို့မဟုတ် plaintext protocol များကို flag လုပ်ရန် post-test traffic log များကို parse လုပ်ရန် ကြေငြာချက်။
  • Jenkins: စမ်းသပ် namespace တွင် DPI probe ကိုလည်ပတ်စေသည့် post-build အဆင့်တစ်ခုထည့်ပါ (ဥပမာ Kubernetes Job သို့မဟုတ် Docker Compose မှတစ်ဆင့်)၊ နှင့် traffic သည် သင်ကြေငြာထားသော service contract မှ သွေဖည်သွားပါက build ကို မအောင်မြင်စေပါ။

 တကယ့်ဇာတ်ခုံအခြေအနေ

သင့်ရဲ့ Node.js အက်ပ်က third-party analytics SDK တစ်ခုကို import လုပ်တယ်လို့ မြင်ယောင်ကြည့်ပါ။ staging မှာ DPI က outbound traffic ကို detect လုပ်ပါတယ်- api.untrusted-telemetry.com၊ သင်၏ ဝန်ဆောင်မှု ခွင့်ပြုစာရင်းတွင် မဖော်ပြထားသော ဒိုမိန်းတစ်ခု။ SDK သည် ရှုပ်ထွေးသော dynamic import များကို အသုံးပြုထားသောကြောင့် static tools များက ၎င်းကို မဖမ်းမိခဲ့ပါ။ သို့သော် DPI သည် live request ကို အချိန်နှင့်တပြေးညီ ဖော်ပြခဲ့သည်။

အဲဒါက နက်ရှိုင်းတဲ့ ပက်ကက်စစ်ဆေးခြင်းမှာ ထည့်သွင်းထားတဲ့နေရာပါ။ CI/CD၊ သီအိုရီကို ထောက်လှမ်းခြင်းအဖြစ်သို့ ပြောင်းလဲပေးသည်။ ၎င်းသည် သင့်အက်ပ် ထုတ်လုပ်မှုမစတင်မီ runtime-based attack surface management ကို အကောင်အထည်ဖော်ပေးသည်။

DPI သာလျှင် ဖမ်းမိမည့် တကယ့်အန္တရာယ် အခြေအနေများ

Deep packet inspection သည် static tools များ မထောက်လှမ်းနိုင်သော အပြုအမူအခြေပြုအန္တရာယ်များကို ဖော်ထုတ်ပေးသည်၊ ၎င်းတွင် အောက်ပါတို့ ပါဝင်သည်-

  • အခမဲ့ တယ်လီမက်ထရီ တိတ်တဆိတ် ခွဲခြမ်းစိတ်ဖြာမှုများကို ပေးပို့သည်။
  • Hardcoded API endpoint များ ဂိတ်ဝေး ပြဋ္ဌာန်းချက်ကို ကျော်လွှားခြင်း။
  • မှားယွင်းစွာ ပြင်ဆင်သတ်မှတ်ထားသော ပရိုတိုကောများ (ဥပမာ၊ HTTPS လိုအပ်သည့်နေရာတွင် HTTP ကိုအသုံးပြုခြင်း)။
  • ခွင့်ပြုချက်မရှိဘဲ ဒေတာအပ်လုဒ်လုပ်ခြင်း ပြင်ပ API များသို့။

ဤအန္တရာယ်များသည် သင်၏ source code တွင် မရှိပါ။ ၎င်းတို့သည် runtime အပြုအမူတွင် ပေါ်ပေါက်လာသည်။ ဆော့ဖ်ဝဲရေးသားသူ ဥပမာ-

staging မှာ DPI logs တွေက outbound POST တစ်ခုကို flag လုပ်ခဲ့ပါတယ်။ တောင်းဆိုရန် api.untrusted-telemetry.com. APM မှတစ်ဆင့် ဆက်စပ်မှု ညွှန်ပြသည် analytics.js မော်ဂျူးထဲမှာ အသုံးပြုသူ-လှုပ်ရှားမှု-ခြေရာခံကိရိယာ။ ဒါကို ဖမ်းမိခဲ့တာ မဟုတ်ပါဘူး SCA အဘယ်ကြောင့်ဆိုသော် library သည် dynamic import နှင့် obfuscated logic ကို အသုံးပြုထားသောကြောင့်ဖြစ်သည်။

DPI နှင့် trace metadata တွဲဖက်ထားခြင်းသည်သာ ရင်းမြစ်ကို ဖော်ပြပြီး အဖွဲ့အား ထိခိုက်စေသော SDK ကို ဖယ်ရှားနိုင်စေခဲ့သည်။ ၎င်းသည် runtime-driven attack surface management အတွက် အဓိကသော့ချက်ဖြစ်သော real code နှင့် ချိတ်ဆက်ထားသော real-time visibility ဖြစ်သည်။

စစ်မှန်သော Runtime Insight အတွက် Code + Traffic ကို ပေါင်းစပ်ခြင်း

အရင်းအမြစ်သို့ ပြန်မခြေရာခံနိုင်ပါက Runtime မှတ်တမ်းများသည် အကန့်အသတ်ရှိပါသည်။

stack traces သို့မဟုတ် APM tools များနှင့် deep packet inspection ကို ပေါင်းစပ်ခြင်းဖြင့် ထိုမြင်သာမှုကွာဟချက်ကို ပေါင်းကူးပေးသည်-

  • DPI မှတ်တမ်းများ “ဘာ”၊ ချိတ်ဆက်မှုတစ်ခု ပြုလုပ်ခဲ့သည်၊ မည်သည့်နေရာနှင့် မည်သည့် protocol ကို အသုံးပြုခဲ့သည်ကို ပြသပါ။
  • APM သို့မဟုတ် ခြေရာခံ မက်တာဒေတာ မည်သည့်လုပ်ဆောင်ချက် သို့မဟုတ် မော်ဂျူးသည် ထိုအပြုအမူကို ဖြစ်ပေါ်စေသည့် “ဘယ်လို” နှင့် “ဘာကြောင့်” ကို ပြသသည်။

ဤမြေပုံရေးဆွဲခြင်းသည် መስተ ...�ትကို လက်တွေ့လုပ်ဆောင်နိုင်သော ထိုးထွင်းသိမြင်မှုများအဖြစ်သို့ ပြောင်းလဲပေးသည်။ ဥပမာ-

"DPI သည် မမျှော်လင့်ထားသော အသွားအလာကို အလံပြခဲ့သည်" analytics.shadowvendor.io. APM က ဖုန်းခေါ်ဆိုမှု စတင်ရာနေရာကနေ စတင်ခဲ့တာကို ပြသခဲ့ပါတယ် analytics.js ထဲမှာ စျေးကွက်ရှာဖွေရေး-sdk မော်ဂျူးကို user onboarding လုပ်နေစဉ်အတွင်း feature flag မှတစ်ဆင့် invoke လုပ်သည်။

ဤရှင်းလင်းပြတ်သားမှုဖြင့် သင်သည် အန္တရာယ်ကို သတိပြုမိရုံသာမက ကြိုတင်ပြုပြင်နိုင်သည်။cisely။ အဲဒါက ထိရောက်ပြီး အချိန်နဲ့တပြေးညီ တိုက်ခိုက်မှု မျက်နှာပြင် စီမံခန့်ခွဲမှုအတွက် DPI ကို စောင့်ကြည့်နိုင်စွမ်းနဲ့ ပေါင်းစပ်ခြင်းရဲ့ စွမ်းအားပါပဲ။

DevSecOps ဖော်ရွေသည်- Shift-Left မှ Shift-Wire အထိ

"ဘယ်ဘက်သို့ ရွှေ့ပါ"ဖြစ်ပါတယ် standardဒါပေမယ့် အသင်းအများစုက မေ့လျော့နေကြတယ် ကြိုးကိုပြောင်းပါruntime လုပ်ဆောင်ချက်များသာမက ဖွံ့ဖြိုးတိုးတက်မှု၏ အစောပိုင်းအဆင့်များအတွင်း deep packet inspection ကို ယူဆောင်လာပါ။

DPI က ဒီပြောင်းလဲမှုကို ဘယ်လိုပံ့ပိုးပေးလဲဆိုတာ ဒီမှာပါ။

  • ဝန်ဆောင်မှုစာချုပ်များကို ရှေ့တွင် သတ်မှတ်ပါခွင့်ပြုထားသော ဦးတည်ရာများ၊ ပရိုတိုကောများနှင့် အပြုအမူများကို စာရင်းပြုစုပါ။ ၎င်းတို့သည် ကွန်ရက်စည်းမျဉ်းများသာမက လုံခြုံရေးဆိုင်ရာ မျှော်မှန်းချက်များလည်း ဖြစ်သည်။
  • Staging မှာ Synthetic Traffic ကိုသုံးပါ: သင့်စာချုပ်နှင့် ကိုက်ညီသော တကယ့်အပြုအမူကို အတည်ပြုရန် စမ်းသပ်မှုများ လုပ်ဆောင်ပြီး DPI မှတ်တမ်းများကို သိမ်းဆည်းပါ။
  • အပြုအမူ လွဲချော်မှုကို စောစောစီးစီး ဖမ်းယူပါအင်္ဂါရပ်အလံများ၊ config ပြောင်းလဲမှုများ သို့မဟုတ် အပ်ဒိတ်များသည် traffic pattern အသစ်များကို ဖြစ်ပေါ်စေနိုင်သည်။ DPI သည် ၎င်းတို့ကို ထုတ်လုပ်မှုမပြုလုပ်မီ ဖော်ပြသည်။

ဒါက DPI ကို တုံ့ပြန်မှုရှိတဲ့ မော်နီတာတစ်ခုသာမက သင့်ရဲ့ AppSec စမ်းသပ်မှုရဲ့ ကြိုတင်ကာကွယ်တဲ့ အစိတ်အပိုင်းတစ်ခု ဖြစ်စေပါတယ်။ pipeline။ ၎င်းသည် အတည်ပြုခြင်း၊ အကောင်အထည်ဖော်ခြင်းနှင့် မြင်သာမှုအတွက် ကိရိယာတစ်ခုဖြစ်ပြီး SAST or SCA။ အစောပိုင်းတွင် ပေါင်းစပ်လိုက်သောအခါ၊ DPI သည် သင့်လုံခြုံရေးအနေအထားကို အားကောင်းစေပြီး တိုက်ခိုက်မှုမျက်နှာပြင်စီမံခန့်ခွဲမှုတွင် runtime gap ကို ပိတ်ပေးသည်။

DPI ဖြင့် Runtime-Aware Attack Surface Management

ရိုးရာတိုက်ခိုက်မှုမျက်နှာပြင်စီမံခန့်ခွဲမှု (ASM) သည် static inventories၊ domain စာရင်းများ၊ service များ၊ endpoint များနှင့် dependencies များအပေါ် မူတည်သည်။ အသုံးဝင်သော်လည်း၊ ထိုမော်ဒယ်သည် app သည် ဒီဇိုင်းထုတ်ထားသည့်အတိုင်း အတိအကျလုပ်ဆောင်သည်ဟု ယူဆသည်။ ၎င်းသည် software သည် ထုတ်လုပ်မှုတွင် မည်သို့ပြောင်းလဲနေသည်ကို ထည့်သွင်းစဉ်းစားခြင်းမပြုပါ။

အဲဒီမှာ runtime-aware attack surface management ပါဝင်လာပါတယ်။

သင့်ကုဒ် သို့မဟုတ် config များတွင်ပါရှိသည့်အရာများအပေါ် အခြေခံ၍ မျက်နှာပြင်ဧရိယာကို စီမံခန့်ခွဲမည့်အစား၊ ၎င်းသည် သင့်အပလီကေးရှင်းကို လည်ပတ်သည့်အခါ မည်သို့ပြုမူသည်အပေါ် အခြေခံ၍ ၎င်းကို စီမံခန့်ခွဲသည်။ ဤချဉ်းကပ်မှုသည် deep packet inspection ကို map လုပ်ရန် အသုံးပြုသည်-

  • ဘယ်ဝန်ဆောင်မှုတွေက ဘယ်ဒိုမိန်းတွေနဲ့ ဆက်သွယ်သလဲ။
  • ဘယ်လို protocol တွေကို အသုံးပြုထားလဲ။
  • မည်သည့် ယာဉ်ကြောပိတ်ဆို့မှုမဆို သင်သတ်မှတ်ထားသော မျှော်လင့်ချက်များကို ချိုးဖောက်ခြင်း ရှိမရှိ။

ဒါဟာ သီအိုရီဆိုင်ရာ ဖော်ထုတ်မှု မဟုတ်ပါဘူး၊ တကယ့် လေ့လာတွေ့ရှိထားတဲ့ အပြုအမူပါ။

အဓိကကွာခြားချက် -

  • ရိုးရာ ASM = “ဤဝန်ဆောင်မှု သင့် X သို့သာ ချိတ်ဆက်ပါ။
  • Runtime-aware ASM = “ဤဝန်ဆောင်မှု” is မမျှော်လင့်ဘဲ Y နဲ့ Z ကိုလည်း ချိတ်ဆက်နေပါတယ်။

DPI ပေါင်းစပ်ထားခြင်းဖြင့် သင်ပေါ်လာသည်-

  • မှားယွင်းသောဖွဲ့စည်းပုံများ။
  • လုံခြုံရေးမူဝါဒများမှ သွေဖည်သွားခြင်း။
  • ကုဒ်တွင် တိတ်ဆိတ်နေသော ပြင်ပအဖွဲ့အစည်း၏ အပြုအမူများကို မမြင်ရပါ။

အပြုအမူဆိုင်ရာ စောင့်ကြည့်နိုင်စွမ်းသို့ ဤပြောင်းလဲမှုသည် ခေတ်သစ် AppSec အတွက် မရှိမဖြစ်လိုအပ်ပါသည်။ ၎င်းသည် သင့်တိုက်ခိုက်မှုမျက်နှာပြင်စီမံခန့်ခွဲမှုသည် ရည်ရွယ်ချက်များကို မြေပုံရေးဆွဲခြင်းသက်သက်မဟုတ်ဘဲ runtime တွင် ဖြစ်ပျက်သည်များကို ထိန်းချုပ်ခြင်းနှင့်ပတ်သက်ကြောင်း သေချာစေသည်။

သင့်ရဲ့ DevSecOps Stack မှာရှိတဲ့ DPI

Deep packet inspection က သင့်ရဲ့ tool တွေကို အစားမထိုးပါဘူး။ runtime awareness နဲ့ pre-inspection တွေနဲ့ သူတို့ကို တိုးချဲ့ပေးပါတယ်။cisအိုင်း။ DPI ကို သင့်ရဲ့ stack ထဲကို integrate လုပ်နိုင်ပါတယ်-

  • မှတ်တမ်းများနှင့် အပြုအမူဆိုင်ရာ သတိပေးချက်များနှင့် ဆက်စပ်စေရန် DPI ပွဲများကို SIEM ပလက်ဖောင်းများထဲသို့ တွန်းပို့ခြင်း။
  • တိုက်ခိုက်မှုလမ်းကြောင်းများကို လမ်းညွှန်ရန်နှင့် လက်တွေ့ကမ္ဘာအသုံးပြုမှုကို တုပရန် DPI ၏ ထိုးထွင်းသိမြင်မှုများကို DAST ထဲသို့ ထည့်သွင်းခြင်း။
  • outbound အပြုအမူကို အဆက်မပြတ်စောင့်ကြည့်ရန်အတွက် staging သို့မဟုတ် production Kubernetes clusters များကဲ့သို့သော သင်၏ GitOps-based environments များထဲသို့ DPI agent များကို ဖြန့်ကျက်ခြင်း။

DPI နှင့် Firewall များ- ကွာခြားချက်ကဘာလဲ။

နားလည်ထားရန် အရေးကြီးပါသည်- DPI သည် firewall မဟုတ်ပါ။

  • firewall သည် binary de ကို အကောင်အထည်ဖော်သည်cisions: ကြိုတင်သတ်မှတ်ထားသော စည်းမျဉ်းများ (ဥပမာ၊ port များ၊ IP များ၊ protocol များ) အပေါ် အခြေခံ၍ ပိတ်ဆို့ သို့မဟုတ် ခွင့်ပြုသည်။
  • အခြားတစ်ဖက်တွင်မူ DPI သည် ဆက်စပ်လေ့လာနိုင်မှုကို ပေးစွမ်းနိုင်ရန် ယာဉ်ကြောပိတ်ဆို့မှုကို စစ်ဆေးသည်။ ၎င်းက “ဤပက်ကက်ကို ခွင့်ပြုထားသည်” ဟုသာ မဆိုဘဲ အောက်ပါတို့ကို ပြသထားသည်-
    • ဘာပို့လိုက်တာလဲ။
    • ဘယ်သူက အစပြုတာလဲ။
    • အကြောင်းအရာ သို့မဟုတ် ဦးတည်ရာသည် မူဝါဒနှင့် ကိုက်ညီမှု ရှိမရှိ။

ဥပမာ:

  • firewall တစ်ခုသည် HTTPS traffic ကို ခွင့်ပြုနိုင်သည် *.external.com။
  • DPI သည် ပြင်ပ analytics SDK မှ အသုံးပြုသူ ID များ ပေးပို့နေကြောင်း ဖော်ပြနိုင်သည်- track.external.com, သင် ဘယ်တုန်းကမှ ပြန်လည်သုံးသပ်ခြင်း သို့မဟုတ် အတည်ပြုခြင်း မပြုခဲ့သော ဒိုမိန်းတစ်ခု။

ဤစောင့်ကြည့်နိုင်စွမ်းသည် runtime-aware attack surface management ကို ဖြစ်စေပြီး access control တစ်ခုတည်းကိုသာမက အပြည့်အစုံပုံရိပ်ကို ပေးစွမ်းနိုင်သည်။

ခေတ်သစ် DevSecOps တွင် DPI သည် dynamic validation layer တစ်ခုဖြစ်လာပြီး၊ အပြုအမူသည် ရည်ရွယ်ချက်နှင့် ကိုက်ညီမှုရှိမရှိ စစ်ဆေးကာ အန္တရာယ်များကို အစောပိုင်းတွင် ပေါ်လာစေသည်။ pipeline ပေးပို့မှုနှေးကွေးခြင်းမရှိဘဲ။

DPI မှတစ်ဆင့် အချိန်နှင့်တပြေးညီ ခြိမ်းခြောက်မှု ထောက်လှမ်းခြင်း

ဖြန့်ကျက်ပြီးနောက် DPI သည် runtime defense ၏ အဓိကအစိတ်အပိုင်းတစ်ခုဖြစ်သည်-

  • HTTPS သို့မဟုတ် TLS မှတစ်ဆင့် ဒေတာခိုးယူမှုကို ရှာဖွေပါ။
  • ခိုးယူခံရသော package များမှ beaconing အပြုအမူကို ဖော်ထုတ်ပါ။
  • ခွင့်ပြုချက်မရှိသော API endpoint များမှတစ်ဆင့် အတွင်းပိုင်းဝန်ဆောင်မှုအလွဲသုံးစားမှုကို ဖော်ထုတ်ပါ။

IP များကို ပိတ်ဆို့သော firewall များနှင့်မတူဘဲ၊ deep packet inspection သည် အပြုအမူကို ခွဲခြမ်းစိတ်ဖြာသည်။ attack surface management ဖြင့်၊ ပိတ်ဆို့ထားသော လိပ်စာများကိုသာမက တကယ့် app အပြုအမူကို အခြေခံ၍ ခြိမ်းခြောက်မှုများကို သင်ရှာဖွေတွေ့ရှိသည်။

Code Visibility က ဘာကြောင့် မလုံလောက်တော့တာလဲ

ဤလုပ်ငန်းသည် static-only AppSec ထက် ကြီးထွားလာပါပြီ။ SAST နှင့် SCA စားပွဲပေါ်မှာ လောင်းကြေးထပ်ထားပေမယ့် runtime ကို မမြင်ကြဘူး။ ခေတ်သစ်အန္တရာယ်တွေဟာ တိုက်ရိုက်အပြုအမူမှာသာ ပေါ်လာပါတယ်- package တွေ အိမ်ပြန်ခေါ်တာ၊ မမျှော်လင့်ထားတဲ့ endpoint တွေ ဒါမှမဟုတ် protocol မူဝါဒချိုးဖောက်တာတွေပါ။ static tool တွေက အဲဒီမေးခွန်းတွေကို မဖြေနိုင်ပါဘူး။ Deep packet inspection က တကယ့် traffic ကို စစ်ဆေးခြင်းအားဖြင့် အဲဒီကွာဟချက်ကို ဖြည့်ဆည်းပေးပြီး definition DPI က မျှော်လင့်ထားတဲ့ အပြုအမူကို လမ်းညွှန်ပေးပါတယ်။ ဒါက attack surface management ကို assumption-driven ကနေ evidence-driven အဖြစ် ပြောင်းလဲပေးပါတယ်။ မြန်မြန်တည်ဆောက်ပြီး မကြာခဏ deploy လုပ်တဲ့အခါ code scan တွေတင်မကဘဲ real-time wire visibility လိုအပ်ပါတယ်။

DPI + Xygeni: လက်တွေ့တွင် Runtime-Aware AppSec

တူသောပလက်ဖောင်း ဆိုက်ဂျီနီ ၎င်းကို runtime-aware၊ developer-friendly နည်းလမ်းဖြင့် သင်၏ AppSec stack ထဲသို့ ထည့်သွင်းခြင်းဖြင့် deep packet inspection ကို ပိုမိုလုပ်ဆောင်ပါ။ ၎င်းသည် observability သက်သက်မဟုတ်ဘဲ automated detection နှင့် enforcement လည်းဖြစ်သည်။

နည်းပညာပိုင်းအရ ဘယ်လိုအလုပ်လုပ်လဲ-

  • Xygeni သည် ပေါ့ပါးသော အေးဂျင့်များကို ဖြန့်ကျက်သည် ကွန်ရက်အပြုအမူကို ဖမ်းယူရန် staging သို့မဟုတ် production environment များတွင်။
  • ဤအေးဂျင့်များသည် အာဟာရဓာတ်များ ပေးစွမ်းသည် ဗဟိုချုပ်ကိုင်မှုမှတ်တမ်း pipeline၊ ၎င်းသည် ယာဉ်ကြောပိတ်ဆို့မှုကို ဝန်ဆောင်မှုများနှင့် အစိတ်အပိုင်းများနှင့် ဆက်စပ်ပေးသည်။
  • Xygeni လည်းလုပ်နိုင်ပါတယ် ရှိပြီးသားကွန်ရက်ကိရိယာများနှင့်ပေါင်းစပ်ပါဥပမာ၊ သင့် stack ကို မနှောင့်ယှက်ဘဲ DPI မြင်သာမှုကို မြှင့်တင်ရန် cloud-native firewall logs၊ service meshes သို့မဟုတ် eBPF instrumentation။

လက်တွေ့မူဝါဒ-

Xygeni သည် ဝန်ဆောင်မှုတစ်ခုသည် ၎င်း၏ဝန်ဆောင်မှုစာချုပ်ပြင်ပတွင် ဖော်ပြထားသော အတည်မပြုရသေးသော domain သို့ ချိတ်ဆက်ရန်ကြိုးစားသည့်အခါ ထောက်လှမ်းသည်။ ဤသို့ staging လုပ်နေစဉ်အတွင်း ဖြစ်ပွားပါက event ကို flag လုပ်ကာ configure လုပ်ပါက deployment ကို အလိုအလျောက် block လုပ်သည်။

ဤ runtime-aware feedback loop သည် သင်၏ တိုက်ခိုက်မှု မျက်နှာပြင် စီမံခန့်ခွဲမှု မူဝါဒအပေါ် အခြေခံပြီး အကောင်အထည်ဖော်ရန် အသင့်ဖြစ်စေသည်။

နှင့် Xygeni + DPI, သင်လုပ်နိုင်သည်:

  • တကယ့်အကောင်အထည်ဖော်မှုလမ်းကြောင်းများအတွက် ခြေရာခံအားနည်းချက်များ: CVE များကို အသုံးပြုမှုအပေါ် အခြေခံ၍ နောက်ခံအခြေအနေအလိုက် ချိန်ညှိထားသည်။
  • တိုက်ရိုက် Telemetry သို့မဟုတ် ဒေတာယိုစိမ့်မှုများကို ဖမ်းယူပါ: အချိန်နှင့်တပြေးညီ ထွက်ခွာသွားသော ယာဉ်ကြောကို ၎င်း၏ မူလနေရာသို့ ပြန်လည်မြေပုံဆွဲထားသည်။
  • ကွန်ရက်စာချုပ်များကို အလိုအလျောက် ပြဋ္ဌာန်းပါ: အတည်ပြုထားသော ဦးတည်ရာများနှင့် ပရိုတိုကောများကိုသာ ခွင့်ပြုသည်။ အခြားသူများကို ပိတ်ဆို့ထားသည် သို့မဟုတ် အလံပြထားသည်။
  • Static Tools တွေ ဘာတွေ လွတ်သွားလဲဆိုတာ အတည်ပြုပါ။: လည်ပတ်ချိန် DPI သည် အသုံးပြုမှုကို အတည်ပြုမှသာ static flags များကို လုပ်ဆောင်နိုင်မည်ဖြစ်သည်။

ဘာကြောင့်အရေးကြီးတာလဲ- developer တွေမှာ false positive တွေကို လိုက်ရှာဖို့ အချိန်မရှိပါဘူး။ Xygeni က de ထဲကို တိုက်ရိုက်ထည့်သွင်းပေးတဲ့ DPI insights တွေနဲ့ real-time၊ behavior-based validation ကို ပေးပါတယ်။cisသင့်ကို လုံခြုံစေသော အိုင်းယွန်းများ pipeline.

နောက်ဆုံးအတွေးများ- မြန်မြန်ပို့ပါ၊ ဂရုတစိုက်စောင့်ကြည့်ပါ

ဆော့ဖ်ဝဲရေးသားသူများ အလျင်အမြန်လှုပ်ရှားကြပြီး လုံခြုံရေးလည်း အလျင်အမြန်လှုပ်ရှားသင့်ပါတယ်။ သင့်တွင် deep packet inspection ကို ထည့်သွင်းပါ pipelineရှင်းလင်းသော အဓိပ္ပာယ်ဖွင့်ဆိုချက် DPI မူဝါဒနှင့် ခိုင်မာသော တိုက်ခိုက်မှုမျက်နှာပြင်စီမံခန့်ခွဲမှုဖြင့် ကျောထောက်နောက်ခံပြုထားသည်။ Static scan များသည် အရေးကြီးသော်လည်း ပိုအရေးကြီးသည်မှာ သင့်အက်ပ်သည် ကွန်ရက်ပေါ်တွင် ဘာလုပ်သည်ဆိုသည့်အချက်ဖြစ်သည်။ သင်ရေးသားခဲ့သည်များကိုသာမက ၎င်း၏လုပ်ဆောင်ချက်များကိုပါ လုံခြုံအောင်ထားပါ။ ၎င်းသည် DevSecOps AppSec ၏ အနာဂတ်ဖြစ်သည်။

sca-tools-software-composition-analysis-tools
သင့်ဆော့ဖ်ဝဲလ်အန္တရာယ်များကို ဦးစားပေးသတ်မှတ်ခြင်း၊ ပြုပြင်ခြင်းနှင့် လုံခြုံစေခြင်း
သင့်ရဲ့ အခမဲ့အကောင့်ကို ရယူလိုက်ပါ။
အကြွေးဝယ်ကဒ်မရှိပါ။

သင့်ရဲ့ Software Development နဲ့ Delivery ကို လုံခြုံအောင်ထားပါ

Xygeni ထုတ်ကုန်အစုံနှင့်အတူ