PAST vs DAST vs IAST: Test de securitate pentru complementaritatile celor trei frati, nu substitutie

Cele mai frecvente trei abrevieri din testele de securitate ale aplicației sunt SAST, DAST, IAST. Prima reacţie a multor oameni a fost aceea de a selecta una dintre cele mai puternice. Dar a fost o propunere ipocrită. Alegerea nu depinde de cine este mai avansat, ci de stadiul în care vă aflați în ciclul de viață software, ce fel de portiță de scăpare doriți să găsiți și cât de mult puteți suporta.

I. DEFINIȚII PRIVIND PRIMA REFERINȚĂ

• SAST (test de securitate a aplicării statice)Alt organizatorNu executa programul, sub care codul sursă de scanare / codul octet găsește o portiță de scăpare, care aparține cutiei albe.
• DASTAlt organizatorRulează programulSolicitări de lansare externă, atacuri simulate sunt
• IAST (test interactiv de siguranță a aplicației)Alt organizatorExecută programul din interiorPlug-in (agent), combinat cu fluxul și contextul de cod, aparține Grey Box.

Cheia înţelegerii acestor trei este că fiecare răspunde la diferite întrebări: SAST se întreabă: "Unde poate fi o greşeală în cod?" DAST întreabă, "Putem obține de fapt, prin intermediul atunci când rulează?" IAST întreabă, "În această operațiune, care flux de date curge într-adevăr la punctul de pericol."

SAST: Strangularea problemei la etapa de scriere cod

SAST analizează direct codul sursă (sau compilează produse intermediare) și nu execută programul. Avantajul este de a putea detecta problemele într-un stadiu incipient, sau chiar atunci când codul este prezentat, pentru a localiza documente specifice și numere de linie, cu costuri reduse de reparații. Ea acoperă "codurile pot fi şterse" şi nu depinde de mediul în care se desfăşoară activitatea.

Scurtătură: Rata de eroare este de obicei mare, deoarece nu determină dacă un anumit număr de coduri vor fi declanșate în afaceri reale; problemele care sunt expuse numai atunci când rulează (de exemplu, erori de configurare, bypass de asigurare, lanț de apel real de a se baza pe bibliotecă) nu sunt pe deplin văzute; codul sursă este necesar și componenta de sursă închisă a terților nu este funcțională.

Scenariu tipic: Ușile de depunere cod linie de streaming CI sunt închise pentru a preveni injectarea vizibilă, cheia de codare dură, funcția de pericol atrage în coloana vertebrală.

Verificând "Chiar funcţionează?"

DAST folosește ținta ca o cutie neagră pentru a trimite cereri din exterior, construi sarcini utile de atac și să observe răspunsul. Cea mai mare valoare este...Aproape de un atac real.Nu este necesar nici un cod sursă, astfel încât componentele terțe părți, straturile de configurare pot fi, de asemenea, acoperite.

ScurtăturăDe multe ori, numai până la implementare, detectarea de detectare tardivă și costul reparațiilor este mare; acoperirea este limitată la reptile și rute de testare care pot fi atinse prin exemplu, fără detectarea unor puncte funcționale nedetectabile; este dificil de localizat codul sursă cu precizie, iar dezvoltarea și raportarea sunt adesea cunoscute numai

Scenariu tipic: clearance-ul de securitate înainte de a merge on-line, scanare periodică a mediilor utilizate.

IV. IAST: Conexiuni pe timp de execuție, echilibrarea contextului cu fluxurile reale de date

IAST observă, de asemenea, execuția codului și fluxul extern atunci când rulează programul prin implantarea furnicului în aplicație. Se poate vedea cum apar cererile, și cum intră datele în cod, astfel încât acestea să poată fi furnizate.Ia toate dovezile hanului.De obicei e mai mică decât SAST şi e corectă.

ScurtăturăNevoia de a putea implementa sonde în mediul țintă (recunoașterea preocupărilor legate de mediul de producție); dependența de acoperirea testelor, care nu poate fi găsită fără punerea în aplicare a codului, care este adesea legată de testarea funcțională/automată; diferențele de limbă și de suport-cadru și anumite costuri de performanță.

Scenariul tipic: să ruleze în mediul de testare împreună cu testarea automată, atât pentru a valida funcționalitatea, cât și pentru a sincroniza concluziile privind siguranța producției.

Cinci, trei contra unu.

Dimensiuni	TRECUT	DAST	ASTA
Obiect de încercare	Sursă/octeți (nu funcționează)	Obiectiv activ (extern)	Aplicații operaționale ( pluguri interne)
Perspectivă	Cutie albă	Black Box	Cutie gri
Timpul de intervenție	Faza de codificare/depunere mai devreme	După implementare	Test/Run-time
Nevoie de cod sursă	Da.	Nu e nevoie.	Cerința (poate fi conectată)
Nivel raportat greșit	Ridicat	Mică	Mai jos
Precizie poziție	În fișier/linie	Pentru URL/ Interfață	Pentru a apela Inn / Data Stream
Suprascrie dependența	Limitată (a se vedea partea din codul sursă)	Suprascrie expunerea în timp ce rulează	Limitată pe cale de execuție
Scenă tipică	Interdicţie de cod CI	Verificați și acceptați înainte de a merge on-line.	Combinat cu încercarea automată

VI. De ce complementaritatea mai degrabă decât înlocuirea

Dacă le asamblezi pe cele trei, zonele lor oarbe sunt complementare:

• SAST vede codul, dar nu ştie dacă va fi declanşat; DAST ştie dacă poate fi declanşat, dar nu ştie în ce linie este problema; IAST ambele, dar cere ca codul să fie executat.
• SAST acoperă devreme, larg și tare; DAST are zgomot mic, dar intervenție întârziată, acoperire îngustă; și IAST are o precizie ridicată, dar poate conecta și rula suficient de bine.
• Doar du-te la SAST, care este vulnerabil la o grămadă de birocrație până la oboseală; du-te la DAST, în cazul în care portița de scăpare este adesea expusă pe linie; du-te la IAST, în cazul în care calea la care nu este atins este orb.

Răspunsul la realitate nu este unul sau două, ci o abordare treptată: utilizarea timpurie a SAST pentru a bloca un model clar de gust rău și pericol, faza de testare a IAST pentru a fi validată cu precizie cu AIST în combinație cu automatizarea, și utilizarea în sus și în jos a DAST pentru acceptarea externă din perspectiva agresorului. Trei superstiții constituie un test de securitate aplicație închis buclă fără lacune semnificative.

VII. Aspecte practice privind aterizarea

1. Raportarea greșită care se ocupă cu ea

Oricum, nimeni nu rezolvă raportul, nimeni nu ştie. Există un proces de triaj clar: cine vede, cât de mult să închidă, cum să marcheze "acceptarea riscului." În special, SAST are nevoie de managementul de bază, altfel moștenirea istoriei va îneca noi probleme.

Acoperirea este mai importantă decât mărcile de instrumente

Capacitatea IAST de a descoperi depinde direct de câte coduri sunt acoperite de test; DAST depinde de câte interfețe sunt atinse de reptile. Este mai important să se măsoare rata de detectare înainte de a merge on-line decât de a înlocui un instrument mai scump.

3. Nu trataţi testele de siguranţă ca teste unice Ia-l.

Testele de siguranță ar trebui să fie integrate într-un proces continuu de cercetare și dezvoltare, mai degrabă decât centralizate înainte de a merge on-line. CI ruleaza SAST, teste de mediu EST, face în mod regulat DAST pentru productie, asa ca nu trebuie sa se bazeze pe carne umana pentru a salva focul.

4. Concentrarea pe sinergii între instrumente

Starea ideală este că trei tipuri de rezultate pot fi grupate în aceeaşi perspectivă: aceeaşi portiţă de scăpare, SAST oferă locaţie de cod, IAST oferă dovezi de flux de date, iar DAST validează disponibilitatea. Valorează mult mai mult decât cele trei insule distruse de război.

VIII. Lista deciziilor

• Da.Faza de depunereDoar țineți off portiță evidentă pe SAST, se concentreze pe închiderea ușilor și de bază.
• Pentru a verificaEste sistemul desfășurat într-adevăr capabil de atac? • Sus cu DAST, concentrându-se pe acoperire și configurare de conectare.
• Pentru a obține concluzii de securitate.Ieșire cu încercare automatăŞi să localizăm exact în baza de date.
• Resursele limitate pot fi utilizate doar ca prioritate pentru SAST pentru a stabili o linie de bază și apoi treptat pentru a finaliza AIEA/DAST.
• Căutarea unei "soluţii unice şi permanente" nu există, dar modul de organizare şi procesare este răspunsul.

PAST este posibil, DAST este practic, IAST este specific