Gyorsított biztonságos fejlesztés egyszerű fenyegetésmodellezés segítségével

Újra kiadta Platón

Követő: 0

Fast-Track Secure Development Using Lite Threat Modeling PlatoBlockchain Data Intelligence. Vertical Search. Ai.

Az elfoglalt szoftvercégeknél folyamatosan történik új fejlesztés. De történik-e biztonságos fejlődés is?

Az egyszerű fenyegetésmodellezésnek (LTM) nevezett folyamat az érdekelt feleket bevonja a biztonságos fejlesztésbe, biztosítva, hogy a biztonság beépüljön, és ne legyen rácsavarozva. Mi az LTM, és miben különbözik a hagyományos fenyegetésmodellezéstől?

Az egyszerű fenyegetés modellezési megközelítés

Az LTM egy egyszerűsített megközelítés a rendszerben vagy alkalmazásban előforduló potenciális biztonsági fenyegetések és sebezhetőségek azonosítására, értékelésére és mérséklésére. Ez egy egyszerűsített változata hagyományos fenyegetésmodellezés, amely jellemzően a biztonsági kockázatok átfogóbb és részletesebb elemzését foglalja magában.

Az LTM esetében nem ragasztunk kézzel tűket a rendszerbe vagy az alkalmazásba, hogy megnézzük, eltörik-e, ahogyan a tolltesztnél tennénk. Inkább „elméleti lyukakat” szúrunk az alkalmazásba, feltárva a lehetséges támadási utakat és sebezhetőségeket.

Íme néhány megfontolandó kérdés:

Ki akarná megtámadni a rendszereinket?
A rendszer mely összetevőit lehet megtámadni, és hogyan?
Mi a legrosszabb dolog, ami történhet, ha valaki betör?
Milyen negatív hatással lenne ez cégünkre? Ügyfeleinken?

Mikor hajtják végre az LTM-eket?

A legjobb, ha LTM-et hajt végre, amikor új szolgáltatást adnak ki, egy biztonsági vezérlőt módosítanak, vagy bármilyen változtatást hajtanak végre a meglévő rendszerarchitektúrán vagy infrastruktúrán.

Ideális esetben LTM-eket hajtanak végre után a tervezési fázis és előtt végrehajtás. Végül is sokkal, de sokkal könnyebb kijavítani egy sebezhetőséget, mielőtt az éles forgalomba kerülne. Ahhoz, hogy az LTM-eket az egész szervezetben kiterjessze, feltétlenül világos és következetes folyamatokat és szabványokat hozzon létre. Ez magában foglalhatja a fenyegetési kategóriák közös halmazának meghatározását, a fenyegetések és sebezhetőségek közös forrásainak azonosítását, valamint a kockázatok értékelésére és csökkentésére szolgáló szabványos eljárások kidolgozását.

Hogyan végezzen LTM-eket a szervezetében

Ahhoz, hogy saját szervezetén belül megkezdhesse az LTM-ek végrehajtását, először kérje meg a belső biztonsági csapatokat, hogy vezessék az LTM-beszélgetéseket. Ahogy a mérnöki csapatok jobban megismerik a folyamatot, megkezdhetik saját fenyegetési modelljeik végrehajtását.

Ahhoz, hogy az LTM-eket az egész szervezetben kiterjessze, feltétlenül világos és következetes folyamatokat és szabványokat hozzon létre. Ez magában foglalhatja a fenyegetési kategóriák közös halmazának meghatározását, a fenyegetések és sebezhetőségek közös forrásainak azonosítását, valamint a kockázatok értékelésére és csökkentésére szolgáló szabványos eljárások kidolgozását.

Gyakori LTM hibák, amelyeket el kell kerülni

A biztonsági emberek nagyszerűek a fenyegetések modellezésében: gyakran a legrosszabbra számítanak, és elég fantáziájúak ahhoz, hogy kitalálják a szélsőséges eseteket. De ezek a tulajdonságok arra is késztetik őket, hogy LTM csapdákba essenek, mint például:

Túlságosan a kiugró értékekre való összpontosítás. Ez egy LTM gyakorlat során fordul elő, amikor a beszélgetés fókusza a legreálisabb fenyegetésekről a kiugró eseményekre kerül. Ennek megoldásához feltétlenül ismerje meg ökoszisztémáját. Használja a biztonsági információ- és eseménykezelési (SIEM) és más biztonsági megfigyelőrendszerekből származó információkat. Ha például 10,000 XNUMX támadás éri az alkalmazásprogramozási felület (API) végpontjait, akkor tudja, hogy az ellenfelei erre összpontosítanak. Az LTM-nek is erre kell összpontosítania.
Egyre túl technikás. Gyakran az elméleti sebezhetőség felfedezése után a műszaki szakemberek „problémamegoldó módba” kapcsolnak. A végén „megoldják” a problémát, és a technikai megvalósításról beszélnek, ahelyett, hogy a sebezhetőségnek a szervezetre gyakorolt hatásáról beszélnének. Ha úgy találja, hogy ez történik az LTM gyakorlatok során, próbálja meg visszahúzni a beszélgetést: Mondja el a csapatnak, hogy még nem fog a megvalósításról beszélni. Beszéljen keresztül a kockázat és hatás először.
Feltételezve, hogy az eszközök önmagukban kezelik a kockázatokat. A fejlesztők gyakran elvárják, hogy eszközeik megtalálják az összes problémát. Végül is a valóság az, hogy egy fenyegetési modellnek nem az a célja, hogy egy adott sebezhetőséget találjon. Inkább a rendszer általános kockázatát kell megvizsgálni, építészeti szinten. Valójában a nem biztonságos tervezés volt az OWASP egyik legfrissebb megoldása A webalkalmazások 10 legfontosabb biztonsági kockázata. Az építészeti szintű fenyegetésmodellekre van szükség, mert az építészeti biztonsági problémákat a legnehezebb kijavítani.
Figyelmen kívül hagyja a lehetséges fenyegetéseket és sebezhetőségeket. A fenyegetés modellezése nem egyszeri gyakorlat. Fontos, hogy rendszeresen újraértékeljük a lehetséges fenyegetéseket és sebezhetőségeket, hogy megelőzzük a folyamatosan változó támadási vektorokat és fenyegetés szereplőit.
Nem vizsgálja felül a magas szintű megvalósítási stratégiákat. A potenciális fenyegetések és sebezhetőségek azonosítása után fontos hatékony ellenintézkedések bevezetése azok mérséklésére vagy megszüntetésére. Ez magában foglalhatja a műszaki ellenőrzések végrehajtását, például a bemeneti ellenőrzést, a hozzáférés-szabályozást vagy a titkosítást, valamint a nem technikai jellegű ellenőrzéseket, például az alkalmazottak képzését vagy adminisztratív irányelveit.

Következtetés

Az LTM egy egyszerűsített megközelítés a potenciális biztonsági fenyegetések és sebezhetőségek azonosítására, értékelésére és mérséklésére. Rendkívül fejlesztőbarát, és biztonságos kódot kap korai fenyegetésmodellezést végez a szoftverfejlesztési életciklusban (SDLC). Még jobb, ha az LTM-et maguk a szoftverfejlesztők és az építészek is elkészíthetik, ahelyett, hogy a fenyegetésmodellezést laboratóriumokra hagyatkoznának.

Az LTM-ek következetes és hatékony fejlesztésével és bevezetésével a szervezetek gyorsan és hatékonyan azonosíthatják és kezelhetik a legkritikusabb biztonsági kockázatokat, miközben elkerülik a gyakori buktatókat és hibákat.