Vi havde 2 kodeanalyseværktøjer, 4 værktøjer til dynamisk testning, vores egne kreationer og 250 scripts. Ikke at alt dette var nødvendigt i den nuværende proces, men da jeg begyndte at implementere DevSecOps, skal man gøre det ordentligt.
. Karakterforfattere: Justin Roiland og Dan Harmon.
Hvad er SecDevOps? Og DevSecOps? Hvad er forskellene? Applikationssikkerhed - hvad handler det om? Hvorfor virker den klassiske tilgang ikke længere? Alle disse spørgsmål har svar. Yuri Shabalin af Swordfish Security. Yuri vil grundigt besvare alle spørgsmål og gennemgå problemerne ved overgangen fra den klassiske model for applikationssikkerhed til DevSecOps-processen: hvordan man korrekt integrerer sikre udviklingsprocesser ind i DevOps, uden at ødelægge noget, hvordan man gennemgår de vigtigste sikkerhedstesttrin, hvilke værktøjer man kan anvende, hvordan disse adskiller sig, og hvordan de kan konfigureres korrekt for at undgå faldgruber.
Om oplægsholderen: Yuri Shabalin - Chief Security Architect i virksomheden Swordfish Security. Han er ansvarlig for implementeringen af SSDL, for den samlede integration af applikationsanalyseværktøjer i et samlet udviklings- og testøkosystem. 7 års erfaring inden for informationssikkerhed. Har arbejdet for Alfa-Bank, Sberbank og i Positive Technologies, som udvikler software og tilbyder tjenester. Oplægsholder ved internationale konferencer såsom ZerONights, PHDays, RISSPA, OWASP.
Applikationssikkerhed: hvad handler det om?
Applikationssikkerhed er en gren af sikkerhed, der beskytter applikationer. Dette relaterer sig ikke til infrastruktur eller netværkssikkerhed, men netop til det, vi skriver og udviklere arbejder på - det handler om mangler og sårbarheder i selve applikationen.
Retning — Security Development Lifecycle er udviklet af Microsoft. På diagrammet ses den kanoniske model for SDLC, som har som hovedopgave at inddrage sikkerheden i hver fase af udviklingen, fra krav til udgivelse og lancering i produktion. Microsoft indså, at der i produktionen er for mange fejl, og at de bliver flere, og at noget måtte gøres, og de foreslog denne tilgang, som blev kanonisk.
Applikationssikkerhed og SSDL fokuserer ikke på at opdage sårbarheder, som mange tror, men på at forhindre, at de opstår. Gennem tiden er den kanoniske tilgang fra Microsoft blevet forbedret og udviklet, med en dybere og mere detaljeret tilgang.
Den kanoniske SDLC er stærkt detaljeret i forskellige metoder - OpenSAMM, BSIMM, OWASP. Metoderne adskiller sig, men generelt er de ens.
Building Security In Maturity Model
Jeg kan bedst lide BSIMM — . Grundlaget for metoden er opdelingen af Application Security processen i 4 domæner: Governance, Intelligence, SSDL Touchpoints og Deployment. I hvert domæne er der 12 praksisser, der præsenteres i form af 112 aktiviteter.
Hver af de 112 aktiviteter har 3 modenhedsniveauer: grundlæggende, mellem og avanceret. Alle 12 praksisser kan studeres efter sektioner, udvælge vigtige for dig og forstå, hvordan man implementerer dem og gradvist tilføje elementer, såsom statisk og dynamisk kodeanalyse eller code review. Du laver en plan og arbejder roligt inden for rammerne af implementeringen af de valgte aktiviteter.
Hvorfor DevSecOps
DevOps er en samlet stor proces, hvor det er nødvendigt at tage sig af sikkerheden.
Oprindeligt forudsatte sikkerhedstjek. I praksis var antallet af sikkerhedsteams meget mindre end nu, og de fungerede ikke som deltagere i processen, men som en kontrol- og tilsynsmyndighed, der stiller krav til den og kontrollerer produktets kvalitet ved slutningen af udgivelsen. Dette er den klassiske tilgang, hvor sikkerhedsteams var adskilt fra udviklingen og ikke deltog i processen.
Det største problem er netop, at informationssikkerhed er adskilt fra udvikling. Normalt er det en slags informationssikkerhedsdomæne, der rummer 2-3 store og dyre værktøjer. Hver sjette måned modtager vi kildekoden eller en applikation, der skal tjekkes, og én gang om året udføres der . Alt dette fører til, at deadlines for produktlancering udsættes, og udviklerne får et enormt antal sårbarheder fra automatiserede værktøjer. Det hele er umuligt at sortere og reparere, fordi resultaterne fra de sidste seks måneder ikke engang er blevet analyseret, og nu er der en ny bunke.
I vores virksomheds arbejdsproces ser vi, at sikkerhed i alle sektorer og industrier indser, at det er tid til at samarbejde med udviklingen - i . DevSecOps-paradigmet passer perfekt ind i metoden for agil udvikling, til implementering, støtte og deltagelse i hver udgivelse og iteration.
Overgangen til DevSecOps
Det vigtigste ord i Security Development Lifecycle er "processen"Du skal forstå dette, før du tænker på at købe værktøjer.
At inkludere værktøjerne i DevOps-processen er ikke nok – det er vigtigt med interaktion og forståelse mellem deltagerne i processen.
Mennesker er vigtigere end værktøjer.
Planlægningen af en sikker udviklingsproces begynder ofte med at vælge og købe et værktøj, og slutter med at forsøge at integrere værktøjet i den nuværende proces, hvilket ofte kun bliver forsøg. Dette fører til triste konsekvenser, da hvert værktøj har sine egne egenskaber og begrænsninger.
Et almindeligt tilfælde er, når sikkerhedsafdelingen vælger et godt, dyrt værktøj med mange funktioner og henvender sig til udviklerne for at integrere det i processen. Men det fungerer ikke – processen er bygget på en måde, hvor begrænsningerne af det allerede købte værktøj ikke passer ind i den nuværende paradigm.
Start med at beskrive, hvilket resultat du ønsker, og hvordan processen vil se ud. Dette hjælper med at forstå værktøjets og sikkerhedens roller i processen.
Begynd med det, der allerede bruges.
Før du køber dyre værktøjer, skal du se på, hvad du allerede har. Hver virksomhed har sikkerhedskrav, der stilles til udviklingen, der er gennemgange og pentests – hvorfor ikke omdanne alt dette til en forståelig og brugervenlig form?
Normalt er kravene en papirforklaring, der ligger på hylden. Der var engang, vi kom ind i en virksomhed for at se på processerne og bad om at få vist sikkerhedskravene til softwaren. Den specialist, der arbejdede med det, ledte i lang tid:
— Nu, et eller andet sted i noter, var der en vej til, hvor dette dokument lå.
Til sidst fik vi dokumentet efter en uge.
For krav, gennemgange og alt andet, opret en side, f.eks. på Confluence — det er praktisk for alle.
Det er nemmere at omformatere det, der allerede findes, og bruge det som start.
Brug Security Champions.
Normalt arbejder der en sikkerhedsekspert i en gennemsnitlig virksomhed med 100-200 udviklere, som udfører flere funktioner og fysisk ikke kan nå at kontrollere alt. Selv hvis han gør sit bedste – kan han ikke kontrollere al den kode, der genereres af udviklingen alene. For sådanne tilfælde er konceptet udviklet – .
Security Champions er en person inden for udviklingsteamet, der er interesseret i sikkerheden af dit produkt.
Security Champion er både indgangen til udviklingsteamet og sikkerhedsevangelisten i én person.
Normalt, når en sikkerhedsekspert kommer ind i udviklingsteamet og påpeger en fejl i koden, får de et overrasket svar:
— Hvem er du? Jeg ser dig for første gang. Jeg har det godt—min senior kollega gav mig 'apply' på review, så lad os komme videre!
Dette er en typisk situation, fordi der er meget mere tillid til seniorer eller blot kolleger inden for teamet, som udvikleren interagerer konstant med i arbejdet og code reviews. Hvis Security Champion påpeger en fejl og dens konsekvenser, vil deres ord have mere vægt.
Udviklere kender også deres kode bedre end nogen sikkerhedsekspert. For en person, der har mindst 5 projekter i statisk analyseværktøjet, er det normalt svært at huske alle nuancer. Security Champions kender deres produkt: hvad interagerer hvad med, og hvad skal man se på først – de er mere effektive.
Så overvej at implementere Security Champions og udvide sikkerhedsteamets indflydelse. For selve championen er dette også gavnligt: professionel udvikling i et nyt område, udvidelse af teknisk viden, forbedring af tekniske, ledelses- og lederskabskompetencer, øget markedsværdi. Dette er et element af social engineering, dine 'øjne' i udviklingsteamet.
Testningsfaser
siger, at 20% af indsatsen giver 80% af resultatet. Disse 20% er de praksisser for applikationsanalyse, som kan og bør automatiseres. Eksempler på sådanne aktiviteter er statisk analyse— SAST, dynamisk analyse— DAST, og kontrol af Open Source. Jeg vil fortælle mere om aktiviteterne samt værktøjerne og hvilke særlige udfordringer vi typisk støder på ved implementering i processen, og hvordan man gør det korrekt.
De primære udfordringer med værktøjerne
Jeg vil fremhæve de relevante udfordringer, der gælder for alle værktøjer, som kræver opmærksomhed. Jeg vil gennemgå dem mere detaljeret for ikke at gentage mig selv senere.
Lang analyseperiode. Hvis der går 30 minutter fra commit til produktion for alle tests og bygninger, vil sikkerhedskontroller tage en hel dag. Ingen vil bremse processen. Tag denne egenskab i betragtning og drag konklusioner.
Højt niveau af False Negative eller False Positive. Alle produkter er forskellige, de bruger forskellige frameworks og har deres egen stil til at skrive kode. På forskellige kodebaser og teknologier kan værktøjer vise forskellige niveauer af False Negative og False Positive. Så se på, hvad der præcist er i dit firma og for dine applikationer, der vil vise gode og pålidelige resultater.
Ingen integrationer med eksisterende værktøjer. Se på værktøjerne med fokus på integrationer, med hvad du allerede bruger. For eksempel, hvis du har Jenkins eller TeamCity – tjek integrationen af værktøjerne med dette software, og ikke med GitLab CI, som du ikke bruger.
Mangel på eller overdreven kompleksitet af tilpasning. Hvis værktøjet ikke har et API, hvorfor har man så brug for det? Alt, hvad der kan gøres i grænsefladen, skal være tilgængeligt gennem API'et. Ideelt set bør værktøjet have mulighed for at tilpasse kontroller.
Ingen udviklings Roadmap for produktet. Udviklingen står ikke stille; vi bruger altid nye frameworks og funktioner, genkoder gammelt kode til nye sprog. Vi ønsker at være sikre på, at værktøjet, vi køber, vil understøtte nye frameworks og teknologier. Derfor er det vigtigt at vide, at produktet har en reel og korrekt for udvikling.
Processens egenskaber
Udover værktøjernes egenskaber, skal du også tage højde for udviklingsprocessens særegenheder. At forstyrre udviklingen er en typisk fejl. Lad os se på, hvilke andre aspekter der bør overvejes, og hvad sikkerhedsteamet skal fokusere på.
For ikke at forsinke udviklings- og udgivelsestidspunkter, skal du oprette forskellige regler og forskellige show stoppers — kriterier for at stoppe byggeprocessen, når der findes sårbarheder — for forskellige miljøer. For eksempel, vi forstår, at den nuværende gren går til udviklingsstand eller UAT, så vi stopper ikke op og siger:
— Der er sårbarheder her, I kan ikke gå videre!
På dette stadium er det vigtigt at informere udviklerne om, at der er sikkerhedsproblemer, som det er værd at være opmærksom på.
Forekomster af sårbarheder er ikke en hindring for fortsat testning: manuel, integrations- eller manuel. På den anden side er vi nødt til at øge sikkerheden af produktet, og så udviklerne ikke overser, hvad sikkerheden opdager. Derfor gør vi nogle gange sådan: på standen, når det udrulles til udviklingsmiljøet, informerer vi blot udviklingen:
— Herre, I har nogle problemer, vær venlig at lægge mærke til dem.
På UAT-fasen viser vi igen advarsler om sårbarheder, og ved overgang til produktion siger vi:
— Herre, vi har advaret flere gange, og I har ikke gjort noget— vi vil ikke frigive det med dette.
Når vi taler om koden og dynamikken, er det nødvendigt kun at vise og advare om sårbarhederne for de funktioner og koder, der lige er blevet skrevet i denne funktion. Hvis udvikleren har rykket en knap 3 pixels, og vi fortæller ham, at han har en SQL-injektion, og at han derfor hurtigt skal rette det— det er forkert. Se kun på det, der er skrevet nu, og de ændringer, der kommer ind i applikationen.
Lad os sige, at vi har en eller anden funktionel fejl— det, hvordan applikationen ikke skal fungere: penge overføres ikke, ved klik på knappen er der ikke overgang til den næste side, eller produktet indlæses ikke. Sikkerhedsdefekter — det er de samme defekter, men ikke i forhold til, hvordan applikationen fungerer, men til sikkerhed.
Ikke alle softwarekvalitetsproblemer er sikkerhedsproblemer. Men alle sikkerhedsproblemer er relateret til softwarekvalitet. Sherif Mansour, Expedia.
Da alle sårbarheder er de samme defekter, bør de befinde sig de samme steder som alle udviklingsdefekter. Så glem rapporter og skræmmende PDF-filer, som ingen læser.
Da jeg arbejdede i et firma, der beskæftigede sig med udvikling, modtog jeg en rapport fra statisk analyseværktøjer. Jeg åbnede den, blev chokeret, lavede mig en kop kaffe, bladrede igennem 350 sider, lukkede den og gik tilbage til arbejdet. Store rapporter er døde rapporter. Normalt går de ingen steder, e-mails slettes, glemmes, tabes, eller virksomheden siger, at den accepterer risici.
Hvad skal man gøre? De bekræftede fejl, vi har fundet, omdanner vi simpelthen til en udviklingsvenlig form, for eksempel ved at lægge dem i backlog i Jira. Vi prioriterer fejl og retter dem i rækkefølge efter prioritet sammen med funktionelle fejl og testfejl.
Statisk analyse - SAST
Det er en analyse af koden for sårbarheder., men det er ikke det samme som SonarQube. Vi tjekker ikke kun efter mønstre eller stil. Under analysen anvendes en række tilgange: efter svaghedstræet, efter , efter analyse af konfigurationsfiler. Det er alt, hvad der har med selve koden at gøre.
Fordele ved tilgangen: identifikation af sårbarheder i koden på et tidligt udviklingstrin, når der ikke endnu er oprettet testmiljøer eller færdige værktøjer, og mulighed for inkrementel scanning: scanning af den del af koden, som er ændret, og kun den funktionalitet, vi arbejder på nu, hvilket reducerer scannings tiden.
Ulemper — det er manglende support for nødvendige sprog.
Nødvendige integrationer, som skal 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 lettere for udvikleren ikke at skulle navigere i en uforståelig grænseflade, der også skal huskes, men direkte på sin arbejdsplads i sit eget udviklingsmiljø at se alle nødvendige integrationer og sårbarheder, som han har fundet.
- Kodegennemgang: SonarQube og manuel gennemgang.
- Fejlsporingssystemer: Jira og Bugzilla.
På billedet er nogle af de bedste repræsentanter for statisk analyse.
Det vigtigste er ikke værktøjerne, men processen, derfor findes der Open Source-løsninger, som også er gode til at afprøve processen.
SAST Open Source vil ikke finde et stort antal sårbarheder eller komplekse DataFlow, men ved opbygning af processen kan de bruges. De hjælper med at forstå, hvordan processen vil blive bygget, hvem der skal tage sig af fejlene, hvem der skal rapportere og hvem der skal redegøre. Hvis du vil gennemføre den indledende fase af at opbygge sikkerheden i din kode, så brug Open Source-løsninger.
Hvordan kan dette integreres, hvis du er i begyndelsen af din rejse, og du ikke har noget: hverken CI, Jenkins eller TeamCity? Lad os se på integrationer i processen.
Integration på CVS-niveau
Hvis du har Bitbucket eller GitLab, kan du lave integration på .
Efter hændelsen — pull request, commit. Du scannerer koden og i build-status viser du, om sikkerhedstesten er bestået eller ikke.
Feedback. Uden tvivl er feedback altid nødvendig. Hvis du blot har udført arbejdet på sikkerhedssiden, lagt det i en boks og ikke har fortalt nogen om det, men så i slutningen af måneden kaster en bunke bugs på bordet — det er ikke korrekt og ikke godt.
Integration med code review systemet
En gang gjorde vi en teknisk bruger fra AppSec til standard reviewer i en række vigtige projekter. Afhængig af om der blev fundet fejl i den nye kode eller ej, tildeler revieweren i pull request status som 'accept' eller 'need work' — enten er alt OK, eller der er behov for forbedringer og links til hvad der skal forbedres. For integration med den version, der går i produktion, havde vi aktiveret en forbud mod merge, hvis testene for informationssikkerhed ikke var bestået. Vi implementerede dette i den manuelle code review, så de øvrige deltagere i processen kunne se sikkerhedsstatus for lige netop denne proces.
Integration med SonarQube
Mange har for kodekvalitet. Her er det det samme — man kan lave de samme gates, men kun for SAST værktøjer. Det vil have det samme interface, samme quality gate, bare kaldet security gate. Og hvis du har implementeret en proces med SonarQube, kan du nemt integrere alt der.
Integration på CI-niveau
Her er det også ret enkelt:
- På samme niveau som autotests, unit tests.
- Opdeling efter udviklingsfaser: dev, test, prod. Forskellige sæt regler kan inkluderes, eller forskellige fail conditions: vi stopper byggeprocessen, eller vi stopper ikke byggeprocessen.
- Synkron/asin-kron kørsel. Vi venter enten på, at testene for sikkerhed er afsluttet, eller ikke venter. Det vil sige, at vi blot har startet dem og går videre, og så kommer status om, at alt er fint eller skidt.
Det hele er i en perfekt rosenrød verden. I virkeligheden eksisterer det ikke, men vi stræber efter det. Resultatet af sikkerhedstests bør svare til resultaterne af unit tests.
For example, we took on a large project and decided that we would now scan it using SAST — OK. We put this project into SAST, it reported 20,000 vulnerabilities, and with a firm decision, we accepted that everything was fine. 20,000 vulnerabilities are our technical debt. We'll store the debt in a box, gradually sorting it out and logging bugs in defect trackers. We will hire a company, do everything ourselves, or receive help from Security Champions — and the technical debt will decrease.
And all newly appearing vulnerabilities in the new code must be fixed just like errors in unit or automated tests. Conditioned, the build ran, two tests fell off, and there were two security tests. OK — we checked what happened, fixed one thing, fixed another, re-ran next time — everything is fine, no new vulnerabilities appeared, tests were not failed. If the task is deeper and needs careful handling, or if fixing vulnerabilities touches large layers of what's under the hood: log a bug in the defect tracker, it'll be prioritized and fixed. Unfortunately, the world is not perfect, and tests sometimes fail.
An example of a security gate — analogous to a quality gate, based on the presence and number of vulnerabilities in the code.
Integrating with SonarQube — the plugin is installed, everything is very convenient and great.
Integration with the development environment
Integration capabilities:
- Launching a scan from the development environment even before commit.
- Viewing results.
- Analyzing results.
- Synchronization with the server.
This is what obtaining results from the server looks like.
In our development environment a new item simply appears, which reports that vulnerabilities were detected during the scan. You can immediately fix the code, check the recommendations, and . All this is located at the developer's workstation, which is very convenient — there's no need to visit other links and look for something extra.
Open Source
This is my favorite topic. Everyone uses Open Source libraries — why write a bunch of shortcuts and bicycles when you can use a ready-made library where everything is already implemented?
Selvfølgelig, det er rigtigt, men biblioteker skrives også af mennesker, de indebærer også visse risici og der opstår også sårbarheder, der sporadisk eller konstant rapporteres om. Derfor er det næste skridt i Applikationssikkerhed - det er analyse af Open Source-komponenter.
Open Source-analyse - OSA
Værktøjet inkluderer tre store faser.
Søgning efter sårbarheder i biblioteker. For eksempel ved værktøjet, at vi bruger et bestemt bibliotek, og at i eller i bug-tracking-systemer er der sårbarheder, der vedrører denne version af biblioteket. Ved brug af det vil værktøjet give en advarsel om, at biblioteket er sårbart og anbefale at bruge en anden version, hvor der ikke er sårbarheder.
Analyse af licensmæssig renhed. Det er ikke så populært her, men hvis du arbejder med udlandet, kan du nogle gange få problemer for at bruge en komponent med åbent kildekode, som ikke må bruges eller modificeres. Ifølge bibliotekets licenspolitik kan vi ikke gøre dette. Eller hvis vi har modificeret det og bruger det, skal vi offentliggøre vores kode. Selvfølgelig ønsker ingen at offentliggøre koden til deres produkter, men der er også måder at beskytte sig mod dette.
Analyse af komponenter, der anvendes i industrimiljø. Lad os forestille os en hypotetisk situation, hvor vi endelig har afsluttet udviklingen og udgivet den seneste version af vores mikrotjeneste. Det lever fantastisk der - en uge, en måned, et år. Vi samler det ikke, foretrækker ikke sikkerhedstests, alt virker fint. Men pludselig efter to uger efter udgivelsen opstår en kritisk sårbarhed i en Open Source-komponent, som vi bruger netop i denne version, i produktionsmiljøet. Hvis vi ikke registrerer, hvad og hvor vi bruger, vil vi simpelthen ikke se denne sårbarhed. Nogle værktøjer har mulighed for at overvåge sårbarheder i biblioteker, der aktuelt bruges i produktionen. Dette er meget nyttigt.
Muligheder:
- Forskellige politikker for forskellige udviklingsfaser.
- Overvågning af komponenter i industrimiljøet.
- Kontrol af biblioteker inden for organisationen.
- Support for forskellige build-systemer og sprog.
- Analyse af Docker-billeder.
Flere eksempler på ledende aktører inden for området, der beskæftiger sig med Open Source-analyse.
Den eneste gratis af dem er fra OWASP. Det kan inkluderes i de tidlige faser for at se, hvordan det fungerer, og hvad det understøtter. Det omfatter primært alle cloud-produkter eller on-premise, men deres database bliver stadig sendt til internettet. De sender ikke dine biblioteker, men hashes eller egne værdier, som de beregner, samt fingeraftryk til deres server for at få notifikationer om sårbarheder.
Integration i proces
Kontrol af biblioteker i perimeteren, som downloades fra eksterne kilder. Vi har eksterne og interne repositoryer. For eksempel er Nexus installeret internt i Event Central, og vi ønsker, at der ikke skal være sårbarheder med status "kritisk" eller "høj" i vores interne repository. Det er muligt at opsætte proxy med hjælp af Nexus Firewall Lifecycle-værktøjet, så sådanne sårbarheder bliver afskåret og ikke kommer ind i det interne repository.
Integration i CI. På samme niveau som autotests, enhedstests og opdeling efter udviklingsfaser: dev, test, prod. På hvert niveau kan man downloade alle biblioteker og bruge hvad som helst, men hvis der er noget kritisk - kan det være en god idé at gøre udviklerne opmærksomme på det, når de går i produktion.
Integration med artifact repositories: Nexus og JFrog.
Integration i udviklingsmiljø. De værktøjer, du vælger, skal have integration med udviklingsmiljøer. Udvikleren skal fra sin arbejdsplads have adgang til scanneresultaterne eller have mulighed for selv at scanne og kontrollere koden for sårbarheder inden commit til CVS.
Integration i CD. Dette er en fantastisk funktion, som jeg rigtig godt kan lide, og som jeg allerede har talt om - overvågning af nye sårbarheder i produktionsmiljøet. Det fungerer cirka sådan her.
Vi har Public Component Repositories — nogle værktøjer udefra, og vores interne repository. Vi ønsker kun, at der skal være trusted components i det. Når vi proxy-anmoder, tjekker vi, at det downloadede bibliotek ikke har sårbarheder. Hvis det falder ind under bestemte politikker, som vi opstiller og nødvendigvis godkender med udviklingen, så downloader vi det ikke, og der kommer en besked om at bruge en anden version. Hvis der virkelig er noget kritisk og dårligt i biblioteket, vil udvikleren slet ikke modtage biblioteket på installationsstadiet — i stedet skal de bruge en nyere eller ældre version.
- Ved build tjekker vi, at ingen har indført noget skadelig, at alle komponenter er sikre, og at ingen har bragt noget farligt på en USB-nøgle.
- I vores repository har vi kun trusted components.
- Ved deployment tjekker vi endnu engang selve pakken: war, jar, DL eller Docker-billede for at sikre, at den overholder politikken.
- Når vi går i produktion, overvåger vi, hvad der sker i produktionsmiljøet: opstår der kritiske sårbarheder eller ej.
Dynamisk analyse — DAST
Værktøjer til dynamisk analyse adskiller sig fundamentalt fra alt, hvad der er blevet sagt tidligere. Det er en imitation af brugerens interaktion med applikationen. Hvis det er en webapplikation, sender vi anmodninger, der simulerer kundens handlinger, trykker på knapperne på frontenden, og sender kunstige data fra formularen: citationstegn, parenteser, tegn i forskellige kodninger, for at se, hvordan applikationen fungerer og behandler eksterne data.
Det samme system muliggør at tjekke skabelonbaserede sårbarheder i Open Source. Da DAST ikke ved, hvilket Open Source vi bruger, sender det blot "ondartede" mønstre og analyserer serverens svar:
— Aha, her er et deserialiseringsproblem, og her er der ikke.
Der er store risici forbundet med dette, fordi hvis du udfører denne sikkerhedstest på den samme stand, som testeplaceringsfolk arbejder med, kan der ske ubehagelige ting.
- Høj belastning på netværket applikationsserver.
- Ingen integrationer.
- Mulighed for ændring af indstillingerne for den analyserede applikation.
- Ingen støtte til nødvendige teknologier.
- Sværhedsgrad ved opsætning.
Vi havde en situation, hvor vi endelig satte AppScan i gang: der var lang tid, vi skulle have adgang til applikationen, vi fik tre konti og blev glade - endelig kunne vi tjekke alt! Vi startede scanning, og det første, AppScan gjorde - var at gå ind i administrationspanelet, trykke på alle knapperne, ændre halvdelen af dataene, og derefter dræbe serveren med sine -anmodninger. Udviklingen med testning sagde:
- Drengene, er I seriøse?! Vi gav jer konti, og I lagde standet ned!
Tænk på de mulige risici. I ideelle tilfælde skal du forberede et separat testmiljø til informationssikkerhed, som på en eller anden måde vil være isoleret fra det øvrige miljø, og det er ønskeligt at tjekke adminpanelet manuelt. Det er et pentest - de resterende procent af indsatsen, som vi ikke overvejer nu.
Det er værd at bemærke, at dette kan bruges som et analogt belastningstest. I første fase kan du aktivere den dynamiske scanner med 10-15 tråde og se, hvad der sker, men som regel, som praksis viser, er der ikke noget godt.
Nogle ressourcer, som vi normalt bruger.
Det er værd at fremhæve - det er "svejtserkniv" for enhver sikkerhedsspecialist. Alle bruger det, og det er meget praktisk. Der er nu kommet en ny demo-version af enterprise edition. Tidligere var det blot et stand-alone værktøj med plugins, men nu endelig laver udviklerne en stor server, som man kan styre flere agenter fra. Det er fantastisk, jeg anbefaler at prøve.
Integration i proces
Integration sker ganske godt og enkelt: start scanning efter vellykket installation af applikationen på standet og scanning efter vellykket gennemførelse af integrationstestning.
Hvis integrationerne ikke fungerer, eller hvis der er stubbe og mock-funktioner, er det meningsløst og ubrugeligt - uanset hvilket mønster vi sender, vil serveren stadig svare ens.
- Ideelt set - et separat miljø til testning.
- Før testning skal du notere login-sekvensen.
- Testning af administrationssystemet - kun manuelt.
Proces
Lidt generelt om processen generelt og om arbejdet med hvert værktøj, især. Alle applikationer er forskellige - nogle fungerer bedre med dynamisk analyse, andre med statisk, nogle med OpenSource-analyse, pentests eller noget helt andet, for eksempel hændelser med .
Hver proces har brug for kontrol.
For at forstå, hvordan processen fungerer, og hvor den kan forbedres, er det nødvendigt at samle metrikker fra alt, hvad der er tilgængeligt, inklusive produktionsmetrikker, metrikker fra værktøjer og fra defekttrackere.
Alle data er nyttige. Man skal se på forskellige aspekter af, hvor hvert værktøj anvendes bedst, og hvor processen specifikt svigter. Måske er det værd at kigge på svartiderne fra udviklingen for at forstå, hvor forbedringer kan laves baseret på tiden. Jo flere data, jo flere perspektiver kan man konstruere fra overordnede til detaljer om hver proces.
Da alle statiske og dynamiske analyseværktøjer har deres egne API'er, forskellige måder at køre dem på, principper, nogle har planlæggere, andre har ikke – skriver vi et værktøj AppSec Orkestrator, som gør det muligt at have et enkelt indgangspunkt til hele processen fra produktet og styre det fra ét sted.
For ledere, udviklere og sikkerhedsingeniører er der et indgangspunkt, hvor man kan se, hvad der er i gang, konfigurere og starte scanninger, få scanningresultater og stille krav. Vi forsøger at undgå papirarbejde og konvertere alt til et menneskeligt format, som udviklingen bruger – sider på Confluence med status og metrikker, defekter i Jira eller i forskellige defekttrackere, eller integration i en synkron/asin-kron proces i CI/CD.
Hovedpunkter
Værktøjer er ikke det vigtigste. Først skal man overveje processen – derefter implementere værktøjer. Værktøjer er gode, men dyre, så man kan begynde med processen og oprette interaktion og forståelse mellem udvikling og sikkerhed. Fra et sikkerhedssynspunkt er det ikke nødvendigt at 'stoppe' alt, og fra et udviklingssynspunkt, hvis der er noget high mega super kritisk, så skal det løses, ikke ignoreres.
Produktkvalitet er et fælles mål for både sikkerhed og udvikling. Vi arbejder på samme sag, og sørger for, at alt fungerer korrekt og undgår omdømmemæssige risici og økonomiske tab. Derfor fremmer vi tilgangene DevSecOps og SecDevOps for at forbedre kommunikationen og gøre produktet bedre.
Start med det, der allerede er tilgængeligt.: krav, arkitektur, delvise kontroller, træning, retningslinjer. Du behøver ikke at anvende alle praktikker på alle projekter med det samme — arbejd iterativt. Der er ikke nogen universel standard — eksperimentér og prøv forskellige metoder og løsninger.
Mellem IOT-defekter og funktionelle defekter er der et lighedstegn.
Automatiser alt, der bevæger sig. Alt, der ikke bevæger sig - skal flyttes og automatiseres. Hvis noget gøres manuelt, er det ikke en god del af processen. Det kan være værd at overveje igen og også automatisere.
Hvis størrelsen på IOT-teamet er lille - brug Security Champions.
Måske er det, jeg har talt om, ikke det for dig, og du finder på noget eget - og det er godt. Men vælg værktøjer baseret på kravene specifikt til din proces. Lyt ikke til, hvad community siger om, at dette værktøj er dårligt, og dette er godt. Måske vil hele situationen være omvendt for dit produkt.
Krav til værktøjer.
- Lav falsk positiv rate.
- Acceptabel analysetid.
- Brugervenlighed.
- Tilgængelighed af integrationer.
- Forståelse af produktets udviklingsplan.
- Mulighed for at tilpasse værktøjerne.
Yuris præsentation blev valgt som en af de bedste på DevOpsConf 2018. For at lære om flere interessante idéer og praktiske cases, kom den 27. og 28. maj til Skolkovo på som en del af . Og endnu bedre, hvis du er klar til at dele din erfaring, så til præsentation inden 21. april.
Kilde: habr.com
