Az innováció biztonsága

Az innováció a digitális korban a szervezet életmentő eleme, amelyet 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 módszer használatával történő alkalmazások fejlesztésének formájában valósul meg a gyors innovációhoz anélkül, hogy megvárná a hagyományos vízeséshajó-menetrendet, amely hónapokig vagy évekig tarthat a kiadások között.

Az új képességek és alkalmazások fejlesztéséhez három különböző követelménytípus sikeres teljesítésére van szükség:

• Üzletfejlesztés (Dev): Az alkalmazásnak meg kell felelnie az üzleti és felhasználói igényeknek, amelyek gyakran gyorsan fejlődnek.
• Biztonság (Sec): Az alkalmazásnak rugalmasnak kell lennie a gyorsan fejlődő támadók támadásai ellen, és ki kell használnia az újításokat a biztonsági védelem terén.
• Informatikai műveletek (Ops): Az alkalmazásnak megbízhatónak és hatékonynak kell lennie.

A három követelmény egyesítése és a megosztott 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 elősegítése érdekében. További információkért lásd a vezetői imperatívát: keverje össze a kultúrákat.

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

Mi az a DevSecOps?

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

Biztonság kialakítással és balra tolással

Ahogy a szervezetek elfogadják a DevOpsot és más gyors innovációs módszereket, a biztonságnak a szervezet és annak fejlesztési folyamatai során szőtt szálnak kell lennie. A biztonságnak a folyamat végén történő integrálása költséges és nehezen javítható.

Az idővonalon balra tolhatja a biztonságot, és integrálhatja 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 operatív csapatokat is tartalmazzon. 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 DevOpst, hogy csökkentse a különálló vagy különálló 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 üzemeltetésen keresztül. A csapatoknak egyidejűleg 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ös tiszteletben tartva egymás igényeit, a csapatok először a legfontosabb kérdéseken fognak dolgozni, függetlenül a forrástól.

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

Miért a DevSecOps?

A DevOps rugalmasságot, 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 az egyéni alkalmazásokra való váltást, és egyre inkább támadják az egyéni alkalmazásokat a támadásaik során. Ezek az új alkalmazások gyakran értékes szellemi tulajdonok gazdag forrásai, amelyek értékes új ötleteket tartalmaznak, amelyek még nem árucikkek a piacon.

Az innováció védelméhez a szervezeteknek kezelnie kell a potenciális biztonsági hiányosságokat és támadásokat mind a fejlesztési folyamat, mind az alkalmazásokat üzemeltető infrastruktúra esetében. Ez a megközelítés a felhőre és a helyszínire is vonatkozik.

A támadók kihasználhatják az alábbiak gyengeségeit:

• Fejlesztési folyamat: A támadók gyengeségeket találhatnak az alkalmazástervezési folyamat során, például gyenge titkosítást használnak vagy nem használnak titkosítást a kommunikációhoz. Vagy a támadók gyengeséget tapasztalhatnak a kialakítás megvalósítása során, például a kód nem ellenőrzi a bemenetet, és lehetővé teszi az olyan gyakori támadásokat, mint az SQL-injektálás. Emellett előfordulhat, hogy a támadók hátsó ajtókat ültetnek be a kódba, amely lehetővé teszi, hogy később visszatérjenek, hogy kihasználhassák az Ön környezetében vagy az ügyfél környezetében.
• Informatikai infrastruktúra: A támadók veszélyeztethetik azokat a végpont- és infrastruktúraelemeket, amelyeken a fejlesztési folyamat szabványos támadásokkal fut. A támadók többlépcsős támadást is végezhetnek, amely ellopott hitelesítő adatokat vagy kártevőket használ a környezet más részeiből származó fejlesztési infrastruktúra eléréséhez. Emellett a szoftverellátási lánc támadásainak kockázata miatt kritikus fontosságú a biztonság integrálása a folyamatba mindkettő esetében:
• A szervezet védelme: Rosszindulatú kódok és biztonsági rések a forráskód ellátási láncában
• Az ügyfelek védelme: Az alkalmazásokban és rendszerekben felmerülő biztonsági problémák, amelyek hírnévkárosodást, felelősséget vagy más negatív üzleti hatásokat okozhatnak a szervezetre nézve

A DevSecOps folyamata

A legtöbb szervezet úgy találja, hogy a DevOps vagy a DevSecOps egy adott számítási feladathoz vagy alkalmazáshoz valójában egy kétfázisú folyamat, amelyben az ötletek először egy biztonságos helyen inkubálódnak, majd később éles környezetben, iteratívan és folyamatosan frissülnek.

Ez az ábra az innovációs gyár ilyen típusú 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 létrejön, é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álisan működőképes termékre (MVP) vonatkozó kritériumoknak:
  • Fejlesztési: A funkciók megfelelnek a minimális üzleti követelményeknek
  • Biztonsági: 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 minimális minőségi, teljesítménybeli és támogatási követelményeinek
• 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ív: Keverje a kultúrákat

A három követelmény teljesítéséhez össze kell egyesíteni ezt a három kultúrát annak érdekében, hogy a csapattagok minden követelményt értékeljenek, és együtt dolgozzanak a közös célok érdekében.

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 üzemeltetés és a biztonsági csapatok részéről, akik egymástól függetlenül dolgoznak, és problémákat okoznak 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árt az új fejlesztés során, a csapatok közötti ütközések gyakran jelentősen növelik a problémák számát és súlyosságát. A konfliktusok gyakran azért fordulnak elő, mert egy vagy két csapatnak politikai előnye van, és ismételten felülbírálja a többi csapat követelményeit. Idővel az elhanyagolt problémák mennyisége és súlyossága növekszik. Ez a dinamikus folyamat még rosszabb lehet a DevOpsban, 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 megosztott kultúrát, amely a vezetőség által támogatott dev, sec és ops követelményeket értékeli. Ez a megközelítés lehetővé teszi, hogy a csapatok jobban együttműködjenek, és segítsenek megoldani az adott futam legsürgetőbb problémáit, legyen szó akár a biztonság, a működési stabilitás javításáról vagy a kritikus üzleti funkciók hozzáadásáról.

Vezetői technikák

Ezek a fő technikák segíthetnek a vezetőségnek egy megosztott kultúra kialakításában:

1. Senki sem nyeri meg az összes argumentumot: A vezetőknek gondoskodniuk kell arról, hogy egyetlen gondolkodásmód sem uralja azokat a döntéseket, amelyek az üzletmenetet negatívan befolyásoló egyensúlytalanságot okozhatnak.

2. Várjon folyamatos javulást, nem tökéletességet: A vezetőknek elvárják a folyamatos fejlődést és a folyamatos tanulást. A sikeres DevSecOps-program létrehozása nem egyik napról a másikra történik. Ez egy folyamatos folyamat növekményes előrehaladással.

3. A közös érdekek és az egyedi egyedi értékek ünnepe: Győződjön meg arról, hogy a csapatok láthatják, hogy a közös eredményeken dolgoznak, és minden egyes személy olyasmit biztosít, amit mások 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önyvekkel szemben. A vezetőknek a szervezet minden szintjén közölniük kell ezt a közösséget, és hogy mennyire fontos, hogy az azonnali és hosszú távú siker minden követelményének megfeleljenek.

4. Közös megértés fejlesztése: A csapat minden résztvevőjének ismernie kell az alábbiakat:

   • Üzleti sürgősség: A csapatnak egyértelmű képet kell adnunk a 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 közvetlenül a vezetői érdekelt felektől érkező jeleken kell alapulnia.
   • Valószínű kockázatok és fenyegetések: A fenyegetésfelderítési 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 közbeni javítást.

5. A kívánt viselkedés bemutatása és modellezése: A vezetőknek nyilvánosan modellezhetik a csapatuk által kívánt viselkedést. Mutasson például alázatot, összpontosítson a tanulásra, és értékelje a többi tudományágat. Egy másik példa, hogy a fejlesztési vezetők a biztonság és a kiváló minőségű alkalmazások, illetve a biztonsági vezetők értékéről beszélnek a gyors innováció és az alkalmazásteljesítmény é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ú a biztonság által generált súrlódások szintjének és típusának monitorozása:

   • 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ása azzal erősíti az alkalmazást, hogy a kritikus gondolkodást a megfelelő időben kényszeríti. Ha a csapatok tanulnak és használják ezeket a tanulásokat a biztonság javítására, például annak figyelembevételével, hogy miért, és hogyan próbálhatják meg a támadók feltörni az alkalmazásokat, és megkeresik és kijavítják a fontos biztonsági hibákat, akkor jó úton járnak.
   • Nem kifogástalan súrlódás: Vigyázni kell a súrlódásokra, amelyek több értéket akadályoznak, mint amennyit véd. Ez gyakran akkor fordul elő, ha az eszközök által generált biztonsági hibák magas téves pozitív vagy téves riasztásokkal rendelkeznek, vagy ha a biztonsági erőfeszítés, hogy valamit kijavítsunk, meghaladja 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 befektetésekhez. Ez 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 a teljes biztonsági költség 10 százalékát biztosítják általános szabályként 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: Győződjön meg arról, hogy az alkalmazás számítási feladatainak teljesítmény- és sikermetrikái tükrözik a fejlesztési, biztonsági és üzemeltetési célokat.

Megjegyzé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ú biztosítani, 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 teljesítéséhez szükséges üzleti igények kielégítésére összpontosítanak. Határozza meg a minimális követelményeket annak érdekében, hogy a képesség sikeressé tegye a szervezetet.
• 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, akik folyamatosan illegális nyereséget keresnek a szervezet erőforrásaiból. A jogszabályi megfelelőségi követelmények teljesítéséhez, 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.
• A műveletek (ops) a teljesítményre, a minőségre és a hatékonyságra összpontosítanak, biztosítva, hogy a számítási feladatok hosszú távon is értéket nyújtsanak. 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 teljesíthető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ő folyamatokkal és eszközökkel való natív integrációra kell összpontosítaniuk. Például:

• 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 kifejlődnek. A biztonsági felülvizsgálatoknak és kockázatértékeléseknek biztosítaniuk kell, hogy a kockázatcsökkentések integrálva legyenek a végpontok közötti fejlesztési folyamatokba, a végső éles szolgáltatásba és a mögöttes infrastruktúrába.

További információ a DevSecOpsról: DevSecOps technikai vezérlők.

Tippek az utazáshoz

Az átalakításhoz növekményesen létre kell hozni ezt az ideális állapotot egy úton. Sok szervezetnek kell navigálnia az összetettség és a kihívások ezen az úton. Ez a szakasz a szervezetek által használt gyakori eseteket ismerteti.

• Az oktatás és a kultúra változásai kritikus korai lépések:Háborúba mész a hadsereggel, ami van. A csapatnak gyakran új készségeket kell fejlesztenie, és új perspektívákat kell alkalmaznia a DevSecOps-modell más részeinek megértéséhez. Ez az oktatási és kulturális változás időbe telik, a fókusz, a vezetői szponzorálás és a 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 belekoppinthat az egyének szakmai identitásába, ami erős ellenállást teremthet. Fontos megérteni és kifejezni az egyes személyek és helyzetük változásának okát, miben és hogyanját.
• A módosítás időt vesz igénybe: Csak olyan gyorsan mozoghat, amennyire a csapata képes alkalmazkodni 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 kezelje azokat az elvárásokat, hogy milyen gyorsan történhet ez a változás. A bejárásra, a sétára és 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 szervezeteknek általában korán szembe kell néznie a tehetség és a készségek megtalálásával 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 biztonsági szemlélettel rendelkező fejlesztőket vagy fejlesztési hátterű biztonsági szakembereket.
• Az alkalmazások, a kód és az infrastruktúra természetének eltolódása: 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, felhőszolgáltatások, felhőBELI API-k és kód nélküli alkalmazások, például a Power Apps. Ez a változás megváltoztatja a fejlesztési gyakorlatokat, az alkalmazásbiztonságot, és még a nem fejlesztők számára is lehetővé teszi az alkalmazások létrehozását.

Megjegyzés

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

Bár ezek a felelősségek egyes szervezetek számára ideális végállapotok lehetnek, ez gyakran a jelenlegi vállalati gyakorlatoktól, kultúrától, eszközöktől és képességcsoportoktól való szélsőséges változás.

Még ha SRE-modellt is céloz meg, javasoljuk, hogy kezdje azzal, hogy a biztonságot a DevOpsba ágyazza be az ebben az útmutatóban ismertetett gyakorlati gyors nyerésekkel és növekményes előrehaladással annak érdekében, hogy megfelelő megtérülést (ROI) kaphasson, és kielégítse az azonnali igényeket. Ez fokozatosan növeli a biztonsági feladatokat az üzemeltetési és fejlesztési személyzet számára, ami közelebb hozza az embereket az SRE végállapotához (ha a szervezet később tervezi ezt a modellt).

Következő lépések

A DevSecOps szolgáltatással kapcsolatos részletesebb útmutatásért tekintse át a DevSecOps technikai vezérlőit .

További információ arról, hogy a GitHub fejlett biztonsági funkciói hogyan integrálják a biztonságot a folyamatos integrációs és folyamatos teljesítésű (CI/CD) folyamatokba: About GitHub advanced security (Tudnivalók a GitHub speciális biztonságáról).

A Microsoft informatikai szervezetének DevSecOps-implementálásával kapcsolatos további információkért és eszközökért lásd: Biztonságos DevOps-eszközkészlet.