Meil oli 2 koodianalüsaatorit, 4 dünaamilise testimise tööriista, oma käsitööd ja 250 skripti. Mitte, et seda kõike praeguses protsessis vaja oleks olnud, kuid kui olete DevSecOpsi juurutama hakanud, peate minema lõpuni.
. Justin Roilandi ja Dan Harmoni loodud tegelased.
Mis on SecDevOps? Aga DevSecOps? Millised on erinevused? Rakenduste turvalisus – mis see on? Miks klassikaline lähenemine enam ei tööta? Kõik need küsimused teavad vastust Juri Šabalin kohta Mõõkkala turvalisus. Juri vastab kõigele üksikasjalikult ja analüüsib klassikaliselt rakenduseturbe mudelilt DevSecOpsi protsessile ülemineku probleeme: kuidas õigesti läheneda turvalise arendusprotsessi integreerimisele DevOpsi protsessi ja mitte midagi rikkuda, kuidas läbida peamised etapid. turvatestide kohta, milliseid tööriistu saab kasutada, kuidas need erinevad ja kuidas neid õigesti konfigureerida, et vältida lõkse.
Kõlari kohta: Juri Šabalin - Ettevõtte turvaarhitekt Mõõkkala turvalisus. Vastutab SSDL juurutamise eest, rakenduste analüüsi tööriistade üldise integreerimise eest ühtsesse arendus- ja testimisökosüsteemi. 7-aastane kogemus infoturbe vallas. Töötanud Alfa-Bankis, Sberbankis ja Positive Technologiesis, mis arendab tarkvara ja osutab teenuseid. Rahvusvaheliste konverentside ZerONights, PHDays, RISSPA, OWASP esineja.
Rakenduse turvalisus: mis see on?
Rakenduse turvalisus on turbeosa, mis vastutab rakenduse turvalisuse eest. See ei puuduta infrastruktuuri ega võrgu turvalisust, vaid seda, mida me kirjutame ja mille kallal arendajad töötavad – need on rakenduse enda vead ja haavatavused.
suund - Turvalisuse arendamise elutsükkel - Microsofti poolt välja töötatud. Diagramm näitab kanoonilist SDLC mudelit, mille peamiseks ülesandeks on turvalisuse osalemine igas arendusetapis alates nõuetest kuni vabastamiseni ja vabastamiseni tootmiseni. Microsoft mõistis, et ballis on liiga palju vigu, neid on rohkem ja sellega on vaja midagi ette võtta ning nad pakkusid välja selle lähenemisviisi, mis muutus kanooniliseks.
Rakenduste turvalisuse ja SSDL-i eesmärk ei ole turvaaukude tuvastamine, nagu tavaliselt arvatakse, vaid nende esinemise ärahoidmine. Aja jooksul on Microsofti kanoonilist lähenemist täiustatud, arendatud, selles on sügavam üksikasjalik keelekümblus.
Kanooniline SDLC on erinevates metoodikates – OpenSAMM, BSIMM, OWASP – väga detailne. Metoodikad on erinevad, kuid üldiselt sarnased.
Ehituse turvalisuse mudel
Mulle meeldib see kõige rohkem BSIMM - . Metoodika aluseks on rakenduste turbe protsessi jagamine 4 domeeniks: juhtimine, luure, SSDL puutepunktid ja juurutamine. Igal domeenil on 12 praktikat, mis on esindatud 112 tegevusena.
Kõik 112 tegevust on 3 küpsusastet: algajad, keskmised ja edasijõudnud. Saate uurida kõiki 12 praktikat jaotiste kaupa, valida enda jaoks olulisi asju, mõelda, kuidas neid rakendada ja järk-järgult lisada elemente, näiteks staatiline ja dünaamiline koodianalüüs või koodi ülevaatus. Koostad plaani ja töötad selle järgi rahulikult valitud tegevuste elluviimise raames.
Miks DevSecOps
DevOps on üldiselt suur protsess, mille käigus tuleb turvalisuse eest hoolt kanda.
Esialgu hõlmas turvakontrolli. Praktikas oli turvameeskondade arv palju väiksem kui praegu ja nad ei tegutsenud protsessis osalejatena, vaid kontroll- ja järelevalveorganina, kes esitab sellele nõudmisi ja kontrollib toote kvaliteeti väljalaske lõpus. See on klassikaline lähenemine, kus turvameeskonnad olid arendusest seina taga ega osalenud protsessis.
Peamine probleem seisneb selles, et infoturve on arendusest lahus. Tavaliselt on see mingi IB-ahel ja see sisaldab 2-3 suurt ja kallist tööriista. Kord kuue kuu jooksul saabub lähtekood või rakendus testimiseks ja kord aastas . Kõik see toob kaasa asjaolu, et tööstuse väljalaskekuupäevi lükatakse edasi ja arendajale langeb tohutu hulk automatiseeritud tööriistade haavatavusi. Seda kõike on võimatu lahti võtta ja parandada, sest isegi eelmisel poolaastal ei võetud tulemusi lahti ja siin on uus partii.
Oma ettevõtte töö käigus näeme, et turvalisus kõigis valdkondades ja tööstusharudes mõistab, et on aeg jõuda järele ja keerutada arengule ühes rattas – sisse . DevSecOpsi paradigma sobib suurepäraselt agiilse arendusmetoodika, juurutamise, toe ja osalemisega igas versioonis ja iteratsioonis.
Üleminek DevSecOpsile
Turvaarenduse elutsükli kõige olulisem sõna on "protsess". Enne tööriistade ostmist peate sellest aru saama.
Ainult tööriistade kaasamisest DevOpsi protsessi ei piisa – protsessis osalejate vaheline suhtlus ja mõistmine on oluline.
Inimesed on tähtsamad kui tööriistad
Sageli algab turvalise arendusprotsessi planeerimine tööriista valikust ja ostmisest ning lõpeb katsetega integreerida tööriist jooksvasse protsessi, mis jäävad katseteks. See toob kaasa kurbaid tagajärgi, sest kõigil tööriistadel on oma omadused ja piirangud.
Levinud juhtum on olukord, kus turvaosakond valis välja hea, kalli ja paljude funktsioonidega tööriista ning tuli arendajate juurde, et see protsessi sisse lülitada. Kuid see ei õnnestu - protsess on kavandatud nii, et juba ostetud instrumendi piirangud ei sobitu praeguse paradigmaga.
Kõigepealt kirjeldage, millist tulemust soovite ja kuidas protsess välja näeb. See aitab mõista tööriista ja turvalisuse rolli protsessis.
Alusta sellest, mis on juba kasutusel
Enne kallite tööriistade ostmist vaadake, mis teil juba on. Igal ettevõttel on arendusele kehtivad turvanõuded, on kontrollid, läbitungimistestid – miks mitte muuta see kõik kõigile arusaadavale ja mugavale vormile?
Tavaliselt on nõuded pabertalmud, mis lebab riiulil. Oli juhus, kui tuleme ettevõttesse protsesse vaatama ja palume näidata tarkvara turvanõudeid. Spetsialist, kes seda tegi, otsis pikka aega:
- Nüüd oli kuskil märkmetes tee, kus see dokument asub.
Selle tulemusena saime dokumendi nädal hiljem kätte.
Nõuete, kontrollide ja muu jaoks looge leht, näiteks aadressil Liitumiskoht - see on mugav kõigile.
Lihtsam on juba olemasolevat uuesti vormindada ja seda alustamiseks kasutada.
Kasutage turvatšempione
Tavaliselt on keskmises 100-200 arendaja ettevõttes üks turvatöötaja, kes täidab mitut funktsiooni ja kellel pole füüsiliselt aega kõike kontrollida. Isegi kui ta annab endast parima, ei kontrolli ta üksi kogu koodi, mida arendus genereerib. Selliste juhtumite jaoks on välja töötatud kontseptsioon - .
Turvatšempionid on arendusmeeskonna isik, kes on huvitatud teie toote turvalisusest.
Security Champion on arendusmeeskonna sisenemispunkt ja turvaevangelist.
Tavaliselt, kui turvatöötaja tuleb arendusmeeskonda ja juhib tähelepanu veale koodis, saab ta üllatunud vastuse:
- Ja kes sina oled? Näen sind esimest korda. Minuga on kõik korras - mu vanem sõber pani koodiülevaatusele “taotle” ja liigume edasi!
See on tüüpiline olukord, sest palju rohkem usaldatakse vanemaid või lihtsalt meeskonnakaaslasi, kellega arendaja tööl ja koodi ülevaatamisel pidevalt suhtleb. Kui turvamehe asemel veale ja tagajärgedele tähelepanu juhib Turvameister, siis on tema sõnal suurem kaal.
Samuti teavad arendajad oma koodi paremini kui ükski turvamees. Inimesel, kellel on staatilise analüüsi tööriistas vähemalt 5 projekti, on tavaliselt raske kõiki nüansse meelde jätta. Turvatšempionid tunnevad oma toodet: mis millega suhtleb ja mida kõigepealt vaadata – nad on tõhusamad.
Seega kaaluge Security Championsi rakendamist ja turvameeskonna mõju suurendamist. Ka meistrile endale on see kasulik: professionaalne areng uues valdkonnas, tehnilise silmaringi laiendamine, tehniliste, juhtimis- ja juhtimisoskuste pumpamine, turuväärtuse tõstmine. See on osa sotsiaalsest insenerist, teie "silmad" arendusmeeskonnas.
Testimise etapid
ütleb, et 20% pingutustest annab 80% tulemustest. Need 20% on rakendusanalüüsi praktikad, mida saab ja tuleks automatiseerida. Selliste tegevuste näideteks on staatiline analüüs − SAST, dünaamiline analüüs — DAST и avatud lähtekoodiga juhtimine. Räägin teile lähemalt tegevustest, samuti tööriistadest, milliste funktsioonidega me tavaliselt protsessi sisseviimisel kokku puutume ja kuidas seda õigesti teha.
Peamised tööriistaprobleemid
Toon välja probleemid, mis on olulised kõigi tähelepanu vajavate instrumentide puhul. Analüüsin neid üksikasjalikumalt, et mitte rohkem korrata.
Pikk analüüsiaeg. Kui kõigi testide ja montaaži jaoks kulub kohustusest vabastamiseni 30 minutit, siis infoturbe kontroll võtab aega päeva. Nii et keegi ei aeglusta protsessi. Mõelge sellele funktsioonile ja tehke järeldused.
Kõrge valenegatiivne või valepositiivne. Kõik tooted on erinevad, kõik kasutavad erinevaid raamistikke ja oma kodeerimisstiili. Erinevatel koodialustel ja tehnoloogiatel võivad tööriistad näidata erinevat valenegatiivse ja valepositiivse taseme taset. Nii et vaadake, mis sees on oma ettevõtetele ja oma rakendused näitavad head ja usaldusväärset tulemust.
Puuduvad integratsioonid olemasolevate tööriistadega. Vaadake tööriistu juba kasutatavate integratsioonide osas. Näiteks kui teil on Jenkins või TeamCity, kontrollige tööriistade integreerimist selle tarkvaraga, mitte GitLab CI-ga, mida te ei kasuta.
Kohandamise puudumine või liigne keerukus. Kui tööriistal pole API-d, siis milleks seda vaja on? Kõik, mida saab liideses teha, peaks olema API kaudu kättesaadav. Ideaalis peaks tööriistal olema võimalus kontrolle kohandada.
Tootearenduse tegevuskava puudub. Arendus ei seisa paigal, kasutame alati uusi raamistikke ja funktsioone, kirjutame vana koodi ümber uutesse keeltesse. Tahame olla kindlad, et ostetud tööriist toetab uusi raamistikke ja tehnoloogiaid. Seetõttu on oluline teada, et tootel on tõeline ja õige arengut.
Protsessiomadused
Lisaks tööriistade omadustele kaaluge arendusprotsessi funktsioone. Näiteks arengusse sekkumine on tüüpiline viga. Vaatame, milliste funktsioonidega tuleks veel arvestada ja millele peaks turvameeskond tähelepanu pöörama.
Et mitte segada arendust ja vabastada tähtaegu, looge erinevad reeglid ja erinev näita stopperid - ehitusprotsessi peatamise kriteeriumid haavatavuse korral - erinevate keskkondade jaoks. Näiteks saame aru, et praegune filiaal läheb arendusstendile või UAT-le, nii et me ei peatu ega ütle:
- Teil on siin haavatavused, te ei jõua kuhugi kaugemale!
Siinkohal on oluline arendajatele öelda, et on turvaprobleeme, millele tähelepanu pöörata.
Turvaaukude olemasolu ei takista edasist testimist: manuaalne, integreeritav või käsitsi. Teisest küljest peame kuidagi toote turvalisust parandama ja nii, et arendajad ei annaks skoori sellele, mida turvalisus leiab. Seetõttu teeme mõnikord nii: stendis, kui see arenduskeskkonda jõuab, teavitame arendust lihtsalt:
- Poisid, teil on probleeme, palun pöörake neile tähelepanu.
UAT etapis näitame jälle hoiatusi haavatavuste kohta ja balli lõpetamise etapis ütleme:
"Poisid, me hoiatasime teid mitu korda, te ei teinud midagi – me ei lase teid sellega välja.
Kui me räägime koodist ja dünaamikast, siis on vaja näidata ja hoiatada ainult nende funktsioonide ja koodide haavatavused, mis just selles funktsioonis on kirjutatud. Kui arendaja liigutas nuppu 3 piksli võrra ja me ütleme talle, et tal on seal SQL-i süst ja seetõttu tuleb see kiiresti parandada, on see vale. Vaadake ainult seda, mis praegu on kirjutatud, ja rakendusega kaasnevat muudatust.
Oletame, et meil on mingi funktsionaalne viga – see, kuidas rakendus ei peaks töötama: raha ei kanta üle, nupule vajutades ei toimu üleminekut järgmisele lehele või toode ei lae. Turvavead - need on samad defektid, kuid mitte rakenduse, vaid turvalisuse kontekstis.
Kõik tarkvara kvaliteediprobleemid ei ole turvaprobleemid. Kuid kõik turvaprobleemid on seotud tarkvara kvaliteediga. Sherif Mansour, Expedia.
Kuna kõik haavatavused on samad defektid, peaksid need asuma samas kohas, kus kõik arendusdefektid. Nii et unustage aruanded ja hirmutavad PDF-id, mida keegi ei loe.
Kui töötasin arendusettevõttes, sain staatilise analüüsi tööriistadest raporti. Avasin selle, kohkusin, keetsin kohvi, lehitsesin 350 lehekülge, sulgesin ja asusin tööle. Suured teated on surnud teated. Tavaliselt nad ei kao kuhugi, meilid kustutatakse, unustatakse, lähevad kaotsi või ettevõte ütleb, et ta võtab riske.
Mida teha? Teisendame leitud kinnitatud defektid lihtsalt arendamiseks mugavaks vormiks, lisame näiteks Jira mahajäämusse. Defektid seatakse prioriteediks ja kõrvaldatakse prioriteetsuse järjekorras koos funktsionaalsete defektide ja testdefektidega.
Staatiline analüüs – SAST
See on turvaaukude koodianalüüs., kuid see pole sama, mis SonarQube. Kontrollime mitte ainult mustreid ega stiili. Analüüsis kasutatakse mitmeid lähenemisviise: haavatavuse puu järgi, poolt , analüüsides konfiguratsioonifaile. See on kõik koodi enda jaoks.
Lähenemise plussid: koodi haavatavuste tuvastamine varases arengujärguskui puuduvad alused ja valmis tööriistad ning astmelise skaneerimise võimalus: skannib muutunud koodiosa ja ainult meie praegu kasutatavat funktsiooni, mis vähendab skannimisaega.
Miinused on vajalike keelte toe puudumine.
Nõutavad integratsioonid, mis peaks minu subjektiivse arvamuse kohaselt tööriistades olema:
- Integreerimistööriist: Jenkins, TeamCity ja Gitlab CI.
- Arenduskeskkond: Intellij IDEA, Visual Studio. Arendajal on mugavam mitte ronida arusaamatusse liidesesse, mis vajab veel meelespidamist, vaid näha kõiki vajalikke integratsioone ja nõrku kohti, mis ta on otse töökohal enda arenduskeskkonnas leidnud.
- Koodi ülevaatus: SonarQube ja käsitsi ülevaatus.
- Defektide jälgijad: Jira ja Bugzilla.
Pildil on mõned staatilise analüüsi parimad esindajad.
Tähtsad pole tööriistad, vaid protsess, seega on avatud lähtekoodiga lahendusi, mis sobivad hästi ka protsessi läbiviimiseks.
SAST avatud lähtekoodiga ei leia tohutul hulgal haavatavusi ega keerulist DataFlow'd, kuid neid saab ja tuleks protsessi ülesehitamisel kasutada. Need aitavad mõista, kuidas protsess üles ehitatakse, kes reageerib vigadele, kes annab teada, kes annab teada. Kui soovite oma koodi turvalisuse loomise algetappi läbi viia, kasutage avatud lähtekoodiga lahendusi.
Kuidas saab seda integreerida, kui olete teekonna alguses ja teil pole midagi: ei CI-d, Jenkinsit ega TeamCityt? Kaaluge protsesside integreerimist.
Integratsioon CVS-i tasemel
Kui teil on Bitbucket või GitLab, saate integreerida tasemel .
Sündmuse järgi tõmba taotlus, pühenduma. Skaneerite koodi ja näitate järgu olekus, kas turvakontroll läbis või ebaõnnestus.
Tagasiside Loomulikult on alati vaja tagasisidet. Kui tegite seda lihtsalt turvalisuse poole pealt, panite selle kasti ja ei rääkinud sellest kellelegi, ja siis kuu lõpus viskasite hunniku vigu, siis see pole õige ega hea.
Integratsioon koodiülevaatussüsteemiga
Kord määrasime AppSeci tehnilise kasutaja mitmes olulises projektis vaikeülevaatajaks. Olenevalt sellest, kas uues koodis leiti vigu või pole vigu, paneb ülevaataja tõmbepäringu olekuks "nõustun" või "vajab tööd" - kas kõik on korras või peate viimistlema ja linkima, mis täpselt lõpetada. Väljalastava versiooniga integreerimiseks oleme keelanud ühendamise, kui IS-i testi ei läbita. Lisasime selle käsitsi koodiülevaatesse ja ülejäänud protsessis osalejad nägid selle konkreetse protsessi turbeolekuid.
Integratsioon SonarQube'iga
Paljudel on koodi kvaliteedi osas. Siin on sama - samu väravaid saab teha ainult SAST-i instrumentidele. Seal on sama liides, sama kvaliteediga värav, ainult seda kutsutakse turvavärav. Ja kui teil on SonarQube'i abil seadistatud protsess, saate kõike seal hõlpsasti integreerida.
Integratsioon CI tasemel
Ka siin on kõik üsna lihtne:
- Autotestidega võrdne, ühikutestid.
- Jaotus arenguetappide järgi: dev, test, prod. Võib sisaldada erinevaid reeglite komplekte või erinevaid rikketingimusi: me peatame koostu, me ei peata kokkupanekut.
- Sünkroonne/asünkroonne jooks. Ootame turvatestide lõppu või ei oota. See tähendab, et me lihtsalt käivitasime need ja liigume edasi ning siis saame staatuse, et kõik on hästi või halvasti.
See kõik on täiuslikus roosas maailmas. Päris elus see nii ei ole, aga me pingutame. Turvakontrolli tulemus peaks olema sarnane üksuse testide tulemustega.
Näiteks võtsime ette suure projekti ja otsustasime, et nüüd skannime selle SASTiga – OK. Lükkasime selle projekti SAST-i, see andis meile 20 000 haavatavust ja tegime kindla otsuse, et kõik on korras. 20 000 haavatavust on meie tehniline võlg. Me paneme võla kasti, rehame selle aeglaselt üles ja käivitame veajälgijates vead. Palgake firma, tehke kõik ise või laske turvatšempionitel meid aidata ja tehniline võlg väheneb.
Ja kõik uues koodis ilmnenud haavatavused tuleks kõrvaldada samamoodi nagu vead üksuses või automaattestides. Suhteliselt öeldes läks koost käima, sõitis minema, kaks katset ja kaks turvatesti kukkusid alla. OK - läksime, vaatasime, mis juhtus, parandasime ühte, parandasime teist, sõitsime järgmine kord - kõik on korras, uusi turvaauke pole ilmnenud, testid pole ebaõnnestunud. Kui see ülesanne on sügavam ja peate sellest hästi aru saama või haavatavuste parandamine mõjutab suuri kihte kapoti all olevast: veajälgijasse tuuakse viga, see prioriseeritakse ja parandatakse. Kahjuks pole maailm täiuslik ja katsed kukuvad mõnikord läbi.
Turvavärava näide on kvaliteetvärava analoog koodis leiduvate turvaaukude ja nende arvu poolest.
Integreerime SonarQube'iga - plugin on installitud, kõik on väga mugav ja lahe.
Arenduskeskkonna integreerimine
Integreerimisvalikud:
- Skannimise alustamine arenduskeskkonnast juba enne kinnistamist.
- Vaata tulemusi.
- Tulemuste analüüs.
- Sünkroonimine serveriga.
Nii näeb välja serverist tulemuste saamine.
Meie arenduskeskkonnas kuvatakse lihtsalt lisaüksus, mis ütleb, et sellised haavatavused leiti skannimise ajal. Saate kohe koodi redigeerida, vaadata soovitusi ja . Kõik see asub arendaja töökohas, mis on väga mugav – te ei pea järgima ülejäänud linke ja vaatama midagi ekstra.
Open Source
See on minu lemmikteema. Kõik kasutavad avatud lähtekoodiga teeke – milleks kirjutada hunnik karkusid ja jalgrattaid, kui võite võtta valmis raamatukogu, milles kõik on juba rakendatud?
See on muidugi tõsi, aga ka raamatukogusid kirjutavad inimesed, need sisaldavad ka teatud riske, samuti on olemas haavatavused, millest perioodiliselt või pidevalt teatatakse. Seetõttu on rakenduste turvalisuses järgmine samm – see on avatud lähtekoodiga komponentide analüüs.
Avatud lähtekoodiga analüüs – OSA
Tööriist sisaldab kolme peamist sammu.
Haavatavuste leidmine raamatukogudes. Näiteks teab tööriist, et me kasutame mingit teeki ja see on sees või veajälgijates on mõned haavatavused, mis on seotud teegi selle versiooniga. Kui proovite seda kasutada, hoiatab tööriist teid, et teek on haavatav, ja soovitab teil kasutada mõnda muud versiooni, kus turvaauke pole.
Litsentsi puhtuse analüüs. See pole meil veel eriti populaarne, kuid kui töötate välisriigiga, võite seal perioodiliselt saada rünnaku avatud lähtekoodiga komponendi kasutamise eest, mida ei saa kasutada ega muuta. Litsentsiga raamatukogu poliitika kohaselt ei saa me seda teha. Või kui oleme seda muutnud ja kasutame seda, peame oma koodi postitama. Loomulikult ei taha keegi oma toodete koodi postitada, kuid saate end ka selle eest kaitsta.
Tööstuskeskkonnas kasutatavate komponentide analüüs. Kujutage ette hüpoteetilist olukorda, kus oleme lõpuks arenduse lõpetanud ja oma mikroteenuse uusima versiooni tööstusele välja andnud. Ta elab seal imeliselt – nädal, kuu, aasta. Me ei kogu seda, me ei tee turvakontrolli, kõik tundub korras olevat. Kuid ootamatult, kaks nädalat pärast väljalaskmist, tuleb avatud lähtekoodiga komponendis välja kriitiline haavatavus, mida me selles konkreetses koostis tööstuskeskkonnas kasutame. Kui me ei salvesta, mida ja kus kasutame, siis seda haavatavust lihtsalt ei näe. Mõnel tööriistal on võimalus jälgida turvaauke raamatukogudes, mida praegu kasutatakse ballis. See on väga kasulik.
Omadused:
- Erinevate arenguetappide jaoks erinevad poliitikad.
- Jälgige komponente tööstuskeskkonnas.
- Raamatukogude juhtimine organisatsiooni kontuuris.
- Erinevate ehitussüsteemide ja keelte tugi.
- Dockeri piltide analüüs.
Mõned näited valdkonna liidritest, kes tegelevad avatud lähtekoodi analüüsiga.
Ainus tasuta on OWASP-lt. Saate selle esimestel etappidel sisse lülitada, vaadata, kuidas see töötab ja mida see toetab. Põhimõtteliselt on need kõik pilvetooted või kohapealsed, kuid nende baasi taga lähevad nad ikkagi Internetti. Nad ei saada oma serverisse teie teeke, vaid räsisid või nende arvutatud väärtusi ja sõrmejälgi, et saada uudiseid turvaaukude olemasolust.
Protsessi integreerimine
Perimeetri raamatukogu juhtiminemis laaditakse alla välistest allikatest. Meil on välised ja sisemised hoidlad. Näiteks on meil Event Centralis Nexus ja me tahame tagada, et meie hoidlas ei oleks "kriitilise" või "kõrge" olekuga turvaauke. Puhverserveri saate seadistada Nexuse tulemüüri elutsükli tööriista abil, nii et sellised haavatavused on ära lõigatud ega sisaldu sisemises hoidlas.
CI integreerimine. Samal tasemel autotestide, ühikutestide ja arendusetappideks jagamisega: dev, test, prod. Igas etapis saate alla laadida mis tahes teeke, kasutada kõike, kuid kui "kriitilise" olekuga on midagi rasket, peaksite tõenäoliselt sellele ballile sisenemise etapis arendajate tähelepanu juhtima.
Artefaktide integreerimine: Nexus ja JFrog.
Integratsioon arenduskeskkonda. Teie valitud tööriistad peaksid olema arenduskeskkondadega integreeritud. Arendajal peab olema juurdepääs oma töökoha kontrolli tulemustele või võimalus skannida ja kontrollida koodi turvaauke enne selle CVS-is kasutuselevõttu.
CD integreerimine. See on lahe funktsioon, mis mulle väga meeldib ja millest olen juba rääkinud – uute haavatavuste jälgimine tööstuskeskkonnas. See toimib nii.
Meil on Avalikud komponentide hoidlad - mõned tööriistad väljaspool ja meie sisemine hoidla. Soovime, et selles oleksid ainult usaldusväärsed komponendid. Päringu puhverserveril kontrollime, et allalaaditud teegil poleks haavatavusi. Kui see langeb teatud poliitikate alla, mille me kehtestame ja mille arendusega tingimata kooskõlastame, siis me seda üles ei laadi ja saame vastulause kasutada teistsugust versiooni. Seega, kui raamatukogus on midagi tõeliselt kriitilist ja halba, siis arendaja ei saa teeki isegi installimisetapis - laske tal kasutada kõrgemat või madalamat versiooni.
- Ehitamisel kontrollime, et kellelgi poleks midagi halvasti libisenud, et kõik komponendid oleksid ohutud ja keegi poleks midagi ohtlikku mälupulgale kaasa toonud.
- Meil on hoidlas ainult usaldusväärsed komponendid.
- Juurutamisel kontrollime veel kord paketti ennast: war, jar, DL või Docker image, kas see vastab poliitikale.
- Tööstuskeskkonda sisenedes jälgime tööstuskeskkonnas toimuvat: kriitilised haavatavused tekivad või ei teki.
Dünaamiline analüüs – DAST
Dünaamilise analüüsi tööriistad erinevad põhimõtteliselt kõigest sellest, mida on varem öeldud. See on omamoodi jäljendamine kasutaja tööst rakendusega. Kui tegemist on veebirakendusega, saadame kliendi tööd imiteerivad päringud, klõpsame esiküljel olevaid nuppe, saadame vormilt tehisandmed: jutumärgid, sulud, märgid erinevates kodeeringus, et vaadata, kuidas rakendus töötab ja välist töötleb. andmeid.
Sama süsteem võimaldab teil kontrollida avatud lähtekoodiga mallide haavatavusi. Kuna DAST ei tea, millist avatud lähtekoodi me kasutame, viskab see lihtsalt "pahatahtlikke" mustreid ja analüüsib serveri vastuseid:
- Jah, siin on deserialiseerimise probleem, aga mitte siin.
Sellega kaasnevad suured riskid, sest kui viia see turvatest läbi samal stendil, millega testijad töötavad, võib juhtuda ebameeldivaid asju.
- Rakendusserveri võrgu suur koormus.
- Integratsioonid puuduvad.
- Võimalus muuta analüüsitava rakenduse sätteid.
- Puudub tugi vajalike tehnoloogiate jaoks.
- Seadistamise raskus.
Meil oli olukord, kui lõpuks AppScani käivitasime: katkestasime pikka aega juurdepääsu rakendusele, saime 3 kontot ja olime rõõmsad - lõpuks kontrollime kõike! Käivitasime skannimise ja esimene asi, mida AppScan tegi, oli siseneda administraatori paneeli, läbistada kõik nupud, muuta pooled andmed ja seejärel tappa server täielikult omadega. -taotlused. Testimisega arendus ütles:
"Poisid, kas te teete minuga nalja?! Andsime teile kontod ja teie panite aluse!
Kaaluge võimalikke riske. Ideaalis valmistage infoturbe testimiseks ette eraldi stend, mis vähemalt kuidagi isoleeritakse muust keskkonnast ja kontrollige tinglikult üle administraatoripaneeli, soovitavalt manuaalrežiimis. See on pentest – need ülejäänud jõupingutuste protsendid, mida me praegu ei arvesta.
Tasub kaaluda, et saate seda kasutada koormustesti analoogina. Esimeses etapis saate dünaamilise skanneri sisse lülitada 10–15 lõime kaupa ja vaadata, mis juhtub, kuid tavaliselt, nagu praktika näitab, pole midagi head.
Mõned ressursid, mida me tavaliselt kasutame.
Väärib esiletõstmist on "Šveitsi nuga" iga turvatöötaja jaoks. Kõik kasutavad seda ja see on väga mugav. Nüüd on välja antud ettevõtte väljaande uus demoversioon. Kui varem oli see lihtsalt eraldiseisev pistikprogrammidega utiliit, siis nüüd on arendajad lõpuks tegemas suurt serverit, kust saab mitut agenti hallata. See on lahe, soovitan teil seda proovida.
Protsessi integreerimine
Integreerimine on üsna hea ja lihtne: alusta skannimist pärast edukat installimist rakendused stendil ja skannimine pärast edukat integratsioonitesti.
Kui integratsioonid ei tööta või on stub-id ja pilkupüüdvaid funktsioone, on see mõttetu ja kasutu – olenemata sellest, millist mustrit me saadame, vastab server ikkagi samamoodi.
- Ideaalis eraldi katsestend.
- Enne testimist kirjutage sisselogimisjärjestus üles.
- Haldussüsteemi testimine on ainult käsitsi.
protsess
Natuke üldistatud protsessi kohta üldiselt ja iga tööriista töö kohta eriti. Kõik rakendused on erinevad – üks töötab paremini dünaamilise analüüsiga, teine staatilise analüüsiga, kolmas OpenSource analüüsiga, pentestid või midagi muud üldiselt, näiteks sündmused .
Iga protsessi tuleb kontrollida.
Protsessi toimimise ja täiustamise mõistmiseks peate koguma mõõdikuid kõigest, mis käepärast, sealhulgas tootmismõõdikutest, tööriistade mõõdikutest ja defektide jälgijatest.
Igasugune teave on abiks. Erinevates jaotistes on vaja vaadata, kus seda või teist tööriista paremini kasutada, kus protsess konkreetselt langeb. Võib-olla tasub vaadata arenduse reageerimisaega, et näha, kus protsessi ajapõhiselt täiustada. Mida rohkem andmeid, seda rohkem kärpeid saab luua tipptasemelt iga protsessi üksikasjadesse.
Kuna kõigil staatilistel ja dünaamilistel analüsaatoritel on oma API-d, oma käivitusmeetodid, põhimõtted, siis mõnel on planeerijad, teistel mitte - kirjutame tööriista AppSec Orchestrator, mis võimaldab teha tootest ühe sisenemispunkti kogu protsessile ja hallata seda ühest punktist.
Juhtidel, arendajatel ja turbeinseneridel on üks sisenemispunkt, kust nad saavad näha, mis töötab, konfigureerida ja käivitada skaneeringuid, hankida kontrolli tulemusi ja esitada nõudeid. Püüame eemalduda paberitükkidest, tõlkida kõik inimlikuks, mida arendus kasutab - leheküljed Confluence'ist koos oleku ja mõõdikutega, Jira või mitmesuguste defektide jälgijate defektid või manustamine sünkroonsesse / asünkroonsesse protsessi CI / CD-s.
Võtme tagasivõtmine
Tööriistadel pole tähtsust. Mõelge kõigepealt protsessile ja seejärel rakendage tööriistu. Tööriistad on head, kuid kallid, nii et saate alustada protsessiga ja täpsustada arenduse ja turvalisuse vahelist suhtlust ja mõistmist. Turvalisuse seisukohalt pole vaja kõike järjest “peatada”.Arengu seisukohalt, kui on midagi kõrget mega superkriitilist, siis tuleb see likvideerida, mitte probleemile kinni panna. .
Toote kvaliteet - ühine eesmärk nii turvalisus kui ka areng. Teeme üht, püüame tagada, et kõik toimiks korrektselt ning ei tekiks maineriske ja rahalisi kaotusi. Seetõttu propageerime suhtluse loomiseks ja toote paremaks muutmiseks lähenemist DevSecOpsile ja SecDevOpsile.
Alusta sellest, mis juba olemas on: nõuded, arhitektuur, osalised kontrollid, koolitused, juhised. Kõiki tavasid ei ole vaja kohe kõigi projektide puhul rakendada - iteratiivselt liikuda. Ühtset standardit pole katse ja proovida erinevaid lähenemisviise ja lahendusi.
Võrdsusmärk IS-defektide ja funktsionaalsete defektide vahel.
Automatiseerige kõiksee liigub. Kõik, mis ei liigu, liigub ja automatiseerub. Kui midagi tehakse käsitsi, pole see protsessi hea osa. Võib-olla tasub see ka ümber mõelda ja automatiseerida.
Kui IB meeskonna suurus on väike - kasutage Security Championsit.
Võib-olla ei sobi see, millest ma rääkisin, ja mõtlete välja midagi oma – ja see on hea. Aga vali tööriistad vastavalt protsessi nõuetele. Ärge vaadake, mida kogukond ütleb, et see tööriist on halb ja see hea. Võib-olla on see teie toote puhul vastupidine.
Tööriistanõuded.
- Madal valepositiivne.
- Piisav analüüsiaeg.
- Kasutusmugavus.
- Integratsioonide saadavus.
- Tootearenduse tegevuskava mõistmine.
- Võimalus tööriistu kohandada.
Juri aruanne valiti DevOpsConf 2018 parimate hulka. Veelgi huvitavamate ideede ja praktiliste juhtumitega tutvumiseks tule 27. ja 28. mail Skolkovosse sees . Veelgi parem, kui olete nõus oma kogemusi jagama Esitage oma aruanne 21. aprilliks.
Allikas: www.habr.com