Két kód-analizátorunk, négy dinamikus tesztelési eszközünk, saját készítményeink és 250 szkriptünk volt. Nem mintha mindezekre szükség lett volna a jelenlegi folyamatban, de ha már elkezdtem bevezetni a DevSecOps-t, akkor érdemes végigmenni a folyamaton.
. A karakterek alkotói: Justin Roiland és Dan Harmon.
Mi az a SecDevOps? És a DevSecOps? Miben különböznek? Mi az alkalmazásbiztonság? Miért nem működik a klasszikus megközelítés? Minden kérdésre válaszol. Júri Sábalin a Swordfish Security. Júri mindent részletesen meg fog válaszolni, és át fogja tekinteni a klasszikus alkalmazásbiztonsági modellről a DevSecOps folyamatra való átállás problémáit: hogyan közelítsük meg helyesen a biztonságos fejlesztési folyamat beépítését a DevOps folyamatba anélkül, hogy bármit is tönkremennénk, hogyan kell végigmenni a biztonsági tesztelés főbb lépésein, milyen eszközöket lehet alkalmazni, miféle eltérések vannak köztük, és hogyan kell ezeket helyesen beállítani, hogy elkerüljük a csapdákat.
A előadóról: Júri Sábalin – Chief Security Architect a Swordfish Security. A SSDL bevezetéséért felel, a különféle alkalmazáselemző eszközök integrálásáért a fejlesztési és tesztelési ökoszisztémába. 7 éves tapasztalattal rendelkezik információbiztonság terén. Dolgozott az Alfa-Banknál, a Sberbanknál és a Positive Technologies-nél, amely szoftvereket fejleszt és szolgáltatásokat nyújt. Nemzetközi konferenciák előadója, mint a ZerONights, PHDays, RISSPA, OWASP.
Alkalmazásbiztonság: miről van szó?
Alkalmazásbiztonság – ez a biztonság egyik ága, amely a programok biztonságával foglalkozik. Ez nem vonatkozik az infrastruktúrára vagy a hálózati biztonságra, hanem konkrétan arra, amit írunk és amin a fejlesztők dolgoznak – ez a program konkrét hibái és sebezhetőségei.
Irányvonal — Security development lifecycle – a Microsoft által kifejlesztett. A diagramon a kanonikus SDLC modell látható, amelynek fő célja a biztonság részvétele a fejlesztés minden szakaszában, az igényektől a kiadásig és a termelésbe való átmenetig. A Microsoft rájött, hogy a piacon túl sok hiba van, ezek egyre gyakoribbak, és ezzel kezdeni kell valamit, ezért ezt a megközelítést javasolták, amely kanonikus lett.
Az alkalmazásbiztonság és az SSDL nem a sebezhetőségek felderítésére, mint általában vélik, hanem azok megjelenésének megakadályozására irányulnak. Az idő múlásával a Microsoft kanonikus megközelítése javult, fejlődött, és mélyebb részletes betekintést nyert.
A kanonikus SDLC részletesen kidolgozott különböző metodológiákban - OpenSAMM, BSIMM, OWASP. A metodológiák eltérnek, de összességében hasonlóak.
Building Security In Maturity Model
Ami a legjobban tetszik nekem BSIMM — . A metodológia alapja az Application Security folyamatának 4 területre való felosztása: Governance, Intelligence, SSDL Touchpoints és Deployment. Minden területen 12 gyakorlat található, amely 112 tevékenység formájában van bemutatva.
Minden 112 tevékenységnek van 3 érettségi szintje: kezdeti, középső és haladó. Az összes 12 gyakorlatot szakaszok szerint lehet tanulmányozni, fontos elemeket kiemelni, kideríteni, hogyan lehet őket bevezetni, és fokozatosan hozzáadni elemeket, például statikus és dinamikus kódellenőrzést vagy code review-t. Megtervezed a tervet, és azon nyugodtan dolgozol a választott tevékenységek bevezetése során.
Miért DevSecOps
A DevOps egy átfogó folyamat, amelyben foglalkozni kell a biztonsággal.
Kezdetben a biztonság ellenőrzését feltételeztem. A gyakorlatban a biztonsági csapatok száma sokkal kisebb volt, mint most, és nem mint folyamat résztvevői, hanem mint ellenőrző és felügyelő szerv működtek, amely követelményeket támasztott és az elkészült termék minőségét ellenőrizte a kiadás végén. Ez egy klasszikus megközelítés, amelyben a biztonsági csapatok a fejlesztéstől távol helyezkedtek el, és nem születtek részt venni a folyamatban.
A fő probléma pontosan az, hogy a kibervédelem különállóan működik a fejlesztéstől. Általában van egy kibervédelmi keret, amelybe 2-3 nagy és drága eszköz tartozik. Félévente érkezik egy forráskód vagy alkalmazás, amelyet ellenőrizni kell, és évente végeznek . Ez mind ahhoz vezet, hogy a kereskedelmi kiadás határideje elcsúszik, és a fejlesztőre hatalmas mennyiségű sebezhetőség zúdul az automatizált eszközökből. Mindezt lehetetlen feldolgozni és javítani, mert az előző félévről kapott eredményekkel még nem dolgoztak fel, és itt van egy újabb adag.
Cégünk működése során azt látjuk, hogy a biztonság minden területen és iparágban megérti, hogy ideje felzárkózni és egy kerékben forogni a fejlesztéssel - az . A DevSecOps paradigma remekül illeszkedik a rugalmas fejlesztési metodológiához, amelyben minden kiadás és iteráció során részt vesz és támogathat.
Áttérés DevSecOps-ra
A Security Development Lifecycle legfontosabb szava a „folyamat”Ezt meg kell értenie, mielőtt gondolkodna az eszközök vásárlásáról.
Csak az eszközök beillesztése a DevOps folyamatába nem elegendő - fontos a résztvevők közötti interakció és megértés.
Fontosabbak az emberek, nem az eszközök.
Gyakran a biztonságos fejlesztési folyamat tervezése az eszköz kiválasztásával és megvásárlásával kezdődik, majd az eszköz integrálásának próbálkozásaival végződik a jelenlegi folyamatba, amelyek végül csak próbálkozások maradnak. Ez szomorú következményekhez vezet, mivel minden eszköz saját sajátosságokkal és korlátokkal rendelkezik.
Általános eset, amikor a biztonsági osztály egy jó, drága eszközt választott széles lehetőségekkel, és megkeresi a fejlesztőket - beilleszteni a folyamatba. De nem sikerül - a folyamat úgy van felépítve, hogy a már megvásárolt eszköz korlátai nem illeszkednek a jelenlegi paradigmába.
Elsősorban írja le, hogy milyen eredményt szeretne, és milyen lesz 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 eszközöket vennél, nézd meg, mi van már a birtokodban. Minden vállalatnak vannak biztonsági követelményei, amelyek a fejlesztésre vonatkoznak, vannak ellenőrzések, pentestek - miért ne alakítanánk mindezt át egy érthető és mindenki számára kényelmes formába?
Általában a követelmények egy papíralapú könyv, ami a polcon hever. Volt már példa arra, hogy belépünk egy vállalatba, hogy megnézzük a folyamatokat, és megkérdezzük, hogy mutassák meg a szoftverre vonatkozó biztonsági követelményeket. A szakember, aki ezzel foglalkozott, sokáig keresett:
— Most, valahol a jegyzetek között volt egy nyom, hol található ez a dokumentum.
Végül egy hét múlva megkaptuk a dokumentumot.
A követelmények, ellenőrzések és egyebek számára hozzon létre egy oldalt, például a Confluence-on. Ez mindenkinek kényelmes.
Könnyebb átalakítani azt, ami már létezik, és használni az induláshoz.
Használj Security Championst.
Általában egy átlagos vállalatnál 100-200 fejlesztőre jut egy biztonsági szakember, aki több feladatot lát el, és fizikailag nem képes mindent ellenőrizni. Még ha mindent meg is tesz - egyedül nem tudja ellenőrizni az egész kódot, amelyet a fejlesztők generálnak. Az ilyen esetekre dolgozták ki a koncepciót - .
A Security Champion egy olyan személy a fejlesztőcsapatban, aki érdeklődik a terméke biztonsága iránt.
A Security Champion a fejlesztőcsapat belépési pontja és a biztonság evangelistája egy személyben.
Általában, amikor egy biztonsági szakember érkezik a fejlesztőcsapatba, és rámutat egy hibára a kódban, meglepő választ kap:
— Ki is vagy te? Először látlak. Minden rendben van – a főnököm a code review során azt mondta, hogy «apply», haladunk tovább!
Ez egy tipikus helyzet, mert a fejlesztők sokkal jobban bíznak a tapasztalt kollégákban, akikkel folyamatosan együtt dolgoznak és akik részt vesznek a code review-ban. Ha a biztonsági szakember helyett a Security Champion mutat rá a hibára és annak következményeire, akkor a szava nagyobb súlyt kap.
Emellett a fejlesztők jobban ismerik a saját kódjukat, mint bármely biztonsági szakember. Az általában 5 projekttel rendelkező statikus analízis eszköz felhasználója számára nehéz észben tartani az összes részletet. A Security Championok ismerik a terméküket: tudják, hogy mi mivel lép interakcióba és mire kell először figyelni – ők hatékonyabbak.
Tehát érdemes elgondolkodni a Security Championok bevezetésén és a biztonsági csapat befolyásának bővítésén. A Champion számára is hasznos: szakmai fejlődés egy új területen, technikai látókör bővítése, vezetői és vezetői készségek fejlesztése, piaci érték növelése. Ez egyfajta társadalmi mérnökség, a «szemed» a fejlesztőcsapatban.
Tesztelési lépések
azt mondja, hogy a befektetett 20% az eredmény 80%-át hozza. Ezek a 20% a támogatható alkalmazáselemzési gyakorlatok. Ilyen aktivitások például a statikus elemzés – SAST, dinamikus elemzés – DAST, és Open Source ellenőrzés. Részletesebben bemutatom az aktivitásokat, valamint az eszközöket, amikkel általában szembesülünk a bevezetésük során, és hogy hogyan lehet ezt helyesen csinálni.
Az eszközök fő problémái
Felsorakoztatom az összes eszköz esetében releváns problémákat, amelyek figyelmet igényelnek. Részletesebben is megvizsgálom őket, hogy ne ismételjem magam később.
Hosszú ideig tartó elemzés. Ha a kötelező tesztelés és az építés 30 percet vesz igénybe a kiadás előtt, akkor az információbiztonsági ellenőrzések egy napot fognak igénybe venni. Senki sem akarja lassítani a folyamatot. Vegye figyelembe ezt a sajátosságot, és vonja le a következtetéseket.
Magas False Negative vagy False Positive szint. Minden termék különböző, mindannyian különböző keretrendszereket és saját kódírási stílust használnak. Különböző kódalapok és technológiák esetén az eszközök különböző False Negative és False Positive szintet mutathatnak. Ezért nézze meg, hogy pontosan mit tesz az ön cégében és az ön alkalmazásaiban mutat jó és megbízható eredményt.
Nincsenek integrációk a meglévő eszközökkel. Nézze az eszközöket az integrációk szempontjából, amit már használ. Például, ha van Jenkins vagy TeamCity - ellenőrizze az eszközök integrációját éppen e szoftverrel, ne a GitLab CI-vel, amelyet nem használ.
A testreszabás hiánya vagy túlzott összetettsége. Ha az eszköznek nincs API-já, akkor minek szükséges? Minden, amit a felületen végrehajthat, elérhetőnek kell lennie az API-n keresztül. Ideális esetben az eszköznek testreszabási lehetőségekkel kell rendelkeznie az ellenőrzésekhez.
Nincs a termék fejlesztésének Roadmap-ja. A fejlesztés nem áll meg, mindig új keretrendszereket és funkciókat használunk, a régi kódot új nyelvekre írjuk át. Biztosak akarunk lenni abban, hogy az eszköz, amit megvásárolunk, támogatni fogja az új keretrendszereket és technológiákat. Ezért fontos tudni, hogy a terméknek van valós és helyes fejlesztési terve.
A folyamat jellemzői
Az eszközök sajátosságai mellett vegye figyelembe a fejlesztési folyamat sajátosságait is. Például a fejlesztés zavarása tipikus hiba. Nézzük meg, milyen további sajátosságokat kell figyelembe venni, és mire kell figyelni a biztonsági csapatnak.
A fejlesztési és kiadási határidők be nem tartásának elkerülése érdekében hozzon létre különböző szabályokat és show stoppers — a folyamat leállításának kritériumait a sebezhetőségek jelenléte esetén — különböző környezetekhez. Például megértjük, hogy a jelenlegi ágon a fejlesztői tesztkörnyezetben vagy UAT-n haladunk, így nem állítjuk le és nem mondjuk:
— Ön itt sebezhetőségekkel rendelkezik, nem mehet tovább!
Ezen a ponton fontos jelezni a fejlesztőknek, hogy biztonsági problémák vannak, amelyekre érdemes figyelni.
A sebezhetőségek létezése nem akadályozza meg a további tesztelést.: manuális, integrált vagy manuális. Másrészt szükségünk van arra, hogy valahogyan növeljük a termék biztonságát, és hogy a fejlesztők ne hanyagolják el azt, amit a biztonság talál. Ezért néha így járunk el: a standon, amikor kiadjuk a fejlesztői környezetbe, egyszerűen értesítjük a fejlesztést:
— Fiúk, problémáitok vannak, kérlek, figyeljetek rájuk.
A UAT szakaszban ismét figyelmeztetjük a sebezhetőségekre, a piaci megjelenés szakaszában pedig azt mondjuk:
— Fiúk, többször figyelmeztettünk, ti nem csináltatok semmit — ezzel nem engedünk ki titeket.
Ha a kódra és a dinamikára gondolunk, akkor csak az éppen most írt funkciók és kód sebezhetőségeit kell megjeleníteni és figyelmeztetni róluk. Ha a fejlesztő 3 pixellel elmozdít egy gombot, és mi azt mondjuk neki, hogy SQL-injektált, és sürgősen ki kell javítania — ez helytelen. Csak arra a kódra figyelj, ami most íródik, és az általa hozott változtatásra az alkalmazásban.
Tegyük fel, hogy van egy funkcionális hiba — hogy az alkalmazásnak hogyan nem szabad működnie: a pénz nem kerül átutalásra, gombnyomásra nem lép tovább 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ének, hanem a biztonságnak a szempontjából.
Nem minden szoftverminőségi probléma biztonsági probléma. De minden biztonsági probléma a szoftverminőséggel függ össze. Sherif Mansour, Expedia.
Mivel minden sebezhetőség ugyanolyan hiba, ott kell lennie, ahol az összes fejlesztési hiba van. Ezért felejtsétek el a jelentéseket és a rémisztő PDF-eket, amelyeket senki sem olvas.
Amikor egy olyan cégben dolgoztam, amely fejlesztéssel foglalkozott, kaptam egy jelentést a statikus elemző eszközöktől. Kinyitottam, megdöbbentem, főztem egy kávét, átlapoztam 350 oldalt, bezártam, és tovább dolgoztam. A nagy jelentések halott jelentések. Általában nem jutnak sehova, az e-mailek törlődnek, elfelejtődnek, elvesznek, vagy a vállalkozás azt mondja, hogy vállalja a kockázatokat.
Mit kell tenni? A megerősített hibákat, amelyeket találtunk, egyszerűen átkonvertáljuk fejlesztésre alkalmas formába, például a Jira backlogjába helyezzük. A hibákat priorizáljuk és a prioritásoknak megfelelően javítjuk ki őket, párhuzamosan a funkcionális hibákkal és a tesztelések hibáival.
Statikus elemzés - SAST
Ez a kód sebezhetőségeinek elemzése., de ez nem ugyanaz, mint a SonarQube. Nem csak minták vagy stílus alapján ellenőrzünk. Az elemzésben számos megközelítést alkalmazunk: sebezhetőségi fára, , konfigurációs fájlok elemzésére. Ez mind a kódra vonatkozik.
A megközelítés előnyei: sebezhetőségek korai felfedezése a fejlesztés során, amikor még nincsenek állványok és kész eszközök, és a fokozatos szkennelés lehetősége: a kód azon részének szkennelése, amely megváltozott, és csak annak a funkciónak, amin most dolgozunk, csökkentve ezzel a szkennelési időt.
Hátrányok — a szükséges nyelvek támogatásának hiánya.
A szükséges integrációk, amelyeknek benne kell lenniük az eszközökben, véleményem szerint:
- Integrációs eszköz: Jenkins, TeamCity és Gitlab CI.
- Fejlesztői környezet: Intellij IDEA, Visual Studio. A fejlesztőnek kényelmesebb nem belemerülni egy megérthetetlen felületbe, amelyet még meg is kell tanulnia, hanem közvetlenül a munkaterületén, a saját fejlesztői környezetében látni az összes szükséges integrációt és a sebezhetőségeket, amelyeket felfedezett.
- Kódellenőrzés: SonarQube és manuális felülvizsgálat.
- 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 léteznek Open Source megoldások, amelyek szintén jók a folyamat kipróbálására.
Az SAST Open Source nem találhat meg hatalmas mennyiségű sebezhetőséget, vagy bonyolult adatáramlást, de a folyamat kiépítésekor használni kell őket. Segítenek megérteni, hogyan épül fel a folyamat, ki fog felelni a bugokért, ki fog jelenteni, ki - számot adni. Ha az a célja, hogy a kódja biztonságát az alapoktól építse fel - használjon Open Source megoldásokat.
Hogyan lehet ezt integrálni, ha a kezdettől fogva nem rendelkezik semmivel: sem CI-vel, sem Jenkins-el, sem TeamCity-vel? Vizsgáljuk meg az integrációkat a folyamatban.
Integráció CVS szinten
Ha van Bitbucket vagy GitLab, integrációt hozhatunk létre .
Eseményalapú — pull request, commit. A kódot átvizsgálja, és a build állapotán láthatja, hogy a biztonsági ellenőrzés sikeres volt-e vagy sem.
Visszajelzés. Természetesen a visszajelzés mindig szükséges. Ha csupán elvégezte a biztonsági oldalon, bedobta egy dobozba, és senkinek sem mondott róla semmit, majd a hónap végén felhalmozódik egy csomó hiba – ez nem helyes és nem is jó.
Integráció a kódellenőrző rendszerrel
Egyszer fontos projektek esetén az AppSec technikai felhasználót állítottuk be alapértelmezett ellenőrnek. A pull requesten az ellenőr hozzárendel egy státuszt: „elfogadva” vagy „munkát igényel” – vagyis minden rendben, vagy javítani kell, és linkeket arra, hogy pontosan mit kell javítani. Az éles verzió integrációjához tiltotta a merge-t, ha a biztonsági teszt nem teljesült. Ezt manuális kódellenőrzésbe építettük be, és a folyamat többi résztvevője a biztonsági státuszokat látta kifejezetten erre a folyamatra vonatkozóan.
Integráció a SonarQube-al
Sokaknak van a kód minősége szempontjából. Itt is ugyanez a helyzet – ugyanazokat a kapukat meg lehet csinálni csak a SAST eszközökhöz. Ugyanaz a felület, ugyanaz a minőségkapu, csak a neve biztonsági kapu. És ha SonarQube-ot használó folyamatot állított be, nyugodtan integrálhat mindent oda.
Integráció CI szinten
Itt is minden eléggé egyszerű:
- Ugyanazon a szinten az automatizált tesztekkel, egységtesztekkel.
- Fejlesztési fázisok szerinti elkülönítés: dev, test, prod. Különböző szabálykészletek vagy különböző hibafeltételek bevonhatók: megállítjuk a buildet, vagy nem állítjuk meg.
- Szincron és aszinkron végrehajtás. Várjuk a biztonsági tesztek befejezését vagy nem várjuk. Azaz csak elindítottuk őket, és tovább haladunk, majd érkezik a státusz, hogy minden rendben van vagy nem.
Ez mind egy tökéletes rózsaszín világban van. A valós életben nincs ilyen, de törekszünk rá. A biztonsági ellenőrzések eredményeinek hasonlónak kell lenniük az egységtesztek eredményeihez.
Például, vettünk egy nagy projektet, és úgy döntöttünk, hogy mostantól SAST-tal fogjuk szkennelni – rendben. Betettük ezt a projektet a SAST-ba, 20 000 sebezhetőséget kaptunk, és akaratunkon kívül elfogadtuk, hogy minden rendben van. 20 000 sebezhetőség – ez a mi technikai adósságunk. Az adósságot egy dobozba tesszük, lassan szépen elsimítjuk, és a hibákat bejegyezzük a hiba-trackerbe. Felbérlünk egy céget, mindent csinálunk magunk, vagy a Security Champions segítenek nekünk – a technikai adósság csökkenni fog.
A minden újonnan megjelenő sebezhetőséget az új kódban is úgy kell kezelni, mint a hibákat az egység vagy az automatikus tesztekben. Hogy úgy mondjam, elindult a build, végigpróbáltuk, két teszt megbukott, és két biztonsági teszt is. Rendben – elmentünk, megnéztük, mi történt, javítottunk egyet, javítottunk a másikon, legközelebb végigpróbáltuk – minden rendben, új sebezhetőségek nem jelentkeztek, a tesztek nem buktak meg. Ha a feladat mélyebben érinti a dolgot, és jól meg kell érteni, vagy ha a sebezhetőségek javítása jelentős részeket érint a háttérben: bejegyeztünk egy hibát a hiba-trackerbe, amelyet priorizálni kell és javítani. Sajnálatos módon a világ nem tökéletes, és néha a tesztek megbuknak.
A security gate példája – hasonló a minőségi kapuhoz, a kódban lévő sebezhetőségek jelenléte és számossága alapján.
Integrálás a SonarQube-hoz – a bővítmény telepítése, minden nagyon kényelmes és klassz.
Integráció a fejlesztési környezettel
Integrációs lehetőségek:
- Szkennelés indítása a fejlesztési környezetből még a commit előtt.
- Eredmények megtekintése.
- Eredmények elemzése.
- Szinkronizálás a szerverrel.
Körülbelül így néz ki az eredmények megszerzése a szerverről.
A mi fejlesztési környezetünkben csak megjelenik egy további pont, amely jelzi, hogy a szkennelés során ilyen sebezhetőségek kerültek elő. Azonnal lehetőség van a kód javítására, a javaslatok átnézésére és . Mindez a fejlesztő munkaterületén van, ami nagyon kényelmes – nem kell más linkekre járni és valami mást keresni.
. Nem kell semmit fizetni. Nem kell megállapodni arról, hogy telepítsük a rendszert a laptopunkra vagy szerverünkre. Nincsenek rejtett díjak. Ugyanakkor egyetlen más Open Source adatbázistechnológia sem tud versenyezni a sebességgel a
Ez a kedvenc témám. Mindenki használ Open Source könyvtárakat – miért kellene rengeteg felesleges kódot írni, amikor kész könyvtárakat vehetünk igénybe, amelyek már mindent megvalósítottak?
Persze, így van, de a könyvtárakat is emberek írják, magukban foglalják a bizonyos kockázatokat, és ott is előfordulnak sebezhetőségek, amelyekről időszakosan vagy folyamatosan tájékoztatnak. Ezért van a következő lépés az Application Securityben – az Open Source komponensek elemzése.
Open Source elemzés – OSA
Az eszköz három nagy szakaszt tartalmaz.
Sebezhetőségek keresése a könyvtárakban. Például az eszköz tudja, hogy használunk egy adott könyvtárat, és hogy a vagy a hibakövetőkben vannak olyan sebezhetőségek, amelyek ehhez a könyvtárverzióhoz tartoznak. Amikor megpróbáljuk használni, az eszköz figyelmeztetést ad ki, hogy a könyvtár sebezhető, és javasolja egy másik verzió használatát, ahol nincsenek sebezhetőségek.
Licenc tisztasági elemzés. Nálunk ez még nem túl népszerű, de ha külföldön dolgozik, akkor ott időszakonként előfordulhat, hogy büntetést kap a nyílt forráskódú komponens használatáért, amelyet nem lehet használni vagy módosítani. A könyvtár licencpolitikája szerint ezt nem tehetjük. Vagy ha módosítottuk és használjuk, akkor kötelező közzétennünk a saját kódunkat. Természetesen senki sem akarja közzétenni a termékeinek kódját, de erre is van védekezési lehetőség.
A ipari környezetben használt komponensek elemzése. Képzeljünk el egy hipotetikus helyzetet, hogy végre befejeztük a fejlesztést és kiadtuk a legutolsó verzióját a mikroszervizünknek. Ott csodálatosan működik – egy hétig, egy hónapig, egy évig. Nem futtatunk ellenőrzéseket, a biztonsági vizsgálatokat nem végezzük, úgy tűnik, minden rendben van. De hirtelen két héttel a kiadás után kritikus sebezhetőség kerül napvilágra a használt Open Source komponensben, amely pontosan ebben a buildben szerepel az ipari környezetben. Ha nem jegyezzük fel, hogy mit és hol használunk, akkor ezt a sebezhetőséget egyszerűen nem fogjuk észrevenni. Néhány eszköz lehetőséget ad a könyvtárak sebezhetőségének figyelésére, amelyek jelenleg az iparban használatban vannak. Ez nagyon hasznos.
Lehetőségek:
- Különböző politikák a fejlesztés különböző szakaszaira.
- Kompontok figyelése az ipari környezetben.
- Könyvtárak ellenőrzése a szervezet keretein belül.
- Különböző build rendszerek és nyelvek támogatása.
- Docker képek elemzése.
Néhány példa területvezetőkre, akik Open Source elemzéssel foglalkoznak.
Az egyetlen ingyenes közülük – ez az OWASP. Ezt a korai szakaszokban be lehet kapcsolni, hogy megnézze, hogyan működik és mit támogat. Főként ezek felhőalapú termékek, vagy on-premise, de az alapjuk így is az interneten keresztül kerül továbbításra. Nem az Ön könyvtárait küldik el, hanem hasheket vagy saját kalkulált értékeiket, valamint ujjlenyomatokat a saját szerverükre, hogy értesítést kapjanak a sebezhetőségekről.
Integráció a folyamatba
A külső forrásokból letöltött könyvtárak ellenőrzése. Van külső és belső tárolónk. Például az Event Centralon belül Nexus működik, és azt szeretnénk, hogy a belső tárolónkban ne legyenek "kritikus" vagy "magas" besorolású sebezhetőségek. A Nexus Firewall Lifecycle eszköz segítségével beállítható a proxyzás, hogy az ilyen sebezhetőségek kiszűrődjenek, és ne juthassanak be a belső tárolóba.Integráció a CI-ba
. Az automatikus tesztek, egységtesztek és a fejlesztési szakaszok (dev, test, prod) szétválasztásának egy szintjén: minden szakaszban letölthet bármilyen könyvtárat, használhat bármit, de ha ott van valami komoly, ami "kritikus" besorolású - talán érdemes, ha a fejlesztők figyelnek erre a kiadás előtti szakaszban.Integráció a műveletekhez
: Nexus és JFrog.Integráció a fejlesztési környezetbe.
A kiválasztott eszközöknek integrálniuk kell a fejlesztési környezetekkel. A fejlesztőnek a saját munkahelyéről hozzáférése kell, hogy legyen a szkennelési eredményekhez, vagy lehetősége, hogy önállóan szkennelje és ellenőrizze a kódot a kompatibilitásra az aláírás előtt a CVS-ben. Integráció a CD-be.
Ez egy nagyszerű funkció, ami nagyon tetszik, és amiről már beszéltem - a új sebezhetőségek megjelenésének figyelése ipari környezetben. Ez körülbelül így működik. Van nekünk
Közösségi Komponens Tárolók Public Component Repositories — külső eszközök és a belső tárolónk. Azt akarjuk, hogy csak megbízható komponenst tartalmazzon. A kérés közvetítésekor ellenőrizzük, hogy a letöltött könyvtárnak nincsenek biztonsági rései. Ha megfelel a megállapított politikáinknak, amelyeket kötelezően egyeztetünk a fejlesztéssel, akkor nem töltjük le, és érkezik egy üzenet, hogy használjon egy másik verziót. Ennek megfelelően, ha a könyvtárban valóban kritikus és rossz dolog van, akkor a fejlesztő már a telepítési fázisban nem kapja meg a könyvtárat — inkább használjon magasabb vagy alacsonyabb verziót.
- A build során ellenőrizzük, hogy senki sem csempészett be semmi rosszat, hogy minden komponens biztonságos, és senki sem hozott be a flash meghajtón semmi veszélyeset.
- A tárolónkban csak megbízható komponensek találhatók.
- A telepítéskor ismét ellenőrizzük magát a csomagot: war, jar, DL vagy Docker-kiépítés, hogy megfelel-e a politikának.
- A termelésbe lépéskor figyelemmel kísérjük, mi történik az ipari környezetben: megjelennek-e vagy nem jelennek meg kritikus biztonsági rések.
Dinamikus analízis — DAST
A dinamikus analízis eszközök lényegesen eltérnek mindattól, amit eddig mondtunk. Ez egyfajta felhasználói munkafolyamat szimuláció az alkalmazással. Ha webalkalmazásról van szó, akkor kérdéseket küldünk, szimulálva a kliens működését, megnyomjuk a gombokat az elülső felületen, mesterséges adatokat küldünk a formából: idézőjelek, zárójelek, karakterek különböző kódolásokban, hogy megnézzük, hogyan működik az alkalmazás és hogyan kezeli a külső adatokat.
Ez a rendszer lehetővé teszi a sablon biztonsági réseinek ellenőrzését nyílt forráskódú szoftverekben. Mivel a DAST nem tudja, milyen nyílt forráskódot használunk, egyszerűen „rosszindulatú” mintákat dobál és elemzi a szerver válaszait:
— Aha, itt van egy deszerializációs probléma, itt pedig nincs.
Ebben nagy kockázatok rejlenek, mert ha ezt a biztonsági tesztet ugyanazon a rendszeren hajtja végre, amelyen a tesztelők dolgoznak - kellemetlen dolgok történhetnek.
- Magas terhelés a hálózat alkalmazásszerverén.
- Nincsenek integrációk.
- Lehetőség a vizsgált alkalmazás beállításainak módosítására.
- Nincs szükséges technológiák támogatása.
- A beállítás bonyolultsága.
Volt egy helyzetünk, amikor végre elindítottuk az AppScan-t: sokáig küzdöttünk az alkalmazás eléréséért, kaptunk 3 fiókot, és örültünk - végre mindent ellenőrizhetünk! Elindítottuk a szkennelést, és az első dolog, amit az AppScan tett - belépett az admin panelbe, megnyomkodta az összes gombot, megváltoztatta az adatok felét, majd teljesen leállította a szervert a saját -kérésekkel. A fejlesztés a tesztelés során azt mondta:
— Fiúk, vicceltek?! Adtunk nektek fiókokat, és ti tönkretettétek a környezetet!
Figyelembe kell venni a lehetséges kockázatokat. Ideális esetben készítsetek egy külön tesztelési környezetet az IT biztonság számára, ami legalább valamennyire izolált a többi környezettől, és az admin panelt célszerű kézi módban ellenőrizni. Ez egy pentest - az a néhány százaléknyi erőfeszítés, amit most nem veszünk figyelembe.
Érdemes megjegyezni, hogy ezt terhelési tesztelésként is használhatjuk. Az első szakaszban lehet aktiválni a dinamikus szkennert 10-15 folyamattal, és megnézni, hogy mi születik, de általában, ahogy a gyakorlat mutatja, semmi jó nem szokott történni.
Néhány forrás, amit általában használunk.
Érdemes kiemelni — ez a "svájci bicska" bármely biztonsági szakember számára. Mindenki használja, és nagyon kényelmes. Most jelent meg egy új demó verzió az enterprise kiadásból. Ha korábban ez csak egy önálló eszköz volt pluginokkal, most végre a fejlesztők egy nagy szervert készítenek, ahonnan több ügynököt lehet kezelni. Ez nagyszerű, javaslom, hogy próbáljátok ki.
Integráció a folyamatba
Az integráció meglehetősen jól és egyszerűen történik: a szkennelés elindítása a sikeres telepítés után az alkalmazás a környezetbe és a szkennelés az integrációs tesztelés sikeres elvégzése után.
Ha az integrációk nem működnek, vagy ha ott vannak a helyettesítő és mock-funkciók, akkor ez értelmetlen és haszontalan - bármilyen mintát küldünk, a szerver akkor is ugyanúgy fog válaszolni.
- Ideális esetben - külön környezet a teszteléshez.
- A tesztelés megkezdése előtt rögzítsétek a bejelentkezési sorrendet.
- A rendszergazdai rendszer tesztelése - csak kézi.
Folyamat
Kicsit általánosítva a folyamatról és az egyes eszközök működéséről, különösen. Minden alkalmazás különböző - az egyiknél a dinamikus elemzés működik jobban, a másiknál a statikus, a harmadiknál az OpenSource analízis, pentestek vagy akár teljesen más, például események. .
Minden folyamatnak szüksége van ellenőrzésre.
Ahhoz, hogy megértsük, hogyan működik a folyamat és hol lehetne azt javítani, mérőszámokat kell gyűjtenünk mindenhol, ahol csak tudunk, beleértve a gyártási mutatókat, az eszközökből származó metrikákat és a hibakövetőkből származó adatokat.
Bármilyen adat hasznos. Különböző szempontokból kell nézni, hogy hol alkalmazható jobban az adott eszköz, hol gyengélkedik a folyamat. Lehet, hogy érdemes megnézni a fejlesztési válaszidőt, hogy megértsük, hol lehetne javítani a folyamaton az idő alapjában. Minél több adat áll rendelkezésre, annál több szempontot lehet felépíteni a felsőbb szinttől a minden egyes folyamat részleteiig.
Mivel minden statikus és dinamikus elemzőnek saját API-ja van, saját elindítási módja, elve, egyeseknek ütemezői vannak, másoknak nincsenek – egy eszközt írunk AppSec Orchestrátor, amely lehetővé teszi, hogy egységes belépési pontot hozzunk létre az egész folyamatban, és egyetlen pontról irányíthassuk azt.
A menedzsereknek, fejlesztőknek és biztonsági mérnököknek van egy belépési pontja, ahonnan láthatják, mi van futásban, beállíthatják és elindíthatják a szkennelést, megkaphatják a szkennelés eredményeit, és követelményeket nyújthatnak be. Arra törekszünk, hogy kerüljük a papírmunkát, és mindent emberi nyelvre fordítsunk, amit a fejlesztés használ – Confluence oldalakat státusz- és metrikákkal, hibákat a Jira-ban vagy különböző hibakövetőkben, vagy integráljunk a szinkron / aszinkron folyamathoz a CI / CD-ben.
Főbb tanulságok
Az eszközök nem a legfontosabbak. Először átgondolni a folyamatot – csak utána bevezetni az eszközöket. Az eszközök jók, de drágák, ezért érdemes a folyamatra koncentrálni, és felállítani az együttműködést és megértést a fejlesztés és a biztonság között. A biztonság szempontjából – nem szükséges mindent megállítani. A fejlesztés szempontjából – ha van valami hihetetlenül kritikus, azt kezelni kell, nem pedig szemet hunyni a probléma felett.
A termék minősége – közös cél a biztonság és a fejlesztés szempontjából. Egy közös célt szolgálunk, hogy minden rendben működjön, és elkerüljük a reputációs kockázatokat és a pénzügyi veszteségeket. Éppen ezért népszerűsítjük a DevSecOps, SecDevOps megközelítést, hogy javítsuk a kommunikációt és a termék minőségét.
Kezdje azzal, ami már megvan: követelmények, architektúra, részleges ellenőrzések, képzések, irányelvek. Nem szükséges az összes gyakorlatot azonnal alkalmazni minden projektre — haladjon iterációnként. Nincs egyetlen standard — kísérletezzen és próbáljon ki különböző megközelítéseket és megoldásokat.
Az IB hibák és a funkcionális hibák között egyenlőség jel áll..
Automatizáljon mindent, ami mozog. Minden, ami nem mozog — mozgassa és automatizálja. Ha valamit kézzel végeznek, az nem jó folyamat. Lehet, hogy érdemes újragondolni és azt is automatizálni.
Ha az IB csapat mérete kicsi — használja a Security Championokat..
Lehetséges, hogy amit mondtam, nem felel meg Önnek, és kitalál valami sajátot — és ez rendben van. De válassza ki az eszközöket, a saját folyamataira vonatkozó követelmények alapján. Ne nézze, mit mond a közösség, hogy ez az eszköz rossz, míg az jó. Lehetséges, hogy az Ön termékén a helyzet éppen ellenkező.
Követelmények az eszközökkel szemben.
- Alacsony hamis pozitív arány.
- Megfelelő elemzési idő.
- Könnyű használhatóság.
- Integrációk elérhetősége.
- A termék fejlesztési ütemtervének megértése.
- Az eszközök testreszabásának lehetősége.
Júri előadását az egyik legjobbnak választották a DevOpsConf 2018-on. Ha szeretne még több érdekes ötlettel és gyakorlati esettanulmánnyal találkozni, jöjjön el május 27-28-án Szkólkovóba a keretein belül . És még jobb, ha kész megosztani tapasztalatait, akkor az előadásra április 21-ig.
Forrás: habr.com
