Wy hiene 2 koade-analyzers, 4 dynamyske test-ark, ús eigen ambachten en 250 skripts. Net dat dit alles nedich wie yn it hjoeddeistige proses, mar as jo ienris begon te ymplementearjen fan DevSecOps, moatte jo nei it ein gean.
. Karakters makke troch Justin Roiland en Dan Harmon.
Wat is SecDevOps? Hoe sit it mei DevSecOps? Wat binne de ferskillen? Applikaasjefeiligens - wêr giet it oer? Wêrom wurket de klassike oanpak net mear? Al dizze fragen witte it antwurd Yuri Shabalin fan Swordfish Security. Yuriy sil alles yn detail beäntwurdzje en de problemen analysearje fan oergong fan it klassike Application Security-model nei it DevSecOps-proses: hoe't jo de yntegraasje fan it feilige ûntwikkelingsproses yn it DevOps-proses goed benaderje en neat brekke, hoe't jo troch de haadstappen gean fan feiligenstesten, hokker ark kinne wurde brûkt, hoe se ferskille en hoe se goed te konfigurearjen om falkûlen te foarkommen.
Oer sprekker: Yuri Shabalin - Chief Security Architect yn it bedriuw Swordfish Security. Ferantwurdlik foar de ymplemintaasje fan SSDL, foar de algemiene yntegraasje fan ark foar applikaasjeanalyse yn ien ekosysteem foar ûntwikkeling en testen. 7 jier ûnderfining yn ynformaasjefeiligens. Hat wurke by Alfa-Bank, Sberbank en Positive Technologies, dy't software ûntwikkelet en tsjinsten leveret. Sprekker fan ynternasjonale konferinsjes ZerONights, PHDays, RISSPA, OWASP.
Applikaasjefeiligens: wêr giet it oer?
Oanfraachfeiligens is de feiligens seksje dy't ferantwurdlik is foar applikaasje feiligens. Dit giet net oer ynfrastruktuer of netwurkfeiligens, mar oer wat wy skriuwe en wêr't ûntwikkelders oan wurkje - dit binne de gebreken en kwetsberens fan 'e applikaasje sels.
Direction - Feiligens ûntwikkeling lifecycle - Untwikkele troch Microsoft. It diagram lit it kanonike SDLC-model sjen, wêrfan de haadtaak de dielname fan feiligens is yn elke stadia fan ûntwikkeling, fan easken, oant frijlitting en frijlitting oant produksje. Microsoft realisearre dat d'r tefolle bugs yn 'e prom binne, d'r binne mear fan har en der moat wat oan dien wurde, en se stelden dizze oanpak foar, dy't kanonike waard.
Applikaasjefeiligens en SSDL binne net rjochte op it opspoaren fan kwetsberens, lykas gewoanlik leaude, mar op it foarkommen fan har foarkommen. Yn 'e rin fan' e tiid is de kanonike oanpak fan Microsoft ferbettere, ûntwikkele, it hat in djipper detaillearre ûnderdompeling.
De kanonike SDLC is heul detaillearre yn ferskate metoaden - OpenSAMM, BSIMM, OWASP. De metoaden ferskille, mar binne oer it algemien fergelykber.
Bouwe Feiligens Yn Maturity Model
Ik fyn it it leukste BSIMM - . De basis fan 'e metodyk is de ferdieling fan it proses foar applikaasjefeiligens yn 4 domeinen: Bestjoer, yntelliginsje, SSDL Touchpoints en ynset. Elk domein hat 12 praktiken, dy't wurde fertsjintwurdige as 112 aktiviteiten.
Elk fan 'e 112 aktiviteiten hat 3 maturity nivo: begjinner, tuskenlizzende en avansearre. Jo kinne alle 12 praktiken yn seksjes studearje, dingen selektearje dy't wichtich binne foar jo, útfine hoe't jo se útfiere en stadichoan eleminten tafoegje, bygelyks statyske en dynamyske koade-analyze of koadebeoardieling. Jo meitsje in plan op en wurkje dêr rêstich nei as ûnderdiel fan de útfiering fan de selektearre aktiviteiten.
Wêrom DevSecOps
DevOps is in algemien grut proses wêryn feiligens moat wurde fersoarge.
earstoan belutsen feiligens kontrôles. Yn 'e praktyk wie it oantal befeiligingsteams folle lytser as no, en fungearren se net as dielnimmers oan it proses, mar as in kontrôle- en tafersjochorgaan dat der easken oan stelt en de kwaliteit fan it produkt kontrolearret oan' e ein fan 'e frijlitting. Dit is in klassike oanpak wêryn befeiligingsteams efter in muorre wiene fan ûntwikkeling en net meidie oan it proses.
It wichtichste probleem is dat ynformaasjefeiligens apart is fan ûntwikkeling. Meastal is dit in soarte fan IB-sirkwy en it befettet 2-3 grutte en djoere ark. Ien kear yn 'e seis moannen komt de boarnekoade of applikaasje om te testen, en ien kear yn't jier . Dit alles liedt ta it feit dat de release dates foar de yndustry wurde útsteld, en in grut oantal kwetsberens fan automatisearre ark falle út op de ûntwikkelder. It is ûnmooglik om dit alles te demontearjen en te reparearjen, om't sels yn 'e foargeande seis moannen de resultaten net waarden ûntmantele, en hjir is in nije partij.
Yn 'e rin fan it wurk fan ús bedriuw sjogge wy dat feiligens yn alle gebieten en yndustry begrypt dat it tiid is om de ûntwikkeling yn ien tsjil yn te heljen en te spinnen - yn . It DevSecOps-paradigma past perfekt yn agile ûntwikkelingsmetodology, ymplemintaasje, stipe en dielname oan elke release en iteraasje.
Oergong nei DevSecOps
It wichtichste wurd yn 'e Lifecycle fan Feiligensûntwikkeling is "proses". Jo moatte dit begripe foardat jo tinke oer it keapjen fan ark.
It opnimmen fan ark yn it DevOps-proses is net genôch - kommunikaasje en begryp tusken proses-dielnimmers is wichtich.
Minsken binne wichtiger as ark
Faak begjint it plannen fan in feilich ûntwikkelingsproses mei it kiezen en keapjen fan in ark, en einiget mei besykjen om it ark te yntegrearjen yn it hjoeddeistige proses, dy't besykjen bliuwe. Dit liedt ta tryste gefolgen, om't alle ark har eigen skaaimerken en beheiningen hawwe.
In gewoan gefal is as de feiligensôfdieling in goed, djoer ark keas mei in breed oanbod fan funksjes en kaam by de ûntwikkelders om it yn it proses te bouwen. Mar it wurket net - it proses is ûntwurpen op sa'n manier dat de beheinings fan in al kocht ynstrumint net passe yn it hjoeddeiske paradigma.
Beskriuw earst hokker resultaat jo wolle en hoe't it proses der útsjen sil. Dit sil helpe om de rollen fan it ark en feiligens yn it proses te begripen.
Begjin mei wat al yn gebrûk is
Foardat jo djoere ark keapje, sjoch nei wat jo al hawwe. Elk bedriuw hat feiligenseasken dy't jilde foar ûntwikkeling, d'r binne kontrôles, penetraasjetests - wêrom dit alles net omsette yn in begryplike en handige foarm foar elkenien?
Meastal binne de easken in papieren Talmoed dy't op in planke leit. D'r wie in gefal doe't wy nei it bedriuw komme om de prosessen te besjen en har te freegjen om de feiligenseasken foar de software te sjen. De spesjalist dy't dit die, socht in lange tiid:
- No, earne yn 'e oantekeningen wie in paad dêr't dit dokumint leit.
Dêrtroch krigen wy it dokumint in wike letter.
Foar easken, kontrôles en mear, meitsje in side, bygelyks by Konfluinsje - it is handich foar elkenien.
It is makliker om te formatterjen wat der al is en it te brûken om te begjinnen.
Brûk Security Champions
Normaal, yn in trochsneed bedriuw foar 100-200 ûntwikkelders is d'r ien befeiligingsoffisier dy't ferskate funksjes útfiert en fysyk gjin tiid hat om alles te kontrolearjen. Sels as hy syn bêst besiket, sil hy allinich net alle koade kontrolearje dy't de ûntwikkeling genereart. Foar sokke gefallen is in konsept ûntwikkele - .
Security Champions is in persoan binnen it ûntwikkelingsteam dy't ynteressearre is yn 'e feiligens fan jo produkt.
Feiligenskampioen is in yngongspunt foar it ûntwikkelingsteam en in feiligensevangelist allegear yn ien rôle.
Gewoanlik, as in befeiligingsoffisier nei it ûntwikkelteam komt en in flater yn 'e koade wiist, krijt hy in ferrast antwurd:
- En wa bisto? Ik sjoch dy foar it earst. Alles is goed mei my - myn senior freon sette "oanfreegje" op 'e koadebeoardieling, wy geane troch!
Dit is in typyske situaasje, om't d'r folle mear fertrouwen is yn senioaren of gewoan teamgenoaten mei wa't de ûntwikkelder konstant ynteraksje op it wurk en yn koadebeoardieling. As de Feiligenskampioen ynstee fan in befeiliger de flater en de gefolgen wiist, dan sil syn wurd mear gewicht hawwe.
Ek, ûntwikkelders kenne harren koade better as hokker feiligens guy. Foar in persoan dy't op syn minst 5 projekten hat yn in statyske analyse-ark, is it normaal lestich om alle nuânses te ûnthâlden. Feiligenskampioenen kenne har produkt: wat ynteraksje mei wat en wat te sjen op it earste plak - se binne effisjinter.
Tink derom om Security Champions út te fieren en de ynfloed fan it feiligensteam út te wreidzjen. Foar de kampioen sels is dit ek nuttich: profesjonele ûntwikkeling yn in nij fjild, útwreidzjen fan de technyske horizonten, pompen technyske, bestjoerlike en liederskip feardichheden, tanimmende merkwearde. Dit is wat elemint fan sosjale engineering, jo "eagen" yn it ûntwikkelingsteam.
Teststadia
seit dat 20% fan de ynspannings jout 80% fan de resultaten. Dizze 20% binne praktiken foar applikaasjeanalyse dy't kinne en moatte wurde automatisearre. Foarbylden fan sokke aktiviteiten binne statyske analyze - SAST, dynamyske analyze - DAST и iepen boarne kontrôle. Ik sil jo mear fertelle oer aktiviteiten, lykas oer ark, hokker funksjes wy meastentiids tsjinkomme as se yn it proses wurde yntrodusearre, en hoe it goed te dwaan.
Main ark problemen
Ik sil de problemen markearje dy't relevant binne foar alle ynstruminten dy't omtinken freegje. Ik sil se yn mear detail analysearje om net fierder te herheljen.
Lange analyze tiid. As it 30 minuten duorret foar alle testen en gearstalling fan tawijing oant frijlitting foar produksje, dan sille kontrôles foar ynformaasjefeiligens in dei duorje. Dus gjinien sil it proses fertrage. Beskôgje dizze funksje en meitsje konklúzjes.
Heech falsk negatyf of falsk posityf. Alle produkten binne oars, allegear brûke ferskillende kaders en har eigen kodearringstyl. Op ferskate koadebasen en technologyen kinne ark ferskate nivo's fan falsk negatyf en falsk posityf sjen litte. Dus sjoch wat der yn sit dyn bedriuwen en foar dyn applikaasjes sille in goed en betrouber resultaat sjen litte.
Gjin yntegraasjes mei besteande ark. Sjoch nei de ark yn termen fan yntegraasjes mei wat jo al brûke. As jo bygelyks Jenkins of TeamCity hawwe, kontrolearje dan de yntegraasje fan ark mei dizze software, en net mei GitLab CI, dy't jo net brûke.
Gebrek of oermjittige kompleksiteit fan maatwurk. As it ark gjin API hat, wêrom is it dan nedich? Alles dat kin wurde dien yn 'e ynterface moat beskikber wêze fia de API. Ideal moat it ark de mooglikheid hawwe om kontrôles oan te passen.
Gjin roadmap foar produktûntwikkeling. Untwikkeling stiet net stil, wy brûke altyd nije kaders en funksjes, skriuwe âlde koade oer yn nije talen. Wy wolle derfoar soargje dat it ark dat wy keapje nije kaders en technologyen sil stypje. Dêrom is it wichtich om te witten dat it produkt in echte en korrekte hat ûntwikkeling.
Process features
Njonken de funksjes fan 'e ark, beskôgje de funksjes fan it ûntwikkelingsproses. Bygelyks, interfering mei ûntwikkeling is in typyske flater. Litte wy sjen hokker oare funksjes moatte wurde beskôge en wêrop it befeiligingsteam omtinken moat jaan.
Om de ûntwikkeling net te fersteuren en deadlines frij te meitsjen, meitsje ferskillende regels en oars show stoppers - kritearia foar it stopjen fan it bouproses yn 'e oanwêzigens fan kwetsberens - foar ferskate omjouwings. Wy begripe bygelyks dat de hjoeddeistige branch nei in ûntwikkelingsstand of UAT giet, dus stopje wy net en sizze:
- Jo hawwe hjir kwetsberens, jo sille net fierder gean!
Op dit punt is it wichtich om ûntwikkelders te fertellen dat d'r feiligensproblemen binne om út te sjen.
De oanwêzigens fan kwetsberens is gjin barriêre foar fierdere testen: hânlieding, yntegraasje of hânlieding. Oan 'e oare kant moatte wy op ien of oare manier de feiligens fan it produkt ferbetterje, en sadat de ûntwikkelders net skoare op wat de feiligens fynt. Dêrom dogge wy dit soms: by de stand, as it útrolt nei de ûntwikkelingsomjouwing, melde wy gewoan de ûntwikkeling:
- Jonges, jo hawwe problemen, sjoch der asjebleaft op.
Op it UAT-stadium litte wy wer warskôgingen sjen oer kwetsberens, en by it útgongsstadium yn 'e prom sizze wy:
"Jongens, wy hawwe jo ferskate kearen warskôge, jo hawwe neat dien - wy litte jo hjirmei net útlitte.
As wy prate oer koade en dynamyk, dan is it nedich om te sjen en warskôgje oer kwetsberens allinnich fan dy funksjes en koade dy't krekt skreaun yn dizze funksje. As de ûntwikkelder de knop mei 3 piksels ferpleatst en wy fertelle him dat hy dêr in SQL-ynjeksje hat en dêrom driuwend reparearre moat, is dit ferkeard. Sjoch allinnich nei wat der no skreaun is, en nei de feroaring dy't by de oanfraach komt.
Litte wy sizze dat wy wat funksjoneel defekt hawwe - de manier wêrop de applikaasje net moat wurkje: jild wurdt net oerdroegen, as jo op de knop klikke, is d'r gjin oergong nei de folgjende side, of it produkt wurdt net laden. Feiligens Defects - dit binne deselde defekten, mar net yn 'e kontekst fan' e applikaasje, mar feiligens.
Net alle problemen mei softwarekwaliteit binne feiligensproblemen. Mar alle feiligensproblemen binne relatearre oan de kwaliteit fan 'e software. Sherif Mansour, Expedia.
Om't alle kwetsberens deselde defekten binne, moatte se op itselde plak lizze as alle ûntwikkelingsdefekten. Ferjit dus rapporten en enge PDF's dy't gjinien lêst.
Doe't ik wurke foar in ûntwikkeling bedriuw, Ik krige in rapport fan statyske analyse ark. Ik die iepen, waard kjel, makke kofje, blêdde troch 350 siden, die ticht en gie oan it wurk. Grutte rapporten binne deade rapporten. Normaal geane se nergens hinne, e-mails wurde wiske, fergetten, ferlern, of it bedriuw seit dat it risiko's nimt.
Wat te dwaan? Wy konvertearje gewoan de befêstige defekten dy't wy fûnen yn in foarm dy't handich is foar ûntwikkeling, foegje it bygelyks ta oan 'e efterstân yn Jira. Defekten wurde prioritearre en elimineare yn folchoarder fan prioriteit tegearre mei funksjonele defekten en testdefekten.
Statyske analyze - SAST
Dit is koade-analyze foar kwetsberens., mar it is net itselde as SonarQube. Wy kontrolearje net allinich foar patroanen of styl. De analyze brûkt in oantal oanpakken: troch kwetsberensbeam, troch , troch it analysearjen fan konfiguraasjebestannen. Dat is alles foar de koade sels.
Pros fan de oanpak: identifisearje kwetsberens yn koade op in ier stadium fan ûntwikkelingas der gjin stands en ready-made ark, en inkrementele scan mooglikheid: scant in seksje fan koade dy't feroare is, en allinich de funksje dy't wy op it stuit dogge, wat de scantiid ferminderet.
Минусы is it gebrek oan stipe foar de fereaske talen.
Fereaske yntegraasjes, dat moat wêze yn 'e ark, yn myn subjektive miening:
- Yntegraasje-ark: Jenkins, TeamCity en Gitlab CI.
- Untwikkelingsomjouwing: Intellij IDEA, Visual Studio. It is handiger foar in ûntwikkelder om net te klimmen yn in ûnbegryplike ynterface dy't noch moat wurde ûnthâlden, mar om alle nedige yntegraasjes en kwetsberens te sjen dy't hy direkt op 'e wurkflier fûn hat yn syn eigen ûntwikkelingsomjouwing.
- Koade beoardieling: SonarQube en hânmjittich beoardieling.
- Defekt trackers: Jira en Bugzilla.
De foto toant guon fan 'e bêste fertsjintwurdigers fan statyske analyze.
It binne net de ark dat fan belang is, mar it proses, dus d'r binne Open Source-oplossingen dy't ek goed binne foar it útfieren fan it proses.
SAST Open Source sil gjin enoarm oantal kwetsberens of komplekse DataFlow fine, mar se kinne en moatte wurde brûkt by it bouwen fan in proses. Se helpe om te begripen hoe't it proses sil wurde boud, wa sil reagearje op bugs, wa sil rapportearje, wa sil rapportearje. As jo de earste faze fan it bouwen fan 'e feiligens fan jo koade wolle útfiere, brûk dan Open Source-oplossingen.
Hoe kin dit wurde yntegrearre as jo binne oan it begjin fan 'e reis, do hast neat: noch CI, noch Jenkins, noch TeamCity? Tink oan proses yntegraasje.
Yntegraasje op it CVS-nivo
As jo Bitbucket of GitLab hawwe, kinne jo yntegraasje dwaan op it nivo .
By evenemint pull fersyk, commit. Jo scannen de koade en litte sjen yn 'e buildstatus dat de feiligenskontrôle trochjûn of mislearre is.
Feedback. Fansels is feedback altyd nedich. As jo it gewoan dien hawwe oan 'e feiligenskant, set it yn in doaze en fertelde gjinien neat oer it, en dan dumpte in bosk bugs oan' e ein fan 'e moanne, dit is net rjocht en net goed.
Yntegraasje mei koade review systeem
Ienris hawwe wy de technyske brûker fan AppSec ynsteld as de standertresinsint yn in oantal wichtige projekten. Ofhinklik fan oft flaters fûn binne yn 'e nije koade of der binne gjin flaters, set de resinsint de status op it pull-fersyk om "akseptearje" of "wurk nedich" - of alles is OK, of jo moatte finalisearje en keppelje nei wat krekt te finalisearjen. Foar yntegraasje mei de ferzje dy't wurdt frijlitten, hawwe wy fúzje útskeakele as de IS-test net trochjûn is. Wy opnommen dit yn 'e hânlieding koade review, en de rest fan it proses dielnimmers seagen de feiligens statuses foar dit bysûndere proses.
Yntegraasje mei SonarQube
In protte hawwe yn termen fan koade kwaliteit. It is hjir itselde - jo kinne deselde poarten allinich meitsje foar SAST-ynstruminten. D'r sil deselde ynterface wêze, deselde kwaliteitspoarte, allinich sil it wurde neamd feiligens poarte. En ek, as jo in proses hawwe ynsteld mei SonarQube, kinne jo alles dêr maklik yntegrearje.
Yntegraasje op it CI-nivo
Ek hjir is alles frij simpel:
- Op par mei autotests, ienheid tests.
- Ferdieling troch ûntwikkelingsstadia: dev, test, prod. Ferskillende sets fan regels kinne wurde opnommen, of ferskillende falen betingsten: wy stopje de gearkomste, wy stopje de gearkomste net.
- Syngroane / asynchrone start. Wy wachtsje op it ein fan 'e feiligenstests of wy wachtsje net. Dat is, wy hawwe se gewoan lansearre en trochgean, en dan krije wy in status dat alles goed of min is.
It is allegear yn in perfekte rôze wrâld. Yn it echte libben is dit net it gefal, mar wy stribje. It resultaat fan it útfieren fan feiligenskontrôles moat fergelykber wêze mei de resultaten fan ienheidstests.
Wy namen bygelyks in grut projekt en besletten dat wy it no sille scannen mei SAST - OK. Wy skowe dit projekt yn SAST, it joech ús 20 kwetsberens, en wy hawwe in sterke wil makke dat alles goed is. 000 kwetsberens is ús technyske skuld. Wy sille de skuld yn in doaze pleatse, wy sille it stadichoan ophelje en bugs begjinne yn defekt trackers. Hire in bedriuw, doch alles sels, of lit Security Champions ús helpe, en technyske skuld sil ôfnimme.
En alle nij ferskinende kwetsberens yn 'e nije koade moatte wurde elimineare op deselde manier as flaters yn in ienheid as yn autotests. Relatyf sjoen begûn de gearstalling, ried fuort, twa tests en twa befeiligingstests foelen del. OK - wy gongen, seagen wat der barde, korrizjearre ien, korrizjearre de twadde, rieden de folgjende kear - alles is goed, gjin nije kwetsberens binne ferskynd, de tests binne net mislearre. As dizze taak djipper is en jo moatte it goed begripe, of it reparearjen fan kwetsberens beynfloedet grutte lagen fan wat ûnder de motorkap leit: in brek wurdt yn 'e defekt tracker brocht, wurdt it prioritearre en fêststeld. Spitigernôch is de wrâld net perfekt en tests mislearje soms.
In foarbyld fan in feiligenspoarte is in analoog fan in kwaliteitspoarte, yn termen fan 'e oanwêzigens en oantal kwetsberens yn' e koade.
Wy yntegrearje mei SonarQube - de plugin is ynstalleare, alles is heul handich en cool.
Yntegraasje fan ûntwikkelingsomjouwing
Yntegraasje opsjes:
- In scan begjinne fan 'e ûntwikkelingsomjouwing sels foar de commit.
- Besjoch resultaten.
- Analyse fan resultaten.
- Syngronisaasje mei de tsjinner.
Dit is hoe't it útsjen fan resultaten fan 'e tsjinner.
Yn ús ûntwikkelingsomjouwing it ferskynt gewoan in ekstra item dat seit dat sokke kwetsberens waarden fûn tidens de scan. Jo kinne fuortendaliks bewurkje de koade, sjoch oanbefellings en . Dit alles leit op it wurkplak fan 'e ûntwikkelder, wat heul handich is - jo hoege de rest fan' e keppelings net te folgjen en wat ekstra te sjen.
Open Source
Dit is myn favorite ûnderwerp. Elkenien brûkt Open Source-biblioteken - wêrom in boskje krukken en fytsen skriuwe as jo in klearmakke bibleteek kinne nimme wêryn alles al ymplementearre is?
Fansels, dit is wier, mar biblioteken wurde ek skreaun troch minsken, ek befetsje bepaalde risiko 's, en der binne ek kwetsberens dy't periodyk, of hieltyd, rapportearre. Dêrom is d'r in folgjende stap yn Application Security - dit is de analyze fan Open Source-komponinten.
Open Source Analysis - OSA
It ark omfettet trije wichtige stappen.
It finen fan kwetsberens yn biblioteken. Bygelyks, it ark wit dat wy in soarte fan bibleteek brûke, en dat yn of yn bug trackers binne d'r wat kwetsberens dy't relatearje oan dizze ferzje fan 'e bibleteek. As jo besykje it te brûken, sil it ark jo warskôgje dat de bibleteek kwetsber is en jo advisearje om in oare ferzje te brûken wêr't gjin kwetsberens binne.
Analyse fan lisinsje suverens. Dit is noch net heul populêr by ús, mar as jo wurkje mei in frjemd lân, dan kinne jo dêr periodyk in oanfal krije foar it brûken fan in iepen boarne-komponint dy't net brûkt of wizige wurde kin. Neffens it belied fan de fergunningbibleteek kinne wy dit net dwaan. Of, as wy it hawwe wizige en brûke, moatte wy ús koade pleatse. Fansels wol gjinien de koade fan har produkten pleatse, mar jo kinne jo sels hjirmei beskermje.
Analyse fan komponinten dy't brûkt wurde yn in yndustriële omjouwing. Stel jo in hypotetyske situaasje foar dat wy de ûntwikkeling einlings hawwe foltôge en de lêste release fan ús mikrotsjinst frijlitten oan 'e yndustry. Hy wennet dêr prachtich - in wike, in moanne, in jier. Wy sammelje it net, wy dogge gjin feiligenskontrôles, alles liket goed te wêzen. Mar ynienen, twa wiken nei de frijlitting, komt in krityske kwetsberens yn 'e Open Source-komponint út, dy't wy brûke yn dizze bepaalde gearkomste, yn' e yndustriële omjouwing. As wy net opnimme wat en wêr't wy brûke, dan sil dizze kwetsberens gewoan net sjoen wurde. Guon ark hawwe de mooglikheid om kwetsberens te kontrolearjen yn biblioteken dy't op it stuit brûkt wurde yn prom. It is tige brûkber.
Features:
- Ferskillende belied foar ferskate stadia fan ûntwikkeling.
- Monitor komponinten yn in yndustriële omjouwing.
- Kontrôle fan biblioteken yn 'e kontoeren fan' e organisaasje.
- Stipe foar ferskate bouwsystemen en talen.
- Analyse fan Docker-ôfbyldings.
In pear foarbylden fan lieders op it fjild dy't dwaande binne mei de analyze fan Open Source.
De ienige frije is fan OWASP. Jo kinne it yn 'e earste stadia ynskeakelje, sjen hoe't it wurket en wat it stipet. Yn prinsipe binne dit allegear wolkprodukten, of on-premise, mar efter har basis gean se noch nei it ynternet. Se stjoere jo biblioteken net, mar hashes as har wearden dy't se berekkenje, en fingerprinten nei har server om nijs te ûntfangen oer de oanwêzigens fan kwetsberens.
Proses Yntegraasje
Perimeter bibleteek kontrôledy't wurde ynladen fan eksterne boarnen. Wy hawwe eksterne en ynterne repositories. Wy hawwe bygelyks Nexus binnen Event Central, en wy wolle derfoar soargje dat d'r gjin kwetsberens binne mei in "krityske" of "hege" status yn ús repository. Jo kinne proxying ynstelle mei it Nexus Firewall Lifecycle-ark, sadat sokke kwetsberens wurde ôfsnien en net opnommen yn it ynterne repository.
CI yntegraasje. Op itselde nivo mei autotests, ienheidstests en ferdieling yn ûntwikkelingsstadia: dev, test, prod. Op elke poadium kinne jo alle biblioteken downloade, alles brûke, mar as d'r wat dreech is mei de "krityske" status, moatte jo wierskynlik de oandacht fan ûntwikkelders hjirop lûke op it poadium fan it yngean fan 'e prom.
Artefakt yntegraasje: Nexus en JFrog.
Yntegraasje yn 'e ûntwikkelingsomjouwing. De ark dy't jo kieze moatte yntegraasje hawwe mei ûntwikkelingsomjouwings. De ûntwikkelder moat tagong hawwe ta de scanresultaten fan syn wurkplak, of de mooglikheid om de koade te scannen en te kontrolearjen op kwetsberens foardat hy it yn CVS ynsette.
CD yntegraasje. Dit is in koele funksje dy't ik echt leuk fyn en wêr't ik al oer praat haw - it kontrolearjen fan it ûntstean fan nije kwetsberens yn in yndustriële omjouwing. It wurket sa.
Wy hawwe Publike Component Repositories - guon ark bûten, en ús ynterne repository. Wy wolle dat der allinnich fertroude komponinten yn sitte. By it proxysjen fan in fersyk kontrolearje wy dat de ynladen bibleteek gjin kwetsberens hat. As it falt ûnder bepaalde beliedslinen dy't wy ynstelle en needsaaklik koördinearje mei de ûntwikkeling, dan uploade wy it net en in ôfwiking komt om in oare ferzje te brûken. Dêrom, as d'r wat echt kritysk en min is yn 'e bibleteek, dan sil de ûntwikkelder de bibleteek net ûntfange, sels yn it ynstallaasjestadium - lit him in ferzje heger as leger brûke.
- By it bouwen kontrolearje wy dat gjinien wat min glide, dat alle komponinten feilich binne en gjinien wat gefaarlik op 'e flash drive brocht.
- Wy hawwe allinich fertroude komponinten yn 'e repository.
- By it ynsetten kontrolearje wy it pakket sels nochris: war, jar, DL of Docker-ôfbylding op it feit dat it foldocht oan it belied.
- By it ynfieren fan 'e yndustriële omjouwing kontrolearje wy wat der bart yn' e yndustriële omjouwing: krityske kwetsberens ferskine of ferskine net.
Dynamic Analysis - DAST
Tools foar dynamyske analyse binne fûneminteel oars as alles dat earder is sein. Dit is in soarte fan imitaasje fan it wurk fan de brûker mei de applikaasje. As dit in webapplikaasje is, stjoere wy fersiken dy't it wurk fan 'e kliïnt imitearje, klikje op 'e knoppen oan' e foarkant, ferstjoere keunstmjittige gegevens út it formulier: quotes, heakjes, karakters yn ferskate kodearrings om te sjen hoe't de applikaasje wurket en eksterne ferwurket data.
Itselde systeem lit jo kontrolearje op sjabloan-kwetsberheden yn Open Source. Sûnt DAST net wit hokker Open Source wy brûke, smyt it gewoan "kwaadwillige" patroanen en analysearret de antwurden fan 'e server:
- Ja, hjir is in deserialisaasjeprobleem, mar hjir net.
D'r sitte grutte risiko's yn, want as jo dizze befeiligingstest útfiere op deselde tribune dêr't de testers mei wurkje, kinne ûnnoflike dingen barre.
- Hege lading op it netwurk fan 'e applikaasjetsjinner.
- Gjin yntegraasjes.
- De mooglikheid om de ynstellingen fan 'e analysearre applikaasje te feroarjen.
- D'r is gjin stipe foar de nedige technologyen.
- Swierrichheid fan ynstelling.
Wy hienen in situaasje doe't wy einlings AppScan lansearren: wy sloegen de tagong ta de applikaasje foar in lange tiid út, krigen 3 akkounts en wiene bliid - úteinlik sille wy alles kontrolearje! Wy lansearren in scan, en it earste wat AppScan die wie yn it adminpaniel te kommen, alle knoppen troch te stekken, de helte fan 'e gegevens te feroarjen, en dan de tsjinner hielendal te deadzjen mei syn eigen -oanfragen. Untwikkeling mei testen sei:
"Jongens, meitsje jim in grapke?! Wy joegen jo akkounts, en jo sette de stand!
Tink oan mooglike risiko's. Ideaallik, meitsje in aparte stand foar testen fan ynformaasjefeiligens, dy't op syn minst ien of oare manier isolearre sil wêze fan 'e rest fan' e omjouwing, en kontrolearje it adminpaniel ûnder betingst, by foarkar yn 'e hânmodus. Dit is in pentest - dy oerbleaune persintaazjes fan ynspanningen dy't wy no net beskôgje.
It is it wurdich te beskôgjen dat jo dit kinne brûke as in analoog fan loadtesten. Op it earste poadium kinne jo de dynamyske scanner yn 10-15 triedden ynskeakelje en sjen wat der bart, mar meastentiids, lykas de praktyk docht bliken, neat goed.
In pear boarnen dy't wy normaal brûke.
De moeite waard om te markearjen is it "Switserske mes" foar elke feiligens professional. Elkenien brûkt it en it is heul handich. In nije demo-ferzje fan 'e Enterprise-edysje is no frijlitten. As it earder gewoan in stand-alone hulpprogramma wie mei plugins, meitsje no ûntwikkelders einlings in grutte server wêrfan it mooglik is om ferskate aginten te behearjen. It is cool, ik riede oan dat jo it besykje.
Proses Yntegraasje
De yntegraasje is aardich goed en ienfâldich: start scan nei suksesfolle ynstallaasje applikaasjes op 'e tribune en skennen nei suksesfolle yntegraasjetesten.
As de yntegraasjes net wurkje of d'r binne stubs en spotfunksjes, is it sinleas en nutteloos - nettsjinsteande hokker patroan wy stjoere, de tsjinner sil noch altyd op deselde manier reagearje.
- Ideal, in aparte testbank.
- Foardat jo testen, skriuw de oanmeldingsekwinsje op.
- Testen fan it administraasjesysteem is allinich hânmjittich.
proses
In bytsje generalisearre oer it proses yn it algemien en oer it wurk fan elk ark, yn it bysûnder. Alle applikaasjes binne oars - ien wurket better mei dynamyske analyze, in oar mei statyske analyze, de tredde mei OpenSource-analyse, pentests, of wat oars yn it algemien, bygelyks eveneminten mei .
Elk proses moat wurde kontrolearre.
Om te begripen hoe't it proses wurket en wêr't it kin wurde ferbettere, moatte jo metriken sammelje fan alles wêr't jo jo hannen op kinne krije, ynklusyf produksjemetriken, metriken fan ark en defekt trackers.
Elke ynformaasje is nuttich. It is needsaaklik om te sjen yn ferskate seksjes wêr't dit of dat ark better brûkt wurdt, wêr't it proses spesifyk sakket. It kin de muoite wurdich wêze om te sjen nei de reaksjetiid fan ûntwikkeling om te sjen wêr't it proses op basis fan tiid kin ferbetterje. Hoe mear gegevens, hoe mear besunigings kinne wurde boud fan it boppeste nivo nei de details fan elk proses.
Om't alle statyske en dynamyske analysatoren har eigen API's hawwe, har eigen startmetoaden, prinsipes, guon hawwe planners, oaren net - wy skriuwe in ark AppSec Orchestrator, wêrmei jo in inkele yngongspunt meitsje kinne foar it heule proses fan it produkt en it fan ien punt beheare.
Behearders, ûntwikkelders en feiligensingenieurs hawwe ien yngongspunt wêrfan se kinne sjen wat der rint, scans konfigurearje en útfiere, scanresultaten krije en easken yntsjinje. Wy besykje fuort te gean fan stikken papier, alles oersette yn in minsklike ien dy't ûntwikkeling brûkt - siden oer Confluence mei status en metriken, defekten yn Jira of yn ferskate defekttrackers, of ynbêde yn in syngroane / asynchrone proses yn CI / CD.
Key Takeaways
De ark makket neat út. Tink earst oer it proses, implementearje dan de ark. De ark binne goed, mar djoer, dus jo kinne begjinne mei it proses en fine-tune de ynteraksje en begryp tusken ûntwikkeling en feiligens. Fanút it eachpunt fan feiligens is d'r gjin need om alles op in rige te "stoppen. Ut it eachpunt fan ûntwikkeling, as der wat heech mega super kritysk is, dan moat dit elimineare wurde, en net sletten foar it probleem .
Produkt kwaliteit - mienskiplik doel sawol feiligens as ûntwikkeling. Wy dogge ien ding, wy besykje te soargjen dat alles goed wurket en dat der gjin reputaasjerisiko's en finansjele ferliezen binne. Dêrom befoarderje wy de oanpak fan DevSecOps, SecDevOps om kommunikaasje te fêstigjen en it produkt better te meitsjen.
Begjin mei wat der al is: easken, arsjitektuer, parsjele kontrôles, trainingen, rjochtlinen. It is net nedich om alle praktiken fuortendaliks op alle projekten te passen - iteratyf bewegen. Der is gjin inkele standert eksperimint en besykje ferskate oanpakken en oplossingen.
Gelyk teken tusken IS-defekten en funksjonele defekten.
Automatisearje allesdat beweecht. Alles dat net beweecht, ferpleatst en automatisearret. As der wat mei de hân dien wurdt, is dit gjin goed diel fan it proses. Miskien is it de muoite wurdich om it ek wer te besjen en te automatisearjen.
As de grutte fan it IB-team lyts is - brûke Security Champions.
Miskien sil wêr't ik it oer haw net by jo past en komme jo mei wat fan jo eigen - en dat is goed. Mar kies ark basearre op de easken fan jo proses. Sjoch net nei wat de mienskip seit dat dit ark min is en dit goed is. Miskien sil it oarsom wêze op jo produkt.
Tool easken.
- Low False Posityf.
- Adekwate analyze tiid.
- It gemak fan gebrûk.
- Beskikberens fan yntegraasjes.
- Begryp fan 'e roadmap fan produktûntwikkeling.
- Mooglikheid om ark oan te passen.
Yuriy's rapport waard keazen as ien fan 'e bêste by DevOpsConf 2018. Om yn 'e kunde te kommen mei noch mear nijsgjirrige ideeën en praktyske gefallen, kom nei Skolkovo op 27 en 28 maaie binnen . Noch better, as jo ree binne om jo ûnderfining te dielen, dan Jou jo ferslach yn foar 21 april.
Boarne: www.habr.com