Megosztás a következőn keresztül:

DevSecOps-vezérlők

  • Cikk

Ez a cikk bemutatja, hogyan alkalmazhat biztonsági vezérlőket a folyamatos SDL biztonsági eljárások támogatására. Ezek a biztonsági vezérlők a DevSecOps-stratégia szerves részét képezik, amely emberekre, folyamatokra és technológiákra terjed ki. Ez a dokumentáció ismerteti az egyes vezérlőket, és bemutatja, hogyan alkalmazhatja ezeket a vezérlőket három biztonsági profilra. Ezek a profilok a legtöbb szervezetnél megfelelnek a gyakori üzleti forgatókönyvek tipikus biztonsági követelményeinek:

A biztonsági vezérlők és az idő és a hatás diagramja.

Biztonsági vezérlőprofilok

Ebben a cikkben háromféle szabályozási profilra hivatkozunk.

Ideiglenes minimum – Rövidített biztonsági profil egy ideiglenes kivételállapothoz az alacsony kockázatú számítási feladatok gyors prototípus-készítéséhez. Ezt a profilt csak olyan ideiglenes kivételekhez szabad használni, amelyeket gyorsított idővonalon kell kiadni a kritikus üzleti igények kielégítése érdekében. A profilt használó elemeket gyorsan fel kell venni a standard profilba.

Standard – Kiegyensúlyozott megközelítés a legtöbb számítási feladathoz, az idő nagy részében.

Magas biztonság – Szigorú biztonság olyan számítási feladatokhoz, amely potenciálisan nagy hatással van az üzleti és az emberi biztonságra.

DevSecOps biztonsági vezérlők

Ez a szakasz az egyes számítási feladatokhoz ajánlott biztonsági vezérlőkre hivatkozik. Ez a hivatkozás a jelenlegi módon is alkalmazható, vagy a meglévő szoftverfejlesztési és szoftverbiztonsági folyamatokhoz igazítható. A legtöbb szervezet nem tudja azonnal implementálni ezeket a vezérlőket, ha még nem végeznek ilyen vezérlőket. A folyamatos fejlesztési megközelítés használata gyakran a legjobb módszer: a vezérlők rangsorolása, az első vezérlő implementálása, a következő vezérlőre való áttérés, implementálás stb. A legtöbb szervezetnek először a kritikus alapokat kell rangsorolnia .

További információ: The DevSecOps journey.

Ez a diagram összefoglalja a biztonsági vezérlőket, és azt, hogyan alkalmazhatja őket az egyes számítási feladatok biztonsági profiljára.

A legfontosabb tervezési szempontok a következők:

  • Shift balra... de dupla ellenőrzés - Ez a hivatkozás arra szolgál, hogy a lehető leghamarabb észlelje és javítsa ki a problémákat, hogy könnyebben és olcsóbban oldhassa meg a problémákat (más néven balra váltott műszak), de a hiba feltételezésére is szolgál, és a folyamat későbbi részében is ellenőrizze őket. Mindig ellenőrizze duplán a CI/CD folyamat biztonsági vezérlőinek állapotát, és győződjön meg arról, hogy az elkerülhető problémák nem csúsznak át az éles rendszereken. Ez a koncepció a "mélységi védelem" és a "fail safe" elveket követi.
  • Mesterséges intelligencia (AI) – A mesterséges intelligencia két fő hatása:
    • Az összes kód védelme, függetlenül attól, hogy emberi vagy generatív AI írta-e
    • Mindkettő használata a biztonság érdekében – A klasszikus és az AI-vezérlők rendelkezésre állásának alkalmazása a biztonsági problémák láthatóságának és kontextusának növelése érdekében (például kódelemzési eszközök)

Biztonsági vezérlők

A vezérlők a fejlesztés szakaszaiba vannak csoportosítva, valamint az összes fejlesztési fázisra és vezérlőprofilra vonatkozó közös vezérlőkre (kritikus alapokra):

Mindegyik elem a következő szakaszokban van definiálva:

Kritikus alapok létrehozása

Ez a vezérlő támogatja az 1. folyamatos SDL-gyakorlatot – Biztonsági szabványok, metrikák és szabályozás létrehozása, 2. gyakorlat – A bevált biztonsági funkciók, nyelvek és keretrendszerek használatának megkövetelése, valamint a 10. gyakorlat – Biztonsági képzés biztosítása.

Standard – Ezek a vezérlők minden fejlesztési fázisra és vezérlőprofilra érvényesek.

Biztonsági képzés biztosítása

Ez a vezérlő arra összpontosít, hogy a fejlesztők és a biztonsági csapatok képzést nyújtsanak a biztonsági problémák felismeréséhez és megoldásához a fejlesztési életcikluson keresztül. Biztonsági betanítás nélkül a csapatok kihagyhatják azokat az alapvető biztonsági hiányosságokat, amelyek az alkalmazások élettartama során veszélybe kerülhetnek.

Ennek eredményeképpen elengedhetetlen, hogy minden szerepkörben (beleértve a felhasználókat, fejlesztőket, termékvonal-kezelőket, tesztelőket stb.) biztonsági képzést alkalmazzon. Minden szerepkörnek rendelkeznie kell a biztonsági kockázatokra vonatkozó oktatással és az alkalmazások biztonságának megőrzésében betöltött szerepükkel. Ez a képzés a következő formát öltheti: formális vagy igény szerinti képzés, szimulációs gyakorlatok, fenyegetésmodellezés, mentorálás/tanácsadók, biztonsági bajnokok, alkalmazásbiztonsági támogatási csapatok, lila csapattevékenységek, podcastok, videók vagy bármilyen más tanulási módszer.

Végső soron minden szerepkörnek meg kell értenie:

  • Miért fontos a biztonsági kockázatok kezelése?
  • Mit kell tenniük a szerepkörük biztonságáért?
  • Hogyan lehet a biztonságot a mindennapi szerepkörük részévé tenni

Kapcsolatok, akik megértik a támadó perspektíváját, céljait, és hogy ez hogyan jelenik meg a valós biztonsági incidensekben, gyorsan biztonsági szövetségesekké válnak ahelyett, hogy megpróbálják elkerülni a biztonságot.

A biztonság egy soha véget nem érő játék, ahol a fenyegetések, a technológia és az üzleti eszközök védelme mindig változik, és a fenyegetések szereplői soha nem adják fel. A biztonsági betanítási megközelítésnek folyamatosnak és folyamatosan fejlődnie kell. A hatékony képzés összhangban van a biztonsági szabályzatokkal, a szoftverfejlesztési életciklussal (SDL) kapcsolatos gyakorlatokkal, szabványokkal és szoftverbiztonsági követelményekkel. A képzési anyagoknak az adatokból és az újonnan elérhető technikai képességekből származó megállapításokból kell származnia.

Bár a biztonság mindenki feladata, fontos megjegyezni, hogy nem mindenkinek kell biztonsági szakértőnek lennie, és nem kell feltétlenül szaktudást szereznie behatolástesztelésből. Alapvető fontosságú annak biztosítása, hogy mindenki megértse a biztonsági alapokat, és hogy hogyan alkalmazza őket a biztonság szoftverbe és szolgáltatásokba történő kiépítésében betöltött szerepére. Ennek a képzésnek tartalmaznia kell a munkaállomások, alkalmazások, identitások és fiókok biztonságos használatát.

A fejlesztők és a rendszereket építő mérnökök általában nem biztonsági szakértők. A fenyegetésmodellezés technikai és fogalmi aspektusait egyaránt be kell tanítani ahhoz, hogy hatékonyak legyenek, hogy a tervezés által biztonságos rendszereket építhessenek ki. Ez a képzés elengedhetetlen ahhoz, hogy a fenyegetésmodellezési folyamat nagy léptékben működjön olyan szervezetekben, ahol a fejlesztők sokkal nagyobb számban használják a biztonsági szakembereket. A fenyegetésmodellezést alapvető mérnöki képességnek kell tekinteni, amelyben minden fejlesztőnek és mérnöknek legalább alapszintű jártasságúnak kell lennie. Ezért a fejlesztési és mérnöki csapatokat be kell tanítani arra, hogy az előkészítés részeként és rendszeres frissítőkkel rendelkezzenek a fenyegetésmodellezés terén.

A biztonság belefoglalása a hibás postmortemsbe

A hibáztatatlan halál utáni elemzés kritikus fontosságú módszer a csapatok számára, hogy hatékonyan és hatékonyan tanuljanak a hibákból anélkül, hogy a csapattagok védekezőképességet váltanak ki azáltal, hogy valakit hibáztatnak. A biztonsági tanulásokat explicit módon bele kell foglalni a hibás postmortem folyamatba, hogy a csapatok a biztonsági tanulást is maximalizálják.

Biztonsági szabványok, metrikák és szabályozás létrehozása

A szervezeteknek létre kell hozniuk ezeket a biztonsági szabványokat, metrikákat és szabályozást, mivel ezek támogatják az innováció képességét. Olyan erős biztonsági programot tesz lehetővé, amely nemcsak a szervezet eszközeit védi, hanem igazodik az üzleti célkitűzéseihez is. A biztonsági szabványok a szervezet rendszereinek, adatainak és folyamatainak biztonságának megőrzésére vonatkozó alapvető követelmények és ajánlott eljárások.

Ezeket a szabványokat mérni és szabályozni kell, beleértve a megfelelőség monitorozását, valamint az aktuális fenyegetések, eszközök és egyéb tényezők rendszeres felülvizsgálatát és frissítését. Ennek a folyamatnak a kezdeti ideációtól kezdve az alkalmazás leszerelésén és az azt támogató fejlesztési környezeteken át a teljes életciklusra ki kell terjednie.

A metrikák a biztonsági vezérlők és folyamatok hatékonyságának mérésére szolgálnak. Az egyik legfontosabb metrika az átlagos szervizelési idő (MTTR) az alkalmazás sebezhetőségének nyomon követéséhez. Ez a mérés lehetővé teszi a biztonsági javítások kiadásába való stratégiai befektetést.

Feljegyzés

Ez a fogalom eltér az MTTR-től a szervezet eszközeihez való támadó hozzáférés eltávolítására összpontosító biztonsági műveletekben.

A biztonsági szabályozás a biztonsági csapatok vezérelve, és gyakran olyan keretrendszerekre és folyamatokra épül, amelyeket a szervezetek az információbiztonságuk kezelésére és szabályozására használnak. Ilyenek például a szabályzatok, az eljárások, a vezérlők és a kockázatkezelés. A metrikák segítenek számszerűsíteni a kockázatnak való kitettséget. Nélkülük előfordulhat, hogy a szervezet nem teljesen érti a biztonsági réseket és a lehetséges hatásokat.

Mivel a biztonsági követelmények újak lehetnek, lehetősége van olyan progresszív megközelítést alkalmazni, amely fokozatosan építi fel a kódolási szabványokat az ideális állapotra. Ez a megközelítés időt ad a csapatoknak a figyelés és a vezérlők megismerésére és automatizálására.

A bevált biztonsági funkciók, nyelvek és keretrendszerek használatának megkövetelése

A jóváhagyott eszközök és a hozzájuk kapcsolódó biztonsági ellenőrzések listájának meghatározása és közzététele. A jól bevált és bevált biztonsági megoldások használata fontos a gyakori hibák elkerülése érdekében, mivel a biztonságos megoldások létrehozása nagyon nagy kihívást jelent. A biztonsági megoldások újbóli feltalálásának megkísérlése szinte mindig nagyobb biztonsági kockázatot, valamint időt és energiát pazarol.

Győződjön meg arról, hogy a fejlesztők és a mérnökök kihasználják az új biztonsági elemzési funkciókat és védelmet. A biztonságos végrehajtható elemek létrehozásához mindig a legújabb fordítót, linkert, kódtárakat, valamint a megfelelő fordító- és linkerjelölőket kell használniuk.

A szervezeteknek felülvizsgálati és jóváhagyási folyamatot kell végrehajtaniuk az integrált összetevők biztonságának ellenőrzése érdekében. Létre kell hozniuk egy szabályzatot, amely csak jóváhagyott összetevőket használ a kényszerített és monitorozott folyamatok létrehozásában és üzembe helyezésében.

Alapszintű identitásbiztonság

Győződjön meg arról, hogy az identitás használata és integrációja jól bevált ajánlott biztonsági eljárásokat követ. A fenyegetést figyelő szereplők gyakran használnak identitástámadási technikákat mind az éles rendszerek, mind a fejlesztési folyamatok ellen. Egy népszerű mondás rögzíti ezt: "a támadók nem törnek be, csak bejelentkeznek."

Az identitásbiztonság két formában használható a fejlesztéshez:

  • Identitásbiztonság a fejlesztési folyamathoz – Győződjön meg arról, hogy a fejlesztési folyamat minden résztvevője erős hitelesítési módszereket használ a napi munkájához, és csak a feladatfeladatok végrehajtásához szükséges jogosultságokkal rendelkezik. További információ: Identitás-/alkalmazáshozzáférési vezérlők.
  • Identity Security rendszerekhez és alkalmazásokhoz – Győződjön meg arról, hogy az általuk megtervezett és létrehozott rendszerek a hitelesítési és engedélyezési módszerek ajánlott eljárásait követik (és nem építik ki saját gyenge utánzataikat a bevált és karbantartott identitásrendszerekből).

Identitásbiztonság alkalmazása rendszerekre és alkalmazásokra az alábbi erőforrások útmutatását követve:

Titkosítási szabványok

Alkalmazzon hang titkosítási eljárásokat a titkosítás minden használatára. Kövesse a 4. folyamatos SDL-gyakorlat – Titkosítási szabványok definiálása és használata című cikkben leírt irányelveket.

További információ: Microsoft SDL titkosítási javaslatok.

A fejlesztési környezet védelme

Ez a vezérlő támogatja a 6. folyamatos SDL-gyakorlatot – a mérnöki környezet biztonságossá tételét.

Ez a vezérlő a fejlesztési környezet biztonságos munkaállomások és integrált fejlesztési környezetek (IDE-k) használatával történő védelmére összpontosít. Ez a vezérlő kiemeli a Teljes felügyelet megközelítés használatának előnyeit a szoftverfejlesztési életciklusban.

A jelenlegi környezetben a támadók kibővítik a műveleteket, hogy megcélzhassák a fejlesztők gépeit, és illetéktelenül módosíthassák a buildelési folyamatokat. Erre a támadásra a SolarWinds által tapasztalt egyik kulcsfontosságú példa volt, amelyben a támadó egy rosszindulatú DLL-t szúrt be a szoftver buildjének utolsó fázisai előtt. Ez gyakorlatilag háttérbe kapcsolta az alkalmazást, és célzott támadást eredményezett, amelyet világszerte több ezer ügyfélnek osztottak el az ellátási láncon keresztül. A SolarWinds-támadással kapcsolatos további információkért lásd a Microsoft Blog A Solorigate elemzése című cikket, a feltört DLL-fájlt, amely kifinomult kibertámadást indított, és hogy a Microsoft Defender hogyan segíti az ügyfelek védelmét.

Elengedhetetlen a munkaállomások, a környezetek, az identitások és más fejlesztési rendszerek megerősítése a fejlett alkalmazások integritásának biztosítása érdekében. Ennek elmulasztása utat teremt a támadók számára, hogy a forráskódkezelő (SCM) rendszeren vagy a fejlesztői munkaállomáson keresztül veszélyeztessék az alkalmazást.

Ez a gyakorlat a fejlesztési életciklus kritikus alapja, és minden profilban létre kell hozni.

Ebben a gyakorlatban Teljes felügyelet megközelítést kell alkalmaznia. A Teljes felügyelet modell alapvető követelménye, hogy minden hozzáférési kérelem (felhasználó, szolgáltatás vagy eszköz) úgy legyen ellenőrizve, mintha nem megbízható hálózatból származik, függetlenül attól, hogy honnan származik a kérés, vagy milyen erőforráshoz fér hozzá. Ezt a "mindig hitelesíteni és engedélyezni" szabályzatot az összes elérhető adatpontra alapozhatja. A just-in-time és a Just-Enough-Access (JIT/JEA) szabályzatokkal korlátoznia kell a felhasználói hozzáférést, különösen a kiemelt felhasználókat, és a szegmenshozzáférést úgy kell korlátoznia, hogy a lehető legkisebb legyen a sérülés, ha incidens történik.

A fejlesztési környezet megkeményedése különböző módszerekkel érhető el, de jó kiindulópont a fejlesztői munkaállomás figyelembe ása. Az olyan technológiák használatával, mint a GitHub Codespaces vagy a Microsoft DevBox, a fejlesztési környezetet SaaS-alkalmazásokra helyezheti át, amelyek ezután biztonsági és hálózati beállítások vagy szervezeti szabályzatok segítségével kezelhetők.

A fejlesztői munkaállomások további zárolásához emelt szintű hozzáférési munkaállomásokat/biztonságos hozzáférési munkaállomásokat (PAW/SAW) is kibocsáthat. Ezek a munkaállomások segítenek a fenyegetésvektorok csökkentésében, valamint a szabványosított és szabályozott fejlesztői eszközök biztosításában.

Biztonságos kialakítás

Fenyegetésmodellezés végrehajtása (biztonsági tervezés áttekintése)

Ez a vezérlő támogatja a 3. folyamatos SDL-gyakorlatot – Fenyegetésmodellezés végrehajtása.

Ez a vezérlő azonosítja a kialakítás biztonsági gyengeségeit, amelyek biztonsági incidenseket és üzleti károkat okozhatnak. A kialakítás biztonsági gyengeségeit nehéz lehet enyhíteni a kialakítás implementálása után, ezért ezeknek a hiányosságoknak az életciklus korai szakaszában történő megtalálása és javítása kritikus fontosságú.

A fenyegetésmodellezés a biztonsági tervezés felülvizsgálati folyamata, amely integrálja a biztonságot egy rendszer vagy alkalmazás kialakításába.

A fenyegetésmodellezés szisztematikusan azonosítja, értékeli, rangsorolja és mérsékli a szoftverrendszeren belüli biztonsági kockázatokat. A szoftveralkalmazások tervezésének és architektúrájának elemzésére alkalmazott strukturált megközelítés a fejlesztési folyamat korai szakaszában azonosítja a potenciális fenyegetéseket és biztonsági réseket.

A végső cél az, hogy megértsék a rendszert, és mi lehet baj. A fenyegetésmodellezés azáltal segít elérni ezt a célt, hogy alapos ismereteket nyújt mind a rendszerről, mind a potenciális támadók nézetéről.

Ez a folyamat általában fenyegetésészlelési műhelyek formájában zajlik, ahol a rendszer és a biztonsági szakértők egy csoportja közösen dolgozik a kockázatok felderítésén és dokumentálásán. Bár ez a folyamat informálisan indulhat el, gyorsan strukturált folyamattá kell alakulnia, amely ismerteti a szolgáltatás felépítésének minden aspektusát, a használat módját és a rendszerillesztőket.

A fenyegetésmodellezés fázisai a következők:

  1. Használati esetek, forgatókönyvek és eszközök azonosítása – Első lépésként ismerje meg, hogy a rendszer milyen üzleti funkciókat és használati eseteket tesz lehetővé a rendszer esetleges üzleti hatásainak felméréséhez, és tájékoztassa a követendő megbeszéléseket.
  2. Architekturális áttekintés létrehozása – Hozzon létre egy vizuális összefoglalást az alkalmazásról (vagy használjon egy meglévőt), hogy egyértelmű képet adjon a rendszerről és annak működéséről. Ennek az áttekintésnek tartalmaznia kell az üzleti folyamattérképet, az összetevőket és az alrendszereket, a megbízhatósági határokat, a hitelesítési és engedélyezési mechanizmusokat, a külső és belső interfészeket, valamint a szereplők és összetevők közötti adatfolyamokat.
  3. A fenyegetések azonosítása – A potenciális biztonsági fenyegetések, például a STRIDE-modell vagy az OWASP fenyegetésmodellezésének számbavételéhez használjon közös módszertant.
  4. Kockázatcsökkentések azonosítása és nyomon követése – A felderített tervezési hibák monitorozása és nyomon követése meglévő fejlesztési folyamatokkal és eszközökkel a javítások implementálásának és dokumentálásának biztosítása érdekében. Ennek a folyamatnak tartalmaznia kell, rangsorolja, hogy mely kockázatcsökkentéseket érdemes először elvégezni, hogy a csapatok először a legfontosabb erőfeszítésekre fordíthassák az idejüket. Ez a folyamat kockázatalapú, és előfordulhat, hogy nem rendelkezik erőforrásokkal az első ciklus összes kockázatának teljes mérsékléséhez. Gondosan gondolja át, hogy mely kockázatcsökkentések, beleértve a részleges kockázatcsökkentéseket, a támadók költségeit a legkevésbé védekező költségek és erőforrások esetében növelik. A biztonság célja a támadók meghibásodása, amely a támadási technika teljes blokkolásának formájában jelenhet meg, észleli őket, hogy lehetővé tegye a védők válaszát, lelassítsa őket, hogy időt adjon a védőknek a válaszadásra, korlátozza a sérülések hatókörét és így tovább.

A fenyegetésmodellek gyakran oktatási folyamatként szolgálnak az összes érintett számára, valamint fontos kontextust biztosítanak az egyéb biztonsági tervezéshez, megvalósításhoz és teszteléshez.

A mesterségesintelligencia-összetevőket tartalmazó alkalmazásoknak ki kell értékelnie az AI-hez társított konkrét kockázati típusokat, amelyek eltérnek a klasszikus alkalmazásoktól.

Fenyegetésmodellek létrehozása és elemzése a következőkkel: kommunikáció a rendszerük biztonsági kialakításáról, a lehetséges biztonsági problémákra vonatkozó tervek elemzése egy bevált módszer használatával, valamint a biztonsági problémák megoldásának javaslata és kezelése.

Biztonságos kód

Kódelemzés

Ez a vezérlő támogatja a 7. folyamatos SDL-gyakorlatot – Biztonsági tesztelés végrehajtása.

Ez a vezérlő a kód biztonságának növelésére összpontosít, miközben a fejlesztők egy integrált fejlesztői környezetbe (IDE) vagy a kód beadása során írnak/írnak be. Ez a vezérlő a DevSecOps-gyakorlatok sarokköve, mivel közvetlenül kezeli a támadók által rendszeresen kihasznált biztonsági réseket.

A vezérlő nélkül előfordulhat, hogy hiányoznak a fejlesztők által közvetlenül az alkalmazásba kódolt biztonsági rések. A fejlesztők nem rosszindulatúak, de előfordulhat, hogy nem rendelkeznek a kódolt kód nem biztonságos azonosításához szükséges szakértelemmel.

Ez a szabályozás kulcsfontosságú ahhoz, hogy az eszközök közvetlenül az IDE-be integrálva kihasználják a balra tolódásos megközelítés hatékonyságát és biztonsági előnyeit. Ez a folyamat lehetővé teszi a biztonsági rések gyors felderítését és elhárítását a lehető leghamarabb és legköltségesebben. Ez a folyamat visszamenőlegesen alkalmazható a már kifejlesztett alkalmazásokra a biztonsági hiányosságok azonosításával és későbbi javításával (bár nagyobb költséggel és nehézségekkel).

Ez a folyamat általában IDE beépülő modulok vagy dedikált ellenőrző eszközök formájában történik, amelyek statikus elemzési biztonsági teszteléssel (SAST) és dinamikus elemzési biztonsági tesztelési (DAST) eszközkészletekkel ellenőrzik a kódot.

A SAST-eszközök átvizsgálják a meglévő kódbázist, és teljes hozzáféréssel rendelkeznek a kódhoz. A SAST-eszközök képesek azonosítani a kód alapvető gyengeségeit. A DAST végrehajtása viszont az üzembe helyezett alkalmazáson történik. Ennek eredményeképpen nem fér hozzá a kódhoz, és a futtatás során a biztonsági hiányosságok szimulálására és azonosítására kerül végrehajtásra.

Feljegyzés

Az AI-alkalmazások különböző típusú biztonsági résekkel (például torzításokkal és hallucinációkkal) rendelkeznek, mint a klasszikus alkalmazások, és olyan eszközöket igényelnek, amelyek ezekre összpontosítanak.

A minőség-ellenőrzés számít! Az eszközök futtatásának egyik legfontosabb szempontja annak biztosítása, hogy finomhangoljuk őket, hogy csökkentsük a zajt és az elpazarolt erőfeszítéseket a hamis pozitív értékektől. Ezeknek az eszközöknek a finomhangolásához általában olyan fejlesztői háttérrel rendelkező biztonsági szakemberre van szükség, aki ismeri a szervezet fejlesztési folyamatait. Ugyanezek a szakemberek a fejlesztők egyéni észleléseihez is nyújthatnak osztályozási útmutatást és szakértelmet. Segítenek megkülönböztetni az igaz és hamis pozitív értékeket, a valós problémákat és a hamis riasztásokat. A fejlesztők ezen szakértőkhöz való hozzáférésének folyamatai gyakran szorosan kapcsolódnak a biztonsági képzés biztosításához, például bajnoki programokon, alkalmazásbiztonsági támogatási csapatokon keresztül stb.

Ideiglenes minimum – Győződjön meg arról, hogy engedélyezi a beépített IDE biztonsági funkciókat, és minimális szintű SAST-vizsgálatot implementál az adattárban az alkalmazás biztonsági réseinek azonosítása érdekében. Dokumentált folyamatnak kell lennie a felderített problémák ésszerű időn belüli elhárításához, bár a hibák kijavításának "hibasáv" szabványa korlátozott, amíg az alkalmazás el nem éri a szabványos kiegyensúlyozott vagy magas biztonsági profilokat.

Standard – Győződjön meg arról, hogy az összes összetevőt teljes mértékben megvizsgálja az összes alkalmazható SAST/DAST-eszközzel, és azonosítja a hiányosságokat. Győződjön meg arról, hogy az alkalmazáskód teljes körű biztonsági lefedettséget biztosít. Győződjön meg arról, hogy követi a dokumentált szervizelési folyamatot, és rendelkezik a szervezet kockázattűrésének megfelelő "hibasáv" szabványsal.

Magas biztonság – Győződjön meg arról, hogy az összes alkalmazható alkalmazás részletes és dokumentált folyamatot kényszerít ki az összes biztonsági rés kezelésére. Javítások kikényszerítése a buildelési vagy kiadási tevékenységek előtt. Győződjön meg arról, hogy követi a dokumentált szervizelési folyamatot, és rendelkezik egy szigorúan korlátozó "hibasávtal", amely megfelel a szervezet kockázattűrésének a magas biztonságú, üzleti szempontból kritikus számítási feladatok esetében.

A statikus elemzéshez számos eszköz használható. További információkért tekintse át a Microsoft biztonsági fejlesztési életciklusának listáját.

A CI/CD-folyamat védelme

Ellátási lánc / függőségkezelés

Ez a vezérlő támogatja az 5. folyamatos SDL-gyakorlatot – a szoftverellátási lánc biztonságossá tételét.

Ez a vezérlő a fejlesztési ellátási lánc védelmére összpontosít a szoftverösszetétel-elemzési (SCA) eszközök és keretrendszerek, például a biztonságos ellátásilánc-használati keretrendszer (S2C2F) használatával. Ezek a folyamatok segítenek csökkenteni a nem Microsoft-kód által jelentett kockázatokat.

A mai környezetben a legtöbb alkalmazás nyílt forráskód szoftverre (OSS) támaszkodik, és az összetevők felhasználóinak felügyelete vagy ellenőrzése kevés. Ez a vezérlő az operációs rendszer biztonságos betöltésére, felhasználására, használatára és karbantartására vonatkozó alapvető stratégiákat, technikákat és technológiákat emeli ki. Emellett hangsúlyozza a belső függőségek védelmét, biztosítva a teljes teljes életciklust, függetlenül attól, hogy ki kódolta a szoftvert.

A szoftverellátási lánc szabályozásának elmulasztása jelentős, ön által nem felügyelt kód által bevezetett biztonsági réseket tesz elérhetővé. Egy hírhedt példa a log4J/Log4Shell biztonsági rés, amely lehetővé tette a távoli kódfuttatást bármely rendszerben vagy alkalmazásban a csomag használatával. Ezek a biztonsági rések véletlenül vagy rosszindulatúan merülhetnek fel.

Az ellátási lánc biztonságossá tételének alapvető része a biztonságos fejlesztési életciklus biztosítása, és minden profilállapotnál figyelembe kell venni, bár minden egyes állapotnak ugyanazt a szabványosított folyamatot kell követnie a függőségek betöltéséhez.

Ideiglenes minimum – Leltározza az összes függőségét, hogy megértse, milyen hatással van egy OSS biztonsági rés az alkalmazásra. Ez a leltár a Dependabot vagy más szoftverösszetétel-elemzési (SCA) eszközökkel érhető el. Ezek az eszközök segíthetnek a szoftveres anyagjegyzék (SBOM) létrehozásában is.

Standard – Elemezze az operációsrendszer-biztonsági réseket, és automatikusan javítsa ki őket automatikus lekéréses kérelmekkel. Ez a vezérlő a Dependabot és a GitHub Dependency graph/review használatával is elérhető.

Magas biztonság – Aktívan blokkolja az összes nem biztonságos csomagot, és kihasználható biztonsági réseket használ az alkalmazásban.

Ha többet szeretne megtudni erről a szabályozásról és az OSS biztonsági fejlettségének méréséről, tekintse át az OSS ellátásilánc-keretrendszerét és a GitHub ajánlott eljárásokkal kapcsolatos dokumentációját a fejlesztési életciklus biztonságossá tételéről.

Biztonsági kód áttekintése

Ez a vezérlő egy biztonsági szakértői felülvizsgálati kódra összpontosít a lehetséges biztonsági hibák azonosításához. Ez segít megtalálni azokat a biztonsági problémákat, amelyek esetében nehéz automatizálni az észleléseket.

Ezt a felülvizsgálatot végezheti el: egy ugyanazon a csapaton belüli, alkalmazásbiztonsági szakértelemmel rendelkező társ, a szervezeten belüli biztonsági bajnok, a központi alkalmazásbiztonsági csapat alkalmazásbiztonsági szakértője vagy egy külső fél.

Ennek a felülvizsgálatnak mindig külön személynek kell lennie attól a fejlesztőtől, aki a kódot írta. Ezt a felülvizsgálatot külön tevékenységként kell elvégezni az automatizált kódelemzés befejezése után.

Ideiglenes minimum – Ez a vezérlő ajánlott ehhez a profilhoz.

Standard – Ez a vezérlő ajánlott ehhez a profilhoz.

Magas biztonság – Ez a vezérlő minden magas biztonsági alkalmazáshoz szükséges, és gyakran több szakértőt is bevon.

Hitelesítő adatok és titkos kódok vizsgálata

Ez a vezérlő támogatja a 7. folyamatos SDL-gyakorlatot – Biztonsági tesztelés végrehajtása.

Ez a vezérlő a hitelesítési kulcsok és a kódban közzétett egyéb titkos kódok kockázatának csökkentésére összpontosít. A veszélyforrás-szereplők szakértelemmel és automatizálással rendelkeznek a kódba ágyazott titkos kódok megkereséséhez és kihasználásához.

A legjobb módszer a felügyelt identitások és a modern hitelesítési protokollok használata kulcsok és titkos kódok helyett, ha lehetséges. Bár az API-kulcsok és titkos kódok használata hagyományosan kódolási és tesztelési gyakorlat, az előnyben részesített módszernek mindig identitásalapú hitelesítésnek kell lennie az erőforrásokhoz a fokozott biztonsági és életciklus-kezelési képességek miatt. Ennek a vezérlőnek a megvalósítása felügyelt identitások, például az Azure-erőforrások felügyelt identitásainak használata.

Ha titkos kulcsok használatára van szükség, azokat a teljes életciklusukon keresztül kell biztosítani, beleértve azok létrehozását, használatát, rendszeres rotálását és visszavonását. Kerülje a titkos kódok közvetlen használatát a kódban, és csak biztonságos kulcs-/titkos tárolórendszerben, például az Azure Key Vaultban vagy a hardveres biztonsági modulban (HSM) tárolja őket, ha szükséges. Semmilyen körülmények között sem szabad egyszerű szöveges kulcsokat és titkos kulcsokat kódban tárolni, még ideiglenesen sem! A támadók megtalálják és kihasználják ezeket a titkos kulcsokat.

Fontos

A belső forráskódtárak nem biztonságosak!

A belső adattárakra ugyanazokra a követelményekre kell vonatkoznia, mint a nyilvánosan elérhető adattárakra, mint a veszélyforrás-szereplőknek, amelyek gyakran keresnek titkos kulcsokat és kulcsokat az adattárakban, miután adathalászattal vagy más módon férnek hozzá a környezethez. Ez egy olyan Teljes felügyelet megközelítéshez szükséges, amely feltételezi a behatolást, és ennek megfelelően tervez biztonsági vezérlőket.

Standard - A jó titkos higiénia elengedhetetlen, és minden profilban szükséges.

Feljegyzés

Mivel ezeket a titkos kulcsokat a csapatok vagy a támadók megtalálják, meg kell győződnie arról, hogy a kulcs nem használható erőforrások elérésére (erőforrástípusonként eltérő) a mechanizmus biztonságosabb hozzáférési módszerre, például felügyelt identitásokra való módosítása mellett.

További részletek és források:

Feljegyzés

Határozottan javasoljuk, hogy számítási feladatonkénti kulcsokat használjunk titkos tárolási megoldásokkal, például az Azure Key Vaulttal.

Biztonságos folyamat

Ez a vezérlő támogatja az 5. folyamatos SDL-gyakorlatot – a szoftverellátási lánc biztonságossá tételét.

Ez a vezérlő a DevOps-folyamat és az alkalmazás buildelési folyamatai során létrehozott összes összetevő védelmére összpontosít.

A folyamatok alapvető ismétlődő tevékenységek automatizálásának alapvető részét képezik a DevSecOps életciklusában. A CI/CD-ben a csapat rendszeresen egyesíti a fejlesztői kódot egy központi kódbázissal, és automatikusan szabványos buildeket és tesztelési folyamatokat futtat, amelyek biztonsági eszközkészleteket is tartalmaznak.

A folyamatok szkriptek futtatására vagy kód éles környezetekben való üzembe helyezésére való használata egyedi biztonsági kihívásokat jelenthet. Győződjön meg arról, hogy a CI-/CD-folyamatok nem válnak rosszindulatú kódok futtatására, hitelesítő adatok ellopására vagy a támadók számára a hozzáféréshez szükséges felület biztosítására. Azt is biztosítania kell, hogy csak a csapat által kiadni kívánt kód legyen üzembe helyezve. Ez a folyamat magában foglalja a CI/CD-folyamatok összetevőit, különösen azokat az összetevőket, amelyek a támadás részeként használható különböző feladatok között vannak megosztva.

A szoftveres anyagjegyzék -generálást (SBOM) a buildelési folyamatba kell automatizálni, hogy manuális fejlesztői műveletek nélkül hozza létre ezt a kritikus fontosságú kód-eredet-összetevőt.

A folyamatok biztonsága biztosítható a folyamatokban használt erőforrások megfelelő hozzáférés-vezérlésének biztosításával, valamint az alapvető függőségek/szkriptek rendszeres ellenőrzésével/frissítésével. Fontos megjegyezni, hogy a CI/CD-folyamatokban használt szkriptek is kódnak számítanak, és ugyanúgy kell kezelni őket, mint a projekt más kódjait.

Feljegyzés

A folyamat biztonsága a mögöttes infrastruktúra és a folyamathoz használt fiókok/identitások biztonságától függ. További információkért tekintse meg a fejlesztési környezet és a biztonságos üzemeltetési vezérlők (Identity Identity/App Access Controls, Host/Container Controls, Network Access Controls) védelmét.

Standard – Ezt a vezérlőt hozzáférési szinten kell kiértékelni a projekt minden erőforrásához; ez egy kötelező vezérlő minden DevSecOps-profilszinten.

A folyamatbiztonságról további információt az Azure Pipelines biztonságossá tételéről szóló cikkben talál.

Biztonságos műveletek

Élő webhely behatolásának tesztelése

Ez a vezérlő támogatja a 7. folyamatos SDL-gyakorlatot – Biztonsági tesztelés végrehajtása.

A professzionális alkalmazásbehatolás tesztelői megpróbálják feltörni a teljes számítási feladat élő példányát. Ez a tesztelés ellenőrzi, hogy a számítási feladat biztonsági vezérlői hatékonyak és konzisztensek-e. A behatolástesztelés segít megtalálni és kiemelni a támadó által az alkalmazás kihasználásához és a vállalkozás veszélyeztetéséhez használható legkisebb ellenállás útját. A behatolási tesztek rendkívül értékesek lehetnek, ha a megfelelő időben végzik el. Használja őket, miután elhárította az olcsó és könnyen kihasználható biztonsági réseket, amelyek az előző vizsgálatokban találhatók.

Javasoljuk, hogy ezt a tesztelést a DevSecOps biztonsági profilok minden szintjén végezze el.

Ideiglenes minimum – Javasoljuk, hogy minden alkalmazáson végezze el a behatolási tesztet. Az időkorlátok miatt előfordulhat, hogy csak a támadó által kihasznált egyszerűbb módszereket tudja azonosítani az alkalmazásban. Tervezze meg, hogy ezt gyorsan a standard szintre hozza minimálisan.

Standard – Standard profil esetén javasoljuk, hogy végezze el a behatolási tesztet. Ebben az esetben összetettebb biztonsági réseket fedezhet fel a fejlesztési folyamat korai szakaszában alkalmazott extra gondosság miatt.

Magas biztonság – Az üzletági alkalmazások és a kritikus számítási feladatok esetében követelmény a behatolási teszt elvégzése. Az alkalmazások biztonsági rését fokozott figyelemmel és gondossággal kell kezelni.

A biztonsági folyamatok és eszközök továbbfejlesztése érdekében integrálja a tevékenységek eredményeit és visszajelzéseit.

Identitás-/alkalmazáshozzáférési vezérlők

Ez a vezérlő támogatja a 8. folyamatos SDL-gyakorlatot – A működési platform biztonságának biztosítása és a 6. gyakorlat – A mérnöki környezet biztonságossá tétele.

Győződjön meg arról, hogy az identitás- és hozzáférés-kezelés, beleértve a kiemelt hozzáférés biztosítását is, biztonsági ajánlott eljárásokat követnek a fejlesztési környezet, a CI/CD-folyamat, a működési számítási feladatok és más fejlesztési rendszerek minden technikai eleme esetében. A fenyegetést okozó szereplők kifinomult módszerekkel és automatizálással rendelkeznek az identitástámadásokhoz, amelyeket gyakran használnak mind az éles rendszerek, mind a fejlesztési folyamatok ellen. Az identitás- és hozzáférés-kezelés a Microsoft által javasolt Teljes felügyelet modell alappillére.

Győződjön meg arról, hogy minden fejlesztési rendszer és az azokat futtató infrastruktúra (virtuális gépek, tárolók, hálózati eszközök stb.) esetében követik a biztonsági ajánlott eljárásokat.

Ideiglenes minimum – Győződjön meg arról, hogy mindenki többtényezős hitelesítést használ, és csak a napi feladatai elvégzéséhez szükséges rendszerekhez fér hozzá.

Standard – Győződjön meg arról, hogy a számítási feladatot futtató infrastruktúra-összetevők (például virtuális gépek, tárolók, hálózati és identitásrendszerek) megfelelnek az identitás- és hozzáférés-kezelés ajánlott biztonsági eljárásainak, beleértve a kiemelt hozzáférés védelmét is.

Magas biztonság – Teljes Teljes felügyelet stratégia implementálása, amely magában foglalja az MFA-t, az identitásfenyegetések észlelését és elhárítását, valamint a felhőinfrastruktúra-jogosultságkezelést (CIEM). Végezze el az identitásrendszerek és összetevők számítási feladatspecifikus fenyegetésmodelljét , amely támogatja az egyes magas biztonsági szintű számítási feladatokat.

A felügyelt identitások a biztonságosabb és előnyben részesített hitelesítési módszerek, ahol csak lehetséges. A jogkivonatok és titkos kódok használata kevésbé biztonságos, mivel az alkalmazásrétegben kell tárolni és lekérni őket. Emellett a felügyelt identitások manuális beavatkozás nélkül automatikusan át lesznek gördülve.

További részletek és források:

Gazdagép-/tároló-/környezetvezérlők

Ez a vezérlő támogatja a 8. folyamatos SDL-gyakorlatot – A működési platform biztonságának biztosítása és a 6. gyakorlat – A mérnöki környezet biztonságossá tétele.

Győződjön meg arról, hogy minden számítási erőforrás és üzemeltetési környezet esetében követik a biztonsági ajánlott eljárásokat a fejlesztési életciklus minden technikai eleméhez. A fenyegetéskezelők kifinomult módszerekkel és automatizálással rendelkeznek az infrastruktúra és a felhasználói végpontok elleni támadásokhoz, amelyeket gyakran használnak mind az éles rendszerek, mind a fejlesztési folyamatok ellen. Az infrastruktúra-biztonság a Microsoft által javasolt Teljes felügyelet modell alappillére.

Ennek az ellenőrzésnek tartalmaznia kell a fejlesztési és működési életciklus minden elemét, beleértve, de nem kizárólagosan a következőket:

  • Általános informatikai/üzemeltetési munkaállomások és környezetek
  • Dedikált fejlesztői munkaállomások és környezetek
  • CI/CD-folyamatinfrastruktúra
  • Számítási feladatok üzemeltetési környezetei
  • Bármely más fejlesztési rendszer.

Ez a vezérlő minden olyan erőforrást tartalmaz, amely bármilyen kódot futtathat, beleértve, de nem kizárólagosan a következőkre:

  • Virtuálisgép-gazdagépek és virtuális gépek
  • Tárolók és tárolóinfrastruktúra
  • Alkalmazás-, szkript- és kódüzemeltetési platformok
  • Felhőbeli előfizetések/fiókok és -regisztrációk
  • Fejlesztői, felhasználói és informatikai Rendszergazda munkaállomások

Győződjön meg arról, hogy biztonsági ajánlott eljárásokat alkalmaz az infrastruktúra összetevőire, beleértve a biztonsági frissítéseket (javításokat), az alapkonfigurációkat és egyebeket.

Ideiglenes minimum – Standard vállalati konfigurációk alkalmazása gazdagépekhez és előfizetésekhez.

Standard – Győződjön meg arról, hogy az infrastruktúra megfelel a Microsoft Cloud Security Benchmarkban (MCSB) ismertetett ajánlott biztonsági eljárásoknak.

Magas biztonság – Szigorúan alkalmazzák az MCSB-szabványokat, és végezze el az egyes magas biztonsági számítási feladatokat támogató infrastruktúra számítási feladatspecifikus veszélyforrás-modelljét .

További részletek és források:

Hálózati hozzáférés-vezérlők

Ez a vezérlő támogatja a 8. folyamatos SDL-gyakorlatot – A működési platform biztonságának biztosítása és a 6. gyakorlat – A mérnöki környezet biztonságossá tétele.

Győződjön meg arról, hogy a hálózati hozzáférés-kezelés biztonsági ajánlott eljárásai a fejlesztési környezet, a CI/CD-folyamat, a működési számítási feladatok környezete és más fejlesztési rendszerek minden technikai eleme esetében követve vannak. A fenyegetést okozó szereplők kifinomult módszerekkel és automatizálással rendelkeznek az identitástámadásokhoz, amelyeket gyakran használnak mind az éles rendszerek, mind a fejlesztési folyamatok ellen. A hálózati biztonság a Microsoft által javasolt Teljes felügyelet modell alappillére.

A hálózati biztonságnak a következőket kell tartalmaznia:

  • Külső hálózatvédelem – A kéretlen külső/internetes forgalomtól való elkülönítés és az ismert támadástípusok mérséklése. Ez az elkülönítés általában internetes tűzfal, webalkalmazási tűzfal (WAF) és API biztonsági megoldások formájában történik.
  • Belső hálózatvédelem – Elkülönítés a kéretlen belső forgalomtól (más vállalati hálózati helyekről). Ez az elkülönítés a külső hálózatvédelemhez hasonló vezérlőket használhat, és részletes lehet a számítási feladathoz, illetve adott összetevőkhöz és IP-címekhez.
  • Szolgáltatásmegtagadási kockázatcsökkentések – Az elosztott szolgáltatásmegtagadás (DDoS) és más szolgáltatásmegtagadási támadások elleni védelem.
  • Security Service Edge (S Standard kiadás) – Ügyféloldali mikrosegmentáció használata közvetlenül az erőforrásokhoz való biztonságos hozzáférés biztosítására, beleértve Teljes felügyelet szabályzatok alkalmazását is.

Győződjön meg arról, hogy minden fejlesztési rendszer és az azokat futtató infrastruktúra (virtuális gépek, tárolók, hálózati eszközök stb.) esetében követik a biztonsági ajánlott eljárásokat.

Ideiglenes minimum – Standard vállalati konfigurációk alkalmazása a számítási feladatokhoz.

Standard – Győződjön meg arról, hogy minden rendszer rendelkezik külső hálózatvédelemmel, DDoS-védelemmel és minimális számítási feladatonkénti belső hálózatvédelemmel.

Magas biztonság – Minden standard védelem, valamint a belső hálózati védelem magas részletessége, a külső hálózatvédelmi mechanizmusokon keresztüli kimenő kiszolgálóforgalom kényszerített bújtatása, valamint az egyes magas biztonsági számítási feladatokat támogató hálózati infrastruktúra számítási feladatspecifikus fenyegetésmodellje .

További részletek és források:

Monitorozás, válasz és helyreállítás

Ez a vezérlő támogatja a 9. folyamatos SDL-gyakorlatot – Biztonsági monitorozás és válasz implementálása.

Győződjön meg arról, hogy a biztonsági műveletek (SecOps/SOC) csapatai rendelkeznek láthatósági, fenyegetésészlelési és reagálási eljárásokkal a számítási feladatokhoz (API-khoz és alkalmazásokhoz), valamint az azokat üzemeltető infrastruktúrához. Győződjön meg arról, hogy a SecOps és az infrastruktúra/számítási feladatok csapatai közötti csapatközi folyamatok és eszközök lehetővé teszik a támadás utáni gyors helyreállítást.

Ez a vezérlő fenntartja a számítási feladat biztonságát, amint éles környezetben van, és aktívan fut a szervezetben. Ezt a folyamatot integrálni kell a meglévő biztonsági műveleti képességgel, amely észleli és reagál a biztonsági incidensekre.

Az egyéni számítási feladatok biztonsági monitorozása a gyakori összetevők kiterjesztett észlelési és válaszmegoldásait kombinálja a naplók és egyéb alkalmazásadatok elemzésével a potenciális biztonsági fenyegetések észleléséhez és vizsgálatához. Az egyéni alkalmazásadatok gyakran tartalmaznak információkat a felhasználói kérésekről, az alkalmazás tevékenységéről, a hibakódokról, a hálózati forgalomról, az alkalmazás egyéb releváns adatairól, az adatbázisokról, a hálózati végpontokról és más rendszerösszetevőkről.

Ezek az adatok ezután a valós idejű fenyegetésfelderítésből származó megállapításokkal bővülnek, és azonosítják a rendellenes viselkedés mintáit, amelyek a hálózatba való behatolás lehetséges kísérleteit jelezhetik. Az Aggregált, korrelált és normalizált XDR és Security Information and Event Management (SIEM) platform szervizelési műveleteket kínál.

Ideiglenes minimum – XDR-képességek üzembe helyezése a környezetben a végfelhasználói eszközök forgalmának figyeléséhez.

Standard – XDR- és egyéni SIEM-észlelések üzembe helyezése, amelyek azonosítják a rendellenes viselkedést a teljes környezethez képest. Ez a profil egyéni észleléseket is tartalmazhat az egyes számítási feladatokhoz.

Magas biztonság – Standard vezérlők, valamint egyéni számítási feladatonkénti észlelések a számítási feladat fenyegetésmodellezéséből származó megállapítások alapján. A profil és az AI kombinálásával környezetfüggő tudatosságot biztosíthat a szervizelési javaslatokhoz.

Következő lépések

Fogadja el ezeket a biztonsági vezérlőket, és igazodjon a szervezet kockázattűrési és termelékenységi követelményeihez. Olyan folyamatos fejlesztési megközelítést kell használnia, amelyben folyamatosan az ideális állapotra épít.

Kezdje a vezérlők és a minimális ideális célszintek rangsorolásával. Először győződjön meg arról, hogy pozitív biztonsági és kis súrlódású változásokra van szüksége. Rangsorolja, implementálja és integrálja az első vezérlőt, majd ismételje meg a folyamatot a következő vezérlővel.

Fontossági sorrendbe kell helyezni a kritikus alapokat a széles körű pozitív hatásuk, valamint a hitelesítő adatok és titkos kulcsok vizsgálata miatt, mivel a támadók gyakran használják őket.