Volt 2 kódelemzőnk, 4 dinamikus tesztelő eszközünk, saját kézművünk és 250 szkriptünk. Nem arról van szó, hogy minderre szükség van a jelenlegi folyamatban, de ha egyszer elkezdi implementálni a DevSecOps-t, akkor a végére kell mennünk.
. Karakter alkotók: Justin Roiland és Dan Harmon.
Mi az a SecDevOps? Mi a helyzet a DevSecOps-szal? Mik a különbségek? Alkalmazásbiztonság – miről szól? Miért nem működik már a klasszikus megközelítés? Mindezekre a kérdésekre tudja a választ Jurij Shabalin A Swordfish Security. Jurij mindenre részletesen válaszol, és elemzi a klasszikus Application Security modellről a DevSecOps folyamatra való átmenet problémáit: hogyan lehet megfelelően megközelíteni a biztonságos fejlesztési folyamat integrálását a DevOps folyamatba, és nem törni semmit, hogyan kell végigmenni a fő szakaszokon. A biztonsági tesztelésről, milyen eszközök használhatók, és miben különböznek egymástól, és hogyan kell helyesen konfigurálni őket a buktatók elkerülése érdekében.
Az előadóról: Jurij Shabalin - A cégnél biztonsági főépítész Swordfish Security. Felelős az SSDL megvalósításáért, az alkalmazáselemző eszközök egységes fejlesztési és tesztelési ökoszisztémába történő átfogó integrációjáért. 7 év információbiztonsági tapasztalat. Dolgozott az Alfa-Bankban, a Sberbankban és a Positive Technologiesnél, amely szoftvereket fejleszt és szolgáltatásokat nyújt. Előadó nemzetközi konferenciákon ZerONights, PHDays, RISSPA, OWASP.
Alkalmazásbiztonság: miről szól?
Alkalmazásbiztonság - Ez a biztonsági rész felelős az alkalmazások biztonságáért. Ez nem az infrastruktúrára vagy a hálózat biztonságára vonatkozik, hanem arra, amit írunk, és amin dolgoznak a fejlesztők – ezek magának az alkalmazásnak a hiányosságai és sebezhetőségei.
Irány - Biztonságfejlesztési életciklus - a Microsoft fejlesztette. Az ábra a kanonikus SDLC modellt mutatja, melynek fő feladata a biztonság részvétele a fejlesztés minden szakaszában, a követelményektől a kiadásig és a gyártásig. A Microsoft rájött, hogy túl sok a hiba az iparágban, több van belőlük, és tenni kell ellene, és ezt a megközelítést javasolták, amely kanonikussá vált.
Az Alkalmazásbiztonság és az SSDL nem a sebezhetőségek felderítését célozza, ahogyan azt általában hiszik, hanem azok előfordulásának megakadályozását. Az idő múlásával a Microsoft kanonikus megközelítése javult, fejlődött, és egy mélyebb, részletesebb merülésbe került.
A kanonikus SDLC nagyon részletes a különféle módszerekben – OpenSAMM, BSIMM, OWASP. A módszerek eltérőek, de általában hasonlóak.
Épületbiztonsági modell
nekem ez tetszik a legjobban BSIMM - . A módszertan alapja az Application Security folyamat 4 tartományra bontása: Irányítás, Intelligencia, SSDL Touchpoints és Deployment. Minden domain 12 gyakorlattal rendelkezik, amelyek 112 tevékenységként jelennek meg.
A 112 tevékenység mindegyike rendelkezik 3 érettségi szint: kezdő, középhaladó és haladó. Részletenként tanulmányozhatja mind a 12 gyakorlatot, kiválaszthatja az Ön számára fontos dolgokat, kitalálhatja, hogyan valósítsa meg őket, és fokozatosan hozzáadhat elemeket, például statikus és dinamikus kódelemzést vagy kód áttekintést. Leírsz egy tervet, és a kiválasztott tevékenységek megvalósítása során nyugodtan dolgozol aszerint.
Miért a DevSecOps?
A DevOps egy általános, nagy folyamat, amelyben a biztonságot figyelembe kell venni.
Kezdetben biztonsági ellenőrzésekkel járt. A gyakorlatban a biztonsági csapatok létszáma jóval kisebb volt a jelenleginél, és nem a folyamat résztvevőiként, hanem ellenőrző és felügyeleti szervként működtek, amely követelményeket támaszt vele szemben, és a megjelenés végén ellenőrzi a termék minőségét. Ez egy klasszikus megközelítés, amelyben a biztonsági csapatok a fal mögött álltak a fejlesztéstől, és nem vettek részt a folyamatban.
A fő probléma az, hogy az információbiztonság elkülönül a fejlesztéstől. Általában ez valamilyen információbiztonsági áramkör, és 2-3 nagy és drága eszközt tartalmaz. Félévente egyszer megérkezik az ellenőrizendő forráskód vagy alkalmazás, és évente egyszer készül el . Mindez oda vezet, hogy az iparág megjelenési dátuma késik, és a fejlesztő az automatizált eszközök hatalmas számú sebezhetőségének van kitéve. Mindezt nem lehet szétszedni és megjavítani, mert az előző hat hónap eredményét nem rendezték, de itt egy új tétel.
Cégünk munkája során azt látjuk, hogy a biztonság minden területen és iparágban megérti, hogy ideje utolérni, és ugyanazon a keréken pörögni a fejlődéssel – . A DevSecOps paradigma tökéletesen illeszkedik az agilis fejlesztési módszertanhoz, megvalósításhoz, támogatáshoz és minden kiadásban és iterációban való részvételhez.
Áttérés a DevSecOps-ra
A biztonságfejlesztési életciklus legfontosabb szava az "folyamat". Ezt meg kell értenie, mielőtt szerszámvásárlásra gondol.
Nem elég az eszközöket egyszerűen beépíteni a DevOps folyamatba – fontos a folyamat résztvevői közötti kommunikáció és megértés.
Az emberek fontosabbak, nem az eszközök.
A biztonságos fejlesztési folyamat tervezése gyakran az eszköz kiválasztásával és megvásárlásával kezdődik, és az eszköznek az aktuális folyamatba való integrálására irányuló kísérletekkel végződik, amelyek kísérletek maradnak. Ez sajnálatos következményekkel jár, mert minden eszköznek megvannak a maga sajátosságai és korlátai.
Gyakori eset, amikor a biztonsági osztály egy jó, drága, széles képességekkel rendelkező eszközt választott, és a fejlesztőkhöz fordult, hogy integrálja a folyamatba. De ez nem működik - a folyamat úgy van felépítve, hogy a már megvásárolt eszköz korlátai nem illeszkednek a jelenlegi paradigmába.
Először írja le, milyen eredményt szeretne, és hogyan fog kinézni a folyamat. Ez segít megérteni az eszköz és a biztonság szerepét a folyamatban.
Kezdje azzal, ami már használatban van
Mielőtt drága szerszámokat vásárolna, nézze meg, mi van már. Minden cégnek vannak biztonsági követelményei a fejlesztéshez, vannak csekkek, pentesztek – miért ne alakíthatnánk mindezt mindenki számára érthető és kényelmes formába?
Általában a követelmények egy papír Talmud, amely egy polcon hever. Volt olyan eset, amikor bementünk egy céghez, hogy megnézzük a folyamatokat, és kértük, hogy lássák a szoftver biztonsági követelményeit. A szakember, aki ezzel foglalkozott, sokáig kereste:
- Nos, valahol a jegyzetekben volt egy út, ahol ez a dokumentum fekszik.
Ennek eredményeként egy héttel később megkaptuk a dokumentumot.
Követelményekhez, csekkekhez és egyéb dolgokhoz hozzon létre egy oldalt pl. Összefolyásánál - mindenkinek kényelmes.
Könnyebb újraformázni a már meglévőt, és felhasználni a kezdéshez.
Használja a Security Champions alkalmazást
Jellemzően egy átlagos, 100-200 fejlesztő cégnél van egy biztonsági szakember, aki több funkciót is ellát, és fizikailag nincs ideje mindent ellenőrizni. Még ha mindent meg is próbál, egyedül nem fogja ellenőrizni az összes kódot, amit a fejlesztés generál. Az ilyen esetekre kidolgoztak egy koncepciót - .
A biztonsági bajnokok a fejlesztőcsapat tagjai, akik érdeklődnek a termék biztonsága iránt.
A Security Champion belépési pont a fejlesztőcsapatba, és egy biztonsági evangélista is.
Általában, amikor egy biztonsági szakember eljön a fejlesztőcsapathoz, és rámutat egy hibára a kódban, meglepett választ kap:
- És te ki vagy? Először látlak. Minden rendben van velem - idősebb barátom adott „jelentkezést” a kód áttekintésénél, megyünk tovább!
Ez egy tipikus helyzet, mert sokkal nagyobb a bizalom az idősekben vagy egyszerűen a csapattársakban, akikkel a fejlesztő folyamatosan érintkezik a munkahelyén és a kód áttekintése során. Ha a biztonsági tiszt helyett a biztonsági bajnok mutat rá a hibára és a következményekre, akkor az ő szavának nagyobb súlya lesz.
Ezenkívül a fejlesztők jobban ismerik a kódjukat, mint bármely biztonsági szakember. Annak a személynek, akinek legalább 5 projektje van egy statikus elemző eszközben, általában nehéz megjegyezni az összes árnyalatot. A biztonsági bajnokok ismerik terméküket: mi az, amivel kölcsönhatásba lép, és mire kell először figyelni – hatékonyabbak.
Ezért fontolja meg a Security Champions bevezetését és a biztonsági csapat befolyásának kiterjesztését. Ez magának a bajnoknak is hasznos: szakmai fejlődés egy új területen, technikai látókör bővítése, technikai, vezetői és vezetői képességek fejlesztése, piaci érték növelése. Ez a social engineering néhány eleme, az Ön „szemei” a fejlesztőcsapatban.
Tesztelési szakaszok
azt mondja, hogy az erőfeszítés 20%-a hozza az eredmények 80%-át. Ez a 20% olyan alkalmazáselemzési gyakorlat, amelyet automatizálni lehet és kell is. Ilyen tevékenységek például a statikus elemzés - SAST, dinamikus elemzés - DAST и Nyílt forráskódú vezérlés. Részletesebben elmondom a tevékenységeket, valamint az eszközöket, milyen jellemzőkkel szoktunk találkozni, amikor bevezetjük őket a folyamatba, és hogyan kell ezt helyesen elvégezni.
Az eszközök főbb problémái
Kiemelem azokat a problémákat, amelyek minden eszközre vonatkoznak, és figyelmet igényelnek. Részletesebben elemzem őket, hogy ne ismételjem meg őket.
Hosszú elemzési idő. Ha a véglegesítéstől a kiadásig 30 percet vesz igénybe az összes teszt és összeszerelés, akkor az információbiztonsági ellenőrzések egy napot vesznek igénybe. Tehát senki sem fogja lelassítani a folyamatot. Vegye figyelembe ezt a tulajdonságot, és vonjon le következtetéseket.
Magas szintű hamis negatív vagy hamis pozitív. Minden termék más, mindegyik más keretrendszert és saját kódolási stílust használ. Különböző kódbázisokon és technológiákon az eszközök különböző szintű hamis negatív és hamis pozitív értékeket mutathatnak. Szóval nézd meg, hogy pontosan mi van benne Ön cégek és számára a ti alkalmazások jó és megbízható eredményeket fognak mutatni.
Nincs integráció a meglévő eszközökkel. Tekintse meg az eszközöket a már használt eszközökkel való integráció szempontjából. Például, ha Jenkins vagy TeamCity van, ellenőrizze az eszközök integrációját ezzel a szoftverrel, és ne a GitLab CI-vel, amelyet nem használ.
A testreszabás hiánya vagy túlzott bonyolultsága. Ha egy eszköznek nincs API-ja, akkor miért van rá szükség? Mindennek, amit a felületen meg lehet tenni, elérhetőnek kell lennie az API-n keresztül. Ideális esetben az eszköznek képesnek kell lennie az ellenőrzések testreszabására.
Nincs termékfejlesztési ütemterv. A fejlesztés nem áll meg, mindig új keretrendszereket és függvényeket használunk, a régi kódot új nyelvekre írjuk át. Biztosak akarunk lenni abban, hogy a megvásárolt eszköz támogatni fogja az új keretrendszereket és technológiákat. Ezért fontos tudni, hogy a termék valódi és helyes fejlődés.
Folyamatfunkciók
Az eszközök jellemzői mellett vegye figyelembe a fejlesztési folyamat jellemzőit is. Gyakori hiba például a fejlődés akadályozása. Nézzük meg, milyen egyéb funkciókat érdemes figyelembe venni, és mire kell figyelnie a biztonsági csapatnak.
Annak érdekében, hogy ne hagyja ki a fejlesztési és kiadási határidőket, hozzon létre eltérő szabályok és más bemutató dugót — kritériumok a felépítési folyamat leállítására sebezhetőség esetén, különböző környezetekhez. Például megértjük, hogy az aktuális ág a fejlesztői standhoz vagy az UAT-hoz megy, ami azt jelenti, hogy nem állunk meg és mondjuk:
"Itt vannak sebezhetőségeid, nem fogsz tovább menni!"
Ezen a ponton fontos elmondani a fejlesztőknek, hogy vannak biztonsági problémák, amelyekre figyelmet kell fordítani.
A sérülékenységek jelenléte nem akadálya a további tesztelésnek: kézi, integrációs vagy kézi. Másrészt valahogy növelnünk kell a termék biztonságát, és hogy a fejlesztők ne hanyagolják el azt, amit biztonságosnak találnak. Ezért néha ezt tesszük: a standnál, amikor kiterítik a fejlesztői környezetbe, egyszerűen értesítjük a fejlesztést:
- Srácok, problémáid vannak, kérlek, figyelj rájuk.
Az UAT szakaszban ismét figyelmeztetéseket jelenítünk meg a sebezhetőségekkel kapcsolatban, a kiadási szakaszban pedig a következőket mondjuk:
- Srácok, többször figyelmeztettünk titeket, nem csináltatok semmit - ezzel nem engedünk ki.
Ha kódról és dinamikáról beszélünk, akkor csak azon funkciók és kódok sebezhetőségeit kell megmutatni és figyelmeztetni, amelyek éppen ebben a funkcióban íródnak. Ha egy fejlesztő 3 pixellel elmozgat egy gombot, és azt mondjuk neki, hogy ott van egy SQL-injekció, és ezért sürgősen javítani kell, ez hibás. Csak azt nézze, ami most van írva, és azt a változást, amely az alkalmazást érinti.
Tegyük fel, hogy van egy bizonyos funkcionális hibánk – ahogyan az alkalmazásnak nem szabad működnie: a pénz nem kerül átutalásra, egy gombra kattintva nem lép át a következő oldalra, vagy nem töltődik be a termék. Biztonsági hibák - ezek ugyanazok a hibák, de nem az alkalmazás működését, hanem a biztonságot tekintve.
Nem minden szoftverminőségi probléma biztonsági probléma. De minden biztonsági probléma a szoftver minőségével kapcsolatos. Sherif Mansour, Expedia.
Mivel minden sérülékenység azonos hiba, ugyanazon a helyen kell elhelyezkedniük, mint az összes fejlesztési hibának. Tehát felejtse el a jelentéseket és az ijesztő PDF-eket, amelyeket senki sem olvas.
Amikor egy fejlesztő cégnél dolgoztam, kaptam egy jelentést a statikus elemző eszközöktől. Kinyitottam, megrémültem, kávét főztem, átlapoztam 350 oldalt, becsuktam és tovább dolgoztam. A nagy jelentések halott jelentések. Általában nem mennek sehova, a leveleket törlik, elfelejtik, elveszik, vagy a vállalkozás azt mondja, hogy vállalja a kockázatot.
Mit kell tenni? A talált megerősített hibákat egyszerűen átalakítjuk a fejlesztés számára kényelmes formára, például a Jira-ban lemaradásba helyezzük őket. A hibákat rangsoroljuk, és fontossági sorrendben küszöböljük ki, a funkcionális hibákkal és a teszthibákkal együtt.
Statikus elemzés – SAST
Ez a biztonsági rések kódelemzése., de ez nem ugyanaz, mint a SonarQube. Nem csak a mintákat vagy a stílust ellenőrizzük. Az elemzés során számos megközelítést alkalmaznak: a sebezhetőségi fa szerint, aszerint , a konfigurációs fájlok elemzésével. Ez minden, ami magára a kódra vonatkozik.
A megközelítés előnyei: a kód sérülékenységeinek azonosítása a fejlesztés korai szakaszábanamikor még nincsenek állványok vagy kész eszközök, és növekményes szkennelési képesség: a kód egy megváltozott szakaszának beolvasása, és csak a jelenleg használt szolgáltatás, amely csökkenti a szkennelési időt.
Hátrányok - ez a szükséges nyelvek támogatásának hiánya.
Szükséges integrációk, aminek szubjektív véleményem szerint az eszközökben kell lennie:
- Integrációs eszköz: Jenkins, TeamCity és Gitlab CI.
- Fejlesztői környezet: Intellij IDEA, Visual Studio. A fejlesztő számára kényelmesebb, ha nem egy érthetetlen, még memorizálásra szoruló felületen navigál, hanem a saját fejlesztői környezetében látja az összes szükséges integrációt és sérülékenységet, amit a munkahelyén talált.
- Kód felülvizsgálata: SonarQube és kézi ellenőrzés.
- Hibakövetők: Jira és Bugzilla.
A képen a statikus elemzés néhány legjobb képviselője látható.
Nem az eszközök a fontosak, hanem a folyamat, ezért vannak nyílt forráskódú megoldások, amelyek a folyamat tesztelésére is jók.
A SAST Open Source nem talál nagyszámú sebezhetőséget vagy összetett DataFlow-ot, de ezeket lehet és kell használni egy folyamat felépítése során. Segítenek megérteni, hogyan épül fel a folyamat, ki fog reagálni a hibákra, ki fog jelenteni és ki fog jelenteni. Ha szeretné végrehajtani a kódja biztonságának kiépítésének kezdeti szakaszát, használja a nyílt forráskódú megoldásokat.
Hogyan lehet ezt integrálni, ha az út elején jár, és nincs semmije: nincs CI, nincs Jenkins, nincs TeamCity? Tekintsük a folyamatba való integrációt.
CVS szintű integráció
Ha van Bitbucket vagy GitLab, akkor szinten integrálhatja .
Esemény szerint - kérés lehívása, kötelezettségvállalás. Beolvassa a kódot, és a build állapota megmutatja, hogy a biztonsági ellenőrzés sikeres vagy sikertelen volt-e.
Visszacsatolás. Természetesen mindig szükség van visszajelzésekre. Ha csak az oldalsó védelmet végezte el, betette egy dobozba, és nem szólt róla senkinek, majd a hónap végén kidobott egy csomó hibát - ez nem helyes és nem jó.
Integráció a kódellenőrző rendszerrel
Egykor számos fontos projektben az AppSec műszaki felhasználójának alapértelmezett felülvizsgálójaként működtünk. Attól függően, hogy az új kódban találtak-e hibákat, vagy nincsenek hibák, a lektor a lekérési kérés állapotát „elfogad” vagy „munkára van szüksége” állapotra állítja - vagy minden rendben van, vagy a linkek arra mutatnak, hogy mit kell pontosan javítani. javítani kell. Az éles verzióval való integráció érdekében engedélyeztük az összevonási tilalmat, ha az információbiztonsági teszt nem felel meg. Ezt belefoglaltuk a kézi kódellenőrzésbe, és a folyamat többi résztvevője láthatta az adott folyamat biztonsági állapotát.
Integráció a SonarQube-ba
Sokaknak van kódminőség szempontjából. Itt is ugyanaz – ugyanazokat a kapukat csak a SAST eszközökhöz készítheti. Ugyanaz a felület lesz, ugyanaz a minőségi kapu, csak azt fogják hívni biztonsági kapu. És ha van egy folyamata a SonarQube használatával, könnyen integrálhat mindent.
Integráció CI szinten
Itt is minden nagyon egyszerű:
- Egyenrangú az automatikus tesztekkel, egységtesztek.
- Fejlesztési szakaszok szerinti felosztás: fejlesztő, teszt, prod. Különböző szabályok vagy meghibásodási feltételek szerepelhetnek: állítsa le az összeszerelést, ne állítsa le az összeszerelést.
- Szinkron/aszinkron indítás. Megvárjuk a biztonsági tesztek végét vagy sem. Vagyis csak elindítottuk őket, és továbbmegyünk, aztán azt a státuszt kapjuk, hogy minden jó vagy rossz.
Mindez egy tökéletes rózsaszín világban. A való életben nincs ilyen, de törekszünk. A biztonsági ellenőrzések eredményének hasonlónak kell lennie az egységtesztek eredményéhez.
Például vettünk egy nagy projektet, és úgy döntöttünk, hogy most a SAST - OK segítségével szkenneljük. Ezt a projektet betoltuk a SAST-ba, 20 000 sebezhetőséget adott nekünk, és határozott akarattal úgy döntöttünk, hogy minden rendben van. 20 000 sérülékenység a technikai adósságunk. Az adósságot egy dobozba tesszük, lassan kitisztítjuk, és hibákat adunk a hibakövetőkhöz. Béreljünk fel egy céget, csináljunk meg mindent magunk, vagy a biztonsági bajnokok segítsenek nekünk – és a technikai adósság csökkenni fog.
És az új kód minden újonnan megjelenő sebezhetőségét ugyanúgy ki kell küszöbölni, mint az egység vagy az automatikus tesztek hibáit. Viszonylag elmondható, hogy az összeszerelés elindult, lefuttattuk, két teszt és két biztonsági teszt nem sikerült. Rendben - elmentünk, megnéztük, mi történt, javítottunk egy dolgot, javítottunk egy másikat, legközelebb lefuttattuk - minden rendben volt, nem jelentek meg új sebezhetőségek, egyetlen teszt sem sikerült. Ha ez a feladat mélyebb, és jól meg kell értenie, vagy a sérülékenységek javítása a motorháztető alatt rejlő dolgok nagy rétegeit érinti: a hibakövetőhöz egy hiba került, azt priorizálja és kijavítja. Sajnos a világ nem tökéletes, és a tesztek néha kudarcot vallanak.
A biztonsági kapura példa a minőségi kapu analógja, a kódban található sebezhetőségek megléte és száma szempontjából.
Integráljuk a SonarQube-ot - a bővítmény telepítve van, minden nagyon kényelmes és menő.
Integráció a fejlesztői környezetbe
Integrációs lehetőségek:
- Vizsgálat futtatása a fejlesztői környezetből a véglegesítés előtt.
- Eredmények megtekintése.
- Az eredmények elemzése.
- Szinkronizálás a szerverrel.
Így néz ki, ha eredményeket kapunk a szervertől.
Fejlesztői környezetünkben egyszerűen megjelenik egy további elem, amely arról tájékoztat, hogy a vizsgálat során ilyen sebezhetőséget észleltek. Azonnal szerkesztheti a kódot, megnézheti az ajánlásokat és . Ez mind a fejlesztő munkahelyén található, ami nagyon kényelmes - nem kell más linkeket követni, és valami továbbit nézni.
Open Source
Ez a kedvenc témám. Mindenki nyílt forráskódú könyvtárakat használ – miért írjunk egy csomó mankót és biciklit, ha vehetünk egy kész könyvtárat, amelyben már minden megvalósul?
Ez persze igaz, de a könyvtárakat is emberek írják, ezek is tartalmaznak bizonyos kockázatokat és vannak olyan sebezhetőségek is, amelyeket időszakosan, vagy folyamatosan jelentenek. Ezért van az Application Security következő lépése – ez a nyílt forráskódú összetevők elemzése.
Nyílt forráskódú elemzés – OSA
Az eszköz három nagy szakaszból áll.
Sebezhetőségek keresése a könyvtárakban. Például az eszköz tudja, hogy valamilyen könyvtárat használunk, és ez az vagy van néhány sebezhetőség a hibakövetőkben, amelyek a könyvtár ezen verziójához kapcsolódnak. Amikor megpróbálja használni, az eszköz figyelmeztetést ad ki, hogy a könyvtár sebezhető, és azt tanácsolja, hogy használjon egy másik verziót, amely nem tartalmaz biztonsági réseket.
Licenctisztaság elemzése. Ez nálunk még nem túl népszerű, de ha külföldön dolgozol, akkor ott időnként adót kaphatsz egy nem használható, nem módosítható nyílt forráskódú komponens használatáért. Az engedélyes könyvtár szabályzata szerint ezt nem tehetjük meg. Vagy ha módosítottuk és használjuk, akkor közzé kell tenni a kódunkat. Természetesen senki sem akarja közzétenni a termékeinek kódját, de ettől is megvédheti magát.
Ipari környezetben használt alkatrészek elemzése. Képzeljünk el egy hipotetikus helyzetet, amikor végre befejeztük a fejlesztést, és kiadtuk mikroszolgáltatásunk legújabb kiadását. Csodálatosan él ott – egy hét, egy hónap, egy év. Nem gyűjtjük, nem végezzük a biztonsági ellenőrzéseket, úgy tűnik, minden rendben van. Ám váratlanul, két héttel a megjelenés után, egy kritikus sérülékenység jelenik meg a nyílt forráskódú összetevőben, amelyet ebben a buildben használunk, az ipari környezetben. Ha nem rögzítjük, hogy mit és hol használunk, akkor egyszerűen nem fogjuk látni ezt a sebezhetőséget. Egyes eszközök képesek figyelni az iparban jelenleg használt könyvtárak sebezhetőségeit. Nagyon hasznos.
Jellemzők:
- Különböző politikák a fejlődés különböző szakaszaihoz.
- Alkatrészek monitorozása ipari környezetben.
- A könyvtárak ellenőrzése a szervezeten belül.
- Különféle build rendszerek és nyelvek támogatása.
- Docker képek elemzése.
Néhány példa az iparági vezetőkről, akik nyílt forráskódú elemzéssel foglalkoznak.
Az egyetlen ingyenes ez az OWASP-től. Az első szakaszokban bekapcsolhatja, megnézheti, hogyan működik és mit támogat. Alapvetően ezek mind felhőtermékek, vagy on-premise, de az alapjuk mögött továbbra is az internetre kerülnek. Nem az Ön könyvtárait, hanem kivonatokat vagy saját értékeket küldenek, amelyeket kiszámolnak, és ujjlenyomatokat a szerverükre, hogy információt kapjanak a sebezhetőségekről.
Folyamat integráció
A könyvtárak határellenőrzése, amelyeket külső forrásból töltenek le. Vannak külső és belső tárolóink. Például az Event Central a Nexust futtatja, és szeretnénk biztosítani, hogy ne legyenek „kritikus” vagy „magas” állapotú sebezhetőségek az adattárunkban. A proxykezelést a Nexus Firewall Lifecycle eszközzel konfigurálhatja úgy, hogy az ilyen biztonsági rések megszűnjenek, és ne kerüljenek a belső adattárba.
Integráció a CI-be. Azonos szinten az automatikus tesztekkel, az egységtesztekkel és a fejlesztési szakaszokra való felosztással: dev, test, prod. Minden szakaszban letölthet bármilyen könyvtárat, bármit használhat, de ha valami nehéz van a „kritikus” állapottal, akkor talán érdemes felhívni a fejlesztők figyelmét erre a termelésbe való kiadás szakaszában.
Integráció műtermékekkel: Nexus és JFrog.
Integráció a fejlesztői környezetbe. A választott eszközöknek integrálniuk kell a fejlesztői környezetekkel. A fejlesztőnek hozzá kell férnie a szkennelési eredményekhez a munkahelyéről, vagy képesnek kell lennie arra, hogy saját maga szkennelje be és ellenőrizze a kódot a sebezhetőségek szempontjából, mielőtt elkötelezi magát a CVS mellett.
CD integráció. Ez egy klassz funkció, amit nagyon szeretek, és amiről már beszéltem – új sérülékenységek felbukkanásának nyomon követése ipari környezetben. Valahogy így működik.
Nekünk van Nyilvános összetevő-tárak - néhány külső eszköz és belső tárhelyünk. Azt akarjuk, hogy csak megbízható összetevőket tartalmazzon. Egy kérés proxyja során ellenőrizzük, hogy a letöltött könyvtár nem tartalmaz-e sebezhetőséget. Ha bizonyos, általunk beállított és a fejlesztéssel összehangolt házirendek alá esik, akkor nem töltjük fel, és egy másik verzió használatára szólít fel. Ennek megfelelően, ha valami nagyon kritikus és rossz van a könyvtárban, akkor a fejlesztő nem kapja meg a könyvtárat a telepítési szakaszban - hadd használjon magasabb vagy alacsonyabb verziót.
- Építéskor ellenőrizzük, hogy senki nem csúszott-e el valami csúnyán, minden alkatrész biztonságban van-e, és senki nem hozott semmi veszélyeset a pendrive-ra.
- Csak megbízható összetevőink vannak az adattárban.
- Telepítéskor még egyszer ellenőrizzük magát a csomagot: war, jar, DL vagy Docker image, hogy megbizonyosodjunk arról, hogy az megfelel a szabályzatnak.
- Az iparba lépéskor figyelemmel kísérjük, hogy mi történik az ipari környezetben: megjelennek-e vagy nem jelennek meg a kritikus sérülékenységek.
Dinamikus elemzés – DAST
A dinamikus elemzési eszközök alapvetően eltérnek mindattól, amit korábban elmondtunk. Ez egyfajta utánzása a felhasználónak az alkalmazással végzett munkájának. Ha webes alkalmazásról van szó, kéréseket küldünk, szimulálva a kliens munkáját, rákattintunk az előlapon lévő gombokra, mesterséges adatokat küldünk az űrlapból: idézőjelek, zárójelek, karakterek különböző kódolásban, hogy megnézzük, hogyan működik és dolgoz fel az alkalmazás külső adatok.
Ugyanez a rendszer lehetővé teszi a nyílt forráskódú sablonok sebezhetőségeinek ellenőrzését. Mivel a DAST nem tudja, melyik nyílt forráskódot használjuk, egyszerűen „rosszindulatú” mintákat dob, és elemzi a szerver válaszait:
- Igen, van itt deserializációs probléma, de nem itt.
Ebben nagy kockázatok rejlenek, mert ha ugyanazon a padon hajtja végre ezt a biztonsági tesztet, amellyel a tesztelők dolgoznak, akkor kellemetlen dolgok történhetnek.
- Nagy terhelés az alkalmazáskiszolgáló hálózaton.
- Nincs integráció.
- Lehetőség az elemzett alkalmazás beállításainak megváltoztatására.
- A szükséges technológiákhoz nincs támogatás.
- Beállítási nehézség.
Volt egy helyzetünk, amikor végre elindítottuk az AppScan-t: sokáig próbáltunk hozzáférni az alkalmazáshoz, 3 fiókunk lett, és boldogok voltunk – végre mindent megnézünk! Elindítottunk egy vizsgálatot, és az AppScan első dolga az volt, hogy belépett az adminisztrációs panelbe, átszúrta az összes gombot, megváltoztatta az adatok felét, majd teljesen megölte a szervert. - kéri. A teszteléssel végzett fejlesztés a következőket mondta:
- Srácok, viccelsz velem?! Számot adtunk neked, és te felállítottál egy standot!
Vegye figyelembe a lehetséges kockázatokat. Ideális esetben készítsen egy külön standot az információbiztonság tesztelésére, amely legalább valahogy el lesz szigetelve a környezet többi részétől, és feltételesen ellenőrizze az adminisztrációs panelt, lehetőleg manuális módban. Ez egy pentest – az erőfeszítés azon fennmaradó százalékai, amelyeket most nem veszünk figyelembe.
Érdemes megfontolni, hogy ezt a terhelési tesztelés analógjaként használhatja. Az első szakaszban bekapcsolhat egy 10-15 szálból álló dinamikus szkennert, és megnézheti, mi történik, de általában, amint a gyakorlat azt mutatja, semmi jó.
Néhány forrás, amit általában használunk.
Érdemes kiemelni egy „svájci kés” minden biztonsági szakember számára. Mindenki használja és nagyon kényelmes. Megjelent a vállalati kiadás új demóverziója. Ha korábban ez csak egy különálló segédprogram volt bővítményekkel, most végre egy nagy szervert készítenek a fejlesztők, amelyről több ügynököt is lehet majd kezelni. Ez klassz, ajánlom, próbáld ki.
Folyamat integráció
Az integráció meglehetősen jól és egyszerűen történik: a sikeres telepítés után indítsa el a szkennelést pályázatok az állványra és szkennelés a sikeres integrációs tesztelés után.
Ha az integrációk nem működnek, vagy vannak csonkok és álfüggvények, akkor az értelmetlen és haszontalan – függetlenül attól, hogy milyen mintát küldünk, a szerver továbbra is ugyanúgy válaszol.
- Ideális esetben külön próbapad.
- A tesztelés előtt írja le a bejelentkezési sorrendet.
- Az adminisztrációs rendszer tesztelése csak manuálisan történik.
folyamat
Kicsit általánosítva a folyamatról általában és az egyes eszközök működéséről. Minden alkalmazás más – az egyik jobban működik a dinamikus elemzéssel, a másik a statikus elemzéssel, a harmadik az OpenSource elemzéssel, pentesztekkel vagy valami egészen mással, például eseményekkel .
Minden folyamat ellenőrzést igényel.
Ahhoz, hogy megértse, hogyan működik egy folyamat, és hol lehet javítani, mérőszámokat kell gyűjtenie mindenről, ami csak a keze ügyébe kerül, beleértve a termelési mutatókat, az eszközök mérőszámait és a hibakövetőket.
Minden információ hasznos. Különböző szemszögekből kell megvizsgálni, hogy hol használható jobban ez vagy az az eszköz, hol dől el a folyamat. Érdemes lehet megnézni a fejlesztési válaszidőket, hogy megtudjuk, hol lehet javítani a folyamaton az idő alapján. Minél több adat, annál több szakasz építhető fel a legfelső szinttől az egyes folyamatok részleteiig.
Mivel minden statikus és dinamikus analizátornak megvan a maga API-ja, saját indítási módszere, alapelve, egyeseknek van ütemezőjük, másoknak nincs - egy eszközt írunk AppSec Orchestrator, amely lehetővé teszi, hogy a termékből egyetlen belépési pontot hozzon létre a teljes folyamatba, és egy pontról kezelje azt.
A menedzserek, fejlesztők és biztonsági mérnökök egyetlen belépési ponttal rendelkeznek, ahonnan láthatják, hogy mi fut, konfigurálhatják és futtathatják a vizsgálatot, fogadhatják a vizsgálat eredményeit, és benyújthatják a követelményeket. Igyekszünk eltérni a papírmunkától, mindent emberire fordítani, amit a fejlesztés is használ - a Confluence oldalai állapottal és mérőszámokkal, a Jira vagy a különféle hibakövetők hibái, vagy a CI szinkron/aszinkron folyamatába való integráció /CD.
Kulcs elvezetések
Nem a szerszámok a legfontosabbak. Először gondolja végig a folyamatot, majd alkalmazza az eszközöket. Az eszközök jók, de drágák, így elkezdheti a folyamatot, és kiépítheti a kommunikációt és a megértést a fejlesztés és a biztonság között. Biztonsági szempontból nem kell mindent "megállítani". Fejlesztési szempontból ha van valami magas mega szuperkritikus, akkor azt ki kell küszöbölni, nem pedig szemet hunyni a probléma előtt.
Termékminőség - közös cél biztonság és fejlesztés egyaránt. Egy dolgot teszünk, igyekszünk biztosítani, hogy minden megfelelően működjön, és ne legyen hírnévkockázat vagy anyagi veszteség. Ezért támogatjuk a DevSecOps, SecDevOps megközelítést a kommunikáció javítása és a termék minőségének javítása érdekében.
Kezdje azzal, ami már van: követelmények, architektúra, részleges ellenőrzések, képzések, irányelvek. Nem szükséges azonnal alkalmazni az összes gyakorlatot minden projektre - iteratív mozgás. Nincs egységes szabvány - kísérlet és próbáljon ki különböző megközelítéseket és megoldásokat.
Az információbiztonsági hibák és a funkcionális hibák között egyenlőségjel van.
Automatizálj mindenthogy mozog. Ami nem mozdul, mozgassa és automatizálja. Ha valamit kézzel csinálnak, az nem jó része a folyamatnak. Talán érdemes felülvizsgálni és automatizálni is.
Ha az IS csapat mérete kicsi - használja a Security Champions alkalmazást.
Lehet, hogy amiről beszéltem, az nem fog megfelelni neked, és kitalál valamit a sajátoddal - és ez jó. De válasszon eszközöket a folyamat követelményei alapján. Ne azt nézd, mit mond a közösség, hogy ez az eszköz rossz, ez pedig jó. Talán az ellenkezője lesz igaz a termékére.
A szerszámokra vonatkozó követelmények.
- Alacsony szint Hamis pozitív.
- Megfelelő elemzési idő.
- Egyszerű használat.
- Integrációk elérhetősége.
- A termékfejlesztési ütemterv megértése.
- Az eszközök testreszabásának lehetősége.
Jurij riportját a legjobbak közé választották a 2018-as DevOpsConf-on. Ha még érdekesebb ötletekkel és gyakorlati esetekkel szeretnél megismerkedni, gyere el Skolkovóba május 27-én és 28-án. belül . Még jobb, ha készen áll megosztani tapasztalatait, akkor a beszámolóhoz április 21-ig.
Forrás: will.com