Biztonság a DevOpsban (DevSecOps)

A biztonság a DevOps kulcsfontosságú része. De honnan tudja egy csapat, hogy egy rendszer biztonságos-e? Valóban lehetséges teljesen biztonságos szolgáltatást nyújtani?

Sajnos a válasz nem. A DevSecOps folyamatos és folyamatos munka, amely a fejlesztés és az informatikai műveletek minden résztvevőjének figyelmét igényli. Bár a munka soha nincs teljesen kész, a csapatok által a behatolások megelőzésére és kezelésére alkalmazott eljárások segíthetnek a lehető legnagyobb mértékben biztonságos és ellenálló rendszerek kialakításában.

Alapvetően, ha valaki be akar jutni, bejut, és kész... fogadja el ezt. Azt mondjuk az ügyfeleknek, hogy az első dolog, amit mondunk, az, hogy részt veszel a harcban, függetlenül attól, hogy gondoltad-e, hogy benne vagy vagy sem. Másodszor, szinte biztos, hogy behatoltak." - Michael Hayden, az NSA és a CIA volt igazgatója.

A biztonsági beszélgetés

A formális DevSecOps-stratégiával nem rendelkező csapatoknak javasoljuk, hogy a lehető leghamarabb kezdjenek hozzá a tervezéshez. Eleinte előfordulhat, hogy a csapattagok ellenállást élveznek, akik nem értékelik teljesen a létező fenyegetéseket. Mások úgy érzik, hogy a csapat nincs kellően felkészülve a probléma kezelésére, és hogy bármilyen különleges befektetés pazarló módon elvonná a figyelmet a funkciók szállításától. Azonban el kell kezdeni a beszélgetést, hogy konszenzust alakítsunk ki a kockázatok természetéről, arról, hogy a csapat hogyan mérsékelheti őket, és hogy a csapatnak szüksége van-e a jelenleg nem használt erőforrásokra.

A szkeptikusok várhatóan néhány gyakori argumentumot hoznak, például:

• Mennyire valós a fenyegetés? A csapatok gyakran nem értékelik a védelemmel megbízott szolgáltatások és adatok potenciális értékét.
• A csapatunk jó, ugye? A biztonsági vita kételynek tűnhet abban, hogy a csapat képes-e biztonságos rendszert létrehozni.
• Nem hiszem, hogy lehetséges. Ez a fiatal mérnökök gyakori érve. A tapasztalattal rendelkezők általában jobban tudják.
• Még soha nem törtek be. De honnan tudod? Honnan tudnád ?
• Végtelen viták az értékről. A DevSecOps egy komoly elkötelezettség, amely az alapvető funkcióktól való elterelésnek tekinthető. Bár a biztonsági befektetést más igényekkel kell egyensúlyba helyezni, nem hagyható figyelmen kívül.

A gondolkodásmódváltás

A DevSecOps-kultúra fontos szemléletváltást igényel. Nem csak a behatolások megelőzésére van szükség, hanem feltételezzük is őket.

Biztonsági stratégia összetevői

Számos technika alkalmazható a biztonságosabb rendszerek keresésében.

Incidensek megelőzése	Incidensek feltételezése
Fenyegetésmodellek	Hadijáték-gyakorlatok
Kódáttekintés	Központi biztonsági monitorok
Biztonsági tesztelés	Élő webhely behatolási tesztjei
Biztonsági fejlesztési életciklus (SDL)

Minden csapatnak már rendelkeznie kell legalább néhány gyakorlattal a szabálysértések megelőzésére. A biztonságos kód írása egyre inkább alapértelmezett, és számos ingyenes és kereskedelmi eszköz áll rendelkezésre a statikus elemzéshez és más biztonsági tesztelési funkciókhoz.

Sok csapat azonban nem rendelkezik olyan stratégiával, amely feltételezi, hogy a rendszer megsértése elkerülhetetlen. Feltételezve, hogy betörtek az ön rendszerébe, nehéz beismerni, különösen akkor, ha nehéz beszélgetéseket folytat a vezetőséggel, de ez a feltételezés segíthet a saját tempójában megválaszolni a biztonsági kérdésekkel kapcsolatos kérdéseket. Nem akarja megpróbálni megoldani egy igazi biztonsági vészhelyzetet.

Az átgondolandó gyakori kérdések a következők:

• Hogyan fogja észlelni a támadást?
• Hogyan válaszol, ha támadás vagy behatolás történik?
• Hogyan fog felépülni egy támadásból, például az adatok kiszivárgása vagy illetéktelen beavatkozás esetén?

A DevSecOps főbb eljárásai

Számos gyakori DevSecOps-gyakorlat létezik, amelyek gyakorlatilag bármilyen csapatra vonatkoznak.

Először is, összpontosítson az észlelési középidejének javítására és az átlagos helyreállítási középidejének javítására. Ezek a metrikák azt jelzik, hogy mennyi ideig tart észlelni egy incidenst, és mennyi ideig tart a helyreállítás. Nyomon követhetők a biztonsági válaszcsomagok folyamatos, élő helyszíni tesztelésével. A lehetséges szabályzatok értékelésekor fontos szempont ezeknek a metrikáknak a javítása.

Gyakoroljon mélységi védelmet. Ha incidens történik, a támadók hozzáférhetnek a belső hálózatokhoz és a bennük lévő mindenhez. Bár ideális lenne a támadók leállítása, mielőtt ilyen messzire jutna, a szabálysértések feltételezése arra ösztönzi a csapatokat, hogy minimalizálják a már bejutott támadók expozícióját.

Végül végezze el a gyakorlatok és környezetek rendszeres, incidens utáni értékelését. A szabálysértés megoldása után a csapatnak értékelnie kell a szabályzatok teljesítményét, valamint a szabályzatok saját betartását. A szabályzatok akkor a leghatékonyabbak, ha a csapatok ténylegesen követik őket. Minden jogsértést, akár valós, akár gyakorlat, a fejlesztés lehetőségének kell tekinteni.

Stratégiák a fenyegetések mérséklésére

Túl sok fenyegetés van az összes számbavételéhez. Bizonyos biztonsági rések olyan függőségek problémáiból adódnak, mint például az operációs rendszerek és a szoftverkönyvtárak, ezért ezek naprakészen tartása kritikus fontosságú. Másoknak a rendszerkód hibái az oka, amelyek gondos elemzést igényelnek a kereséshez és a javításhoz. A rossz titkosítás kezelése számos adatvédelmi incidens oka, csakúgy, mint a társadalmi manipuláció. Érdemes átgondolni a különböző biztonsági réseket, és hogy mit jelentenek a rendszer számára.

Támadási vektorok

Fontolja meg azt a forgatókönyvet, amelyben a támadó hozzáférést kapott egy fejlesztő hitelesítő adataihoz. Mit tehetnek?

Kiváltság	Támadás
Küldhetnek e-maileket?	Adathalász kollégák
Hozzáférhetnek más gépekhez?	Bejelentkezés, mimikatz, ismétlés
Módosíthatják a forrást?	Kód injektálása
Módosíthatják a buildelési/kiadási folyamatot?	Kód injektálása, szkriptek futtatása
Hozzáférnek egy tesztkörnyezethez?	Ha egy éles környezet a tesztkörnyezetre támaszkodik, aknázza ki
Hozzáférhetnek az éles környezethez?	Annyi lehetőség...

Hogyan védekezhet csapata ezek ellen a vektorok ellen?

• Titkos kulcsok tárolása védett tárolókban
• Helyi rendszergazdai fiókok eltávolítása
• SAMR korlátozása
• Hitelesítő adatok védelme
• Kettős otthonú kiszolgálók eltávolítása
• Előfizetések elkülönítése
• Többtényezős hitelesítés
• Különleges jogosultsággal rendelkező munkaállomások
• Észlelés az ATP és a Microsoft Defender for Cloud használatával

Titkos kódok kezelése

Minden titkos kódot védett tárolóban kell tárolni. Titkos kódok a következők:

• Jelszavak, kulcsok és jogosultsági tokenek
• Tárfiókkulcsok
• Certificates
• Megosztott, nem éles (tesztelési vagy fejlesztési) környezetekben használt hitelesítő adatok

A titkos kódok duplikálásának kiküszöböléséhez tárolóhierarchiát kell használnia. Azt is mérlegelje, hogy a titkos kulcsok hogyan és mikor érhetők el. Néhányat üzembe helyezéskor használnak a környezetkonfigurációk létrehozásakor, míg mások futásidőben érhetők el. Az üzembehelyezési idő titkos kódjai általában új üzembe helyezést igényelnek az új beállítások felvételéhez, míg a futásidejű titkos kulcsok szükség esetén elérhetők, és bármikor frissíthetők.

A platformok biztonságos tárolási funkciókkal rendelkeznek a titkos kódok CI/CD-folyamatokban és felhőkörnyezetekben, például az Azure Key Vaultban és a GitHub Actionsben való kezeléséhez.

Hasznos eszközök

• A Microsoft Defender for Cloud nagyszerűen használható általános infrastruktúra-riasztásokhoz, például kártevőkhez, gyanús folyamatokhoz stb.
• Forráskódelemzési eszközök statikus alkalmazásbiztonsági teszteléshez (SAST).
• A GitHub fejlett biztonsága az adattárak elemzéséhez és monitorozásához.
• A mimikatz a Windows helyi biztonsági hatóság alrendszerszolgáltatásának lsass.exememóriájából kinyeri a jelszavakat, kulcsokat, pin-kódokat, jegyeket és egyebeket. Csak rendszergazdai hozzáférést igényel a géphez, vagy egy olyan fiókot, amely engedélyezve van a hibakeresési jogosultsággal.
• A BloodHound egy gráfot készít az Active Directory-környezeten belüli kapcsolatokról. A piros csapat segítségével könnyen azonosíthatók a nehezen azonosítható támadási vektorok.

Hadijáték-gyakorlatok

A Microsoftnál gyakori gyakorlat a hadijáték-gyakorlatok végzése. Ezek olyan biztonsági tesztelési események, amelyek során két csapat feladata egy rendszer biztonsági és szabályzatainak tesztelése.

A vörös csapat egy támadó szerepét veszi át. Valós támadásokat próbálnak modellelni, hogy réseket találjanak a biztonságban. Ha bármelyiket ki tudják használni, bemutatják a jogsértések lehetséges hatását is.

A kék csapat átveszi a DevOps-csapat szerepét. Tesztelik, hogy képesek-e észlelni és reagálni a vörös csapat támadására. Ez segít a helyzettudatosság növelésében, valamint a DevSecOps-stratégia felkészültségének és hatékonyságának mérésében.

Háborús játékok stratégiájának fejlesztése

A háborús játékok hatékonyak a biztonság megerősítésében, mert arra ösztönzik a vörös csapatot, hogy megtalálják és kihasználják a problémákat. Valószínűleg sokkal könnyebb lesz, mint korábban vártuk. Azok a csapatok, amelyek nem próbálták meg aktívan megtámadni a saját rendszereiket, általában nem tudják, hogy mekkora méretű és mennyiségű biztonsági rés áll rendelkezésre a támadók számára. Előfordulhat, hogy a kék csapat először demoralizálódik, mivel többször elgázolják őket. Szerencsére a rendszernek és a gyakorlatoknak idővel fejlődnie kell, hogy a kék csapat következetesen nyerjen.

Felkészülés háborús játékokra

A háborús játékok megkezdése előtt a csapatnak gondoskodnia kell minden olyan problémáról, amit egy biztonsági ellenőrzés során felfedezhetnek. Ez egy nagyszerű gyakorlat, amelyet célszerű elvégezni a támadás előtt, mert kiinduló tapasztalatot biztosít mindenki számára, hogy összehasonlíthassa, amikor az első kihasznált biztonsági rést megtalálják a későbbiekben. Kezdje a biztonsági rések manuális kódvizsgálati és statikus elemzési eszközökkel történő azonosításával.

Csoportok rendszerezése

A piros és kék csapatokat különlegesség szerint kell szervezni. A cél az, hogy a lehető leghatékonyabb végrehajtás érdekében mindkét oldalon a legtehetségesebb csapatokat építsék ki.

A vörös csapatnak tartalmaznia kell néhány biztonsági gondolkodású mérnököt és fejlesztőt, akik mélyen ismerik a kódot. Ha lehetséges, érdemes kibővíteni a csapatot egy behatolástesztelő szakemberrel. Ha nincs szakember házon belül, sok vállalat biztosítja ezt a szolgáltatást, és mellé mentorálást is kínál.

A kék csapatnak olyan ops-gondolkodású mérnökökből kell állnia, akik alapos ismereteket szerezhetnek a rendszerekről és a naplózásról. Nekik van a legjobb esélyük a gyanús viselkedés észlelésére és kezelésére.

Korai háborús játékok futtatása

Várják, hogy a vörös csapat hatékony legyen a korai háborús játékokban. Elég egyszerű támadásokkal, például a rosszul védett titkos kódok megkeresésével, az SQL-injektálással és a sikeres adathalászati kampányokkal kell sikereket elérniük. A javítások és a szabályzatokkal kapcsolatos visszajelzések alkalmazása sok időt vesz igénybe a fordulók között. Ez szervezetenként eltérő lesz, de nem szeretné elindítani a következő fordulót, amíg mindenki biztosan tudja, hogy az előző fordulót már kihasználták, amennyire csak lehet.

Folyamatban lévő háborús játékok

Néhány forduló után a vörös csapatnak kifinomultabb technikákra kell támaszkodnia, például a helyek közötti szkriptelésre (XSS), a deszerializálási támadásokra és a mérnöki rendszerek biztonsági réseire. Ha külső biztonsági szakértőket hozunk be olyan területeken, mint az Active Directory, hasznos lehet a homályosabb biztonsági rések elleni támadáshoz. Ekkorra a kék csapatnak nem csak egy edzett platformmal kell rendelkeznie a védelemhez, hanem átfogó, központosított naplózást is használnia kell a incidens utáni kriminalisztikai vizsgálatokhoz.

"A védők listákban gondolkodnak. A támadók grafikonokon gondolkodnak. Mindaddig, amíg ez igaz, a támadók nyernek." - John Lambert (MSTIC)

Idővel a vörös csapat sokkal hosszabb ideig tart, hogy elérje a célokat. Ilyenkor gyakran több biztonsági rés felderítésére és láncolására lesz szükség, hogy korlátozott hatást gyakoroljanak. A valós idejű monitorozási eszközök használatával a kék csapatnak valós időben kell megkezdenie a kísérleteket.

Guidelines

A háborús játékok nem lehetnek mindenki számára ingyenesek. Fontos felismerni, hogy a cél egy hatékonyabb, hatékonyabb csapat által futtatott rendszer létrehozása.

Magatartási kódex

Íme egy minta magatartási kódex, amelyet a Microsoft használ:

1. Mind a piros, mind a kék csapatnak semmi baja nem lesz. Ha jelentős a károkozás lehetősége, dokumentálni és kezelni kell.
2. A vörös csapatnak nem szabad a célobjektumok megszerzéséhez többet kockáztatnia a szükségesnél.
3. A józan ész szabályai a fizikai támadásokra vonatkoznak. Bár a vörös csapatot arra ösztönzik, hogy kreatívak legyenek nem technikai támadásokkal, például a szociális tervezéssel, nem szabad hamis jelvényeket nyomtatniuk, embereket zaklatniuk stb.
4. Ha egy társadalommérnöki támadás sikeres, ne fedje fel annak a személynek a nevét, aki sérült. A lecke megosztható anélkül, hogy elidegenítenének vagy zavarba hoznak egy csapattagot, akivel mindenkinek dolgoznia kell.

Az együttműködés szabályai

Íme a Microsoft által használt előjegyzési mintaszabályok:

1. Ne befolyásolja a rendszer rendelkezésre állását.
2. Ne férhessen hozzá külső ügyféladatokhoz.
3. Ne gyengítse jelentősen a helyszíni biztonsági védelmet semmilyen szolgáltatáson.
4. Ne végezzen szándékosan romboló műveleteket az erőforrások ellen.
5. A hitelesítő adatok, a biztonsági rések és a beszerzett egyéb kritikus információk védelme.

Termékek

Minden biztonsági kockázatot vagy tanulságot dokumentálni kell a javítási elemek hátralékában. A Teamsnek szolgáltatásiszint-szerződést (SLA-t) kell meghatároznia a biztonsági kockázatok gyors kezelésére. A súlyos kockázatokat a lehető leghamarabb meg kell oldani, míg kisebb problémák esetén előfordulhat, hogy két futamra van határidő.

Egy jelentést a teljes szervezetnek be kell mutatni a tanult tanulságokkal és a talált biztonsági résekkel. Ez egy tanulási lehetőség mindenki számára, ezért igyekezz a lehető legtöbbet kihozni belőle.

A Microsoft tanulságai

A Microsoft rendszeresen használ háborús játékokat, és rengeteg leckét tanult az út során.

• A háborús játékok hatékonyan módosíthatják a DevSecOps-kultúrát, és szem előtt tarthatja a biztonságot.
• Az adathalászati támadások nagyon hatékonyak a támadók számára, és nem szabad alábecsülni. Az hatás korlátozható a gyártási hozzáférés korlátozásával és a kéttényezős hitelesítés megkövetelésével.
• A mérnöki rendszer vezérlése minden felett uralmat biztosít. Ügyeljen arra, hogy szigorúan szabályozza a build-/kiadási ügynökhöz, az üzenetsorhoz, a készlethez és a definícióhoz való hozzáférést.
• Gyakorolja a mélységi védelmet, hogy megnehezítse a támadók dolgát. Minden határ, amit át kell törniük, lelassítja őket, és újabb lehetőséget kínál arra, hogy elkapják őket.
• Soha ne keresztezd a bizalom területeit. Az éles rendszernek soha nem szabad megbíznia semmiben a tesztelésben.

Következő lépések

További információ az Azure-beli biztonsági fejlesztési életciklusról és DevSecOpsról.