Frica și dezgustul față de DevSecOps

Aveam 2 analizoare de cod, 4 instrumente de testare dinamică, propriile noastre meșteșuguri și 250 de scripturi. Nu este că toate acestea sunt necesare în procesul actual, dar odată ce începeți să implementați DevSecOps, trebuie să mergeți până la sfârșit.

Sursă. Creatorii personajelor: Justin Roiland și Dan Harmon.

Ce este SecDevOps? Dar DevSecOps? Care sunt diferențele? Securitatea aplicațiilor - despre ce este vorba? De ce nu mai funcționează abordarea clasică? Cunoaște răspunsul la toate aceste întrebări Yuri Shabalin de Securitate pește-spadă. Yuri va răspunde la toate în detaliu și va analiza problemele tranziției de la modelul clasic de securitate a aplicațiilor la procesul DevSecOps: cum să abordezi corect integrarea procesului de dezvoltare securizată în procesul DevOps și să nu rupi nimic, cum să treci prin etapele principale de testare de securitate, ce instrumente pot fi utilizate și ce diferă și cum să le configurați corect pentru a evita capcanele.

Despre vorbitor: Yuri Shabalin - Arhitect șef de securitate în companie Securitate pește-spadă. Responsabil pentru implementarea SSDL, pentru integrarea globală a instrumentelor de analiză a aplicațiilor într-un ecosistem unificat de dezvoltare și testare. 7 ani de experiență în securitatea informațiilor. A lucrat la Alfa-Bank, Sberbank și Positive Technologies, care dezvoltă software și oferă servicii. Speaker la conferințe internaționale ZerONights, PHDays, RISSPA, OWASP.

Securitatea aplicațiilor: despre ce este vorba?

Securitatea aplicațiilor - Aceasta este secțiunea de securitate care este responsabilă pentru securitatea aplicației. Acest lucru nu se aplică infrastructurii sau securității rețelei, ci mai degrabă ceea ce scriem și la ce lucrează dezvoltatorii - acestea sunt deficiențele și vulnerabilitățile aplicației în sine.

Direcție SDL sau SDLC - Ciclul de viață al dezvoltării securității - dezvoltat de Microsoft. Diagrama prezintă modelul canonic SDLC, a cărui sarcină principală este participarea securității la fiecare etapă de dezvoltare, de la cerințe până la lansare și producție. Microsoft și-a dat seama că erau prea multe bug-uri în industrie, erau mai multe și trebuia făcut ceva în privința asta și a propus această abordare, care a devenit canonică.

Application Security și SSDL nu au ca scop detectarea vulnerabilităților, așa cum se crede în mod obișnuit, ci prevenirea apariției acestora. De-a lungul timpului, abordarea canonică a Microsoft a fost îmbunătățită, dezvoltată și introdusă într-o scufundare mai profundă și mai detaliată.

SDLC canonic este foarte detaliat în diverse metodologii - OpenSAMM, BSIMM, OWASP. Metodologiile sunt diferite, dar în general similare.

Modelul de securitate a construcției în maturitate

imi place cel mai mult BSIMM - Modelul de securitate a construcției în maturitate. Baza metodologiei este împărțirea procesului de securitate a aplicațiilor în 4 domenii: guvernare, inteligență, puncte de contact SSDL și implementare. Fiecare domeniu are 12 practici, care sunt reprezentate ca 112 activități.

Fiecare dintre cele 112 activități are 3 niveluri de maturitate: începător, intermediar și avansat. Puteți studia toate cele 12 practici secțiune cu secțiune, puteți selecta lucrurile care sunt importante pentru dvs., puteți afla cum să le implementați și să adăugați treptat elemente, de exemplu, analiza codului statică și dinamică sau revizuirea codului. Scrieți un plan și lucrați cu calm în conformitate cu acesta, ca parte a implementării activităților selectate.

De ce DevSecOps

DevOps este un proces general, amplu, în care trebuie luată în considerare securitatea.

Inițial DevOps implicat controale de securitate. În practică, numărul echipelor de securitate a fost mult mai mic decât acum și nu au acționat ca participanți la proces, ci ca un organism de control și supraveghere care îi impune cerințe și verifică calitatea produsului la sfârșitul lansării. Aceasta este o abordare clasică în care echipele de securitate au fost în spatele zidului de la dezvoltare și nu au participat la proces.

Problema principală este că securitatea informațiilor este separată de dezvoltare. De obicei, acesta este un fel de circuit de securitate a informațiilor și conține 2-3 instrumente mari și scumpe. O dată la șase luni, sosește codul sursă sau aplicația care trebuie verificată și o dată pe an sunt produse pentesti. Toate acestea duc la faptul că data lansării pentru industrie este întârziată, iar dezvoltatorul este expus unui număr mare de vulnerabilități din instrumentele automate. Este imposibil să dezasamblați și să reparați toate acestea, deoarece rezultatele din ultimele șase luni nu au fost rezolvate, dar iată un nou lot.

Pe parcursul activității companiei noastre, vedem că securitatea în toate domeniile și industriile înțelege că este timpul să ne atingă din urmă și să ne învârtim cu dezvoltarea pe aceeași roată - în Agilitate. Paradigma DevSecOps se potrivește perfect cu metodologia de dezvoltare agilă, implementare, suport și participare la fiecare lansare și iterație.

Trecerea la DevSecOps

Cel mai important cuvânt din ciclul de viață al dezvoltării securității este "proces". Trebuie să înțelegeți acest lucru înainte de a vă gândi să cumpărați unelte.

Simpla încorporare a instrumentelor în procesul DevOps nu este suficientă - comunicarea și înțelegerea între participanții la proces sunt importante.

Oamenii sunt mai importanți, nu instrumentele.

Adesea, planificarea unui proces de dezvoltare securizat începe cu alegerea și achiziționarea unui instrument și se termină cu încercări de integrare a instrumentului în procesul curent, care rămân încercări. Acest lucru duce la consecințe nefericite, deoarece toate instrumentele au propriile caracteristici și limitări.

Un caz obișnuit este atunci când departamentul de securitate a ales un instrument bun, scump, cu capacități largi, și a venit la dezvoltatori pentru a-l integra în proces. Dar nu funcționează - procesul este structurat în așa fel încât limitările instrumentului deja achiziționat să nu se încadreze în paradigma actuală.

Mai întâi, descrieți ce rezultat doriți și cum va arăta procesul. Acest lucru va ajuta la înțelegerea rolurilor instrumentului și siguranței în proces.

Începeți cu ceea ce este deja în uz

Înainte de a cumpăra unelte scumpe, uitați-vă la ceea ce aveți deja. Fiecare companie are cerințe de securitate pentru dezvoltare, există verificări, pentest-uri - de ce să nu transformi toate acestea într-o formă care să fie înțeleasă și convenabilă pentru toată lumea?

De obicei, cerințele sunt un Talmud de hârtie care se află pe un raft. A existat un caz când am venit la o companie să ne uităm la procese și am cerut să vedem cerințele de securitate pentru software. Specialistul care s-a ocupat de acest lucru a petrecut mult timp căutând:

- Acum, undeva în note era o cale unde se află acest document.

Drept urmare, am primit documentul o săptămână mai târziu.

Pentru cerințe, verificări și alte lucruri, creați o pagină pe, de ex. confluență - este convenabil pentru toată lumea.

Este mai ușor să reformatați ceea ce aveți deja și să îl utilizați pentru a începe.

Folosește campionii de securitate

De obicei, într-o companie medie cu 100-200 de dezvoltatori, există un specialist în securitate care îndeplinește mai multe funcții și nu are timp fizic să verifice totul. Chiar dacă face tot posibilul, el singur nu va verifica tot codul pe care îl generează dezvoltarea. Pentru astfel de cazuri, a fost dezvoltat un concept - Campioni de securitate.

Campionii securității sunt oameni din cadrul echipei de dezvoltare care sunt interesați de securitatea produsului dumneavoastră.

Campionul securității este un punct de intrare în echipa de dezvoltare și un evanghelist de securitate inclus într-unul.

De obicei, atunci când un specialist în securitate vine la o echipă de dezvoltare și indică o eroare în cod, acesta primește un răspuns surprins:

- Si cine esti tu? Te văd pentru prima dată. Totul este în regulă pentru mine - prietenul meu senior mi-a dat „aplica” la revizuirea codului, mergem mai departe!

Aceasta este o situație tipică, deoarece există mult mai multă încredere în seniori sau pur și simplu în colegii de echipă cu care dezvoltatorul interacționează constant la locul de muncă și în revizuirea codului. Dacă, în locul ofițerului de securitate, Campionul Securității evidențiază greșeala și consecințele, atunci cuvântul lui va avea mai multă greutate.

De asemenea, dezvoltatorii își cunosc codul mai bine decât orice specialist în securitate. Pentru o persoană care are cel puțin 5 proiecte într-un instrument de analiză statică, este de obicei dificil să-și amintească toate nuanțele. Campionii securității își cunosc produsul: ce interacționează cu ce și la ce să se uite mai întâi - sunt mai eficienți.

Prin urmare, luați în considerare implementarea Campionilor de securitate și extinderea influenței echipei dvs. de securitate. Acest lucru este util și pentru campionul însuși: dezvoltare profesională într-un domeniu nou, extinderea orizontului său tehnic, îmbunătățirea abilităților tehnice, manageriale și de conducere, creșterea valorii de piață. Acesta este un element al ingineriei sociale, „ochii” tăi în echipa de dezvoltare.

Etape de testare

Paradigma de la 20 la 80 spune că 20% din efort produce 80% din rezultate. Aceste 20% sunt practici de analiză a aplicațiilor care pot și ar trebui automatizate. Exemple de astfel de activități sunt analiza statică - SAST, analiza dinamica - DAST и Control Open Source. Vă voi spune mai detaliat despre activități, precum și despre instrumente, ce caracteristici întâlnim de obicei atunci când le introducem în proces și cum să o facem corect.

Principalele probleme ale instrumentelor

Voi evidenția problemele care sunt relevante pentru toate instrumentele și necesită atenție. Le voi analiza mai detaliat pentru a nu le repeta mai departe.

Timp lung de analiză. Dacă de la commit până la lansare durează 30 de minute pentru toate testele și asamblarea, atunci verificările de securitate a informațiilor vor dura o zi. Deci nimeni nu va încetini procesul. Luați în considerare această caracteristică și trageți concluzii.

Nivel înalt fals negativ sau fals pozitiv. Toate produsele sunt diferite, toate folosesc cadre diferite și propriul stil de codare. Pe baze de cod și tehnologii diferite, instrumentele pot afișa diferite niveluri de fals negativ și fals pozitiv. Așa că uită-te la ce se află exact dumneavoastră companii si pentru dumneavoastră aplicațiile vor arăta rezultate bune și fiabile.

Fără integrări cu instrumentele existente. Priviți instrumentele în termeni de integrări cu ceea ce utilizați deja. De exemplu, dacă aveți Jenkins sau TeamCity, verificați integrarea instrumentelor cu acest software, și nu cu GitLab CI, pe care nu îl utilizați.

Lipsa sau complexitatea excesivă a personalizării. Dacă un instrument nu are un API, atunci de ce este necesar? Tot ceea ce se poate face în interfață ar trebui să fie disponibil prin API. În mod ideal, instrumentul ar trebui să aibă capacitatea de a personaliza verificările.

Fără foaie de parcurs pentru dezvoltarea produsului. Dezvoltarea nu stă pe loc, folosim mereu noi cadre și funcții, rescriind vechiul cod în limbi noi. Vrem să fim siguri că instrumentul pe care îl cumpărăm va sprijini noi cadre și tehnologii. Prin urmare, este important să știți că produsul are real și corect Roadmap dezvoltare.

Caracteristicile procesului

Pe lângă caracteristicile instrumentelor, luați în considerare și caracteristicile procesului de dezvoltare. De exemplu, împiedicarea dezvoltării este o greșeală comună. Să ne uităm la ce alte caracteristici ar trebui luate în considerare și la ce ar trebui să acorde atenție echipa de securitate.

Pentru a nu rata termenele de dezvoltare și lansare, creați reguli diferite si diferita arata opritoare — criterii pentru oprirea procesului de construire în prezența unor vulnerabilități — pentru medii diferite. De exemplu, înțelegem că ramura actuală merge la standul de dezvoltare sau UAT, ceea ce înseamnă că nu ne oprim și spunem:

„Ai vulnerabilități aici, nu vei merge nicăieri mai departe!”

În acest moment, este important să le spunem dezvoltatorilor că există probleme de securitate care necesită atenție.

Prezența vulnerabilităților nu este un obstacol pentru testarea ulterioară: manual, integrare sau manual. Pe de altă parte, trebuie să creștem cumva securitatea produsului și astfel încât dezvoltatorii să nu neglijeze ceea ce consideră sigur. Prin urmare, uneori facem acest lucru: la stand, când este lansat în mediul de dezvoltare, pur și simplu notificăm dezvoltarea:

- Băieți, aveți probleme, vă rog să fiți atenți la ele.

În etapa UAT arătăm din nou avertismente despre vulnerabilități, iar în etapa de lansare spunem:

- Băieți, v-am avertizat de mai multe ori, nu ați făcut nimic - nu vă vom lăsa să ieșiți cu asta.

Dacă vorbim despre cod și dinamică, atunci este necesar să arătăm și să avertizăm despre vulnerabilități numai ale acelor caracteristici și cod care tocmai a fost scris în această caracteristică. Dacă un dezvoltator mută un buton cu 3 pixeli și îi spunem că are o injecție SQL acolo și, prin urmare, trebuie remediat urgent, acest lucru este greșit. Uită-te doar la ce este scris acum și la schimbarea care vine în aplicație.

Să presupunem că avem un anumit defect funcțional - modul în care aplicația nu ar trebui să funcționeze: banii nu sunt transferați, când dați clic pe un buton nu există tranziție la pagina următoare sau produsul nu se încarcă. Defecte de securitate - sunt aceleasi defecte, dar nu in ceea ce priveste functionarea aplicatiei, ci in securitate.

Nu toate problemele legate de calitatea software-ului sunt probleme de securitate. Dar toate problemele de securitate sunt legate de calitatea software-ului. Sherif Mansour, Expedia.

Deoarece toate vulnerabilitățile sunt aceleași defecte, ele ar trebui să fie localizate în același loc ca toate defectele de dezvoltare. Așa că uită de rapoarte și PDF-uri înfricoșătoare pe care nimeni nu le citește.

Când lucram la o companie de dezvoltare, am primit un raport de la instrumentele de analiză statică. L-am deschis, am fost îngrozit, am făcut cafea, am răsfoit 350 de pagini, l-am închis și am continuat să lucrez. Rapoartele mari sunt rapoarte moarte. De obicei nu ajung nicăieri, literele sunt șterse, uitate, pierdute sau compania spune că acceptă riscurile.

Ce să fac? Pur și simplu transformăm defectele confirmate pe care le-am găsit într-o formă convenabilă pentru dezvoltare, de exemplu, le punem într-un backlog în Jira. Prioritizează defectele și le eliminăm în ordinea priorității, împreună cu defectele funcționale și defectele de testare.

Analiza Statica - SAST

Aceasta este o analiză de cod pentru vulnerabilități., dar nu este același lucru cu SonarQube. Nu verificăm doar modele sau stil. În analiză sunt utilizate o serie de abordări: conform arborelui de vulnerabilitate, conform Flux de date, prin analiza fișierelor de configurare. Acesta este tot ceea ce privește codul în sine.

Avantajele abordării: identificarea vulnerabilităților în cod într-un stadiu incipient de dezvoltarecând nu există încă suporturi sau unelte gata făcute și capacitate de scanare incrementală: scanarea unei secțiuni de cod care s-a schimbat și numai a funcției pe care o facem în prezent, ceea ce reduce timpul de scanare.

Contra - aceasta este lipsa de sprijin pentru limbile necesare.

Integrari necesare, care ar trebui să fie în instrumente, în opinia mea subiectivă:

• Instrument de integrare: Jenkins, TeamCity și Gitlab CI.
• Mediu de dezvoltare: Intellij IDEA, Visual Studio. Este mai convenabil pentru un dezvoltator să nu navigheze într-o interfață de neînțeles care mai trebuie să fie memorată, ci să vadă toate integrările și vulnerabilitățile necesare pe care le-a găsit chiar la locul de muncă în propriul mediu de dezvoltare.
• Revizuirea codului: SonarQube și revizuirea manuală.
• Următoarele defectelor: Jira și Bugzilla.

Imaginea prezintă unii dintre cei mai buni reprezentanți ai analizei statice.

Nu instrumentele sunt importante, ci procesul, așa că există soluții Open Source care sunt bune și pentru testarea procesului.

SAST Open Source nu va găsi un număr mare de vulnerabilități sau DataFlow-uri complexe, dar ele pot și ar trebui să fie utilizate atunci când construiesc un proces. Ele ajută la înțelegerea modului în care va fi construit procesul, cine va răspunde la erori, cine va raporta și cine va raporta. Dacă doriți să efectuați etapa inițială de construire a securității codului dvs., utilizați soluții Open Source.

Cum poate fi integrat acest lucru dacă sunteți la începutul călătoriei și nu aveți nimic: fără CI, fără Jenkins, fără TeamCity? Să luăm în considerare integrarea în proces.

Integrare la nivel CVS

Dacă aveți Bitbucket sau GitLab, puteți integra la nivel Sistem de versiuni concurente.

După eveniment - trage cerere, comite. Scanați codul și starea construcției arată dacă verificarea de securitate a trecut sau nu a reușit.

Părere. Desigur, feedback-ul este întotdeauna necesar. Dacă tocmai ați făcut securitatea laterală, puneți-o într-o cutie și nu spuneți nimănui nimic despre asta, apoi, la sfârșitul lunii, aruncați o grămadă de bug-uri - acest lucru nu este corect și nu este bun.

Integrare cu sistemul de revizuire a codului

Odată, am acționat ca evaluator implicit pentru un utilizator tehnic AppSec într-o serie de proiecte importante. În funcție de dacă erorile sunt identificate în noul cod sau dacă nu există erori, examinatorul setează starea cererii de extragere la „acceptare” sau „trebuie să lucreze” - fie totul este OK, fie linkurile către ceea ce trebuie îmbunătățit exact trebuie îmbunătățite. Pentru integrarea cu versiunea care intră în producție, am activat o interdicție de îmbinare dacă testul de securitate a informațiilor nu este trecut. Am inclus acest lucru în revizuirea manuală a codului, iar alți participanți la proces au văzut stările de securitate pentru acest proces anume.

Integrare cu SonarQube

Mulți au poarta de calitate în ceea ce privește calitatea codului. Este același lucru aici - puteți face aceleași porți numai pentru instrumentele SAST. Va fi aceeași interfață, aceeași poartă de calitate, doar că se va apela poartă de securitate. Și, de asemenea, dacă aveți un proces care utilizează SonarQube, puteți integra cu ușurință totul acolo.

Integrarea la nivel CI

Totul aici este, de asemenea, destul de simplu:

• La egalitate cu autotestele, teste unitare.
• Împărțirea pe etape de dezvoltare: dev, test, prod. Pot fi incluse diferite seturi de reguli sau diferite condiții de eșec: opriți asamblarea, nu opriți asamblarea.
• Lansare sincronă/asincronă. Așteptăm sau nu sfârșitul testelor de securitate. Adică tocmai le-am lansat și mergem mai departe, iar apoi obținem statutul că totul este bun sau rău.

Totul este într-o lume roz perfectă. Nu există așa ceva în viața reală, dar ne străduim. Rezultatul efectuării controalelor de securitate ar trebui să fie similar cu rezultatele testelor unitare.

De exemplu, am luat un proiect mare și am decis că acum îl vom scana cu SAST - OK. Am împins acest proiect în SAST, ne-a oferit 20 de vulnerabilități și, printr-o decizie puternică, am decis că totul este bine. 000 de vulnerabilități sunt datoria noastră tehnică. Vom pune datoria într-o cutie, o vom curăța încet și vom adăuga erori la dispozitivele de urmărire a defectelor. Să angajăm o companie, să facem totul singuri sau să ne ajute Campionii Securității - și datoria tehnică va scădea.

Și toate vulnerabilitățile nou apărute din noul cod trebuie eliminate în același mod ca erorile dintr-o unitate sau din autotestele. Relativ vorbind, a început montajul, l-am rulat, două teste și două teste de securitate au eșuat. OK - ne-am dus, ne-am uitat la ce s-a întâmplat, am reparat un lucru, am reparat altul, l-am rulat data viitoare - totul a fost bine, nu au apărut noi vulnerabilități, nici un test nu a eșuat. Dacă această sarcină este mai profundă și trebuie să o înțelegeți bine, sau repararea vulnerabilităților afectează straturi mari din ceea ce se află sub capotă: a fost adăugat un bug la trackerul defectelor, acesta este prioritizat și corectat. Din păcate, lumea nu este perfectă, iar testele eșuează uneori.

Un exemplu de poartă de securitate este un analog al unei porți de calitate, în ceea ce privește prezența și numărul de vulnerabilități din cod.

Ne integrăm cu SonarQube - pluginul este instalat, totul este foarte convenabil și cool.

Integrare cu mediul de dezvoltare

Opțiuni de integrare:

• Rularea unei scanări din mediul de dezvoltare înainte de comitere.
• Vezi rezultate.
• Analiza rezultatelor.
• Sincronizare cu serverul.

Așa arată să primiți rezultate de la server.

În mediul nostru de dezvoltare Intelect IDEA pur și simplu apare un element suplimentar care vă informează că astfel de vulnerabilități au fost detectate în timpul scanării. Puteți edita imediat codul, vă uitați la recomandări și Graficul fluxului. Toate acestea se află la locul de muncă al dezvoltatorului, ceea ce este foarte convenabil - nu este nevoie să urmați alte link-uri și să priviți ceva suplimentar.

Open Source

Acesta este subiectul meu preferat. Toată lumea folosește biblioteci Open Source - de ce să scrieți o grămadă de cârje și biciclete când puteți lua o bibliotecă gata făcută în care totul este deja implementat?

Desigur, acest lucru este adevărat, dar bibliotecile sunt scrise și de oameni, includ și anumite riscuri și există și vulnerabilități care sunt raportate periodic, sau constant. Prin urmare, există următorul pas în Securitatea aplicațiilor - aceasta este analiza componentelor Open Source.

Analiză Open Source - OSA

Instrumentul include trei etape mari.

Căutarea vulnerabilităților în biblioteci. De exemplu, instrumentul știe că folosim o bibliotecă și că în CVE sau există unele vulnerabilități în instrumentele de urmărire a erorilor care se referă la această versiune a bibliotecii. Când încercați să îl utilizați, instrumentul va emite un avertisment că biblioteca este vulnerabilă și vă sfătuiește să utilizați o altă versiune care nu are vulnerabilități.

Analiza purității licenței. Acest lucru nu este încă deosebit de popular aici, dar dacă lucrați în străinătate, atunci din când în când puteți obține o taxă acolo pentru utilizarea unei componente open source care nu poate fi folosită sau modificată. Conform politicii bibliotecii licențiate, nu putem face acest lucru. Sau, dacă l-am modificat și îl folosim, ar trebui să postăm codul nostru. Desigur, nimeni nu dorește să publice codul produselor lor, dar vă puteți proteja și de acest lucru.

Analiza componentelor care sunt utilizate într-un mediu industrial. Să ne imaginăm o situație ipotetică în care am finalizat în sfârșit dezvoltarea și am lansat cea mai recentă versiune a microserviciului nostru. Trăiește acolo minunat - o săptămână, o lună, un an. Nu îl colectăm, nu efectuăm verificări de siguranță, totul pare să fie în regulă. Dar brusc, la două săptămâni de la lansare, apare o vulnerabilitate critică în componenta Open Source, pe care o folosim în această versiune specială, în mediul industrial. Dacă nu înregistrăm ce și unde folosim, atunci pur și simplu nu vom vedea această vulnerabilitate. Unele instrumente au capacitatea de a monitoriza vulnerabilitățile din bibliotecile care sunt utilizate în prezent în industrie. E foarte folositor.

caracteristici:

• Politici diferite pentru diferite stadii de dezvoltare.
• Monitorizarea componentelor într-un mediu industrial.
• Controlul bibliotecilor din cadrul organizației.
• Suport pentru diverse sisteme și limbi de construcție.
• Analiza imaginilor Docker.

Câteva exemple de lideri din industrie care sunt implicați în analiza Open Source.

Singurul gratuit este acesta Dependență-Verificare de la OWASP. Îl poți porni în primele etape, vezi cum funcționează și ce suportă. Practic, toate acestea sunt produse cloud, sau on-premise, dar în spatele bazei lor sunt încă trimise pe Internet. Ei nu trimit bibliotecile tale, ci hash-uri sau propriile valori, pe care le calculează, și amprente digitale către serverul lor pentru a primi informații despre prezența vulnerabilităților.

Integrarea proceselor

Controlul perimetral al bibliotecilor, care sunt descărcate din surse externe. Avem depozite externe și interne. De exemplu, Event Central rulează Nexus și dorim să ne asigurăm că nu există vulnerabilități în depozitul nostru cu o stare „critică” sau „ridicată”. Puteți configura proxy folosind instrumentul Nexus Firewall Lifecycle, astfel încât astfel de vulnerabilități să fie eliminate și să nu ajungă în depozitul intern.

Integrarea în CI. La același nivel cu autotestele, testele unitare și împărțirea în etape de dezvoltare: dev, test, prod. În fiecare etapă, puteți descărca orice bibliotecă, puteți utiliza orice, dar dacă există ceva greu cu starea „critică”, poate că merită să atragem atenția dezvoltatorilor asupra acestui lucru în etapa de lansare în producție.

Integrare cu artefacte: Nexus și JFrog.

Integrarea în mediul de dezvoltare. Instrumentele pe care le alegeți ar trebui să aibă integrare cu mediile de dezvoltare. Dezvoltatorul trebuie să aibă acces la rezultatele scanării de la locul său de muncă sau capacitatea de a scana și verifica el însuși codul pentru vulnerabilități înainte de a se angaja în CVS.

Integrare CD. Aceasta este o caracteristică cool care îmi place foarte mult și despre care am vorbit deja - monitorizarea apariției unor noi vulnerabilități într-un mediu industrial. Funcționează așa ceva.

Avem Arhivele publice de componente — unele instrumente din exterior și depozitul nostru intern. Dorim ca acesta să conțină doar componente de încredere. Când trimitem o solicitare prin proxy, verificăm dacă biblioteca descărcată nu are vulnerabilități. Dacă se încadrează în anumite politici pe care le stabilim și ne coordonăm în mod necesar cu dezvoltarea, atunci nu îl încărcăm și ni se solicită să folosim o altă versiune. În consecință, dacă există ceva cu adevărat critic și rău în bibliotecă, atunci dezvoltatorul nu va primi biblioteca în etapa de instalare - lăsați-l să folosească o versiune mai mare sau mai mică.

• Când construim, verificăm că nimeni nu a alunecat nimic rău, că toate componentele sunt în siguranță și nimeni nu a adus nimic periculos pe unitatea flash.
• Avem doar componente de încredere în depozit.
• La implementare, verificăm încă o dată pachetul în sine: war, jar, DL sau imagine Docker pentru a ne asigura că respectă politica.
• La intrarea în industrie, monitorizăm ce se întâmplă în mediul industrial: vulnerabilități critice apar sau nu apar.

Analiza dinamică - DAST

Instrumentele de analiză dinamică sunt fundamental diferite de tot ceea ce s-a spus înainte. Acesta este un fel de imitație a muncii utilizatorului cu aplicația. Dacă aceasta este o aplicație web, trimitem solicitări, simulând munca clientului, facem clic pe butoanele din față, trimitem date artificiale din formular: ghilimele, paranteze, caractere în diferite codificări, pentru a vedea cum funcționează și procesează aplicația date externe.

Același sistem vă permite să verificați vulnerabilitățile șablonului în Open Source. Deoarece DAST nu știe ce sursă deschisă folosim, pur și simplu aruncă modele „răuitoare” și analizează răspunsurile serverului:

- Da, aici este o problemă de deserializare, dar nu aici.

Există riscuri mari în asta, pentru că dacă efectuați acest test de securitate pe aceeași bancă cu care lucrează testerii, se pot întâmpla lucruri neplăcute.

• Sarcină mare în rețeaua serverului de aplicații.
• Fara integrari.
• Posibilitatea de a modifica setările aplicației analizate.
• Nu există suport pentru tehnologiile necesare.
• Dificultate de configurare.

Am avut o situație când am lansat în sfârșit AppScan: am petrecut mult timp încercând să obținem acces la aplicație, am primit 3 conturi și am fost mulțumiți - în sfârșit vom verifica totul! Am lansat o scanare, iar primul lucru pe care l-a făcut AppScan a fost să intri în panoul de administrare, să străpungem toate butoanele, să schimbăm jumătate din date și apoi să omorâm complet serverul cu formularul de poștă-cereri. Dezvoltarea cu testare a spus:

- Băieți, vă bateți joc de mine?! Ți-am dat conturi și ai amenajat un stand!

Luați în considerare posibilele riscuri. În mod ideal, pregătiți un stand separat pentru testarea securității informațiilor, care va fi izolat de restul mediului cel puțin cumva și verificați condiționat panoul de administrare, de preferință în modul manual. Acesta este un pentest - acele procente de efort rămase pe care nu le luăm în considerare acum.

Merită să luați în considerare faptul că puteți utiliza acest lucru ca analog al testării de sarcină. În prima etapă, puteți porni un scanner dinamic cu 10-15 fire și puteți vedea ce se întâmplă, dar de obicei, după cum arată practica, nimic bun.

Câteva resurse pe care le folosim de obicei.

Merita subliniat Suită Burp este un „cuțit elvețian” pentru orice profesionist în securitate. Toată lumea îl folosește și este foarte convenabil. O nouă versiune demo a ediției Enterprise a fost lansată acum. Dacă mai devreme era doar un utilitar de sine stătător cu pluginuri, acum dezvoltatorii realizează în sfârșit un server mare de pe care va fi posibil să gestionezi mai mulți agenți. Este tare, recomand să-l încercați.

Integrarea proceselor

Integrarea se întâmplă destul de bine și simplu: începe scanarea după instalarea cu succes aplicatii pentru stand si scanare după testarea de integrare cu succes.

Dacă integrările nu funcționează sau există stub-uri și funcții simulate, este inutil și inutil - indiferent de modelul pe care îl trimitem, serverul va răspunde în continuare la fel.

• În mod ideal, un stand de testare separat.
• Înainte de testare, notați secvența de conectare.
• Testarea sistemului de administrare este doar manuală.

proces

Puțin generalizat despre proces în general și despre munca fiecărui instrument în particular. Toate aplicațiile sunt diferite - una funcționează mai bine cu analiza dinamică, alta cu analiză statică, o a treia cu analiză OpenSource, pentest-uri sau cu totul altceva, de exemplu, evenimente cu waf.

Fiecare proces are nevoie de control.

Pentru a înțelege cum funcționează un proces și unde poate fi îmbunătățit, trebuie să colectați valori din tot ceea ce puteți pune mâna, inclusiv valorile de producție, valorile din instrumente și din instrumentele de urmărire a defectelor.

Orice informatie este de ajutor. Este necesar să privim din unghiuri diferite unde este mai bine utilizat acest sau acel instrument, unde procesul în mod specific se lasă. Ar putea fi în valoare de a analiza timpii de răspuns la dezvoltare pentru a vedea unde să îmbunătățim procesul în funcție de timp. Cu cât sunt mai multe date, cu atât mai multe secțiuni pot fi construite de la nivelul superior până la detaliile fiecărui proces.

Deoarece toți analizatorii statici și dinamici au propriile lor API-uri, propriile lor metode de lansare, principii, unii au programatori, alții nu - scriem un instrument AppSec Orchestrator, care vă permite să creați un singur punct de intrare în întregul proces din produs și să îl gestionați dintr-un singur punct.

Managerii, dezvoltatorii și inginerii de securitate au un punct de intrare din care pot vedea ce rulează, configura și rula o scanare, pot primi rezultatele scanării și pot trimite cerințe. Încercăm să ne îndepărtăm de hârtii, să transpunem totul într-unul uman, care este folosit de dezvoltare - pagini pe Confluence cu status și metrici, defecte în Jira sau în diverse trackere de defect, sau integrare într-un proces sincron/asincron în CI /CD.

Intrebari cu cheie

Instrumentele nu sunt principalul lucru. Mai întâi gândiți-vă la proces - apoi implementați instrumentele. Instrumentele sunt bune, dar costisitoare, așa că puteți începe cu procesul și puteți construi comunicarea și înțelegerea între dezvoltare și securitate. Din punct de vedere al siguranței, nu este nevoie să „opriți” totul. Din punct de vedere al dezvoltării, dacă există ceva mega super critic, atunci trebuie eliminat și nu închideți ochii la problemă.

Calitatea produsului - Tel comun atât securitatea cât și dezvoltarea. Facem un lucru, încercăm să ne asigurăm că totul funcționează corect și că nu există riscuri reputaționale sau pierderi financiare. De aceea promovăm o abordare DevSecOps, SecDevOps pentru a îmbunătăți comunicarea și a îmbunătăți calitatea produsului.

Începe cu ceea ce ai deja: cerințe, arhitectură, verificări parțiale, traininguri, linii directoare. Nu este nevoie să aplicați imediat toate practicile tuturor proiectelor - mișcă iterativ. Nu există un singur standard - experiment și încercați abordări și soluții diferite.

Există un semn egal între defectele de securitate a informațiilor și defectele funcționale.

Automatizează totulcare se mișcă. Orice nu se mișcă, mutați-l și automatizați-l. Dacă ceva este făcut manual, nu este o parte bună a procesului. Poate că merită să-l revizuiți și să îl automatizați.

Dacă dimensiunea echipei IS este mică - folosiți Campionii de securitate.

Poate că ceea ce am vorbit nu ți se va potrivi și vei veni cu ceva al tău - și asta e bine. Dar alegeți instrumentele în funcție de cerințele procesului dvs. Nu te uita la ce spune comunitatea, că acest instrument este rău și acesta este bun. Poate că opusul va fi adevărat pentru produsul dvs.

Cerințe pentru unelte.

• Nivel scăzut fals pozitiv.
• Timp de analiză adecvat.
• Ușurința de utilizare.
• Disponibilitatea integrărilor.
• Înțelegerea foii de parcurs de dezvoltare a produsului.
• Posibilitate de personalizare a instrumentelor.

Raportul lui Yuri a fost ales ca unul dintre cele mai bune la DevOpsConf 2018. Pentru a face cunoștință cu idei și mai interesante și cazuri practice, veniți la Skolkovo pe 27 și 28 mai DevOpsConf în festivalul RIT++. Mai bine, dacă sunteți gata să vă împărtășiți experiența, atunci aplica pentru raport până pe 21 aprilie.

Sursa: www.habr.com