DevOps Security

A DevOps security a szoftverfejlesztési életciklus (SDLC) során integrálja a biztonsági eljárásokat a kezdeti tervezéstől és kódolástól kezdve a buildelésen, tesztelésen és üzembe helyezésen keresztül az éles környezetbe. A hagyományos biztonsági megközelítésekkel ellentétben, amelyek végső kapuként kezelik a biztonságot, a DevOps security beágyazza a biztonsági vezérlőket, az automatizált tesztelést és a folyamatos monitorozást a fejlesztési folyamat minden szakaszába. Ez a megközelítés felismeri, hogy a modern szoftverkézbesítés összetett CI-/CD-folyamatokra, külső függőségekre, kódkénti infrastruktúrára és automatizált üzembe helyezésekre támaszkodik, amelyek mindegyike olyan potenciális támadási vektorokat vezet be, amelyeket a támadók aktívan kihasználnak. A zéró megbízhatósági elvek (a behatolás feltételezése, az ellenőrzés explicit módon) és a mélységi védelmi stratégiák alkalmazásával a DevOps-biztonság biztosítja, hogy a kód, a függőségek, az infrastruktúra-konfigurációk és a folyamatfolyamatok megbízhatóak és illetéktelen beavatkozásnak ellenállóak maradjanak a tervezéstől az éles környezeten keresztül. Átfogó DevOps-biztonság nélkül a szervezetek kritikus kockázatokkal szembesülnek, beleértve az ellátási láncot érintő támadásokat, a folyamatok hitelesítő adatainak kitettségét, a rosszindulatú kódinjektálást, a sebezhető tárolólemezképeket és a jogosulatlan infrastruktúra-módosításokat, amelyek állandó háttérrendszereket hozhatnak létre az összes alsóbb rétegbeli felhasználóra.

Íme a DevOps Security tartomány három alapvető pillére.

A tervezési és ellátási lánc védelme: A strukturált fenyegetésmodellezés korai végrehajtása. Az ellátási lánc védelme függőségekkel és licencvizsgálatokkal, sebezhetőségi kezeléssel és SBOM-generációval. Ellenőrizze az összes összetevő származását és integritását.

Kapcsolódó vezérlők:

A Shift elhagyta a biztonsági vezérlőket: A Shift úgy hagyta el a biztonsági vezérlőket, hogy integrálja a SAST-t, a titkos kulcsok vizsgálatát, az IaC-vizsgálatot és a DAST-et a CI/CD-folyamatba. A titkos kulcsok felügyeletének központosítása (pl. Key Vault), a folyamatmódosítási szolgáltató korlátozása, valamint az összetevők (például tároló- és virtuálisgép-rendszerképek) folyamatos vizsgálata és védelme az üzembe helyezés előtt.

Kapcsolódó vezérlők:

DevOps-tevékenységek monitorozása és naplózása: Gyűjtse össze és továbbítsa a DevOps naplózási és biztonsági naplóit egy központi elemzési platformnak a korreláció és a válasz érdekében. Észlelheti a jogosulatlan folyamatmódosításokat, a jogosultságok eszkalációit, a rendellenes véglegesítéseket és a munkaidőn kívüli végrehajtást.

Kapcsolódó vezérlők:

DS-1: Fenyegetésmodellezés végrehajtása

Biztonsági alapelv

Szisztematikus fenyegetésmodellezés implementálása a STRIDE módszertan használatával a tervezési fázisban a potenciális biztonsági fenyegetések azonosítása, a kockázatok rangsorolása és a megfelelő kockázatcsökkentések implementálása a kódfejlesztés megkezdése előtt. Ez a bal oldali megközelítés csökkenti a szervizelési költségeket, és javítja az általános biztonsági helyzetet.

Kockázat csökkentése

Azok a szervezetek, amelyek a tervezési fázis során nem hajtanak végre fenyegetésmodellezést, kritikus vakfoltokkal működnek, amelyeket a támadók szisztematikusan kihasználnak. Szisztematikus fenyegetéselemzés nélkül:

  • Késői architekturális hibák: A beágyazott tervezési sebezhetőségek költséges újratervezést igényelnek a termelési környezetben, a javítási költségek pedig lényegesen magasabbak, mint a tervezési fázisban felmerülő problémák kezelése.
  • Azonosítatlan támadási felületek: A fenyegetésvektorok, például a nem biztonságos megbízhatósági határok, a hiányzó hitelesítési követelmények vagy a nem megfelelő adatfolyam-védelem továbbra is nem dokumentálva maradnak, így a támadók kihasználhatják azokat az ismert gyengeségeket, amelyeket a védők nem ismernek fel.
  • Nem megfelelő biztonsági vezérlők: A hiányzó vagy nem megfelelő biztonsági vezérlők (titkosítás, hitelesítés, engedélyezés, naplózás) hiányos fenyegetéselemzést eredményeznek, és kihasználható hiányosságokat okoznak a részletes védelmi stratégia terén.
  • Megfelelőségi vakfoltok: A biztonságos kialakítás ellenőrzésére vonatkozó szabályozási követelmények (PCI-DSS, HIPAA, SOX) dokumentált fenyegetésmodellek és kockázatcsökkentési bizonyítékok nélkül nem teljesíthetők.
  • Értékpapír-tartozások felhalmozása: A folyamatos funkciók fenyegetésmodellezés nélküli kiegészítései összetett biztonsági technikai adósságot hoznak létre, így a rendszerek fokozatosan sebezhetőbbek és nehezen védhetőek visszamenőlegesen.

A fenyegetésmodellezés hiánya növeli a biztonsági rések valószínűségét, meghosszabbítja a tartózkodási időt, és sokkal magasabb szervizelési költséget és korai tervezési fázisú kockázatcsökkentést vezet.

MITRE ATT&CK

  • Kezdeti hozzáférés (TA0001): kihasználhatja a nyilvános elérésű alkalmazást (T1190), kihasználva a hitelesítés, a munkamenet-kezelés vagy a bemeneti ellenőrzés azon architekturális hibáit, amelyeket a fenyegetésmodellezés azonosítana.
  • Jogosultságok eszkalálása (TA0004): a jogosultságszint-emelési vezérlési mechanizmus (T1548) kihasználja az elégtelen jogosultság-elkülönítést vagy a hiányzó engedélyezési ellenőrzéseket a rendszerarchitektúrában.
  • Védelmi kijátszás (TA0005): rontja a védelmet (T1562), kihasználva a hiányzó naplózást, a monitorozási hiányosságokat vagy a rendszerbe tervezett nem megfelelő biztonsági telemetriát.

DS-1.1: STRIDE-alapú fenyegetésmodellezés implementálása

A tervezési fázisban végzett szisztematikus fenyegetésmodellezés a biztonsági szoftverarchitektúra alapjait biztosítja a biztonsági rések azonosításával a fejlesztés megkezdése előtt. A tervezési fázis biztonsági problémáinak kezelése jelentősen csökkenti a szervizelési költségeket, és megakadályozza, hogy az architekturális hibák beépülnek az éles rendszerekbe. A korai fenyegetésazonosítás biztosítja, hogy a biztonsági vezérlők ne később, hanem az architektúrába legyenek beépítve.

Implementálja a következő strukturált megközelítést a fenyegetésmodellezés létrehozásához:

  • Szisztematikus STRIDE-módszertan kialakítása: Rendszeres fenyegetésmodellezés létrehozása kötelező tervezési fázisú tevékenységként a STRIDE módszertan használatával (hamisítás, illetéktelen beavatkozás, elutasítás, információfeltárás, szolgáltatásmegtagadás, jogosultságszint-emelés). Először hozzon létre olyan adatfolyam-diagramokat (DFD-ket), amelyek rendszerösszetevőket, adatfolyamokat, megbízhatósági határokat és külső függőségeket képeznek le. Az egyes összetevők és adatfolyamok esetében szisztematikusan értékelje ki a potenciális fenyegetéseket mind a hat STRIDE-kategóriában, rangsorolja a kockázatokat a valószínűség és a hatás alapján, és dokumentálja az egyes kockázatcsökkentéseket a fejlesztés megkezdése előtt.

  • Strukturált fenyegetésmodellezési eszközök használata: A konzisztencia fenntartásához és a gyakori architektúramintákhoz (webalkalmazásokhoz, API-khoz, mikroszolgáltatásokhoz és IoT-megoldásokhoz) a strukturált fenyegetésmodellező eszközök, például a Microsoft Fenyegetésmodellező eszköz használata. Az eszköz elősegíti az elosztott fájlrendszer létrehozását, az összetevők típusain és adatfolyamokon alapuló automatikus fenyegetésazonosítást, valamint a kapcsolódó biztonsági vezérlőkkel kapcsolatos, végrehajtható kockázatcsökkentési javaslatokat hoz létre. A fenyegetésmodelleket verziószámozott összetevőkként tárolja a forráskövetésben az architektúra dokumentációja mellett.

  • Integrálás a fejlesztési munkafolyamatokba: A fenyegetésmodellezési kimenetek közvetlenül a fejlesztési munkafolyamatokba integrálhatók az azonosított fenyegetések Azure DevOps-ba való exportálásával, és egyértelmű tulajdonjogi, prioritási és elfogadási feltételekkel rendelkező munkaelemeket exportálnak. Architektúra-felülvizsgálati kapuk implementálása, amelyek a terv jóváhagyása előtt befejezett fenyegetésmodelleket igényelnek, és lekéréses kérelmek ellenőrzése, amelyek a fenyegetésmodellek felülvizsgálatát váltják ki az architektúraváltozások észlelésekor. Ez biztosítja, hogy a fenyegetéselemzés a fejlesztési életciklus során szinkronizálva maradjon a rendszerfejlődéssel.

DS-1.2: Fenyegetéselemzési integráció automatizálása

A fenyegetések nagy szervezetek közötti modellezéséhez automatizálásra és elosztott képességre van szükség, hogy a biztonsági felülvizsgálatok ne váljanak fejlesztési szűk keresztmetszetekké. A projektindítási és lekéréses kérelmek folyamatába ágyazott automatizált fenyegetésazonosítási munkafolyamatok minden projekt esetében manuális beavatkozás nélkül biztosítják a konzisztens biztonsági elemzést. A fejlesztési csapatok biztonsági szakértelmének kiépítése engedélyezési programokon keresztül fenntartható, méretezhető fenyegetésmodellezési gyakorlatokat hoz létre.

Implementálja ezeket az automatizálási és engedélyezési képességeket:

  • Skálázás automatizálással és engedélyezéssel: A fenyegetésmodellezés méretezése a szervezetben automatizálással és engedélyezéssel. Biztonsági kérdőívek beágyazása projektkezdési sablonokba, amelyek automatikusan értékelik a kockázati szintet, meghatározzák a fenyegetésmodellezési követelményeket, és megfelelő biztonsági felülvizsgálati ellenőrzőpontokat rendelnek hozzá az adatbesorolás, a külső kitettség és a szabályozási hatókör alapján. Automatizálhatja az architektúra-felülvizsgálat eseményindítóit a lekéréses kérelmek munkafolyamataiban, amelyek észlelik a rendszerhatárok, a hitelesítési folyamatok vagy az adatkezelési logika útválasztásának változásait a biztonsági tervezők számára a fenyegetésmodell érvényesítéséhez.

  • Elosztott képesség létrehozása biztonsági bajnokokkal: Hozzon létre egy Biztonsági Bajnokok programot, amely elosztott fenyegetésmodellezési képességet hoz létre a fejlesztői csapatokon belül. Tanítson be bajnokokat a STRIDE-módszertanra, biztosítson nekik fenyegetésmodellezési eszközöket és sablonokat, és tegye lehetővé számukra, hogy megkönnyítsék a fenyegetésmodellezési munkameneteket a csapataik számára. A biztonsági bajnokok szolgálnak az első áttekintési sorként, és összetett forgatókönyveket eszkalálnak a központosított biztonsági csapatokra, miközben lehetővé teszik a legtöbb fenyegetésmodellezést szűk keresztmetszetek nélkül.

Automatizált fenyegetéselemzés implementálása:

  • Kérdőívalapú értékelés: Standardizált biztonsági kérdőívek az Azure DevOps-sablonokba integrálva a fenyegetések egységes azonosításához
  • Biztonsági bajnokok program: A fenyegetésmodellezés megkönnyítésére betanított fejlesztőcsapatok kijelölt biztonsági bajnokai
  • Architektúra-felülvizsgálat automatizálása: A fenyegetésmodell felülvizsgálatát igénylő architektúradiagram-frissítések lekéréses kérelmeinek automatikus ellenőrzése
  • Fenyegetésmodell kódként: Verzióvezérelt fenyegetésmodell-definíciók strukturált formátumok (JSON/YAML) használatával, amelyek lehetővé teszik az automatizált elemzést

Megvalósítási példa

Egy pénzügyi szolgáltatási szervezet adatsértést szenvedett el, amikor a támadók olyan hitelesítési hibát kihasználtak a fizetési API-ban, amelyet a fejlesztés során soha nem azonosítottak, ami jelentős csalárd tranzakciókat és szabályozási bírságokat eredményezett.

Kihívás: Mikroszolgáltatás-architektúra számos, biztonsági felülvizsgálat nélkül üzembe helyezett API-val. A fejlesztői csapatok nem rendelkeztek biztonsági szakértelemmel a fenyegetések azonosításához. Az architekturális biztonsági problémák csak éles incidensek után észlelhetők.

Megoldási megközelítés:

  • STRIDE fenyegetésmodellezés: Implementált Microsoft Threat Modeling Tool az összes mikroszolgáltatáshoz és API-végponthoz az architektúrát és a bizalmas adatfolyamokat megjelenítő adatfolyam-diagramokkal.
  • Biztonsági bajnokok program: Betanított fenyegetésmodellezési segítők minden fejlesztőcsapatban, amely a központi biztonsági csapat szűk keresztmetszete nélkül teszi lehetővé a biztonsági tervezést.
  • Automatizált munkafolyamat-integráció: Az integrált fenyegetésmodell áttekintése az Azure DevOps lekéréses kérelmek munkafolyamataiba, amelyek biztonsági jóváhagyást igényelnek az architekturális módosításokhoz.

Eredmény: Számos biztonsági problémát észlelt az üzembe helyezés előtt, amelyek megakadályozták a lehetséges incidenseket. Jelentősen csökkentette a biztonsági réseket az éles környezetben. A biztonsági felülvizsgálatok minimális időt adtak a fejlesztési ciklushoz.

Kritikussági szint

Biztosan így van.

Vezérlőleképezés

  • NIST SP 800-53 Rev.5: SA-11, SA-15, PL-8, RA-3, RA-5
  • PCI-DSS v4: 6.3.1, 6.3.2, 12.3.1
  • CIS-vezérlők v8.1: 14.2, 14.3
  • NIST CSF 2.0-s verzió: ID.RA-3, PR. IP-2
  • ISO 27001:2022: A.5.12, A.8.25
  • SOC 2: CC3.2, CC7.1

DS-2: A szoftverellátási lánc védelme

Biztonsági alapelv

A függőségek zéró megbízhatóságának megvalósítása az integráció előtt az összes külső összetevő származási, integritási és biztonsági helyzetének ellenőrzésével. Folyamatosan vizsgálja a függőségeket a biztonsági rések után, fenntartja az átfogó szoftverjegyzéket (SBOM), és automatikus biztonsági frissítéseket kényszerít ki az ellátási lánc támadási felületének minimalizálása érdekében.

Kockázat csökkentése

A szoftverellátási lánc támadásai kritikus fenyegetést jelentenek, mivel a támadók minimális erőfeszítéssel kihasználják a szervezetek és a külső összetevők közötti megbízhatósági kapcsolatokat, hogy széles körű hatást érjenek el. Az ellátási lánc átfogó biztonsága nélkül:

  • Rosszindulatú függőségek: A támadók hátsóajtókat injektálnak népszerű nyílt forráskódú könyvtárakba (SolarWinds-stílusú támadások), vagy olyan typosquatted csomagokat hoznak létre, amelyek rosszindulatú kódot hajtanak végre a telepítés vagy a futtatás közben.
  • Sebezhető külső kódtárak: A függőségek ismert CVE-i (Log4Shell, Heartbleed, Struts biztonsági sebezhetőségek) hetekig vagy hónapokig nem kerülnek javításra a láthatóság hiánya és az automatikus sebezhetőségkezelés miatt.
  • Sérült buildösszetevők: A támadók módosítják a lefordított bináris fájlokat, tárolólemezképeket vagy üzembehelyezési csomagokat a tárolás vagy átvitel során, és olyan kártevőket injektálnak, amelyek áthaladnak a forráskód áttekintésében.
  • Függőségi zavarokkal kapcsolatos támadások: A rosszindulatú aktorok olyan csomagokat töltenek fel a nyilvános adattárakba, amelyek neve megegyezik a belső privát csomagokkal, és kihasználják a csomagkezelő megoldási logikáját a rosszindulatú kódok helyettesítésére.
  • Tranzitív függőség kockázatai: A közvetett függőségek (függőségek függőségei) biztonsági rései észrevétlenek maradnak, ha nem végezzük el alaposan a függőségi fa elemzését és az SBOM létrehozását.
  • Az eredetellenőrzés hiánya: A titkosítási ellenőrzés hiánya lehetővé teszi a csomaghelyettesítési támadásokat, ha a megbízható csomagokat rosszindulatú verziókra cserélik.

Az ellátási lánc kompromisszuma lehetővé teszi a széles körű hatást, a megbízható könyvtárakban lévő tartós hátsóajtókat és a nagy rejtőzködést a megbízható megjelenés miatt.

MITRE ATT&CK

  • Initial Access (TA0001): az ellátási lánc sérülése (T1195.001) a szoftverfüggőségek és a fejlesztési eszközök veszélyeztetése révén, hogy kezdeti lábra álljon a célkörnyezetekben, és megbízható kapcsolat (T1199) kihasználja a szervezetek és a külső szoftvergyártók közötti megbízhatóságot a rosszindulatú frissítések kézbesítéséhez.
  • Végrehajtás (TA0002): parancs- és parancsfájl-értelmező (T1059) a függőségtelepítési szkriptekbe vagy a telepítés utáni horgokba beágyazott rosszindulatú kód végrehajtására.
  • Kitartás (TA0003): az ügyfélszoftver binárisának kompromittálása hátsó ajtók beépítésével olyan lefordított könyvtárakba, amelyek megmaradnak az alkalmazás frissítései során.

DS-2.1: Függőségek vizsgálata és kezelése

A függőségek átfogó biztonsági kezelése megakadályozza az ellátási lánc támadásait azáltal, hogy megőrzi az összes külső összetevő láthatóságát, folyamatosan figyeli a biztonsági réseket, és automatizálja a szervizelési folyamatokat. A modern alkalmazások több száz vagy több ezer függőségre támaszkodnak (közvetlen és tranzitív), ami lehetetlenné teszi a manuális biztonsági felmérést, és kiterjedt támadási felületet hoz létre sebezhető kódtárakon keresztül. Az automatikus függőségvizsgálat folyamatos monitorozással biztosítja, hogy a szervezetek észleljék és orvosolják a biztonsági réseket a kihasználás előtt.

Folyamatos függőségi biztonság létrehozása az alábbi alapvető képességeken keresztül:

  • Átfogó láthatóság és SBOM-generáció létrehozása: Hozzon létre folyamatos függőségi biztonsági felügyeletet három alapvető funkcióval: átfogó láthatóság, automatizált sebezhetőség-észlelés és proaktív szervizelés. Először hozzon létre teljes függőségi leltárakat, amelyek a közvetlen függőségeket (a csomagjegyzékekben explicit módon deklarálva) és a tranzitív függőségeket (függőségek függőségeit) az összes adattárra leképezik. A szoftveres anyagjegyzék (SBOM) karbantartása iparági szabványformátumokban (SPDX, CycloneDX) a jogszabályi megfelelőség és az incidensmegoldások felkészültsége érdekében.

  • Automatizált biztonságirés-vizsgálat és -szervizelés implementálása: Automatizált biztonságirés-vizsgálat implementálása, amely folyamatosan figyeli a nemzeti biztonságirés-adatbázis (NVD), a GitHub Advisory Database és a nyelvspecifikus biztonsági tanácsadók függőségeit. Valós idejű riasztások konfigurálása új CVE-k közzétételekor, amelyek befolyásolják a függőség-halmazt, súlyosságon alapuló irányítással a megfelelő csapatokhoz. Olyan automatikus biztonsági frissítési képességek engedélyezése, amelyek lekéréses kérelmeket hoznak létre függőségi verziófrissítésekkel, beleértve a kompatibilitási tesztelést és az intelligens egyesítési ütközések feloldását a manuális szervizelési terhek csökkentése érdekében.

  • A biztonsági ellenőrzések integrálása a fejlesztési munkafolyamatokba: Integrálja a függőségi biztonsági ellenőrzéseket közvetlenül a fejlesztési munkafolyamatokba lekéréses kérelmek áttekintésével, amelyek automatikusan értékelik a függőségi változtatások biztonsági hatását, és megjelölik az új függőségeket ismert biztonsági résekkel, licencmegfelelőségi problémákkal vagy gyanús jellemzőkkel (elíráscsapdázás, a karbantartói hírnév hiánya). Jóváhagyási kapukat hozhat létre a magas kockázatú függőségek változásaihoz, és olyan szabályzatokat kényszeríthet ki, amelyek tiltják a kritikus biztonsági résekkel rendelkező függőségeket a védett ágakba való egyesítéstől.

  • Láthatóság kiterjesztése az éles környezetekre: A forráskódon túli láthatóság kiterjesztése az üzembe helyezett környezetekre olyan eszközökkel, mint a Microsoft Defender for Cloud DevOps Security , a kódfüggőségek és a futó számítási feladatok korrelációja, a függőségi láncokon keresztüli támadási útvonalak azonosítása, valamint a tényleges éles kitettség alapján történő szervizelés rangsorolása az elméleti kockázat helyett. Az olyan eszközök, mint a GitHub Advanced Security , átfogó függőségi gráfvizualizációt, Dependabot-alapú automatizált frissítéseket és egyéni biztonságirés-mintákat biztosítanak a védett csomag ökoszisztémáihoz.

Megvalósítási példa

Egy egészségügyi szervezet kártékony npm-csomagot észlelt az éles alkalmazásban, amely hónapokig kiszivárogtatta a betegadatokat. A vizsgálat kiterjedt sebezhető függőségeket tárt fel ismert CV-ekkel, beleértve a kritikus Log4Shell-sebezhetőséget is.

Kihívás: Több ezer függőség több száz adattárban, amelyek nem láthatók a biztonsági résekben vagy a rosszindulatú csomagokban. A manuális függőségi felülvizsgálatok alkalmazásonként heteket használnak fel. A szabályozási ellenőrzés kritikus ellátási láncbeli hiányosságokat észlelt.

Megoldási megközelítés:

  • Automatizált biztonságirés-kezelés: Engedélyezve lett a GitHub Advanced Security a Dependabot által végzett függőségvizsgálattal és a biztonsági frissítésekhez kapcsolódó pull kérések automatikus létrehozásával.
  • Ellátási lánc átláthatósága:ImplementáltUk a Microsoft SBOM eszközt , amely SPDX formátumban hozza létre a szoftverjegyzéket a jogszabályi megfelelőség és az incidensek elhárításához.
  • Csomagellenőrzés: Konfigurált Azure Artifacts aláírás-ellenőrzéssel és függőségi rögzítéssel, amely megakadályozza a keveredési támadásokat és a jogosulatlan csomag-helyettesítést.
  • DevOps biztonsági monitorozás: Üzembe helyezte a Microsoft Defender for Cloud DevOps Securityt a kód–felhő nyomon követhetőség érdekében.

Eredmény: Gyorsan észlelte és orvosolta a kiterjedt sebezhető függőségeket. Automatizált ellenőrzéssel megakadályozott több kártékony csomag incidenst. Az átfogó SBOM-dokumentációnak való jogszabályi megfelelőség elérése.

Kritikussági szint

Biztosan így van.

Vezérlőleképezés

  • NIST SP 800-53 Rev.5: SR-3, SR-4, SR-6, SA-12, SA-15(9), RA-5
  • PCI-DSS v4: 6.2.4, 6.3.2, 6.3.3
  • CIS-vezérlők v8.1: 16.1, 16.2, 16.11
  • NIST CSF 2.0-s verzió: ID.SC-2, ID.SC-4, DE. CM-8
  • ISO 27001:2022: A.5.19, A.5.22, A.5.23
  • SOC 2: CC3.2, CC8.1

DS-3: A DevOps-infrastruktúra védelme

Biztonsági alapelv

Átfogó titkos kódok kezelésével, jóváhagyási kapukkal rendelkező folyamathozzáférési vezérlőkkel, biztonságos buildügynök-konfigurációval és folyamatos monitorozással valósítható meg az infrastruktúra részletes védelme. Szüntesse meg a merevlemezes hitelesítő adatokat, és kényszerítse ki a minimális jogosultsági hozzáférést a szoftverfejlesztési és üzembehelyezési folyamat integritásának védelme érdekében.

Kockázat csökkentése

A nem biztonságos DevOps-infrastruktúra kritikus biztonsági réseket hoz létre, amelyeket a támadók kihasználnak a teljes szoftverkézbesítési lánc veszélyeztetése érdekében. Átfogó infrastruktúra-biztonság nélkül:

  • Sérült CI/CD-csővezetékei: A támadók ellopott hitelesítő adatokkal, kihasznált biztonsági résekkel vagy belső hozzáféréssel férhetnek hozzá az építési csatornákhoz, lehetővé téve a kódinjektálást, az összetevők meghamisítását, vagy az összes későbbi felhasználót érintő üzembe helyezési manipulációt.
  • Fedett titkok a buildnaplókban és -összetevőkben: Rögzített hitelesítő adatok, API-kulcsok, tanúsítványok és kapcsolati sztringek szivárognak ki a pipeline-naplókon, hibaüzeneteken vagy lefordított összetevőkön keresztül, lehetővé téve a támadók számára a közvetlen hozzáférést az éles környezetekhez.
  • Jogosulatlan folyamatmódosítások: A módosítás-vezérlési és jóváhagyási munkafolyamatok hiánya lehetővé teszi a rosszindulatú szereplők számára a folyamatdefiníciók módosítását, a rosszindulatú buildelési lépések beszúrását vagy az üzembehelyezési konfigurációk észlelésének nélküli módosítását.
  • Nem megfelelő hozzáférés-vezérlés: A túlzottan megengedő szerepkör-hozzárendelések és a feladatok elkülönítésének hiánya lehetővé teszi az oldalirányú mozgást, a jogosultságok eszkalálását és az állandó hozzáférés létrehozását a DevOps-infrastruktúrán belül.
  • Nem biztonságos build-ügynökök: A nem javított, helytelenül konfigurált vagy feltört build-ügynökök állandó hozzáférést biztosítanak a támadóknak a buildkörnyezethez és a potenciális megkerülési pontokhoz az éles hálózatokba történő bejutásra.
  • Hiányzó auditnaplók: A DevOps-tevékenységek nem megfelelő naplózása és monitorozása megakadályozza a jogosulatlan hozzáférés, gyanús módosítások vagy belső fenyegetések észlelését.

Az infrastruktúra sérülése lehetővé teszi, hogy a támadók kódokat injektálnak a forrásnál, megkerüljék a megbízható folyamatokat, és minden alárendelt alkalmazást érintenek.

MITRE ATT&CK

  • Kezdeti hozzáférés (TA0001): érvényes fiókok (T1078) ellopott hitelesítő adatokkal vagy szolgáltatásnév titkos kódokkal a DevOps-platformokhoz és -folyamatokhoz való hozzáféréshez.
  • Perzisztencia (TA0003): fiókmanipuláció (T1098) háttérszolgáltatás hitelesítőinek, személyes hozzáférési jogkivonatoknak vagy SSH kulcsoknak a létrehozása a fenntartott hozzáférés érdekében.
  • Hitelesítő adatok elérése (TA0006):: nem biztonságos hitelesítő adatok (T1552.001) titkos kulcsok kinyerése folyamatnaplókból, környezeti változókból vagy konfigurációs fájlokból.
  • Védelmi kijátszás (TA0005): a védelem gyengítése (T1562) a biztonsági vizsgálati lépések, az auditnaplózás vagy a jóváhagyási kapuk letiltásával a folyamatdefiníciókban.

DS-3.1: Titkos kódok kezelésének implementálása folyamatokhoz

A központi titkos kódok kezelése kiküszöböli a devOps-folyamatok hitelesítőadat-kitettségét azáltal, hogy eltávolítja a kódból, a konfigurációs fájlokból és a folyamatdefiníciókból a merevlemezes titkos kódokat. A pipeline YAML fájlokba, környezeti változókba vagy forrásadattárakba beágyazott hitelesítő adatok jelentik a folyamat feltörésének elsődleges támadási vektorát. Az adattárakhoz vagy naplókhoz hozzáférő támadók hozzáférhetnek és kinyerhetik a gyártási hitelesítő adatokat. A kriptográfiai védelemmel ellátott titkos tár dinamikus lekéréses és igény szerint történő hozzáférési mintákkal történő implementálása megakadályozza a hitelesítő adatok ellopását, miközben fenntartja a működési hatékonyságot.

Titkos kulcsok kezelésének konfigurálása az alábbi biztonsági vezérlőkkel:

  • Beégetett hitelesítő adatok eltávolítása központosított tárhellyel: Távolítsa el a beégetett hitelesítő adatokat a folyamatdefiníciókból és a forráskódból úgy, hogy az összes titkos adatot a dedikált titkos kódkezelési infrastruktúrában helyezi el, amely kriptográfiai hozzáférés-vezérléssel és átfogó naplózási nyomokkal rendelkezik. Állapítsa meg azt az elvet, hogy a titkos kulcsokat soha nem szabad folyamat YAML-fájlokban, naplókban látható környezeti változókban vagy adattárak konfigurációs fájljaiban tárolni– ezek a DevOps-környezetekben a hitelesítő adatok expozíciójának elsődleges vektorai.

  • Dinamikus titkos kódok lekérésének konfigurálása felügyelt identitásokkal: Központosított titkos tárat valósít meg olyan megoldásokkal, mint az Azure Key Vault , amely titkosított titkos tárat, részletes hozzáférési szabályzatokat, automatikus titkos kulcsváltást és átfogó naplózást biztosít. Konfigurálja a folyamatokat úgy, hogy futásidőben dinamikusan lekérjék a titkos kulcsokat a biztonságos szolgáltatáskapcsolatokon keresztül, és ne ágyazza be őket a folyamatdefiníciókba. Felügyelt identitások vagy számítási feladatok identitás-összevonásával hitelesítheti a titkos tárolókhoz való folyamathozzáférést, így nincs szükség hosszú élettartamú szolgáltatásnév hitelesítő adataira, amelyek maguk is lopás célpontjává válnak.

  • Igény szerint történő hozzáférés kényszerítése jóváhagyási kapukkal: Igény szerinti titkos kódok hozzáférési mintáinak kényszerítése, ahol a titkos kulcsok csak szükség esetén lesznek lekérve, a folyamat befejezése után automatikus visszavonással minimalizálva a hitelesítő adatok élettartamának kitettségét. Időkorlátos hozzáférési korlátozásokat valósíthat meg, és többszemélyes hitelesítést (jóváhagyási kapukat) igényel az éles titkos kulcsokhoz való folyamathozzáféréshez, biztosítva, hogy egyetlen feltört fiók se férhessen hozzá a bizalmas hitelesítő adatokhoz további ellenőrzés nélkül.

  • Rétegzett infrastruktúra-hozzáférési vezérlők létrehozása: Rétegzett hozzáférés-vezérlések létrehozása a DevOps-infrastruktúrához: a folyamatmódosítási jogosultságok korlátozása a biztonsági szempontból ellenőrzött személyzet számára, környezetspecifikus engedélyek kikényszerítése az éles üzemelő példányok jóváhagyásához, adattárszintű szolgáltatáskapcsolati korlátozások implementálása, amelyek megakadályozzák, hogy a folyamatok hozzáférjenek a titkos kulcsokhoz a kívánt hatókörön kívül, és a bizalmas számítási feladatokhoz hálózati elkülönítéssel rendelkező, saját üzemeltetésű buildügynököket helyezzenek üzembe. Integrálja az infrastruktúra kódként történő biztonsági vizsgálatát a folyamatokba, hogy megakadályozza a titkos kulcsokat felfedő vagy jogosulatlan hozzáférési útvonalakat létrehozó helytelen erőforrások üzembe helyezését.

Megvalósítási példa

Egy kiskereskedelmi szervezet adatsértést szenvedett el, amikor támadók a folyamatnaplókban talált ellopott szolgáltatás-principal hitelesítő adatokat használták fel az éles adatbázisok eléréséhez, ezzel több millió ügyfélrekordot tettek hozzáférhetővé.

Kihívás: A folyamatváltozókban rögzített adatbázis-kapcsolati sztringek és API-kulcsok. A túlságosan megengedő folyamatengedélyek lehetővé tették, hogy bármely fejlesztő üzembe helyezhesse az éles környezetben. A buildügynök kompromittálása állandó hozzáférést biztosított az infrastruktúrához.

Megoldási megközelítés:

  • Központosított titkos kódok kezelése: Implementált Azure Key Vault-integráció , amely kiküszöböli a merevlemezes titkos kódokat a folyamatokból. Konfigurált felügyelt identitáshitelesítés, amely eltávolítja a hitelesítő adatok expozíciós kockázatát.
  • Folyamathozzáférés-vezérlők: Jóváhagyási pontokat és környezetspecifikus engedélyeket hoztunk létre az Azure DevOps-környezetek használatával, amelyek a biztonsági csapat jóváhagyását igénylik az éles környezetbe történő telepítésekhez.
  • Edzett buildügynökök: A szabályozott adatokat feldolgozó bizalmas számítási feladatokhoz telepített, biztonsági korlátozással és hálózati elkülönítéssel rendelkező, saját üzemeltetésű ügynökök.
  • Infrastruktúra biztonsági vizsgálata: Integrált biztonsági ellenőrzés ARM-sablonokhoz és Terraform-konfigurációkhoz, amelyek megakadályozzák a helytelen konfiguráció üzembe helyezését.

Eredmény: A hitelesítő adatok ellopását megakadályozó folyamatnaplók titkos kulcsainak eltávolítása. Megszüntette a jogosulatlan üzembe helyezést. Az üzembe helyezést megelőzően észlelt és letiltott infrastruktúra hibás konfigurációk.

Kritikussági szint

Biztosan így van.

Vezérlőleképezés

  • NIST SP 800-53 Rev.5: AC-2, AC-3, AC-6, SC-12, SC-13, AU-2, AU-6
  • PCI-DSS v4: 8.3.2, 8.6.1, 8.6.3, 12.3.3
  • CIS-vezérlők v8.1: 4.1, 4.7, 6.1, 6.5
  • NIST CSF 2.0-s verzió: PR. AC-4, PR. DS-5, DE. CM-7
  • ISO 27001:2022: A.5.15, A.5.16, A.8.3
  • SOC 2: CC6.1, CC6.6, CC6.7

DS-4: Statikus alkalmazásbiztonsági tesztelés (SAST) integrálása

Biztonsági alapelv

Átfogó automatizált biztonsági tesztelés implementálása több speciális statikus alkalmazásbiztonsági tesztelési (SAST) szkenneren keresztül, amely minden buildelési folyamatba integrálva van. Használjon többszkenneres lefedettséget az átfogó észleléshez, a leküldéses védelemmel rendelkező titkos kódok vizsgálatának implementálásához, valamint szemantikai kódelemzés üzembe helyezéséhez a biztonsági rések azonosításához és blokkolásához, mielőtt éles környezetbe jutnának.

Kockázat csökkentése

A fejlesztés során az észlelés elől menekülő kódszintű biztonsági rések állandó biztonsági hiányosságokat hoznak létre, amelyeket a támadók rendszeresen kihasználnak. Átfogó SAST-integráció nélkül:

  • Injektálási biztonsági rések: Az SQL-injektálás, a helyek közötti szkriptelés (XSS), a parancsinjektálás és az LDAP-injektálási hibák lehetővé teszik a támadók számára az alkalmazáslogika manipulálását, bizalmas adatok kinyerését vagy tetszőleges kód végrehajtását.
  • Rögzített hitelesítő adatok: A fejlesztők véletlenül jelszavakat, API-kulcsokat, tanúsítványokat és kapcsolati karakterláncokat helyeznek el a forráskód-tárházakba, így közvetlen hozzáférést biztosítanak a támadóknak az éles rendszerekhez és adatokhoz.
  • Nem biztonságos titkosítási implementációk: A gyenge titkosítási algoritmusok (DES, MD5), a merevlemezes titkosítási kulcsok, a helytelen inicializálási vektorok vagy az elégtelen kulcshosszok veszélyeztetik az adatok bizalmasságát és integritását.
  • Puffer túlcsordulása és memóriasérülés: A C/C++ alkalmazások nem biztonságos memóriaműveletei lehetővé teszik a kód tetszőleges végrehajtását, a jogosultságok eszkalálását és a szolgáltatásmegtagadási támadásokat.
  • Üzleti logika hibái: A hitelesítési átmenő forgalom, az engedélyezési hiányosságok, a versenyfeltételek és az elégtelen bemeneti ellenőrzés lehetővé teszi a jogosultságok eszkalálását, a csalást és a jogosulatlan hozzáférést.
  • Az infrastruktúra mint kód (IaC) helytelen konfigurációi: A nem biztonságos Terraform-, ARM-sablonok vagy Kubernetes-jegyzékek sebezhető infrastruktúrát helyeznek üzembe túlzottan megengedő hozzáféréssel, hiányzó titkosítással vagy közzétett felügyeleti végpontokkal.

Az automatizált SAST hiányában a biztonsági rések technikai adósságként halmozódnak fel, meghosszabbítják a tartózkodási időt, és költségessé válnak az éles környezetben történő szervizeléshez.

MITRE ATT&CK

  • Kezdeti hozzáférés (TA0001): a nyilvános elérésű alkalmazás (T1190) kihasználása az alkalmazáskódban található injektálási biztonsági rések vagy hitelesítési megkerülők kihasználásával.
  • Végrehajtás (TA0002): az ügyfélvégrehajtás (T1203) kihasználása az olyan ügyféloldali biztonsági rések kihasználásához, mint az XSS vagy a nem biztonságos deszerializálás.
  • Hitelesítő adatok elérése (TA0006): jelszótárakból (T1555) származó hitelesítő adatok, amelyek a forráskódból, konfigurációs fájlokból vagy lefordított bináris fájlokból nyerik ki a merevlemezes hitelesítő adatokat.
  • Jogosultságok eszkalálása (TA0004): a jogosultságok eszkalálása (T1068) kihasználja a pufferek túlcsordulását vagy a memória sérülését emelt szintű hozzáférés esetén.

DS-4.1: Többszkenneres SAST-folyamat implementálása

Az összes buildbe integrált átfogó statikus alkalmazásbiztonsági tesztelés a kódszintű biztonsági rések korai észlelését teszi lehetővé, mielőtt éles környezetekbe érnének. A modern alkalmazások különböző nyelveket, keretrendszereket és infrastruktúrát használnak, amelyek speciális elemzőket igényelnek– egyetlen szkenner sem észleli az összes sebezhetőségi osztályt. A speciális eszközöket automatikus végrehajtással és minőségi kapukkal kombináló többrétegű SAST-stratégiák átfogó lefedettséget biztosítanak, miközben a fejlesztők azonnali visszajelzést kapnak a biztonsági problémák észlelésekor.

Automatizált biztonsági tesztelés implementálása az alábbi összetevőkkel:

  • Többrétegű vizsgálati stratégia implementálása: Automatikus statikus alkalmazásbiztonsági tesztelés beágyazása minden buildbe, hogy észlelje a biztonsági réseket, mielőtt a kód éles környezetbe kerül. Többrétegű SAST-stratégia implementálása, amely több speciális szkennert kombinál– egyetlen eszköz sem észleli az összes biztonságirés-osztályt, így az átfogó lefedettséghez nyelvspecifikus elemzőkre (Python, JavaScript, C/C+++), kódként szolgáló infrastruktúra-szkennerekre (Terraform, ARM-sablonok, Kubernetes-jegyzékek), titkos kódok észlelésére és szemantikai kódelemzésre van szükség az összetett adatfolyamok biztonsági réseihez.

  • Automatikus végrehajtás konfigurálása minőségi kapukkal: Konfigurálja a SAST-vizsgálatot úgy, hogy minden véglegesítési és lekéréses kérelem automatikusan végre legyen hajtva, így a fejlesztők azonnal visszajelzést kaphatnak a biztonsági problémákról, miközben a kódkörnyezet friss. Súlyossági alapú minőségi kapuk létrehozása, amelyek blokkolják az egyesítéseket vagy az üzembe helyezéseket kritikus vagy nagy súlyosságú biztonsági rések észlelésekor, megakadályozva a sebezhető kód továbbhaladását a folyamaton. A képolvasók konfigurálásával szabványosított formátumban (SARIF) jeleníthetők meg a találatok, így konzisztens biztonsági rések nyomon követése, deduplikáció az eszközök között, valamint integráció a központosított biztonsági irányítópultokkal.

  • Tegye lehetővé a titkos kódvizsgálat üzembe helyezését leküldéses védelemmel: Valósítsa meg a speciális titkos kódvizsgálatot leküldéses védelemmel, amely megakadályozza, hogy a fejlesztők hitelesítő adatokat, API-kulcsokat, tanúsítványokat vagy jogkivonatokat tegyenek közzé az adattárakban. Így a titkos kódok a véglegesítéskor kerülnek elkapásra, ahelyett, hogy azok hetekkel később auditvizsgálatok során fedeznék fel azokat. Támogatja a szabványos titkos mintákat (AWS-kulcsok, Azure-jogkivonatok, adatbázis-kapcsolati sztringek) és egyéni szervezetspecifikus mintákat a védett hitelesítési mechanizmusokhoz. Titkos kódok észlelésekor azonnali szervizelési útmutatást adhat, beleértve a hitelesítő adatok rotálási eljárásait és a biztonságos alternatívákat.

  • Használjon szemantikai kódelemzést összetett biztonsági résekhez: Olyan szemantikai kódelemző eszközöket telepíthet, mint a GitHub CodeQL , amely részletes adatfolyam-elemzést végez a mintaegyeztető szkennerek számára láthatatlan összetett biztonsági rések azonosításához, például sql-injektálás több függvényhíváson keresztül, hitelesítési megkerülések az üzleti logikában, vagy nem biztonságos deszerializálási láncok. Egyéni biztonsági lekérdezéseket hozhat létre a szervezet keretrendszereihez, biztonsági követelményeihez és az incidensek visszamenőlegesen azonosított gyakori sebezhetőségi mintáihoz igazítva. Az SAST-megállapításokat közvetlenül integrálhatja a fejlesztői munkafolyamatokba a lekéréses kérelmek megjegyzéseivel, konkrét sorszámokkal, biztonságirés-magyarázatokkal és szervizelési javaslatokkal.

  • Vezénylés egységes platformokkal: Az egyesített SAST-platformok, például a Microsoft Biztonság DevOps Extension több speciális szkennert (AntiMalware, Bandit, BinSkim, Checkov, ESLint, Template Analyzer, Terrascan, Trivy) vezényelhetnek egyetlen folyamatfeladaton keresztül, szabványosíthatják a konfigurációkezelést és az eredmények összesítését heterogén eszköz-ökoszisztémákban.

Megvalósítási példa

Egy SaaS-szolgáltató sql-injektálási támadást szenvedett, amely több százezer ügyfélrekordot adott ki. Az incidens utáni elemzés kiterjedt kódszintű biztonsági réseket tárt fel, beleértve a rögzített hitelesítő adatokat és a hónapok óta fennálló injektálási hibákat.

Kihívás: A manuális kódismétlések csak a biztonsági rések egy kis részét ütötték ki. A fejlesztők nem rendelkeztek biztonsági képzésekkel az injektálási hibák és a titkosítási hiányosságok azonosításához. Nincs automatikus vizsgálat az éles üzembe helyezés előtt.

Megoldási megközelítés:

  • Többszkenneres SAST: Üzembe helyezte a Microsoft Biztonság DevOps-bővítményt a CodeQL, az ESLint és a Bandit használatával, amely átfogó lefedettséget biztosít a nyelvek és a biztonságirés-típusok között.
  • Titkos kódok védelme: A GitHub Advanced Security implementálása titkos kulcsok vizsgálatával és leküldéses védelemmel, amely megakadályozza a hitelesítő adatoknak való kitettséget a véglegesítésekben.
  • Szemantikai elemzés: A GitHub CodeQL-t egyéni lekérdezésekkel konfigurálta az üzleti logikai biztonsági rések és a keretrendszerspecifikus biztonsági minták érdekében.
  • Biztonsági kapuk: Az Azure Pipelinesban létrehozott folyamatkapuk megakadályozzák a nagy súlyosságú eredmények üzembe helyezését.

Eredmény: Gyorsan azonosította és elhárította a kiterjedt biztonsági réseket. Megakadályozta, hogy a kritikus biztonsági hibák elérjék az éles üzemet. Jelentősen csökkentették a biztonsági adósságot.

Kritikussági szint

Biztosan így van.

Vezérlőleképezés

  • NIST SP 800-53 Rev.5: SA-11, RA-5, SI-2
  • PCI-DSS v4: 6.3.2, 6.4.1, 11.3.1
  • CIS-vezérlők v8.1: 16.3, 16.6
  • NIST CSF 2.0-s verzió: PR. IP-2, DE. CM-4
  • ISO 27001:2022: A.8.25, A.8.29
  • SOC 2: CC7.1, CC7.2

DS-5: Dinamikus alkalmazásbiztonsági tesztelés (DAST) integrálása

Biztonsági alapelv

Átfogó dinamikus biztonsági tesztelés implementálása tesztkörnyezetekben, konténerbiztonsági ellenőrzéssel a konténerizált számítási feladatokra, a webalkalmazások és alkalmazásprogramozási felületek (API-k) automatizált behatolási tesztelésével, valamint speciális tesztekkel a hitelesítés, engedélyezés és munkamenet-kezelés területén. A futtatókörnyezet ellenőrzése azonosítja azokat a konfigurációs hiányosságokat és integrációs biztonsági réseket, amelyeket a statikus elemzés nem tud észlelni.

Kockázat csökkentése

A statikus elemzés számára láthatatlan futtatókörnyezeti biztonsági rések kritikus biztonsági réseket hoznak létre, amelyeket a támadók az alkalmazások üzembe helyezése után kihasználnak. Átfogó DAST nélkül:

  • Az üzembe helyezés konfigurációjának gyengeségei: A helytelenül konfigurált hitelesítési szolgáltatók, a megengedő CORS, a gyenge TLS-konfigurációk vagy a hiányzó biztonsági fejlécek (CSP, HSTS, X-Frame-Options) lehetővé teszik a támadásokat, amelyeket a forrásvizsgálat nem tud kimutatni.
  • API-biztonsági rések: A REST- és GraphQL API-k hitelesítéssel, engedélyezési hibákkal, túlzott adatexpozícióval, hiányzó sebességkorlátozással vagy nem biztonságos közvetlen objektumhivatkozásokkal (IDOR) teszik lehetővé a jogosulatlan hozzáférést és az adatok kinyerését.
  • Hitelesítési és engedélyezési megkerülő adatok: A munkamenet-kezelés, a jelszó-visszaállítási folyamatok, a többtényezős hitelesítés implementálása vagy a szerepköralapú hozzáférés-vezérlési logika hibái lehetővé teszik a jogosultságok eszkalálását és a fiókok átvételét.
  • Munkamenet-kezelési sérülékenységek: A kiszámítható munkamenet-tokenek, a nem megfelelő időtúllépés-kényszerítés, a munkamenet-rögzítés sérülékenységei vagy a hiányzó token-visszavonás lehetővé teszik a munkamenet-eltérítést és a hitelesítő-adatlopást.
  • Környezetspecifikus biztonsági problémák: Az adatbázisokkal, üzenetsorokkal, külső API-kkal vagy külső szolgáltatásokkal való integrációs pontok futásidejű biztonsági réseket vezetnek be, amelyek nem láthatók a fejlesztés vagy az izolált tesztelés során.
  • Üzleti logika hibái: A versenyfeltételek, az állapotmanipuláció biztonsági rései, az összetett munkafolyamatok nem megfelelő bemeneti ellenőrzése vagy a tranzakcióintegritási problémák lehetővé teszik a csalást és az adatmanipulációt.

A DAST ellenőrzi a futtatókörnyezet viselkedését, a környezet konfigurációját és az integráció biztonságát biztosító lefedettségi statikus elemzést.

MITRE ATT&CK

  • Kezdeti hozzáférés (TA0001): kihasználni a nyilvános elérésű alkalmazást (T1190) az olyan hitelesítési megkerülések, injektálási hibák és biztonságtalan API-végpontok révén, amiket futásidejű tesztelés során fedeznek fel.
  • Hitelesítőadat-hozzáférés (TA0006): brute force támadás (T1110) a hiányzó kéréskorlátozás, a gyenge jelszóházirendek vagy a DAST során észlelt kiszámítható munkamenet tokenek kihasználására.
  • Jogosultságok eszkalálása (TA0004): érvényes fiókok (T1078) kihasználják az engedélyezett átjárókat vagy a szerepkör-manipuláció biztonsági réseit az üzembe helyezett alkalmazásokban.
  • Gyűjtemény (TA0009): az információtárakból (T1213) származó adatok, amelyek túlzott API-válaszok, címtárbejárás vagy nem biztonságos közvetlen objektumhivatkozási biztonsági rések révén nyernek ki bizalmas adatokat.
  • Exfiltration (TA0010): a webszolgáltatáson (T1567) végzett exfiltráció az API biztonsági réseit kihasználva észlelés nélkül kinyeri az adatokat nagy méretekben.

DS-5.1: Automatizált DAST implementálása az előgyártásban

A dinamikus alkalmazásbiztonsági tesztelés ellenőrzi a futó alkalmazások biztonsági vezérlőit, és felderíti azokat a futtatókörnyezeti biztonsági réseket, amelyeket a statikus elemzés nem képes észlelni. Míg az SAST megvizsgálja a forráskódot, a DAST éles környezethez hasonló konfigurációkkal teszteli az üzembe helyezett alkalmazásokat, hogy azonosítsa az üzembe helyezéssel kapcsolatos problémákat, például a hitelesítési helytelen konfigurációkat, az engedélyezési hibákat és az integrációs biztonsági réseket, amelyek csak az üzemeltetési környezetekben jelentkeznek. Az éles üzem előtti automatizált DAST biztosítja a biztonsági ellenőrzést az ügyfelek expozíciója előtt, miközben valós támadási forgatókönyveket tesztel az integrált rendszerek ellen.

A futtatókörnyezet biztonsági érvényesítésének megvalósítása az alábbi képességekkel:

  • Az SAST kiegészítése futásidejű ellenőrzéssel: A statikus elemzést kiegészítheti dinamikus alkalmazásbiztonsági tesztekkel, amelyek az éles környezethez hasonló konfigurációjú alkalmazások futtatásának biztonságát ellenőrzik. Bár a SAST azonosítja a forráskód biztonsági réseit, a DAST észleli a statikus elemzés számára láthatatlan futtatókörnyezeti problémákat: az üzembe helyezés konfigurációs hibáit (helytelenül konfigurált hitelesítési szolgáltatók, megengedő CORS-szabályzatok, hiányzó biztonsági fejlécek), környezetspecifikus integrációs hibákat (adatbázis-kapcsolat biztonsága, API-engedélyezés az üzembe helyezett környezetekben), valamint olyan üzletilogikai biztonsági réseket, amelyek csak reális üzemeltetési feltételek mellett jelentkeznek.

  • Üzembe helyezés éles környezetekben: A DAST-vizsgálat üzembe helyezése éles üzem előtti előkészítési környezetekben, amelyek tükrözik az éles architektúrát, a hálózati topológiát, a külső függőségeket és a konfigurációs paramétereket. Az automatikus DAST-végrehajtásnak az üzembe helyezéskor aktiválnia kell az előkészítést, a hitelesítési folyamatok szisztematikus tesztelését, az engedélyezési határokat, a munkamenet-kezelést, a bemenet-ellenőrzést, az API-biztonságot és a hibakezelést reális terhelési és használati minták mellett. Ez ellenőrzi, hogy a biztonsági vezérlők megfelelően működnek-e az éles környezethez hasonló külső rendszerekkel (identitásszolgáltatókkal, adatbázisokkal, üzenetsorokkal, külső API-kkal) integrálva.

  • Futtatókörnyezet monitorozásának implementálása tárolókhoz: Tárolóalapú számítási feladatok esetén folyamatos futtatókörnyezeti biztonsági monitorozást valósíthat meg, amely az üzembe helyezés előtti rendszerkép-vizsgálatot és az üzembe helyezés utáni viselkedéselemzést kombinálja. Ellenőrizze a tárolólemezképeket az üzembe helyezés előtt, majd figyelje a futó tárolókat a rendellenes hálózati kapcsolatok, a jogosulatlan folyamatvégrehajtás, a fájlrendszer módosítása és a jogosultságok eszkalálási kísérletei esetén. Normál Kubernetes-számítási feladatok viselkedésének profilozása a kompromisszumot jelző eltérések észleléséhez, valamint a tárolókonfigurációk folyamatos értékelése a CIS-teljesítménytesztek és a biztonsági ajánlott eljárások alapján.

  • Összpontosítson a magas kockázatú támadási felületekre: Koncentráljon speciális DAST-erőfeszítésekre a magas kockázatú támadási felületeken: REST és GraphQL API-k (tesztelési hitelesítő adatok, engedélyezési hibák, injektálási biztonsági rések, túlzott adatexpozíció, nem biztonságos közvetlen objektumhivatkozások), hitelesítés és munkamenet-kezelés (jogkivonat biztonságának ellenőrzése, időtúllépés kényszerítése, kijelentkezési funkciók, jelszó-visszaállítási folyamatok, többtényezős hitelesítés) és üzleti logikai munkafolyamatok (versenyfeltételek tesztelése, állapotkezelés, tranzakcióintegritási problémák). Olyan SAST/DAST korrelációs munkafolyamatokat hozhat létre, amelyek mindkét megközelítés eredményeit egyesítik, és a statikus és a dinamikus elemzéssel megerősített biztonsági réseket részesítik előnyben a legmagasabb kockázatként.

  • Integrált platformok használata: Tárolóalapú környezetek esetén a Microsoft Defender for Containers integrált futtatókörnyezeti biztonságirés-felmérést, számítási feladatprofilozást és fenyegetésészlelési képességeket biztosít a tároló teljes életciklusa során.

Megvalósítási példa

Egy e-kereskedelmi szervezet felfedezte a hitelesítési megkerülő műveletet a fizetési API-ban, amely jogosulatlan kedvezményeket tesz lehetővé. Az SAST nem észlelte a futtatókörnyezet konfigurációs hibáját, amely csak külső hitelesítésszolgáltatókkal rendelkező üzembe helyezett környezetekben nyilvánult meg.

Kihívás: Az SAST a kód biztonsági réseit észlelte, de nem észlelte a futtatókörnyezet konfigurációs problémáit és az API engedélyezési hibáit. Az éles üzembe helyezés konfigurációja eltért a fejlesztéstől, és a statikus elemzés számára láthatatlan biztonsági réseket eredményezett.

Megoldási megközelítés:

  • Automatikus DAST-vizsgálat: Telepített OWASP ZAP előzetes élesítési környezetekben, a telepített alkalmazásokat éles környezethez hasonló konfigurációkkal tesztelve.
  • Tároló futásidejű védelme:Implementálta a Microsoft Defender for Containerst a futtatókörnyezet biztonsági monitorozásához és sebezhetőségi felméréséhez.
  • API-biztonsági tesztelés: Konfigurált speciális API-tesztelés, amely érvényesíti a hitelesítést, az engedélyezést és az adatérvényesítést az üzembe helyezett REST- és GraphQL-végpontokon.
  • SAST/DAST korreláció: Biztonságirés-korrelációs munkafolyamatokat hozott létre, melyek statikus és dinamikus megállapításokat kombinálnak az átfogó biztonsági ellenőrzéshez.

Eredmény: A SAST által elmulasztott futásidejű biztonsági rések, beleértve a hitelesítési megkerülőket és az API engedélyezési hibáit. A biztonsági incidenseket az éles üzem előtti észleléssel előzték meg.

Kritikussági szint

Biztosan így van.

Vezérlőleképezés

  • NIST SP 800-53 Rev.5: SA-11, CA-8, RA-5
  • PCI-DSS v4: 6.4.2, 11.3.2
  • CIS-vezérlők v8.1: 16.7, 16.8
  • NIST CSF 2.0-s verzió: DE. CM-4, PR. IP-12
  • ISO 27001:2022: A.8.29, A.8.30
  • SOC 2: CC7.1, CC7.3

DS-6: A számítási feladatok életciklusának védelme

Azure Policy: Lásd az Azure beépített szabályzatdefinícióit: DS-6.

Biztonsági alapelv

Az immutábilis infrastruktúrát teljes körű képbiztonsággal valósíthatja meg konténer-regiszterek és tároló terhelések biztonsági szkennelésének segítségével, arany képek kezelésével és automatizált építéssel a virtuális gépek (VM) terhelésekhez, valamint a folyamatos sebezhetőség-vizsgálattal és automatizált karanténnal. Ellenőrizze a titkosítási aláírásokat, minimális alaplemezképeket tartson fenn, és a számítási feladatok teljes életciklusa során kényszerítse ki a biztonsági alapkonfigurációkat.

Kockázat csökkentése

A nem biztonságos számítási feladatok életciklus-kezelése lehetővé teszi, hogy a sebezhető vagy sérült összetevők elérjék az éles üzemet, és állandó támadási vektorokat hozzanak létre, amelyeket a támadók szisztematikusan kihasználnak. Átfogó munkaterhelés-biztonság nélkül:

  • Sebezhető éles virtuális gép rendszerképek: A nem javított operációs rendszer alapkonfigurációk vagy a helytelenül konfigurált golden image-ek minden üzembe helyezett virtuális gép gyengeségeit elterjesztik.
  • Javítatlan sebezhető alapképek: A CVE által érintett alapokon (Log4Shell, Heartbleed, OpenSSL) épülő tárolók kiszolgáltatják a számítási feladatokat a kihasználásnak és menekülésnek.
  • Elavult sebezhető összetevők: A be nem vizsgált képek és csomagok összegyűjtik a CVE-ket, és kibővítik a támadási felületet.
  • Nem megfelelő képellenőrzés: A titkosítási aláírás és az eredetellenőrzés hiánya lehetővé teszi a támadók számára, hogy megbízható képeket cseréljenek le a backdoorokat vagy kártevőket tartalmazó feltört verziókra.
  • Blobozott támadási felület: A szükségtelen csomagokat, fejlesztési eszközöket vagy hibakeresési segédprogramokat tartalmazó tárolólemezképek növelik a sebezhetőségnek való kitettséget, és további kihasználási eszközöket biztosítanak a támadóknak.
  • Hiányzó biztonsági alapkonfigurációk: A CIS-teljesítményteszt-megfelelőség, a biztonsági megkonfigurálás vagy a minimális jogosultságkonfiguráció nélkül üzembe helyezett virtuális gépek és tárolólemezképek kihasználható hiányosságokat okoznak a mélységi védelem terén.

A sérült összetevők állandó támadási vektorokká válnak, segítik az oldalirányú mozgást, és jogosnak tűnnek a védők számára.

MITRE ATT&CK

  • Kezdeti hozzáférés (TA0001): a nyilvános elérésű alkalmazás (T1190) kihasználása az alkalmazástárolókban vagy webszolgáltatásokban lévő nem elérhető biztonsági rések kihasználásával.
  • Végrehajtás (TA0002): konténer (T1610) üzembe helyezése, hogy olyan rosszindulatú konténereket telepítsenek, amelyek a nem megfelelő képkép-ellenőrzés miatt hitelesnek tűnnek.
  • Jogosultságok eszkalálása (TA0004): a tároló biztonsági réseit kihasználó gazdagépre való menekülés (T1611) a tárolók elkülönítésének megszüntetésére és a gazdarendszer veszélyeztetésére.
  • Oldalirányú mozgás (TA0008): távoli szolgáltatások kihasználása (T1210), amely során sebezhető virtuális gépek vagy tárolók között mozog, amelyek sérült rendszerképekből lettek üzembe helyezve.

DS-6.1: Konténerkép-biztonság implementálása

A tároló- és virtuálisgép-rendszerképek kritikus támadási felületeket jelentenek, amelyek teljes életciklusuk során átfogó biztonsági vezérlőket igényelnek. A sebezhető alaprendszerképek minden üzembe helyezett példányra terjesztik a gyengeségeket, és felerősíti az infrastruktúrára gyakorolt hatást. A számítási feladatok összetevőinek a forráskóddal (például vizsgálattal, aláírással és biztonságos tárhellyel) azonos biztonsági szigorral történő kezelése biztosítja, hogy a szervezetek csak ellenőrzött, megbízható képeket helyezzenek üzembe, miközben megakadályozzák, hogy a támadók kihasználhassák az ismert biztonsági réseket, vagy rosszindulatú képeket helyettesíthetnek.

A számítási feladatok összetevőinek védelme az alábbi eljárásokkal:

  • Nem módosítható infrastruktúra-alapelvek kialakítása: A tárolólemezképek és a virtuálisgép-rendszerképek kritikus fontosságú összetevőkként vannak kezelve, amelyek ugyanolyan biztonsági szigort igényelnek, mint a forráskód által sebezhető alaprendszerképek, amelyek a gyengeségeket minden üzembe helyezett példányra propagálják. Olyan nem módosítható infrastruktúra-alapelveket hozhat létre, amelyekben a számítási feladatok összetevői egyszer épülnek fel, átfogóan beolvashatók, kriptográfiailag aláírtak és módosítás nélkül üzembe helyezhetők, hogy az egész életciklus során konzisztenciát és nyomon követhetőséget biztosítsanak.

  • Minimális alaprendszerképek használata többfázisú buildekkel: Tároló-számítási feladatok esetén a rétegzett rendszerképek biztonságának megvalósítása minimális alaprendszerképekkel kezdődik, amelyek csak az alapvető futtatókörnyezeti összetevőket tartalmazzák, és jelentősen csökkentik a támadási felületet a teljes operációsrendszer-rendszerképekhez képest. A többfázisú buildek használatával elkülöníthetők a buildidő-függőségek a futtatókörnyezeti rendszerképektől – a funkciógazdag képeken történik a lefordítás és az építés, majd csak a végleges összetevők másolódnak a minimális futásidejű rendszerképekbe, megszüntetve a fejlesztési eszközöket, a csomagkezelők alkalmazását, és a sebezhetőségi kitettséget növelő függőségek létrejöttét, amely eszközöket biztosítana a támadók számára a kihasználáshoz.

  • Automatikus vizsgálat integrálása karanténszabályzatokkal: Integrálhatja az automatikus biztonságirés-vizsgálatot a rendszerkép-összeállítási folyamatba, amely minden lemezképet átvizsgál a beállításjegyzék-tároló előtt, átfogó CVE-adatbázisokon ellenőrzi, és folyamatosan újrakonfigurálja a tárolt lemezképeket az új biztonsági rések közzétételekor. Automatizált karanténszabályzatok implementálása, amelyek megakadályozzák a kritikus vagy nagy súlyosságú biztonsági résekkel rendelkező képek üzembe helyezését, a biztonsági csapat jóváhagyását és dokumentált kockázatelfogadást igénylő kivétel-munkafolyamatokkal. Alaprendszerkép-frissítési szabályzatokat hozhat létre automatikus folyamatindítókkal a biztonsági javítások megjelenésekor, így biztosítva, hogy a rendszerképek ne halmozódják fel a CVE-ket.

  • Kriptográfiai aláírás és ellenőrzés kényszerítése: A képintegritást a buildelés minden szakaszában kriptográfiai aláírással lehet biztosítani, az aláírásokat az üzembe helyezés előtt ellenőrizni kell, és automatikusan el kell utasítani az aláíratlan vagy manipulált képeket. Ez megakadályozza a képhelyettesítési támadásokat, ahol a támadók lecserélik a megbízható képeket a hátsó kapukat tartalmazó kompromittált verziókra. Lemezképeket biztonságos tárolóregisztrációs adatbázisokban tárolhat hálózati hozzáférés-vezérléssel (privát végpontokkal, virtuális hálózati integrációval), szerepköralapú hozzáférési szabályzatokkal, amelyek korlátozzák a rendszerképek leküldését/lekérését, valamint az összes beállításjegyzék-művelet átfogó naplózását.

  • A virtuális gépekhez rögzített aranylemezképek karbantartása: Virtuálisgép-számítási feladatok esetén a központi aranylemezkép-adattárakat a CIS benchmark-kompatibilis, megerősített alaprendszerképeivel kell fenntartani, amelyek rendszeres biztonsági javításon és megfelelőségi ellenőrzésen mennek keresztül. Automatizált rendszerkép-létrehozási folyamatokat implementálhat, amelyek biztonsági frissítéseket tartalmaznak, eltávolítják a szükségtelen szolgáltatásokat, minimális jogosultsági szintű konfigurációkat kényszerítenek ki, és a futó rendszerek javítása helyett friss rendszerképeket hoznak létre a megadott ütemezések szerint.

  • Integrált biztonsági platformok használata: Az olyan megoldások, mint az Azure Container Registry és a Microsoft Defender for Containers integrációja, automatikus vizsgálatot, karanténba helyezési munkafolyamatokat, tartalommegbízhatóságot és többrégiós replikációt biztosítanak konzisztens biztonsági szabályzatokkal.

Megvalósítási példa

Egy logisztikai szervezet olyan tárolóalkalmazást helyezett üzembe, amely a kritikus távoli kódvégrehajtási biztonsági rést tartalmazó, nem kódolt alaprendszerképet tartalmaz. A támadók röviddel az üzembe helyezés után kihasználták a biztonsági rést, ami veszélyeztette a szállítási adatokat.

Kihívás: Számos tárolólemezkép biztonsági rések vizsgálata nélkül. A hónapokkal ezelőtt létrehozott képek számos CVE-t halmoztak fel, beleértve a kritikus biztonsági réseket is. Az ellenőrzés nem akadályozta meg a rosszindulatú kép helyettesítését.

Megoldási megközelítés:

  • Tárolóregisztrációs adatbázis biztonsága:Az Azure Container Registry-t alkalmaztuk, a biztonsági rések vizsgálatával és a magas súlyosságú CVE-kkel rendelkező képek karanténba helyezésével az üzembe helyezés előtt.
  • Rögzített virtuálisgép-rendszerképek: Üzembe helyezett Azure Shared Image Gallery CIS-teljesítménytesztnek megfelelő virtuálisgép-rendszerképekkel szabályozott számítási feladatokhoz.
  • Futtatókörnyezet védelme: A Microsoft Defender for Containers konfigurálva van a folyamatos fenyegetésészleléshez és a sodródás monitorozásához.
  • Összetevők integritása: A létrehozott titkosítási aláírás és ellenőrzés biztosítja a rendszerkép hitelességét az életciklus során.

Eredmény: Megakadályozta a sebezhető lemezképek éles környezetbe történő telepítését. Képenként jelentősen csökkent a konténer CVE-k száma. Aláírás-ellenőrzéssel megakadályozta a képhelyettesítési támadásokat.

Kritikussági szint

Biztosan így van.

Vezérlőleképezés

  • NIST SP 800-53 Rev.5: CM-2, CM-3, SI-2, SI-7, RA-5
  • PCI-DSS v4: 6.2.4, 6.3.3, 11.3.1
  • CIS-vezérlők v8.1: 4.1, 7.3, 7.4
  • NIST CSF 2.0-s verzió: PR. IP-1, PR. IP-3, DE. CM-8
  • ISO 27001:2022: A.8.9, A.8.31, A.8.32
  • SOC 2: CC7.2, CC8.1

DS-7: DevOps-naplózás és -monitorozás implementálása

Biztonsági alapelv

Átfogó DevOps-tevékenységnaplózás implementálása naplózási streamelésen keresztül a központosított biztonsági információs és eseménykezelési (SIEM) platformokra való integrációval a biztonsági elemzéshez, a valós idejű fenyegetésészleléshez és az automatizált válaszhoz. Viselkedéselemzési, anomáliadetektálási és biztonsági metrikákat hozhat létre a gyors incidenskezeléshez és a megfelelőségi auditnaplók fenntartásához.

Kockázat csökkentése

Az elégtelen DevOps-naplózás és -figyelés kritikus vakfoltokat hoz létre, amelyeket a támadók kihasználnak, hogy észrevétlenül működjenek, megőrizze és kiszűrje a bizalmas kódot vagy hitelesítő adatokat. Átfogó láthatóság nélkül:

  • Észlelhetetlen csővezeték sérülések: A támadók úgy módosítják a CI/CD-folyamatokat, hogy kártékony kódot injektáljanak, titkokat szivárogtassanak ki, vagy hátsó kapukat hozzanak létre anélkül, hogy riasztásokat aktiválnak a hiányzó vagy nem megfelelő audit naplózás miatt.
  • A kódot vagy infrastruktúrát módosító insider-fenyegetések: A rosszindulatú bennfentes vagy feltört fiókok észlelés nélkül módosítják a forráskódot, az infrastruktúra-definíciókat vagy az üzembehelyezési konfigurációkat.
  • Átfogó ellenőrzési nyomvonalak hiánya: A részletes tevékenységnaplók hiánya megakadályozza a kriminalisztikai vizsgálatot, a hatásvizsgálatot és a kiváltó ok elemzését, ha biztonsági incidensek fordulnak elő– meghosszabbítva a tartózkodási időt, és növeli a biztonsági incidensek hatását.
  • Késleltetett incidenskezelés: Az átlagos észlelési idő (MTTD) óráktól hetekig terjed, amikor a biztonsági csapatok nem rendelkeznek valós idejű riasztással, anomáliadetektálással és a DevOps biztonsági eseményeinek automatikus korrelációval.
  • Megfelelőségi naplózási hibák: A szabályozási követelmények (SOX, PCI-DSS, HIPAA, ISO 27001) átfogó auditútvonalak, változáskövetés és hozzáférés-naplózás központosított DevOps-monitorozás nélkül nem teljesíthetők.
  • Jogosultságeszkalációs vakság: Az engedélyek jogosulatlan emelése, a háttérfiókok létrehozása vagy a hozzáférés-vezérlés módosítása észrevétlenül folytatódik viselkedéselemzés és jogosultságfigyelés nélkül.

A naplózási hiányosságok elrejtik a rosszindulatú folyamatmódosításokat, a jogosultságok eszkalálását és az állandó hozzáférési kísérleteket a magas jogosultsági szintű fejlesztési útvonalakon.

MITRE ATT&CK

  • Védelmi kijátszás (TA0005): rontja a védekezést (T1562), letiltja a naplózást, a biztonsági vizsgálati lépéseket vagy a monitorozási ügynököket, hogy vakfoltokban működjenek, és a mutatóeltávolítás (T1070) törölje az auditnaplókat vagy a folyamat végrehajtási előzményeit a rosszindulatú tevékenységek elrejtéséhez.
  • Adatmegőrzés (TA0003): fiókkezelés (T1098) további szolgáltatásnevek, személyes hozzáférési jogkivonatok vagy SSH-kulcsok létrehozása észlelés nélkül.
  • Gyűjtemény (TA0009): információtárakból származó adatok (T1213) forráskód, titkos kódok vagy szellemi tulajdon kinyerése folyamathozzáférés útján.
  • Hitelesítő adatokhoz való hozzáférés (TA0006): nem biztonságos hitelesítő adatok (T1552) a folyamatnaplókból vagy a végrehajtási előzményekből származó titkos kulcsok kinyerése.

DS-7.1: Auditnaplózás implementálása DevOps-platformokhoz

Az éles infrastruktúrához és a bizalmas forráskódhoz kiemelt hozzáféréssel rendelkező DevOps-platformok átfogó biztonsági monitorozást igényelnek a támadó tevékenységek és az insider fenyegetések észleléséhez. A naplózási hiányosságok lehetővé teszik a rosszindulatú szereplők számára, hogy hosszabb ideig észrevétlenül működjenek, míg a központi naplóösszesítés lehetővé teszi a szélesebb körű biztonsági telemetriával való korrelációt, amely kifinomult támadási láncokat fed fel. A valós idejű viselkedéselemzés azonosítja az izolált eseményekben láthatatlan gyanús mintákat, és a nyers naplózási adatokat végrehajtható biztonsági intelligenciává alakítja.

Átfogó DevOps-biztonsági monitorozás létrehozása az alábbi képességekkel:

  • Átfogó, biztonsággal kapcsolatos tevékenységek rögzítése: Átfogó naplózás létrehozása, amely rögzíti az összes biztonsági szempontból releváns DevOps-tevékenységet: felhasználói hitelesítési és engedélyezési eseményeket, forráskód-véglegesítéseket és fiókműveleteket, folyamatlétrehozást és -módosítást, üzembe helyezési végrehajtásokat, titkos hozzáféréseket, engedélymódosításokat, szolgáltatásnév létrehozását és rendszergazdai műveleteket. A DevOps-platformok emelt szintű hozzáférést biztosítanak az éles infrastruktúrához, és a kódnaplózási hiányosságok lehetővé teszik a támadók és rosszindulatú bennfentesek számára, hogy hosszabb ideig észrevétlenül működjenek.

  • Naplók továbbítása a központosított SIEM-be valós időben: Valós időben továbbíthatja az auditnaplókat a központosított SIEM-platformokra aHelyett, hogy a DevOps-platform natív megőrzésére (általában 90 nap) támaszkodna, lehetővé téve a hosszú távú kriminalisztikai elemzést, a megfelelőségi jelentéskészítést és a más rendszerek biztonsági eseményeivel való korrelációt. Naplók streamelése a biztonsági műveleti központokba szabványosított protokollokkal (/azure Event Hubs, syslog) strukturált formátumokban (JSON), amelyek manuális naplóvizsgálat nélkül teszik lehetővé az automatikus elemzést, elemzést és riasztást.

  • Viselkedéselemzés és anomáliadetektálás üzembe helyezése: Viselkedéselemzés és anomáliadetektálás implementálása a DevOps-naplózási adatokon az egyes eseményekben láthatatlan gyanús minták azonosításához: az órák utáni folyamatmódosítások, a bizalmas adattárakhoz való szokatlan hozzáférés, a gyors jogosultság-eszkalációk, a szolgáltatásnév létrehozása, majd a gyanús üzembe helyezések, a váratlan helyekről érkező folyamatvégrehajtások vagy a titkos hozzáférés rendellenes mintái. Alapszintű viselkedési profilokat hozhat létre a felhasználók és szolgáltatások számára, és olyan statisztikailag jelentős eltéréseket jelezhet, amelyek veszélyeztetést vagy belső fenyegetéseket jelezhetnek.

  • Automatikus riasztás konfigurálása magas kockázatú tevékenységekhez: A magas kockázatú tevékenységek automatikus riasztásának konfigurálása a biztonsági csapatok azonnali értesítésével: éles üzembe helyezési hibák, folyamatmódosítások a védett ágakban, új szolgáltatásnév létrehozása, engedélyszint-emelési események, letiltott biztonsági ellenőrzési lépések, naplótovábbítási konfigurációmódosítások vagy jogosulatlan folyamatok titkos kulcsainak elérésére tett kísérletek. Súlyossági alapú eszkaláció implementálása, amely biztosítja, hogy a kritikus riasztások azonnal elérjék a biztonsági műveleteket, miközben a rutineseményeket a rendszer elemzésre köti.

  • Integráció szélesebb körű biztonsági telemetriával: A DevOps-naplók integrálása szélesebb körű biztonsági telemetriával A SIEM-platformokon a végpontészlelés, a hálózati biztonság, az identitásesemények és a fenyegetésfelderítési hírcsatornák közötti korreláció érdekében. Ez lehetővé teszi az olyan kifinomult támadási láncok észlelését, amelyek esetében a DevOps biztonsága a többfázisú műveletek egyik szakasza, például az adathalász hitelesítő adatok összekapcsolása a későbbi folyamatmódosításokkal és a szokatlan felhőbeli erőforrás-kiépítéssel.

  • Integrált SIEM-platformok használata: Az Olyan platformok, mint az Azure DevOps Audit Streaming és a Microsoft Sentinel integrációja valós idejű naplótovábbítást, előre összeállított észlelési szabályokat biztosítanak a DevOps-fenyegetésekhez, biztonsági munkafüzeteket a vizsgálathoz és az automatikus válasz-vezénylést.

Megvalósítási példa

Egy gyártó vállalat belső fenyegetést észlelt, amikor a korábbi alvállalkozó módosította a CI/CD-pipeline-t, és ezzel backdoor kódot injektált az éles alkalmazásba. Az incidens hónapokig észrevétlen maradt a nem megfelelő naplózás miatt.

Kihívás: A DevOps-tevékenységek központi naplózása nem. A folyamatmódosítások és a jogosultsági hozzáférés módosítása nem lett figyelve. A törvényszéki nyomozást akadályozta a vizsgálati nyomok hiánya. Nem sikerült a megfelelőségi naplózás a nem megfelelő változáskövetés miatt.

Megoldási megközelítés:

  • Központosított naplózás: Engedélyezve van az Azure DevOps naplózási streamelési eseményeinek továbbítása a Microsoft Sentinelnek biztonsági elemzés és hosszú távú megőrzés céljából.
  • Viselkedéselemzés: Az anomáliadetektálás a szokatlan hozzáférési mintákat, az órák utáni folyamatmódosításokat és a bennfentes fenyegetéseket jelző jogosultság-eszkalációkat azonosítja.
  • Automatikus riasztás: Konfigurált riasztások gyanús tevékenységekhez, beleértve a jogosulatlan termelési telepítéseket és a szolgáltatásfő létrehozásának útválasztását a biztonsági műveletekhez.
  • Megfelelőségi jelentés: A szabályozási követelményeknek megfelelő automatizált naplózási napló létrehozása átfogó változáskövetéssel.

Eredmény: Gyorsan észlelte és megakadályozta az ezt követő jogosulatlan folyamatmódosításokat. Jelentősen csökkentette az incidensvizsgálati időt átfogó ellenőrzési nyomokkal. A dokumentált változáskezelésnek való megfelelés elérése.

Kritikussági szint

Kellett volna.

Vezérlőleképezés

  • NIST SP 800-53 Rev.5: AU-2, AU-3, AU-6, AU-12, SI-4
  • PCI-DSS v4: 10.2.1, 10.2.2, 10.3.4
  • CIS-vezérlők v8.1: 8.2, 8.5, 8.11
  • NIST CSF 2.0-s verzió: DE. CM-1, DE. CM-7, RS. AN-1
  • ISO 27001:2022: A.8.15, A.8.16
  • SOC 2: CC7.2, CC7.3
  • Last updated on