Vi havde 2 kodeanalysatorer, 4 dynamiske testværktøjer, vores eget håndværk og 250 scripts. Ikke at alt dette var nødvendigt i den nuværende proces, men når du først begyndte at implementere DevSecOps, skal du gå til slutningen.
. Karakterer skabt af Justin Roiland og Dan Harmon.
Hvad er SecDevOps? Hvad med DevSecOps? Hvad er forskellene? Applikationssikkerhed - hvad handler det om? Hvorfor virker den klassiske tilgang ikke længere? Alle disse spørgsmål kender svaret Yuri Shabalin af Sværdfisk sikkerhed. Yuriy vil besvare alt i detaljer og analysere problemerne med overgangen fra den klassiske Application Security-model til DevSecOps-processen: hvordan man korrekt griber integrationen af den sikre udviklingsproces ind i DevOps-processen og ikke ødelægger noget, hvordan man går gennem hovedstadierne af sikkerhedstest, hvilke værktøjer der kan bruges, hvordan de adskiller sig, og hvordan man korrekt konfigurerer dem for at undgå faldgruber.
Om højttaler: Yuri Shabalin - Hovedsikkerhedsarkitekt i virksomheden Sværdfisk sikkerhed. Ansvarlig for implementeringen af SSDL, for den overordnede integration af applikationsanalyseværktøjer i et enkelt udviklings- og testøkosystem. 7 års erfaring med informationssikkerhed. Arbejdet hos Alfa-Bank, Sberbank og Positive Technologies, som udvikler software og leverer services. Foredragsholder for internationale konferencer ZerONights, PHDays, RISSPA, OWASP.
Applikationssikkerhed: hvad handler det om?
Ansøgningssikkerhed er sikkerhedssektionen, der er ansvarlig for applikationssikkerhed. Det her handler ikke om infrastruktur eller netværkssikkerhed, men om hvad vi skriver og hvad udviklere arbejder på – det er fejlene og sårbarhederne ved selve applikationen.
retning — Sikkerhedsudviklings livscyklus - Udviklet af Microsoft. Diagrammet viser den kanoniske SDLC-model, hvis hovedopgave er deltagelse af sikkerhed på alle udviklingstrin, fra krav til frigivelse og frigivelse til produktion. Microsoft indså, at der er for mange fejl i skolebal, der er flere af dem, og der skal gøres noget ved det, og de foreslog denne tilgang, som blev kanonisk.
Application Security og SSDL er ikke rettet mod at opdage sårbarheder, som det almindeligvis antages, men på at forhindre deres forekomst. Med tiden er den kanoniske tilgang fra Microsoft blevet forbedret, udviklet, den har en dybere detaljeret fordybelse.
Den kanoniske SDLC er meget detaljeret i forskellige metoder - OpenSAMM, BSIMM, OWASP. Metoderne er forskellige, men er generelt ens.
Bygningssikkerhed i modenhedsmodel
Jeg kan bedst lide det BSIMM — . Grundlaget for metodikken er opdelingen af Application Security-processen i 4 domæner: Governance, Intelligence, SSDL Touchpoints og Deployment. Hvert domæne har 12 praksisser, som er repræsenteret som 112 aktiviteter.
Hver af de 112 aktiviteter har 3 modenhedsniveauer: begynder, mellem og øvet. Du kan studere alle 12 praksisser i sektioner, vælge ting, der er vigtige for dig, finde ud af, hvordan du implementerer dem og gradvist tilføje elementer, for eksempel statisk og dynamisk kodeanalyse eller kodegennemgang. Du lægger en plan og arbejder roligt efter den som led i gennemførelsen af de udvalgte aktiviteter.
Hvorfor DevSecOps
DevOps er en overordnet stor proces, hvor der skal tages hånd om sikkerheden.
Oprindeligt involverede sikkerhedstjek. I praksis var antallet af sikkerhedshold meget mindre end nu, og de fungerede ikke som deltagere i processen, men som et kontrol- og tilsynsorgan, der stiller krav til det og kontrollerer kvaliteten af produktet ved udgivelsens afslutning. Dette er en klassisk tilgang, hvor sikkerhedsteams stod bag en mur fra udviklingen og ikke deltog i processen.
Hovedproblemet er, at informationssikkerhed er adskilt fra udvikling. Normalt er dette en slags IB-kredsløb, og det indeholder 2-3 store og dyre værktøjer. En gang hvert halve år ankommer kildekoden eller applikationen for at blive testet, og en gang om året . Alt dette fører til, at udgivelsesdatoerne for industrien er udskudt, og et stort antal sårbarheder fra automatiserede værktøjer falder ud på udvikleren. Det er umuligt at adskille og reparere alt dette, for selv i de foregående seks måneder blev resultaterne ikke demonteret, og her er en ny batch.
I løbet af vores virksomheds arbejde ser vi, at sikkerhed inden for alle områder og brancher forstår, at det er tid til at indhente og spinde med udviklingen i ét hjul - i . DevSecOps-paradigmet passer perfekt ind i agil udviklingsmetodologi, implementering, support og deltagelse i enhver udgivelse og iteration.
Overgang til DevSecOps
Det vigtigste ord i sikkerhedsudviklingens livscyklus er "behandle". Du skal forstå dette, før du tænker på at købe værktøjer.
Bare at inkludere værktøjer i DevOps-processen er ikke nok – kommunikation og forståelse mellem procesdeltagere er vigtig.
Mennesker er vigtigere end værktøjer
Ofte starter planlægningen af en sikker udviklingsproces med at vælge og købe et værktøj og ender med forsøg på at integrere værktøjet i den aktuelle proces, som fortsat er forsøg. Dette fører til triste konsekvenser, fordi alle værktøjer har deres egne karakteristika og begrænsninger.
Et almindeligt tilfælde er, når sikkerhedsafdelingen valgte et godt, dyrt værktøj med en lang række funktioner og kom til udviklerne for at bygge det ind i processen. Men det lykkes ikke - processen er designet på en sådan måde, at begrænsningerne for et allerede købt instrument ikke passer ind i det nuværende paradigme.
Beskriv først hvilket resultat du ønsker, og hvordan processen vil se ud. Dette vil hjælpe med at forstå værktøjets roller og sikkerhed i processen.
Start med det, der allerede er i brug
Før du køber dyrt værktøj, så se på, hvad du allerede har. Hver virksomhed har sikkerhedskrav, der gælder for udvikling, der er kontroller, penetrationstests - hvorfor ikke omdanne alt dette til en forståelig og bekvem form for alle?
Normalt er kravene en papir Talmud, der ligger på en hylde. Der var en sag, da vi kom til virksomheden for at se på processerne og bede dem vise sikkerhedskravene til softwaren. Specialisten, der gjorde dette, ledte længe efter:
- Nu, et sted i notaterne var der en sti, hvor dette dokument ligger.
Som følge heraf modtog vi dokumentet en uge senere.
For krav, checks med mere skal du oprette en side, for eksempel på Confluence - det er praktisk for alle.
Det er nemmere at omformatere det, der allerede er der, og bruge det til at starte.
Brug Security Champions
Normalt er der i en gennemsnitlig virksomhed for 100-200 udviklere én sikkerhedsansvarlig, der udfører flere funktioner og ikke fysisk har tid til at tjekke alt. Selvom han gør sit bedste, vil han alene ikke tjekke al den kode, som udviklingen genererer. For sådanne tilfælde er der udviklet et koncept - .
Security Champions er en person i udviklingsteamet, som er interesseret i sikkerheden af dit produkt.
Security Champion er et indgangspunkt til udviklingsteamet og en sikkerhedsevangelist, som alle er samlet i én.
Normalt, når en sikkerhedsofficer kommer til udviklingsteamet og påpeger en fejl i koden, modtager han et overrasket svar:
- Og hvem er du? Jeg ser dig for første gang. Alt er fint med mig - min senior ven satte "anvend" på kodegennemgangen, vi går videre!
Dette er en typisk situation, fordi der er meget mere tillid til seniorer eller bare holdkammerater, som udvikleren konstant interagerer med på arbejde og i kodegennemgang. Hvis Sikkerhedsmesteren i stedet for en sikkerhedsvagt påpeger fejlen og konsekvenserne, så vil hans ord have større vægt.
Udviklere kender også deres kode bedre end nogen sikkerhedsmand. For en person, der har mindst 5 projekter i et statisk analyseværktøj, er det normalt svært at huske alle nuancerne. Security Champions kender deres produkt: hvad der interagerer med hvad og hvad de skal se på i første omgang - de er mere effektive.
Så overvej at implementere Security Champions og udvide sikkerhedsteamets indflydelse. For mesteren selv er dette også nyttigt: faglig udvikling inden for et nyt felt, udvidelse af den tekniske horisont, pumpning af tekniske, ledelsesmæssige og ledelsesmæssige færdigheder, øget markedsværdi. Dette er et element af social engineering, dine "øjne" i udviklingsteamet.
Test stadier
siger, at 20 % af indsatsen giver 80 % af resultaterne. Disse 20 % er applikationsanalysepraksis, der kan og bør automatiseres. Eksempler på sådanne aktiviteter er statisk analyse − CEST, dynamisk analyse — DAST и open source kontrol. Jeg vil fortælle dig mere om aktiviteter, samt om værktøjer, hvilke funktioner vi normalt støder på, når de introduceres i processen, og hvordan man gør det korrekt.
Vigtigste værktøjsproblemer
Jeg vil fremhæve de problemer, der er relevante for alle instrumenter, der kræver opmærksomhed. Jeg vil analysere dem mere detaljeret for ikke at gentage yderligere.
Lang analysetid. Hvis der går 30 minutter fra commit til frigivelse til alle test og montering, så vil informationssikkerhedskontrollen tage en dag. Så ingen vil bremse processen. Overvej denne funktion og drag konklusioner.
Høj Falsk Negativ eller Falsk Positiv. Alle produkter er forskellige, alle bruger forskellige rammer og deres egen kodningsstil. På forskellige kodebaser og teknologier kan værktøjer vise forskellige niveauer af falsk negativ og falsk positiv. Så se hvad der er i Deres virksomheder og for dine applikationer vil vise et godt og pålideligt resultat.
Ingen integrationer med eksisterende værktøjer. Se på værktøjerne i forhold til integrationer med det, du allerede bruger. For eksempel, hvis du har Jenkins eller TeamCity, så tjek integrationen af værktøjer med denne software, og ikke med GitLab CI, som du ikke bruger.
Manglende eller overdreven kompleksitet af tilpasning. Hvis værktøjet ikke har en API, hvorfor er det så nødvendigt? Alt, hvad der kan gøres i grænsefladen, bør være tilgængeligt via API'et. Ideelt set bør værktøjet have mulighed for at tilpasse checks.
Ingen produktudvikling køreplan. Udviklingen står ikke stille, vi bruger altid nye rammer og funktioner, omskriver gammel kode til nye sprog. Vi vil sikre os, at det værktøj, vi køber, understøtter nye rammer og teknologier. Derfor er det vigtigt at vide, at produktet har en reel og korrekt udvikling.
Procesfunktioner
Ud over funktionerne i værktøjerne skal du overveje funktionerne i udviklingsprocessen. For eksempel er det en typisk fejl at forstyrre udviklingen. Lad os se, hvilke andre funktioner der skal overvejes, og hvad sikkerhedsteamet skal være opmærksom på.
For ikke at forstyrre udviklingen og frigive deadlines, skal du oprette forskellige regler og anderledes vise stoppere - kriterier for at stoppe byggeprocessen i tilfælde af sårbarheder - til forskellige miljøer. For eksempel forstår vi, at den nuværende filial skal til en udviklingsstand eller UAT, så vi stopper ikke og siger:
- Du har sårbarheder her, du kommer ikke længere!
På dette tidspunkt er det vigtigt at fortælle udviklere, at der er sikkerhedsproblemer, man skal være opmærksom på.
Tilstedeværelsen af sårbarheder er ikke en hindring for yderligere test: manuel, integration eller manuel. På den anden side skal vi på en eller anden måde forbedre sikkerheden på produktet, og så udviklerne ikke scorer på, hvad sikkerheden finder. Derfor gør vi nogle gange dette: på standen, når den ruller ud til udviklingsmiljøet, giver vi blot besked om udviklingen:
- Gutter, I har problemer, vær venligst opmærksom på dem.
På UAT-stadiet viser vi igen advarsler om sårbarheder, og på exit-stadiet i skolebal siger vi:
"Drenge, vi advarede jer flere gange, I gjorde ikke noget - vi vil ikke slippe jer ud med det her.
Hvis vi taler om kode og dynamik, så er det nødvendigt kun at vise og advare om sårbarheder af de funktioner og kode, der lige blev skrevet i denne funktion. Hvis udvikleren flyttede knappen med 3 pixels, og vi fortæller ham, at han har en SQL-injektion der og derfor skal rettes hurtigst muligt, er det forkert. Se kun på, hvad der står nu, og på den ændring, der kommer til ansøgningen.
Lad os sige, at vi har en funktionsfejl - den måde, applikationen ikke skal fungere på: penge overføres ikke, når du klikker på knappen, er der ingen overgang til næste side, eller produktet indlæses ikke. Sikkerhedsdefekter - det er de samme fejl, men ikke i forbindelse med ansøgningen, men sikkerhed.
Ikke alle problemer med softwarekvalitet er sikkerhedsproblemer. Men alle sikkerhedsproblemer er relateret til kvaliteten af softwaren. Sherif Mansour, Expedia.
Da alle sårbarheder er de samme defekter, bør de placeres samme sted som alle udviklingsfejl. Så glem alt om rapporter og skræmmende PDF-filer, som ingen læser.
Da jeg arbejdede for en udviklingsvirksomhed, modtog jeg en rapport fra statiske analyseværktøjer. Jeg åbnede den, blev forfærdet, lavede kaffe, bladrede i 350 sider, lukkede den og gik videre til arbejdet. Store rapporter er døde rapporter. Normalt går de ingen steder, e-mails bliver slettet, glemt, tabt, eller virksomheden siger, at den tager risici.
Hvad skal man gøre? Vi konverterer simpelthen de bekræftede defekter, som vi fandt, til en form, der er praktisk til udvikling, f.eks. tilføjer vi den til efterslæbet i Jira. Fejl prioriteres og elimineres i prioriteret rækkefølge sammen med funktionsfejl og testfejl.
Statisk analyse - SAST
Dette er kodeanalyse for sårbarheder., men det er ikke det samme som SonarQube. Vi tjekker ikke kun efter mønstre eller stil. Analysen bruger en række tilgange: efter sårbarhedstræ, efter , ved at analysere konfigurationsfiler. Det er alt for selve koden.
Fordele ved tilgangen: identifikation af sårbarheder i kode på et tidligt udviklingsstadiumnår der ikke er stativer og færdigt værktøj, og inkrementel scanningsfunktion: scanner en sektion af kode, der er ændret, og kun den funktion, som vi gør i øjeblikket, hvilket reducerer scanningstiden.
Cons er manglen på støtte til de påkrævede sprog.
Nødvendige integrationer, som burde være i værktøjerne, efter min subjektive mening:
- Integrationsværktøj: Jenkins, TeamCity og Gitlab CI.
- Udviklingsmiljø: Intellij IDEA, Visual Studio. Det er mere bekvemt for en udvikler ikke at klatre ind i en uforståelig grænseflade, der stadig skal huskes, men at se alle de nødvendige integrationer og sårbarheder, som han har fundet lige på arbejdspladsen i sit eget udviklingsmiljø.
- Kodegennemgang: SonarQube og manuel gennemgang.
- Defekt trackers: Jira og Bugzilla.
Billedet viser nogle af de bedste repræsentanter for statisk analyse.
Det er ikke værktøjerne, der betyder noget, men processen, så der findes Open Source-løsninger, som også er gode til at køre processen.
SAST Open Source vil ikke finde et stort antal sårbarheder eller komplekse DataFlow, men de kan og bør bruges, når man bygger en proces. De hjælper med at forstå, hvordan processen vil blive bygget, hvem vil reagere på fejl, hvem vil rapportere, hvem vil rapportere. Hvis du ønsker at udføre den indledende fase af opbygningen af din kodes sikkerhed, skal du bruge Open Source-løsninger.
Hvordan kan dette integreres, hvis du er i begyndelsen af rejsen, du ikke har noget: hverken CI, Jenkins eller TeamCity? Overvej procesintegration.
Integration på CVS-niveau
Hvis du har Bitbucket eller GitLab, kan du lave integration på niveau .
Efter begivenhed trække anmodning, begå. Du scanner koden og viser i build-status, at sikkerhedstjekket bestod eller mislykkedes.
Feedback. Der er selvfølgelig altid brug for feedback. Hvis du bare gjorde det på sikkerhedssiden, lagde det i en boks og ikke fortalte nogen noget om det, og så dumpede en masse fejl i slutningen af måneden, er det ikke rigtigt og ikke godt.
Integration med kodegennemgangssystem
En gang satte vi den tekniske AppSec-bruger som standard anmelder i en række vigtige projekter. Afhængigt af om der blev fundet fejl i den nye kode, eller der ikke er nogen fejl, sætter anmelderen status på pull-anmodningen til "accepter" eller "behøver arbejde" - enten er alt OK, eller også skal du færdiggøre og linke til, hvad der præcist er at afslutte. For integration med den version, der udgives, har vi deaktiveret fletning, hvis IS-testen ikke er bestået. Vi inkluderede dette i den manuelle kodegennemgang, og resten af procesdeltagerne så sikkerhedsstatusserne for denne særlige proces.
Integration med SonarQube
Mange har med hensyn til kodekvalitet. Det er det samme her - du kan kun lave de samme porte til SAST-instrumenter. Der vil være den samme grænseflade, den samme kvalitetsport, kun den vil blive kaldt sikkerhedsport. Og også, hvis du har en proces sat op ved hjælp af SonarQube, kan du nemt integrere alt der.
Integration på CI-niveau
Også her er alt ganske enkelt:
- På niveau med autotests, enhedstest.
- Inddeling efter udviklingstrin: udvikler, test, prod. Forskellige sæt regler kan være inkluderet, eller forskellige fejltilstande: vi stopper samlingen, vi stopper ikke samlingen.
- Synkron/asynkron kørsel. Vi venter på slutningen af sikkerhedstestene, eller vi venter ikke. Det vil sige, at vi bare lancerede dem og går videre, og så får vi en status om, at alt er godt eller dårligt.
Det hele er i en perfekt lyserød verden. I det virkelige liv er dette ikke tilfældet, men vi stræber. Resultatet af udførelse af sikkerhedstjek bør svare til resultaterne af enhedstests.
For eksempel tog vi et stort projekt og besluttede, at nu vil vi scanne det med SAST - OK. Vi skød dette projekt ind i SAST, det gav os 20 sårbarheder, og vi tog en viljestærk beslutning om, at alt er i orden. 000 sårbarheder er vores tekniske gæld. Vi vil lægge gælden i en boks, vi vil langsomt rake den op og starte fejl i defekte trackere. Lej en virksomhed, gør alting selv, eller få Security Champions til at hjælpe os, så vil den tekniske gæld falde.
Og alle nyligt opståede sårbarheder i den nye kode bør elimineres på samme måde som fejl i en enhed eller i autotest. Relativt set startede forsamlingen, kørte væk, to tests og to sikkerhedstests faldt ned. OK - vi gik, så på, hvad der skete, rettede en, rettede den anden, kørte næste gang - alt er fint, ingen nye sårbarheder er dukket op, testene har ikke fejlet. Hvis denne opgave er dybere, og du skal forstå den godt, eller reparation af sårbarheder påvirker store lag af det, der ligger under motorhjelmen: en fejl bringes ind i defekt-trackeren, den prioriteres og rettes. Desværre er verden ikke perfekt, og prøver mislykkes nogle gange.
Et eksempel på en sikkerhedsport er en analog af en kvalitetsport, hvad angår tilstedeværelsen og antallet af sårbarheder i koden.
Vi integrerer med SonarQube - plugin'et er installeret, alt er meget praktisk og cool.
Integration af udviklingsmiljø
Integrationsmuligheder:
- Start af en scanning fra udviklingsmiljøet selv før commit.
- Se resultater.
- Analyse af resultater.
- Synkronisering med serveren.
Sådan ser det ud at få resultater fra serveren.
I vores udviklingsmiljø det vises bare et ekstra element, der siger, at sådanne sårbarheder blev fundet under scanningen. Du kan straks redigere koden, se anbefalinger og . Alt dette er placeret på udviklerens arbejdsplads, hvilket er meget praktisk - du behøver ikke følge resten af linkene og se noget ekstra.
Open Source
Dette er mit yndlingsemne. Alle bruger Open Source biblioteker - hvorfor skrive en masse krykker og cykler, når man kan tage et færdiglavet bibliotek, hvor alt allerede er implementeret?
Det er selvfølgelig rigtigt, men biblioteker er også skrevet af mennesker, inkluderer også visse risici, og der er også sårbarheder, der periodisk eller konstant rapporteres. Derfor er der et næste skridt i Application Security - dette er analysen af Open Source-komponenter.
Open Source Analyse - OSA
Værktøjet omfatter tre hovedtrin.
Finde sårbarheder i biblioteker. For eksempel ved værktøjet, at vi bruger en form for bibliotek, og det i eller i fejlsporere er der nogle sårbarheder, der relaterer til denne version af biblioteket. Hvis du prøver at bruge det, vil værktøjet advare dig om, at biblioteket er sårbart og råde dig til at bruge en anden version, hvor der ikke er nogen sårbarheder.
Analyse af licensens renhed. Dette er ikke særlig populært hos os endnu, men hvis du arbejder med et fremmed land, så der kan du med jævne mellemrum få et angreb for at bruge en open source-komponent, der ikke kan bruges eller ændres. I henhold til politikken for det licenserede bibliotek kan vi ikke gøre dette. Eller, hvis vi har ændret det og bruger det, skal vi sende vores kode. Der er selvfølgelig ingen, der ønsker at sende koden på deres produkter, men du kan også beskytte dig mod dette.
Analyse af komponenter, der anvendes i et industrielt miljø. Forestil dig en hypotetisk situation, hvor vi endelig har afsluttet udviklingen og frigivet den seneste udgivelse af vores mikroservice til industrien. Han bor der vidunderligt - en uge, en måned, et år. Vi indsamler det ikke, vi foretager ikke sikkerhedstjek, alt ser ud til at være i orden. Men pludselig, to uger efter udgivelsen, kommer der en kritisk sårbarhed i Open Source-komponenten ud, som vi bruger i netop denne samling, i det industrielle miljø. Hvis vi ikke registrerer, hvad og hvor vi bruger, så vil denne sårbarhed simpelthen ikke blive set. Nogle værktøjer har mulighed for at overvåge sårbarheder i biblioteker, der i øjeblikket bruges i bal. Det er meget nyttigt.
features:
- Forskellige politikker for forskellige udviklingsstadier.
- Overvåg komponenter i et industrielt miljø.
- Kontrol af biblioteker i konturen af organisationen.
- Support til forskellige byggesystemer og sprog.
- Analyse af Docker-billeder.
Et par eksempler på ledere på området, der er engageret i analysen af Open Source.
Den eneste gratis er fra OWASP. Du kan tænde den i de første trin, se, hvordan den virker, og hvad den understøtter. Dybest set er disse alle cloud-produkter eller on-premise, men bag deres base går de stadig til internettet. De sender ikke dine biblioteker, men hashes eller deres værdier, som de beregner, og fingeraftryk til deres server for at modtage nyheder om tilstedeværelsen af sårbarheder.
Procesintegration
Perimeter bibliotekskontrolsom er downloadet fra eksterne kilder. Vi har eksterne og interne depoter. For eksempel har vi Nexus inde i Event Central, og vi vil gerne sikre os, at der ikke er nogen sårbarheder med en "kritisk" eller "høj" status inde i vores lager. Du kan konfigurere proxy ved hjælp af Nexus Firewall Lifecycle-værktøjet, så sådanne sårbarheder afskæres og ikke inkluderes i det interne lager.
CI integration. På samme niveau med autotest, enhedstest og opdeling i udviklingstrin: dev, test, prod. På hvert trin kan du downloade alle biblioteker, bruge hvad som helst, men hvis der er noget hårdt med den "kritiske" status, bør du nok henlede udviklernes opmærksomhed på dette på tidspunktet for at gå ind i skolebal.
Artefakt integration: Nexus og JFrog.
Integration i udviklingsmiljøet. De værktøjer, du vælger, skal have integration med udviklingsmiljøer. Udvikleren skal have adgang til scanningsresultaterne fra sin arbejdsplads, eller mulighed for at scanne og tjekke koden for sårbarheder, før den begår den i CVS.
CD integration. Dette er en fed funktion, som jeg virkelig godt kan lide, og som jeg allerede har talt om - overvågning af fremkomsten af nye sårbarheder i et industrielt miljø. Det fungerer sådan her.
Vi har Offentlige komponentlager - nogle værktøjer udenfor, og vores interne depot. Vi ønsker kun pålidelige komponenter i den. Ved fuldmagt af en anmodning kontrollerer vi, at det downloadede bibliotek ikke har nogen sårbarheder. Hvis det falder ind under visse politikker, som vi sætter og nødvendigvis koordinerer med udviklingen, så uploader vi det ikke, og vi får et afslag på at bruge en anden version. Derfor, hvis der er noget virkelig kritisk og dårligt i biblioteket, vil udvikleren ikke modtage biblioteket selv på installationsstadiet - lad ham bruge en version højere eller lavere.
- Når vi bygger, kontrollerer vi, at ingen gled noget slemt, at alle komponenter er sikre, og at ingen bragte noget farligt på flashdrevet.
- Vi har kun pålidelige komponenter i depotet.
- Når vi installerer, tjekker vi endnu en gang selve pakken: war, jar, DL eller Docker-billede for, at den overholder politikken.
- Når vi går ind i det industrielle miljø, overvåger vi, hvad der sker i det industrielle miljø: kritiske sårbarheder dukker op eller dukker ikke op.
Dynamisk analyse - DAST
Dynamiske analyseværktøjer er fundamentalt forskellige fra alt, hvad der er blevet sagt før. Dette er en slags efterligning af brugerens arbejde med applikationen. Hvis dette er en webapplikation, sender vi anmodninger, der efterligner klientens arbejde, klik på knapperne på forsiden, send kunstige data fra formularen: citater, parenteser, tegn i forskellige kodninger for at se på, hvordan applikationen fungerer og behandler eksternt data.
Det samme system giver dig mulighed for at tjekke for skabelonsårbarheder i Open Source. Da DAST ikke ved hvilken Open Source vi bruger, kaster den simpelthen "ondsindede" mønstre og analyserer serverens svar:
- Ja, der er et deserialiseringsproblem her, men ikke her.
Det er der store risici i, for hvis man gennemfører denne sikkerhedstest på samme stand, som testerne arbejder med, kan der ske ubehagelige ting.
- Høj belastning på applikationsservernetværket.
- Ingen integrationer.
- Muligheden for at ændre indstillingerne for den analyserede applikation.
- Der er ingen support til de nødvendige teknologier.
- Svært ved at indstille.
Vi havde en situation, da vi endelig lancerede AppScan: vi slog adgangen til applikationen ud i lang tid, modtog 3 konti og var glade - endelig vil vi tjekke alt! Vi lancerede en scanning, og det første, AppScan gjorde, var at komme ind i administrationspanelet, gennembore alle knapperne, ændre halvdelen af dataene og derefter dræbe serveren helt med sin egen. -anmodninger. Udvikling med test sagde:
"Drenge, laver du sjov med mig?! Vi gav dig regnskab, og du satte standen!
Overvej mulige risici. Ideelt set skal du forberede en separat stand til at teste informationssikkerhed, som vil være isoleret fra resten af miljøet i det mindste på en eller anden måde, og kontrollere adminpanelet betinget, helst i manuel tilstand. Dette er en pentest - de resterende procenter af indsatsen, som vi ikke overvejer nu.
Det er værd at overveje, at du kan bruge dette som en analog til belastningstest. På det første trin kan du tænde for den dynamiske scanner i 10-15 tråde og se, hvad der sker, men normalt, som praksis viser, er der ikke noget godt.
Et par ressourcer, som vi normalt bruger.
Værd at fremhæve er "schweizerkniven" for enhver sikkerhedsprofessionel. Alle bruger det, og det er meget praktisk. En ny demoversion af enterprise-udgaven er nu blevet frigivet. Hvis det tidligere bare var et selvstændigt værktøj med plugins, laver udviklere nu endelig en stor server, hvorfra det vil være muligt at administrere flere agenter. Det er fedt, jeg anbefaler dig at prøve det.
Procesintegration
Integrationen er ret god og enkel: start scanningen efter vellykket installation applikationer på standen og scanning efter vellykket integrationstest.
Virker integrationerne ikke, eller der er stubs og mock-funktioner, er det meningsløst og ubrugeligt – uanset hvilket mønster vi sender, vil serveren stadig reagere på samme måde.
- Ideelt set en separat testbænk.
- Inden du tester, skal du skrive login-sekvensen ned.
- Test af administrationssystemet er kun manuel.
Процесс
Lidt generaliseret om processen generelt og om arbejdet med hvert værktøj i særdeleshed. Alle applikationer er forskellige - en fungerer bedre med dynamisk analyse, en anden med statisk analyse, den tredje med OpenSource-analyse, pentests eller noget andet generelt, for eksempel begivenheder med .
Hver proces skal kontrolleres.
For at forstå, hvordan processen fungerer, og hvor den kan forbedres, skal du indsamle målinger fra alt, hvad du kan få fingrene i, inklusive produktionsmålinger, målinger fra værktøjer og defektsporere.
Enhver information er nyttig. Det er nødvendigt at se i forskellige afsnit på, hvor dette eller hint værktøj er bedre brugt, hvor processen specifikt falder. Det kan være værd at se på udviklingens responstid for at se, hvor man kan forbedre processen baseret på tid. Jo flere data, jo flere snit kan der bygges fra øverste niveau til detaljerne i hver proces.
Da alle statiske og dynamiske analysatorer har deres egne API'er, deres egne lanceringsmetoder, principper, nogle har skemalæggere, andre har ikke - vi skriver et værktøj AppSec Orchestrator, som giver dig mulighed for at lave en enkelt indgang til hele processen fra produktet og administrere den fra ét punkt.
Ledere, udviklere og sikkerhedsingeniører har ét indgangspunkt, hvorfra de kan se, hvad der kører, konfigurere og køre scanninger, få scanningsresultater og indsende krav. Vi forsøger at komme væk fra stykker papir, oversætte alt til et menneskeligt, som udviklingen bruger – sider om Confluence med status og metrikker, defekter i Jira eller i diverse defektsporere, eller indlejring i en synkron/asynkron proces i CI/CD.
Nøgleforsøg
Værktøjerne er ligegyldige. Tænk først over processen, og implementer derefter værktøjerne. Værktøjerne er gode, men dyre, så du kan starte med processen og finjustere samspillet og forståelsen mellem udvikling og sikkerhed. Ud fra et sikkerhedssynspunkt er der ingen grund til at "stoppe" alting i træk. Ud fra udviklingssynspunktet, hvis der er noget højt mega super kritisk, så skal dette elimineres, og ikke lukkes for problemet .
Produktkvalitet - fælles mål både sikkerhed og udvikling. Vi gør én ting, vi forsøger at sikre, at alt fungerer korrekt, og der ikke er nogen omdømmerisici og økonomiske tab. Derfor fremmer vi tilgangen til DevSecOps, SecDevOps for at etablere kommunikation og gøre produktet bedre.
Start med det, der allerede er der: krav, arkitektur, deltjek, træninger, retningslinjer. Det er ikke nødvendigt straks at anvende al praksis på alle projekter - bevæge sig iterativt. Der er ikke en enkelt standard eksperiment og prøv forskellige tilgange og løsninger.
Ligetegn mellem IS-defekter og funktionsdefekter.
Automatiser altder bevæger sig. Alt, der ikke bevæger sig, bevæger sig og automatiserer. Hvis noget udføres i hånden, er dette ikke en god del af processen. Måske er det værd at genoverveje og automatisere det også.
Hvis størrelsen af IB-holdet er lille - brug Security Champions.
Måske vil det, jeg talte om, ikke passe dig, og du vil finde på noget af dit eget – og det er godt. Men vælg værktøjer baseret på kravene i din proces. Se ikke på, hvad samfundet siger, at dette værktøj er dårligt, og det her er godt. Måske vil det være omvendt på dit produkt.
Værktøjskrav.
- Lav Falsk Positiv.
- Tilstrækkelig analysetid.
- Brugervenlighed.
- Tilgængelighed af integrationer.
- Forståelse af produktudviklingens køreplan.
- Evne til at tilpasse værktøjer.
Yuriys rapport blev valgt som en af de bedste ved DevOpsConf 2018. For at blive bekendt med endnu flere interessante ideer og praktiske cases, kom til Skolkovo den 27. og 28. maj inden for . Endnu bedre, hvis du er villig til at dele din oplevelse, så Send din rapport senest den 21. april.
Kilde: www.habr.com