Rädsla och hat DevSecOps

Vi hade 2 kodanalysatorer, 4 verktyg för dynamisk testning, egna skapelser och 250 skript. Inte så att allt detta var nödvändigt i den nuvarande processen, men eftersom jag började implementera DevSecOps, så måste man gå hela vägen.

Källa. Karaktärernas skapare: Justin Roiland och Dan Harmon.

Vad är SecDevOps? Och DevSecOps? Vad är skillnaderna? Applikationssäkerhet – vad handlar det om? Varför fungerar den klassiska metoden inte längre? På alla dessa frågor har svaret. Jurij Shabalin från Swordfish Security. Jurij kommer grundligt att svara på allt och gå igenom problemen med övergången från den klassiska modellen för applikationssäkerhet till DevSecOps-processen: hur man rätt ska gå tillväga för att integrera processen för säker utveckling i DevOps-processen utan att bryta något, hur man går igenom huvudsakliga faser av säkerhetstestning, vilka verktyg som kan användas, hur de skiljer sig och hur man korrekt konfigurerar dem för att undvika fallgropar.

Om talaren: Jurij Shabalin – Chief Security Architect på Swordfish Security.. Ansvarar för implementeringen av SSDL, för den totala integrationen av programanalysverktyg i ett enhetligt utvecklings- och testekosystem. 7 års erfarenhet inom informationssäkerhet. Har arbetat på Alfa-Bank, Sberbank och på Positive Technologies, som utvecklar programvara och tillhandahåller tjänster. Talare vid internationella konferenser som ZerONights, PHDays, RISSPA, OWASP.

Applikationssäkerhet: vad handlar det om?

Applikationssäkerhet – är ett område inom säkerhet som ansvarar för säkerheten hos applikationer. Detta rör sig inte om infrastruktur eller nätverkssäkerhet, utan just det vi skriver och det utvecklarna arbetar med – det handlar om brister och sårbarheter i själva applikationen.

Inriktning SDL eller SDLC — Security development lifecycle – utvecklades av Microsoft. På schemat – den kanoniska modellen av SDLC, vars huvudsakliga uppgift är att säkerhet ska ingå i varje steg av utvecklingen, från krav till release och produktion. Microsoft insåg att det fanns för många buggar i produktion, att de blev fler och att något måste göras åt det, vilket ledde till detta tillvägagångssätt som blev kanoniskt.

Applikationssäkerhet och SSDL syftar inte till att upptäcka sårbarheter, som man vanligtvis tror, utan till att förhindra att de uppstår. Med tiden har den kanoniska metoden från Microsoft förbättrats, utvecklats, och det har tillkommit en djupare och mer detaljerad insikt.

Den kanoniska SDLC är starkt detaljerad i olika metoder – OpenSAMM, BSIMM, OWASP. Metoderna skiljer sig åt, men övergripande liknar de varandra.

Bygg säkerhet in i mognadsmodellen

Jag gillar mest BSIMM — Bygg säkerhet in i mognadsmodellen. Grunden i metoden är att dela upp processen för applikationssäkerhet i 4 domäner: Governance, Intelligence, SSDL Touchpoints och Deployment. I varje domän finns 12 praktiker som presenteras i form av 112 aktiviteter.

Varje av de 112 aktiviteterna har 3 mognadsnivåer: grundläggande, medel och avancerad. Alla 12 praktiker kan studeras avsnitt för avsnitt, välja viktiga för er och förstå hur de ska implementeras och gradvis lägga till element, till exempel statisk och dynamisk kodanalys eller code review. Ni skriver en plan och arbetar lugnt enligt den i implementeringen av de valda aktiviteterna.

Varför DevSecOps

DevOps är en stor helhet där man måste ta ansvar för säkerheten.

Ursprungligen DevOps antog säkerhetskontroller. I praktiken var säkerhetsteamen mycket mindre än idag, och de fungerade inte som deltagare i processen, utan som en kontroll- och tillsynsorganisation som ställer krav och kontrollerar kvaliteten på produkten i slutet av release. Detta är den klassiska metoden där säkerhetsteamen stod bakom en vägg från utvecklingen och inte deltog i processen.

Huvudproblemet ligger just i att säkerheten är separat från utvecklingen. Vanligtvis är det en säkerhetskontur med 2-3 stora och dyra verktyg. En gång var sjätte månad kommer källkoden eller applikationen som behöver kontrolleras, och en gång om året görs pentester. Detta leder till att tidslinjen för produktlansering försenas, och utvecklaren får en enorm mängd sårbarheter från automatiserade verktyg. Allt detta är omöjligt att sortera ut och åtgärda, eftersom resultaten från tidigare sex månader inte har sorterats, och här kommer en ny bunt.

Under vårt företags arbete ser vi att säkerhet inom alla områden och industrier förstår att det är dags att samarbeta med utvecklingen – i Agile. DevSecOps-paradigmet passar utmärkt in i metoden för agil utveckling, för implementering, stöd och deltagande i varje release och iteration.

Övergången till DevSecOps

Det viktigaste ordet i säkerhetsutvecklingslivscykeln är "process"Du måste förstå detta innan du tänker på att köpa verktyg.

Att bara inkludera verktyg i DevOps-processen är inte tillräckligt - det är viktigt med samverkan och förståelse mellan deltagarna i processen.

Människor är viktigare än verktygen.

Ofta börjar planeringen av en säker utvecklingsprocess med valet och köpet av verktyg, och slutar med försök att integrera verktyget i den pågående processen, som ofta förblir just försök. Detta leder till sorgliga konsekvenser, eftersom varje verktyg har sina egna egenskaper och begränsningar.

Ett vanligt fall är när säkerhetsavdelningen valt ett bra, dyrt verktyg med många möjligheter och kom till utvecklarna för att integrera det i processen. Men det fungerar inte - processen är sådan att begränsningarna för det redan inköpta verktyget inte passar in i den nuvarande paradigm.

Börja med att beskriva vilket resultat du vill ha och hur processen ska se ut. Detta hjälper till att förstå verktygets och säkerhetens roller i processen.

Börja med det som redan används.

Innan du köper dyra verktyg, ta en titt på vad du redan har. Varje företag har säkerhetskrav som ställs på utvecklingen, det finns granskningar, pentester - varför inte omvandla allt detta till en begriplig och användarvänlig form?

Vanligtvis är kraven en pappershög som ligger på hyllan. Det har funnits fall där vi kommer till ett företag för att titta på processerna och ber om att få se säkerhetskraven för mjukvaran. Specialisten som hanterade detta letade länge:

- Nu, någonstans i anteckningarna var det en väg till det här dokumentet.

Till slut fick vi dokumentet efter en vecka.

För krav, kontroller och annat, skapa en sida, till exempel på Confluence – det är praktiskt för alla.

Det är enklare att omforma det som redan finns och använda det som start.

Använd Security Champions.

Vanligtvis, i ett medelstort företag med 100-200 utvecklare, arbetar en säkerhetsansvarig som utför flera funktioner och har fysiskt svårt att kolla allt. Även om han försöker sitt bästa - ensam kan han inte kontrollera hela koden som utvecklarna genererar. För sådana fall har konceptet balanserats - Security Champions.

Security Champions är en person inom utvecklingsteamet som är intresserad av säkerheten i din produkt.

Security Champion är ingången till utvecklingsteamet och säkerhetens evangelist i en och samma person.

Vanligtvis, när en säkerhetsexpert kommer till utvecklingsteamet och påpekar ett fel i koden, får de ett förvånat svar:

— Vem är du? Jag ser dig för första gången. Jag mår bra — min seniora kollega gav godkänt på code review, vi går vidare!

Detta är en typisk situation, eftersom det finns mycket större förtroende för seniorer eller bara kollegor i teamet som utvecklaren ständigt interagerar med i sitt arbete och under code review. Om Security Champion istället påpekar felet och konsekvenserna kommer deras ord att väga tyngre.

Utvecklare känner också till sin kod bättre än någon säkerhetsexpert. För en person som har minst 5 projekt i verktyget för statisk analys är det vanligtvis svårt att komma ihåg alla detaljer. Security Champions känner sitt produkt: vad som interagerar med vad och vad som bör beaktas först — de är mer effektiva.

Så tänk på att implementera Security Champions och utöka säkerhetsteamets inflytande. För själva mästaren är detta också fördelaktigt: professionell utveckling inom ett nytt område, utvidgning av teknisk kunskap, förbättring av tekniska, ledarskaps- och ledarnivåer, ökad marknadsvärde. Det är en viss form av social ingenjörskonst, dina "ögon" i utvecklingsteamet.

Testningssteg

Paradigmet 20 av 80 anger att 20% av insatserna ger 80% av resultaten. Dessa 20% är praxis för analys av applikationer som kan och bör automatiseras. Exempel på sådana aktiviteter är statisk analys — SAST, dynamisk analys — DAST, och kontroll av Open Source. Jag kommer att berätta mer om aktiviteterna samt om de verktyg och specifika egenskaper vi vanligtvis stöter på när vi implementerar dem i processen, och hur man gör det korrekt.

Huvudproblem med verktygen

Jag kommer att lyfta fram aktuella problem för alla verktyg som kräver uppmärksamhet. Jag kommer att gå igenom dem mer ingående för att undvika upprepning.

Långsam analys. Om det tar 30 minuter från commit till produktionslansering för alla tester och byggprocessen, kommer säkerhetskontrollerna att ta ett dygn. Ingen kommer att vilja bromsa processen. Tänk på denna aspekt och dra slutsatser.

Hög nivå av False Negative eller False Positive. Alla produkter är olika, alla använder olika ramverk och sin egen kodstil. På olika kodbaser och teknologier kan verktygen visa olika nivåer av False Negative och False Positive. Så se på vad som faktiskt gäller för ert företag och era applikationer, som kommer att ge bra och tillförlitliga resultat.

Det finns inga integrationer med befintliga verktyg. Titta på verktygen ur integrationsperspektiv, baserat på det ni redan använder. Till exempel, om ni använder Jenkins eller TeamCity — kontrollera integrationen av verktygen med just denna programvara, och inte med GitLab CI, som ni inte använder.

Avsaknad eller överdriven komplexitet av anpassningar. Om verktyget inte har ett API, varför skulle det då vara nödvändigt? Allt som kan göras i gränssnittet bör också vara tillgängligt via API. I en idealisk situation bör verktyget ha möjlighet att anpassa kontroller.

Ingen produktutvecklingsplan. Utvecklingen står inte still, vi använder alltid nya ramverk och funktioner, och skriver om gammal kod till nya språk. Vi vill vara säkra på att verktyget vi köper kommer att stödja nya ramverk och teknologier. Därför är det viktigt att veta att produkten har en verklig och korrekt Roadmap utvecklingsplan.

Processens särdrag

Förutom verktygens särdrag bör ni också ta hänsyn till utvecklingsprocessens särdrag. Till exempel, att störa utvecklingen är ett typiskt misstag. Låt oss titta på vilka andra särdrag som bör beaktas och vad säkerhetsteamet bör fokusera på.

För att inte försena utvecklings- och lanseringsscheman, skapa olika regler och show stoppers — kriterier som stoppar byggprocessen vid förekomst av sårbarheter — för olika miljöer. Till exempel, vi förstår att den aktuella grenen går till utvecklingsmiljön eller UAT, vilket betyder att vi inte stoppar eller säger:

— Här finns sårbarheter, ni kan inte gå vidare!

I detta skede är det viktigt att informera utvecklarna om att det finns säkerhetsproblem som de bör uppmärksamma.

Närvaron av sårbarheter är inget hinder för fortsatt testning: manuell, integrations- eller manuellt. Å andra sidan behöver vi på något sätt öka produktens säkerhet så att utvecklarna inte ignorerar det som säkerheten upptäcker. Därför gör vi ibland så här: vid stand-upen, när det lanseras på utvecklingsmiljön, informerar vi helt enkelt utvecklingen:

— Grabbar, ni har problem, vänligen ta en titt på dem.

Under UAT-steget visar vi återigen varningar om sårbarheter, och när vi går live säger vi:

— Grabbar, vi har varnat flera gånger, ni har inte gjort något – vi kan inte släppa ut er med detta.

Om vi pratar om kod och dynamik, så är det nödvändigt att bara visa och varna för sårbarheterna i de funktioner och koder som just har skrivits i denna funktion. Om utvecklaren flyttade en knapp med 3 pixlar och vi säger till honom att han har en SQL-injektion och därför måste fixa detta omedelbart – det är fel. Titta bara på det som har skrivits nu och på den ändring som kommer till applikationen.

Låt oss säga att vi har en viss funktionell defekt – det som applikationen inte ska göra: pengar överförs inte, det blir inget klick på knappen som leder till nästa sida eller varan laddas inte. Säkerhetsdefekter — det är samma typ av defekter, men inte i termer av applikationens funktion, utan av säkerhet.

Inte alla problem med mjukvarukvalitet är säkerhetsproblem. Men alla säkerhetsproblem är relaterade till mjukvarukvalitet. Sherif Mansour, Expedia.

Eftersom alla sårbarheter är samma typ av defekter, bör de finnas där där alla utvecklingsdefekter finns. Så glöm rapporterna och de skrämmande PDF:erna som ingen läser.

När jag arbetade på ett företag som sysslade med utveckling fick jag en rapport från verktyg för statisk analys. Jag öppnade den, blev förskräckt, gjorde kaffe, bläddrade igenom 350 sidor, stängde den och gick tillbaka till mitt arbete. Stora rapporter är döda rapporter. Ofta går de ingenstans, e-postmeddelanden raderas, glöms bort, tappar bort eller så säger affärssidan att de accepterar riskerna.

Vad ska man göra? De bekräftade defekter som har hittats omvandlar vi helt enkelt till en utvecklingsvänlig form, till exempel genom att lägga dem i backloggen i Jira. Vi prioriterar defekterna och åtgärdar dem i prioritetsordning tillsammans med funktionella defekter och testdefekter.

Statisk analys - SAST

Detta är en analys av koden för att upptäcka sårbarheter., men det är inte detsamma som SonarQube. Vi kontrollerar inte bara utifrån mönster eller stil. Under analysen tillämpas en rad tillvägagångssätt: efter sårbarhetsstrukturen, genom DataFlow, genom analys av konfigurationsfiler. Det handlar allt om koden.

Fördelar med tillvägagångssättet: upptäckte sårbarheter i koden i ett tidigt skede av utvecklingen, när det ännu inte finns några miljöer eller färdiga verktyg, och möjligheten till inkrementell skanning: skanning av den del av koden som har ändrats, och endast den funktion som vi just nu arbetar med, vilket minskar skanningstiden.

Nackdelar — det är avsaknaden av stöd för nödvändiga språk.

Nödvändiga integrationer, som bör finnas i verktygen, enligt min subjektiva åsikt:

• Integrationsverktyg: Jenkins, TeamCity och Gitlab CI.
• Utvecklingsmiljö: Intellij IDEA, Visual Studio. För utvecklaren är det bekvämare att inte tränga sig in i ett oklart gränssnitt som man måste minnas, utan direkt på sin arbetsplats i sin egen utvecklingsmiljö se alla nödvändiga integrationer och sårbarheter som han har hittat.
• Code review: SonarQube och manuell granskning.
• Defekthanterare: Jira och Bugzilla.

På bilden visas några av de bästa representationerna av statisk analys.

Det är inte verktygen som är viktiga, utan processen, därför finns det Open Source-lösningar som också är bra för att testa processen.

SAST Open Source kommer inte att upptäcka ett stort antal sårbarheter eller komplexa DataFlow, men i uppbyggnaden av processen kan de användas och bör användas. De hjälper till att förstå hur processen kommer att byggas, vem som kommer att ansvara för buggar, vem som rapporterar, och vem som ska rapportera. Om du vill genomföra den inledande fasen av att bygga säkerheten i din kod - använd Open Source-lösningar.

Hur kan detta integreras om ni är i början av er resa, om ni inte har något: ingen CI, ingen Jenkins, ingen TeamCity? Låt oss betrakta integrationer i processen.

Integrering på CVS-nivå

Om ni har Bitbucket eller GitLab kan ni göra en integration på Concurrent Versions System.

Vid händelse — pull request, commit. Du skannar koden och i byggstatus visar du om säkerhetskontrollen passerade eller inte.

Feedback. Självklart behövs alltid feedback. Om du bara genomförde det på säkerhetssidan, lade det i en låda och inte berättade något för någon, och sedan i slutet av månaden släppte en massa buggar - det är inte rätt och inte bra.

Integration med kodgranskningssystemet

En gång ställde vi in en teknisk användare AppSec som standardgranskare i flera viktiga projekt. Beroende på om det fanns några fel i den nya koden eller inte, ställer granskarna status för pull request till "accept" eller "need work" - antingen är allt okej, eller så behöver det justeras och länkar till vad som behöver justeras. För den version som går i produktion hade vi inkluderat ett förbud mot merge om testet för informationssäkerhet inte passerades. Vi inkluderade detta i manuell kodgranskning, och de andra deltagarna i processen såg säkerhetsstatusarna just för den specifika processen.

Integration med SonarQube

Många har quality gate för kodkvalitet. Här är detsamma - du kan skapa samma gates bara för SAST-verktyg. Det kommer att vara samma gränssnitt, samma quality gate, bara att det kommer att kallas security gate. Och om du har ställt in en process med SonarQube kan du lugnt integrera allt där.

Integration på CI-nivå

Här är allt också ganska enkelt:

• På samma nivå som automatiserade tester, enhetstester.
• Uppdelning efter utvecklingssteg: dev, test, prod. Olika uppsättningar regler kan inkluderas, eller olika fail conditions: vi stoppar byggandet, vi stoppar inte byggandet.
• Synchronous/asynchronous launch. Vi väntar på att testerna för säkerhet ska avslutas eller inte. Det vill säga vi kör dem bara och går vidare, och senare får vi status att allt är bra eller dåligt.

Detta är allt i en perfekt rosa värld. I verkliga livet finns det inte, men vi strävar efter det. Resultatet av genomförda säkerhetskontroller bör vara jämförbart med resultaten från enhetstester.

Till exempel tog vi ett stort projekt och bestämde att vi nu skulle skanna det med SAST – okej. Vi la in detta projekt i SAST, och det gav oss 20 000 sårbarheter. Genom en viljeaktighet beslutade vi att allt var okej. 20 000 sårbarheter är vår tekniska skuld. Vi lägger skulden i en låda och kommer att ta itu med den gradvis och registrera buggar i defektspårare. Vi anställer ett företag, gör allt själva eller får hjälp av Security Champions – och den tekniska skulden kommer att minska.

Och alla nya sårbarheter i den nya koden måste åtgärdas lika snabbt som fel i unit- eller automatisk tester. Som sagt, bygget startade, vi körde det, två tester misslyckades och två säkerhetstester misslyckades. Okej – vi gick dit, såg vad som hände, korrigerade det ena, korrigerade det andra, nästa gång körde vi det – allt var bra, inga nya sårbarheter dök upp, testerna misslyckades inte. Om denna uppgift är djupare och behöver undersökas grundligt, eller om åtgärden av sårbarheterna påverkar stora delar av vad som ligger under huven: en bug registrerades i defektspårare, den prioriteras och åtgärdas. Tyvärr är världen inte perfekt och testerna faller ibland.

Exempel på säkerhetsport – analog med kvalitetsport, baserat på närvaron och mängden sårbarheter i koden.

Integrera med SonarQube – pluginen installeras, allt är mycket bekvämt och bra.

Integration med utvecklingsmiljön

Integrationsmöjligheter:

• Starta skanning från utvecklingsmiljön redan innan commit.
• Granska resultaten.
• Analysera resultaten.
• Synkronisering med servern.

Så här ser det ut att hämta resultat från servern.

I vår utvecklingsmiljö Intellij IDEA finns det bara ett extra alternativ som informerar att sådana sårbarheter upptäcktes under skanningen. Man kan omedelbart rätta koden, se rekommendationer och Flödesdiagram. Allt detta finns på utvecklarens arbetsplats, vilket är mycket bekvämt – man behöver inte gå igenom andra länkar och leta efter något extra.

Öppen källkod

Det här är mitt favoritämne. Alla använder Open Source-bibliotek – varför skriva en massa provisoriska lösningar och cyklar när man kan ta ett färdigt bibliotek där allt redan är implementerat?

Självklart, det är så, men bibliotek skrivs också av människor, innefattar också vissa risker och där finns också sårbarheter som periodiskt eller konstant rapporteras. Därför finns det ett nästa steg i Application Security – det är analysen av Open Source-komponenter.

Analys av Open Source – OSA

Verktyget innehåller tre stora steg.

Sökning efter sårbarheter i biblioteken. Till exempel, verktyget vet att vi använder ett visst bibliotek och att det CVE eller i bug trackers finns sårbarheter som är relaterade till den här versionen av biblioteket. Vid försök att använda det kommer verktyget att ge en varning om att biblioteket är sårbart och rekommenderar att använda en annan version där sårbarheter inte finns.

Analys av licensrenhet. Det är fortfarande inte särskilt populärt här, men om du arbetar internationellt kan du periodiskt få problem för att använda en komponent med öppen källkod som inte får användas eller modifieras. Enligt licenspolicyn för biblioteket får vi inte göra detta. Eller om vi har modifierat den och använder den, måste vi lägga ut vår kod. Naturligtvis vill ingen lägga ut koden för sina produkter, men det finns också sätt att skydda sig mot detta.

Analys av komponenter som används i industriell miljö. Låt oss föreställa oss en hypotetisk situation där vi äntligen har avslutat utvecklingen och släppt den sista versionen av vår mikrotjänst. Den fungerar utmärkt – en vecka, en månad, ett år. Vi samlar inte in den, vi gör inga säkerhetskontroller, allt verkar bra. Men plötsligt, två veckor efter släppet, kommer en kritisk sårbarhet fram i en Open Source-komponent som vi använder just i den här versionen, i produktionsmiljö. Om vi inte registrerar vad och var vi använder, kommer vi helt enkelt inte att se den här sårbarheten. Vissa verktyg har möjlighet att övervaka sårbarheter i bibliotek som för närvarande används i produktion. Det är mycket användbart.

Möjligheter:

• Olika policys för olika faser av utveckling.
• Övervakning av komponenter i industriell miljö.
• Kontroll av bibliotek inom organisationens kontur.
• Stöd för olika byggsystem och språk.
• Analys av Docker-bilder.

Några exempel på ledande aktörer inom området som sysslar med Open Source-analys.

Den enda gratis av dem är Dependency-Check från OWASP. Det kan inkluderas tidigt för att se hur det fungerar och vad det stöder. I huvudsak handlar det om alla molnprodukter eller on-premise, men de skickas fortfarande till internet i samband med sin databas. De skickar inte dina bibliotek, utan hashvärden eller sina egna beräknade värden, och fingeravtryck till sina servrar för att få information om sårbarheter.

Integration i processen

Kontroll av bibliotek i perimeter, som laddas ner från externa källor. Vi har externa och interna förråd. Till exempel, inom Event Central finns Nexus, och vi vill att vårt interna förråd inte ska innehålla sårbarheter med status 'kritisk' eller 'hög'. Det går att ställa in proxy med hjälp av verktyget Nexus Firewall Lifecycle så att sådana sårbarheter blockeras och inte når det interna förrådet.

Integration i CI. På samma nivå som automatiserade tester, enhetstester och uppdelning efter utvecklingssteg: dev, test, prod. I varje steg kan man ladda ner vilket bibliotek som helst och använda vad som helst, men om det finns något med status 'kritisk' kanske man bör uppmärksamma utvecklarna på detta i samband med lansering.

Integration med artefaktlagringar: Nexus och JFrog.

Integration i utvecklingsmiljön. Verktyg som du väljer måste ha integration med utvecklingsmiljöer. Utvecklaren ska ha tillgång till resultaten från skanningarna från sin arbetsstation, eller ha möjlighet att själv skanna och kontrollera koden för sårbarheter innan man commitar i CVS.

Integration i CD. Det här är en fantastisk funktion som jag verkligen gillar och som jag redan har berättat om – övervakning av nya sårbarheter i produktionsmiljöer. Det fungerar ungefär så här.

Vi har Offentliga komponentförråd — vissa verktyg utanför och vår interna databas. Vi vill att det endast ska finnas trusted components i den. Vid proxyförfrågningar verifierar vi att det nedladdade biblioteket inte har några sårbarheter. Om det faller under vissa policyer som vi fastställer och godkänner med utvecklingen, laddar vi inte ner det, och det kommer en avvisning att använda en annan version. Om biblioteksinnehållet är verkligt kritiskt och dåligt, får utvecklaren inte biblioteket ens under installationssteget — det får använda en högre eller lägre version.

• Vid bygget kontrollerar vi att ingen har introducerat något dåligt, att alla komponenter är säkra och att ingen har fört in något farligt via USB.
• I vårt arkiv har vi endast trusted components.
• Vid deployment kontrollerar vi återigen själva paketet: war, jar, DL eller Docker-image så att det överensstämmer med policyn.
• När vi går i produktion övervakar vi det som händer i den industriella miljön: om kritiska sårbarheter dyker upp eller inte.

Dynamisk analys — DAST

Verktyg för dynamisk analys skiljer sig markant från allt som sagts tidigare. Det är en simulering av användarens interaktion med applikationen. Om det är en webbapplikation, skickar vi förfrågningar som imiterar klientens arbete, trycker på knappar på frontend, skickar artificiella data från formulär: citationstecken, parenteser, symboler i olika kodningar, för att se hur applikationen fungerar och behandlar externa data.

Detta system gör det också möjligt att kontrollera mönstervärdiga sårbarheter i Open Source. Eftersom DAST inte vet vilken Open Source vi använder, skickar den helt enkelt "skadliga" mönster och analyserar svaren från servern:

— Aha, här finns ett deserialiseringsproblem, men här finns det inte.

Det medför stora risker, eftersom om du genomför detta säkerhetstest på samma plattform som används av testarna — kan obehagliga saker hända.

• Hög belastning på applikationsservern.
• Inga integrationer.
• Möjlighet att ändra inställningarna för den analyserade applikationen.
• Ingen support för nödvändiga teknologier.
• Svårighetsgrad i konfigurationen.

Vi hade en situation när vi äntligen körde AppScan: vi kämpade länge för att få tillgång till applikationen, fick tre konton och var glada - nu kan vi äntligen kontrollera allt! Vi startade skanningen, och det första AppScan gjorde - det gick in i administratörspanelen, klickade på alla knappar, ändrade hälften av datan, och sedan dödade det servern helt. mailform-förfrågningar. Utveckling med testning sa:

— Grabbar, ni skämtar?! Vi gav er konton, och ni la ner standen!

Tänk på möjliga risker. I idealfallet förbered ett separat stand för testning av informationssäkerhet, som bör vara isolerat från den övriga miljön på något sätt, och det är önskvärt att kontrollera adminpanelen manuellt. Det här är en pentest - de återstående procenten av insatserna som vi inte beaktar just nu.

Det är värt att notera att detta kan användas som ett alternativ till belastningstestning. I det första steget kan en dynamisk skanner sättas i 10-15 trådar och se vad som händer, men i praktiken visar det sig vanligtvis att det inte blir något bra.

Några resurser som vi vanligtvis använder.

Det är värt att framhäva Burp Suite — detta är en "schweizisk armékniv" för varje säkerhetsspecialist. Den används av alla och är mycket användarvänlig. En ny demoversion av enterprise edition har just släppts. Tidigare var det bara en fristående programvara med plugins, men nu gör utvecklarna äntligen en stor server från vilken man kan hantera flera agenter. Det är fantastiskt, jag rekommenderar att prova.

Integration i processen

Integrationen fungerar ganska bra och enkelt: start av skanning efter en lyckad installation av applikationen på standen och skanning efter en framgångsrik genomförd integrationstestning.

Om integrationerna inte fungerar eller det finns dummy-funktioner, är det meningslöst och värdelöst - oavsett vilket mönster vi skickar så kommer servern fortfarande att svara samma.

• Idealiskt - ett separat stand för testning.
• Innan testningen börjar, skriv ner inloggningssekvensen.
• Testning av administrativt system - bara manuellt.

Process

Lite översiktligt om processen i allmänhet och om varje verktygs arbete, speciellt. Alla applikationer är olika - den ena fungerar bättre med dynamisk analys, den andra med statisk, den tredje med OpenSource-analys, pentest eller något helt annat, till exempel händelser med Waf.

Varje process behöver kontroll.

För att förstå hur processen fungerar och var den kan förbättras, måste man samla metrik från allt som går att nå, inklusive produktionsmetrik, metrik från verktyg och från defektspårare.

All data är användbar. Man måste titta ur olika vinklar på var ett verktyg tillämpas bäst, var processen specifikt faller. Kanske bör man titta på utvecklingens svarstid för att förstå var man kan förbättra processen baserat på tid. Ju mer data, desto fler perspektiv kan byggas från övergripande till detaljer i varje process.

Eftersom alla statiska och dynamiska analyzers har sina egna API:er, sina egna sätt att starta, principer, några har schemaläggare, andra har det inte – skriver vi ett verktyg AppSec Orkestrator, som möjliggör en enhetlig ingångspunkt till hela processen med produkten och hantera den från en punkt.

För chefer, utvecklare och säkerhetsingenjörer finns en ingångspunkt där man kan se vad som körs, konfigurera och starta skanning, få resultat av skanning, ställa krav. Vi försöker gå bort från papper och översätta allt till ett mänskligt sätt som utvecklingen använder – sidor i Confluence med status och metrik, defekter i Jira eller i olika defektspårare, eller integrera i en synkron/asin kprocess i CI/CD.

Nyckelinsikter

Verktyg är inte huvudsaken. Först planera processen – sedan implementera verktyg. Verktyg är bra men dyra, så man kan börja med processen och etablera samverkan och förståelse mellan utveckling och säkerhet. Ur säkerhetssynpunkt – det är inte nödvändigt att stoppa allt som kommer, Ur utvecklingssynpunkt – om det finns något som är högmega superkritisk, måste det åtgärdas snarare än att blunda för problemet.

Produktkvalitet – ett gemensamt mål både för säkerhet och utveckling. Vi gör en gemensam sak, strävar efter att allt fungerar korrekt och att det inte finns reputationsrisker eller ekonomiska förluster. Därför förespråkar vi tillvägagångssättet DevSecOps, SecDevOps för att förbättra kommunikationen och göra produkten mer kvalitativ.

Börja med det som redan finns: krav, arkitektur, partiella kontroller, träningar, riktlinjer. Använd inte alla metoder på en gång för alla projekt — gå vidare iterativt. Det finns ingen enhetlig standard — experimentera och prova olika tillvägagångssätt och lösningar.

Det finns en likhet mellan säkerhetsdefekter och funktionella defekter.

Automatisera allt, som rör sig. Allt som inte rör sig — försök att få det att röra sig och automatisera det. Om något görs manuellt är det inte en bra del av processen. Det kanske är värt att omvärdera det och automatisera det också.

Om storleken på säkerhetsteamet är liten — använd Security Champions..

Kanske är det jag har pratat om inte lämpligt för er och ni hittar på något eget — och det är okej. Men välj verktyg baserat på kraven för just er process. Titta inte på vad communityn säger om att det här verktyget är dåligt, och att det här är bra. Kanske visar det sig att det är tvärtom för just er produkt.

Verktygskrav.

• Låg nivå av False Positive.
• Rimlig analys tid.
• Användarvänlighet.
• Finns integrationer.
• Förståelse för produktens utvecklingsplan.
• Möjlighet till anpassning av verktyg.

Yuris föredrag valdes som ett av de bästa på DevOpsConf 2018. För att upptäcka fler intressanta idéer och praktiska fall, kom den 27 och 28 maj till Skolkovo på DevOpsConf i samband med festivalen RIT++. Och ännu bättre, om ni är villiga att dela med er av er erfarenhet, då skicka in en ansökan för föredraget senast den 21 april.

Källa: habr.com