Mūsdienu lietojumprogrammu drošība vairs nav saistīta ar izolētiem rīkiem. Mūsdienās komandas saskaras ar izkliedētiem signāliem, nebeidzamiem brīdinājumiem un ierobežotu skaidrību par to, kas patiesībā darbojas viņu vidē. Šis izaicinājums ir pamudinājis daudzas organizācijas pārdomāt, kā… lietojumprogrammu vadības dzinējs, lietojumprogrammas klienta konteiners, un Application Security Posture Management (ASPM) sader kopā, lai nodrošinātu patiesu izpildes kontroli.
ASPM nodrošina vienotu veidu, kā izprast risku visā kodā, pipelineun izpildlaiku. Tomēr ar stāju vien nepietiek. Lai rīkotos atbilstoši šai stājai, komandām ir nepieciešama reāla izpildes kontrole. Šeit kritiski svarīga kļūst lietojumprogrammu vadības programma, un tradicionālie modeļi, piemēram, lietojumprogrammu klienta konteiners, sāk parādīt savus ierobežojumus.
Kāpēc ASPM Ir lietojumprogrammu kontroles sākumpunkts
ASPM atbild uz fundamentālu jautājumu: Kāda ir mana reālā drošības pozīcija visās lietojumprogrammās?.
Tas tiek panākts, korelējot signālus no avota koda, atkarībām, CI/CD pipelines, infrastruktūru un izpildes uzvedību. Rezultātā komandas iegūst ieskatu par to, kas pastāv, kā komponenti ir saistīti un kur koncentrējas risks.
Tomēr redzamība bez rīcības ātri rada berzi. Tāpēc ASPM ir jāsaista stāja ar izpildi. Citiem vārdiem sakot, tiklīdz risks ir izprasts, platformai ir jāpalīdz izlemt, ko atļaut izpildīt un ko ne.
Tieši šeit iederas lietojumprogrammu kontrole ASPM.
Ko ASPM Atrisina to punktu, ko drošības rīki nevar
Lielākā daļa drošības rīku tika izstrādāti, lai atbildētu uz šauriem jautājumiem. Statiskie skeneri aplūko kodu. Atkarību rīki analizē bibliotēkas. Izpildes laika risinājumi novēro izpildes notikumus. Katrs no tiem darbojas izolēti.
Kā noteikts NIST riska pārvaldības sistēma, efektīva drošības decisjoniem ir nepieciešams nepārtraukts konteksts, nevis izolētas kontroles. Šis ierobežojums izskaidro, kāpēc punktveida rīkiem ir grūti aprakstīt reālu lietojumprogrammu risku.
Tomēr mūsdienu lietojumprogrammu risks nepastāv atsevišķi. Tā vietā tas rodas no mijiedarbības starp koda izmaiņām, atkarībām, pipelineun izpildlaika uzvedību. Tā rezultātā punktveida rīki bieži ģenerē brīdinājumus, nepaskaidrojot reālo iedarbību.
Tas ir tur ASPM maina modeli.
ASPM korelē signālus visā lietojumprogrammas dzīves ciklā. Tā vietā, lai novērtētu atsevišķu skenēšanu vai notikumu, tā veido nepārtrauktu priekšstatu par to, kas pastāv, kā komponenti ir saistīti un kā risks attīstās laika gaitā. Līdz ar to komandas var saprast ne tikai to, kas notika, bet arī to, kāpēc tas notika un vai tam vispār ir nozīme.
Bez ASPMKontroles mehānismi darbojas bez konteksta. Izmaiņas var šķist bīstamas atsevišķi, lai gan tās ir pilnībā paredzamas. Tajā pašā laikā neliela modifikācija var radīt reālu risku, ja tā lauž iedibinātus modeļus. Tāpēc poza kļūst par jēgpilnas kontroles pamatu.
Īsumā, ASPM pārvērš izkliedētus drošības datus strukturētā ieskatā. Tas aizstāj fragmentārus brīdinājumus ar izpratni par lietojumprogrammu riskiem, uz kuriem var reaģēt kontroles mehānismi.
Kas ir lietojumprogrammu vadības dzinējs
An lietojumprogrammu vadības dzinējs ir mehānisms, kas izlemj, kurām lietojumprogrammām, procesiem vai komponentiem ir atļauts izpildīties vidē. Tā vietā, lai reaģētu pēc izpildes, tā koncentrējas uz nevēlamas izpildes novēršanu jau no paša sākuma, padarot lietojumprogrammu vadības programmu par galveno proaktīvās drošības sastāvdaļu.
Tradicionāli lietojumprogrammu vadības dzinēji paļāvās uz statiskiem atļauto failu sarakstiem. Ja binārais fails vai process netika skaidri apstiprināts, tā izpilde tika bloķēta. Sākumā šī pieeja samazināja risku stabilās un paredzamās sistēmās.
Tomēr mūsdienu programmatūras vides pastāvīgi mainās. Atkarības tiek atjauninātas automātiski, būvējumi notiek bieži, un darba slodzes ir īslaicīgas. Līdz ar to statiskie noteikumi ļoti ātri zaudē aktualitāti.
Atšķirībā no pretvīrusu risinājumiem, klasiskajiem EDR rīkiem vai ugunsmūriem, kas koncentrējas uz zināmiem draudiem vai tīkla trafiku, lietojumprogrammu vadības dzinējs darbojas citā līmenī. Tas izlemj, vai izpilde vispār ir jāveic. Tāpēc tam ir nozīme profilaksē, nevis atklāšanā pēc notikuma.
Kas ir lietojumprogrammas klienta konteiners
An lietojumprogrammas klienta konteiners Nodrošina pārvaldītu izpildlaika vidi klienta lietojumprogrammām. Tā risina tādus jautājumus kā dzīves cikla pārvaldība, konfigurācija un drošības konteksts.
Vienkārši sakot, konteiners ietver lietojumprogrammu un piedāvā koplietotus pakalpojumus, lai izstrādātājiem tie nebūtu jāveido manuāli. Šis modelis kļuva populārs 2000. gadā. enterprise vidēs, kur ir konsekvence un standardbija nepieciešama atjaunošana.
Mūsdienās lietojumprogrammu klientu konteineri joprojām ir aktuāli konkrētās jomās. enterprise un mantojuma scenārijus. Tomēr tie koncentrējas uz to, kā darbojas lietojumprogramma, nevis uz to, vai tai vajadzētu darboties. Tie pieņem, ka lietojumprogramma un tās komponenti jau ir uzticami, un tiem trūkst pārredzamības par piegādes ķēdes risku vai negaidītām izmaiņām.
Lietojumprogrammu vadības dzinējs pret lietojumprogrammu klienta konteineru
Lai gan nosaukumi izklausās līdzīgi, šīs pieejas kalpo ļoti atšķirīgiem mērķiem.
| Aspekts | Lietojumprogrammu vadības dzinējs | Lietojumprogrammas klienta konteiners |
|---|---|---|
| Primārais mērķis | Izlemiet, ko var izpildīt | Nodrošināt pārvaldītu izpildlaiku |
| Kontroles brīdis | Pirms izpildes un tās laikā | Izpildes laikā |
| redzamība | Ierobežots mantoto modeļu skaits | Tikai izpildlaikā |
| izpilde | Uz politiku balstīta izpildes kontrole | Platformas līmeņa izpilde |
| Piegādes ķēdes izpratne | Bieži vien trūkst | Nav tam paredzēts |
Īsāk sakot, lietojumprogrammas klienta konteiners pārvalda izpildi pēc tam, kad komandas ir ieguvušas uzticību. Lietojumprogrammu vadības dzinējs izlemj, vai izpilde vispār ir uzticamaTomēr bez stājas konteksta daudzi dzinēji darboties akli un palaist garām reālu risku.
Kāpēc mantoto lietojumprogrammu kontrole neizdodas bez ASPM
Mantotas lietojumprogrammu vadības programmas mērķtiecīgu vidēs, kur programmatūra mainījās lēnām. Viņi pieņemts paredzamus izpildes ceļus un apstrādāts pilnībā izprastas lietojumprogrammas.
Šodien šis modelis sabojājas.
Atkarīgas ienākt projekti automātiski no publiskajiem reģistriem.
komandas push kods mainās vairākas reizes dienā.
Platformas vadīt pielietojumi īslaicīgos konteineros.
Uzbrucēji slēpt iekšējās komponentes, kurām komandas jau uzticas.
Saskaņā ar OWASP, Mūsdienu piegādes ķēdes uzbrukumi bieži vien ļaunprātīgi izmanto uzticamus komponentus, kas statisku izpildes kontroli pašu par sevi padara nepietiekamu. Šajā kontekstā atļauto vielu saraksti un fiksētie noteikumi nespēj aptvert, kā risks faktiski nonāk lietojumprogrammās.
Tā rezultātā statiskie atļauju saraksti gandrīz uzreiz zaudē aktualitātiTurklāt mantojuma kontrole trūkst stājas izpratnes. tas neizdodas izskaidrot kāpēc notika izmaiņas vai vai šīs izmaiņas rada reālu risku.
Tāpēc lietojumprogrammu kontrole bez ASPM kļūst vai nu pārāk ierobežojošs, vai bīstami atļaujošs.
Mūsdienīga lietojumprogrammu kontrole iekšpusē ASPMNo stājas līdz izpildei
Mūsdienīga lietojumprogrammu vadība darbojas vislabāk kā daļa no ASPM, nevis kā atsevišķs mehānisms.
Tā vietā, lai paļautos tikai uz statiskiem noteikumiem, komandas bāzes kontrole decisjoni par stājas signāliem, piemēram:
- Kā komandas izveidoja lietojumprogrammu
- Kuras atkarības komandas ieviesa vai modificēja
- Vai uzvedība novirzās no iepriekšējām versijām
- Vai izpildes modeļi negaidīti mainīties
Tā rezultātā lietojumprogrammu kontrole darbojas nepārtrauktiSistēmas nevis jautā tikai "vai tam vajadzētu darboties", bet gan jautāt "Vai šī nāvessoda izpilde atbilst zināmai stājai un vēsturei?"
Šajā modelī lietojumprogrammu vadības dzinējs darbojas kā izpildes līmenis vadīts ASPM ieskatu.
Kā lietojumprogrammu kontrole tiek decisjoni mainās līdz ar ASPM konteksts
Lietojumprogrammu kontrolecisjoni būtiski mainīties kad komandas piemēro pozas kontekstu.
Bez ASPM, lietojumprogrammu vadības dzinēji paļauties uz statiskiem noteikumiem. Binārs iztur vai neizturProcess atbilst noteikumam vai neatbilstTā rezultātā, decisjoni paliek bināri un ignorē nolūku.
ar ASPM konteksts, kontrole kļūst situatīvs.
Piemēram, komandas ļaut jauna atkarība, kad tā atbilst nesenajām izstrādes aktivitātēm. Tomēr komandas bloķēt to pašu atkarību, kad tā negaidīti parādās stabilā lietojumprogrammā. Tādā veidā kontrole pielāgojas kontekstam tā vietā, lai uzspiestu fiksētus pieņēmumus.
Līdzīgi, izpildes uzvedība, kas izskatās normāli vienā pieteikumā signalizē par risku citā. ASPM sniedz vēsturisku un relacionālu kontekstu, Kas palīdz kontroles mehānismiem atšķirt starp paredzamo attīstību un aizdomīgu novirzi.
Tā vietā, lai jautātu “vai tas atbilst noteikumam”, lietojumprogrammu vadība jautā "Vai tam ir jēga, ņemot vērā to, ko mēs zinām?" Līdz ar to, izpilde kļūst precīzāks un mazāk traucējošs.
Kā Xygeni savienojas ASPM, lietojumprogrammu kontrole un izpilde
Ksigēni pieejas lietojumprogrammu kontrole kā dabisks turpinājums ASPM.
Pirmkārt, Xygeni veido stāju, kartējot lietojumprogrammas, atkarības, pipelineun izpildes signāli. Tas rada skaidru priekšstatu par to, kas pastāv un kā komponenti ir saistīti.
Pēc tam Xygeni piemēro lietojumprogrammu kontroli, izmantojot šo pozīciju. Statisku atļauto sarakstu vietā decisjoni ņem vērā veidošanas kontekstu, atkarības izcelsmi un uzvedības vēsturi.
Svarīgi ir tas, ka šī pieeja nepaļaujas uz lieljaudas izpildlaika aģentiem. Lietojumprogrammu vadības loģika ir tieši integrēta CI/CD pipelineun drošības darbplūsmasTā rezultātā noteikumu ievērošanas nodrošināšana notiek agrīnā stadijā, konsekventi un bez ietekmes uz veiktspēju.
Visbeidzot, stāja, kontrole un izpilde veido slēgtu cilpu:
- ASPM identificē reālu risku
- Lietojumprogrammu kontrole nosaka, kas jāizpilda
- Izpilde tiek piemērota nocisjoni automātiski
Citiem vārdiem sakot, Xygeni nebloķē akli. Tas īsteno, jo apzinās risku.
Piemēram, aktīvas izstrādes laikā ieviesta jauna atkarība var tikt atļauta, ja tā atbilst nesenajai veidošanas aktivitātei un vēsturiskajiem modeļiem. Tomēr, ja tā pati atkarība negaidīti parādās stabilā pakalpojumā, to var automātiski bloķēt. Tādā veidā lietojumprogrammu kontrole tiek definēta.cisjonus virza pozas konteksts, nevis fiksēti pieņēmumi.
Bieži sastopami nepareizi priekšstati par lietojumprogrammu vadības dzinējiem
Daudzas komandas joprojām domā, ka lietojumprogrammu kontrole attiecas tikai uz bināro failu bloķēšanu. Tomēr mūsdienu lietojumprogrammu kontrole ir plašāka.
Bieži sastopami maldīgi priekšstati:
- Lietojumprogrammu kontrole aizstāj ievainojamību skenēšanu
- Pietiek ar statiskiem atļauju sarakstiem
- Kontrole ir svarīga tikai izpildes laikā
Patiesībā efektīva lietojumprogrammu kontrole ir atkarīga no stājas, konteksta un uzvedības laika gaitā. Bez tā ASPM, kontrole joprojām ir nepilnīga.
Final Domas
Lietojumprogrammu klientu konteineri palīdz lietojumprogrammām darboties konsekventi. Lietojumprogrammu vadības dzinēji izlemt, vai izpildei vispār jānotiek. Tomēr mūsdienu vidē neviens no tiem nedarbojas atsevišķi.
ASPM nodrošina kontekstu. Lietojumprogrammu vadība nodrošina decisIzpilde nodrošina darbību.
Apvienojot stāju, kontroli un izpildi, tādas platformas kā Xygeni ļauj komandām kontrolēt, kas tiek izpildīts, kāpēc tas tiek izpildīts un vai tam vispār vajadzētu tikt izpildītam. Mūsdienu vidē kontrole kas darbojas pirms izpildes ir daudz svarīgāk nekā skenēšana pēc izpildes, jo īpaši tāpēc, ka programmatūra nepārtraukti mainās.
par autoru
Sarakstījis Fatima Said, satura mārketinga vadītājs, kas specializējas lietojumprogrammu drošībā uzņēmumā Xygeni drošība.
Fátima veido izstrādātājiem draudzīgu, uz pētījumiem balstītu saturu platformā AppSec, ASPMun DevSecOps. Viņa pārvērš sarežģītas tehniskas koncepcijas skaidrās, praktiski izmantojamās atziņās, kas savieno kiberdrošības inovācijas ar ietekmi uz uzņēmējdarbību.
