SAST vs DAST vs IAST: Sikkerhedstest for komplementariteter af de tre brødre, ikke substitution

De tre mest almindelige forkortelser i ansøgningssikkerhedstesten er SAST, DAST, IAST. Mange menneskers første reaktion var at "vælge en af de stærkeste", men det var et hyklerisk forslag - de tre brødre konkurrerede ikke, men så det samme fra forskellige perspektiver. Valget afhænger ikke af, hvem der er mere avanceret, men på det stadium, du er på i software livscyklus, hvilken slags smuthul du ønsker at finde, og hvor meget du kan bære.

Oversigt over anvendelsen af de tre metoder til sikkerhedstest

I. DEFINITIONER PÅ DEN FØRSTE REFERENCE

SAST (statisk prøvning af applikationssikkerhed)Andre arrangørerKør ikke programmet, under hvilken scanning kildekode / byte kode finder et smuthul, som tilhører den hvide boks.
DASTAndre arrangørerKører programEkstern lancering anmodninger, simulerede angreb er "sorte kasser" og ingen kildekode er påkrævet.
IAST (Interactive Application Safety Test)Andre arrangørerKør program indefraPlug- in (agent), kombineret med flow og kode sammenhæng, tilhører Grey Box.

Nøglen til at forstå disse tre er, at de hver især besvarer forskellige spørgsmål: SAST spørger, "Hvor kan der være en fejl i koden?" "Kan vi komme igennem, når vi løber?" IAST spørger, "I denne operation, hvilken datastrøm virkelig flyder til det punkt af fare".

SAST: Kvælning af problemet på kodeskrivning

SAST analyserer kildekoden (eller samler mellemprodukter) direkte og udfører ikke programmet. Fordelen er at være i stand til at opdage problemer på et tidligt tidspunkt, eller selv når koden er indsendt, at finde specifikke dokumenter og linjenumre, med lave reparationsomkostninger. Den dækker "koder kan fejes" og afhænger ikke af køretidsmiljøet.

Kortbræt: Fejlprocenten er normalt høj, fordi det ikke afgør, om et bestemt antal koder vil blive udløst i den virkelige virksomhed; de problemer, der kun er udsat, når du kører (fx, konfigurations fejl, sikkerhed omgår, faktisk call chain af tillid til biblioteket) er ikke fuldt ud set; kildekoden er nødvendig, og tredjeparts closed- source komponent er ikke funktionel.

Typisk scenario: CI streaming line kode indsendelse døre er lukket for at forhindre synlig injektion, hard- kodning nøgle, farefunktion kalder ind i rygraden.

"Virker det virkelig?"

DAST bruger målet som en sort boks til at sende anmodninger udefra, konstruere angreb nyttelaster og observere respons. Dens største værdi er...Tæt på et rigtigt angreb.- Problemet med "reel adgang til at køre" blev fundet, med relativt lav underrapportering. Der kræves ingen kildekode, så tredjepartskomponenter, konfigurationslag kan også dækkes.

KortbrætDet er ofte kun indtil ibrugtagning, at detektering af sen detektion og omkostningerne ved reparation er høj; dækning er begrænset til krybdyr og testruter, der kan nås med eksempel, uden påvisning af ikke-påviselige funktionelle punkter; det er vanskeligt at lokalisere kildekoden præcist, og udvikling og rapportering er ofte kun kendt "hvilken URL er problematisk"; og konfigurationsomkostningerne er høje for scenarier, der kræver login, multi-trin forretningsprocesser.

Typisk scenario: sikkerhedsgodkendelse før online, periodisk scanning af anvendte miljøer.

IV. LAST: Run- time stik, balancering sammenhæng med reelle datastrømme

IAST også observerer kode udførelse og ekstern flow, når du kører programmet ved at implantere antent i programmet. Det kan se, hvordan anmodninger kommer ind, og hvordan data flyder ind i koden, så det kan gives.Tag alle beviser fra kroen.Den er normalt lavere end SAST og præcis.

KortbrætNødvendigheden af at kunne anvende sonder i målmiljøet (på grund af bekymringer om produktionsmiljøet), afhængighed af testdækning, som ikke kan findes, uden at koden bliver implementeret, som ofte er bundet til funktionel / automatiseret test, forskelle i sprog og rammestøtte samt visse præstationsomkostninger.

Typisk scenario: køre i testmiljøet i forbindelse med automatiseret test, både for at validere funktionalitet og for at synkronisere output sikkerhed konklusioner.

Se data flow og call stack fra inde kode

Fem, tre mod en.

Dimensioner	SAST	DAST	AST
Testobjekt	Kilde / bytes (ikke kørende)	Aktivt mål (eksternt)	Operationelle applikationer (interne stik)
Perspektiver	Hvid boks	Sort boks	Grå boks
Tid til intervention	Indkodning / indsendelse tidligst	Efter indsættelse	Prøvning / køretid
Brug for kildekode	Ja.	Det behøves ikke.	Krav (kan tilsluttes)
Urapporteret niveau	Høj	Lav	Lavere
Positionspræcision	Til fil / linje	Til URL / grænseflade	At ringe til Inn / Data Stream
Overskriv afhængighed	Begrænset (se kildekode del)	Overskrid eksponering under kørsel	Begrænset af udførelsessti
Typisk scene	CI Code Dørforbud	Tjek og accepter før du går online.	Kombineret med automatiseret prøvning

VI. Hvorfor komplementaritet snarere end substitution

Hvis du sætter de tre sammen, de finder deres blinde zoner at være komplementære:

SAST ser koden, men ved ikke, om den vil blive udløst; DAST ved, om den kan udløses, men ved ikke i hvilken linje problemet er; IAST både, men kræver koden skal udføres.
SAST dækker tidligt, bredt og højt; DAST har lille støj, men sen indgriben, smal dækning; og IAST har høj nøjagtighed, men kan tilslutte sig og køre godt nok.
Bare gå til SAST, som er sårbar over for "en masse bureaukrati" træthed; gå til DAST, hvor smuthullet er ofte udsat på linjen; gå til IAST, hvor den vej, som det ikke er nået, er blind.

Svaret på virkeligheden er ikke en eller to, men en stadie-by-stage tilgang: tidlig brug af SAST til at jamme et klart mønster af dårlig smag og fare, testfasen af IAST skal valideres præcist med IAST i forbindelse med automatisering, og up-og downline brug af DAST til ekstern accept fra aggressors perspektiv. Tre overtro udgør en applikationssikkerhedstest uden væsentlige huller.

Statiske, dynamiske, interaktive test danner en lukket cirkel.

VII. PRAKTISKE SPØRGSMÅL VEDRØRENDE LANDING

1. Fejlrapportering hvem der beskæftiger sig med det

Uanset hvad, ingen ordner rapporten, ingen gør. Der er en klar triage proces: hvem ser, hvor længe at lukke, hvordan man markerer "acceptere risiko". SAST har især brug for en basisadministration, ellers vil historiens arv drukne nye problemer.

Dækning er vigtigere end værktøjsmærker

IAST 's evne til at opdage afhænger direkte af, hvor mange koder der er omfattet af testen; DAST afhænger af, hvor mange grænseflader krybdyr når. Det er mere meningsfuldt at måle "hastigheden af påvisning" før at gå online end at erstatte et dyrere værktøj.

3. Behandl ikke sikkerhedstests som engangsprøver Tag den.

Sikkerhedsforsøg bør indgå i en kontinuerlig F & U-proces i stedet for centraliseret, før de går online. CI kører SAST, tester miljø IAST, regelmæssigt gør DAST til produktion, så det behøver ikke at stole på menneskekød for at redde ilden.

4. Fokus på synergier mellem værktøjer

Den ideelle tilstand er, at tre typer af resultater kan grupperes i samme visning: det samme smuthul, SAST giver kode placering, IAST giver data stream beviser, og DAST validerer tilgængelighed. Det er mere værd end de tre krigshærgede øer.

VIII. En liste over beslutninger

Ja.IndsendelsesfaseBare hold det åbenlyse smuthul på SAST væk, fokuser på dørlukninger og basislinjer.
For at verificereEr systemet virkelig i stand til at angribe? • Op med DAST, med fokus på dækning og login konfiguration.
For at få sikkerhedskonklusioner.Output med automatiseret prøvningOg find præcis på det mindste.
Begrænsede ressourcer kan kun anvendes som første prioritet for SAST til at etablere en bundlinje og derefter gradvist fuldføre IAEA / DAST.
Søgningen efter en "one-second-fits-all, permanent løsning" findes ikke, men den måde at organisere og proces er svaret.

SAST er muligt, DAST er praktisk, IAST er specifik - kombineret er et komplet billede.