A folyamatos biztonsági fejlesztési életciklus (folyamatos SDL) megközelítés alkalmazása

Az innováció a digitális korban a szervezet életköre, és engedélyezni és védeni kell. Az innovációs biztonság védi az innováció folyamatait és adatait a kibertámadásokkal szemben. A digitális korban az innováció a DevOps vagy a DevSecOps metódus használatával történő alkalmazások fejlesztésének formájában történik. Ez a megközelítés lehetővé teszi a szervezetek számára, hogy gyorsan újítsanak anélkül, hogy a hagyományos vízesés hajóütemezésekre várnak, amelyek hónapokig vagy évekig tarthatnak a kiadások között.

A sikeres képességek és alkalmazások három különböző követelménytípusnak felelnek meg:

• Funkcionális (Dev): Az alkalmazásnak meg kell felelnie az üzleti és felhasználói igényeknek, amelyek gyakran gyorsan fejlődnek.
• Biztonságos (Sec): Az alkalmazásnak rugalmasnak kell lennie a gyorsan fejlődő támadók támadásai ellen, és ki kell használnia a biztonsági védelem terén nyújtott újítások előnyeit.
• Reliable (Ops): Az alkalmazásnak megbízhatónak és hatékonynak kell lennie.

A három követelmény egyesítése és a közös kultúra létrehozása kritikus fontosságú, de gyakran kihívást jelent. A fejlesztési, informatikai és biztonsági csapatok vezetőinek együtt kell működnie a változás érdekében.

Az alábbi videóból többet is megtudhat a DevSecOps módszerről a biztonságos és gyors innováció érdekében.

A biztonság integrálása a fejlesztési életciklus során

Fontos, hogy a fejlesztés teljes életciklusa során integráljuk a biztonságot a tervezés, kód és egyéb problémák gyors azonosítása és javítása érdekében, miközben a felhasználók a folyamat ezen szakaszán dolgoznak. Ez a megközelítés elkerüli a drágább és nehezebb javításokat, amelyek nagy mennyiségű újramunkát okozhatnak.

A biztonsági kockázatok (és azok mérséklésének szükségessége) a fejlesztési életciklus bármely pontján előfordulhatnak:

• Tervezés – Győződjön meg arról, hogy a kialakítás nem teszi lehetővé a támadók számára, hogy egyszerűen jogosulatlan hozzáférést szerezzenek a számítási feladathoz, az adataihoz vagy a szervezet egyéb üzleti eszközeihez.
• Kód – Győződjön meg arról, hogy a kód írása (és újrafelhasználása) nem teszi lehetővé a támadók számára, hogy könnyen átvegye az alkalmazás irányítását az ügyfeleket, az alkalmazottakat, a rendszereket, az adatokat vagy más üzleti eszközöket károsító jogosulatlan műveletek végrehajtásához. A fejlesztőknek olyan biztonságos környezetben kell dolgozniuk, amely nem teszi lehetővé a támadók számára, hogy tudásuk nélkül átvehessék az irányítást.
• Buildelés és üzembe helyezés – Győződjön meg arról, hogy a folyamatos integrációs és folyamatos üzembe helyezési (CI/CD) folyamatok nem teszik lehetővé a jogosulatlan felhasználók számára a kód módosítását, és lehetővé teszik a támadók számára, hogy feltörik azt.
• Futtatás – Győződjön meg arról, hogy a kódot futtató környezet (felhő, kiszolgálók, mobileszközök stb.) a biztonsági ajánlott eljárásokat követi a felhasználók, a folyamatok és a technológia esetében, hogy a támadók ne veszélyezzenek és ne használjanak vissza a számítási feladatokat. Ez a folyamat magában foglalja a jól bevált ajánlott eljárások bevezetését, a biztonsági alapkonfigurációk konfigurálását és egyebeket.
• Teljes felügyelet Architektúra és irányítás – Ezen szakaszok mindegyikének Teljes felügyelet alapelveket kell követnie, hogy feltételezze a biztonsági rést (feltételezze a biztonsági rést), explicit módon ellenőrizze a megbízhatóságot, és biztosítsa az egyes felhasználói fiókokhoz, gépi/szolgáltatás-identitásokhoz és alkalmazásösszetevőkhöz szükséges minimális jogosultságot.

Mi az a DevSecOps?

A technológiai innovációt gyakran fejlesztik egy gyors, sovány és agilis fejlesztési megközelítés kontextusában, amely egyesíti a fejlesztést és a műveleteket egy DevOps-folyamatba , és a biztonság ebbe a folyamatba való integrálása kritikus fontosságú az innovációs folyamat kockázatainak, a szervezet növekedésének és a szervezet meglévő eszközeinek mérséklése érdekében. A biztonság folyamatba való integrálása létrehoz egy DevSecOps-folyamatot .

Biztonság a tervezéssel és a bal oldali eltolással

Mivel a szervezetek a DevOpst és más gyors innovációs módszereket vezetik be, a biztonságnak a szervezet és fejlesztési folyamatai során szőtt szálnak kell lennie. A biztonsági integráció a folyamat késői szakaszában költséges és nehezen javítható.

A biztonság az ütemtervben maradva integrálható a szolgáltatások és termékek tervezésébe, tervezésébe, megvalósításába és működtetésébe. Ahogy a fejlesztői csapatok a DevOpsra váltanak, és felhőtechnológiákat vezetnek be, a biztonságnak az átalakítás részét kell képeznie.

A vízesésmodellben a biztonság hagyományosan minőségi kapu volt a fejlesztés befejezése után.

A DevOps kiterjesztette a hagyományos fejlesztési modellt (emberek, folyamat és technológia), hogy az operatív csapatokat is magában foglalja. Ez a változás csökkentette azokat a súrlódásokat, amelyek a fejlesztési és üzemeltetési csapatok elválasztásához vezettek. Hasonlóképpen, a DevSecOps kibővíti a DevOps-t, hogy csökkentse a különálló vagy eltérő biztonsági csapatok közötti súrlódást.

A DevSecOps a biztonság integrálása a DevOps életciklusának minden szakaszába az ötlettől kezdve a tervezésen, az architekturális tervezésen, az iteratív alkalmazásfejlesztésen és műveleteken keresztül. A csapatoknak egyszerre kell igazodniuk az innovációs sebesség, a megbízhatóság és a biztonsági rugalmasság céljaihoz. Kölcsönös megértéssel és kölcsönösen tiszteletben tartva egymás igényeit, a csapatok először a legfontosabb kérdéseken dolgoznak, függetlenül a forrástól.

A felhőadaptálási keretrendszer rendszerezési módszertana további kontextust biztosít a szervezet DevSecOps-struktúráihoz. További információ: Az alkalmazásbiztonság és a DevSecOps-függvények ismertetése.

Miért a DevSecOps?

A DevOps agilitást, a DevSecOps pedig biztonságos rugalmasságot biztosít.

A világ szinte minden szervezete szoftverfejlesztést keres, hogy versenyelőnyhöz jusson az innováció révén. A DevOps-folyamat biztonságossá tétele kritikus fontosságú a szervezet sikere szempontjából. A támadók észrevették ezt a váltást az egyéni alkalmazásokra, és egyre gyakrabban támadják az egyéni alkalmazásokat a támadásaik során. Ezek az új alkalmazások gyakran értékes szellemi tulajdon gazdag forrásai, amelyek értékes új ötleteket tartalmaznak, amelyek még nem árucikkek a piacon.

Ennek az innovációnak a védelméhez a szervezeteknek a fejlesztési folyamat és az alkalmazásokat üzemeltető infrastruktúra potenciális biztonsági gyengeségeit és támadásait kell kezelnie. Ezt a megközelítést a felhőbeli és a helyszíni erőforrásra is alkalmazni kell.

A támadók úgy érhetik el céljaikat, hogy kihasználják a fejlesztési folyamat, a számítási feladatok alapjául szolgáló infrastruktúra gyengeségeit, vagy mindkettőt:

• Fejlesztési támadások az alkalmazástervezési és fejlesztési folyamat gyengeségeit használva. Előfordulhat például, hogy a támadók olyan kódot találnak, amely nem ellenőrzi a bemenetet (amely lehetővé teszi az olyan gyakori támadásokat, mint az SQL-injektálás), vagy azt tapasztalhatják, hogy az alkalmazás gyenge titkosítást használ (vagy nincs titkosítás) a kommunikációhoz. Emellett előfordulhat, hogy a támadók hátsó ajtókat ültetnek be a kódba, amely lehetővé teszi számukra, hogy később visszatérjenek, hogy hozzáférjenek az Ön környezetében vagy az ügyfél környezetében lévő eszközökhöz.
• Olyan infrastruktúra-támadások , amelyek a fejlesztési folyamat által üzemeltetett végpontokat és infrastruktúraelemeket veszélyeztetik standard támadásokkal. A támadók többlépcsős támadást is végrehajthatnak, amely ellopott hitelesítő adatokat vagy kártevőket használ a fejlesztési infrastruktúra elérésére a környezet más részeiről.

Emellett a szoftverellátási lánc támadásainak kockázata miatt kritikus fontosságú a biztonság integrálása a folyamatba mindkét esetben:

• A szervezet védelme a forráskód ellátási láncában lévő rosszindulatú kódok és biztonsági rések ellen
• Az ügyfelek védelme az alkalmazásokban és rendszerekben felmerülő biztonsági problémáktól, amelyek a szervezetre gyakorolt hírnévkárosodást, felelősséget vagy egyéb negatív üzleti hatásokat eredményezhetnek

A DevSecOps folyamata

A legtöbb szervezet úgy véli, hogy a DevOps vagy a DevSecOps egy adott számítási feladathoz vagy alkalmazáshoz valójában kétfázisú folyamat. Az ötletek először egy biztonságos helyre inkubálnak, és később a minimálisan működőképes termékként (MVP) jelennek meg az éles környezetben. Ezután iteratív módon és folyamatosan frissülnek.

Ez az ábra az innovációs gyár ilyen megközelítésének életciklusát mutatja be:

A biztonságos innováció mindkét fázis integrált megközelítése:

• Ötlet inkubáció , ahol egy kezdeti ötlet készül, érvényesítve és készen áll a kezdeti éles használatra. Ez a fázis egy új ötlettel kezdődik, és akkor ér véget, amikor az első éles kiadás megfelel a minimális működőképes termékre (MVP) vonatkozó feltételeknek:
  • Fejlesztés: A funkcionalitás megfelel a minimális üzleti követelményeknek
  • Biztonság: A képességek megfelelnek az üzemi használatra vonatkozó jogszabályi megfelelőségi, biztonsági és biztonsági követelményeknek
  • Műveletek: A funkcionalitás megfelel az éles rendszer minőségére, teljesítményére és támogatottságára vonatkozó minimális követelményeknek
• DevOps: Ez a fázis az alkalmazás vagy számítási feladat folyamatos iteratív fejlesztési folyamata, amely lehetővé teszi a folyamatos innovációt és fejlesztést

A vezetői imperatíva: Keverje a kultúrákat

Ennek a három követelménynek a teljesítéséhez össze kell egyesíteni ezt a három kultúrát, hogy minden csapattag értékelje a követelmények minden típusát, és közös célok érdekében működjön együtt.

Ezeknek a kultúráknak és céloknak a valódi DevSecOps-megközelítésbe való integrálása kihívást jelenthet, de megéri a befektetést. Számos szervezetnél magas szintű egészségtelen súrlódás tapasztalható a fejlesztés, az informatikai műveletek és az önállóan dolgozó biztonsági csapatok részéről, ami problémákat okoz a következőkkel:

• Lassú értékkézbesítés és alacsony rugalmasság
• Minőséggel és teljesítménnyel kapcsolatos problémák
• Biztonsági problémák

Bár néhány probléma normális és elvárható az új fejlesztés során, a csapatok közötti ütközések gyakran jelentősen növelik ezeknek a problémáknak a számát és súlyosságát. A konfliktusok gyakran azért fordulnak elő, mert egy vagy két csapat politikai előnyt élvez, és ismételten felülbírálják a többi csapat követelményeit. Idővel az elhanyagolt problémák mennyisége és komolysága növekszik. Ez a dinamikus folyamat a DevOpsban még rosszabb lehet, mivel a döntések sebessége nő az üzleti igények és az ügyfelek preferenciáinak gyors fejlődése érdekében.

Ezeknek a problémáknak a megoldásához létre kell hoznia egy közös kultúrát, amely értékeli a vezetés által támogatott fejlesztési, mp- és ops követelményeket. Ez a megközelítés lehetővé teszi a csapatok számára, hogy jobban együttműködjenek, és segítsenek megoldani az adott futam legsürgetőbb problémáit, akár a biztonságot, az üzemeltetési stabilitást, akár a kritikus üzleti funkciók hozzáadását.

Vezetői technikák

Ezek a kulcsfontosságú technikák segíthetnek a vezetőségnek egy közös kultúra kialakításában:

1. Senki sem nyeri meg az összes érvet: A vezetőknek gondoskodniuk kell arról, hogy egyetlen gondolkodásmód sem uralja azokat a döntéseket, amelyek az üzletre negatív hatással lévő egyensúlyhiányt okozhatnak.
2. Várjon folyamatos javulást, nem tökéletességet: A vezetőknek a folyamatos fejlődésre és a folyamatos tanulásra kell számítaniuk. A sikeres DevSecOps-program létrehozása nem történik meg egyik napról a másikra. Ez egy folyamatos folyamat növekményes előrehaladással.
3. Ünnepelje a közös érdekeket és az egyedi egyéni értékeket is: Győződjön meg arról, hogy a csapatok látják, hogy a közös eredményeken dolgoznak, és minden egyes személy olyasmit biztosít, amit a többiek nem. Az összes követelménytípus ugyanazon üzleti érték létrehozására és védelmére vonatkozik. A fejlesztés új értéket próbál létrehozni, míg az ops és a biztonság ezt az értéket próbálja védeni és megőrizni a különböző kockázati forgatókönyvek ellen. A szervezet minden szintjén a vezetőknek közölniük kell ezt a közösséget, és mennyire fontos, hogy az azonnali és a hosszú távú siker minden követelményének megfeleljenek.
4. Közös megértés fejlesztése: A csapat minden tagja alapszintű ismereteket szerezhet a következőről:
   • Üzleti sürgősség: A csapatnak egyértelmű képet kell alkotnia a tétben lévő bevételről. Ennek a nézetnek tartalmaznia kell az aktuális bevételt (ha a szolgáltatás offline állapotban van), valamint az alkalmazások és szolgáltatások késedelme által érintett jövőbeli bevételt. Ennek a nézetnek közvetlenül a vezető érdekelt felektől érkező jeleken kell alapulnia.
   • Valószínű kockázatok és fenyegetések: A fenyegetésintelligencia-csapat bemenete alapján, ha van ilyen, a csapatnak meg kell állapítania, hogy az alkalmazásportfólió várhatóan mely fenyegetésekkel fog szembesülni.
   • Rendelkezésre állási követelmények: A csapatnak közösen kell értelmeznie az üzemeltetési követelményeket, például a szükséges üzemidőt, az alkalmazás várható élettartamát, valamint a hibaelhárítási és karbantartási követelményeket, például az online szolgáltatás során történő javítást.
5. A kívánt viselkedés bemutatása és modellezése: A vezetőknek nyilvánosan modellezhetik a csapatuktól kívánt viselkedést. Mutasson például alázatot, összpontosítson a tanulásra, és értékelje a többi szemléletet. Egy másik példa a fejlesztési vezetők a biztonság és a kiváló minőségű alkalmazások értékéről, vagy a biztonsági vezetők beszélnek a gyors innováció és az alkalmazások teljesítményének értékéről.
6. A biztonsági súrlódás szintjének monitorozása: A biztonság természetesen súrlódást okoz, amely lelassítja a folyamatokat. A vezetők számára kritikus fontosságú, hogy megfigyeljék a biztonság által generált súrlódás szintjét és típusát:
   • Egészséges súrlódás: Hasonlóan ahhoz, ahogyan a testmozgás erősebbé teszi az izmokat, a DevOps-folyamat megfelelő biztonsági súrlódási szintjének integrálásával a kritikus gondolkodás megfelelő időben történő kényszerítésével erősíti az alkalmazást. Ha a csapatok tanulnak és használják ezeket a tanulásokat a biztonság javítása érdekében, például figyelembe véve, hogy a támadók miért és hogyan próbálhatják meg feltörni az alkalmazásokat, és megkeresik és kijavítják a fontos biztonsági hibákat, akkor jó úton haladnak.
   • Nem kifogástalan súrlódás: Olyan súrlódásokra kell figyelni, amelyek több értéket akadályoznak, mint amennyit véd. Ez a súrlódás gyakran akkor fordul elő, ha az eszközök által generált biztonsági hibák magas hamis pozitív rátával vagy hamis riasztásokkal rendelkeznek, vagy ha a hiba elhárítására tett biztonsági erőfeszítések túllépik a támadás lehetséges hatását.
7. A biztonság integrálása a költségvetés-tervezésbe: Győződjön meg arról, hogy a biztonsági költségvetés arányosan van lefoglalva más biztonsági beruházásokhoz. Ez a fogalom hasonló egy olyan fizikai eseményhez, mint egy koncert, ahol az esemény költségvetése normaként tartalmazza a fizikai biztonságot. Egyes szervezetek általános szabályként a teljes biztonsági költség 10 százalékát osztják ki a biztonsági ajánlott eljárások következetes alkalmazásának biztosítása érdekében.
8. Közös célok létrehozása: Az alkalmazás-számítási feladatok teljesítmény- és sikermetrikáinak biztosítása a fejlesztési, biztonsági és üzemeltetési célokat tükrözi.

Feljegyzés

Ideális esetben ezeknek a csapatoknak együttesen kell létrehozniuk ezeket a közös célokat, hogy maximalizálják a vásárlást, akár az egész szervezet, akár egy adott projekt vagy alkalmazás számára.

A DevSecOps MVP azonosítása

Az ötletről az éles környezetre való áttérés során kritikus fontosságú annak biztosítása, hogy a képesség megfeleljen a minimális követelményeknek vagy a minimálisan működőképes terméknek (MVP) minden követelménytípus esetében:

• A fejlesztők (fejlesztői) a felhasználók, ügyfelek és üzleti vezetők elvárásainak megfelelő képességek gyors rendelkezésre állásához szükséges üzleti igényeket képviselik. Határozza meg a minimális követelményeket annak érdekében, hogy a képesség hozzájáruljon a szervezet sikeressé tételéhez.
• A biztonság (sec) a megfelelőségi kötelezettségek teljesítésére helyezi a hangsúlyt, és védelmet nyújt azokkal a támadókkal szemben, amelyek folyamatosan keresnek tiltott nyereséget a szervezet erőforrásaiból. Azonosítsa a jogszabályi megfelelőségi követelményeknek való megfeleléshez, a biztonsági helyzet fenntartásához és annak biztosításához, hogy a biztonsági műveletek gyorsan észleljék és reagáljanak az aktív támadásokra.
• Az operatív műveletek a teljesítményre, a minőségre és a hatékonyságra összpontosítanak, biztosítva, hogy a számítási feladat hosszú távon is értéket teremtsen. Határozza meg azokat a minimális követelményeket, amelyek biztosítják, hogy a számítási feladatok a belátható jövőben jelentős architekturális vagy tervezési módosítások nélkül is végrehajthatók és támogatottak legyenek.

Az MVP definíciói idővel és különböző számítási feladattípusokkal is változhatnak, mivel a csapat a saját tapasztalataikból és más szervezetektől tanul együtt.

A biztonság natív integrálása a folyamatba

A biztonsági követelményeknek a meglévő folyamattal és eszközökkel való natív integrációra kell összpontosítaniuk. Példa:

• Az olyan tervezési tevékenységeket, mint a fenyegetésmodellezés, integrálva kell lennie a tervezési fázisba
• A biztonsági ellenőrző eszközöket integrálni kell a folyamatos integrációs és folyamatos kézbesítési (CI/CD) rendszerekbe, például az Azure DevOpsba, a GitHubba és a Jenkinsbe
• A biztonsági problémákat ugyanazokkal a hibakövető rendszerekkel és folyamatokkal kell jelenteni, mint például a rangsorolási sémát, mint más hibákat.

A biztonság folyamatba való integrálásának módját folyamatosan javítani kell, ahogy a csapatok tanulnak, és a folyamatok kiforrnak. A biztonsági felülvizsgálatoknak és a kockázatértékeléseknek biztosítaniuk kell, hogy a kockázatcsökkentések integrálva legyenek a teljes körű fejlesztési folyamatokba, a végső éles szolgáltatásba és az alapul szolgáló infrastruktúrába.

A DevSecOpsról további információt a DevSecOps technikai vezérlőiben talál.

Tippek az utazás navigálásához

Az átalakításhoz növekményesen kell felépíteni ezt az ideális állapotot egy úton. Sok szervezetnek el kell navigálnia az összetettség és a kihívások között ezen az úton. Ez a szakasz a szervezetek által gyakran használtak közül mutat be néhányat.

• Az oktatás és a kultúra változásai kritikus korai lépések: Háborúba lépsz a hadsereggel. A csapatnak gyakran új készségeket kell fejlesztenie, és új perspektívákat kell elfogadnia a DevSecOps-modell többi részének megértéséhez. Ez az oktatási és kulturális változás időt, fókuszt, vezetői szponzorálást és rendszeres nyomon követés, hogy segítsen az egyének teljes mértékben megérteni és látni az értéket a változás. A kultúrák és készségek drasztikus megváltoztatása néha megérintheti az egyének szakmai identitását, ami erős ellenállást teremthet. Kritikus fontosságú megérteni és kifejezni az egyes személyek és helyzetük változásának okát, miét és módját.
• A változás időbe telik: Csak olyan gyorsan mozoghat, amennyire a csapata alkalmazkodni tud a dolgok új módon történő elvégzésének következményeihez. A csapatoknak mindig el kell végezniük a meglévő feladataikat az átalakításuk során. Kritikus fontosságú, hogy gondosan rangsorolja a legfontosabb dolgokat, és hogy kezelni tudja a változás gyors bekövetkezésének elvárásait. A bejárásra, a sétára, a futtatási stratégiára összpontosítva, ahol a legfontosabb és alapvető elemek kerülnek előtérbe, jól szolgálja a szervezetet.
• Korlátozott erőforrások: A szervezetek általában korán szembesülnek kihívással, ha tehetségeket és készségeket keresnek mind a biztonság, mind az alkalmazásfejlesztés terén. A szervezetek hatékonyabb együttműködése során rejtett tehetségeket találhatnak, például a biztonsági szemlélettel rendelkező fejlesztőket vagy a fejlesztési háttérrel rendelkező biztonsági szakembereket.
• Az alkalmazások, a kód és az infrastruktúra változó jellege: Az alkalmazások technikai definíciója és összetétele alapvetően változik olyan technológiák bevezetésével, mint a kiszolgáló nélküli, a felhőszolgáltatások, a felhő API-k és a kód nélküli alkalmazások, például a Power Apps. Ez a váltás megváltoztatja a fejlesztési gyakorlatokat, az alkalmazásbiztonságot, és még a nem fejletleneket is lehetővé teszi alkalmazások létrehozására.

Feljegyzés

Egyes implementációk az üzemeltetést és a biztonsági feladatokat egy helymegbízható mérnök (SRE) szerepkörbe egyesítik.

Bár egyes szervezetek számára ideális végállapot lehet ezeknek a feladatoknak az egyetlen szerepkörbe való beolvadása, ez gyakran szélsőséges változás a jelenlegi vállalati gyakorlatoktól, kultúrától, eszközöktől és képességkészletektől.

Még ha SRE-modellt is céloz meg, javasoljuk, hogy kezdje a biztonság DevOpsba való beágyazásával az ebben az útmutatóban ismertetett gyakorlati gyors nyeréssel és növekményes előrehaladással, hogy biztos legyen abban, hogy jó megtérülést (ROI) kap, és kielégíti az azonnali igényeket. Ez fokozatosan növeli a biztonsági feladatokat a műveleti és fejlesztési személyzet számára, ami közelebb hozza a felhasználókat az SRE végső állapotához (ha a szervezet később tervezi a modell bevezetését).

Következő lépések

A DevSecOps technikai vezérlőinek áttekintésével részletesebb útmutatást talál a DevSecOpsról.

További információ arról, hogy a GitHub fejlett biztonsága hogyan integrálja a biztonságot a folyamatos integrációs és folyamatos kézbesítési (CI/CD)-folyamatokba, olvassa el a GitHub speciális biztonságáról szóló cikket.

A Microsoft informatikai szervezetének DevSecOps implementálásával kapcsolatos további információkért és eszközökért tekintse meg a Biztonságos DevOps eszközkészletet.