Am avut 2 analizatori de cod, 4 instrumente pentru testare dinamică, propriile creații și 250 de scripturi. Nu că ar fi fost toate necesare în procesul actual, dar odată ce am început implementarea DevSecOps, trebuie să mergem până la capăt.
. Creatorii personajelor: Justin Roiland și Dan Harmon.
Ce este SecDevOps? Și DevSecOps? Care sunt diferențele? Ce înseamnă Securitatea Aplicațiilor? De ce abordarea clasică nu mai funcționează? La toate aceste întrebări știe răspunsul Yuri Shabalin din Swordfish Security. Yuri va răspunde detaliat la tot ș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 sigură în procesul DevOps fără a strica nimic, cum să treci prin etapele principale de testare a securității, ce instrumente pot fi folosite, cu ce se deosebesc și cum să le configurezi corect pentru a evita capcanele.
Despre vorbitor: Yuri Shabalin — Chief Security Architect la Swordfish Security. Este responsabil pentru implementarea SSDL, pentru integrarea generală a instrumentelor de analiză a aplicațiilor într-o ecosistemă unificată de dezvoltare și testare. Are 7 ani de experiență în securitate informațională. A lucrat la Alfa-Bank, Sberbank și la Positive Technologies, care dezvoltă software și oferă servicii. Vorbitor la conferințe internaționale cum ar fi ZerONights, PHDays, RISSPA, OWASP.
Securitatea Aplicațiilor: ce înseamnă?
Securitatea Aplicațiilor — este o ramură a securității care se ocupă cu securitatea aplicațiilor. Aceasta nu se referă la infrastructură sau la securitatea rețelei, ci la ceea ce scriem și la ce lucrează dezvoltatorii — adică la defectele și vulnerabilitățile aplicației în sine.
Direcția — Ciclul de viață al dezvoltării securității — a fost dezvoltat de Microsoft. În schema de mai sus se află modelul canonic SDLC, a cărui sarcină principală este participarea securității la fiecare etapă a dezvoltării, de la cerințe până la lansare și producție. Microsoft a realizat că în industrie sunt prea multe bug-uri și că acestea devin mai multe, iar cu asta trebuie făcut ceva, iar această abordare a fost propusă și de atunci a devenit canonică.
Securitatea Aplicațiilor și SSDL sunt orientate nu spre identificarea vulnerabilităților, așa cum se crede de obicei, ci spre prevenirea apariției acestora. De-a lungul timpului, abordarea canonică de la Microsoft a fost îmbunătățită, dezvoltată, având o aprofundare mai detaliată.
Ciclul de viață software (SDLC) este detaliat în diferite metodologii – OpenSAMM, BSIMM, OWASP. Metodologiile diferă, dar în general, sunt similare.
Modelul de Maturitate a Securității în Construire
Cel mai mult îmi place BSIMM — . Fundamentul metodologiei este împărțirea procesului de Securitate a Aplicațiilor în 4 domenii: Guvernanță, Inteligență, Puncte de contact SSDL și Implementare. Fiecare domeniu are 12 practici, prezentate sub formă de 112 activități.
Fiecare dintre cele 112 activități are 3 niveluri de maturitate: inițial, mediu și avansat. Toate cele 12 practici pot fi studiate pe secțiuni, selectând aspectele importante pentru tine, învățând cum să le implementezi și adăugând treptat elemente, cum ar fi analiza statică și dinamică a codului sau revizuirea codului. Îți elaborezi un plan și lucrezi liniștit în cadrul implementării activităților selectate.
De ce DevSecOps
DevOps este un proces mare, complex, în care trebuie să ai grijă de securitate.
Inițial era a prevăzut verificări de securitate. În practică, numărul echipelor de securitate era mult mai mic decât acum, iar acestea acționau nu ca participanți în proces, ci ca un organism de control și supraveghere, care impune cerințe și verifică calitatea produsului la finalul rundei de lansări. Aceasta este abordarea clasică, în care echipele de securitate se aflau în spatele unui zid față de dezvoltare și nu participau în proces.
Principala problemă este tocmai că securitatea informațională este separată de dezvoltare. De obicei, există un anumit contur de securitate informațională, în care se află 2-3 instrumente mari și scumpe. O dată la șase luni se primește codul sursă sau aplicația care trebuie verificată, iar o dată pe an se efectuează . Toate acestea duc la întârzieri în livrarea produsului pe piață, iar dezvoltatorii se confruntă cu un număr imens de vulnerabilități provenite din instrumente automatizate. Totul este imposibil de analizat și reparat, deoarece n-au fost analizate rezultatele din ultimele șase luni, iar acum a apărut o nouă serie.
În procesul activității noastre, observăm că securitatea în toate domeniile și industriile înțelege că este timpul să se sincronizeze și să colaboreze cu dezvoltarea într-un singur ritm – în . Paradigma DevSecOps se potrivește perfect cu metodologia de dezvoltare agilă, cu implementarea, suportul și participarea în fiecare lansare și iterație.
Tranziția către DevSecOps
Cel mai important cuvânt în Ciclul de Viață al Dezvoltării Securizate este "proces"Trebuie să înțelegeți acest lucru înainte de a lua în considerare achiziția de instrumente.
A include instrumente în procesul DevOps nu este suficient - interacțiunea și înțelegerea între participanții la proces sunt importante.
Oamenii sunt mai importanți decât instrumentele.
De multe ori, planificarea procesului de dezvoltare sigură începe cu alegerea și achiziționarea unui instrument, dar se termină cu încercări de integrare a instrumentului în procesul actual, care rămân doar încercări. Acest lucru duce la consecințe triste, deoarece fiecare instrument are propriile sale caracteristici și limitări.
Un caz frecvent este atunci când departamentul de securitate a ales un instrument bun, scump, cu posibilități largi și s-a dus la dezvoltatori pentru a-l integra în proces. Dar nu funcționează - procesul este construit astfel încât limitările instrumentului deja achiziționat nu se aliniază cu 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 securității în proces.
Începeți cu ceea ce este deja folosit.
Înainte de a achiziționa instrumente scumpe, aruncați o privire asupra a ceea ce aveți deja. Fiecare companie are cerințe de securitate care sunt impuse dezvoltării, există verificări, teste de penetrare - de ce să nu transformați totul într-o formă clară și convenabilă pentru toți?
De obicei, cerințele sunt un document greu, care stă pe o poliță. A fost un caz când am ajuns într-o companie să analizăm procesele și am cerut să ne arate cerințele de securitate pentru software. Specialistul responsabil cu acest lucru a căutat mult:
— Acum, undeva în notițe am avut calea unde se află acest document.
În cele din urmă, am obținut documentul după o săptămână.
Pentru cerințe, verificări și altele, creați o pagină, de exemplu, pe Confluence — este convenabil pentru toată lumea.
Este mai simplu să reformatați ceea ce există deja și să folosiți pentru început.
Folosiți Security Champions.
În general, într-o companie medie de 100-200 de dezvoltatori lucrează un specialist în securitate, care îndeplinește mai multe funcții și nu are timpul fizic să verifice totul. Chiar dacă se străduiește din greu - nu poate verifica singur tot codul generat de dezvoltare. Pentru astfel de cazuri a fost dezvoltat conceptul de .
Security Champions sunt persoane din echipa de dezvoltare care sunt interesate de securitatea produsului dumneavoastră.
Security Champion este un punct de contact în echipa de dezvoltare și un avocat al securității într-o singură persoană.
De obicei, când un specialist în securitate se alătură echipei de dezvoltare și indică o eroare în cod, răspunsul pe care îl primește este de obicei surprins:
— Și cine ești tu? Te văd pentru prima dată. Eu sunt bine — mentorul meu mi-a dat «apply» la code review, continuăm mai departe!
Aceasta este o situație tipică, deoarece există mult mai multă încredere în colegii mai vechi sau în cei cu care dezvoltatorul interacționează constant la locul de muncă și în code review. Dacă, în loc de specialistul în securitate, Security Champion atrage atenția asupra erorii și a consecințelor, atunci cuvântul său va avea mai multă greutate.
De asemenea, dezvoltatorii cunosc mai bine codul lor decât orice specialist în securitate. Pentru cineva care are cel puțin 5 proiecte în instrumentul de analiză statică, este de obicei greu să-și amintească toate nuanțele. Security Champions știu produsul lor: ce interacționează cu ce și la ce să se uite întâi — sunt mai eficienți.
Așadar, gândiți-vă să implementați Security Champions și să extindeți influența echipei de securitate. Pentru însuși campionul, aceasta este de asemenea benefică: dezvoltare profesională într-un nou domeniu, extinderea orizontului tehnic, îmbunătățirea abilităților tehnice, de management și de leadership, creșterea valorii pe piață. Este un element de inginerie socială, «ochii» dumneavoastră în echipa de dezvoltare.
Etapele testării
indică faptul că 20% din eforturi dau 80% din rezultate. Aceste 20% constituie practicile de analiză a aplicațiilor care pot și trebuie automatizate. Exemple de astfel de activități sunt analiza statică — SAST, analiza dinamică — DAST, și controlul Open Source. Voi vorbi mai în detaliu despre activități, dar și despre instrumentele cu care ne confruntăm de obicei în timpul implementării acestora în proces și cum să facem acest lucru corect.
Problemele principale ale instrumentelor
Voi evidenția problemele relevante pentru toate instrumentele, care necesită atenție. Le voi analiza în detaliu pentru a nu mai repeta mai departe.
Timp îndelungat de analiză. Dacă de la commit la lansarea în producție trec 30 de minute pentru toate testele și compilare, atunci verificările de securitate vor dura o zi. Nimeni nu va încetini procesul din această cauză. Luați în considerare această particularitate și trasați concluziile.
Un nivel ridicat de False Negative sau False Positive. Toate produsele sunt diferite, fiecare folosește cadre diferite și propriul stil de scriere a codului. Pe diferite baze de cod și tehnologii, instrumentele pot arăta niveluri diferite de False Negative și False Positive. Așadar, verificați ce anume va arăta în compania dumneavoastră și pentru aplicațiile dumneavoastră un rezultat bun și de încredere. Nu există integrare cu instrumentele existente . Privind instrumentele din perspectiva integrărilor, gândiți-vă la cele pe care deja le folosiți. De exemplu, dacă aveți Jenkins sau TeamCity, verificați integrarea instrumentelor exact cu acel software, nu cu GitLab CI, pe care nu îl utilizați.
Lipsa sau complexitatea excesivă a personalizării.Dacă instrumentul nu are API, atunci de ce este necesar? Tot ce se poate face în interfață ar trebui să fie disponibil și prin API. Ideal, instrumentul ar trebui să permită personalizarea verificărilor.
Lipsa unui Roadmap de dezvoltare a produsului. Dezvoltarea nu stă pe loc, întotdeauna folosim cadre și funcții noi, rescriem codul vechi în limbaje noi. Vrem să fim siguri că instrumentul pe care îl cumpărăm va susține cadre și tehnologii noi. De aceea, este important să știm că produsul are un
plan de dezvoltare real și bine definit. Particularitățile procesului Pe lângă particularitățile instrumentelor, luați în considerare și particularitățile procesului de dezvoltare. De exemplu, a interveni în dezvoltare este o greșeală tipică. Să vedem ce alte particularități ar trebui să luăm în considerare și la ce ar trebui echipa de securitate să fie atentă.
Pentru a nu întârzia termenele de dezvoltare și lansare, creați
reguli diferite
și diferite show stoppers — criterii de oprire a procesului de compilare în prezența vulnerabilităților — pentru diferite medii . De exemplu, înțelegem că ramura curentă merge pe un mediu de dezvoltare sau UAT, așa că nu ne oprim și nu spunem: — Aveți aici vulnerabilități, nu veți merge mai departe!Este important să le spunem dezvoltatorilor, în această etapă, că există probleme de securitate la care ar trebui să fie atenți.
— Aveți vulnerabilități aici, nu veți putea merge mai departe!
În această etapă, este important să spunem dezvoltatorilor că există probleme de securitate la care ar trebui să fie atenți.
Prezența vulnerabilităților nu reprezintă un obstacol pentru testarea ulterioară: manuală, integrată sau manuală. Pe de altă parte, trebuie să găsim o modalitate de a spori securitatea produsului, astfel încât dezvoltatorii să nu ignore ceea ce descoperă echipa de securitate. Așadar, uneori acționăm astfel: pe stand, când se face transferul către mediu de dezvoltare, doar notificăm echipa de dezvoltare:
— Guys, aveți probleme, vă rugăm să le acordați atenție.
În etapa UAT, din nou prezentăm avertizări cu privire la vulnerabilități, iar în etapa de lansare în producție spunem:
— Guys, v-am avertizat de câteva ori, nu ați făcut nimic — cu asta nu vă vom lansa.
Dacă vorbim despre cod și dinamică, este necesar să arătăm și să avertizăm doar cu privire la vulnerabilitățile funcțiilor și codului care au fost scrise recent în această funcție. Dacă dezvoltatorul a mutat un buton cu 3 pixeli și îi spunem că are o injecție SQL și că trebuie să corecteze urgent — este greșit. Uitați-vă doar la ceea ce este scris acum și la modificarea care vine în aplicație.
Să presupunem că avem un defect funcțional — adică modul în care aplicația nu ar trebui să funcționeze: banii nu se transferă, nu există navigare către pagina următoare atunci când faceți clic pe buton sau produsul nu se încarcă. Defectele de securitate — sunt defecte la fel ca orice altele, dar nu în privința funcționării aplicației, ci a securității.
Nu toate problemele de calitate ale 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 defecte, ele ar trebui să se afle acolo unde se află toate defectele de dezvoltare. Așadar, uitați de rapoarte și de PDF-uri înfricoșătoare pe care nimeni nu le citește.
Când lucram într-o companie de dezvoltare, am primit un raport din instrumentele de analiză statică. L-am deschis, am fost devastat, am făcut o cafea, m-am răsfoit 350 de pagini, l-am închis și m-am apucat din nou de muncă. Rapoartele mari sunt rapoarte moarte. De obicei, nu ajung nicăieri, e-mailurile sunt șterse, uitate, pierdute sau business-ul spune că își asumă riscurile.
Ce trebuie să facem? Defectele confirmate identificate sunt transformate într-o formă удобной pentru dezvoltare, de exemplu, adunate în backlog în Jira. Prioritizăm defectele și le remedieze în ordinea priorității, la fel ca defectele funcționale și defectele testelor.
Analiză statică - SAST
Aceasta este analiza codului pentru identificarea vulnerabilităților, dar nu este același lucru cu SonarQube. Verificăm nu doar după modele sau stil. În analiză se aplică o serie de abordări: pe baza arborelui vulnerabilităților, pe , pe analiza fișierelor de configurare. Acestea sunt toate aspectele legate direct de cod.
Avantajele abordării: identificarea vulnerabilităților în cod în etapele timpurii ale dezvoltării, când nu există încă standuri și un instrument gata, și posibilitatea scanării incrementale: scanarea unei porțiuni de cod care a fost modificată și doar a acelei caracteristici pe care o realizăm acum, ceea ce reduce timpul de scanare.
Dezavantaje — este lipsa suportului pentru limbajele necesare.
Integrările necesare, care ar trebui să fie în instrumente, din punctul meu de vedere subiectiv:
- Instrumente de integrare: Jenkins, TeamCity și Gitlab CI.
- Mediul de dezvoltare: Intellij IDEA, Visual Studio. Programatorului îi este mai ușor să nu se joace în interfața confuză, care trebuie încă memorată, ci să vadă toate integrările necesare și vulnerabilitățile identificate direct în locul de muncă, în propriul său mediu de dezvoltare.
- Revizuirea codului: SonarQube și revizuirea manuală.
- Tracker-e de defecte: Jira și Bugzilla.
În imagine sunt câțiva dintre cei mai buni reprezentanți ai analizei statice.
Instrumentele nu sunt importante, ci procesul, de aceea există soluții Open Source care sunt la fel de bune pentru testarea procesului.
SAST Open Source nu va identifica un număr mare de vulnerabilități sau fluxuri de date complexe, dar pot și trebuie utilizate în construirea procesului. Ele ajută la înțelegerea modului în care va fi construit procesul, cine va răspunde la buguri, cine va raporta, cine - va face raportări. Dacă doriți să desfășurați etapa inițială de construcție a securității codului dvs. - folosiți soluții Open Source.
Cum poate fi integrat acest lucru, dacă sunteți la început de drum, nu aveți nimic: nici CI, nici Jenkins, nici TeamCity? Să analizăm integrările în proces.
Integrarea la nivel de CVS
Dacă aveți Bitbucket sau GitLab, puteți face integrarea la nivel de .
Pe bază de eveniment — pull request, commit. Scanați codul și în statusul build-ului arătați dacă verificarea de securitate a trecut sau nu.
Feedback. Desigur, feedback-ul este întotdeauna necesar. Dacă ați efectuat pur și simplu acțiuni pe partea de securitate, le-ați pus într-o cutie și nu ați spus nimănui despre asta, iar apoi, la sfârșitul lunii, ați aruncat o mulțime de bug-uri - nu este corect și nu este bine.
Integrarea cu sistemul de revizuire a codului
Odată, am numit ca revizor implicit utilizatorul tehnic AppSec în cadrul unor proiecte importante. În funcție de faptul dacă au fost identificate erori în noul cod sau nu, revizorul pune un status pe pull request ca „acceptat” sau „necesită lucru” - fie totul OK, fie trebuie să se lucreze la asta, cu legături la ceea ce trebuie să fie îmbunătățit. La integrarea cu versiunea care merge în producție, am activat interdicția de merge dacă testul de securitate nu a fost trecut. Aceasta a fost inclusă în revizuirea manuală a codului, iar ceilalți participanți la proces au văzut statusurile de securitate specifice pentru acest proces anume.
Integrarea cu SonarQube
Multe persoane au în ceea ce privește calitatea codului. Aici este la fel - se pot face aceleași gates doar pentru instrumentele SAST. Va exista aceeași interfață, același gates de calitate, doar că se va numi gates de securitate. Și, de asemenea, dacă aveți un proces setat folosind SonarQube, puteți să integrați totul fără probleme.
Integrarea la nivel de CI
Aici totul este destul de simplu:
- La același nivel cu testele automate, testele unității.
- Separarea pe etapele de dezvoltare: dev, test, prod. Pot fi incluse diferite seturi de reguli, sau diferite condiții de eșec: oprim compilarea, nu oprim compilarea.
- Executare sincronă/asynchronă. Așteptăm finalizarea verificării testelor de securitate sau nu așteptăm. Adică le-am pur și simplu lansat și mergem mai departe, iar apoi primim statusul că totul este bine sau rău.
Toate acestea se află în lumea ideală. În viața reală, nu există așa ceva, dar ne străduim. Rezultatul executării verificărilor de securitate ar trebui să fie similar cu rezultatele testelor unității.
De exemplu, am preluat un proiect mare și am decis că acum îl vom scana cu SAST – OK. Am introdus acest proiect în SAST, a generat 20.000 de vulnerabilități și, printr-o decizie fermă, am acceptat că totul este bine. 20.000 de vulnerabilități reprezintă datoria noastră tehnică. O vom pune într-o cutie, vom începe să o abordăm treptat și vom înregistra bug-uri în defect trackers. Vom angaja o companie, vom face totul singuri sau ne vor ajuta Security Champions – și datoria tehnică va scădea.
Iar toate vulnerabilitățile nou apărute în codul nou trebuie rezolvate la fel ca erorile din teste unitare sau din autotestare. Pe scurt, construit un build, au rulat teste, au picat două teste și două teste de securitate. OK – am mers, am verificat ce s-a întâmplat, am corectat una, am corectat cealaltă, data următoare am rulat – totul bine, nu au apărut vulnerabilități noi, testele nu au picat. Dacă această sarcină este mai complexă și trebuie să ne aprofundăm bine în ea, sau dacă remedierea vulnerabilităților afectează mari segmente ale ceea ce se află sub capotă: am înregistrat un bug în defect tracker, acesta va fi prioritizat și corectat. Din păcate, lumea nu este perfectă iar testele uneori pică.
Exemplu de security gate – analog cu quality gate, în ceea ce privește prezența și numărul de vulnerabilități în cod.
Integrăm cu SonarQube – pluginul se instalează, totul este foarte convenabil și grozav.
Integrând cu mediul de dezvoltare
Posibilități de integrare:
- Lansarea scanării din mediul de dezvoltare chiar înainte de commit.
- Vizualizarea rezultatelor.
- Analiza rezultatelor.
- Sincronizarea cu serverul.
Așa arată obținerea rezultatelor de la server.
În mediul nostru de dezvoltare apare pur și simplu un punct suplimentar, care informează că în timpul scanării au fost descoperite astfel de vulnerabilități. Poți corecta imediat codul, vizualiza recomandările și . Totul este plasat pe locul de muncă al dezvoltatorului, ceea ce este foarte convenabil – nu trebuie să navighezi pe alte linkuri și să cauți ceva suplimentar.
Open Source
Aceasta este tema mea preferată. Toată lumea folosește biblioteci Open Source – de ce să scriem o mulțime de soluții improvizate și biciclete, când putem lua o bibliotecă gata făcută, în care totul este deja implementat?
Desigur, așa este, dar bibliotecile sunt scrise și de oameni, includ, de asemenea, anumite riscuri și au vulnerabilități despre care se raportează periodic sau constant. Prin urmare, următorul pas în Securitatea Aplicațiilor este analiza componentelor Open Source.
Analiza Open Source - OSA
Instrumentul include trei etape mari.
Identificarea vulnerabilităților în biblioteci. De exemplu, instrumentul știe că folosim o anumită bibliotecă și că în sau în bug-tracker există unele vulnerabilități legate de această versiune a bibliotecii. În cazul utilizării acesteia, instrumentul va emite o avertizare că biblioteca este vulnerabilă și va recomanda să se utilizeze o altă versiune care nu are vulnerabilități.
Analiza curățeniei licențelor. Pentru noi, aceasta nu este încă foarte populară, dar dacă colaborați cu persoane din străinătate, atunci periodic puteți primi o atenționare pentru utilizarea unei componente cu cod sursă deschis pe care nu o puteți folosi sau modifica. Conform politicii bibliotecii licențiate, nu putem face acest lucru. Sau, dacă am modificat-o și o folosim, trebuie să publicăm codul nostru. Desigur, nimeni nu dorește să publice codul produselor sale, dar există și modalități de a vă proteja de acest lucru.
Analiza componentelor utilizate în medii industriale. Să presupunem o situație ipotetică în care în sfârșit am finalizat dezvoltarea și am lansat ultima versiune a microserviciului nostru. Acesta funcționează minunat - o săptămână, o lună, un an. Nu îl mai îmbunătățim, nu efectuăm verificări de securitate, părea că totul este în regulă. Dar, brusc, la două săptămâni după lansare, apare o vulnerabilitate critică în componenta Open Source pe care o folosim exact în această construcție, în mediu de producție. Dacă nu notăm ce și unde folosim, atunci această vulnerabilitate pur și simplu nu o vom observa. Unele instrumente oferă posibilitatea de monitorizare a vulnerabilităților în bibliotecile care sunt folosite în prezent în producție. Aceasta este foarte util.
Funcționalități:
- Diverse politici pentru diferite etape de dezvoltare.
- Monitorizarea componentelor în mediul industrial.
- Controlul bibliotecilor în cadrul organizației.
- Suport pentru diferite sisteme de construire și limbi.
- Analiza imaginilor Docker.
Câteva exemple de lideri din domeniu care se ocupă cu analiza Open Source.
Singurul gratuit dintre acestea este de la OWASP. Poate fi activat în stadiile inițiale pentru a vedea cum funcționează și ce suport oferă. În principal, se referă la toate produsele cloud sau on-premise, dar deși au propria bază de date, tot sunt conectate la internet. Ele nu trimit bibliotecile dumneavoastră, ci hash-uri sau propriile valori pe care le calculează, împreună cu amprentele, către serverul lor pentru a obține notificări cu privire la vulnerabilități.
Integrarea în proces
Controlul bibliotecilor în perimetrul, care sunt descărcate din surse externe. Avem un depozit extern și unul intern. De exemplu, în interiorul Event Central avem Nexus, și dorim ca în depozitul nostru intern să nu existe vulnerabilități cu statutul 'critice' sau 'elevate'. Se poate configura un proxy folosind instrumentul Nexus Firewall Lifecycle pentru a bloca astfel de vulnerabilități astfel încât să nu ajungă în depozitul intern.
Integrarea în CI. La același nivel cu teste automate, teste unitare și împărțirea pe etape de dezvoltare: dev, test, prod. În fiecare etapă se pot descărca orice biblioteci, se poate folosi orice, dar dacă există ceva sever cu statutul 'critică' - poate ar trebui să atragă atenția dezvoltatorilor în etapa de producție.
Integrarea cu artefacte: Nexus și JFrog.
Integrarea în medii de dezvoltare. Instrumentele pe care le alegeți trebuie să aibă integrare cu mediile de dezvoltare. Dezvoltatorul ar trebui să aibă acces la rezultatele scanării de pe stația de lucru sau posibilitatea de a scana el însuși și de a verifica codul pentru vulnerabilități înainte de a-l comite în CVS.
Integrarea în CD. Aceasta este o funcție fantastică care îmi place foarte mult și despre care am vorbit deja - monitorizarea apariției de noi vulnerabilități în mediul industrial. Funcționează cam așa.
Avem Depozite Publice de Componente — unele instrumente externe și depozitul nostru intern. Vrem ca acesta să conțină doar componente de încredere. Atunci când proxy-izăm o cerere, verificăm că biblioteca descărcată nu are vulnerabilități. Dacă aceasta se încadrează în anumite politici stabilite și obligatoriu aprobate cu echipa de dezvoltare, atunci nu o descărcăm și se trimite un mesaj pentru utilizarea unei alte versiuni. Prin urmare, dacă biblioteca conține ceva critic și dăunător, dezvoltatorul nu va primi biblioteca chiar la etapa de instalare — va trebui să folosească o versiune superioară sau inferioară.
- În timpul build-ului, verificăm că nimeni nu a introdus nimic dăunător, că toate componentele sunt sigure și că nimeni nu a adus pe flash drive nimic periculos.
- În depozit avem doar componente de încredere.
- La deploy, verificăm din nou pachetul în sine: war, jar, DL sau imagine Docker pentru a ne asigura că se conformează politicii.
- La ieșirea în producție, monitorizăm ce se întâmplă în mediul industrial: dacă apar sau nu vulnerabilități critice.
Analiza dinamică — DAST
Instrumentele de analiză dinamică sunt radical diferite de tot ce s-a spus până acum. Acestea reprezintă o simulare a interacțiunii utilizatorului cu aplicația. Dacă este o aplicație web, trimitem cereri, imitând activitatea clientului, apăsăm butoanele de pe frontend, trimitem date artificiale din formulare: ghilimele, paranteze, simboluri în diferite codificări, pentru a observa cum funcționează și cum procesează aplicația datele externe.
Acest sistem permite de asemenea verificarea vulnerabilităților comune în Open Source. Deoarece DAST nu știe ce Open Source folosim, pur și simplu aruncă „patternuri rău intenționate” și analizează răspunsurile serverului:
— Ah, aici există o problemă de deserializare, iar aici nu.
Acest lucru presupune riscuri mari, deoarece dacă efectuați acest test de securitate pe același mediu în care lucrează testeri — pot apărea lucruri neplăcute.
- Încărcare ridicată pe serverul de aplicații.
- Nu există integrații.
- Posibilitatea de a modifica setările aplicației analizate.
- Nu există suport pentru tehnologiile necesare.
- Dificultăți în configurare.
Am avut o situație în care, în sfârșit, am lansat AppScan: am obținut cu greu acces la aplicație, am primit 3 conturi și ne-am bucurat — în sfârșit, vom verifica totul! Am început scanarea, iar primul lucru pe care l-a făcut AppScan — a intrat în panoul de administrare, a apăsat toate butoanele, a schimbat jumătate din date și apoi, în cele din urmă, a crăpat serverul. -solicitări. Dezvoltarea cu testarea a spus:
— Oameni buni, faceți mișto?! V-am dat conturi, iar voi ați distrus standul!
Luați în considerare riscurile posibile. Ideal ar fi să pregătiți un stand separat pentru testarea securității, care să fie izolat de restul mediului, și, în mod ideal, să verificați panoul de administrare preferabil în mod manual. Acesta este un pentest — ultimele procente de efort pe care acum nu le considerăm.
Ar trebui avut în vedere că se poate folosi ca un analog al testării de încărcare. În prima etapă, puteți activa scanerul dinamic în 10-15 fire și să observați ce se întâmplă, dar, de obicei, cum arată practica, nu iese nimic bun.
Câteva resurse pe care le folosim de obicei.
Ar trebui să evidențiem — acesta este un „cuțit elvețian” pentru orice specialist în securitate. Toată lumea îl folosește și este foarte convenabil. A ieșit acum o nouă versiune demo a ediției enterprise. Dacă anterior era doar un utilitar stand-alone cu plugin-uri, acum, în sfârșit, dezvoltatorii creează un server mare, de pe care se vor putea gestiona mai mulți agenți. Este grozav, recomand să încercați.
Integrarea în proces
Integrarea se face destul de bine și simplu: lansarea scanării după instalarea cu succes aplicației pe stand și scanarea după finalizarea cu succes a testării de integrare.
Dacă integrarea nu funcționează sau există stub-uri și funcții mock, este inutil și lipsit de valoare — oricât de multe pattern-uri am trimite, serverul va răspunde tot timpul la fel.
- Ideal — un stand separat pentru testare.
- Înainte de a începe testarea, notați secvența de login.
- Testarea sistemului de administrare — doar manuală.
Procesul
Puțin generalizat despre procesul în ansamblu și despre munca fiecărui instrument, în special. Toate aplicațiile sunt diferite — unele au un analizator dinamic mai bun, altele static, altele analize OpenSource, penteste sau ceva complet diferit, de exemplu, evenimentele cu .
Fiecare proces are nevoie de control.
Pentru a înțelege cum funcționează procesul și unde poate fi îmbunătățit, este necesar să colectăm metrici din tot ce putem atinge, inclusiv metrici de producție, metrici din instrumente și din trackere de defecte.
Orice date sunt utile. Trebuie să ne uităm din diverse unghiuri la unde este cel mai bine aplicat un anumit instrument, unde procesul scade specific. Poate că ar trebui să analizăm timpul de răspuns al dezvoltării pentru a înțelege unde putem îmbunătăți procesul pe baza timpului. Cu cât avem mai multe date, cu atât putem construi mai multe unghiuri, de la cele de nivel înalt până la detaliile fiecărui proces.
Pentru că toți analizoarele statice și dinamice au propriile lor API-uri, propriile moduri de a fi lansate, principii, unii au planificatoare, iar alții nu, scriem un instrument AppSec Orchestrator, care permite crearea unui singur punct de acces pentru întregul proces cu produsul și gestionarea lui dintr-un singur loc.
Managerii, dezvoltatorii și inginerii de securitate au un singur punct de acces, din care pot vedea ce este inițiat, pot configura și lansa scanarea, obține rezultatele scanării, prezenta cerințe. Încercăm să ne îndepărtăm de hârtiuțe, traducând totul în format uman, utilizat de dezvoltare - pagini pe Confluence cu statut și metrici, defecte în Jira sau în diferite trackere de defecte, sau integrarea în procesul sincron sau asincron în CI/CD.
Puncte cheie de învățare
Instrumentele nu sunt cele mai importante. Mai întâi trebuie gândit procesul - apoi implementate instrumentele. Instrumentele sunt bune, dar costisitoare, așa că putem începe cu procesul și să configurăm interacțiunea și înțelegerea între dezvoltare și securitate. Din punct de vedere al securității - nu trebuie să acoperim totul, din perspectiva dezvoltării - dacă există ceva foarte critic, trebuie să se rezolve, nu să închidem ochii la problemă.
Calitatea produsului — este obiectivul comun atât pentru securitate cât și pentru dezvoltare. Facem un singur lucru, ne străduim să funcționeze corect și să nu existe riscuri reputaționale sau pierderi financiare. De aceea promovăm abordarea DevSecOps, SecDevOps, pentru a îmbunătăți comunicarea și a face produsul mai bun.
Începeți cu ceea ce aveți deja: cerințe, arhitectură, verificări parțiale, training-uri, linii directoare. Nu este necesar să aplicați imediat toate practicile pe toate proiectele - acționați iterativ. Nu există un standard unic - experimentati și încercați diferite abordări și soluții.
Între defectele de securitate și defectele funcționale există un semn de egalitate.
Automatizați tot, ce se mișcă. Tot ce nu se mișcă - mișcați și automatizați. Dacă ceva se face manual, nu este o bună parte a procesului. Ar putea merita să analizați și acest aspect și să-l automatizați.
Dacă dimensiunea echipei de securitate este mică - folosiți Security Champions.
Este posibil ca ceea ce am povestit să nu vi se potrivească și să creați ceva propriu - și este bine. Dar alegeți uneltele în funcție de cerințele procesului vostru specific. Nu vă bazați pe ceea ce spune comunitatea, că acest instrument este prost, iar celălalt este bun. Este posibil ca, pentru produsul vostru, să fie exact invers.
Cerințe pentru unelte.
- Un nivel scăzut de False Positive.
- Timp de analiză adecvat.
- Ușurința în utilizare.
- Existența integrărilor.
- Înțelegerea foii de parcurs a dezvoltării produsului.
- Posibilitatea de personalizare a uneltelor.
Prezentarea lui Iuri a fost aleasă ca una dintre cele mai bune la DevOpsConf 2018. Pentru a descoperi și mai multe idei interesante și cazuri practice, veniți pe 27 și 28 mai în Skolkovo la în cadrul . Și ar fi și mai bine dacă sunteți pregătiți să împărtășiți experiența voastră, atunci pentru prezentare până pe 21 aprilie.
Sursa: habr.com
